LLM Judge 비용이 Agent보다 더 많이 든다면? 40줄의 코드로 게이팅(Gate) 하세요.

LLM judge (LLM 판사) 비용이란 에이전트(Agent)의 결과물을 생성하는 대신, 그 결과물을 채점하는 데 소비되는 평가(Eval) 비용의 비중을 의미합니다. 이를 제어하기 위해, 네 가지 결정론적 규칙(Deterministic rules)으로 모든 스팬(Span)을 분류(Triage)하고, 불확실한 나머지 부분만 비용이 많이 드는 judge에게 전달하는 40줄짜리 오프라인 프리-게이트(Pre-gate)를 실행하세요. 한 트레이스(Trace) 분석 결과, 이 방법은 judge 비용 비중을 50%에서 16%로 낮추었습니다.

LLM judge 비용은 아무도 FinOps 대시보드에 올리지 않는 항목입니다. 모든 에이전트 스팬을 채점하기 위해 LLM-as-judge를 추가하면 잠은 더 편하게 잘 수 있겠지만, 3주 뒤면 평가(Eval) 레이어가 에이전트 자체 비용의 3분의 1을 조용히 청구하고 있을 것입니다. 이 포스트에서는 40줄짜리 오프라인 미터(Meter)를 사용하여, '수행(Doing)' 대신 '판단(Judging)'하는 데 소비되는 비용 비중을 측정하고, 동일한 트레이스에서 이 비중을 50%에서 16%로 떨어뜨리는 단 하나의 방법을 보여줍니다.

AI 공개 사항: 저는 AI 글쓰기 어시스턴트를 사용하여 이 글을 초안했습니다. 도구, 설정값, 그리고 아래의 모든 숫자는 네트워크 연결이나 API 키 없이 Python 3.13.5 환경에서 judge_gate.py를 실제로 로컬에서 실행한 결과입니다. 저는 직접 실행하고, 종료 코드(Exit codes)를 확인했으며, 결과가 결정론적(Deterministic)임을 확인하기 위해 출력을 두 번 해싱(Hash)했고, 게시하기 전에 모든 줄을 직접 편집했습니다.

저를 자극했던 문장은 이것입니다. Sattyam Jain은 6월 12일 Dev.to에 모든 에이전트 호출에 대해 LLM judge를 실행하는 것을 중단해야 한다는 주장을 담은 포스트를 작성했습니다: "만약 모니터링 비용이 운영 비용의 약 20~25%를 초과한다면, 당신은 잘못된 모니터를 만든 것입니다." (Dev.to) 이는 훌륭한 경험칙(Rule of thumb)입니다. 하지만 당신의 모니터링 비용을 수치화하기 전까지는 반증할 수 없는 이야기이기도 합니다. 그의 포스트는 계층적 아키텍처(저렴한 결정론적 휴리스틱을 먼저 사용하고, 비싼 judge를 마지막에 사용)를 스케치하고 있지만, 당신의 트레이스에 직접 실행해 볼 수 있는 코드는 제공하지 않습니다. 그래서 저는 부족했던 40줄의 코드를 직접 작성했습니다.

이러한 타이밍은 우연이 아닙니다. 현재 업계 전반에 걸쳐 토큰 비용 청구서가 날아오고 있습니다. TechCrunch는 6월 5일 보도를 통해 _"Uber가 2026년 AI 코딩 예산 전체를 4월까지 다 써버렸다"_라고 전했으며, Priceline의 한 직원은 _"일상적인 Cursor 계약 갱신 비용이 4~5배 더 비싸게 돌아왔다"_라고 언급했습니다. (TechCrunch) 이틀 전, Linux Foundation은 _Tokenomics Foundation 출시 의사_를 발표했습니다. 이는 AI 비용 관리를 위한 개방형 표준을 구축하기 위함이며, Jim Zemlin의 말에 따르면 "토큰이 기술 지출의 새로운 단위가 되었기" 때문입니다. (Linux Foundation) 모두가 에이전트(Agent)가 무엇을 소비하는지는 감사(Auditing)하고 있습니다. 하지만 _감시자(Watchdog)_가 무엇을 소비하는지는 거의 아무도 감사하지 않습니다.

