에이전트 벤치마크 점수보다 자체 평가셋이 필요한 이유

DeepSeek V4-Flash는 Terminal Bench 2.1에서 82.7점을 기록해 V4-Pro-Preview의 72.1점을 앞섰다. 저가 모델이 같은 벤더의 상위 모델보다 특정 에이전트 벤치마크에서 높은 점수를 얻을 수 있다는 사실은, 공개 순위를 곧바로 채택 근거로 삼기 어렵게 만든다.

에이전트 벤치마크는 단일 응답의 품질만 보지 않는다. 도구 호출 선택, 여러 단계의 계획, 실패 뒤 복구까지 측정한다. 따라서 실제 측정 대상은 모델 하나가 아니라 모델과 평가 하네스의 조합이다. 도구 세트, 시스템 프롬프트, 최대 반복 횟수, 타임아웃, 초기 환경, 성공 판정 기준 가운데 하나만 바뀌어도 점수는 크게 흔들릴 수 있다.

공개 점수는 후보 선별에 사용하고, 채택 판단은 조직의 저장소와 도구, 개발 관행을 반영한 자체 평가셋에서 내리는 편이 낫다.

점수를 만들던 하네스를 먼저 고정한다

모델 비교 전에 하네스의 조건을 명시적으로 고정해야 한다. 제공 도구와 설명 문구, 시스템 프롬프트, 최대 턴 수, 턴별 타임아웃, 컨텍스트 관리 방식을 모두 평가 구성으로 다룬다.

하네스 구성은 버전 관리 대상이다. 하네스가 달라지면 과거 점수와 현재 점수는 같은 기준에서 비교할 수 없으므로, 구성 버전도 결과의 일부로 남겨야 한다. 모델별로 하네스를 따로 최적화하면 결국 무엇을 비교한 것인지 불분명해진다.

도구 설명 역시 통제해야 한다. 설명의 품질이 도구 선택 정확도에 영향을 주므로, 설명을 바꾸는 행위는 평가 조건을 바꾸는 일이다. 평가에서 운영 환경보다 많은 도구를 주면 점수가 과대 산출될 수 있다.

조직의 업무를 태스크 스위트로 옮긴다

자체 평가셋은 실제 작업 이력에서 뽑은 태스크로 구성한다. 저장소 구조, 빌드 도구, 테스트 프레임워크, 코딩 관행이 반영되어야 모델 성능이 운영 결과를 얼마나 예측하는지 판단할 수 있다. 상상으로 만든 태스크는 실제 업무의 난이도 분포와 달라지기 쉽다.

성공 사례만 담아서는 오류 복구 능력을 측정할 수 없다. 실패 사례도 표본에 포함하고, 쉬운 태스크와 어려운 태스크가 한쪽으로 치우치지 않도록 난이도를 나눈다. 쉬운 태스크만 있으면 상위 모델의 차이가 드러나지 않고, 어려운 태스크만 있으면 하위 모델이 모두 0점이 될 수 있다.

태스크 수와 커버리지는 결과와 함께 보고한다. 태스크 10개로 얻은 결과는 신뢰구간이 넓다는 사실까지 포함해 해석해야 한다. 코드베이스와 업무가 바뀌면 표본의 대표성도 낮아지므로 갱신 주기도 정해 둘 필요가 있다.

성공 여부는 자동으로 판정하고 환경 오류는 분리한다

사람이 결과를 판정하면 규모를 키우기 어렵고 판정자별 편차도 생긴다. 성공 판정은 프로그램으로 구현하는 편이 측정의 객관성을 지키기 쉽다.

판정 결과는 완전 성공, 부분 성공, 실패, 환경 오류로 구분한다. 이진 판정만으로는 실패 원인을 분석하기 어렵고, 부분 성공에 담긴 정보도 사라진다. 네트워크나 의존성 문제로 실패한 실행을 모델 실패에 포함하면 점수 자체가 오염된다. 환경 오류는 측정에서 제외하고 원인을 고친 뒤 재실행한다.

⤢✕

반복 실행으로 성공률과 분산을 함께 본다

에이전트 실행은 확률적이어서 단일 실행 점수는 분산 정보를 담지 못한다. 같은 태스크라도 재실행에서 다른 값이 나올 수 있다. 태스크당 최소 3~5회 실행하고, 성공률뿐 아니라 분산도 함께 기록해야 하는 이유다.

