Anthropic 엔지니어링 블로그 #19: Infrastructure Noise in Agentic Coding Evals — 벤치마크 점수, 그거 진짜 모델 차이인가요?

이 글은 Anthropic 엔지니어링 블로그에 2026년 2월 5일 게재된 “Quantifying infrastructure noise in agentic coding evals” 를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/infrastructure-noise

한 줄로 말하면

#

리더보드 모델 간 격차보다, RAM·CPU 설정 차이로 생기는 점수 변동이 더 클 수 있다.

어떤 문제를 해결하려 했나

#

코딩 에이전트 벤치마크는 정적인 입출력 평가가 아닙니다. 모델이 코드를 짜고, 테스트를 돌리고, 반복합니다. 인프라 자체가 문제 해결 과정의 일부예요.

그런데 사람들은 리더보드를 볼 때 점수 차이 1~2%p로 우열을 가립니다. 그 차이가 진짜 모델 능력 차이일까요? 아니면 한 모델이 더 좋은 VM에서 돌았을 뿐일까요?

Anthropic이 측정해보니 — 충격적이게도 인프라 설정만으로 6%p가 흔들렸습니다. 리더보드 상위 모델 사이 격차보다 큰 변동입니다.

해결책: 인프라 노이즈 정량화

#

1. 측정 결과

#

Terminal-Bench 2.0 에서 자원 할당을 다르게 줘 비교:

흥미로운 점: 1x → 3x로 늘릴 때는 에러율만 떨어집니다 (5.8% → 2.1%, p < 0.001). 그런데 3x → 무제한으로 늘리면 에러율은 1.6%p만 더 떨어지는데 성공률은 4%p나 오릅니다. 무한 자원이 단순한 신뢰성 회복을 넘어, 새로운 풀이법 을 가능하게 만든 거예요.

“추가 자원은 큰 의존성 풀, 비싼 서브프로세스 생성, 메모리 많이 먹는 테스트 같은 접근을 시도할 수 있게 한다.”

2. 노이즈의 출처

#

1. 자원 할당 (CPU/메모리, 특히 강제 방식)
2. 컨테이너 런타임 파라미터 (보장 할당 vs 강제 종료 한도)
3. 시간 제한
4. 클러스터 상태와 시간대 — 트래픽 패턴에 따른 API 지연 변동
5. 하드웨어 사양 — 강력한 하드웨어가 점수를 인위적으로 올림
6. 동시성·송신 대역폭

3. 통제 방법

#

원문 권장 6가지:

• 이중 파라미터 자원 명세 — 보장 할당과 강제 종료 한도를 따로 명시
• 여유 보정 — 점수가 통계적 노이즈 안에 들어오게 경험적으로 조정
• 3x 천장 기준 — Terminal-Bench가 사용한 합리적 기준
• 여러 시간대 실행 — 시간대 노이즈 평균화
• 설정 공개 — 강제 방식·하드웨어·실험 파라미터 모두 공개
• 운영 환경과 동일 조건 — 가능하면 운영 인프라와 같게

결과 / 효과

#

리더보드 점수 해석의 변화:

• 3%p 미만 격차는 의심해야 함 — 설정 매칭이 문서화되지 않았다면
• 서로 다른 시험을 본 셈 — 다른 자원 예산의 에이전트들은 같은 시험이 아님
• 타이트한 제약은 효율 코드를, 넉넉한 제약은 무거운 도구 활용을 보상 — 둘 다 합법이지만 다른 능력을 잼

원문 인용: “몇 %p 차이가 진짜 능력 차이를 신호할 수도 있고, 그냥 더 큰 VM이었을 수도 있다.”

핵심 결론

#

벤치마크 점수를 비교할 때 사람들은 본능적으로 “점수가 높은 쪽이 더 좋은 모델” 이라고 결론냅니다. 이 글의 답은 다릅니다.

“점수 차이가 모델 능력인 줄 알았는데, 사실은 인프라 노이즈가 그보다 컸을 수도 있다.”

리더보드의 정밀해 보이는 숫자 뒤에는 상당한 불확실성이 숨어 있습니다. 작은 격차는 인프라 설정 매칭이 공개되기 전까지는 결론을 보류해야 해요.

내 작업에 적용한다면

#

시나리오 1 — 일반적인 데이터 분석 과정

#

분석 결과 비교에서도 똑같은 노이즈가 작용합니다. “A 모델이 B 모델보다 정확도 1% 높았다"는 결론에 인프라 영향이 숨어 있을 수 있어요.

[Before — 단순 점수 비교]
모델 A: 정확도 91%
모델 B: 정확도 90%
   → A가 더 좋다고 결론

[infrastructure noise 적용]
[변동 요인 통제]
- 같은 하드웨어, 같은 시간대에서 측정
- 자원 할당 동일하게
- 데이터 분할 시드 고정
[반복 측정]
- 5~10회 반복 후 평균과 표준편차 보고
- 점수 차이가 표준편차보다 작으면 결론 보류
[설정 문서화]
- 측정 환경을 다 적어두기

핵심: 분석 모델 비교에서 “단발 점수"가 아니라 “분포와 환경” 으로 봐야 합니다.

시나리오 2 — 웹 사이트를 자동으로 운영할 때

#

운영 자동화 성능 평가도 같은 함정이 있어요. “이번 배포는 더 빠르다”, “응답 속도가 좋아졌다” 같은 비교가 사실은 시간대 차이일 수 있습니다.

[Before — 단발 측정]
배포 전 평균 응답 200ms, 배포 후 180ms
   → 개선됐다고 결론

[infrastructure noise 적용]
[같은 조건 매칭]
- 같은 시간대, 같은 트래픽 수준에서 비교
- A/B 테스트로 동시 비교
[충분한 표본]
- 시간대·요일별 분포 보기
- 평균 외에 분위수(p50, p95, p99)도
[배포 외 변동 통제]
- 같은 시기 다른 변경 사항 기록
- CDN/네트워크 상태도 측정

핵심: 운영 자동화의 성능 변화는 “인프라 노이즈를 통제한 비교” 위에서만 의미가 있습니다. 단발 수치 비교는 자주 거짓 결론을 만들어요.

Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.