에이전트가 모든 평가를 통과하고도 하루에 4,000달러를 쓰고 있다면

여기에 아무도 로드맵에 넣지 않는 실패 모드(failure mode)가 있습니다. 바로 에이전트가 제대로 작동한다는 것입니다. 에이전트는 올바르게 답변합니다. 당신의 골든 세트(golden set)를 통과합니다. 당신의 모델 기반 평가자(model-as-judge)는 9.2점을 줍니다. 환각 체크(hallucination checks)도 모두 통과(green) 상태입니다. 그러고 나서 재무팀이 추론 비용 청구서를 전달하며, 지난 3주 동안 정확히 무엇을 하고 있었는지 정중하게 묻습니다.

대부분의 평가 스위트(eval suites)는 하나의 축만을 측정합니다. 즉, 출력이 정확했는가 하는 점입니다. 이것은 모든 사람이 데모와 리더보드(leaderboards)에서 복사해 오는 축입니다. 하지만 "정확함"은 필요조건일 뿐, 충분조건은 아닙니다. 실제 서비스되는 에이전트에는 현실과 접촉했을 때 생존 여부를 결정하는 최소 세 가지의 차원이 더 있습니다. 바로 **비용(cost), 지연 시간(latency), 그리고 도구 호출 효율성(tool-call efficiency)**입니다. 하지만 거의 아무도 이를 점수화하지 않습니다. 그래서 에이전트들은 대시보드의 숫자가 아닌 사고(incident)가 될 때까지, 릴리스가 거듭될수록 조용히 퇴보합니다.

저는 운영 지표(operational metrics)가 사후 모니터링 대상이 아니라 그 자체로 평가(evals)이며, 이를 어떻게 연결할 수 있는지 논증하고자 합니다.

"정확함"은 측정하기에 가장 저렴하며 가장 불완전하다

에이전트의 두 버전 사이에서 실제로 무엇이 변하는지 생각해 보십시오. 시스템 프롬프트(system prompt)를 미세 조정합니다. "단계별로 생각하기(think step by step)"라는 유도 문구를 추가합니다. 모델을 업그레이드합니다. "만약을 대비해" 검색(retrieval) 단계를 추가합니다. 이러한 변화 하나하나가 정확도는 그대로 유지하면서도, 토큰 사용량을 조용히 두 배로 늘리거나, 지연 시간을 3초 추가하거나, 혹은 예전에는 두 단계면 끝났을 질문에 대해 에이전트를 14단계의 도구 호출 소용돌이(tool-calling spiral)로 몰아넣을 수 있습니다.

당신의 정확도 평가(correctness eval)는 이 중 그 어떤 것도 잡아내지 못할 것입니다. 설계상, 그것은 답변이 어떻게 생성되었는지에 대해서는 눈이 멀어 있습니다. 오직 최종 문자열(string)만을 바라볼 뿐입니다. 이는 에이전트 시스템에서 가장 비용이 많이 드는 퇴보가, 순진한 평가 스위트가 구조적으로 볼 수 없는 바로 그 지점에서 발생한다는 것을 의미합니다.

해결책은 더 많은 정확도 테스트를 하는 것이 아닙니다. 에이전트가 답변에 도달한 전체 기록인 트레이스(trace)를 일급 평가 대상(first-class eval target)으로 취급하는 것입니다.

두 가지 측면: 출력 점수 매기기 vs 경로 캡처하기

이 지점에서 하나의 단위로 제공되는 두 가지 도구가 제 역할을 다하게 되며, 이들은 서로 다른 것을 측정하기 때문에 둘 다 필요합니다.

agent-eval은 에이전트의 출력을 점수 매기고 게이트(gate) 역할을 합니다. 이는 결정론적 검사(deterministic checks), 모델 기반 평가(model-as-judge), 드리프트(drift), 환각(hallucination)과 같은 어설션(assertion)을 실행하며, 결정적으로 운영 지표(operational metrics)에 대해서도 어설션을 수행할 수 있습니다. 즉, 수치가 임계치를 넘었을 때 빌드를 실패하게 만드는 역할을 합니다.

AgentLens는 _트레이스(trace)_를 캡처합니다. 모든 모델 호출과 도구 단계, 실제로 전송된 해결된 입력값(resolved inputs), 돌아온 가공되지 않은 출력값(raw outputs), 토큰 수, 그리고 단계별 실제 소요 시간(wall-clock timings)을 기록합니다. 이러한 트레이스가 없다면 운영 평가(operational eval) 신호는 디버깅이 불가능합니다. 비용이 40% 증가했다는 사실은 알 수 있겠지만, _어느 단계_에서 발생했는지는 전혀 알 수 없게 됩니다. agent-eval이 청구서가 두 배로 늘어났음을 알려준다면, AgentLens는 잘못된 캐시 키(cache key) 때문에 검색(retrieval) 단계가 세 번 실행되었음을 알려줍니다.

당신은 출력을 점수 매기고, 경로를 캡처합니다. 경로는 점수가 단순히 경고를 주는 것에 그치지 않고 실행 가능한(actionable) 정보가 되도록 만듭니다. 하나만 있고 다른 하나가 없다면 그것은 절반의 워크플로우에 불과합니다.

