Terminal-Bench 진화사 - 에이전트 벤치마크는 어떻게 소프트웨어가 되었나 (1.0 → 4.1)

이 글은 tbench.ai 공식 블로그 전문과 GitHub harbor-framework/terminal-bench 릴리스 노트를 실접속해 수치를 추출·교차 검증한 뒤 운영자가 검수했어요. 리더보드 수치는 각 공지 시점 기준입니다.

에이전트 벤치마크 중에 지금 가장 많이 인용되는 이름이 하나 있어요. 모델과 에이전트에게 Linux 터미널을 주고 진짜 작업을 시켜보는 Terminal-Bench예요. 2025년 5월 Laude Institute와 Stanford 팀이 80개 태스크로 출발했고, 18개월 동안 1.0 → 2.0 → 2.1 → 3.0 → 4.0 → 4.1로 이어지는 대개편을 거쳤어요. 단순히 '문제셋을 갈아엎은' 역사가 아니라, 벤치마크를 만들고 방치하는 대신 소프트웨어처럼 지속 유지보수하는 방법을 처음으로 실증한 역사이기도 해요.

이 글은 tbench.ai 공식 블로그 전체 글과 GitHub 릴리스 노트를 직접 읽고 버전별 변경점을 시계열로 정리한 기록이에요. 차트의 수치는 전부 공식 공지에 실린 값입니다.

버전 한눈에 보기

아래 탐색기에서 버전을 클릭하면 그 버전이 무엇을 바꿨는지 한 화면에 정리돼 있어요.

타임라인: 2025-05 → 2026-11

1.0 (2025-05): '터미널'이라는 축의 발견

출발점의 관찰은 단순했어요. Cursor, Manus, Devin, Goose, OpenHands, Codex 같은 에이전트들이 전부 터미널로 행동을 실행한다는 것. 터미널은 언어 모델의 학습 도메인과 맞닿은 텍스트 인터페이스면서, 세밀한 제어가 가능하고, 컨테이너로 샌드박싱하기 쉽고, 실제 소프트웨어 엔지니어링에서도 여전히 표준 도구죠. 문제는 당시 에이전트들이 여러 동작을 연쇄하거나 긴 컨텍스트를 다루는 데 자주 무너진다는 것이었고요.

태스크 구조는 이때 정해진 것이 지금까지 그대로 이어져요:

tasks/<task-id>/
  Dockerfile (or docker-compose.yaml)
  task.yaml
  solution.sh        # 인간 검증 정답 솔루션
  run-tests.sh
  tests/test_outputs.py

• 태스크 커버리지는 과학 워크플로우, 네트워크 설정, 게임, 데이터 분석, 보안 취약점까지였어요.
• 특정 벤더 에이전트(Claude Code 등)는 임의 모델 교체가 안 되니, 팀이 직접 Terminus라는 중립 레퍼런스 에이전트를 만들었어요. 도구는 tmux 패널 하나뿐 - 모델의 순수 실력을 재는 '자(尺)' 역할이죠.
• 에이전트 통합은 컨테이너 설치 / Python 직접 통합 / MCP 서버 세 가지를 지원했고, AppWorld 포팅을 시작으로 다른 벤치마크 어댑터 로드맵도 이때 공개됐어요.

성장 속도도 빨랐어요. 5월엔 Anthropic이 Claude 4 모델 카드에 싣으며 신기록을 세웠고, 6월엔 터미널 네이티브 제품 Warp가 52%로 첫 제품 에이전트 SOTA를 기록했으며, 7월엔 벤치마크 레지스트리가 공개됐어요.

무결성 소동: 오픈 리더보드의 대가 (2025-09 → 2026-04)

벤치마크가 표준이 되자 진입 유인도 커졌어요. 2025년 9월에 타임아웃 규정이 먼저 명문화됐고, 2026년 4월엔 커뮤니티가 적발한 사례들과 함께 정책이 대폭 강화됐어요. 공지에 실린 사건은 다음 세 가지입니다:

강화된 정책은 세 줄로 요약돼요: 통과 트라이얼 전수에 에이전트 저지를 돌린다, 리워드 해킹은 그 트라이얼을 0점 처리한다, cheating은 즉시 퇴출한다. 여기에 모든 통과 트라이얼에 ATIF 트라젝토리 제출이 필수가 됐고, 저지 판별기를 오픈소스로 공개해 제출자가 미리 자가 검증할 수 있게 했어요.

