# Research

> 자료조사, 자료수집, 레퍼런스, 문헌조사, 기술조사, 논문, 사례조사, 비교분석, 리서치, 학술조사, 기술리서치, 정보수집, 자료정리, 배경조사 - 특정 주제에 대해 병렬 전문가 서브에이전트를 활용한 심층 자료 조사를 수행한다. 기술 문서, 논문, 사례, 통계, 비교 분석, 최신 동향을 복합적으로 수집·통합하여 종합 리포트를 생성한다. PRD 작성 전 기술 검토, 아키텍처 결정, 기술 스택 선택, 학술 배경 파악이 필요할 때 사용. 마켓 리서치(시장조사/경쟁분석)는 market-research 스킬을 사용할 것.

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

---


# 자료 리서치

## Role

병렬 전문가 서브에이전트 방식으로 자료를 수집하고 종합 리포트를 생성하는 리서치 코디네이터.

각 전문가는 독립적으로 자신의 영역을 조사하고, 코디네이터가 결과를 통합·교차 검증한 후 단일 리포트로 제출한다. 단일 에이전트가 순차 조사할 때보다 커버리지가 넓고 관점의 다양성이 확보된다.

**비유**: 한 명이 도서관을 순차 방문하는 게 아니라, 각자 다른 서가를 동시에 담당하는 팀이 조사 후 편집회의에서 통합하는 방식.

## Input Requirements

조사를 시작하기 전 반드시 다음 3가지를 확인한다:

1. **Topic**: 조사할 주제 (예: "PaddleOCR-VL 한국어 문서 처리 성능")
2. **Purpose**: 이 자료를 왜 수집하는가 (예: "기술 스택 선택", "구현 가능성 검토", "배경 지식 습득")
3. **Scope**: 조사 깊이
   - `quick`: 핵심 자료 빠른 수집 (전문가 3개, 각 핵심 소스만)
   - `standard`: 종합 리포트 (전문가 3-4개, 교차 검증 포함)
   - `deep`: 심층 분석 (전문가 5-6개, 전문가 간 충돌 데이터 해소까지)

## 전문가 유형 및 할당 기준

주제 성격을 분석하여 적합한 전문가 조합을 선택한다.

| 전문가 | 담당 영역 | 주요 소스 | Agent 파일 |
|--------|----------|----------|-----------|
| **학술** | 논문, 리뷰, 연구 결과 | arXiv, Google Scholar, PubMed | `agents/academic.md` |
| **기술문서** | 공식 docs, 스펙, RFC | 공식 사이트, GitHub, ReadTheDocs | `agents/technical.md` |
| **구현사례** | 실제 적용, 벤치마크, 튜토리얼 | Medium, 기술 블로그, Stack Overflow | `agents/case-study.md` |
| **비교분석** | 대안 기술, 트레이드오프 | StackShare, HN, 비교 글 | `agents/comparison.md` |
| **통계데이터** | 수치, 채택률, 다운로드 통계 | npm trends, GitHub Stars, 설문 | `agents/stats.md` |
| **최신동향** | 최근 발표, 커뮤니티 반응 | GitHub Trending, HN, 공식 블로그 | `agents/trends.md` |
| **Codex 독립분석** | 독립 관점, blind spot 발견 | Codex 자체 분석 (codex-synthesis.md) | `codex-synthesis.md` |

### 주제 성격별 권장 조합

| 주제 유형 | 권장 전문가 조합 |
|----------|---------------|
| 라이브러리/프레임워크 선택 | 기술문서 + 구현사례 + 비교분석 + 통계데이터 + **Codex** |
| 기술 아키텍처 결정 | 학술 + 기술문서 + 구현사례 + 비교분석 + **Codex** |
| 학술/연구 주제 | 학술 + 비교분석 + 최신동향 + **Codex** |
| 구현 방법 탐색 | 기술문서 + 구현사례 + 최신동향 + **Codex** |
| 기술 성숙도 평가 | 학술 + 통계데이터 + 비교분석 + 최신동향 + **Codex** |

> **Codex 독립분석**은 모든 주제 유형에 자동 포함된다. `codex-synthesis.md`를 참조하여 실행.

## Workflow

### Step 1: 주제 분석 및 전문가 할당

입력 3가지를 확인 후:

1. 주제를 핵심 키워드 3-5개로 분해
2. 주제 성격 파악 (학술적/실용적/탐색적)
3. Scope에 맞게 전문가 수 결정
4. 각 전문가에게 구체적인 담당 범위 할당 (전문가 간 중복 최소화)

사용자에게 할당 계획을 미리 고지한다:
```
[주제] 조사를 시작합니다.
투입 전문가: [전문가 목록]
각 담당 범위: [전문가별 범위]
예상 소요: [시간]
```

### Step 2: 병렬 조사 실행

**서브에이전트 사용 가능한 경우**: 모든 전문가를 **동일한 턴에 동시 스폰**한다. 각 전문가에게 전달:

```
역할: [전문가 유형]
조사 주제: [원본 주제]
담당 범위: [구체적 할당 영역]
지침 파일: agents/[파일명].md

반환 형식:
- 핵심 발견사항 (3-5개)
- 레퍼런스 (URL, 출처, 발행일)
- 인사이트
- 불확실하거나 미확인된 항목
```

**Codex 독립분석 (항상 포함)**: 다른 전문가 스폰과 동시에 `codex-synthesis.md`의 research 프롬프트 템플릿으로 Codex를 Bash `run_in_background: true`로 실행한다. Codex는 다른 전문가와 독립적으로 분석하여 blind spot 발견과 비주류 관점을 제공한다.

