에이전트 평가의 절반은 LLM Judge가 필요하지 않다 — 그리고 그것은 가장 뼈아픈 실패를 잡아내는 절반이다

2026년, 에이전트 평가 문제는 더 이상 가설이 아닙니다. LangChain의 State of AI Agents 보고서에 따르면, 57%의 조직이 프로덕션 환경에서 에이전트를 운용하고 있으며, 품질을 최대의 도입 장벽으로 꼽고 있습니다. "에이전트를 어떻게 평가할 것인가"에 대한 표준적인 답은 다음과 같이 정해졌습니다. 궤적(trajectory)을 기록하고, LLM Judge에게 채점하게 하는 것입니다.

LLM-as-judge는 진짜이며, 필요합니다 — 그것이 필요한 부분에는 말이죠. 하지만 에이전트 평가의 상당 부분은 **결정적(deterministic)**이며, Judge를 전혀 필요로 하지 않으면서 기업 환경에서 가장 뼈아픈 실패를 잡아냅니다. 잘못된 도구를 호출하거나, 필수 체크를 건너뛰거나, 기록 시스템에 부정확한 데이터를 쓰는 것과 같은 일들입니다. 바로 이를 보여주기 위해, 작은 결정적 궤적 평가기(deterministic trajectory evaluator)를 만들어 실제 송장 처리 에이전트에게 실행해 보았습니다.

저렴한 결정적 레이어를 먼저, 그리고 제대로 구축하는 것 — 그것이 논거입니다.

에이전트: 거부 조건이 있는 송장 추출

테스트 대상은 의도적으로 평범합니다. 셀프 호스팅 스택(LiteLLM 게이트웨이 → 로컬 모델) 위에서 동작하는 일본어 송장 에이전트입니다. 3개의 도구, 프레임워크 없음 — 네이티브 function calling만을 사용합니다. 에이전트는 만들어내는 대상이 아니라 평가되는 대상이기 때문입니다.

extract_fields(pdf)
— 송장에서 구조화된 필드를 추출

validate(fields)
— 소비세 계산 및 명세가 합계와 일치하는지 체크

write_back(fields)
— (모의) 회계 시스템에 커밋

흥미로운 동작은 추출이 아닙니다 — OCR로도 추출은 가능합니다. 바로 **거부(refusal)**입니다. validate가 실패했을 때, 에이전트는 쓰기 작업을 해서는 안 됩니다. 소비세가 잘못 계산된 송장을 성실하게 커밋하는 에이전트는 에이전트가 없는 것보다 나쁩니다. 부정확한 수치를 "자동화됨"이라는 감사 추적(audit trail)과 함께 장부에 섞어 넣기 때문입니다.

5장의 송장을 준비했습니다. 3장은 깨끗한 상태, 2장은 계산 오류를 심어두었습니다 (1장은 소비세 오류, 1장은 합계 오류). 좋은 에이전트는 깨끗한 3장을 추출하여 쓰기 작업을 수행하고, 망가진 2장에 대해서는 플래그를 세워 거부합니다. 그 거부야말로 가치 제안 그 자체입니다.

Judge 없이 체크할 수 있는 것들

"LLM Judge를 사용하면 된다"라는 프레임워크가 과소평가하고 있는 부분입니다. 이러한 에이전트의 경우, 신경 써야 할 대부분은 의견(opinion)이 아니라 단언(assertion)으로 판정할 수 있습니다.

도구 호출의 정확성 — 기대되는 도구가 유효한 인자(argument)와 함께 호출되었는가?
순서 제약 — write_back은 항상 성공한 validate에 선행되었는가? 이는 궤적의 순수하게 구조적인 특성입니다.
단계 효율성 — 몇 단계가 소요되었는가, 불필요하거나 중복된 호출은 없었는가?
태스크 완료 — 그라운드 트루스(ground truth)에 대해 올바른 일이 일어났는가 (깨끗한 것은 쓰기, 망가진 것은 거부)?

이 중 어느 것도 모델에게 채점하게 할 필요가 없습니다. 정확하고, 재현 가능하며, 프롬프트 변경, 도구 추가, 모델 교체 시마다 CI 게이트로서 실행할 수 있을 만큼 빠릅니다. 2026년의 컨센서스는 바로 이 순서로 수렴하고 있습니다 — 저렴한 결정적 체크를 먼저 수행하고, 규칙이 정말로 닿지 않는 부분(에이전트의 문장이 도움이 되는지, 추론이 건전한지)만 LLM Judge로 격상시키는 것입니다. LLM Judge에 반대하는 것이 아닙니다. 갑자기 그 단계로 뛰어넘으면, 운영상 최악의 실패를 잡아낼 레이어를 건너뛰게 된다는 뜻입니다.

평가기가 정말로 구분해낸다는 것을 증명하기

익숙한 함정 — 이전에 제가 모델 선정 벤치마크에서 빠졌던 함정 — 은, 모든 것을 통과시켜 버리는 평가기입니다. 좋은 궤적에 도장을 찍어주는 평가기는 아무것도 알려주지 않습니다. 나쁜 것을 떨어뜨린다는 것을 보여주어야 합니다.

그래서 단순히 5개의 실제 (통과하는) 궤적만으로 실행하지 않았습니다. 의도적으로 망가진 궤적을 구축하여, 각각이 결정적으로 포착되는지 확인했습니다.

