2024년 8월 SWE-bench Verified를 처음 발표한 이후, 업계에서는 자율 소프트웨어 엔지니어링 작업에 대한 모델의 발전을 측정하는 데 이를 널리 사용해 왔습니다. 출시 이후, SWE-bench Verified는 역량 향상의 강력한 지표를 제공했으며 프런티어 모델 출시 시 보고되는 표준 지표가 되었습니다. 이러한 역량의 발전을 추적하고 예측하는 것은 OpenAI의 준비성 평가 프레임워크의 중요한 부분이기도 합니다. 처음 Verified 벤치마크를 구축할 당시, SWE-bench 데이터세트(새 창에서 열기)에서 특정 작업 완료를 불가능하게 만들었던 원본 평가의 문제점을 해결하고자 했습니다.
초기의 비약적인 성장 이후 SWE-bench Verified의 최고 성능(SOTA) 향상세가 둔화되어, 지난 6개월 동안 74.9%에서 80.9%로 향상되는 데(새 창에서 열기) 그쳤습니다 이는 남은 실패 사례가 모델의 한계를 반영하는 것인지, 아니면 데이터세트 자체의 특성 때문인지 의문을 제기합니다.
새로운 분석 결과, Verified 데이터세트에서 두 가지 주요 문제를 발견했습니다. 이는 현재의 성능 수준에서 프런티어 모델 출시에 수반되는 자율 소프트웨어 엔지니어링 역량 발전을 측정하는 데 해당 벤치마크가 더 이상 적합하지 않음을 시사합니다.
- 올바른 해결책을 거부하는 테스트: 모델이 종종 해결에 실패하는 데이터세트의 27.6% 하위 집합을 감사했습니다. 그 결과, SWE-bench Verified를 처음 구축할 당시 이 부분을 개선하고자 최선의 노력을 다했음에도 불구하고, 감사 대상 문제 중 최소 59.4%에 기능적으로 올바른 제출물을 거부하는 결함 있는 테스트 케이스가 존재한다는 사실을 발견했습니다.
- 해답 학습: 대규모 프런티어 모델은 학습 과정을 통해 정보를 습득할 수 있으므로, 평가 대상이 되는 문제와 해답으로 모델을 절대 학습시키지 않는 것이 중요합니다. 이는 앞으로 치를 시험의 문제와 해답을 시험 전에 학생에게 공유하는 것과 같습니다. 정답을 통째로 외우지는 않더라도, 해답을 미리 본 학생은 그렇지 않은 학생보다 당연히 더 좋은 성적을 거둘 것입니다. SWE-bench 문제는 많은 모델 제공업체가 학습 목적으로 사용하는 오픈 소스 리포지터리에서 추출됩니다. 이번 분석 결과, 테스트한 모든 프런티어 모델이 정답 기준으로 사용된, 사람이 작성한 원본 버그 수정(골드 패치)을 재현해 내거나 특정 작업의 문제 명세 세부 사항을 글자 그대로 재현할 수 있었으며, 이는 모든 모델이 학습 과정에서 최소한 일부 문제와 해답을 접했음을 나타냅니다.
또한, 학습 과정에서 문제를 접한 모델은 명세가 불충분한 테스트를 통과하는 데 필요한 추가 정보를 가지고 있기 때문에 성공할 가능성이 더 높다는 증거도 발견했습니다.
이는 SWE-bench Verified 점수의 향상이 모델의 실제 소프트웨어 개발 능력에 있어 유의미한 향상을 더 이상 반영하지 않음을 의미합니다. 오히려, 모델이 학습 과정에서 해당 벤치마크에 얼마나 노출되었는지를 점점 더 반영하고 있습니다. 이것이 OpenAI가 SWE-bench Verified 점수 보고를 중단한 이유이며, 다른 모델 개발사에도 동일하게 조치할 것을 권장합니다.
코딩 능력을 더 잘 추적하기 위해 오염되지 않은 새로운 평가 지표를 구축하고 있으며, 이는 더 넓은 연구 커뮤니티가 집중해야 할 중요한 분야라고 생각합니다. 그러한 평가가 마련될 때까지, OpenAI는 SWE-bench Pro 결과를 보고할 것을 권장합니다.
원본 SWE-bench(새 창에서 열기) 평가는 2023년에 공개되었습니다. 각 문제는 12개의 오픈 소스 Python 리포지터리 중 하나에서 해결된 GitHub 이슈로부터 가져오며, 해당 풀 리퀘스트(PR)와 짝을 이룹니다. 모델이 생성한 코드 변경 사항이 올바른지 판단하기 위해, 각 문제에는 두 가지 테스트 세트가 함께 제공됩니다.
- 수정되지 않은 코드베이스에서는 실패하지만, 문제가 올바르게 수정되면 통과하는 테스트
- 버그 수정과 무관한 기존 기능이 손상되지 않고 유지됨을 보장하기 위해, 수정 전후에 모두 통과해야 하는 회귀 테스트
모델에게는 이 테스트 코드가 제공되지 않습니다. 원본 이슈 텍스트와 수정 전 리포지터리 상태만 주어진 환경에서 코드 수정안을 생성해야 합니다. 코드 변경 사항이 적용된 후 모든 테스트를 통과해야만 해당 문제를 통과한 것으로 간주됩니다.
해당 평가에서 모델의 역량을 과소평가하게 만들 수 있는 여러 문제를 발견했습니다.
- 일부 단위 테스트는 지나치게 구체적이거나 작업 목적과 어긋나 있어, 올바른 수정안마저 거부될 수 있었습니다.
- 많은 작업 명세가 불충분하여 여러 타당한 해석이 가능했지만, 테스트는 그중 특정 해석 하나만을 다루었습니다.
- 환경 설정(예: Linux와 Windows의 차이, 또는 Python 버전)에 따라 일부 테스트가 실제 오류가 없는데도 실패할 수 있었습니다.
이러한 문제를 해결하기 위해 2024년에 SWE-bench Verified를 구축했습니다. 전문 소프트웨어 엔지니어와 협력하여 1,699개의 SWE-bench 문제를 검토하고, 이러한 문제가 있는 항목을 걸러냈습니다. 각 문제는 3명의 전문가가 독립적으로 검토했습니다. 이 검토 과정을 거쳐 엄선된 500개의 문제 세트인 SWE-bench Verified가 만들어졌습니다.
SWE-bench Verified가 초기 버전에 비해 크게 개선되긴 했지만, 여전히 문제가 남아있습니다. 64회의 독립적인 실행에서 OpenAI o3가 일관되게 해결하지 못한 138개의 SWE-bench Verified 문제를 대상으로 감사를 진행했습니다. 각 사례는 최소 6명의 숙련된 소프트웨어 엔지니어가 독립적으로 검토했습니다. 전문가가 문제를 지적하면 별도의 팀에서 이를 재검증했습니다.
그 결과, 138개의 문제 중 59.4%가 테스트 설계 및/또는 문제 설명에 중대한 결함을 포함하고 있어, 가장 뛰어난 모델이나 사람조차도 해결하는 것이 매우 어렵거나 불가능하다는 사실을 발견했습니다.
- 감사 대상 작업의 35.5%에는 특정 구현 세부 사항을 강제하여 기능적으로 올바른 다수의 제출물을 무효화하는 엄격한 테스트 케이스가 포함되어 있으며, 이를 제한적인 테스트 케이스라고 부릅니다.
- 감사 대상 작업의 18.8%에는 문제 설명에 명시되지 않은 추가 기능을 검사하는 테스트가 포함되어 있으며, 이를 광범위한 테스트 케이스라고 부릅니다.
- 나머지 5.1%의 작업에는 이 분류 기준에 명확하게 속하지 않는 기타 문제가 있었습니다.
첫 번째 실패 유형을 잘 보여주는 예는 pylint-dev__pylint-4551(새 창에서 열기)로, 해당 PR에서는 전체 해결책의 일환으로 `get_annotation`이라는 새로운 함수를 도입합니다. 이 함수 이름은 문제 명세에 언급되어 있지 않지만, 테스트 코드에서 직접 임포트합니다. 일부 모델이 스스로 유추하여 이러한 함수를 작성할 수도 있겠지만, 문제를 올바르게 해결하기 위해 이 특정 이름의 함수를 반드시 구현해야 하는 것은 아닙니다. 많은 유효한 해결책이 임포트 오류로 인해 테스트에 실패합니다.
문제 설명
PR 테스트 스니펫
PR 테스트 실패(가독성을 위해 일부 생략됨)
너무 광범위한 테스트 케이스의 예로는 sympy__sympy-18199(새 창에서 열기)가 있습니다. 이 작업은 `nthroot_mod` 함수와 관련된 세 가지 별개의 이슈인 #17373(새 창에서 열기), #17377(새 창에서 열기), #18212(새 창에서 열기)를 해결한 PR에서 가져왔습니다. 하지만 SWE-bench Verified 작업의 설명은 마지막 이슈인 #18212(새 창에서 열기)만을 다룹니다. 이는 불일치를 초래합니다. PR 테스트는 세 가지 이슈를 모두 다루는 반면, 설명은 단 하나의 이슈만 상세히 기술합니다. 실행 과정에서 여러 모델이 종종 설명된 수정 사항을 올바르게 구현하고도 나머지 두 이슈의 구현을 다루는 테스트에서 실패했습니다.
원본 PR 설명(GitHub PR 발췌)
#18212의 문제 설명
SWE-bench Verified 작업의 문제 설명(#18212에서만 발췌됨):
SWE-bench Verified와 해당 리포지터리(코드베이스 및 릴리스 노트)는 모두 오픈 소스이며 널리 사용 및 논의되고 있어, 모델 개발자 입장에서 데이터 오염을 피하기는 어렵습니다.
자체 모델에서 처음으로 오염 징후를 발견했습니다. 예를 들어, 해결이 거의 불가능하다고 판단했던 31개의 작업을 GPT‑5.2가 해결한 경우가 그렇습니다. django__django-14725(새 창에서 열기)에서 테스트는 문제 명세에서 명시적으로 요구하지 않은 `edit_only`라는 특정 새 매개변수를 요구합니다. 문제를 해결하는 동안 GPT‑5.2는 자신의 추론 과정에서 코드베이스의 변경 사항을 상세히 설명하는 릴리스 노트에 대한 정보를 가지고 있음을 보여주며, `edit_only` 매개변수가 Django 4.1에 도입되었다는 사실을 정확하게 파악합니다.
GPT‑5.2 CoT
오염이 전반적으로 얼마나 심각한지 평가하기 위해 자동화된 레드팀 테스트 환경을 구축했습니다. 각 SWE-bench Verified 문제에 대해 GPT‑5에 GPT‑5.2‑Chat, Claude Opus 4.5, Gemini 3 Flash Preview의 오염 여부를 조사하도록 지시했습니다. 이러한 모델은 추론 모델을 배제하기 위해 선택되었으나, 이들 사이에는 무시할 수 없는 역량 차이가 존재할 수 있음을 인정합니다.
오염 여부를 조사하기 위해 GPT‑5는 SWE-bench Verified 작업의 ID, 설명, 골드 패치 및 PR 테스트를 제공받았습니다. 총 15턴에 걸쳐 GPT‑5가 시스템/개발자 프롬프트, 사용자 프롬프트, 어시스턴트 사전 입력 및 다양한 유도 전략을 변경할 수 있도록 허용했습니다. 각 턴이 끝난 후 평가 모델은 작업에 특화된 새로운 정보가 얼마나 나타났는지 판별했으며, 각 응답의 오염 심각도를 '없음'에서 '강함'으로 레이블링했습니다. GPT‑5는 이전 턴을 바탕으로 전략을 조정하여 작업별 세부 정보를 반복적으로 복원할 수 있었습니다. 각 심각한 오염 사례에 대해 또 다른 평가 모델을 통해 GPT‑5가 대상 모델에 너무 많은 정보를 유출하지 않았는지 검증했습니다. 마지막으로 이 게시물의 대화 기록을 구성하는 오염도가 '강함'으로 분류된 사례를 직접 검토했습니다.
아래는 다양한 모델 제공업체 전반에서 나타난 심각한 오염 사례입니다.
작업 설명의 짧은 스니펫만 주어져도, GPT‑5.2는 정확한 골드 패치를 출력합니다. 특히, 이 모델은 정확한 클래스 및 메서드 이름과 새롭게 도입된 조기 반환 조건인 `if username is None or password is None`을 알고 있습니다.
오염 발현 유도
골드 패치
Opus는 PR이 도입한 기능을 수정한 4줄의 실제 코드와 수정된 특정 파일명 및 메서드를 정확히 기억해 낼 뿐만 아니라, diff에 포함되어 있던 인라인 주석까지 글자 그대로 인용할 수 있습니다.
오염 발현 유도
골드 패치
Gemini 3 Flash는 작업 ID 외에 작업에 대한 추가 정보가 주어지지 않았음에도, 작업 설명과 골드 패치의 세부 내용을 글자 그대로 출력할 수 있습니다. 여기에는 사용자 이름 유효성 검사를 위한 새로운 정규식과 변경 사항의 정확한 줄 번호가 포함됩니다.
오염 발현 유도
골드 패치
이번 SWE-bench Verified 감사를 통해, 평가 설계에 대한 두 가지 포괄적인 교훈을 얻을 수 있었습니다. 첫째, 공개적으로 이용 가능한 자료에서 추출한 벤치마크는 오염 위험을 수반하며, 이 경우 학습 데이터 노출이 알게 모르게 점수를 부풀릴 수 있습니다. 벤치마크 구축에 공개적으로 크롤링한 데이터를 사용하는 경우, 모델 개발자는 오염 여부를 확인하기 위한 추가 테스트를 수행해야 합니다. 공개적으로 게시된 벤치마크와 그 해답조차도 결국 학습 데이터에 포함될 수 있습니다. 데이터세트를 게시하는 방식(예: 비밀번호 보호) 및 학습 데이터 필터링(예: 카나리아 문자열 엄수) 양쪽 모두에 각별한 주의를 기울여야 합니다.
둘째, 자동화된 채점을 제대로 구현하는 것은 까다롭습니다. 완벽한 테스트 케이스라면 중요하지 않은 세부 구현 방식에 구애받지 않으면서도, 편법적인 해결책을 방어할 만큼 견고하게 기능의 정상 작동 여부를 온전히 검증해야 합니다. 이러한 문제는 본질적으로 복잡하고 해결하기 어렵습니다. 이러한 문제를 찾아내는 데는 여러 차례에 걸친 대규모 수동 레이블링 작업이 필요했습니다.
이러한 발견 사항을 최근의 내부 평가 작업에 반영했습니다. 최근 몇 달 동안 SWE-bench Pro의 공개 평가 데이터 결과를 보고하기로 결정했습니다. 다른 모델 개발자 역시 동일한 조치를 취하기를 권장합니다. SWE-bench Pro가 완벽하지는 않지만, 경험적으로 볼 때 오염 문제의 영향을 덜 받는 것으로 보입니다. 내부 오염 검증 파이프라인에서 일부 오염 사례가 발견되긴 했으나, 이러한 사례는 SWE-bench Verified에 비해 훨씬 드물고 덜 심각했으며, 어떤 모델도 글자 그대로 완벽하게 일치하는 골드 패치를 생성하지는 못했습니다.
독창적이고 비공개로 작성된 벤치마크에 지속적으로 투자할 것이며, 업계와 학계에도 이에 동참해 줄 것을 요청합니다. GDPVal에서는 도메인 전문가가 비공개로 작업을 작성하여 노출 위험을 줄이고, 훈련된 평가자가 솔루션을 종합적으로 채점합니다. 이러한 접근 방식은 리소스가 많이 소모되지만, 실질적인 역량 향상을 측정하기 위해 점차 필수적인 요소가 되고 있습니다.
작성자
더 읽어보기
