AI 에이전트 평가가 너무 일찍 종료됩니다 | Focused Labs

AI 에이전트 (AI agent) 평가는 너무 일찍 종료됩니다.

초기 점수는 테스트 환경 (harness)이 팀이 상상한 몇 가지 사례를 실행할 수 있었음을 나타내지만, 실제 증거는 프로덕션 (production) 환경에서 나타날 것입니다.

현재의 평가 방법들이 주로 성공 여부에만 집중하고 있다는 명확한 증거가 있습니다. 2026년 발표된 15개 벤치마크(benchmarks) 리뷰에 따르면, 15개 벤치마크 중 어느 것도 안전성 (safety) 및 보안 (security)을 점수에 포함하지 않았으며, 15개 벤치마크 중 어느 것도 비용 효율성 (cost efficiency)을 주요 프로토콜에 포함하지 않았습니다. 또한 15개 벤치마크 중 13개는 주로 또는 전적으로 이진 성공 지표 (binary success metrics)에 의존했으며, 리뷰의 프레임워크 내에서 15개 벤치마크 중 어느 것도 배포 준비도 (deployment-readiness) 커버리지 50%에 도달하지 못했습니다.

벤치마크는 일반적인 작업을 완료하는 능력을 테스트할 수 있습니다. 또한 제품이 실제로 출시되기 전에 릴리스 (release)에 대한 오프라인 평가 (offline evaluation)도 이루어집니다. 하지만 평가의 진짜 작업은 출시 후에 시작됩니다.

평가 작업은 계속해서 이어집니다.

벤치마크는 능력을 스크리닝합니다

에이전트적 행동 (agentic behaviors)에 대한 공개 벤치마크는 배포를 위한 근거로서 취약합니다. 왜냐하면 이들은 모델과 테스트 환경 (harness) 행동의 가능한 범위 내에서 제한된 조건만을 테스트하기 때문입니다. 벤치마크는 공개적인 능력 테스트, 대략적인 시장 언어, 그리고 유사한 가정하에 유사한 설계들을 비교하는 수단으로 기능합니다. 벤치마크의 수치는 배포를 위한 근거가 될 수 없으며, 프로덕션 준비도 (production-readiness)의 지표와 혼동해서는 안 됩니다.

NVIDIA는 모델 능력 평가 (model-capability evaluation)와 에이전트 평가 (agent evaluation)는 서로 다른 것이라고 명시합니다. 에이전트는 계획을 세우고, 도구를 사용하며, 환경 피드백에 반응하고, 결과를 달성하며, 예산(budget) 내에서 작동하는 엔드 투 엔드 (end-to-end) 시스템입니다. 이는 에이전트가 근본적으로 다른 수단을 통해 동일한 결과를 어떻게 달성할 수 있는지를 보여줍니다. 한 사례에서는 테스트 환경 (harness)이 올바른 도구를 사용하고 정답을 위해 적절하게 논리를 전개합니다. 다른 사례에서는 테스트 환경이 갈팡질팡하며, 사실을 조작하고, 토큰 (tokens)을 낭비하며, 우연히 복구하는 등의 행위를 합니다. 이 모든 과정이 결국 동일한 정답으로 이어집니다.

이는 경로상의 실패를 숨깁니다.

우리는 이전에 에이전트 벤치마크 점수는 테스트 환경을 측정하며, 에이전트 평가는 테스트 환경을 유도해야 한다는 점을 확립했습니다. 이 글은 출시 후 그러한 유도 신호 (steering signal)가 발생하는 추적 (traces)을 매핑합니다. 해당 추적들은 실제 도구, 실제 권한, 실제 사용자와 함께 에이전트를 실행하며, 사람들이 단계를 반복하고, 지루해하며, 프로세스 중간에 작업을 포기할 때 나타나는 지루한 상황들을 보여줍니다.

최종 답변은 망가진 실행을 숨깁니다

먼저, 출력 수준 (output-level) 테스트에는 안심하게 만드는 실패 모드 (failure mode)가 있습니다. 응답은 정확합니다. 어조는 괜찮습니다. 작업은 완료된 것으로 표시됩니다. 테스트 러너 (test runner)는 초록색을 출력합니다.

