DeepSWE는 오늘날의 공개 벤치마크(benchmarks) 대비 네 가지 주요한 진보를 제공하는 장기적 관점(long-horizon)의 소프트웨어 엔지니어링 벤치마크입니다.

오염 없음 (Contamination free): 태스크(tasks)는 기존의 커밋(commits)이나 PR(Pull Requests)에서 가져온 것이 아니라 처음부터 새로 작성되었으므로, 어떤 모델도 사전 학습(pretraining) 과정에서 정답을 본 적이 없습니다.
높은 다양성 (High diversity): 태스크는 5개 언어에 걸친 91개 리포지토리(repositories)의 광범위한 풀을 아우릅니다.
실제 세계의 복잡성 (Real-world complexity): 프롬프트(prompts) 길이는 SWE-bench Pro의 절반 수준이지만, 해결책은 5.5배 더 많은 코드와 약 2배 더 많은 출력 토큰(output tokens)을 필요로 합니다.
신뢰할 수 있는 검증 (Reliable verification): 검증기(verifiers)는 구현 세부 사항이 아닌 소프트웨어 동작을 테스트하도록 수동으로 작성되었습니다.

기존 벤치마크들은 이러한 축들 중 여러 부분에서 미흡합니다. 선도적인 에이전트 코딩 벤치마크인 SWE-bench Pro는 해결해야 할 코드의 평균 길이가 단 120줄에 불과하며, 당사의 감사 결과 검증기가 에이전트 출력에 대해 8%의 거짓 양성(false positives)과 24%의 거짓 음성(false negatives) 비율로 오답을 매기는 것으로 나타났습니다. 프런티어 연구소(Frontier labs)들 또한 벤치마크 오염(benchmark contamination)에 대해 점점 더 큰 우려를 제기하고 있습니다.

대조적으로, DeepSWE는 프런티어 코딩 에이전트들에 대해 더 날카로운 비교를 제공합니다. 공개 벤치마크에서 서로 근접해 보였던 모델들이, 개발자들이 일상적인 에이전트 워크플로(workflows)에서 목격하는 차이와 일치하는 넓고 순서화된 격차로 분리됩니다.

모든 모델은 mini-swe-agent로 실행됩니다; 다른 하네스(harnesses)와의 비교는 Why mini-swe-agent를 참조하십시오.

GitHub에서 벤치마크를 확인하거나, 위 수치 뒤에 있는 모든 롤아웃(rollout)을 살펴보거나, 벤치마크에 대해 직접 에이전트를 실행해 보십시오.

1. 현실적이고 짧은 프롬프트를 사용하는 장기적 작업

DeepSWE 프롬프트는 개발자들이 에이전트와 대화하는 방식에 맞춰져 있습니다. 즉, 지나치게 장황하고 지시적이기보다는 동작 중심적이고, 짧으며, 거대한 인터페이스 정의 블록(interface-definition blocks)이 없습니다. 에이전트는 변경 사항을 어디에 어떻게 구현할지 스스로 찾아내야 하므로, 평가되는 능력의 상당 부분은 단순히 과도하게 명시된 엔지니어링 작업을 실행하는 것이 아니라 엔드 투 엔드 탐색(end-to-end exploration)을 포함합니다.

GitHub 이슈(issue)와 풀 리퀘스트(pull request)에서 가져온 공개 벤치마크(public benchmarks)는 재현 단계(reproduction steps), 추가 컨텍스트(context), 코드 스니펫(code snippets), 그리고 특정 심볼(symbol)이나 시그니처(signature)를 가정하는 테스트 등 더 많은 세부 정보를 포함하는 경우가 많습니다. 반면 DeepSWE는 관찰 가능한 동작(observable behavior)을 평가하며, 이를 통해 기저의 작업이 실질적으로 더 길더라도 프롬프트(prompt)를 짧고 자연스럽게 유지할 수 있습니다.

DeepSWE 작업은 실제 소프트웨어 엔지니어링(SWE) 업무를 반영하여 범위가 더 넓고 명시성이 낮습니다

