blog logo
iaman

SWE-bench 점수가 말해주지 않는 것

TOC

2023년 10월, SWE-bench라는 벤치마크가 나왔을 때 최고 성능 모델이 푼 문제는 1.96%였다.

지금은 70%를 넘긴 점수가 흔하다. 3년도 안 되는 사이다.

그런데 2026년 2월, OpenAI는 이 벤치마크 점수를 더 이상 보고하지 않겠다고 발표했다. 숫자가 올라가는 동안 숫자의 의미는 내려갔다는 이야기다.

마침 최근에 이 블로그를 Claude Code로 통째로 마이그레이션했다. 벤치마크가 측정하는 것과 실제 작업에서 중요한 것이 어떻게 다른지 직접 보게 됐다. 그 기록을 겸해서 정리한다.

SWE-bench가 뭔가

프린스턴의 Carlos E. Jimenez, John Yang 등이 2023년 10월에 공개했다. 아이디어는 단순하다.

"GitHub에 실제로 올라온 이슈를, AI가 실제로 고칠 수 있는가?"

인기 있는 파이썬 저장소 12개에서 이슈와 그걸 해결한 PR 쌍 2,294개를 모았다. 각 문제는 이렇게 주어진다.

  • 저장소를 그 이슈가 열렸던 시점의 커밋으로 되돌린 상태
  • 이슈 본문 (사람이 쓴 그대로)

모델은 여기서 패치를 만들어내야 한다.

기존 코딩 벤치마크들과 결정적으로 다른 점이 있다. HumanEval 같은 건 "함수 하나를 구현하라"는 식인데, SWE-bench의 문제는 여러 파일에 걸친 수정을 요구한다. 어떤 파일을 봐야 하는지부터 스스로 찾아야 한다.

채점 방식 — 여기가 핵심이다

제출된 패치를 적용한 뒤 테스트를 돌린다. 두 종류를 본다.

뜻
FAIL_TO_PASS 이슈 때문에 실패하던 테스트. 이게 통과해야 한다
PASS_TO_PASS 원래 통과하던 테스트. 이게 깨지면 안 된다

둘 다 만족하면 "해결(resolved)"로 친다. 점수는 2,294개 중 몇 개를 해결했는가의 비율이다.

깔끔한 설계다. 사람의 주관이 안 들어가고, 자동으로 돌릴 수 있고, 실제 코드베이스를 쓴다.

그리고 바로 여기에 한계가 있다. 이 채점이 측정하는 건 정확히 이것이다.

테스트가 통과하는가

"코드가 옳은가"가 아니다. 보통은 둘이 같이 가지만, 항상 그렇지는 않다. 이 글의 뒷부분은 그 차이에 대한 이야기다.

그 차이는 측정된 적이 있다

추측이 아니다. 2025년 ACL에 실린 UTBoost 연구가 SWE-bench에 테스트를 보강해서 다시 채점해봤다.

결과는 이랬다.

  • 테스트가 불충분한 과제 36개
  • 벤치마크가 통과로 판정했지만 실제로는 이슈를 고치지 못한 패치 345개

그리고 이걸 바로잡자 리더보드 순위가 바뀌었다. Lite에서는 항목의 40.9%가 영향을 받아 18건의 순위 변동이, Verified에서는 24.4%가 영향을 받아 11건의 순위 변동이 있었다.

"테스트를 통과했다"가 "문제를 풀었다"와 다르다는 것이, 345건으로 실측된 것이다. 그리고 그 차이가 모델 간 순위를 뒤집을 만큼 컸다.

Verified가 나온 이유

2024년 8월, OpenAI가 원 저자들과 함께 SWE-bench Verified를 내놨다. 파이썬 개발자 93명이 1,699개 샘플을 직접 검수해서 500개만 남긴 것이다.

왜 걸러냈냐면, 원본에 이런 문제들이 섞여 있었다.

  • 이슈 설명이 불충분하다. 사람이라도 그 글만 보고는 뭘 고쳐야 할지 알 수 없다.
  • 테스트가 지나치게 구체적이다. 원 PR이 택한 구현을 그대로 따라가야만 통과한다. 다르게 고쳤으면 똑같이 옳아도 실패한다.
  • 아예 풀 수 없는 문제가 있다.

