원문 정보

E. Kelly Buchanan, Crystal Zhou, Scott W. Linderman, Christopher Ré, "Benchmarks as Software: Terminal-Bench and the Case for Continuous Benchmarks", arXiv:2611.08417 [cs.AI], 2026-11-05 제출, CC BY 4.0. 소속: 스탠퍼드 대학교(공동저자 Crystal Zhou는 코넬 대학교 겸임 표기). 교신저자: E. Kelly Buchanan. 코드·과제 저장소: github.com/harbor-framework/terminal-bench-2-1.

동료심사를 거치지 않은 프리프린트입니다. 저자 전원이 스탠퍼드 대학교 소속이며, 평가 대상 모델을 만드는 어느 기업에도 속하지 않은 독립 연구팀이라는 점은 이 논문이 다루는 "벤치마크 신뢰도"라는 주제에서 가산 요인입니다. 다만 사사(acknowledgements)에는 Anthropic·Google DeepMind·Together AI 등 다수 기업이 스탠퍼드 DAWN·SEAMS 프로젝트의 일반 연구비 후원자로 나열돼 있습니다 — 이번 연구를 직접 후원한 것은 아니지만, 평가 대상 중 일부(Claude, Gemini 계열)의 제공사가 같은 연구실의 광범위한 후원자 명단에 포함돼 있다는 사실은 투명성 차원에서 밝혀 둡니다. 이번 실행에서는 세션 egress가 전면 차단돼(WebFetch가 arxiv.org·example.com 등 대상과 무관하게 전부 DNS 조회 실패) 원문 전문은 2026-11-06T22:09:29Z 기준 GitHub Actions 수집 스냅숏(HTML 전문 사본, 절단 없음)으로 대조했습니다.

연구 개요

연구 질문은 두 가지입니다. ① 출시 전 사람 검토와 LM 보조 레드티밍을 거친 "잘 관리된" 에이전트 벤치마크에도 과제 단위 결함이 얼마나 남아 있고, 이를 지속적으로 찾아 고치는 워크플로를 자동화할 수 있는가. ② 결함을 고친 뒤 정확도와 순위가 얼마나, 어떻게 바뀌는가 — 특히 모델·하네스 간 격차 중 '진짜 능력 차이'와 '자원 예산 차이'를 분리할 수 있는가.

저자들은 증거 수집 에이전트·감사(auditor) 에이전트·검증 에이전트 3단으로 이어지는 감사 워크플로를 설계했습니다. 감사자는 과제마다 '결함 없음', '지시-채점 불일치'(지시문과 채점 기준이 서로 다른 것을 요구), '작업 드리프트'(패키지 버전·외부 API·웹 콘텐츠 같은 외부 상태가 출시 후 바뀌어 과제가 틀어짐), '환경 문제'(CPU·메모리·시간 예산이 정답 코드조차 못 돌릴 만큼 빡빡함) 네 범주 중 하나(복수 가능)를 매긴 뒤 근거와 수정안을 제시하고, 검증 에이전트가 정답 코드를 다시 돌려 교차 확인합니다. 이 워크플로를 89개 과제로 구성된 Terminal-Bench 2.0(Merrill et al., 2026, ICLR)에 적용해 나온 결과물이 Terminal-Bench 2.1입니다. 이어서 19개 에이전트·모델 조합을 TB2.0과 TB2.1 양쪽 다 재평가하고, 시간 예산을 최대 32배까지 늘려 효율성 경계가 어떻게 바뀌는지, 별도 벤치마크 Harbor-Index v0.1에도 같은 워크플로가 통하는지를 검증했습니다.

핵심 결과

아래 수치는 모두 원문(HTML 전문, arxiv.org/html/2611.08417v1)의 표·본문에서 직접 대조한 값입니다. 감사는 89개 과제 중 28개(약 31%)에서 결함을 찾아냈습니다 — 기존 감사(Terminal-Bench Verified, 11개)와 공개 이슈·PR(5개)에서 이어받은 과제, 이번 감사가 새로 찾아낸 14개 과제를 합치고(2개는 두 출처에 겹쳐 중복 제외) 나온 숫자입니다.

결함 유형해당 과제 수(28개 중, 중복 허용)비중
지시-채점 불일치16개57%
작업 드리프트(외부 상태 변화)12개43%
환경 문제(자원 예산 부족)8개29%

