SWE-bench Verified는 끝났다 — OpenAI가 자기 벤치마크를 폐기한 진짜 이유

80.9%와 45.9%. 같은 모델, 같은 주(週)에 측정된 두 점수의 차이는 무엇을 의미하는가. 그리고 OpenAI가 자기네 평가 지표를 스스로 내려놓은 사건은, 단순한 벤치마크 교체인가 아니면 AI 코딩 능력 측정의 패러다임이 무너지는 신호인가.

OpenAI가 자기 벤치마크를 손절했다

2026년 2월 23일, OpenAI는 공식 블로그에 “Why we no longer evaluate SWE-bench Verified”라는 짧은 글을 올렸다. 한 줄 요약은 이렇다. “프런티어 코딩 평가의 기준은 모델 성숙도와 함께 바뀌고 있다(The standard for frontier coding evals is changing with model maturity).” 같은 날 OpenAI Devs 계정의 X 포스트도 동일한 메시지를 발신했다.

이 발표는 Hacker News에서 281점을 받고 158개의 코멘트가 달렸다. 흥미로운 것은 발표 두 달이 지난 4월 시점에도 X 타임라인과 엔지니어 커뮤니티에서 다시 회자되고 있다는 점이다. 이유는 단순하다. 2024년 이래 거의 모든 LLM 발표 자료의 첫 슬라이드를 장식했던 지표가, 그 지표를 가장 적극적으로 활용하던 회사 손에 의해 사실상 사망 선고를 받았기 때문이다.

SWE-bench Verified는 2024년 OpenAI 자신이 검증·정제한 파생 벤치마크다. 본가 SWE-bench가 노이즈가 많다는 비판을 받자, OpenAI는 직접 인간 어노테이터를 동원해 500개의 Python 이슈를 골라냈다. 이름에 “Verified”가 붙은 이유다. 그 후 약 1년 반 동안 GPT-5 시리즈, Claude Opus 시리즈, Gemini 시리즈 등 모든 프런티어 모델이 이 지표 위에서 점수 경쟁을 벌였다. 80%를 돌파했다는 헤드라인이 줄을 이었고, 외주 발주 RFP에서도 “SWE-bench Verified X% 이상”이라는 항목이 종종 등장했다.

그 벤치마크를 만든 측이 “이제 우리는 이걸로 모델을 평가하지 않는다”고 선언한 것이다. 이 글은 그 결정의 근거 데이터를 살펴보고, 외주 발주처와 의사결정자가 AI 코딩 도구를 평가할 때 무엇을 봐야 하는지를 정리한다.

무엇이 일어났는가 — 두 가지 결함

OpenAI 발표가 제시한 폐기 사유는 크게 둘이다. 테스트 케이스 자체의 결함, 그리고 데이터 컨태미네이션(data contamination, 학습 데이터 오염).

결함 1. 테스트 케이스의 59.4%가 망가져 있었다

OpenAI에 따르면, 자체 감사한 SWE-bench Verified 문제 중 59.4%가 결함 있는 테스트 케이스(flawed test cases) 를 포함하고 있었다. 무엇이 결함인가. 가장 빈번한 패턴은 “기능적으로 맞는 답을 자동 채점기가 거절(reject)” 하는 경우다. 즉 false negative다.

구체적으로는 이런 식이다. 어느 GitHub 이슈를 고치는 패치가 실제로 버그를 해결하더라도, 채점 스크립트는 “원본 PR과 토큰 단위로 일치하는 코드”만 정답으로 인정한다. 변수명을 다르게 짓거나, 동일 기능을 다른 함수 시그니처로 구현하면 0점 처리된다. 코드는 단일 정답이 없다는 자명한 사실이 채점기 안에서는 통하지 않는 것이다.

여기서 역설이 발생한다. 더 똑똑한 모델일수록 다양한 표현으로 답을 내놓는다. 반면 학습 데이터에 동일한 PR을 외운 모델은 토큰 단위로 정답을 재현한다. 결과적으로 “진짜로 더 잘 푸는 모델이 점수가 더 낮게 나오는” 모순이 구조화된다. 이는 평가 지표로서 치명적 결함이다.