즉 원본 점수는 모델 능력을 과소평가하고 있었다. 못 푼 게 아니라 풀 수 없는 문제였던 것이다.

이건 벤치마크 설계에서 중요한 교훈이다. 자동 채점이 가능하다는 건 채점이 옳다는 뜻이 아니다. 500개로 추리는 데 사람 93명이 붙었다.

그리고 2026년 2월, 끝났다

OpenAI의 Frontier Evals 팀은 SWE-bench Verified 보고를 중단한다고 밝혔다. 이유는 크게 둘이다.

포화(saturation). 상위 모델들이 비슷한 고득점에 몰려서 변별력이 없어졌다. 85%와 87%의 차이가 실력 차이인지 노이즈인지 알 수 없다.

오염(contamination). 문제의 출처가 공개 GitHub 저장소다. 모델이 학습 과정에서 그 저장소를, 그 이슈를, 그 PR을 봤을 가능성이 높다. 시험 문제가 교과서에 실려 있는 셈이다.

두 번째가 더 근본적이다. 공개 데이터로 벤치마크를 만들면 시간이 지날수록 반드시 오염된다. 벤치마크의 수명이 설계에 내장돼 있는 것이다.

떠도는 숫자들 중에는 서로 충돌하는 것도 있어서(결함 있는 테스트 비율 등) 여기 옮기지 않았다. 후속 벤치마크의 상태에 대해서도 상반된 보도가 있으니 직접 확인하길 권한다.

실제로 시켜보면 — 블로그 마이그레이션 기록

이 블로그는 원래 헤드리스 CMS에 글을 저장하고 빌드할 때 받아왔다. 그걸 저장소 안의 Markdown 파일로 옮겼다. 글 16편, 커밋 64개 규모의 작업을 Claude Code Opus 5와 함께 했다.

결과만 보면 성공이다. 테스트 77개, 공개 URL 전부 보존, 빌드 성공. 그런데 중간에 나온 실패들이 벤치마크가 못 보는 지점을 정확히 가리킨다.

1. 테스트는 통과하는데 전부 깨져 있었다

HTML을 Markdown으로 변환하는 과정에서 코드블록 46개가 전부 망가졌다. 코드가 들어간 글 14편 전체다.

원인은 이랬다. 이 CMS가 저장한 HTML은 <pre> 안에 <code>가 없었다. 에디터가 구문 강조를 하면서 <pre class="language-javascript"> 안에 토큰 조각들을 직접 넣어뒀던 것이다. 변환 규칙은 pre > code 구조를 전제하고 있었고, 그래서 하나도 발동하지 않았다. 코드가 일반 문단으로 떨어져 마크다운 이스케이프를 먹었다.

파일을 열어보면 멀쩡해 보인다. 테스트도 통과한다. 렌더링해야만 드러난다.

2. 그걸 잡으라고 만든 검증 스크립트도 틀려 있었다

더 나쁜 건 이쪽이다. 원본 HTML과 변환 결과를 비교하는 스크립트를 따로 만들었는데, 코드블록 비교가 양쪽 모두 pre > code를 보고 있었다.

원본에 그 구조가 없으니 비교 대상이 항상 빈 배열 대 빈 배열이었다. 즉 코드가 통째로 사라져도 조용히 통과하는 검사였다.

안전망이라고 만든 것이 정작 가장 큰 사고를 못 잡는 상태였다. SWE-bench로 치면 FAIL_TO_PASS 테스트가 아무것도 검증하지 않는 것과 같다.

3. 자동 검증 16/16 통과, 그런데 화면이 달랐다

구조 비교가 전부 통과한 뒤 브라우저로 열어보니 코드에 색이 없었다.

원본 HTML에는 구문 강조 결과가 통째로 저장돼 있었고(토큰 조각 2,703개), CSS에도 그에 맞는 색상표가 있었다. Markdown으로 펴면서 그 정보가 사라진 것이다.

검증 스크립트는 텍스트와 구조를 비교한다. 색은 텍스트가 아니라 표현이라 비교 대상이 아니었다. 자동 검증으로는 영원히 안 잡힌다.

4. 전제가 틀렸다

