2026년 7월 8일

코딩 평가에서 유의미한 신호와 노이즈 구분하기

상세한 감사를 통해 SWE-Bench Pro 전반에서 작업의 문제가 광범위하게 존재한다는 사실을 확인했으며, 전체 작업의 약 30%에 결함이 있는 것으로 추정했습니다.

로딩 중...

모델의 역량을 정확하게 측정하는 것은 OpenAI의 준비성 평가 프레임워크⁠(새 창에서 열기)에 따른 의사결정을 포함해, 적절한 배포 및 안전성 관련 의사결정을 내리는 데 매우 중요합니다. OpenAI는 새로운 모델을 출시할 때마다 다양한 외부 및 내부 벤치마크 결과를 공개해 모델의 발전 상황을 추적합니다. 그러나 평가 결과에 영향을 미치는 결함이 있으면 모델의 역량을 잘못 이해하게 만들고, 안전성에 대한 판단을 왜곡하며, 연구 우선순위에도 영향을 미칠 수 있습니다.

최근 OpenAI는 가장 널리 사용되는 코딩 벤치마크 중 하나인 SWE-bench Verified를 조사한 결과, 근본적인 설계 문제와 데이터 오염 문제가 있음을 확인했으며, 해당 평가가 더 이상 소프트웨어 개발 역량을 측정하는 유의미한 기준이 되지 못한다는 결론을 내렸습니다. 당시 OpenAI는 더 넓은 커뮤니티에 SWE-Bench Pro로 전환할 것을 권장했습니다.

SWE-Bench Pro⁠(새 창에서 열기)는 더 긴 기간에 걸친 작업과 실제에 가까운 코딩 과제를 통해 모델을 평가함으로써, 에이전틱 코딩 역량을 더욱 정확하게 측정할 수 있도록 SWE-bench Verified를 개선한 벤치마크입니다. SWE-bench Verified와 마찬가지로 작업은 공개 및 비공개 리포지터리의 기능 변경 이력을 바탕으로 프로그래밍 방식으로 생성됩니다. 모델은 기존 기능을 손상시키지 않으면서 특정 기능에 새롭게 추가된 테스트를 모두 통과하는 해결책을 구현해야 합니다. 731개의 작업으로 구성된 공개 데이터세트에서는 최첨단 모델의 통과율이 8개월 만에 23.3%에서 80.3%로 향상되었습니다.

이후 OpenAI는 SWE-Bench Pro에 대해서도 동일한 방식의 감사를 수행했으며, 데이터 포인트 분석 파이프라인을 사용해 데이터세트를 검토했습니다. 이 파이프라인은 모델의 작업 수행 결과, 작업 메타데이터, 실패 추적 정보를 분석해 평가상의 결함이 의심되는 작업을 식별했습니다. 식별된 각 작업은 조사 에이전트가 여러 차례 검토한 뒤, 숙련된 소프트웨어 엔지니어 5명이 독립적으로 다시 검토했습니다. 의견이 엇갈린 경우에는 추가 조사를 위해 상위 검토로 회부했습니다.

데이터세트의 상당 부분에서 작업에 결함이 있음을 보여 주는 증거를 확인했습니다. 데이터 포인트 분석 파이프라인은 결함이 있는 작업 200개(27.4%)를 식별했으며, 사람 주석 작업에서는 249개(34.1%)를 확인했습니다.

확인된 문제는 크게 네 가지 유형으로 나뉘었습니다.

지나치게 엄격한 테스트¹는 프롬프트에 명시되지 않은 특정 구현 세부 사항까지 요구하기 때문에, 기능적으로 올바른 제출물도 상당수가 정답으로 인정되지 않습니다.
요구 사항이 불충분하게 명시된 프롬프트²에는 숨겨진 테스트에서 확인하는 요구 사항이 일부 빠져 있으며, 이러한 요구 사항은 프롬프트만으로는 합리적으로 추론하기 어렵습니다.
낮은 커버리지의 테스트는 요청된 기능을 충분히 검증하지 않기 때문에, 불완전한 수정도 테스트를 통과할 수 있습니다.
오해를 불러일으키는 프롬프트는 모델이 잘못된 동작을 하도록 유도하거나, 테스트에서 요구하는 내용과 모순됩니다.

