핵심 요약
DeepSWE는 기존 코딩 벤치마크보다 더 긴 작업, 더 다양한 저장소, 더 깨끗한 검증, 더 낮은 오염 가능성을 목표로 만든 소프트웨어 엔지니어링 평가 벤치마크입니다.
핵심 주장은 단순합니다. "모델이 이미 본 문제를 기억하는가"가 아니라 "낯선 코드베이스에서 실제 개발자처럼 문제를 해결하는가"를 보겠다는 것입니다.
DeepSWE가 풀려는 문제
기존 코딩 벤치마크는 실제 개발 업무를 충분히 반영하지 못한다는 비판을 받습니다.
많은 벤치마크는 GitHub 이슈, PR, 커밋에서 문제를 가져옵니다. 이 방식은 편리하지만, 모델이 학습 중 이미 정답 코드나 관련 토론을 봤을 가능성이 있습니다.
또한 기존 테스트는 특정 PR의 구현을 확인하기 위해 만들어진 경우가 많습니다. 그래서 같은 기능을 다른 방식으로 올바르게 구현해도 실패하거나, 반대로 일부만 구현했는데도 통과하는 문제가 생깁니다.
DeepSWE는 이 문제를 피하기 위해 과제를 새로 만들고, 검증기도 행동 중심으로 직접 작성합니다.
DeepSWE의 네 가지 핵심 특징
첫째, 오염 가능성을 낮췄습니다. 과제와 기준 해법은 기존 커밋이나 PR에서 가져오지 않고 새로 작성됩니다.
둘째, 범위가 넓습니다. 91개 오픈소스 저장소, 5개 언어, 113개 과제로 구성되어 있습니다.
셋째, 작업이 큽니다. 프롬프트는 상대적으로 짧지만, 실제 해결에는 더 많은 코드 수정과 탐색이 필요합니다.
넷째, 검증이 구현 방식보다 결과 행동을 봅니다. 내부 함수 이름이나 구조가 달라도 사용자가 관찰하는 동작이 맞으면 통과하도록 설계됩니다.
"긴 작업"을 평가한다는 의미
DeepSWE의 과제는 개발자가 에이전트에게 실제로 말하는 방식에 가깝습니다.
기존 벤치마크는 종종 재현 절차, 코드 조각, 구체적인 함수명, 테스트 조건을 길게 제공합니다. 반면 DeepSWE는 더 짧고 행동 중심의 요청을 줍니다.
예를 들어 "이 함수에 이 파라미터를 추가하고 이 테스트를 통과시켜라"보다는 "이 상황에서 이런 동작이 되도록 고쳐라"에 가깝습니다.
따라서 모델은 먼저 코드베이스를 탐색하고, 어디를 바꿔야 하는지 찾고, 기존 구조를 이해한 뒤 구현해야 합니다. 단순 코딩보다 실제 엔지니어링에 더 가깝습니다.
과제 규모와 다양성
DeepSWE는 평균적으로 SWE-Bench Pro보다 프롬프트는 짧지만, 기준 해법의 코드 추가량은 훨씬 큽니다.
원문 기준으로 DeepSWE의 평균 기준 해법은 668줄 추가이며, SWE-Bench Pro의 120줄보다 훨씬 큽니다. 수정 파일 수도 평균 7개로 더 넓은 범위를 건드립니다.
언어 분포는 TypeScript, Go, Python이 대부분을 차지하고, JavaScript와 Rust도 포함됩니다.
이 구성은 하나의 유명 프레임워크에 최적화된 모델이 아니라, 다양한 현실 코드베이스에서 잘 작동하는 모델을 보려는 의도입니다.
검증기는 왜 중요한가
코딩 벤치마크에서 검증기는 심판입니다. 심판이 잘못 판단하면 순위표도 믿기 어렵습니다.
DeepSWE는 검증기가 "어떤 방식으로 구현했는가"보다 "요청한 행동이 실제로 나타나는가"를 보도록 설계합니다.
예를 들어 어떤 기능을 새 헬퍼 함수로 구현해도 되고, 기존 함수 안에 직접 넣어도 됩니다. 외부 API나 실행 결과가 맞으면 통과해야 합니다.
원문 분석에 따르면 SWE-Bench Pro는 검증기 판단에서 거짓 양성 8.5%, 거짓 음성 24.0%가 나왔습니다. DeepSWE는 각각 0.3%, 1.1%로 훨씬 낮게 보고되었습니다.
리더보드가 보여주는 것
DeepSWE에서는 모델 간 격차가 더 크게 벌어집니다.
상위권은 gpt-5.5가 70%, gpt-5.4가 56%, claude-opus-4.7이 54%로 나타났습니다. 그 아래로 claude-sonnet-4.6, gemini-3.5-flash 등이 이어집니다.
저자들의 해석은 명확합니다. 기존 공개 벤치마크에서는 비슷해 보이는 모델들이 DeepSWE에서는 더 뚜렷하게 구분됩니다.
이는 실제 개발자가 체감하는 차이와 더 잘 맞는다고 주장합니다. 즉, "점수는 비슷한데 써보면 다르다"는 경험을 더 잘 드러낸다는 뜻입니다.
평가 환경: mini-swe-agent
모든 모델은 같은 평가 하네스인 mini-swe-agent에서 실행됩니다.
이 선택의 장점은 공정성입니다. 모델마다 다른 전용 도구나 프롬프트를 쓰면, 순위가 모델 능력인지 도구 세팅 차이인지 구분하기 어렵습니다.
대신 현실성은 줄어듭니다. 실제 개발자는 Codex CLI, Claude Code, Cursor, Gemini CLI 같은 제품을 사용하기 때문입니다.
DeepSWE는 우선 모델 자체 비교를 위해 동일한 bash 도구와 공통 프롬프트를 사용합니다.
모델 실패 패턴
분석에 따르면 Claude 계열은 여러 요구사항이 병렬로 있을 때 일부를 빠뜨리는 경향이 관찰되었습니다.
예를 들어 동기 처리와 비동기 처리를 모두 지원해야 하는데, 동기 쪽만 구현하고 비동기 쪽을 놓치는 식입니다.
GPT 계열은 프롬프트와 코드베이스의 명시적 계약을 비교적 정확히 따르는 경향이 관찰되었습니다.
강한 모델일수록 스스로 테스트를 작성하고 실행하는 비율도 높았습니다. 흥미로운 점은 SWE-Bench Pro의 프롬프트가 테스트 수정을 하지 말라고 암시해, 모델들이 자체 테스트 작성까지 덜 하게 만든다는 분석입니다.
SWE-Bench Pro와의 핵심 차이
SWE-Bench Pro는 실제 PR 기반 테스트를 많이 사용하기 때문에 현실 코드에서 온 장점이 있습니다.
하지만 그만큼 골드 커밋이 .git 기록에 남아 있거나, 테스트가 특정 내부 헬퍼 함수에 의존하거나, 필요한 fixture가 누락되는 문제가 생길 수 있습니다.
DeepSWE는 기존 공개 커밋에서 과제를 가져오지 않고, 얕은 클론과 새 검증기를 사용해 이런 위험을 줄입니다.
쉽게 말해 SWE-Bench Pro가 "기존 시험지를 잘 복원한 평가"라면, DeepSWE는 "새 문제를 내고 행동 기준으로 채점하는 평가"에 가깝습니다.
한계와 다음 과제
DeepSWE도 완벽하지 않습니다.
모든 모델을 mini-swe-agent에서 돌리기 때문에 실제 제품 환경에서의 성능과 다를 수 있습니다. 어떤 모델은 자기 전용 편집 도구나 시스템 프롬프트에서 더 강할 수 있습니다.
또한 대상 저장소는 별 500개 이상의 활발한 오픈소스 프로젝트로 제한되어 있습니다. 사내 코드베이스나 작은 프로젝트까지 일반화하기는 어렵습니다.
언어도 아직 C++와 Java가 빠져 있습니다. 장기적으로는 더 많은 언어, 더 다양한 작업 유형, 더 자연스러운 짧은 프롬프트가 필요합니다.
인사이트
DeepSWE의 핵심 가치는 코딩 에이전트를 "알고리즘 문제 풀이 모델"이 아니라 "실제 코드베이스에서 일하는 개발 파트너"로 평가하려는 데 있습니다.
코딩 모델을 고를 때는 단순 pass rate만 보지 말고, 과제가 오염되지 않았는지, 검증기가 행동을 평가하는지, 비용과 시간은 어떤지 함께 봐야 합니다.
실무에서 에이전트를 쓸 때도 같은 원칙이 유용합니다. 짧고 자연스럽게 요청하되, 기대하는 외부 동작은 명확히 적고, 모델이 스스로 테스트를 만들고 실행하도록 유도하는 것이 좋습니다.
@misc{datacurve2026deepswe,
title = {DeepSWE: Measuring frontier coding agents on original, long-horizon engineering tasks},
author = {Wenqi Huang and Charley Lee and Leonard Tng and Serena Ge},
year = {2026},
url = {https://github.com/datacurve-ai/deep-swe},
}출처 및 참고 : DeepSWE
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.