03. Agent-as-Judge

한 줄: 평가하는 LLM에게 툴까지 쥐여줘서, 단순히 글을 읽고 채점하는 게 아니라 직접 검증·재현하면서 채점하게 만드는 방식.

비유: 02장 LLM-as-Judge가 “답안지를 읽고 채점하는 조교”라면, Agent-as-Judge는 “답안지를 보고 같은 문제를 다시 풀어보고 채점하는 조교”. DB를 직접 쿼리하거나 코드를 실행해서 진위를 검증한다.

이 문서에서 챙길 3가지

긴 trajectory(예: 50-step)나 코드/DB 같은 동적 검증이 필요한 평가는 LLM-as-Judge로 부족 → Agent-as-Judge가 등장
평가자도 에이전트라 같은 종류의 실패를 한다 — 회피책: 평가자 모델을 더 강하게, 또는 다중 평가자 합의
비용은 LLM-as-Judge의 5–20배 — 모든 trace에 못 쓰고 어려운 케이스 큐에만 적용

1. 정의

Agent-as-Judge는 평가자도 에이전트로 만들어, 평가 대상 에이전트의 trajectory를 능동적으로 조사·재현·검증하게 하는 평가 패턴이다. 2025년 후반부터 본격화된 흐름으로, LLM-as-Judge가 정적 텍스트를 보고 채점한다면 Agent-as-Judge는 동적으로 검증을 수행한다.

비유: LLM-as-Judge = 풀이를 읽고 채점하는 조교. Agent-as-Judge = 풀이를 다시 풀어보고 채점하는 조교.

2. 핵심 메커니즘

2.1 왜 필요한가

평가 대상 에이전트의 trajectory가 길어질수록 LLM-as-Judge는 약해진다.

50-step trajectory를 한 컨텍스트에 다 넣으면 토큰 폭발
중간 결과의 진위를 정적으로 판단 불가 (예: “DB에 X가 있다고 주장” — 진짜 있나?)
정책 위반 시점의 주변 상태를 능동 조사할 수 없음

Agent-as-Judge는 평가자에게 툴을 준다:

DB 쿼리 (대상 에이전트가 만든 상태 검증)
외부 API 호출 (대상이 보낸 요청을 추적)
코드 실행 (대상이 짠 코드를 직접 돌려봄)
다른 LLM 호출 (cross-check)

2.2 전형적 구조

sequenceDiagram
    participant Target as 대상 에이전트
    participant Env as 환경 (DB·API·FS)
    participant Judge as 평가 에이전트
    participant Report as 평가 보고서

    Target->>Env: trajectory (다단계 행동)
    Target-->>Judge: trajectory + 환경 스냅샷
    Judge->>Judge: 단계 1 — 요약·이상 신호 탐지
    Judge->>Env: 단계 2 — 의심 지점 능동 조사<br/>(DB 쿼리, API call, 코드 실행)
    Env-->>Judge: 실제 상태
    Judge->>Judge: 단계 3 — 가설 검증
    Judge->>Report: 단계 4 — 채점 + 증거 인용

이건 사실상 평가도 에이전트 태스크로 만든 것이다.

2.3 SWE-Bench 류에서의 활용

코드 에이전트 평가에 특히 강하다. 대상 에이전트가 패치를 제출하면, 평가 에이전트가:

패치 적용
테스트 실행
실패 시 왜 실패했는지 로그 분석
“테스트 의도와 다른 실패”인지 “단순 버그”인지 판별
점수 + 코멘트

이 절차 자체가 LLM 단일 호출로는 불가능. Agent-as-Judge가 자연스럽게 끼는 자리.

2.4 한계 — 평가자도 에이전트라 틀린다

Agent-as-Judge의 가장 큰 함정은 평가자도 에이전트라서 같은 종류의 실패를 한다는 점이다. 추론 오류, 환각, 툴 사용 오류. 평가자가 잘못 검증하면 잘못된 채점이 나간다.

회피책:

평가자 모델을 대상보다 강하게: 대상이 Claude Sonnet이면 평가자는 Claude Opus 같은 식. 단 비용 폭증.
다단계 검증: 평가자 1차 → 다른 평가자 검토 → 인간 spot check.
결정론적 검증을 가능한 한 많이 사용: 코드 실행, exact match, regex 등 LLM 호출 없는 검증을 우선.

3. 강점과 약점

