5.9 KiB
5.9 KiB
결정 로그
회의 자료(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 등 완전한 기능의 최종 목적지로 유지.
Q8 — 계정·인증·설정 IA (클로즈드 베타 갭) — 확정
2026-08-03 Master 피드백 후 문서화 → 2026-08-03 Master 「1번부터 진행」으로 Q8 확정·구현.
| # | 질문 | 결정 | 근거 | 상태 |
|---|---|---|---|---|
| Q8a | Phase 1 계정 모델? | 초대 코드 클로즈드 베타 유지 (이메일/비번·소셜 로그인 비범위) | Q7 + invite-ops.md |
확정 |
| Q8b | 재접속(로그인) UX? | 초대 코드 + 표시 이름으로 토큰 재발급. 입장 화면에 「이미 가입」탭. (DEMO-YKAVU는 표시 이름으로 사용자 구분) |
서버 login 확장 + 앱 UI | 확정 |
| Q8c | 로그아웃? | P0. 설정에서 로그아웃 → 현재 세션 revoke + 로컬 토큰/유저 클리어 → 입장 화면 | SessionsScreen만으로는 불완전했음 |
확정 |
| Q8d | 설정 IA? | 대화 목록 설정 화면: 말투 · 자율성 · 로그인 세션 · 데이터 흐름 · 로그아웃 | 발견성 | 확정 |
| Q8e | 계정 삭제/탈퇴? | Phase 1 앱 UI 비범위 (운영 수동) | 베타 범위 | 확정 |
상세 명세: account-settings-ia.md.
Q9 — L2 “자동 응답”의 제품 의미 — 제안
| # | 질문 | 제안 결정 | 근거 | 상태 |
|---|---|---|---|---|
| Q9 | L2는 무엇인가? | 목표(PRD §2.2): 상대 메시지 수신 → 화이트리스트면 초안·발송까지 무인. 현재 구현: 클라이언트가 와카뷰 발송을 시도할 때 서버가 화이트리스트면 approved 없이 통과시키는 발송 게이트. Phase 1 베타 직전 최소는 게이트를 유지하되, UI/카피로 “상대가 오면 알아서 답한다”고 오해되지 않게 하고, 수신 트리거 자동응대는 별도 로드맵 항목으로 분리 |
2026-08-03 실사용에서 L2+주제 등록 후에도 ✨ 없이는 응답이 없어 혼란 | 제안 |
아직 열려 있는 하위 질문 (PoC/실사용 의존 — D 이후)
- 와카뷰 응답 임계점·화이트리스트 기본 주제 목록 (실사용 데이터)
- 자율성 기본 시작 레벨 L1 vs L2 (Q3 인터뷰)
- 상표 정식 등록 여부 (Q6은 "와카뷰"로 명칭 확정, 등록 절차는 베타 반응 이후)
- 베타 참가자 모집 규모와 방식
- Q9 제안 → Master 확정 (Q8은 2026-08-03 확정)