언뜻 보기에 AI를 에이전트 (agent)로서 평가하는 것은 간단해 보입니다. 에이전트가 테스트 케이스에 대해 올바른 응답을 출력한다면 제대로 작동하는 것처럼 보이기 때문입니다. 문제는 최종 출력 점수 산정 (final-output scoring) 방식이 에이전트를 블랙박스 (black box)로 취급한다는 점입니다. 이는 에이전트가 도구 (tools)를 어떻게 사용하는지, 결과를 어떻게 검증하는지, 또는 정보를 어떻게 검색 (retrieval)하는지를 조사하지 않습니다. AWS의 Agent-EvalKit 기술 문서도 이러한 실패를 지적합니다. 에이전트는 도구 사용 실패 후에도 다듬어진 출력을 반환하거나, 검증 단계를 완전히 건너뛸 수 있습니다 (AWS Machine Learning Blog). 최종 출력 테스트의 실패는 도구 호출 (tool calls), 파라미터 (parameters), 관찰 (observations), 검색된 컨텍스트 (retrieved context), 재시도 (retries), 그리고 부작용 (side effects)에서 나타납니다.

예시를 들면 상황은 금방 불편해집니다. 고객 지원 에이전트가 환불을 올바르게 처리하지만, 잘못된 계정에 대해 처리하는 경우입니다. 보안 에이전트가 취약점에 대해 올바른 티켓을 닫지만, 잘못된 소스를 검증하는 경우입니다. 데이터 에이전트가 데이터 웨어하우스 (warehouse)에 쿼리를 날려 올바르게 보이는 차트를 생성하지만, 사실 에이전트가 해당 테이블을 쿼리할 권한이나 이유가 없는 경우입니다.

점수는 정답뿐만 아니라 경로 (path)를 포괄해야 합니다.

AI를 에이전트로 평가하는 것은 출력을 넘어선 영역입니다. 평가 차원에는 도구-파라미터 정확성 (tool-parameter correctness), 그라운딩 (grounding), 비용 (cost), 지연 시간 (latency), 정책 (policy), 안전성 (safety), 그리고 복구 (recovery)가 포함됩니다. Databricks 또한 AI 라이프사이클 (lifecycle)의 단계를 실험 (experimentation), 오프라인 테스트 (offline testing), 프로덕션 모니터링 (production monitoring), 그리고 개선 (refinement)으로 구분합니다 (Databricks). 최종 출력 점수 산정만으로는 충분하지 않습니다. 전체 궤적 (trajectory)을 점수화해야 합니다.

평가 루프는 온라인 상태를 유지해야 합니다

더 나은 루프는 지루하고 지속적입니다.

공개 벤치마크 (benchmarks)를 개발하세요. 출시 전 개발 데이터셋 (dev dataset)을 대상으로 오프라인 평가 (offline evals)를 수행하세요. 프로덕션 (prod) 환경에서는 다음 사항을 확인하기 위해 트레이스 (traces)를 계측해야 합니다: 도구 호출 (tool calls), 인자 (arguments), 검색된 근거 (evidence retrieved), 도구에 의해 내려진 중간 결정 (intermediate decisions made by the tool), 결정을 내리는 데 걸리는 지연 시간 (latency), 행동을 취하는 데 드는 비용 (cost), 과정 중의 정책 점검 (policy checks), 그리고 도구에 의해 발생하는 다른 도구 및 시스템에 대한 모든 부수 효과 (side effects).

프로덕션의 트레이스를 샘플링하기 위해 온라인 평가기 (online evaluators)를 사용하고, 실패한 모든 트레이스를 오프라인 평가에 사용되는 데이터셋으로 승격시키세요. 이를 통해 검토자 (reviewers)가 평가기 (evaluator)가 무엇을 측정하려고 하는지 이해할 수 있도록 평가를 보정 (calibrate)할 수 있습니다. 이슈에 대한 후속 수정 사항은 재배포 전 오프라인 평가를 통해 다시 실행됩니다.

