DeepSWE 벤치마크 2026 AI 코딩 에이전트 숫자만 보면 위험한 이유

2026년 5월 Datacurve가 공개한 DeepSWE는 91개 오픈소스 저장소와 5개 언어에서 뽑은 113개 장기 소프트웨어 엔지니어링 과제로 AI 코딩 에이전트를 평가한다. 공개 리더보드 기준 GPT-5.5 xhigh는 70%, Claude Opus 4.7 max는 54%로 표시됐고, Datacurve는 모든 모델을 mini-swe-agent 하네스에서 실행했다고 설명한다.

벤치마크 리더보드는 사람을 급하게 만든다. 70%, 54%, 32%처럼 숫자가 줄을 서면 마음은 바로 순위를 사고 싶어진다. 그런데 AI 코딩 에이전트는 모델만 사는 게 아니다. 하네스, 도구 권한, 테스트 검증기, 작업 크기, 실패 복구 방식까지 같이 산다. 점수표만 보고 도구를 고르면 자동차 엔진 출력만 보고 출근길 차를 고르는 꼴이 된다. 멋은 있는데 주차장에서 울 수 있다.

이번 글감 자체가 좋은 예시였다. 인박스에는 Threads 요약으로 DeepSWE 숫자가 들어왔지만, 자동 요약은 “5가 70%”처럼 모델명과 수치를 뭉개고 있었다. 그래서 Datacurve 원문, DeepSWE 페이지, GitHub 저장소, VentureBeat 보도를 다시 확인했다. 숫자를 빨리 가져오는 것보다 어떤 조건에서 나온 숫자인지 확인하는 쪽이 더 중요했다.

질문은 “DeepSWE 1위가 누구냐”에서 끝나면 안 된다. 실무 질문은 “이 점수가 내 코드베이스와 우리 팀의 작업 방식에 얼마나 옮겨오나”다. 코딩 에이전트는 단일 함수 문제를 푸는 도구가 아니라 파일을 읽고, 테스트를 돌리고, 실패하고, 다시 돌아와야 하는 작업자에 가깝다.

먼저 잡을 답

DeepSWE 점수는 필요하다. 다만 충분하지 않다. Datacurve는 DeepSWE가 기존 공개 코딩 벤치마크의 포화 문제를 줄이기 위해 오리지널 과제, 91개 저장소, 5개 언어, 평균 668라인 reference solution, 손으로 작성한 behavior verifier를 쓴다고 설명한다. 이건 기존 SWE-bench류보다 더 긴 작업을 보려는 시도다.

하지만 실제 도입에서는 점수 옆에 조건표가 붙어야 한다. 어떤 agent harness에서 돌렸는지, 인터넷 접근은 막혔는지, 테스트는 행동을 검증하는지, 출력 토큰과 reasoning effort가 얼마나 들어갔는지, 실패한 trajectory를 사람이 볼 수 있는지가 중요하다.

TECHTAEK식으로 줄이면 이렇다. DeepSWE는 “어느 모델이 강한가”를 보는 좋은 신호지만, 팀에서 바로 쓸 때는 “어느 작업에 어떤 하네스로 붙일까”를 같이 봐야 한다. 점수표는 입장권이고, 하네스 검증표는 작업 배치표다.

DeepSWE에서 숫자보다 먼저 읽을 것

Datacurve의 DeepSWE 페이지는 네 가지 차이를 강조한다. 첫째, 과제는 기존 commit이나 PR을 가져온 것이 아니라 새로 작성됐다. 둘째, 91개 저장소와 5개 언어에 걸쳐 있다. 셋째, prompt는 SWE-bench Pro보다 짧지만 solution은 5.5배 많은 코드를 요구한다. 넷째, verifier는 구현 세부보다 소프트웨어 행동을 보도록 작성됐다.

이 네 문장이 중요하다. GPT-5.5 70%, Claude Opus 4.7 54% 같은 숫자보다 먼저 봐야 할 것은 “어떤 경기장에서 나온 점수인가”다. 같은 모델도 다른 하네스, 다른 도구 권한, 다른 테스트 품질에서는 달라질 수 있다. 벤치마크는 경기 결과지만, 실무자는 경기장 규격도 봐야 한다.

