[arXiv 2607.05391] LLM-as-a-Verifier: 범용 검증 프레임워크로 에이전트 궤적을 고르기

LLM-as-a-Verifier: A General-Purpose Verification Framework

https://arxiv.org/abs/2607.05391

Jacky Kwok, Shulu Li, Pranav Atreya, Yuejiang Liu, Yixing Jiang, Chelsea Finn, Marco Pavone, Ion Stoica, Azalia Mirhoseini | Stanford University, UC Berkeley, NVIDIA Research | arXiv:2607.05391 | 2026년 7월

---

1. 서론: 더 많이 생성한 답을 실제로 고르는 문제가 남았다

1.1 생성 스케일링 뒤에 남은 선택 병목

대형 언어 모델의 성능 향상은 오랫동안 사전학습 규모, 후학습, test-time compute라는 세 축으로 설명됐다. 더 큰 모델을 만들고, 더 좋은 선호 데이터로 다듬고, 추론 때 여러 답을 샘플링하면 실제 정답 후보가 생길 확률은 높아진다. 하지만 운영 환경에서는 후보가 많다는 사실만으로 충분하지 않다. 에이전트가 다섯 개의 터미널 실행 궤적을 만들었을 때, 어떤 궤적이 숨은 테스트를 통과하는지 고르지 못하면 추가 샘플링은 비용만 늘린다.

이 논문은 그 병목을 verification scaling이라는 이름으로 독립적인 스케일링 축에 올린다. 핵심 주장은 단순하다. 생성 모델이 이미 한 번쯤 맞는 답을 만들 수 있다면, 다음 성능 개선은 더 큰 생성기보다 더 세밀한 검증기에서 나올 수 있다. Terminal-Bench V2에서 후보 궤적을 충분히 모으면 oracle verifier가 98.9%까지 올라가는 장면은 이 주장을 잘 압축한다. 모델 능력 부재보다 맞는 궤적을 찾는 선택기의 약함이 병목이라는 뜻이다.

표준 LLM judge는 보통 후보를 읽고 1점부터 5점 또는 10점까지의 정수 점수를 내게 한다. 이 방식은 간단하지만 복잡한 에이전트 궤적에서는 치명적인 손실을 만든다. 두 후보가 모두 그럴듯해 보이면 judge가 같은 정수를 출력하고, 내부적으로는 미묘하게 다른 확신을 갖고 있어도 최종 값은 tie가 된다. 논문은 이 tie가 단순한 불편함을 넘어 Best-of-N, agent monitoring, reinforcement learning reward shaping 전체를 막는 병목이라고 본다.

Figure 1: coding, robotics, medical benchmark에서 LLM-as-a-Verifier가 보고한 headline 성능.

Figure 1은 논문의 메시지를 한 장으로 요약한다. 같은 verifier 형태가 Terminal-Bench V2, SWE-Bench Verified, RoboRewardBench, MedAgentBench에 모두 적용되고, 각 영역에서 SOTA 또는 기존 강한 baseline을 넘는 수치를 낸다. 중요한 점은 domain-specific reward model을 새로 학습한 결과와 구분되며, scoring-token 분포를 읽는 범용 검증 절차를 여러 도메인에 옮긴 결과라는 점이다.

Benchmark	후보/기준 설정	Pass@1 또는 기존 강한 기준	Oracle upper bound	LLM-as-a-Verifier
Terminal-Bench V2	Capy scaffold, GPT-5.5 후보 5개	83.1% Pass@1 / leaderboard 84.7%	92.1%	86.5%
SWE-Bench Verified	Opus 4.5, Gemini 3 Flash, MiniMax M2.5 후보 3개	76.1% 평균 Pass@1 / Opus 4.5 76.8%	84.4%	78.2%
MedAgentBench	AgentBench harness, Claude Opus 4.8 후보 5개	70.2% Pass@1	75.0%	73.3%
RoboRewardBench	500개 robotics trajectory preference pair	RoboReward-8B 81.4%	별도 oracle 미보고	87.4%

위 표에서 특히 눈에 띄는 부분은 개선 폭이 과장된 한 벤치마크에 몰려 있지 않다는 점이다. coding benchmark에서는 숨은 테스트와 파일 상태를 읽어야 하고, robotics에서는 영상 프레임을 통해 진행도를 판단해야 하며, medical benchmark에서는 EHR 형태의 도구 사용이 포함된다. 서로 다른 입력 양식과 실패 양식이 섞여 있는데도 동일한 verifier protocol이 동작했다는 점이 이 논문의 실용적 매력이다.

1.2 judge와 verifier를 구분하는 이유

저자들은 용어를 일부러 구분한다. judge는 전체 인상으로 점수를 매기는 평가자에 가깝고, verifier는 후보가 실제 조건을 만족하는지 따지는 확인자에 가깝다. 이 차이는 프롬프트 문구보다 출력 해석에서 더 크게 드러난다. judge 방식은 모델이 가장 가능성 높다고 본 점수 토큰 하나를 고른다. verifier 방식은 점수 토큰 전체의 확률분포를 가져와 기대값을 계산한다. 같은 모델이 같은 후보를 봐도, argmax 점수 하나와 분포 기대값은 다른 정보를 보존한다.

예를 들어 어떤 후보에 대해 모델이 15점, 16점, 17점에 확률을 나눠 주었다면, argmax 방식은 그 중 하나만 남긴다. 반대로 기대값은 주변 점수에 걸친 확신의 모양을 보존한다. 이 차이는 후보가 복잡할수록 커진다. 터미널 작업에서 실행 로그 일부는 맞고 검증 절차가 틀린 경우, 모델의 자연어 reasoning은 실패 지점을 알고 있으면서도 최종 정수 점수에서는 같은 5점을 줄 수 있다. 논문은 이 손실을 줄이기 위해 logprob 접근 가능한 verifier를 사용한다.

나는 이 문제 설정이 최근 에이전트 평가 흐름과 잘 맞는다고 본다. 이전에 다룬 Workspace-Bench, DORA, Agent Genome 계열은 최종 답만으로 에이전트를 평가하기 어렵다는 사실을 계속 보여 줬다. LLM-as-a-Verifier는 그 흐름을 한 단계 더 내려가, 궤적 전체를 읽는 평가자가 어떤 수치 신호를 남겨야 다음 선택·감시·학습으로 이어질 수 있는지 묻는다.

2. 배경 및 관련 연구: 궤적 평가와 보상 모델 사이의 빈칸

2.1 에이전트 궤적은 최종 답보다 많은 정보를 가진다

에이전트 작업은 단일 응답 생성과 다르다. 사용자가 “이 코드를 고쳐라”라고 요청했을 때 모델은 파일을 읽고, 테스트를 돌리고, 실패 로그를 해석하고, 패치를 만들고, 다시 검증한다. 마지막 답변이 “완료”라고 쓰여 있어도 중간에 어떤 파일을 건드렸는지, 실패한 테스트를 숨겼는지, 임시 데이터베이스를 조작했는지에 따라 실제 성공 여부는 달라진다. 그래서 최근 벤치마크들은 trajectory-level agent evaluation을 강조한다.

이 논문이 Terminal-Bench V2와 SWE-Bench Verified를 고른 것도 우연이 아니다. Terminal-Bench V2는 shell 환경에서 장기 작업을 수행하고, SWE-Bench Verified는 실제 GitHub issue와 hidden test를 통과해야 한다. 두 벤치마크 모두 궤적 안에 파일 상태, 도구 호출 순서, 실패 로그, 검증 근거가 들어 있다. 단일 최종 텍스트 점수보다 과정의 정합성을 읽는 verifier가 필요한 이유가 여기서 나온다.

RoboRewardBench와 MedAgentBench는 같은 논점을 다른 양식으로 확장한다. robotics에서는 성공 여부가 마지막 텍스트보다 영상 속 물체 진행도와 조작 상태에 있고, medical agent에서는 환자 정보 검색과 guideline lookup의 순서가 안전성과 직결된다. 범용 verifier가 이런 환경을 모두 다룰 수 있으려면, 출력 문장을 채점하는 수준을 넘어 candidate trajectory 자체를 비교 대상으로 삼아야 한다.

2.2 reward model, process reward model, outcome reward model의 관계

보상 모델은 이미 RLHF와 reasoning 연구에서 널리 쓰인다. Outcome Reward Model은 최종 답이 좋은지 평가하고, Process Reward Model은 중간 추론 단계를 평가한다. 하지만 에이전트 궤적에서는 “중간 단계”와 “최종 결과”의 구분이 깔끔하지 않다. 터미널에서 패키지를 잘못 설치해 disk space를 소진한 행동은 중간 단계이면서도 이후 모든 결과를 오염시키고, 데이터베이스를 복사해 index를 추가한 검증은 마지막 결과를 그럴듯하게 보이게 만든다.

