브라우저별 테스트 보고서를 만드는 기능은 정상입니다. 그런데 파일명을 소문자로 저장하라는 조건을 추가하자, 어제의 정답은 오늘의 오답이 됩니다. MaxxBench가 던지는 질문은 이 작은 차이를 코딩 에이전트가 실제로 반영하는가입니다.
10월 20일 연구 소개와 공개 저장소는 DeepSWE 89개 과제의 지시문 또는 시작 코드를 변경했다고 설명합니다. 이 글은 11월 8일 확인한 자료를 분석하며, 전체 모델 평가를 재실행하지 않았습니다.
두 점수 사이에 빠진 실험 조건
브리핑의 Gemini 3.8 Flash 73.8%와 53.4%는 서로 다른 과제 구성의 결과입니다. 같은 시험을 반복해서 성능이 떨어졌다는 뜻으로 읽으면 안 됩니다.
| 관측 | 값 | 읽을 때 필요한 조건 |
|---|---|---|
| 브리핑이 인용한 공개 DeepSWE 점수 | 73.8% | 원래 과제 구성의 수치 |
| MaxxBench에서 확인한 Gemini 3.8 Flash, high | 53.4% | 변형된 과제, 연구진 평가 |
| 두 표시값의 단순 차 | 20.4%p | 원인 추정치나 동일 조건 효과가 아님 |
출처: MaxxBench 결과와 연구 설명. 확인 시점 표는 추정 benchmaxxing 차이를 20.5%p로 표시합니다. 표시값을 뺀 20.4%p와 일치하지 않으므로 원시 값·반올림·기준 버전 확인 전에는 어느 쪽도 정확한 효과 크기로 사용하지 않습니다. 비교를 재현하려면 원래 평가의 모델 버전, 프롬프트, 도구, 토큰 예산, 시행 횟수까지 맞춰야 합니다.
여기서 얻을 수 있는 판단은 모델의 절대 순위보다 좁습니다. 공개된 문제를 잘 푸는 능력과, 그 문제의 계약이 바뀌었음을 알아차리는 능력을 별도로 검사할 이유가 생겼습니다.
작은 변경은 정답의 경계를 이동시킨다
보고서 과제의 지시문은 보고서 분리 외에도 파일명 정규화 등 여러 조건을 담고 있습니다. 다음은 그중 소문자 조건만 분리한 CodeBridge 설명용 예제입니다. 공식 정답 패치나 과제 전체를 재현한 코드는 아닙니다.
import assert from 'node:assert/strict';
const previous = name => name.replace(/[^a-zA-Z0-9]/g, '_');
const revised = name => previous(name).toLowerCase();
const input = 'Chrome (Headless)';
const oldContract = value => /^[a-zA-Z0-9_]+$/.test(value);
const newContract = value => oldContract(value) && value === value.toLowerCase();
assert(oldContract(previous(input)));
assert(!newContract(previous(input)));
assert(newContract(revised(input)));
console.log(previous(input), revised(input));
전제 조건은 Node.js 18 이상입니다. contract.mjs로 저장해 node contract.mjs로 실행합니다. 로컬 실행 결과는 Chrome__Headless_ chrome__headless_였습니다. API·네트워크·실제 저장소 수정 없이 문자열 계약만 검사했습니다.
기존 테스트는 문자 집합을 검사하므로 두 구현을 모두 통과시킬 수 있습니다. 새 테스트는 그 집합 안에서도 대문자를 금지합니다. 따라서 테스트 수가 많다는 사실만으로 새로운 요구사항의 검증을 대신할 수 없습니다.
변경 요청마다 “기존 동작이 깨졌는가”와 “새 조건이 실제로 적용됐는가”를 서로 다른 질문으로 남기세요.
평가기는 에이전트가 쓴 답안 밖에 있어야 한다
저장소 README는 별도 컨테이너에서 패치를 채점하고 기능·회귀 테스트 통과를 요구한다고 설명합니다. run.py는 검증기가 필요로 하는 재빌드 이미지 전달 경로도 다룹니다. 평가기의 환경과 실제 작업 환경을 연결하는 코드까지 재현 조건에 들어가는 이유입니다.
실무에서도 에이전트에게 테스트를 수정하게 할 수는 있습니다. 다만 새 테스트 파일이 생겼다는 사실과 독립적인 수락 기준을 통과했다는 사실은 다릅니다. 예를 들어 에이전트가 소문자 조건을 놓치고 테스트 기대값을 대문자로 바꾸면, 같은 실행 주체가 만든 패치와 테스트만으로는 오류를 드러내기 어렵습니다.
팀 평가에서는 작업 전에 수락 조건과 검증용 입력을 보관하고, 에이전트에게는 요구사항을 제공합니다. 작업 후에는 기존 회귀 테스트, 변경 조건 검사, 수정 범위 검토를 각각 실행합니다. 테스트를 숨기는 것 자체가 목표는 아닙니다. 답안을 만드는 과정에서 판단 기준이 조용히 바뀌지 않도록 하는 것이 목적입니다.
팀에서 시작할 수 있는 세 가지 변형
새 벤치마크 전체를 운영하기 전에 실제 저장소의 작은 작업으로 시작할 수 있습니다.
| 원래 작업 | 바꿀 조건 | 별도로 확인할 실패 |
|---|---|---|
| 보고서 파일 생성 | 소문자 이름과 빈 이름 처리 | 기존 이름 관습으로 돌아감 |
| 목록 API 구현 | 정렬 순서와 동점 처리 | 샘플 하나만 맞춤 |
| 데이터 내보내기 | UTC 날짜 경계 | 로컬 시간에 의존 |
이 표는 CodeBridge의 평가 제안이며 MaxxBench의 측정 결과가 아닙니다. 같은 시작 커밋과 모델 설정으로 원본/변형 작업을 짝지어 실행하고, 반복 시행의 분산과 실패 이유를 함께 보관하세요. 서로 다른 제품 버전을 비교한다면 모델과 하네스의 효과를 분리할 수 없다는 제한도 기록해야 합니다.
점수보다 먼저 보관할 것
MaxxBench만으로 특정 모델의 학습 데이터 오염이나 의도적 부정행위를 입증할 수는 없습니다. 공개 실행 기록은 실패 경로를 살펴볼 자료지만, 모든 모델·모든 코드베이스의 일반 능력을 대표하지 않습니다. 이 글의 문자열 실험도 모델 적응 능력을 측정하지 않았습니다.
그럼에도 팀이 바꿀 수 있는 것은 분명합니다. 모델을 바꾸기 전에 요구사항 변경 이력과 수락 테스트를 함께 저장하세요. 다음 평가에서 보고 싶은 결과는 단순한 통과율 하나가 아니라, 바뀐 계약을 놓친 실패가 어떤 조건에서 다시 나타나는지입니다.
관련 배경: AI 벤치마크 포화가 의미하는 것.