이번 분석 결과는 도전적이면서도 공정한 벤치마크를 만드는 일이 쉽지 않다는 점과, 대규모 데이터 품질 검증에서 에이전트의 활용 가치가 점점 커지고 있다는 점을 보여 줍니다. 이러한 결과를 바탕으로 OpenAI는 SWE-Bench Pro 작업의 약 30%에 결함이 있는 것으로 추정하며, 모델 개발자에게는 평가 결과를 신중하게 검토할 것을 권고합니다.

방법론

OpenAI의 목표는 작업 실패는 모델의 실제 한계를, 작업 성공은 프롬프트의 요구 사항을 완전하고 올바르게 충족한 해결책을 반영하도록 하는 것입니다. 이를 위해 평가에 사용되는 데이터의 품질을 검증하고, 각 데이터 포인트가 모델의 역량을 정확하게 반영하는지 평가하는 품질 보증 파이프라인을 구축했습니다.

자동 선별과 사람의 검토를 결합해 작업 품질을 평가하는 품질 보증 워크플로. — 초기 데이터 품질 파이프라인이 검토가 필요한 문제를 식별합니다. 그런 다음 숙련된 엔지니어가 참여하는 사람 주석 작업과 에이전트가 지원하는 심층 감사를 통해 식별된 작업을 검증합니다.

먼저 자동 필터가 모델에 제공된 지침, 모델의 작업 수행 결과, 그리고 이를 채점하는 데 사용된 테스트를 분석해 결함이 있거나 문제가 있을 가능성이 높은 사례를 식별합니다. 이 필터는 결함이 의심되는 작업 286개를 식별했습니다. 이후 이 작업들을 두 가지 방식으로 심층 검토했습니다. 첫 번째는 조사 에이전트가 광범위한 검사를 수행한 뒤 사람이 최종 판단을 내리는 사람이 감독하는 에이전트 검토이며, 두 번째는 숙련된 소프트웨어 개발자가 참여하는 사람 주석 작업입니다.

사람이 감독하는 에이전트 검토

식별된 각 문제는 작업 리포지터리와 실행 환경에 접근할 수 있는 Codex 기반 조사 에이전트를 활용해 감사했습니다. 이를 통해 에이전트는 주변 코드와 리포지터리의 관례를 살펴보면 해결할 수 있는 수준의 모호함과, 실제로 프롬프트에 요구 사항이 충분히 명시되지 않은 경우를 구분할 수 있습니다. 에이전트는 테스트를 실행하고 리포지터리의 파일을 검토하는 것은 물론, 모델의 작업 수행 결과와 그 과정에서 나타나는 대표적인 실패 유형도 분석합니다. 이러한 심층 감사를 여러 차례 독립적으로 수행한 뒤에는 연구자가 결과를 종합해 검토하고 최종 판단을 내린 후, 확인된 문제를 분류했습니다.

사람 주석 작업

이와 동시에 식별된 작업을 대상으로 사람 주석 작업도 진행했습니다. 작업을 검토하기에 앞서 숙련된 소프트웨어 엔지니어들에게 벤치마크의 목표, 문제 분류 체계, 그리고 엣지 케이스에 대한 교육을 실시했으며, 각 작업은 엔지니어 5명이 독립적으로 검토했습니다.

검토자는 먼저 공개된 문제 설명, 테스트 케이스, 그리고 정답 기준이 되는 참조 해결책(gold patch)만을 바탕으로 독립적으로 판단했습니다. 그 이후에만 파이프라인 분석 결과와 기록을 참고 자료로 활용했습니다. 이어서 구체적인 근거를 바탕으로 문제 유형과 심각도를 분류했으며, 의견이 엇갈리거나 판단에 확신이 서지 않는 사례는 추가 검토를 위해 회부했습니다.

사람 검토자는 조사 에이전트보다 작업을 결함이 있는 것으로 판단하는 경향이 더 강했습니다. 두 검토 방식 간에는 문제 유형을 분류하는 과정에서 일부 의견 차이도 있었지만, 식별된 어떤 작업에서도 사람 검토자가 가장 많이 내린 판단은 '결함이 없음'이 아니었습니다. 또한 에이전트 파이프라인이 식별한 문제 유형 가운데 74%는 사람 검토자의 판단과 일치했습니다.

