벤치마크 점수가 높아도 실환경에서 실패하는 이유는 평가 설계의 차이에 있다. 에이전트 평가에서 벤치마크와 실환경 지표를 어떻게 나눠야 하는지 설명한다.
이하는 실제 엔터프라이즈 도입 환경에서 반복적으로 관찰되는 패턴을 바탕으로 구성한 가상 시나리오다.
한 IT 서비스 기업의 AI 도입팀이 코드 리뷰 자동화 에이전트를 선정하는 과정을 생각해보자. 팀은 HumanEval이라는 코딩 벤치마크에서 상위 3위 안에 드는 모델을 기반으로 에이전트를 구축했다. 벤치마크 점수는 87%. 내부 PoC에서도 성공률 82%가 나왔다.
3개월 뒤 결과는 달랐다. 실제 GitHub 이슈와 멀티파일 변경 요청 앞에서 에이전트의 유효 완료율은 41%에 머물렀다. 오류의 절반은 에이전트가 "성공"을 반환한 상태에서 발생했다. 틀린 파일을 수정하거나, 없는 함수를 참조하거나, 테스트가 실제로는 실패하는데 통과로 기록했다.
팀은 처음에 모델 문제라고 생각했다. 더 높은 벤치마크 점수의 모델로 교체했다. 결과는 거의 같았다.
모델만의 문제가 아니었다. 모델을 감싼 에이전트 워크플로우, 툴 호출 설계, 권한 구조, 그리고 무엇보다 — 평가 방식 자체가 문제였다. 벤치마크가 측정하는 것과 현장이 요구하는 것이 처음부터 달랐기 때문이다.
주의: 아래 한계는 단편적·정적 과제 위주의 기존 대중 벤치마크(HumanEval, MMLU 등)에 해당한다. SWE-bench Verified, TheAgentCompany처럼 멀티스텝·툴 사용을 반영한 벤치마크는 더 현실적이지만, 그조차도 실제 엔터프라이즈 환경의 불안정성·보안·비용 제약을 완전히 커버하지는 못한다.
HumanEval, MMLU 같은 대중 벤치마크의 공통점은 단일 응답으로 끝나는 작업을 측정한다는 점이다. 함수 하나를 작성하거나, 질문 하나에 답하는 것. 자동화하기 쉽고 점수가 명확하다.
엔터프라이즈 에이전트가 실제로 처리하는 업무는 다르다. 수십 단계를 거쳐야 하고, 도중에 외부 시스템을 호출하며, 앞 단계의 결과가 뒤 단계 입력이 된다. WebArena 연구팀이 웹 에이전트를 현실적인 e-commerce, 이슈 트래커, CMS 환경에서 테스트한 결과가 이 간극을 보여준다. 인간은 같은 작업을 78.24%의 성공률로 처리했다. GPT-4 기반 에이전트의 성공률은 14.41%였다[1]. MMLU나 코딩 벤치마크에서 최상위권인 동일한 모델이, 실제 연속 작업 환경에서는 인간의 5분의 1 수준으로 떨어졌다.
NaturalCodeBench(NCB)는 실제 개발자들의 코딩 요청 402개로 구성됐다. 이 벤치마크에서 39개 LLM을 테스트한 결과, HumanEval 점수가 비슷한 모델들이 NCB에서는 두 자릿수 차이가 났다. HumanEval에서 90% 가까운 점수를 기록한 모델이 NCB에서는 53% 수준이었다[2]. 벤치마크 점수가 거의 같아도 실제 코딩 태스크에서 결과가 크게 다를 수 있다.
벤치마크 환경은 정해진 입력이 있고, 시스템이 예상대로 응답하며, 레이턴시가 없다. 엔터프라이즈 현장은 다르다. 외부 API가 가끔 오류를 반환하고, UI가 A/B 테스트로 레이아웃이 바뀌어 있으며, 인증 세션이 만료된다.
이것은 단순히 "평가가 어렵다"는 문제가 아니라 시스템의 복원력(Resilience) 설계 문제이기도 하다. 현실적인 장시간 웹 탐색 작업을 다루는 AssistantBench 연구에서 최고 성능 모델조차 정확도 25% 미만에 그쳤고, 벤치마크 환경과 달리 실제 노이즈(네트워크 지연, 간헐적 UI 오류, 세션 만료)가 추가될 때 성공률이 30%포인트 이상 하락하는 케이스가 보고됐다[3]. 클린한 환경에서 측정된 점수는 이런 저하를 예고하지 못한다.
표준 벤치마크는 "맞았냐, 틀렸냐"를 측정한다. 엔터프라이즈는 다른 질문을 한다. "응답당 비용이 얼마인가?", "보안 위협에 얼마나 강한가?", "장애 시 어떻게 롤백하는가?"
실제 엔터프라이즈 채팅봇 대화 2,133건과 423개 워크플로우를 기반으로 만든 CLASSIC은 정확도 외에 비용, 레이턴시, 안정성, 보안을 함께 측정하는 복합 평가 체계로 최근 제안된 연구다[4]. 이 벤치마크에서 최고 성능 LLM은 76.1%의 정확도를 달성했다. 그런데 비용 항목에서는 정확도가 비슷한 모델들 사이에서 요청당 비용이 5.4배까지 차이가 났다. 보안 항목에서 탈옥 시도 거부율은 한 모델이 78.5%, 다른 모델이 99.8%였다. 정확도 벤치마크만으로는 이 차이를 발견할 수 없었다.
에이전트 시스템을 단일 성공률로 평가하면 두 가지 근본 문제가 생긴다.
첫 번째: 비결정론이 단일 측정값을 불안정하게 만든다.
LLM은 동일한 입력에 대해 다른 응답을 생성할 수 있다. Temperature를 0으로 설정해도 GPU 병렬 처리 방식이나 배치 스케줄링에 따라 출력이 달라지는 경우가 있다 — 이는 모델 자체의 문제라기보다 인프라 레벨의 부동소수점 연산 방식 차이에서 비롯되기도 한다. 호스팅 LLM 시스템을 대상으로 한 재현성 연구에 따르면, 통상적인 조건에서 반복 실행 시 정확도 편차가 5~15%포인트 수준이며, 입력이 경계 케이스에 해당하거나 인프라 조건이 극단적인 경우에는 더 크게 벌어질 수 있다[5].
RPA는 같은 입력에 같은 결과가 보장되므로 단일 테스트로도 충분히 검증할 수 있다. 에이전트 시스템은 다르다. 오늘 82% 성공률이 내일도 82%라는 보장이 없다.
두 번째: 전체 성공률은 "어디서 실패하는가"를 숨긴다.
전체 성공률 80%는 특정 업무 유형, 특정 언어, 특정 권한 경계에서 체계적으로 실패하더라도 집계에서 희석될 수 있다. 예를 들어 에이전트가 읽기 전용 조회에서는 95% 성공하지만, 실제 데이터를 변경하는 쓰기 작업에서는 40% 성공률이어도 전체 볼륨 비중에 따라 집계 지표에는 잘 드러나지 않는다.
TheAgentCompany는 GitLab, OwnCloud, Rocket.Chat을 포함한 컨테이너화된 소프트웨어 기업 환경에서 에이전트가 실제 업무를 처리하도록 했다. 최고 모델을 사용해도 자율 완료율은 24%에 그쳤다[6]. 실패는 멀티에이전트 커뮤니케이션, 복잡한 UI 탐색, 장기 계획이 필요한 작업에 집중됐다. 표준 벤치마크에서는 이런 실패 패턴이 드러나지 않는다.
먼저 평가 대상을 명확히 해야 한다. 에이전트 시스템은 최소 세 레이어로 구성된다:
대부분의 벤치마크는 모델 레이어만 측정한다. 그러나 현장 실패의 상당 부분은 에이전트 레이어와 운영 레이어에서 발생한다.
에이전트의 각 Tool call 입출력, 중간 추론 단계, API 호출 순서를 모두 기록하는 Observability 레이어가 필요하다. LangSmith, Langfuse, Arize Phoenix 같은 에이전트 특화 플랫폼이 이 역할을 한다. 최종 결과가 "성공"으로 기록되더라도 내부 경로가 올바른지를 추적해야 한다.
트레이스에서 추출해야 할 핵심 지표는 다음과 같다:
한 가지 주의할 점이 있다. LangSmith, Langfuse 같은 외부 SaaS 플랫폼으로 트레이스를 내보낼 때 고객 데이터가 포함될 수 있다. 규정 준수 요건이 엄격한 금융·의료 환경이라면 On-premise 설치형 Observability 솔루션이나 사내 구축 파이프라인을 별도로 검토해야 한다.
모든 트레이스를 사람이 직접 리뷰하는 것은 현실적으로 불가능하다. 여기서 더 강력한 LLM을 평가자로 활용하는 방법이 실무에서 널리 쓰인다. 에이전트가 생성한 출력을 다른 모델이 채점하거나, 추론 경로의 일관성을 자동으로 검증하게 하는 구조다.
LLM-as-a-Judge는 완벽하지 않다. 평가자 모델 자체의 편향이 개입될 수 있고, "더 좋은 모델로 평가한다"는 논리가 순환 구조처럼 보일 수 있다. 이를 보완하려면 판정 모델이 실제 정답(Ground Truth)과 얼마나 일치하는지를 별도로 검증하는 과정이 필요하다 — 적어도 초기 도입 시점에 도메인 전문가가 샘플을 함께 채점해 기준을 맞추는 과정을 거쳐야 한다.
또한 100% 트레이스에 LLM-as-a-Judge를 적용하면 평가 비용 자체가 상당해진다. 현실적인 접근은 전수 평가 대신 위험도 기반 샘플링이다. 읽기 전용 작업은 5~10% 샘플만 판정에 돌리고, 데이터를 변경하는 쓰기 작업은 초기 배포 기간 중 더 높은 비율을 적용하는 방식이다.
고위험 작업 경로에서는 LLM-as-a-Judge를 1차 필터로 쓰고, 그 중 의심 케이스만 사람이 최종 확인하는 방식이 균형점이 된다.
에이전트 평가는 도입 전 한 번이 아니라 배포 후 지속적으로 이어져야 한다. 두 단계를 명확히 구분해야 한다.
도입 전 평가: 실제 업무와 유사한 작업 세트로 구성한 내부 테스트 셋 활용. 이때 업무 유형별 성공률을 분리해서 측정한다. 읽기 전용 조회/단순 요약/외부 API 쓰기 작업을 구분하고, 위험도가 높은 작업 유형에 더 엄격한 기준을 적용한다.
운영 중 지속 평가: 배포 후에도 성능 drift를 모니터링해야 한다. 프롬프트 변경, 모델 버전 업데이트, 외부 API 스펙 변경이 생길 때마다 이전에 통과하던 작업이 실패할 수 있다. 이를 잡기 위한 회귀 테스트(Regression Testing) — 핵심 업무 경로에 대해 변경 전후 성능을 비교하는 자동화된 테스트 — 가 있어야 한다. 대략적인 기준으로, 핵심 업무 경로 성공률이 5%포인트 이상 하락하거나 보안 거부율이 3%포인트 이상 떨어지면 배포를 중단하고 원인을 확인하는 게이트를 두는 방식이 실무에서 많이 쓰인다. 임계치는 업무 위험도에 따라 조직마다 다르게 설정해야 한다.
도입 전 평가 기준을 단일 성공률이 아닌 복합 지표로 구성해야 한다:
정확도 (업무 유형별)
비용 효율
안정성
보안
오류 파급 범위
위 수치는 예시다. 업무 위험도, 데이터 민감도, 조직의 실패 허용치에 따라 조정해야 한다.
에이전트 평가에서 자주 빠지는 영역이 운영 레이어 자체의 검증이다. 여기서 봐야 할 질문은 다음과 같다:
이 항목들은 정확도 측정으로는 드러나지 않는다. 의도적으로 설계된 테스트 케이스(잘못된 권한 요청, 불완전한 컨텍스트, 예외 상황)로 검증해야 한다.
자동화된 메트릭이 놓치는 것을 사람이 잡는다. 에이전트가 외부 시스템에 데이터를 변경하거나 쓰기 작업을 하는 경로에서는 초기 배포 기간 중 샘플링 리뷰가 필요하다. 이것은 단순한 품질 확인이 아니라, LLM-as-a-Judge가 놓친 도메인 특화 오류를 감지하고 평가 기준 자체를 개선하기 위한 구조적 피드백 루프다.
에이전트 도입 전 평가 단계에서 아래를 확인하라:
3개 이상 해당하지 않는다면, 벤치마크 점수를 신뢰하고 도입했다가 현장에서 예상치 못한 실패를 마주칠 가능성이 높다.
에이전트 평가 구조를 어떻게 설계해야 할지 논의하고 싶다면 →
