큐레이션

Terminal-Bench: 코딩 에이전트를 실제 터미널 작업으로 어떻게 비교할까

코드 컴파일·모델 학습·서버 설정 같은 터미널 과제를 샌드박스에서 반복 실행하고, 테스트 스크립트로 AI 에이전트 결과를 비교하는 오픈소스 벤치마크

Python2,578 (2026-09-14 GitHub API 확인)

코딩 에이전트를 비교하려는 개발팀이라면 같은 프롬프트를 몇 번 실행해 보는 것만으로는 실제 작업 능력을 판단하기 어렵습니다. Terminal-Bench는 코드 컴파일, 모델 학습, 서버 설정처럼 결과를 확인할 수 있는 터미널 과제와 샌드박스 실행 환경을 묶어, 에이전트·모델·실행 하니스를 같은 조건에서 비교할 출발점을 제공합니다.

이 Pick의 핵심 질문은 “어떤 모델이 가장 좋은가?”가 아닙니다. “우리 업무와 비슷한 과제를 어떻게 고르고, 성공 조건과 실행 환경을 고정해 다시 비교할 것인가?”입니다.

어떤 팀이 먼저 살펴볼 만한가요?

  • 코딩 에이전트의 파일 수정·명령 실행·테스트 수행을 반복해서 비교하려는 팀
  • 모델이나 에이전트 하니스를 바꿀 때 같은 시험 조건을 유지하려는 개발자
  • 에이전트가 말로 설명하는 능력보다 실제 터미널 작업의 완료 여부를 확인하려는 팀
  • 자체 과제를 추가해 내부 업무에 맞는 평가 목록을 만들려는 팀

짧은 질의응답이나 문장 품질만 비교하려는 경우에는 Terminal-Bench의 과제 구조가 무거울 수 있습니다. 실제로 파일을 만들고 명령을 실행하는 업무가 평가 대상인지 먼저 확인하세요.

무엇을 비교할 수 있나요?

과제와 성공 조건을 함께 고릅니다

Terminal-Bench의 각 과제에는 자연어 지시문, 성공 여부를 확인하는 테스트 스크립트, 참고용 정답 풀이가 포함됩니다. 에이전트가 그럴듯한 설명을 했는지가 아니라, 미리 정한 확인 절차를 통과했는지를 비교할 수 있는 구조입니다.

처음에는 팀의 실제 업무와 비슷한 과제 몇 개를 골라야 합니다. 파일 수정, 패키지 설치, 테스트 실행, 서비스 설정처럼 결과와 실패 지점을 분리해 기록할 수 있는 과제가 시작하기 좋습니다.

실행 환경을 고정합니다

공식 README는 언어 모델을 터미널 샌드박스에 연결하는 실행 하니스를 별도 구성요소로 설명합니다. uv와 Docker가 필요한 실행 구조이므로, 운영 컴퓨터와 같은 권한·네트워크·비밀값을 바로 넣기보다 평가 전용 환경을 따로 두는 편이 안전합니다.

벤치마크 결과를 비교할 때는 에이전트만 바꾸고 과제·데이터셋 버전·모델·동시 실행 수·시간 제한은 먼저 고정하세요. 그래야 모델 변경과 실행 조건 변경을 혼동하지 않을 수 있습니다.

점수와 업무 적합성을 나눠 봅니다

공식 저장소는 tb run CLI와 데이터셋 버전, 리더보드 제출 절차를 안내합니다. 점수는 같은 과제 세트에서의 실행 결과를 비교하는 데 쓸 수 있지만, 조직의 실제 비용·처리 시간·권한 정책·사용자 경험을 대신 측정하지는 않습니다.

공식 원문에서 확인한 범위는 무엇인가요?

Terminal-Bench 공식 README는 컴파일, 모델 학습, 서버 설정처럼 실제 터미널에서 끝까지 수행하는 과제를 평가 대상으로 설명합니다. 구성은 과제 데이터셋과 실행 하니스 두 부분으로 나뉩니다.

현재 README는 약 100개 과제를 가진 beta 상태라고 밝히며, 새로운 사용자는 Terminal-Bench 2.0 실행에 Harbor 프레임워크를 확인하라고 안내합니다. README에 적힌 기본 설치는 uv tool install terminal-bench 또는 pip install terminal-bench이고, 실행 진입점은 tb입니다.

GitHub API에서 2026년 9월 14일 확인한 canonical 저장소는 harbor-framework/terminal-bench-1입니다. 당시 별 2,578개, 주 언어 Python, Apache-2.0 라이선스로 표시되었습니다. 별 수와 라이선스는 공개 활동과 사용 조건을 보여 줄 뿐, 내 업무에서의 성공률을 보증하지 않습니다.

한계와 주의사항은 무엇인가요?

  • beta 데이터셋의 과제 수와 분야가 조직의 업무를 충분히 대표하지 않을 수 있습니다. 국내 문서·사내 시스템·한국어 지시문이 필요한 업무는 별도 과제로 다시 만들어야 합니다.
  • 테스트 스크립트가 통과해도 변경 내용의 유지보수성, 비용, 처리 시간, 보안, 사용자 만족까지 확인한 것은 아닙니다.
  • Docker 샌드박스는 평가 범위를 제한하는 장치이지 운영 환경의 권한·네트워크 정책·데이터 보관을 자동으로 대신하지 않습니다.
  • Terminal-Bench 2.0과 Harbor의 관계, 데이터셋 버전, 어댑터 지원 범위가 바뀔 수 있으므로 실행 전에 공식 문서의 현재 안내를 다시 읽어야 합니다.
  • 이 저장소에서 Terminal-Bench를 직접 실행하거나 과제별 성공률·비용을 측정한 것은 아닙니다. 아래 내용은 공식 저장소와 문서가 설명하는 범위에 대한 판단입니다.

처음에는 무엇을 시험할까요?

  1. 실제 업무와 비슷한 터미널 과제 5개를 고르고, 각 과제의 성공 조건과 사람이 확인할 항목을 적습니다.
  2. 데이터셋 버전·모델·에이전트·실행 환경·시간 제한을 고정하고 한 번에 한 요소만 바꿉니다.
  3. tb run으로 정상 완료뿐 아니라 설치 실패, 테스트 실패, 시간 초과와 되돌리기 어려운 명령도 기록합니다.
  4. 점수 옆에 실행 시간·비용·재시도 횟수·권한 요청·사람 검수 결과를 함께 남깁니다.
  5. 평가 과제가 실제 업무를 충분히 대표하지 못하면 내부 과제를 추가한 뒤, 공식 과제와 섞지 말고 데이터셋 버전을 따로 관리합니다.

에이전트가 어떤 도구를 쓰고 어디서 사람의 확인을 받는지까지 함께 설계하려면 AI 에이전트 설정과 활용 과정의 실습 범위를 확인해 보세요. Terminal-Bench는 그 설계를 대신하는 제품이 아니라, 정한 작업 조건을 반복해서 비교하기 위한 평가 틀에 가깝습니다.

참고한 공식 자료