GitHub 저장소를 보면 DeepSWE는 113개 과제를 TypeScript, Go, Python, JavaScript, Rust로 구성하고, task마다 repository, base commit, instruction, Docker 환경, verifier, reference solution을 둔다. 그리고 leaderboard는 Pier와 mini-swe-agent로 실행됐다고 설명한다. 즉 이 점수는 모델 단독 성적표가 아니라 모델+agent harness+reasoning setting의 조합으로 읽는 게 안전하다.

볼 항목	왜 중요한가	실무 질문
Tasks	오리지널 장기 과제인지	우리 작업도 이 정도로 길고 복잡한가
Harness	어떤 agent runner로 돌렸는지	우리 도구는 Codex, Claude Code, Cursor 중 무엇인가
Verifier	행동을 제대로 검증하는지	테스트가 진짜 요구사항을 잡는가
Trajectory	실패 과정을 볼 수 있는지	사람이 복구 가능한 로그가 남는가
Reasoning effort	비용과 속도 조건이 어떤지	실무 예산에서도 같은 설정을 쓸 수 있는가

이런 상황에서 특히 봐야 한다

이 글은 “어떤 LLM이 제일 좋아요?”보다 “우리 작업에 어떤 모델이 맞아요?”가 궁금한 사람에게 더 맞다. 개인 개발자라면 Cursor, Codex, Claude Code, Gemini CLI를 번갈아 쓰면서 왜 어떤 도구는 빠른데 불안하고, 어떤 도구는 느린데 덜 망가지는지 설명할 언어가 필요할 수 있다.

팀이라면 더 중요하다. 레거시 유지보수, 신규 프로토타입, 주니어 개발자 페어프로그래밍, 대규모 리팩터링, 운영 자동화는 전부 다른 일이다. 같은 모델 하나로 다 밀어붙이면 당장은 편하지만, 실패했을 때 원인 분석이 어려워진다.

블로그나 Obsidian 자동화에도 적용된다. URL 요약, 글감 후보화, 초안 작성, preflight, 발행 후 성과 점검은 모두 AI가 도울 수 있다. 하지만 어느 단계에서 사람이 개입해야 하는지, 어떤 실패를 로그로 남겨야 하는지는 정답률만으로 나오지 않는다.

기존 벤치마크가 보는 것

MMLU는 2020년 논문으로, 초등수학, 미국사, 컴퓨터과학, 법 등 57개 과목을 통해 모델의 다중 과제 이해 능력을 본다. 당시 논문은 큰 모델도 전문가 수준에는 아직 부족하고, 자신이 틀렸는지 잘 모르는 문제가 있다고 지적했다. 즉 MMLU는 “폭넓게 아는가”를 보는 데 강하다.

HumanEval은 OpenAI가 Codex 논문에서 제시한 코드 평가셋이다. docstring과 함수 시그니처를 보고 동작하는 코드를 만들 수 있는지, functional correctness를 중심으로 본다. 단일 함수 문제에서는 꽤 명확하다. 테스트를 통과하면 맞고, 아니면 틀린다.

SWE-bench는 훨씬 현실에 가깝다. 2023년 처음 제출된 논문은 실제 GitHub issue와 pull request에서 뽑은 2,294개 소프트웨어 엔지니어링 문제를 제시했다. 모델은 코드베이스와 issue 설명을 보고 패치를 만들어야 한다. 여러 파일과 긴 맥락, 실행 환경이 얽힌다는 점에서 HumanEval보다 실무에 더 가깝다.

그럼에도 이 벤치마크들만으로는 부족한 부분이 남는다. 정답률은 도착점이다. 하지만 팀에서 궁금한 건 도착점만이 아니다. 어떤 길로 갔는지, 막혔을 때 돌아나왔는지, 기존 코드 스타일을 존중했는지, 다음에도 비슷하게 일할지까지 보고 싶다.

벤치마크	잘 보는 것	놓치기 쉬운 것
MMLU	넓은 지식과 문제 풀이 폭	실제 업무 적용 판단, 모르는 것 인지
HumanEval	docstring 기반 단일 함수 구현	디버깅, 반복, 기존 코드베이스 적응
SWE-bench	실제 issue 기반 패치 생성	접근 경로, 아키텍처 이해 과정, 세션 간 학습
행동 평가	문제 접근 방식과 복구 패턴	설계가 어렵고 로그 수집이 필요