여기서 평가는 개발, 프로덕션 배포, 온라인 평가기, 실시간 모니터링, 그리고 실제 트레이스에 대한 도메인 전문가 보정 (domain-expert calibration)이라는 생명 주기를 가진 자연스러운 서비스 형태를 띱니다. LangSmith의 평가 워크플로우는 데이터셋 생성으로 시작하여 오프라인 실험, 배포, 온라인 평가기, 모니터링 및 검토로 이어집니다 (LangSmith evaluation docs). Azure Databricks MLflow 3에 따르면, 프로덕션 모니터링은 개발 중에 사용된 것과 동일한 심판 (judges) 및 채점기 (scorers)를 재사용할 수 있고, 개발 및 프로덕션 트레이스를 평가하며, 검토 앱을 통해 도메인 전문가의 피드백을 수집할 수 있습니다 (Azure Databricks MLflow docs).

유용한 평가 루프는 출시 후에도 계속 실행됩니다.

평가 시스템은 출시 보고서가 아닙니다. 오히려 평가 시스템은 프로덕션 환경에서 에이전트 (agent)가 작동하는 운영 루프 (operating loop)입니다. 에이전트의 트레이스는 평가기가 시간이 지남에 따라 관찰하는 근거이며, 데이터셋은 프로덕션의 '흉터 조직 (scar tissue)'으로부터 성장합니다.

에이전트 정확도 (Agent accuracy) 역시 마찬가지로 지속적인 관찰 가능성 (observability)의 문제입니다. 에이전트 정확도의 가치는 에이전트의 행동이 비즈니스 목표, 도구 환경 (tool environment), 정책 경계 (policy boundary), 그리고 사용자의 의도와 일치한다는 주장입니다. 이러한 요소들은 동적이기 때문에, 에이전트 정확도는 관찰 가능성의 문제 (agent accuracy becomes an observability problem)가 됩니다.

트레이스토리 (Trajectory) 평가는 기이한 실패가 드러나는 지점입니다

가장 심각한 에이전트 실패는 트레이스토리 (trajectories) 형태로 나타납니다.

에이전트의 실패는 일정한 경로를 따릅니다 (예: 도구를 잘못된 순서로 호출, 잘못된 파라미터로 올바른 도구 호출, 오래된 정책을 가져온 뒤 이를 바탕으로 유려하게 논쟁, 승인 전 쓰기 작업 수행, 재시도를 통한 비용 예산 소진, 불충분한 상태로 특수 에이전트에게 업무 인계 등).

LangSmith에서의 트레이스토리 평가 (trajectory evaluations)를 위해, 메시지 및 도구 호출 (tool-call) 시퀀스 매칭은 엄격 (strict), 무순서 (unordered), 부분 집합 (subset), 또는 상위 집합 (superset) 방식으로 설정할 수 있습니다. 생성된 시퀀스는 LLM 판사 (LLM judge)에게 전달되어 메시지 및 도구 호출 경로가 수용 가능한지 추론하게 할 수도 있습니다 (LangSmith 트레이스토리 평가 문서).

결제 전 승인. 예외 처리 전 정책 조회. 환불 전 계정 확인. 요약 생성 전 소스 검색. 쓰기 전 승인. 비즈니스 태스크를 완료하는 이러한 일상적인 단계들은 평가 시 반드시 올바른 순서로 지정되어야 합니다.

LangGraph 에이전트의 경우, 평가 파이프라인 (evaluation pipelines)은 관련 데이터셋, 평가기 (evaluators), 회귀 탐지 (regression detection)와 함께 그래프와 밀접하게 결합되어 있어야 합니다. 그래프는 변경되므로, 그래프를 통과하는 관련 경로들은 평가 코드 내부에 명명되어야 합니다.

인간의 검토는 의식이 아니라 교정입니다

자동 평가기(Automated evaluators)는 적절히 교정(calibrated)될 때까지 기본적으로 비활성화 상태입니다. 인간 검토자(Human reviewers) 역시 도구화(instrumented)되기 전까지는 마찬가지로 신뢰하기 어렵습니다. 이 둘을 루프(loop) 안에 함께 넣으면, 시간이 흐르면서 서로를 교정하게 됩니다.

Amazon의 평가 프레임워크에는 모델의 구성 요소, 동작, 품질, 성능, 책임 및 비용뿐만 아니라 최종 출력에 대한 지속적인 모니터링과 인간 참여형 검증(human-in-the-loop validation)이 포함되어 있습니다 (AWS Machine Learning Blog).