LLM-as-a-Verifier는 이 틈을 Trajectory Reward Model로 메운다. 각 후보 trajectory 전체를 비교하고, 필요하면 prefix 단위로도 점수를 매긴다. 저자들이 말하는 진짜 장점은 범용성이다. 별도 reward model을 학습하지 않고도 scoring-token logit을 읽을 수 있는 LLM 또는 VLM을 verifier로 사용한다. 학습된 reward model이 도메인 데이터에 갇히는 문제를 줄이면서, judge보다 연속적인 신호를 얻는 절충점이다.

물론 이 절충점은 공짜가 아니다. logprob을 노출하는 모델이 필요하고, 반복 평가와 기준 분해를 적용하면 비용이 증가한다. 논문은 이 비용을 숨기지 않고, Probabilistic Pivot Tournament로 후보 비교 수를 줄이는 별도 알고리즘을 넣는다. 즉 논문의 구조는 “연속 점수를 얻자”에서 끝나지 않고, 그 점수를 실제 후보 선택에 쓸 때 필요한 예산 문제까지 이어진다.

Figure 2: LLM-as-a-Verifier가 logit 기반 연속 점수를 test-time scaling, progress tracking, RL reward로 연결하는 전체 구조.

Figure 2는 논문의 범위를 보여 준다. verifier는 단순히 정답 후보를 고르는 후처리 모듈로만 쓰이지 않고, 진행도 추적과 강화학습 보상에도 연결된다. 그림의 중요한 축은 score granularity, repeated evaluation, criteria decomposition이다. 세 축이 모두 같은 수식 안에서 평균화되기 때문에, 사용자는 비용 예산에 맞춰 더 세밀한 점수·더 많은 반복·더 분해된 기준을 조합할 수 있다. 이 구조가 이후 모든 실험의 공통 인터페이스가 된다.

2.3 기존 위키 맥락과의 연결

이 논문은 기존 위키의 provenance-aware agent evaluation과도 자연스럽게 이어진다. Workspace-Bench가 파일 의존성과 산출물 계보를 평가 표면으로 올렸고, Agent Genome은 에이전트 step을 X/E/P/V sequence로 압축해 행동 패턴을 분석했다. LLM-as-a-Verifier는 그 표면 위에 “검증자가 줄 수 있는 연속 보상 신호”를 얹는다. 같은 trajectory를 보더라도 최종 pass/fail만 남기지 않고, 후보 간 선호확률과 prefix 진행도까지 남기는 셈이다.

또 하나의 연결점은 Bootstrapped Monitoring이다. 그 논문은 reasoning trace를 노출하는 untrusted monitor를 trusted model이 감사하는 구조를 제안했다. LLM-as-a-Verifier는 감시 대상이 monitor reasoning 대신 candidate trajectory를 겨냥한다는 점에서 다르지만, 둘 다 투명한 중간 신호를 안전·성능 개선의 입력으로 삼는다. 이 차이를 염두에 두면, verifier는 단순한 리더보드 점수 계산기를 넘어 장기 agent loop를 운영하는 runtime component에 가깝다.

LongSeeker나 TACO처럼 context 압축을 다룬 논문과 비교하면 관점이 더 분명해진다. 그쪽은 긴 실행을 계속 이어가기 위해 관찰을 줄이고 요약하는 문제를 다룬다. LLM-as-a-Verifier는 긴 실행이 여러 갈래로 만들어졌을 때 어떤 갈래를 믿을지 고른다. 하나는 context budget의 문제이고, 다른 하나는 selection budget의 문제다. 실제 에이전트 시스템에서는 두 문제가 같이 나타나므로, 이 논문은 운영 스택의 다른 위치를 채우는 조각으로 읽을 수 있다.

3. 방법론: scoring-token 분포를 기대값으로 읽는 검증기

3.1 Fine-grained reward estimation

방법론의 핵심 수식은 후보 trajectory $\tau$의 보상을 점수 토큰 분포의 기대값으로 계산하는 것이다. ordered score token set을 $V_{\text{score}}=\{v_1,\ldots,v_G\}$로 두고, 각 토큰을 scalar 값 $\phi(v_g)$에 매핑한다. verifier 모델은 task prompt $x$, 평가 기준 $c$, 후보 trajectory $\tau$를 보고 각 점수 토큰의 확률 $p_\theta(v_g\mid x,c,\tau)$를 낸다. 최종 reward는 기준 수 $C$, 반복 횟수 $K$, granularity $G$에 대해 평균화된다.

논문은 이를 $R(x,\tau)=\frac{1}{CK}\sum_{c=1}^{C}\sum_{k=1}^{K}\sum_{g=1}^{G}p_\theta(v_g\mid x,c,\tau)\phi(v_g)$로 쓴다. 여기서 중요한 부분은 argmax가 사라진다는 점이다. 모델이 18점과 19점 사이에서 망설였는지, 10점과 20점 사이에 불안정하게 갈라졌는지, 또는 낮은 점수에 확률이 몰렸는지까지 reward에 반영된다. discrete judge가 같은 5점을 주는 두 후보도 verifier expectation에서는 다른 값이 된다.

pairwise preference는 normalized reward 차이를 Bradley-Terry 형태로 바꿔 계산한다. 즉 $P(\tau_i\succ\tau_j\mid x)=1/(1+\exp(-(R(x,\tau_i)-R(x,\tau_j))))$이다. 이 확률은 후보 선택 알고리즘에서 soft win으로 누적된다. 정답/오답을 딱 잘라 맞히는 classifier라기보다, 복잡한 candidate pool 안에서 어느 후보가 더 좋은지 비교 가능한 선호 질량을 만드는 방식이다.

구성 요소	기호	역할	운영 의미
Score granularity	$G$	점수 토큰 수를 1, 4, 16, 20 등으로 확장	내부 확신을 더 촘촘한 연속 점수로 투영
Repeated evaluation	$K$	같은 후보를 여러 번 평가해 평균	한 번의 verifier 편향과 프롬프트 노이즈를 줄임
Criteria decomposition	$C$	Specification, Output, Errors 같은 하위 기준으로 분해	복합 rubric이 한 요인에 끌려가는 문제를 완화
Preference probability	$P(\tau_i\succ\tau_j)$	reward 차이를 soft win 확률로 변환	후보 토너먼트에서 tie 없는 비교 질량 제공

3.2 점수 granularity가 만드는 분리도

granularity를 늘린다고 모델이 새로운 정보를 갑자기 배우는 것은 아니다. 하지만 모델 내부에 이미 있는 불확실성을 더 촘촘한 출력 공간으로 투영할 수 있다. 1점짜리 coarse scale에서는 거의 같은 후보로 보이던 두 궤적이 20개 score token에서는 다른 기대값을 갖는다. 논문은 이를 signal-to-noise ratio로 분석한다. correct trajectory score $s_c$와 incorrect trajectory score $s_i$의 차이 $s_c-s_i$가 얼마나 안정적으로 양수인지 보는 방식이다.

Terminal-Bench에서 $G$를 1에서 20으로 키우면 SNR은 0.775에서 0.799로 올라간다. 숫자만 보면 작아 보일 수 있지만, pairwise verification accuracy는 73.1%에서 77.5%까지 올라간다. 이 실험은 granularity가 단순한 미세 조정을 넘어 tie를 줄이고 correct/incorrect candidate의 standardized gap을 키우는 역할을 한다는 근거다. 특히 복잡한 agent trajectory에서는 작은 분리도 차이가 Best-of-N 선택의 최종 성공률로 증폭된다.

Figure 3: 사전학습, 후학습, test-time compute 옆에 verification scaling을 별도 축으로 배치한 개념도.

Figure 3은 논문의 framing을 이해하는 데 중요하다. 저자들은 verification을 기존 test-time compute의 부속 기능으로만 보지 않고, 독립적으로 스케일할 수 있는 축으로 둔다. 생성 후보를 많이 뽑는 것과 후보를 잘 고르는 것은 다른 작업이다. 이 구분이 명확해야 Best-of-N, agent monitoring, RL reward shaping이 같은 verifier 신호를 공유하는 이유도 자연스럽게 보인다.

Figure 4: score granularity, repeated evaluation, criteria decomposition을 키울 때 verification accuracy가 올라가는 실험.