그리고 그 감시자 또한 LLM 호출입니다. 당신은 에이전트의 비용을 산정했습니다. 그렇다면 에이전트를 지켜보는 대상의 비용은 산정했습니까?

요약 (TL;DR)

• 모든 스팬(Span)에 LLM 판사(Judge)를 사용하는 것은 엄격함(Rigor)이 아니라, 예산 책정을 잊어버린 두 번째 에이전트입니다. 예상치 못한 비용이 발생하기 전에 미리 가격을 산정하세요.
• judge_gate.py는 40줄로 구성된 오프라인, 키리스(Keyless), 제로 네트워크 스크립트입니다. JSONL 트레이스(Trace)를 입력하면, 4가지 결정론적(Deterministic) 규칙이 각 스팬을 OK / BAD / UNCERTAIN으로 분류하며, 오직 UNCERTAIN인 경우에만 비용이 많이 드는 판사에게 전달됩니다.
• 잘 설계된 50-스팬 트레이스에서, 이 방식은 68%를 저렴하게 해결했으며 단 **32%만을 판사에게 전달 → 판사 비용 점유율 16%**를 기록했습니다 (exit 0, PASS). 반면, 동일한 에이전트를 자유 텍스트(Free text)로 기록했을 때는 **100%가 에스컬레이션(Escalated) → 비용 점유율 50%**를 기록했습니다 (exit 1, FAIL).
• 판사는 실제로 호출되지 않습니다. 대신 구성 가능한 --judge-price 및 --prod-cost 플래그를 통해 _비용이 산정(Priced)_됩니다. 본인의 요율로 대체하여 사용하세요. 저는 중립적인 플레이스홀더(Placeholder) 단위를 제공합니다.
• 종료 코드(Exit code)는 CI 게이트(Gate) 역할을 합니다: 판사 비용 점유율이 예산(기본값 0.25) 이하이면 0, 초과하면 1, 잘못된 입력인 경우 2를 반환합니다. 결정론적(Deterministic)이므로 실행 간에 바이트 단위로 동일합니다.

이 글은 실행 후가 아니라, 실행 전 에이전트를 제어하는 시리즈의 다음 편입니다. 사전 실행 게이트 (pre-execution gate)는 에이전트의 _행동 (action)_을 제어합니다. 성공 게이트 (success gate)는 결과물에서 무엇을 검증할지 결정합니다. 이번 단계는 스택의 한 단계 위입니다. 에이전트를 제어하는 것이 아니라, _판단자 (judge)_를 제어하며, 그 판단자에게 얼마만큼의 비용을 지불할 용의가 있는지를 묻습니다.

"판단 비용 점유율 (judge cost share)"의 실제 의미

제가 계속 목격하는 실패 사례는 다음과 같습니다. 누군가 에이전트가 조용히 실패할 수 있다는 사실(사실임)을 읽고는, 모든 단계를 채점하기 위해 LLM-as-a-judge (판단자로서의 LLM)를 급하게 붙여버립니다. 모든 구간 (span)마다 두 번째 모델 호출이 발생하며, 이는 종종 프론티어 모델 (frontier model)이고, 때로는 방대한 루브릭 (rubric) 프롬프트를 동반합니다. 작동은 합니다. 문제도 잡아냅니다. 그러다 재무 담당자가 왜 평가 (eval) 비용이 에이전트 비용과 맞먹는 수준인지 물으면, 정직한 답변은 "첫 번째 모델이 수행하는 모든 작업에 대해 전체 두 번째 모델을 실행하기 때문입니다"가 됩니다.

중요한 숫자는 비율입니다. 이를 **판단 비용 점유율 (judge cost share)**이라 부릅시다. 즉, 판단 레이어의 비용을 그것이 판단하고 있는 운영 실행 (production run) 비용으로 나눈 값입니다.

judge_cost_share = (judge_calls × judge_price) / prod_cost

