/research

name: research
description: 여러 출처를 조사해 결정에 쓸 근거 문서를 만들 때 사용. 질문을 정하고, 주제에 맞는 조사 갈래를 병렬로 돌리고, 모든 주장을 원문 인용이 있는 출처 대장으로 묶고, 결론을 바꾸는 주장은 독립 출처로 다시 확인한다. Triggers - 리서치, 조사해 줘, 비교 조사, 시장 조사, 기술 조사, 사례 조사, research.

Research

결과물은 읽을거리가 아니라 **결정에 쓸 근거**다. 결론이 먼저 오고, 모든 주장은 어디서 왔는지 원문으로 확인할 수 있어야 한다.

1. 질문 정하기

• 이 조사로 **무엇을 결정하는가**, 범위(지역·기간·대상), 깊이를 한 문단으로 적는다. 결정이 불분명하면 한 번만 묻는다.
• 깊이: **light**(갈래 2개, 출처 5개 안팎), **standard**(갈래 3~4개, 기본), **deep**(갈래 5개 이상, 핵심 주장마다 독립 출처 2개).

2. 조사 갈래 나누기

질문에 맞는 2~5개를 고른다. 겹치지 않게 나누고, 갈래마다 "무엇을 찾아오나"를 한 줄로 적는다.

| 갈래 | 찾는 것 | 먼저 볼 출처 | |---|---|---| | 1차 자료·공식 | 사양, 공식 문서, 법령·정책 원문, 발표 | 공식 사이트, 표준 문서, 관보 | | 기술·구현 | API, 라이브러리, 제약, 버전 | 공식 문서(context7 등), 저장소 README·릴리스 노트 | | 시장·경쟁 | 대안, 가격, 점유, 차별점 | 회사 발표, 가격 페이지, 신뢰할 만한 분석 | | 사례·근거 | 실제 적용 결과, 실패 사례, 연구 | 논문, 엔지니어링 블로그, 사후 분석 | | 사용자 평판 | 실제 사용자의 불만·칭찬 | 앱 리뷰, 커뮤니티, 이슈 트래커 |

3. 병렬 조사

서브에이전트를 띄울 수 있으면 갈래마다 하나씩 동시에 띄운다. 브리프에는 질문, 그 갈래의 범위, 아래 출처 규칙, 돌려받을 형식(출처 대장 행)을 넣는다. 띄울 수 없으면 갈래를 차례로 한다.

**출처 규칙**

• 1차 출처를 먼저 쓴다. 2차 출처만 있으면 그렇다고 표시한다.
• 주장마다 URL, **원문 인용**(그 주장을 뒷받침하는 문장 그대로), 발행·확인 날짜를 붙인다.
• URL을 지어내지 않는다. 열어 보지 못한 출처는 대장에 넣지 않는다.
• 가격·버전·통계처럼 시간이 지나면 바뀌는 사실은 날짜를 꼭 붙인다.
• 검색은 호스트의 웹 검색이나 연결된 검색 MCP(Tavily·Exa 등), 라이브러리 문서는 context7을 쓴다.

4. 출처 대장

| ID | 주장 | 출처(URL) | 원문 인용 | 날짜 | 구분 |
|---|---|---|---|---|---|
| S1 | ... | https://... | "..." | 2026-10-01 | 1차 |

본문에서는 `[S1]`처럼 ID로 가리킨다. 같은 출처를 여러 번 쓰면 행은 하나다.

5. 검증

• **결론을 바꾸는 주장**(이것이 틀리면 결정이 달라지는 것)을 골라 독립 출처로 한 번 더 확인한다. deep은 두 개.
• 출처끼리 다르면 둘 다 적고 어느 쪽을 왜 믿는지 쓴다.
• 확인하지 못한 것은 "미확인"으로 남긴다. 추측으로 채우지 않는다.
• 서브에이전트가 가져온 인용은 핵심 주장만이라도 원문을 다시 열어 문장이 실제로 있는지 본다.

6. 정리

`docs/research/YYYY-MM-DD-<주제>.md`(프로젝트에 정해진 위치가 있으면 그쪽)에 쓴다.

1. **결론**: 결정에 대한 답과 추천, 세 줄 안팎 2. **근거**: 주장별로 `[S#]` 3. **반대 근거와 불확실성**: 미확인, 출처끼리의 충돌, 날짜가 오래된 사실 4. **다음 할 일**: 더 확인할 것, 결정하려면 필요한 것 5. **출처 대장**

조사 결과로 기능을 만들게 되면 이 문서를 `brainstorming`의 입력으로 넘긴다. 다른 프로젝트에도 쓸 사실(예: 자주 쓰는 API의 제약)은 `memory` 스킬로 남긴다.