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

SWE-bench, Terminal-Bench 같은 에이전트 코딩 벤치마크는 프론티어 모델의 소프트웨어 엔지니어링 역량을 비교하는 데 널리 사용됩니다. 리더보드 상위권은 불과 몇 퍼센트포인트 차이로 순위가 갈리는 경우가 많습니다. 이런 점수는 모델 간 상대적 역량을 정밀하게 측정한 결과로 받아들여지며, 어떤 모델을 배포할지 결정하는 데도 점점 더 큰 영향을 미치고 있습니다. 그런데 저희는 인프라 설정만으로도 이 격차를 넘어서는 점수 차이가 발생할 수 있다는 사실을 발견했습니다. 내부 실험에서 Terminal-Bench 2.0 기준으로 가장 많은 리소스를 할당한 구성과 가장 적게 할당한 구성 사이의 점수 차이는 6퍼센트포인트에 달했습니다(p < 0.01).

정적 벤치마크(Static benchmark)는 모델의 출력을 직접 채점하므로 실행 환경이 결과에 영향을 주지 않습니다. 반면 에이전트 코딩 평가는 다릅니다. 모델에게 완전한 환경이 주어지고, 그 안에서 프로그램을 작성하고 테스트를 실행하며 의존성을 설치하고 여러 턴에 걸쳐 반복 작업을 수행합니다. 런타임은 더 이상 수동적인 컨테이너가 아니라, 문제 해결 과정의 핵심 구성 요소입니다. 리소스 예산과 시간 제한이 다른 두 에이전트는 사실상 같은 시험을 치르는 것이 아닙니다.

평가 개발자들도 이 문제를 인식하기 시작했습니다. 예를 들어 Terminal-Bench 2.0은 최신 2.0 릴리스에서 태스크별로 권장 CPU와 RAM을 명시하고 있습니다. 하지만 리소스를 명시하는 것과 일관되게 적용하는 것은 다른 문제입니다. 더 나아가 저희는 적용 방식 자체가 벤치마크가 실제로 무엇을 측정하는지를 바꿔버릴 수 있다는 점을 발견했습니다.

발견 경위

저희는 Google Kubernetes Engine 클러스터에서 Terminal-Bench 2.0을 실행하고 있었습니다. 환경을 보정하는 과정에서 점수가 벤치마크 공식 리더보드와 맞지 않았고, 인프라 오류율도 예상보다 높았습니다. 태스크의 최대 6%가 파드 오류로 실패했으며, 대부분은 모델의 문제 해결 능력과 무관한 원인이었습니다.

점수 차이의 원인은 리소스 적용 방식이었습니다. 저희의 Kubernetes 구현에서는 태스크별 리소스 스펙을 하한이자 상한으로 동시에 설정했습니다. 각 컨테이너에 지정된 리소스가 보장되지만, 초과하는 순간 즉시 종료되는 방식이었습니다. 컨테이너 런타임은 보장 할당량(미리 확보하는 리소스)과 하드 리밋(초과 시 컨테이너를 종료하는 임계값)이라는 두 가지 별도의 매개변수로 리소스를 제어합니다. 이 두 값을 동일하게 설정하면 일시적인 스파이크를 흡수할 여유가 전혀 없어, 순간적인 메모리 변동만으로도 정상 동작했을 컨테이너가 OOM으로 종료될 수 있습니다. 이를 감안하여 Terminal-Bench의 리더보드는 다른 샌드박싱 제공자를 사용하는데, 그 구현은 보다 관대하게 동작하여 컨테이너를 바로 종료하지 않고 일시적인 초과 할당을 허용함으로써 인프라 안정성을 우선시합니다.

이 발견은 더 큰 질문으로 이어졌습니다. 리소스 설정이 평가 점수에 얼마나 영향을 미치는가?

스캐폴드(scaffold)의 영향을 정량화하기 위해 Terminal-Bench 2.0을 6가지 리소스 구성으로 실행했습니다. 태스크별 스펙을 하한과 상한으로 동시에 적용하는 엄격한 적용(1x)부터 완전 무제한까지 다양하게 설정했으며, 그 외 조건은 모두 동일하게 유지했습니다. 동일한 Claude 모델, 동일한 하네스, 동일한 태스크 셋입니다.