2. 광범위한 리포지토리(repository) 커버리지

DeepSWE는 5개 언어(TypeScript, Go, Python, JavaScript, Rust)에 걸쳐 91개의 활성 오픈 소스 리포지토리(open-source repositories)에 걸친 113개의 작업을 포함합니다. 이 정도 규모의 샘플링을 통해 DeepSWE는 코딩 에이전트(coding agents)의 실제 유용성을 훨씬 더 강력하게 대변하는 프록시(proxy)가 됩니다. 즉, 에이전트가 구조, 문서화, 유지보수 수준이 각기 다른 다양한 코드베이스(codebase) 전반에 걸쳐 유용하고 범위가 잘 지정된 변경 사항을 만들어낼 수 있는지를 평가합니다.

기존의 공개 벤치마크는 훨씬 더 집중되어 있습니다. SWE-Bench Pro Public은 11개의 리포지토리를, SWE-Bench Verified는 12개의 리포지토리를 다루며, 많은 작업이 유명하고 유지보수가 활발한 프로젝트에서 추출되었습니다. 이는 개발자들이 실제로 코딩 에이전트에게 맡기는 프로젝트의 범위보다 더 좁은 설정입니다.

언어 분포

• typescript35(31%)
• go34(30%)
• python34(30%)
• javascript5(4%)
• rust5(4%)

5개 언어에 걸친 라이브러리부터 대규모 프레임워크까지

91개의 리포지토리. 점의 크기는 작업(task) 수이며, 색상은 주요 언어를 나타냅니다.

3. 문제 해결 능력을 테스트하는 새로운 작업, 암기력 테스트가 아님

모든 DeepSWE 작업은 독창적입니다. 참조 솔루션(reference solution)은 기존의 풀 리퀘스트(pull request), 커밋(commit), 또는 공개 패치(public patch)에서 복사하거나 변형하는 대신 처음부터 새로 작성되었습니다. 일부 작업은 해결되지 않은 GitHub 이슈(issue)에서 영감을 얻었지만, 수정 사항(fix) 자체는 새롭습니다. 또한 DeepSWE 작업은 업스트림 리포지토리(upstream repositories)로 다시 병합(merge)되지 않으므로, 공개 GitHub 기록에 남지 않으며 오픈 소스에서 스크래핑(scraping)되는 향후 사전 학습 코퍼스(pre-training corpora)에 나타날 가능성도 낮습니다.

이러한 특성 덕분에 DeepSWE는 에이전트가 공개된 수정 사항을 회상(recall), 검색(retrieve) 또는 재발견(rediscover)하는 것이 아니라, 새로운 소프트웨어 엔지니어링 문제를 실제로 해결할 수 있는지 여부를 더 깨끗하게 테스트할 수 있는 도구가 됩니다.

기존 커밋(commit)에서 가져온 벤치마크는 그에 대응하는 구현(implementation), 테스트, 그리고 논의 사항이 이미 온라인에 존재하기 때문에 본질적인 오염(contamination) 위험을 안고 있습니다. 우리의 SWE-Bench Pro 감사 결과, 이러한 위험은 가설에 그치지 않는 것으로 나타났으며, 솔루션 유출(solution leakage) 및 거짓 양성(false positives)이 감사된 롤아웃(rollout)의 약 8%에 영향을 미치고 있었습니다.

4. 검증기(Verifier)는 다양한 유효한 구현에 대해 정확성에 보상합니다

벤치마크의 품질은 검증기(verifier)의 품질에 달려 있습니다. SWE 벤치마크에서 검증기는 작업의 행동 사양(behavioral specification)을 근사해야 합니다. 즉, 특정 구현 전략에는 구애받지 않으면서 제출된 코드가 요청된 변경 사항을 구현했는지 여부를 결정해야 합니다. DeepSWE의 검증기는 이러한 목표를 염두에 두고 작업 설명으로부터 목적에 맞게 작성되었으며, 요청된 동작을 구현하는 모든 솔루션을 수용합니다.