결함 2. 모든 프런티어 모델이 정답을 외우고 있었다

두 번째는 컨태미네이션이다. OpenAI는 “모든 주요 프런티어 모델이 verbatim gold patches를 재현 가능하다”고 명시했다. GPT-5.2, Claude Opus 4.5, Gemini 3 Flash. 이름이 알려진 모델은 모두 SWE-bench Verified의 “정답 패치”를 토큰 단위로 그대로 출력할 수 있다는 뜻이다.

이유는 짚어보면 자명하다. SWE-bench는 GitHub 공개 PR을 기반으로 만들어졌다. 공개 PR은 모든 LLM의 학습 데이터에 포함된다. 따라서 SWE-bench Verified의 “문제와 정답”은 사실상 모델의 사전학습 코퍼스 안에 모두 들어 있다. 시험 직전에 학생에게 정답지를 보여준 셈이다.

OpenAI가 직접 비유한 표현은 따로 있지만, 한국어로 옮기자면 “기말고사 문제와 모범답안이 학생의 교과서에 인쇄되어 있는 상태로 시험을 보는 것”에 가깝다. 이 상태에서 80%를 돌파했다는 점수는, 능력이 아니라 노출의 증거에 가깝다.

점수 차이를 보여주는 한 장면

이 두 결함이 합쳐지면 어떤 모순이 보이는가. 가장 단적인 사례는 Claude Opus 4.5다.

  • SWE-bench Verified: 80.9%
  • SWE-bench Pro: 45.9%

같은 모델, 같은 시점에 측정된 두 점수다. 무엇이 다른가. Verified는 500개의 Python-only 태스크로 구성되며, 위에서 본 두 가지 결함을 안고 있다. 반면 Pro는 Scale AI가 만든 1,865개의 multi-language 태스크 모음이며, 컨태미네이션 방지를 위해 부분적으로 private test set 구조를 채택했다.

같은 모델의 능력이 절반으로 줄어드는 것은 모델 능력이 변한 것이 아니다. 자(尺) 가 바뀌었기 때문에 길이의 표시값이 달라진 것이다. 그리고 두 자 중 어느 쪽이 진짜 길이에 가까운지는, 위에서 본 두 결함이 답해준다.

왜 일어났는가 — Goodhart’s law의 교과서적 사례

이 사건을 한 줄로 요약하는 가장 적절한 학술 개념이 있다. Goodhart’s law다. 영국 경제학자 Charles Goodhart가 1975년에 정식화한 명제로, 가장 자주 인용되는 형태는 다음과 같다.

“When a measure becomes a target, it ceases to be a good measure.” (지표가 목표가 되는 순간, 그 지표는 더 이상 좋은 지표가 아니다.)

SWE-bench Verified의 흥망은 이 법칙의 거의 완벽한 사례다. 처음에는 모델 능력을 가늠하는 도구였다. 그러다 LLM 마케팅의 핵심 지표로 격상됐다. 점수를 올리기 위한 학습 데이터·평가 파이프라인 최적화가 이뤄졌고, 결과적으로 “지표는 올라가는데 실제 능력 향상과의 상관은 약해지는” 단계로 진입했다. OpenAI 자신도 이 파이프라인의 일부였다는 점이 중요하다.

자동 채점기의 구조적 한계

코드는 자연어와 다르지만, 자연어보다 더 어려운 평가 문제가 있다. 자연어는 사람이 직접 읽으면 의미가 통한다. 코드는 일단 컴파일되고 실행돼야 한다. 그래서 자동 채점기에 의존할 수밖에 없다.

자동 채점기는 두 부류가 있다.

  1. 테스트 통과 여부: PR에 포함된 단위 테스트를 모델 패치가 통과시키는가
  2. 참조 패치와의 일치도: 모델이 만든 패치가 사람이 만든 정답 패치와 얼마나 비슷한가

(1)은 false positive에 약하다. 모델이 테스트만 우회하는 코드를 만들면 통과한다. (2)는 false negative에 약하다. 위에서 본 그대로다. 실제 SWE-bench류 벤치마크는 (1)을 주로 쓰지만, 테스트 자체가 부실하거나 환경 의존성이 높아 결국 결함률이 높아진다.

