# Agent Research

> 에이전트 팀을 구성하여 종합 리서치 보고서를 작성하는 스킬. 조사 대상을 분석하여 전문가 풀에서 최적의 에이전트를 동적으로 선택·구성한다. (1) '조사해줘', '리서치해줘', '보고서 작성해줘' 요청 시, (2) '~기업 분석해줘', '~회사 조사해줘' 요청 시, (3) '~사람 조사해줘', '~인물 분석해줘', '~에 대해 알려줘' 요청 시, (4) 미디어 반응, 커뮤니티 의견, 경쟁 환경 등을 종합적으로 파악해야 할 때, (5) '에이전트 팀으로 조사', '팀 리서치' 요청 시, (6) 영상 스크립트, 기사, 보도자료 등을 바탕으로 배경 조사가 필요할 때.

- Skill: `revfactory/agent-research` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add revfactory/agent-research`
- Raw SKILL.md: https://api.skillmd.com/api/skills/revfactory/agent-research/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: revfactory (https://skillmd.com/u/revfactory)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/revfactory/agent-research

---


# 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](references/agent-prompts.md)

## 조사 깊이 선택

| 깊이 | 트리거 | 에이전트 수 | 검색 횟수/에이전트 | 특징 |
|------|--------|-----------|-------------------|------|
| **quick** | `간단히`, `빠르게`, `요약`, `개요` | 2~3개 | 5~8회 | 핵심 정보만. 교차 검증·보충 생략 |
| **standard** (기본) | 미지정 | 3~4개 | 10~15회 | 기본 조사 + 교차 검증 + 선택적 보충 |
| **deep** | `심층`, `깊이`, `상세히`, `철저히` | 4~6개 | 15~25회 | 다단계 검색 + 교차 검증 + 필수 보충 + 1차 소스 추적 |

## 워크플로우

### Phase 1: 대상 분석 및 팀 설계

이 Phase가 핵심이다. 리더가 조사 대상을 분석하여 최적의 팀을 구성한다.

**1단계: 대상 파악**
1. 사용자 입력에서 **조사 대상**, **조사 깊이**, **출력 경로**, **조사 기간** 파악
2. 입력이 파일이면 읽어서 주제 추출, 텍스트면 그대로 사용
3. **핵심 키워드 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`에 기록):

```markdown
# 팀 설계

## 조사 대상: {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})
→ {수신자}에게 권장 행동: {추가 조사 방향}
```

**교차 공유 수신 시 의무:**
- 다른 팀원으로부터 교차 공유를 수신한 에이전트는 해당 정보가 자신의 조사 방향에 영향을 미쳤는지 기록해야 한다
- 조사 결과 파일의 `## 교차 공유 로그` 섹션에 **수신한 공유 + 이에 따른 조사 방향 변경**을 기록:
  ```
  | 수신 | 발신자 | 내용 | 조사 방향 변경 |
  |------|--------|------|---------------|
  | 예 | {sender} | {내용} | {변경 사항 또는 "영향 없음"} |
  ```
- 이 기록은 Phase 4 교차 검증에서 에이전트 간 협업 효과를 평가하는 데 사용

### Phase 4: 교차 검증 (quick 모드에서는 생략)

모든 에이전트 조사 완료 후, 리더가 직접 수행:

1. N개 조사 파일을 `Read`로 읽기
2. **상충 정보 식별**: 에이전트 간 모순되는 정보를 추출
3. **검증 조사**: 상충 정보에 대해 리더가 직접 WebSearch로 추가 검증 (최대 3건)
4. **신뢰도 판정**: 각 상충 정보에 대해 어느 쪽이 더 신뢰할 수 있는지 판정하되, 판정 불가 시 양론 병기
5. 검증 결과를 `_workspace/cross_validation.md`에 기록

**상충 정보 해결 우선순위:**
1. 1차 소스 (공식 문서, 당사자 발언, 원본 데이터) > 2차 소스 (미디어 보도, 분석)
2. 최신 정보 > 오래된 정보
3. 다수 소스 일치 > 단일 소스
4. 해결 불가 시: 양론 병기 + 각 출처 명시

### Phase 5: 갭 분석 및 보충 조사 (quick 모드에서는 생략)

교차 검증 결과를 바탕으로 **갭 분석은 standard/deep 모두 필수** 수행:

**5-1. 갭 분석 (standard/deep 필수)**

1. **정보 갭 식별**: 보고서 예상 구조의 각 섹션에 대해 다음 체크리스트로 평가:
   - [ ] 해당 섹션에 1차 소스가 1개 이상 있는가?
   - [ ] 핵심 수치/주장이 2개 이상 소스에서 확인되었는가?
   - [ ] 반대 관점/리스크가 포함되었는가?
