AI 코딩 도구의 성능을 비교할 때 SWE-Bench는 사실상 업계 표준으로 자리 잡았다. 실제 깃허브 이슈를 해결하는 과제 형식이고, 검증된 오픈소스 저장소를 쓴다는 점에서 신뢰를 얻어왔다. 그런데 2026년 들어 SWE-Bench Verified와 SWE-Bench Pro 양쪽 모두에서 상위 모델들이 80~90%대 점수를 기록하기 시작하면서 문제가 생겼다. 벤치마크가 포화되면 더 이상 모델 간 차이를 가려낼 수 없다. AI 데이터 회사 Datacurve가 DeepSWE를 설계한 이유가 여기에 있다.
기존 벤치마크의 두 가지 결함
Datacurve가 지적한 기존 벤치마크의 문제는 크게 두 갈래다.
첫 번째는 오염(contamination)이다. SWE-Bench를 포함한 대부분의 벤치마크는 기존 깃허브 커밋이나 풀 리퀘스트를 기반으로 과제를 만든다. 문제는 이 데이터가 LLM 훈련 데이터에 이미 포함됐을 가능성이 높다는 것이다. 모델이 “실제로 문제를 풀었는지”가 아니라 “학습 때 본 답을 기억해서 냈는지”를 구분하기 어렵다. Datacurve는 실제로 Claude가 git 저장소에서 미래 커밋을 찾아 정답을 “발견”한 사례를 포착했다. 에이전트가 문제를 풀지 않고 환경에서 답을 그냥 주워온 것이다.
두 번째, 그리고 더 심각한 문제는 검증 시스템의 신뢰도다. Datacurve가 SWE-Bench Pro를 직접 감사한 결과는 충격적이다.
검증 오류율 비교 — SWE-Bench Pro vs DeepSWE
올바른 구현을 불합격시킨 비율(위음성)과 틀린 구현을 합격시킨 비율(위양성)
SWE-Bench Pro는 올바른 구현의 24%를 위음성으로 처리했다. 네 번 제출하면 한 번은 맞게 풀었어도 틀렸다고 나온다는 뜻이다. 틀린 구현을 합격 처리한 위양성도 8.5%에 달했다. 이런 수준의 오류율이라면 리더보드 순위 자체가 측정 오류의 반영일 수 있다. DeepSWE는 행동(behavior) 기반 검증기를 직접 손으로 작성해 위음성 1.1%, 위양성 0.3%로 낮췄다. 구현 방식이 아니라 소프트웨어가 실제로 어떻게 동작하는지를 테스트한다는 철학의 차이다.
프롬프트 문구 하나가 결과를 바꾼 사례도 발견됐다. SWE-Bench Pro의 프롬프트에 “테스트 수정은 이미 처리됐다”는 문구가 들어가자, 더 강력한 모델들이 자체 검증 테스트를 작성하는 행동을 멈췄다. 모델이 지시를 따른 것이지만, 그 결과로 성능이 하락했다. 어떤 프롬프트를 쓰느냐가 벤치마크 점수에 영향을 미친다는 뜻이고, 이는 비교 자체의 신뢰성을 흔든다.
DeepSWE가 과제를 다르게 설계한 방식
DeepSWE의 113개 과제는 기존 커밋이나 PR을 재활용하지 않고 처음부터 새로 작성했다. 어떤 모델도 학습 데이터에서 정답을 본 적이 없다. 5개 언어(TypeScript, Go, Python, JavaScript, Rust)에 걸쳐 91개 저장소를 사용하고, 각 과제는 LLM 보조 분석과 독립적인 인간 검토를 모두 거쳤다.
난이도 설계가 특이하다. 프롬프트의 길이는 SWE-Bench Pro의 절반 수준이지만, 실제 해결에는 5.5배 더 많은 코드와 약 2배 더 많은 출력 토큰이 필요하다. 짧게 요청하고 길게 만들어야 하는 구조다. 현업에서 개발자에게 주어지는 요구사항이 흔히 이런 형태다. “로그인 기능 만들어줘”라는 한 줄 요청이 수백 줄의 구현으로 이어지는 것처럼.
리더보드 결과 — 익숙한 순서가 뒤집혔다
DeepSWE 리더보드 (2026년 5월)
장기 소프트웨어 엔지니어링 과제 해결율 (%, ±오차 범위 포함)
GPT-5.5가 70%로 1위다. 2위 GPT-5.4(56%)와의 격차가 14점이나 된다. 기존 SWE-Bench에서 비슷하게 평가받던 모델들이 장기 과제에서 큰 차이를 보인다는 점이 이 결과의 핵심이다. Claude Opus 4.7이 54%로 GPT-5.4와 근접한 3위, Claude Sonnet 4.6이 32%로 4위를 차지했다.
가장 눈에 띄는 이상값은 DeepSeek V4 Pro의 8%다. 다른 벤치마크에서는 프론티어 모델로 분류되던 DeepSeek가 이 지표에서 꼴찌 수준이다. Xiaomi의 MiMo v2.5 Pro(19%), Z.AI의 GLM 5.1(18%)보다도 낮다. DeepSWE가 이 결과를 직접 분석하지는 않았지만, 복잡한 멀티파일 엔지니어링 작업에서 긴 탐색 단계를 거쳐야 하는 과제, 즉 이 벤치마크가 가장 집중하는 유형에서 DeepSeek의 에이전트 하네스와 추론 방식이 불리하게 작용했을 가능성이 높다.
전반적으로 점수가 낮아 보이는 것도 의도적이다. 기존 벤치마크에서 80~90%를 기록하던 모델들이 여기서 50~70%대로 떨어진다. 이게 문제가 아니라 Datacurve가 목표한 결과다. 오염이나 채점 오류 없이 순수한 문제 해결 능력을 측정하면, 숫자가 낮게 나오더라도 그 숫자가 더 믿을 만하다는 주장이다.
이 결과를 어떻게 받아들여야 하는가
DeepSWE의 등장이 기존 벤치마크를 완전히 대체할 수 있다는 의미는 아니다. 113개 과제는 통계적으로 충분히 큰 샘플이 아니며, 에이전트 하네스와 추론 강도 설정이 결합된 점수라는 점도 순수 모델 비교를 어렵게 한다. GPT-5.5[xhigh]의 70%와 GPT-5.4-mini[xhigh]의 24%를 단순 비교하면 모델 차이처럼 보이지만, 실제로는 모델과 설정의 조합 차이이기도 하다.
▶ 펼쳐보기: 리더보드 항목 구성 방식
DeepSWE 리더보드의 각 항목은 세 가지 요소의 조합이다.
- 모델 — GPT-5.5, Claude Opus 4.7 등 기반 모델
- 에이전트 하네스 — 모델을 에이전트로 구동하는 프레임워크 (각 제공사가 직접 제출)
- 추론 강도 — [xhigh], [max], [high], [medium] 등의 컴퓨팅 예산 설정
따라서 “GPT-5.5가 70%”라는 문장은 정확하게는 “OpenAI의 GPT-5.5 모델을 xhigh 추론 강도로 OpenAI 에이전트 하네스에서 구동했을 때 70%”다. 하네스나 설정을 바꾸면 같은 모델도 다른 점수가 나올 수 있다.
그럼에도 DeepSWE가 제기한 문제는 진지하게 받아들일 필요가 있다. 올바른 코드가 네 번 중 한 번 탈락하는 채점 시스템이라면, 그 위에서 나온 순위는 실제 능력보다 측정 오류를 더 많이 반영할 수 있다. AI 코딩 도구 도입을 고려하는 팀이라면 리더보드 숫자 하나를 보는 것보다 어떤 벤치마크인지, 과제가 어떻게 설계됐는지, 검증은 어떻게 이루어지는지를 함께 살펴봐야 한다.
결국 DeepSWE는 “AI가 얼마나 잘 코딩하느냐”만큼이나 “우리가 AI를 어떻게 평가해야 하느냐”라는 더 근본적인 질문을 던진다. 모델 성능 경쟁이 빨라질수록 그 성능을 정확하게 측정하는 기준도 함께 진화해야 한다는 것, 그리고 지금의 벤치마크 체계가 그 속도를 따라가고 있지 못할 수 있다는 것이 이번 발표가 남긴 가장 중요한 시사점이다. DeepSWE 자체도 현재 12개 모델 제출에 머물고 있어, 앞으로 더 많은 모델과 에이전트가 참여하면서 결과의 신뢰도가 높아지는 과정이 필요하다.
출처