모델 발표표에 SWE-bench와 Terminal-Bench 점수가 나란히 있어도 시험 과제와 채점 기준은 다릅니다. SWE-bench 공식 리더보드 안에서도 Verified, Lite, Multilingual은 서로 다른 문제 묶음입니다. 이름을 줄여 ‘코딩 점수’로 묶으면 무엇을 풀었는지가 사라집니다.
SWE-bench와 Terminal-Bench가 푸는 과제
SWE-bench의 원본 설명과 Terminal-Bench 2.0 논문은 입력 과제와 결과 확인 방식을 각각 제시합니다. 아래는 2026년 10월 15일 확인한 두 자료의 평가 범위입니다.
| 시험 | 맡기는 작업 | 완료를 확인하는 방식 |
|---|---|---|
| SWE-bench | GitHub 이슈와 해당 시점 코드베이스를 받아 수정 패치 작성 | 패치를 적용한 뒤 지정 테스트 실행 |
| Terminal-Bench 2.0 | 정해진 컴퓨터 환경에서 소프트웨어 작업·시스템 설정·데이터 처리 등 수행 | 작업 후 환경의 상태를 과제별 테스트로 검사 |
두 시험의 백분율은 각자의 과제 집합과 실행 결과를 바탕으로 집계됩니다. 서로 다른 시험의 점수만으로 도구의 우열을 매기면 시험 범위의 차이를 건너뛰게 됩니다.
SWE-bench의 해결 판정에는 문제를 고쳤는지 보는 FAIL_TO_PASS와 기존 기능을 망가뜨리지 않았는지 보는 PASS_TO_PASS가 함께 쓰입니다. 오픈AI의 SWE-bench Verified 소개는 두 테스트 묶음을 모두 통과해야 완전 해결로 판정한다고 설명합니다. Verified는 사람이 문제 설명과 테스트를 점검해 선별한 문제셋입니다. 지정 테스트의 검사 범위를 확인한 뒤, 보안과 변경 코드의 유지보수성도 채택 전에 검토합니다.
버전을 바꾸면서 시험 자체를 고치기도 합니다. Terminal-Bench 2.1 공지에 따르면 제작진은 2.0의 89개 과제 중 28개를 고쳤습니다. 외부 의존성의 변화, 자원 예산 불일치, 지시문과 테스트의 불일치가 수정 이유였습니다. 버전이 바뀐 전후 점수에는 시험을 고친 영향도 섞입니다.
모델과 함께 시험받는 하네스와 예산
에이전트 하네스와 평가 하네스는 맡는 일이 다릅니다. 에이전트 하네스는 모델에 제공할 도구와 문맥, 호출·수정 순서를 관리합니다. 평가 하네스는 과제 환경을 준비하고 결과를 테스트·채점합니다. Terminal-Bench 2.0 논문도 상호작용형 평가에서 모델과 에이전트의 영향을 분리하기 어렵다고 설명하고, 모델 비교를 위해 단일 터미널 도구를 쓰는 Terminus 2를 제시합니다.
모델별 차이를 보려면 같은 에이전트 버전과 설정에서 모델을 바꿉니다. 도구를 선택하는 평가에서는 각 도구의 기본 기능까지 포함한 조합을 같은 업무에 투입합니다. 이때 얻은 차이는 도구·모델 조합의 결과로 읽습니다.
점수와 함께 확인할 항목은 문제셋 버전, 실제 과제 목록, 모델 ID와 추론 설정, 에이전트 버전입니다. 제공한 프로젝트 문서, 파일 편집·검색 도구, 네트워크와 권한도 입력 조건입니다. 같은 에이전트 이름을 썼더라도 CPU·메모리, 제한시간, 토큰·비용 상한이 달라질 수 있습니다.
이 조건을 찾을 수 없는 결과는 ‘실행 조건 미확인’으로 남깁니다. 자체 평가의 예산은 실제로 맡길 업무에서 허용할 시간과 비용으로 정합니다.
pass@k, 반복 평균, 오류 재시도 구분
pass@k는 한 과제에서 생성한 후보 k개 중 하나 이상이 테스트를 통과할 확률을 다루는 지표입니다. HumanEval의 공식 평가 코드는 과제별 표본 수와 통과 수로 값을 추정한 뒤 과제 전체의 평균을 냅니다. pass@1은 후보 한 개의 통과를 다루며, 여러 표본으로 추정할 때는 과제별 통과 비율을 평균합니다.
pass@5의 ‘5’는 다섯 후보 모두의 성공을 뜻하지 않습니다. 통과 후보가 있어도 실제 작업에서 그것을 골라 내려면 별도의 선택 과정이 필요합니다. 같은 조건의 독립 실행 결과를 모두 평균내는 방법과, 여러 시도 중 통과한 결과 하나를 택하는 방법은 집계 기준부터 다릅니다.
에이전트의 한 시도에는 여러 모델 호출, 도구 실행, 테스트와 수정이 들어갈 수 있습니다. Terminal-Bench 2.0 논문의 실행 분석에서도 한 과제를 수행하는 동안 호출과 도구 사용이 반복됩니다. Harbor 실행 안내는 시도를 에이전트가 한 과제를 수행하는 단위로 정의하며 반복 횟수 -k와 재시도 -r를 구분합니다. 반복 횟수를 늘렸다는 설정만으로 그 결과를 pass@k라고 부를 수는 없으며, 실제 집계 방식을 함께 읽습니다.
오류 뒤의 재시도도 별도 기록입니다. 처음 시도가 왜 멈췄는지, 다시 시작할 때 어떤 상태를 이어받았는지, 추가 비용이 얼마였는지를 남깁니다. 유리한 결과 하나만 남기면 같은 도구를 다시 쓸 때의 실패 빈도와 비용을 읽기 어렵습니다.
같은 저장소 과제로 비교하는 평가 절차
자체 평가에서는 자주 맡길 업무를 과제로 고릅니다. 재현 가능한 버그 수정, 작은 기능 추가, 기존 동작을 보존하는 리팩터링처럼 작업 종류를 나눕니다. 아래 절차는 평가를 시작할 때 쓸 수 있는 제안이며, 실제 코딩 도구를 실행해 얻은 결과는 없습니다.
먼저 시작 커밋, 요청문, 수락 조건, 의존성 잠금파일과 실행 환경을 고정합니다. 각 후보는 같은 상태의 작업 사본에서 시작하며, 시작 상태의 테스트 결과도 기록합니다. 채점용 테스트를 입력에서 제외하더라도 테스트가 요구하는 동작은 요청문에 적습니다. 숨겨 둔 새 요구사항으로 결과를 탈락시키지 않도록 요구조건과 검사를 미리 맞춥니다.
다음으로 제한시간·비용 상한, 사람 개입 범위와 오류 재시도 기준을 정합니다. 실행은 새 세션과 독립 작업 사본에서 반복합니다. 이전 시도의 패치·대화·메모리를 다음 시도에 넘기지 않습니다. 반복 수는 예산에 맞춰 정하되 성공한 시도만 고르지 않고 모든 결과를 남깁니다. 적은 반복에서 보인 차이는 추가 평가가 필요한 신호로 다룹니다.
에이전트가 멈추면 사람이 코드를 고치기 전에 패치와 로그를 저장합니다. 기능·회귀 검사 결과와 요청 조건 충족 여부를 기록하고, 사람이 검토하거나 코드를 고치는 시간은 따로 잽니다. 테스트가 실행되지 않았거나 검증기가 실패한 결과는 통과로 넣지 않습니다. 채점기의 오류를 고쳤다면 영향을 받는 모든 후보를 같은 기준으로 다시 채점합니다.
통과율과 함께 남길 수정량·비용·시간
평가 기록은 ‘자동 완료’, ‘사람 수정 후 채택’, ‘미채택’을 구분합니다. 사람이 패치를 고치지 않은 상태로 사전에 정한 검사를 통과하고, 검토에서도 채택한 경우를 자동 완료로 기록합니다. 요구 누락·기능 오류·예산 소진·환경 장애·검증기 오류도 나누어 적으면, 다음 실행에서 무엇을 다시 볼지 알 수 있습니다.
Harbor의 오류 분류도 에이전트의 예산 소진과 샌드박스·모델 공급자·검증기 실패를 구분하고 서로 다른 채점·재시도 정책을 둡니다. 자체 평가에서는 성공 건수와 분모를 함께 쓰고, 분모에서 뺀 실행이 있다면 원인과 원본 기록을 남깁니다.
아래 양식은 실행 한 번당 복사해 채우는 빈 기록입니다. 결과를 합산하기 전에 사람의 수정 전 패치와 후속 수정 내역을 각각 보관합니다.
과제·작업 종류:
시작 커밋 / 요청문·수락 조건 파일:
도구·버전 / 모델 ID·설정 / 실행일:
입력 문서·도구·권한 / 환경 / 예산:
실행 ID / 독립 반복 번호:
재시도라면 원본 실행 ID·사유:
기능·회귀 검사 / 요구조건 판정 / 실패 원인:
사람 수정 전 패치·테스트 로그 경로:
결과: 자동 완료 / 사람 수정 후 채택 / 미채택
사람 검토 시간 / 수정 시간:
사람 수정 diff 경로 / 변경 파일·줄 수 / 수정 이유:
전체 경과시간(대기 포함) / 에이전트 실행시간:
토큰 사용량 / 실제 청구액·통화 / 확인 불가 항목:
추정·구독 배분 비용과 계산 가정:비용에는 실패와 재시도에 쓴 금액도 포함합니다. API 청구액, 실행 환경 비용, 구독료를 평가용으로 배분한 비용은 구분하고, 알 수 없는 값은 0 대신 ‘미확인’으로 둡니다. 토큰 수는 사용량 기록이며 청구액과 별도 항목입니다. 성공 건당 비용을 계산할 때는 전체 시도 비용을 성공 건수로 나누되, 성공이 없으면 계산 불가로 적습니다.
시간은 대기까지 포함한 전체 경과시간, 에이전트 실행시간, 사람 검토·수정 시간을 나누어 잽니다. 이 값들은 일부가 겹칠 수 있으므로 전부 더해 총시간으로 만들지 않습니다. 사람 수정량도 원래 에이전트 패치와 분리해 저장합니다. 자동 포맷·생성파일·잠금파일 변경이 줄 수에 섞였는지 적고, 작은 수정량만으로 품질을 판정하지 않습니다.
최종 판단은 업무 종류별로 내립니다. 버그 수정에서는 통과가 안정적이어도 기능 추가에서 사람 수정이 반복되면 맡길 범위를 나눌 근거가 생깁니다. 평가한 저장소와 예산 안에서 채택 가능한 결과가 얼마나 자주 나왔는지, 검토·수정에 얼마가 들었는지가 도구 선택의 기준입니다. 작은 과제 묶음의 결과를 전체 제품 순위로 넓히지 않습니다.
자료 확인 기준: 2026년 10월 15일. 벤치마크 버전과 실행 정책은 바뀔 수 있습니다.
AI 코딩 도구 9종 가격 가이드: 무료 한도와 추가 요금 (2026년 10월)
Claude·Cursor·Codex 등 AI 코딩 도구 9종의 요금을 2026년 10월 15일 공식 자료로 확인했습니다. 무료 한도, 월·연 결제, 팀 청구 단위와 구독 외 사용료를 구분합니다.