에이전트형 코딩 평가에서 인프라로 인한 노이즈를 정량적으로 측정하기

https://www.anthropic.com/engineering/infrastructure-noise

인프라를 어떻게 구성하느냐에 따라 에이전트형 코딩 벤치마크 점수가 몇 퍼센트씩 출렁일 수 있고, 그 폭이 리더보드 상위 모델들 간 점수 차이보다 더 클 때도 있습니다.

Agentic coding 벤치마크인 SWE-bench와 Terminal-Bench는 종종 프런티어 모델들의 소프트웨어 엔지니어링 능력을 비교하는 데 사용되며, 리더보드 최상위권의 점수 차이는 몇 퍼센트 포인트에 불과한 경우가 많습니다. 이런 점수는 상대적인 모델 역량을 정밀하게 측정한 값으로 간주되며, 어떤 모델을 배포할지 결정할 때 점점 더 큰 영향을 미치고 있습니다. 하지만 저희가 확인한 바로는, 인프라 구성만으로도 이 격차를 넘어서는 점수 차이가 발생할 수 있습니다. 내부 실험에서 Terminal-Bench 2.0에 가장 적게 리소스를 할당한 설정과 가장 많이 할당한 설정 사이의 점수 차이는 6%포인트였으며(p < 0.01), 이는 리더보드 상위 모델들 간의 점수 차이를 웃도는 수준입니다.

정적 벤치마크는 모델이 한 번에 내놓은 출력을 그대로 점수화하기 때문에, 실행 환경은 점수에 직접 영향을 주지 않습니다. 하지만 agentic coding 평가에서는 상황이 다릅니다. 모델에게는 프로그램을 작성하고, 테스트를 실행하고, 의존성을 설치하고, 여러 턴에 걸쳐 반복 시도할 수 있는 완전한 환경이 주어집니다. 이때 런타임은 더 이상 수동적인 컨테이너가 아니라, 문제 해결 과정의 한 축을 이루는 능동적인 구성 요소가 됩니다. 서로 다른 리소스 예산과 시간 제한을 가진 두 에이전트는 사실상 같은 시험을 치르고 있는 것이 아닙니다.

평가를 설계하는 사람들은 이런 점을 점점 더 고려하기 시작했습니다. 예를 들어 Terminal-Bench 2.0은 최신 2.0 릴리스에서 작업별로 권장 CPU와 RAM을 명시하고 있습니다. 하지만 리소스를 “명시”하는 것과 그것을 “일관되게 강제”하는 것은 다른 문제입니다. 더 나아가, 저희는 리소스 강제 방식의 차이만으로도 벤치마크가 실제로 측정하는 대상이 달라질 수 있다는 사실을 발견했습니다.

우리가 여기까지 오게 된 과정

저희는 Google Kubernetes Engine 클러스터에서 Terminal-Bench 2.0을 실행합니다. 이 셋업을 튜닝하는 과정에서, 저희가 얻은 점수가 공식 리더보드에 나온 점수와 맞지 않는다는 사실과, 인프라 관련 오류 비율이 예상보다 높다는 사실을 발견했습니다. 작업의 최대 6%가 파드 오류로 실패하고 있었으며, 이들 대부분은 모델이 작업을 해결할 수 있는 능력과는 무관한 문제였습니다.

점수 차이는 리소스 강제 방식에서 비롯되었습니다. 저희 Kubernetes 구현에서는 작업별 리소스 스펙을 “최소 보장치”이자 “하드 상한선”으로 동시에 취급했습니다. 즉, 각 컨테이너에 해당 리소스를 보장해 주는 동시에, 그 한도를 초과하는 순간 컨테이너를 바로 종료하는 방식이었습니다. 컨테이너 런타임은 보통 두 개의 별도 파라미터로 리소스를 관리합니다. 하나는 선제적으로 예약되는 보장 리소스, 다른 하나는 이를 초과하면 컨테이너를 종료하는 하드 제한입니다. 이 둘을 같은 값으로 설정해버리면 일시적인 스파이크를 위한 여유가 전혀 없어집니다. 순간적인 메모리 변동만으로도, 원래라면 성공할 수 있었던 컨테이너가 OOM(Out Of Memory)으로 종료될 수 있습니다. 이를 완화하기 위해 Terminal-Bench 리더보드에서는 보다 관대한 샌드박싱 제공자를 사용합니다. 이 구현은 인프라 안정성을 우선시해, 컨테이너를 종료하지 않고 일시적인 리소스 초과를 허용합니다.