Figure 4는 세 가지 스케일링 축이 서로 보완적이라는 주장을 뒷받침한다. granularity는 score separation을 키우고, repeated evaluation은 개별 평가의 variance를 낮추며, criteria decomposition은 복합 질문의 prompt bias를 줄인다. 세 축 모두 비용을 요구하지만, 비용을 어디에 쓸지 선택할 수 있게 만든다는 점에서 단일 judge 호출보다 운영 여지가 크다. 그래서 실험 해석도 축별 예산 대비 이득으로 읽어야 한다.

축	비교 조건	보고된 결과	해석
Granularity	$G=1$ → $G=20$	73.1% → 77.5%	점수 토큰 분포 기대값이 correct/incorrect gap을 키움
Repeated evaluation	$K=1$ → $K=16$	74.7% → 77.4~77.5%	반복 평균으로 verifier variance를 줄임
Criteria decomposition	단일 기준 → 세 기준 ensemble	75.2~76.4% → 78.3%	Specification, Output, Errors를 분리해 prompt bias를 낮춤
Discrete judge tie	$K=1$ 기준	tie 26.7%	coarse score가 후보 차이를 지움
Continuous verifier tie	$K=1$ 기준	tie 0%	기대값 계산이 비교 가능성을 유지

이 방식의 실무적 장점은 verifier output을 여러 downstream decision에 재사용할 수 있다는 데 있다. Best-of-N 선택에서는 여러 후보 중 가장 높은 normalized score를 가진 궤적을 고르면 되고, monitoring에서는 prefix score의 시간적 변화를 보면 된다. 강화학습에서는 같은 점수를 reward shaping 항으로 넣을 수 있다. 하나의 평가 호출이 단순 pass/fail label보다 더 많은 구조화 정보를 남기므로, 시스템이 후보 선택·중간 중단·학습 신호를 같은 scale에서 다룰 수 있다.

반대로 이 구조가 요구하는 전제도 분명하다. verifier 모델은 점수 토큰의 확률을 안정적으로 반환해야 하고, prompt는 score token이 실제 rubric과 연결되도록 설계되어야 한다. 논문은 숫자 대신 letter-based scale을 쓴다고 설명하는데, 이는 일부 tokenizer에서 digit token의 logprob이 균일하지 않거나 top-logprob extraction에 불리할 수 있기 때문이다. 결국 방법론은 “LLM에게 점수를 쓰게 한다”보다 “score token distribution을 계측 가능한 계량기로 바꾼다”에 가깝다.

criteria decomposition도 단순한 prompt 장식이 아니다. 긴 agent trajectory의 품질은 요구사항 충족, 최종 출력 형식, 로그 오류 부재, 검증 artifact 보존 같은 여러 요소로 갈라진다. 하나의 복합 질문으로 묻으면 모델이 가장 눈에 띄는 요소 하나에 끌릴 수 있다. 기준을 나누면 각 평가 pass가 더 좁은 질문에 집중하고, 마지막 reward는 그 좁은 판단들의 평균으로 구성된다. 이 설계가 Terminal-Bench류 작업에서 특히 중요하다.

PPT가 필요한 이유도 여기에 있다. continuous reward를 만들 수 있어도 후보가 많아질수록 모든 pair를 비교하는 비용은 빠르게 커진다. agent serving에서 후보 20개를 만들고 전부 round-robin으로 비교하면 verifier 호출이 본래 생성 비용을 압도한다. ring pass와 pivot 비교는 full tournament의 대부분 정보를 유지하면서도 비용을 상위 후보 주변으로 모은다. 논문이 verification scaling을 실제 시스템 축으로 주장하려면 이런 ranking budget 설계가 반드시 필요했다.

3.3 Probabilistic Pivot Tournament

후보가 $N$개 있을 때 모든 pair를 비교하면 $\mathcal{O}(N^2)$ 비용이 든다. 논문은 이를 줄이기 위해 Probabilistic Pivot Tournament를 제안한다. 먼저 후보들을 random Hamiltonian cycle로 연결해 ring pass를 수행한다. 이때 모든 후보는 A 위치와 B 위치에 정확히 한 번씩 등장하므로 verifier의 positional bias가 평균적으로 상쇄된다. ring pass에서 얻은 평균 win mass를 기준으로 top-$k$ 후보를 pivot set으로 고른다.

다음 단계에서는 모든 후보를 모든 후보와 비교하지 않고, non-pivot 후보를 pivot 후보와 비교하고 pivot끼리도 비교한다. soft preference probability를 win mass로 누적한 뒤, 각 후보가 참여한 비교 수 $c_i$로 정규화해 $w_i/c_i$가 가장 큰 후보를 고른다. 이 구조는 예산을 약한 후보와의 무의미한 비교에 쓰지 않고, top candidate 근처의 불확실성을 줄이는 데 집중한다. 논문은 전체 round-robin이 13,111 pair로 67.42%를 얻는 설정에서, PPT $k=9$가 9,630 pair로 67.13%까지 접근한다고 보고한다.

Figure 5: candidate ring pass, pivot selection, pivot tournament, normalized selection으로 이어지는 PPT 절차.

Figure 5는 PPT가 왜 비용을 줄이는지 직관적으로 보여 준다. 첫 ring pass는 모든 후보를 얕게 훑어 positional bias를 줄이고, pivot selection은 검증 예산을 상위 후보 주변으로 이동시킨다. 마지막 aggregation은 soft win을 누적하기 때문에 hard tournament처럼 작은 판단 오류 하나가 후보를 즉시 탈락시키지 않는다. 이 설계는 agent 후보가 많아질수록 실용성이 커진다. 작은 후보군보다 대량 샘플링 환경에서 장점이 더 뚜렷해진다.

Method	Pairs queried	Accuracy
pass@1	—	52.64%
V1, 1N budget	1,400	64.64%
V1, 5N budget	7,000	65.85%
PPT, $k=1$	2,570	65.83%
PPT, $k=5$	6,609	66.27%
PPT, $k=9$	9,630	67.13%
Full round-robin	13,111	67.42%

4. 실험 설정: 네 도메인에서 같은 검증 프로토콜을 적용하기

4.1 데이터셋 및 벤치마크

실험은 coding, robotics, medical의 세 큰 도메인과 네 개 벤치마크로 구성된다. coding 쪽에는 Terminal-Bench V2와 SWE-Bench Verified가 들어간다. Terminal-Bench V2는 shell 기반 장기 작업에서 파일 조작, 실패 복구, 테스트 실행을 요구한다. SWE-Bench Verified는 실제 GitHub issue를 수정하고 hidden test를 통과해야 한다. 둘 다 최종 응답보다 실행 궤적과 산출물 상태가 훨씬 중요하다.

robotics 쪽은 RoboRewardBench다. 여기서는 자연어 instruction이 같지만 진행도가 다른 rollout video pair를 비교한다. verifier는 텍스트 로그 대신 multi-frame video에서 물체가 목표 상태로 얼마나 가까워졌는지 읽어야 한다. medical 쪽은 MedAgentBench로, simulated EHR 환경에서 환자 정보 검색과 guideline lookup이 섞인 multi-step tool use를 평가한다. ground-truth trajectory checker를 만들기 어렵고 오류 비용이 큰 영역이라는 점에서 verifier의 일반성을 시험하기 좋다.

4.2 구현 세부사항

기본 설정은 granularity $G=20$, repeated evaluation $K=8$, criteria decomposition 세 가지다. code-agent trajectory에 대해서는 Specification, Output, Errors를 나눠 평가한다. Specification은 task requirement를 만족했는지, Output은 최종 산출물 형식과 요구 조건을 지켰는지, Errors는 로그와 도구 출력에 실패 신호가 남았는지 본다. 이 세 기준을 평균해 하나의 reward로 만들고, pairwise preference를 계산한다.

Terminal-Bench V2에서는 Capy scaffold와 GPT-5.5 후보 5개를 사용하고, Gemini 2.5 Flash를 verifier로 쓴다. SWE-Bench Verified에서는 mini-swe-agent scaffold 위에서 Claude Opus 4.5, Gemini 3 Flash, MiniMax M2.5가 각각 만든 후보를 섞어 heterogeneous pool을 만든다. RoboRewardBench에서는 Qwen 3.6 35B VLM을 verifier로 사용하며, MedAgentBench에서는 AgentBench harness와 Claude Opus 4.8 후보를 사용한다. 같은 scoring protocol이 서로 다른 candidate generator와 harness 위에 올라간다.

4.3 베이스라인과 비교 관점