재미있는 건 적발의 상당 부분이 커뮤니티 몫이었다는 점이에요. Adam Stein·Davis Brown의 DebugML 분석이 Pilot과 ForgeCode를, Ante 팀이 OpenBlock을 잡아냈어요. 벤치마크의 방어력도 크라우드소싱되는 시대라는 뜻이죠.

2.0 + Harbor (2025-11): 하드 리셋

1.0은 출범 몇 달 만에 사실상 모든 프론티어 랩이 쓰는 표준이 됐어요(디스코드 멤버 1천 명, GitHub 기여자 100명). 그런데 팀 스스로 데이터셋 검증 수준에 만족하지 못했어요. 대표 사례가 download-youtube - YouTube 안티봇 정책이 바뀌면 어제까지 통과하던 solution이 오늘 실패하는 태스크였죠.

2025년 11월 7일 팀은 두 가지를 동시에 내놓아요. 첫째는 89개 태스크로 재구성하고 수작업 + LM 보조 대규모 검증을 거친 Terminal-Bench 2.0. 둘째는 그간 쌓인 불만 - 컨테이너 평가가 느리다, SFT/RL도 돌리고 싶다, 프레임워크가 제각각이다 - 를 풀어준 평가·최적화 패키지 Harbor예요. 클라우드에서 수천 개 컨테이너를 병렬로 돌리고, 롤아웃 인터페이스로 RL/SFT 학습 데이터까지 뽑아주는 구조였어요. 저장소가 harbor-framework 조직으로 옮겨가고 버전별로 저장소가 갈라지는, 지금의 운영 체제도 이때 확립됐어요.

2.1 (2026-05): 89개 중 28개를 고치다

좋은 데이터셋도 살아있는 시스템이라 시간이 지나면 상처가 난다 - 2.1이 그걸 증명한 릴리스예요. 커뮤니티 리포트와 리더보드 트라젝토리를 근거로 89개 중 28개 태스크를 수리했는데, 문제를 세 부류로 분류한 방식이 인상적이에요.

명세 불일치의 예가 재밌어요. query-optimize는 지시문은 PostgreSQL을 요구하는데 테스트는 Spark SQL을 기대하고 있었죠. 태스크를 PostgreSQL 기준으로 재작성해서 정합을 맞췄어요.

수리 효과는 컸어요. 대부분의 에이전트-모델 조합이 상승했고 가장 큰 폭은 Opus 4.6 + Claude Code의 +12.1%p였어요. 태스크별로는 폴리글랏 빌드 태스크 polyglot-c-py가 무려 +84.3%p, 수리 후에는 미해결 태스크가 0개가 됐어요. 이번 수정 28건 중 11건은 Z.AI가 진행한 'TB 2.0 Verified' 검증 작업에서 나왔다는 점도 기록할 만해요 - 랩이 벤치마크 품질에 직접 기여한 초기 사례죠.

아래 차트 임베드의 '2.1 수리효과' 탭에서 에이전트-모델 14개 조합 전체의 변화를 확인할 수 있어요. 이 글의 나머지 차트(세대별 SOTA, 3.0 패스율, 난이도 리셋)도 전부 여기에 탭으로 들어 있어요.

Challenges (2026-06): 벤치마크의 세 번째 축

에이전트가 이제 수 시간씩 자율로 굴러갈 수 있게 되자 '태스크 한 개 = 프로젝트 한 개'인 포맷이 필요해졌어요. Terminal-Bench Challenges는 장기·토큰 집약형 단일 태스크 벤치마크로, 기존 축들과 이렇게 나뉘어요:

첫 삼종 세트는 이렇습니다. Rust 컴파일러 가속(공식 rustc-perf에서 쓰는 52개 크레이트를 잘라낸 미니 테스트베드에서 명령어 수로 컴파일 시간 채점), 25KB 이하 C/CUDA 한 파일로 Kimi 2.5를 서빙하는 추론 엔진(TTFT·tokens/s·TPOT 파레토 프런트 측정), 브라우저·GPU 없이 WebGL을 돌리는 WASM 소프트웨어 렌더러(headless-gl 드롭인 대체제)예요.

초기 실험 결과는 냉정했어요. Opus 4.8을 12시간 굴린 Rust 가속은 최적화 시도가 회귀만 만들며 유의미한 진전이 없었고, WebGL은 Devin + Fable 5가 WebGL 1.0 커버리지 96.4%까지 가고도 WebGL 2.0 컨펌런스에서 20.5%로 멈췄어요.