이 발견은 더 큰 질문을 던지게 만들었습니다. “리소스 설정이 평가 점수에 얼마나 큰 영향을 미치는가?”라는 질문입니다.

이 스캐폴드(실행 인프라)의 영향을 정량화하기 위해, 저희는 Terminal-Bench 2.0을 여섯 가지 리소스 구성에서 실행했습니다. 여기에는 작업별 스펙을 바닥이자 하드 상한으로 삼는 엄격한 설정(1x)부터, 사실상 리소스에 상한을 두지 않는 완전 언캡(un­capped) 설정까지가 포함됩니다. 이 실험에서 다른 조건은 모두 동일하게 유지했습니다. 같은 Claude 모델, 같은 평가 하니스(harness), 같은 작업 세트를 사용했습니다.

실험 결과, 리소스에 여유를 줄수록 성공률이 높아졌습니다. 이는 주로 인프라 오류율이 단계별로 단조롭게 감소한 데서 비롯되었습니다. 1x처럼 엄격하게 제한된 설정에서는 인프라 오류가 5.8%였지만, 상한을 해제하면 0.5%까지 떨어졌습니다. 특히 1x에서 3배 헤드룸(3x)으로 바꿨을 때 인프라 오류율은 5.8%에서 2.1%로 유의미하게 감소했으며(p < 0.001), 리소스에 더 많은 여유를 주면 컨테이너가 할당량 초과로 종료되는 빈도가 줄어들었습니다.

1x에서 3x 사이 구간에서는 성공률이 통계적 잡음 범위 내에서만 변동했습니다(p=0.40). 1x 구성에서 크래시가 나던 작업 대부분은, 리소스가 충분했더라도 어차피 실패했을 것이라는 점을 데이터에서 확인했습니다. 에이전트가 탐색을 진행하다가 리소스 벽에 막혀 선점(preempt)되지만, 어차피 정답에 도달하는 경로 위에 있지는 않았던 셈입니다.

그러나 3x 근처부터는 이 흐름이 달라집니다. 성공률이 인프라 오류 감소 속도보다 더 빠르게 상승하기 시작합니다.

3x에서 언캡까지 가는 구간에서 인프라 오류율은 추가로 1.6%포인트 감소한 반면, 성공률은 거의 4%포인트 상승했습니다. 여유 있는 리소스 덕분에 에이전트는 넉넉한 할당이 있어야만 가능한 전략을 시도할 수 있게 됩니다. 예를 들어, 대형 의존성을 끌어오거나, 비용이 큰 서브프로세스를 여러 개 띄우거나, 메모리를 많이 쓰는 테스트 스위트를 실행하는 식입니다. 리소스 상한을 풀었을 때, 1x 대비 전체 성공률은 6%포인트 증가했습니다(p < 0.01). 이 구간의 변동은 특히 rstan-to-pystan⁠이나 compile-compcert⁠ 같은 작업에서 두드러졌는데, 이들은 추가적인 메모리 헤드룸을 줄 경우 성공률이 크게 향상되는 경향을 보였습니다.

이것이 측정에 어떤 영향을 미치는지

