코딩 에이전트(Coding agent)가 한 벤치마크(Benchmark)에서는 높은 점수를 받을 수 있지만, 여러분의 저장소(Repository)에서는 실망스러운 결과를 보일 수도 있습니다.

이것이 반드시 모순되는 것은 아닙니다. SWE-bench, Terminal-Bench, 그리고 SWE-Atlas는 소프트웨어 엔지니어링(Software engineering)에 대해 서로 다른 질문을 던집니다. 하나는 실제 저장소의 이슈(Issue)를 해결하는 데 집중합니다. 다른 하나는 터미널 샌드박스(Terminal sandbox)에서의 엔드 투 엔드(End-to-end) 작업을 테스트합니다. 세 번째는 엔지니어링 루프(Engineering loop)를 코드베이스 이해(Codebase understanding), 테스트 작성(Test writing), 그리고 리팩터링(Refactoring)으로 나눕니다.

실질적인 교훈은 간단합니다. 벤치마크 점수를 보편적인 순위로 취급하지 마십시오. 줄이고자 하는 실패 모드(Failure mode)에 맞춰 벤치마크를 선택하십시오.

평가 기준

저는 다섯 가지 기준을 바탕으로 세 가지 벤치마크 제품군을 비교했습니다:

1. 주요 작업 (Primary task): 에이전트에게 실제로 요구되는 작업은 무엇인가?
2. 환경 및 도구 (Environment and tools): 저장소에서 작동하는가, 일반 터미널에서 작동하는가, 아니면 둘 다인가?
3. 채점 신호 (Grading signal): 무엇을 성공으로 간주하는가: 테스트, 루브릭(Rubric), 또는 다른 검증기(Verifier)인가?
4. 드러나는 점 (What it reveals): 점수가 개발자 워크플로(Developer workflow)의 어느 부분을 조명하는가?
5. 오해의 소지가 있는 점 (Where it can mislead): 수치로부터 무엇을 추론해서는 안 되는가?

이 비교는 2026년 7월 21일 기준으로 유지 관리자들의 공개 문서 및 논문을 확인하여 작성된 문서 기반 비교입니다. 저는 세 가지 모두에 대해 공통된 모델, 프롬프트(Prompt), 또는 하네스(Harness)를 실행하지 않았으므로, 이것은 새로운 직접 비교(Head-to-head) 벤치마크는 아닙니다.

빠른 비교

1. SWE-bench: 이슈 해결 테스트

SWE-bench는 GitHub에서 수집된 실제 소프트웨어 이슈, 코드베이스(Codebase), 그리고 예상되는 패치(Patch)로 시작합니다. 에이전트는 해당 이슈를 해결하는 변경 사항을 생성해야 합니다. 공식 프로젝트 설명에 따르면 Docker 기반의 재현 가능한 평가(Reproducible evaluation)와 SWE-bench, Lite, Verified, Multimodal을 포함한 여러 데이터셋을 제공합니다.

이러한 특징 덕분에 SWE-bench는 코딩 에이전트에게 다음과 같은 유용한 첫 번째 질문을 던집니다:

이슈와 저장소(Repository)가 주어졌을 때, 타당한 패치를 통해 기존 테스트를 통과시킬 수 있는가?

엔지니어링 팀의 관점에서 이는 버그 수정이나 작은 기능 요청(Feature requests)이 쌓인 백로그(Backlog)를 분류(Triaging)하는 작업과 가장 유사합니다. 또한 이는 비교적 구체적인 성공 조건입니다. 패치는 단순히 서술형 답변으로 판단되는 것이 아니라 테스트를 통해 평가됩니다.

점수가 알려주는 것

높은 결과는 평가된 모델-에이전트 결합 설정(Model-plus-agent setup)이 해당 데이터셋에서 이슈를 해결하는 패치를 생성할 수 있을 만큼 충분한 저장소 컨텍스트(Repository context)를 탐색할 수 있다는 증거입니다. 이는 동일한 데이터 분할(Split), 스캐폴드(Scaffold), 예산(Budget), 그리고 평가 프로토콜 하에서 시스템들을 비교하는 데 유용합니다.

점수가 알려주지 않는 것

패스(Passing)한 패치가 에이전트가 다음을 수행했음을 증명하는 것은 아닙:

• 수정하기 전에 시스템을 깊이 있게 조사했는지
• 올바른 새로운 테스트를 작성했는지
• 리팩터링(Refactor) 후 모든 오래된 호출 지점(Call site)을 제거했는지
• 귀하의 리뷰 기준에 부합하는 유지보수 가능한 변경을 생성했는지
• 비공개된, 더 최신의, 또는 구조가 다른 저장소에서도 동일하게 동작할지