**서브에이전트 불가한 경우**: 순차 실행. 각 `agents/*.md`를 읽고 해당 역할로 인라인 실행. Codex도 순차로 실행. 사용자에게 순차 실행임을 명시.

### Step 3: 결과 수집 및 교차 검증

모든 전문가 + Codex 결과 수집 후:

1. **충돌 확인**: 전문가 간 상충 정보 식별 (Codex 결과 포함)
2. **교차 검증**: 동일 사실을 2개 이상 전문가가 확인했는지 체크
3. **공백 식별**: 어떤 전문가도 다루지 못한 영역
4. **Codex 합성**: `codex-synthesis.md`의 합성 프레임워크 (Consensus / Divergence / Unique Insights) 적용
5. **신뢰도 등급**: 각 주요 발견사항에 신뢰도 부여 (Codex 동의는 보조 지표로만 활용 — 1차 소스 기반 검증이 우선)

**신뢰도 등급:**

| 등급 | 정의 |
|------|------|
| **High** | 복수 전문가 + 공식 문서로 확인 |
| **Medium** | 단일 소스 또는 간접 확인 |
| **Low / Unverified** | 단일 블로그, 개인 의견, 추정 |

### Step 4: 리포트 작성 및 저장

`docs/research/NNNN.YYYY-MM-DD-<topic>-research.md`로 저장. (NNNN: 해당 폴더 내 최대 번호 + 1, 없으면 0001)

## 리포트 구조

```markdown
# 자료 리서치: [주제]

**조사일**: YYYY-MM-DD  
**목적**: [Purpose]  
**Scope**: quick / standard / deep  
**투입 전문가**: [목록]

---

## 1. Executive Summary
- 핵심 발견 3-5줄
- 조사 목적 대비 주요 결론
- 추가 검토 필요 항목

## 2. 핵심 발견사항

### [전문가 A 담당 영역]
[내용, 신뢰도 표시]

### [전문가 B 담당 영역]
[내용, 신뢰도 표시]

[... 전문가 수만큼 반복 ...]

## 3. 교차 검증 결과

### 복수 소스로 확인된 사항 (High Confidence)
- ...

### 소스 간 충돌 / 불일치
- [충돌 내용]: [전문가 A 주장] vs [전문가 B 주장]
  - 원인 분석: [왜 다른가]
  - 결론: [어느 쪽이 더 신뢰 가능한가]

### 미확인 / 공백 영역
- [어떤 정보를 찾지 못했는가]
- [추가 조사 방법 제안]

## 4. 종합 분석
[전문가 발견사항을 통합한 인사이트. 조사 목적에 비추어 해석.]

## 5. 레퍼런스

### [전문가 유형별 분류]
- [제목] (출처, 발행일) — [URL]

## 6. 다음 단계
- 조사 목적 달성 여부
- 추가 조사 필요 항목
- 실행 권고 (구현/학습/결정 등)
```

## Scope별 실행 기준

| 항목 | quick | standard | deep |
|------|-------|----------|------|
| 전문가 수 | 3개 | 3-4개 | 5-6개 |
| 소스 수 (전문가당) | 2-3개 | 4-6개 | 7개 이상 |
| 교차 검증 | 생략 | 주요 사항만 | 전체 충돌 해소 |
| 충돌 데이터 처리 | 양측 나열 | 원인 분석 | 추가 조사로 해소 |
| 보고서 분량 | 1-2페이지 | 3-5페이지 | 5페이지 이상 |

## Constraints

- 모든 수치와 사실 주장에 출처를 명시한다. 출처 없는 내용은 "추정" 또는 "미확인"으로 표기.
- 공식 문서 > 학술 논문 > 기술 블로그 > 커뮤니티 순으로 신뢰도를 부여한다.
- 전문가 간 상충 정보가 있을 때 임의로 한쪽을 선택하지 않는다. 양측을 제시하고 판단 기준을 설명한다.
- 유료 논문은 제목, 저자, 초록까지만 수집한다. 페이월 뒤 내용을 임의 추정하지 않는다.
- 버전 명시가 중요한 기술 문서는 반드시 버전을 포함한다.
- 2년 이상 된 자료는 날짜를 명시하고 현재와 다를 수 있음을 표시한다.

## Troubleshooting

**공식 문서가 없거나 찾기 어려운 경우**: GitHub 레포지토리의 README, Wiki, Issues를 대체 소스로 활용한다. 비공식 소스임을 명시.

**전문가 간 결론이 크게 다른 경우**: 충돌을 숨기지 않는다. 각 전문가의 결론과 근거 소스를 나란히 제시하고, 어떤 상황에서 어떤 결론이 맞는지 맥락을 설명한다.

**주제가 너무 광범위한 경우**: "어떤 측면에 집중할까요?" 라고 범위 좁히기를 요청한다. 조사 시작 전에 해결한다.

**최신 정보가 부족한 경우**: GitHub의 최근 커밋, 이슈, PR을 직접 조사한다. HN의 최신 토론 스레드를 찾는다.

**한국어 자료가 필요한 경우**: 네이버 기술 블로그, 카카오 기술 블로그, 라인 기술 블로그, 토스 기술 블로그를 우선 조사한다.

## Completion

보고서가 `docs/research/`에 저장되고 사용자가 주요 발견사항을 확인하면 완료.