에이전틱 코딩 평가에서 인프라 노이즈 정량화하기

개발자 뉴스레터를 구독하세요

제품 업데이트, 사용법, 커뮤니티 소식 등을 매달 이메일로 받아보세요.

SWE-bench나 Terminal-Bench 같은 에이전틱 코딩 벤치마크는 최첨단 모델들의 소프트웨어 엔지니어링 능력을 비교하는 데 많이 사용되는데요. 리더보드 상위권 모델들이 겨우 몇 퍼센트 포인트 차이로 갈리는 경우가 많아요. 이런 점수들은 보통 모델의 상대적인 능력을 정밀하게 측정한 것으로 여겨지고, 어떤 모델을 배포할지 결정하는 데 점점 더 중요한 정보가 되죠. 하지만, Anthropic 팀은 인프라 설정만으로도 그런 점수 차이를 넘어서는 결과를 낼 수 있다는 걸 발견했어요. 내부 실험에서 Terminal-Bench 2.0의 리소스가 가장 많은 설정과 가장 적은 설정 간의 점수 차이가 무려 6% 포인트(p < 0.01)나 됐죠.

정적인 벤치마크는 모델의 결과물을 직접 채점해요. 런타임 환경은 결과에 전혀 영향을 미치지 않죠. 하지만 에이전틱 코딩 평가는 달라요. 모델들은 실제 환경에서 프로그램을 짜고, 테스트를 돌리고, 의존성을 설치하고, 여러 번 반복하며 문제를 해결하죠. 런타임은 더 이상 수동적인 컨테이너가 아니라, 문제 해결 과정의 필수적인 요소가 되는 거예요. 리소스 예산과 시간 제한이 다른 두 에이전트는 사실상 같은 테스트를 보는 게 아니죠.

평가 개발자들도 이제 이 점을 고려하기 시작했어요. 예를 들어, Terminal-Bench 2.0은 최신 2.0 릴리스에서 작업별 권장 CPU와 RAM을 명시하고 있어요. 하지만 리소스 명시와 일관된 적용은 다른 이야기예요. 게다가 Anthropic 팀은 리소스 적용 방식이 벤치마크가 궁극적으로 측정하는 내용을 바꿀 수 있다는 걸 알아냈어요.

이 연구에서는 Terminal-Bench 2.0을 구글 쿠버네티스 엔진 클러스터에서 돌려봤어요. 설정을 보정하는 과정에서 팀의 점수가 벤치마크의 공식 리더보드와 일치하지 않았고, 인프라 오류율이 예상외로 높다는 걸 발견했죠. 작업의 최대 6%가 파드 오류 때문에 실패했는데, 대부분은 모델의 작업 해결 능력과 무관한 문제들이었어요.

점수 불일치의 원인은 '적용 방식'에 있었어요. Anthropic 팀의 쿠버네티스 구현 방식은 작업별 리소스 사양을 최저 한도이자 엄격한 상한선으로 간주했어요. 즉, 각 컨테이너는 명시된 리소스를 보장받지만, 이를 초과하는 순간 강제 종료된 거죠. 컨테이너 런타임은 사전에 예약된 리소스인 '보장된 할당량'과 컨테이너가 강제 종료되는 '하드 제한'이라는 두 가지 별개의 파라미터로 리소스를 적용하거든요. 이 두 가지가 같은 값으로 설정되면, 일시적인 사용량 급증에 대한 여유 공간이 전혀 없는 셈이죠. 순간적인 메모리 변동만으로도 원래 성공했을 컨테이너가 OOM-kill될 수 있다는 뜻이에요. 이 점을 고려해서 Terminal-Bench의 리더보드는 다른 샌드박싱 제공업체를 사용하는데, 그 구현은 더 관대해서 일시적인 초과 할당을 허용하면서도 컨테이너를 종료하지 않아 인프라 안정성을 우선시해요.

이런 발견은 더 큰 의문을 불러일으켰죠. 리소스 설정이 평가 점수에 얼마나 큰 영향을 미칠까?