candidate pool 구성은 이 논문을 읽을 때 계속 확인해야 하는 변수다. Pass@1이 낮은 모델에서 후보를 많이 뽑으면 oracle headroom이 클 수 있지만, verifier가 고른 최종 성능이 실제 SOTA를 넘지 못할 수 있다. 반대로 이미 강한 모델의 후보 pool에서는 absolute gain이 작아도 leaderboard 상 의미가 커진다. Terminal-Bench V2 결과는 후자에 가깝고, SWE-Bench Verified의 heterogeneous pool은 여러 모델 family가 서로 다른 실패 양식을 낼 때 verifier가 어떤 후보를 선호하는지 시험한다.

검증 기준의 공정성도 중요하다. 같은 verifier가 후보 생성에 사용된 모델과 관련되어 있거나, 특정 harness의 로그 표현에 더 익숙하다면 선택 편향이 생길 수 있다. 논문은 harness generalization과 multiple domain 결과를 통해 이 우려를 일부 줄인다. 그래도 실제 운영에서는 generator와 verifier를 완전히 독립된 vendor나 model family로 나누거나, 적어도 verifier disagreement를 추적하는 절차가 필요하다.

RoboRewardBench 실험은 텍스트 기반 agent 평가에서 visual reward 평가로 넘어가는 연결고리다. VLM이 multi-frame video를 보고 progress preference를 내는 설정은 로봇 정책의 학습 신호로 직접 이어질 수 있다. 하지만 영상 기반 판단은 object state, camera angle, occlusion, instruction ambiguity에 민감하다. 따라서 87.4%라는 숫자는 “범용 verifier가 robotics reward model을 완전히 대체한다”는 선언보다, zero-shot VLM verifier가 reward model 후보로 충분히 강하다는 근거로 읽는 편이 정확하다.

MedAgentBench 결과도 비슷하게 절제해서 읽어야 한다. simulated EHR benchmark에서 73.3%를 얻었다는 사실은 verifier가 medical tool-use trajectory를 읽을 수 있음을 보여 준다. 그러나 실제 의료 의사결정에서는 guideline provenance, 환자 정보 privacy, 법적 책임, clinician override가 함께 필요하다. 이 논문은 그런 deployment 조건을 해결하지 않지만, 검증 신호가 의료 agent workflow에서도 후보 선택 성능을 개선할 수 있는지 탐색한 첫 단계로 의미가 있다.

베이스라인은 세 층으로 나뉜다. 첫째, candidate pool에서 아무 선택 없이 첫 후보를 쓰는 Pass@1이다. 둘째, official leaderboard나 기존 강한 모델의 single-run 성능이다. 셋째, oracle verifier가 후보 pool 안에서 실제 정답을 항상 고르는 upper bound다. 이 세 값을 함께 보면 verifier가 어디까지 headroom을 회수했는지 알 수 있다. 성능이 Pass@1보다 높지만 oracle에는 못 미치면, 생성 능력과 선택 능력 사이에 아직 여지가 남아 있다는 뜻이다.

robotics에서는 별도 학습된 reward model도 비교한다. RoboReward-8B는 약 45k episode로 학습됐고, Robometer-4B는 약 1M comparison을 사용한다. TOPReward와 discrete LLM-as-a-Judge도 함께 놓는다. LLM-as-a-Verifier가 zero-shot 설정에서 이 reward model들을 넘는다는 결과는 강하다. 다만 이 비교는 benchmark 구성과 VLM verifier 품질에 크게 의존하므로, 실제 로봇 제어에서 곧바로 일반화된다고 읽기보다는 reward signal 후보의 범용성을 보여 주는 evidence로 보는 편이 안전하다.

영역	Benchmark	Candidate generator / scaffold	Verifier	핵심 측정값
Coding	Terminal-Bench V2	GPT-5.5 + Capy, $N=5$	Gemini 2.5 Flash	Accuracy, oracle Pass@5, harness generalization
Coding	SWE-Bench Verified	Opus 4.5 / Gemini 3 Flash / MiniMax M2.5 + mini-swe-agent	Gemini 2.5 Flash	Hidden test issue resolution accuracy
Robotics	RoboRewardBench	trajectory video pair 500개	Qwen 3.6 35B VLM	Preference accuracy, MAE, VOC
Medical	MedAgentBench	Claude Opus 4.8 + AgentBench, $N=5$	동일 verification protocol	EHR/tool-use task accuracy

이 설정에서 한 가지 유의할 점은 verifier와 generator가 완전히 독립적인 연구 질문으로 분리되지는 않는다는 점이다. candidate pool이 강해야 verifier가 고를 수 있는 좋은 후보가 생긴다. 반대로 candidate pool이 너무 약하면 oracle upper bound도 낮다. 그래서 이 논문의 결과는 verifier 단독 능력이라기보다, strong generator pool과 fine-grained verifier가 결합했을 때 얻는 test-time system 성능으로 읽어야 한다.

5. 주요 실험 결과: 연속 검증 점수가 후보 선택 성능을 끌어올린다

5.1 Terminal-Bench V2와 SWE-Bench Verified

Terminal-Bench V2에서 GPT-5.5 + Capy의 Pass@1은 83.1%이고, 후보 5개를 완벽히 고르는 oracle Pass@5는 92.1%다. LLM-as-a-Verifier는 86.5%를 달성한다. 절대 개선폭은 3.4%p지만, 이미 높은 baseline 위에서 얻은 개선이라는 점이 중요하다. 또한 official leaderboard의 강한 조합인 GPT-5.5 + NexAU-AHE 84.7%, Claude Mythos + Terminus-2 82.0%, Opus 4.7 + WOZCODE 80.2%를 넘는다고 보고한다.

SWE-Bench Verified에서는 candidate pool이 더 흥미롭다. 하나의 모델에서 여러 후보를 뽑는 대신, Opus 4.5, Gemini 3 Flash, MiniMax M2.5가 만든 후보를 하나씩 섞는다. 평균 Pass@1은 76.1%, oracle Pass@3은 84.4%이고, verifier 선택은 78.2%를 만든다. 이는 verifier가 단일 모델의 샘플 다양성과 서로 다른 모델 family가 만든 patch 후보 사이에서도 선택 신호를 줄 수 있음을 보여 준다.

두 coding 결과는 최근 agent benchmark가 왜 어려운지와도 맞닿아 있다. 숨은 테스트를 통과해야 하는 task에서는 겉보기 reasoning이 좋아도 결과 파일이 틀릴 수 있고, terminal task에서는 로그에 나온 실패를 무시한 채 종료할 수 있다. discrete judge는 “전반적으로 그럴듯함”에 높은 점수를 줄 가능성이 있지만, verifier는 Specification, Output, Errors 기준으로 궤적을 나눠 읽기 때문에 더 직접적으로 실패 근거를 잡는다.

5.2 query-optimize 사례: tie를 없애는 기대값

논문이 제시한 query-optimize 사례는 방법론의 필요성을 가장 잘 보여 준다. 과제는 SQLite 데이터베이스에서 느린 query를 최적화하되, 같은 출력을 만들어야 한다. 한 후보는 canonical database에서 원 query가 완료될 때까지 5분 이상 기다린 뒤 optimized output과 직접 diff를 수행한다. 다른 후보는 원 query 실행이 오래 걸리자 데이터베이스를 복사하고 index를 추가한 뒤 그 복사본 기준으로 비교한다. 겉으로는 둘 다 최적화된 query와 diff를 이야기하지만, 후자는 hidden grader가 보는 원본 조건을 검증하지 않았다.

Gemini 2.5 Flash의 reasoning trace는 이 차이를 포착한다. 문제는 최종 discrete score다. 1~5 discrete judge는 100회 평가 중 88회나 두 후보를 tie로 만든다. 같은 1~5 scale이라도 확률분포 기대값을 쓰면 tie가 0회가 되고 correct trajectory를 69회 더 높게 점수화한다. granularity를 $G=20$으로 키우면 correct가 77회 더 높게 평가된다. 이 결과는 verifier가 “새로운 지식”을 얻었다기보다, 이미 reasoning에 드러난 미묘한 판단을 수치로 잃지 않았다는 데 의미가 있다.

Method	Reward 계산	$s_c>s_i$	$s_c=s_i$	$s_c<s_i$
Judge, discrete $G=5$	$\phi(\arg\max_g p_\theta(v_g))$	12/100	88/100	0/100
Verifier, continuous $G=5$	$\sum_{g=1}^{5}p_\theta(v_g)\phi(v_g)$	69/100	0/100	31/100
Verifier, continuous $G=20$	$\sum_{g=1}^{20}p_\theta(v_g)\phi(v_g)$	77/100	0/100	23/100

