무엇을 만들고 왜 중요한가\n\n당신은 엉켜있는 고객 인터뷰 자료를 공유 가능한 검색 가능한 진실의 원천으로 바꾸는 웹 앱을 만들고 있습니다.\n\n대부분 팀은 이미 고객 인터뷰를 진행하지만, 결과는 문서, 스프레드시트, 슬라이드, 녹화 파일, 개인 노트 등 곳곳에 흩어져 있습니다. 몇 주 후에는 필요한 정확한 인용문을 찾기 어렵고, 맥락이 사라지며, 매 프로젝트마다 동일한 인사이트를 "재발견"합니다.\n\n### 해결하는 문제\n\n이 도구는 세 가지 흔한 실패를 고칩니다:\n\n- 흩어진 노트: 데이터가 너무 많은 곳에 존재하고 일관된 구조가 없음.\n- 찾기 어려운 인사이트: 좋은 리서치도 검색 가능하거나 재사용 가능하지 않으면 사라짐.\n- 일관성 없는 리포팅: 팀마다 인터뷰 요약 방식이 달라 의사결정 근거가 약해짐.\n\n### 대상 사용자\n\n리서치 저장소는 리서처만을 위한 것이 아닙니다. 가장 좋은 버전은 다음을 지원합니다:\n\n- 리서처: 인터뷰를 캡처하고 패턴을 합성함.\n- 프로덕트 매니저와 디자이너: 증거로 의사결정을 검증함.\n- 서포트·성공팀: 실제 고객 고충을 제품 작업에 전달함.\n- 리더십: 무엇이 사실이고 무엇이 변하며 그 이유를 빠르게 이해함.\n\n### 핵심 결과\n\n목표는 단순히 “인터뷰를 저장하는 것”이 아니라 원시 대화를 재사용 가능한 인사이트로 전환하는 것입니다—각 인사이트는 출처 인용, 태그, 그리고 누구나 나중에 신뢰하고 적용할 수 있는 충분한 맥락을 가집니다.\n\n### 작게 시작하고 점차 복잡도를 늘려라\n\n초기 기대치를 설정하세요: 실제 사용자가 쓰게 될 MVP로 런칭한 뒤 실제 사용 행태에 따라 확장합니다. 일상 업무에 맞는 작은 도구가 아무도 업데이트하지 않는 기능 과다 플랫폼보다 낫습니다.\n\n### “잘됐다”의 정의\n\n성공을 실용적으로 정의하세요:\n\n- 이전 리서치를 찾는 시간이 감소\n- 기존 인사이트의 재사용 증가\n- 인용문과 증거로 뒷받침된 더 명확하고 빠른 의사결정\n- 이미 답변된 질문에 대한 중복 인터뷰 감소\n\n## 사용자 작업과 리서치 워크플로우에서 시작하기\n\n기능을 고르기 전에 사람들이 하려는 *작업(jobs)*을 명확히 하세요. 고객 인터뷰 인사이트 앱은 단지 노트를 저장하는 것이 아니라 전체 리서치 사이클의 마찰을 줄일 때 성공합니다.\n\n### 주요 사용자 작업(앱이 반드시 지원해야 하는 것)\n\n대부분 팀은 동일한 핵심 작업을 반복합니다:\n\n- 캡처: 일정 잡기, 녹화, 노트 작성, 파일 첨부\n- 전사: 전사 가져오기(수동 또는 자동)\n- 코드/태깅: 인용문 하이라이트, 태그 적용, 테마 연결\n- 합성: 증거 그룹화, 인사이트 작성, 신뢰도 표기\n- 공유: 요약 발행, 내보내기, 이해관계자 알림\n\n이 작업들이 당신의 제품 어휘(그리고 내비게이션)가 되어야 합니다.\n\n### 인터뷰 → 인사이트 흐름을 매핑하세요\n\n워크플로우를 “인터뷰 계획됨”에서 “의사결정”까지의 간단한 순서로 작성하세요. 일반적인 흐름은 다음과 같습니다:\n\n스케줄링 → 준비(가이드, 참가자 맥락) → 통화/녹화 → 전사 → 인용문 하이라이트 → 태깅 → 합성(인사이트) → 리포팅 → 의사결정/다음 단계.\n\n이제 사람들이 시간이나 맥락을 잃는 지점을 표시하세요. 흔한 고충 지점:\n\n- 핸드오프: 한 사람이 인터뷰하고 다른 사람이 태깅하면 맥락이 사라짐\n- 중복: 동일한 인사이트가 여러 데크와 문서에 다시 쓰임\n- 맥락 부족: 참가자 상세, 날짜, 연구 목표 없는 인용문\n- 분산된 도구: 전사는 한 곳, 태그는 다른 곳, 리포트는 또 다른 곳에 있음\n\n### 앱이 소유할 것과 통합할 것을 결정하세요\n\n경계를 명확히 하세요. MVP의 경우 앱은 보통 *저장소(인터뷰, 인용문, 태그, 인사이트, 공유)*를 소유하고 다음과 통합해야 합니다:\n\n- 캘린더 일정(Google/Microsoft)\n- 화상 통화/녹화(Zoom/Meet/Teams)\n- 전사 서비스(파일 가져오기 또는 API 연결)\n\n성숙한 제품을 재구축하지 않으면서도 단일화된 워크플로우를 제공할 수 있습니다.\n\n### 범위를 좁히는 5–8개의 사용자 스토리\n\n첫 빌드를 안내하는 데 다음 스토리를 사용하세요:\n\n1. 리서처로서 참가자 맥락과 목표가 포함된 인터뷰 레코드를 만들 수 있다.\n2. 리서처로서 전사를 가져와 인터뷰에 연결할 수 있다.\n3. 리서처로서 텍스트를 하이라이트해 인용문으로 저장할 수 있다.\n4. 리서처로서 인용문에 태그를 달고 테마로 묶을 수 있다.\n5. 리서처로서 다수의 인용문으로 뒷받침되는 인사이트를 작성할 수 있다.\n6. 팀원으로서 인사이트에 댓글을 달고 설명을 요청할 수 있다.\n7. 이해관계자로서 편집 없이 공유 가능한 요약을 볼 수 있다.\n\n어떤 기능이 이 스토리 중 하나를 지원하지 않으면, 초기 범위에서 제외하는 것이 좋습니다.\n\n## MVP 범위: 첫날에 필요한 기능들\n\n이런 제품은 모든 문제를 한 번에 해결하려다 지체되는 경우가 많습니다. MVP는 팀이 신뢰성 있게 인터뷰를 캡처하고 나중에 찾을 수 있게 하며, 새로운 프로세스 부담을 만들지 않고 인사이트를 공유할 수 있게 해야 합니다.\n\n### 실용적인 첫날 기능셋\n\n엔드투엔드 워크플로우를 지원하는 최소 집합으로 시작하세요:\n\n- 프로젝트: 이니셔티브별로 작업을 그룹화(예: “온보딩 개선 Q1”).\n- 인터뷰: 참가자 세부, 날짜, 리서처, 링크/파일을 포함한 레코드.\n- 노트 + 인용문: 하이라이트 가능한 발췌(수동으로도 괜찮음)으로 인터뷰에 연결.\n- 태그: 테마, 페르소나, 고충, 기능 등을 라벨링하는 가벼운 방식.\n- 검색 + 기본 필터: 제목, 노트, 인용문 전반 검색; 태그·프로젝트별 필터.\n- 내보내기/공유: 프로젝트 요약 공유 또는 인용문/태그를 CSV/PDF로 추출.\n\n### 필수 vs 있으면 좋은 기능\n\n배포 시 엄격하게 구분하세요:\n\n- 필수: 캡처, 태그, 검색, 공유.\n- 나중에 추가(좋은 기능): AI 요약, 자동 클러스터링, 감성 분석, 고급 대시보드, Slack 요약.\n\nAI를 나중에 쓰고 싶다면 설계 단계에서 대비(깨끗한 텍스트와 메타데이터 저장)를 해두되, MVP가 AI에 의존하지 않게 하세요.\n\n### 복잡도 감소를 위한 제한 설정\n\n배포를 유지하려면 제약을 정하세요:\n\n- 우선 하나의 전사 형식(예: 텍스트 붙여넣기)만 지원하고 모든 벤더를 다루는 것은 미룸.\n- 기본 역할(Owner/Admin/Editor/Viewer)로 시작해 세밀한 권한은 나중에.\n- 인터뷰 노트는 템플릿 3–5개 섹션 정도의 간단한 템플릿으로 시작.\n\n### 첫 실제 사용 타겟 정의\n\n처음에 누구를 위해 만드는지 결정하세요: 예를 들어 5–15명 규모의 리서치/프로덕트 팀이 초기 몇 달에 50–200개의 인터뷰를 가진다고 가정하면 성능, 저장, 권한 기본값에 영향을 줍니다.\n\n### 간단한 릴리스 계획(2–3 마일스톤)\n\n1. 마일스톤 1: 프로젝트 + 인터뷰 + 노트 + 태그(핵심 캡처).\n2. 마일스톤 2: 검색/필터 + 내보내기/공유(팀 간 유용성 확보).\n3. 마일스톤 3: 품질 개선(대량 가져오기, 태깅 UX 개선, 감사 로그).\n\n## 인터뷰, 인용문, 인사이트를 위한 데이터 모델 설계\n\n좋은 리서치 앱의 성패는 데이터 모델에 달려 있습니다. “인사이트”를 단순 텍스트 필드로 모델링하면 나중에 재사용할 수 없는 노트 더미가 됩니다. 반대로 모든 것을 과도하게 모델링하면 팀이 일관되게 데이터를 입력하지 않습니다. 목표는 캡처, 추적 가능성, 재사용을 지원하는 구조입니다.\n\n### 주요 객체(최소 유용 세트)\n\n다음과 같은 소수의 일급 객체로 시작하세요:\n\n- 워크스페이스: 조직 경계(결제, 설정, 멤버)\n- 프로젝트: 리서치 노력 또는 이니셔티브\n- 인터뷰: 세션(날짜/시간, 방법, 출처)\n- 참가자: 대화를 나눈 사람(또는 가명 프로필)\n- 전사: 인터뷰에 연결된 원문 텍스트\n- 노트: 리서처의 관찰과 해석\n- 인사이트: 재사용 가능한 “그래서 어쩌라고” 결론\n- 태그: 그룹핑을 위한 공유 어휘\n\n### 맥락을 보호하는 관계 설계\n\n항상 “이것은 어디에서 왔나?”를 답할 수 있게 모델을 설계하세요:\n\n- 프로젝트는 여러 인터뷰를 가진다.\n- 인터뷰는 하나의 참가자에 연결(그룹 세션이면 여러 명 가능).\n- 전사는 인터뷰에 속한다.\n- 인용문(발췌)은 전사에 속한다이며 여러 인사이트에 참조될 수 있다.\n- 인사이트는 하나 이상의 인용문에 연결되고 프로젝트에도 연결된다(선택적으로 태그로 제품 영역이나 여정 단계 연결).\n\n이 추적성은 인사이트를 재사용하면서도 증거를 보존하게 해줍니다.\n\n### 생각보다 빨리 필요한 메타데이터\n\n다음 필드를 포함하세요: 날짜, 리서처, 출처(모집 채널, 고객 세그먼트), 언어, 동의 상태. 이들은 필터링과 안전한 공유에 필수적입니다.\n\n### 첨부 파일과 외부 미디어\n\n미디어는 기록의 일부로 다루세요: 오디오/비디오 링크, 업로드된 파일, 스크린샷, 관련 문서를 인터뷰(또는 경우에 따라 인사이트)에 첨부합니다. 스토리지를 유연하게 해 추후 도구와 통합하기 쉽게 하세요.\n\n### 변경에 대비한 설계(히스토리 손상 없이)\n\n태그, 인사이트 템플릿, 워크플로우는 진화합니다. 버전 가능한 템플릿(예: 인사이트에 “type”과 선택적 JSON 필드) 사용하고, 공유된 분류를 절대 완전히 삭제하지 말고 폐기(deprecate)하세요. 이렇게 하면 오래된 프로젝트는 읽을 수 있게 유지하면서 새로운 프로젝트는 더 나은 구조를 갖게 됩니다.\n\n## UX 계획: 캡처, 태깅, 합성, 공유\n\n리서치 저장소가 실패하는 이유는 속도가 노트북보다 느리기 때문입니다. UX는 특히 라이브 인터뷰 중 멀티태스킹하는 리서처에게 “올바른” 워크플로우가 가장 빠르게 느껴지도록 설계해야 합니다.\n\n### 팀 사고방식에 맞춘 내비게이션 설계\n\n계층 구조를 예측 가능하고 가시적으로 유지하세요:\n\n워크스페이스 → 프로젝트 → 인터뷰 → 인사이트\n\n워크스페이스는 조직이나 부서를 반영합니다. 프로젝트는 제품 이니셔티브나 연구 스터디에 해당합니다. 인터뷰는 원자료입니다. 인사이트는 팀이 실제로 재사용하는 산출물입니다. 이 구조는 인용문, 노트, 결론이 맥락 없이 떠다니는 문제를 방지합니다.\n\n### 캡처를 즉시 가능하게 만들기\n\n통화 중에 리서처는 속도와 낮은 인지 부하를 필요로 합니다. 우선순위:
\n- : 필수 필드 최소화\n- : 한 번의 클릭으로 “00:12:34” 삽입해 클립과 인용문의 추적성 유지\n- : 참가자, 인터뷰어, 이해관계자 등의 라벨로 정리 시간 절약\n\n노트 작성 흐름을 방해하는 요소는 옵션으로 만들거나 자동 제안으로 처리하세요.\n\n### 합성을 표준화하는 “인사이트 카드”\n\n합성이 자유 형식이면 보고 품질이 들쭉날쭉합니다. 인사이트 카드 패턴은 팀이 발견을 비교하기 쉽게 해줍니다:\n\n- : 평이한 문장으로 핵심 테이크어웨이\n- : 링크된 인용문 또는 순간(타임스탬프 포함)\n- : 왜 중요한가\n- : 누구에게 해당하는가(페르소나, 플랜, 역할)\n- : 증거 기반 신뢰 수준\n\n### 일상 검색을 위한 저장된 뷰\n\n대부분 사용자는 “검색”을 하기보다 짧은 목록을 원합니다. 같은 저장된 뷰를 제공하고, 사람들이 주간으로 돌아오는 대시보드처럼 취급하세요.\n\n### 맥락을 존중하는 공유\n\n인사이트를 내보낼 때 혼란이 생기지 않게 하세요. 환경에 따라 , , 경량 내부 리포트를 지원합니다. 공유된 산출물은 항상 근거(원자료)로 연결되어야 합니다—단순 요약만 제공하지 마세요.\n\n## 권한, 역할, 팀 협업\n\n권한 관리는 "관리 작업"처럼 느껴질 수 있지만, 저장소가 신뢰할 수 있는 진실의 원천이 될지 아니면 피하는 엉킨 폴더가 될지를 직접 좌우합니다. 목표는 단순합니다: 사람들이 안전하게 기여하게 하고, 이해관계자는 위험 없이 인사이트를 소비하게 합니다.\n\n### 명확한 역할 정의(예측 가능하게 유지)\n\n초기에는 네 가지 역할로 시작하고 실제 엣지 케이스가 생길 때까지 추가를 참으세요:\n\n- : 결제, 워크스페이스 설정, 프로젝트 삭제, 관리자 지정 관리.\n- : 멤버·역할·워크스페이스 구성 관리; 기본적으로 모든 프로젝트 접근 가능.\n- : 접근 권한이 있는 프로젝트에서 인터뷰, 인용문, 인사이트 생성·편집.\n- : 읽기 전용; 검색 및 내보내기(허용할 경우) 가능하지만 콘텐츠 변경 불가.\n\n초대 모달 등 UI에서 권한을 명시적으로 보여줘 사람들이 "Editor"가 무슨 권한인지 추측하지 않게 하세요.\n\n### 워크스페이스 레벨 vs 프로젝트 레벨 접근\n\n접근을 두 레이어로 모델링하세요:\n\n- : “이 사람이 팀의 일부인가?”를 답함.\n- : “어떤 리서치를 보고 편집할 수 있나?”를 답함.\n\n실용적 기본값: 관리자(Admin)는 모든 프로젝트 접근 가능; 에디터/뷰어는 프로젝트별로 추가(또는 ‘Product’, ‘Research’, ‘Sales’ 같은 그룹을 통해 추가)되도록 하세요. 새 프로젝트 생성 시 실수로 과도 공유되는 것을 막습니다.\n\n### 이해관계자·계약자를 위한 게스트 접근\n\n필요하면 를 별도 케이스로 추가하세요: 특정 프로젝트에만 초대되고 워크스페이스 디렉터리를 전체 볼 수 없어야 합니다. 시간 제한 접근(예: 30일 만료)과 기본적으로 게스트의 내보내기 제한을 고려하세요.\n\n### 나중에 감사할 기본 추적사항\n\n다음 항목을 추적하세요:\n\n- 누가 인터뷰/인용문/인사이트를 생성·편집했는가\n- 언제 발생했는가\n- (선택) 인사이트의 경우 변경 내용 적어도 일부 기록\n\n이는 리뷰 시 신뢰를 쌓고 실수 정리에 도움을 줍니다.\n\n### 민감한 인터뷰 처리\n\n처음부터 제한된 데이터에 대비하세요:\n\n- : 더 엄격한 멤버십 규칙\n- : 특정 역할(또는 작성자만) 볼 수 있게 설정\n- 콘텐츠가 민감함을 표시하는 명확한 표식, 그래야 넓은 채널에 붙여넣지 않음\n\n## 사람들이 실제로 쓰는 검색, 필터, 태깅\n\n검색은 저장소가 일상 도구가 될지 아니면 메모 무덤이 될지를 좌우합니다. 검색을 ‘모든 것의 검색창’으로 만들지 말고 실제 검색 업무에 맞춰 설계하세요.\n\n### 상위 검색 사용 사례부터 시작하세요\n\n팀이 반복해서 찾는 것들:
\n- 기억나는 특정 인용문(“온보딩이 혼란스럽다”는 말)