이 스캐폴드의 영향을 정량화하기 위해, Anthropic 팀은 Terminal-Bench 2.0을 6가지 리소스 구성으로 실행했어요. 작업별 사양을 엄격하게 적용하는(1x) 방식, 즉 최저 한도와 상한선 모두로 설정하는 방식부터 완전히 무제한으로 설정하는 방식까지요. 다른 모든 조건은 동일하게 유지했어요. 같은 클로드 모델, 같은 하네스, 같은 작업 세트를 사용했죠.

실험 결과, 리소스 여유 공간이 많아질수록 성공률도 높아지는 것을 확인했어요. 이는 주로 인프라 오류율이 각 단계마다 꾸준히 감소했기 때문이에요. 엄격한 적용 시 5.8%에서 무제한일 때 0.5%까지 떨어졌죠. 엄격한 적용에서 3x 여유 공간으로 넘어갈 때의 감소 폭(5.8%에서 2.1%)은 통계적으로 유의미했어요(p < 0.001). 여유 공간이 많아질수록 할당량을 초과해서 강제 종료되는 컨테이너가 줄어드는 거죠.

1x에서 3x까지는 성공 점수가 노이즈 범위 내에서 변동했어요(p=0.40). 1x에서 충돌하던 대부분의 작업은 어차피 실패했을 거예요. 이는 데이터에서 관찰한 내용이기도 해요. 에이전트가 탐색하다가 리소스 한계에 부딪혀 중단되지만, 애초에 올바른 해결 경로에 있지는 않았다는 거죠.

하지만 약 3x부터는 이 경향이 바뀌어요. 성공률이 인프라 오류 감소 속도보다 더 빠르게 상승하죠.

3x에서 무제한 설정으로 갈 때, 인프라 오류는 추가로 1.6% 포인트 감소했지만, 성공률은 거의 4% 포인트나 뛰었어요. 추가 리소스 덕분에 에이전트는 큰 의존성을 가져오고, 비용이 많이 드는 서브프로세스를 실행하고, 메모리 집약적인 테스트 스위트를 돌리는 등 넉넉한 할당량에서만 가능한 접근 방식을 시도할 수 있게 된 거죠. 리소스가 무제한일 때, 1x 대비 총 6% 포인트(p < 0.01) 상승했어요. 특히 rstan-to-pystan과 compile-compcert 같은 작업들은 메모리 여유 공간을 얻었을 때 성공률이 크게 향상됐죠.

대략 Terminal-Bench 사양의 3배까지는 추가 리소스가 인프라 신뢰성 문제, 즉 일시적인 리소스 급증을 해결해줘요. Terminal-Bench 관리자들이 사용하는 샌드박싱 제공업체는 이런 작업을 암묵적으로 백그라운드에서 처리하고 있었던 거죠. 평가는 더 안정적이지만, 더 쉬워지는 건 아니라는 이야기예요.

하지만 3x를 넘어서는 순간부터는 추가 리소스가 에이전트가 이전에 해결하지 못했던 문제를 능동적으로 해결하는 데 도움을 주기 시작해요. 이는 제한이 실제 평가의 측정 대상을 바꿀 수 있다는 걸 보여줍니다. 엄격한 제한은 의도치 않게 매우 효율적인 전략에 보상하는 반면, 넉넉한 제한은 더 관대해서 사용 가능한 모든 리소스를 잘 활용하는 에이전트에 보상하게 돼요.

간결하고 효율적인 코드를 매우 빠르게 작성하는 에이전트는 엄격한 제약 조건에서 잘 작동할 거예요. 반면, 무거운 도구로 무차별 대입(brute-force) 솔루션을 시도하는 에이전트는 넉넉한 조건에서 잘 작동하겠죠. 둘 다 유효하게 테스트할 수 있는 능력이지만, 리소스 설정을 명시하지 않고 이들을 하나의 점수로 통합하면, 그 차이와 실제 환경에서의 일반화 가능성을 해석하기 어려워져요.

