[2026-1] 김학선, 임준수 - BENCHMARKING AGENTS ON HARD, REALISTICTASKS IN COMMAND LINE INTERFACES

https://arxiv.org/abs/2601.11868

Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces

 

Task Formulation

Terminal-Bench의 테스크는 에이전트가 현실적인 터미널 환경에서 상호작용하며 문제를 해결하도록 설계되었습니다.

• 구성 요소:
  • 각 테스크는 지시 사항
  • 초기 환경이 세팅된 Docker 이미지
  • 정답을 확인할 수 있는 테스트 세트
  • 인간이 작성한 예제 솔루션
  • 시간 제한
• 결과 중심적 평가: 테스트는 에이전트가 입력한 명령어 세트나 콘솔 출력을 검사하는 것이 아니라, 최종적으로 한다. 즉, 컨테이너의 상태가 지시 사항을 충족했는지만을 평가
• 상호작용적 탐색: 에이전트는 제공된 Bash 명령어 등 다양한 도구를 사용해 스스로 환경을 탐색하고 조작하며 목표를 달성해야 합니다. 이 과정은 Harbor 프레임워크를 통해 실행되며 Cluade Code, Codex CLI 등 다양한 에이전트를 지원합니다.

Terminal-Bench task architecture

Verification

데이터셋의 품질을 보장하기 위해 각 테스크는 평균 3시간 가량의 철저한 다단계 검증 과정을 거쳤습니다.

• 3대 품질기준
  1. 구체성: 테스크가 모든 올바른 최종 상태를 명시하고, 테스트가 이를 정확히 포착하는지 확인합니다.
  2. 해결 가능성: 수동으로 작성된 예제 솔루션을 실행했을 때 모든 테스트가 통과되는지 확인합니다.
  3. 무결성: 에이전트가 미래의 Git 커밋 내역을 미리 보는 등 현실에 없는 '편법'을 써서 테스트를 통과할 수 없도록 차단합니다.
• 검토 프로세스: 기여자들의 체크리스트 작성, LLM을 활용한 자동화된 실수 검토, 자동화된 솔루션 테스트 외에도, 여러 최신 모델을 통해 테스크를 직접 실행해 보거나 적대적 공격 에이전트를 투입해 시스템의 허점을 악용할 수 있는지 검사하는 과정을 거쳤습니다.

검증 프로세스 흐름도

Composition

초기 제출된 229개의 테스크 중 엄격한 심사를 통과한 89개의 테스크로 구성되어 있습니다.

• 다양한 도메인: 소프트웨어 엔지니어링을 비롯해 시스템 관리, 데이터 과학, 보안, 기계 학습, 비디오 처리 등 매우 광범위한 분야를 다룬다.
• 실제적인 복잡성: 단순히 패키지를 설치하는 것을 넘어, 'Python 비동기 작업 관리 시 키보드 인터럽트 처리', '레거시 COBOL 코드를 Python으로 완벽히 재작성하기' 등 고도의 작업이 포함되어 있습니다.
• 소요 시간의 현실성: 전문가의 경우 95% 이상의 테스크를 1일 이내에 해결할 수 있도록 설계되었으나, 주니어 엔지니어 기준으로는 하루에서 최대 일주일 이상이 걸리는 테스크(OCaml 가비지 콜렉터 버그 수정)도 포함되어 있어 모델의 긴 호흡(long-horizon) 능력을 요구한다.

벤치마크에 포함된 도메인 분포

주니어 엔지니어와 도메인 전문가 기준 테스크를 해결하는데 걸리는 예상 소요 시간 분포

 

Results

16개의 최신 모델과 6개의 에이전트 조합을 통해 3만 번 이상의 테스트를 수행한 결과입니다.

