research

name	research
description	특정 주제·시장·기술·경쟁 상황을 웹(뉴스+블로그+커뮤니티+뉴스레터)과 연결된 커넥터로 깊게 조사해 핵심 발견·근거·시사점으로 종합한다. "이거 좀 리서치해줘 / OO에 대해 조사해줘 / 시장 조사 / 기술 조사 / 경쟁 상황 파악 / 이 주제 깊게 파줘 / 근거 좀 찾아줘" 요청 시.

작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].

심층 리서치 — 주제·시장·기술·경쟁

"이거 좀 알아봐줘"를 받으면, 흩어진 신호를 모아 기획 판단에 쓸 수 있는 근거로 만든다.

1. 질문부터 좁힌다

막연한 주제는 그대로 파면 겉핥기가 된다. 먼저 정확히 뭘 알고 싶은지, 왜 필요한지, 어디까지 깊게를 한 줄로 정리해 확인받는다. 예) "결제 실패 이탈, 경쟁사는 어떻게 푸나?" → 조사 범위: 경쟁 3사 + 업계 베스트프랙티스, 목적: 스펙 근거. 컨텍스트가 있으면 참고한다: cat ~/.pm-copilot/data/context.md

2. 넓게 훑고 좁게 판다 (웹 + 커넥터)

• 소스 범위(넓게): 정식 뉴스뿐 아니라 회사·개인 테크블로그, 커뮤니티/포럼(Hacker News·Reddit·디스콰이엇·링크드인), 뉴스레터, 릴리즈노트/문서까지. 진짜 신호는 여기서 먼저 나온다.
• 연결된 커넥터(사내 문서·노션·슬랙 등)가 있으면 내부 자료도 함께 훑어 안팎을 대조한다.
• 클라우드 예약 실행은 네트워크가 켜져 있어야 웹을 본다. 못 보면 그 사실을 명시하고 가진 자료로만 답한다.

출처 규칙(엄수): 각 항목에 내용 — (출처·유형, 날짜) + 링크. 유형(뉴스/블로그/커뮤니티/뉴스레터)과 신뢰도를 붙인다. 커뮤니티·소문·미검증 블로그는 "미확인/추정"으로 명시하고 과신하지 않는다. 날짜·출처 없으면 넣지 않는다.

3. 출력 구조

1. 핵심 발견 3~5 — 각 발견에 근거(출처·날짜) + "그래서 기획자에게 의미(so what)" 한 줄. 이게 핵심.
2. 더 팔 지점 — 아직 얕은 곳, 상충되는 정보, 다음에 확인할 질문.
3. 한계 — 못 찾은 것/미확인은 솔직히 **"확인 필요"**로 남긴다.

필요하면 저장(개인 리서치 로그): pm-copilot save_brief --kind private --file <초안.md>. 팀 공유는 [[daily-brief]]/post_slack.py로.

원칙

• 환각 절대 금지. 없는 사실·통계·인용은 만들지 않는다. 근거 못 찾으면 지어내지 말고 "확인 필요".
• 왜 중요한지 사람 말로. 사실 나열이 아니라 "우리 판단에 뭘 뜻하는지"까지.
• 반자동: 이건 사람이 결정하기 위한 AI 초안이다. 결론을 대신 내리지 말고, 근거를 놓고 기획자가 판단하게 한다.
• 신입이면 좋은 소스 고르는 법(1차 출처 우선, 날짜 확인, 커뮤니티는 교차검증)을 한 줄 코칭한다.

구분: 정기 경쟁·업계 브리핑은 [[market-radar]], 유저 인터뷰/VOC 종합은 [[research-synthesis]]. 이 스킬은 특정 주제를 한 번 깊게 파는 용도. 결과는 [[write-spec]]·[[prioritize]]로 이어붙이면 좋다.