Terminal-Bench 스펙의 약 3배까지는, 리소스를 더 주는 것이 주로 인프라의 신뢰성을 개선하는 방향으로 작용합니다. 구체적으로는 일시적 리소스 스파이크로 인한 문제를 줄여 줍니다. Terminal-Bench 유지보수자가 사용하는 샌드박싱 제공자는 이러한 효과를 내부적으로 암묵 구현하고 있습니다. 덕분에 평가 자체가 더 안정적이 되지만, 난이도가 실질적으로 낮아지는 것은 아닙니다.

하지만 3x를 넘어가는 순간부터 추가 리소스는 에이전트가 원래는 풀 수 없던 문제를 실제로 풀 수 있게 도와주기 시작합니다. 이 지점에서 리소스 제한은 평가가 “무엇을” 측정하는지 자체를 바꾸게 됩니다. 리소스를 촘촘하게 제한하면 매우 효율적인 전략에 보상이 돌아가고, 넉넉한 리소스 아래에서는 가능한 모든 자원을 잘 활용하는 에이전트에게 보상이 돌아갑니다.

예를 들어, 빠르게 날렵한 코드를 작성하는 에이전트는 빡빡한 제약 아래에서도 좋은 성과를 낼 것입니다. 반면, 무거운 도구들을 동원해 사실상 브루트포스에 가까운 전략을 구사하는 에이전트는 리소스가 넉넉한 환경에서 더 잘 작동합니다. 두 방식 모두 충분히 의미 있는 평가 대상이지만, 리소스 구성을 명시하지 않은 채 이들을 하나의 점수로 압축해 버리면, 점수 차이를 어떻게 해석해야 하는지 — 특히 실제 환경에 얼마나 일반화될 수 있는지를 — 이해하기가 어려워집니다.

Terminal-Bench의 bn-fit-modify⁠처럼 베이지안(Bayesian) 네트워크 피팅이 필요한 작업에서, 일부 모델은 첫 단계에서 표준 파이썬 데이터 사이언스 스택을 설치하려고 듭니다. 예를 들어 pandas⁠, networkx⁠, scikit-learn⁠과 그에 필요한 전체 툴체인을 설치하는 식입니다. 리소스 제한이 느슨할 때는 이 전략이 통합니다. 하지만 제한이 엄격한 환경에서는, 에이전트가 정답 코드를 한 줄도 작성하기 전에 설치 과정에서 메모리가 부족해 파드가 종료됩니다. 사실 더 가벼운 전략도 존재합니다. 예를 들어 표준 라이브러리만 활용해 수식을 직접 구현하는 방식입니다. 실제로 일부 모델은 기본적으로 이런 접근을 택하기도 합니다. 그렇지 않은 모델도 있습니다. 모델마다 기본 전략이 다른데, 리소스 구성에 따라 어떤 전략이 우연히 성공하게 되느냐가 달라집니다.

저희는 이런 핵심 결과를 여러 Anthropic 모델에 걸쳐 재현했습니다. 효과의 방향은 일관되었고, 그 크기만 모델별로 달랐습니다. Claude 이외의 모델에서도 같은 경향이 나타나는 것으로 보이나, 아직 이 모델들에 대해 엄밀한 실험을 수행한 것은 아닙니다.

또한 Terminal-Bench 외의 평가에서도 같은 패턴이 나타나는지 확인하기 위해 SWE-bench에 교차 실험(crossover experiment)을 적용했습니다. 여기서는 227개 문제에 대해 각 10개 샘플씩을 사용해, 기본 설정의 최대 5배까지 주어진 총 RAM을 변화시켰습니다. 이 경우에도 동일한 효과가 관찰되었습니다. 점수는 RAM이 늘어날수록 단조롭게 상승했지만, 1x 대비 5x에서의 점수 차이는 1.54%포인트 정도에 그쳤습니다. SWE-bench 작업은 상대적으로 덜 리소스를 많이 쓰는 편이어서 효과가 작게 나타난 것은 예상된 결과이지만, 이 경우에도 리소스 할당이 평가와 무관하다고 보기는 어렵다는 점을 보여 줍니다.

