에이전트가 확신에 차서 틀릴 때, 문제는 모델이 아닌 경우가 많습니다.

생성(generation)과 검증(verification)을 같은 LLM 하나에 맡겼기 때문입니다.

같은 뇌로 쓰고 같은 뇌로 검토하면 생기는 일

인간도 자기 글을 바로 교정하면 오류를 잘 못 잡습니다. 눈이 이미 쓴 내용을 ‘읽는’ 게 아니라 ‘기억하는’ 대로 흘러가기 때문입니다.

LLM도 마찬가지입니다. 생성 단계에서 특정 방향으로 추론이 굳어지면, 같은 모델이 검증을 해도 같은 방향으로 흐릅니다. 이것이 에이전트 루프에서 확증 편향이 생기는 구조적 이유입니다.

이 문제를 정면으로 겨냥한 연구가 있습니다. 2Brains 논문은 생성 LLM과 검증 LLM을 분리했을 때 두 가지 효과가 동시에 나타났다고 보고합니다.

  • 환각(hallucination) 발생률 감소
  • 추론 비용 감소

이 둘이 동시에 개선되는 경우는 드뭅니다. 보통 정확도를 높이면 비용이 오릅니다. 분리형 구조가 두 가지 모두 낮출 수 있는 건, 검증 전담 LLM이 훨씬 가벼운 모델로도 충분하기 때문입니다. 대형 모델은 초안을 만들고, 소형 모델은 그것이 맞는지만 판단합니다.

PM이 설계에서 가장 자주 놓치는 결정

에이전트를 처음 만들 때 대부분의 팀이 이렇게 시작합니다.

  1. 사용자 요청을 받는다
  2. LLM이 처리하고 결과를 낸다
  3. 결과를 반환한다

여기서 “검증” 단계는 어디에 있습니까? 없거나, 있어도 같은 LLM에게 “이 답이 맞는지 다시 확인해줘”라고 묻는 구조입니다.

이것은 검증이 아닙니다. 같은 편향을 재확인하는 과정입니다.

검증을 별도 뇌로 분리하면 에이전트 루프는 이렇게 달라집니다.

Generator LLM  → 초안 생성 (대형 모델, 창의적 추론)
Verifier LLM   → 독립 검토 (소형 모델, 다른 역할, 반박 지향 프롬프트)
Orchestrator   → 두 출력 비교 후 최종 결정

LangChain의 @hwchase17은 이 패턴을 adversarial verification이라고 부릅니다. 생성자와 검증자가 서로 다른 역할로 배치되어, 검증자가 생성자의 출력을 반박하도록 설계하는 방식입니다. 같은 편을 가정하지 않고, 구조적으로 긴장을 만드는 것이 핵심입니다.

LangGraph TBC — 예산 정책이 오케스트레이션의 본체다

생성·검증 분리는 구조입니다. 그 구조를 운영하는 정책이 따로 필요합니다.

LangGraph의 TBC(Trust Budget Constraint) 패턴은 세 가지를 동시에 관리합니다.

  • 우선순위: 어떤 서브에이전트의 출력을 먼저 반영할 것인가
  • 신뢰도: 각 출력에 얼마나 가중치를 줄 것인가
  • 토큰 예산: 검증에 얼마나 컴퓨팅을 쓸 것인가

세 번째가 결정적입니다. 검증을 도입하면 비용이 늘 것 같지만, TBC를 쓰면 오케스트레이터가 자동으로 판단합니다. 반복 조회나 단순 요약은 빠른 검증 모델로 통과시키고, 계약서 검토나 의사결정 보고서만 강력한 검증 레이어를 거치게 합니다.

오케스트레이션의 본체는 모델 선택이 아니라 이 예산 정책에 있습니다. 어떤 작업에 얼마의 검증 예산을 배분할 것인가 — 이것이 에이전트 PM이 설계해야 할 1차 의사결정입니다.

Fanout-and-Synthesize: 여러 생성자, 하나의 합성자

@hwchase17이 최근 정리한 또 다른 패턴은 fanout-and-synthesize입니다. 하나의 질문을 여러 서브에이전트에게 동시에 던지고(fanout), 각자의 답을 합성 에이전트가 비교·종합하는 구조입니다.

Query ──→ Agent A (관점 1) ─┐
       ──→ Agent B (관점 2) ─┼──→ Synthesizer ──→ 최종 응답
       ──→ Agent C (관점 3) ─┘

이 패턴이 주는 것은 두 가지입니다.

첫째, 다양성. 단일 LLM이 하나의 추론 경로를 타는 것과 달리, 여러 에이전트가 서로 다른 접근으로 탐색합니다. 확증 편향이 구조적으로 희석됩니다.

둘째, 속도. 직렬 검증(순서대로 하나씩)보다 병렬 실행이 훨씬 빠릅니다. 가장 느린 에이전트의 시간이 전체 응답 시간입니다.

구글 딥마인드도 같은 방향으로 움직이고 있습니다. 6월 29일 정식 출시된 Gemini Interactions API는 Managed Agents API, A2A Protocol, Agent skills와 함께 플랫폼 경쟁이 “단일 모델 호출”에서 “실행·오케스트레이션 레이어”로 이동한다는 신호입니다. 생성과 검증이 모두 인프라 레이어로 내려가는 중입니다. 이 방향을 인프라 벤더들이 표준화한다는 건, 분리 설계가 선택이 아니라 default가 된다는 의미입니다.

PM이 지금 물어야 할 질문

에이전트를 설계하거나 운영하는 팀이라면, 이 질문을 해야 합니다.

“우리 에이전트 루프에 검증 전담 역할이 있습니까?”

없다면 지금의 “검증”은 생성자가 자기 출력을 재확인하는 구조입니다. 품질 관리가 아닙니다.

생성과 검증을 분리하는 일은 모델을 교체하는 것보다 훨씬 쉽습니다. 프롬프트와 역할 설계만으로 시작할 수 있습니다. 그리고 그 효과는 비싼 모델로 업그레이드하는 것보다 실질적인 경우가 많습니다.

지금 에이전트 루프에 두 번째 뇌가 없다면, 첫 번째 뇌가 혼자 감당하고 있는 것입니다.