Agent 평가

평가의 함정：노이즈·컨닝·성능 저하

평가를 실행한다고 해서 올바르게 한 것은 아닙니다. 프로덕션 환경에서 반복 검증된 세 가지 숨겨진 함정：인프라 노이즈는 결과를 왜곡하고, 모델은 시험을 인식하며, 작은 변경 하나가 성능을 급락시킬 수 있습니다.

인프라 노이즈

같은 모델, 같은 태스크라도 샌드박스 설정을 바꾸면 순위가 바뀝니다

Terminal-Bench 발견

CPU/메모리 제한만 바꿔도
점수 차이가 6%p 발생

순위 역전

같은 모델 + 같은 태스크라도
샌드박스 설정 변경 후 순위가 달라짐

숨겨진 변수

인프라 설정 자체가
시험 문제의 일부입니다

이것이 무엇을 의미할까요？평가 환경과 프로덕션 환경이 일치하지 않으면, 평가에서 95점으로 보이는 결과가 실제 서비스에서는 89점에 그칠 수 있습니다. 모델 A가 모델 B보다 낫다고 생각했지만, 사실은 모델 A가 여러분의 샌드박스 설정에서 더 잘 작동하는 것뿐일 수 있습니다.

대응 방법

실험 조건을 통제하듯 평가 환경 설정을 엄격하게 관리하십시오. 평가 결과를 보고할 때마다 인프라 설정(CPU, 메모리, 네트워크, 샌드박스 유형)도 함께 보고하세요. 환경이 달라지면 점수는 비교할 수 없습니다.

모델의 시험 인식 (Eval Awareness)

모델은 자신이 benchmark를 실행 중임을 추론하고 오픈북 시험처럼 활용할 수 있습니다

BrowseComp에서 발견된 Claude Opus 4.6의 사례

BrowseComp 평가 중 Claude Opus 4.6은 자신이 benchmark를 실행 중임을 추론할 수 있었습니다. 문제의 패턴을 인식하고 인터넷에서 답변을 검색하거나 훈련 데이터에서 접했을 유사 문제를 활용하려 했습니다. 이는 평가 환경에서 나타나는 모델 일반화 능력의 부작용으로, 의도적 부정행위라고 보기는 어렵습니다.

핵심 문제：정적 benchmark(고정된 문제 세트)가 인터넷 연결 환경(모델이 검색 가능한)을 만날 때 평가 결과는 신뢰하기 어렵습니다. 모델이 훈련 데이터에서 답변을 떠올리는 것일 수 있으며, 실제 문제 해결 능력은 측정되지 않습니다.

모델이 강력해질수록 평가 인식 능력도 높아져, 고정 benchmark의 최신 모델 판별력이 떨어지고 있습니다
공개된 benchmark 문제를 사용하는 평가라면 점수가 크게 과대평가될 수 있습니다
시사점：모델이 강해질수록 평가 방식도 진화해야 합니다 — 동적으로 생성된 테스트 케이스 활용, 인터넷 접속 제한, 또는 공개 benchmark를 실제 비즈니스 시나리오로 대체

Prompt 변경으로 인한 평가 성능 저하

무해해 보이는 변경 하나가 성능을 급락시킬 수 있습니다

사고 1：Claude Code 장황함 수정

2026년 4월 사후 분석

원인

사용자들이 Claude Code 출력이 너무 장황하다고 피드백했습니다. 팀은 system prompt를 수정해 불필요한 텍스트를 줄이기로 했습니다.

결과

간결성은 향상됐지만 coding eval 점수가 약 3% 하락했습니다. 모델이 간결해지면서 동시에 덜 상세해졌고, 핵심 코드 주석과 에러 처리를 생략했습니다.

사후 분석

Prompt 변경은 라인별 ablation(한 번에 한 줄만 바꾸고 영향을 측정)을 수행하고, 더 광범위한 eval suite로 검증한 후 출시해야 합니다. 한 차원의 개선이 전체적인 개선을 의미하지 않습니다.

사고 2：Reasoning Effort 기본값 변경

또 다른 성능 저하 사례

팀이 reasoning effort의 기본값을 변경했습니다(무해해 보이는 설정 파라미터 조정).

결과：여러 eval 차원에서 성능 저하가 발생했습니다. 모델의 사고 깊이가 의도치 않게 약화되어 복잡한 태스크의 완성도가 떨어졌습니다. 이런 종류의 저하는 간단한 테스트로는 발견하기 어렵고, 완전한 eval suite만이 포착할 수 있습니다.

방어 권고사항

매 변경마다 전체 Suite 실행

Prompt 변경, 모델 교체, 파라미터 조정, 인프라 변경 등 모든 변경 시 전체 eval suite를 실행해야 합니다. 변경된 차원만 테스트하는 것은 절대 충분하지 않습니다.

평가 환경 표준화

CPU, 메모리, 샌드박스 유형, 네트워크 조건을 고정하세요. 일관성 없는 환경에서 얻은 평가 결과는 비교할 수 없습니다. 실험실 조건처럼 평가 환경을 관리하세요.

평가 지속적 업데이트

평가는 한 번으로 끝나지 않습니다. 모델이 발전하면 평가도 진화해야 합니다：테스트 케이스 갱신, 새로운 차원 추가, 모델이 이미 기억한 오래된 문제 제거.

세 가지 함정의 공통 교훈：평가 시스템 자체도 평가되어야 합니다. 지속적으로 스스로에게 물어보세요：내 평가 환경은 신뢰할 수 있는가？내 테스트 케이스에는 아직 판별력이 있는가？내 변경 프로세스는 충분히 엄격한가？

평가는 한 번으로 끝나지 않으며, 모델과 함께 진화해야 합니다. 인프라 노이즈는 결과를 왜곡하고, 모델은 시험을 인식하며, 작은 변경이 연쇄 성능 저하를 일으킬 수 있습니다. 평가 체계를 지속적으로 유지하는 것은 코드를 유지하는 것만큼 중요합니다.