멀티 에이전트 숙의: 합의가 버그일 때
제 AI 에이전트가 생성하는 가장 위험한 출력은 오류가 아닙니다. 오류는 쉽습니다. 린터가 구문 실수를 잡고, 테스트 스위트가 회귀를 잡고, 제가 만든 95개의 훅이 except: pass와 강제 푸시를 잡아냅니다. 위험한 출력은 자신감 있고 논리적으로 잘 구성되었지만 틀린 권장 사항입니다.
단일 에이전트에게 API 엔드포인트의 보안 문제를 검토하도록 요청했습니다. 에이전트는 인증을 확인하고, 입력 살균을 검증하고, CORS 헤더를 확인했습니다. 이상 없음. 별도로 침투 테스터로 프롬프트된 두 번째 에이전트는 해당 엔드포인트가 제한 없는 쿼리 매개변수를 수용하여 데이터베이스 쿼리 증폭을 통한 서비스 거부 공격을 유발할 수 있다는 것을 발견했습니다. 첫 번째 에이전트는 평가 프레임워크에서 쿼리 복잡도를 보안 표면으로 취급하는 항목이 없었기 때문에 확인하지 않았습니다.
이 격차는 구조적입니다. 프롬프트 엔지니어링을 아무리 많이 해도 이 문제는 해결되지 않습니다. 한계가 프롬프트에 있는 것이 아니기 때문입니다. 한계는 하나의 관점이 다차원적 문제를 평가하는 데 있습니다.
이 격차를 해소하기 위해 멀티 에이전트 숙의 시스템을 구축했습니다. 서로 다른 페르소나를 가진 에이전트들이 독립적으로 조사하고, 발견 사항을 토론하며, 구조화된 투표를 통해 합의에 도달합니다. 이 시스템은 141개의 테스트를 실행하고, 에이전트 간 컨텍스트 격리를 시행하며, 성급한 합의를 차단하는 2단계 검증 아키텍처를 사용합니다.
TL;DR
단일 에이전트 AI 시스템에는 구조적 사각지대가 있습니다: 자신의 가정에 도전할 수 없다는 것입니다. Sonnet을 실행하는 Ralph 루프는 시간당 $10로 코드를 생산하지만, 모델의 모든 사각지대도 같은 속도로 배포됩니다. 멀티 에이전트 숙의는 어떤 결정이 확정되기 전에 여러 관점에서 독립적인 평가를 강제합니다. 제 구현은 10개의 연구 페르소나, 7단계 상태 머신, 그리고 Claude Code 훅에서 실행되는 2개의 검증 게이트(합의 + 자부심 검증)를 사용합니다. 이 시스템은 낮은 신뢰도 결정(0.70 미만)에서 트리거되며 숙의당 대략 3배의 토큰 비용이 추가됩니다. 보안 결정, 아키텍처 선택, 그리고 되돌릴 수 없는 모든 작업에 대해 이 비용은 단일 에이전트가 놓친 것을 처음 잡아내는 순간 자체적으로 정당화됩니다. 문서 수정이나 일상적인 편집의 경우 숙의를 완전히 건너뛰십시오.
에이전트들이 모든 것을 망치기로 합의한 밤
2026년 2월. 화요일이었습니다. 에이전트에게 “훅 디스패치 시스템 개선 방안을 조사해줘”라고 요청하고 커피를 만들러 갔습니다. 에이전트는 자체 신뢰도를 0.58(0.70 임계값 미만)로 평가했고, 이것이 숙의를 트리거했습니다. 시스템은 3개의 연구 에이전트를 생성했습니다. 각 연구 에이전트는 문제를 평가하고, 하위 문제를 찾고, 자체적으로 연구 에이전트를 생성했습니다. 그 에이전트들이 또 더 많은 에이전트를 생성했습니다.
7분 후: 23개의 활성 에이전트 프로세스. $4.80의 API 크레딧 소진. ~/.claude/state/ 디렉토리가 각 에이전트가 성실하게 저장한 발견 사항의 JSON 상태 파일로 채워지고 있었습니다. 수렴의 기미 없이 분당 약 $0.70의 토큰 소비가 증가하고 있었습니다.
품질 시스템을 위해 구축한 재귀 가드는 깊이(부모가 자식을 생성하고, 자식이 손자를 생성)는 추적했지만 너비(부모가 12개의 자식을 생성하고 각각이 12개를 더 생성)는 추적하지 않았습니다. 에이전트들이 수평으로 확산했기 때문에 깊이 제한 3은 한 번도 트리거되지 않았습니다. 프로세스를 수동으로 종료하고 상태 파일을 살펴보았습니다.
모든 에이전트가 훅 디스패치 시스템에 개선이 필요하다고 동의했습니다. 모든 에이전트가 합리적으로 들리는 변경을 제안했습니다. 조사 자체의 범위가 올바르게 설정되었는지 의문을 제기한 에이전트는 단 하나도 없었습니다. 23개의 에이전트가 잘못된 질문에 합의를 달성한 것입니다.
수정에는 20분이 걸렸습니다: 부모당 총 활성 자식 수를 추적하고 12개로 제한하는 생성 예산. 더 깊은 교훈은 더 오래 걸렸습니다. 제가 문서화한 인프라 가속 곡선은 훅 인프라가 이미 존재했기 때문에 정확히 2주 만에 숙의 시스템을 구축할 수 있게 해주었습니다. 하지만 빠른 구축이 구조적 실패를 방지하지는 않습니다. 단일 에이전트 RAG 파이프라인에서 자율 시스템으로의 진행은 예측 가능한 궤적을 따릅니다. 멀티 에이전트 숙의가 맨 끝에 위치하는 데는 이유가 있습니다: 단일 에이전트가 자신 있게 잘못된 답을 배포한 후에야 구축하게 됩니다.
불일치가 아닌 합의가 위험한 실패 모드였습니다.
숙의의 해부
이 시스템은 두 가지 구조적 구성 요소가 있습니다: 작업 순서를 정하는 상태 머신과 잘못된 합의가 배포되는 것을 방지하는 두 개의 검증 게이트입니다.
상태 머신
7개의 단계로, 각각 이전 단계에 의해 제어됩니다:
IDLE -> RESEARCH -> DELIBERATION -> RANKING -> PRD_GENERATION -> COMPLETE
|
(or FAILED)
RESEARCH: 독립적인 에이전트들이 주제를 조사합니다. 각 에이전트는 서로 다른 페르소나를 부여받습니다(기술 아키텍트, 보안 분석가, 성능 엔지니어, 그리고 7개의 기타 역할). 컨텍스트 격리를 통해 연구 중에 에이전트들이 서로의 발견 사항을 볼 수 없도록 합니다. L0(시스템 규칙)과 L1(프로젝트 컨텍스트)은 공유됩니다. L2(에이전트별 초점)는 비공개입니다. L3(도메인 패턴)는 페르소나별로 관련 패턴 라이브러리를 로드합니다.1
DELIBERATION: 에이전트들이 모든 연구 결과를 보고 대안을 생성합니다. 토론 에이전트가 관점 간의 충돌을 식별합니다. 종합 에이전트가 모순되지 않는 발견 사항을 결합합니다.
RANKING: 각 에이전트가 5개의 가중 차원에 걸쳐 제안된 모든 접근 방식에 점수를 매깁니다:
| 차원 | 가중치 |
|---|---|
| 영향도 | 0.25 |
| 품질 | 0.25 |
| 실현 가능성 | 0.20 |
| 재사용성 | 0.15 |
| 위험도 | 0.15 |
가중 점수가 합의 점수로 집계됩니다. 임계값은 작업에 따라 적응적입니다: 보안 결정의 경우 0.85, 아키텍처의 경우 0.80, 기본값 0.70, 리팩토링의 경우 0.65, 문서의 경우 0.50입니다.2
두 개의 게이트
게이트 1: 합의 검증 (PostToolUse:Task 훅). 모든 숙의 에이전트가 완료된 후 4가지 검사가 실행됩니다:
- 단계가 최소 RANKING에 도달해야 합니다
- 최소 2개의 에이전트가 완료되어야 합니다 (설정 가능)
- 합의 점수가 작업 적응형 임계값을 충족해야 합니다
- 이의를 제기한 에이전트가 있으면 해당 우려 사항이 문서화되어야 합니다
어떤 검사라도 실패하면 숙의 진행이 차단됩니다.3
게이트 2: 자부심 검증 (Stop 훅). 세션이 종료되기 전에 5가지 품질 검사가 실행됩니다:
- 다양한 방법론: 여러 고유 페르소나가 대표되어야 합니다
- 모순 투명성: 이의 제기에 문서화된 이유가 있어야 합니다
- 복잡성 처리: 최소 2개의 대안이 생성되어야 합니다
- 합의 신뢰도: 점수가 강함(0.85 이상) 또는 보통(0.70-0.84)으로 분류되어야 합니다
- 개선 증거: 최종 신뢰도가 초기 신뢰도를 초과해야 합니다
2단계 게이트 아키텍처는 서로 다른 단계에서 문제를 포착합니다. 게이트 1은 프로세스 중 성급한 수렴을 방지합니다. 게이트 2는 완전해 보이지만 엄밀함이 부족한 결과의 배포를 방지합니다.
정보 분석가들이 먼저 이 문제를 겪었습니다
2026년 1월에 숙의 시스템을 구축했습니다. 2주 후, 구조화된 의사결정에 관한 추천 도서 목록에서 Richards Heuer의 Psychology of Intelligence Analysis를 발견했습니다. 8장에서는 경쟁 가설 분석(ACH)을 설명합니다: 분석가들이 선호하는 결론에 대한 논거를 구축하는 대신, 여러 가설에 대해 증거를 동시에 평가하는 방법입니다.4
유사성이 불편할 정도였습니다. 1999년 CIA를 위해 출판된 Heuer의 프레임워크는 제가 디버깅하고 있던 것과 동일한 구조적 실패를 다루고 있었습니다: 똑똑한 사람들이 대안을 평가하도록 스스로를 강제하지 않았기 때문에 단일 설명에 수렴하는 현상.
ACH가 실제로 어떻게 작동하는지 살펴보겠습니다. 의심되는 무기 프로그램을 조사하는 정보 분석가는 “이것이 무기 프로그램인가?”라고 묻지 않습니다(확증 편향). 대신 분석가는 모든 타당한 가설(무기 프로그램, 민간 연구, 이중 용도 시설)을 나열하고, 각 증거를 모든 가설에 대해 평가하며, 어떤 증거가 가설들을 가장 잘 구별하는지 식별합니다.
제 시스템은 다른 용어로 같은 일을 합니다. 세 개의 에이전트가 제안된 데이터베이스 스키마 변경을 평가합니다. 에이전트 A(기술 아키텍트)는 “스키마가 깔끔하고 제3정규형으로 정규화되어 있습니다”라고 씁니다. 에이전트 B(성능 엔지니어)는 “쿼리 패턴이 매 읽기마다 4개 테이블에 걸친 조인을 필요로 합니다”라고 씁니다. 에이전트 C(보안 분석가)는 “PII 필드가 저장 시 암호화되지 않았습니다”라고 씁니다. 같은 스키마, 세 가지 다른 평가, 세 가지 구별하는 증거. 순위 단계에서는 ACH가 증거에 대해 가설을 평가하는 방식으로 이러한 독립적 평가에 대해 제안된 접근 방식을 평가합니다.
Heuer의 프레임워크에서 시스템을 설계한 것이 아닙니다. 시행착오를 통해 ACH의 하위 집합을 재발명한 후, 누군가가 이미 교과서를 썼다는 것을 발견했습니다. 솔직한 버전이 자찬하는 버전보다 더 유용합니다: 독립적으로 같은 아키텍처에 도달했다는 것은 근본적인 문제가 이론적이 아닌 실제적임을 확인해줍니다.
합의가 위험한 실패 모드인 이유
Charlan Nemeth는 1986년부터 2018년 저서 In Defense of Troublemakers에 이르기까지 소수 의견 반대를 연구했습니다. 반대 의견이 있는 집단이 빠르게 합의에 도달하는 집단보다 더 나은 결정을 내립니다. 반대자가 옳을 필요는 없습니다. 반대 행위 자체가 다수로 하여금 그렇지 않았으면 건너뛰었을 가정을 검토하도록 강제합니다.5
James Surowiecki의 The Wisdom of Crowds는 현명한 집단 결정을 위한 네 가지 조건을 제시합니다: 의견의 다양성, 판단의 독립성, 탈중앙화, 그리고 집계 메커니즘입니다.6 독립성을 위반하면(연구 중에 에이전트들이 서로의 작업을 보게 하면) 군집 행동이 나타납니다. 다양성을 위반하면(모든 에이전트에 동일한 프롬프트를 사용하면) 반향실이 됩니다.
독립성 조건을 직접 테스트했습니다. 같은 배포 전략을 평가하는 두 에이전트가 서로의 결과를 볼 수 있었을 때: 에이전트 A는 위험도를 0.45로 평가했습니다. 에이전트 B는 그 점수를 보고 0.48을 제시했습니다. 가시성 없이 같은 에이전트들로 테스트했을 때: 0.45와 0.72. 0.48과 0.72 사이의 격차가 군집 행동의 비용입니다. 에이전트 B의 독립적 평가는 사회적 압력이 평가에 들어왔을 때 사라진 컨테이너 오케스트레이션 위험을 표시했습니다.
최근 연구는 두 패턴 모두 LLM 에이전트에서도 유효함을 확인합니다. Choi 등은 NeurIPS 2025에서 독립적으로 프롬프트된 에이전트 간의 다수결 투표가 멀티 에이전트 시스템의 품질 향상 대부분을 포착한다는 것을 발견했습니다.7 Kaesberg 등은 ACL 2025에서 그 차이를 정량화했습니다: 투표는 추론 과제를 13.2% 개선하고, 합의 프로토콜은 지식 과제를 2.8% 개선합니다.8 이는 선택이 과제 유형에 따라 달라져야 함을 시사합니다. 이것이 제 시스템이 단일 합의 수치 대신 작업 적응형 임계값을 사용하는 이유입니다.
Wu 등은 LLM 에이전트가 진정으로 토론할 수 있는지 테스트했으며, 불일치에 대한 구조적 인센티브 없이는 에이전트들이 정확성과 무관하게 가장 자신감 있게 들리는 초기 응답으로 수렴한다는 것을 발견했습니다.9 Wynn 등은 더 나아갔습니다: 토론이 적극적으로 해로울 수 있습니다. 모델들이 더 강한 모델이 더 약한 모델보다 수적으로 많을 때조차 동료의 추론에 반응하여 올바른 답에서 잘못된 답으로 전환합니다.10 Liang 등은 근본 원인을 “사고의 퇴화(Degeneration-of-Thought)”로 식별했습니다: LLM이 한 입장에 대한 확신을 확립하면 자기 성찰로는 새로운 반론을 생성할 수 없어 멀티 에이전트 평가가 구조적으로 필수적이 됩니다.11
제 시스템은 컨텍스트 격리(연구 중 L2 계층은 에이전트 전용)를 통해 독립성을 다룹니다. 다양성은 서로 다른 평가 우선순위를 가진 10개의 고유한 페르소나에서 나옵니다. 집계는 단순 투표 대신 5개 차원에 걸친 가중 점수를 사용합니다. 불일치에 대한 구조적 인센티브는 더 약합니다: 이의 제기가 문서화되었는지 추적하지만 에이전트들에게 반대에 대한 보상을 하지는 않습니다. 순응 감지 모듈이 이 격차를 해결하려고 시도하지만, 결과는 혼합적입니다.
가짜 불일치 감지
순응 모듈은 에이전트들이 진정한 평가 없이 동의하고 있음을 시사하는 패턴을 추적합니다. 에이전트 간에 같은 언어를 반복하는 문서화된 우려, 임계값에 의심스러울 정도로 가까이 군집하는 점수, 또는 모든 페르소나의 만장일치 지지(보안 분석가와 성능 엔지니어가 모든 것에 동의하는 경우는 드뭅니다)가 경고를 트리거합니다.
포착하는 것: 상투적 반대(에이전트들이 서로의 우려 사항 문구를 복사), 점수 군집(10점 척도에서 모든 에이전트가 0.3점 이내로 점수를 매기는 것), 소수 관점의 부재(상충하는 우선순위를 가진 페르소나들의 만장일치 승인).
제 로그의 예시: 다섯 개의 에이전트가 인증 리팩토링을 평가했습니다. 다섯 모두 보안 위험을 7.1에서 7.4 사이로 점수를 매겼습니다. 순응 감지기가 군집을 표시했습니다. 새로운 컨텍스트 격리(L2 캐시 초기화)로 다시 실행했을 때 점수가 5.8-8.9로 분산되었습니다. 원래 군집은 진정한 합의가 아닌 공유 컨텍스트 오염을 반영한 것이었습니다.
놓치는 것: 에이전트들이 진정으로 자기 페르소나의 관점에서 평가하지만 다른 이유로 같은 결론에 도달하는 정교한 합의. 모듈은 추론이 독립적으로 보일 때 진정한 합의와 군집 행동을 구별할 수 없습니다. 진정한 합의 vs. 만들어진 합의의 예시로 분류기를 훈련시키려 했지만, 훈련 데이터가 너무 적었고(50개 미만의 숙의 세션) 신호가 너무 약했습니다. 순응 감지기는 명백한 경우를 잡고 미묘한 경우를 놓칩니다.
솔직한 평가: 순응 감지는 에이전트들이 너무 빠르게 수렴하는 숙의의 10-15%에서 유용한 온전성 검사를 추가합니다. 나머지 85-90%에 대해서는 합의 및 자부심 검증 게이트가 충분한 검증을 제공합니다. 더 정교한 순응 시스템을 구축하는 것을 고려했지만 엔지니어링 노력이 한계적 개선에 비해 맞지 않다고 판단했습니다.
효과가 없었던 것들
실패한 접근법 1: 자유 형식 토론 라운드
첫 번째 버전에서는 에이전트들이 서로의 발견 사항에 대한 장문의 반박을 작성하도록 했습니다: 3라운드의 주고받는 텍스트. 데이터베이스 인덱싱 전략에 관한 숙의가 7,500 토큰의 토론으로 전개되는 것을 지켜보았습니다. 1라운드: 복합 인덱스 vs. 단일 컬럼 인덱스에 대한 진정한 의견 차이. 2라운드: 약간의 부연과 함께 입장을 재진술. 3라운드: 다른 단어로 포장된 거의 동일한 논증. 신호는 1라운드에서 최고점을 찍고 이후로 저하되었습니다.
숙의당 토큰 비용이 $2-4에 달했고, 유용한 정보 밀도는 라운드마다 떨어졌습니다. 해결책: 구조화된 차원 점수 체계가 자유 형식 토론을 대체했습니다. 에이전트들이 에세이를 작성하는 대신 5개 차원에 걸쳐 수치 값으로 제안을 점수화합니다. 비용과 시간이 약 60% 감소했으며, 최종 순위의 품질은 실제로 향상되었습니다. 수치 점수가 산문이 모호하게 만드는 정밀성을 강제하기 때문입니다.
실패한 접근법 2: 숙의를 위한 깊이 기반 재귀
무한 생성 사건은 근본적인 모델링 오류를 노출했습니다. 재귀 가드는 깊이를 추적했습니다: 깊이 0의 부모가 깊이 1의 자식을 생성하고, 자식이 깊이 2의 손자를 생성하며, 최대 깊이 3. 하지만 숙의 에이전트는 깊게(한 에이전트가 한 자식을 생성하고 그 자식이 한 손자를 생성) 들어가는 것이 아니라 넓게(같은 수준에서 10개의 연구 에이전트) 펼쳐져야 합니다. 깊이 1에 23개의 에이전트가 있어도 여전히 “깊이 1”이기 때문에 깊이 제한 3은 한 번도 트리거되지 않았습니다.
해결책은 생성 예산 모델이었습니다: 숙의 에이전트는 깊이를 증가시키는 대신 부모의 깊이를 상속하고, 12개로 제한된 자식 생성 총 예산을 공유합니다. 예산 모델은 프록시 지표(중첩 수준이 너무 많음)가 아닌 실제 실패 모드(총 에이전트가 너무 많음)에 매핑됩니다. 에이전트 계보는 비동기 에이전트 완료 간에 예산이 유지되도록 JSON 파일로 추적됩니다.12
실패한 접근법 3: 단일 검증 게이트
첫 번째 구현은 세션 종료 시 합의 검사와 품질 검사를 결합한 하나의 검증 훅을 실행했습니다. 실패 모드는 첫 주 안에 나타났습니다. 에이전트가 0.52 합의 점수(0.70 임계값 미만)로 숙의를 완료했습니다. 그런 다음 세션 종료 훅이 실패를 표시하기 전까지 20분 동안 관련 없는 작업을 계속했습니다. 검증을 통과하지 못한 기반 위에 20분의 작업이 구축된 것입니다.
두 개의 게이트로 분리하여 타이밍 문제를 해결했습니다. 게이트 1(합의 검증)은 PostToolUse:Task 훅으로 실행되어 숙의 에이전트가 완료된 직후 잘못된 합의를 잡습니다. 게이트 2(자부심 검증)는 세션 종료 시 실행되어 단계 전반에 걸쳐 누적된 품질 문제를 잡습니다. 서로 다른 라이프사이클 지점에 있는 두 개의 훅은 실패가 실제로 발생하는 방식에 매핑됩니다: 일부는 즉각적(나쁜 점수)이고 일부는 점진적(낮은 다양성, 누락된 이의 제기 문서)입니다.
솔직한 수학
숙의에는 토큰이 소요됩니다. 각 연구 에이전트는 약 5,000 토큰의 컨텍스트를 처리하고 2,000-3,000 토큰의 발견 사항을 생성합니다. 3개의 에이전트(유용한 숙의를 위한 최소)로 결정당 15,000-24,000개의 추가 토큰이 발생합니다. 10개의 에이전트(전체 연구 패널)로는 약 50,000-80,000 토큰입니다.
Opus 가격($15/$75 per million tokens)으로 3개 에이전트 숙의는 약 $0.68-0.90입니다. 10개 에이전트 숙의는 $2.25-3.00입니다. 제 시스템은 결정의 약 10%(0.70 신뢰도 미만으로 점수가 매겨진 것들)에서 숙의를 트리거하므로, 모든 결정에 걸친 분할 비용은 세션당 $0.23-0.30입니다.
이것이 가치 있는지 여부는 잘못된 결정의 비용에 달려 있습니다. 프로덕션 배포에서 놓친 보안 취약점은 사고 대응에 시간이 소요됩니다. 잘못된 아키텍처 선택은 리팩토링에 주 단위의 시간이 소요됩니다. 문서의 오타는 비용이 없습니다.
신뢰도 모듈이 어떤 결정이 숙의를 트리거하는지 결정합니다. 네 가지 차원(모호성, 복잡성, 위험도, 컨텍스트 의존성)이 각각 0-1 점수를 생성합니다. 전체 신뢰도가 0.70 아래로 떨어져 숙의를 트리거하려면 여러 차원에서 높은 점수를 받아야 합니다. 단일 차원 문제(“이것은 복잡하지만 모호하지 않다”)는 임계값 이상에 머무르며 숙의를 건너뜁니다.13
두 개의 에이전트, 하나의 규칙
멀티 에이전트 숙의에서 가치를 얻기 위해 10개의 연구 페르소나, 8개의 Python 모듈, 또는 141개의 테스트가 필요하지 않습니다. 2개의 에이전트와 1개의 규칙으로 시작하십시오: 에이전트들은 서로의 작업을 보기 전에 독립적으로 평가해야 합니다.
최소 기능 숙의
Decision arrives
|
v
Confidence check: is this risky, ambiguous, or irreversible?
|
├── NO -> Single agent decides (normal flow)
|
└── YES -> Spawn 2 agents with different system prompts
Agent A: "Argue FOR this approach"
Agent B: "Argue AGAINST this approach"
|
v
Compare findings
|
├── Agreement with different reasoning -> Proceed
├── Genuine disagreement -> Investigate the conflict
└── Agreement with same reasoning -> Suspect herding
위의 결정 흐름도가 가치의 80%를 커버합니다. 최소한의 구현은 다음과 같습니다:
# Minimum viable deliberation: 2 agents, 1 rule
def deliberate(decision_description):
agent_for = spawn_agent(
f"Argue FOR this approach: {decision_description}",
persona="advocate"
)
agent_against = spawn_agent(
f"Argue AGAINST this approach: {decision_description}",
persona="critic"
)
if same_reasoning(agent_for, agent_against):
return "WARNING: Suspect herding. Verify independently."
elif genuine_conflict(agent_for, agent_against):
return "Investigate the specific disagreement."
else:
return "Proceed. Independent agreement with different reasoning."
그 외 모든 것은 점진적 개선을 추가합니다: 5차원 순위, 작업 적응형 임계값, 순응 감지. 핵심 통찰은 단순합니다: 두 개의 독립적 관점이 하나의 관점이 놓치는 실패를 포착합니다.
단일 에이전트 vs. 멀티 에이전트: 무엇이 달라지는가
| 시나리오 | 단일 에이전트 | 멀티 에이전트 숙의 |
|---|---|---|
| 보안 검토 | “아키텍처가 깔끔합니다” | 에이전트 A: “깔끔합니다.” 에이전트 B: “관리자 영역에 속도 제한이 없습니다” |
| 스키마 설계 | “제3정규형으로 정규화됨” | 에이전트 A: “깔끔합니다.” 에이전트 B: “매 읽기마다 4개 테이블 조인” |
| 의존성 업그레이드 | “테스트 통과, 배포하세요” | 에이전트 A: “테스트 통과.” 에이전트 B: “변경 로그에 v3에서 호환성 깨지는 API 변경 표시” |
| 문서 업데이트 | “README 업데이트됨” | 모든 에이전트가 동의 (올바른 건너뛰기, 신뢰도 임계값 미만) |
숙의할 것과 건너뛸 것
| 숙의 대상 | 건너뛰기 |
|---|---|
| 보안 아키텍처 | 문서 오타 |
| 데이터베이스 스키마 설계 | 변수명 변경 |
| API 계약 변경 | 로그 메시지 업데이트 |
| 배포 전략 | 주석 수정 |
| 의존성 업그레이드 | 테스트 픽스처 업데이트 |
숙의 테스트
이 시스템은 세 개의 계층에 걸쳐 141개의 테스트를 실행합니다:14
- 48개의 bash 통합 테스트: 훅 구문 검증, 합의 흐름, 자부심 검증 게이트, 재귀 가드 시행, 그리고 교차 설정 호환성
- 81개의 Python 단위 테스트: 모든 7개 라이브러리 모듈 (상태 머신, 신뢰도, 컨텍스트 격리, 순위, 에이전트, 순응, PRD 생성)
- 12개의 엔드투엔드 테스트: 신뢰도 평가부터 PRD 출력까지 전체 파이프라인 시뮬레이션
불일치를 위해 설계된 시스템을 테스트하려면 두 가지 범주를 테스트해야 합니다. 성공 경로: 에이전트들이 생산적으로 의견이 갈리고 합의에 도달하는 경우. 실패 경로: 에이전트들이 너무 빠르게 수렴하거나, 절대 수렴하지 않거나, 생성 예산을 초과하는 경우. E2E 테스트는 결정론적 에이전트 응답으로 각 시나리오를 시뮬레이션하여, 두 게이트가 문서화된 모든 실패 모드를 잡는지 검증합니다.
2개 에이전트 패턴으로 시작하십시오. 2개 에이전트 버전이 특정한 것을 놓칠 때 복잡성을 추가하십시오. 제 시스템의 모든 추가 에이전트, 임계값, 검증 게이트는 더 단순한 버전이 특정 작업에서 실패했기 때문에 존재합니다. 여러분의 실패는 다를 것이며, 그 실패를 잡기 위해 구축하는 시스템은 제 것이 아닌 여러분의 실패를 반영해야 합니다.
핵심 요약
- 합의가 위험한 실패 모드입니다. 단일 에이전트는 자신의 가정에 도전할 수 없습니다. 서로 다른 평가 우선순위를 가진 두 개의 독립적인 에이전트가 품질 게이트와 철학으로는 해결할 수 없는 구조적 사각지대를 포착합니다.
- 두 개의 게이트가 하나보다 낫습니다. 프로세스 중 합의 검증은 문제를 조기에 잡습니다. 세션 종료 시 자부심 검증은 단계 전반에 걸쳐 누적된 문제를 잡습니다. 검증을 서로 다른 라이프사이클 지점의 두 개의 훅으로 분리하는 것은 실패가 실제로 발생하는 방식에 매핑됩니다.
- 선택적으로 숙의하십시오. 신뢰도 모듈은 결정의 약 10%에서 숙의를 트리거합니다. 모든 것에 숙의하면 토큰이 낭비됩니다. 아무것에도 숙의하지 않으면 독립적 관점이 가장 중요한 결정을 놓치게 됩니다.
FAQ
멀티 에이전트 숙의의 결정당 비용은 얼마입니까?
3개 에이전트 숙의는 Opus 가격 기준으로 API 토큰에서 약 $0.68-0.90입니다(15,000-24,000개의 추가 토큰). 10개 에이전트 전체 패널은 $2.25-3.00입니다. 시스템은 결정의 약 10%에서 숙의를 트리거하므로, 모든 결정에 걸친 분할 비용은 코딩 세션당 $0.23-0.30입니다.
모든 결정에 숙의가 필요합니까?
아닙니다. 신뢰도 모듈은 네 가지 차원(모호성, 복잡성, 위험도, 컨텍스트 의존성)에 걸쳐 결정을 점수화합니다. 전체 신뢰도가 0.70 미만인 결정만 숙의를 트리거하며, 전체 결정의 약 10%입니다. 문서 수정, 변수명 변경, 일상적인 편집은 숙의를 완전히 건너뜁니다. 보안 아키텍처, 데이터베이스 스키마 변경, 되돌릴 수 없는 배포는 일관되게 트리거됩니다.
Claude 외의 다른 모델에서도 작동합니까?
아키텍처 원칙(독립적 평가, 구조화된 투표, 2단계 게이트 검증)은 페르소나 지시를 따르고 구조화된 출력을 생성할 수 있는 모든 LLM에 적용됩니다. 구현은 에이전트 생성을 위해 Claude Code 훅과 Task 도구를 사용하며, 이는 Claude 전용 인프라입니다. 다른 모델로 포팅하려면 상태 머신, 순위 시스템, 검증 게이트를 유지하면서 생성 메커니즘과 프롬프트 템플릿을 교체해야 합니다.
불일치를 생성하도록 설계된 시스템을 어떻게 테스트합니까?
세 개의 계층에 걸친 141개의 테스트: 48개의 bash 통합 테스트가 훅 동작(합의 흐름, 자부심 검증 게이트, 재귀 가드)을 검증하고, 81개의 Python 단위 테스트가 결정론적 입력으로 각 라이브러리 모듈을 커버하며, 12개의 엔드투엔드 테스트가 고정된 에이전트 응답으로 전체 숙의 파이프라인을 시뮬레이션합니다. E2E 테스트는 성공 경로(생산적 불일치가 합의에 도달)와 실패 경로(성급한 합의, 수렴 실패, 예산 소진) 모두를 커버합니다.
숙의의 지연 시간 영향은 어떻습니까?
3개 에이전트 숙의는 30-60초의 실제 소요 시간을 추가합니다(에이전트는 Task 도구를 통해 순차적으로 실행됩니다). 10개 에이전트 숙의는 2-4분을 추가합니다. 합의 및 자부심 검증 훅은 각각 200ms 이내에 실행됩니다. 주요 병목은 오케스트레이션 오버헤드가 아닌 에이전트당 LLM 추론 시간입니다. 숙의가 필요한 결정의 경우, 지연 시간은 수용 가능합니다. 대안(나중에 실수를 발견하는 것)이 훨씬 더 많은 시간이 소요되기 때문입니다.
참고 문헌
-
저자의 숙의 컨텍스트 격리 모듈.
~/.claude/lib/deliberation/context_isolation.py에 구현. 네 가지 격리 수준: L0 (시스템 규칙, 공유), L1 (세션 컨텍스트, 공유), L2 (에이전트 초점, 비공개), L3 (도메인 패턴, 페르소나별). ↩ -
저자의 숙의 설정. 임계값은
~/.claude/configs/deliberation-config.json에 정의. ↩ -
저자의 숙의 후 합의 훅.
~/.claude/hooks/post-deliberation.sh에 구현, PostToolUse:Task에 연결. ↩ -
Heuer, Richards J., Psychology of Intelligence Analysis, Center for the Study of Intelligence, CIA, 1999. 8장: Analysis of Competing Hypotheses. 전문 (CIA). ↩
-
Nemeth, Charlan, In Defense of Troublemakers: The Power of Dissent in Life and Business, Basic Books, 2018. 참조: Nemeth, C. J., “Differential Contributions of Majority and Minority Influence,” Psychological Review, 93(1), 23-32, 1986. ↩
-
Surowiecki, James, The Wisdom of Crowds: Why the Many Are Smarter than the Few, Doubleday, 2004. 1장. ↩
-
Choi, H. K., Zhu, X., and Li, S., “Debate or Vote: Which Yields Better Decisions in Multi-Agent Large Language Models?” NeurIPS 2025 Spotlight. arXiv:2508.17536. ↩
-
Kaesberg, L. B. et al., “Voting or Consensus? Decision-Making in Multi-Agent Debate,” Findings of ACL 2025, pp. 11640-11671. ACL Anthology. ↩
-
Wu, H., Li, Z., and Li, L., “Can LLM Agents Really Debate? A Controlled Study of Multi-Agent Debate in Logical Reasoning,” arXiv:2511.07784, 2025. ↩
-
Wynn, A., Satija, H., and Hadfield, G., “Talk Isn’t Always Cheap: Understanding Failure Modes in Multi-Agent Debate,” arXiv:2509.05396, 2025. ↩
-
Liang, T. et al., “Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate,” EMNLP 2024, pp. 17889-17904. ACL Anthology. ↩
-
저자의 재귀 가드.
~/.claude/hooks/recursion-guard.sh의 생성 예산 모델.~/.claude/state/agent-lineage.json에서 에이전트 계보 추적. ↩ -
저자의 신뢰도 모듈.
~/.claude/lib/deliberation/confidence.py에 구현. 네 가지 차원: 모호성, 복잡성, 위험도, 컨텍스트 의존성. ↩ -
저자의 테스트 스위트.
~/.claude/tests/test-deliberation-pipeline.sh에 48개의 bash 테스트,~/.claude/tests/test_deliberation_lib.py에 81개의 Python 테스트,~/.claude/tests/test_deliberation_e2e.py에 12개의 E2E 테스트. ↩