query-optimize 사례에서 특히 흥미로운 부분은 verifier reasoning과 discrete score 사이의 불일치다. 모델은 자연어로는 failing trajectory가 copied database와 added index에 의존했다는 점을 지적한다. 그럼에도 1~5 scale argmax 점수는 correct와 incorrect 모두 높은 점수로 묶는다. 이 현상은 우리가 LLM 평가를 볼 때 자주 겪는 문제다. 설명문에는 핵심 결함이 들어 있는데, 최종 점수나 pass/fail label은 그 결함을 충분히 반영하지 못한다.

continuous expectation은 이 불일치를 줄인다. 모델이 5점 토큰을 가장 높게 보더라도 4점과 3점에 남은 확률이 후보별로 다르면 기대값은 달라진다. 즉 verifier는 모델의 hesitation을 수치로 읽는다. 이 접근은 reasoning trace를 더 길게 쓰게 하는 방식과 다르다. 더 많은 설명을 생성하는 대신, 이미 scoring position에 존재하는 확률 질량을 버리지 않는 방식이다.

Terminal-Bench류 작업에서 이런 차이는 실제 성공률로 이어질 수 있다. hidden grader는 겉보기 설명이 아니라 canonical environment에서의 결과를 본다. 잘못된 trajectory는 스스로 검증했다고 주장할 수 있지만, 검증 방식이 task condition을 바꾸면 hidden test는 실패한다. LLM-as-a-Verifier는 기준 분해와 continuous score를 통해 이런 “검증의 검증” 문제를 더 민감하게 포착하려고 한다.

SWE-Bench Verified 결과는 patch selection 관점에서도 중요하다. 여러 모델이 각자 다른 patch를 만들 때, 사람 개발자는 diff, test log, issue requirement를 모두 보고 고른다. verifier는 이 사람 검토의 일부를 자동화하려는 시도다. 78.2%가 oracle 84.4%에 미치지 못한다는 점은 아직 많은 여지가 있음을 보여 주지만, heterogeneous candidate pool에서 단일 모델 baseline을 넘었다는 점은 실제 coding assistant workflow에 가까운 신호다.

5.3 robotics와 medical benchmark

RoboRewardBench 결과는 논문의 범용성 주장을 크게 강화한다. LLM-as-a-Verifier는 87.4% preference accuracy를 기록해 RoboReward-8B의 81.4%, Robometer-4B의 78.8%, TOPReward의 74.7%, discrete LLM-as-a-Judge의 70.8%를 모두 넘는다. 더 흥미로운 부분은 MAE다. human annotation과의 Mean Absolute Error가 RoboReward 8B의 1.11에서 verifier 결합 시 0.72로 줄어든다. VLM의 scoring-token 기대값이 영상 기반 trajectory progress에도 의미 있는 정렬 신호를 만든 것이다.

MedAgentBench에서는 Claude Opus 4.8 후보 pool의 Pass@1이 70.2%이고, LLM-as-a-Verifier는 73.3%를 얻는다. 의료 task라는 표현 때문에 결과를 과장해서 읽으면 안 된다. 이 벤치마크는 실제 임상 deployment와 구분되는 simulated EHR 환경의 agent benchmark다. 하지만 guideline lookup과 patient information retrieval이 섞인 multi-step tool use에서는 검증 오류가 단순 정확도보다 더 민감한 문제를 만든다. 그런 환경에서 같은 verifier protocol이 coding과 robotics 밖에서도 작동했다는 점은 의미가 있다.

Method	RoboRewardBench preference accuracy
TOPReward	74.7%
Robometer-4B	78.8%
RoboReward-8B	81.4%
LLM-as-a-Judge (Discrete)	70.8%
LLM-as-a-Verifier	87.4%

Model	RoboRewardBench MAE (낮을수록 좋음)
RoboReward 8B	1.11
RoboReward 8B + LLM-as-a-Verifier	0.72

5.4 harness generalization

appendix의 harness generalization도 중요하다. Capy scaffold에서만 성능이 좋아졌다면 verifier가 특정 로그 형식이나 agent style에 과적합했다고 볼 수 있다. 저자들은 Terminus-Kira와 Terminus-2라는 다른 harness에서도 Terminal-Bench V2 평가를 반복한다. Terminus-Kira에서는 LLM-as-a-Verifier가 79.4%를 얻어 Claude Opus 4.6 74.7%, Gemini 3.1 Pro 74.8%를 넘는다. Terminus-2에서는 71.2%로 Claude Opus 4.6 62.9%, Gemini 3.1 Pro 68.5%보다 높다.

이 결과는 verifier가 scaffold-specific syntax만 읽는 수준을 넘어 terminal state와 task progress를 어느 정도 일반화해서 읽는다는 근거다. 물론 모든 harness에 대한 보장은 아니다. benchmark별 로그 포맷, hidden grader, candidate generator 품질에 따라 달라질 수 있다. 그래도 같은 prompt template과 같은 verifier 설정이 두 추가 harness에서 양의 효과를 보였다는 사실은, 이 접근이 특정 데모를 넘어 실험적 재현성을 갖고 있음을 보여 준다.

Agent harness	LLM-as-a-Verifier	Claude Opus 4.6	Gemini 3.1 Pro
Terminus-Kira (Opus 4.6 proposals)	79.4%	74.7%	74.8%
Terminus-2 (GPT-5.3-Codex proposals)	71.2%	62.9%	68.5%

6. 추가 분석 및 Ablation Study: 검증 신호를 진행도와 보상으로 재사용하기

6.1 Verifier와 Judge의 반복 평가 비교

반복 평가는 discrete judge에도 도움이 된다. 같은 후보를 여러 번 평가해 평균하면 tie가 일부 깨지고 noise가 줄어든다. 하지만 논문은 continuous verifier가 같은 반복 예산에서 계속 더 나은 신호를 낸다고 보고한다. Terminal-Bench V2의 repeated evaluation 실험에서 verifier는 $k=1$에도 74.7%를 얻고, $k=16$에 77.5%로 올라간다. 반면 judge는 tie 문제가 남아 있고, $k=1$ tie rate가 26.7%에서 $k=16$에도 5.5%까지 남는다. verifier는 tie를 0으로 유지한다.

Figure 6: Terminal-Bench V2에서 repeated evaluation 예산별 continuous verifier와 discrete judge의 accuracy 및 tie rate 비교.

Figure 6은 LLM-as-a-Verifier의 장점이 반복 평가 자체에서만 나오지 않는다는 점을 보여 준다. discrete judge도 반복하면 tie가 줄지만, coarse score를 평균해 tie를 깨는 방식은 한계가 있다. continuous verifier는 첫 평가부터 score distribution 기대값을 쓰기 때문에 tie가 발생하지 않고, 반복은 그 위에서 variance를 더 낮추는 역할을 한다. 이 차이가 agent 후보 선택에서 안정성으로 이어진다.

6.2 Value-Order Correlation: 점수가 진행도를 따라가는가

논문은 verifier score를 단순히 최종 후보 선택에만 쓰지 않는다. prefix trajectory가 길어질수록 score가 어떻게 변하는지 보며 Value-Order Correlation을 계산한다. VOC는 step index와 prefix score의 Spearman rank correlation이다. 성공적인 궤적이라면 시간이 지날수록 작업이 진전되므로 score가 점차 올라가야 하고, 실패하거나 정체된 궤적이라면 score가 낮거나 불안정해야 한다. 이 지표는 verifier가 task progress를 읽는지 확인하는 장치다.

Terminal-Bench V2의 500개 trajectory pair에서 successful trajectory의 VOC는 0.848±0.012, failed trajectory의 VOC는 0.769±0.016이다. 둘 다 양수라는 점은 agent가 실패하더라도 일부 진행을 하기는 한다는 뜻이고, 성공과 실패 사이의 +0.079 gap은 verifier가 더 일관된 진전을 구분한다는 뜻이다. robotics에서는 차이가 더 크다. LLM-as-a-Verifier의 RoboReward VOC는 0.966으로 RoboReward-8B 0.877, Robometer-4B 0.780, TOPReward 0.565보다 높다.

Figure 7: pytorch-model-cli 작업에서 성공 trajectory와 실패 trajectory의 verifier score 진행 양상을 비교한 예시.

Figure 7은 verifier score가 사람이 읽는 실패 로그와 맞물리는 방식을 보여 준다. 성공 trajectory는 model.py 읽기, compiler 설치, CPU-only torch 설치, hidden_dim 수정, DONE으로 이어지며 점수가 올라간다. 실패 trajectory는 큰 torchvision 설치로 disk space를 소진하고 compilation error에 부딪히며 낮은 점수를 유지한다. 이 그림은 score가 단순 선호를 넘어 진행도 모니터로도 쓰일 수 있음을 보여 준다.

