판정자가 이제 제어 흐름에 참여한다 - 평가를 에이전트 런타임 안으로 넣는 일곱 패턴

판정자가 이제 제어 흐름에 참여한다

TL;DR

• LLM 판정자는 원래 오프라인 도구였다. 데이터셋에 애플리케이션을 돌리고 다른 모델이 결과를 채점하면 그 점수로 최신 버전이 나아졌는지 판단했다. 그런데 이제 판정자가 런타임 자체로 옮겨 와 작업이 일어나는 대로 평가하며, 더 이상 애플리케이션을 평가하기만 하지 않고 그것의 제어 흐름에 참여한다.
• 필요의 근거는 확인 불가능성이다. 결정적 소프트웨어라면 스키마 검증과 타입 검사, 어서션, 정확한 비교로 확인하면 된다. 반면 AI가 만든 작업에는 그런 수단이 없어서 작업이 넘어갈 만큼 완전한가, 답이 유용했는가, 조사가 결론을 뒷받침했는가처럼 원래 인간이 봐야 했던 판단을 판정자가 대신 맡는다.
• 판정자로 무엇을 쓸지는 반직관적이다. 비용을 무시하면 가장 강한 프론티어 모델이 답이지만, 좁은 속성을 판정하는 일은 원래 작업보다 훨씬 쉽다. 훌륭한 조사 보고서를 못 만드는 모델도 모든 주장이 증거로 뒷받침되는지는 완벽히 판정할 수 있고, 그래서 전용 판정 모델이 등장했다.
• 처방은 쪼개기와 비교다. 하나의 모델에 거대하고 흐릿한 결정을 맡기지 말고 작은 판단으로 나눠 각각에 잘 만든 프롬프트를 주고, 그것들을 합치는 규칙에 구조를 두른다. 점수보다 비교가 나은 것도 같은 이유인데, 모델은 8이 아니라 7이라고 말하는 데는 약하지만 둘 중 어느 쪽이 나은지 고르는 데는 훨씬 강하다.
• 대가는 명확하다. 판정이 제어 흐름을 움직이면 재시도든 다른 모델 라우팅이든 인간 에스컬레이션이든 자동으로 걸 수 있지만, 판정자의 실수가 곧 애플리케이션 장애가 된다. 오프라인에서 잡음 있는 판정자는 짜증거리지만, 같은 판정자가 모든 중요한 행동 앞에 앉으면 루프를 만들고 좋은 작업을 막고 나쁜 작업을 승인하며 모든 실행에 지연을 더한다.

Source

LLM-as-Judge Architectures: Putting Evals Into Your Agent Runtime — Josh Rosen(@JoshARosen), 2026년 9월 8일 · 조회 7.3만