이 비율이 8%라면 괜찮습니다. 저렴한 보험이죠. 하지만 50%라면, 당신은 모니터를 추가한 것이 아니라, 비용을 전액 지불하면서 오버헤드(overhead)라고 부르는 부조종사 (co-pilot)를 추가한 것입니다. 핵심은 judge_calls를 줄이는 것입니다. 즉, 멍청하지만 결정론적인 (deterministic) 규칙으로 무료로 해결할 수 있는 구간과, 실제로 인간 수준의 판단이 필요한 구간 사이의 수를 조절하는 것입니다.

대부분의 구간은 판단자가 필요하지 않습니다. 도구가 호출되었거나 호출되지 않았거나 둘 중 하나입니다. JSON 출력은 파싱이 되거나 되지 않거나 둘 중 하나입니다. 본문의 문구가 아무리 자신만만하게 들리더라도, 본문이 비어 있는 200 응답은 잘못된 것입니다. []가 성공적인 송장 전송이 아니라는 것을 알기 위해 프론티어 모델이 필요하지는 않습니다. if 문 하나면 충분합니다.

해결책: 모든 구간을 분류하고, 불확실한 끝부분만 에스컬레이션 하세요

사전 게이트 (pre-gate)는 함수입니다. 하나의 구간을 살펴보고 세 가지 판결 중 하나를 반환합니다.

• OK — 저렴하고, 증명 가능하게 괜찮습니다. 판결을 위해 비용을 지불하지 마세요.
• BAD — 저렴하고, 증명 가능하게 망가졌습니다. 이미 알고 있으니 판결을 위해 비용을 지불하지 마세요.
• UNCERTAIN — 저렴한 규칙들이 판단을 유보합니다. 이것만이 비싼 판결자(judge)가 확인해야 할 유일한 구간입니다.

