한 줄 요약
터미널 기반 AI 에이전트 벤치마크는 대부분 몇 분 안에 끝나는 단순 작업만 다뤘다. **Long-Horizon-Terminal-Bench(LHTB)**는 평균 88.9분, 239 에피소드, 980만 토큰이 소요되는 46개의 장기 과제를 제시하며, 최강 모델조차 28.3% 통과율에 그친다.
기존 벤치마크의 빈틈
Terminal-Bench 2나 SWE-Bench 같은 기존 평가는 두 가지 한계가 있다.
- 시간이 너무 짧다 — 대부분 20
30분, 2030 에피소드면 끝난다. - 평가가 binary다 — 최종 결과물만 보고 성공/실패를 가른다. 중간 과정이 얼마나 진행되었는지 알 수 없다.
실제 업무 환경에서 에이전트가 해야 하는 일은 다르다. 논문 실험 재현, SLAM 파이프라인 수리, 기후 모델 감사, 멀티모달 데이터 감사, 소코반 캠페인 풀이 등은 수십 단계의 터미널 명령과 파일 수정, 디버깅을 거쳐야 한다.
Figure 1: LHTB 과제 구조. 각 서브태스크마다 중간 보상을 부여해 얼마나 진행했는지 측정한다.
LHTB의 설계 원칙
1. 서브태스크 기반 밀도 보상
각 과제는 여러 개의 세분화된 서브태스크로 쪼개진다. 예를 들어 “ROS SLAM 벤치마크 수리” 과제라면:
- SE(2) 포즈 합성이 정확한가?
- 루프 클로저를 평가했는가?
- 랜드마크 맵을 재구성했는가?
- 궤적 일관성을 보고했는가?
각 서브태스크는 0~1 점수를 받고, 가중 평균으로 전체 보상 R이 계산된다. R ≥ 0.95면 “통과”로 간주한다.
2. 46개 과제, 9개 카테고리
Figure 2: 46개 과제는 인터랙티브 게임, 소프트웨어 엔지니어링, 과학 계산, 멀티모달 분석, 지구/기후 과학 등 9개 도메인에 걸쳐 있다.
과제 난이도는 Easy/Hard로 나뉘며, 대부분은 Hard다. 컨테이너화된 터미널 환경에서 자연어 지시문만 주어지고, 에이전트는 셸 명령을 통해 파일을 읽고, 스크립트를 실행하고, 결과를 검사하며 반복적으로 디버깅해야 한다.
3. 현실적인 장기 실행
평균 통계:
| 지표 | LHTB | Terminal-Bench 2 |
|---|---|---|
| 평균 실행 시간 | 88.9분 | 20~30분 |
| 평균 에피소드 | 239회 | 20~30회 |
| 평균 토큰 사용량 | 980만 | — |
17개 프론티어 모델 결과
리더보드
Figure 3: R ≥ 0.9, 0.95, 1.0 세 가지 임계값에서의 pass@1과 평균 보상. Grok 4.5가 28.3%로 1위.
핵심 발견:
- Grok 4.5 — 28.3% (R≥0.95), 19.6% (R=1.0)
- 평균 통과율 — 6.4% (R≥0.95), 3.2% (R=1.0)
- 즉, 최강 모델도 10개 중 7개 이상 실패한다.
보상 분포
Figure 4: 17×46=782회 실행 중 R≥0.95를 넘은 것은 50건(6.4%)에 불과하다. 대다수는 R<0.5에서 끝난다.
비용 분석
Table 1: 과제당 평균 239 에피소드, 88.9분이 소요되며, 모델별로 비용 차이가 크다.
Figure 5: 총 비용(log 스케일) 대비 R≥0.95 통과율. 비싼 모델이 항상 더 잘하는 것은 아니다.
실패 패턴 분석
Figure 6: 타임아웃, 조기 종료, 약한 자기 검증 등 실패 원인을 모델별로 분해.
LHTB의 밀도 보상 시스템 덕분에 기존에는 숨겨져 있던 실패 패턴이 드러난다:
- 타임아웃 기반 미완료 — 에이전트가 시간 안에 과제를 끝내지 못함. 가장 흔한 패턴.
- 조기 종료 — 에이전트가 스스로 “끝났다”고 판단하고 멈추지만, 실제로는 서브태스크가 남아 있음.
- 약한 자기 검증 — 에이전트가 자신의 작업 결과를 제대로 확인하지 않음.
이 패턴들은 단순히 “모델이 멍청해서”가 아니라, 장기 과제에서의 계획 유지, 상태 추적, 자기 검증 능력이 근본적으로 부족하다는 것을 보여준다.
왜 중요한가
에이전트 평가의 패러다임 전환
LHTB는 두 가지 점에서 기존 평가를 바꾼다:
- 부분 점수 — 바이너리 성공/실패 대신, 에이전트가 “얼마나 멀리 왔는지”를 측정한다. 이는 연구자에게 훨씬 유용한 신호다.
- 극단적 장기 과제 — 88.9분 평균 실행 시간은 실제 업무 환경에 가깝다. “5분 안에 끝나는 코딩 문제”가 아닌, “반나절 걸리는 디버깅 세션”을 평가한다.
에이전트 한계의 구체적 증거
최강 모델도 71.7%의 과제를 R<0.95에서 실패한다. 이는 “에이전트가 잘 안 된다”는 막연한 인상이 아니라, 정량적으로 측정된 구체적 한계다. 특히:
- 980만 토큰을 써도 끝내지 못하는 과제가 있다
- 239 에피소드를 반복해도 중간에 길을 잃는다
- 비용이 많이 든다고 항상 더 잘하는 것은 아니다
하네스와 컨텍스트 관리의 중요성
LHTB의 결과는 에이전트 하네스 설계의 중요성을 다시 한번 강조한다. 동일한 모델로도 하네스가 다르면 결과가 달라진다. 긴 컨텍스트 유지, 에피소드 간 상태 추적, 자기 검증 루프 — 이런 하네스 수준의 설계가 장기 과제에서는 결정적이다.
한계와 향후 방향
- 과제 수 — 46개는 여전히 적다. 커뮤니티 기여로 확장이 필요하다.
- 도메인 편향 — Easy 과제가 6개에 불과하고, 대부분 Hard다. 난이도 스펙트럼이 좁다.
- 실행 비용 — 17개 모델 × 46개 과제 × 평균 88.9분 = 막대한 GPU/API 비용이 발생한다. 재현성에 장벽이 될 수 있다.
- 단일 하네스 — Harbor + Terminus-2 하네스(일부는 Codex)로만 평가했다. 하네스 자체가 결과에 미치는 영향을 분리하기 어렵다.
더 실습해보고 싶은 분들께
에이전트 하네스, 긴 컨텍스트 루프, 터미널 에이전트 같은 주제가 점점 중요해지고 있습니다. 직접 실습하며 감을 잡고 싶다면 아래 두 가지를 추천합니다:
- 『이게 되네? 오픈클로 미친 활용법 50제』 — 에이전트 자동화와 도구 활용을 처음부터 끝까지 손으로 익히는 실전 가이드
- 「모두를 위한 루프 엔지니어링」 — 에이전트 루프 설계와 컨텍스트 관리의 원리를 체계적으로 배우는 강의
논문: Long-Horizon-Terminal-Bench: Testing the Limits of Agents on Long-Horizon Terminal Tasks with Dense Reward-Based Grading (arXiv:2607.08964, 2026년 7월)