실험 결과, 리소스 여유분이 늘어날수록 성공률이 높아졌습니다. 이는 주로 인프라 오류율이 단계마다 단조 감소한 데 기인합니다. 엄격한 적용(1x)에서 5.8%였던 오류율이 무제한 설정에서는 0.5%로 떨어졌습니다. 엄격한 적용에서 3배 여유분(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 유지관리팀이 사용하는 샌드박싱 제공자도 이와 동일한 역할을 이면에서 수행하고 있으며, 평가가 더 쉬워지지 않으면서 더 안정적으로 작동하게 됩니다.

그러나 3배를 넘어서면 추가 리소스가 에이전트의 문제 해결 자체를 적극적으로 돕기 시작합니다. 이전에는 풀지 못했던 문제를 풀 수 있게 되는 것입니다. 이는 리소스 제한이 평가가 측정하는 대상 자체를 바꿀 수 있음을 보여줍니다. 타이트한 제한은 의도치 않게 매우 효율적인 전략에 유리하게 작용하고, 넉넉한 제한은 가용 리소스를 잘 활용하는 에이전트에게 유리합니다.

간결하고 효율적인 코드를 빠르게 작성하는 에이전트는 타이트한 제약 조건에서 좋은 성과를 냅니다. 무거운 도구를 동원해 무차별 대입으로 풀어내는 에이전트는 넉넉한 조건에서 유리합니다. 둘 다 충분히 의미 있는 테스트 대상이지만, 리소스 구성을 명시하지 않은 채 하나의 점수로 뭉뚱그리면 그 차이를—그리고 실제 환경에서의 일반화 가능성을—해석하기 어려워집니다.

Terminal-Bench 태스크 중 베이지안 네트워크 피팅을 요구하는 bn-fit-modify를 예로 들어보겠습니다. 일부 모델은 첫 수로 파이썬 데이터 과학 표준 스택인 pandas, networkx, scikit-learn,와 관련 툴체인 전체를 설치합니다. 넉넉한 제한에서는 이 방식이 동작합니다. 하지만 타이트한 제한에서는 설치 도중 파드의 메모리가 부족해져, 에이전트가 솔루션 코드를 한 줄도 작성하기 전에 종료됩니다. 표준 라이브러리만으로 수학을 직접 구현하는 더 가벼운 전략도 존재하며, 실제로 일부 모델은 이 방식을 기본으로 채택합니다. 그렇지 않은 모델도 있습니다. 모델마다 기본 접근 방식이 다르고, 리소스 구성이 어떤 접근 방식이 성공하는지를 좌우합니다. 저희는 이 핵심 발견을 여러 Anthropic 모델에서 재현했습니다. 효과의 방향은 일관되었고, 크기는 모델에 따라 달랐습니다. Claude 이외의 모델에서도 동일한 경향이 나타나는 것으로 보이지만, 이에 대해서는 아직 엄밀한 테스트를 수행하지 않았습니다.

이 패턴이 Terminal-Bench 외의 평가에서도 성립하는지 확인하기 위해 SWE-bench에서 교차 실험도 진행했습니다. 227개 문제에 대해 각 10개 샘플로 총 가용 RAM을 기준의 최대 5배까지 변경했습니다. 동일한 효과가 확인되었으나 크기는 더 작았습니다. 점수는 RAM에 따라 역시 단조 증가했지만, 5배에서 1배 대비 상승폭은 1.54퍼센트포인트에 그쳤습니다. SWE-bench 태스크는 리소스 요구량이 상대적으로 낮으므로 효과가 작은 것은 예상 범위 내이지만, 리소스 할당이 SWE-bench에서도 중립적이지 않다는 점은 분명합니다.

기타 변동 요인

리소스 할당이 유일한 숨은 변수는 아닙니다. 특정 구성에서는 시간 제한도 결과에 영향을 미치기 시작합니다.

원칙적으로 평가 환경의 모든 요소가 최종 점수에 영향을 줄 수 있습니다. 클러스터 상태, 하드웨어 스펙, 동시 실행 수준, 심지어 이그레스(egress) 대역폭까지 모두 해당됩니다. 에이전트 평가는 구조적으로 엔드투엔드 시스템 테스트이며, 시스템의 모든 구성 요소가 교란 변수로 작용할 수 있습니다. 예를 들어 저희는 합격률이 시간대에 따라 변동하는 현상을 경험적으로 관찰했는데, 이는 API 지연 시간이 트래픽 패턴과 장애에 따라 달라지기 때문으로 보입니다. 이 효과를 공식적으로 정량화하지는 않았지만, 더 큰 시사점을 보여줍니다. "모델 역량"과 "인프라 동작" 사이의 경계는 단일 벤치마크 점수가 암시하는 것보다 훨씬 모호하다는 점입니다. 모델 제공업체는 전용 하드웨어를 확보해 평가 인프라를 이런 요인으로부터 차단할 수 있지만, 외부 평가자가 같은 조치를 취하기는 쉽지 않습니다.

공개 벤치마크는 본래 순수한 모델 역량을 측정하기 위한 것이지만, 실제로는 인프라 특이성과 뒤섞일 위험이 있습니다. 전체 스택의 엔드투엔드 테스트가 목적이라면 이런 혼재가 바람직할 수도 있지만, 대부분의 경우에는 그렇지 않습니다. 공개적으로 공유되는 코딩 평가의 경우, 여러 시간대와 여러 날에 걸쳐 실행하면 노이즈를 평균화하는 데 도움이 됩니다.

권장 사항

이상적으로는 모든 평가를—스캐폴드와 추론 스택 모두—완전히 동일한 하드웨어 조건에서 실행하여 완벽한 재현성을 확보하는 것이 가장 좋습니다. 다만 이것이 항상 현실적이지는 않습니다.

컨테이너 런타임이 보장 할당량과 별도의 하드 킬 임계값으로 리소스를 제어한다는 점을 고려하면, 평가 시 태스크별로 단일 고정값이 아닌 두 매개변수를 모두 명시할 것을 권장합니다. 단일 정확한 스펙은 보장 할당량과 킬 임계값을 동일하게 설정하여 여유가 전혀 없으므로, 1x에서 저희가 확인한 일시적 메모리 스파이크만으로도 평가가 불안정해집니다. 두 매개변수를 분리하면 불필요한 OOM 종료를 방지할 만큼의 여유를 확보하면서도, 점수 부풀림을 막는 하드 상한을 유지할 수 있습니다.

두 값 사이의 폭은 하한과 상한에서의 점수가 노이즈 범위 내에 들도록 보정해야 합니다. 예를 들어 Terminal-Bench 2.0에서 태스크별 스펙의 3배를 상한으로 설정하면 인프라 오류율이 약 3분의 2로 감소했으며(5.8%→2.1%, p < 0.001), 점수 상승폭은 노이즈 범위 내로 미미했습니다(p = 0.40). 이는 합리적인 균형점입니다. 인프라 교란 변수가 대부분 제거되면서도 의미 있는 리소스 압박은 유지됩니다. 정확한 배수는 벤치마크와 태스크 분포에 따라 달라지므로 함께 보고해야 하지만, 실험적으로 보정한다는 원칙 자체는 범용적으로 적용 가능합니다.

이 문제에 주목하는 이유

이번 발견은 평가 인프라를 넘어 실질적인 영향을 미칩니다. 벤치마크 점수는 의사결정 근거로 점점 더 많이 활용되고 있지만, 이러한 관심과 의존도 증가에 비해 평가 실행 및 보고 방식의 엄밀함은 미처 따라가지 못하고 있습니다. 현 상황에서 리더보드의 2포인트 차이는 진정한 역량 차이를 반영할 수도 있지만, 한쪽이 더 좋은 하드웨어에서 평가를 실행했거나, 운 좋게 트래픽이 한가한 시간대에 돌렸거나, 혹은 두 가지 모두의 결과일 수도 있습니다. 평가 환경 구성이 공개되거나 표준화되지 않는 한, 관심 있는 당사자가 동일한 조건에서 결과를 직접 재현하는 수고를 들이지 않는 이상 외부에서 이를 구분하기 어렵습니다.

Anthropic 같은 연구소 입장에서 시사점은 다음과 같습니다. 에이전트 평가의 리소스 구성을 프롬프트 형식이나 샘플링 온도와 동일한 수준의 엄밀함으로 문서화하고 통제해야 하는 일급 실험 변수로 다루어야 합니다. 벤치마크 유지관리자 입장에서는 Terminal-Bench 2.0처럼 권장 리소스 스펙을 공개하는 것이 큰 도움이 되며, 여기에 적용 방식까지 명시하면 저희가 확인한 격차를 해소할 수 있습니다. 벤치마크 결과를 참고하는 모든 이에게 핵심 시사점은 이렇습니다. 에이전트 평가에서 작은 점수 차이는 보고된 숫자의 정밀도가 암시하는 것보다 훨씬 큰 불확실성을 내포하며, 특히 일부 교란 변수는 통제 자체가 매우 어렵습니다.

리소스 방법론이 표준화되기 전까지, 저희 데이터에 따르면 리더보드에서 3퍼센트포인트 미만의 차이는 평가 구성이 문서화되고 조건이 일치될 때까지 회의적으로 바라볼 필요가 있습니다. Terminal-Bench의 중간 범위 리소스 구성에서 관측된 점수 편차는 2퍼센트포인트를 약간 밑돌았습니다. 단순 이항 신뢰 구간만으로도 이미 1~2퍼센트포인트를 차지하는데, 여기서 확인한 인프라 교란 변수는 그 안에 포함되는 것이 아니라 위에 추가로 쌓입니다. 할당 범위의 양 극단에서는 편차가 6퍼센트포인트에 달합니다.

몇 포인트 차이의 우위가 진짜 역량 격차를 의미하는 것인지, 아니면 단지 더 큰 VM 덕분인지—지금으로서는 쉽게 구분할 수 없습니다.

감사의 글

작성: Gian Segato. Nicholas Carlini, Jeremy Hadfield, Mike Merrill, Alex Shaw의 기여에 특별히 감사드립니다. 이 연구는 코딩 에이전트 평가를 담당하는 여러 팀의 공동 노력으로 이루어졌습니다. 기여에 관심 있는 분은 anthropic.com/careers에서 지원하실 수 있습니다.