OpenAI가 SWE-bench Verified를 버린 이유 - AI 코딩 평가의 한계가 드러나다

벤치마크가 "포화"되면 생기는 일

OpenAI가 자사 블로그에 흥미로운 글을 올렸어요. 한동안 AI 코딩 능력의 표준 척도로 쓰이던 SWE-bench Verified라는 벤치마크를, 더 이상 자기들 모델 평가의 주요 지표로 쓰지 않겠다는 선언이에요. 왜 이게 의미 있는지 풀어볼게요.

SWE-bench가 뭐냐면, 깃허브의 실제 오픈소스 저장소에서 가져온 이슈와 그에 대응하는 PR(풀 리퀘스트)을 모아놓은 데이터셋이에요. 모델한테 "이 이슈를 해결하는 코드 패치를 만들어봐"라고 시키고, 해당 PR의 테스트가 통과하는지로 채점하죠. Verified는 그중에서도 사람이 한 번 더 검수해서 "진짜 풀 만한 문제"만 추린 버전이고요. 한동안 "50%만 맞춰도 대단하다" 했던 게, 최근에는 프론티어 모델들이 70~80%대를 우습게 찍기 시작했어요.

왜 더 이상 의미가 없다는 건가

핵심 이유 몇 가지가 있어요.

첫째, 점수가 천장에 닿았어요. 최신 모델들이 80%를 넘기면서 모델 간 차이가 잘 드러나지 않게 됐죠. A 모델이 82%, B 모델이 84%라고 했을 때 그 차이가 진짜 능력 차인지, 아니면 데이터셋의 노이즈인지 구분하기 어려워졌습니다. 머신러닝에서는 이걸 "벤치마크가 포화됐다(saturated)"고 표현해요.

둘째, 데이터 오염 문제가 커요. SWE-bench에 쓰이는 PR들은 깃허브에 공개돼 있어요. 그런데 요즘 LLM들은 깃허브 코드를 학습 데이터로 빨아들이거든요. 즉, 모델이 "이 이슈는 본 적 있고, 정답 패치도 본 적 있는" 상태에서 푸는 셈이 될 수 있어요. 시험 문제가 미리 유출된 시험을 보는 거랑 비슷하죠.

셋째, 실제 개발 작업과 너무 다르다는 점. 진짜 엔지니어는 이슈 하나만 보고 패치를 짜지 않아요. 코드베이스를 탐색하고, 동료에게 물어보고, 테스트를 새로 쓰고, 트레이드오프를 따지고, 버그를 재현하는 환경을 셋업하죠. SWE-bench는 "문제 → 패치"라는 단편적 작업이라 이런 다층적 능력을 측정 못 해요.

넷째, 평가가 뚫리기 쉬운 구조. 일부 에이전트는 테스트 케이스 자체를 보고 거기에 맞춰 코드를 짜는 "치팅성" 트릭을 쓸 수도 있어요. 정답을 진짜로 푼 게 아니라, 채점기를 통과하는 패턴을 학습한 거죠.

그럼 대안은 뭔데

OpenAI 글에서 읽히는 방향은 더 길고, 더 현실적이고, 검증이 어려운 작업으로 옮겨가자는 거예요. 예를 들어 며칠짜리 멀티 스텝 작업, 환경 셋업부터 PR 머지까지 전 과정을 다루는 작업, 모호한 명세에서 시작해 스펙을 명확히 만드는 작업 같은 것들이죠.

비교해볼 만한 다른 벤치마크들도 있어요. METR라는 곳에서는 AI 에이전트가 한 번에 얼마나 긴 작업을 처리할 수 있는지(작업 길이의 시간 단위)를 측정해요. TerminalBench는 셸 환경에서의 진짜 작업을 측정하고요. LiveCodeBench는 새로 출제된 알고리즘 문제로 데이터 오염을 줄이려는 시도예요. SWE-bench Multimodal, SWE-Lancer처럼 SWE-bench의 후속작도 나오고 있고요.

비유하자면, 옛날에는 "100m 달리기 기록"으로 운동선수를 평가했는데 모두가 9초대를 찍으니까 변별이 안 되는 상황이 된 거예요. 그래서 이제 마라톤이나 철인 3종을 해보자는 흐름인 거죠.

한국 개발자에게 주는 시사점

AI 코딩 도구를 도입하거나 평가할 때 "벤치마크 점수"만 보고 결정하지 마세요. 80%, 90% 같은 숫자는 마케팅용으로 쓰이지만, 정작 우리 회사 코드베이스에서 잘 동작할지는 별개의 문제예요. 가장 좋은 평가는 "우리 팀의 실제 이슈 5~10개를 골라서 직접 시켜보는 것" 입니다. 이게 말 그대로 "우리만의 미니 벤치마크"가 되거든요.

또 한 가지, AI 코딩 에이전트 시장이 짧은 작업에서 긴 작업으로 옮겨가고 있다는 신호로 읽으세요. 함수 하나 짜주는 수준은 이미 평준화됐고, 앞으로의 차별점은 "하루치 작업을 알아서 진행하는" 능력이 될 거예요. Claude Code, Cursor, Devin, Codex 같은 도구들의 경쟁 축도 거기로 옮겨가고 있어요. 직접 써보면서 어떤 도구가 우리 워크플로에 맞는지 익혀두는 게 실전에서 큰 차이를 만듭니다.