베이지안 네트워크 피팅이 필요한 Terminal-Bench 작업인 bn-fit-modify를 보면, 일부 모델의 첫 번째 행동은 표준 파이썬 데이터 과학 스택인 pandas, networkx, scikit-learn 및 이들의 모든 툴체인을 설치하는 거예요. 넉넉한 제한에서는 이 방법이 통하죠. 하지만 제한이 엄격하면 에이전트가 솔루션 코드를 한 줄도 작성하기 전에 설치 중에 파드가 메모리 부족으로 꺼져버려요. 더 효율적인 전략(표준 라이브러리만 사용해서 수학 공식을 처음부터 구현하는 것)도 있지만, 어떤 모델은 그 방법을 기본으로 삼고, 어떤 모델은 그렇지 않아요. 모델마다 기본 접근 방식이 다르고, 리소스 설정이 어떤 접근 방식이 성공할지를 결정하는 거죠. Anthropic 팀은 다른 클로드 모델들에서도 이 핵심 발견을 재현했어요. 효과의 방향은 일관적이었지만, 그 크기는 다양했어요. 클로드 외 다른 모델들에서도 같은 경향이 나타나는 것 같지만, 엄격하게 테스트해보지는 않았어요.

Terminal-Bench 외 다른 평가에서도 이런 패턴이 유지되는지 확인하기 위해 SWE-bench에서 교차 실험을 진행했어요. 227개 문제에 대해 각 10개의 샘플로 총 가용 RAM을 기준선의 최대 5배까지 다양하게 설정해봤죠. 같은 효과가 나타났지만, 그 크기는 더 작았어요. RAM이 늘어날수록 점수는 단조롭게 증가했지만, 5x일 때 1x보다 단 1.54% 포인트 높았죠. SWE-bench 작업은 리소스 집약적이지 않아서 더 작은 효과가 예상되지만, 거기서도 리소스 할당이 중립적이지 않다는 걸 보여주죠.

리소스 할당만이 숨겨진 변수는 아니에요. 특정 구성에서는 시간 제한도 영향을 미치기 시작하죠.

원칙적으로는 클러스터 상태부터 하드웨어 사양, 동시성 수준, 심지어 이그레스 대역폭까지, 평가 설정의 모든 요소가 최종 점수에 영향을 줄 수 있어요. 에이전틱 평가는 본질적으로 엔드투엔드 시스템 테스트이고, 그 시스템의 어떤 구성 요소든 교란 변수로 작용할 수 있죠. 예를 들어, Anthropic 팀은 통과율이 시간대에 따라 변동하는 것을 목격했는데, 이는 아마도 트래픽 패턴과 사고에 따라 API 레이턴시가 달라지기 때문일 거예요. 이 효과를 공식적으로 정량화하지는 않았지만, 이는 ‘모델 능력’과 ‘인프라 동작’ 사이의 경계가 단일 벤치마크 점수가 시사하는 것보다 훨씬 모호하다는 거죠. 모델 제공업체는 전용 하드웨어를 사용해서 평가 인프라를 이런 문제로부터 보호할 수 있지만, 외부 평가자들은 그렇게 하기 쉽지 않아요.

공개 벤치마크는 일반적으로 순수한 모델 능력을 측정하기 위한 것이지만, 실제로는 인프라의 특이점들과 혼동될 위험이 있어요. 때로는 전체 스택의 엔드투엔드 테스트를 가능하게 하기 때문일 수도 있지만, 대부분의 경우에는 그렇지 않아요. 대중에 공유될 코딩 평가의 경우, 여러 시간대에 걸쳐 며칠 동안 실행하면 노이즈를 평균화하는 데 도움이 될 거예요.

이상적인 시나리오는 평가를 실행하는 스캐폴드와 추론 스택 모두에서 각 평가를 정확히 동일한 하드웨어 조건으로 실행하는 것인데요. 이는 모든 면에서 완벽한 재현성을 보장할 거예요. 하지만 항상 실용적이지는 않을 수 있어요.

컨테이너 런타임이 리소스를 실제로 적용하는 방식(보장된 할당량과 별도의 강제 종료 임계값)을 고려할 때, 평가에서는 단일 고정 값이 아닌, 작업별로 두 가지 파라미터 모두를 명시해야 한다고 권장해요. 단일한 정확한 사양은 보장된 할당량을 종료 임계값과 동일하게 설정하여 여유 공간을 전혀 남기지 않는다는 의미예요. Anthropic 팀이 1x에서 기록했던 일시적인 메모리 급증만으로도 평가를 불안정하게 만들기에 충분하죠. 두 파라미터를 분리하면 컨테이너에 충분한 여유 공간을 줘서 가짜 OOM kill을 방지하고, 동시에 점수 인플레이션을 막는 엄격한 상한선도 적용할 수 있게 해줘요.