[x.com/josharosen/status/2097324183428444499](https://x.com/josharosen/status/2097324183428444499)

Knowledge

판정자가 루프 안으로 들어왔다

LLM 판정자는 이미 AI 애플리케이션을 만드는 흔한 부분이다. 데이터셋에 애플리케이션을 돌리고 다른 모델이 결과를 채점하게 한 뒤, 그 점수로 최신 버전이 나아졌는지 나빠졌는지 알아낸다. 지금까지는 여기까지였다.

이제 판정자가 런타임 자체로 옮겨 가 작업이 일어나는 대로 평가한다. 제품들이 판정자를 오프라인 도구로 쓰는 대신 에이전트 루프 안에 직접 넣는 사례가 점점 늘고 있다. 위상이 달라진 지점이 여기다. 판정자는 더 이상 애플리케이션을 평가하기만 하지 않고 그것의 제어 흐름에 참여한다. 아직 어떤 형태의 판정자도 없는 애플리케이션이라면 결국 갖게 될 가능성이 높다.

왜 필요한지는 확인 수단의 차이에서 나온다. 전통적 결정적 소프트웨어에는 무언가 작동했는지 확인할 방법이 많다. 스키마 검증, 타입 검사, 어서션, 정확한 비교를 쓰면 된다. 반면 AI 애플리케이션이 만드는 작업은 그런 식으로 확인되지 않는다. 작업이 넘어갈 만큼 완전한가. 답이 실제로 유용했는가. 조사가 결론을 뒷받침했는가. 이 생성된 산출물을 회사의 뇌에 들여도 되는가. 원래 인간이 결과를 보고 판단을 내려야 하는 질문이라면, LLM 판정자가 그 판단 일부를 애플리케이션 스스로 하게 해 준다.

모델 평가 세계는 모델이 다른 모델을 안정적으로 판정하게 만드는 법을 알아내는 데 여러 해를 썼다. 그 기법 다수가 한 계층 위에서도, 즉 그 모델로 만드는 애플리케이션의 아키텍처로도 통한다.

다른 모델로 시작하기

정통 접근은 한 모델이 작업하고 다른 모델이 그것을 판정하는 형태다. 판정자는 원래 요청과 생성된 결과, 루브릭, 참조 자료, 어쩌면 기대 답까지 조합해 받고 점수나 라벨, 설명을 돌려준다. LangSmith와 Phoenix, DeepEval 같은 시스템이 이것을 애플리케이션 평가의 정상적 부분으로 만들어 놨다.

미리 정해야 할 것이 하나 있다. 어느 모델을 판정자로 쓸지다. 비용이 문제가 아니라면 답은 명백하다. 가장 강한 프론티어 모델이다.

그런데 판정자가 일반적 의미에서 더 똑똑할 필요는 없다. 좁은 속성 하나를 판정하는 일은 원래 작업을 하는 것보다 훨씬 쉽기 때문이다. 훌륭한 조사 보고서를 만들지 못하는 모델도 모든 주장이 제공된 증거로 뒷받침되는지 결정하는 데는 완벽히 유능할 수 있다. 그래서 Prometheus 같은 전용 판정 모델과 특정 판단에 맞춰 훈련되거나 증류된 작은 평가기가 나왔다. Galileo는 큰 프론티어 모델을 반복 호출하는 것보다 프로덕션 규모 평가를 싸게 만들려는 전용 평가 모델도 만들었다.

대량 애플리케이션에서는 이 경제성이 꽤 중요해진다. 런타임에서 평가를 끊임없이 돌리면 비용이 훨씬 눈에 띄므로, 이 용도로 싸게 설계된 전용 모델이 좋은 선택이 된다.

판단을 쪼개기

LLM 판정의 상당 부분이 하나의 질문으로 뭉개진다. 이 출력이 좋았는가. 그런데 답이 맞으면서 불완전할 수 있고 잘 쓰였으면서 원자료로 뒷받침되지 않을 수 있다. 절대 취하지 말아야 했던 행동을 취한 뒤 올바른 결과에 도달하기도 한다.

판정 아키텍처를 한 단계 올리는 방법은 판단을 작은 결정의 집합으로 쪼개는 것이다. 한 판정자는 답이 요청을 다루는지 본다. 다른 판정자는 주장이 제공된 증거로 뒷받침되는지 본다. 또 다른 판정자는 에이전트가 요구된 작업을 완료했는지 본다.

G-Eval이 이 방향으로 초기 걸음을 뗐다. 점수를 내기 전에 기준에서 평가 단계를 모델이 직접 생성하게 만든 방식이다. DeepEval은 방향 그래프 기반 평가로 더 밀고 나가, 개별 LLM 판단이 더 큰 결정적 결정 그래프 안에 앉게 한다.

요컨대 하나의 모델에 거대하고 흐릿한 결정을 요청하는 대신, 그 결정을 잘 만든 작은 프롬프트를 가진 작은 판단들로 나누고 그것들이 결합되는 방식에 구조를 두르라는 뜻이다.

점수 대신 비교

모델은 무언가 8이 아니라 7에 값한다고 말하는 데 늘 능하지 않다. 반면 둘 중 어느 것이 더 나은지 결정하는 데는 훨씬 낫다. 쌍대 판정이 이 차이를 활용한다. 같은 입력에서 나온 두 출력을 주고 어느 쪽이 기준을 더 잘 만족하는지 물으면 된다. LangSmith와 DeepEval이 이것을 직접 지원하며 어느 답을 먼저 보여줄지 무작위화해 위치 편향을 줄이는 기법도 함께 제공한다.

애플리케이션 회귀 테스트에 흔히 쓰이는 방식이지만 런타임 아키텍처로도 옮겨 갈 수 있다. 에이전트가 계획 여러 개를 생성하고 판정자가 그중 하나를 고르게 하면 된다. 또는 두 에이전트가 같은 분석을 독립적으로 수행하고 세 번째 모델이 결과를 비교한다. 시스템이 어떤 행동에 커밋해 진행하기 전에 그 행동을 대안과 견주는 것이다.

답이 아니라 작업을 판정하기

챗봇이라면 최종 응답만 판정해도 괜찮다. 20분간 작업하는 에이전트에게는 그것이 알려 주는 게 훨씬 적다. 에이전트가 잘못된 문서를 검색했거나 중요한 출처를 무시했어도 최종 결과는 완전히 합리적으로 보일 수 있다. 잘못된 도구를 호출했을 수도 있고 끝에서 운이 좋기 전까지 불필요한 단계를 헤맸을 수도 있다.

평가 시스템들은 이미 추적 안으로 더 들어가고 있다. Phoenix는 검색 관련성과 도구 선택, 도구 호출, 도구 응답, 전반적 에이전트 성능에 각각 평가기를 둔다. LangSmith는 개별 실행뿐 아니라 더 큰 추적과 스레드에도 평가기를 적용한다.

에이전트 일반, 특히 장기 실행 에이전트로 일반화하면 요점은 하나다. 중요한 결정이 실제로 내려지는 작업 조각을 판정하라. 조사 에이전트라면 종합에 들어가기 전에 출처 선택을 판정받는다. 코딩 에이전트라면 구현 전에 제안된 접근을 판정받는다. 운영 에이전트라면 행동을 취하기 전에 그 행동을 뒷받침하는 증거를 판정받는다. 애플리케이션에 통합한다는 것은 판정자를 런타임 곳곳에 흩어 놓아 핵심 검문소를 만든다는 뜻이다.

판정자를 하나 이상 두기

불편한 사실이 하나 있다. 판정자도 여전히 LLM이다. 작업하는 모델이 실수하는 것과 똑같은 모든 이유로 실수한다. 그래서 단일 판정자를 권위 있는 것으로 대하기를 멈추는 방법이 나온다.

모델 평가 연구는 판정자 패널과 평가자 페르소나 투표, 집계, 평가자 간 토론을 탐색해 왔다. MAJ-EVAL은 평가의 서로 다른 차원을 대표하는 평가자 에이전트를 여럿 만들고 결과를 두고 숙의하게 한다. 애플리케이션이 프로덕션에서 이 방식을 채택했다는 증거는 아직 많지 않다.

그래도 모델 계층 위에서는 이 기제가 다른 이유로 흥미롭다. 판정자 셋이 답이 좋다고 2 대 1로 투표하는지에 신경 쓰지 않아도, 그들이 서로 동의하지 않는다는 사실에는 엄청나게 신경 쓸 수 있다. 독립적 판단 사이의 일치는 확신을 높이고 불일치는 더 강한 모델로 재시도하거나 증거를 더 모으거나 작업을 사람에게 넘길 이유가 된다. 이 원리로 앱에 재시도나 에스컬레이션 기제를 만들 수 있다.

판정자를 판정하기

판정자가 애플리케이션에서 일어나는 일에 영향을 주기 시작하면 그 신뢰성이 크게 중요해진다. 그리고 실제로 문제가 생긴다. LLM 판정자는 어느 답이 먼저 제시되는지에 따라 결정을 바꾸는 편향을 보이는 것으로 알려져 있다. 특정 글쓰기 스타일을 선호하기도 하고 평가 대상들의 품질이 서로 가까울 때 어려움을 겪는다. 자기 것과 닮은 출력을 선호하는 경우까지 있다.

모델 평가 세계는 이 문제를 재려고 벤치마크를 만들어 뒀다. LLMBar는 어려운 조건에서 판정자가 지시를 따르는 응답을 구별할 수 있는지 시험한다. JudgeBench는 객관적 선호가 있는 어려운 응답 쌍을 담는다. RewardBench는 도전적 선호 과업에서 보상 모델을 평가하며 생성형 LLM 판정자 평가에도 쓸 수 있다.

앤스로픽의 Bloom도 쓸 만한 패턴을 보여준다. 판정자를 고르기 전에 인간이 라벨링한 전사에 대해 후보 판정 모델 모음을 평가했고 그 결과 평가 파이프라인에는 더 넓은 평가 결과를 가로질러 보는 메타 판정자까지 들어갔다.

애플리케이션 구축자는 오늘 더 단순한 버전을 쓸 수 있다. 판정자를 주기적으로 인간과 비교하면 된다. 판정이 중요한 무언가를 통제한다면 그 결정 예시를 모아 사람들이 독립적으로 평가하게 하고 판정자가 어긋나는 지점을 측정한다. 어긋남이 받아들일 수 없는 수준이면 루브릭이나 모델, 맥락, 결정 경계를 바꾼다.

판정자 주변에 결정성을 두르기

모든 애플리케이션 결정을 또 다른 LLM 판단으로 바꾸고 에이전트 위에 에이전트를 던지려는 유혹이 있다. 그것은 애플리케이션 계층에서 우리가 가진 가장 큰 이점 하나를 버리는 짓이다. 모델과 달리 주변 시스템은 우리가 통제한다.

결정적으로 확인할 수 있다면 결정적으로 확인하라. 테스트든 스키마 검사든 데이터베이스 검사든 쓰면 된다. 이런 검증을 위한 정책 엔진을 쓰는 것도 방법이다. OpenAI의 채점기 아키텍처가 이 분리를 반영한다. 문자열 검사와 파이썬 코드 같은 결정적 채점기를 모델 기반 채점기와 나란히 지원하고 여러 채점기를 더 큰 평가로 결합할 수 있다.

같은 분업이 애플리케이션 안에서도 통한다. LLM은 증거가 충분한지, 권고가 잘 뒷받침되는지, 에이전트가 과업을 완료한 것처럼 보이는지 판정한다. 결정적 코드는 그 판단들과 다른 사실들의 어떤 조합이 갖춰져야 워크플로가 앞으로 나아가는지 결정한다.

이렇게 결정적 논리와 비결정적 논리를 결합하는 일이 애플리케이션 계층에서 잡을 수 있는 가장 큰 기회 하나다. 그 경계를 잘 그릴수록 모델 자체를 넘어 더 많은 가치를 더한다.

함의와 대가

위 패턴 다수가 판정자를 에이전트 루프 안으로 옮겨 임계 경로에 두기를 요구한다. 오늘 많은 판정자가 애플리케이션 실행 경로 밖에 앉아 있는 것과 정반대다.

판정이 제어 흐름을 움직인다는 뜻이다. 애플리케이션을 계속 진행시키거나 재시도하게 하거나 다른 모델로 라우팅하거나 정보를 더 모으게 하거나 사람에게 에스컬레이션하게 만들 수 있다. 판정자에게는 훨씬 큰 역할이다. 애플리케이션이 어제 작동했는지 알려 주는 데서, 애플리케이션이 다음에 무엇을 할지 결정하는 데로 옮겨 간다.

동시에 판정자의 실수가 애플리케이션 장애가 된다. 오프라인 평가에서 약간 잡음이 있는 판정자는 짜증스러운 정도로 끝난다. 같은 판정자가 모든 중요한 행동 앞에 앉으면 루프를 만들고 좋은 작업을 막고 나쁜 작업을 승인하고 모든 실행에 지연을 더한다.

프로덕션에서 판정자를 임계 경로에 올려도 편안해지기까지는 이 아키텍처에 투자하고 패턴을 성숙시켜야 한다. 그만큼 혁신할 여지가 크게 남아 있다.

더 생각해보기

• 판정자가 제어 흐름에 참여하면 애플리케이션의 신뢰성 상한은 무엇이 결정하는가.
• 좁은 속성 판정이 원래 작업보다 쉽다는 논거는 어느 판정에서 깨지는가.
• 판단을 쪼갤 때 조각들의 결합 규칙은 결정적이어야 하는가.
• 점수보다 비교가 낫다면 절대 기준이 필요한 판정은 어떻게 처리하는가.
• 판정자를 런타임 곳곳에 흩어 놓으면 지연과 비용은 어떻게 관리되는가.
• 판정자들의 불일치를 신호로 쓰는 설계에서 불일치율의 정상 범위는 어떻게 정하는가.
• 모델이 자기 것과 닮은 출력을 선호한다면 판정자와 작업자를 같은 계열로 두어도 되는가.
• 판정자를 인간과 주기적으로 비교하는 절차는 어느 빈도가 적정한가.
• 결정적으로 확인할 수 있는 것과 없는 것의 경계는 실무에서 어떻게 그리는가.
• 판정자 실수가 좋은 작업을 막는 경우와 나쁜 작업을 승인하는 경우 중 무엇을 먼저 줄여야 하는가.