한 과제가 여러 결함 유형에 동시에 해당할 수 있어 비중의 합은 100%를 넘습니다(원문 Fig. 3a, Table 2). 가장 흔한 유형인 지시-채점 불일치의 예로 query-optimize 과제는 지시문에 없는 "데이터베이스 파일 바이트 단위 보존"을 채점기가 몰래 요구하고 있었습니다.

결함을 고친 Terminal-Bench 2.1로 19개 에이전트를 재평가하자, 정확도는 평균 10%p 넘게 올랐고 리더보드 순위는 최대 3단계까지 바뀌었습니다. 전체 순위 상관(스피어만 ρ=0.958, 부트스트랩 95% 구간 [0.881, 0.979])은 높게 유지돼 큰 틀의 서열은 흔들리지 않았지만, 회귀선(TB2.1=2.1+1.04×TB2.0)에서 개별 에이전트가 벗어나는 정도는 상당했습니다 — Claude Code+Opus 4.6은 회귀선보다 7%p 넘게 위에서 3단계를 올랐고, TB2.0에서 40% 미만이던 가장 약한 두 에이전트는 회귀선 아래로 떨어지며 오히려 정확도가 낮아졌습니다(수정된 28개 과제 중 19개가 '어려움'으로 분류돼, 애초에 잘 못 푸는 에이전트에는 수정이 별 영향을 못 준다는 설명과 일치). 개선분의 출처도 집중돼 있습니다 — 지시-채점 불일치가 고쳐진 과제 5개가 통과율 15% 이하에서 50% 이상으로 뛰면서, 수정된 과제 전체의 절대 통과율 변화 중 약 62.7%를 이 5개가 차지했습니다.

두 번째 발견은 '하네스 격차'로 알려진 차이의 상당 부분이 속도 문제라는 것입니다. 실패한 시도의 50% 이상이 타임아웃으로 끝났고, 하네스별로는 gemini-cli의 18%부터 claude-code의 68%까지 벌어졌습니다. 시간 예산을 기본값의 최대 32배로 늘려 6개 에이전트·모델 조합을 재시험하자 결과가 달라졌습니다.

비교(Codex vs. Terminus-2 하네스)기본 시간 예산에서의 격차32배로 늘린 뒤
GPT 5.4약 20%p격차 대부분 해소
GPT 5.4 mini약 30%p약 5%p로 축소

같은 실험에서 GLM 5.1+Claude Code는 TB2.1에서 8개 과제를 더 풀어 GPT 5.4를 앞질렀는데, GPT 5.4 쪽 커버리지는 거의 변화가 없었습니다 — 효율성 순위 자체도 벤치마크 버전에 따라 달라질 수 있다는 뜻입니다(원문 Fig. 5·6).

세 번째로, 이 감사 워크플로가 Terminal-Bench만의 특수한 결과가 아님을 보이기 위해 별도 벤치마크 Harbor-Index v0.1(29개 원천 벤치마크에서 가져온 80개 과제 스냅숏 중 34개 무작위 표본)에 같은 방식을 적용했습니다. 워크플로가 14개 과제를 결함으로 표시했고, Harbor 팀이 34개 전체를 수동 검토한 결과 12개가 실제 결함으로 확인돼 정밀도 86%를 기록했습니다. 다만 워크플로가 놓친 결함도 있었습니다 — Lab-Bench의 오답 정답지 1건, QCircuitBench의 비결정적 채점, 정답이 두 개 이상 가능한 HLE 과제 1건, 그리고 GSO·GAIA2의 공용 채점 코드 버그 2건(13개 과제에 영향, 일부는 이미 다른 결함으로 표시된 과제와 겹침)입니다.

신뢰도 평가

믿을 근거는 네 가지입니다. ① 평가 대상 모델을 만드는 기업과 무관한 스탠퍼드 독립 연구팀입니다. ② 감사자 간 일치도를 직접 검증했습니다 — 관리형 코딩 어시스턴트(Claude Code+Opus 4.6, Codex+GPT-5.4)는 89개 과제 전체의 1차 결함 범주(결함 없음 포함)에서 코언의 카파 0.80으로 높게 일치했습니다. ③ 별도 벤치마크(Harbor-Index)에 적용한 외부 타당성 검증에서 정밀도 86%를 얻어, Terminal-Bench 특유의 우연이 아님을 보였습니다. ④ 독립된 선행 감사(Z.ai의 Terminal-Bench 2.0 Verified)와 결론이 수렴합니다 — Z.ai는 환경 수정만으로 Claude Opus 4.5의 점수를 52.4%에서 57.9%로 끌어올렸다고 보고했는데, 이는 이 논문의 '환경 문제가 점수를 흔든다'는 주장과 같은 방향입니다.

