포화된 벤치마크는 더 이상 신호가 아닙니다
프런티어 모델의 점수가 88~90%대로 몰리면서 MMLU와 GPQA Diamond 같은 대표 벤치마크는 사실상 포화 상태에 이르렀습니다. 상단이 막힌 지표에서는 1~2% 차이가 실력 차이인지 측정 잡음인지 구분되지 않습니다. 점수 올리기에 최적화된 운영 루프는 이런 포화 구간에서 개선을 착각하기 쉽습니다.
오염은 자기기만을 만듭니다
OpenAI는 SWE-bench Verified의 문제와 정답이 학습 데이터에 섞여 들어갔을 오염 우려를 제기했습니다. 테스트 문제를 이미 본 모델은 실력이 아니라 암기로 점수를 냅니다. 그 결과 벤치마크는 오르는데 실제 운영 품질은 정체되는 괴리가 생기고, 후속 표준으로 SWE-bench Pro가 부상하고 있습니다.
오염에 강한 평가를 함께 씁니다
LiveCodeBench는 최근 대회 문제를 지속적으로 수집해 평가에 쓰므로, 학습 시점 이후에 나온 문제로 오염을 구조적으로 피합니다. 여기에 우리 서비스 로그에서 추출한 자체 홀드아웃 세트를 더하면, 공개 벤치와 무관하게 실제 태스크 분포에서의 실력을 측정할 수 있습니다.
A4 분량 상세 가이드: 기획부터 운영까지
기획 단계에서는 목표 지표를 수치로 고정합니다. 자체 홀드아웃 통과율은 공개 벤치 점수와 별개로 관리하고, 예를 들어 홀드아웃 통과율 기준선 대비 하락 2% 이상을 회귀로 정의합니다. 홀드아웃은 실제 운영 로그에서 최근 문제를 뽑아 구성하고, 학습·프롬프트 예시로 절대 노출하지 않으며, 분기마다 신규 문제로 30% 이상 교체해 암기 여지를 줄입니다.
실패 패턴의 첫째는 공개 벤치 점수만 보고 개선을 선언하는 것입니다. 홀드아웃과 공개 점수가 함께 오를 때만 실제 개선으로 인정하고, 공개 점수만 오르면 오염을 의심합니다. 둘째는 홀드아웃 유출입니다. 홀드아웃 문제가 프롬프트나 파인튜닝 데이터에 새어 들어가면 세트를 폐기하고 신규 문제로 재구성합니다. 복구 분기로, 회귀가 감지되면 이전 프롬프트·모델 버전으로 롤백하고, 원인이 확인될 때까지 자동 배포를 중단하며, 판정이 모호하면 사람 확인 단계로 넘깁니다.
운영 체크리스트에는 평가 실행마다 모델 버전, 데이터셋 버전, 통과율, p95 지연을 표준 로그로 남깁니다. 홀드아웃 문제와 로그에 개인정보가 포함되지 않도록 PII 마스킹 규칙을 적용하고, 마스킹 위반 0건을 릴리스 게이트 조건으로 둡니다. 어떤 문제가 언제 세트에 들어오고 교체됐는지 이력을 남겨, 오염 추적이 가능하게 합니다.
지속 개선 루프는 주간 단위로 공개 벤치와 홀드아웃의 점수 괴리를 추적합니다. 괴리가 벌어지면 오염 신호로 보고 세트를 갱신하며, LiveCodeBench처럼 최신 문제 기반 벤치를 함께 돌려 교차 검증합니다. 오래된 홀드아웃 문제는 정기적으로 은퇴시켜, 평가셋 자체가 포화되지 않게 유지합니다.
실행 요약
정리하면 포화된 공개 벤치는 더 이상 실력 신호가 아니며, 오염은 점수 상승을 실제 개선으로 착각하게 만듭니다. SWE-bench Pro와 LiveCodeBench 같은 오염 저항 평가에 더해, 운영 로그 기반 자체 홀드아웃을 수치 기준으로 관리해야 합니다. 홀드아웃 통과율 하락 2% 이상은 회귀로 다루고, 공개 점수와의 괴리를 오염 신호로 읽으며, 세트를 계속 갱신해야 자기기만을 막습니다.