구축된 실패	포착 여부	방식
validate를 호출하지 않고 write_back 수행	✅	필수 도구 결여 + 순서 위반: "step 2 write_back: 선행하는 validate 없음"
실패한 validate 이후에 write_back 수행	✅	순서 위반: "'passed'가 한 번도 True가 되지 않음"
불필요하거나 예기치 않은 추가적인 도구 호출	✅	진단으로서 표면화 (불필요한 카운트, 예기치 않은 도구 목록)
거부해야 할 송장에 대한 write_back	✅	거부 규약에서의 금지 도구 위반

실제 궤적(trajectory)에서는: 깨끗한 3개는 각각 3단계·위반 제로로 통과했고, 망가진 2개는 올바르게 2단계·write_back 없음·상태 flagged로 나타났습니다.

평가기는 "옳은 일을 했다"와 "틀린 일을 했다"를 구분합니다 — 이것이 평가기를 실행할 가치를 만드는 유일한 속성입니다.

사이런트 궤적 리그레션 (Silent Trajectory Regression)

명백한 오답보다 더 까다로운 실패가 있습니다. 에이전트가 태스크를 *완료(complete)*는 계속하지만, 그 경로가 조용히 악화되는 경우입니다 — 프롬프트 조정이나 모델 교체 후에 단계가 늘어나거나, 가끔 체크를 건너뛰거나, 위반율이 서서히 올라가는 식입니다. 결과(outcome)만을 보는 평가는 이를 완전히 놓칩니다. 결과 자체는 여전히 문제없어 보이기 때문입니다.

평가기는 페어 부트스트랩 리그레션 체크(Pair-bootstrap regression check, 이 도구의 검색 지표 버전에서 계승한 것)를 궤적 수준에서 재사용합니다. 베이스라인 궤적 군과 후보 궤적 군을 비교하여, 완료율은 정체되어 있더라도 위반율이나 단계 효율성이 유의미하게 악화되면 경고를 보냅니다. 테스트에서는 좋은 궤적 8개의 베이스라인에 대해, 나쁜 4개 + 좋은 4개의 후보군을 넣었을 때 경고가 울렸고(완료율 -0.50, 위반 +0.50), 동일한 2회의 실행은 변화가 없어 올바르게 침묵했습니다.

이것이 잘못된 도구일 때

솔직한 경계선을 긋자면, 이 점이 중요합니다. 에이전트가 항상 동일한 고정 시퀀스를 실행한다면 — 매번 retrieve, generate, format — 경로를 채점해도 얻을 것이 적습니다. 결과가 이미 필요한 정보를 알려주기 때문입니다. 또한 초기 프로토타이핑 단계에서 에이전트가 무엇을 해야 할지를 아직 탐색 중이라면, 궤적 사양을 형식화하는 것은 시기상조입니다.

궤적 평가가 가치를 갖는 것은 경로에 *위반될 수 있는 제약(constraints)*이 있을 때입니다 — "성공한 validate 없이 쓰기 작업을 하지 마라"와 같은 것 말이죠. 저의 송장 에이전트는 정확히 그러한 성격을 가지고 있으므로, 구조적 체크가 여기서 가치를 발휘합니다. 다른 에이전트에는 필요 없을 수도 있습니다. 자신이 어느 케이스에 속해 있는지 아는 것도 판단의 일부입니다.

훔쳐올 가치가 있는 설계 결정

메트릭 자체보다 더 효과적이었던 두 가지 결정입니다.

순서 제약은 코드에 의해 강제되어야 하며, 단지 평가되는 것에 그쳐서는 안 됩니다. 에이전트의 write_back에는 Python 측의 가드(guard)가 있어, validate가 성공하지 않는 한 커밋을 거부합니다 — LLM이 지시를 따르기로 "결정"했는지 여부와는 독립적으로 작동합니다. 에이전트가 프롬프트의 단계 순서를 항상 지킬 것이라고 신뢰할 수는 없습니다. 실질적인 제약은 코드에 속해야 하며, 평가기는 그 위에서 궤적이 이를 존중했는지 확인하는 것입니다. 프롬프트에 대한 맹신이 아닌, 다층 방어(defense in depth)입니다.

평가는 설정 가능해야 하며, 절대적이지 않아야 합니다. 예기치 않은 도구를 호출한다고 해서 자동으로 실패 처리되지는 않습니다 — 명시적으로 금지 목록에 추가하지 않는 한, 진단으로서 표면화될 뿐입니다. 태스크마다 허용하는 느슨함의 정도는 다릅니다. 엄격함은 당신이 작성하는 규약의 성격이지, 평가기에 박제되어 있어서는 안 됩니다. 이것은 기능입니다. 이 태스크에 있어 "옳다"는 것이 무엇을 의미하는지 기술하도록 강제하는 것입니다.

결정적인 에이전트 평가가 이야기의 전부는 아닙니다 — 그 위의 LLM Judge 계층은 실재하며, 규칙이 닿지 않는 차원을 위해 존재합니다. 하지만 그것은 상대적으로 저렴한 계층이며, CI 게이트(gate)로 만들 수 있는 계층입니다. 기록 시스템을 사용하는 기업용 에이전트에게 있어서, 이는 가장 용납할 수 없는 실패를 잡아내는 계층입니다. 먼저 실행하고, 제대로 하십시오.

평가기 (의존성 제로, 결정적): eval-sanity v0.3

송장 에이전트 및 해당 궤적: onprem-llm-stack/payloads/invoice-agent

Discussion