감안할 점도 뚜렷합니다. 동료심사 전 프리프린트입니다. 워크플로 자체의 정밀도 57.1%·재현율 71.4%는 최종 TB2.1 발표본과 비교한 수치인데, 그 발표본 자체가 이 워크플로의 결과물이라 순환적입니다(저자들도 "독립적 결함 발견이 아니라 발표본과의 사후 일치도를 측정한 것"이라고 명시). 저비용 API 감사자(gpt-4o-mini·gpt-4o·gemini-2.5-flash)의 범주별 일치도는 지시-채점 불일치(κ=0.60)·환경 문제(κ=0.59)는 중간 수준이지만 작업 드리프트는 κ=0.21~0.41로 낮아, 저자들도 LLM 판단보다 결정론적인 정답 코드 재실행에 드리프트 탐지를 맡겼습니다. 또한 Z.ai의 선행 감사와 이번 감사는 같은 방향의 결론에 도달했지만 수정 철학은 정반대입니다 — Z.ai는 지시문을 채점 기준에 맞춰 고쳐(정답의 일부를 노출하는 셈) 11개 중 4개를 TB2.1도 그대로 채택했지만, 나머지는 TB2.1이 "채점기를 고쳐 정답으로 인정되는 범위를 넓히는" 반대 방향으로 수정해, 과제의 원래 난이도를 지키려 했습니다. 사사에 다수 AI 기업이 연구실 일반 후원자로 등장한다는 점은 위 '원문 정보'에서 밝힌 대로입니다.

관련 연구

  • Zhu et al.(2025). Establishing Best Practices for Building Rigorous Agentic Benchmarks — 선행 연구(prior, 방법 확장). 에이전트 벤치마크 감사 체크리스트(ABC)를 제안해 CVE-Bench의 성능 과대추정을 33% 줄였고, 널리 쓰이는 벤치마크 10개에서 최대 100%(상대 기준)에 달하는 추정 오류를 찾아냈습니다. 이번 논문의 감사 루브릭은 ABC를 "유지보수" 상황에 맞게 변형한 것입니다.
  • Merrill et al.(2026, ICLR). Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces — 벤치마크 원전(benchmark-origin). 이번 논문이 감사한 Terminal-Bench 2.0의 원 논문으로, 출시 당시 최고 에이전트도 65% 미만의 성공률을 기록했다고 보고했습니다. 사람 검토와 LM 보조 레드티밍을 거쳤는데도 이번 감사가 89개 중 28개에서 결함을 찾아냈다는 사실이, "출시 전 검증"과 "지속적 유지보수"가 다른 일임을 보여줍니다.
  • OpenAI(2024). Introducing SWE-bench Verified — 같은 범주의 선행 사례(동시에 대비되는 접근). 개발자 93명이 SWE-bench 과제 1,699건을 검토해 결함 있는 과제를 걸러낸 500개짜리 '검증된' 부분집합을 냈습니다. 이번 논문은 이 방식을 "한 번 걸러내고 끝나는" 일회성 정제로 분류하고, 자신들의 접근을 "계속 찾아 고치는" 연속적 유지보수로 구분합니다 — 결함을 다루는 두 다른 철학(걸러내기 vs. 고치기)이 공존함을 보여줍니다.

세 선행 연구를 종합하면, 에이전트 벤치마크의 신뢰성 문제는 "체크리스트로 결함을 분류하는 법(ABC)" → "출시 전 검증을 아무리 해도 결함이 남는다(Terminal-Bench 원 논문 대비 이번 감사)" → "결함을 걸러낼지 고칠지(SWE-bench Verified vs. 이번 논문)"로 이어지는 흐름 위에 있습니다. 이번 논문은 이 흐름에 "고친 뒤 순위가 얼마나 흔들리는가"를 수치로 더했다는 점에서, 선행 연구들과 결론이 충돌하지 않고 오히려 그 빈틈을 채웁니다.

리뷰어 판단

첫째, '하네스 격차'를 곧바로 '모델 능력 격차'로 읽는 습관이 가장 위험하다고 판단합니다. GPT 5.4의 20%p 격차, GPT 5.4 mini의 30%p 격차가 시간 예산을 늘리자 대부분·대폭 줄었다는 결과는, 사내에서 하네스 A와 B를 "같은 타임아웃으로" 비교하는 흔한 관행이 실은 "같은 예산에서 누가 더 빠른가"만 재고 있을 가능성을 보여줍니다. 모델 교체나 하네스 채택을 결정할 때 예산을 고정한 1회 비교만 보면 잘못된 결론에 이르기 쉽습니다.

