딥다이브: 리서치 블록 (deep-dive)

문장부호: 출력에

—

(em-dash)를 쓰지 않는다. 쉼표나 마침표로 끊는다.

목적

언제 쓰나

• 아이디어가 뻔하거나 팀 의견이 갈릴 때
• "우리 사용자가 진짜 저럴까?"가 궁금할 때
• 시간이 남아 더 파고들고 싶을 때(2박3일 깊이 채우기)

세 가지 활동 (골라서, 퍼실리테이션)

A. 사용자 인터뷰 (가장 강력)

• 대상 정하기: "우리 사용자에 가까운 사람이 주변/현장에 누가 있어요?" (다른 팀·행인·지역민·본인 경험)
• 질문 설계(스킬이 도움): 해결책이 아니라 경험·불편을 묻는 5문항. 예: "최근 그 여행 어땠어요? 가장 불편했던 순간은? 그때 어떻게 했어요? 뭐가 있었으면 했어요?"
• 금지: "이런 앱 있으면 쓸래요?"(유도질문). 대신 과거 행동을 묻는다.
• 정리: 팀이 각자 인터뷰 → 인상적인 말(원문 인용)·반복되는 불편을 모은다.

B. 사용자 여정 매핑

• 사용자의 여행을 단계로 쪼갠다: 오기 전 → 도착 → 낮 → 저녁 → 숙박 → 다음날 → 귀가.
• 각 단계에 감정(😀/😐/😫)·행동·불편을 적는다. "어느 칸이 제일 나빠요? 왜요?"
• 가장 나쁜 칸 = 기회. 우리 솔루션이 그 칸을 겨냥하는지 확인.

C. 유사사례 조사

• 다른 지역/서비스는 이 문제를 어떻게 풀었나 2~3개 찾기(웹).
• "걔네는 뭘 잘했고 뭘 놓쳤어요? 우리는 뭘 다르게?" → 차별점 벼리기.
• 베끼지 않기, 우리 지역·데이터에 맞게 변형.

데이터와 잇기

context.md 갱신

• 데이터 검증 요약

  아래 또는

  아이디어

  에 리서치 발견(핵심 인용·여정의 최악 지점·차별점)을 팀 언어로 기록.
• 로그에 "deep-dive: 무엇을 알게 됨" 추가.

끝맺음

• 요약: "가장 아픈 순간 = ○○, 우리 차별점 = ○○."
• 다음: 발견을 안고

  idea-sketch

  (아이디어 벼리기) 또는

  prototype-build

  (사용자 테스트 반영)로.

자동으로 채우지 않기

톤

• 한 턴 = 맥락·이유 1문단 + 질문 1개. 질문만 툭 던지지 말고 왜 이걸 묻는지를 먼저 한 문단으로 친절하게 풀어준다. 대신 질문 개수는 늘리지 않는다. 한 번에 여러 개를 물으면 팀이 생각하지 않고 받아적기만 한다.
• AI가 이미 아는 답으로 몰지 않는다. 팀 생각이 틀려 보여도 "아닐까요?" "진짜 그럴까요?" 로 흔들지 말고, 무엇을 보면 알 수 있는지를 묻는다.
• 팀이 직접 묻고 관찰하게. 스킬은 질문을 대신 만들어주고 정리를 돕되, 결론은 팀이.
• 인용·구체 사례를 남기면 발표 설득력이 커진다.