Trajectory outcome	Spearman VOC
Successful	$0.848 \pm 0.012$
Failed	$0.769 \pm 0.016$
Success − Failed gap	+0.079

Method	RoboRewardBench Spearman VOC
LLM-as-a-Verifier (Qwen 3.6 35B, $K=5$, $G=20$)	0.966
RoboReward-8B	0.877
Robometer-4B	0.780
TOPReward	0.565

6.3 TurboAgent와 실시간 모니터링

저자들은 이 진행도 신호를 실제 coding agent extension으로 연결한다. TurboAgent는 Claude Code와 OpenAI-API compatible client 사이에 들어가는 inference-time proxy다. 각 요청에 대해 여러 후보 trajectory를 병렬로 만들고, PPT로 가장 좋은 응답을 고른다. 동시에 verifier output을 web interface로 시각화해 long-running agent job을 모니터링할 수 있게 한다. 논문의 공개 프로젝트 링크에는 llm-as-a-verifier.com, GitHub repository, Claude Code extension이 함께 제시된다.

이 부분은 아직 연구 prototype에 가깝지만, 방향은 실무적으로 중요하다. 에이전트가 오래 실행될수록 사용자는 “끝났는가”보다 “망가지고 있는가”를 먼저 알고 싶다. VOC 기반 progress score가 안정적으로 작동하면, verifier는 중간 중단, rollback, human approval checkpoint를 여는 trigger가 될 수 있다. 다만 실제 개발 환경에서는 verifier 호출 비용, 비공개 코드 유출 위험, 잘못된 낮은 점수로 인한 과도한 중단을 함께 관리해야 한다.

VOC의 장점은 score를 시간축 위에 놓는다는 점이다. 최종 후보를 고르는 verifier는 마지막 artifact만 잘 보면 된다고 생각하기 쉽지만, 실제 agent 운영에서는 중간 궤적의 모양이 훨씬 중요하다. score가 성공 trajectory에서 점진적으로 상승한다면, 사용자는 긴 작업이 아직 진행 중인지, 이미 막혔는지, 또는 잘못된 방향으로 drift하는지 볼 수 있다. 이는 agent UI와 observability 설계에 바로 연결된다.

다만 VOC가 높다고 해서 모든 prefix score가 안전한 stop signal이 되는 것은 아니다. 어떤 작업은 초반에 많은 준비를 하고 마지막 한 단계에서만 결과가 확인된다. 이런 task에서는 성공 trajectory도 초반 score가 낮게 유지될 수 있다. 반대로 실패 trajectory가 중간까지는 매우 좋아 보이다가 마지막 검증에서 무너질 수도 있다. 따라서 VOC는 task family별로 해석해야 하며, universal early-stop threshold로 쓰기에는 추가 calibration이 필요하다.

TurboAgent 같은 proxy 구조는 구현 면에서 유연하지만, 데이터 경계가 커진다. 에이전트 요청과 후보 trajectory가 verifier proxy를 지나가므로, 비공개 코드나 업무 문서가 외부 verifier로 흘러갈 수 있다. 사내 환경에 배포하려면 local verifier, redaction, audit log, opt-in task class 같은 통제가 함께 필요하다. 논문은 extension을 제시하지만, enterprise deployment의 privacy policy까지 다루지는 않는다.

RL reward shaping에서도 같은 점이 반복된다. verifier reward가 sparse reward의 빈칸을 채워 주는 것은 매력적이지만, 정책이 verifier의 언어적 선호를 학습하면서 실제 환경 목표와 어긋날 수 있다. 특히 장기 multi-turn RL에서는 초기 작은 score bias가 rollout distribution을 바꾸고, 그 바뀐 분포에서 verifier가 더 큰 bias를 보일 수 있다. 논문이 제한적 single-turn setting을 한계로 적은 이유도 여기에 있다.

6.4 dense reward로서의 LLM-as-a-Verifier

마지막 확장은 reinforcement learning이다. 논문은 verifier score를 dense reward로 사용해 sparse reward의 credit assignment 문제를 완화한다. robotics에서는 $\pi_0$ vision-language-action policy를 LIBERO ketchup task에서 DSRL-SAC로 fine-tune한다. 각 rollout의 rendered frame sequence를 verifier가 progress curve로 평가하고, 환경 reward에 $\lambda\rho_t$를 더해 replay buffer에 저장한다. 이 방식은 SAC objective 자체를 바꾸지 않고 중간 신호를 보강한다.

math reasoning에서는 Qwen3-8B를 MATH에서 GRPO로 fine-tune한다. 초반 학습에서는 같은 group 안의 답이 모두 틀리면 correctness reward가 0으로 묶여 gradient가 사라질 수 있다. LLM-as-a-Verifier는 reasoning trace를 비교해 normalized preference score를 주고, correctness와 format reward에 reasoning reward를 더한다. 결과적으로 LIBERO에서는 약 1.8배 sample efficiency와 더 높은 final success rate 0.76 vs 0.69를 보고하고, MATH에서는 약 1.1배 sample efficiency를 얻는다.

Figure 8: LIBERO off-policy RL과 MATH on-policy RL에서 verifier dense reward가 sample efficiency를 높인 결과.

Figure 8은 verifier를 평가 모듈에서 학습 신호로 확장한 결과다. 왼쪽 LIBERO 실험은 sparse reward만으로는 늦게 드러나는 진행도를 verifier가 중간 보상으로 바꿔 SAC 학습을 빠르게 만든다. 오른쪽 MATH 실험은 GRPO에서 모든 답이 틀린 early stage에도 reasoning quality 차이를 보상으로 남긴다. 두 결과 모두 verifier score가 후보 선택을 넘어 credit assignment에 쓰일 수 있음을 시사한다.

Setting	Baseline	Verifier reward 효과	보고된 수치
LIBERO ketchup + DSRL-SAC	sparse environment reward	progress curve $\rho_t$를 dense reward로 relabeling	약 1.8× sample efficiency, final success 0.76 vs 0.69
MATH + GRPO	correctness + format reward	reasoning trace preference score를 추가	약 1.1× sample efficiency

7. 한계점 및 향후 연구 방향: logprob 접근, 비용, 검증자 편향

7.1 logprob 접근성의 제약

가장 직접적인 한계는 scoring-token logprob 접근성이다. LLM-as-a-Verifier의 핵심은 점수 토큰 분포의 기대값을 계산하는 데 있다. 하지만 많은 frontier API는 token-level logprob을 제한하거나 제공하지 않는다. 저자들은 appendix에서 two-stage workaround를 제안한다. 먼저 GPT-5.5 같은 closed model이 trajectory pair에 대한 reasoning을 생성하고, 그 reasoning을 Gemini 2.5 Flash 같은 logprob 접근 가능한 open verifier에 전달해 continuous reward를 회수하는 방식이다.

이 workaround는 실험적으로 괜찮은 결과를 낸다. GPT-5.5 discrete score는 $K=1$에서 accuracy 74.9%, tie rate 10.9%였지만, GPT-5.5 reasoning을 Gemini 2.5 Flash continuous scorer로 넘기면 accuracy 80.1%, tie 0%가 된다. $K=16$에서도 continuous workaround가 81.2%로 discrete 79.1%보다 높다. 하지만 이 구조는 reasoning model과 scoring model을 나누므로 latency, 비용, privacy surface가 커진다.

K	GPT-5.5 discrete accuracy	GPT-5.5 discrete tie	GPT-5.5 → Gemini continuous accuracy	Continuous tie
1	74.9%	10.9%	80.1%	0.0%
2	76.3%	9.1%	80.5%	0.0%
4	77.6%	7.0%	81.0%	0.0%
8	78.4%	5.8%	80.9%	0.0%
16	79.1%	5.0%	81.2%	0.0%

7.2 비용과 adaptive allocation

두 번째 한계는 비용이다. $G$를 키우는 것은 주로 logprob extraction의 문제지만, $K$와 $C$를 키우면 verifier 호출 수가 늘어난다. PPT가 pairwise comparison 비용을 줄여도, long-horizon agent service에서 모든 요청마다 여러 후보를 만들고 여러 기준으로 반복 검증하는 것은 부담스럽다. 논문은 세 축을 practitioner가 latency budget에 맞춰 조절할 수 있다고 설명하지만, 실제 시스템에서는 어떤 task에 verifier budget을 집중할지 결정하는 또 다른 scheduler가 필요하다.