다른 변동 요인들

리소스 할당만이 숨겨진 변수는 아닙니다. 특정 구성에서는 시간 제한 또한 중요한 역할을 하기 시작합니다.

원칙적으로는 클러스터 상태, 하드웨어 스펙, 동시 실행 수준, 심지어 (이그레스(egress) 대역폭)¹에 이르기까지, 평가 셋업의 모든 요소가 최종 점수에 영향을 줄 수 있습니다. agentic 평가 자체가 설계상 엔드 투 엔드 시스템 테스트이기 때문에, 시스템을 구성하는 어떤 요소라도 혼란 변수(confounder)가 될 수 있습니다. 예를 들어 저희는 경험적으로, 통과율이 시간대에 따라 달라지는 것을 관찰했습니다. 이는 아마도 API 레이턴시가 트래픽 패턴이나 인시던트 발생 여부에 따라 달라지기 때문일 것입니다. 이 효과를 엄밀하게 계량화한 것은 아니지만, 이 사례는 더 큰 메시지를 시사합니다. “모델의 순수한 역량”과 “인프라의 동작 방식” 사이의 경계는 단일 벤치마크 점수가 암시하는 것보다 훨씬 더 흐릿하다는 점입니다. 모델 제공자는 전용 하드웨어를 할당해 평가 인프라를 이런 요인으로부터 어느 정도 보호할 수 있지만, 외부 평가자는 이를 그대로 따라 하기 쉽지 않습니다.

공개 벤치마크의 목적은 보통 모델의 순수한 능력을 측정하는 데 있지만, 실제로는 인프라 특성까지 함께 섞여 측정될 위험이 있습니다. 전체 스택을 한 번에 검증하는 엔드 투 엔드 테스트가 필요할 때는 오히려 이런 점이 장점일 수 있지만, 대부분의 경우에는 그렇지 않습니다. 특히 공개 공유를 목적으로 하는 코딩 평가에서는, 여러 시간대와 여러 날에 걸쳐 반복 실행해 결과를 평균 내는 방식이 인프라에서 오는 잡음을 완화하는 데 도움이 될 수 있습니다.

우리가 추천하는 것

가장 이상적인 상황은 각 평가를 실제 배포 환경과 완전히 동일한 하드웨어 조건(평가를 실행하는 스캐폴드와 추론 스택 모두 포함)에서 실행하는 것입니다. 이렇게 하면 모든 면에서 완벽한 재현성을 확보할 수 있습니다. 하지만 현실적으로 항상 이렇게 하기란 어렵습니다.

컨테이너 런타임이 실제로 리소스를 강제하는 방식을 고려해 보면 — 하나는 보장된 할당량, 다른 하나는 컨테이너를 종료하는 별도의 하드 제한 — 저희는 평가에서 작업별로 두 파라미터를 모두 명시하는 방식을 권장합니다. 단일 고정값만 지정하면, 보장 할당량과 종료 상한을 동일하게 설정하는 셈이 되어 여유 버퍼가 전혀 남지 않습니다. 저희가 1x 구성에서 관찰했던 일시적인 메모리 스파이크만으로도 평가가 쉽게 불안정해질 수 있습니다. 두 파라미터를 분리해서 지정하면, 컨테이너가 불필요하게 OOM 종료되지 않도록 숨 쉴 공간을 충분히 제공하면서도, 점수 부풀리기를 막기 위한 하드 상한선은 유지할 수 있습니다.

