iykyka/docs/decision-log.md

결정 로그

회의 자료(idea-meeting-2026-06-29.html)의 논점 Q1~Q7에 대한 결정을 추적한다.

상태 범례

• 제안: 문서 작성용 잠정안 (회의 전)
• 확정: Master가 Phase 1 C(베타 직전)에서 승인·고정한 값. 이후 번복 시 이 로그와 근거로 만든 Vision/PRD/기술설계를 함께 갱신한다.

#	질문	결정	근거	상태
Q1	AI 와카뷰로 확정?	예	"기록/관계 피로/프라이버시" 축은 기능 묶음이라 한 문장 정체성이 약함. 와카뷰는 "나를 대신해 남과 대화하는 나"로 명확히 정의됨	확정
Q2	타깃: 대중 vs 회사?	대중 우선	회사용은 워크스페이스 도입 결정권자를 설득해야 해 진입 장벽이 큼. 대중은 개인 대 개인으로 바로 가치 체감 가능(읽씹 종결). B2B는 v3 확장 항목으로 남김	확정
Q3	자율성 몇 단계까지 출시?	L0~L2만	L3(자리비움 응대)·L4(와카뷰 협상)는 신뢰가 쌓이기 전엔 리스크 대비 이득이 낮음. "켜는 만큼만 만든다" 원칙 적용. 기본 자율성 레벨(L1 vs L2 시작점)과 화이트리스트 기본 주제는 사람 PoC/실사용 후 확정	확정
Q4	사칭 우려 대응 충분한가?	1차 설계로 베타 진입, PoC #3로 검증	와카뷰 뱃지·거부권·확정 불가·본인확인 고정 문구는 설계상 필수. 상대 신뢰 여부는 D(사람 PoC #3)에서 측정	확정
Q5	MVP 데모 시나리오 1개는?	읽씹 종결 + 단톡 따라잡기 (묶음)	둘 다 L0~L2, 같은 파이프라인(수신 요약 → 맥락 응답 초안) 공유. 발송 자동화 없이도(단톡 따라잡기) 가치 증명 가능	확정
Q6	서비스 이름	"와카뷰 (Ykavu)"	기존 가칭 "분신"에서 변경(2026-07-31). "분신"(分身)은 메신저 브랜드로 부르기 무겁고, 焚身(분신자살)과 동음이의 리스크도 있었음. "와카뷰(Ykavu)"는 Master가 최종 선택한 브랜드명 — 메신저 이름으로 짧고 부르기 쉬움. 상표 등록 여부는 여전히 베타 반응 이후 재검토	확정 (2026-07-31 명칭 변경)
Q7	자체 앱 vs OS 레이어 시작점	자체 앱(클로즈드 베타) 먼저 → OS 레이어는 v2	아래 "Q7 상세 근거"	확정

확정일: 2026-07-30 (Phase 1 C — Master 승인 하에 제안 → 확정).

Q7 상세 근거 — 왜 자체 앱을 먼저 만드는가

PLANNING.md §6에서는 채택 장벽이 낮다는 이유로 OS 레이어(읽기 전용 허브)를 먼저 검증하는 안을 제시했다. 하지만 실제 실행 순서를 정할 때는 아래 이유로 자체 앱 클로즈드 베타를 먼저 둔다.

• 카카오톡·인스타그램은 자동화/크롤링을 정책상 제한하는 경우가 많아, OS 레이어의 "발송" 쪽은 처음부터 제3자 API 제약을 받는다. 아직 검증되지 않은 핵심 가설을 제3자 플랫폼 제약과 동시에 검증하면 실패 원인을 구분할 수 없다.
• 자체 앱(초대 기반 클로즈드 베타)에서는 와카뷰 로직·UX(뱃지, 거부권, 에스컬레이션)를 온전히 구현해 통제된 소규모 그룹으로 "이게 정말 쓸만한가"만 순수하게 검증할 수 있다.
• 이 단계에서 만든 요약/응답 초안 생성 로직은 이후 OS 레이어(문자·이메일 우선)로 그대로 재사용 가능.

순서: ① 자체 앱 클로즈드 베타로 핵심 가설 검증 → ② 검증되면 OS 레이어 읽기 전용 허브 → ③ 자체 앱은 L3·L4 등 완전한 기능의 최종 목적지로 유지.

아직 열려 있는 하위 질문 (PoC/실사용 의존 — D 이후)

• 와카뷰 응답 임계점·화이트리스트 기본 주제 목록 (실사용 데이터)
• 자율성 기본 시작 레벨 L1 vs L2 (Q3 인터뷰)
• 상표 정식 등록 여부 (Q6은 "와카뷰"로 명칭 확정, 등록 절차는 베타 반응 이후)
• 베타 참가자 모집 규모와 방식