공백 하나로 정답이 오답이 됐다: SWE-Bench Pro 감사에서 배울 평가 계약

코딩 에이전트가 테스트에 실패하면 보통 모델부터 의심한다. 요구사항을 이해하지 못했거나, 저장소를 충분히 읽지 않았거나, 구현이 틀렸다고 생각하기 쉽다. 그러나 문제 설명에는 공백 한 칸이 정답이라고 적혀 있는데 숨겨진 테스트는 두 칸을 요구한다면 어떨까. 이때 실패는 코딩 능력보다 문제와 채점 규칙의 불일치를 측정한다.

OpenAI가 2026년 7월 8일 발표한 코딩 평가 감사는 이런 불일치를 SWE-Bench Pro에서 조사했다. 핵심은 ‘모든 코딩 벤치마크의 30%가 망가졌다’는 선언이 아니다. SWE-Bench Pro 공개 데이터셋 731개 작업을 대상으로 한 감사에서, 약 30%에 결함이 있다고 OpenAI가 추정했다는 제한된 결과다. 이 범위를 지키면서 읽으면 리더보드를 버리자는 주장보다 훨씬 실용적인 평가 설계 원칙이 보인다.

1. 731개 중 286개를 먼저 골랐다: 분모와 검토 단계를 구분하자

SWE-Bench Pro는 저장소의 기능 변경 이력을 바탕으로 코딩 작업을 구성하고, 새 기능 테스트를 통과하면서 기존 동작도 보존하는지 평가한다. Scale의 최초 소개는 공개·보류·상용 분할을 구분한다. 따라서 이번 감사에서 사용하는 공개 작업 731개를 벤치마크의 모든 분할이나 모든 코딩 평가 문제로 확대하면 안 된다.

OpenAI는 먼저 지침, 모델의 실행 결과, 채점 테스트 등을 자동 분석해 결함이 의심되는 작업 286개를 선별했다. 그 다음 이 집합을 두 경로로 깊이 검토했다. 하나는 조사 에이전트가 저장소와 실행 환경을 살펴보고 사람이 최종 판단을 내리는 방식이다. 다른 하나는 숙련된 소프트웨어 엔지니어들이 직접 주석을 붙이는 방식이다.

보고된 결함 작업 수는 사람이 감독하는 에이전트 검토에서 200개, 사람 주석에서 249개다. 27.4%와 34.1%의 분모는 모두 공개 작업 전체인 731개다. 두 숫자는 같은 문제 집합에 대한 서로 다른 검토 방식의 결과이므로 합산해서 449개라고 쓰면 안 된다. 선별된 286개가 전부 같은 강도로 결함 확정됐다는 뜻도 아니다.

두 비율의 분모는 모두 공개 작업 731개다. 에이전트 검토와 사람 주석 결과는 합산하지 않는다. 출처: openai.com/ko-KR/index/separating-signal-from-noise-coding-evaluations.

이번 글에서는 공개된 개수로 나눗셈을 다시 계산해 소수점 첫째 자리의 비율을 확인했다. 이것은 산식 검산이지, 작업별 판정을 독립적으로 다시 수행한 결과가 아니다. 특히 자동 필터가 선별하지 않은 작업까지 모두 같은 깊이로 사람이 재검토했다고 해석해서는 안 된다.

2. 공백 한 칸과 두 칸: 문제를 지킨 코드가 실패하는 구조

원문이 제시한 OpenLibrary-77c16d5 사례는 목차 항목을 Markdown으로 직렬화하는 TocEntry.to_markdown() 작업이다. 프롬프트의 예시는 첫 번째 구분자 앞 공백을 한 칸으로 보여 준다. 반면 숨겨진 test_to_markdown 검사는 두 칸을 기대한다. 원문은 이 한 글자 차이 때문에 프롬프트를 따른 구현도 오답 처리될 수 있다고 설명한다.

여기서 공백은 장식이 아니다. 출력 문자열을 정확히 비교하는 테스트에서는 한 글자도 계약의 일부다. 그렇다고 모든 공백 차이를 자동으로 무시하면 해결되는 것도 아니다. 포맷 자체가 필요한 API나 문서 변환 작업에서는 정확한 직렬화 규칙을 검증해야 한다. 문제는 엄격함 자체가 아니라 그 엄격한 규칙이 해결자에게 제공된 요구사항과 일치하는가다.