• 성능 순위: 상위권 모델도 65% 미만의 해결률을 보였습니다. GPT-5.2와 Codex CLI 조합(63%)이 1위를 차지했으며, Terminus 2 에이전트 기반의 Claude Opus 4.5(58%), Gemini 3 Pro(57%)가 뒤를 이었습니다. 오픈 소스 모델 중에서는 Kimi K2 Thinking이 36%로 가장 높았습니다.

다양한 언어 모델과 에이전트 조합이 달성한 최종 테스크 해결률

 

- 에이전트보다 모델의 역량이 중요: 동일한 에이전트를 사용하더라도 모델을 상위 버전으로 교체했을 때 성능 향상 폭이 훨씬 커, 에이전트 스캐폴딩보다 기반 모델 자체의 능력이 더 중요함을 시사합니다.

모델 출시일에 따른 벤치마크 성능 변화 추이

 

• 체감 난이도 차이: 인간이 '어려움'으로 평가한 테스크의 93.3%는 모델에게도 실제로 어려웠습니다. 반면, 인간이 '보통'이라고 평가한 테스크의 54.5%를 모델은 풀지 못했는데, 이는 패턴 인식보다는 을 보여줍니다.
• ⇒ 창의적이거나 적대적인 추론이 필요한 경우 모델이 취약함

사람이 예측한 난이도와 모델이 풀며 나타난 난이도 간 상관관계

 

모델별 맞춤형 오류 패턴: 최상위 폐쇄형 모델들은 주로 지시사항을 무시하거나 같은 단계를 무의미하게 반복하는 '실행 오류'가 압도적으로 많이 발생합니다. 반면 오픈소스 모델은 실행, 일관성 유지, 결과 검증 등 모든 영역에서 고르게 실패하는 패턴을 보였습니다.

LLM 종류별 오류 비중

 

명령어 단위의 가장 흔한 실패 원인: 에이전트가 입력한 명령어의 실패율은 모델에 따라 9.2%~26.7%까지 다양하게 나타납니다. 전체 실패 원인 중 'Command not found'이 24.1%로 1위를 차지했는데, 이는 에이전트들이 설치되지 않은 패키지나 경로에 없는 실행 파일을 무작정 호출하려다 가로막히는 기초적인 환경 인식 오류를 자주 범하고 있음을 보여줍니다.

 

에이전트가 실패한 개별 명령어를 시각화한 원형 차트

 

Limitations

벤치마크의 현실성을 극대화하기 위해 인터넷 접속을 허용하면서 발생한 불가피한 한계들입니다.

• 재현성의 문제: 의존성 패키지나 외부 API 환경이 시간이 지남에 따라 변동될 수 있으며, 실행되는 기기의 하드웨어 리소스 차이로 인해 결과가 달라질 수 있습니다.
• 부정행위 및 데이터 오염 위험: 에이전트가 인터넷에서 벤치마크의 정답을 직접 검색하여 부정행위를 할 가능성이 존재합니다. 또한, LLM 개발사들이 이 데이터셋을 학습에 사용할 위험을 막기 위해 '카나리아 문자열'을 삽입했으나, 의도적인 학습 오염을 완벽히 막기엔 한계가 있습니다.
• 잔존 오류 가능성: 테스크당 3시간 이상의 방대한 수작업 검증과 LLM 검토를 거쳤음에도 불구하고, 과제들이 워낙 다양하고 복잡하여 여전히 일부 테스트 스펙이나 지시 사항에 결함이 남아있을 가능성을 배제할 수 없습니다.

Related work

Software Engineering

• SWE-bench / SWE-bench Multimodal 실제 GitHub의 이슈(버그 리포트)를 해결하는 능력을 측정합니다. 코드 수정 능력에 특화되어 있으나, 시스템 설정이나 복잡한 인프라 조작 능력은 상대적으로 덜 강조됩니다.
• https://github.com/swe-bench/SWE-bench

GitHub - SWE-bench/SWE-bench: SWE-bench: Can Language Models Resolve Real-world Github Issues?

