start

name	start
description	다분야 전문가를 동적으로 선정해 구조화된 토론으로 다각적 평가·제언을 정리합니다. "전문가에게 묻고 싶다", "리뷰해줘", "다각적으로 평가해줘", "토론해줘" 등의 표현에서 발동됩니다. 웹사이트, 코드, 사업 전략, 디자인, 조직 설계 등 모든 도메인에 대응합니다.
argument-hint	[의제 또는 대상 (URL, 파일, 텍스트 등)]

Roundtable — 전문가 원탁회의

다분야의 세계 최고 수준 전문가를 동적으로 선정하고, 구조화된 토론으로 평가·제언을 정리합니다.

설계 원칙

이 스킬은 다음 학술적 지견에 근거해 설계되었습니다.

• 독립된 의견 생성을 먼저 한다 (델파이 기법, Nominal Group Technique)
• 반대 의견을 구조적으로 보장한다 (Devil's Advocate, Red Team)
• 반복은 최대 2라운드 (MAD 연구: 3라운드 이상은 Degeneration of Thought를 초래)
• 소수 의견을 구조적으로 보호한다 (Groupthink 회피)
• 오케스트레이터는 Phase 1-2에서 프로세스 관리에 전념하고, Phase 3에서 통합자로서 추천을 낸다
• 전문가 패널은 Phase 0에서 확정한다. 토론 도중에 추가·교체하지 않는다

언제 사용하는가

• 다각적인 평가·리뷰를 원할 때
• 전문가 의견을 듣고 싶을 때
• 여러 관점에서 토론을 심화하고 싶을 때
• 놓친 부분이나 리스크를 찾아내고 싶을 때

언제 사용하지 않는가

• 답이 하나로 정해지는 사실 확인 (검색으로 충분)
• 단순 버그 수정이나 오타 수정
• 전문 지식이 필요 없는 작업

전체 파이프라인

Phase 0: 의제 분석·전문가 선정 (오케스트레이터 단독)
Phase 1: 독립 분석 (각 전문가가 병렬. 다른 의견은 보지 않음)
Phase 2: 구조화된 토론 (대립점을 중심으로 최대 2라운드)
Phase 3: 통합·평결 (소수 의견을 명시적으로 체크)
Phase 4: 사용자에게 보고

Quick 심도의 경우: Phase 2를 건너뜀 (독립 분석 → 통합 → 보고).

---

Phase 0: 의제 분석·전문가 선정

오케스트레이터(당신 자신)가 메타 레벨에서 전체를 설계하는 단계입니다. Phase 1-2에서는 프로세스 관리에 전념하고, Phase 3에서는 통합자로서 추천을 냅니다.

0-1. 의제의 구조화

사용자의 입력에서 다음을 명확히 합니다:

1. 의제: 무엇을 토론할 것인가 (한 문장으로)
2. 대상물: URL, 파일, 텍스트, 이미지 등. 취득 가능한 것은 취득한다
   • URL → WebFetch로 취득
   • 파일 경로 → Read로 취득
   • Figma URL → Figma MCP로 취득 (이용 가능한 경우)
   • 텍스트 → 그대로 사용
3. 평가 기준: 무엇을 기준으로 좋다/나쁘다고 할 것인가. 사용자가 명시하지 않은 경우 의제에서 추정하여 제시

Standard / Deep의 경우, 구조화 과정에서 다음도 검증합니다:

• 이 의제의 암묵적 전제는 무엇인가
• 의제의 답이 나왔다고 할 때, 사용자의 본래 목적은 달성되는가
• 더 적절한 프레이밍은 없는가

문제를 발견한 경우:

• Standard: 0-5의 승인 제시 시 "의제를 다음과 같이 재정의했습니다"라고 설명
• Deep: 재정의 선택지를 제시하고, 사용자에게 선택을 요청

0-2. 패널 크기와 토론 심도의 판정

패널 크기와 토론 심도는 독립된 두 축이며, 각각 판정합니다.

패널 크기 (의제가 필요로 하는 전문 영역의 수로 결정)

"이 의제에 관련된 이해관계자는 몇 명인가"로 판단합니다.

의제의 성질	전문가 수	예시
단일 도메인의 명확한 문제	3명 + DA	정규표현식의 정확성, 특정 API 설계
복수 도메인이 얽힌 문제	4-5명 + DA	기능 설계, 기사 리뷰, 기술 선정
많은 이해관계자에 영향을 주는 문제	6-7명 + DA	사이트 리뉴얼, 사업 전략, 조직 설계

• 최소: 3명 + DA = 4명
• 최대: 7명 + DA = 8명
• DA는 의제에 관계없이 항상 1명 (전문가 슬롯과는 별도)
• 같은 시점의 전문가를 2명 이상 뽑지 않는다 (만드는 쪽 + 받는 쪽, 제안 측 + 평가 측의 쌍을 의식)

토론 심도 (리스크·대립 가능성·사용자의 의도로 결정)

시그널	Deep	Standard	Quick
영향 범위	사업 전체·다수 사용자	특정 기능·한정 사용자	개인 프로젝트
리스크	보안·금전·법률	중간 정도	낮음
대립 가능성	복수의 정답이 있을 듯	다소 대립	거의 합의할 듯
사용자 명시	"철저하게", "깊이"	지정 없음	"가볍게", "슬쩍"

• Quick: Phase 2 건너뜀. 참조 파일을 읽지 않음. SKILL.md 본체로 완결 에스컬레이션: Phase 1의 결과에서 권장 액션의 방향성이 모순되는 케이스 (예: "기능 A를 삭제해야 함" vs "기능 A를 확충해야 함")가 2개 이상 있는 경우, Standard로 승격을 사용자에게 제안
• Standard: 최대 2라운드. deliberation-rules.md + output-format.md를 읽음
• Deep: 최대 2라운드 + 세컨드 찬스. 모든 참조 파일을 읽음

패널 크기와 심도는 독립적: 6명 + DA의 Quick(많은 시점으로 가볍게 평가)도, 3명 + DA의 Deep(소수의 시점으로 철저 토론)도 가능합니다.

0-3. 전문가의 동적 선정

선정의 원리 (키워드 매칭이 아닌 원리로 판단):

1. "이 의제에서 실패했을 때, 누가 가장 먼저 알아차리는가?" → 그 시점을 가진 전문가가 필요 (직접 관련 전문가)

2. "이 의제의 수용자·영향을 받는 사람은 누구인가?" → 만드는 쪽뿐 아니라, 수용자(사용자, 독자, 이용자)의 시점을 포함 예: 기사 리뷰에 타깃 독자, API 설계에 API 이용자

3. "이 의제에서 간과되기 쉬운 관점은 무엇인가?" → 인접 도메인의 전문가를 포함 예: 이커머스 사이트 평가에 접근성 전문가, 사업 전략에 엔드 유저의 시점

4. "이 의제에서, 일반적으로는 소집되지 않지만 사실 중요한 지견을 가진 분야가 있는가?" → Step 1-3에서 선정한 전문가 리스트를 둘러본 후에 자문 → LLM의 학습 지식에는 "이 분야에는 이 전문성이 유효했다"는 지견이 포함되어 있다. 명시적으로 묻는 것으로, 물어보지 않으면 나오지 않는 지식을 끌어냄 예: AI 개발에 윤리철학자, 조직 설계에 생태학자, UX 설계에 인지심리학자 → 후보가 떠오르지 않으면 무리하게 넣지 않는다. 로직으로 판단한 결과 "넣어야 한다"고 판단한 경우에만 추가

5. Devil's Advocate를 1명 포함한다 (전문가 슬롯과는 별도) → 구조적으로 반대 의견을 내는 역할. 도메인 전문가가 아닌 비판의 전문가 "이 제안/대상의 약점은 무엇인가"를 철저히 찾는 것이 사명

선정의 체크:

• 같은 쪽의 전문가가 2명 이상 있지 않은가? (편집자 + 전략가는 "만드는 쪽 x 2")
• 수용자의 시점이 포함되어 있는가?
• 패널 크기는 의제의 복잡도에 맞는가?

Standard 이상의 경우 expert-archetypes.md를 참조하여, 도메인별 권장 전문가를 확인합니다.

0-4. 전문가 페르소나의 정의

각 전문가에 대해 다음을 정의합니다:

당신은 [분야]의 세계 최고 수준 전문가입니다.
[해당 분야에서의 구체적인 경험·실적을 1-2문장으로 설정]

## 당신의 사명
[이 의제에서의 구체적인 평가 관점]

## 판단 기준
[오케스트레이터가 정의한 평가 기준]

## 분석 시 주의사항
- 근거 없는 주장은 하지 않는다. 구체적인 이유·사례·데이터를 제시한다
- "문제없다"로 끝내지 않는다. 개선 여지가 있으면 반드시 지적한다
- 당신의 전문 영역 관점에서, 다른 전문가가 놓칠 만한 점에 주목한다

## 출력 포맷
1. **종합 평가**: ★☆☆☆☆ 〜 ★★★★★ (5단계)와 한 줄 평
2. **주요 발견**: 3-5점. 각 점에 구체적 근거를 첨부
3. **가장 중요한 우려**: 1점. 최우선으로 대처해야 할 문제
4. **권장 액션**: 우선순위를 포함한 3-5점

Devil's Advocate의 페르소나 정의:

당신은 비판적 분석의 전문가입니다.
...(위와 동일한 경험 설정)...

## 당신의 사명
이 [대상]의 약점·리스크·간과된 점을 철저히 찾아내는 것.
좋은 점을 찾을 필요는 없다. 다른 전문가가 "문제없다"고 판단한 점에야말로 의문을 던져라.

## 주의
- "반대를 위한 반대"가 아니다. 구체적 근거에 기반한 비판을 한다
- "만약 이것이 최악의 형태로 실패한다면, 어디가 원인인가?"를 항상 묻는다
- 사소한 문제가 아니라, 구조적·근본적 약점에 집중한다

0-5. 메타 판단의 출력

심도에 따라 승인 플로우가 달라집니다:

Quick의 경우: 승인을 기다리지 않고 즉시 Phase 1로 진행. 패널 구성은 리포트 첫머리에 기재.

[의제]에 대해 [N]명의 전문가 + Devil's Advocate로 분석합니다.
패널: [전문가 A], [전문가 B], ..., [Devil's Advocate]

Standard / Deep의 경우: 다음을 사용자에게 제시하고 승인을 받습니다.

**원탁회의 구성:**
- 의제: [구조화된 의제]
- 평가 기준: [정의된 기준]
- 심도: [Standard/Deep] — [이유]
- 추정 에이전트 기동: [N]회 (Phase 1: [n]명 병렬 + Phase 2: 최대 [m]회)
- 전문가 패널:
  1. [역할명] ([분야]) — [왜 이 전문가가 필요한가]
  2. [역할명] ([분야]) — [이유]
  3. [역할명] ([분야]) — [이유]
  4. Devil's Advocate ([비판의 초점]) — [무엇에 대해 비판하는가]

전문가의 추가·변경이 있으면 알려주세요.
없으면 이대로 회의를 시작합니다.

사용자가 전문가의 추가나 변경을 원하는 경우 반영합니다. 원칙적으로, Phase 1 개시 후 전문가의 추가·교체는 하지 않습니다. 예외: Phase 1 완료 후, 중대한 관점의 누락이 판명된 경우에 한해, 이유를 명기한 후 1명의 추가를 허용합니다. 추가된 전문가는 Phase 1의 독립 분석을 수행한 후 Phase 2에 참가합니다.

---

Phase 1: 독립 분석

가장 중요한 규칙: 다른 전문가의 의견을 보여주지 않는다.

실행 방법의 선택

Phase 1에서는 독립성이 가장 중요. Phase 2에서는 대립점의 심도 있는 탐구가 중요. 각각에 최적의 실행 방식이 다릅니다 (하이브리드 방식).

Phase 1: 서브 에이전트로 병렬 기동 (독립성을 구조적으로 보장)

• Claude Code: Agent tool로 run_in_background: true로 병렬 기동
• Cursor: 서브 에이전트를 병렬 기동
• 각 에이전트는 독립된 컨텍스트를 가지며, 다른 전문가의 존재를 알지 못함

모델 혼합 (크로스 프로바이더 환경에서만 권장): 다른 프로바이더의 모델을 전문가별로 할당함으로써, 동일 모델의 유사 다양성 문제를 완화할 수 있습니다. MAD 연구에서 가장 안정적인 효과가 확인된 기법.

• Cursor: 서브 에이전트의 model 필드에서 다른 프로바이더 지정 가능 (예: 전문가 A = Claude, 전문가 B = GPT, DA = Gemini)
• 동일 패밀리 내에서의 혼합은 비권장: 같은 프로바이더 내에서 모델을 바꾸면 (예: 상위 모델 + 하위 모델), 다양성이 아닌 성능 차이가 생김. 특정 에이전트만 "똑똑해져서" 공정한 토론이 성립하지 않음
• 모델 혼합이 불가능한 경우에도, 스킬은 정상 동작합니다 (단일 모델로 실행)

Phase 2: 대립점마다 최적의 방식을 선택

• 오케스트레이터 중개 (기본): 오케스트레이터가 대립점 요약을 전달하고, 각 에이전트로부터 개별적으로 반론을 수거. 정보량을 통제할 수 있고 sycophancy를 방지하기 쉬움
• Agent Teams로 직접 토론 (이용 가능한 경우의 옵션): 특정 대립점에서 2명의 전문가가 깊이 있게 파고들 필요가 있는 경우, SendMessage로 직접 대화시킴. 오케스트레이터의 요약에 의한 정보 손실을 피할 수 있음. 다만 Agent Teams는 실험적 기능이며, 이용 가능한 환경에서만 사용

서브 에이전트 이용 불가 (fallback): 먼저 사용자에게 통지하고, 속행 확인을 받음. "서브 에이전트의 병렬 실행이 이용 불가하므로, 순차 실행으로 대체합니다. 독립성 보장이 제한적이 됩니다. Quick 심도로 변경하시겠습니까?" 사용자가 속행을 선택한 경우, 각 전문가를 순차 실행합니다. 독립성을 유사하게 담보하기 위해, 다음 규칙을 지킵니다:

• 전문가 A의 분석을 생성한 후, 전문가 B의 분석 시 A의 출력을 참조하지 않음
• 각 전문가의 출력은 개별적으로 기록하고, 전원 분이 갖춰진 후 Phase 2로 진행
• 한계: 동일 컨텍스트 내 순차 실행에서는, 이전 출력이 물리적으로 남기 때문에 독립성은 완전히 보장되지 않음. 병렬 실행과 비교해 품질이 저하될 가능성 있음. 리포트의 "토론의 한계" 섹션에 그 취지를 기재할 것

진행 피드백

각 페이즈 시작 시 사용자에게 중간 보고:

• Phase 1 시작: "[전문가명] 등 N명 + Devil's Advocate가 독립 분석을 시작합니다"
• Phase 2 시작 (해당하는 경우): "X개의 대립점에 대해 토론을 시작합니다"
• Phase 3 시작: "통합·평결을 진행합니다"

각 에이전트에게 전달하는 것:

1. 페르소나 정의 (Phase 0에서 작성)
2. 의제 설명
3. 대상물 (텍스트, URL 취득 결과, 파일 내용 등)
4. 평가 기준

각 에이전트에게 전달하지 않는 것:

• 다른 에이전트의 존재나 의견
• "정답을 내주세요" 등의 지시 (연구에서 효과 없음 ~ 역효과)
• 투표 결과나 다수파 정보

모든 에이전트의 분석이 갖춰지면 Phase 2로 진행. Quick 심도의 경우 Phase 2를 건너뛰고 Phase 3로 직행합니다.

Quick 심도에서의 DA 보호: Quick에서는 Phase 2가 건너뛰어지므로, DA의 비판이 토론에서 심도 있게 탐구되지 않습니다. Phase 3에서 DA의 출력을 소수 의견과 동등하게 보호적으로 다루며, DA가 지적한 점 중 다른 전문가가 언급하지 않은 점은 소수 의견 체크의 대상에 반드시 포함시킵니다.

---

Phase 2: 구조화된 토론 (Standard / Deep만)

분석 결과의 정리

Phase 1의 전체 결과를 오케스트레이터가 분석하고, 3가지로 분류합니다:

1. 합의점: 전원이 일치하는 점 → 더 이상 토론 불필요
2. 대립점: 의견이 갈린 점 → 토론의 초점
3. 소수 의견: 1명만 지적한 점 → 보호 대상으로 플래그

대립점이 없으면 Phase 3로 진행.

Round 1: 대립점에 대한 반론

대립점에 대해, 관련된 에이전트에게만 반론을 요청 (선택적 참가).

"관련된"의 판정 기준 (오케스트레이터의 자의성을 방지):

• Phase 1에서 해당 논점에 직접 언급한 전문가
• 해당 논점이 전문 영역에 포함되는 전문가
• 선택의 이유는 리포트의 "토론 프로세스" 섹션에 기재

에이전트의 컨텍스트 재구성 (서브 에이전트는 스테이트리스이므로): Phase 2의 에이전트에게는 다음을 전달하여, Phase 1에서의 자신의 분석을 재인식시킵니다:

1. Phase 1과 동일한 페르소나 정의
2. Phase 1에서의 해당 에이전트 자신의 출력 전문
3. 대립점의 요약 (아래 템플릿)

요약의 대칭성 체크 (Deep만. 오케스트레이터의 요약 편향을 완화): 대립점의 요약을 작성하면, 전달하기 전에 각 에이전트에게 "이 요약이 당신의 주장을 정확히 반영하고 있는가? 수정이 있으면 지정해주세요" 라고 확인. 수정이 있으면 반영 후 토론을 시작. 주의: 동일 모델 환경에서는, 프레이밍 편향의 검출이 구조적으로 어렵습니다 (체크하는 쪽도 같은 프레이밍 경향을 가짐). 누락이나 사실 오인의 검출에는 유효하지만, 과신하지 말 것.

Standard의 경우: 대칭성 체크는 생략하고, 대신 요약과 함께 원래 출력의 해당 부분을 인용으로 전달합니다 (요약에만 의존하는 것을 완화).

각 에이전트에게 전달할 것:

당신의 분석에 대해, 다른 전문가로부터 다른 견해가 나왔습니다.

[대립점의 요약]:
- 당신의 견해: [요약]
- 다른 견해: [요약]

이 대립에 대해, 당신의 관점에서 다시 분석해주세요.
의견을 바꾸는 경우도, 유지하는 경우도, 구체적인 근거를 제시해주세요.

각 에이전트에게 전달하지 않을 것:

• 누가 다수파인지 하는 정보 (소수 의견의 억제를 방지)
• 다른 에이전트의 모든 발언 (요약 차분만)

Agent Teams에 의한 직접 토론 (옵션)

Agent Teams가 이용 가능한 환경에서, 다음 조건을 만족하는 대립점이 있는 경우, 2명의 전문가를 직접 대화시킬 수 있습니다:

• 조건: 2명의 전문가가 특정 논점에서 구체적 근거를 제시하며 대립하고 있다
• 방법: 오케스트레이터가 대립하는 2명의 에이전트에게 SendMessage로 대화를 촉구
• 상한: 직접 대화는 각 대립점당 왕복 2회까지 (Round 1 + Round 2의 범위 내)
• 주의: 직접 대화 중에도 오케스트레이터는 대화 내용을 감시하고, sycophancy (한쪽이 상대에 동조해 의견을 바꿈)의 조짐이 있으면 개입

직접 토론을 사용하지 않는 경우, 위의 오케스트레이터 중개 방식으로 Round 1을 실시합니다.

Round 2: 심화 (대립이 남은 경우에만)

Round 1에서 수렴하지 않은 논점에 대해:

• Devil's Advocate에게 "현재의 합의 경향의 약점은 무엇인가"를 질문
• 다른 에이전트에게 새로운 논점이 있는지 확인

수렴 조건 (어느 하나를 만족하면 종료):

1. 모든 에이전트가 같은 결론에 도달
2. 이전 라운드와 비교해 새로운 구체적 증거·데이터·사례를 포함한 논점이 나오지 않음 (동일 주장의 재서술은 신규 논점으로 인정하지 않음)
3. Round 2에 도달 (하드 캡. 추가 라운드는 정밀도 향상에 기여하지 않음)

---

Phase 3: 통합·평결

오케스트레이터가 통합자로서 최종적인 추천을 내는 단계. Phase 1-2에서는 프로세스 관리에 전념했지만, 여기서는 사전 정의된 기준에 근거해 판단을 행합니다.

3-1. 합의 사항의 정리

모든 전문가가 일치한 점을 불릿으로 정리.

3-2. 대립의 해결

대립이 남은 점에 대해, 다음 기준으로 가중치를 부여:

• 근거의 구체성: 코드 예시·데이터·사양서 인용을 포함하는 의견 > 추상적 의견
• 전문 영역과의 일치도: 해당 논점에 가장 관련된 전문가의 의견을 중시
• 반론에 대한 응답 품질: 반론에 구체적으로 응답한 의견 > 무시한 의견

사용하지 않는 것: 에이전트의 자기 신고에 의한 확신도 (연구에서 과신이 확인되어 신뢰 불가)

3-3. 소수 의견 체크 (필수·모든 심도에서 생략 불가)

1. 다수파의 결론과 모순되는 소수 의견을 모두 리스트업
2. 각 소수 의견을 다음 2축으로 판정:

	근거 있음	근거 없음
영향 큼 (놓치면 중대한 문제)	반드시 채택	채택 (리스크가 높으므로)
영향 작음 (놓쳐도 경미)	채택 권장	기각 가능 (이유 명기)

3. 기각하는 경우 구체적 이유를 기술 ("다수파니까"는 불가)
4. 최종 리포트에 소수 의견 섹션을 포함 (소수 의견이 없는 경우도 명기)

3-4. 세컨드 찬스 (Deep만)

2단계 확인 (통합 결과를 보여준 후의 sycophancy를 방지):

1. Step 1 (사전 커밋): 통합 결과를 보여주기 전에, 각 에이전트에게 "Phase 1-2에서의 당신의 결론은 지금도 변함없는가? 변했다면 이유를 말해라"라고 확인
2. Step 2 (통합 결과의 제시와 차분 검출): 통합 결과의 요약을 보여주고, "당신의 결론과 통합 결과에 차분이 있는 경우, 지적해주세요"라고 질문

의견 변경의 판정 룰 (차분의 유무가 아닌, 변경 이유의 질로 판단):

• 변경 이유에 새로운 근거 (데이터, 사례, 논리적 추론)가 있음 → 정당한 변경으로 채택
• 변경 이유가 "통합 결과를 보고 납득했다" 수준 → sycophancy의 조짐. 원래 의견을 존중
• Step 1에서 "변함없다"고 답했는데 Step 2에서 근거 없이 의견을 바꾼 경우도 마찬가지

여기서 나온 정당한 지적은 최종 리포트에 반영합니다.

---

Phase 4: 사용자에게 보고

출력 포맷의 상세는 output-format.md를 참조. 다음은 필수 섹션:

# 원탁회의 리포트: [의제]

## 이그제큐티브 서머리
[3-5행으로 결론. 가장 중요한 발견과 권장 액션을 포함]

## 전문가 패널
| 전문가 | 역할 | 종합 평가 |
|---|---|---|
| [이름] | [분야] | ★★★★☆ |

## 합의 사항
[모든 전문가가 일치한 점]

## 주요 쟁점과 결론
### [논점 1]
- **결론**: [채택된 견해]
- **찬성 측 근거**: [구체적으로]
- **반대 측 근거**: [구체적으로]
- **판단 이유**: [왜 이쪽을 채택했는가]

## 소수 의견 (놓쳐서는 안 될 지적)
[1명만 지적했지만 중요한 점. 기각한 경우 그 이유]

## 권장 액션
1. **[최우선]** ...
2. **[높음]** ...
3. **[중간]** ...

## 토론의 한계
- 이 분석은 [단일 LLM 모델 / 복수 모델 혼합]에 의한 페르소나 기반 토론이며, [모델 고유의 맹점은 검출 불가 / 모델 다양성으로 완화되지만 완전하지는 않음]
- [이 토론에서 커버할 수 없었던 관점, 추가 조사가 필요한 점]

불확실성의 표현

확신도에 따라 문체를 구분해 사용:

확신도	문체	사용 장면
높음	"~이다", "~이 필요"	전원 합의 + 구체적 근거 있음
중간	"~라고 생각된다", "~이 권장된다"	다수파 합의 or 조건부 결론
낮음	"~의 가능성이 있다", "~을 검토해야 한다"	소수 의견 or 근거가 한정적

리포트 제시 후, 사용자로부터 추가 질문이나 심도 있는 요청이 있으면 대응합니다.

---

설계의 한계

이 스킬의 구조적 한계를 이해한 후에 사용할 것.

1. 델파이 기법에 가까운 구조: 서브 에이전트 방식(기본)에서의 Phase 1→2는, MAD 연구가 전제로 하는 스테이트풀한 동적 토론이 아닌, 델파이 기법에 가까운 "구조화된 독립 리뷰의 통합"입니다. Agent Teams 직접 토론 옵션을 사용한 경우에만, 국소적으로 동적인 주고받음이 실현됩니다

2. 동일 모델의 유사 다양성: 모든 에이전트가 동일한 LLM 모델이며, 페르소나의 차이에 의한 다양성은 본질적으로 한정됩니다. 모델 고유의 편향은 검출할 수 없습니다. 고위험·고영향 의제에서는 사람 전문가의 확인을 권장합니다

3. 오케스트레이터의 요약 편향: Phase 2에서 대립점을 요약할 때, 오케스트레이터의 프레이밍이 토론의 방향을 좌우합니다. deliberation-rules.md의 요약 품질 룰로 완화하지만, 완전히 배제할 수는 없습니다

---

참고 자료 (심도에 따라 로딩)

Quick: 참조 파일을 읽지 않음. SKILL.md 본체로 완결됩니다. Standard: deliberation-rules.md + output-format.md를 읽음. Deep: 모든 참조 파일을 읽음.

파일	내용	읽는 조건
expert-archetypes.md	전문가 아키타입 집·선정 원리	Deep, 또는 전문가 선정에 망설였을 경우
deliberation-rules.md	토론 룰·수렴 조건·소수 의견 보호	Standard 이상
output-format.md	출력 포맷 상세	Standard 이상

---

설계 참고: 델파이 기법, Nominal Group Technique, Six Thinking Hats (de Bono), Devil's Advocate, Adversarial Collaboration (Kahneman), Multi-Agent Debate (Du et al. 2023), S2-MAD (NAACL 2025), CONSENSAGENT (ACL 2025), Groupthink (Janis 1972)