DeepSWE: 오염 없는 장기 코딩 에이전트 벤치마크
DeepSWE: A contamination-free benchmark for long-horizon coding agents
TL;DR Highlight
기존 SWE-bench의 데이터 오염 및 검증 오류 문제를 해결하기 위해 처음부터 새로 만든 코딩 에이전트 벤치마크로, GPT-5.5가 70%로 1위를 차지하고 모델 간 성능 격차가 훨씬 뚜렷하게 드러난다.
Who Should Read
AI 코딩 에이전트를 실무에 도입하거나 평가 중인 개발자 및 ML 엔지니어. 특히 기존 벤치마크 결과와 실제 체감 성능 간의 괴리를 경험한 사람에게 유용하다.
Core Mechanics
- DeepSWE는 기존 GitHub 이슈나 PR을 재활용하지 않고 태스크를 처음부터 직접 작성해서, 모델이 사전학습 중에 정답을 본 적이 없도록 설계했다. 이른바 '벤치마크 오염(contamination)' 문제를 원천 차단한 것이다.
- 기존 최고 수준 벤치마크인 SWE-bench Pro를 감사해봤더니 검증기(verifier)가 에이전트 출력을 잘못 채점하는 비율이 거짓 양성(false positive) 8%, 거짓 음성(false negative) 24%에 달했다. DeepSWE는 구현 방식이 아닌 소프트웨어 동작(behavior)을 직접 테스트하는 검증기를 손으로 직접 작성해 이 문제를 해결했다.
- 프롬프트 길이는 SWE-bench Pro(평균 4,614자)보다 절반 수준인 2,158자로 짧지만, 실제 해결책은 평균 668줄의 코드를 추가해야 하고 7개 파일을 수정해야 한다. SWE-bench Pro의 참조 해결책이 120줄, 5개 파일인 것과 비교하면 훨씬 복잡한 장기(long-horizon) 작업이다.
- TypeScript, Go, Python, JavaScript, Rust 5개 언어에 걸쳐 91개 오픈소스 저장소에서 113개 태스크를 수집했다. 다양한 코드베이스 구조와 문서화 수준을 포괄하기 때문에 실무 환경과의 유사성이 높다.
- 리더보드 결과: gpt-5.5(70%) > gpt-5.4(56%) > claude-opus-4.7(54%) > claude-sonnet-4.6(32%) > gemini-3.5-flash(28%) > gpt-5.4-mini(24%) = kimi-k2.6(24%) 순이다. 공개 벤치마크에서 비슷하게 붙어 있던 모델들이 DeepSWE에서는 큰 격차로 벌어진다.
- 모든 모델을 동일한 에이전트 하네스(harness)인 mini-swe-agent로 실행해 공정한 비교를 보장했다. 특히 Google 계열 모델들이 mini-swe-agent에 잘 적응하지 못하는 경향이 관찰됐는데, 이는 실제 다양한 도구 환경에서의 일반화 능력 부족을 시사한다.
- 정성적 분석에서 모델별 실패 패턴이 다르게 나타났다. Claude는 요구사항을 누락하거나 반대로 세심하게 챙기는 양면이 있고, GPT는 지시를 잘 따르며, 강력한 모델일수록 자체 테스트(self-test)를 더 잘 수행하는 경향이 있다.
- SWE-bench Pro와 유사한 패턴도 관찰됐는데, 이는 두 벤치마크가 어느 정도 유사한 실제 소프트웨어 엔지니어링 역량을 측정하고 있음을 보여준다.
Evidence
- 'contamination-free'라는 라벨은 최초 공개 시점에만 유효하다는 지적이 있었다. 결국 모든 벤치마크는 하나의 정답을 가지는 구조적 문제에서 벗어나지 못하며, 시간이 지나면서 모델이 학습 데이터에 포함될 수 있다는 근본적 한계가 있다는 의견이었다.
- GPT가 요구사항을 더 잘 따르고 Claude가 요구사항을 놓치는 경향이 있다는 벤치마크 결과가 실제 사용 경험과 일치한다는 댓글이 있었다. 다만 코드 품질, 유지보수성, '코드 취향(code taste)' 같은 비기능적 요소는 검증기가 측정하지 못한다는 비판도 함께 제기됐다.
- 출시 시점에 이미 최고 성능 모델이 70%를 달성했다는 점에서 '이미 포화(saturated)에 가까운 벤치마크를 왜 출시하느냐'는 날카로운 지적이 있었다. 벤치마크가 프론티어 모델에 의해 곧 100%에 가까워질 수 있다는 우려다.
- Gemini 2.5 Flash High 설정이나 비용 효율적인 구성이 테스트되지 않은 점, Claude Opus 4.6(max reasoning)이 Claude Sonnet 4.6(high reasoning)보다 낮은 점수를 기록한 이유에 대한 의문이 제기됐으나 공식 답변은 없었다.
- 성능 측정을 넘어서 문서, 성능(performance), 유지보수성, 코드 복잡도 같은 비기능적 측면을 어떻게 검증하느냐는 질문이 나왔다. 현재 DeepSWE는 이런 측면을 다루지 않으며, 이는 모든 코딩 벤치마크의 공통 미해결 과제라는 인식이 공유됐다.
How to Apply
- 실무에서 코딩 에이전트를 선택할 때 SWE-bench 점수만 보고 결정하지 말고, DeepSWE 리더보드를 함께 참고하면 실제 복잡한 멀티파일 작업에서의 성능 차이를 더 현실적으로 파악할 수 있다.
- 자체 코딩 에이전트를 개발 중이거나 평가 파이프라인을 구축 중이라면, DeepSWE의 GitHub 저장소에서 벤치마크를 직접 실행해볼 수 있다. 모든 모델 롤아웃 궤적(trajectory)도 공개돼 있어 에이전트가 어떻게 실패하는지 패턴을 분석하는 데 활용할 수 있다.
- Claude와 GPT 중 어느 모델을 쓸지 고민 중이라면, DeepSWE의 정성적 분석 결과를 참고하면 좋다. GPT 계열은 지시사항을 잘 따르는 편이고, Claude는 요구사항을 놓치는 경향이 있지만 세심한 측면도 있다는 패턴이 실제 사용 경험과 일치한다는 커뮤니티 피드백이 있었다.
- 코딩 에이전트가 특정 도구 환경에 과적합됐는지 확인하고 싶다면, mini-swe-agent처럼 표준화된 하네스로 테스트해보는 것이 중요하다. Google 모델들이 mini-swe-agent에 잘 적응하지 못한 사례처럼, 도구 일반화 능력이 실무 유용성과 직결된다.
Terminology
관련 논문
Constraint Decay: LLM 에이전트가 백엔드 코드 생성에서 구조적 제약을 못 따라가는 이유
LLM 코딩 에이전트는 구조적 제약(아키텍처 패턴, ORM, DB 설계)이 쌓일수록 성능이 급격히 떨어지는 'constraint decay' 현상을 보인다는 연구 결과로, AI 코딩 도구를 프로덕션에 쓰려는 개발자라면 반드시 알아야 할 한계다.
AMEL: 대화 히스토리가 LLM 판단에 미치는 누적 편향 효과
LLM을 자동 평가자로 쓸 때 이전 대화 기록의 긍정/부정 분위기가 이후 판단을 오염시킨다는 걸 75,898개 API 호출로 증명한 연구.
Language Model의 Backdoor Trigger는 숨겨진 Latent 경로를 통해 전파된다
8B LLM에 심어진 백도어 트리거가 중간 레이어에서 언어 탐지기를 완전히 속이는 직교 부분공간(orthogonal subspace)으로 숨어 이동한다는 걸 회로 분석으로 밝혀냈다.
Formal Methods와 LLM의 만남: AI 시스템 규정 준수를 위한 감사, 모니터링, 개입
LLM이 규칙을 잘 지키고 있는지 감시하려면 LLM에게 맡기지 말고 LTL(시간 논리 공식) 기반 모니터를 쓰세요.
Bun의 Rust 재작성: "safe Rust에서 UB(Undefined Behavior)를 허용하는 코드베이스"
Anthropic이 인수한 Bun 런타임이 Zig 코드베이스를 AI로 Rust에 재작성했는데, 가장 기본적인 메모리 안전성 검사(miri)조차 통과하지 못하는 UB(Undefined Behavior)가 발견됐다는 이슈가 제기됐다.
MetaBackdoor: LLM의 Positional Encoding을 Backdoor 공격 표면으로 악용하기
입력 텍스트는 멀쩡한데 입력 길이만으로 LLM 백도어가 발동되는 새로운 공격 기법 발견.
Claude Design 구독 해지 후 프로젝트 접근 불가 경험담 및 주의사항