두 값 사이의 간격은 바닥과 상한에서의 점수가 통계적 잡음 범위 내에 머무르도록 조정하는 것이 좋습니다. 예를 들어 Terminal-Bench 2.0에서는 작업별 스펙의 3배 정도를 상한으로 설정했을 때, 인프라 오류율이 5.8%에서 2.1%로 약 3분의 1 수준으로 줄어들었고(p < 0.001), 점수 상승 폭은 크지 않고 통계적 잡음 수준(p = 0.40) 안에 머물렀습니다. 이는 꽤 괜찮은 트레이드오프로 볼 수 있습니다. 인프라로 인한 혼란 변수를 상당 부분 제거하면서도, 의미 있는 리소스 압박 자체는 여전히 유지할 수 있기 때문입니다. 정확한 배율은 벤치마크와 작업 분포에 따라 달라질 수 있으므로, 이를 명시해 함께 공개해야 하지만, 이러한 “실증적 캘리브레이션” 원칙 자체는 일반적으로 적용 가능합니다.

우리가 이것을 중요하게 여기는 이유

이러한 발견은 단순히 평가 인프라 설계를 넘어서는 실질적인 함의를 갖습니다. 벤치마크 점수는 점점 더 다양한 의사결정에 직접 사용되고 있지만, 이러한 관심과 의존도의 상승이 항상 그에 상응하는 실행·보고상의 엄밀함으로 이어진 것은 아닙니다. 현재 상황에서는, 리더보드 상의 2점 차이가 실제 모델 역량의 차이를 반영하고 있을 수도 있지만, 한쪽 평가가 더 좋은 하드웨어에서 돌아갔기 때문일 수도 있고, 단지 더 운 좋은 시간대에 실행되었기 때문일 수도 있습니다. 심지어 이 모든 요인이 겹쳤을 가능성도 있습니다. 평가 셋업 구성이 명시적으로 공개되거나 표준화되지 않는 한, 외부에서 이 차이를 식별하기는 어렵고, 객관적인 결과를 동일 조건에서 재현하려는 추가 노력이 없이는 사실상 알 수 없습니다.

Anthropic 같은 연구 기관 입장에서 이 결과가 의미하는 바는, agentic 평가의 리소스 구성 역시 프롬프트 형식이나 샘플링 온도만큼 중요한 1급(퍼스트 클래스) 실험 변수로 다뤄야 한다는 점입니다. 즉, 이를 동일한 수준의 엄격함으로 문서화하고 통제해야 한다는 뜻입니다. 벤치마크를 유지·관리하는 쪽에서는 Terminal-Bench 2.0처럼 권장 리소스 스펙을 공개하는 것만으로도 큰 도움이 되며, 여기에 리소스 강제 방식까지 함께 명시한다면 저희가 확인한 격차를 상당 부분 해소할 수 있습니다. 그리고 벤치마크 결과를 소비하는 모든 이들에게 주는 핵심 메시지는 이렇습니다. agentic 평가에서 보고되는 작은 점수 차이는 숫자가 주는 정밀한 인상에 비해 훨씬 더 큰 불확실성을 내포하고 있다는 점입니다. 특히 일부 혼란 변수는 통제 자체가 매우 어렵다는 점을 감안하면 더욱 그렇습니다.

리소스 설정 방법이 표준화되기 전까지, 저희 데이터는 리더보드에서 3%포인트 미만의 점수 차이는 평가 셋업이 충분히 문서화되고 일치한다는 것이 확인되기 전까지는 의심의 여지가 있다고 말해 줍니다. Terminal-Bench에서 중간 수준의 리소스 구성들 사이에서 관찰된 점수 분산은 2%포인트 바로 아래 수준이었습니다. 순수한 이항 분포 기반의 단순 신뢰구간만 보더라도 이미 1–2%포인트 정도의 폭을 갖습니다. 저희가 여기서 보여 준 인프라 관련 혼란 변수는 이 신뢰구간 “안에” 포함되는 것이 아니라, 그 위에 추가로 얹히는 요소입니다. 리소스 할당 범위의 극단값들을 비교하면, 점수 차이는 최대 6%포인트에 이릅니다.

리더보드에서 몇 점 앞선다는 사실은 실제로 의미 있는 역량 차이를 의미할 수도 있지만, 그저 더 큰 VM 위에서 평가를 돌렸다는 뜻일 수도 있습니다.