강점	약점
긴 trajectory의 국소 검증 가능	비용 (평가자도 멀티 step 실행)
능동 조사 (정적 텍스트론 못 하는 검증)	평가자 자체 신뢰도 문제
환경과 상호작용 가능 (DB·API 직접 검증)	평가자 prompt injection 위협 (대상이 평가자를 속이려 trajectory에 instruction 박을 수 있음)
에이전트 평가의 자연스러운 추상화 — 평가도 한 종류의 task	디버깅 어려움 (평가자 trajectory도 trajectory)

4. 대안과의 비교

LLM-as-Judge vs Agent-as-Judge를 명확히 가르는 기준:

평가자에게 툴 호출 권한을 주면 → Agent-as-Judge
평가자가 단일 LLM call로 점수만 뱉으면 → LLM-as-Judge

스펙트럼이지 이분법은 아니다. “평가자가 한 번만 추가 검증 호출” 같은 중간 형태 多.

언제 어느 걸 쓰나:

상황	권장 평가자
짧은 응답 채점 (Q&A, 요약, 톤)	LLM-as-Judge
Tool-use trajectory의 정책 위반 boolean	LLM-as-Judge (충분)
코드 패치, DB 변경, 멀티 API 워크플로	Agent-as-Judge
환각·factuality 검증	Multi-model LLM-as-Judge 또는 Agent-as-Judge (web search)
비용 극도 민감 + 정확성 덜 중요	단일 LLM-as-Judge + 인간 spot check

5. 우리 실험에의 적용

본 실험에서 Agent-as-Judge가 유의미하게 들어갈 자리는 사실 좁다. 이유:

우리는 280건 정도의 작은 N. 평가자 비용이 본 비용을 넘으면 안 됨.
민지가 직접 결과를 받아쓰는 입장이라, 민지가 ground truth. 평가자 정확성보다 민지 채점이 우선.
우리 태스크 대부분은 텍스트 산출물 (공지, 메일, 회고) — Agent-as-Judge가 빛나는 코드/DB 도메인이 아님.

그럼 어디에?

후보 — Hermes의 학습 흔적 검증

H2 가설(“Hermes가 반복 학습으로 따라잡는다”)을 검증하려면, Hermes가 실제로 무엇을 학습했는지 봐야 한다. Hermes는 자체 메모리/스킬을 ~/.hermes/ 에 누적한다. 14일 후의 Hermes는 Day 0과 다른 시스템이다.

평가 에이전트(codex CLI)에게:

~/.hermes/skills/ 를 ls
새로 생성된 스킬 파일을 읽고 무엇을 자동화한 것인지 요약
T1–T10 중 어느 태스크에 대응하는 스킬인지 매핑
그 스킬이 합리적인 추상화인지 (너무 구체적/일반적)

이건 단순 LLM call로 어려움 (디렉토리 walk + 파일 read + 매핑). Agent-as-Judge의 자리.

권장 도입안

본 실험에는 과도. 단, 후속 실험에서 H2를 검증할 때 검토.
본 실험에선 Hermes 누적 자산만 수량적으로 기록 (스킬 수, 라인 수). 의미는 사후 정성 분석.

6. 더 읽을거리

Zhuge et al., “Agent-as-a-Judge: Evaluate Agents with Agents” (2024) — 평가자 자체를 에이전트로 만든 시초 논문
“When AIs Judge AIs: The Rise of Agent-as-a-Judge Evaluation for LLMs” (2025) — Agent-as-Judge 흐름을 정리한 종합 서베이
METR (Model Evaluation & Threat Research) — 평가 에이전트가 능동 조사로 모델 위험 평가하는 실전 사례

다음 장 미리보기

평가의 자동화를 어디까지 끌어올릴지(2·3장)를 봤다. 이제 자동화의 반대편 — 인간이 매기는 점수를 어떻게 정량화 가능하게 만들지. 정성 1–5를 130개 측정 항목으로 분해하는 다층 rubric. 04장.

이 장에서 확실히 알아야 하는 것

Agent-as-Judge가 LLM-as-Judge와 갈라지는 정확한 기준(툴 호출 권한)을 안다.
평가자도 에이전트라 같은 종류의 실패를 한다는 함정을 인식하고 있다.
본 실험에 Agent-as-Judge가 과도인 이유를 설명할 수 있다.
H2 검증(Hermes 학습 흔적)에서 Agent-as-Judge가 자연스러운 자리라는 점을 안다.