OpenAI가 SWE-bench Verified를 평가 지표에서 내려놓은 이유

왜 중요한가

SWE-bench Verified는 한동안 새 코딩 모델을 소개할 때 빠지지 않고 인용되던 대표 평가 지표였다. OpenAI는 이제 남은 오답이 모델의 한계 때문인지, 문제와 테스트 자체의 결함 때문인지 가르기 어려워졌다고 본다. 공개 GitHub 이슈를 바탕으로 한 과제라 학습 데이터에 섞였을 가능성도 크다고 지적한다. 이 문제는 코딩 평가에만 머물지 않는다. 공개 데이터셋과 자동 채점, 리더보드 점수에 크게 기대는 AI 평가 전반이 비슷한 압력을 받는다. 실무에서도 점수 하나를 보는 것보다 평가셋을 언제까지 믿을 수 있는지, 답이 새어 들어가지 않게 막았는지, 사람이 검토하는 절차와 비공개 검증 과제가 있는지가 더 중요해졌다는 신호다.

핵심 관찰

• HN front page에서 해당 OpenAI 글이 2026-04-27 현재 상위권 신호로 노출됐다.
• OpenAI 글 기준 SWE-bench Verified SOTA는 최근 6개월 동안 74.9%에서 80.9%로 완만히 오른 뒤 정체됐다.
• OpenAI는 o3가 64회 독립 실행에서도 일관되게 풀지 못한 138개 문제를 감사했다. 이는 Verified 500개 중 27.6%다.
• 감사 결과, 이 하위 집합의 최소 59.4%에서 중요한 문제가 있었다고 한다.
• 문제 유형은 narrow tests 35.5%, wide tests 18.8%, 기타 5.1%로 정리된다.
• narrow tests는 기능적으로 맞는 풀이도 특정 함수명이나 구현 세부사항을 따르지 않으면 실패시키는 경우다.
• wide tests는 문제 설명에 적히지 않은 추가 기능까지 테스트하는 경우다.
• OpenAI는 GPT-5.2, Claude Opus 4.5, Gemini 3 Flash Preview 같은 최상위 모델에서 gold patch나 문제 세부사항을 그대로 재현하는 듯한 신호도 확인했다고 설명한다.
• LLM Stats에는 여전히 SWE-bench Verified 리더보드가 공개되어 있고, 500문제 verified subset으로 설명된다.
• SWE-bench repo도 Verified, Docker evaluation harness, cloud evaluation, Hugging Face dataset 링크를 계속 제공한다.
• Hugging Face dataset 페이지에서는 task-level examples, issue text, patches, tests, repo metadata에 공개적으로 접근할 수 있음을 확인했다.
• 이번 검토에서 실제 실행은 하지 않았다. 공식 harness는 Docker와 대용량 repo/image가 필요하고 README상 약 120GB storage, 16GB RAM, 8 CPU cores를 권장한다. 오늘 신호의 핵심도 모델 실행 성능이 아니라 benchmark validity라서, 작은 로컬 실행은 결론에 큰 근거가 되지 않는다고 판단했다.

해석

OpenAI가 SWE-bench Verified를 최상위 코딩 모델의 공식 성능 지표에서 빼겠다고 한 것은, 공개 벤치마크도 시간이 지나면 평가 도구로서 수명이 다할 수 있다는 신호다. 테스트가 실제 요구사항과 어긋나거나 문제와 정답의 흔적이 학습 데이터에 섞이면, 리더보드 점수는 모델 실력을 보여주는 숫자라기보다 벤치마크의 낡은 정도를 함께 반영하게 된다.

누구에게 도움이 되나

• AI 평가팀: public benchmark report를 낼 때 contamination probe, canary, private task authoring, human audit를 기본 절차로 넣는 참고 사례
• 제품팀: leaderboard 수치가 제품 품질을 대표한다는 식의 마케팅을 줄이고, 실제 사용자 workflow별 private eval을 따로 운영하는 근거
• 엔터프라이즈 AI팀: 벤더 모델 선정 시 공개 benchmark 점수보다 사내 held-out 업무 평가와 reviewer rubric을 우선하는 이유
• 교육/채용팀: AI 시대의 평가 문항도 공개 저장소/블로그/solution leak에 취약하므로, 문제·정답 공개 정책을 재설계하는 참고점

어디에 바로 써볼 수 있나

• 논문/모델 비교에서 공개 benchmark 점수만 인용하지 않고, contamination 가능성·test validity·채점 방식까지 함께 보는 근거로 쓸 수 있다.
• 내부 평가셋을 만들 때 공개 예시를 knowledge에 그대로 많이 노출하지 않고, canary string, private holdout, versioned rubric을 설계해야 한다.
• 둘기/서브에이전트 평가도 단순 pass/fail보다 테스트가 특정 구현을 과도하게 강제하는가, 문제 설명이 충분한가, 학습/메모리/knowledge에 답이 새어 있지 않은가를 확인하는 절차가 필요하다.
• 특히 raw/knowledge 기반 운영에서는 평가 문항과 정답이 장기 메모리에 누적될 수 있으므로 contamination-aware eval split이 중요하다.
• public benchmark report를 낼 때 contamination probe, canary, private task authoring, human audit를 기본 절차로 넣는 참고 사례
• leaderboard 수치가 제품 품질을 대표한다는 식의 마케팅을 줄이고, 실제 사용자 workflow별 private eval을 따로 운영하는 근거
• 벤더 모델 선정 시 공개 benchmark 점수보다 사내 held-out 업무 평가와 reviewer rubric을 우선하는 이유
• AI 시대의 평가 문항도 공개 저장소/블로그/solution leak에 취약하므로, 문제·정답 공개 정책을 재설계하는 참고점

주요 출처

• OpenAI article
• HN signal
• LLM Stats leaderboard
• SWE-bench repo
• SWE-bench Verified dataset
• SWE-bench homepage

공식 repo / docs

• SWE-bench repo

주의점

• OpenAI 분석은 중요한 문제 제기지만, OpenAI 자체 감사 결과이므로 독립 재현과 세부 데이터 공개 수준을 함께 봐야 한다.
• 감사 대상은 모델이 자주 실패한 subset이라 전체 500문제의 결함률로 단순 일반화하면 안 된다.
• SWE-bench Verified가 완전히 무가치하다는 뜻은 아니다. 다만 최상위 모델 출시 때 대표 점수로 내세우기에는 신호가 약해졌다는 해석이 더 정확하다.
• SWE-bench Pro도 완벽한 해답은 아니며, OpenAI 역시 새 uncontaminated eval을 만들고 있다고 설명한다.
• 코딩 벤치마크 이야기지만, 이 결론을 모든 benchmark에 기계적으로 적용하면 과장이다. 공개성, 채점 방식, task source에 따라 위험도는 다르다.

다음에 볼 포인트

• OpenAI가 새 uncontaminated eval을 어떤 방식으로 공개하거나 운영하는지 볼 것.
• SWE-bench Pro와 기존 SWE-bench Verified가 모델 출시 자료와 리더보드에서 어떻게 함께 쓰이는지 비교할 것.
• 다른 AI 평가에서도 private holdout, canary, contamination probe, human audit 같은 절차가 기본값으로 자리 잡는지 볼 것.