• HumanEval / DevEval 짧고 독립적인 파이썬 함수 구현 능력을 평가하는 기초적인 코딩 벤치마크입니다. 격리된 환경에서 코드 로직만 보기 때문에 실제 OS 의존성이나 터미널 실행 환경은 고려하지 않습니다.
• SWE-Lancer 실제 프리랜서 사이트의 유료 과업을 기반으로 에이전트의 경제적 가치를 평가합니다. 실제 비즈니스 환경에서의 작업 완수 능력을 중점적으로 봅니다.

Computer & Tool Use

• WebArena / Visual Web Arena 웹 브라우저 상에서 쇼핑, 예약 등 인간의 인터넷 활동을 대행하는 능력을 측정합니다. 마우스 클릭이나 스크롤 같은 GUI 기반 상호작용이 중심이며, 엔지니어링 툴 숙련도는 낮습니다.
• OS World 윈도우나 리눅스 데스크톱 환경(GUI)에서 파일을 옮기거나 앱을 실행하는 일반 사용자 행동을 평가합니다. 터미널 중심의 전문적인 개발자 워크플로우와는 차이가 있습니다.
• Berkeley Function Calling Leaderboard AI 모델이 특정 함수나 API를 규격에 맞게 얼마나 정확하게 호출하는지(Tool-use)에 집중하여 평가합니다.

Scientific & ML

• MLGym-bench 에이전트가 하이퍼파라미터를 튜닝하고 실험 로그를 분석하는 등 머신러닝 학습 주기 전반을 관리하는 능력을 측정합니다. 터미널 조작보다는 ML 워크플로우 자체에 특화되어 있습니다.

https://arxiv.org/abs/2502.14499

MLGym: A New Framework and Benchmark for Advancing AI Research Agents

 

• ReplicationBench / Auto-Bench 기존 과학 논문의 실험 결과를 AI가 똑같이 재현(Replicate)할 수 있는지 평가합니다. 과학적 정밀도와 논리적 절차를 수행하는 능력을 중점적으로 봅니다.

Terminal & Shell

• NL-to-Bash (자연어-Bash 변환) 사람의 말을 Bash 명령어로 번역하는 단순 모델의 성능을 측정합니다. 단발성 명령어 생성에 집중하며, Terminal-Bench처럼 복잡한 연속 작업을 수행하는 '장기 과업' 능력은 보지 않습니다.
• Shell Script Optimization 작성된 쉘 스크립트의 성능이나 효율성을 얼마나 더 최적화할 수 있는지 평가합니다. 에이전트의 자율적 문제 해결보다는 코드 최적화 지능에 집중합니다.
• 기존 CLI 관련 벤치마크의 한계:
• 일부 연구는 쉘 스크립트 최적화, 환경 설정, 자연어→Bash 변환 등 단일 기능만 평가합니다.

Terminal-Bench 2.0은 In comparison, Terminal-Bench is focused on general agentic manipulation of computers.

 

EXPERIMENTAL SETUP

TERMINUS 2

• Terminal-Bench는 상호작용형(interactive) 프레임워크이기 때문에, 에이전트의 구조(Scaffold)와 모델의 순수한 성능을 따로 떼어내어(decouple) 평가하기가 어려움.
• 많은 에이전트 구조들이 특정 모델의 성향에 맞춰 설계되어 있는데, 특히 모델과 에이전트가 같은 조직에서 개발된 경우에 이런 경향이 더 두드러짐.
• 실제로 많은 에이전트가 패키지 매니저를 통해 컨테이너에 직접 설치되며, 일반적인 Bash 명령어보다 훨씬 복잡한 실제 실행 프로그램 형태의 도구들을 사용.
• 이러한 에이전트들의 제약 사항과 편향성을 고려하고 벤치마크 본연의 취지를 살리기 위해, 모델 성능 비교를 위한 중립적인 테스트베드 역할을 하는 단순한 구조의 Terminus 2는 오직 Bash 명령어만을 사용해 태스크를 수행.