또한 측정 건강성(Measurement-health)에 대한 주의 사항이 있습니다. 벤치마크 오염(Contamination)과 암기(Memorization)는 SWE-bench 스타일의 평가에서 활발히 논의되는 우려 사항입니다. 데이터셋 버전과 보고 날짜를 각주가 아닌 결과의 일부로 취급하십시오.

2. Terminal-Bench: 터미널 작업 테스트

Terminal-Bench는 실제 터미널 환경에서 에이전트를 평가합니다. 작업 스위트(Task suite)에는 코드 컴파일, 모델 학습, 서버 설정, 시스템 관리 및 보안 지향적 작업 등이 포함됩니다. 이 프로젝트는 두 개의 분리 가능한 요소로 구성됩니다: 작업 데이터셋과 에이전트를 샌드박스(Sandboxed) 터미널에 연결하는 실행 하네스(Execution harness)입니다.

각 작업은 영어 지침(Instruction), 테스트 스크립트(Test script), 그리고 참조 솔루션(Reference solution)을 포함합니다. 이러한 구조는 에이전트가 단일 패치(Patch)를 생성하는 것이 아니라 일련의 동작(Sequence of actions)을 수행해야 하므로 가치가 있습니다. 이는 명령 선택(Command selection), 환경 설정(Environment setup), 디버깅 루프(Debugging loops), 그리고 운영 지속성(Operational persistence)에서의 실패를 드러낼 수 있습니다.

점수가 알려주는 것

에이전트가 다음과 같은 작업을 수행해야 할 때, Terminal-Bench는 이슈(Issue) 중심의 벤치마크보다 더 나은 관점을 제공합니다:

• 의존성(Dependencies) 설치 또는 구성;
• 소프트웨어 컴파일 또는 실행;
• 파일 및 프로세스 조작;
• 로그(Logs)를 통한 실패 진단; 또는
• 다단계 CLI 워크플로(Workflow) 완료.

이는 터미널(Terminal), CI 러너(CI runner), 컨테이너(Container), 또는 원격 개발 환경(Remote development environment)에서 작동하는 에이전트에게 특히 유의미합니다.

점수가 알려주지 않는 것

터미널 작업은 장기적인 코드베이스 관리(Codebase stewardship) 능력을 입증하지 않고도 성공적으로 완료될 수 있습니다. 서버 설정(Server-setup)이나 시스템(Systems) 작업을 통과했다고 해서 에이전트가 대규모 애플리케이션을 이해하거나, 강력한 어설션(Assertions)을 포함한 회귀 테스트(Regression tests)를 작성하거나, 광범위한 리팩터링(Refactor)을 완료할 수 있음을 의미하지는 않습니다.

환경 또한 매우 중요합니다. 에이전트 어댑터(Agent adapters), 도구 권한(Tool permissions), 시간 제한(Time limits), 동시성(Concurrency), 모델 버전(Model version), 그리고 컨테이너 이미지(Container images)가 결과에 영향을 미칠 수 있습니다. 이러한 조건들을 고려하지 않고 두 숫자를 비교하는 것은 대개 모델뿐만 아니라 구성(Configurations)을 비교하는 것이 됩니다.

3. SWE-Atlas: 엔지니어링 루프 테스트

SWE-Atlas는 모든 것을 이슈 해결(Issue resolution)로 축소하는 대신, 소프트웨어 개발 주기(Software development cycle) 전반에 걸친 상호 보완적인 역량을 측정하도록 설계되었습니다. 공개 리포지토리(Public repository)와 Scale의 개요에 따르면 세 가지 트랙(Tracks)을 설명합니다:

• Codebase QnA: 런타임 분석(Runtime analysis)과 다중 파일 추론(Multi-file reasoning)을 통해 복잡한 리포지토리(Repository)를 이해하기;
• Test Writing: 중요한 동작에 적합한 테스트를 식별하고 리포지토리 컨벤션(Repository conventions)을 따르기;
• Refactoring: 동작을 유지하면서 코드를 재구조화하고, 소비자(Consumers)를 업데이트하며, 오래된 코드(Stale code)를 정리하고, 문서(Documentation)를 일치시키기.

이러한 프레임워크(Framing)는 패치 벤치마크(patch benchmarks)가 종종 암묵적으로 남겨두는 질문에 대해 SWE-Atlas를 유용하게 만들어 줍니다.

에이전트가 단순히 기존 테스트를 통과하는 패치(patch)를 생성하는 것을 넘어, 코드 변경과 관련된 조사(investigative) 및 유지보수(maintenance) 작업을 수행할 수 있는가?