OpenLibrary-77c16d5의 공식 발표 사례를 재구성했다. 사각형 하나는 보이도록 표시한 공백 한 칸이다. 독립 실행 화면이 아니다. 출처: openai.com/ko-KR/index/separating-signal-from-noise-coding-evaluations.

평가 운영자가 해야 할 일은 실패한 에이전트에게 숨은 테스트에 맞추라고만 요구하는 것이 아니다. 먼저 공개 명세와 기대값 가운데 어느 쪽이 의도한 동작인지 결정하고, 수정된 평가 버전을 기록해야 한다. 채점 이후 모델별로 유리한 예외를 넣으면 공정성 문제가 새로 생긴다. 수정 전후 점수는 구분하고, 비교 대상에는 동일한 규칙을 적용해야 한다.

3. 결함은 점수를 낮추기도, 높이기도 한다

OpenAI가 설명한 주요 실패 유형은 네 가지다. 지나치게 엄격한 테스트는 명세에 없는 구현 세부사항을 강제한다. 요구사항이 불충분한 프롬프트는 숨겨진 테스트가 확인하는 조건을 빠뜨린다. 오해를 부르는 프롬프트는 테스트와 모순되는 동작을 지시한다. 반대로 낮은 커버리지의 테스트는 요구한 기능 일부가 빠진 수정도 통과시킬 수 있다.

앞의 유형들만 보면 ‘모델이 억울하게 감점됐다’고 생각하기 쉽다. 그러나 낮은 커버리지는 불완전한 구현에 성공 표시를 줄 수 있다. 따라서 결함 비율만으로 현재 점수가 실제 능력보다 얼마나 낮거나 높은지 계산할 수 없다. 결함 작업을 제거하면 모든 모델 순위가 어느 방향으로 움직이는지도 이 발표만으로는 확정할 수 없다.

이 구분은 사내 평가에도 중요하다. 실패한 결과만 조사하면 부당한 감점은 찾을 수 있지만, 허술한 테스트를 통과한 잘못된 구현은 놓친다. 평가 품질을 확인하려면 실패 사례뿐 아니라 통과 사례에서도 요구사항이 실제로 충족됐는지 표본 검토할 필요가 있다. 이는 이번 결과에서 도출한 운영 제안이지, 원문의 추가 실험 결과는 아니다.

4. 엔지니어 5명과 74%: 사람이 참여해도 판단 단위가 중요하다

사람 주석 경로에서는 선별된 각 작업을 엔지니어 5명이 독립적으로 검토했다. 처음에는 문제 설명, 테스트, 참조 해결책인 gold patch만 보고 판단하고, 그 뒤 파이프라인 분석을 참고했다. 불확실하거나 의견이 엇갈리는 사례는 추가 검토로 넘겼다. ‘엔지니어 다섯 명이 전체 평가를 한 번 훑었다’와는 다른 절차다.

원문의 74%도 주의해서 읽어야 한다. 에이전트 파이프라인이 식별한 문제 유형 가운데 사람 판단과 일치한 비율이다. 작업 정답률, 에이전트의 코딩 성공률, 모든 작업에 대한 사람·기계의 판정 정확도를 뜻하지 않는다. 사람은 한 작업에 여러 문제 유형을 붙이는 경우가 더 많았다고 발표는 설명한다.

자동 분석은 의심할 지점을 모으는 데 유용하지만, 최종 숫자를 만들기까지 어떤 증거를 읽었고 어느 단위로 합의했는지가 따로 필요하다. 여러 검토자가 참여했다는 사실만으로 데이터셋 전체의 완전한 정답표가 생기는 것은 아니다. OpenAI 역시 이번 분석을 이유로 앞서 SWE-Bench Pro 도입을 권장했던 입장을 철회했다. 이것은 OpenAI의 평가 사용 방침에 관한 결론이지, 모든 사용자가 같은 결정을 내려야 한다는 독립적 합의는 아니다.

5. 사내 코딩 평가에 붙일 ‘문제-테스트 계약’ 체크리스트