인간은 모델을 프로덕션에 출시할지 결정하기 위해 검토하는 것이 아닙니다. 그들은 향후 프로덕션 트레이스(production traces)에 사용될 스코어링 루프(scoring loop)를 교정하는 것입니다. 검토자는 도구 경로(tool path), 평가 결과(evaluator verdict), 정책 컨텍스트(policy context), 부수 효과 수신(side-effect receipt), 그리고 평가 데이터셋을 위한 제안된 행(proposed row)을 확인해야 합니다.

이것이 바로 루브릭(rubrics)이 평가를 런타임 QA로 전환하는 이유입니다. 루브릭은 모델을 위한 재사용 가능한 운영 규칙 세트입니다. 루브릭은 트레이스(traces)를 대상으로 테스트되고, 검토되며, 이의가 제기되고, 프로덕션에서 실패할 경우 업데이트됩니다. 모델의 느낌(vibe)만으로는 잘못된 배포를 막을 수 없습니다.

에이전트 평가 프레임워크는 운영 모델입니다

최고의 AI 에이전트 평가 프레임워크는 소유권(ownership)에 뿌리를 둔 프레임워크입니다.

AI 에이전트 평가를 위한 평가 데이터셋(eval dataset)은 누가 소유합니까? 온라인 평가기(online evaluator)는 누가 소유합니까? 실패한 트레이스는 누가 검토합니까? 프로덕션에서 트레이스가 수집됨에 따라, 프로덕션의 트레이스(수집된 상태 그대로)가 언제 회귀 사례(regression case)가 될지 누가 결정합니까? AI 에이전트 평가에서 트레이스 점수를 매기는 데 사용되는 루브릭을 누가 변경할 수 있으며, AI 에이전트 평가기(scorer)의 점수를 누가 무효화(override)할 수 있습니까? 마지막으로, 통과율(pass rate)은 녹색(정상)을 유지하지만 인간 참여형 AI(HITL)의 작업당 비용이 두 배로 증가한다면 누구에게 페이지(paged)가 발송됩니까?

이러한 질문들은 지루하며, 그것은 좋은 징조입니다. 시스템이 작동하게 만드는 작업은 지루합니다. 시스템을 신뢰할 수 있게 만드는 작업 또한 지루합니다.

전체 역량을 갖춘 운영 모델 (operating model)에는 역량 스크린 (capability screen), 릴리스 게이트 (release gate), 프로덕션 모니터 (production monitor), 리뷰 큐 (review queue), 성장하는 평가 데이터셋 (eval dataset), 그리고 재배포 게이트 (redeploy gate)가 포함됩니다. 또한 프로덕션 환경에서 동작에 영향을 미치는 변경 사항들, 즉 도구 스키마 (tool schema), 데이터베이스 스키마 (database schema), 모델 버전 (model version), 정책 (policy), 프롬프트 (prompt), 루브릭 (rubric), 그리고 회귀 케이스 (regression case)에 대한 실행 기록 (running ledger)을 유지합니다.

KDD 2026은 이제 실시간 사후 시장 모니터링 (post-market monitoring), 모델 진화 (model evolution), 프로덕션 거버넌스 (production governance), 드리프트 탐지 (drift detection), 이상 탐지 (anomaly identification), 그리고 성능 저하 추적 (performance deterioration tracking)을 포함하여, 배포 라이프사이클 (deployment lifecycle) 단계 전반에 걸친 에이전트형 AI (agentic AI) 시스템의 평가 및 신뢰성에 관한 언어를 갖추게 되었습니다 (KDD Workshop on Evaluation and Trustworthiness of Agentic AI). 출시 시점에 평가가 멈춰버린다면, 출시 후에도 계속 동작하는 시스템들은 너무 늦게 평가를 받게 됩니다.

루프를 계속 유지하세요

State of Agent Engineering 2026 설문조사에 따르면, 응답자의 57.3%가 이미 프로덕션 환경에서 AI 에이전트를 실행하고 있습니다. 그들 중 약 3분의 1에게 품질은 가장 큰 과제입니다. 한편, 88.6%는 이미 관측성 (observability)을 채택했지만, 평가 (evals)를 채택한 비율은 51.7%에 불과했습니다 (State of Agent Engineering). 트레이스 저장 (trace storage)과 효과적인 평가 (effective evaluation) 사이에는 큰 격차가 존재합니다.

그 격차는 해가 될 것입니다.