모델을 심사위원으로 사용하는 것이 실시간 경로에 적합하지 않은 이유

제가 너무 많은 화이트보드에서 그려본 다이어그램이 있습니다. 에이전트가 실행되고 출력을 생성한 다음, 결과가 어디로 가기 직전에 — 바로 요청 경로(request path)에서 — 모델-심사위원(model-as-judge)이 그것을 10점 만점에 8.4점으로 점수 매기고 배포할지 여부를 결정합니다. 모두 고개를 끄덕입니다. 이것은 일종의 품질 게이트처럼 보입니다. 하지만 사실, 이는 에이전트 평가(agent evals)를 수행하는 팀들이 저지르는 가장 비싼 아키텍처적 실수입니다.

제가 주장할 의견은 이렇습니다: 실시간 게이트와 모델-심사위원은 서로 다른 시스템이며, 각각 다른 곳에 존재해야 합니다. 하나는 모든 실행마다 작동하며, 비용이 사실상 들지 않고, 밀리초(milliseconds) 단위로 응답하며, 실행을 차단할 수 있는 결정론적 검사입니다. 다른 하나는 느리고, 측정 가능한(metered), 비결정론적인 의견으로, 오직 샘플에 대해 사후에, 오프라인에서만 실행될 수 있습니다. 이 둘을 '출력을 반환하기 전에 LLM이 점수를 매기는' 하나의 단계로 통합하면 최악의 결과를 얻게 됩니다: 실시간 경로(hot path)에서 심사위원 지연 시간과 비용을 지불하게 되지만, 여전히 신뢰할 수 있는 게이트를 갖지 못합니다.

해결책은 더 나은 심사위원을 만드는 것이 아닙니다. 그것은 심사위원이 있어야 할 곳에 배치하고, 그 자리에 완전히 다른 무언가를 두는 것입니다.

증거는 비용 축이 아닌 독립성 축을 가져야 한다

대부분의 사람들은 평가 방법을 비용으로 순위를 매깁니다: 가장 아래에는 저렴한 정규 표현식(regex) 검사를, 가장 위에는 비싼 LLM 심사위원을 배치하며, 마치 돈을 더 많이 쓸수록 품질이 더 높아지는 것처럼 생각합니다. 이러한 틀은 완전히 역행하는 것이며, 이것이 바로 심사위원들이 실시간 경로에 놓이는 이유입니다 — '가장 비싸기 때문에 가장 권위적이어야 한다'고 생각하기 때문입니다.

대신 **독립성(independence)**으로 증거를 순위화해야 합니다. 즉, 에이전트가 위조하기 얼마나 어려운지 여부로 판단하는 것입니다:

Tier 1 — 에이전트가 위조할 수 없는 외부 관찰 가능한 증거 (externally observable proof). 출력이 유효한 JSON으로 파싱되었는가? 작성했다고 주장하는 파일이 실제로 디스크에 존재하는가? 코드가 컴파일되었는가? 테스트를 통과했는가? 타임아웃(timeout) 전에 실행이 완료되었는가? 결과가 비어 있지 않은가? 이것들은 작업에 대한 의견이 아니라 세상에 대한 사실입니다. 에이전트는 JSON.parse가 오류를 던지는 상황을 말로 때울 수 없습니다.
Tier 2 — 에이전트가 작성하지 않은 기준점(baseline)에 대한 통계적 신호 (statistical signal). 출력값과 주어진 작업 사이의 임베딩 유사도(Embedding similarity). 길이 및 반복 체크. diff가 실제로 무언가를 변경했는가, 아니면 에이전트가 수정을 주장하면서 아무것도 건드리지 않았는가? 에이전트는 기준점(baseline)을 작성하지 않았으므로, 비교 과정을 손쉽게 조작(game)할 수 없습니다.
Tier 3 — 모델을 심사위원으로 사용 (model-as-judge). 동일한 기질을 공유하는 '의견(opinion)'입니다. 유용하지만, 이는 신호(signal)일 뿐 결코 판결(verdict)이 될 수 없습니다. 그리고 왜 그런지를 이해하는 것이 이 포스트의 핵심입니다.

이 축이 아키텍처 측면에서 중요한 이유: Tier 1과 Tier 2는 결정론적(deterministic)이며, 비용이 거의 들지 않고, 밀리초(milliseconds) 단위로 실행됩니다. 따라서 핫 패스(hot path)에 위치하여 실행을 차단(block)할 수 있습니다. Tier 3는 사용량에 따라 비용이 부과되고(metered), 느리며, 비결정론적(non-deterministic)입니다. 따라서 그렇게 할 수 없습니다. 이것은 선호의 문제가 아닙니다. 각 티어가 '무엇인가'에 따른 속성입니다.