근본적으로 코드 평가에는 단일 정답이 없다는 사실이 채점기 설계와 충돌한다. 그래서 모델이 더 다양한 솔루션을 만드는 능력을 갖출수록 채점기와 모델 사이의 간극은 커진다.

새로운 평가 기준의 트레이드오프

OpenAI는 SWE-bench Pro로의 이행을 권장했다. 그러나 Pro도 만능은 아니다. 새로운 코딩 벤치마크가 충족해야 할 조건들을 정리하면 다음과 같다.

  • 다국어 지원: Java, Go, C++, TypeScript 등. Python-only 평가는 실무 분포를 반영하지 못한다.
  • 실제 PR 환경 근접성: 단순한 함수 시그니처 매칭이 아니라, 멀티 파일·멀티 모듈·기존 코드 컨텍스트까지 다루는 태스크.
  • 컨태미네이션 방지: private test set 또는 정기 리프레시. 공개되는 순간 다음 학습 사이클에서 오염된다.
  • 재현성: 누구나 같은 방식으로 점수를 잴 수 있어야 비교가 의미를 갖는다.

문제는 이들이 서로 충돌한다는 점이다. 재현성은 공개를 요구하지만, 컨태미네이션 방지는 비공개를 요구한다. 실제 PR 환경 근접성은 평가 비용을 키우지만, 다국어·다중 모듈 태스크 1,865개를 매번 돌리는 비용은 적지 않다. 산업 차원에서 “stronger coding eval standards” 작업이 진행 중이라는 OpenAI의 표현은, 이 트레이드오프 위에 합의를 만들어가고 있다는 뜻이다.

벤치마크 인플레이션의 종말

2024년 이래 LLM 마케팅의 표준 패턴은 명확했다. 새 모델 발표 → SWE-bench Verified 점수 갱신 → “코딩 SOTA 달성” 헤드라인. 이 패턴은 기술 보도뿐 아니라 RFP·계약서 수준까지 침투했다. “벤치마크 점수 X% 이상의 도구를 사용할 것”이라는 조건이 명시되는 사례도 적지 않다.

그러나 위 데이터가 시사하는 바는 분명하다. 80%대 후반에서의 1~2점 차이는 모델 능력 차이가 아니라, 컨태미네이션의 농도 차이를 반영하는 경우가 더 많다. 점수의 “노이즈 플로어”가 모델 간 진짜 격차보다 커진 것이다. 이 상태에서 점수 비교는 의사결정 근거로 기능하지 못한다.

의사결정자에게 무엇을 의미하는가

SWE-bench Verified의 폐기는 학술적 사건이 아니다. AI 코딩 도구를 도입하고, 외주 협력사를 평가하며, 사내 개발 생산성을 측정하는 의사결정자에게 직접적인 시사점을 던진다.

시사점 1. “벤치마크 점수”만으로의 도구 선정은 위험 구간에 들어섰다

CTO·개발 매니저가 코딩 어시스턴트나 AI 코드 리뷰 도구를 비교할 때, 벤더 자료의 첫 페이지에는 거의 예외 없이 SWE-bench류 점수가 등장한다. 이 점수의 의미가 흔들린 이상, 공급사 자료의 점수만으로 도구를 선정하는 의사결정 프로세스 자체를 재검토할 가치가 있다.

대안은 새롭지 않다. 자사 코드베이스에서의 파일럿 테스트다. 실제 자사 리포지토리에서 일주일 동안 실 PR을 만들어보게 하고, 시니어 엔지니어가 머지율·롤백률·리뷰 코멘트 수 같은 실제 지표를 기록하는 방식이다. 비용이 들지만, 이 비용은 “잘못된 도구를 1년간 쓰는 비용”보다 작다.

시사점 2. 다국어·다중 모듈·legacy 코드는 별도 평가가 필요하다

SWE-bench Verified의 Python-only 구성은 평가 단순화를 위한 결정이지만, 일본 시장의 실무 분포와는 거리가 있다. 외주 발주처의 코드베이스는 Java·PHP·Ruby·Go·TypeScript·C#·심지어 COBOL이 공존하는 경우가 일반적이다. 거기에 사내 프레임워크, 10년 묵은 legacy 모듈, 사내 라이브러리에 대한 의존성이 겹친다.