Scale의 개요에 따르면, 이 스위트(suite)는 세 가지 트랙에 걸쳐 284개의 태스크(tasks)를 포함하고 있습니다. Codebase QnA 트랙은 실제 저장소(repositories)와 태스크별 루브릭(rubrics)을 사용합니다. Test Writing 트랙은 에이전트가 단순히 얼마나 많은 테스트 파일을 추가하느냐가 아니라, 테스트가 의미 있는 동작을 포착하는지에 집중합니다. Refactoring 트랙은 테스트 보존(test preservation) 외에도 다중 파일 변경(multi-file changes)과 완전성(completeness)을 평가합니다.

점수가 알려주는 것

SWE-Atlas는 이슈 해결(issue resolution) 측면에서 비슷해 보이는 에이전트들의 서로 다른 약점을 드러낼 수 있습니다:

• 얕은 저장소 탐색 (shallow repository exploration)
• 그럴듯하게 들리지만 실행 시점의 증거(runtime evidence)가 부족한 답변
• 검증(assertion)을 너무 적게 하면서 통과되는 테스트
• 호출 지점(call sites)을 누락하거나 데드 코드(dead code)를 남기는 리팩터링(refactors)

이러한 점은 리뷰(review), 마이그레이션(migration), 또는 유지보수(maintenance) 워크플로우를 구축하는 팀에게 SWE-Atlas가 SWE-bench를 보완하는 강력한 도구가 되게 합니다.

점수가 알려주지 않는 것

SWE-Atlas는 완전한 프로덕션 시뮬레이션(production simulation)은 아닙니다. 이 스위트의 태스크, 저장소, 루브릭, 판사 모델(judge model), 그리고 하네스(harness)는 여전히 측정 기준을 정의합니다. 루브릭으로 채점되는 태스크는 평가자 편차(evaluator variance)를 유발할 수 있으며, 고정된 태스크 세트를 가진 벤치마크는 모든 언어, 아키텍처, 보안 정책 또는 조직적 워크플로우를 대변할 수 없습니다.

또한 이 스위트는 가장 확립된 이슈 해결 벤치마크들에 비해 더 최신이며 규모가 작습니다. 이를 확정적인 업계 표준 순위가 아닌, 진단 신호(diagnostic signal)로 사용하십시오.

가장 중요한 차이점: 모델(model) 대 에이전트 설정(agent setup)

이러한 벤치마크들은 기본 모델(base model) 이상의 것을 측정합니다. 이들은 에이전트 스캐폴드(agent scaffold), 도구(tools), 프롬프트(prompts), 권한(permissions), 컨텍스트 제한(context limits), 그리고 실행 환경(execution environment)을 통해 작동하는 모델을 측정합니다.

리더보드(leaderboard) 표에서는 이러한 차이를 놓치기 쉽습니다. 동일한 모델이라도 일반적인 하네스(harness)를 사용할 때보다 네이티브 코딩 에이전트 스캐폴드(scaffold)를 사용할 때 더 효과적으로 탐색할 수 있습니다. 반대로, 고도로 최적화된 스캐폴드에서 얻은 벤치마크 결과가 최소한의 내부 래퍼(wrapper)를 통해 얻게 될 결과를 예측하지 못할 수도 있습니다.

결과를 읽을 때는 최소한 다음 사항들을 기록해야 합니다:

• 모델 및 정확한 버전;
• 에이전트(agent) 또는 스캐폴드(scaffold);
• 벤치마크 이름, 스플릿(split), 및 버전;
• 토큰(token), 시간(time), 및 스텝(step) 예산;
• 도구 권한(tool permissions) 및 네트워크 정책(network policy);
• 시도 횟수(number of trials) 및 통과(pass) 정의;
• 그리고 채점 방식이 테스트 기반(test-based), 루브릭 기반(rubric-based), 또는 판사 모델 기반(judge-model-based)인지 여부.

이는 최종적인 "완료(done)" 메시지를 신뢰하기보다 트레이스(trace)를 유지하는 것과 맞먹는 벤치마크 상의 대응 방식입니다. 저는 코딩 에이전트의 트레이스를 회귀 테스트로 전환하는 것에서도 동일한 원칙을 사용합니다.

실질적인 의사결정 규칙

위임하고자 하는 작업에 맞는 벤치마크를 선택하세요:

