오픈AI, 코딩 벤치마크 신뢰도 높인 'SWE-bench Verified' 공개
오픈AI가 원작자들과 협력해 신뢰성을 대폭 개선한 'SWE-bench Verified'를 공개했다. 전문 개발자 93명이 참여해 모호한 문제 설명과 부당한 테스트 케이스를 걷어내고 500개 샘플을 추려냈다. 소프트웨어 엔지니어링 에이전트의 역량을 한층 정확하게 측정할 수 있게 됐다.

지난 1년 동안 AI 모델의 코딩 능력을 이야기할 때 가장 자주 언급된 기준은 SWE-bench였습니다. 깃허브의 실제 오픈소스 이슈를 가져와 모델이 직접 버그를 고치게 만드는 방식으로, 코딩 에이전트의 실전 능력을 평가하는 표준으로 자리 잡았습니다.
하지만 정작 이 시험 문제지에 심각한 하자가 있었습니다. OpenAI는 8월 13일, SWE-bench 원작자들과 협력해 인간 전문가의 검증을 거친 새 평가셋인 SWE-bench Verified를 공개했습니다.
시험 문제 자체가 불공정했던 SWE-bench
AI가 사람의 개입 없이 소프트웨어를 개발하는 역량은 OpenAI 내부의 자율성 위험 평가에서도 핵심 지표로 꼽힙니다. 그런데 기존 SWE-bench로 테스트를 진행해 보니, 모델의 실제 코딩 능력이 체계적으로 저평가되고 있다는 사실이 드러났습니다.
문제는 크게 세 가지였습니다. 첫째는 채점용 단위 테스트가 지나치게 협소하거나 문제 본문과 동떨어져 있던 점입니다. 예를 들어 scikit-learn의 한 이슈에서는 무시되던 매개변수를 고치라고 요구하면서, 실제 채점 테스트는 본문에 언급도 없던 특정 경고문 문구를 완벽히 똑같이 출력하도록 요구했습니다. 모델 입장에서는 정상적인 해결책을 내놓고도 오답 처리를 당할 수밖에 없었습니다.
둘째는 원본 깃허브 이슈 설명이 지나치게 모호해 무엇을 고쳐야 할지 사람조차 알 수 없는 경우가 많았습니다. 셋째는 테스트 환경 구축이 불안정해, 모델이 맞게 짠 코드조차 의존성 오류 때문에 탈락하는 일이 빈번했습니다.
개발자 93명이 투입돼 68%의 문제를 쳐냈다
OpenAI는 이 문제를 바로잡기 위해 파이썬 경험이 풍부한 소프트웨어 엔지니어 93명을 모았습니다. 그리고 기존 테스트셋에서 무작위로 추출한 1699개 샘플을 일일이 검수했습니다.
검수 방식은 매우 보수적이었습니다. 각 문제를 3명의 엔지니어가 교차 검증했으며, 3명 중 단 한 명이라도 설명이 모호하거나 채점 테스트에 결함이 있다고 판단하면 가차 없이 폐기했습니다.
검수 결과는 충격적이었습니다. 전체 샘플 중 38.3%는 문제 설명이 불충분했고, 61.1%는 올바른 수정안을 억울하게 탈락시키는 부당한 테스트를 포함하고 있었습니다. 결국 전체 문제의 68.3%가 자격 미달로 버려졌습니다.
이렇게 걸러내고 남은 500개의 깨끗한 문제로 구성된 것이 바로 SWE-bench Verified입니다. 이 데이터셋은 기존의 오리지널 SWE-bench와 Lite 버전을 대체합니다. 또한 도커 기반의 새로운 테스트 프레임워크를 도입해 환경 문제로 인한 채점 오류도 잡았습니다.
불합리한 오답 처리가 사라지자 모델들의 점수는 껑충 뛰었습니다. GPT-4o는 33.2%의 해결률을 기록했고, 오픈소스 프레임워크인 Agentless는 기존 16%에서 두 배 가까이 점수가 올랐습니다.
왜 중요한가
현업 개발자와 기업 입장에서는 AI의 실제 버그 해결 능력을 훨씬 정확하게 가늠할 수 있게 되었습니다. 기존 벤치마크에서 10~20% 수준에 머물던 수치만 보고 실무 도입을 미뤘던 조직이라면, 부당하게 깎였던 점수가 복원된 이번 결과를 바탕으로 코드 유지보수 업무에 AI를 도입할 타이밍인지 다시 검토해 볼 가치가 있습니다.
업계 전반으로 봐도 이번 개편은 이정표가 될 것으로 보입니다. 지난 몇 달간 수많은 기업과 연구진이 잘못된 시험 문제에 맞춰 프롬프트를 깎고 모델을 쥐어짜는 비효율을 겪었습니다. OpenAI가 독자적인 벤치마크를 새로 만들어 홍보하는 대신, 기존 권위 있는 벤치마크 팀과 손잡고 원본의 거품과 오류를 걷어내는 방식을 택한 점은 매우 영리했습니다.
우리는 이번 조치가 벤치마크의 신뢰도를 크게 높였다고 평가하지만, 한편으로는 일정한 한계도 존재한다고 봅니다. 3명 중 1명만 문제를 제기해도 탈락시키는 방식을 택하다 보니 전체의 70% 가까이가 잘려 나갔습니다. 이 과정에서 실제 현업 개발자가 마주하는 현실적인 모호함까지 과도하게 정제되었을 가능성이 있습니다. 그럼에도 불량 시험지를 쥐고 순위 경쟁을 벌이던 업계의 소모전을 끝냈다는 점에서 지금 꼭 필요했던 작업이었습니다.
출처 (1)
- openai.com(새 탭에서 열림)원문openai.com