모델 교체 전에 평가 문제 몇 개를 사람이 풀어 보는 것만으로도 비용 대비 유용한 결함을 찾을 수 있다. 다음은 위 감사를 실무에 옮긴 제안이다.

• 요구사항 연결표를 만든다. 테스트의 각 기대값이 문제 설명의 어느 문장이나 저장소의 어느 공개 관례에서 나오는지 적는다. 근거가 없으면 모델 실패와 평가 결함을 분리해 검토한다.
• 다른 올바른 구현도 허용하는지 본다. 참조 패치의 함수 이름이나 내부 호출 순서만 따라야 통과하는 테스트인지 확인한다. 구현 제약이 정말 필요하면 명세에 먼저 공개한다.
• 통과한 불완전한 수정도 찾는다. 기능 일부를 의도적으로 생략한 작은 대조 구현을 만들어 테스트가 거부하는지 본다. 실행 환경은 격리하고 실제 서비스에는 적용하지 않는다.
• 검토 순서를 보존한다. 초기 사람 판단과 에이전트 분석을 본 뒤의 판단을 따로 기록한다. 평가자가 같은 자동 설명에 끌리는 현상을 확인할 수 있게 한다.
• 수정 버전과 분모를 고정한다. 제외 사유, 수정된 문제 ID, 총 작업 수, 모델별 동일 적용 여부를 남긴다. 정제 전 점수와 정제 후 점수를 같은 리더보드 열에 섞지 않는다.

이 체크리스트는 성능을 무조건 올리는 비법이 아니다. 점수가 바뀌었을 때 모델이 달라진 것인지, 채점 계약이 달라진 것인지 설명할 수 있게 만드는 장치다. 어려운 과제와 불공정한 과제를 구분하는 것이 목표다.

6. 이 결과로 말할 수 있는 것과 없는 것

이번 발표가 보여 주는 강한 신호는 평가 데이터도 소프트웨어처럼 감사를 받아야 한다는 점이다. 오픈소스 이슈와 pull request는 사람들의 협업 흔적이다. 그 기록을 떼어 독립 시험 문제로 만들면 원래 대화에서 공유됐던 전제나 구현 제약이 사라질 수 있다. 문제 설명·패치·테스트가 한때 함께 존재했다는 사실은 셋이 공정한 시험 계약을 이룬다는 보장이 아니다.

반면 ‘모든 코딩 벤치마크 30%가 무효’, ‘AI의 진짜 실력이 30% 더 높다’, ‘74% 정확도의 자동 평가기’ 같은 문장은 이 자료로 뒷받침되지 않는다. 공개 731개, 선별 286개, 두 검토 경로와 문제 유형이라는 범위를 끝까지 붙여야 한다. 작업별 감사 라벨 전체를 독립 재채점하거나 모델을 새로 실행한 것도 아니므로, 이 글은 결함 비율의 재현 연구나 수정 리더보드를 제공하지 않는다.

모델을 평가할 때 물을 질문은 ‘몇 점인가’에서 끝나지 않는다. ‘그 점수가 어떤 요구사항과 어떤 테스트 사이에서 나왔는가’까지 물어야 한다. 공백 한 칸은 작은 구현 차이지만, 그 차이를 누가 정했는지는 평가 전체의 신뢰를 결정할 수 있다.

참고 자료

• OpenAI 공식 한국어 발표: 감사 수치·방법론·OpenLibrary 사례
• OpenAI 원문 식별 URL: Separating signal from noise in coding evaluations
• Scale 공식 소개: SWE-Bench Pro의 목적과 공개·보류·상용 분할
• ScaleAI 공개 데이터셋: 데이터와 실행 환경의 배포 위치

작성·검증 안내: AI를 활용해 공개 자료를 검토하고 독자적인 해설과 도식을 작성했다. OpenAI의 공식 한국어 본문과 Scale의 소개·데이터셋 문서를 확인했으며, 두 결함 비율은 공개 개수에서 다시 계산했다. 제품 사용 후기나 벤치마크의 독립 재현은 아니다. 자체 도식은 출처의 수치와 사례를 설명하기 위한 것이며 공식 조직의 제작물·협찬을 뜻하지 않는다.