현장에서 에이전트 PoC가 운영으로 넘어갈 때 같은 장면이 반복된다. 모델은 답을 낸다. 데모도 된다. 그런데 운영 회의에서는 “이걸 누가 맞다고 보증하나”라는 질문 앞에서 멈춘다.
문제는 verifier가 없어서가 아니다. 테스트도 있고, rubric도 있고, 사용자 피드백도 있고, LLM judge도 있다. 문제는 전부 한 줄로 서 있다는 점이다. 쉬운 작업에도 과검증을 걸고, 위험한 작업에는 얕은 rubric 하나로 통과시킨다.
reward는 점수가 아니라 결재선이다
Verifier portfolio router는 reward를 하나의 점수 함수로 보지 않는다. 작업 위험도에 따라 어떤 검증기를 태울지 고르는 운영 아키텍처다.
최근 에이전트 평가 논의도 같은 방향으로 움직인다. Anthropic은 agent eval을 제품 수명주기 전반의 기준선, 회귀 테스트, 비용·지연·오류 추적 장치로 설명한다. OpenAI도 trace grading, dataset 기반 평가, prompt optimization 같은 평가 기능을 agent 운영 도구의 일부로 묶었다. 즉 eval은 출시 전 시험지가 아니라 운영 중 품질 계측망이다. (anthropic.com)
reward 선택은 모델 튜닝 문제가 아니라 운영 리스크 배분 문제다.
AX Ops에서는 reward를 네 가지 포트폴리오로 나눈다.
| verifier | 강점 | 약점 | 맞는 작업 |
|---|---|---|---|
| 테스트 | 빠르고 재현 가능 | 의미 품질을 놓친다 | 코드, 계산, 형식, 정책 위반 |
| rubric | 판단 기준을 명시한다 | 기준 작성 품질에 의존한다 | 보고서, 상담 답변, 요약 |
| 사용자 | 실제 선호를 반영한다 | 느리고 일관성이 흔들린다 | 고객 접점, 내부 의사결정 |
| agent verifier | 긴 추론과 도구 검증을 수행한다 | 비용과 오류 전파가 있다 | 다단계 조사, 고위험 초안 |
하나를 고르는 것이 아니다. 위험도별 기본 경로를 정하고, 불확실성이 커질 때 다음 verifier로 승격시킨다.
위험도 라우터가 없으면 검증비가 새어 나간다
모든 산출물에 인간 검토를 붙이면 운영이 멈춘다. 모든 산출물을 자동 점수로 통과시키면 사고가 난다. 그래서 라우터가 필요하다.
라우터의 입력은 복잡할 필요가 없다. 먼저 작업을 네 등급으로 나눈다.
- 낮음: 형식, 중복 제거, 단순 변환
- 보통: 내부 문서 초안, 검색 기반 요약
- 높음: 고객 응대, 재무·계약·인사 관련 초안
- 치명: 외부 발송, 권한 변경, 금전·법적 효과가 있는 실행
낮은 위험은 테스트와 간단한 rubric으로 닫는다. 보통 위험은 rubric과 샘플링 리뷰를 붙인다. 높은 위험은 agent verifier가 근거, 정책, 누락을 재검사하고 사람에게 승격한다. 치명 위험은 자동 실행을 막고 사용자 승인과 감사 로그를 필수 경로로 둔다.
OpenAI의 chain-of-thought monitorability 연구는 고성능 agent를 약한 monitor가 감독하는 scalable control 문제를 다룬다. 논문은 추가 검사 compute를 필요한 경우에만 쓰는 접근의 매력을 짚는다. 이 관점은 기업 운영에서도 그대로 맞다. 비싼 검증은 모든 곳에 쓰는 것이 아니라 위험한 지점에 몰아야 한다. (openai.com)
agent verifier는 최종 심판이 아니라 승격 엔진이다
Agent verifier를 “LLM judge의 고급형”으로만 보면 실패한다. agent verifier의 역할은 정답 선언이 아니다. 불확실성을 줄이고, 근거를 모으고, 다음 결재선을 정하는 것이다.
2026년 AgentV-RL 논문은 reward modeling을 multi-turn, tool-augmented deliberative process로 바꾸고, forward agent와 backward agent가 서로 다른 방향으로 풀이와 전제를 점검하는 구조를 제안했다. 같은 해 Verifiable Process Rewards 논문은 중간 단계의 verifier-grounded reward가 긴 작업의 credit assignment를 개선하지만 verifier 신뢰도에 의존한다고 명시했다. (arxiv.org)
운영 설계로 번역하면 결론은 단순하다. agent verifier도 verifier portfolio 안의 한 구성원이다. 테스트가 확인할 수 있는 것은 테스트가 한다. rubric이 잡을 수 있는 것은 rubric이 한다. agent verifier는 다단계 근거 확인, 도구 호출, 반례 탐색, 에스컬레이션 판단에 쓴다.
이때 라우터는 다음 로그를 남겨야 한다.
- 어떤 위험 등급으로 분류했는가
- 어떤 verifier를 호출했는가
- 어떤 근거로 통과·보류·승격했는가
- 사람이 뒤집은 결정은 무엇인가
이 로그가 쌓여야 reward가 학습된다. 점수만 저장하면 운영은 배울 수 없다.
참고
- Anthropic, “Demystifying evals for AI agents”, 2026: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- OpenAI, “Introducing AgentKit”, 2025, 2026년 6월 업데이트 포함: https://openai.com/index/introducing-agentkit/
- OpenAI, “Evaluating chain-of-thought monitorability”, 2025: https://openai.com/index/evaluating-chain-of-thought-monitorability/
- Zhang et al., “AgentV-RL: Scaling Reward Modeling with Agentic Verifier”, 2026: https://arxiv.org/abs/2604.16004
- Yuan et al., “Verifiable Process Rewards for Agentic Reasoning”, 2026: https://arxiv.org/abs/2605.10325
- Gao et al., “Agent-as-a-Router: Agentic Model Routing for Coding Tasks”, 2026: https://arxiv.org/abs/2606.22902
Verifier portfolio router의 첫 버전은 거창한 플랫폼이 아니다. 업무 위험도 표, verifier 선택 규칙, 승격 로그 세 가지면 시작한다. 중요한 것은 agent를 더 많이 붙이는 것이 아니라, 검증 책임을 작업 위험도에 맞게 배치하는 일이다. 이 설계를 AX Ops 운영 사이클 안에 넣어야 PoC가 현장 시스템으로 바뀐다. 구체적인 설계 방식은 AX Ops 방법론 →에서 이어간다.