
OpenAI가 "다들 경쟁하던 AI 코딩 벤치마크"였던 SWE-bench Verified의 비중을 사실상 내리겠다고 밝혔습니다.1 점수 0.x% 올리기 경쟁이 이어지던 판에 "이 점수, 이제 의미가 줄었다"는 선언이라 업계가 술렁이죠. 오늘은 왜 이런 결론이 나왔는지, 그리고 앞으로 AI 코딩 성능을 어디서 어떻게 봐야 하는지까지 한 번에 정리해보겠습니다.
SWE-bench Verified가 '게임화'되며 생긴 두 가지 문제
첫 번째는 테스트 자체의 신뢰 문제입니다. OpenAI는 Verified 과제 중 상당수가 "정답을 맞혀도 오답 처리"될 수 있는 구조적 결함을 갖고 있다고 지적했습니다.1 예를 들어 결과가 맞아도 특정 구현 방식을 강제하거나, 문제 설명에 없는 동작을 테스트가 요구하면 모델이 실력을 보여줄 기회가 사라집니다. 벤치마크가 실력을 측정하는 저울이 아니라, 특정 모양의 추를 요구하는 퍼즐이 되어버리는 셈이죠.
두 번째는 데이터 오염(Contamination)입니다. Verified는 오픈소스 저장소에서 뽑은 문제들로 구성됐고, 워낙 유명해지면서 문제·풀이가 학습 데이터나 2차 데이터셋으로 흘러들 여지가 커졌습니다. OpenAI는 최신 모델들이 일부 문제에서 "기억으로 패치 재현"을 보였다고 설명했는데, 이 상황에서 점수 상승은 추론력 향상보다 '봤던 문제를 떠올리는 능력'일 수 있습니다.1
숫자만 보면 착시: Verified 상위권이 70~80%대인 이유
최근 리더보드를 보면 SWE-bench Verified는 상위 모델들이 70% 후반~80%대에 몰려 있습니다. 한 번 업데이트가 돌면 상위 10개가 70%대 초중반에서 촘촘히 붙어 "누가 1등이냐"만 남는 분위기가 되기도 합니다.2 게다가 점수를 올리는 방법이 "모델 자체"뿐 아니라 스캐폴드(에이전트 구조), 프롬프트, 하네스 최적화로도 가능해져서, 같은 모델이라도 세팅에 따라 체감이 달라집니다.
Verified의 태생적 특징도 한몫합니다. 원본 SWE-bench 2,294개 중에서 사람이 검증한 500개만 뽑은 서브셋이 바로 Verified입니다.2 문제 수가 줄어든 만큼 빠르게 실험하기 좋았고, 그래서 더 많은 팀이 달려들었습니다. 문제는 "많이 쓰인 벤치마크는 빨리 닳는다"는 점입니다. 유명해질수록 학습 데이터에 섞일 확률이 올라가고, 점수 경쟁이 과열될수록 벤치마크에 과적합하기 쉬워집니다.
대안으로 떠오른 SWE-bench Pro: 더 느리고 더 현실적인 코딩 평가
OpenAI가 추천하는 대안으로 가장 자주 언급되는 것이 SWE-bench Pro입니다.1 Pro는 "에이전트가 실제 개발처럼 일할 수 있나"에 초점을 맞춰 설계를 갈아엎었습니다. 작업이 길어지고(롱호라이즌), 여러 파일을 동시에 만지고, 환경 재현성을 도커 기반으로 고정하는 식이죠.3 그리고 핵심은 오염을 줄이려는 장치입니다. Pro는 GPL 계열 라이선스의 공개 저장소와, 아예 비공개 기업 코드(프라이빗 세트)까지 섞어 "어디선가 봤던 코드"로 찍어 맞히기 어렵게 만듭니다.3
체감 난이도는 점수로도 드러납니다. Verified에서 70%+가 흔한데, Pro(공개 세트)를 Scale의 통일 스캐폴드로 돌리면 상위 모델도 20%대 초반 수준이라는 결과가 보고됐습니다.3 즉 Pro는 "모델이 코딩을 잘한다"를 쉽게 칭찬해주지 않는 벤치마크에 가깝습니다. 개발자 입장에서는 오히려 이게 반갑습니다. 실서비스에서 겪는 고통은 한두 줄 수정이 아니라, 코드베이스를 탐색하고 영향 범위를 계산하며, 테스트가 통과될 때까지 맥락을 유지하는 능력이니까요.
시사점: 이제는 '점수'보다 '평가 방식'을 봐야 한다
이번 이슈가 주는 메시지는 단순합니다. "SWE-bench Verified 몇 점"만으로 AI 코딩 모델을 고르는 시대가 저물고 있다는 것. 앞으로는 벤치마크를 볼 때도 체크리스트가 바뀌어야 합니다.
먼저 오염 저항이 있는지 보세요. 공개 저장소 기반 벤치마크는 점점 더 '이미 본 문제'가 될 가능성이 큽니다. 그래서 Pro처럼 라이선스/비공개 세트를 섞거나, 아예 기업 내부의 비공개 테스트로 검증하는 흐름이 강해질 겁니다.13
다음으로는 스캐폴드 영향(에이전트 구조)을 분리해서 보세요. "모델 점수"인지 "도구·검색·메모리·워크플로우 점수"인지가 섞이면, 현장 적용에서 기대치가 흔들립니다. Pro가 강조하는 것도 결국 에이전트의 실제 작업 능력, 즉 '소프트웨어 엔지니어링'에 가까운 종합 역량입니다.3
마지막으로, 여러분이 모델을 쓰는 목적에 맞는 미니 테스트를 꼭 만드세요. 우리 서비스의 언어, 프레임워크, 테스트 문화, 배포 방식은 벤치마크 평균과 다릅니다. 작은 버그 5개, 기능 추가 2개처럼 "우리 코드에서 실제로 생기는 일"을 뽑아 비교해보면, 리더보드보다 빠르게 결론이 납니다.
참고
1OpenAI wants to retire the AI coding benchmark that everyone has been competing on
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.