네 가지 규칙이 거의 모든 비중을 차지합니다. 이 규칙들은 Sattyam Jain이 지적했던 결정론적 휴리스틱(deterministic heuristics)(

첫 번째인 trace_gated.jsonl은 도구화(instrumented)가 잘 되어 있습니다: 각 스팬(span)은 사용되었다고 주장한 도구, 실제로 호출된 도구, 구조화된 출력(판결이 명확한 경우 ok 플래그, 그렇지 않은 경우 confidence 값 또는 라벨), 그리고 인자 해시(argument hash)를 기록합니다. 두 번째인 trace_naive.jsonl은 _동일한 에이전트(agent)_가 실제 현장에서 많은 에이전트가 기록하는 방식인 {"text": "email sent"}와 같은 자유 형식 텍스트(free-text) 출력만을 기록한 것입니다. 작업은 동일하지만, 텔레메트리(telemetry)가 다릅니다.

다음은 수정하지 않은 원문 그대로의 출력 결과입니다:

$ python3 judge_gate.py fixtures/trace_gated.jsonl --judge-price 1 --prod-cost 100
spans total:        50
resolved by gate:   34 (68.0%)  [OK=29 BAD=5]
...

두 결과를 나란히 비교해 보십시오. 동일한 에이전트, 동일한 50개의 스팬, 동일한 --judge-price 1 --prod-cost 100 설정입니다. 도구화가 잘 된 트레이스(trace)는 16개의 스팬만을 판사(judge)에게 보내며, 비용 점유율 16%를 기록하여 PASS, exit 0으로 종료됩니다. 반면 자유 형식 텍스트 트레이스는 단 하나의 스팬도 저렴하게 해결하지 못해 50개 전체를 보내며, 비용 점유율 50%를 기록하여 FAIL, exit 1로 종료됩니다. 이는 Sattyam Jain이 말한 "잘못된 모니터링(wrong monitor)"의 사례를 아주 극명하게 보여줍니다.

핵심 레버(lever)는 더 화려한 판사를 사용하는 것이 아닙니다. 규칙(rule)이 읽을 수 있는 네 가지 저렴한 사실(cheap facts)을 트레이스가 담고 있느냐의 문제입니다. 게이팅(gated) 실행에서 판사에게 전달된 16개의 스팬 중 대부분은 진정으로 주관적입니다: 모호한 계약 요약(confidence: 0.45), 확신이 없는 답변 초안("I cannot find the order, but it is probably fine."), 경계선에 있는 의도 라벨(intent labels) 등입니다. 몇몇은 더 겸손한 이유로 전달됩니다. 즉, 저렴한 규칙이 확인할 수 있는 ok 플래그가 없기 때문에, 게이트가 추측하는 대신 판단을 유보하는 것입니다. 어느 쪽이든, 그것이 바로 당신이 인간 수준의 판사를 필요로 하는 영역입니다. 나머지 34개는 어땠을까요? 5개는 명백히 오류가 있었고(중복 재시도 1개, 도구 호출과 일치하지 않는 주장 2개, 빈 본문을 가진 200 응답 1개, 객체가 아닌 출력 1개), 나머지는 깨끗한 성공이었습니다. 이 중 그 어느 것도 모델의 판결이 필요하지 않았습니다.

제가 거의 대충 얼버무릴 뻔했던 수치에 대해 정확히 짚고 넘어가고 싶습니다. 비용 수치는 플레이스홀더 단위 (placeholder units) (judge_price=1, prod_cost=100)입니다. 저는 판결(judge) 호출 한 번에 1달러가 든다거나, 실행 비용이 무엇인가 100만큼 든다고 말씀드리는 것이 아닙니다. 실제 호출당 판결 비용과 실제 실행 비용을 직접 대입해 보십시오. 제가 말씀드리는 부분은 에스컬레이션(escalating)되는 스팬(span)의 비율인 32% 대 100%이며, 이는 측정 가능하고 재현 가능한 수치입니다. 달러(금액) 수치는 여러분의 데이터에 따라 달라집니다.

버그를 단순히 게이트(gate) 안으로 옮기는 것뿐인가요?

타당한 반론이며, 저 역시 제기했을 질문입니다. 만약 저렴한 규칙들이 틀렸다면, 50달러의 판결 비용을 16%의 비용과 한 더미의 잘못된 판결로 대체하는 셈이 됩니다. 그렇다면 질문은 이것입니다: 저렴한 레이어(layer)가 실제로 얼마나 성능이 좋을 수 있을까요?

최근 발표된 두 편의 논문은 중요한 부분에서 놀라울 정도로 성능이 좋다고 말합니다. Cheap Reward Hacking Detection (arXiv:2606.08893, 6월 8일)에서 Belenky, Itria, Johns는 작은 트랜스포머 인코더(transformer encoder)에 선형 프로브(linear probe)를 적용하여, LLM-as-judge 베이스라인보다 **

• 평가 스위트(eval suite)가 아닙니다. 답변의 품질을 점수 매기지 않습니다. 대신 _어떤 구간(span)이 판사(judge)의 검토를 받을 가치가 있는지_를 결정하고, 해당 레이어의 비용을 산정합니다. 롱테일(hard tail) 구간의 정확성을 판단하는 것은 여전히 판사의 역할입니다.
• 런타임 제한(runtime cap)이 아닙니다. 완료된 트레이스(trace)를 읽고 CI(지속적 통합)를 실패 처리합니다. 만약 실행 중인 루프가 폭주하는 것을 _차단(block)_해야 한다면, 그것은 슬라이딩 윈도우 지출 가드(sliding-window spend guard)라는 다른 도구의 영역입니다.
• 신뢰도 필드(confidence fields)에 대한 판결이 아닙니다. 솔직한 한계를 말씀드리자면, 저의 게이트(gate)는 구간의 자체 보고된 confidence를 무시합니다. 테스트 케이스(fixture) 중 한 구간은 confidence: 0.95, "no ambiguity"라고 명시했음에도 불구하고 여전히 에스컬레이션(escalation)되었습니다. 모델 스스로 보고하는 신뢰도를 저렴한 신호로 믿기를 거부했기 때문입니다. 그러한 자기 평가(self-assessment)는 거짓말을 하기 마련입니다. 만약 당신의 모델을 신뢰한다면 다섯 번째 규칙을 추가하십시오. 저는 추가하지 않았습니다.
• 판사를 건너뛰기 위한 면죄부가 아닙니다. 판사는 진정으로 불확실한 구간들을 처리합니다. 이 논점은 판사를 아예 사용하지 말자는 것이 아니라, 명백한 구간들에 대해서까지 판사를 실행하는 것에 반대하는 것입니다.

자신의 트레이스에서 실행해 보세요