AI 코딩 모델을 검색하면 SWE-bench, Terminal-Bench, ProgramBench 같은 이름이 계속 나옵니다.
문제는 모두 숫자로 표시되기 때문에 같은 시험처럼 보인다는 점입니다.
하지만 세 벤치마크는 묻는 질문 자체가 다릅니다.
SWE-bench
→ 기존 코드베이스의 실제 이슈를 고칠 수 있는가?
Terminal-Bench
→ 터미널 환경에서 여러 단계 작업을 끝낼 수 있는가?
ProgramBench
→ 프로그램을 처음부터 다시 만들어낼 수 있는가?
이 차이를 모르면 점수를 비교해도 의미를 잘못 해석할 수 있습니다.
SWE-bench: 이미 있는 프로젝트를 고치는 시험
SWE-bench는 실제 GitHub 저장소에서 수집한 이슈를 기반으로 모델이 코드를 수정할 수 있는지 평가합니다.
전형적인 형태는 이렇습니다.
Repository
+
Issue description
+
Existing tests
↓
Agent가 코드 수정
↓
Tests / patch evaluation
즉 소프트웨어 엔지니어가 실제로 하는 기존 코드 읽기 → 문제 파악 → 수정 → 테스트에 가깝습니다.
2026년 9월에는 SWE-bench Multimodal v2도 공개됐습니다. 이 버전은 480개 재현 가능한 작업을 포함하고, 버그 스크린샷·디자인 mockup·시각적 오류처럼 텍스트만으로 설명하기 어려운 정보도 다룹니다.
프론트엔드나 GUI 작업에서는 특히 의미가 있습니다.
Terminal-Bench: 코드를 쓰는 것보다 환경을 다루는 시험
Terminal-Bench는 Linux terminal 환경에서 에이전트가 실제 작업을 수행하도록 합니다.
여기서는 단순 함수 구현보다 다음과 같은 능력이 중요합니다.
- 명령어 실행
- 패키지 설치
- 파일 탐색
- 서버 설정
- 빌드와 디버깅
- 여러 단계의 환경 조작
Artificial Analysis의 Coding Agent Index v1.5는 Terminal-Bench 4.0의 66개 더 어려운 터미널 작업을 사용합니다.
즉 Terminal-Bench는 이런 질문에 가깝습니다.
AI가 코드를 “알고” 있는가?
보다
AI가 실제 개발 환경에서 끝까지 일을 수행할 수 있는가?
ProgramBench: 소스 없이 프로그램을 다시 만드는 시험
ProgramBench는 훨씬 독특합니다.
모델에게 소스코드를 주지 않습니다.
대신:
Compiled binary
+
Documentation
↓
프로그램 행동을 관찰
↓
새 코드베이스를 처음부터 작성
↓
Hidden behavioral tests
의 방식으로 평가합니다.
ProgramBench에는 200개 작업이 있으며, 2026년 9월 기준으로도 완전 해결률은 매우 낮습니다. 즉 현재 frontier 모델에게도 상당히 어려운 시험입니다.
흥미로운 점은 초기 실험에서 모델들이 인터넷에서 원본 저장소를 찾아오거나 패키지 매니저를 통해 기존 구현을 가져오는 식의 shortcut을 사용했다는 점입니다. 그래서 최종 benchmark는 이런 우회 경로를 제한합니다.
이 자체가 AI 평가에서 중요한 문제를 보여줍니다.
테스트를 통과했다고 해서 반드시 의도한 능력을 사용한 것은 아닙니다.
세 벤치마크를 한 표로 보면
| Benchmark | 시작점 | 핵심 능력 | 실제 업무와 비슷한 장면 |
|---|---|---|---|
| SWE-bench | 기존 repo + issue | 코드 이해와 수정 | 버그 수정, PR 작업 |
| Terminal-Bench | 터미널 환경 + task | 도구 사용과 실행 | DevOps, 디버깅, 환경 설정 |
| ProgramBench | binary + docs | 전체 프로그램 설계 | reverse engineering, 재구현 |
따라서 “모델 A가 코딩 70점, 모델 B가 60점”이라는 식으로 섞어 말하면 안 됩니다.
어떤 시험의 70점인지가 먼저입니다.
CodeBridge Mini Lab: 같은 기능을 세 방식으로 시켜보기
직접 차이를 체감하는 작은 실험도 만들 수 있습니다.
예를 들어 간단한 CLI Todo 앱 하나를 준비합니다.
실험 A: SWE-bench 스타일
기존 Todo 앱에서 완료된 항목 삭제가 실패합니다.
버그를 수정하고 regression test를 추가하세요.
실험 B: Terminal-Bench 스타일
프로젝트를 실행하고 실패 원인을 찾으세요.
필요한 dependency를 설치하고 테스트를 모두 통과시키세요.
실험 C: ProgramBench 스타일
원본 소스는 숨기고 실행 파일과 사용법만 줍니다.
$ todo add "write article"
$ todo list
1. write article
그리고 같은 동작을 하는 프로그램을 새로 만들게 합니다.
같은 “Todo 앱”이지만 필요한 능력이 전혀 다릅니다.
어떤 벤치마크를 보면 좋을까?
AI 코딩 도구로 실제 repo를 수정하고 싶다면
SWE-bench 계열이 가장 직관적입니다.
AI Agent가 개발 환경을 얼마나 잘 다루는지 궁금하다면
Terminal-Bench가 더 가깝습니다.
모델의 장기 설계와 프로그램 이해 능력을 보고 싶다면
ProgramBench가 흥미롭습니다.
그리고 실제 제품을 고를 때는 하나만 보는 것보다 내 업무에 가까운 평가를 우선하고 다른 평가를 보조적으로 보는 방식이 좋습니다.
결론: “코딩 잘하는 AI”라는 한 문장을 쪼개야 합니다
코딩 능력은 하나가 아닙니다.
코드 생성
코드 이해
버그 수정
환경 조작
테스트 실행
장기 작업
프로그램 설계
모델이 어느 영역에 강한지를 봐야 실제 사용성과 연결됩니다.
벤치마크 이름을 외우는 것이 목적이 아니라, 각 시험이 어떤 개발 장면을 흉내 내는지 이해하는 것이 핵심입니다.