실행 간 편차가 큰 태스크는 별도로 표시한다. 평가에서 편차가 큰 영역은 운영에서도 불안정할 가능성이 있는 영역이다. 평균 성공률이 같더라도 분산이 다르면 두 모델의 운영 예측성은 다르다. 분산이 작은 모델이 더 예측 가능한 선택이 될 수 있다.

반복 횟수는 목표 신뢰구간에서 역산한다. 먼저 반복 횟수를 정한 뒤 결과를 해석하면 근거가 약해진다. 반복 실행은 평가 비용을 배수로 늘리므로 그 비용도 예산에 포함한다.

성공률만으로는 운영 비용을 설명할 수 없다

성공률이 같아도 태스크당 토큰 소비, 턴 수, 소요 시간이 다르면 선택은 달라진다. 성공률이 같은 두 모델 가운데 한쪽의 비용이 두 배라면 운영 판단은 같을 수 없다. 실패 실행에 사용된 토큰도 회수되지 않으므로 비용 집계에서 제외하면 안 된다.

채택 기준은 성공률 하한, 분산 상한, 태스크당 비용 상한, 지연 상한을 조합한 복합 기준으로 사전에 문서화한다. 결과를 본 뒤 기준을 조정하면 평가가 채택 결정을 정당화하는 절차가 된다.

구분	공개 리더보드 준용	자체 평가셋 검증
비용	없음	실행 비용 발생
소요 시간	즉시	수일~수주
실무 예측력	낮음	높음
하네스 통제	불가	가능
오염 위험	확인 불가	통제 가능
적합 용도	후보 선별	채택 결정

공개 리더보드는 비용 없이 즉시 후보를 좁히고, 많은 모델을 동일 조건에서 비교하는 데 유용하다. 반면 하네스가 조직 환경과 다를 수 있고 학습 데이터 오염 여부도 확인하기 어려워 실무 예측력은 낮다.

자체 평가셋은 조직의 저장소·도구·관행을 반영하고 하네스와 오염 위험을 통제할 수 있다. 대신 구축과 실행에 비용이 들고, 태스크 수가 적으면 신뢰구간이 넓어진다. 두 방식은 대체재가 아니다. 리더보드로 후보를 3~5개로 줄인 뒤 자체 평가셋으로 채택을 결정하는 순차 구성이 비용과 예측력의 균형점이 된다.

후보 선별 단계에서는 단일 실행으로 다수 모델을 빠르게 훑을 수 있다. 최종 후보 2~3개를 비교할 때는 다회 실행으로 성공률과 분산을 확인한다. 이 구분은 반복 비용을 통제하면서도 운 좋은 한 번의 실행이 채택 근거가 되는 문제를 줄인다.

결과를 시계열 자산으로 관리한다

평가 결과는 모델, 하네스, 태스크 스위트 버전을 키로 저장하고 시계열로 비교한다. 결과를 남기지 않은 채 매번 실행하면 어떤 변화가 있었는지 알 수 없다. 리포트에는 신뢰구간도 표시한다. 후보 간 점수 차이가 신뢰구간 안에 있으면 차이가 없다고 보고해야 한다.

재평가 조건도 미리 등록한다. 모델 세대 교체, 동작 편차 감지, 하네스 변경, 태스크 스위트 갱신, 정기 주기 도달이 트리거가 된다. 초기 평가만 수행하면 시간이 지날수록 채택 근거는 낡는다.

실행 환경은 격리하고 초기 상태를 재현 가능하게 만든다. 환경 오염은 곧 측정 오염으로 이어진다. 점수뿐 아니라 평가 실행 로그도 보관해야 실패 원인을 되짚을 수 있다. 평가셋 소유자와 채택 결정 책임자를 분리하고, 하네스가 공개되지 않은 벤더 제출 벤치마크 결과만으로 채택하지 않는 원칙을 문서화한다.

하네스 공개와 복합 지표가 평가 기준이 되는 흐름

에이전트 벤치마크 점수가 하네스 구성에 크게 의존한다는 인식이 확산되면, 하네스 공개 여부는 점수 신뢰도를 판단하는 기준이 된다. 조직별 자체 평가셋 구축은 모델 채택 절차의 표준 단계로 편입되고, 평가 인프라도 관리해야 할 자산이 된다.

채택 기준은 성공률 하나에서 비용·지연·재시도율을 포함한 복합 지표로 이동한다. 다회 실행의 분산 보고도 벤치마크 발표의 기본 요건으로 요구되며, 단일 실행 점수만 제시한 결과의 인용 가치는 낮아지는 흐름이다.