• 백로그 이슈 해결 (Backlog issue resolution): SWE-bench 스타일의 평가로 시작한 다음, 패치 품질(patch quality)과 숨겨진 테스트 동작(hidden-test behavior)을 검사하세요.
• 터미널 및 인프라 자동화 (Terminal and infrastructure automation): 실제 권한 및 네트워크 모델을 사용하여 Terminal-Bench 스타일의 작업을 사용하세요.
• 유지보수 중심의 엔지니어링 (Maintenance-heavy engineering): SWE-Atlas 스타일의 코드베이스 Q&A, 테스트 작성, 그리고 리팩터링(refactoring) 작업을 추가하세요.
• 장기 실행 에이전트 (Long-running agents): 단 한 번의 성공적인 실행이 아니라 반복된 시도(repeated trials)를 평가하세요. 신뢰성(Reliability)은 최고 성능(peak capability)만큼 중요합니다.
• 프로덕션 배포 (Production rollout): 자체 리포지토리(repositories)에서 비공개 홀드아웃 세트(holdout set)를 구축하세요. 공개 벤치마크는 보정 도구(calibration tool)일 뿐, 내부 수락 테스트(acceptance tests)를 대체할 수는 없습니다.

하나의 벤치마크에 다섯 가지 질문 모두에 답하라고 요구하지 마세요. 컴팩트한 내부 평가(internal eval)는 하나의 이슈 수정, 하나의 디버깅 작업, 하나의 코드베이스 설명, 하나의 테스트 작성 작업, 그리고 하나의 리팩터링 작업을 결합할 수 있으며, 각 작업은 명확한 루브릭(rubric)과 검토 가능한 트레이스(trace)를 가져야 합니다.

지금 해야 할 일

1. 버그 수정 (bug fixes), 의존성 업그레이드 (dependency upgrades), 또는 테스트 유지보수 (test maintenance)와 같이 위임하고자 하는 실제 워크플로우 (workflow) 하나를 선택하세요.
2. 이를 가장 유사한 벤치마크 관점(lens)에 매핑하세요: 이슈 해결 (issue resolution), 터미널 실행 (terminal execution), 또는 엔지니어링 루프 품질 (engineering-loop quality).
3. 실제로 사용할 에이전트 스캐폴드 (agent scaffold) 및 권한과 정확히 일치하는 소규모 프라이빗 홀드아웃 (private holdout)을 다시 실행하세요.
4. 완료 여부 그 이상을 점수화하세요: 테스트 품질 (test quality), 디프 범위 (diff scope), 조사 증거 (investigation evidence), 정리 (cleanup), 비용 (cost), 지연 시간 (latency), 그리고 리뷰어의 재작업 (reviewer rework)을 포함하세요.
5. 각 작업을 최소 3번 반복하세요. 통과율 (pass rate)과 일관성 (consistency)을 별도로 추적하세요.
6. 모든 결과 옆에 벤치마크 버전, 모델 버전, 그리고 하네스 (harness) 설정을 기록하세요.

장기 실행 작업의 경우, 컨텍스트 전략 (context strategy) 또한 기록할 가치가 있는 또 다른 변수입니다. 저의 코딩 에이전트를 위한 컨텍스트 압축 비교 (context-compaction comparison for coding agents)에서는 왜 긴 컨텍스트 창 (context window)만으로는 지속 가능한 작업 상태 (task state)를 보장할 수 없는지를 다룹니다.

솔직한 한계점

이 비교는 통제된 실행이 아닌 공개 문서와 연구 설명을 사용했습니다. 벤치마크 버전과 리더보드 (leaderboards)는 변경됩니다. 작업들은 서로 대체 가능하지 않으며, 점수를 하나의 "최고의 코딩 에이전트" 수치로 평균 내어서는 안 됩니다. 일부 평가 세부 사항, 특히 스캐폴드 (scaffolds) 및 심사 모델 (judge models)과 관련된 부분은 결과에 실질적인 영향을 미칠 수 있습니다. 마지막으로, 벤치마크를 통과하는 것은 특정 프로토콜 하에서의 능력에 대한 증거일 뿐, 안전한 자율적 운영 (autonomous production) 동작에 대한 증명은 아닙니다.

출처

• SWE-bench 공식 개요 (official overview)
• Terminal-Bench 리포지토리 및 작업 형식 (repository and task format)
• Terminal-Bench 논문 (paper)
• SWE-Atlas 리포지토리 (repository)
• Scale의 SWE-Atlas 개요 (overview from Scale)
• SWE-Atlas 논문 (paper)

토론

여러분의 코딩 에이전트 (coding-agent) 워크플로에서 어떤 벤치마크 신호가 가장 예측력이 높았나요: 이슈 해결 (issue resolution), 터미널 실행 (terminal execution), 아니면 엔지니어링 루프 (engineering-loop) 품질인가요?