운영 평가(operational eval)의 실제 모습

구체적인 예를 들어보겠습니다. AgentLens는 실행당 구조화된 트레이스를 제공하고, agent-eval은 이를 바탕으로 어설션을 수행할 수 있게 해줍니다. 그 형태는 다음과 같습니다:

import { defineEval, runEval } from "agent-eval";
import { getTrace } from "agentlens";

...

이 방식이 작동하게 만드는 세 가지 요소가 있으며, 이는 제가 옹호할 저의 견해입니다.

1. 예산(budgets)은 정확성 어설션(correctness assertions) 바로 옆에 존재해야 합니다. 누군가 금요일에 슬쩍 쳐다보는 Grafana 패널에 있는 것이 아닙니다. 동일한 파일 내에 존재하며, 동일한 process.exit(1)에 의해 강제되어야 합니다. 5배의 토큰 회귀(token regression)는 오답과 동일한 권위로 빌드를 실패시켜야 합니다. 운영 측면에서 그것은 똑같은 결함이기 때문입니다.

2. 수치는 재계측(re-instrumentation)이 아니라 트레이스(trace)에서 가져옵니다. 에이전트 곳곳에 console.time을 뿌려대는 것이 아닙니다. AgentLens는 실행의 부수 효과(side effect)로 모든 단계의 토큰과 타이밍을 이미 기록했습니다. agent-eval은 단지 이를 다시 읽어올 뿐입니다. 만약 운영 지표를 위해 별도의 계측(instrumentation) 단계가 필요하다면, 당신은 이를 건너뛸 것이고, 스스로도 그럴 것이라는 사실을 알고 있을 것입니다.

3. 단순히 '통과(pass)' 여부만이 아니라 값(value)에 대해 단언(assert)하세요. 숫자를 저장하십시오. 예산이 초과되는 날, 당신의 바로 다음 질문은 "얼마나, 그리고 언제부터 그랬는가?"가 될 것이기 때문입니다. 그리고 그것은 불리언(boolean) 값이 아니라 추세(trend)입니다.

서서히 진행되는 출혈(slow bleed) 포착하기

위험한 회귀(regression)는 좀처럼 절벽처럼 급격하게 나타나지 않습니다. 그것은 서서히 진행되는 출혈과 같습니다. 4,100 토큰, 그다음 4,400 토큰, 그다음 4,900 토큰. 각각은 예산 범위 내에 있지만, 어느 날 예산을 초과하게 되면 당신은 지난 40개의 PR 중 어떤 것이 원인이 되었는지 알 수 없게 됩니다.

agent-eval은 실행당 트레이스에서 파생된 값(trace-derived values)을 영구 저장하므로, 이를 비교(diff)할 수 있습니다:

import { compareRuns } from "agent-eval";

const diff = await compareRuns({ base: "main", head: "PR-512" });
...

PR에서 토큰이 15% 급증했다면, 모든 절대적 예산이 여전히 통과하더라도 그것은 하나의 '대화 주제'가 됩니다. 그리고 경고에 AgentLens의 headRunId가 포함되어 있기 때문에, 리뷰어는 수치가 변한 정확한 단계로 단 한 번의 클릭만으로 이동할 수 있습니다. 평가는 회귀가 발생했음을 말해주고, 트레이스는 그 이유를 말해줍니다. 당신은 PR 스레드에서 논쟁할 필요가 없습니다. 그냥 트레이스를 열면 됩니다.

불편한 진실

이를 채택한다는 것은 당신의 에이전트가 가진 비용과 지연 시간(latency) 프로필이 구현 세부 사항(implementation detail)이 아니라 하나의 '제품 표면(product surface)'임을 인정하는 것을 의미합니다. "안전하게 하기 위해 도구 호출(tool call)을 하나 더 추가하자"라는 반사적인 행동은, 정당화 가능한 작은 변화들을 하나씩 쌓아 올려 하루 400달러짜리 에이전트를 하루 4,000달러짜리 에이전트로 만드는 바로 그 방식입니다. 그 변화들 중 어느 것도 개별적으로는 틀리지 않았습니다. 하지만 그 '합계'가 바로 장애(incident)가 됩니다.

그러니 수치화하십시오. agent-eval로 출력을 점수화하고, AgentLens로 경로를 캡처하여, 에이전트가 정답을 맞히더라도 비용이 과다하게 발생할 경우 두 지표가 결합하여 빌드(build)를 실패하게 만드십시오. 정확성(Correctness)은 사용자에 대해 정직함을 유지하게 해줍니다. 운영 평가(Operational evals)는 프로덕션(production) 환경에서 해당 시스템을 실행해야 하는 모든 사람, 즉 결국에는 당신 자신에 대해 정직함을 유지하게 해줍니다.

모든 정확성 평가(correctness eval)를 통과하고도 해당 기능의 비용을 파산 수준으로 만드는 에이전트는 가상의 시나리오가 아닙니다. 그것은 측정하기 쉬운 시스템의 절반만을 측정했을 때 나타나는 기본 결과(default outcome)입니다.