diff --git a/README.md b/README.md
new file mode 100644
index 0000000..993c223
--- /dev/null
+++ b/README.md
@@ -0,0 +1,9 @@
+# hikikomori
+
+카카오톡 대안 메신저 아이디어 — "나를 대신해 남과 대화하는 AI 분신"이 있는 메신저 프로젝트.
+
+- 원본 회의 자료: [`docs/idea-meeting-2026-06-29.html`](./docs/idea-meeting-2026-06-29.html)
+- 기획 진행 방법: [`docs/PLANNING.md`](./docs/PLANNING.md)
+
+현재 단계: 아이디어 발산 및 컨셉 심화 완료. 다음 단계는 `docs/PLANNING.md`의 프로세스를 따라
+컨셉 확정 → MVP 시나리오 선정 → PRD 작성 순으로 진행합니다.
diff --git a/docs/PLANNING.md b/docs/PLANNING.md
new file mode 100644
index 0000000..4ae8301
--- /dev/null
+++ b/docs/PLANNING.md
@@ -0,0 +1,113 @@
+# 프로젝트 기획 접근 방법 — 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)
+
+기능 명세를 쓰기 전에 아래 표를 채운다. 답이 안 나온 항목은 "보류 사유"를 적어두고 다음 회의 안건으로 남긴다.
+
+| # | 질문 | 결정 | 비고 |
+|---|------|------|------|
+| 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) 우선순위
+
+기능을 만들기 전에, 이 아이디어를 무너뜨릴 수 있는 가정부터 코드로 확인한다.
+
+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/자동입력 제약을 받아 범위가 좁다. 안드로이드 우선, 문자/이메일처럼 안정적 API가 있는 채널부터.
+- **자체 메신저**: 완전한 기능(L4 분신 협상 등)이 가능한 최종 목적지. 대신 "메신저를 옮겨야 한다"는
+ 채택 장벽이 크다.
+
+**권장 순서:** OS 레이어의 "읽기 전용 허브"(로드맵 1단계, 발송 권한 없음)로 가장 낮은 신뢰 비용부터
+검증 → 반응이 확인되면 초안 제안(2단계) → 자체 메신저는 그 다음 자연스러운 업그레이드 경로로 둔다.
+두 트랙을 동시에 만들지 않는다.
+
+## 7. 표준 산출물 세트 (다음에 작성할 문서)
+
+이 문서(PLANNING.md)는 "어떻게 진행할지"에 대한 가이드다. §2의 Q1~Q7이 확정되면 아래 문서를
+순서대로 만든다. 지금 시점에 전부 미리 만들지 않는다 — 앞 단계가 안 끝나면 다음 문서는 다시 쓰게 된다.
+
+1. **Vision Doc (1페이지)** — 문제, 타깃, 가치제안 한 문장, 성공 지표
+2. **PRD** — MVP 시나리오 기준 기능 명세, 유저 플로우, 엣지 케이스, 화면 정의
+3. **기술 설계서** — 온디바이스/서버 경계, 데이터 흐름, 에스컬레이션 로직
+4. **리스크 로그** — 회의 자료 §2-6, §oslayer §4의 리스크를 실제 완화 상태와 함께 추적
+5. **로드맵 & 마일스톤** — §5의 L0~L4 단계, §6의 OS 레이어→자체 앱 전환 시점 반영
+6. **결정 로그** — 회의에서 확정된 것과 보류된 것을 계속 누적 기록 (이 프로젝트 자체 아이디어이기도 함)
+
+## 8. 다음 액션 체크리스트
+
+- [ ] §2의 Q1~Q7을 회의에서 실제로 확정 (또는 보류 사유 기록)
+- [ ] Vision Doc 1페이지 작성
+- [ ] MVP 시나리오 1~2개로 확정 (§3 권장안 검토)
+- [ ] §4의 기술 PoC 중 1번(말투 학습)과 2번(알림 접근 안정성) 먼저 진행
+- [ ] 클릭 가능한 프로토타입(Figma 등) 제작, 뱃지·거부권 UX 포함
+- [ ] 5~10명 대상 유저 인터뷰로 "AI 대리 응답 수용성"(Q3) 검증
diff --git a/docs/idea-meeting-2026-06-29.html b/docs/idea-meeting-2026-06-29.html
new file mode 100644
index 0000000..79b013c
--- /dev/null
+++ b/docs/idea-meeting-2026-06-29.html
@@ -0,0 +1,579 @@
+
+
+
+
+
+msn 메신저 아이디어 · 회의 자료
+
+
+
+
+
+
+
+
msn. 메신저 회의 자료
+
+
+
+
+
+
+
+ Idea Meeting · 2026.06.29
+
카카오톡 대안 메신저 기획
+
브레인스토밍한 전체 아이디어와, 그중 가장 특색 있는 AI 분신 메신저 설계를 한 곳에 모았습니다. 회의 진행용 자료입니다.
+
🎯 최종 목표 — 대중·회사까지 아우르는 대표 메신저 | 핵심 축 — 메시지가 곧 행동이 되는 / 나를 대신하는 AI
+
+
+
1. 넓게 발산5개 카테고리로 아이디어 브레인스토밍
+
→
+
2. 특색 탐색"한 문장으로 정의되는" 컨셉 4종 비교
+
→
+
3. 선택 & 고도화AI 분신 메신저로 좁혀 설계 심화
+
+
+
+
+
+
+
+
1
아이디어 보드
+
카톡에 없거나 카톡이 못 하는 것들. 발산 단계에서 모은 전체 후보입니다.
+
+
+
+
A · 대화가 기록이 된다
+
핵심 차별 축
+
+
메시지 → 할일/결정/일정 승격말풍선을 꾹 누르면 업무 데이터로 변환
+
결정 로그 자동 누적"그때 뭐로 정했지?"가 방마다 타임라인으로
+
번복 추적결정이 바뀌면 "이전: A" 히스토리가 따라붙음
+
약속 자동 캘린더화"금요일 3시 ㄱㄱ"에서 일정 후보 추출
+
+
+
+
B · 읽씹·눈치 스트레스
+
관계 피로 줄이기
+
+
읽음 표시를 응답으로"1" 대신 확인 / 할게요 / 나중에 버튼
+
나만의 답장 마감 알림"이따 답장" 누르면 본인에게만 리마인드
+
나중에 모아보기안 급한 방은 정해진 시간에 묶어 알림
+
상태 자동화회의 중·이동 중을 캘린더·위치로 자동
+
+
+
+
C · 프라이버시·관계
+
부담 없는 연결
+
+
전화번호 없는 메신저초대코드·링크로만 연결, 번호 노출 0
+
관계별 분리 ID회사용 나 / 친구용 나를 한 앱에서 분리
+
종료 시한 대화방프로젝트 끝나면 자동 보관·삭제
+
사라지는 민감 메시지비번·주소 등 읽고 나면 소멸
+
+
+
+
D · AI 활용
+
똑똑한 비서
+
+
안 본 동안 요약"자리 비운 사이 뭐 정해짐?" 3줄
+
번역 없는 대화한국어로 치면 상대는 영어로 수신
+
톤 코치공격적인 메시지 보내기 전 한 번 확인
+
자료 찾아주기"지난주 그 PDF 어딨지?" 자연어 검색
+
+
+
+
E · 카톡이 못 박는 한 방
+
기능 내장
+
+
자료가 안 사라짐파일·링크·사진을 방별 자료함에 자동 정리
+
투표·정산 기본 내장장소·시간 투표, n빵 정산을 앱 안에서
+
가벼운 스레드한 방에서 주제 섞여 난장판 되는 것 방지
+
우리만의 검색특정 친구와 나눈 것만 따로 검색·앨범화
+
+
+
+
+
+
★ "오 이건 카톡에 없네" 가 터지는 한 방 후보
+
회사든 대중이든 모두가 공감하는 페인을 정확히 때리는 셋.
+
+
01
번복 추적 결정 로그
회의 뒤집기 짜증을 정확히 때림
+
02
읽씹을 응답 버튼으로
전 국민이 겪는 눈치 스트레스 해소
+
03
나중에 모아보기 알림
알림 폭격 피로를 근본적으로 해결
+
+
+
+
💡 회의 결론(현재): 위 아이디어들은 "기능 묶음"이라 정체성이 약하다는 판단 → 한 문장으로 정의되는 특색이 필요. 그래서 "나 대신 말하는 AI 분신이 있는 메신저"로 좁혀 아래에서 설계를 고도화함.
+
+
+
+
+
+
+
2
AI 분신 메신저 · 설계 고도화
+
정체성 한 줄 — 챗GPT가 나와 대화하는 AI라면, 분신은 나를 대신해 남과 대화하는 나다.
+
+
+
▶
연결 구조 ① — 메시지는 이렇게 흐른다
화살표 방향으로 흐름이 움직입니다
+
+
+
+ 들어오는 흐름 (상대 → 분신 → 나)
+ 나가는 흐름 (나 → 분신 → 상대)
+
+
분신이 1차로 받아 정리하고, 민감·중요한 건만 나에게 올린다. 가벼운 건 ④에서 분신이 바로 응답.
+
+
+
+
▶
연결 구조 ② — 분신끼리 약속을 조율한다 (L4)
두 분신이 직접 협상
+
+
+
두 분신이 협상한 뒤 양쪽 본인에게 후보 시간만 제안 → 최종 확정은 사람이. (둘 다 앱이 있어야 작동 = 초대 동기)
+
+
+
+
1
분신 자율성 5단계
통제권은 항상 사용자에게 — 켜는 만큼만 일한다
+
+
L0
비서 모드
나에게만 요약·할 일 정리·초안 제안. 발송은 안 함
상대 모름
+
L1
제안 모드
답장 초안 생성 → 내가 한 탭으로 검토·발송
상대 모름
+
L2
부분 위임
허락한 주제만 자동 응대 (약속 조율·택배 문의·간단 안내)
상대 표시
+
L3
자리비움 응대
자는 중·운전 중 가벼운 대화를 맥락에 맞게 대신
상대 표시
+
L4
분신 협상
상대 분신과 직접 조율 (캘린더 보고 약속 시간 잡기 등)
양쪽 제안
+
+
🛡️
절대 안전선: 금전, 약속 확정, 감정적·민감한 내용은 어떤 단계에서도 자동 처리하지 않고 무조건 본인에게 에스컬레이션. 모든 위임 행동은 사후 알림 + 되돌리기 가능.
+
+
+
2
신뢰·정체성 설계
"사칭 아니냐"는 의심을 투명성으로 정면 돌파
+
+
+
🔎 투명성 원칙
+
+
분신 뱃지 — 분신 발화는 말풍선에 표식이 붙어 사람 발화와 시각 구분
+
실시간 확인 — 상대는 언제든 "지금 본인? 분신?" 물어볼 수 있음
+
확정 불가 — 분신은 금전·약속을 확정 못 하고 "본인 확인 필요"로 보류
+
거부권 — 상대가 "분신 말고 본인이랑만" 요청하면 자동 응대 중단
+
+
+
+
자료 언제 줄 수 있어?
+
✦ 지우님의 분신지금 자리 비우셨고 보통 오전에 작업하세요. 내일 10시쯤 가능할 것 같아요 — 확정은 본인 확인 후 알려드릴게요!
+
ㅇㅋ 고마워
+
(지우 본인) 내일 10시 맞아요 :)
+
분신은 점선·뱃지로 구분, 확정은 본인이 마무리
+
+
+
+
+
3
"나다운" 분신 만들기
분신이 어색하면 컨셉 전체가 무너진다
+
+
🎨 말투 학습
+
온디바이스 우선 — 말투·표현·이모지 습관을 기기 안에서 학습
+
5분 온보딩 — 가입 시 기존 대화 임포트 or 질문 몇 개로 초기 세팅
+
교정 학습 — 분신 답을 고치면 학습해 점점 나다워짐
+
+
🎭 관계별 페르소나
+
톤 자동 전환 — 엄마엔 다정, 상사엔 정중, 친구엔 편하게
+
관계 메모 — 상대별 맥락(호칭·금기어·관계 온도) 기억
+
경계 설정 — "이 사람엔 분신 응대 끄기" 같은 관계별 규칙
+
+
+
+
+
4
분신이 빛나는 순간 (킬러 시나리오)
+
+
🌙 읽씹 종결
자는 동안 온 메시지에 분신이 "지금 자는 중, 내일 답할게" 맥락 응대 → 읽씹·답장 압박 소멸
+
📅 약속 자동 조율
분신끼리 서로 캘린더를 보고 가능한 시간을 좁혀 양쪽에 후보만 제안
+
🚫 비호감 대화 방어
영업·번호 캐묻기·치근덕거림을 분신이 정중히 막아 감정 노동 대신
+
📚 단톡 따라잡기
밀린 단톡에서 나 언급된 것만 골라 요약 + 답장 초안 제시
+
+
+
+
5
기존 AI 비서와의 결정적 차이
+
+
챗GPT · 시리 등
나와 대화하는 AI
+
VS
+
분신 메신저
나를 대신해 남과 대화하는 나
+
+
+
+
6
리스크 & 안전장치
컨셉을 무너뜨릴 질문에 미리 답한다
+
+
분신이 틀린 약속을 잡으면?
모든 위임 행동은 사후 알림 + 원클릭 되돌리기. 확정성 있는 건 본인 승인 전까지 "보류".
+
상대가 자동응대를 악용(스팸)?
분신이 스팸·도배 감지 시 응대 중단하고 본인에게 보고. 무한 응답하지 않음.
+
두 분신이 무한 대화 루프?
분신끼리 대화는 목적·턴 수 제한. 결론 안 나면 양쪽 본인에게 넘김.
+
프라이버시는?
말투 학습은 온디바이스/암호화. 분신 끄기 항상 가능, 상대도 분신 거부 가능.
+
+
+
+
7
확산 훅 & 수익 모델
+
+
🌱 네트워크 효과
+
분신 협상(L4)은 둘 다 앱이 있어야 작동 → "네 분신이랑 약속 잡게 하자"가 초대 동기
+
나다운 분신은 쓸수록 똑똑해져 이탈 비용 발생
+
+
💳 수익 모델
+
기본 분신 무료 (L0~L2)
+
고급 구독 — 더 똑똑한 모델, 더 넓은 위임(L3·L4), 다중 페르소나
+
기업용 — 고객 응대 분신 (B2B 확장)
+
+
+
+
+
8
이름 후보
"또 하나의 나"라는 정체성을 담은
+
+
Echo · 나를 따라 울리는
+
Twin · 또 하나의 나
+
분신 · 직관적 한국어
+
Aka · 또 다른 이름(alias)
+
둘이서 · 나와 분신이 함께
+
Mirror · 나를 비추는
+
+
+
+
+
+
+
+
💡
획기적 아이디어 · 분신을 OS 레이어로
+
"새 메신저 앱"이 아니라 지금 쓰는 모든 대화 위에 얹히는 AI 레이어로 재정의하면 어떨까. 채택 장벽 자체를 없애는 접근.
+
+ ✦ 카톡 대안이 아니라 — 모든 대화의 AI 비서
+
+
+
+
지금 설계
새 메신저 앱을 설치하고 옮겨와야 함
+
→
+
OS 레이어 확장
카톡·문자·DM 위에 분신만 얹으면 끝
+
+
+
+
1
구조 — 분신이 관통하는 레이어
앱을 옮기는 게 아니라, 앱 위에 얹는다
+
+
🙂 나모든 채널의 알림·초안·결정을 한곳에서 확인
+
↑ ↓
+
✨ AI 분신 레이어읽기·요약·초안·자동응대를 채널 구분 없이 동일하게 수행
+
↑ ↑ ↑ ↑ ↑
+
+
💬카카오톡
+
✉️문자(SMS)
+
📷인스타 DM
+
📧이메일
+
💼슬랙
+
+
각 앱은 그대로 두고, 분신이 알림 접근 권한으로 관통해 동일한 경험을 제공. 자체 메신저는 "완전판"으로 나중에 자연스럽게 유도.
+
+
+
+
2
왜 판이 바뀌는가
+
+
🚪
채택 장벽 제거
"메신저 옮기기"라는 가장 큰 진입 장벽이 사라짐. 앱 설치 후 권한만 허용하면 바로 가치 체감.
+
📈
시장 크기 확대
"카톡 대안 메신저" 시장이 아니라 "모든 대화의 AI 비서" 시장으로 — 타깃 인구 자체가 훨씬 커짐.
+
🔗
네트워크 효과 재설계
상대가 앱이 없어도 나는 즉시 가치를 얻음(L0~L1). 분신 협상(L4)만 "둘 다 앱 있어야" 유효 — 압박감 없는 자연 확산.
+
🏆
독점적 진입점
모든 채널의 요약·결정 로그가 한곳에 모이는 "허브"가 되면, 이후 자체 메신저·B2B 확장의 자연스러운 발판이 됨.
+
+
+
+
3
단계적 도입 로드맵
권한이 큰 만큼, 신뢰를 먼저 쌓고 넓힌다
+
+
1
읽기 전용 허브
알림만 모아 요약. 발송 권한 없음 — 가장 낮은 신뢰 비용으로 시작
+
2
초안 제안
답장 초안을 만들어 각 앱으로 넘겨줌. 발송은 사람이 원래 앱에서
+
3
제한적 자동응대
허락한 채널·주제에서만 분신이 직접 응답 (L2 수준 그대로 확장)
+
4
자체 앱으로 유도
분신 협상(L4) 등 완전한 기능은 자체 메신저로 넘어와야 가능 — 자연스러운 업그레이드 동기
+
+
+
+
4
기술·정책 도전 과제
이 아이디어의 진짜 리스크는 여기에 있다
+
+
각 앱이 접근을 막으면?
카톡·인스타는 자동화·크롤링을 정책상 막는 경우가 많음. 알림 접근 권한(안드로이드 Notification Access) 기반으로 시작 — 읽기는 가능하나 발송은 각 앱 자체 API/자동입력에 의존해 범위가 제한적일 수 있음.
+
OS·플랫폼 정책 리스크는?
iOS는 안드로이드보다 훨씬 제한적. 안드로이드 우선 출시로 검증 후, iOS는 자체 메신저 전환을 유도하는 전략이 현실적.
+
권한 요청이 과도해 보이지 않을까?
"모든 메시지를 읽는 앱"은 프라이버시 우려를 키움. 온디바이스 처리 원칙을 이 레이어에도 그대로 적용하고, 어떤 데이터가 어디로 가는지 실시간 대시보드로 공개.
+
각 앱 UI가 바뀌면 깨지지 않을까?
앱 업데이트마다 파싱 로직이 깨질 수 있음. 초기엔 안정적인 API가 있는 채널(문자·이메일) 우선으로 검증하고, 카톡·인스타 등은 이후 확장.
+
+
+
💡 정리: 이 아이디어는 "새 메신저를 만든다"에서 "지금 쓰는 대화 위에 AI 자아를 얹는다"로 제품 정의 자체를 바꾼다. 자체 메신저(현재 설계)는 완전한 분신 경험(L4 협상 등)을 위한 최종 목적지로 남기고, OS 레이어는 그곳으로 가는 저마찰 진입점 역할을 하는 투트랙 전략이 가능.
+
+
+
+
+
+
+
3
회의 논점
+
이 자료를 띄워놓고 함께 결정하면 좋을 질문들입니다.
+
+
Q1 · 방향
AI 분신으로 확정할까?
아이디어 보드의 다른 축(기록/관계)과 비교해 최종 컨셉을 정한다.
+
Q2 · 타깃
대중 vs 회사, 어디부터?
첫 사용자층을 정해야 기능 우선순위가 잡힌다.
+
Q3 · 수용성
사람들이 AI 대리 응답을 받아들일까?
자율성 어느 단계(L0~L4)까지 현실적으로 켤지 토론.
+
Q4 · 신뢰
사칭 우려를 충분히 막았나?
투명성 장치가 사용자를 납득시키는지 점검.
+
Q5 · MVP
데모로 보여줄 한 시나리오는?
읽씹 종결 / 약속 조율 / 대화 방어 중 하나를 고른다.
+
Q6 · 이름
서비스 이름을 뭐로?
정체성을 가장 잘 담는 후보를 추린다.
+
Q7 · 전략
자체 앱 vs OS 레이어, 어디서 시작?
채택 장벽을 낮추는 OS 레이어 선출시 vs 완전한 경험의 자체 메신저 선출시, 투트랙 순서를 정한다.