이는 검증기가 병합된 풀 리퀘스트(pull request)의 테스트 스위트(test suite)로부터 상속되는 일반적인 벤치마크 구축 패턴과는 다릅니다. 이러한 테스트들은 유용한 신호를 제공하지만, 임의의 향후 제출물에 대한 완전한 채점 도구로 설계된 것은 아닙니다. 따라서 유효한 솔루션을 놓치거나, 작업을 완전히 충족하지 않으면서 테스트만 통과하는 제출물을 허용할 수 있습니다.

이를 정량화하기 위해, 우리는 DeepSWE와 SWE-Bench Pro에서 30개의 작업을 무작위로 추출하여 10개의 최첨단(frontier) 에이전트 구성에 대해 3번의 롤아웃(rollout)을 실행했습니다. 그 후 LLM이 작업 정의, 참조 솔루션(reference solution) 및 검증기 출력과 함께 각 궤적(trajectory)을 분석하여, 패치가 실제로 요청된 동작을 구현했는지에 대해 독립적인 판결을 내렸습니다. 분석기의 판결은 다음 두 가지 방향에서 검증기와 의견이 다를 수 있었습니다:

False positives (거짓 양성): 검증기(verifier)는 통과시켰으나, AI 판사(AI judge)는 패치(patch)가 요청된 동작을 실제로 구현하지 않았다고 결론 내리는 경우.**
False negatives (거짓 음성): 검증기(verifier)는 실패로 판정했으나, AI 판사(AI judge)는 패치(patch)가 프롬프트(prompt)에 대한 합리적인 해결책이라고 결론 내리는 경우.

DeepSWE 검증기는 실제 작업 성공과 더 밀접하게 일치함

분석기(analyzer)는 32%의 실험에서 SWE-Bench Pro 검증기(verifier)와 의견이 달랐으며, DeepSWE 검증기(verifier)와는 1.4%의 실험에서만 의견이 달랐습니다. 달리 표현하자면, 동일한 궤적(trajectory)을 주의 깊게 읽는 독자에게 SWE-Bench Pro의 합격/불합격(pass/fail) 결정 중 거의 3분의 1이 잘못된 것으로 보인다는 의미입니다. 이 정도로 넓은 오차 범위는 리더보드(leaderboard) 상의 최첨단 모델(frontier models) 간의 미세한 차이를 높은 신뢰도로 수용하기 어렵게 만듭니다. 아래의 정성적 분석(qualitative analysis)에서 SWE-Bench Pro의 불일치가 실제로 어떤 모습인지 자세히 파헤쳐 보겠습니다.

저장소 선정 (Repository selection)

저장소(repositories)는 공개되어 있어야 하며, 활발하게 유지 관리되고, 최소 500개의 GitHub 스타(stars)를 보유해야 하며, 허용적인 오픈 소스 라이선스(permissive open-source license) 하에 배포되어야 합니다. 이러한 기준은 의도적으로 광범위하게 설정되었습니다. 우리는 이미 공개 벤치마크를 지배하고 있는 주요 프레임워크(flagship frameworks)뿐만 아니라, 경제적으로 가치 있는 모든 엔지니어링 작업 전반에 걸친 에이전트(agent)의 성능을 측정하고자 합니다. 활발한 유지 관리와 500개 스타라는 하한선은 해당 저장소에 의존하는 실제 사용자가 있을 가능성이 높음을 시사합니다.

우리는 TypeScript, JavaScript, Python, Go, Rust의 다섯 가지 언어에 집중합니다. 각 작업(task)은 불변의 커밋 해시(immutable commit hash)에 고정되어 실행의 재현성(reproducible)을 보장합니다. 중앙값(median) 저장소는 단 하나의 작업만을 기여하므로, 특정 저장소가 리더보드(leaderboard)를 독점하지 않습니다.

작업 구성 (Task construction)

