3.6 KiB
3.6 KiB
결정 로그
회의 자료(idea-meeting-2026-06-29.html)의 논점 Q1~Q7에 대한 결정을 추적한다.
상태 범례
- 제안: 문서 작성용 잠정안 (회의 전)
- 확정: Master가 Phase 1 C(베타 직전)에서 승인·고정한 값. 이후 번복 시 이 로그와 근거로 만든 Vision/PRD/기술설계를 함께 갱신한다.
| # | 질문 | 결정 | 근거 | 상태 |
|---|---|---|---|---|
| Q1 | AI 분신으로 확정? | 예 | "기록/관계 피로/프라이버시" 축은 기능 묶음이라 한 문장 정체성이 약함. 분신은 "나를 대신해 남과 대화하는 나"로 명확히 정의됨 | 확정 |
| Q2 | 타깃: 대중 vs 회사? | 대중 우선 | 회사용은 워크스페이스 도입 결정권자를 설득해야 해 진입 장벽이 큼. 대중은 개인 대 개인으로 바로 가치 체감 가능(읽씹 종결). B2B는 v3 확장 항목으로 남김 | 확정 |
| Q3 | 자율성 몇 단계까지 출시? | L0~L2만 | L3(자리비움 응대)·L4(분신 협상)는 신뢰가 쌓이기 전엔 리스크 대비 이득이 낮음. "켜는 만큼만 만든다" 원칙 적용. 기본 자율성 레벨(L1 vs L2 시작점)과 화이트리스트 기본 주제는 사람 PoC/실사용 후 확정 | 확정 |
| Q4 | 사칭 우려 대응 충분한가? | 1차 설계로 베타 진입, PoC #3로 검증 | 분신 뱃지·거부권·확정 불가·본인확인 고정 문구는 설계상 필수. 상대 신뢰 여부는 D(사람 PoC #3)에서 측정 | 확정 |
| Q5 | MVP 데모 시나리오 1개는? | 읽씹 종결 + 단톡 따라잡기 (묶음) | 둘 다 L0~L2, 같은 파이프라인(수신 요약 → 맥락 응답 초안) 공유. 발송 자동화 없이도(단톡 따라잡기) 가치 증명 가능 | 확정 |
| Q6 | 서비스 이름 | "분신" (가칭) | 한국어로 직관적. 최종 브랜딩/상표는 MVP·베타 반응 이후 | 확정 (가칭 유지) |
| Q7 | 자체 앱 vs OS 레이어 시작점 | 자체 앱(클로즈드 베타) 먼저 → OS 레이어는 v2 | 아래 "Q7 상세 근거" | 확정 |
확정일: 2026-07-30 (Phase 1 C — Master 승인 하에 제안 → 확정).
Q7 상세 근거 — 왜 자체 앱을 먼저 만드는가
PLANNING.md §6에서는 채택 장벽이 낮다는 이유로 OS 레이어(읽기 전용 허브)를 먼저 검증하는 안을
제시했다. 하지만 실제 실행 순서를 정할 때는 아래 이유로 자체 앱 클로즈드 베타를 먼저 둔다.
- 카카오톡·인스타그램은 자동화/크롤링을 정책상 제한하는 경우가 많아, OS 레이어의 "발송" 쪽은 처음부터 제3자 API 제약을 받는다. 아직 검증되지 않은 핵심 가설을 제3자 플랫폼 제약과 동시에 검증하면 실패 원인을 구분할 수 없다.
- 자체 앱(초대 기반 클로즈드 베타)에서는 분신 로직·UX(뱃지, 거부권, 에스컬레이션)를 온전히 구현해 통제된 소규모 그룹으로 "이게 정말 쓸만한가"만 순수하게 검증할 수 있다.
- 이 단계에서 만든 요약/응답 초안 생성 로직은 이후 OS 레이어(문자·이메일 우선)로 그대로 재사용 가능.
순서: ① 자체 앱 클로즈드 베타로 핵심 가설 검증 → ② 검증되면 OS 레이어 읽기 전용 허브 → ③ 자체 앱은 L3·L4 등 완전한 기능의 최종 목적지로 유지.
아직 열려 있는 하위 질문 (PoC/실사용 의존 — D 이후)
- 분신 응답 임계점·화이트리스트 기본 주제 목록 (실사용 데이터)
- 자율성 기본 시작 레벨 L1 vs L2 (Q3 인터뷰)
- 상표/네이밍 최종안 (Q6은 가칭 확정)
- 베타 참가자 모집 규모와 방식