referencinglisted

# 레퍼런싱 기획 방향을 잡거나 결정을 내리기 어려울 때, 유사 사례와 경쟁사를 빠르게 훑어 "남들은 어떻게 했는가"를 파악하고 우리 기획에 적용할 시사점을 도출한다. ## 언제 쓰나 **발동 신호 — 다음 중 하나라도 해당하면 이 스킬을 쓴다.** - 사용자가 "비슷한 거 찾아줘", "경쟁사는 어때", "레퍼런스 좀", "사례가 있어?" 같은 말을 할 때 - 브레인스토밍 도중 기획 방향이 갈라져 결정이 막힐 때 **남용 금지 — 다음 상황에서는 제안하지 않는다.** - 방향이 이미 정해졌고 사용자가 실행을 요청한 경우 - 단순 문구·디자인 수정처럼 레퍼런스가 결정에 영향을 주지 않는 경우 - 직전 대화에서 이미 레퍼런싱을 한 경우 (같은 주제를 반복 조사하지 않는다) 매번 들이밀지 않고, 정말 도움이 될 때만 제안한다. ## 절차 1. **조사 범위 확정**: 무엇을 조사할지 한 줄로 정한다. ("국내 B2B SaaS 견적 화면 UX 사례" 처럼 구체적으로.) > **외부 검색 정보 유출 가드 (필수).** 외부 검색에는 **일반화된 키워드만** 넣는다. 미공개 제품명·내부 코드네임·고객사/거래처명·개인정보·미공개 수치는 쿼리에서 빼거나 일반 용어로 치환한다("우리 ○○앱" → "B2B 견적 관리 앱"). 외부 검색은 한 번 나가면 회수 불가이고, 비개발자는 무엇이 기밀인지 판단하기 어렵다. 치환이 애매하면 **검색에 쓸 키워드를 먼저 사용자에게 보여주고 동의를 받은 뒤** 검색한다. 2. **가벼운 웹 스캔**: WebSearch와 WebFetch로 핵심 사례 2~4개를 찾아 요약한다(위 유출 가드를 지킨 키워드로만). 사용자가 링크나 이미지를 직접 준 경우 그것을 우선 활용한다. 이 단계만으로 충분한 경우가 대부분이다. **단 구현 레퍼런스(어떻게 만드나)는 웹 요약보다 실제 코드·라이브러리·공식 예제를 최우선으로 가리킨다(다른 언어여도 밑 구조가 참고됨) — "이 앱처럼"은 겉모습이 아니라 그 밑 구조를 읽는 것이다.** 3. **deep-research로 승격하는 조건 — 다음 신호가 있을 때만 사용한다.** - (a) 이번 결정이 되돌리기 어렵다 (아키텍처·가격 정책·핵심 UX 방향 등) - (b) 가벼운 스캔 결과가 서로 엇갈려 판단이 어렵다 - (c) 사용자가 "제대로 조사해줘" 또는 "깊게 봐줘"라고 명시한다 위 조건이 없으면 deep-research를 쓰지 않는다. 과도한 조사는 기획 속도를 늦춘다. 4. **결론 도출**: "남들은 이렇게 한다 → 그래서 우리 기획은 이렇게" 형태의 짧은 한국어 요약으로 마무리한다. 사실 나열이 아니라 시사점 중심으로 쓴다. ## 근거 저장 - 조사 본문이 길면 `docs/references/YYYY-MM-DD-<주제>.md` 파일로 저장한다. - **중요(폴더 생성 책임):** 파일을 저장하기 직전에 `docs/references/` 폴더가 없으면 이 스킬이 직접 만든다. 다른 스킬에 미루지 말고 이 스킬 안에서 자족적으로 처리한다.