두 에이전트 검토 패턴: AI 에이전트가 자신의 출력을 검증하면 안 되는 이유

Source: Dev.to

두 에이전트 검토 패턴: AI 에이전트가 자신의 출력물을 검증하면 안 되는 이유

AI 에이전트 시스템에서 30일 정도 지나면 나타나는 미묘한 실패 모드가 있습니다. 에이전트가 기술적으로는 맞지만 상황에 맞지 않는 출력물에 대해 성공을 보고하는 것입니다.

에이전트가 작업을 수행했습니다. 출력이 존재합니다. 하지만 그것은 실제로 당신이 필요로 했던 것이 아닙니다.

근본 원인은 거의 항상 자기 검증입니다. 에이전트는 자신의 출력을 객관적으로 평가할 수 없습니다—출력을 만든 자신이 맞다고 믿고 성공을 보고합니다. 이는 모델 자체의 문제가 아니라 구조적인 문제입니다.

패턴

에이전트 A가 작업을 수행합니다.
에이전트 B가 배포 전에 이를 검토합니다.

실행 중에 두 에이전트는 컨텍스트를 공유하지 않습니다. 에이전트 A는 출력물을 파일에 기록하고, 에이전트 B는 그 출력 파일과 원래 작업 사양만을 읽어 검토 파일에 통과/실패 판정을 기록합니다.

• 교차 오염 없음.
• 공유된 추론 없음.
• 명확한 분리.

왜 효과적인가

에이전트 B는 에이전트 A의 작업에 이해관계가 없습니다. 인간 검토자가 하는 것과 같은 방식으로 새롭게 출력을 읽습니다. 검토 항목은 다음과 같습니다:

• 출력이 작업 사양과 일치하는가?
• done_when 조건이 실제로 충족되는가?
• 누락되거나 모호한 부분은 없는가?

에이전트 B가 문제를 발견하면, 출력은 구체적인 피드백과 함께 에이전트 A에게 돌아갑니다—“다시 시도하세요”와 같은 모호한 메시지가 아니라.

수치로 보는 효과

이 패턴을 30일 동안 5인 팀이 적용했을 때:

• 오탐 성공률: 8 % → 1.2 %
• 수동 검토 오버헤드: –52 %
• 재작업 루프: –61 %

한 단계만 추가하면, 정리 작업이 크게 줄어듭니다.

최소 구현 예시

// current-task.json (Agent A)
{
  "task": "summarize_weekly_report",
  "status": "pending_review",
  "output_file": "outputs/weekly-summary-2026-03-08.md",
  "done_when": "all 5 sections covered, < 500 words each"
}

// review.json (Agent B writes after check)
{
  "verdict": "pass",
  "checked_at": "2026-03-08T20:45:00Z",
  "notes": "All 5 sections present. Section 3 is 487 words — within spec."
}

에이전트 A는 작업을 완료하기 전에 review.json을 읽습니다. 판정이 "fail"이면, 노트를 확인하고 수정합니다.

이 패턴의 원칙

어떠한 에이전트도 자신의 출력물에 대해 유일한 판단자가 되어서는 안 됩니다. 이는 신뢰 문제라기보다 아키텍처 문제입니다. 인간이 코드 리뷰, 편집 리뷰, QA를 하는 이유와 동일합니다: 두 번째 시각이 첫 번째 시각이 놓친 부분을 잡아줍니다.

필요해지기 전에 검토 루프를 구축하세요. 오탐 문제를 인지했을 때는 이미 잘못된 출력이 여러 번 배포된 뒤일 가능성이 높습니다.

전체 피어 리뷰 템플릿은 askpatrick.co library에서 확인할 수 있으며, 다중 에이전트 팀을 깔끔하게 운영하기 위한 다른 패턴들도 함께 제공됩니다.