코딩 에이전트 벤치마크는 리더보드 행보다 실행 매니페스트가 필요하다

지난달, 동료 한 명이 저희 채널에 스크린샷을 붙여넣었습니다. 그 내용은 _"agent X가 내부 테스트 스위트의 78%를 해결합니다."_였습니다. 누군가 어떤 스위트를 물었지만 아무도 알지 못했습니다. 스크린샷에는 막대 그래프, 백분율, 그리고 로고가 있었는데, 이 것이 우리가 지금까지 실행해 본 어떤 것과도 비교할 수 없다는 것을 확인하는 데 세 사람이 한 시간을 들여야 했습니다.

이것이 바로 에이전트 벤치마킹의 일반적인 실패 모드입니다. 부정행위는 아닙니다. 심지어 부주의함조차 아닙니다. 단지, 그 숫자를 만들어낸 '포장(envelope)' 없이 발표된 숫자일 뿐입니다.

더 나은 리더보드로 이것을 고칠 수는 없습니다. 이 문제는 숫자의 전제 조건들을 검토자가 비교할 수 있는 기계가 읽을 수 있는 아티팩트로 만듦으로써 해결됩니다. 아래는 제가 누군가의 백분율을 읽기 전에 요구하는 계약 내용입니다.

숫자는 첫 줄이 아니라 보고서의 마지막 줄이어야 한다

통과율(pass rate)은 한 번의 실행(run)에 대한 요약일 뿐입니다. 이 실행은 결정들의 묶음입니다: 어떤 태스크를 사용할지, 어떤 스냅샷을 사용할지, 어떤 재시도 정책을 사용할지, 어떤 토큰 예산(token budget)을 사용할지, 어떤 채점 스크립트를 사용할지 등. 이들 중 어느 하나라도 변경되면 백분율이 의미하는 바가 달라집니다.

그러니 먼저 이 묶음(bundle)을 문서화하고, 해시를 생성한 다음, 비로소 숫자를 계산해야 합니다. 만약 두 번의 실행이 어떤 포장 필드에 대해 의견이 다르면, 올바른 결과는 차이점(delta)이 아닙니다. 그것은 거부(refusal)입니다.

1단계: 무언가를 실행하기 전에 슬라이스를 고정하라

태스크 ID를 파일에 작성하고, 정렬한 다음, 그 파일을 해시하세요. 디렉토리를 해시하는 것이 아닙니다. '우리가 보통 사용하는 SWE 태스크' 같은 것도 아닙니다. 안정적이고 정렬된 내용으로 이루어진 단일 파일이어야 합니다.

# tasks.txt — 줄당 하나의 안정적인 태스크 ID, 주석 없음
printf '%s\n' task-0011 task-0023 task-0047 > tasks.txt
sort -o tasks.txt tasks.txt
...

이 습관 하나만으로 대부분의 벤치마크 논쟁을 종식시킬 수 있습니다. 만약 태스크가 추가되면 해시가 바뀌고, 이 해시 변화는 검토 과정에서 눈에 보입니다. 아무도 실패하는 태스크를 빼버림으로써 조용히 점수를 개선할 수 없습니다.

명확한 이유로 슬라이스를 선택했다면 그 이유 또한 문서화하세요. 단지 편리해서 선택된 슬라이스라도 괜찮습니다 — 매니페스트(manifest)에 그렇게 명시되어 있고 결론이 그 경계 안에 머물러 있다면 말입니다.

2단계: 매니페스트에 포장을 선언하라

제가 사용하는 파일입니다. 검토자들의 접촉을 견디기 위해 의도적으로 지루하게 만들었습니다.