이 환경에서 AI 코딩 도구의 실제 성능은 Python-only 벤치마크 점수와 무관해질 가능성이 높다. SWE-bench Pro가 제시하는 multi-language 태스크가 더 가까운 근사값이지만, 그것도 자사 환경의 대체물은 아니다. “우리 회사 환경에서 실제로 동작하는가” 라는 질문은, 어떤 외부 벤치마크로도 자동으로 답해지지 않는다.

시사점 3. private 평가셋의 가치

이미 일부 대기업은 자사 코드베이스 일부를 비공개 평가셋으로 만들어 운영하고 있다. 외주 협력사 또는 도구 벤더에 의뢰할 때, “이 비공개 태스크 50개에 대해 X% 이상의 머지 가능 PR을 생성할 것”이라는 조건을 걸 수 있다.

이 방식은 두 가지 이점이 있다. 첫째, 컨태미네이션이 원천적으로 차단된다. 비공개 코드는 공개 학습 데이터에 들어 있지 않다. 둘째, 자사 도메인·코딩 컨벤션·legacy 의존성이 모두 평가에 반영된다. 단점은 평가셋 구축·유지 비용이지만, 이는 외주 RFP 작성 비용의 자연스러운 확장으로 흡수할 수 있다.

시사점 4. “점수의 시간 감가상각”을 전제로 한 계약

벤치마크 점수의 반감기가 짧아지고 있다. 오늘 80%인 지표는 내년 동일 모델에서 의미가 다를 수 있다. 따라서 도구 도입 계약서에 “평가 지표의 갱신 시점에 재평가한다” 는 조항을 명시하는 사례가 늘고 있다. 이는 도구 벤더와의 신뢰관계를 깨는 조항이 아니라, 양쪽 모두 변하는 평가 환경에 대비하는 합리적 설계로 볼 수 있다.

결론 — 자(尺)가 바뀌는 시대의 의사결정

처음 던진 질문으로 돌아가자. 80.9%와 45.9%의 차이는 무엇을 의미하는가. 답은 명료하다. 모델 능력이 아니라, 평가 도구의 신뢰도가 절반으로 줄어든 것이다. 그리고 OpenAI의 SWE-bench Verified 폐기는, 더 신뢰할 수 있는 자(尺)를 산업 차원에서 만들어가는 작업의 시작 신호다.

이 변화는 AI 코딩 도구를 도입·평가·발주하는 의사결정자에게 두 가지를 시사한다. 첫째, 외부 벤치마크 점수의 절대값을 의사결정의 단일 근거로 삼는 시대는 지나갔다. 둘째, 자사 코드베이스에 기반한 실측·비공개 평가셋·다국어 평가를 결합한 평가 체계가 점차 표준이 되어가고 있다.

흥미로운 것은 이 흐름이 특별히 비관적이지 않다는 점이다. 오히려 “벤치마크 인플레이션” 이전, 즉 도구를 도입하는 회사가 자사 환경에서 직접 검증하던 시절로 돌아가는 정상화에 가깝다. 다만 이번엔 평가 대상이 LLM이고, 평가의 방법론이 더 정교해질 여지가 있을 뿐이다.

남은 열린 질문도 있다. SWE-bench Pro 역시 공개된 이상 시간이 지나면 같은 운명을 맞을 수 있다. 더 근본적으로, “좋은 코드”의 정의 자체가 환경마다 다르다는 사실을 자동 채점기가 어떻게 흡수할 것인가. 이 질문에 산업이 어떤 답을 만들어내는지 — 그것이 다음 수년간 AI 코딩 도구의 평가 풍경을 결정할 것이다.

출처

  • OpenAI, “Why we no longer evaluate SWE-bench Verified” (2026-02-23): https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/
  • OpenAI Devs X 포스트 (2026-02-23)
  • SWE-Bench Pro Leaderboard (Scale AI)
  • Hacker News 논의 (2026-02-23, 281점, 158 comments)
  • Goodhart, C. (1975). “Problems of Monetary Management: The U.K. Experience”