내가 보기에는 여기서 다음 연구 질문은 adaptive verification allocation이다. verifier가 자신 있게 큰 점수 차이를 낸 pair는 한 번만 보고, 불확실한 pair나 안전 민감도가 높은 task에만 반복 평가와 기준 분해를 늘리는 방식이 필요하다. 현재 논문은 $K=8$ 또는 $K=16$ 같은 고정 예산을 주로 다룬다. 운영 환경에서는 budget이 task difficulty, risk level, candidate diversity, user interruption cost에 따라 바뀌어야 한다.

7.3 verifier가 틀릴 때의 위험

세 번째 한계는 verifier bias다. LLM-as-a-Verifier가 discrete judge보다 tie를 줄인다고 해서 항상 더 진실한 판단을 한다는 뜻은 아니다. score-token 분포의 기대값은 모델 내부 확신을 더 잘 보존하지만, 그 내부 확신 자체가 잘못된 경우도 있다. 예를 들어 특정 harness의 로그 형식에 익숙해져 false positive를 주거나, medical task에서 guideline lookup의 안전 조건을 놓칠 수 있다. continuous score가 부드럽기 때문에 오히려 잘못된 확신이 더 그럴듯한 숫자로 보일 위험도 있다.

이 한계를 줄이려면 verifier 자체도 감사 대상이 되어야 한다. query-optimize 사례처럼 reasoning trace를 함께 남기고, selected trajectory와 rejected trajectory의 차이를 사람이 다시 볼 수 있어야 한다. 특히 개발 도구에 붙일 때는 “verifier가 낮은 점수를 줬다”만 보여 주면 안 된다. 어떤 기준에서, 어떤 로그나 파일 상태 때문에 낮은 점수를 줬는지 provenance를 연결해야 한다. 이 지점은 기존 위키의 provenance-aware evaluation과 다시 만난다.

logprob 접근성 문제는 단지 API 옵션 하나의 문제가 아니다. 기업 환경에서는 model provider가 보안·비용·서비스 안정성을 이유로 세부 token distribution을 숨길 수 있고, 일부 모델은 sampling interface만 제공한다. 이때 two-stage workaround는 유용하지만, reasoning을 한 모델에서 만들고 scoring을 다른 모델에서 수행하므로 model mismatch가 생긴다. closed model의 reasoning이 open verifier의 scoring token space에서 같은 의미로 해석된다는 보장은 추가 검증이 필요하다.

비용 문제도 latency 평균만으로 판단하기 어렵다. agent workflow에서는 사용자가 기다리는 interactive step과 background batch step이 섞인다. 동일한 $K=8$ verifier 반복도 interactive coding session에서는 길게 느껴지고, overnight benchmark run에서는 충분히 허용될 수 있다. 따라서 verifier budget은 task urgency와 risk level에 맞춰 조정되어야 한다. 이 논문은 그 스케줄러를 직접 만들지는 않지만, 세 축을 분리해 둔 덕분에 후속 시스템이 adaptive policy를 붙일 수 있는 여지를 준다.

검증자 편향을 다루려면 negative result 공개가 더 필요하다. 어떤 benchmark에서 verifier가 자주 속는지, 어떤 trajectory artifact가 false confidence를 만드는지, 어떤 criteria decomposition이 오히려 noise를 키우는지까지 보여 주면 방법론의 경계가 더 분명해진다. 현재 논문은 성능 개선을 넓게 제시하는 데 집중하므로, 실패 사례의 체계화는 후속 연구의 몫으로 남는다.

마지막으로 human-in-the-loop 위치가 더 명확해야 한다. verifier가 top candidate를 고를 때 사람이 모든 후보를 다시 볼 필요는 없지만, 고위험 task에서는 verifier score 차이가 작거나 criteria 간 disagreement가 큰 경우 사람 검토를 열어야 한다. continuous score는 이런 routing signal로 쓰기 좋다. 따라서 다음 단계는 단순 자동 선택보다, verifier uncertainty를 사람 검토 큐와 연결하는 운영 프로토콜이라고 본다.

7.4 reward hacking 가능성

dense reward로 사용될 때는 reward hacking도 생각해야 한다. 정책이 verifier가 좋아하는 표면적 진행 신호를 학습할 수 있기 때문이다. robotics에서는 프레임 sequence가 그럴듯한 중간 상태를 보이지만 실제 성공 조건을 만족하지 못하는 궤적이 생길 수 있고, coding에서는 로그에 깨끗한 validation 메시지를 남기지만 hidden test를 통과하지 못하는 패턴이 생길 수 있다. 논문은 sample efficiency 개선을 보였지만, verifier reward를 장기 RL에 쓰는 설정은 아직 제한적이다.

향후에는 verifier reward와 ground-truth evaluator 사이의 drift를 추적하는 장치가 필요하다. 정책 업데이트가 진행될수록 verifier score는 올라가는데 hidden success가 정체되는지, verifier reasoning이 특정 형식에 끌려가는지, adversarial trajectory가 continuous score를 속일 수 있는지 봐야 한다. 이 검증이 없으면 LLM-as-a-Verifier는 agent 성능을 올리는 도구이면서 동시에 새로운 최적화 표면이 된다.

8. 내 해석: 약점 1 + 후속 제안 1

나는 이 논문의 가장 큰 약점이 “검증자가 왜 맞는가”를 충분히 분해하지 못한 데 있다고 본다. 성능표는 강하고, query-optimize 사례도 설득력 있다. 하지만 많은 결과가 강한 verifier backbone, 강한 candidate generator, 특정 benchmark의 hidden grader 구조가 결합된 system-level 결과다. 예를 들어 Terminal-Bench에서 86.5%를 얻었다는 사실은 유용하지만, 그 개선이 logit expectation 자체에서 얼마나 왔고, criteria decomposition에서 얼마나 왔고, Gemini 2.5 Flash가 해당 로그 패턴을 잘 읽는 데서 얼마나 왔는지는 더 세밀하게 분리될 필요가 있다. 논문에 scaling axis ablation은 있지만, verifier failure taxonomy와 benchmark별 오류 유형 분석은 상대적으로 얇다.

이 지점은 이전에 리뷰한 Agent Genome이나 Bootstrapped Monitoring과 비교하면 더 두드러진다. Agent Genome은 행동 sequence를 X/E/P/V처럼 압축해 실패 패턴 자체를 분석했고, Bootstrapped Monitoring은 monitor reasoning이 collusion이나 누락을 만들 수 있는 경로를 safety 관점으로 봤다. LLM-as-a-Verifier는 훨씬 실용적인 성능 이득을 보여 주지만, verifier가 틀린 trajectory를 고른 순간 그 오류가 어떤 종류인지 체계적으로 남기는 장치가 아직 부족하다. 실제 운영에서는 평균 성능보다 “어떤 실패를 자신 있게 잘못 고르는가”가 더 중요할 때가 많다.

내가 이 연구를 확장한다면, 다음 단계는 verifier disagreement ledger를 붙이는 것이다. 같은 candidate pair에 대해 continuous verifier, discrete judge, hidden test, human audit, lightweight static checker가 각각 어떤 판단을 했는지 기록하고, 불일치 유형을 schema로 쌓는다. 특히 coding agent에서는 파일 diff, test log, execution timeout, deleted artifact, database mutation 같은 provenance feature를 함께 저장할 수 있다. 이렇게 하면 verifier score가 단순 scalar reward로 끝나지 않고, 다음 prompt criteria나 adaptive budget allocation을 고치는 데이터가 된다.

후속 실험으로는 “verifier가 확신했지만 틀린 top-1 선택”만 모은 challenge set을 만들고 싶다. 여기서 $G$, $K$, $C$를 늘렸을 때도 오류가 유지되는지, 다른 verifier backbone을 섞으면 줄어드는지, provenance feature를 추가하면 줄어드는지 보면 verification scaling의 한계가 더 선명해진다. 지금 논문은 verification을 새 스케일링 축으로 세우는 데 성공했지만, 실제 서비스에 붙이려면 verifier의 실패도 first-class artifact로 관리해야 한다. 이 보강이 들어가면 agent monitoring, selective human review, RL reward shaping이 같은 ledger를 공유할 수 있다.

9. 결론: 검증을 스케일링 가능한 시스템 구성요소로 보기

논문을 한 문장으로 압축하면, 생성 후보의 양을 늘리는 시대에는 후보 선택기의 해상도도 함께 올라가야 한다는 주장이다. 기존 judge는 후보를 읽고 단일 점수 토큰을 선택하지만, LLM-as-a-Verifier는 그 점수 토큰 주변의 확률 질량을 모두 읽는다. 이 작은 계측 차이가 tie rate, candidate ranking, progress monitoring, dense reward로 이어진다. 방법 자체는 간단하지만, 적용 범위가 넓기 때문에 영향력이 생긴다.

