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

기능 명세를 쓰기 전에 아래 표를 채운다. 답이 안 나온 항목은 "보류 사유"를 적어두고 다음 회의 안건으로 남긴다.

#	질문	결정	비고
Q1	AI 분신으로 확정?	☐	다른 축(기록/관계) 대비 최종 선택 근거
Q2	타깃: 대중 vs 회사?	☐	첫 사용자층에 따라 기능 우선순위가 바뀜
Q3	자율성 몇 단계까지 출시?	☐	L0~L2만 먼저 여는 것을 권장 (§5)
Q4	사칭 우려 대응 충분한가?	☐	분신 뱃지·거부권 등 투명성 장치 재확인
Q5	MVP 데모 시나리오 1개는?	☐	읽씹 종결 / 약속 조율 / 대화 방어 중 하나
Q6	서비스 이름	☐	Echo / Twin / 분신 / Aka / 둘이서 / Mirror
Q7	자체 앱 vs OS 레이어 시작점	☐	§6 참고 — 신뢰 비용 낮은 쪽부터

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/자동입력 제약을 받아 범위가 좁다. 안드로이드 우선, 문자/이메일처럼 안정적 API가 있는 채널부터.
자체 메신저: 완전한 기능(L4 분신 협상 등)이 가능한 최종 목적지. 대신 "메신저를 옮겨야 한다"는 채택 장벽이 크다.

권장 순서: OS 레이어의 "읽기 전용 허브"(로드맵 1단계, 발송 권한 없음)로 가장 낮은 신뢰 비용부터 검증 → 반응이 확인되면 초안 제안(2단계) → 자체 메신저는 그 다음 자연스러운 업그레이드 경로로 둔다. 두 트랙을 동시에 만들지 않는다.

7. 표준 산출물 세트 (다음에 작성할 문서)

이 문서(PLANNING.md)는 "어떻게 진행할지"에 대한 가이드다. §2의 Q1~Q7이 확정되면 아래 문서를 순서대로 만든다. 지금 시점에 전부 미리 만들지 않는다 — 앞 단계가 안 끝나면 다음 문서는 다시 쓰게 된다.

Vision Doc (1페이지) — 문제, 타깃, 가치제안 한 문장, 성공 지표
PRD — MVP 시나리오 기준 기능 명세, 유저 플로우, 엣지 케이스, 화면 정의
기술 설계서 — 온디바이스/서버 경계, 데이터 흐름, 에스컬레이션 로직
리스크 로그 — 회의 자료 §2-6, §oslayer §4의 리스크를 실제 완화 상태와 함께 추적
로드맵 & 마일스톤 — §5의 L0~L4 단계, §6의 OS 레이어→자체 앱 전환 시점 반영
결정 로그 — 회의에서 확정된 것과 보류된 것을 계속 누적 기록 (이 프로젝트 자체 아이디어이기도 함)

8. 다음 액션 체크리스트

§2의 Q1~Q7을 회의에서 실제로 확정 (또는 보류 사유 기록)
Vision Doc 1페이지 작성
MVP 시나리오 1~2개로 확정 (§3 권장안 검토)
§4의 기술 PoC 중 1번(말투 학습)과 2번(알림 접근 안정성) 먼저 진행
클릭 가능한 프로토타입(Figma 등) 제작, 뱃지·거부권 UX 포함
5~10명 대상 유저 인터뷰로 "AI 대리 응답 수용성"(Q3) 검증

7.4 KiB Raw Blame History