Terminal-Bench: 명령줄 인터페이스의 어렵고 현실적인 과제에서 에이전트 벤치마킹
Digest:
AI 에이전트(목표만 주면 스스로 여러 명령을 이어 실행하는 프로그램)가 소프트웨어 개발·사이버보안·과학 계산 같은 고가치 영역에서 자율적으로 일하기 시작했고—Anthropic은 Claude Code만으로 연 $1B run-rate 매출을 주장한다—이들에게 실무를 맡겨도 되는지 판단하려면 실제 난이도를 재는 잣대가 필요하다(Context).그러나 기존 벤치마크는 SWE-Bench·WebArena처럼 합성 환경이라 현실적이지 않거나, 최전선 모델(frontier model, 그 시점 최고 성능의 상용/공개 LLM)에게 너무 쉬워 포화된다. 저자들의 통찰은 터미널 셸(명령줄로 컴퓨터를 조작하는 인터페이스)이 바로 그 전문가들이 공통으로 쓰는 범용·강력 도구라는 점이다—장난감 문제 대신 전문가가 돈 받고 하는 진짜 명령줄 작업(예: COBOL→Python 재작성, OCaml 가비지 컬렉터 수정—전문가 24h·주니어 240h)으로 재면 포화 없이 모델 간 차이가 드러난다(Insight).
이에 따라 93명이 크라우드소싱한 229개 후보에서 89개를 골라 각 과제에 격리된 Docker 이미지, 사람이 쓴 오라클 솔루션(정답 참조 스크립트), 그리고 명령 순서가 아니라 컨테이너 최종 상태의 속성을 검사하는 결과지향 테스트를 붙이고, Harbor 하네스와 Terminus 2 중립 스캐폴드로 표준 실행한 뒤 과제당 ~3 리뷰어-시간의 7단계 검증(Specificity·Solvability·Integrity)을 거쳤다(Solution).
16개 모델×6개 에이전트를 32,155회 시행한 결과 최고 조합 Codex CLI + GPT-5.2조차 62.9%±3.0%(§Results)에 그쳤고, 최전선 전체가 65% 미만, 소형 모델은 평균
15%(GPT-OSS-20B 3.13.4%)였으며, 실패의 24.1%가 “PATH에 없거나 미설치된 실행파일 호출”이었다(Evidence).다만 오라클 솔루션 열람으로 컨닝이 가능하고(수만 궤적서 미관측), 개발사가 벤치마크로 학습하는 오염 위험이 있어 Big-Bench canary string으로 사후 탐지하되 의도적 오염 차단은 제한적이며, 인터넷 접속에 따른 외부 의존성으로 환경이 변하고 대규모 검토에도 일부 과제 품질은 미달일 수 있다(Limitations).
남는 질문은, 63% 미만 해결이 자율 배포 안전 임계로 충분한가, 8개월 만에 최고 성능이 거의 배증한 이 분야에서 과제셋 갱신이 모델 발전 속도(1년 내 포화 예상)를 따라갈 수 있는가, 결과지향 테스트가 실무 성공의 완전한 대리지표인가이다(Open Questions). 📎 https://arxiv.org/abs/2601.11868
먼저 이해하기
쉬운 설명
Terminal-Bench는 AI 에이전트(목표만 받고 스스로 여러 명령을 이어 실행하는 프로그램)가 진짜 어려운 명령줄 작업을 얼마나 해내는지 재는 벤치마크다. 전문가가 실제로 돈 받고 하는 89개 과제(COBOL→Python 재작성, OCaml 가비지 컬렉터 수정처럼 전문가 24시간·주니어 240시간이 걸리는 것)를 모아, 각 과제를 격리된 Docker 컨테이너(과제마다 따로 준비된 실행 환경)에 담았다. 채점은 에이전트가 친 명령이나 화면 출력을 보는 게 아니라 컨테이너의 최종 상태가 지시대로인지를 검사하는 결과지향 테스트(outcome-driven test)로 하고, 사람이 쓴 오라클 솔루션(정답 참조 스크립트)으로 애초에 풀 수 있는 과제임을 미리 확인한다. 16개 모델과 6개 에이전트를 32,155회 돌린 결과, 가장 잘한 Codex CLI + GPT-5.2도 62.9%±3.0%밖에 못 풀었고 최전선 모델을 다 합쳐도 65% 미만, 소형 모델은 평균 ~15%였다. 실패를 뜯어보니 가장 흔한 유형은 “설치가 안 됐거나 PATH에 없는 실행파일을 부르는 것”으로 전체 오류의 24.1%였다. 다만 이 숫자들은 Terminus 2 중립 스캐폴드와 이 89개 과제라는 특정 설정에서 나온 값이고, 저자들 스스로 이 벤치마크가 1년 내 포화될 수 있다고 본다.
왜 중요한가
이 결과는 “에이전트가 이미 실무를 대체한다”는 인상과 실제 역량 사이의 격차를 숫자로 못 박는다: Claude Code가 연 $1B 매출을 낸다는 시대에도 전문가급 터미널 과제의 최전선 해결률은 62.9%±3.0%에 머문다. 채점을 명령 순서가 아니라 컨테이너 최종 상태의 속성으로 하는 결과지향 방식은 “정답 경로를 외운” 에이전트와 “실제로 결과를 만든” 에이전트를 분리해 평가의 타당성을 높인다. 8개월 만에 최고 성능이 거의 배증했고 1년 내 포화가 예상되므로, 저자들은 과제셋을 계속 갱신하고 canary string으로 오염을 추적하겠다고 밝혀 정적 점수 대신 갱신되는 평가 방식을 제시한다. 또한 실패 유형 분류(taxonomy)는 어디를 고쳐야 하는지—예컨대 오류의 24.1%를 차지한 “PATH/미설치 실행파일 호출”—를 개발자에게 구체적으로 알려준다.
먼저 알아둘 말
| 용어 | 쉬운 설명 | 정확성 메모 |
|---|---|---|
| 에이전트(agent) / 에이전틱 | 목표만 주면 스스로 여러 단계 명령을 이어 실행하는 프로그램 | 이 논문에선 스캐폴드(Claude Code·Codex CLI 등)+모델 조합으로 구현; “trial(시행)“은 한 에이전트가 한 과제를 1회 시도한 것 |
| 최전선 모델(frontier model) | 그 시점 가장 성능 좋은 상용/공개 LLM | 평가 대상은 GPT-5.2·Claude Opus 4.5·Gemini 3 Pro 등 16개 모델; “최전선 <65%“는 이 집합 기준 |
| 스캐폴드(scaffold) / Terminus 2 | 모델을 감싸 터미널과 주고받게 해주는 실행 껍데기; Terminus 2는 Bash 명령만 쓰는 단일 도구 중립 기준선 | 해결률은 (모델×스캐폴드) 조합마다 다름; Terminus 2 평균 해결률이 난이도 라벨의 기준값 |
| 결과지향(속성 기반) 테스트 | 에이전트가 친 명령이 아니라 컨테이너 최종 상태의 속성을 검사해 성공을 판정 | 명령/콘솔 출력은 채점하지 않음; 정답 경로 암기와 실제 결과를 분리하는 핵심 설계(§Methods) |
| 오라클(레퍼런스) 솔루션 | 사람이 직접 작성한 정답 스크립트 | Solvability 검증(오라클 실행으로 통과 가능 확인)에 사용; 열람 시 컨닝 위험이 있어 한계로 명시 |
| 해결률(resolution rate) | 전체 과제 중 테스트를 통과한 비율 | ±값은 최소 5회 반복 시행의 편차; 최고 62.9%±3.0% |
| 컨테이너 / Docker 이미지 | 과제마다 독립된, 패키지 버전이 고정된 실행 환경 | 인터넷 접속 허용→외부 의존성으로 시간이 지나며 변할 수 있음(한계); 실험은 Daytona로 32~100개 병렬 |
| Harbor | 여러 에이전트·모델을 표준 방식으로 실행하는 평가 하네스 | Claude Code·Codex CLI·OpenHands·Mini-SWE-Agent 지원; Appendix D에서 26개 기존 벤치마크를 이 포맷으로 변환 |
| canary string | 데이터셋에 심어 두는 고유 표식 문자열 | 학습 데이터 오염을 사후 탐지하기 위한 것; Big-Bench 방식 차용, 의도적 오염 차단엔 제한적(한계) |
섹션별 요약
Abstract
AI 에이전트가 소프트웨어 엔지니어링·사이버보안·과학 계산 등 고가치 영역에서 본격 활용되기 시작하면서 실제 워크플로 수준의 난이도를 측정하는 평가 기준이 필요해졌으나, 기존 벤치마크는 현실적이지 않거나 최전선 모델에게 충분히 어렵지 않다는 한계가 있다. 본 논문은 어렵고 현실적인 터미널 환경 과제로 에이전트를 평가하는 Terminal-Bench를 제안한다. Terminal-Bench 2.0은 93명 기여자가 크라우드소싱한 229개 후보에서 다단계 검증으로 선별한 89개 과제로 구성되며, 각 과제는 컨테이너화된 고유 환경·인간 작성 참조 솔루션·결과 지향 검증 테스트를 포함한다. 16개 최전선 모델과 6개 에이전트를 대상으로 총 32,155회 시행한 결과, 최고 조합 Codex CLI + GPT-5.2조차 62.9%에 그쳐 최전선 전체가 65% 미만만 해결, 소형 모델은 평균 약 15%였다. 데이터셋·평가 하네스는 tbench.ai에 공개되며 8개 하위 범주 실패 유형 분류체계를 함께 제시한다.
저자 contribution
- Terminal-Bench Framework 제안 — Harbor 컨테이너 샌드박스와 통합해 다양한 에이전트·모델을 표준화 실행하는 평가 프레임워크.
- Terminal-Bench 2.0 데이터셋 구축 — 컨테이너 환경·지시·테스트 스위트·오라클 솔루션을 갖춘 89개 수동 검증 과제.
- 최전선 모델·에이전트 평가 + 실패 유형 분류체계 제공 — 16×6 조합 32,155회 시행에서 최전선 65% 미만 해결 확인, 8개 하위 실패 유형 도출.
왜 이 연구를 하는가?
핵심 질문: AI 에이전트가 실제 전문가의 터미널 작업을 자율 해결할 수 있는가, 그리고 기존 벤치마크는 이를 공정히 측정하는가?
| 한계 | 설명 |
|---|---|
| 현실적 작업 부재 | SWE-Bench(GitHub 이슈)·WebArena·OS World(시각적 웹·OS 조작)·τ-Bench(도구-에이전트-사용자) 등이 전문가 실무를 포착 못 하고 다수가 합성 환경에서 실행된다. |
| 최전선 모델에 충분히 어렵지 않음 | 최전선 모델이 기존 벤치마크 대부분을 높은 정확도로 풀어 실질적 역량 차이를 구분하기 어렵고, 실제 배치 가능성 신호로서 신뢰성을 잃었다. |
| 좁은 CLI 단면만 측정 | KOALA(셸 스크립트 최적화)·EnvBench(환경 설정)·NL-to-Bash 번역 등은 터미널의 극히 일부만 다뤄 범용 터미널 조작 역량을 평가하지 못한다. |
핵심 통찰: 터미널(CLI)은 SE·과학계산·보안·ML 전반에서 전문가들이 공통으로 쓰는 범용·강력 인터페이스다. Claude Code가 연 $1B 매출을 낸 현 시점에서, 합성 환경이 아닌 실제 터미널 셸의 다양하고 장기지평(long-horizon)인 전문가 과제로 측정해야 포화 없이 최전선 모델 간 의미 있는 성능 차이를 드러낼 수 있다.
Introduction
AI 에이전트가 고가치·고위험 영역에서 장기 자율 작동 능력을 빠르게 갖추는 중이며, Anthropic은 Claude Code만으로 연 $1B run-rate 매출을 발표했다. 그러나 기존 벤치마크는 현실적 작업을 측정하지 못하거나 최전선 모델에게 충분히 어렵지 않다는 공백이 있다. 관련 연구로 SE 계열(SWE-Bench·SWE-Lancer·HumanEval), 도구 사용(τ-Bench·Berkeley Function Calling Leaderboard), 시각 컴퓨터 조작(WebArena·OS World·AppWorld), 과학 발견(ReplicationBench·MLGym-Bench), CLI 특화(KOALA·EnvBench·NL-to-Bash)가 있으나 이들은 터미널의 협소한 단면만 다루거나 합성 환경을 쓴다.
이 공백을 채우기 위해 저자들은 실제 터미널 셸에서 전문가 과제를 측정하는 Terminal-Bench를 제안한다. Terminal-Bench 2.0은 93명 기여자가 제출한 229개 중 다단계 검증으로 89개를 선별하며, 각 과제는 고유 Docker 컨테이너 환경·지시문·결과지향 테스트·전문가 작성 오라클 솔루션을 포함한다. 예시: 비동기 작업 병렬화 함수 작성, COBOL→Python 재작성, OCaml 가비지 컬렉터 수정(전문가 ~24h, 주니어 ~240h). 16개 모델×6개 에이전트 스캐폴드로 총 32,155회 시행한 결과 최고 Codex CLI + GPT-5.2가 62.9%, 최전선 전체 65% 미만, 소형 모델 평균 ~15%로, 자율 에이전트와 실제 전문가 작업 사이의 역량 격차를 정량화했다.
저자가 명시한 기여: (1) Terminal-Bench Framework, (2) Terminal-Bench 2.0 Dataset(tbench.ai 공개), (3) 최전선 65% 미만 실증 Benchmark Evaluation, (4) 실패 유형 분류체계(Error Analysis).
Methods
개요: 229개→89개 정제, Docker 컨테이너·결과지향 테스트·오라클 솔루션 패키징, Harbor 하네스+Terminus 2 중립 스캐폴드 실행, 과제당 ~3 리뷰어-시간 7단계 검증으로 구성된 엔드-투-엔드 벤치마크 체계.
5대 과제 구성요소
- Instruction(지시문): 시간 제한 내 달성할 목표를 서술하는 텍스트. 에이전트가 받는 유일한 명세.
- Docker image(컨테이너 환경): 패키지·파일이 사전 설치된 이미지. 버전 고정, 의존성을 Docker context에 포함. 인터넷 접속 허용(외부 의존성 변동 위험).
- Tests(결과지향·속성 기반): 명령 시퀀스·콘솔 출력이 아닌 컨테이너 최종 상태의 속성만 검사. 다양한 풀이 경로를 공평 수용.
- Reference solution(오라클): 저자 수작업 정답 스크립트. Solvability 검증·실패 원인 분류의 기준선.
- Time limit: 최대 실행 시간(대부분 <20분, 극단 ~2h).
Harbor 하네스: Claude Code·Codex CLI·OpenHands·Mini-SWE-Agent 지원, 과제 명세 표준화·다중 샌드박스 연동. 실험은 Daytona로 32~100개 컨테이너 병렬. Appendix D에 26개 기존 벤치마크를 Harbor 포맷으로 변환 통합.
Terminus 2 중립 스캐폴드: 단일 도구(헤드리스 터미널)만 갖추고 Bash 명령만으로 수행. 스캐폴드 오버헤드를 배제해 모델 자체 역량만 측정하는 중립 기준점.
3기준 검증: Specificity(허용 상태에서만 테스트 통과) / Solvability(오라클 실행으로 풀이 가능성 확인) / Integrity(미래 git 이력 열람 등 치팅 방지).
7단계 리뷰(과제당 ~3 리뷰어-시간): 자동 오라클 실행 → 기여자 체크리스트 → 자동 LLM 점검(명세 공백·docstring·치팅·오타·하드코딩·의존성 고정·스키마) → 전문가 수작업 검토 → 모델 테스트(능력한계 vs 과제결함) → 적대적 exploit 에이전트 → 병합 후 이중 감사.
난이도 보정: Terminus 2 평균 해결률 기준 Easy ≥66.7% / Medium 33.3~66.7% / Hard <33.3%. 인간-실증 난이도 상관 r=0.436, p<<0.001; 인간-hard의 93.3%가 실증 hard, medium의 54.5%가 실증 hard(창의·적대 추론 과제에서 인간이 난이도 과소평가).
차별점: (1) 명령 시퀀스가 아닌 컨테이너 최종 상태 속성 검증, (2) 합성이 아닌 실제 Docker 컨테이너·터미널 셸, (3) 93인 크라우드소싱 + 7단계 품질 보증·적대적 exploit 탐지.
발견 (Findings)
- 발견 1 — 최전선 모델도 37% 이상 미해결: 최고 조합 GPT-5.2 + Codex CLI가 62.9%±3.0%, 최전선 전체 65% 미만. GPT-5-Nano 7.9
11.5%, GPT-OSS-20B 3.13.4%로 규모·세대 격차가 극명. - 발견 2 — 8개월간 최전선 성능 거의 배증: Gemini 2.5 Pro→GPT-5.2 사이 최고 해결률이 거의 두 배로 성장 → 1년 내 포화 가능성.
- 발견 3 — 최대 단일 실패는 PATH 미등록 실행파일 호출: 명령 단위 실패의 24.1%. 에이전트별 오류율 9.2%(Grok 4)~26.7%(GPT-OSS-120B). 시행당 턴 수·토큰과 성공률 무상관(Appendix G).
Results
해결률(모델×에이전트) — 32,155회 시행:
- GPT-5.2 + Codex CLI: 62.9% ± 3.0% (전체 최고)
- Claude Opus 4.5 + Terminus 2: 57.8% ± 2.5%
- Gemini 3 Pro + Terminus 2: 56.9% ± 2.5%
- GPT-5.2 + Terminus 2: 54.0% ± 2.9%
- Claude Opus 4.5 + Claude Code: 52.1% ± 2.5%
- GPT-5-Nano: 11.5%(Codex CLI)~7.9%(Terminus 2); GPT-OSS-20B: 3.4%~3.1%
최전선 전체 <65%, 소형 평균 ~15%. Terminus 2는 단일 Bash 도구 중립 스캐폴드로 모델 순수 역량 비교 기준점 역할.
비용·토큰: 실행 비용 100. 대부분 <20분·<25 API 호출·<10M 토큰; 극단 2h·수백 호출·~100M 토큰. 턴 수·토큰과 성공률 무상관(Appendix G).
시간 추이: Gemini 2.5 Pro→GPT-5.2 8개월 최고 성능 거의 배증.
궤적 단위 오류: Execution Errors(Opus 4.5·GPT-5.2서 지배적), Coherence Errors(최전선서 낮음), Verification Errors(coherence와 유사). Qwen Coder는 세 유형 모두 높고 균등.
ABC(Agentic Benchmark Checklist): Outcome Validity·Task Validity·Benchmark Reporting 세 영역 모두 높은 점수.
Discussion
Terminal-Bench 2.0은 최전선 모델·에이전트가 전문가 수준 터미널 작업 상당 부분을 여전히 해결하지 못함을 확인한다. 다양·장기지평의 전문가 과제가 난이도·현실성·경제적 가치를 동시에 충족하며, 89개 과제는 방대한 도메인 지식·상호의존 행동 연쇄·자율 문제해결을 요구해 합성 환경·협소 CLI 측정의 한계를 넘어선다. 성능 향상 궤적상 1년 내 포화 가능성을 전망하고, 신규 과제셋 지속 공개·tbench.ai 게시를 약속한다. 향후 데이터셋 구축자에게는 무결성 보장·착취 방지를 위한 수동 검증 투자를 권고한다.
이론적 의의
- 현실 기반 에이전트 평가 기준 확립: 합성 환경·단일 기능 과제를 넘어 전문가 실무를 벤치마크화해 생태학적 타당성을 높인 새 기준. 실무 위임 가부 판단의 실증 근거.
- 동적 평가 생태계 모델: 1년 내 포화 예측 + 신규 과제셋 공개 약속으로, 벤치마크가 목표가 되면 왜곡되는 Goodhart 문제에 갱신형 평가 생태계로 대응.
- 오염 탐지 프로토콜 이식: Big-Bench canary string을 터미널 에이전트 벤치마크에 도입해 학습 데이터 오염 사후 탐지의 표준 방법론 선례 제시.
Discussion Points
- 논쟁점: 최고 63% 미만 해결이 상업적 자율 배포 안전 임계로 충분한가; 과제셋 갱신이 모델 발전 속도를 실제로 따라갈 수 있는가.
- 검증 필요 가정: canary string이 의도적 오염을 실제 억제·탐지하는가; 결과지향·속성 기반 테스트가 실무 성공의 완전한 대리지표인가.
- 후속 연구: 오류 유형별 표적 훈련; 외부 의존성 동결·오프라인화 과제 설계; SE 외 도메인(보안·과학계산) 균형 확장.
실험 결과 상세
주 실험 결과: Model × Agent × Resolution Rate
| Model | Agent | Resolution Rate | vs. Best (GPT-5.2/Codex CLI) |
|---|---|---|---|
| GPT-5.2 | Codex CLI | 62.9% ± 3.0% | — (최고 성능) |
| Claude Opus 4.5 | Terminus 2 | 57.8% ± 2.5% | −5.1%p |
| Gemini 3 Pro | Terminus 2 | 56.9% ± 2.5% | −6.0%p |
| GPT-5.2 | Terminus 2 | 54.0% ± 2.9% | −8.9%p |
| Claude Opus 4.5 | Claude Code | 52.1% ± 2.5% | −10.8%p |
| GPT-5-Nano | Codex CLI | 11.5% | −51.4%p |
| GPT-5-Nano | Terminus 2 | 7.9% | −55.0%p |
| GPT-OSS-20B | Codex CLI | 3.4% | −59.5%p |
| GPT-OSS-20B | Terminus 2 | 3.1% | −59.8%p |
- 총 32,155 trials; 모델-에이전트 조합당 최소 5회 실행. 소형 모델 평균 ~15%. 최전선 전체 65% 미만.
명령 수준 실패 분류 (Command-Level Failure Taxonomy)
| 실패 유형 | 전체 실패 내 비율 |
|---|---|
| Calling executables not in PATH (미설치/PATH 미등록 실행파일 호출) | 24.1% |
| Running-executables failures (실행파일 실행 실패) | 9.6% |
| Other (8개 하위 유형) | 나머지 |
- 모델별 명령 에러율 범위: 9.2%(Grok 4) ~ 26.7%(GPT-OSS-120B).
- 8개 하위 유형: Disobey Task Specification / Step Repetition / Unaware of Termination Conditions / Context Loss / Premature Termination / No or Irrelevant Verification / Reasoning-Action Mismatch / Weak Verification.
프레임워크 다이어그램
graph TB A["태스크 수집 (229개 제출, 93명 기여자)"] --> B["품질 심사 후 89개 선정"] B --> C["5개 태스크 구성요소"] C --> C1["지시문 (Instruction)"] C --> C2["Docker 이미지"] C --> C3["테스트 스위트 (결과 기반)"] C --> C4["참조 솔루션 (Oracle)"] C --> C5["시간 제한"] C1 --> D["Harbor 하네스"] C2 --> D C3 --> D C4 --> D C5 --> D D --> E["Daytona 컨테이너 (32-100개 병렬)"] E --> F["에이전트 스캐폴드 6종 x 모델 16종"] F --> G["에이전트-환경 상호작용 (32,155 trials)"] G --> H["결과 기반 테스트 (Outcome-Based Tests)"] H --> I["해결률 (Resolution Rate)"] H --> J["실패 분류 (Failure Taxonomy)"]
재현성 및 신뢰도 평가
| 항목 | 등급 | 비고 |
|---|---|---|
| 코드 공개 | ✅ | Harbor 하네스 공개, tbench.ai에 평가 파이프라인 게시 |
| 데이터 공개 | ✅ | 89개 과제 전량 tbench.ai 공개(Docker 이미지·지시문·테스트 포함) |
| 하이퍼파라미터 | ✅ | 패키지 버전 고정, Docker 사전 빌드, 최소 5회 반복, 95% CI 보고 |
| 실험 환경 | ⚠️ | Daytona 표준화되나 인터넷 접속 허용 → 외부 패키지/API 변동 시 재현성 저하 가능 |
| 통계적 신뢰도 | ✅ | 상위 결과 ± 신뢰구간 명시, 32,155 trials; 하위 모델 일부 CI 미기재 |
| 종합 등급 | B | 공개 데이터+하네스+Docker로 높은 재현성 기반이나, 인터넷 의존성·오염 위험이 A를 제한 |
주장별 신뢰도
| # | 주장 | 근거 | 신뢰도 |
|---|---|---|---|
| 1 | GPT-5.2 + Codex CLI가 62.9%±3.0%로 최고 해결률 | 32,155 trials, 95% CI, 다중 실행 평균, 공개 하네스 검증 가능 | 🟢 |
| 2 | 최전선 모델 전체 65% 미만 해결 | 상위 5개 조합 전부 65% 이하 수치로 직접 확인, 소형 ~15% | 🟢 |
| 3 | Gemini 2.5 Pro 이후 8개월간 최고 성능 거의 배증 | 진술은 있으나 Gemini 2.5 Pro 구체 수치 미게재, 비교 기준 불투명 | 🟡 |
| 4 | PATH 미등록 실행파일 호출이 명령 실패의 24.1% | 명시적 퍼센트 인용·분류 공개; 분류 방법론 상세 미기술 | 🟡 |
관련 연구 비교 매트릭스
| 축 | Terminal-Bench (2026) | SWE-Bench (2023) [base] | τ-bench (2024) [alternative] | WebArena (2023) [alternative] | OSWorld (2024) [alternative] | MLE-Bench/MLGym (2024-25) [sota] |
|---|---|---|---|---|---|---|
| 환경 | 실제 Docker 컨테이너 터미널 셸(인터넷 허용) | 실제 GitHub 저장소, 컨테이너 격리 | 시뮬레이션 고객서비스(도구-에이전트-사용자) | 실제 웹 브라우저 환경 | 실제 OS 환경(GUI+CLI, 멀티모달) | 실제 ML 실험 환경(Kaggle/파이프라인) |
| 과제 도메인 | SE·인프라·ML·데이터·보안·영상(다영역) | 소프트웨어 엔지니어링(이슈→PR) | 고객서비스 도구 호출(리테일·항공) | 웹 탐색·정보검색·폼·전자상거래 | OS 파일·앱·워크플로 자동화 | ML 연구·모델 학습·제출 |
| 과제 수·규모 | 89(229 중 선별, 93 기여) | 2,294(Verified 500) | ~170 [근사] | ~812 [근사] | ~369 [근사] | MLE-Bench ~75 대회 [근사] |
| 검증 방식 | 결과지향 속성 테스트(최종 상태 검사) | 단위 테스트 + PR 병합 가능 | pass^k 반복 시뮬레이션 | 규칙 기반 성공률 | 실행 기반 반환값·스크린샷 | 메달/지표 임계값 [근사] |
| 장기지평 | 예(최대 2h, 수백 호출, 상호의존 체인) | 부분적(단일 이슈) | 아니오(단일 대화 세션) | 예(멀티스텝 웹) | 예(멀티스텝 OS) | 예(전체 ML 파이프라인) |
| 난이도(최전선) | 최고 62.9%; 소형 ~15%; 전체 <65% | Verified ~50–70%+ [근사] | ~60–70%+ [근사] | ~35–50%+ [근사] | ~30–40%+ [근사] | 편차 큼 [근사] |
| 코드/데이터 공개 | ✅ (tbench.ai) | ✅ | ✅ | ✅ | ✅ | MLE-Bench ✅; MLGym [근사] |
차별점: (1) 명령 시퀀스가 아닌 컨테이너 최종 상태 속성 검증, (2) 89개 소규모지만 93인 전문가 실무 추출로 경제적 가치, (3) 단일 터미널 환경에서 SE·ML·보안·인프라 다도메인 포괄. [근사]는 원문 미기재로 공개 자료 기반 추정치.
원자적 인사이트 (Zettelkasten)
💡 최전선 에이전트도 전문가급 터미널 과제의 65% 미만만 해결한다
전문가가 돈 받고 하는 89개 명령줄 과제를 16개 모델×6개 에이전트로 32,155회 시행하자, 최고 조합 Codex CLI + GPT-5.2조차 62.9%±3.0%에 그쳤고 최전선 모델 전체가 65% 미만, 소형 모델은 평균 15%(GPT-OSS-20B 3.13.4%)였다. Claude Code가 연 $1B 매출을 낸다는 시대에도 자율 에이전트의 실전 역량엔 큰 격차가 남아 있음을 정량화한다. (조건: Terminal-Bench 2.0 89개 과제·결과지향 테스트, Terminus 2 중립 기준)
💡 명령이 아니라 “컨테이너 최종 상태”를 검사하는 결과지향 테스트
Terminal-Bench는 에이전트가 친 명령 순서·콘솔 출력을 채점하지 않고 컨테이너 최종 상태가 지시된 속성을 만족하는지(property-based)만 검사한다. “정답 경로를 외운” 에이전트와 “실제로 결과를 만든” 에이전트를 분리해, 어떤 경로로 풀든 결과만 맞으면 인정하는 실무 지향 평가를 가능케 한다. (조건: 오라클 솔루션으로 Solvability 확인, Specificity·Integrity와 함께 3기준 검증)
💡 성공률은 턴 수·토큰 사용량과 무상관이다
32,155회 시행에서 시행당 평균 턴 수와 성공률, 토큰 총량과 성능 사이에 상관이 없었다(Appendix G). 에이전트가 더 오래 붙잡고 더 많이 시도한다고 과제를 더 잘 푸는 게 아니며, 단순히 계산 예산을 늘리는 것만으로 역량 격차가 메워지지 않는다. (조건: 대부분 <20분·<25 호출·<10M 토큰, 극단 2h·수백 호출·~100M 토큰)
💡 포화 예측·갱신 약속 + canary string = Goodhart 대응 동적 평가
8개월 만에 최고 성능이 거의 배증했고 저자들은 Terminal-Bench 2.0이 1년 내 포화될 수 있다고 보아, 새 과제셋을 계속 공개하고 리더보드(tbench.ai)를 운영하며 Big-Bench canary string으로 학습 데이터 오염을 추적하겠다고 선언한다. 벤치마크가 목표가 되면 왜곡된다는 Goodhart 문제에 정적 점수 대신 갱신되는 평가 생태계로 답한다. (조건: canary string은 사후 탐지용, 의도적 오염 차단엔 제한적)
핵심 용어 정리
| 용어 | 정의 |
|---|---|
| 에이전트(agent) / 에이전틱 | 목표를 받아 스스로 여러 단계의 도구·명령 사용을 이어가며 과제를 수행하는 LLM 기반 시스템. |
| Terminal-Bench / Terminal-Bench 2.0 | 실제 터미널 셸의 어렵고 현실적인 89개 과제로 에이전트를 평가하는 벤치마크와 그 2.0 릴리스. |
| 스캐폴드(scaffold) / Terminus 2 | 모델을 감싸 터미널과 상호작용하게 하는 실행 계층. Terminus 2는 헤드리스 터미널 단일 도구로 Bash 명령만 쓰는 중립 비교 기준. |
| 결과지향(속성 기반) 테스트 | 에이전트의 명령·출력이 아니라 컨테이너 최종 상태의 속성을 검사해 성공을 판정하는 방식. |
| 오라클(레퍼런스) 솔루션 | 사람이 작성한 정답 스크립트로, 과제가 실제로 풀리는지(Solvability)를 확인하는 기준. |
| 해결률(resolution rate) | 전체 과제 중 테스트를 통과한 비율. 최소 5회 시행의 평균과 편차(±)로 보고. |
| 시행(trial) | 한 에이전트가 한 과제를 1회 시도한 단위. 이 논문은 총 32,155회 시행. |
| Harbor | 다양한 에이전트·모델을 표준화해 컨테이너 샌드박스에서 실행하는 평가 하네스(Daytona로 32~100개 병렬). |
| canary string | 데이터셋에 심는 고유 표식 문자열로, 학습 데이터 오염을 사후 탐지하기 위한 것(Big-Bench 방식 차용). |
| 최전선 모델(frontier model) | 그 시점 가장 성능이 높은 상용/공개 LLM(GPT-5.2, Claude Opus 4.5, Gemini 3 Pro 등). |
| 장기 지평 과제(long-horizon task) | 상호 의존적인 여러 행동을 긴 사슬로 이어야 풀리는, 자율 문제해결이 필요한 과제. |
| 실패 유형 분류체계(taxonomy) | 에이전트 실패를 8개 하위 유형으로 나눈 진단 틀. |
관련 연구
- τ-bench - A Benchmark for Tool-Agent-User Interaction in Real-World Domains — 논문이 ‘도구 사용(tool use)’ 계열 선행 벤치마크로 인용. τ-bench는 도구 호출·사용자 대화 상호작용에 초점인 반면, Terminal-Bench는 실제 터미널 셸의 장기지평 전문가 과제와 컨테이너 최종상태 검증으로 난이도·현실성을 끌어올림.
- AgentBench - Evaluating LLMs as Agents — LLM을 에이전트로 여러 환경에서 평가한 종합 선행 벤치마크. Terminal-Bench는 단일 터미널 환경에 집중하되 SE·ML·보안·데이터 등 다도메인을 담아 최전선 모델에도 포화되지 않는 난이도를 확보한 점이 대비됨.
- SWE-bench - Can Language Models Resolve Real-World GitHub Issues — 관련연구의 SE 대표 벤치마크(GitHub 이슈 해결). 코드 저장소 이슈에 특화된 SWE-Bench와 달리 Terminal-Bench는 터미널 전반을 포괄하고 Appendix D에서 26개 기존 벤치마크를 Harbor 포맷으로 흡수.
- WebArena - A Realistic Web Environment for Building Autonomous Agents — 웹 GUI 조작 에이전트 벤치마크. 시각·웹 인터페이스 조작 vs 명령줄 터미널 인터페이스라는 인터페이스 축의 대비.
- OSWorld — GUI 기반 실제 OS 컴퓨터 사용 벤치마크. 같은 ‘컴퓨터 사용’이라도 GUI가 아닌 터미널 셸에 집중하고 실제 셸 환경을 강조한다는 점에서 대비.
태그
paper #2026 ai-agents benchmark llm-evaluation terminal-cli
BibTeX
@article{merrill2026,
title={Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces},
author={Merrill, Mike A. and Shaw, Alexander G. and Carlini, Nicholas and Li, Boxuan and Raj, Harsh and Bercovich, Ivan and Dimakis, Alex and Konwinski, Andy and Schmidt, Ludwig},
journal={arXiv preprint arXiv:2601.11868},
year={2026},
url={https://arxiv.org/abs/2601.11868},
eprint={2601.11868},
archivePrefix={arXiv}
}