왜 심사위원이 물리적으로 게이트(gate)가 될 수 없는가

세 가지 요소가 모델을 심사위원으로 사용하는 방식을 핫 패스(hot path)에서 제외시키며, 각 요소는 독립적으로 치명적입니다.

느리고 비용이 부과됩니다 (It's slow and metered). 심사위원 호출은 또 다른 전체 추론(inference)이며, 종종 긴 루브릭(rubric) 프롬프트를 사용하는 프런티어 모델(frontier model)을 대상으로 합니다. 이제 지연 시간(latency)은 두 배로 늘어났고, 모든 요청마다 실행하고 싶은 작업에 실행당 달러 비용을 추가하게 되었습니다. 낮은 트래픽에서는 눈에 띄지 않습니다. 하지만 프로덕션 규모의 트래픽에서는 첫 번째 에이전트의 점수를 매기는 것이 유일한 업무인, 더 느린 두 번째 에이전트를 구축한 셈이며, 크리티컬 패스(critical path)에서 두 에이전트 모두에 대한 비용을 지불하게 됩니다.

비결정론적(non-deterministic)이기 때문에 게이트(gate)가 될 수 없습니다. 게이트의 역할은 안정적인 승인/거절(accept/reject) 결정을 내리는 것입니다. 동일한 출력을 동일한 심사위원에게 세 번 실행하면 7, 8, 6이라는 결과를 얻을 수 있습니다. 동일한 입력에 대해 판결이 뒤집히는 게이트는 게이트가 아니라, 온도(temperature)에 의해 무게가 달라지는 동전과 같습니다. 재현되지 않는 수치를 바탕으로는 신뢰할 수 있는 차단/허용(block/allow) 결정을 내릴 수 없습니다.

이것이 핵심적인 문제입니다: 심사위원은 순환적(circular)입니다. 모델이 다른 모델의 추론(reasoning)을 심사할 때, 심사위원과 피심사위원은 동일한 기질(substrate)을 공유합니다. 그 루프 안에는 독립적인 정답(ground truth)이 없습니다. 당신은 언어 모델(language model)에게 다른 언어 모델의 출력이 좋은지 묻고 있는 것이며, 둘 다 동일한 학습 데이터의 원천과 동일한 실패 모드(failure modes)에서 파생됩니다. 확신에 찬 틀린 답변에 대해 확신을 가지고 승인(rubber-stamp)을 내리는 심사위원은 버그가 아닙니다. 그것은 채점자(grader)와 피채점자(gradee)를 동일한 축 위에 놓았을 때 나타나는 예측 가능한 결과입니다. Tier 1과 Tier 2는 에이전트의 전체 궤적(trajectory)—즉, 추론 단계와 도구 호출(tool calls)—을 정당하게 검토할 수 있습니다. 왜냐하면 이들은 외부 세계나 독립적인 기준선(baseline)을 바탕으로 검증하기 때문입니다. Tier 3는 궤적을 심사할 수 없습니다. 모델로 모델의 추론을 심사하는 것은 순환적인 사례이기 때문입니다. 따라서 심사위원은 _피심사 에이전트가 작성하지 않은 결과물(artifacts로써의 최종 파일, 커밋된 diff, 렌더링된 출력 등)_만을 검사해야 하며, 자신의 작업이 얼마나 훌륭했는지에 대한 에이전트 자신의 서술(narration)은 결코 검사해서는 안 됩니다.

이것들을 종합하면 결론은 자명합니다: 심사위원은 오프라인에서 샘플을 대상으로 결과물(artifacts)을 살펴보는 데 적합합니다. 핫패스(hot-path) 게이트는 반드시 Tier 1 + Tier 2여야 합니다.

두 경로의 실제 모습

이 구분을 구체화하면 다음과 같습니다. 실시간 게이트는 인라인(inline)으로 실행되며 실행을 차단하기 위해 예외를 던질 수 있습니다. 심사위원은 아무것도 차단할 수 없는 별도의 오프라인 경로에서 실행됩니다.

// ---------- 경로 1: 실시간 게이트 (Tier 1 + Tier 2) ----------
// 결정론적(Deterministic), 비용 약 $0, 밀리초(milliseconds) 단위. 모든 실행 시 작동.
// 예외를 던짐으로써 실행을 차단할 수 있음.
...

그 게이트는 지루하며, 그 지루함이 바로 핵심입니다. 그 안의 모든 검사는 재현 가능하고, 밀리초(milliseconds) 단위로 실행되며, 에이전트가 조작할 수 없는 무언가와 비교함으로써 위조 가능한 주장을 잡아냅니다. 이제 심사위원(judge)을 살펴보겠습니다. 동일한 평가(evals) 철학을 따르지만, 배치 방식은 완전히 다릅니다.

// ---------- LANE 2: 오프라인 심사위원 (Tier 3) ----------
// 계량화됨, 느림, 비결정론적(non-deterministic). 핫 패스(hot path) 외부에서 샘플(SAMPLE)에 대해 실행됨.
// 실행을 절대 차단할 수 없음. 에이전트가 작성하지 않은 산출물(artifacts)만 검사함.
...

이 비대칭성이 설계의 전부입니다. Lane 1은 예외를 던져 실행을 중단합니다. Lane 2는 라벨이 지정된 신호를 반환하고 대시보드로 들어갑니다. 이 둘은 결코 동일한 함수 호출이 아니며, 심사위원은 에이전트의 추론(reasoning)에는 절대 관여하지 않습니다. 오직 에이전트가 생성한 산출물(artifact)만을 다룹니다.

트레이스(trace)가 개입하는 지점 (그리고 왜 양쪽 모두에 필요한가)

오프라인 심사위원이 agentlens.getTrace(runId)를 통해 읽어온다는 점을 눈치채셨을 것입니다. 이는 우연이 아닙니다. 이 전체 아키텍처를 디버깅 가능하게 만드는 핵심 요소이며, 제가 agent-eval과 AgentLens를 두 개의 도구가 아닌 하나의 단위로 실행하는 이유입니다.

agent-eval은 점수 산정 및 게이팅(scoring-and-gating) 부분입니다. 실시간으로 실행을 차단하는 결정론적(deterministic) Tier 1 + Tier 2 검사와, 라벨링된 신호로서 오프라인에서 실행되는 Tier 3 심사위원을 모두 구현합니다. 이것이 출력이 좋은지를 결정하며, 핫 패스(hot path)에서는 실행을 계속 진행할 수 있을지를 결정하는 역할을 합니다.

AgentLens는 트레이스(trace) 부분입니다. 에이전트가 어떻게 그 결과에 도달했는지 — 즉, 모든 모델 호출과 도구 단계, 템플릿화(templating) 이후 에이전트가 실제로 본 해결된 입력값(resolved inputs), 그리고 돌아온 가공되지 않은 출력값(raw outputs)을 캡처합니다. 이 두 가지를 결합하는 것이 선택 사항이 아닌 필수 사항인 이유는 다음과 같습니다:

심사위원(judge)은 추론 과정이 제외된 결과물(artifact-without-the-reasoning)을 찾기 위해 트레이스(trace)가 필요합니다. 에이전트가 작성하지 않은 부분만을 심사하려면, 최종적으로 확정된 결과물(artifact)과 이를 설명하는 에이전트의 서술(narration)을 깔끔하게 분리하는 기록이 필요합니다. 그 분리는 바로 트레이스(trace) 안에 존재합니다.
Tier 1 + Tier 2는 점수를 매기기 위해 에이전트가 작성하지 않은, 위조 불가능한 데이터가 필요합니다. 독립성 축(independence axis)의 전체 전제는 에이전트가 조작할 수 없는 무언가 — 즉, 디스크 상의 실제 파일, 실제 diff, 해결된 작업 입력값(resolved task input) — 를 기준으로 출력을 검증하는 것입니다. AgentLens는 이러한 정답(ground-truth) 기록을 보존하는 역할을 합니다. 따라서 게이트(gate)가 실행을 차단했을 때, 트레이스(trace)를 열어 어떤 해결된 입력값(resolved input)과 어떤 가공되지 않은 도구 출력값(raw tool output)이 위반을 발생시켰는지 정확히 확인할 수 있습니다.

agent-eval은 실행이 차단되었는지, 또는 심사위원이 결과물에 6점을 주었는지를 알려줍니다. AgentLens는 왜 그랬는지 — 즉, 어떤 단계, 어떤 입력, 어떤 출력 때문인지를 알려줍니다. 트레이스(trace)가 뒷받침되지 않는 게이트 결정은 항소할 수 없는 판결과 같으며, 트레이스(trace)가 없는 심사위원 점수는 감사(audit)할 수 없는 의견과 같습니다.

Tier 1+2에서 80%를 처리하고, 심사위원은 나머지 소수에 대해서만 사용하세요

이 부분이 이론이 아닌 실무로 만드는 핵심입니다. 실제 운영 환경에서 에이전트의 실패 사례를 분류해 보면, 압도적인 대다수는 Tier 1 + Tier 2 만으로도 포착됩니다:

출력이 오래되었거나(stale), 실행 중 충돌(crash)이 발생했거나, 시간 초과(timeout)가 발생한 경우 → Tier 1.
JSON 파싱이 불가능하거나 형식이 잘못된 경우 → Tier 1.
증거에 없는 파일 경로 나 레코드 ID를 환각(hallucination)한 경우 → Tier 1 (존재 여부 확인).
빈 값을 반환했거나 작업과 무관한 것을 반환한 경우 → Tier 1 + Tier 2.

이 중 그 어느 것도 모델의 의견을 필요로 하지 않습니다. 이것들은 사실(facts)이며, 저렴하고 빠르며 결정론적(deterministic)이고 차단(blocking) 기능을 갖춘 귀하의 게이트는 사용자가 접하기 전에 모든 사례를 매 실행마다 약 $0의 비용으로 잡아냅니다. 이것이 바로 80%(솔직히 그 이상)에 해당하며,

그다음은 진정으로 주관적인 나머지 부분인 약 20%가 있습니다. 요약이 실제로 명확한가? 어조가 적절한가? 두 가지 합리적인 접근 방식 중 더 나은 것을 선택했는가? _바로 그 지점_이 모델을 심사위원(model-as-judge)으로 사용하는 가치가 발휘되는 곳입니다. 따라서 이를 샘플에 대해 오프라인(offline)으로 실행하되, 명확하게 **증거가 아닌 의견(opinion, not evidence)**이라고 라벨을 붙여야 합니다. 그리고 이를 품질의 추세를 파악하고 인간의 검토를 위한 후보를 드러내는 데 사용해야 하며, 실행 경로(path) 상에서 조용히 차단하거나 승인(rubber-stamp)하는 용도로는 절대 사용해서는 안 됩니다.

이것이 진정한 에이전트 평가(agent-eval) 아키텍처와 "LLM을 심사위원으로 사용하여 점수를 주는" 도구들을 구분하는 경계선입니다: 심사위원은 마지막 20%를 담당하며, 오프라인에서 작동하는 신호(signal)여야 합니다. 즉, 게이트(gate)가 아니어야 하며, 핫 패스(hot path)에 있어서도 안 되고, 에이전트 자신의 추론(reasoning)을 채점하도록 허용해서도 안 됩니다.

월요일에 해야 할 일

만약 현재 귀하의 아키텍처가 출력을 반환하기 전에 인라인(inline)으로 LLM이 점수를 매기고 있다면, 이를 경로에서 분리하십시오. 구체적으로는 다음과 같습니다:

Tier 1 + Tier 2만으로 실시간 게이트(real-time gate)를 구축하십시오. 형식 유효성(format validity), 존재 여부 확인(existence checks), 타임아웃(timeout), 비어 있지 않음(non-empty), 작업 관련성(relevance-to-task) 등을 포함합니다. 오류를 발생시키도록 만드십시오. 이것이 실행을 차단할 수 있는 유일한 요소이며, 비용이 들지 않고 매번 재현 가능해야 합니다.
심사위원을 샘플에 대한 오프라인 레인(offline lane)으로 이동시키십시오. 이는 궤적(trajectories)이 아닌 산출물(artifacts)에 점수를 매기며, 신호(signal)로 라벨링되어야 하고, 아무것도 차단할 수 없어야 합니다. 이를 AgentLens 트레이스(traces)와 연결하여 각 점수가 해당 점수를 생성한 실행(run)으로 한 번의 클릭만으로 연결되도록 하십시오.
AgentLens를 사용하여 모든 실행에 대해 트레이스(trace)를 캡처하십시오. 이를 통해 두 레인 모두 에이전트가 작성하지 않은, 위조 불가능한 데이터를 바탕으로 작업할 수 있게 하며, 차단된 실행이나 낮은 심사 점수가 단순히 경고로 끝나는 대신 디버깅(debuggable) 가능하도록 만드십시오.

심사위원(judge)은 비용이 많이 들고 시니어 리뷰어처럼 말하기 때문에 권위가 있는 것처럼 느껴집니다. 하지만 이 문제에서의 권위는 비용이 아니라 '독립성(independence)'에서 나옵니다. 채점자(grader)와 피채점자(gradee)를 실시간 경로(hot path) 상의 동일한 기질(substrate)에 배치하는 순간, 당신은 재현할 수 없고 차단(block)을 신뢰할 수 없는 의견을 사기 위해 지연 시간 예산(latency budget)을 써버린 셈이 됩니다. 증명(proof)은 경로(path)에 두십시오. 의견(opinion)은 대시보드(dashboard)에 두십시오. 이 둘은 동일한 시스템이 아니며, 프로덕션(production)에서 살아남는 에이전트(agents)는 이 둘이 같다고 가장하기를 멈춘 팀들에 의해 구축됩니다.