사람 검토자는 에이전트 파이프라인보다 하나의 작업에 여러 문제 유형을 함께 부여하는 경우도 더 많았습니다. 이는 하나의 작업에 여러 문제가 동시에 존재하거나, 하나의 유형만으로는 명확하게 분류하기 어려운 사례가 많았음을 보여 줍니다. 이러한 결과는 에이전트와 사람 검토를 결합한 파이프라인이 다소 보수적으로 문제를 분류했음을 시사합니다. 즉, 사람이 확인한 주요 실패 유형은 대부분 포착했지만, 사람이 추가로 발견한 문제나 여러 문제가 겹쳐 있는 사례는 충분히 반영하지 못했습니다. 가장 큰 차이는 낮은 커버리지의 테스트에서 나타났습니다. 사람 검토자는 전체 벤치마크의 9.4%를 이 유형의 대표적인 문제로 분류한 반면, 에이전트 파이프라인은 4.1%만 식별했습니다.

실패 유형

일부 사례에서는 작업 프롬프트가 특정 구현 방식을 요구했지만, 숨겨진 테스트 케이스는 그와 다른 동작을 요구했습니다.

This task involves normalizing table-of-contents entries and rendering them back to Markdown via TocEntry.to_markdown(). The task prompt specifies serialization down to character-level spacing, describing how exact spacing and pipes are enforced, and gives examples such as " | Chapter 1 | 1" and "** | Chapter 1 | 1":

없음

1"[space]| Chapter 1 | 1"
2"**[space]| Chapter 1 | 1"
3"[space]| Just title | "

The hidden test_to_markdown assertions instead require " | Chapter 1 | 1" and "** | Chapter 1 | 1":

없음

1"[space][space]| Chapter 1 | 1"
2"**[space][space]| Chapter 1 | 1"
3"[space][space]| Just title | "

There are two leading spaces in the hidden tests, but the example given to the model only contains one leading space. If a model rightly follows the given prompt, that one-character difference would fail the hidden test cases and the task would be marked incorrect.

논의

이번 분석에서 확인한 문제와 SWE-bench Verified에서 발견된 유사한 사례는 벤치마크를 철저하게 검증하는 일이 얼마나 중요한지를 보여 줍니다. 오픈소스 리포지터리의 이슈와 pull request는 원래 사람 간의 협업을 위해 만들어진 것으로, 유지 관리자와 기여자가 여러 차례 의견을 주고받으며 발전하는 경우가 많습니다. 따라서 문제 설명, 병합된 코드, 단위 테스트가 항상 서로 일치하는 것은 아니며, 모델을 신뢰성 있게 평가할 수 있는 독립적인 과제로 구성되지 않는 경우도 있습니다. 특히 풀 리퀘스트에 포함된 테스트는 작업을 해결하기 위한 구현 방식과 무관한 기준을 제시하기보다 특정 변경 사항을 검증하기 위해 작성되는 경우가 많아, 지나치게 엄격해질 수 있습니다.

한편 평가상의 결함은 불과 얼마 전보다도 훨씬 쉽게 찾아낼 수 있게 되었습니다. 모델의 성능이 향상되면서 이제는 모델 자체를 활용해 프롬프트, 테스트, 패치, 실행 기록, 엣지 케이스를 더욱 깊이 있고 일관성 있게 분석할 수 있습니다. 그 결과 과거에는 대규모로 찾아내기 어렵거나 많은 비용이 들었던 벤치마크의 문제도 훨씬 효과적으로 발견할 수 있게 되었습니다.

OpenAI는 더 넓은 평가 커뮤니티가 숙련된 소프트웨어 개발자가 직접 설계한 새로운 벤치마크를 개발해 모델의 역량을 평가하기를 기대합니다. 이러한 접근 방식이라면 높은 평가 기준과 실제 사용 환경에 가까운 현실성을 유지하면서도, 전 과정에 걸쳐 사람의 감독을 더욱 효과적으로 적용할 수 있습니다. 또한 이번 분석에서 확인된 문제를 고려해 OpenAI는 앞서 SWE-Bench Pro의 도입을 권장했던 기존 입장을 철회합니다.

궁극적으로 평가는 조작하기 어렵고 신뢰할 수 있으며, 모델의 역량이나 정렬 수준을 정확하게 반영하는 벤치마크를 통해 유의미한 결과를 제공해야 합니다. 이러한 결과는 OpenAI의 배포 및 안전성 관련 의사결정의 근거가 되므로, OpenAI가 활용하는 평가는 반드시 타당하고 충분한 정보를 제공할 수 있어야 합니다.