여기서 기존 벤치마크를 깎아내릴 필요는 없다. MMLU, HumanEval, SWE-bench는 각각 자기 목적이 있다. 다만 “우리 팀의 레거시 유지보수에 어떤 에이전트를 붙일까”라는 질문에는 추가 질문이 필요하다.

행동 벤치마크가 필요한 이유

John Lee의 글은 행동 벤치마크를 “LLM이 어떤 인지 패턴으로 문제에 접근하는지 프로파일링하는 평가”로 제안한다. 완성된 표준이라기보다 문제 제기에 가깝다. 그래도 실무자가 바로 써먹기 좋은 축이 있다.

첫째는 분해 방식이다. 모델이 문제를 받자마자 파일을 찾아 패치부터 하는지, 아니면 하위 작업으로 쪼개고 재현부터 하는지를 본다. 빠른 프로토타입에서는 전자가 유리할 수 있고, 장애 복구나 결제 로직에서는 후자가 나을 수 있다.

둘째는 접근 방식이다. 비슷한 패턴을 먼저 찾는지, 원리부터 새로 추론하는지를 본다. 기존 컨벤션이 중요한 코드베이스에서는 패턴 검색형이 강하다. 반대로 새 아키텍처나 연구성 작업에서는 원리 추론형이 필요할 수 있다.

셋째는 복구 방식이다. 막혔을 때 다른 전략으로 바꾸는지, 같은 방향을 계속 미는지를 본다. AI 에이전트에서 제일 피곤한 실패는 틀린 길을 아주 성실하게 달리는 경우다. 성실한데 틀리면 사람이 두 번 운다. 한 번은 결과 때문에, 한 번은 로그 읽다가.

넷째는 일관성이다. 비슷한 문제에서 비슷한 접근을 보이는지 본다. 기업 도입에서는 창의성만큼 예측 가능성이 중요하다. 다음 주에도 같은 방식으로 로그를 남기고, 같은 기준으로 테스트를 돌리고, 같은 방식으로 위험을 보고해야 팀이 안심한다.

행동 축	확인 질문	실무에서 보이는 차이
Decomposition	바로 실행하나, 먼저 쪼개나	빠른 수정형 vs 아키텍처형
Approach	선례를 찾나, 원리부터 푸나	유지보수형 vs 탐색형
Recovery	막히면 전략을 바꾸나	적응형 vs 밀어붙임형
Consistency	비슷한 문제에서 예측 가능한가	팀 운영형 vs 즉흥형

이 네 축은 점수표를 대체하지 않는다. 점수표 옆에 붙는 설명서에 가깝다. “이 모델은 90점”에서 끝나는 것이 아니라 “이 모델은 빠른 탐색은 좋지만 복구 로그가 약하다”처럼 말할 수 있어야 한다.

역할별로 맞는 모델은 다르다

AI 코딩 에이전트는 이제 하나의 직무처럼 봐야 한다. 사람을 뽑을 때도 백엔드, 데이터, SRE, 프론트엔드, 테크리드를 같은 면접 질문으로만 평가하지 않는다. AI도 비슷하다. 전부 “코딩 잘함”으로 묶으면 중요한 차이가 사라진다.

빠른 프로토타입에는 과감하게 파일을 찾고 첫 패치를 내는 모델이 좋다. 이때는 속도가 가치다. 단, 사람이 마지막 구조와 품질을 정리할 수 있어야 한다. 빠른 모델에게 운영 DB 마이그레이션까지 바로 맡기면 그건 속도전이 아니라 담력 테스트다.

레거시 유지보수에는 조심스러운 모델이 좋다. 기존 테스트, git log, 유사 PR, 코드 스타일을 먼저 보는 성향이 중요하다. 여기서는 창의적인 한 방보다 맥락 존중이 더 비싸다. 오래된 코드베이스는 가끔 박물관 같다. 예쁘게 고치는 것보다 전시품 안 깨는 게 먼저다.

주니어 페어프로그래밍에는 설명과 복구가 중요하다. 단순히 정답을 내는 모델보다 왜 이 파일을 봤는지, 어떤 테스트를 먼저 돌려야 하는지, 실패하면 무엇을 확인할지 말해주는 모델이 낫다. 주니어에게 필요한 건 마법사가 아니라 옆자리 선배에 가깝다.

