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

@@ -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, 프로토타입, 유저 인터뷰)입니다.

docs/PLANNING.md

@@ -83,31 +83,35 @@
 두 트랙은 경쟁 관계가 아니라 순서 문제다.
 
 - **OS 레이어(알림 관통형)**: 채택 장벽이 낮다(앱 설치+권한 허용만). 대신 발송 자동화는 각 앱의
-  API/자동입력 제약을 받아 범위가 좁다. 안드로이드 우선, 문자/이메일처럼 안정적 API가 있는 채널부터.
+  API/자동입력 제약을 받아 범위가 좁고, 검증 안 된 핵심 가설(분신의 자연스러움·신뢰)과 제3자
-- **자체 메신저**: 완전한 기능(L4 분신 협상 등)이 가능한 최종 목적지. 대신 "메신저를 옮겨야 한다"는
+  플랫폼 제약(카카오톡 등의 자동화 정책)이 동시에 섞여 실패 원인을 구분하기 어렵다.
-  채택 장벽이 크다.
+- **자체 메신저(클로즈드 베타)**: 분신 로직·UX(뱃지, 거부권, 에스컬레이션)를 온전히 구현해
+  통제된 소규모 그룹으로 핵심 가설만 순수하게 검증할 수 있다. "메신저를 옮겨야 한다"는 채택
+  장벽은 있지만, 베타 단계에서는 어차피 소규모 초대 기반이라 큰 문제가 아니다.
 
-**권장 순서:** OS 레이어의 "읽기 전용 허브"(로드맵 1단계, 발송 권한 없음)로 가장 낮은 신뢰 비용부터
+**최종 결정 (`decision-log.md` Q7 참고):** 자체 앱 클로즈드 베타를 먼저 만들어 핵심 가설을
-검증 → 반응이 확인되면 초안 제안(2단계) → 자체 메신저는 그 다음 자연스러운 업그레이드 경로로 둔다.
+검증하고, 검증되면 그 로직을 재사용해 OS 레이어(읽기 전용 허브, 문자·이메일 우선)로 확장해
-두 트랙을 동시에 만들지 않는다.
+채택 장벽을 낮춘다. 두 트랙을 동시에 만들지 않는다. (이 판단의 상세 근거는 `decision-log.md`
+"Q7 상세 근거" 참고 — 이 섹션은 그 판단을 반영해 갱신되었다.)
 
-## 7. 표준 산출물 세트 (다음에 작성할 문서)
+## 7. 표준 산출물 세트
 
-이 문서(PLANNING.md)는 "어떻게 진행할지"에 대한 가이드다. §2의 Q1~Q7이 확정되면 아래 문서를
+§2의 Q1~Q7에 잠정 결정을 내리고 아래 문서를 작성했다. 결정이 뒤집히면 이 문서들도 함께 갱신한다.
-순서대로 만든다. 지금 시점에 전부 미리 만들지 않는다 — 앞 단계가 안 끝나면 다음 문서는 다시 쓰게 된다.
 
-1. **Vision Doc (1페이지)** — 문제, 타깃, 가치제안 한 문장, 성공 지표
+1. [`vision.md`](./vision.md) — 문제, 타깃, 가치제안 한 문장, 성공 지표
-2. **PRD** — MVP 시나리오 기준 기능 명세, 유저 플로우, 엣지 케이스, 화면 정의
+2. [`PRD.md`](./PRD.md) — MVP 시나리오 기준 기능 명세, 유저 플로우, 엣지 케이스
-3. **기술 설계서** — 온디바이스/서버 경계, 데이터 흐름, 에스컬레이션 로직
+3. [`tech-design.md`](./tech-design.md) — 온디바이스/서버 경계, 데이터 흐름, 에스컬레이션 로직
-4. **리스크 로그** — 회의 자료 §2-6, §oslayer §4의 리스크를 실제 완화 상태와 함께 추적
+4. [`risk-log.md`](./risk-log.md) — 회의 자료 §2-6, §oslayer §4의 리스크를 완화 상태와 함께 추적
-5. **로드맵 & 마일스톤** — §5의 L0~L4 단계, §6의 OS 레이어→자체 앱 전환 시점 반영
+5. [`roadmap.md`](./roadmap.md) — L0~L4 단계, OS 레이어→자체 앱 전환 시점 반영
-6. **결정 로그** — 회의에서 확정된 것과 보류된 것을 계속 누적 기록 (이 프로젝트 자체 아이디어이기도 함)
+6. [`decision-log.md`](./decision-log.md) — Q1~Q7 결정과 근거, 계속 누적 기록
 
 ## 8. 다음 액션 체크리스트
 
-- [ ] §2의 Q1~Q7을 회의에서 실제로 확정 (또는 보류 사유 기록)
+- [x] §2의 Q1~Q7 잠정 결정 — `decision-log.md` (실제 회의에서 재확인/뒤집기 필요)
-- [ ] Vision Doc 1페이지 작성
+- [x] Vision Doc 작성 — `vision.md`
-- [ ] MVP 시나리오 1~2개로 확정 (§3 권장안 검토)
+- [x] MVP 시나리오 확정 (읽씹 종결 + 단톡 따라잡기) — `PRD.md`
-- [ ] §4의 기술 PoC 중 1번(말투 학습)과 2번(알림 접근 안정성) 먼저 진행
+- [x] PRD, 기술 설계서, 리스크 로그, 로드맵 작성
+- [ ] §4의 기술 PoC 중 1번(말투 학습)과 3번(사칭/신뢰 수용성) 먼저 진행 — 아직 코드/실사용 검증 없음
 - [ ] 클릭 가능한 프로토타입(Figma 등) 제작, 뱃지·거부권 UX 포함
 - [ ] 5~10명 대상 유저 인터뷰로 "AI 대리 응답 수용성"(Q3) 검증
+- [ ] 실제 회의에서 이 문서 세트 전체를 리뷰하고 Q1~Q7을 정식 확정

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 화이트리스트 자동발송 후 되돌리기 사용률 — 낮을수록 신뢰 신호

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은 가칭)
+- 베타 참가자 모집 규모와 방식 (§로드맵 참고)

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을 최우선으로 진행한다.

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 근거).

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) — 네트워크 효과가 필요해 사용자 기반이 있어야 의미 있음.
+- 서버 측 전체 대화 분석/추천 — 온디바이스 우선 원칙과 상충.

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라면, 분신은 나를 대신해 남과 대화하는 나.
+- **원칙:** 통제권은 항상 사용자에게 — 켜는 만큼만 일한다. 금전·약속 확정·민감 내용은
+  어떤 단계에서도 예외 없이 사람에게 에스컬레이션한다.