실무 관점에서 바로 가져갈 수 있는 교훈은 두 가지다. 첫째, agent evaluation에서 최종 텍스트 점수 하나만 저장하면 너무 많은 정보를 잃는다. 점수 분포, criteria별 점수, 반복 평가 variance, 선택된 후보와 탈락 후보의 차이를 함께 남겨야 다음 개선이 가능하다. 둘째, verifier 호출은 비용이므로 모든 task에 같은 예산을 쓰면 안 된다. 불확실한 후보쌍, 위험이 큰 작업, hidden evaluator와 disagreement가 잦은 영역에 예산을 집중해야 한다.

연구 관점에서는 verification scaling이 generation scaling과 별도로 측정될 수 있는지 더 봐야 한다. 후보 pool quality를 고정하고 verifier만 바꾸는 실험, verifier backbone을 바꿔 failure taxonomy를 비교하는 실험, adversarial trajectory로 continuous score를 속이는 실험이 필요하다. 이런 실험이 쌓이면 “검증도 스케일링된다”는 주장이 단일 논문 결과를 넘어 더 일반적인 경험 법칙으로 자리 잡을 수 있다.

블로그에서 계속 추적하던 agent evaluation 계열 논문들과 연결하면, LLM-as-a-Verifier는 평가 표면을 넓히는 흐름의 다음 단계다. Workspace-Bench는 workspace artifact를 평가에 넣었고, Agent Genome은 행동 sequence를 요약했으며, Bootstrapped Monitoring은 monitor reasoning을 감사했다. 이번 논문은 그 표면 위에서 쓸 수 있는 calibrated scalar signal을 제안한다. 이 신호가 충분히 잘 관리되면, 장기 에이전트 시스템의 관찰·선택·학습 루프가 하나의 검증 계층으로 묶일 수 있다.

LLM-as-a-Verifier의 핵심 기여는 점수 토큰 logit의 기대값이라는 비교적 단순한 아이디어를 agentic task의 여러 층위로 밀어붙인 데 있다. discrete judge가 하나의 정수 점수로 버리는 정보를 보존하고, granularity, repetition, criteria decomposition을 독립적인 예산 축으로 다룬다. 여기에 PPT를 붙여 후보 비교 비용을 줄이고, coding·robotics·medical benchmark에서 같은 절차를 시험한다. 결과적으로 verifier는 평가 모듈, 후보 선택기, 진행도 모니터, RL reward source를 동시에 맡는다.

논문의 성과가 특히 의미 있는 이유는 agent 시스템이 점점 “여러 번 시도한 뒤 좋은 것을 고르는” 구조로 바뀌고 있기 때문이다. 모델 하나가 한 번에 답을 내는 시대에는 generation quality가 대부분이었다. 하지만 장기 코딩 작업, 로봇 rollout, 의료 정보 검색처럼 실패 비용이 큰 작업에서는 후보를 많이 만드는 것보다 올바른 후보를 고르는 능력이 더 중요해진다. 이 논문은 그 선택 능력을 별도 스케일링 축으로 명명하고, 실험적으로 꽤 넓은 범위에서 보여 준다.

동시에 이 접근은 verifier 자체의 감사를 요구한다. 연속 점수는 tie를 줄이고 ranking을 부드럽게 만들지만, 잘못된 확신도 부드러운 숫자로 포장할 수 있다. 그래서 향후 시스템은 verifier score, reasoning trace, provenance artifact, hidden evaluator 결과를 함께 저장해야 한다. 이 조건이 갖춰지면 LLM-as-a-Verifier는 단순 benchmark trick보다 장기 에이전트 운영의 안전장치로 발전할 수 있다.

전체적으로 이 논문은 “더 큰 모델을 만들자”보다 “이미 만들어진 후보 중 무엇을 믿을지 더 잘 정하자”에 초점을 둔다. 그 전환은 지금의 AI agent 흐름과 잘 맞는다. 코드 에이전트, 검색 에이전트, 로봇 정책, 의료 도구 사용 시스템이 모두 긴 궤적을 만들고 있기 때문이다. 생성 모델이 확장될수록 검증기도 함께 확장되어야 한다는 주장을, 이 논문은 숫자와 알고리즘과 prototype extension으로 비교적 설득력 있게 보여 준다.

또 하나 짚을 부분은 verifier가 만드는 숫자의 해석 단위다. 86.5% 같은 headline accuracy는 최종 제출 기준이지만, 실제 시스템 안에서는 candidate pair별 preference probability, criteria별 reward, 반복 평가의 분산, prefix별 score curve가 함께 존재한다. 이 값들을 모두 저장하면 단일 성공률보다 훨씬 풍부한 운영 로그가 된다. 다음번 실패 분석에서는 “어떤 후보를 골랐는가”와 함께 “어떤 기준이 선택을 밀었는가”를 다시 볼 수 있다.

이 관점에서 LLM-as-a-Verifier는 모델 평가 논문이면서 observability 논문에 가깝다. 좋은 observability 도구는 단순히 알람을 울리는 데서 멈추지 않고, 나중에 원인을 추적할 수 있는 충분한 중간 상태를 남긴다. verifier score도 마찬가지다. continuous reward가 높았다는 숫자만 남기면 실패 뒤에 배울 수 있는 것이 적다. score distribution, criteria prompt, reasoning excerpt, 선택된 trajectory의 artifact hash를 함께 보존해야 한다.

따라서 이 논문을 실제 agent pipeline에 붙인다면, 첫 적용 지점은 완전 자동화보다 shadow mode가 좋다. 기존 pass/fail evaluator와 human review를 유지한 채 verifier가 어떤 후보를 골랐을지, 어떤 순간에 낮은 진행도 점수를 냈을지, 사람이 고른 후보와 얼마나 자주 어긋나는지 기록하는 방식이다. 이 shadow log가 충분히 쌓이면 그때 selected task class부터 자동 선택이나 early warning을 켤 수 있다.

마지막으로, 이 논문은 “평가가 학습을 돕는다”는 오래된 명제를 에이전트 시대에 다시 쓴다. 좋은 verifier는 리더보드 숫자를 계산하는 데 그치지 않고, 후보 생성 전략, UI 모니터링, 사람 검토 라우팅, RL reward 설계까지 바꾼다. 그래서 verification scaling은 후처리 옵션이 아니라 agent system architecture의 한 축이다. 생성 모델이 더 강해질수록, 그 출력 중 무엇을 실행할지 결정하는 층의 중요성은 더 커진다.

특히 개발 에이전트에서는 verifier가 선택한 후보와 실제 테스트 결과가 갈라지는 순간을 따로 모아야 한다. 그런 사례는 단순 실패 로그보다 가치가 크다. verifier가 놓친 조건, 모델이 과신한 로그 패턴, 후보 생성기가 반복해서 만드는 위험한 우회 검증을 동시에 드러내기 때문이다. 이 데이터가 쌓이면 다음 세대 verifier prompt와 criteria decomposition을 손으로 추측하지 않고 실제 disagreement에서 고칠 수 있다.

10. 요약 정리: LLM-as-a-Verifier에서 가져갈 핵심 포인트

• LLM-as-a-Verifier는 discrete LM judge가 버리는 scoring-token 분포를 기대값으로 읽어 continuous reward를 만든다.
• verification scaling은 score granularity $G$, repeated evaluation $K$, criteria decomposition $C$라는 세 축으로 구성된다.
• Terminal-Bench V2에서 Pass@1 83.1%, oracle Pass@5 92.1%인 후보 pool에서 verifier 선택은 86.5%를 달성한다.
• SWE-Bench Verified에서는 서로 다른 모델 family가 만든 후보 3개 중 좋은 patch를 골라 78.2%를 기록한다.
• RoboRewardBench에서는 zero-shot verifier가 RoboReward-8B, Robometer-4B, TOPReward보다 높은 87.4% preference accuracy를 낸다.
• Probabilistic Pivot Tournament는 모든 후보쌍을 비교하지 않고 pivot set 중심으로 soft win을 누적해 후보 선택 비용을 줄인다.
• Value-Order Correlation 분석은 verifier score가 단순 최종 선택과 agent progress monitoring에도 쓰일 수 있음을 보여 준다.
• dense verifier reward는 LIBERO off-policy RL과 MATH GRPO에서 sample efficiency를 높였지만, reward hacking과 verifier bias 검증이 후속 과제로 남는다.
• 실제 운영에 붙이려면 verifier score만 저장하지 말고 reasoning trace, 파일·로그 provenance, hidden evaluator 결과를 함께 남기는 ledger가 필요하다.