모든 작업은 세 가지 산출물(artifacts)을 포함합니다: 에이전트가 읽는 프롬프트(prompt), 결과를 채점하는 실행 가능한 검증기(verifier), 그리고 검토 과정에서 사용되는 참조 솔루션(reference solution)입니다. 검증기는 요청된 동작을 실행하는 새로운 파일들을 통해 저장소 자체의 테스트 인프라를 확장합니다. 테스트는 내부 헬퍼(internal helpers)나 내부 상태(internal states)가 아닌, 공개 API(public APIs)와 관찰 가능한 출력(observable outputs)을 통해 단언(assert)합니다. 따라서 동일한 작업을 내부 헬퍼를 재작성하거나, 새로운 모듈을 추가하거나, 기존 클래스를 확장하는 방식으로 해결할 수 있습니다. 검증기는 관찰 가능한 동작이 나타나기만 한다면 이 중 어떤 방식이든 수용합니다. 따라서 점수는 에이전트가 작성자의 구조와 일치했는지 여부가 아니라, 작업을 해결했는지 여부를 반영합니다.

채점의 신뢰성을 유지하기 위해 두 가지 추가 점검을 수행합니다. 모든 검증기는 작성 단계에서 세 번 실행됩니다. 실행 결과가 매번 달라지는 검증기는 불안정한(flaky) 것으로 표시되어 작성자에게 수정 요청이 반환되므로, 검증기의 노이즈가 점수에서 모델의 변동성(variance)으로 나타나지 않습니다. 또한 매 시도마다 검증기는 회귀 테스트(regression checks)를 실행합니다. 이는 저장소의 기존 테스트 중 일부와 작성자가 추가한 새로운 회귀 테스트를 포함합니다. 요청된 기능을 구현하면서 관련 없는 동작을 망가뜨리는 패치는 작업 실패로 처리되므로, 높은 점수를 받으려면 에이전트가 코드베이스의 나머지 부분을 정상적으로 유지해야 합니다.

품질 보증 (Quality Assurance)

작업은 LLM 지원 분석(LLM-assisted analysis)과 독립적인 인간 검토(independent human review)를 모두 거친 후에만 포함됩니다.

검토자들은 승인 전 프롬프트, 검증기, 참조 솔루션, 그리고 진단 에이전트의 실행 과정(diagnostic agent rollouts)을 조사합니다. 참조 솔루션은 작업과 함께 작성되지만, 채점 시에는 절대 사용되지 않습니다. 이를 통해 검토자들은 프롬프트 및 검증기와 비교할 수 있는 하나의 알려진 정답 구현(known-correct implementation)을 확보하게 되며, 검증기는 다른 올바른 형태의 구현들도 수용할 것으로 기대됩니다.

검토자들은 다음 네 가지 차원을 따라 각 작업을 평가합니다:

