8.4 KiB

Raw Blame History

프로젝트 기획 접근 방법 — AI 분신 메신저

원본 회의 자료: 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를 단일 기준으로 따른다.

#	질문	잠정 결정	상태
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) 우선순위

기능을 만들기 전에, 이 아이디어를 무너뜨릴 수 있는 가정부터 코드로 확인한다.

온디바이스 말투 학습이 실제로 "나답게" 느껴지는가 — 소규모 대화 샘플로 톤 재현 정도를 사람이 직접 평가
안드로이드 알림 접근 권한(Notification Access)으로 읽기가 안정적인가 — 카톡 알림 파싱이 OS/앱 버전에 따라 얼마나 자주 깨지는지 확인 (OS 레이어 트랙을 갈 경우 필수)
자동응대가 "이상하다"고 느껴지는 임계점은 어디인가 — 실제 대화 로그로 사용자 테스트, 뱃지·거부권 같은 투명성 장치가 실제로 신뢰를 회복시키는지 확인
분신 간 협상(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에 잠정 결정을 내리고 아래 문서를 작성했다. 결정이 뒤집히면 이 문서들도 함께 갱신한다.

vision.md — 문제, 타깃, 가치제안 한 문장, 성공 지표
PRD.md — MVP 시나리오 기준 기능 명세, 유저 플로우, 엣지 케이스
tech-design.md — 온디바이스/서버 경계, 데이터 흐름, 에스컬레이션 로직
risk-log.md — 회의 자료 §2-6, §oslayer §4의 리스크를 완화 상태와 함께 추적
roadmap.md — L0~L4 단계, 자체 앱→OS 레이어 확장 시점 반영
decision-log.md — Q1~Q7 결정과 근거, 계속 누적 기록
poc-plan.md — PoC #1(말투 학습)·#3(사칭/신뢰 수용성) 실행 계획과 Go/No-Go 기준

8. 다음 액션 체크리스트

§2의 Q1~Q7 잠정 결정 — decision-log.md (실제 회의에서 재확인/뒤집기 필요)
Vision Doc 작성 — vision.md
MVP 시나리오 확정 (읽씹 종결 + 단톡 따라잡기) — PRD.md
PRD, 기술 설계서, 리스크 로그, 로드맵 작성
§4의 기술 PoC 중 1번(말투 학습)과 3번(사칭/신뢰 수용성) 실행 계획서 작성 — poc-plan.md (계획만 작성됨, 실제 참가자 모집·데이터 수집·인터뷰는 아직 실행 전 — poc-plan.md §4 참고)
PoC #1·#3 실제 실행 (참가자 모집, 대화 샘플 수집, 역할극 인터뷰) 및 Go/No-Go 판정
클릭 가능한 프로토타입(Figma 등) 제작, 뱃지·거부권 UX 포함
5~10명 대상 유저 인터뷰로 "AI 대리 응답 수용성"(Q3) 검증 (PoC #3와 통합 진행 가능)
실제 회의에서 이 문서 세트 전체를 리뷰하고 Q1~Q7을 정식 확정

8.4 KiB Raw Blame History