여기서 보고된 두 실패 모드가, 개인적으로는 이 글에서 가장 값진 관찰이에요:

1. 해결공간 탐색 부족 - 시간이 지나도 코드 뭉치를 통째로 지우고 크게 다시 짜는 대규모 리라이트를 못 참고 국소 최적점에 갇혀요.
2. 테스트 스위트 남발 - 20분 넘는 풀 스위트를 돌리는 대신, 지금 바꾼 부분만 재는 자작 타깃 테스트를 스스로 만들어야 하는데 그러지 않아요.

장기 자율 작업의 병목이 '지능'이 아니라 '작업 관리'라는 신호로 읽히는 부분이에요.

3.0 (2026-07): 프론티어 재측정 + '벤치마크는 소프트웨어다'

2.1 시점엔 프론티어가 80%대까지 올라와 리더보드가 좁은 띠로 뭉쳤어요. Fable 5와 Opus 4.8의 격차가 불과 4.9%p - 모델 간 차이를 구분하지 못하는 벤치마크는 신호를 잃은 거죠. 2026년 7월 30일, 팀은 7개 도메인 74개 태스크의 Terminal-Bench 3.0과 함께 선언문을 냈어요. Continuous Benchmarks - 벤치마크는 소프트웨어이고, 소프트웨어처럼 유지보수되어야 한다.

구조적 변화는 세 가지가 핵심이에요.

1. 에이전트 컨테이너와 검증기 컨테이너의 분리 - 에이전트 산출물을 트라이얼 끝에 수집·로그로 남기고 검증 컨테이너에서 채점해요. 리워드 해킹 벡터를 크게 줄이고, 검증기를 고쳤을 때 토큰을 다시 안 태우고 재채점(regrade)할 수 있게 해줘요.
2. 시맨틱 버저닝 + 리더보드 마이그레이션 - 무엇을 바꿨는지에 따라 기존 트라이얼을 재사용/재채점/재실행으로 최소 비용으로 이관해요.
3. 품질 CI 게이트 - 새 태스크는 oracle 에이전트 만점, no-op 에이전트 0점, cheating 에이전트 실패 같은 통합 테스트를 통과해야 병합돼요.

오픈 인터넷 벤치마크라 웹 검색도 허용되는데, '태스크 전용 풀이나 힌트를 온라인에서 찾지 말라'는 지시 한 줄이 의외로 효과적이라고 해요. 채점 대상 artifact의 스펙트럼도 넓어졌어요:

태스크 하나가 평균 20개 파일, 4천 줄 규모의 시뮬레이션이 된 시대라, 검증 신뢰성을 위한 리뷰 파이프라인도 공개됐어요:

결과부터 말하면 최고 기록은 34.4% - 난이도 리셋이 성공했고 판별력도 돌아왔어요. Fable 5 vs Opus 4.8 격차가 4.9%p에서 12.7%p로 벌어졌죠. 비용 편차도 커졌어요. GPT-5.6 Sol은 Fable 5와 비슷한 패스율(34.4% vs 33.8%)을 내면서 비용은 ~40% 저렴, 토큰은 ~50% 절감했고, GPT-5.6 라인업 세 모델이 모두 비용-패스율 파레토 프런트에 올랐어요. 같은 점수라도 토큰 적게 쓰고 행동 많이 하는 쪽(Codex 계열)과 토큰 많이 쓰고 행동 적은 쪽(Claude 계열)의 문제 풀이 스타일 차이도 트라젝토리 통계로 드러났어요.

참고로 이 시기 저장소에는 'Frontier-Bench'라는 이름의 흔적이 남아 있어요. Continuous Benchmarks 글은 그 기능들을 'Frontier-Bench, the successor to Terminal-Bench를 만들면서 개발했다'고 썼고, GitHub PR 링크들도 frontier-bench → terminal-bench 리다이렉트를 보여줘요. 개명했다가 다시 돌아온 듯한 자취인데, 결과적으로 Continuous 선언은 Terminal-Bench라는 브랜드를 유지한 채 흡수된 걸로 보여요.

4.0 (2026-08): 유지보수의 실증

3.0의 선언이 실제로 작동하는 모습이 4.0이에요. 이번엔 새 태스크 경연이 아니라 측정기 자체의 정밀도가 주제였어요.