{
  "run_id": "2026-10-18-acme-v3-r1",
  "started_at_utc": "2026-10-18T09:12:00Z",
...

두 가지 세부 사항이 중요합니다. model_snapshot은 제공업체가 그날 노출하는 어떤 버전 문자열이든 됩니다—단순한 계보명만으로는 봉투 필드가 될 수 없습니다. 왜냐하면 가문들은 아래로 이동하기 때문입니다. 실제로는 retry_policy가 temperature보다 더 중요합니다. 실패하는 테스트 스위트에서 두 번의 추가 시도를 할 수 있는 에이전트는 한 번의 시도만 하는 것과 비교하여 실질적으로 더 나아 보일 수 있습니다.

3단계: 검사기가 잘못된 비교를 거부하도록 만들기

이것이 전체 아티팩트입니다. 나머지 모든 것은 조연들입니다.

#!/usr/bin/env python3
""check_comparable.py — 다른 봉투를 가진 두 실행을 diff하는 것을 거부합니다."" 
import json, sys
...

종료 코드 3이 중요한 줄입니다. CI에서는 작업을 실패시킵니다. 검토에서는 "이 두 숫자는 서로 다른 실험이다"라고 말하는 주석이 됩니다.

마지막 행은 사람들이 과도하게 보정하는 부분입니다. 실행 A가 노트북을 사용했고 실행 B가 무료 서버를 사용했다는 기록은, 결론이 지연 시간이나 하드웨어에 의존하지 않는 한, 불이익이 아니라 유용한 맥락입니다.

4단계: 평균값뿐만 아니라 불일치 쌍(discordant pairs)을 보고하기

동일한 슬라이스에 대한 두 번의 실행은 쌍으로 된 결과를 산출합니다. 평균값은 그 구조를 버립니다.

#!/usr/bin/env python3
""paired.py — 시드된 부트스트랩 간격(seeded bootstrap interval)을 가진 태스크별 델타."" 
import json, random, sys
...

20개의 태스크와 +0.150 델타가 있다면, 95%CI=[-0.050,+0.350]과 약 2 / 5의 불일치 분할(discordant split)을 예상해야 합니다. 그 구간은 0을 가로지릅니다. 정직한 문장은 "방향성상 긍정적이지만, 확립된 것은 아니다"이며, 불일치 카운트는 어떤 태스크부터 읽어야 할지 알려줍니다.

위의 숫자는 스크립트의 예상 출력 형태일 뿐, 실제 실행 측정값은 아닙니다. 무언가를 인용하기 전에 스스로 결과를 돌려보세요.

5단계: 매니페스트를 숫자 옆에 게시하기

매니페스트가 없는 패스율은 퍼센트 기호가 붙은 소문과 같습니다. run.manifest.json, outcomes.json 그리고 정확한 명령줄을 게시해야 합니다. 검토자는 질문 없이 1분 이내에 비교 가능성을 확인할 수 있어야 합니다.

실용적인 지름길이 하나 있습니다. 에이전트가 러너(runner) 변경에도 살아남는지 테스트하기 위해 두 번째 환경이 필요합니다. 이는 무료 티어 설정으로 할 수 있는 저렴한 확인 절차입니다. 같은 슬라이스(slice)를 노트북과 임대 또는 무료 인프라에서 실행한 다음, 두 매니페스트 모두를 검사기에 입력하세요. MonkeyCode의 무료 모델 액세스와 무료 서버 옵션은 예산 논의 없이 두 번째 환경을 얻는 한 방법입니다. 운영 담당자가 말하길 무료 티어는 10M 토큰 할당량과 무료 서버로 설명되지만, 할당량은 변경될 수 있으므로 이를 기준으로 실행 규모를 잡기 전에 현재 가격 페이지에서 재확인해야 합니다.

공개 고지: 이 기사는 MonkeyCode의 제품 홍보 활동의 일환으로 작성되었습니다.

이것이 증명하지 않는 것들

일치하는 매니페스트는 비교 가능성을 증명할 뿐, 품질을 증명하지 않습니다. 당신의 20개 작업은 여전히 20개의 작업이며, 부트스트랩 간격(bootstrap interval)은 그 크기에서는 추론적이라기보다는 지표적입니다.

슬라이스 선택 편향(Slice selection bias)은 모든 해시에서 살아남습니다. 만약 당신이 에이전트가 잘하는 작업을 골랐다면, 매니페스트는 아첨하고 쓸모없는 숫자를 충실하게 기록할 것입니다. 부정 통제(Negative controls)와 사전 등록(pre-registration)이 이를 다루며, 매니페스트는 실수로 거짓말하는 것을 막아줄 뿐입니다.

무료 티어 및 호스팅 러너 또한 완전히 파악할 수 없는 변동성을 추가합니다: 할당량 제한(quota throttling), 공유 용량(shared capacity), 그리고 다른 날짜에 실행된 두 번의 실행 간 제공업체 측 버전 드리프트(provider-side version drift)가 있습니다. 타임스탬프를 기록하고 결합하기 전에 매니페스트 검사를 다시 실행하세요.

누가 건너뛰어야 하는지

만약 에이전트가 오후 시간을 투자할 가치가 있는지 결정하기 위한 일회성 스모크 테스트(smoke test)를 수행한다면 매니페스트를 생략하세요. 데모용이라면 생략하세요. 결론이

숫자가 터미널을 떠나는 순간 이를 채택하십시오. 누군가 계획 회의에서 귀하의 백분율을 인용할 때, 매니페스트는 측정치와 슬로건 사이의 차이입니다.