역할	더 중요한 행동	덜 중요한 것
빠른 프로토타입	탐색 속도, 첫 산출물 생성	완벽한 컨벤션 준수
레거시 유지보수	선례 검색, 변경 범위 제한	과감한 재설계
주니어 페어	설명력, 단계 분해, 복구 힌트	압도적인 자동 수정
운영 자동화	일관성, 로그, 승인 대기	즉흥적 창의성
대규모 리팩터링	계획, 테스트 전략, 단계별 rollback	한 번에 끝내기

이렇게 나누면 모델 선택 질문이 부드러워진다. “제일 좋은 모델은 뭐야?”가 아니라 “이 작업에는 어떤 행동이 필요한가?”가 된다. 질문이 좋아지면 도구 선택도 덜 흔들린다.

내 워크플로에 붙이는 10분 평가표

행동 벤치마크를 거창하게 시작할 필요는 없다. 처음에는 같은 작은 작업을 서로 다른 모델이나 도구에 맡기고, 결과가 아니라 과정 로그를 비교하면 된다. 예를 들어 “인박스 요약 노트를 TECHTAEK 글감으로 바꾸기” 같은 작업이 좋다.

이번 글감에서 자동 요약은 파일 생성과 시트 handoff까지 잘했다. 하지만 TL;DR은 원문 논점을 충분히 잡지 못했고, 블로그 제목도 원문 제목을 반복하는 쪽으로 기울었다. 그래서 사람은 DEV 원문과 관련 arXiv를 확인하고, 행동 평가라는 실무 각도로 다시 잡았다. 이건 자동화의 실패라기보다 역할 분리다.

아래 표처럼 보면 된다. 한 번 평가한다고 모델 성격이 확정되지는 않는다. 그래도 기록이 쌓이면 “이 도구는 초안 생성은 빠르지만 출처 깊이는 보강해야 한다” 같은 판단이 생긴다.

10분 체크	볼 것	메모 예시
목표 이해	완료 조건을 다시 말했나	글감화, 초안화, 검수 중 어디까지인지
탐색 방식	어떤 파일/링크를 먼저 봤나	원문보다 2차 요약에 기대는지
근거 사용	공식/원문 출처를 확인했나	날짜, 논문, 원문 링크
복구 방식	부족할 때 전략을 바꿨나	웹 보강, 추가 검색, 사람 확인 요청
출력 품질	바로 쓸 수 있나, 편집이 큰가	제목 반복, TL;DR 모호함
로그성	다음 사람이 이어받을 수 있나	source, status, review, updated_at

이 평가표의 포인트는 모델을 혼내는 게 아니다. 도구별 역할을 정하는 것이다. 어떤 도구는 인박스 처리 담당, 어떤 도구는 원문 검증 담당, 어떤 도구는 초안 담당, 어떤 도구는 리뷰 담당이 될 수 있다. 사람 팀에서도 다들 같은 일을 하지 않는다. AI 팀도 슬슬 그렇게 봐야 한다.

흔한 실수 TOP 5

첫 번째 실수는 벤치마크 점수를 곧바로 실무 적합성으로 읽는 것이다. 점수는 실력의 일부를 보여준다. 하지만 업무가 길어지고 도구가 붙고 권한이 넓어질수록 운영성이 따로 필요하다.

두 번째 실수는 빠른 모델을 좋은 모델로만 보는 것이다. 빠른 모델은 정말 유용하다. 다만 빠른 첫 패치가 좋은 최종 패치라는 뜻은 아니다. 특히 테스트가 부족한 코드베이스에서는 빠른 확신이 오히려 비싸다.

세 번째 실수는 실패 복구를 평가하지 않는 것이다. 성공한 샘플만 보면 다 좋아 보인다. 진짜 차이는 막혔을 때 나온다. 다른 파일을 찾는지, 테스트를 줄여 재현하는지, 가정을 표시하는지, 아니면 같은 말만 반복하는지를 봐야 한다.

네 번째 실수는 하네스 영향을 모델 성향으로 착각하는 것이다. 같은 모델도 툴 권한, 시스템 프롬프트, 파일 접근, memory, approval policy에 따라 행동이 달라진다. 그래서 “모델이 그렇다”라고 말하기 전에 실행 환경을 같이 기록해야 한다.