최소화된 중립성

• 특정 모델에 유리하게 맞춰진 편향(Bias)을 제거하기 위해 만든 가장 단순한 형태의 에이전트 구조입니다. 복잡한 추상화,CLI 없이, 언어 모델이 터미널과 '직접' 소통하는 환경을 제공하여 모델 간의 공정한 성능 비교가 가능하게 합니다.

추상화된 도구 배제

• Claude Code나 OpenHands 같은 다른 에이전트들은 '파일 편집', '다운로드' 등의 전용 API 도구를 갖추고 있지만, Terminus 2는 오직 Bash 명령어만 사용합니다. 예를 들어, 파일을 수정할 때 에이전트가 echo 명령어로 덮어씌울지, 혹은 직접 vim이나 emacs 같은 텍스트 에디터를 띄워 수정할지 스스로 결정.

실제 터미널 사용성 재현

• 단순한 텍스트 입력을 넘어, 화면 스크롤, 방향키 조작, 다중 쉘(Sub-shells) 실행 등 실제 사람이 터미널을 다루는 것과 똑같은 동작이 가능합니다. 이를 통해 메뉴 기반의 대화형 프로그램도 자율적으로 조작할 수 있습니다.

컨텍스트 요약 모듈

• 모델의 컨텍스트 제한(Token Limit)에 도달하면, 별도의 요약 에이전트가 지금까지의 작업 내용을 압축하여 전달합니다. 이 덕분에 수백만 개의 토큰이 소모되는 복잡하고 긴 호흡의 태스크(Long-horizon tasks)도 끊김 없이 수행할 수 있습니다.

AGENTS

• 모델–에이전트 결합 평가 구조: 각 모델은 단독으로 평가되지 않고, 호환되는 에이전트 프레임워크(agent scaffold)에 결합되어 실행됩니다. 즉, 모델 자체 성능이 아니라 “모델 + 에이전트 조합”의 실제 작업 수행 능력을 측정합니다.

MODELS

• API 기반 실행 환경: 클로즈드 모델은 각 기업의 공식 API를 통해 호출되며, 오픈 모델은 Together.AI API를 통해 일관된 방식으로 실행됩니다.

HARBOR

• Harbor 기반 대규모 실행 프레임워크: Harbor 프레임워크를 활용하여 Terminal-Bench 태스크를 표준화된 형식으로 실행하며, 단일 명령어(harbor run -d terminal-bench@2.0)로 재현 가능한 평가 환경을 제공합니다.
• 컨테이너 기반 병렬 실행 환경: Daytona와 같은 샌드박스 환경을 사용하여 32~100개의 컨테이너를 병렬로 실행함으로써, 실제 시스템 환경과 유사한 조건에서 대규모 에이전트 평가를 수행합니다.
• 실험 설정 공개를 통한 재현성 지원: Harbor 설정 파일 및 실험 구성은 GitHub에 공개되어 있어, 동일한 환경에서 실험을 재현할 수 있도록 지원합니다.

외부 소스 수집 및 데이터셋

1. 모델의 resoultion rate, 모델이 각각 task를 완벽하게 성공시켰는지에 대한 비율을 색깔로 보여줌

• 오른쪽 하단이 hard 데이터셋

 

2. 타임아웃 비율, 에이전트가 문제를 풀다 time-out한 비율

3. 토큰 사용량 지표, 해결률은 0인데 토큰 사용량은 최대치(수천만~1억 개)를 기록하는 경우. AI가 문제를 풀려고 많은 토큰을 사용

 

• figure11에서는 성공인데 figure13에서 파란색이라면 AI가 시행착오 끝에 정답 찾아냄.
• figure11에서 실패인데, figure13에서 파란색? 돈과 토큰을 과다하게 썻지만 해결 못한 최악의 효율

Figure 해석

