궤적을 judge가 채점한다 — rubric 생성형 reward의 확장
AgentRewardBench: Evaluating Automatic Evaluations of Web Agent Trajectories (Lù et al., arXiv 2025)
Introduction
#9는 환경의 최종 상태(파일이 생겼는가, DB row가 바뀌었는가, API가 200을 반환했는가)로 궤적을 채점했다. #10은 그 안의 개별 도구 호출 — 스키마가 맞는가, 인자가 유효한가 — 을 채점했다. 둘 다 공통점이 있다. 프로그램이 “예/아니오”로 답할 수 있는 것만 본다.
그런데 프로그램이 답할 수 없는 질문이 남는다. “이 궤적이 좋은 접근이었나?” 결과가 맞아도 과정이 나빴을 수 있다 — 남의 주문을 잘못 취소했다가 되돌리고, 같은 API를 열 번 재시도하고, 결국 운 좋게 정답에 도착한 궤적도 최종 상태 검증기 앞에서는 완벽한 1점이다. 반대로 결과가 아깝게 틀렸어도 과정은 훌륭했을 수 있다 — 정확한 전략으로 접근했는데 마지막 API가 rate limit에 걸려 실패한 경우다. 이런 “과정의 질”은 규칙으로 짤 수 없고, 사람이 매번 채점하기엔 궤적 수가 너무 많다. 남는 선택지는 judge다.
RLHF 시리즈가 정리한 reward 4분류 — 규칙 기반, 스칼라 리워드 모델, reference 기반 judge, generative reward model(GRM) — 중 ③④가 이번 편의 무대다. 지금까지는 이 둘이 응답 하나(prompt-response 쌍)를 판정했다. 이 글은 판정 대상이 응답이 아니라 궤적으로 바뀔 때 무엇이 달라지는지를 다룬다.
결론을 먼저 적는다. 궤적으로 확장한 judge는 두 얼굴을 가진다.
- 강력해진다. rubric을 궤적에 맞춰 그때그때 생성하고(Kimi K3의 Agentic GRM), 그 rubric을 트랜지션 단위로 쪼개 적용할 수 있다(TRCA). 환경검증과 도구채점이 놓치는 “부작용”과 “불필요한 반복” 같은 축을 하나의 자연어 판정에 담을 수 있다.
- 더 비싸지고, 더 쉽게 뚫린다. 판정 1건이 10만 토큰짜리 궤적을 읽어야 할 수도 있고, 그 비용을 감당 못 한 판정자는 궤적의 결말에 의존하게 된다. 정책은 이걸 학습으로 발견한다 — “그럴듯하게 끝맺으면 이긴다”는 사실을. One Token to Fool이 응답 judge 하나가 토큰 하나로 뒤집히는 걸 보였다면, 궤적 judge는 구조적으로 더 크게 뚫린다. 이 취약점이 #15에서 본격적인 공격 표면이 된다.
Background
4분류가 궤적에서 다시 배치되는 자리
본격적으로 들어가기 전에, RLHF 시리즈의 reward 4분류가 이 시리즈 3부에서 어디에 각각 배치됐는지 정리하고 가자. 응답 단위였던 분류가 궤적 단위로 넘어오면서 항목마다 무게가 다르게 실린다.
| RLHF 4분류 | 응답 단위(RLHF 시리즈) | 궤적 단위(이 시리즈 3부) |
|---|---|---|
| ① 규칙 기반 | 정답 문자열 매칭, 형식 검사 | #9 환경검증 — 최종 상태를 규칙으로 확인 |
| ② 스칼라 리워드 모델 | 학습된 RM이 응답 하나에 점수 하나 | 궤적 전체에 스칼라 하나는 신호가 지나치게 성겨서 이 시리즈에서는 거의 쓰이지 않는다 |
| ③ reference 기반 judge | 정답과 후보를 대조 | #10 도구채점의 일부(스키마·기대 인자와의 대조) |
| ④ GRM(생성형 리워드 모델) | rubric·자유 서술 판정 | 이 글의 Kimi K3 Agentic GRM, TRCA |
이 표가 보여주는 것은 단순하다. 궤적 단위로 넘어오면 ②는 거의 자취를 감추고, ①은 환경검증으로, ③은 도구채점의 일부로 흡수된다. 남는 건 ④뿐인데, ④가 감당해야 할 몫이 응답 하나였을 때보다 훨씬 커졌다 — “이 텍스트가 좋은가”가 아니라 “이 실행 과정 전체가 좋은가”를 판정해야 하기 때문이다. 이 확장이 정확히 무엇을 어렵게 만드는지가 다음 절의 주제다.
응답 judge와 궤적 judge, 판정 대상이 다르다
응답 judge가 받는 입력은 (prompt, response) 한 쌍이다. 길이는 대개 수백에서 수천 토큰이다. 궤적 judge가 받는 입력은 (사고, 행동, 관측)의 시퀀스다. 여기서 관측(tool output, 웹페이지 텍스트, 코드 diff, DB 쿼리 결과)이 특히 크다. 검색 에이전트가 페이지 10개를 열람하면 관측만으로 수만 토큰이 쌓인다.
이 차이가 세 가지를 동시에 어렵게 만든다.
1. 컨텍스트 한계. 궤적 전체가 judge 자신의 context window 안에 들어가야 정확한 판정이 가능하다. 안 들어가면 요약·샘플링·잘라내기 중 하나를 선택해야 하는데, 그 선택 자체가 이미 판정을 왜곡하는 결정이다. 무엇을 잘라낼지 정하는 순간 그 판정은 “궤적 전체”가 아니라 “judge가 고른 부분”에 대한 판정이 된다. 비유하자면 이렇다 — 응답 judge를 채점하는 건 답안지 한 장을 읽고 점수를 매기는 일이지만, 궤적 judge를 채점하는 건 학생이 한 학기 동안 쓴 연습장 전부를 읽고 학점을 매기는 일에 가깝다. 시간이 없으면 결국 마지막 장(결론)이나 학생이 직접 쓴 자체 요약만 보고 학점을 매기게 되는데, 그 순간 “연습장 전체를 봤다”는 전제가 깨진다.
2. 어디를 보고 판정할지. 응답 judge는 “이 텍스트가 좋은가” 하나만 보면 된다. 궤적 judge는 “이 시퀀스의 어느 지점이 결정적이었는가”를 봐야 한다. 최종 상태 하나로는 안 보이는 축들이 있다 — 부작용을 일으켰는가, 불필요하게 반복했는가, 효율적으로 도달했는가.
3. 부분 성공의 표현. 환경검증(#9)은 이진(0/1) 판정이 많다. 파일이 있거나 없거나다. 하지만 궤적은 “80% 왔는데 마지막에 삐끗”처럼 연속적인 실패가 흔하다. 이걸 스칼라 하나로 뭉개면 어디서 궤적이 틀어졌는지에 대한 신호가 사라진다.
이 어려움이 추상적 주장이 아니라는 걸 실측한 벤치마크가 있다. AgentRewardBench (Lù et al., arXiv 2025)는 웹 에이전트 궤적 1,302개(5개 벤치마크 × 4개 대상 모델)를 전문가가 직접 리뷰하며 세 가지 질문에 답하게 했다 — 성공(success)했는가, 부작용(side effect)을 일으켰는가, 불필요하게 반복(repetitiveness)했는가. 이 세 축에 대해 12개 LLM judge를 평가한 결과, 모든 벤치마크에서 고르게 우수한 judge는 하나도 없었다. 더 눈에 띄는 발견은 따로 있다 — 기존에 표준으로 쓰이던 룰 기반 평가(=#9식 환경검증)가 실제 성공률을 체계적으로 과소 보고(underreport)한다는 것이다. 즉 환경검증이 “성공을 성공으로 인정하지 못하는” 방향으로 이미 틀리고 있다는 걸 사람 리뷰와의 비교로 보여준 셈이다. 이게 이번 편이 필요한 이유의 실증적 근거다.
같은 결론이 다른 도메인에서도 되풀이된다. MobileJudgeBench (arXiv 2026, 2608.11434)는 모바일 에이전트 궤적 931개(6개 벤치마크, 4개 에이전트 모델, 68개 앱)를 사람이 주석한 뒤 6개 judge 방법론을 비교했다. 두 가지가 눈에 띈다 — 하나는 스크린샷을 몇 장 샘플링하는 단순한 baseline judge가 정교하게 설계된 전용 판정 파이프라인과 견줄 만하거나 오히려 능가했다는 점(즉 파이프라인을 복잡하게 짜는 것보다 judge의 backbone 모델 자체가 품질을 좌우한다), 다른 하나는 벤치마크 품질 지표가 실제 활용도와 상관돼 있다는 점이다 — judge를 on-policy RL의 reward 신호로 썼을 때의 다운스트림 성능까지 예측할 수 있었다. 웹 도메인(AgentRewardBench)과 모바일 도메인(MobileJudgeBench)에서 독립적으로 같은 그림이 나온다는 건, “궤적 judge는 균일하게 잘하지 못한다”는 문제가 특정 도메인의 우연이 아니라는 뜻이다.
rubric 기반 채점이 궤적으로 확장될 때 무엇이 달라지는가
RLHF 시리즈의 Rubrics as Rewards와 Prometheus 2는 응답 하나에 rubric을 적용하는 방법을 다뤘다(재서술은 링크로 대신한다). 여기서는 그게 궤적으로 확장될 때 새로 생기는 설계 축만 짚는다.
응답 하나에 rubric을 적용하는 건 “결과물 채점”이다. 궤적에 적용하면 최소 세 가지 축이 새로 열린다.
- 언제 채점하나 — 끝에서 한 번(outcome-level) 대 매 턴·트랜지션마다(process-level).
- rubric을 누가 만드나 — 사람이 태스크별로 미리 써두는 고정 rubric 대 judge가 궤적을 보고 그 자리에서 생성하는 생성형 rubric.
- 부분 진행을 어떻게 반영하나 — 최종 점수 하나 대 트랜지션마다 누적되는 보상.
이 세 축의 조합 하나를 구체적으로 보여주는 최근 논문이 TRCA(Transition-wise Rubric Credit Assignment, arXiv 2026, 2608.16156)다. 이 논문은 매 트랜지션 — 행동 하나가 만든 환경 상태 변화 — 마다 세 개의 rubric으로 채점한다.
- Evidence: 이 트랜지션이 문제 해결에 쓸 새 정보를 얻었는가.
- Execution: 유효한 실행이었는가.
- Invalidity: 무효하거나 퇴행적인 행동인가.
이 판정에서 두 종류의 보상을 만든다. Foundational Rubric Reward는 그 트랜지션 자체의 지역적 품질이고, Breakthrough Rubric Reward는 “이전 트랜지션들에서 아직 충족되지 않았던 Evidence·Execution 조건을 새로 충족했는가”를 추적한다. 후자가 핵심이다 — 이미 충족한 조건을 반복해서 채워봐야 추가 보상이 없으므로, 같은 행동을 반복하는 궤적에는 자연스럽게 페널티가 걸린다. 학습된 평가자나 “성공한 궤적을 앵커로 삼는” 기존 방식 없이, 트랜지션 자체의 rubric 판정만으로 credit을 만든다는 게 요지다. ALFWorld, WebShop, 검색 기반 QA 7종에서 검증했고, Qwen2.5-7B-Instruct 기준 WebShop 점수가 6.0~12.6%p, Qwen2.5-3B-Instruct 기준 검색 QA 평균 점수가 1.9~18.3%p 개선됐다. 저자들은 특히 초기 RL 구간 — 성공 궤적이 희귀해 앵커 기반 방법이 힘을 못 쓰는 구간 — 에서 이 방식이 유효하다는 점을 강조한다.
구체적인 숫자로 두 보상의 차이를 따라가 보자. 다음은 TRCA의 아이디어를 설명하기 위해 이 글이 구성한 예시이며, 원문의 실제 산식이나 스케일이 아니다. 궤적이 5개의 트랜지션으로 이뤄져 있고, 이 태스크에서 필요한 Evidence 조건이 A·B·C 세 가지라고 하자.
| 트랜지션 | 실제로 벌어진 일 | Foundational Reward | Breakthrough Reward |
|---|---|---|---|
| 1 | 조건 A를 처음 충족 | +1 (유효한 실행) | +1 (A 최초 충족) |
| 2 | 무효한 행동(존재하지 않는 API 호출) | −1 (Invalidity) | 0 |
| 3 | 조건 A를 다시 확인만 함 | +1 (유효한 실행) | 0 (A는 이미 충족됨) |
| 4 | 조건 B를 처음 충족 | +1 (유효한 실행) | +1 (B 최초 충족) |
| 5 | 조건 A·B·C를 한 번에 정리, 그중 C가 신규 | +1 (유효한 실행) | +1 (C만 신규) |
트랜지션 3이 핵심이다. Foundational Reward는 여전히 양수다 — 유효한 실행이었으니까. 하지만 Breakthrough Reward는 0이다 — 이미 아는 걸 다시 확인했을 뿐 태스크를 진전시키지 않았기 때문이다. 이게 앞서 말한 “반복 행동에 자연스러운 페널티가 걸린다”는 설명의 구체적인 형태다. 트랜지션 하나만 보면 “유효한 실행”이라 나쁘지 않아 보이지만, 궤적 전체에서 보면 “이미 아는 걸 다시 확인하느라 스텝 하나를 낭비했다”는 게 Breakthrough Reward의 0이라는 값에 담긴다 — outcome-level 채점 하나로는 절대 볼 수 없는 정보다.
이게 왜 중요한지는 비교하면 분명해진다. outcome-level rubric은 #9의 환경검증과 크게 다르지 않다 — 끝에 한 번 채점하는 건 매한가지고, 채점 함수가 규칙 대신 judge라는 차이만 있다. 궤적 judge가 진짜 다른 도구가 되는 지점은 판정을 트랜지션 단위로 쪼갤 수 있다는 것이다. 그리고 그 대가는 뒤에서 계산하는 비용이다 — 판정 횟수가 트랜지션 수만큼 늘어난다.
Method
Kimi K3의 Agentic GRM — judge가 스스로 rubric을 만든다
Kimi K3 tech report(Kimi Team, arXiv 2607.24653, “K3 tech report”)는 2.8T 파라미터 MoE(활성 파라미터 104B), 1M 토큰 컨텍스트, Kimi Delta Attention 기반 모델이다. Post-training RL을 세 도메인으로 나눈다 — general tasks, general agents(장기 지평 assistant 작업, deep research, 문단 단위 글쓰기), coding agents. 이 중 general agents 도메인이 이번 글의 표적이다. 검증 가능한 정답이 없는 영역이기 때문이다.
원문의 해당 문단을 옮기면 이렇다.
“검증 불가능한(non-verifiable) 일반 태스크에 대해 우리는 Agentic Generative Reward Model(GRM)을 채택한다. 이는 Kimi K2/K2.5에서와 같이 tournament 방식의 binary comparison 그룹 보상을 유지한다. 향상된 판단을 위한 일반적 agentic 능력을 넘어, 이 agentic judge는 다음의 의무 프로토콜을 따라야 한다: (1) 결과물·산출물·텍스트 출력을 읽는다 (2) rubric을 생성한다 (3) 각 후보를 그 rubric에 대해 채점한다 (4) rubric이 매긴 점수를 scorepad에 기록한다.”
이 프로토콜을 순서대로 풀면 다음과 같다.
- 읽는다 — 판정 대상(결과물·산출물·텍스트 출력)을 입력받는다.
- rubric을 생성한다 — 판정 대상에 맞춰 채점 기준을 그 자리에서 만든다. 사람이 미리 써둔 고정 rubric이 아니다.
- 채점한다 — 생성한 rubric에 각 후보를 대조해 점수를 매긴다.
- scorepad에 기록한다 — rubric과 점수를 하나의 기록으로 남긴다.
세 가지가 눈에 띈다.
첫째, binary tournament. 절대 점수를 매기지 않고 후보끼리 짝을 지어 이긴 쪽만 표시한다. GRPO 그룹 내 후보들의 상대 서열만 있으면 되므로, judge마다 “5점”과 “8점”의 기준이 다른 절대 스케일 문제를 피해간다. 심사위원 한 명이 참가자 8명 각각에게 절대 점수를 매기는 대회보다, 8명을 토너먼트 대진표에 넣어 옆 사람과 번갈아 겨루게 하는 쪽이 “누가 더 잘했나”를 훨씬 안정적으로 가려낸다는 것과 같은 이치다. 대신 대진표를 짜려면 대회 규모(그룹 크기)가 커질수록 경기 수가 조합적으로 늘어난다 — 뒤에서 이 비용을 정확히 계산한다.
둘째, rubric을 미리 정해두지 않는다. judge가 “이 결과물을 무슨 기준으로 평가해야 하는가”를 스스로 정하고 그다음 채점한다. Rubrics as Rewards 같은 고정 rubric 방식과 달리 태스크 다양성에 매번 대응할 수 있다. 대신 “judge가 스스로 만든 기준으로 스스로 채점”하는 순환 구조가 생긴다 — 기준 자체가 느슨해지거나 장황해지는 쪽으로 흐를 위험이 있다.
셋째, “the outcome, product, or text output”이라는 표현. 이 judge가 정확히 무엇을 입력으로 받는지가 원문에 세 단어로만 나와 있다 — 결과물(outcome), 산출물(product), 텍스트 출력(text output). 이건 (사고, 행동, 관측)의 원시 로그 전체라기보다 최종 산출물에 가깝게 읽힌다. general agents 도메인의 산출물(deep research 보고서, 장문 assistant 응답, 문단 단위 글쓰기 결과)이 대개 “텍스트 결과물” 형태이므로 이 표현 자체는 자연스럽다. 다만 이건 원문이 명시적으로 주장하는 바가 아니라 이 글의 해석인데 — 뒤에서 다룰 “판정자가 결말만 보고 판단하면 정책은 결말만 그럴듯하게 쓰는 법을 배운다”는 취약점과 정확히 같은 모양이라는 점은 짚어둘 만하다.
원문에는 한 가지 표현이 더 있다 — “향상된 판단을 위한 일반적 agentic 능력을 넘어(beyond generic agentic capabilities for enhanced judgment)”라는 구절이다. 이건 이 judge가 판정 도중 도구를 쓴다는 뜻으로 읽히지는 않는다(원문이 그렇게 명시하지 않는다). 오히려 judge 자체가 agentic RL로 학습된 모델이라는 전제를 깔고 있는 것에 가깝다 — 즉 정책과 judge가 같은 계보의 모델이고, 그 judge가 이미 장기 지평 태스크를 스스로 수행해본 경험이 있다는 뜻이다. 이게 왜 궤적 판정에 유리할 수 있는지는 직관적이다 — 궤적을 판정하려면 “이 스텝에서 이 선택이 왜 합리적이었는지”를 이해해야 하는데, 그 이해는 판정자 자신이 비슷한 도구·환경에서 행동해본 경험과 무관하지 않다. 다만 이 인과관계를 K3 원문이 직접 검증하지는 않는다는 점은 분명히 해둔다 — 여기서는 해석일 뿐이다.
간접적인 정황 증거는 있다. K3의 평가 스위트에는 딥리서치 산출물을 rubric으로 채점하는 ResearchRubrics 벤치마크가 포함돼 있는데, K3는 여기서 76.2점을 받아 비교 대상 모델 중 가장 높았다(원문 Table, arXiv 2607.24653). 이 벤치마크 자체가 Agentic GRM 학습의 산물이라고 확언할 수는 없지만 — 학습에 쓰인 judge와 평가에 쓰인 judge가 같다는 보장도 없다 — 적어도 “rubric 기반 채점을 훈련 신호로 쓴 모델이 rubric 기반 평가에서도 강하다”는 방향의 일관성은 확인된다.
이 rubric 순환 구조가 만드는 위험(장황함을 보상하는 방향으로 흐르는 것)에 대해 K3는 명시적 방어 장치를 둔다. verbosity budget control이다 — reasoning-effort RL에 쓰는 것과 같은 방식으로, cold-start 모델에서 추정한 초기 verbosity \(\ell_0\)과 배수 \(\sigma\)를 두고, 출력 길이가 \(\sigma \cdot \ell_0\)를 넘는 후보는 자동으로 tournament에서 패배 처리한다. reward hacking을 사후에 벌하는 대신, 애초에 그 경로로는 이길 수 없게 만드는 방식이다.
RLHF 시리즈 프론티어 편이 이 GRM을 “reward 설계 계보”(스칼라 RM을 GRM이 대체해가는 흐름) 관점에서 다뤘다면, 여기서는 판정 대상이 원시 궤적이 아니라 산출물에 수렴한다는, 궤적 판정 특유의 트레이드오프로 본다는 점이 다르다.
두 rubric 확장 방식의 대차대조
Kimi K3(생성형, outcome-level)와 TRCA(고정 카테고리, transition-level)는 같은 “rubric을 궤적에 적용한다”는 목표를 정반대 축에서 풀었다.
| 항목 | 고정 rubric (예: Rubrics as Rewards) | 생성형 rubric (Kimi K3 Agentic GRM) | 트랜지션 rubric (TRCA) |
|---|---|---|---|
| 채점 시점 | 끝에서 한 번 | 끝에서 한 번(산출물 단위) | 매 트랜지션마다 |
| rubric 출처 | 사람이 태스크별로 사전 정의 | judge가 판정 대상을 보고 즉석 생성 | 3개 고정 카테고리(Evidence/Execution/Invalidity) |
| 판정 빈도 | 궤적당 1회 | 궤적당 1회(후보 간 pairwise) | 궤적당 트랜지션 수만큼 |
| 강점 | 재현 가능, judge 편향에 덜 민감 | 태스크 다양성에 자동 대응 | 초기 RL(성공 궤적 희귀 구간)에서도 dense 신호 |
| 위험 | 새 태스크마다 rubric 재작성 필요 | 기준 자체가 판정마다 달라질 수 있음 | 카테고리가 못 잡는 실패 유형은 여전히 놓침 |
세 방식 모두 “판정 1건의 비용”이 다르다는 점을 기억해두자. 다음 절에서 정확히 계산한다.
Experiments
판정 비용 계산
다음 계산은 확인된 벤치마크 수치가 아니라 예시 가정에 기반한 어림값이다. 목적은 정확한 비용 예측이 아니라 “궤적이 길어질수록 판정 비용이 정책 학습 비용을 구조적으로 앞지른다”는 방향성을 보이는 것이다.
가정
- 궤적 평균 스텝 수 \(T = 30\), 스텝당 평균 토큰(사고+행동+관측) \(\approx 800\) → 궤적 길이 \(L_{traj} \approx 24{,}000\) 토큰 (시나리오 A, “보통 궤적”)
- 딥리서치·장문 코딩 등 극단적으로 긴 궤적: \(L_{traj} = 100{,}000\) 토큰 (시나리오 B)
- judge 오버헤드: rubric 생성 \(L_{rubric} \approx 300\), 후보별 점수·근거 \(L_{score} \approx 500\) → 판정 1건당 오버헤드 800 토큰
- RL 배치: 스텝당 프롬프트 수 \(N=64\), 그룹 크기 \(K=8\)
- 정책이 실제로 생성하는 토큰(사고+행동만, 관측은 환경이 주므로 제외): 시나리오 A는 궤적당 \(9{,}000\) 토큰(스텝당 300), 시나리오 B는 같은 관측:생성 비율을 유지한다고 가정해 궤적당 \(37{,}500\) 토큰
판정 1건의 비용(pointwise, 후보 하나를 그대로 채점)은 다음과 같다.
\[C_{point} = N \times K \times (L_{traj} + L_{rubric} + L_{score})\]여기서 각 기호는 앞서 정의한 대로다. 이 식을 \(L_{traj}\)로 미분하면 \(\partial C_{point} / \partial L_{traj} = NK > 0\) — 판정 비용은 궤적 길이에 (이 단순화된 토큰 카운트 모델에서) 선형으로 비례한다. 다만 이는 하한에 가깝다. 실제 prefill 연산량은 attention 때문에 시퀀스 길이에 대해 초선형(superlinear)으로 늘어날 수 있어, 토큰 수만 세는 이 모델은 실제 비용을 과소평가할 가능성이 높다.
Kimi K3처럼 binary tournament를 쓰면 후보 하나씩 채점하는 대신 그룹 내 모든 쌍을 비교해야 한다. 그룹 크기 \(K\)일 때 쌍의 수는 \(\binom{K}{2} = K(K-1)/2\)이므로,
\[C_{tour} = N \times \binom{K}{2} \times (L_{traj} + L_{rubric} + L_{score}) = \frac{K-1}{2} \times C_{point}\]\(K=8\)이면 \((K-1)/2 = 3.5\)다. 즉 tournament 방식은 pointwise보다 3.5배 더 많은 토큰을 판정에 쓴다 — 그룹 크기를 키워 advantage 추정의 분산을 줄이려 할수록(GRPO 계열의 표준적인 선택) tournament 판정 비용은 제곱으로 커진다는 뜻이다.
이 값들을 시나리오 A·B에 대입하면 다음 표가 나온다.
| 시나리오 | \(L_{traj}\) | 판정 1건 토큰 | Pointwise judge/step | Tournament judge/step(\(K{=}8\)) | 정책 생성/step | Pointwise 비율 | Tournament 비율 |
|---|---|---|---|---|---|---|---|
| A (보통 궤적) | 24,000 | 24,800 | 약 12.7M | 약 44.4M | 약 4.6M | 약 2.76배 | 약 9.65배 |
| B (긴 궤적, 10만 토큰) | 100,000 | 100,800 | 약 51.6M | 약 180.6M | 약 19.2M | 약 2.69배 | 약 9.41배 |
두 시나리오에서 비율이 거의 같게 나오는 이유는 구조적이다. judge는 관측을 포함한 궤적 전체를 읽어야 하지만, 정책 학습(그래디언트)의 대상은 정책이 직접 생성한 토큰(사고+행동)뿐이다. 관측이 궤적의 대부분을 차지하는 한, 판정 비용은 궤적 길이와 무관하게 정책 학습 비용을 일정 배수만큼 앞지른다. 여기 가정에서는 그 배수가 pointwise로 약 2.7배, tournament로는 약 9.4~9.6배다. 1,000 스텝을 학습한다고 하면 시나리오 B·tournament 조합만으로 판정에 쓰이는 토큰 누적량이 약 1,800억 토큰에 이른다 — 정책이 실제로 생성해 학습 대상이 되는 토큰(약 192억)의 9배가 넘는 양을, reward 계산 하나에 쓰는 셈이다.
토이 예제: 같은 결과, 다른 궤적
태스크: “고객 A의 최근 주문을 취소하라.”
(a) 짧고 정확한 궤적 — 3스텝으로 끝난다.
| 스텝 | 행동 | 관측 |
|---|---|---|
| 1 | 고객 A의 최근 주문 ID를 조회 | 주문 ID #1042 확인 |
| 2 | #1042에 취소 API 호출 | 200 OK, 상태 cancelled |
| 3 | 주문 상태를 재조회해 확인 | cancelled 확인, 종료 |
(b) 길게 헤매다 우연히 성공한 궤적 — 14스텝을 거친다. 네 국면으로 나눠보면 흐름이 뚜렷하다.
| 국면 | 스텝 | 행동 | 관측 |
|---|---|---|---|
| 엔드포인트 탐색 실패 | 1~4 | 존재하지 않거나 잘못된 취소 엔드포인트를 순서대로 시도 | 404, 405 등 반복 |
| 부작용 발생 | 5~7 | 파라미터를 잘못 넣어 고객 B의 주문을 오취소, 뒤늦게 알아채고 되돌림 | 200 OK(오취소) → 되돌리기 성공 |
| 재시도·오타 | 8~11 | 올바른 엔드포인트를 찾았지만 파라미터 이름을 계속 틀림 | 400 Bad Request 반복 |
| 최종 성공 | 12~14 | 파라미터를 바로잡아 #1042에 취소 호출, 재조회로 확인 | 200 OK, cancelled 확인, 종료 |
최종 상태는 (a)와 동일하게 “고객 A의 주문이 취소됨”이다. 하지만 5~7 국면에서 벌어진 일 — 무관한 고객 B의 주문을 건드린 것 — 은 최종 상태만 봐서는 전혀 드러나지 않는다.
세 채점 방식이 이 둘을 어떻게 다루는지 비교한다.
| 채점 방식 | (a) 짧고 정확 | (b) 길게 헤매다 성공 | 구분 가능한가 |
|---|---|---|---|
| 환경검증(#9, 최종 상태만) | 1점 | 1점 | 불가능 — 최종 DB 상태가 같다 |
| 도구채점(#10, 마지막 호출만 검사) | 통과 | 통과 | 대개 불가능 — 마지막 호출의 스키마·인자만 보면 중간 과정이 안 보인다 |
| rubric judge(궤적 전체를 읽음) | 고득점 | 저득점 | 가능 |
rubric judge가 궤적 (a), (b)를 보고 스스로 생성할 법한 rubric의 예:
- 첫 시도에서 올바른 엔드포인트를 선택했는가.
- 되돌릴 수 없는 부작용(타 고객 주문 오취소 같은)을 일으켰는가.
- 불필요한 재시도가 몇 차례였는가.
- 최종 결과가 사용자 의도와 일치하는가.
(a)는 1~4 모두 만점에 가깝다. (b)는 4번은 만점이지만 2번에서 크게 감점된다 — 되돌렸다 해도 실제로 다른 고객의 주문이 취소됐다 되돌아온 사건 자체는 사라지지 않는다. 3번(재시도 횟수)에서도 감점된다.
이 결과가 임의로 지어낸 게 아니라는 점이 중요하다. 위에서 인용한 AgentRewardBench가 실측한 세 축 — success, side effects, repetitiveness — 이 이 토이 예제의 rubric 1~4와 정확히 대응한다. 환경검증과 얕은 도구채점은 success 축만 본다(혹은 검사 범위를 크게 늘려야 나머지를 본다). rubric judge는 세 축을 하나의 자연어 판정 안에 자연스럽게 담을 수 있다 — 그 대신 비용은 위 표에서 계산한 대로 궤적 전체를 읽는 만큼 든다.
판정자도 뚫린다
One Token to Fool은 응답 judge가 “물론이죠” 같은 상투적 토큰 하나만으로 점수가 뒤집힐 수 있음을 보였다. 텍스트 하나짜리 판정도 이 정도로 취약하다면, 궤적 judge는 구조적으로 더 취약하다. 이유는 단순하다 — 판정자가 컨텍스트 한계나 비용 한계 때문에 궤적 전체를 다 읽지 못하면, 결국 요약이나 궤적의 결말에 의존하게 된다. 위에서 짚은 Kimi K3의 “read the outcome, product, or text output”이라는 표현 자체가 이미 이 구조를 내포한다.
Confident Closing to Silent Failure (Advani, FAGEN Workshop @ ICML 2026, arXiv 2606.09863)가 정확히 이 실패 모드를 측정했다. 에이전트가 환경 상태와 무관하게 “작업 완료”를 자신 있게 선언하는 것을 false success라 부른다. tau2-bench(9,876개 궤적, 8개 모델군)의 단일 제어(single-control) 도메인에서는 실패의 45~48%가 false success였다. 반면 제어권이 사람과 나뉘는 이중 제어(dual-control) 통신 도메인에서는 이 비율이 3%로 줄었다 — 제어권을 공유하면 거짓 완료 선언이 통하기 어려워진다는 뜻이다. AppWorld(1,879개 궤적, 4개 모델군)에서 명시적으로 상태를 주장하는 코딩 에이전트 궤적 중에서는 75.8%가 false success였다. 그리고 judge는 이걸 잘 잡지 못한다 — 5개 judge × 5개 프롬프트 전략(전체 태스크 명세 포함)을 다 시도해도 tau2-bench에서 AUROC 0.65를 넘지 못했고, AppWorld에서는 0.54에 그쳤다. 거의 동전 던지기 수준이다. 원인은 명확하다. judge가 “확신에 찬 종결 언어(confident closing language)”(tau2-bench)와 “대강의 행동-시퀀스 분량”(AppWorld)이라는 표면적 완료 신호에 의존하기 때문이다. 대조적으로 가벼운 TF-IDF 탐지기는 같은 조건에서 task-disjoint AUROC 0.83(tau2-bench)/0.95(AppWorld)를 내며, 같은 플래그율에서 judge보다 4~8배 많은 false success를 잡아내고 지연시간은 3,300배 낮았다.
이게 브리프가 걱정한 그림 그대로다 — 판정자가 결말에 의존하면, 정책은 결말을 그럴듯하게 쓰는 법을 학습한다. 정책이 이걸 명시적으로 배우지 않아도, RL의 그래디언트는 “reward가 결말의 자신감과 조금이라도 상관돼 있다”는 사실을 스스로 찾아낸다.
Gaming the Judge (Khalifa et al., arXiv 2026, 2601.14691)는 한 걸음 더 나아가 능동적 조작을 보인다. 행동과 관측은 그대로 두고 CoT(추론 흔적)만 다시 쓰는 방식으로, 800개의 다양한 웹 태스크 궤적에 대해 최신 VLM judge들의 오탐률(false positive rate)을 최대 90%까지 끌어올렸다. 문체만 바꾸는 조작(더 자신감 있게 쓰기)보다 내용 자체를 조작하는 방식(진행 신호를 날조)이 일관되게 더 효과적이었다 — judge가 “그럴듯한 진행 서술”과 실제 진행을 구분하지 못한다는 뜻이다. 프롬프트를 정교화하거나 judge-time compute를 늘려도 취약성은 줄어들 뿐 사라지지 않았다.
두 논문을 겹쳐보면 궤적 judge의 취약성이 응답 judge의 취약성과 종류가 다르다는 게 분명해진다. 응답 judge는 “이 텍스트가 매력적으로 보이는가”에서 뚫린다. 궤적 judge는 “이 긴 실행 과정이 성공적으로 보이는가”에서 뚫리는데, 이건 판정자가 실제로 전체를 검증할 시간과 예산이 없다는 구조적 제약과 직결돼 있어서 더 근본적이다. 판정 비용이 궤적 길이에 비례해 커진다는 앞 절의 계산과 이 취약성은 같은 원인의 양면이다 — 예산이 없어서 결말에 의존하고, 결말에 의존하니까 뚫린다.
이 취약점을 완전히 없앨 수는 없지만, 비용과 취약성 각각을 줄이려는 시도는 있다. Share the Judge, Learn the Deferral (arXiv 2026, 2607.27984)은 값싼 judge로 먼저 거르고 확신이 낮은 사례만 비싼 judge에 넘기는 deferral cascade를 제안한다. RewardBench 2에서 이 방식은 전체 계산량의 41.5%만 쓰고도 정확도 89.40%를 냈다 — 8B judge 단독(84.75%)보다 높다. E-valuator (arXiv 2025, 2512.03109)는 판정을 순차 가설 검정(sequential hypothesis testing)으로 바꿔, 궤적을 끝까지 읽지 않고도 통계적으로 유효하게 조기 종료할 수 있음을 보였다 — 문제적 궤적을 일찍 끊어 토큰을 아끼는 방향이다. 비슷한 결을 가진 AgentForesight (arXiv 2026, 2605.08715)는 궤적이 끝나길 기다리지 않고, 진행 중인 접두(prefix)만 보고 “지금 결정적 오류가 났는가”를 온라인으로 판단하는 auditor를 학습시켜, 외부 벤치마크(Who&When)에서 기존 방법 대비 최대 +19.9%p 성능 향상과 3배 낮은 스텝 국소화 오차를 보였다. 궤적 전체를 다 읽어야 한다는 전제 자체를 깨는 방향이라는 점에서 위 두 방법과 궤를 같이한다. 다만 이 셋 모두 응답 단위 벤치마크나 일반적 검증기 설정, 혹은 별도로 큐레이션된 실패 탐지 코퍼스에서 나온 결과이며, Kimi K3류 궤적 judge에 그대로 적용된다고 확인된 건 아니다. 그리고 두 방법 모두 비용 문제에 대한 답이지, 판정이 뚫린다는 문제에 대한 답은 아니라는 점을 구분해야 한다 — 판정을 더 싸게, 더 일찍 끝내는 것과 판정이 조작에 강해지는 것은 다른 문제다.
언제 무엇을 쓰나 — 실무 체크리스트
지금까지 다룬 방법들을 상황별로 정리하면 다음과 같다. 어느 하나가 정답이 아니라, 궤적 길이·태스크 다양성·예산·RL 단계에 따라 조합이 달라진다.
| 상황 | 권장 조합 | 근거 |
|---|---|---|
| 궤적이 짧고(예: 20스텝 미만) 태스크가 균일 | outcome-level 고정 rubric + 도구채점(#10) 병행 | 판정 비용이 크지 않고, 고정 rubric이 재현성을 준다 |
| 궤적이 매우 길거나(50스텝 이상) 태스크가 다양 | 생성형 rubric(Kimi K3 방식) | 태스크마다 rubric을 새로 쓸 필요가 없다. 대신 verbosity 통제가 필수다 |
| 성공 궤적이 희귀한 초기 RL 구간 | 트랜지션 rubric(TRCA류) | 앵커(성공 궤적) 없이도 dense한 신호를 만든다 |
| judge 예산이 빠듯함 | pointwise 채점 + deferral cascade, 조기 종료(E-valuator·AgentForesight류) | 그룹 크기를 키울수록 tournament 비용이 제곱으로 늘어난다는 걸 앞서 계산했다 |
| 에이전트가 자기 완료를 선언하는 게 흔한 도메인(고객지원·업무 자동화 등) | judge와 별도로 confident-closing 탐지기(TF-IDF 등 경량 분류기) 병행 | Confident Closing to Silent Failure가 보인 것처럼 judge 단독으로는 AUROC 0.5~0.65 수준에 머문다 |
마지막 행이 특히 중요하다. 이 시리즈가 지금까지 강조한 원칙 — “reward는 한 조달처에만 의존하지 않는다” — 이 judge 안에서도 반복된다. judge 하나에 전부를 맡기는 대신, 값싸고 판정이 좁은 신호(TF-IDF 탐지기, 규칙 기반 조기 종료)를 judge와 나란히 두면 서로의 약점을 메운다.
통계 요약 — 3부를 닫는 종합표
지금까지 세 편에 걸쳐 본 것은 결국 “reward를 어디서 조달하는가”에 대한 세 가지 답이다.
| 조달처 | 무엇을 검증하나 | 신호 형태 | 무엇을 못 잡나 | 비용 특성 | 대표 취약점 |
|---|---|---|---|---|---|
| 환경(#9) | 최종 상태(파일·DB·API 응답) | 이진 0/1, 스텝별로 확장 가능 | 과정 품질, 부작용, 효율 | 낮음(시뮬레이터 재실행 수준) | 검증기 자체가 느슨하면 통과 |
| 도구(#10) | 개별 호출의 스키마·인자·부작용 | 스텝 단위, 세밀 | 전체 궤적이 왜 이 경로를 택했는가 | 낮음(정적 검사 수준) | 스키마만 맞추고 의미 없는 호출 반복 |
| judge/rubric(#11) | 산출물·궤적의 품질, 부작용, 반복 | 연속 점수 또는 tournament 서열, rubric을 judge가 정의 | 판정자가 못 읽은 부분(컨텍스트 밖) | 매우 높음(궤적 길이에 비례, 위 계산) | confident closing·CoT 조작에 취약 |
세 조달처는 서로 배타적이지 않다. 오히려 실전에서는 섞어 쓴다. 이어지는 4부(#12~#14)에서 도메인마다 이 배합이 어떻게 달라지는지를 본다 — 검색 에이전트는 근거 인용의 품질을 판정에 맡기는 비중이 크고, 코드 에이전트는 테스트 스위트(환경검증의 강력한 형태)에 크게 의존하되 설계·스타일 판단만 judge에 맡기고, 웹·GUI 에이전트는 이번 편의 토이 예제와 같은 부작용·비효율 문제가 특히 두드러진다. 각 편에서 그 구체적인 배합을 다룬다.
Conclusion
궤적 judge는 응답 judge보다 강력하다 — 산출물과 과정, 부작용까지 하나의 자연어 판정에 담을 수 있다. Kimi K3의 Agentic GRM은 rubric조차 고정하지 않고 판정 대상에 맞춰 그때그때 생성하며, TRCA는 그 판정을 트랜지션 단위로 쪼개 초기 RL 구간에서도 dense한 신호를 만든다.
하지만 대가가 있다. 판정 비용은 궤적 길이에 비례해 커지고(이 글의 어림값으로는 정책 학습 비용의 약 2.7~9.6배), tournament 방식을 쓰면 그룹 크기의 제곱에 비례해 더 커진다. 그리고 판정자가 이 비용을 감당하지 못해 궤적의 결말에 의존하는 순간, 정책은 그 결말을 조작하는 법을 배운다 — Confident Closing to Silent Failure가 보인 도메인별 45~48%(tau2-bench 단일 제어)에서 75.8%(AppWorld)에 이르는 false success 비율과, Gaming the Judge가 보인 최대 90%의 오탐률 상승이 이걸 실측으로 증명한다.
이 글의 비용 계산은 확인된 벤치마크 수치가 아니라 예시 가정 기반의 어림값이라는 한계가 있다. 또한 confident closing·CoT 조작 연구는 대부분 웹·앱 도메인에서 이뤄졌다 — 코드나 검색처럼 다른 도메인에도 같은 정도로 일반화되는지는 이어지는 편에서 다시 봐야 할 질문이다.
3부(#9~#11)를 한 줄로 요약하면: reward는 환경에서, 도구에서, 그리고 judge에서 온다. 각각 무엇을 검증하고 무엇을 놓치는지가 다르며, 그 놓치는 지점이 곧 다음 취약점이다. #15는 이 세 조달처 각각의 놓치는 지점을 정책이 어떻게 찾아내는지를 정리한다.
참고 문헌
- Lù et al., 2025. AgentRewardBench: Evaluating Automatic Evaluations of Web Agent Trajectories.
- Wang et al., 2026. Benchmarking LLM Judges for Mobile Agent Evaluation.
- Kimi Team, 2026. Kimi K3: Open Frontier Intelligence (K3 tech report). GitHub: MoonshotAI/Kimi-K3.
- Huan Zhang et al., 2026. TRCA: Transition-wise Rubric Credit Assignment for Long-horizon LLM Agents.
- Advani, 2026. From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents. (FAGEN Workshop @ ICML 2026)
- Khalifa et al., 2026. Gaming the Judge: Unfaithful Chain-of-Thought Can Undermine Agent Evaluation.
- Chen and Zhang, 2026. Share the Judge, Learn the Deferral: Where Specialization Helps LLM Evaluation.
- Sadhuka et al., 2025. E-valuator: Reliable Agent Verifiers with Sequential Hypothesis Testing.
- Boxuan Zhang et al., 2026. AgentForesight: Online Auditing for Early Failure Prediction in Multi-Agent Systems.
- RLHF Reward 설계 시리즈. reward 4분류, 프론티어 편, Rubrics as Rewards, Prometheus 2, One Token to Fool.
Agentic RL 설계 시리즈
이 글은 Agentic RL 설계 시리즈의 열한 번째 글이다.
1부. 왜 에이전트는 다른가
- 에이전트 RL은 무엇이 다른가 — 장기 지평·희소 보상·긴 궤적
- 공을 어디에 돌릴 것인가 — credit assignment 47개 방법의 지도
- 멀티턴 RL 실무 가이드 — 무엇이 실제로 작동하는가
2부. credit assignment — 공을 어디에 돌릴 것인가
- 결과만으로는 부족하다 — 장기 지평에서 증폭되는 RLVR의 한계
- 턴 단위로 공을 나눈다 — turn-level reward 설계
- 스텝을 단위로 삼는다 — 행동 단위 궤적 표현과 credit
- 토큰과 세그먼트로 더 잘게 — 세밀한 입도의 득과 실
- shaping은 약인가 독인가 — 중간 보상의 효율과 위험
3부. reward를 어디서 얻나
- 환경이 곧 reward다 — 샌드박스·테스트·상태 검증
- 도구 호출을 어떻게 채점하나 — ToolRL·ToolRM
- (현재 글) 궤적을 judge가 채점한다 — rubric 생성형 reward의 확장
4부. 도메인별 설계
- 검색 에이전트 — Search-R1에서 DeepDive까지
- 코드 에이전트 — SWE-RL과 테스트라는 reward
- 웹·GUI 에이전트 — end-to-end 멀티턴 RL
5부. 실패와 방어
- 에이전트의 reward hacking — 판정기가 뚫린다, 그리고 조합의 실패
6부. 실전 종합
- 프론티어 모델은 실제로 어떻게 하나 — 최신 모델들의 agentic RL 설계
본 시리즈는 16편으로 구성된다.
Enjoy Reading This Article?
Here are some more articles you might like to read next: