From 97d70028e3e83d362c025d21c73299bc6b0e2db8 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 29 Jul 2026 06:25:11 +0000 Subject: [PATCH] Flesh out full planning doc set: vision, PRD, tech design, risks, roadmap Resolves the open Q1-Q7 questions as tentative decisions (self-app beta first, target consumers, MVP scenario = read-receipt relief + group-chat catch-up, autonomy capped at L0-L2) and builds the standard deliverable set on top of them, ready for review at the next meeting. --- README.md | 15 +++++++-- docs/PLANNING.md | 42 ++++++++++++----------- docs/PRD.md | 79 ++++++++++++++++++++++++++++++++++++++++++++ docs/decision-log.md | 41 +++++++++++++++++++++++ docs/risk-log.md | 21 ++++++++++++ docs/roadmap.md | 38 +++++++++++++++++++++ docs/tech-design.md | 75 +++++++++++++++++++++++++++++++++++++++++ docs/vision.md | 41 +++++++++++++++++++++++ 8 files changed, 331 insertions(+), 21 deletions(-) create mode 100644 docs/PRD.md create mode 100644 docs/decision-log.md create mode 100644 docs/risk-log.md create mode 100644 docs/roadmap.md create mode 100644 docs/tech-design.md create mode 100644 docs/vision.md diff --git a/README.md b/README.md index 993c223..7b45bda 100644 --- a/README.md +++ b/README.md @@ -2,8 +2,19 @@ 카카오톡 대안 메신저 아이디어 — "나를 대신해 남과 대화하는 AI 분신"이 있는 메신저 프로젝트. +## 문서 + - 원본 회의 자료: [`docs/idea-meeting-2026-06-29.html`](./docs/idea-meeting-2026-06-29.html) - 기획 진행 방법: [`docs/PLANNING.md`](./docs/PLANNING.md) +- 결정 로그 (Q1~Q7): [`docs/decision-log.md`](./docs/decision-log.md) +- Vision Doc: [`docs/vision.md`](./docs/vision.md) +- PRD (v1 클로즈드 베타): [`docs/PRD.md`](./docs/PRD.md) +- 기술 설계서: [`docs/tech-design.md`](./docs/tech-design.md) +- 리스크 로그: [`docs/risk-log.md`](./docs/risk-log.md) +- 로드맵: [`docs/roadmap.md`](./docs/roadmap.md) -현재 단계: 아이디어 발산 및 컨셉 심화 완료. 다음 단계는 `docs/PLANNING.md`의 프로세스를 따라 -컨셉 확정 → MVP 시나리오 선정 → PRD 작성 순으로 진행합니다. +## 현재 단계 + +아이디어 발산 → 컨셉 심화 → 기획 문서 세트(Vision/PRD/기술설계/리스크/로드맵) 초안 작성까지 완료. +`docs/decision-log.md`의 결정은 아직 **잠정안**이므로, 실제 회의에서 확정/수정이 필요합니다. +다음 단계는 `docs/PLANNING.md` §8 체크리스트의 남은 항목(기술 PoC, 프로토타입, 유저 인터뷰)입니다. diff --git a/docs/PLANNING.md b/docs/PLANNING.md index 4ae8301..6f2fe59 100644 --- a/docs/PLANNING.md +++ b/docs/PLANNING.md @@ -83,31 +83,35 @@ 두 트랙은 경쟁 관계가 아니라 순서 문제다. - **OS 레이어(알림 관통형)**: 채택 장벽이 낮다(앱 설치+권한 허용만). 대신 발송 자동화는 각 앱의 - API/자동입력 제약을 받아 범위가 좁다. 안드로이드 우선, 문자/이메일처럼 안정적 API가 있는 채널부터. -- **자체 메신저**: 완전한 기능(L4 분신 협상 등)이 가능한 최종 목적지. 대신 "메신저를 옮겨야 한다"는 - 채택 장벽이 크다. + API/자동입력 제약을 받아 범위가 좁고, 검증 안 된 핵심 가설(분신의 자연스러움·신뢰)과 제3자 + 플랫폼 제약(카카오톡 등의 자동화 정책)이 동시에 섞여 실패 원인을 구분하기 어렵다. +- **자체 메신저(클로즈드 베타)**: 분신 로직·UX(뱃지, 거부권, 에스컬레이션)를 온전히 구현해 + 통제된 소규모 그룹으로 핵심 가설만 순수하게 검증할 수 있다. "메신저를 옮겨야 한다"는 채택 + 장벽은 있지만, 베타 단계에서는 어차피 소규모 초대 기반이라 큰 문제가 아니다. -**권장 순서:** OS 레이어의 "읽기 전용 허브"(로드맵 1단계, 발송 권한 없음)로 가장 낮은 신뢰 비용부터 -검증 → 반응이 확인되면 초안 제안(2단계) → 자체 메신저는 그 다음 자연스러운 업그레이드 경로로 둔다. -두 트랙을 동시에 만들지 않는다. +**최종 결정 (`decision-log.md` Q7 참고):** 자체 앱 클로즈드 베타를 먼저 만들어 핵심 가설을 +검증하고, 검증되면 그 로직을 재사용해 OS 레이어(읽기 전용 허브, 문자·이메일 우선)로 확장해 +채택 장벽을 낮춘다. 두 트랙을 동시에 만들지 않는다. (이 판단의 상세 근거는 `decision-log.md` +"Q7 상세 근거" 참고 — 이 섹션은 그 판단을 반영해 갱신되었다.) -## 7. 표준 산출물 세트 (다음에 작성할 문서) +## 7. 표준 산출물 세트 -이 문서(PLANNING.md)는 "어떻게 진행할지"에 대한 가이드다. §2의 Q1~Q7이 확정되면 아래 문서를 -순서대로 만든다. 지금 시점에 전부 미리 만들지 않는다 — 앞 단계가 안 끝나면 다음 문서는 다시 쓰게 된다. +§2의 Q1~Q7에 잠정 결정을 내리고 아래 문서를 작성했다. 결정이 뒤집히면 이 문서들도 함께 갱신한다. -1. **Vision Doc (1페이지)** — 문제, 타깃, 가치제안 한 문장, 성공 지표 -2. **PRD** — MVP 시나리오 기준 기능 명세, 유저 플로우, 엣지 케이스, 화면 정의 -3. **기술 설계서** — 온디바이스/서버 경계, 데이터 흐름, 에스컬레이션 로직 -4. **리스크 로그** — 회의 자료 §2-6, §oslayer §4의 리스크를 실제 완화 상태와 함께 추적 -5. **로드맵 & 마일스톤** — §5의 L0~L4 단계, §6의 OS 레이어→자체 앱 전환 시점 반영 -6. **결정 로그** — 회의에서 확정된 것과 보류된 것을 계속 누적 기록 (이 프로젝트 자체 아이디어이기도 함) +1. [`vision.md`](./vision.md) — 문제, 타깃, 가치제안 한 문장, 성공 지표 +2. [`PRD.md`](./PRD.md) — MVP 시나리오 기준 기능 명세, 유저 플로우, 엣지 케이스 +3. [`tech-design.md`](./tech-design.md) — 온디바이스/서버 경계, 데이터 흐름, 에스컬레이션 로직 +4. [`risk-log.md`](./risk-log.md) — 회의 자료 §2-6, §oslayer §4의 리스크를 완화 상태와 함께 추적 +5. [`roadmap.md`](./roadmap.md) — L0~L4 단계, OS 레이어→자체 앱 전환 시점 반영 +6. [`decision-log.md`](./decision-log.md) — Q1~Q7 결정과 근거, 계속 누적 기록 ## 8. 다음 액션 체크리스트 -- [ ] §2의 Q1~Q7을 회의에서 실제로 확정 (또는 보류 사유 기록) -- [ ] Vision Doc 1페이지 작성 -- [ ] MVP 시나리오 1~2개로 확정 (§3 권장안 검토) -- [ ] §4의 기술 PoC 중 1번(말투 학습)과 2번(알림 접근 안정성) 먼저 진행 +- [x] §2의 Q1~Q7 잠정 결정 — `decision-log.md` (실제 회의에서 재확인/뒤집기 필요) +- [x] Vision Doc 작성 — `vision.md` +- [x] MVP 시나리오 확정 (읽씹 종결 + 단톡 따라잡기) — `PRD.md` +- [x] PRD, 기술 설계서, 리스크 로그, 로드맵 작성 +- [ ] §4의 기술 PoC 중 1번(말투 학습)과 3번(사칭/신뢰 수용성) 먼저 진행 — 아직 코드/실사용 검증 없음 - [ ] 클릭 가능한 프로토타입(Figma 등) 제작, 뱃지·거부권 UX 포함 - [ ] 5~10명 대상 유저 인터뷰로 "AI 대리 응답 수용성"(Q3) 검증 +- [ ] 실제 회의에서 이 문서 세트 전체를 리뷰하고 Q1~Q7을 정식 확정 diff --git a/docs/PRD.md b/docs/PRD.md new file mode 100644 index 0000000..8c46164 --- /dev/null +++ b/docs/PRD.md @@ -0,0 +1,79 @@ +# PRD — 분신 v1 (클로즈드 베타) + +범위: `vision.md`의 가치 제안을 자체 앱 클로즈드 베타로 구현한다. 자율성 L0~L2, 시나리오는 +"읽씹 종결"과 "단톡 따라잡기" 두 가지로 한정한다. (근거: `decision-log.md` Q3, Q5) + +## 1. 페르소나 + +- **주 사용자(분신을 쓰는 나)** — 메신저 응답 압박을 자주 느끼는 개인. 분신을 켜고, 응답을 + 검토·승인하거나 위임 범위를 조정한다. +- **상대방** — 분신 사용자와 대화하는 사람. 앱을 설치하지 않았어도 분신의 응답을 받을 수 있어야 + 하며(v1은 자체 앱 내부이므로 상대방도 사실상 앱 사용자), 분신 여부를 언제든 확인·거부할 수 있다. + +## 2. 유저 플로우 + +### 2.1 온보딩 (말투 학습) +1. 가입 시 기존 대화 일부 임포트 또는 짧은 질문 응답으로 말투 초기 세팅 (목표: 5분 이내) +2. 관계별 페르소나 초기값 설정 — 최소 "가까운 사이 / 공식적인 사이" 2종만 v1에서 지원 +3. 분신 자율성 기본값은 **L0(비서 모드)** — 사용자가 명시적으로 올려야 L1, L2로 이동 + +### 2.2 읽씹 종결 시나리오 (핵심) +1. 사용자가 "방해금지"(수면 중 등) 상태를 켜거나, 앱이 비활성 상태 감지 시 자동 제안 +2. 상대가 메시지를 보냄 → 분신이 맥락(상태, 최근 활동 패턴)을 보고 응답 초안 생성 +3. **L1**: 사용자에게 "지금 자동 응답 보낼까요?" 알림 → 승인 시 발송 (기본값) +4. **L2**: 사용자가 화이트리스트에 등록한 상대·주제(예: "가벼운 안부, 시간 문의")에 한해 + 즉시 자동 발송, 사후 알림 +5. 상대에게는 분신 뱃지가 붙은 말풍선으로 표시됨 (3.1 참고) +6. 사용자가 복귀하면 미응답/보류 항목 요약 제공, 필요 시 후속 메시지 작성 + +### 2.3 단톡 따라잡기 시나리오 +1. 사용자가 오랜만에 단톡방 진입 또는 "안 본 동안 요약" 요청 +2. 분신이 **나에게 멘션된 것 / 결정된 사항** 위주로 3~5줄 요약 +3. 답장이 필요한 항목에는 초안 버튼 제공 (발송은 항상 사용자 승인 — 이 시나리오는 L0 고정, + 자동 발송 없음) + +## 3. 기능 명세 + +### 3.1 P0 (v1 필수) + +| 기능 | 설명 | +|---|---| +| 분신 뱃지 | 분신이 작성한 말풍선은 사람 말풍선과 시각적으로 구분(점선 테두리 + 뱃지 라벨) | +| 자율성 설정(L0~L2) | 전역 기본값 + 상대별 예외 설정 | +| 응답 승인 UI | L1 초안을 한 탭으로 검토·수정·발송 | +| 화이트리스트 주제 | L2에서 자동 발송을 허용할 주제/상대를 사용자가 직접 등록 | +| 에스컬레이션 규칙 | 금전, 약속 확정, 감정적/민감 내용 감지 시 자동 처리 금지, 무조건 사용자에게 넘김 | +| 실시간 본인 확인 | 상대가 "지금 본인이야 분신이야?" 물으면 분신이 스스로 정직하게 답함 | +| 거부권 | 상대가 "분신 말고 본인이랑만" 요청 시 해당 대화에서 자동응대 즉시 중단 | +| 사후 알림 + 되돌리기 | 분신이 취한 모든 자동 행동은 알림 로그에 남고 원클릭 취소 가능 | +| 단톡 요약(멘션 기준) | 안 본 동안 나 언급/결정 사항만 골라 요약 | +| 관계별 페르소나(최소 2종) | 가까운 사이 / 공식적인 사이 톤 구분 | + +### 3.2 P1 (v1 이후 곧) + +- 답장 마감 알림(내가 "이따 답장" 누르면 나에게만 리마인드) +- 스팸/도배 감지 시 응대 자동 중단 +- 관계 메모(호칭, 금기어 기억) + +### 3.3 P2 / 명시적 범위 밖 (v2+) + +- L3 자리비움 전면 응대, L4 분신 협상 — `roadmap.md` 참고 +- OS 레이어(타 앱 알림 관통) — `roadmap.md` 참고 +- 다중 페르소나, 구독 결제 — 수익 모델은 베타 이후 + +## 4. 엣지 케이스 + +| 상황 | 처리 | +|---|---| +| 분신이 잘못된 맥락으로 응답 초안을 만듦 | L1은 발송 전 사용자 검토이므로 그 자리에서 수정. L2는 사후 알림 + 되돌리기 | +| 상대가 분신에게 확정을 요구(예: "그럼 3시 확정이지?") | 분신은 확정 불가 — "본인 확인 필요"로 응답하고 사용자에게 에스컬레이션 | +| 상대가 짧은 시간에 메시지 도배 | 스팸 감지 임계치 초과 시 응대 중단, 사용자에게 보고 (P1이지만 안전 관련이라 v1 최소 버전 필요) | +| 사용자가 여러 상대에게 다른 자율성 레벨을 원함 | 상대별 예외 설정으로 지원 (전역 기본값 + 오버라이드) | +| 온보딩 시 임포트할 기존 대화가 없음 | 질문 기반 초기 세팅 경로로 폴백 | + +## 5. 성공 지표 + +`vision.md`의 v1 성공 지표를 그대로 따른다. 이 PRD 범위에서 추가로 추적할 것: + +- L1 초안 승인율(수정 없이 그대로 발송된 비율) — 말투 학습 품질의 대리 지표 +- L2 화이트리스트 자동발송 후 되돌리기 사용률 — 낮을수록 신뢰 신호 diff --git a/docs/decision-log.md b/docs/decision-log.md new file mode 100644 index 0000000..f50ce29 --- /dev/null +++ b/docs/decision-log.md @@ -0,0 +1,41 @@ +# 결정 로그 + +회의 자료(`idea-meeting-2026-06-29.html`)의 논점 Q1~Q7에 대한 결정을 추적한다. +상태가 **제안**인 항목은 실제 회의에서 확정되지 않았고, 이 문서 이후의 Vision/PRD/기술설계서를 +쓰기 위해 잠정적으로 내린 판단이다. 다음 회의에서 뒤집히면 이 로그와 그 근거로 만들어진 +하위 문서를 함께 갱신한다. (이 "결정 로그" 자체가 회의 자료 §1의 "번복 추적 결정 로그" 아이디어를 +그대로 실천하는 것이기도 하다.) + +| # | 질문 | 결정 | 근거 | 상태 | +|---|------|------|------|------| +| Q1 | AI 분신으로 확정? | **예** | "기록/관계 피로/프라이버시" 축은 기능 묶음이라 한 문장 정체성이 약함. 분신은 "나를 대신해 남과 대화하는 나"로 명확히 정의됨 | 제안 | +| Q2 | 타깃: 대중 vs 회사? | **대중 우선** | 회사용은 워크스페이스 도입 결정권자를 설득해야 해 진입 장벽이 큼. 대중은 개인 대 개인으로 바로 가치 체감 가능(읽씹 종결). B2B는 v3 확장 항목으로 남김 | 제안 | +| Q3 | 자율성 몇 단계까지 출시? | **L0~L2만** | L3(자리비움 응대)·L4(분신 협상)는 신뢰가 쌓이기 전엔 리스크 대비 이득이 낮음. "켜는 만큼만 만든다" 원칙 적용 | 제안 | +| Q4 | 사칭 우려 대응 충분한가? | **1차로는 충분, 실사용 검증 필요** | 분신 뱃지·거부권·확정 불가 원칙은 설계상 합리적이나, 실제 상대방이 이를 신뢰하는지는 §4 기술 PoC #3(사용자 테스트)로 검증 전까지는 가설 | 제안 | +| Q5 | MVP 데모 시나리오 1개는? | **읽씹 종결 + 단톡 따라잡기 (묶음)** | 둘 다 L0~L2, 같은 파이프라인(수신 요약 → 맥락 응답 초안) 공유. 발송 자동화 없이도(단톡 따라잡기) 가치 증명 가능해 안전하게 시작 가능 | 제안 | +| Q6 | 서비스 이름 | **"분신" (가칭)** | 한국어로 직관적이고 정체성을 바로 전달함. 최종 브랜딩/상표 조사는 MVP 검증 이후 진행 | 제안 (가칭) | +| Q7 | 자체 앱 vs OS 레이어 시작점 | **자체 앱(클로즈드 베타) 먼저 → OS 레이어는 v2 성장 전략** | 근거는 아래 "Q7 상세 근거" 참고 | 제안 | + +## Q7 상세 근거 — 왜 자체 앱을 먼저 만드는가 + +`PLANNING.md` §6에서는 채택 장벽이 낮다는 이유로 OS 레이어(읽기 전용 허브)를 먼저 검증하는 안을 +제시했다. 하지만 실제 실행 순서를 정할 때는 아래 이유로 **자체 앱 클로즈드 베타를 먼저** 두는 것이 더 낫다고 판단한다. + +- 카카오톡·인스타그램은 자동화/크롤링을 정책상 제한하는 경우가 많아, OS 레이어의 "발송" 쪽은 + 처음부터 제3자 API 제약을 받는다. 아직 검증되지 않은 핵심 가설(분신이 자연스럽게 느껴지는가, + 신뢰를 얻는가)을 제3자 플랫폼 제약과 동시에 검증하면 실패 원인을 구분할 수 없다. +- 자체 앱(초대 기반 클로즈드 베타)에서는 분신 로직·UX(뱃지, 거부권, 에스컬레이션)를 온전히 + 구현해 통제된 소규모 그룹으로 "이게 정말 쓸만한가"만 순수하게 검증할 수 있다. +- 이 단계에서 만든 요약/응답 초안 생성 로직은 이후 OS 레이어(문자·이메일 우선)로 그대로 재사용 가능 — + 버리는 작업이 아니다. + +**따라서 순서:** ① 자체 앱 클로즈드 베타로 핵심 가설(분신의 자연스러움·신뢰) 검증 → ② 검증되면 +OS 레이어 읽기 전용 허브(문자·이메일 우선, 안드로이드)로 채택 장벽을 낮춰 확산 → ③ 자체 앱은 +L3·L4 등 완전한 기능의 최종 목적지로 유지. + +## 아직 열려 있는 하위 질문 + +- 분신 응답 임계점(어디까지 자동, 어디부터 사람에게) — Q3 확정 후에도 화이트리스트 주제 목록은 + 실사용 데이터로 계속 조정 필요 +- 상표/네이밍 최종안 (Q6은 가칭) +- 베타 참가자 모집 규모와 방식 (§로드맵 참고) diff --git a/docs/risk-log.md b/docs/risk-log.md new file mode 100644 index 0000000..d8c7c37 --- /dev/null +++ b/docs/risk-log.md @@ -0,0 +1,21 @@ +# 리스크 로그 + +회의 자료(§2-6, §oslayer §4)와 `PRD.md`/`tech-design.md` 작성 중 식별된 리스크를 한곳에서 +추적한다. 완화 방안이 "설계상 반영됨"인 항목도 실사용 검증 전까지는 가설이다. + +| 리스크 | 영향 | 완화 방안 | 상태 | +|---|---|---|---| +| 분신이 틀린 응답/약속을 자동 발송 | 사용자 신뢰 상실, 관계 손상 | 사후 알림 + 원클릭 되돌리기, 확정성 있는 내용은 항상 보류 | 설계 반영 — 실사용 검증 필요 | +| 상대가 분신을 사칭/신뢰 문제로 인식 | 확산 저해, 컨셉 자체 붕괴 | 분신 뱃지, 실시간 본인 확인, 거부권 | 설계 반영 — Q4 핵심 리스크, PoC #3로 검증 예정 | +| 자동응대가 스팸에 악용됨 | 무한 응답, 사용자 피해 | 스팸/도배 감지 시 응대 중단 (P1, v1 최소 버전 필요) | 부분 반영 — v1 최소 버전 필요, `PRD.md` §4 | +| 에스컬레이션 판정기 오탐/누락 | 안전선 위반(금전/약속 자동 확정) 가능성 | 규칙 기반 + 애매하면 항상 에스컬레이션(fail-safe) | 설계 반영 — 오탐/누락률은 베타 로그로 계속 튜닝 | +| 온디바이스 말투 학습 품질 미흡 | "나답지 않다"는 인상, 핵심 가치 제안 실패 | PoC #1(§4)로 사전 검증, 교정 학습으로 지속 개선 | 미검증 — 최우선 PoC | +| 배터리/성능 부담 (온디바이스 추론) | 사용자 이탈 | 경량 모델 우선, 부족 시 서버 폴백 | 미검증 | +| 베타 참가자 확보 어려움 | 검증 지연 | 소규모 지인 네트워크 초대 기반 클로즈드 베타로 시작 | 계획 단계 | +| (v2 대비) 카카오톡/인스타 알림 파싱이 앱 업데이트로 깨짐 | OS 레이어 확장 시 유지보수 부담 | v1 범위에서 제외, v2 착수 시 안정적 API 채널(문자·이메일) 우선 | v1 범위 밖 — 그대로 유지 | +| (v2 대비) iOS 플랫폼 정책 제약 | OS 레이어 iOS 확장 어려움 | 안드로이드 우선 검증 후 iOS는 자체 앱 전환 유도 | v1 범위 밖 — 그대로 유지 | + +## 우선순위 + +지금 시점에서 가장 먼저 확인해야 할 두 가지는 **온디바이스 말투 학습 품질**과 **사칭/신뢰 수용성**이다. +이 둘이 무너지면 나머지 리스크 완화는 의미가 없다. `PLANNING.md` §4의 PoC #1, #3을 최우선으로 진행한다. diff --git a/docs/roadmap.md b/docs/roadmap.md new file mode 100644 index 0000000..2e76ecf --- /dev/null +++ b/docs/roadmap.md @@ -0,0 +1,38 @@ +# 로드맵 & 마일스톤 + +`decision-log.md`의 Q3(자율성 단계), Q7(자체앱→OS레이어 순서)에 따른 단계별 계획. +각 단계는 이전 단계의 핵심 가설이 검증되어야 다음으로 넘어간다 — 일정보다 검증 결과가 게이트다. + +## Phase 0 — 기술 PoC (착수 즉시) + +- 온디바이스 말투 학습 품질 검증 (`PLANNING.md` §4 PoC #1) +- 에스컬레이션 판정기(규칙 기반) 최소 프로토타입으로 오탐/누락 감 잡기 +- 목표: "분신이 나답게 느껴지는가"에 대해 Go/No-Go 판단 근거 확보 + +## Phase 1 — v1 클로즈드 베타 (자체 앱, `PRD.md` 범위) + +- 자율성 L0~L2, 시나리오: 읽씹 종결 + 단톡 따라잡기 +- 안드로이드 우선, 초대 기반 소규모 베타 (지인 네트워크) +- 게이트: `vision.md` 성공 지표(자연스러움 70%, 거부율 10% 미만, 안전선 위반 0건) 충족 여부 + +## Phase 2 — L3 확장 + 베타 확대 + +- 자리비움 전면 응대(L3) 추가 — Phase 1에서 신뢰가 검증된 경우에만 +- 관계 메모, 답장 마감 알림 등 P1 기능 +- 베타 규모를 소규모 지인 네트워크 밖으로 확대 + +## Phase 3 — OS 레이어 진입 (성장 전략) + +- 읽기 전용 허브부터 (발송 권한 없음, 문자·이메일 등 안정적 API 채널 우선) +- 순서: 읽기 전용 → 초안 제안 → 제한적 자동응대(L2 그대로 확장) → 자체 앱으로 유도 +- 안드로이드 우선, iOS는 이 단계 반응을 본 뒤 자체 앱 전환 유도 전략으로 대응 + +## Phase 4 — L4 분신 협상 + B2B 확장 + +- 사용자 기반이 어느 정도 쌓여 네트워크 효과가 의미 있을 때 착수 +- 기업용 고객 응대 분신(B2B)은 이 시점 이후 별도 트랙으로 검토 + +## 명시적으로 지금 계획하지 않는 것 + +- Phase 1 게이트를 통과하기 전에 Phase 2 이후 기능을 설계/개발하지 않는다. +- OS 레이어와 자체 앱을 동시에 만들지 않는다 (`decision-log.md` Q7 근거). diff --git a/docs/tech-design.md b/docs/tech-design.md new file mode 100644 index 0000000..c73b4cb --- /dev/null +++ b/docs/tech-design.md @@ -0,0 +1,75 @@ +# 기술 설계서 — 분신 v1 + +`PRD.md` 범위(자체 앱, L0~L2, 읽씹 종결 + 단톡 따라잡기)를 구현하기 위한 아키텍처 개요. +상세 API 스펙이 아니라 경계와 원칙을 정의하는 문서다 — 실제 구현 시 세부 설계는 별도로 좁혀나간다. + +## 1. 전체 구조 + +``` +[클라이언트 앱 (Android 우선, iOS 병행 검토)] + ├─ 메시지 UI / 뱃지 렌더링 + ├─ 온디바이스 말투 모델 (경량, 로컬 추론) + ├─ 자율성 엔진 (L0~L2 규칙 + 에스컬레이션 판정) + └─ 로컬 이벤트 로그 (사후 알림 / 되돌리기용) + │ (암호화된 동기화만, 원문은 최소 전송) + ▼ +[서버] + ├─ 메시지 릴레이 / 대화방 저장 + ├─ 응답 초안 생성 (온디바이스로 부족한 경우의 폴백 LLM 호출) + └─ 화이트리스트·설정 동기화 (기기 간) +``` + +## 2. 온디바이스 vs 서버 경계 + +- **말투 학습(온보딩, 교정 학습)은 온디바이스 우선.** 원문 대화를 서버로 올리지 않고 + 기기 내에서 스타일 특징만 추출·저장한다. (`vision.md`의 신뢰 가설과 직결 — 여기서 타협하면 + Q4 사칭/프라이버시 우려가 그대로 리스크로 남는다) +- **응답 초안 생성은 온디바이스 우선 + 서버 폴백.** 기기 성능/배터리 제약으로 온디바이스 모델이 + 처리 못 하는 경우에만 서버 LLM 호출, 이 경우도 필요한 최소 컨텍스트만 전송. +- **자율성 엔진(L0~L2 판정, 에스컬레이션 규칙)은 클라이언트에 둔다.** 금전/약속/민감 감지가 + 서버 왕복 지연이나 서버 장애에 영향받지 않아야 안전선이 항상 지켜진다. +- **대화방 저장/릴레이는 서버.** 멀티 디바이스 동기화, 상대방에게 메시지를 전달하는 기본 기능. + +## 3. 자율성 엔진 (L0~L2) + +1. 수신 메시지 → 에스컬레이션 판정기 먼저 통과 (금전/약속 확정/민감 키워드+의도 분류) +2. 에스컬레이션 대상이면 무조건 사용자에게 알림만 하고 종료 (자동 처리 안 함) — **이 경로엔 예외 없음** +3. 아니면 자율성 레벨 확인: + - L0: 초안만 생성해 사용자에게 보여줌, 발송 없음 + - L1: 초안 생성 + 발송 승인 요청 알림 + - L2: 상대·주제가 화이트리스트에 있으면 즉시 발송, 아니면 L1과 동일하게 강등 +4. 발송된 모든 자동 응답은 로컬 이벤트 로그에 기록 (사후 알림 + 되돌리기 버튼 노출) + +에스컬레이션 판정기는 v1에서는 규칙 기반(키워드 + 간단한 의도 분류) + 온디바이스 모델의 결합으로 +시작하고, 오탐/누락 사례를 베타 로그로 계속 튜닝한다. 100% 정확도를 목표하지 않는다 — 애매하면 +항상 에스컬레이션 쪽으로 fail-safe. + +## 4. 투명성 구현 + +- **분신 뱃지**: 메시지 객체에 `sender_mode: human | twin` 필드, 클라이언트가 이를 렌더링에만 사용 + (서버가 신뢰의 원천 — 클라이언트 임의 조작 방지를 위해 서명 포함) +- **실시간 본인 확인**: "본인/분신" 질문은 별도 API 없이 자율성 엔진이 인식하는 고정 인텐트로 처리, + 분신은 항상 정직하게 "저는 분신입니다"로 응답 (프롬프트 레벨에서 이 사실을 숨기지 않도록 고정) +- **거부권**: 대화방 단위 플래그(`twin_disabled_by_peer`) — 상대방의 거부 요청이 감지되면 즉시 + 해당 대화방에서 L1/L2 자동 동작을 끄고 L0으로 강등 + +## 5. 데이터/프라이버시 원칙 + +- 원문 대화 내용은 기본적으로 기기 내 저장, 서버는 릴레이에 필요한 최소 기간만 보관 +- 말투 특징 벡터 등 학습 산출물은 암호화 저장, 사용자가 언제든 초기화 가능 +- 어떤 데이터가 어디로 가는지 설정 화면에서 실시간으로 확인 가능한 대시보드 제공 (베타 초기엔 + 최소한 "이 대화는 서버로 갔음/기기에만 있음" 표시 수준으로 시작) + +## 6. 플랫폼 전략 + +- **Android 우선.** 알림 접근 권한 기반 확장(v2 OS 레이어)을 염두에 둔 선택이기도 하고, v1 + 자체 앱 단계에서도 베타 규모라면 단일 플랫폼으로 좁혀 개발 속도를 확보하는 게 유리하다. +- iOS는 베타 반응 확인 후 병행 착수. (근거: `decision-log.md` Q7, 원본 회의자료 §oslayer 리스크 + "iOS는 안드로이드보다 훨씬 제한적") + +## 7. v1에서 의도적으로 안 만드는 것 + +- OS 레이어(알림 파싱 기반 타 앱 관통) — v2. 지금 만들면 카카오톡 등 UI 변경에 따라 계속 깨지는 + 파싱 로직을 유지보수해야 해서, 아직 검증 안 된 v1 핵심 가설과 리스크가 섞인다. +- 분신 간 프로토콜(L4) — 네트워크 효과가 필요해 사용자 기반이 있어야 의미 있음. +- 서버 측 전체 대화 분석/추천 — 온디바이스 우선 원칙과 상충. diff --git a/docs/vision.md b/docs/vision.md new file mode 100644 index 0000000..a311c1b --- /dev/null +++ b/docs/vision.md @@ -0,0 +1,41 @@ +# Vision Doc — 분신 (가칭) + +## 문제 + +메신저에서 사람들은 "읽었으면 답해야 한다"는 무언의 압박(읽씹 스트레스), 자는 동안/바쁠 때 +쌓인 메시지를 다 확인해야 하는 피로, 그리고 원치 않는 대화(영업, 번호 캐묻기)를 정중히 +받아내야 하는 감정 노동을 일상적으로 겪는다. 기존 AI 비서(챗GPT, 시리 등)는 **나와** 대화할 뿐, +**나를 대신해 남과** 대화해주지 않는다. + +## 타깃 사용자 (v1) + +일반 개인 사용자 — 특히 메신저 응답 압박을 자주 느끼는 20~30대. 회사/팀 사용 사례(B2B)는 +v1 이후 확장 대상으로 명시적으로 제외한다. (근거: `decision-log.md` Q2) + +## 가치 제안 (한 문장) + +> 분신은 내가 답할 수 없는 순간에도, 나 대신 나답게 응답해 읽씹 압박과 응답 피로를 없애주는 +> 메신저다. + +## 이번 v1에서 하지 않는 것 (Non-goals) + +- 분신 간 협상(L4, 약속 자동 조율) — 네트워크 효과가 필요한 단계라 사용자 기반이 있어야 의미가 있음 +- 자리비움 전면 자동응대(L3) — 신뢰가 쌓이기 전에는 리스크가 큼 +- 카카오톡/인스타그램 등 타 채널 위 OS 레이어 — v2 성장 전략으로 미룸 +- 기업용(B2B) 고객 응대 분신 + +## 성공 지표 (v1 클로즈드 베타 기준) + +| 지표 | 목표 | 측정 방법 | +|---|---|---| +| 분신 응답 자연스러움 | 베타 참가자의 70% 이상이 "내 말투 같다"고 평가 | 온보딩 후 설문 | +| 신뢰 유지 | 상대방의 분신 거부율 10% 미만 | 거부권 사용 로그 | +| 핵심 시나리오 도달률 | 베타 참가자 50% 이상이 "읽씹 종결" 시나리오를 1주 내 실사용 | 이벤트 로그 | +| 리텐션 | 2주차 재사용률 40% 이상 | DAU/재방문 로그 | +| 안전선 위반 0건 | 금전/약속 확정을 분신이 자동 처리한 사례 0건 | 에스컬레이션 로그 감사 | + +## 핵심 축 요약 + +- **정체성 한 줄:** 챗GPT가 나와 대화하는 AI라면, 분신은 나를 대신해 남과 대화하는 나. +- **원칙:** 통제권은 항상 사용자에게 — 켜는 만큼만 일한다. 금전·약속 확정·민감 내용은 + 어떤 단계에서도 예외 없이 사람에게 에스컬레이션한다.