- torch-pipeline-parallelism : LLaMA 모델을 여러 GPU에 쪼개서 학습시키는 AFAB(All-Forward-All-Backward) 파이프라인 병렬화를 구현, Microbatch 단위로 데이터를 쪼개야 함. 각 GPU 간 데이터 주고받는 로직 구현

-> Hard Level

- reshard-c4-data : 데이터 전처리 및 관리 능력 지표 데이터, 거대 데이터셋(C4 sample)을 특정 제약 조건(폴더당 파일 30개 이하, 파일당 15MB 이하)에 맞춰 다시 나누고(Reshard), 다시 합치는(Decompress) 스크립트를 짜는 것 

-> medium Level

 

 

 

데이터셋 예시 및 개요

1. reshard-c4-data

• 거대 언어 모델(LLM) 학습에 사용되는 C4(Colossal Clean Crawled Corpus) 데이터셋의 샘플을 다룸.
• 수 테라바이트에 달하는 실제 데이터를 효율적으로 관리하기 위해 파일을 쪼개고 합치는 'Sharding' 능력을 검증

https://www.tbench.ai/registry/terminal-bench-core/head/reshard-c4-data

Terminal-Bench

• 제공된 c4_sample/ 데이터를 특정 제약 조건에 맞춰 재구조화(compress.py)하고, 이를 다시 원상복구(decompress.py)하는 스크립트를 작성
• 한 디렉토리 내에 파일이나 폴더가 30개를 넘지 않아야 하는 구조.
• 파일 크기가 15MB를 초과하지 않아야 함.
• 가상환경 - uv를 사용하여 pyproject.toml을 생성하고 가상환경(venv)에서만 실행

재현성(Reproducibility) 확보

• uv sync와 pyproject.toml을 강제함으로써 에이전트가 각 환경에서 표준화된 환경을 구축할 수 있게함

평가

• decompress.py로 복구했을 때 파일 구조가 단 하나라도 틀리면 0점 처리되는 이진 평가(Binary Evaluation) 방식

2. sam-cell-seg

• 이미지에서 세포 마스크를 추출하고, 이를 경량화된 SAM 모델인 MobileSAM으로 정밀하게 다듬는 파이썬 스크립트(convert_masks.py) 작성
• 오리지널 SAM이 아닌, 성능을 유지하면서 크기를 줄인 MobileSAM을 반드시 사용해야 하는 제약.
• CPU만 사용해야함

평가

• 결과 마스크 간에 Overlap이 없어야 함.
• 각 세포는 반드시 하나의 연속된(Contiguous) 마스크만 가져야 함.
• 모든 출력은 좌표값 기반의 폴리라인 형식이어야 함.

CONCLUSION

 

• Terminal-Bench는 AI 에이전트의 실전 능력을 평가하기 위해 실제 엔지니어링 난제들을 데이터셋화한 고난도 벤치마크 프레임워크
• 모델 지능이 고도화됨에 따라 더 복잡하고 현실적인 과제가 필요하며, 이를 위해 전문가의 철저한 Manual Verification을 통한 평가의 신뢰성 확보가 핵심 가치
• 이는 부정행를 방지하는 동시에, 테스트하고자 하는 모든 속성이 과제 설명에 적절하고 명확하게 명시되었는지 확인하기 위한 과정
• 결과적으로 AI가 단순 코딩 보조를 넘어 실제 시스템 인프라를 자율적으로 제어하고 관리하는 에이전트로 나아가기 위한 strict한 기준점을 제시

 

비고

앤서블, 테라폼 VS Terminal-Bench

- 현재 Terminal-Bench에서는 AI가 쌩 Bash 명령어로만 문제를 풀어서 성공률이 낮고 비용(토큰)이 많이 든다. 만약 AI가 앤서블이나 테라폼 같은 Iac 툴을 외부 소스로서 적재적소에 꺼내 쓸 수 있게 된다면 성능 개선이 있을지? ex) sem-cell-seg 환경설정을 playbook으로 처리