둘째, 워크플로 자체의 정밀도·재현율(57.1%/71.4%)보다 외부 검증(Harbor-Index 86%)이 훨씬 신뢰할 만한 신호라고 판단합니다. 전자는 워크플로가 만든 수정안과 그 결과물을 비교하는 순환 검증이고, 후자는 그 워크플로가 전혀 관여하지 않은 사람 검토와 대조한 것이기 때문입니다. 벤치마크 감사 도구의 성능을 인용할 때는 어떤 종류의 검증인지부터 구분해야 합니다.

셋째, 작업 드리프트 범주에서만 감사자 간 일치도가 유독 낮았다는 점(κ=0.21~0.41)은 설계 선택의 타당성을 보여주는 사례라고 판단합니다. 저자들이 이 범주를 LLM의 주관적 판단에 맡기지 않고 정답 코드를 다시 돌려보는 결정론적 체크로 대체한 것은, "판단이 필요한 범주"와 "기계적으로 확인 가능한 범주"를 구분해 파이프라인을 설계하는 일반적인 전략으로 읽을 수 있습니다.

실무 적용

  • 벤치마크 버전을 명시 — 모델 선택 근거로 벤치마크 점수를 인용할 때 TB2.0인지 TB2.1인지처럼 버전을 함께 적습니다. 같은 벤치마크라도 버전에 따라 순위가 최대 3단계 바뀔 수 있습니다.
  • 하네스 비교는 예산을 바꿔 재확인 — 두 하네스의 점수 차이가 크면, 시간 예산을 늘린 조건에서도 격차가 유지되는지 한 번 더 확인해 속도 차이와 능력 차이를 분리합니다.
  • 타임아웃 비중을 별도로 기록 — 실패 원인 중 타임아웃 비율(이번 논문은 하네스별 18~68%)을 따로 집계해, 능력 부족과 자원 부족을 구분합니다.
  • 정답 재실행으로 드리프트 자동 탐지 — 외부 API·패키지에 의존하는 내부 평가 과제는 정답 코드를 주기적으로 재실행해, 외부 상태 변화로 인한 거짓 실패를 걸러냅니다.
  • 근접 순위는 과신하지 않기 — 전체 순위 상관이 높아도(ρ=0.958) 개별 점수는 최대 12%p까지 흔들릴 수 있으므로, 순위가 1~2단계 차이인 모델 간 선택은 벤치마크 점수만으로 확정하지 않습니다.

결론

이 논문의 기여는 새 벤치마크가 아니라 "벤치마크도 소프트웨어처럼 유지보수가 필요하다"는 관점과 그 비용을 수치로 보인 것입니다. 사람 검토와 레드티밍을 거친 Terminal-Bench 2.0에도 89개 과제 중 28개(약 31%)에서 결함이 남아 있었고, 고친 뒤 정확도는 10%p 넘게 올랐으며 순위는 최대 3단계 바뀌었습니다. '하네스 격차'로 보였던 차이의 상당 부분이 실은 시간 예산 차이였다는 결과는, 벤치마크 점수를 비교할 때 과제 내용뿐 아니라 자원 설정도 측정 사양의 일부로 다뤄야 한다는 뜻입니다.

다만 워크플로 자신의 정밀도·재현율은 순환 검증이라는 한계가 있고, 작업 드리프트 탐지는 LLM 판단보다 결정론적 재실행에 의존한다는 점은 '완전 자동화된 감사'를 기대하면 안 된다는 신호이기도 합니다. 긴 호라이즌 작업에서 중간 체크포인트와 조기 중단을 다룬 장기 호라이즌 코딩 에이전트의 체크포인트·조기중단 설계와 같은 축으로 읽을 수 있습니다 — 그 글은 평가 대상인 에이전트의 중간 궤적을 다루고, 이 리뷰는 그 에이전트를 평가하는 잣대 자신의 결함을 다룹니다.

참고 링크

이 리뷰에 대해 AI와 대화하기

AI가 이 리뷰와 검증된 수치를 읽은 상태로 답합니다. 무엇이든 물어보세요 — 글에 없는 내용이면 없다고 먼저 알려줍니다.

대화창을 불러오는 중…