다섯 번째 실수는 모든 작업을 하나의 최고 모델에 몰아주는 것이다. 초안 생성, 코드 수정, 리뷰, 배포 체크, 문서 요약은 요구 행동이 다르다. 하나의 모델이 전부 잘할 수는 있어도, 전부 같은 방식으로 쓰는 건 낭비일 수 있다.

TECHTAEK식 결론

LLM 평가의 다음 질문은 “몇 점인가”에서 “어떤 일을 맡길 것인가”로 넘어가야 한다. MMLU, HumanEval, SWE-bench는 여전히 중요하다. 다만 AI 코딩 에이전트를 실제 팀 도구로 쓰려면 분해, 접근, 복구, 일관성을 같이 봐야 한다.

개인 사용자라면 이번 주에 작은 실험 하나만 해보면 된다. 같은 작업을 두 도구에 맡기고 결과물이 아니라 접근 과정을 적어보자. 어떤 파일을 먼저 봤는지, 원문을 확인했는지, 막혔을 때 전략을 바꿨는지, 다음 사람이 이어받을 로그를 남겼는지 보면 된다.

팀이라면 모델 평가표를 두 겹으로 만들면 좋다. 첫 겹은 기존 벤치마크와 비용, 속도, context 길이 같은 기본 스펙이다. 두 번째 겹은 역할 적합성이다. 레거시 유지보수, 빠른 프로토타입, 운영 자동화, 리뷰 보조, 주니어 페어에 각각 필요한 행동을 따로 본다.

결국 좋은 AI 도입은 “최고 점수 모델 하나 고르기”가 아니다. 작업을 나누고, 모델의 행동을 관찰하고, 실패했을 때 복구 가능한 구조를 만드는 일이다. 점수표만 들고 들어가면 멋있어 보이지만, 현장에서는 로그와 역할표가 더 오래 간다. 성적표는 액자에 넣고, 작업표는 책상 위에 두자. 일은 책상 위에서 터진다.

FAQ

Q. 기존 LLM 벤치마크는 이제 의미가 없나?

아니다. MMLU, HumanEval, SWE-bench는 여전히 중요하다. 다만 각각 지식 폭, 단일 함수 구현, 실제 issue 패치 같은 특정 목적에 강하다. 실무 도입에서는 이 점수에 행동 관찰을 추가해야 한다.

Q. 행동 벤치마크는 객관적으로 만들 수 있나?

완전히 쉽지는 않다. 모델 자체 성향, 프롬프트, 도구 권한, 하네스 구조가 섞이기 때문이다. 그래서 처음에는 절대 점수보다 로그 기반 비교가 낫다. 같은 작업, 같은 입력, 같은 권한으로 접근 과정을 비교하면 출발점이 생긴다.

Q. 코딩 에이전트 평가에서 제일 먼저 볼 행동은 무엇인가?

복구 방식이다. 성공한 결과는 다 좋아 보인다. 하지만 테스트가 깨졌거나 파일을 못 찾았을 때 전략을 바꾸는지, 가정을 표시하는지, 사람에게 확인을 요청하는지 보면 실무 신뢰도가 드러난다.

Q. 레거시 코드베이스에는 어떤 모델이 더 맞나?

선례 검색과 변경 범위 제한을 잘하는 모델이 유리하다. git log, 유사 테스트, 기존 패턴을 먼저 보고 작은 diff를 내는 쪽이 안전하다. 빠른 재작성 성향은 프로토타입에서는 좋지만 레거시 유지보수에서는 리스크가 될 수 있다.

Q. 개인 블로그 운영에도 이 기준을 쓸 수 있나?

쓸 수 있다. URL 요약, 글감 후보화, 초안 작성, 출처 검증, 발행 전 QC를 나누고 각 단계에서 AI가 어떻게 행동하는지 기록하면 된다. 이번 글처럼 자동 요약은 빠르게 쓰고, 원문 검증과 각도 보정은 사람이 맡기는 방식이 현실적이다.

DeepSWE 이후 AI 코딩 에이전트를 고를 때 벤치마크 숫자만 보면 위험한 이유 2026