2. **갭 목록 작성**: 부족한 영역을 심각도 순으로 정렬 (최대 3개)
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: 종합 보고서 작성

모든 조사 + 검증 + 보충 완료 후:

1. 전체 조사 파일 + 교차 검증 결과를 `Read`로 읽기
2. **보고서 구조를 동적으로 설계**: 선택된 전문가와 수집된 데이터에 기반하여 보고서 섹션을 구성

#### 보고서 구조 동적 생성 규칙

보고서 구조는 고정이 아니라, 다음 원칙에 따라 동적으로 결정한다:

```
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 기반 | (미확인) |
| **상충** | 소스 간 모순 존재 | (상충 - 양론 병기) |

> 모든 주장에 등급을 달 필요 없음. **핵심 주장, 수치 데이터, 논란 사항**에만 표시.

3. 보고서 파일명: `{대상}_종합보고서.md`
4. 보고서 메타 헤더:

```markdown
# {대상} 종합 조사 보고서

> **작성일**: {date}
> **조사 기간**: {time_range} 이내 ({start_date} ~ {end_date})
> **조사 깊이**: {depth}
> **투입 전문가**: {specialist_list}
> **교차 검증**: 상충 {n}건 중 해결 {m}건
```

5. `TaskUpdate`로 보고서 태스크 완료 처리

### Phase 7: 정리

1. 모든 에이전트에 `SendMessage(type: "shutdown_request")` 전송
2. 종료 확인 후 `TeamDelete`로 팀 정리
3. `_workspace/` 디렉토리 보존 (중간 산출물은 삭제하지 않음 — 사후 검증·감사 추적용)
4. 사용자에게 결과 요약 보고:
   - 종합 보고서 파일 경로
   - 투입된 전문가 목록과 선택 이유
   - 조사 커버리지 요약 (각 영역별 수집 정보량)
   - 교차 검증에서 발견된 상충 사항 수
   - 보충 조사 수행 여부 및 영역

## 데이터 흐름

```
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)
1. 입력: "Claude Code 조사해줘"
2. Phase 1: 대상=AI 개발 도구, 깊이=standard, 키워드=[Claude Code, Anthropic, AI coding, CLI]
3. 팀 설계: official(공식 문서) + technical(기술 분석) + community(개발자 반응) + industry(경쟁 환경) = 4명
4. Phase 2: 팀 구성, 6개 태스크
5. Phase 3: 4개 에이전트 병렬 실행
6. Phase 4: 교차 검증
7. Phase 6: 보고서 구조 = 개요 → 기능·아키텍처 → 개발자 반응 → 경쟁 환경(Cursor, Copilot) → 전망
8. 결과: `Claude_Code_종합보고서.md`

### 시나리오 2: 인물 조사 (deep)
1. 입력: "Jensen Huang 심층 조사해줘"
2. Phase 1: 대상=기업인, 깊이=deep, 키워드=[Jensen Huang, NVIDIA, GPU, AI]
3. 팀 설계: career(경력) + works(업적) + media(인터뷰/발언) + financial(NVIDIA 재무) + reputation(평판) + industry(반도체 산업) = 6명
4. Phase 3: 6개 에이전트 병렬 실행
5. Phase 5: 보충 조사 — 최근 GTC 키노트 관련 추가 조사
6. Phase 6: 보고서 구조 = 인물 개요 → 경력 → NVIDIA 경영 성과 → 재무·주가 → 미디어·발언 → 반도체 산업 내 위상 → 평판·평가 → 전망

### 시나리오 3: 사회 이슈 조사 (quick)
1. 입력: "EU AI Act 간단히 조사해줘"
2. Phase 1: 대상=규제 정책, 깊이=quick, 키워드=[EU AI Act, AI regulation, 인공지능 규제]
3. 팀 설계: policy(규제 분석) + official(공식 문서) = 2명
4. Phase 3: 2개 에이전트 병렬 실행
5. Phase 4~5: 생략 (quick)
6. Phase 6: 보고서 구조 = 개요 → 주요 조항 → 영향 분석 → 시사점

### 에러 흐름
1. Phase 3에서 financial-researcher가 에러로 중지
2. 리더가 유휴 알림 수신, 1회 재시도
3. 재시도 실패 → 나머지 결과로 Phase 4 진행
4. 보고서의 재무 관련 섹션에 "데이터 미수집 — industry 에이전트의 부분 데이터로 대체" 명시
5. 사용자에게 부분 완료 알림