두 파라미터 사이의 범위는 최저 한도와 상한선에서의 점수가 서로 노이즈 범위 내에 들도록 조정되어야 해요. 예를 들어, Terminal-Bench 2.0에서는 작업별 사양의 3배에 해당하는 상한선을 설정했을 때 인프라 오류율이 대략 3분의 2로 줄어들었고(5.8%에서 2.1%, p < 0.001), 점수 상승은 미미하고 노이즈 범위 내에 있었어요(p = 0.40). 이는 합리적인 절충안이죠. 의미 있는 리소스 압력을 제거하지 않으면서도 인프라 교란 변수가 크게 중화되는 거예요. 정확한 승수(multiplier)는 벤치마크와 작업 분포에 따라 달라질 것이므로 보고해야 하지만, 경험적 보정 원칙은 일반적으로 적용될 수 있어요.

이러한 발견은 평가 인프라를 넘어 실제적인 결과를 가져와요. 벤치마크 점수는 의사 결정의 중요한 입력값으로 점점 더 많이 사용되고 있지만, 이러한 관심과 의존도 증가에 따라 실행 또는 보고 방식에 상응하는 엄격함이 항상 따라온 건 아니에요. 현재 상황을 보면, 리더보드에서 2점 앞서는 것이 실제 능력 차이를 반영할 수도 있지만, 더 강력한 하드웨어에서 평가를 돌렸거나, 심지어 운 좋은 시간대에 돌렸기 때문일 수도 있고, 둘 다일 수도 있다는 거죠. 공개되거나 표준화된 설정 구성 없이는, 이해 관계자들이 동일한 조건에서 객관적인 결과를 재현하기 위해 더 많은 노력을 기울이지 않는 한 외부에서는 알기 어려워요.

Anthropic 같은 연구실에게 시사하는 바는, 에이전틱 평가를 위한 리소스 구성은 프롬프트 형식이나 샘플링 온도와 동일한 엄격함으로 문서화되고 제어되는 일등 실험 변수로 취급해야 한다는 거죠. 벤치마크 관리자들에게는 (Terminal-Bench 2.0처럼) 권장 리소스 사양을 공개하는 것이 큰 도움이 될 수 있으며, 적용 방법론을 명시하면 Anthropic 팀이 확인한 격차를 줄일 수 있을 거예요. 그리고 벤치마크 결과를 사용하는 모든 사람에게 핵심 시사점은, 에이전틱 평가에서 작은 점수 차이는 보고된 숫자의 정밀도가 시사하는 것보다 더 많은 불확실성을 내포하고 있다는 점이에요. 특히 일부 교란 변수는 너무 통제하기 어렵기 때문이죠.

리소스 방법론이 표준화될 때까지는, Anthropic 팀의 데이터에 따르면 3% 포인트 미만의 리더보드 점수 차이는 평가 구성이 문서화되고 일치할 때까지는 회의적인 시각으로 봐야 한다는 거죠. Terminal-Bench의 적당한 리소스 구성 범위에서 관찰된 편차는 2% 포인트 바로 아래예요. 단순 이항 신뢰 구간만으로도 이미 1~2% 포인트를 차지하는데, Anthropic 팀이 이 글에서 다루는 인프라 교란 변수는 그 위에 쌓이는 것이지, 그 안에 포함되는 게 아니에요. 할당 범위의 극단에서는 편차가 6%에 달하기도 합니다.

몇 점 차이의 리드는 실제 능력 격차를 나타낼 수도 있지만, 단순히 더 큰 VM을 썼기 때문일 수도 있다는 거예요.

작성: Gian Segato. Nicholas Carlini, Jeremy Hadfield, Mike Merrill, Alex Shaw에게 특별히 감사드립니다. 이 작업은 코딩 에이전트 평가에 참여하는 여러 팀의 공동 노력을 반영합니다. 기여에 관심 있는 지원자들은 anthropic.com/careers에서 지원할 수 있습니다.

제품 업데이트, 사용법, 커뮤니티 소식 등을 매달 이메일로 받아보세요.