🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

OpenAI는 SWE-bench Verified가 결함 있는 테스트와 훈련 데이터 오염 때문에 더 이상 최전선 코딩 모델의 실제 소프트웨어 개발 능력 향상을 신뢰성 있게 측정하지 못한다고 주장한다.

📌 핵심 요약

• SWE-bench Verified는 2024년 공개 이후 자율 소프트웨어 엔지니어링 능력을 측정하는 표준 지표처럼 쓰였지만, 최근 최상위 모델의 점수 향상이 둔화되면서 남은 실패가 모델 한계인지 데이터셋 문제인지가 핵심 쟁점이 되었다.
• OpenAI의 새 분석은 두 가지 큰 문제를 제시한다. 하나는 일부 테스트가 기능적으로 맞는 풀이도 거부한다는 점이고, 다른 하나는 공개 저장소 기반 문제와 해답이 모델 훈련 데이터에 포함되어 평가 오염을 일으킬 수 있다는 점이다.
• OpenAI는 모델들이 자주 실패한 138개 문제를 감사했고, 그중 59.4%에서 테스트 설계나 문제 설명에 중대한 결함이 있다고 밝혔다. 특히 특정 구현 방식을 강제하는 좁은 테스트와, 문제 설명에 없는 추가 기능까지 요구하는 넓은 테스트가 주요 원인으로 제시됐다.
• 오염 문제도 심각하게 다뤄진다. OpenAI는 GPT-5.2, Claude Opus 4.5, Gemini 3 Flash Preview 등을 대상으로 자동화된 레드팀 절차를 수행했고, 일부 모델이 원래 인간이 작성한 골드 패치나 문제별 세부 정보를 재현할 수 있다는 증거를 제시했다.
• 따라서 OpenAI는 SWE-bench Verified 점수 상승이 더 이상 실제 코딩 능력 향상을 의미하기보다, 모델이 벤치마크 문제와 해답에 얼마나 노출되었는지를 반영할 가능성이 커졌다고 보고, SWE-bench Verified 보고를 중단하고 SWE-bench Pro 사용을 권고한다.

🧩 주요 포인트

1. SWE-bench Verified는 2024년 공개 이후 자율 소프트웨어 엔지니어링 능력을 측정하는 표준 지표처럼 쓰였지만, 최근 최상위 모델의 점수 향상이 둔화되면서 남은 실패가 모델 한계인지 데이터셋 문제인지가 핵심 쟁점이 되었다.
2. OpenAI의 새 분석은 두 가지 큰 문제를 제시한다. 하나는 일부 테스트가 기능적으로 맞는 풀이도 거부한다는 점이고, 다른 하나는 공개 저장소 기반 문제와 해답이 모델 훈련 데이터에 포함되어 평가 오염을 일으킬 수 있다는 점이다.
3. OpenAI는 모델들이 자주 실패한 138개 문제를 감사했고, 그중 59.4%에서 테스트 설계나 문제 설명에 중대한 결함이 있다고 밝혔다. 특히 특정 구현 방식을 강제하는 좁은 테스트와, 문제 설명에 없는 추가 기능까지 요구하는 넓은 테스트가 주요 원인으로 제시됐다.
4. 오염 문제도 심각하게 다뤄진다. OpenAI는 GPT-5.2, Claude Opus 4.5, Gemini 3 Flash Preview 등을 대상으로 자동화된 레드팀 절차를 수행했고, 일부 모델이 원래 인간이 작성한 골드 패치나 문제별 세부 정보를 재현할 수 있다는 증거를 제시했다.
5. 따라서 OpenAI는 SWE-bench Verified 점수 상승이 더 이상 실제 코딩 능력 향상을 의미하기보다, 모델이 벤치마크 문제와 해답에 얼마나 노출되었는지를 반영할 가능성이 커졌다고 보고, SWE-bench Verified 보고를 중단하고 SWE-bench Pro 사용을 권고한다.

🧠 상세 정리

1. SWE-bench Verified가 표준 지표가 된 배경

OpenAI는 SWE-bench Verified가 2024년 8월 처음 공개된 뒤 업계에서 자율 소프트웨어 엔지니어링 작업의 모델 진전을 측정하는 데 널리 사용되었다고 설명한다. 이 벤치마크는 프런티어 모델 출시 때 자주 보고되는 표준 지표가 되었고, OpenAI의 Preparedness Framework에서도 관련 역량의 추적과 예측이 중요한 요소로 다뤄졌다. 원래 Verified 버전은 기존 SWE-bench 데이터셋에서 일부 문제가 실제로 해결 불가능하거나 평가가 부정확해지는 문제를 줄이기 위해 만들어졌다. 즉 출발점은 더 공정하고 신뢰할 수 있는 코딩 평가를 만들려는 개선 작업이었다.

