Agent Research
에이전트 팀 기반 종합 리서치 스킬. 조사 대상의 성격을 분석하여 전문가 풀에서 최적의 에이전트를 동적으로 선택하고, 교차 검증을 거쳐 분석적 종합 보고서를 산출한다.
실행 모드: 에이전트 팀
전문가 풀
리더는 아래 11개 전문가 중에서 조사 대상에 맞는 2~6개를 선택한다.
| ID |
전문가 |
조사 영역 |
적합한 대상 |
official |
공식 정보 조사관 |
공식 문서, 1차 소스, 기술 문서, GitHub, API |
기술/제품/서비스/기업/정책 |
media |
미디어 분석관 |
미디어 보도, 기사, 영상 콘텐츠, 인터뷰 |
거의 모든 대상 |
community |
커뮤니티 분석관 |
Reddit, HN, Twitter, 포럼, 블로그 |
기술/제품/인물/논란 |
academic |
학술 연구관 |
논문, 학회, 연구 트렌드 |
기술/과학/의료/인물(학자) |
financial |
재무 분석관 |
재무제표, 투자, 밸류에이션, 주가 |
기업/산업/경제 이슈 |
industry |
산업·경쟁 분석관 |
시장 규모, 경쟁사, SWOT, 트렌드 |
기업/제품/산업 |
reputation |
평판 조사관 |
고객 리뷰, 직원 평판, 여론, 논란 |
기업/제품/인물 |
career |
경력·배경 조사관 |
학력, 경력, 인적 네트워크 |
인물 |
works |
업적·저작 조사관 |
논문, 특허, 수상, 프로젝트 성과 |
인물(학자/창업자/개발자) |
technical |
기술 심층 분석관 |
아키텍처, 벤치마크, 코드, 성능, 보안 |
기술/제품/오픈소스 |
policy |
규제·정책 분석관 |
법률, 규제, 정책, 윤리, 컴플라이언스 |
산업/기술/사회 이슈 |
프롬프트 템플릿: references/agent-prompts.md
조사 깊이 선택
| 깊이 |
트리거 |
에이전트 수 |
검색 횟수/에이전트 |
특징 |
| quick |
간단히, 빠르게, 요약, 개요 |
2~3개 |
5~8회 |
핵심 정보만. 교차 검증·보충 생략 |
| standard (기본) |
미지정 |
3~4개 |
10~15회 |
기본 조사 + 교차 검증 + 선택적 보충 |
| deep |
심층, 깊이, 상세히, 철저히 |
4~6개 |
15~25회 |
다단계 검색 + 교차 검증 + 필수 보충 + 1차 소스 추적 |
워크플로우
Phase 1: 대상 분석 및 팀 설계
이 Phase가 핵심이다. 리더가 조사 대상을 분석하여 최적의 팀을 구성한다.
1단계: 대상 파악
- 사용자 입력에서 조사 대상, 조사 깊이, 출력 경로, 조사 기간 파악
- 입력이 파일이면 읽어서 주제 추출, 텍스트면 그대로 사용
- 핵심 키워드 3~5개 도출
2단계: 조사 차원 식별
조사 대상의 성격에 따라 어떤 차원의 조사가 필요한지 판단한다:
| 대상 성격 |
필수 차원 |
선택 차원 |
| AI 신기술 |
official, technical |
media, community, academic |
| 상장 기업 |
official, financial, industry |
reputation, media |
| 스타트업 |
official, financial |
industry, media, reputation |
| 학자/연구자 |
career, works, academic |
media, influence→reputation |
| CEO/창업자 |
career, works |
media, reputation, financial |
| 정치인/공인 |
career, media |
reputation, policy |
| 규제/정책 이슈 |
policy, official |
media, community, industry |
| 오픈소스 프로젝트 |
official, technical, community |
media, academic |
| 사회적 논란 |
media, community |
policy, reputation, official |
| 제품/서비스 |
official, technical |
media, community, industry |
위 표는 가이드라인이다. 리더는 대상의 고유한 특성을 분석하여 자유롭게 조합한다.
사용자가 특정 관점을 명시적으로 요청한 경우 (예: "재무 중심으로", "커뮤니티 반응 위주로") 해당 전문가를 반드시 포함한다.
media 전문가 포함 판단 기준:
media를 제외하면 미디어 보도 수집이 다른 에이전트에 분산되어 깊이가 얕아질 수 있다. 다음 경우 media를 반드시 포함한다:
- 대상이 대중적 관심이 높은 이슈 (광범위한 미디어 보도 예상)
- 미디어 논조 분석(호의적/비판적 분류)이 보고서 핵심일 때
- 영상 콘텐츠(YouTube, 팟캐스트) 분석이 필요할 때
- 에이전트 수 예산에 여유가 있을 때 (4개 이상)
media 제외 시: official(공식 보도), community(여론/반응), reputation(평판 보도)이 미디어 영역을 분담. 단, 미디어 보도의 논조 분석 깊이는 떨어짐을 인지.
3단계: 팀 구성 결정
깊이에 따라 에이전트 수를 결정하고, 전문가 풀에서 선택한다:
선택 기준:
1. 조사 대상에 필수적인 차원의 전문가를 먼저 선택
2. 깊이 예산 내에서 선택 차원의 전문가를 추가
3. 전문가 간 시너지를 고려 (예: financial + industry는 상호 보완적)
4. 사용자가 명시적으로 요청한 관점이 있으면 반드시 포함
결정 사항 기록 (리더가 팀 구성 근거를 _workspace/team_design.md에 기록):
# 팀 설계
## 조사 대상: {target}
## 핵심 키워드: {keywords}
## 조사 깊이: {depth}
## 조사 기간: {time_range}
## 선택된 전문가 ({N}명)
| # | 전문가 | 선택 이유 |
|---|--------|----------|
| 1 | {specialist} | {이 전문가가 필요한 이유} |
| 2 | {specialist} | {이 전문가가 필요한 이유} |
| ... | ... | ... |
## 제외된 전문가 (해당 시)
| 전문가 | 제외 이유 |
|--------|----------|
| {specialist} | {불필요한 이유} |
## 보고서 구조 (예상)
{선택된 전문가에 기반한 보고서 섹션 구조}
4단계: 조사 기간 결정 (사용자 미지정 시 기본 3개월):
| 옵션 |
기간 |
적용 시점 |
최신 / 긴급 / 1주 |
최근 1주일 이내 |
방금 발표된 뉴스, 핫이슈 |
최근 / 1달 |
최근 1개월 이내 |
비교적 최신 동향 |
| 기본값 (미지정) |
최근 3개월 이내 |
일반적인 리서치 |
Phase 2: 팀 구성 및 병렬 조사 시작
1단계: TeamCreate로 팀 생성 + 팀원 스폰
TeamCreate(
team_name: "research-{slug}",
members: [
{
name: "{specialist-1}-researcher",
agent_type: "general-purpose",
model: "opus",
prompt: // references/agent-prompts.md 템플릿을 커스터마이즈 (아래 규칙 참조)
},
{
name: "{specialist-2}-researcher",
agent_type: "general-purpose",
model: "opus",
prompt: // ...
},
// ... N개 팀원
]
)
TeamCreate 호출 시 모든 팀원이 즉시 스폰된다. 별도로 에이전트를 개별 실행할 필요 없다.
2단계: TaskCreate로 작업 등록
TaskCreate(tasks: [
{ title: "{specialist-1} 조사", description: "{조사 지시}", assignee: "{specialist-1}-researcher" },
{ title: "{specialist-2} 조사", description: "{조사 지시}", assignee: "{specialist-2}-researcher" },
// ... N개 조사 태스크
{ title: "교차 검증", description: "리더가 수행", assignee: "leader", depends_on: ["조사 태스크 전체"] },
{ title: "종합 보고서", description: "리더가 수행", assignee: "leader", depends_on: ["교차 검증"] }
])
팀원들은 자신에게 할당된 태스크를 자동으로 수행하고, 완료 시 TaskUpdate로 상태를 갱신한다.
프롬프트 커스터마이즈 규칙:
- references/agent-prompts.md의 해당 전문가 기본 템플릿을 가져온다
{target} 변수를 조사 대상으로 치환
{keywords} 변수를 핵심 키워드로 치환
{teammate_list}를 실제 선택된 팀원 목록으로 치환
- 교차 공유 트리거를 실제 팀원 구성에 맞게 조정 (없는 팀원에게 공유하도록 되어 있으면 가장 가까운 역할의 팀원으로 대체하거나, 없으면 리더에게 공유)
- 대상 특성에 맞는 추가 조사 지시를 프롬프트에 삽입
Phase 3: 리더 모니터링 및 팀 조율
TeamCreate 후 팀원들은 자율적으로 조사를 수행한다. 리더는 다음을 수행:
모니터링:
TaskGet으로 전체 태스크 진행 상황 확인
- 팀원이 유휴 상태가 되면 자동 알림 수신
- 특정 팀원이 막혔다는 SendMessage를 보내면 키워드 제안 등으로 지원
개입이 필요한 상황:
- 팀원이 조사 범위 확장을 요청 → 승인/거부 판단
- 상충 정보가 교차 공유됨 → Phase 4에서 해결할 것을 메모
- 팀원이 에러로 중지 → 1회 재시도 또는 나머지 결과로 진행 결정
모든 팀원 공통 행동:
general-purpose 타입 (WebSearch, WebFetch 필요)
- 교차 공유 의무: 조사 중 다른 팀원에게 유용한 정보 발견 시
SendMessage로 즉시 공유
- 완료 시
TaskUpdate로 태스크 완료 처리 + SendMessage로 리더에 보고
에이전트 간 교차 공유 프로토콜
에이전트들은 조사 중 다음 상황에서 다른 팀원에게 SendMessage로 정보를 공유한다:
| 발견 상황 |
공유 행동 |
| 다른 팀원 전문 영역의 중요 정보 발견 |
해당 팀원에게 직접 공유 |
| 상충 정보 발견 |
관련 팀원 + 리더에게 공유 |
| 새로운 핵심 키워드/인물/조직 발견 |
전체 팀원에게 공유 |
| 조사 범위 확장이 필요한 영역 발견 |
리더에게 보고 (보충 조사 판단용) |
SendMessage 형식:
[교차공유] {발견 유형}: {핵심 내용} (출처: {URL})
→ {수신자}에게 권장 행동: {추가 조사 방향}
교차 공유 수신 시 의무:
Phase 4: 교차 검증 (quick 모드에서는 생략)
모든 에이전트 조사 완료 후, 리더가 직접 수행:
- N개 조사 파일을
Read로 읽기
- 상충 정보 식별: 에이전트 간 모순되는 정보를 추출
- 검증 조사: 상충 정보에 대해 리더가 직접 WebSearch로 추가 검증 (최대 3건)
- 신뢰도 판정: 각 상충 정보에 대해 어느 쪽이 더 신뢰할 수 있는지 판정하되, 판정 불가 시 양론 병기
- 검증 결과를
_workspace/cross_validation.md에 기록
상충 정보 해결 우선순위:
- 1차 소스 (공식 문서, 당사자 발언, 원본 데이터) > 2차 소스 (미디어 보도, 분석)
- 최신 정보 > 오래된 정보
- 다수 소스 일치 > 단일 소스
- 해결 불가 시: 양론 병기 + 각 출처 명시
Phase 5: 갭 분석 및 보충 조사 (quick 모드에서는 생략)
교차 검증 결과를 바탕으로 갭 분석은 standard/deep 모두 필수 수행:
5-1. 갭 분석 (standard/deep 필수)
- 정보 갭 식별: 보고서 예상 구조의 각 섹션에 대해 다음 체크리스트로 평가:
- 갭 목록 작성: 부족한 영역을 심각도 순으로 정렬 (최대 3개)
- 갭 분석 결과를
_workspace/cross_validation.md에 추가 기록
5-2. 보충 에이전트 실행 (조건부)
| 모드 |
보충 에이전트 실행 조건 |
| standard |
갭 심각도 "높음" (핵심 섹션에 데이터 부재)인 경우에만 |
| deep |
갭 목록이 1개 이상이면 항상 실행 |
- 보충 에이전트는 서브 에이전트로 실행한다 (팀원 간 통신 불필요, 결과 전달만 필요하므로)
Agent(subagent_type: "general-purpose", model: "opus", run_in_background: true) 로 1~2개 실행
- 전문가 풀에서 추가 전문가를 선택하거나, 이미 투입된 전문가의 범위를 좁힌 보충 조사도 가능
- 보충 결과를
_workspace/supplement_{area}.md에 저장
Phase 6: 종합 보고서 작성
모든 조사 + 검증 + 보충 완료 후:
- 전체 조사 파일 + 교차 검증 결과를
Read로 읽기
- 보고서 구조를 동적으로 설계: 선택된 전문가와 수집된 데이터에 기반하여 보고서 섹션을 구성
보고서 구조 동적 생성 규칙
보고서 구조는 고정이 아니라, 다음 원칙에 따라 동적으로 결정한다:
1. 핵심 요약 (Executive Summary) — 항상 포함
2. 개요/배경 — 항상 포함
3. [선택된 전문가별 핵심 섹션] — 각 전문가의 조사 결과에서 도출
4. 교차 분석 — 에이전트 간 교차 발견 패턴
5. 결론 및 전망 — 항상 포함
6. 참고 자료 — 항상 포함
부록 A: 교차 검증 결과
부록 B: 정보 갭 및 한계
전문가별 → 보고서 섹션 매핑 가이드:
| 전문가 |
보고서 섹션 후보 |
official |
공식 개요, 기술 구조, 연혁/타임라인 |
media |
미디어 보도 분석, 전문가 평가 |
community |
커뮤니티 반응, 여론 분석, 주요 논쟁점 |
academic |
관련 학술 연구, 이론적 배경 |
financial |
재무 현황, 투자/펀딩, 비즈니스 모델 |
industry |
산업 환경, 경쟁 분석, SWOT, 시장 전망 |
reputation |
평판 분석, 고객/직원 리뷰, 논란/이슈 |
career |
인물 개요, 학력 및 경력, 인적 네트워크 |
works |
주요 업적, 학술 논문, 저작/특허 |
technical |
기술 심층 분석, 아키텍처, 성능/벤치마크 |
policy |
규제 환경, 법적 리스크, 정책 동향 |
리더는 위 매핑을 참고하되, 수집된 데이터의 실제 분량과 중요도에 따라 섹션을 병합하거나 세분화한다.
분석적 종합 프레임워크
보고서의 각 섹션은 다음 3층 구조를 가이드라인으로 따른다:
| 층 |
내용 |
비중 |
| 사실 층 |
검증된 팩트, 데이터, 인용 (출처 명시) |
50% |
| 분석 층 |
사실의 의미 해석, 패턴 발견, 인과관계 추론 |
30% |
| 인사이트 층 |
발견된 패턴에서 도출한 시사점, 전망, 제언 |
20% |
적용 원칙: 3층 구조는 사고 프레임워크이지 기계적 포맷이 아니다. 각 섹션에 "사실:", "분석:", "인사이트:" 같은 마커를 기계적으로 삽입하지 않는다. 자연스러운 서술 흐름 안에서 팩트→해석→시사점이 유기적으로 흐르도록 한다. 핵심은 팩트만 나열하지 않고, 분석과 인사이트를 반드시 포함하는 것이다.
종합 시 금지 사항:
- 에이전트별 결과를 순서대로 나열하는 것 (단순 concatenation)
- 동일 정보를 다른 표현으로 반복하는 것
- 출처 없는 주장
종합 시 필수 사항:
- 에이전트 간 교차 발견된 패턴을 하이라이트
- 상충 정보는 양쪽 근거와 함께 제시 (교차 검증 결과 반영)
- 각 정보의 신뢰도 등급 표시
정보 신뢰도 등급
| 등급 |
기준 |
표기 |
| 확인됨 |
1차 소스에서 직접 확인 + 2개 이상 소스 일치 |
(확인됨) |
| 보도됨 |
2차 소스(미디어/분석가)에서 보도, 1차 소스 미확인 |
(보도됨) |
| 미확인 |
단일 소스 또는 커뮤니티/SNS 기반 |
(미확인) |
| 상충 |
소스 간 모순 존재 |
(상충 - 양론 병기) |
모든 주장에 등급을 달 필요 없음. 핵심 주장, 수치 데이터, 논란 사항에만 표시.
- 보고서 파일명:
{대상}_종합보고서.md
- 보고서 메타 헤더:
# {대상} 종합 조사 보고서
> **작성일**: {date}
> **조사 기간**: {time_range} 이내 ({start_date} ~ {end_date})
> **조사 깊이**: {depth}
> **투입 전문가**: {specialist_list}
> **교차 검증**: 상충 {n}건 중 해결 {m}건
TaskUpdate로 보고서 태스크 완료 처리
Phase 7: 정리
- 모든 에이전트에
SendMessage(type: "shutdown_request") 전송
- 종료 확인 후
TeamDelete로 팀 정리
_workspace/ 디렉토리 보존 (중간 산출물은 삭제하지 않음 — 사후 검증·감사 추적용)
- 사용자에게 결과 요약 보고:
- 종합 보고서 파일 경로
- 투입된 전문가 목록과 선택 이유
- 조사 커버리지 요약 (각 영역별 수집 정보량)
- 교차 검증에서 발견된 상충 사항 수
- 보충 조사 수행 여부 및 영역
데이터 흐름
Phase 1: [리더: 대상 분석 + 팀 설계] → team_design.md
Phase 2: [리더] → TeamCreate(model: opus) + TaskCreate
│
┌─────┼─────┐── ... ──┐
↓ ↓ ↓ ↓
[specialist-1] ... [specialist-N] ← 팀원 자동 스폰
│ │ │ │
Phase 3: ├──SendMessage──┤ (교차 공유, 리더 모니터링)
│ │ │ │
↓ ↓ ↓ ↓
research_1 ... research_N ← TaskUpdate로 완료 보고
│ │ │ │
└─────┼─────┘── ... ──┘
↓
Phase 4: [리더: 교차 검증] → cross_validation.md
Phase 5: [리더: 갭 분석]
↓ (보충 필요 시)
[Agent(서브에이전트) 1~2개] → supplement_*.md
Phase 6: [리더: 동적 보고서 구조 설계 + 분석적 종합]
↓
종합보고서.md
Phase 7: [TeamDelete + 정리]
에러 핸들링
| 상황 |
전략 |
| 에이전트 1명 실패/중지 |
리더가 감지 → 1회 재시도 → 재실패 시 나머지 결과로 진행, 보고서에 누락 명시 |
| 에이전트 과반 실패 |
사용자에게 알리고 진행 여부 확인 |
| 타임아웃 |
현재까지 수집된 부분 결과 사용, 미완료 에이전트 종료 |
| 에이전트 간 데이터 충돌 |
Phase 4 교차 검증에서 해결. 해결 불가 시 양론 병기 |
| 검색 결과 빈약 |
에이전트가 키워드 변형/영문 검색/관련 용어 확장으로 재시도 |
| WebFetch 차단 |
해당 소스 스킵, 대체 소스 검색 |
| 팀 설계 실패 (대상 모호) |
AskUserQuestion으로 조사 방향 확인 |
핵심 규칙
- 모든 보고서는 한글로 작성
- 모든 정보에 출처 URL 포함 필수
- 팀 설계가 최우선: Phase 1에서 대상 분석과 전문가 선택에 충분한 시간을 투자
- 모든 에이전트는
model: "opus"로 실행
- 선택된 에이전트는
TeamCreate 한 번으로 동시에 스폰
- 교차 공유 의무: 에이전트는 다른 팀원에게 유용한 발견을 SendMessage로 공유
- 종합 보고서는 분석적 종합 — 단순 취합 금지, 3층 구조(사실/분석/인사이트) 적용
- 보고서 구조는 동적 — 고정 템플릿이 아니라 투입된 전문가와 수집 데이터에 맞게 설계
- 핵심 주장에 신뢰도 등급 표시
- 사용자 입력이 파일(스크립트, 기사 등)인 경우 내용을 분석하여 검색 키워드 자동 도출
- 최신성 우선: 조사 기간 내의 최신 정보를 우선적으로 수집
- 각 에이전트는 검색 시 현재 연도를 포함한 쿼리 사용
테스트 시나리오
시나리오 1: 기술 제품 조사 (standard)
- 입력: "Claude Code 조사해줘"
- Phase 1: 대상=AI 개발 도구, 깊이=standard, 키워드=[Claude Code, Anthropic, AI coding, CLI]
- 팀 설계: official(공식 문서) + technical(기술 분석) + community(개발자 반응) + industry(경쟁 환경) = 4명
- Phase 2: 팀 구성, 6개 태스크
- Phase 3: 4개 에이전트 병렬 실행
- Phase 4: 교차 검증
- Phase 6: 보고서 구조 = 개요 → 기능·아키텍처 → 개발자 반응 → 경쟁 환경(Cursor, Copilot) → 전망
- 결과:
Claude_Code_종합보고서.md
시나리오 2: 인물 조사 (deep)
- 입력: "Jensen Huang 심층 조사해줘"
- Phase 1: 대상=기업인, 깊이=deep, 키워드=[Jensen Huang, NVIDIA, GPU, AI]
- 팀 설계: career(경력) + works(업적) + media(인터뷰/발언) + financial(NVIDIA 재무) + reputation(평판) + industry(반도체 산업) = 6명
- Phase 3: 6개 에이전트 병렬 실행
- Phase 5: 보충 조사 — 최근 GTC 키노트 관련 추가 조사
- Phase 6: 보고서 구조 = 인물 개요 → 경력 → NVIDIA 경영 성과 → 재무·주가 → 미디어·발언 → 반도체 산업 내 위상 → 평판·평가 → 전망
시나리오 3: 사회 이슈 조사 (quick)
- 입력: "EU AI Act 간단히 조사해줘"
- Phase 1: 대상=규제 정책, 깊이=quick, 키워드=[EU AI Act, AI regulation, 인공지능 규제]
- 팀 설계: policy(규제 분석) + official(공식 문서) = 2명
- Phase 3: 2개 에이전트 병렬 실행
- Phase 4~5: 생략 (quick)
- Phase 6: 보고서 구조 = 개요 → 주요 조항 → 영향 분석 → 시사점
에러 흐름
- Phase 3에서 financial-researcher가 에러로 중지
- 리더가 유휴 알림 수신, 1회 재시도
- 재시도 실패 → 나머지 결과로 Phase 4 진행
- 보고서의 재무 관련 섹션에 "데이터 미수집 — industry 에이전트의 부분 데이터로 대체" 명시
- 사용자에게 부분 완료 알림
1---2name: agent-research3description: 에이전트 팀을 구성하여 종합 리서치 보고서를 작성하는 스킬. 조사 대상을 분석하여 전문가 풀에서 최적의 에이전트를 동적으로 선택·구성한다. (1) '조사해줘', '리서치해줘', '보고서 작성해줘' 요청 시, (2) '~기업 분석해줘', '~회사 조사해줘' 요청 시, (3) '~사람 조사해줘', '~인물 분석해줘', '~에 대해 알려줘' 요청 시, (4) 미디어 반응, 커뮤니티 의견, 경쟁 환경 등을 종합적으로 파악해야 할 때, (5) '에이전트 팀으로 조사', '팀 리서치' 요청 시, (6) 영상 스크립트, 기사, 보도자료 등을 바탕으로 배경 조사가 필요할 때.4---56# Agent Research78에이전트 팀 기반 종합 리서치 스킬. 조사 대상의 성격을 분석하여 **전문가 풀에서 최적의 에이전트를 동적으로 선택**하고, 교차 검증을 거쳐 분석적 종합 보고서를 산출한다.910## 실행 모드: 에이전트 팀1112## 전문가 풀1314리더는 아래 11개 전문가 중에서 조사 대상에 맞는 **2~6개**를 선택한다.1516| ID | 전문가 | 조사 영역 | 적합한 대상 |17|----|--------|----------|------------|18| `official` | 공식 정보 조사관 | 공식 문서, 1차 소스, 기술 문서, GitHub, API | 기술/제품/서비스/기업/정책 |19| `media` | 미디어 분석관 | 미디어 보도, 기사, 영상 콘텐츠, 인터뷰 | 거의 모든 대상 |20| `community` | 커뮤니티 분석관 | Reddit, HN, Twitter, 포럼, 블로그 | 기술/제품/인물/논란 |21| `academic` | 학술 연구관 | 논문, 학회, 연구 트렌드 | 기술/과학/의료/인물(학자) |22| `financial` | 재무 분석관 | 재무제표, 투자, 밸류에이션, 주가 | 기업/산업/경제 이슈 |23| `industry` | 산업·경쟁 분석관 | 시장 규모, 경쟁사, SWOT, 트렌드 | 기업/제품/산업 |24| `reputation` | 평판 조사관 | 고객 리뷰, 직원 평판, 여론, 논란 | 기업/제품/인물 |25| `career` | 경력·배경 조사관 | 학력, 경력, 인적 네트워크 | 인물 |26| `works` | 업적·저작 조사관 | 논문, 특허, 수상, 프로젝트 성과 | 인물(학자/창업자/개발자) |27| `technical` | 기술 심층 분석관 | 아키텍처, 벤치마크, 코드, 성능, 보안 | 기술/제품/오픈소스 |28| `policy` | 규제·정책 분석관 | 법률, 규제, 정책, 윤리, 컴플라이언스 | 산업/기술/사회 이슈 |2930프롬프트 템플릿: [references/agent-prompts.md](references/agent-prompts.md)3132## 조사 깊이 선택3334| 깊이 | 트리거 | 에이전트 수 | 검색 횟수/에이전트 | 특징 |35|------|--------|-----------|-------------------|------|36| **quick** | `간단히`, `빠르게`, `요약`, `개요` | 2~3개 | 5~8회 | 핵심 정보만. 교차 검증·보충 생략 |37| **standard** (기본) | 미지정 | 3~4개 | 10~15회 | 기본 조사 + 교차 검증 + 선택적 보충 |38| **deep** | `심층`, `깊이`, `상세히`, `철저히` | 4~6개 | 15~25회 | 다단계 검색 + 교차 검증 + 필수 보충 + 1차 소스 추적 |3940## 워크플로우4142### Phase 1: 대상 분석 및 팀 설계4344이 Phase가 핵심이다. 리더가 조사 대상을 분석하여 최적의 팀을 구성한다.4546**1단계: 대상 파악**471. 사용자 입력에서 **조사 대상**, **조사 깊이**, **출력 경로**, **조사 기간** 파악482. 입력이 파일이면 읽어서 주제 추출, 텍스트면 그대로 사용493. **핵심 키워드 3~5개** 도출5051**2단계: 조사 차원 식별**5253조사 대상의 성격에 따라 어떤 차원의 조사가 필요한지 판단한다:5455| 대상 성격 | 필수 차원 | 선택 차원 |56|----------|----------|----------|57| AI 신기술 | official, technical | media, community, academic |58| 상장 기업 | official, financial, industry | reputation, media |59| 스타트업 | official, financial | industry, media, reputation |60| 학자/연구자 | career, works, academic | media, influence→reputation |61| CEO/창업자 | career, works | media, reputation, financial |62| 정치인/공인 | career, media | reputation, policy |63| 규제/정책 이슈 | policy, official | media, community, industry |64| 오픈소스 프로젝트 | official, technical, community | media, academic |65| 사회적 논란 | media, community | policy, reputation, official |66| 제품/서비스 | official, technical | media, community, industry |6768> 위 표는 **가이드라인**이다. 리더는 대상의 고유한 특성을 분석하여 자유롭게 조합한다.69> 사용자가 특정 관점을 명시적으로 요청한 경우 (예: "재무 중심으로", "커뮤니티 반응 위주로") 해당 전문가를 반드시 포함한다.7071**`media` 전문가 포함 판단 기준:**72`media`를 제외하면 미디어 보도 수집이 다른 에이전트에 분산되어 깊이가 얕아질 수 있다. 다음 경우 `media`를 반드시 포함한다:73- 대상이 **대중적 관심이 높은 이슈** (광범위한 미디어 보도 예상)74- **미디어 논조 분석**(호의적/비판적 분류)이 보고서 핵심일 때75- **영상 콘텐츠**(YouTube, 팟캐스트) 분석이 필요할 때76- 에이전트 수 예산에 여유가 있을 때 (4개 이상)7778`media` 제외 시: `official`(공식 보도), `community`(여론/반응), `reputation`(평판 보도)이 미디어 영역을 분담. 단, **미디어 보도의 논조 분석 깊이는 떨어짐**을 인지.7980**3단계: 팀 구성 결정**8182깊이에 따라 에이전트 수를 결정하고, 전문가 풀에서 선택한다:8384```85선택 기준:861. 조사 대상에 필수적인 차원의 전문가를 먼저 선택872. 깊이 예산 내에서 선택 차원의 전문가를 추가883. 전문가 간 시너지를 고려 (예: financial + industry는 상호 보완적)894. 사용자가 명시적으로 요청한 관점이 있으면 반드시 포함90```9192**결정 사항 기록** (리더가 팀 구성 근거를 `_workspace/team_design.md`에 기록):9394```markdown95# 팀 설계9697## 조사 대상: {target}98## 핵심 키워드: {keywords}99## 조사 깊이: {depth}100## 조사 기간: {time_range}101102## 선택된 전문가 ({N}명)103104| # | 전문가 | 선택 이유 |105|---|--------|----------|106| 1 | {specialist} | {이 전문가가 필요한 이유} |107| 2 | {specialist} | {이 전문가가 필요한 이유} |108| ... | ... | ... |109110## 제외된 전문가 (해당 시)111112| 전문가 | 제외 이유 |113|--------|----------|114| {specialist} | {불필요한 이유} |115116## 보고서 구조 (예상)117118{선택된 전문가에 기반한 보고서 섹션 구조}119```120121**4단계: 조사 기간 결정** (사용자 미지정 시 기본 3개월):122123| 옵션 | 기간 | 적용 시점 |124|------|------|----------|125| `최신` / `긴급` / `1주` | 최근 1주일 이내 | 방금 발표된 뉴스, 핫이슈 |126| `최근` / `1달` | 최근 1개월 이내 | 비교적 최신 동향 |127| 기본값 (미지정) | 최근 3개월 이내 | 일반적인 리서치 |128129### Phase 2: 팀 구성 및 병렬 조사 시작130131**1단계: TeamCreate로 팀 생성 + 팀원 스폰**132133```134TeamCreate(135 team_name: "research-{slug}",136 members: [137 {138 name: "{specialist-1}-researcher",139 agent_type: "general-purpose",140 model: "opus",141 prompt: // references/agent-prompts.md 템플릿을 커스터마이즈 (아래 규칙 참조)142 },143 {144 name: "{specialist-2}-researcher",145 agent_type: "general-purpose",146 model: "opus",147 prompt: // ...148 },149 // ... N개 팀원150 ]151)152```153154> TeamCreate 호출 시 모든 팀원이 즉시 스폰된다. 별도로 에이전트를 개별 실행할 필요 없다.155156**2단계: TaskCreate로 작업 등록**157158```159TaskCreate(tasks: [160 { title: "{specialist-1} 조사", description: "{조사 지시}", assignee: "{specialist-1}-researcher" },161 { title: "{specialist-2} 조사", description: "{조사 지시}", assignee: "{specialist-2}-researcher" },162 // ... N개 조사 태스크163 { title: "교차 검증", description: "리더가 수행", assignee: "leader", depends_on: ["조사 태스크 전체"] },164 { title: "종합 보고서", description: "리더가 수행", assignee: "leader", depends_on: ["교차 검증"] }165])166```167168> 팀원들은 자신에게 할당된 태스크를 자동으로 수행하고, 완료 시 TaskUpdate로 상태를 갱신한다.169170**프롬프트 커스터마이즈 규칙:**171- references/agent-prompts.md의 해당 전문가 기본 템플릿을 가져온다172- `{target}` 변수를 조사 대상으로 치환173- `{keywords}` 변수를 핵심 키워드로 치환174- `{teammate_list}`를 실제 선택된 팀원 목록으로 치환175- **교차 공유 트리거**를 실제 팀원 구성에 맞게 조정 (없는 팀원에게 공유하도록 되어 있으면 가장 가까운 역할의 팀원으로 대체하거나, 없으면 리더에게 공유)176- 대상 특성에 맞는 **추가 조사 지시**를 프롬프트에 삽입177178### Phase 3: 리더 모니터링 및 팀 조율179180TeamCreate 후 팀원들은 자율적으로 조사를 수행한다. 리더는 다음을 수행:181182**모니터링:**183- `TaskGet`으로 전체 태스크 진행 상황 확인184- 팀원이 유휴 상태가 되면 자동 알림 수신185- 특정 팀원이 막혔다는 SendMessage를 보내면 키워드 제안 등으로 지원186187**개입이 필요한 상황:**188- 팀원이 조사 범위 확장을 요청 → 승인/거부 판단189- 상충 정보가 교차 공유됨 → Phase 4에서 해결할 것을 메모190- 팀원이 에러로 중지 → 1회 재시도 또는 나머지 결과로 진행 결정191192모든 팀원 공통 행동:193- `general-purpose` 타입 (WebSearch, WebFetch 필요)194- **교차 공유 의무**: 조사 중 다른 팀원에게 유용한 정보 발견 시 `SendMessage`로 즉시 공유195- 완료 시 `TaskUpdate`로 태스크 완료 처리 + `SendMessage`로 리더에 보고196197#### 에이전트 간 교차 공유 프로토콜198199에이전트들은 조사 중 다음 상황에서 다른 팀원에게 `SendMessage`로 정보를 공유한다:200201| 발견 상황 | 공유 행동 |202|----------|----------|203| 다른 팀원 전문 영역의 중요 정보 발견 | 해당 팀원에게 직접 공유 |204| **상충 정보** 발견 | 관련 팀원 + 리더에게 공유 |205| 새로운 핵심 키워드/인물/조직 발견 | 전체 팀원에게 공유 |206| 조사 범위 확장이 필요한 영역 발견 | 리더에게 보고 (보충 조사 판단용) |207208**SendMessage 형식:**209```210[교차공유] {발견 유형}: {핵심 내용} (출처: {URL})211→ {수신자}에게 권장 행동: {추가 조사 방향}212```213214**교차 공유 수신 시 의무:**215- 다른 팀원으로부터 교차 공유를 수신한 에이전트는 해당 정보가 자신의 조사 방향에 영향을 미쳤는지 기록해야 한다216- 조사 결과 파일의 `## 교차 공유 로그` 섹션에 **수신한 공유 + 이에 따른 조사 방향 변경**을 기록:217 ```218 | 수신 | 발신자 | 내용 | 조사 방향 변경 |219 |------|--------|------|---------------|220 | 예 | {sender} | {내용} | {변경 사항 또는 "영향 없음"} |221 ```222- 이 기록은 Phase 4 교차 검증에서 에이전트 간 협업 효과를 평가하는 데 사용223224### Phase 4: 교차 검증 (quick 모드에서는 생략)225226모든 에이전트 조사 완료 후, 리더가 직접 수행:2272281. N개 조사 파일을 `Read`로 읽기2292. **상충 정보 식별**: 에이전트 간 모순되는 정보를 추출2303. **검증 조사**: 상충 정보에 대해 리더가 직접 WebSearch로 추가 검증 (최대 3건)2314. **신뢰도 판정**: 각 상충 정보에 대해 어느 쪽이 더 신뢰할 수 있는지 판정하되, 판정 불가 시 양론 병기2325. 검증 결과를 `_workspace/cross_validation.md`에 기록233234**상충 정보 해결 우선순위:**2351. 1차 소스 (공식 문서, 당사자 발언, 원본 데이터) > 2차 소스 (미디어 보도, 분석)2362. 최신 정보 > 오래된 정보2373. 다수 소스 일치 > 단일 소스2384. 해결 불가 시: 양론 병기 + 각 출처 명시239240### Phase 5: 갭 분석 및 보충 조사 (quick 모드에서는 생략)241242교차 검증 결과를 바탕으로 **갭 분석은 standard/deep 모두 필수** 수행:243244**5-1. 갭 분석 (standard/deep 필수)**2452461. **정보 갭 식별**: 보고서 예상 구조의 각 섹션에 대해 다음 체크리스트로 평가:247 - [ ] 해당 섹션에 1차 소스가 1개 이상 있는가?248 - [ ] 핵심 수치/주장이 2개 이상 소스에서 확인되었는가?249 - [ ] 반대 관점/리스크가 포함되었는가?2502. **갭 목록 작성**: 부족한 영역을 심각도 순으로 정렬 (최대 3개)2513. **갭 분석 결과를 `_workspace/cross_validation.md`에 추가 기록**252253**5-2. 보충 에이전트 실행 (조건부)**254255| 모드 | 보충 에이전트 실행 조건 |256|------|----------------------|257| standard | 갭 심각도 "높음" (핵심 섹션에 데이터 부재)인 경우에만 |258| deep | 갭 목록이 1개 이상이면 항상 실행 |259260- 보충 에이전트는 **서브 에이전트**로 실행한다 (팀원 간 통신 불필요, 결과 전달만 필요하므로)261- `Agent(subagent_type: "general-purpose", model: "opus", run_in_background: true)` 로 1~2개 실행262- 전문가 풀에서 추가 전문가를 선택하거나, 이미 투입된 전문가의 범위를 좁힌 보충 조사도 가능263- 보충 결과를 `_workspace/supplement_{area}.md`에 저장264265### Phase 6: 종합 보고서 작성266267모든 조사 + 검증 + 보충 완료 후:2682691. 전체 조사 파일 + 교차 검증 결과를 `Read`로 읽기2702. **보고서 구조를 동적으로 설계**: 선택된 전문가와 수집된 데이터에 기반하여 보고서 섹션을 구성271272#### 보고서 구조 동적 생성 규칙273274보고서 구조는 고정이 아니라, 다음 원칙에 따라 동적으로 결정한다:275276```2771. 핵심 요약 (Executive Summary) — 항상 포함2782. 개요/배경 — 항상 포함2793. [선택된 전문가별 핵심 섹션] — 각 전문가의 조사 결과에서 도출2804. 교차 분석 — 에이전트 간 교차 발견 패턴2815. 결론 및 전망 — 항상 포함2826. 참고 자료 — 항상 포함283부록 A: 교차 검증 결과284부록 B: 정보 갭 및 한계285```286287**전문가별 → 보고서 섹션 매핑 가이드:**288289| 전문가 | 보고서 섹션 후보 |290|--------|----------------|291| `official` | 공식 개요, 기술 구조, 연혁/타임라인 |292| `media` | 미디어 보도 분석, 전문가 평가 |293| `community` | 커뮤니티 반응, 여론 분석, 주요 논쟁점 |294| `academic` | 관련 학술 연구, 이론적 배경 |295| `financial` | 재무 현황, 투자/펀딩, 비즈니스 모델 |296| `industry` | 산업 환경, 경쟁 분석, SWOT, 시장 전망 |297| `reputation` | 평판 분석, 고객/직원 리뷰, 논란/이슈 |298| `career` | 인물 개요, 학력 및 경력, 인적 네트워크 |299| `works` | 주요 업적, 학술 논문, 저작/특허 |300| `technical` | 기술 심층 분석, 아키텍처, 성능/벤치마크 |301| `policy` | 규제 환경, 법적 리스크, 정책 동향 |302303> 리더는 위 매핑을 참고하되, 수집된 데이터의 실제 분량과 중요도에 따라 섹션을 병합하거나 세분화한다.304305#### 분석적 종합 프레임워크306307보고서의 각 섹션은 다음 3층 구조를 **가이드라인으로** 따른다:308309| 층 | 내용 | 비중 |310|----|------|------|311| **사실 층** | 검증된 팩트, 데이터, 인용 (출처 명시) | 50% |312| **분석 층** | 사실의 의미 해석, 패턴 발견, 인과관계 추론 | 30% |313| **인사이트 층** | 발견된 패턴에서 도출한 시사점, 전망, 제언 | 20% |314315> **적용 원칙**: 3층 구조는 사고 프레임워크이지 기계적 포맷이 아니다. 각 섹션에 "사실:", "분석:", "인사이트:" 같은 마커를 기계적으로 삽입하지 않는다. 자연스러운 서술 흐름 안에서 팩트→해석→시사점이 유기적으로 흐르도록 한다. 핵심은 **팩트만 나열하지 않고, 분석과 인사이트를 반드시 포함**하는 것이다.316317**종합 시 금지 사항:**318- 에이전트별 결과를 순서대로 나열하는 것 (단순 concatenation)319- 동일 정보를 다른 표현으로 반복하는 것320- 출처 없는 주장321322**종합 시 필수 사항:**323- 에이전트 간 교차 발견된 패턴을 하이라이트324- 상충 정보는 양쪽 근거와 함께 제시 (교차 검증 결과 반영)325- 각 정보의 신뢰도 등급 표시326327#### 정보 신뢰도 등급328329| 등급 | 기준 | 표기 |330|------|------|------|331| **확인됨** | 1차 소스에서 직접 확인 + 2개 이상 소스 일치 | (확인됨) |332| **보도됨** | 2차 소스(미디어/분석가)에서 보도, 1차 소스 미확인 | (보도됨) |333| **미확인** | 단일 소스 또는 커뮤니티/SNS 기반 | (미확인) |334| **상충** | 소스 간 모순 존재 | (상충 - 양론 병기) |335336> 모든 주장에 등급을 달 필요 없음. **핵심 주장, 수치 데이터, 논란 사항**에만 표시.3373383. 보고서 파일명: `{대상}_종합보고서.md`3394. 보고서 메타 헤더:340341```markdown342# {대상} 종합 조사 보고서343344> **작성일**: {date}345> **조사 기간**: {time_range} 이내 ({start_date} ~ {end_date})346> **조사 깊이**: {depth}347> **투입 전문가**: {specialist_list}348> **교차 검증**: 상충 {n}건 중 해결 {m}건349```3503515. `TaskUpdate`로 보고서 태스크 완료 처리352353### Phase 7: 정리3543551. 모든 에이전트에 `SendMessage(type: "shutdown_request")` 전송3562. 종료 확인 후 `TeamDelete`로 팀 정리3573. `_workspace/` 디렉토리 보존 (중간 산출물은 삭제하지 않음 — 사후 검증·감사 추적용)3584. 사용자에게 결과 요약 보고:359 - 종합 보고서 파일 경로360 - 투입된 전문가 목록과 선택 이유361 - 조사 커버리지 요약 (각 영역별 수집 정보량)362 - 교차 검증에서 발견된 상충 사항 수363 - 보충 조사 수행 여부 및 영역364365## 데이터 흐름366367```368Phase 1: [리더: 대상 분석 + 팀 설계] → team_design.md369370Phase 2: [리더] → TeamCreate(model: opus) + TaskCreate371 │372 ┌─────┼─────┐── ... ──┐373 ↓ ↓ ↓ ↓374 [specialist-1] ... [specialist-N] ← 팀원 자동 스폰375 │ │ │ │376Phase 3: ├──SendMessage──┤ (교차 공유, 리더 모니터링)377 │ │ │ │378 ↓ ↓ ↓ ↓379 research_1 ... research_N ← TaskUpdate로 완료 보고380 │ │ │ │381 └─────┼─────┘── ... ──┘382 ↓383Phase 4: [리더: 교차 검증] → cross_validation.md384385Phase 5: [리더: 갭 분석]386 ↓ (보충 필요 시)387 [Agent(서브에이전트) 1~2개] → supplement_*.md388389Phase 6: [리더: 동적 보고서 구조 설계 + 분석적 종합]390 ↓391 종합보고서.md392393Phase 7: [TeamDelete + 정리]394```395396## 에러 핸들링397398| 상황 | 전략 |399|------|------|400| 에이전트 1명 실패/중지 | 리더가 감지 → 1회 재시도 → 재실패 시 나머지 결과로 진행, 보고서에 누락 명시 |401| 에이전트 과반 실패 | 사용자에게 알리고 진행 여부 확인 |402| 타임아웃 | 현재까지 수집된 부분 결과 사용, 미완료 에이전트 종료 |403| 에이전트 간 데이터 충돌 | Phase 4 교차 검증에서 해결. 해결 불가 시 양론 병기 |404| 검색 결과 빈약 | 에이전트가 키워드 변형/영문 검색/관련 용어 확장으로 재시도 |405| WebFetch 차단 | 해당 소스 스킵, 대체 소스 검색 |406| 팀 설계 실패 (대상 모호) | AskUserQuestion으로 조사 방향 확인 |407408## 핵심 규칙409410- 모든 보고서는 **한글**로 작성411- 모든 정보에 **출처 URL** 포함 필수412- **팀 설계가 최우선**: Phase 1에서 대상 분석과 전문가 선택에 충분한 시간을 투자413- 모든 에이전트는 `model: "opus"`로 실행414- 선택된 에이전트는 `TeamCreate` 한 번으로 **동시에** 스폰415- **교차 공유 의무**: 에이전트는 다른 팀원에게 유용한 발견을 SendMessage로 공유416- 종합 보고서는 **분석적 종합** — 단순 취합 금지, 3층 구조(사실/분석/인사이트) 적용417- **보고서 구조는 동적** — 고정 템플릿이 아니라 투입된 전문가와 수집 데이터에 맞게 설계418- 핵심 주장에 **신뢰도 등급** 표시419- 사용자 입력이 파일(스크립트, 기사 등)인 경우 내용을 분석하여 검색 키워드 자동 도출420- **최신성 우선**: 조사 기간 내의 최신 정보를 우선적으로 수집421- 각 에이전트는 검색 시 **현재 연도를 포함**한 쿼리 사용422423## 테스트 시나리오424425### 시나리오 1: 기술 제품 조사 (standard)4261. 입력: "Claude Code 조사해줘"4272. Phase 1: 대상=AI 개발 도구, 깊이=standard, 키워드=[Claude Code, Anthropic, AI coding, CLI]4283. 팀 설계: official(공식 문서) + technical(기술 분석) + community(개발자 반응) + industry(경쟁 환경) = 4명4294. Phase 2: 팀 구성, 6개 태스크4305. Phase 3: 4개 에이전트 병렬 실행4316. Phase 4: 교차 검증4327. Phase 6: 보고서 구조 = 개요 → 기능·아키텍처 → 개발자 반응 → 경쟁 환경(Cursor, Copilot) → 전망4338. 결과: `Claude_Code_종합보고서.md`434435### 시나리오 2: 인물 조사 (deep)4361. 입력: "Jensen Huang 심층 조사해줘"4372. Phase 1: 대상=기업인, 깊이=deep, 키워드=[Jensen Huang, NVIDIA, GPU, AI]4383. 팀 설계: career(경력) + works(업적) + media(인터뷰/발언) + financial(NVIDIA 재무) + reputation(평판) + industry(반도체 산업) = 6명4394. Phase 3: 6개 에이전트 병렬 실행4405. Phase 5: 보충 조사 — 최근 GTC 키노트 관련 추가 조사4416. Phase 6: 보고서 구조 = 인물 개요 → 경력 → NVIDIA 경영 성과 → 재무·주가 → 미디어·발언 → 반도체 산업 내 위상 → 평판·평가 → 전망442443### 시나리오 3: 사회 이슈 조사 (quick)4441. 입력: "EU AI Act 간단히 조사해줘"4452. Phase 1: 대상=규제 정책, 깊이=quick, 키워드=[EU AI Act, AI regulation, 인공지능 규제]4463. 팀 설계: policy(규제 분석) + official(공식 문서) = 2명4474. Phase 3: 2개 에이전트 병렬 실행4485. Phase 4~5: 생략 (quick)4496. Phase 6: 보고서 구조 = 개요 → 주요 조항 → 영향 분석 → 시사점450451### 에러 흐름4521. Phase 3에서 financial-researcher가 에러로 중지4532. 리더가 유휴 알림 수신, 1회 재시도4543. 재시도 실패 → 나머지 결과로 Phase 4 진행4554. 보고서의 재무 관련 섹션에 "데이터 미수집 — industry 에이전트의 부분 데이터로 대체" 명시4565. 사용자에게 부분 완료 알림