120 lines
8.0 KiB
Markdown
120 lines
8.0 KiB
Markdown
# 프로젝트 기획 접근 방법 — AI 분신 메신저
|
|
|
|
원본 회의 자료: [`idea-meeting-2026-06-29.html`](./idea-meeting-2026-06-29.html)
|
|
|
|
## 0. 지금 어디까지 왔나
|
|
|
|
회의 자료는 "발산 → 컨셉 탐색 → AI 분신으로 좁혀 설계 심화"까지 진행됐다.
|
|
즉 **아이디어 단계는 끝났고, 다음은 아이디어를 실행 가능한 스펙으로 좁히는 단계**다.
|
|
이 단계에서 실패하는 가장 흔한 패턴은 두 가지다.
|
|
|
|
- 자율성 5단계(L0~L4) + OS 레이어 확장 + 자체 메신저를 **동시에** 설계하려는 것 (범위 과다)
|
|
- 회의 자료의 "논점 Q1~Q7"을 확정하지 않은 채 기능 명세부터 쓰는 것 (순서 역전)
|
|
|
|
그래서 아래 프로세스는 "결정 → 좁히기 → 검증 → 명세" 순서를 강제하는 데 초점을 둔다.
|
|
|
|
## 1. 기획 프로세스 (5단계)
|
|
|
|
```
|
|
1) 컨셉 확정 회의 Q1~Q7에 실제로 답한다 (아래 §2)
|
|
2) 한 문장 정의 "누구를 위한, 무엇을, 왜" — Vision Doc 1페이지
|
|
3) MVP 시나리오 선정 4개 킬러 시나리오 중 "딱 하나"만 고른다 (§3)
|
|
4) PRD 작성 선정한 시나리오 기준으로만 기능/플로우/화면 정의
|
|
5) 기술 PoC 제일 위험한 가정부터 코드 없이/최소코드로 검증 (§4)
|
|
```
|
|
|
|
1→5는 순서대로, 단계를 건너뛰지 않는다. 특히 4(PRD)를 3(MVP 시나리오 선정) 전에 쓰면
|
|
자율성 5단계 전체를 다 설계하려는 함정에 다시 빠진다.
|
|
|
|
## 2. 먼저 확정해야 할 결정 (회의 Q1~Q7)
|
|
|
|
기능 명세를 쓰기 전에 아래 표를 채운다. 답이 안 나온 항목은 "보류 사유"를 적어두고 다음 회의 안건으로 남긴다.
|
|
현재 작업용 답은 [`decision-log.md`](./decision-log.md)에 있으며, 상태는 모두 **제안(잠정)** 이다.
|
|
회의에서 정식 확정되기 전까지는 decision-log를 단일 기준으로 따른다.
|
|
|
|
| # | 질문 | 잠정 결정 | 상태 |
|
|
|---|------|------|------|
|
|
| Q1 | AI 분신으로 확정? | 예 | 제안 — 근거는 `decision-log.md` |
|
|
| Q2 | 타깃: 대중 vs 회사? | 대중 우선 (B2B는 이후) | 제안 |
|
|
| Q3 | 자율성 몇 단계까지 출시? | L0~L2만 | 제안 |
|
|
| Q4 | 사칭 우려 대응 충분한가? | 1차 설계는 충분, 실사용 검증 필요 | 제안 |
|
|
| Q5 | MVP 데모 시나리오 1개는? | 읽씹 종결 + 단톡 따라잡기 (묶음) | 제안 |
|
|
| Q6 | 서비스 이름 | "분신" (가칭) | 제안 (가칭) |
|
|
| Q7 | 자체 앱 vs OS 레이어 시작점 | 자체 앱 클로즈드 베타 먼저 → OS 레이어는 이후 | 제안 |
|
|
|
|
## 3. MVP 시나리오 좁히기
|
|
|
|
회의 자료의 "킬러 시나리오" 4개를 검증 난이도·데모 임팩트 기준으로 비교한다.
|
|
|
|
| 시나리오 | 필요 자율성 | 데모 임팩트 | 기술 난이도 | 비고 |
|
|
|---|---|---|---|---|
|
|
| 🌙 읽씹 종결 | L0~L2 | 높음 (전 국민 공감) | 낮음 (컨텍스트 응답 1건) | **1순위 추천** — 가장 좁고 명확 |
|
|
| 📚 단톡 따라잡기 | L0 | 중간 | 낮음 (요약만) | 발송 권한 불필요, 안전 |
|
|
| 🚫 비호감 대화 방어 | L2 | 중간 | 중간 (의도 판별 필요) | 오탐 리스크 존재 |
|
|
| 📅 약속 자동 조율(L4) | L4 | 높음 | 높음 (분신 간 프로토콜, 양쪽 앱 필요) | 초기엔 데모용으로만, 정식 범위 아님 |
|
|
|
|
**권장:** "읽씹 종결"과 "단톡 따라잡기"는 둘 다 L0~L2로 커버되고 같은 파이프라인(수신 메시지 요약 →
|
|
맥락 기반 응답 초안)을 공유하므로, 이 둘을 묶어 MVP로 잡고 L3(자리비움 응대)·L4(분신 협상)는
|
|
로드맵의 다음 단계로 명시적으로 미룬다.
|
|
|
|
## 4. 기술 검증(PoC) 우선순위
|
|
|
|
기능을 만들기 전에, 이 아이디어를 무너뜨릴 수 있는 가정부터 코드로 확인한다.
|
|
|
|
1. **온디바이스 말투 학습이 실제로 "나답게" 느껴지는가** — 소규모 대화 샘플로 톤 재현 정도를 사람이 직접 평가
|
|
2. **안드로이드 알림 접근 권한(Notification Access)으로 읽기가 안정적인가** — 카톡 알림 파싱이
|
|
OS/앱 버전에 따라 얼마나 자주 깨지는지 확인 (OS 레이어 트랙을 갈 경우 필수)
|
|
3. **자동응대가 "이상하다"고 느껴지는 임계점은 어디인가** — 실제 대화 로그로 사용자 테스트, 뱃지·거부권
|
|
같은 투명성 장치가 실제로 신뢰를 회복시키는지 확인
|
|
4. **분신 간 협상(L4) 프로토콜의 최소 형태** — MVP 범위는 아니지만, 자체 메신저 트랙의 차별화 지점이므로
|
|
설계 문서 수준에서만 먼저 검증 (턴 수 제한, 타임아웃, 결렬 시 에스컬레이션 규칙)
|
|
|
|
## 5. 범위 관리 원칙 — "켜는 만큼만 만든다"
|
|
|
|
회의 자료의 자율성 사다리(L0~L4)는 제품 로드맵과 그대로 대응시킨다.
|
|
|
|
- **MVP**: L0(비서 모드) + L1(제안 모드) + L2(부분 위임, 좁은 화이트리스트 주제만)
|
|
- **v2**: L3(자리비움 응대) — 사용자 신뢰가 쌓인 뒤
|
|
- **v3+**: L4(분신 협상) — 네트워크 효과가 필요한 단계이므로 사용자 기반이 어느 정도 생긴 뒤
|
|
|
|
절대 안전선(금전·약속 확정·민감 내용은 항상 사람에게 에스컬레이션)은 L0부터 L4까지 전 단계에서
|
|
예외 없이 지킨다 — 이건 범위를 줄여도 타협하지 않는 항목이다.
|
|
|
|
## 6. 자체 앱 vs OS 레이어 — 어디서 시작할까 (Q7)
|
|
|
|
두 트랙은 경쟁 관계가 아니라 순서 문제다.
|
|
|
|
- **OS 레이어(알림 관통형)**: 채택 장벽이 낮다(앱 설치+권한 허용만). 대신 발송 자동화는 각 앱의
|
|
API/자동입력 제약을 받아 범위가 좁고, 검증 안 된 핵심 가설(분신의 자연스러움·신뢰)과 제3자
|
|
플랫폼 제약(카카오톡 등의 자동화 정책)이 동시에 섞여 실패 원인을 구분하기 어렵다.
|
|
- **자체 메신저(클로즈드 베타)**: 분신 로직·UX(뱃지, 거부권, 에스컬레이션)를 온전히 구현해
|
|
통제된 소규모 그룹으로 핵심 가설만 순수하게 검증할 수 있다. "메신저를 옮겨야 한다"는 채택
|
|
장벽은 있지만, 베타 단계에서는 어차피 소규모 초대 기반이라 큰 문제가 아니다.
|
|
|
|
**최종 결정 (`decision-log.md` Q7 참고):** 자체 앱 클로즈드 베타를 먼저 만들어 핵심 가설을
|
|
검증하고, 검증되면 그 로직을 재사용해 OS 레이어(읽기 전용 허브, 문자·이메일 우선)로 확장해
|
|
채택 장벽을 낮춘다. 두 트랙을 동시에 만들지 않는다. (이 판단의 상세 근거는 `decision-log.md`
|
|
"Q7 상세 근거" 참고 — 이 섹션은 그 판단을 반영해 갱신되었다.)
|
|
|
|
## 7. 표준 산출물 세트
|
|
|
|
§2의 Q1~Q7에 잠정 결정을 내리고 아래 문서를 작성했다. 결정이 뒤집히면 이 문서들도 함께 갱신한다.
|
|
|
|
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. 다음 액션 체크리스트
|
|
|
|
- [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을 정식 확정
|