2. 최근 점수 둔화가 제기한 질문

초기에는 SWE-bench Verified에서 최신 모델 성능이 크게 뛰었지만, 이후 최상위 성능의 향상 속도는 둔화되었다. 원문은 최근 6개월 동안 점수가 74.9%에서 80.9%로 개선되는 데 그쳤다고 제시하며, 이 상황이 중요한 질문을 낳는다고 말한다. 남은 실패들이 정말 모델의 한계를 보여주는지, 아니면 데이터셋 자체의 속성 때문에 발생하는지를 구분해야 한다는 것이다. OpenAI의 결론은 현재 성능 수준의 프런티어 모델 출시를 평가하기에는 Verified 세트가 더 이상 적합하지 않다는 쪽으로 기운다.

3. 두 가지 핵심 문제: 결함 있는 테스트와 훈련 오염

OpenAI가 제시한 핵심 문제는 크게 두 가지다. 첫째, 모델이 기능적으로 올바른 해법을 제출해도 테스트가 이를 거부하는 경우가 많다는 점이다. 둘째, SWE-bench 문제들이 오픈소스 저장소에서 온 만큼 대형 모델이 훈련 과정에서 문제와 해답을 접했을 가능성이 있다는 점이다. 원문은 이것을 시험 전에 학생에게 문제와 해답을 보여주는 것에 비유한다. 학생이 답을 그대로 외우지 않더라도, 이미 본 적이 있는 학생은 그렇지 않은 학생보다 유리해질 수 있다는 설명이다.

4. 원래 SWE-bench와 Verified 버전의 평가 방식

원래 SWE-bench는 2023년에 공개되었고, 12개의 오픈소스 파이썬 저장소에서 해결된 GitHub 이슈와 대응되는 풀 리퀘스트를 바탕으로 문제를 구성했다. 모델은 테스트를 보지 못한 상태에서 원래 이슈 설명과 수정 전 저장소 상태만 보고 코드 변경을 만들어야 한다. 평가는 수정 전에는 실패하지만 올바른 수정 후에는 통과해야 하는 테스트와, 기존 기능이 깨지지 않았는지 확인하는 회귀 테스트로 이루어진다. OpenAI는 기존 평가에 과도하게 구체적인 테스트, 불충분한 문제 설명, 환경 차이에 따른 우발적 실패 같은 문제가 있었다고 보고, 전문가 검토를 통해 1,699개 문제를 살펴 500개 문제로 구성된 SWE-bench Verified를 만들었다.

5. Verified에도 남은 테스트 설계 결함

Verified는 초기 SWE-bench보다 개선된 평가였지만, OpenAI는 여전히 남은 결함이 크다고 분석한다. 이들은 OpenAI o3가 64회의 독립 실행에서 일관되게 풀지 못한 138개 문제를 감사했고, 각 사례를 최소 여섯 명의 경험 많은 소프트웨어 엔지니어가 독립적으로 검토하게 했다. 그 결과 감사 대상의 59.4%에서 테스트 설계나 문제 설명에 중대한 문제가 있어, 가장 강력한 모델이나 사람에게도 매우 어렵거나 불가능한 과제로 판정될 수 있다고 밝혔다. 이는 전체 데이터셋 전체에 대한 수치가 아니라, 모델이 자주 실패한 27.6% 부분집합에 대한 감사 결과라는 점이 중요하다.

6. 좁은 테스트와 넓은 테스트의 구체적 양상

OpenAI는 결함 유형을 크게 좁은 테스트와 넓은 테스트로 나눈다. 감사된 과제 중 35.5%는 특정 구현 세부사항을 강제해 기능적으로 맞는 여러 풀이를 배제하는 좁은 테스트를 가지고 있었다. 예시로 pylint-dev__pylint-4551에서는 문제 설명에 언급되지 않은 get_annotation 함수명을 테스트가 직접 import하기 때문에, 같은 문제를 올바르게 고쳐도 해당 이름의 함수를 만들지 않으면 실패할 수 있다. 반대로 18.8%는 문제 설명에 없는 추가 기능까지 검사하는 넓은 테스트였고, sympy__sympy-18199 사례에서는 설명은 하나의 이슈만 다루지만 PR 테스트는 세 개의 별도 이슈를 함께 검사해 모델이 설명된 수정만 정확히 구현해도 실패할 수 있었다.

