코딩 에이전트의 벤치마크 점수는 높은데 새 저장소에서는 성능이 낮습니다. 평가 오염과 운영 차이는 어떻게 확인하나요?

벤치마크는 정해진 과제·환경·도구·예산에서의 결과입니다. 점수가 높아도 새로운 저장소의 규칙·의존성·권한·작업 길이가 다르면 운영 성능이 달라질 수 있습니다. 학습이나 프롬프트 최적화에서 평가 문제·정답을 이미 봤는지와, 평가 환경이 실제 배포 조건을 얼마나 대표하는지를 나눠 확인하겠습니다.

누출과 과적합의 경로

공개 문제의 패치나 해설이 모델 학습 자료에 포함됐는지 완전히 확인하기 어려울 수 있습니다. 또 개발자가 같은 평가 세트에 반복 맞춰 프롬프트를 조정하면 직접 정답을 넣지 않아도 그 세트에 과적합할 수 있습니다. 개발용·회귀용·최종 평가용 집합을 분리하고 시간상 새로운 내부 과제와 변형 사례를 사용합니다. 단어만 바꾼 문제가 독립적인 새 과제라고 가정하지 않습니다.

trial 사이 파일·캐시·Git 이력에 정답이 남는 환경 누출도 있습니다. 각 실행을 초기화하고 숨겨진 테스트·정답 파일의 접근을 제한합니다. 에이전트가 테스트를 삭제하거나 성공 결과 파일을 직접 조작할 수 있으면 실제 기능을 고치지 않고도 점수를 얻을 수 있습니다. 테스트 변경이 정당한 과제와 평가 기준 훼손을 구분해 채점 권한을 분리합니다.

운영 대표성과 비교 조건

벤치마크에서 인터넷·도구·실행 시간이 넉넉했는데 운영은 짧은 deadline과 제한된 자격을 사용한다면 같은 숫자를 기대하기 어렵습니다. 모델 버전뿐 아니라 harness·검색·도구 설명·컴파일 환경·재시도 수와 후보 선택 방법을 기록해야 공정한 비교가 됩니다. 여러 번 중 최고 결과와 단일 실행 결과도 나눠 보고합니다.

실제 실패에서 과제를 만들고 저장소 크기·언어·작업 유형·권한·장기 수명별로 평가를 나눕니다. 공개 점수는 후보를 좁히는 참고 자료로 쓰되 배포 판단은 자체 과제의 성공·회귀·검토 시간·비용·안전 결과로 합니다. 점수가 포화되면 더 어려운 과제를 추가하면서 기존 안정 동작의 회귀 세트는 유지합니다. 최신 모델 순위가 바뀌어도 어떤 조건에서 측정했는지 없이 '에이전트가 개발자를 대체한다'처럼 넓은 결론을 내리지 않겠습니다.

실행 사례로 확인합니다

새 내부 과제를 만들 때도 해결에 필요한 자료가 실제 환경에서 접근 가능한지 확인해야 합니다. 정답은 숨겼지만 필수 API 문서도 제거했다면 모델 능력이 아니라 정보 부재를 평가할 수 있습니다. 기준 구현이나 사람의 재현으로 과제가 해결 가능하고 채점이 맞는지 확인합니다. 공개 벤치마크와 자체 과제를 함께 쓰되 두 집합의 목적을 구분합니다. 자체 세트도 반복 사용하면 개발 과정에 노출되므로 별도의 보류 집합과 정기적인 새 실패 사례가 필요합니다. 비용 예산을 다르게 준 모델의 점수를 단순 순위로 나열하지 않고 어떤 자원과 도구에서 측정했는지 명시하면 최신 결과를 과장 없이 활용할 수 있습니다.