프롬프트-검증기 일대일 대응 (Prompt-verifier bijection). 검증기는 프롬프트가 요구하는 동작만을 정확히 테스트해야 하며, 그 이상도 그 이하도 아니어야 합니다. 더 많은 것을 테스트하는 검증기는 거짓 음성 (False Negatives, 에이전트가 명시된 작업은 해결했으나 명시되지 않은 작업을 실패함)을 생성하고, 더 적은 것을 테스트하는 검증기는 거짓 양성 (False Positives, 부분적인 해결책이 완전한 것처럼 보상받음)을 생성합니다. 어느 쪽이든, 벤치마크는 측정하고자 하는 바를 정확하게 또는 완전히 측정하지 못하게 됩니다. 수용 범위 (Acceptance breadth). 검증기는 참조 구현 (Reference implementation)뿐만 아니라 요청된 동작에 대한 모든 합리적인 구현을 수용해야 합니다. 실제 엔지니어링 작업은 많은 정답을 허용합니다. 서로 다른 모듈 경계, 헬퍼 이름 (Helper names), 제어 흐름 (Control flow) 모두 동일한 관찰 가능한 동작을 만들어낼 수 있습니다. 단 하나의 형태만 수용하는 검증기는 에이전트가 작업을 해결할 수 있는지 여부가 아니라, 작성자의 구조를 맞출 수 있는지를 측정하게 됩니다. 현실성 (Realism). 현실성은 두 가지 축을 가집니다. 프롬프트 현실성 (Prompt realism): 프롬프트가 구체적인 할 일 목록 (Todo list)이라기보다, 누군가가 실제로 에이전트에게 메시지를 보내는 방식인 자연스러운 개발자 어조로 작성되어야 합니다. 작업 현실성 (Task realism): 작업 자체가 유지보수자 (Maintainer)가 기여 (Contribution)로서 합리적으로 수용할 수 있는 것이어야 합니다. 명확하게 규정되지 않은 프롬프트는 에이전트가 코드를 작성하기 전에 관련 인터페이스를 탐색하고 설계상의 트레이드오프 (Tradeoffs)를 고려하도록 강제하며, 이는 에이전트에게 실제로 요구될 엔지니어링 작업의 종류를 반영합니다. 환경 청결도 (Environment Cleanliness). 검토자들은 실패한 롤아웃 (Rollouts)과 작업 자체 모두를 검사하여 환경 오류, 의존성 문제, 플래키 테스트 (Flaky tests), 그리고 기타 인프라 문제를 확인합니다. 이러한 요소들은 모델의 능력을 측정하는 것이 아니므로, 검토자들은 이를 수정 대상으로 표시합니다. 에이전트가 실패할 때, 그 실패는 환경적인 문제가 아니라 작업을 완료하는 데 어려움을 겪는 데서 기인해야 합니다.

여러 최첨단 에이전트 구성(frontier agent configurations)이 검토 과정의 일부로 각 작업을 시도합니다. 우리는 통과한 롤아웃(rollouts)이 진양성(true positives)임을 확인하며, 실패한 롤아웃은 환경이나 하네스(harness)의 문제가 아니라 모델의 역량을 반영함을 확인합니다. 특히 정답에 근접하여 실패한 롤아웃은 매우 유용합니다. 이는 검증기(verifier)가 엣지 케이스(edge cases)에서 어떻게 동작하는지를 드러내어, 우리가 이를 개선하는 데 도움을 줍니다.

기준 미달인 작업은 벤치마크에 포함되기 전에 수정을 위해 반환됩니다.

평가 하네스 (Evaluation harness)

모든 실행에는 SWE-bench 저자들이 구축한 하네스인 mini-swe-agent를 사용합니다. 우리는 리더보드가 모델 주변의 스캐폴딩(scaffolding)이 아닌 모델의 역량을 반영할 수 있도록 모든 모델에 대해 이를 고정하여 유지합니다.

실제로 개발자들은 Codex CLI, Claude Code, Cursor, Gemini CLI와 같은 네이티브 제품을 통해 이러한 모델에 도달합니다. 각 제품은 모델이 학습한 편집 프리미티브(editing primitives)(GPT의 apply_patch, Claude의 str_replace_based_edit_tool)와 해당 특정 모델에 맞춰 조정된 시스템 프롬프트(system prompt)를 함께 제공합니다. 이러한 요소 중 어느 하나라도 포함된다면, 리더보드는 모델의 역량만큼이나 스캐폴딩 선택을 반영하게 될 것입니다. mini-swe-agent는 설계 단계부터 모델 불가지론적(model-agnostic)입니다. 즉, 모든 모델은 벤더별 편집 프리미티브나 모델별 지침 없이 동일한 bash 도구와 동일한 공유 프롬프트를 받게 됩니다.

소규모 파일럿으로서, 우리는 표준화된 하네스가 비교 결과를 크게 왜곡하지 않는지 확인하기 위해 각 모델을 mini-swe-agent와 각자의 네이티브 하네스 모두에서 실행했습니다.

mini-swe-agent는 동일한 작업에서 네이티브 하네스와 대등하거나 이를 능가함

각 모델을 동일한 10개의 SWE-Bench Pro 작업에 대해 mini-swe-agent와 각자의 네이티브 하네스 하에서 실행했습니다.

이 슬라이스(slice)에서 mini-swe-agent