7. 오픈소스 기반 벤치마크의 오염 위험

원문은 SWE-bench Verified와 그 기반 저장소, 코드베이스, 릴리스 노트가 모두 공개되어 있고 널리 사용·논의된다는 점 때문에 오염을 피하기 어렵다고 말한다. OpenAI는 자체 모델에서 먼저 오염 징후를 발견했다고 설명한다. 예를 들어 GPT-5.2가 거의 해결 불가능하다고 분류된 31개 과제를 풀었고, django__django-14725에서는 문제 설명에 명시되지 않은 edit_only 매개변수를 알아내는 정황이 제시됐다. 원문은 모델의 추론 내용에 Django 4.1에서 해당 매개변수가 도입되었다는 릴리스 노트 관련 정보가 나타났다고 설명하며, 이것이 평가 대상 문제에 대한 사전 노출 가능성을 보여준다고 본다.

8. 레드팀 방식의 오염 탐지와 OpenAI의 권고

OpenAI는 오염이 얼마나 넓은지 평가하기 위해 자동화된 레드팀 절차를 만들었다. 각 SWE-bench Verified 질문에 대해 GPT-5가 과제 ID, 설명, 골드 패치, PR 테스트 정보를 받은 뒤 GPT-5.2-Chat, Claude Opus 4.5, Gemini 3 Flash Preview를 대상으로 오염을 탐지하도록 했다. 15턴 동안 시스템·개발자·사용자 프롬프트와 assistant prefill, 여러 유도 전략을 바꾸게 했고, 판정 모델이 새롭게 나타난 과제별 정보와 오염 강도를 평가했다. OpenAI는 일부 강한 오염 사례를 수동 검토했으며, 이런 이유로 SWE-bench Verified 점수 보고를 중단했고 다른 개발자들에게도 중단을 권하며, 새 평가가 마련되기 전까지 SWE-bench Pro 결과 보고를 추천한다고 결론낸다.

🧾 핵심 주장 / 시사점

• 이 글의 핵심은 벤치마크 점수가 높아질수록 평가 자체의 결함과 오염 문제가 더 큰 비중을 차지할 수 있다는 점이다. 낮은 성능 구간에서는 대략적인 진전 신호가 되던 지표도, 최상위 성능 구간에서는 남은 실패의 원인이 모델이 아니라 데이터셋일 수 있다.
• OpenAI가 제시한 좁은 테스트와 넓은 테스트 사례는 코드 평가에서 ‘정답’이 단일 구현으로 고정되면 실제 개발 능력을 과소평가할 수 있음을 보여준다. 반대로 문제 설명에 없는 기능까지 테스트하면 모델은 주어진 요구사항을 충실히 해결하고도 실패한다.
• 오픈소스 이슈와 PR을 기반으로 한 벤치마크는 현실적인 과제를 제공한다는 장점이 있지만, 프런티어 모델 훈련 데이터와 겹칠 위험이 크다. 따라서 앞으로의 코딩 평가는 공개성, 재현성, 비오염성을 동시에 만족시키는 새 설계가 중요해진다.

✅ 액션 아이템

• SWE-bench Verified의 정체 구간을 성능 한계로 단정하지 않고, 138개 감사 대상 중 59.4% 결함 비율을 기준으로 실패 원인을 분해한다.
• 기능적으로 맞는 풀이를 거부하는 케이스를 좁은 테스트와 넓은 테스트로 분리해, 구현 방식 강제성과 문제 설명 누락 요구를 점검한다.
• 훈련 데이터 오염 우려와 레드팀 재현 증거를 반영해 GPT-5.2·Claude Opus 4.5·Gemini 3 Flash Preview 사례를 기준으로 SWE-bench Pro 전환 필요성을 정리한다.

❓ 열린 질문

• 상위 모델의 잔여 실패가 모델 한계인지 SWE-bench Verified 결함인지 구분하는 실효적 기준은 무엇인가?
• 공개 저장소 기반 문제·해답의 학습 데이터 오염 신호가 어느 수준에서 점수 신뢰도를 무너뜨렸는지 어떻게 판단할 것인가?
• SWE-bench Verified를 중단하고 SWE-bench Pro를 채택할 때, 실제 코딩 능력 반영도를 가장 잘 검증할 비교 방법은 무엇인가?