가장 뼈아픈 건 이것이다. 설계 문서에 "이 블로그는 코드 구문 강조가 없다"고 적혀 있었다. 확인하지 않고 단정한 것이다.

실제로는 있었다. 저장 방식이 특이해서 눈에 안 띄었을 뿐이다. 그래서 "범위 밖"으로 분류됐고, 그 전제 위에서 모든 작업이 진행됐다.

SWE-bench는 이런 실패를 측정할 수 없다. 문제가 주어지고 테스트가 주어진다. 하지만 실제 작업에서 가장 비싼 실수는 문제 정의 자체가 틀린 경우다.

5. 한국어 때문에 깨진 것

부수적이지만 흥미로운 것도 있었다.

**텍스트 형식( 통신 방식 아님 )**입니다.

CommonMark의 flanking 규칙상 닫는 **가 구두점 뒤이면서 글자 앞이면 강조로 해석되지 않는다. 한국어는 조사가 바로 붙어서 이 조건에 잘 걸린다. 화면에 **가 그대로 보였다.

영어 위주 벤치마크에서는 나올 일이 없는 문제다.

덧붙이면, 이 글을 쓰면서도 같은 버그를 밟았다. **1.96%**였다, **Verified(500개)**가 같은 문장이 전부 강조로 렌더되지 않았다. 결국 그 자리들은 <strong> 태그로 바꿨다.

그래서 벤치마크를 어떻게 봐야 하나

SWE-bench가 쓸모없다는 이야기가 아니다. 1.96%에서 70%대로 간 건 실재하는 변화다. 측정 없이는 그 변화를 말할 수 없었다.

다만 숫자를 읽을 때 이걸 같이 생각하면 좋겠다.

벤치마크가 측정하는 것 측정하지 않는 것
테스트가 통과하는가 변경이 옳은가
주어진 문제를 푸는가 문제 정의가 맞는가
코드의 동작 화면에 보이는 결과
영어 이슈 한국어 콘텐츠, 비영어 환경
한 번의 패치 며칠에 걸친 작업의 누적된 판단

점수가 높은 모델이 실제로 유능한 건 맞다. 위의 작업도 사람 혼자 했으면 훨씬 오래 걸렸다. 하지만 "몇 %"가 "얼마나 믿고 맡길 수 있는가"로 바로 번역되지는 않는다.

실제로 도움이 됐던 건 점수가 아니라 작업 방식이었다.

  • 변환과 검증을 분리해서, 변환을 여러 번 다시 돌리며 검증 결과가 나아지는지 봤다
  • 원본을 통째로 덤프해 커밋해뒀다. 변환이 틀려도 되돌릴 수 있었다
  • 자동 검증이 통과한 뒤에도 화면을 직접 봤다. 위의 3번은 그래서 잡혔다
  • 리뷰를 따로 돌렸다. "펜스를 제거했다"는 수정이 들여쓴 펜스·중첩 펜스·CRLF에서 동작하지 않는다는 걸 리뷰가 실행해서 반증했다

벤치마크는 "이 모델이 얼마나 하는가"를 재지만, 실제 결과를 가르는 건 "틀렸을 때 어떻게 알아차리는가" 쪽이었다.

정리

  • SWE-bench는 실제 GitHub 이슈 2,294개로 AI의 코드 수정 능력을 재는 벤치마크다. 2023년 최고 점수는 1.96%였다.
  • 채점은 테스트 통과 여부다. FAIL_TO_PASS가 통과하고 PASS_TO_PASS가 안 깨지면 해결로 친다.
  • 그 둘이 같지 않다는 건 실측됐다. UTBoost 연구가 통과 판정됐지만 실제로는 틀린 패치 345개를 찾아냈고, 바로잡자 리더보드 순위가 바뀌었다.
  • 원본에 결함이 많아 2024년에 사람 93명이 검수한 Verified(500개)가 나왔다.
  • 2026년 2월 OpenAI는 포화와 오염을 이유로 이 벤치마크 보고를 중단했다. 공개 데이터로 만든 벤치마크의 구조적 한계다.
  • 실제 작업에서 비싼 실수는 테스트가 통과하는데 틀린 경우, 화면으로만 드러나는 경우, 그리고 전제 자체가 틀린 경우였다. 전부 벤치마크 바깥이다.

참고