Gian Segato가 설계한 캘리브레이션 실험(Anthropic 엔지니어링 글 'Quantifying infrastructure noise in agentic coding evals'의 방법론)으로 각 태스크에 큰 리소스 여유를 주고 돌려본 뒤, 지표에 영향이 없는 선에서 시간/CPU/메모리를 재조정했어요. 에이전트 타임아웃은 8시간 플랫으로 통일됐고 프론티어 모델은 이제 타임아웃을 거의 겪지 않아요. 남는 오류는 대부분 모델 거절과 출력 토큰 초과 - 하네스 노이즈가 아니라 모델 특성이 되었죠. 재미있는 디테일: Sonnet 5는 리더보드 런에서 21.6B 토큰을 쓰며(경쟁 모델 Opus 5는 6.5B) 출력 한도를 자주 넘었다고 해요.

태스크 셋 정리는 이렇습니다:

포화의 정의가 깔끔해요: 최신 세대 모델의 모든 클래스·패밀리가 5회 시도 전부 해결하면 더 이상 모델을 구분하지 못하는 태스크라 치고 내보낸다. 그리고 4.0부터 버전 번호가 시맨틱 규약을 따르기 때문에, 에이전트 환경 변경(재실행 필요 = breaking)이 포함된 이번 릴리스가 3.1이 아니라 4.0이 되었어요. 팀은 '곧 커뮤니티가 헷갈리겠지만, 벤치마크를 새로 짜는 것보다 계속 손보는 게 낫다'고 솔직하게 인정했어요.

4.1 (2026-11): 조용한 패치의 힘

11월 4일에 나온 v4.1.0은 Continuous 벤치마크의 장점을 그대로 보여주는 릴리스예요. 태스크 추가·제거는 0, 수정은 66개 전부 minor/patch - 그래서 기존 트라이얼을 재활용·재채점해서 리더보드를 새 버전으로 이관할 수 있었어요. 바뀐 것은 세 가지예요.

• 검증기 격리: RewardKit Workers로 검증기를 에이전트 환경에서 분리해 리워드 해킹 표면을 축소
• 재현성: 컨테이너 이미지 고정 + lockfile로 재현 가능한 빌드
• 접근성: GPU 없이 돌리는 terminal-bench-cpu 63개 태스크 서브셋 신설

harbor run -d terminal-bench/[email protected]        # 풀 데이터셋
harbor run -d terminal-bench/[email protected]    # CPU-only 63개

다음 마일스톤은 이미 열려 있어요. Terminal-Bench 5.0은 신규 태스크를, 그 사이 패치들은 검증기 개선(탬퍼링 방지 등)을 담당합니다. 벤치마크에 '출시'가 아니라 '릴리즈 트레인'이 생긴 거예요.

이 18개월이 말해주는 것

• 하네스가 제품이 됐다: 자체 Python 하네스 → Harbor 프레임워크 + 데이터셋·리더보드를 패키지처럼 버전 관리하는 Harbor Hub
• 운영 패러다임이 바뀌었다: '만들고 방치'가 아니라 리포트 → 수정 → 재채점/재실행 사이클. 공식 블로그 표현을 빌리면 벤치마크가 '감가상각 자산'이 아니라 '가치가 올라가는 자산'이 된 거예요
• 난이도는 주기적으로 리셋된다: 52%(2025) → 80%대(2.1) → 34%(3.0). 포화는 죽음이 아니라 버전 업의 트리거
• 무결성이 시스템이 됐다: 저지 + 트라젝토리 의무화 + 공개 처분. 오픈 인터넷 벤치마크의 숙제에 대한 실무적 답
• 패밀리가 갈라진다: 과학 워크플로우의 Terminal-Bench-Science(2026-08), 장기 과제의 Challenges(2026-06), 경량 다면평가 Harbor-Index(2026-06)
• 태스크의 정의가 넓어진다: CLI 한 줄짜리에서 DB 스냅샷, ML 체크포인트, RTL, Lean 증명, VM 이미지, CAD, 악보까지
• 에이전트 생태는 두 갈래: 중립 자 측정기 Terminus(2)와 실제 제품 에이전트(Claude Code, Codex CLI, Gemini CLI, Cursor)가 같은 리더보드를 공유

벤치마크가 모델 발표에 첨부되는 숫자에서 '지속 배포되는 소프트웨어'로 변신하는 과정을 실시간으로 본 18개월이었어요. 다음은 5.0. 그때쯤이면 프론티어가 또 몇 퍼센트일지, 그리고 그 기록을 다시 리셋할 새 태스크들이 어떤 모습일지 궁금해지네요.