코딩 벤치마크 숫자, Anthropic가 6%p 흔들림을 공개했다

2026-04-12

6%p가 먼저 걸렸습니다

Anthropic Engineering이 올린 'Quantifying infrastructure noise in agentic coding evals'를 읽고 저는 코딩 벤치마크 숫자부터 다시 보게 됐습니다. Terminal-Bench 2.0에서 가장 빡빡한 설정과 가장 넉넉한 설정 사이 점수 차이가 6 percentage points였다고 적었거든요.

모델이 더 똑똑해졌다는 소식은 매일 보는데, 이번 글은 좀 결이 달랐습니다. 코딩 벤치마크 숫자가 모델 실력만으로 만들어진 게 아닐 수 있다는 얘기를, Anthropic가 자기 수치로 꺼냈으니까요.

Anthropic Engineering 글이 실제로 적은 숫자

사실로 확인된 건 이렇습니다. Anthropic Engineering 글 'Quantifying infrastructure noise in agentic coding evals'는 strict enforcement에서 infra error rate가 5.8%였고, uncapped에서는 0.5%였다고 적었습니다. strict에서 3x headroom으로 올렸을 때는 2.1%까지 내려갔구요. 그 감소는 p < 0.001로 적었습니다.

여기서 더 흥미로운 대목은 3x 이후입니다. 글은 3x에서 uncapped로 가는 동안 infra errors는 1.6 percentage points 더 줄었는데 success는 almost 4 percentage points 뛰었다고 썼습니다. 같은 글에서 SWE-bench도 따로 봤는데, 227 problems에 10 samples each로 돌렸을 때 RAM을 5x로 키우자 점수가 1.54 percentage points 올라갔다고 했습니다.

Anthropic는 마지막에 이렇게 적었습니다. "A few-point lead might signal a real capability gap—or it might just be a bigger VM." 저는 이 한 줄이 이번 기사 전체보다 더 오래 남더라구요.

제가 크게 본 건 모델보다 환경이었습니다

해석을 붙이면, 코딩 벤치마크 경쟁은 이제 모델 카드만 읽어서는 안 된다는 뜻에 가깝습니다. 같은 모델이라도 RAM, kill threshold, time limit, sandbox provider가 달라지면 다른 시험을 치는 셈이 되니까요.

이건 벤치마크를 부정하자는 얘기랑은 다릅니다. 벤치마크는 여전히 필요합니다. 다만 코딩 벤치마크 숫자를 headline 하나로 소비하면, 실제 팀이 현장에서 겪는 차이를 놓치게 된다는 쪽에 더 가깝습니다.

매달 돈 내는 사람 눈에는 다르게 보입니다

매달 Claude, Copilot, Codex 같은 도구 구독료 내는 입장에선 이 대목이 꽤 현실적입니다. 회사에서 모델 선택할 때도 API 단가만 보는 게 아니구요. runner 크기, CI 시간, dependency 설치 실패, 재시도 비용이 같이 붙습니다.

Anthropic 글에서 말한 3x headroom 같은 조건은 그냥 연구실 디테일이 아닙니다. 코딩 벤치마크 숫자를 높게 만드는 환경이 실제 프로덕션 비용까지 밀어올릴 수도 있다는 얘기라서 그렇습니다. 개발팀 입장에선 모델 1등보다 먼저 청구서가 보일 때가 많거든요.

코딩 벤치마크를 읽는 방식도 바뀔 겁니다

추측이지만, 올해 나오는 코딩 벤치마크 기사들은 표가 하나 더 붙기 시작할 것 같습니다. CPU, RAM, time limit, sandbox enforcement를 같이 적지 않으면 설득력이 금방 떨어질 가능성이 커 보입니다.

벤치마크 운영자도 더 까다로워질 겁니다. Anthropic 글은 recommended specs를 적는 것만으로는 부족하고 guaranteed allocation과 hard kill threshold를 둘 다 써야 한다고 권했습니다. 이건 숫자 장난을 막자는 말이 아니라, 같은 말을 같은 조건에서 하자는 요구에 가깝습니다.

코딩 벤치마크 숫자 앞에서 남는 것

이번 코딩 벤치마크 기사를 보고 든 생각은 단순했습니다. 이제 리더보드에서 2점, 3점 차이가 보이면 모델 이름보다 실행 조건부터 확인해야 한다는 겁니다.

코딩 벤치마크를 읽을 때 이제 모델 옆이 아니라 VM 크기 옆에 시선이 먼저 갈 겁니다.