[앱·스튜디오] Chat 메신저 기능 PRD

Backlog grooming 단계의 산출물. 무엇을 만들지·왜 만들지·핵심 비즈니스 룰을 정의한다. 화면별 디테일(컴포넌트·상태·인터랙션)은 spec.md로.

---

Status: draft Created: 2026-05-15 Last updated: 2026-06-01 (chat generation star cost fixed: 10 stars) Linear Project: [앱] Chat 메신저 기능 (8aea9b7ef906) Linear Issue: DEE-72 (PRD writing) Author: agent (momo) 앱/웹/스튜디오: 앱 + 스튜디오

---

0. 요약

• 본 PRD는 캐릭터별 1:1 Chat Thread를 신설해, 유저가 에피소드 밖에서도 캐릭터를 살아있는 상대로 느끼고 관계를 이어가게 만드는 메신저 surface를 정의한다.
• Chat Thread는 1 캐릭터당 1개만 생성되는 persistent entity다. 이번 MVP에서는 채팅방 나가기/삭제/대화기록 삭제를 제공하지 않는다.
• 사용자에게 보이는 송수신 단위는 Chat Bubble(말풍선), LLM 호출·과금·성공/실패 판단 단위는 Chat Generation Unit으로 분리한다. 여러 user bubble이 1개의 generation input으로 묶일 수 있다.
• 과금은 메시지/말풍선 단위가 아니라 generation 성공 완료 시점에 10스타를 차감한다. 생성 실패, timeout, 안전 가드 차단, 서버 오류는 차감하지 않는다.
• Chat은 카카오톡식 메신저 호흡(읽음 1, 타이핑, 시간/날짜 표시, 말풍선 분리)을 따르고, surface/진입감은 Instagram DM도 함께 참고한다.
• MVP 진입점은 Chat 메뉴와 에피소드 상세 2개다. 디렉터/캐릭터 프로필 진입점은 후속 범위다.
• 캐릭터 프로필 이미지·표시명·상태 메시지는 스튜디오 **[소울 관리]**에서 디렉터가 관리하고 Chat에 라이브 반영된다. 캐릭터 비공개/삭제 시 기존 대화는 조회 가능하지만 입력창은 비활성화된다.
• 채팅방 헤더에는 캐릭터(Soul) 프로필, 이름, 상태 메시지만 노출한다. 관계 Lv.N + Exp progress는 프로필 이미지를 눌러 진입하는 캐릭터 프로필 상세에서만 노출하며, raw score/숫자 점수는 노출하지 않는다.
• 관계 Lv/progress 노출 조건: Chat Thread가 생성/연결된 (user, Soul) 관계에서만 노출한다. Chat 미연결 Character 또는 에피소드 단독 노출면에서는 숨긴다. (Bond Exp/Level은 episode 소스 + Chat 소스를 (user, Soul)로 aggregate하여 산출하며, 노출 자체는 Chat Thread/Soul 연결을 전제로 한다.)
• 최근 기억 불러오기, 내 User Relational Persona 수정(UI 라벨은 "내 프로필 수정" 후보), 선톡 더 자주 받기는 채팅방 우상단 햄버거 메뉴에서 진입한다.
• 선톡 생성·예약·기본 빈도·발송 정책은 별도 PRD/이슈(DEE-131) 범위다. 본 PRD는 기본 선톡을 끄는 ON/OFF가 아니라, 기본 제공분 위에 더 자주 받는 유료 추가 빈도 surface와 비용 고지를 책임진다.

---

1. 목표 및 배경

1.1 문제

• 사용자 정의 (segment): 캐릭터 중심으로 콘텐츠를 소비하는 플레이어 — 특정 캐릭터가 등장하는 에피소드를 반복 플레이하거나, 캐릭터 자체에 정서적 애착이 있는 사용자.
• 상황 (when, where): 에피소드 하나를 끝내고 나서 같은 캐릭터와의 접점이 끊기는 시점. 다음 에피소드 발행을 기다리는 사이, 또는 짧은 호흡으로 가볍게 캐릭터와 닿고 싶은 일상 맥락.
• 불편 / 미충족 needs: 에피소드를 벗어나면 캐릭터-유저 접점이 0이다. 캐릭터가 "에피소드 안의 말풍선"으로만 존재하고, 살아 있는 상대로 느껴지지 않는다.

1.2 근거

• 이니셔티브 방향: "캐릭터 관계/메신저 경험 기반 구축". 본 PRD는 그 이니셔티브의 첫 진입 surface — 캐릭터가 에피소드 밖에서도 존재하는 상대임을 체감하게 하는 채널.
• 현재 우회: 캐릭터 애착이 있는 유저들도 다음 에피소드 발행까지 접점이 없어 작품 이탈로 이어짐.
• 인접 작업:
  • DEE-71/character-bond-system: (user, Soul) Bond Exp 누적 적재 (Chat 응답 생성 소스). 본 PRD는 그 소스를 제공하고, 캐릭터 프로필 상세에서 관계 Lv + Exp progress를 노출(Chat Thread 연결 시에만).
  • DEE-131/seontok (선톡): 캐릭터 발신 시작·예약·빈도 정책. 본 PRD는 선톡 더 자주 받기(유료 추가 빈도) surface만 책임지고, 선톡 생성·발송 정책은 DEE-131.
  • DEE-66/79/episode-detail: 에피소드 상세에서 Chat 진입점 제공.

1.3 아이디어 (해결 방향)

캐릭터별 1:1 채팅방을 가진 메신저 surface를 신설한다. 친숙한 모바일 메신저(Instagram DM, 카카오톡)의 메타포를 차용해 "살아 있는 상대와 메시지를 주고받는" 감각을 만든다.

• 레퍼런스 참조 방식:
  • Instagram DM — 가벼운 Chat surface·진입 느낌(메신저 탭·채팅방 리스트의 톤).
  • 카카오톡(모바일 메신저) — 메시지 교환 호흡: 익숙한 읽음 상태·타이핑·말풍선·시간 표시·실시간감.
• 채택 컨셉:
  • 1 캐릭터 = 1 채팅방. 에피소드를 가로질러 누적되는 단일 persistent entity이며, 이번 범위에서는 채팅방 나가기/삭제를 제공하지 않는다.
  • 캐릭터는 디렉터가 만들고 운영하는 지속적 존재. 프로필 이미지·표시명·상태 메시지는 디렉터가 스튜디오에서 관리하고 Chat에 라이브 반영.
  • 메모리: Chat 시작 시 에피소드 컨텍스트로 초기 자동 로딩. 이후 사용자가 채팅방 우상단 햄버거 메뉴에서 명시적으로 "최근 기억 불러오기"를 눌러 그 시점 기준 최신 에피소드 메모리를 다시 불러올 수 있음(스타 소모).
  • User Relational Persona (유저 측 대화 프로필): Chat 시작 시 해당 (user, Soul) 관계용 User Relational Persona이 자동 생성되며 유저가 편집 가능. 해당 Soul과의 Chat Thread 안에서만 적용. 전역 계정 프로필이 아니며 다른 Soul의 User Relational Persona에 영향 없음.
  • BM: 메시지 generation 1회 성공당 10스타를 소모한다. 메모리 업데이트도 스타 소모 대상이다. 별도 "일일 무료 메시지" 한도는 두지 않고 일별 무료 스타 발급으로 무료 사용을 자연스럽게 흡수.

1.4 핵심 원칙 / 가설

가설: Chat을 통해 유저가 캐릭터를 에피소드 밖에서도 존재하는 상대로 인지하면, 관계를 이어가며 반복적으로 대화하게 된다.

원칙:

• 캐릭터는 단순히 에피소드 안의 말풍선이 아니라 지속적으로 존재하는 상대다.
• Chat은 챗봇 응답 박스가 아니라 살아 있는 상대에게 메시지를 보내는 경험이어야 한다.
• 캐릭터는 디렉터가 만들고 운영하는 존재. 프로필·상태·메타 정보는 디렉터가 관리하며 라이브 반영된다.

구체 가설:

1. 캐릭터별 1:1 Chat surface가 생기면, 캐릭터에 애착이 있는 유저의 상당 비율이 Chat을 시작한다 — 진입 가설.
2. Chat을 시작한 유저는 1회성이 아니라 일정 빈도로 재방문해 대화를 이어간다 — 체류·재방문 가설.
3. 유료 스타 소모(메시지 · 메모리 업데이트)로 대화를 이어가는 유저가 일정 비율 발생한다 — BM 시그널 가설.

1.5 성공 지표

지표	현재	목표	측정 방법
Chat 진입율	0	출시 직전 확정	캐릭터 진입 가능 유저 중 첫 Chat 메시지 전송 비율
Chat 재방문율 (WoW)	0	출시 직전 확정	Chat 첫 메시지 발송 유저의 다음 주 재 메시지 전송 비율
유료 스타 결제 메시지 비율	0	"0이 아님" 시그널	무료 스타 외 결제 스타로 차감된 메시지 비율

• 메인 지표 (둘 다): Chat 진입율 + Chat 재방문율. 한쪽이 무너지면 surface 의미가 흔들리므로 둘 다 메인.
• 가드레일 지표:
  • 에피소드 플레이 funnel 회귀 (Chat이 플레이를 잠식하지 않는지).
  • LLM 응답 비용/메시지.
  • 일일 무료 스타 발급 비용 (메시지·메모리 업데이트 스타 소모로 인한 무료 스타 소모량).

---

2. 타깃 사용자

2.1 주요 사용자

• 특정 캐릭터에 정서적 애착이 있는 플레이어 (캐릭터 중심 소비층).
• 빈도: 짧은 호흡(분 단위)·반복적 방문 — 메신저 메타포의 자연 빈도.

2.2 핵심 시나리오

1. 플레이어가 에피소드를 클리어한 직후, 에피소드 상세에서 등장 캐릭터의 "대화하기" 진입점을 눌러 채팅방에 들어간다. 매핑된 Soul과의 Chat Thread가 시작/재사용되고, 그 시점에 해당 에피소드 컨텍스트로 메모리가 자동 로딩되며, (user, Soul) User Relational Persona이 자동 생성된다. 첫 메시지를 보내면 스타가 소모되고 Soul의 응답이 도착한다.
2. 다음 날 플레이어가 Chat 메뉴에 들어와 어제 대화한 캐릭터의 채팅방에서 이어서 대화한다. 무료 스타가 회복되어 있으면 그걸 쓰고, 부족하면 결제한다.
3. 플레이어가 캐릭터의 최신 에피소드를 클리어한 뒤 채팅방 우상단 햄버거 메뉴에서 "최근 기억 불러오기"를 눌러 최신 에피소드 메모리를 캐릭터에게 반영한다(스타 소모). 이후 캐릭터는 그 기억 위에서 대화한다.
4. 플레이어가 채팅방에서 User Relational Persona(유저 측 대화 프로필)을 편집해 Soul이 자신을 어떻게 인지하길 원하는지 조정한다.
5. 플레이어가 캐릭터에게 사진을 전송한다(예: 일상 사진). 캐릭터도 사진으로 응답할 수 있다(MVP에서는 구조만 가능, 실 사진은 후속).
6. 플레이어가 채팅방 우상단 햄버거 메뉴에서 선톡 더 자주 받기를 확인한다. 기본 선톡은 유지되고, 추가 빈도를 신청하면 유료/스타 소모 가능성이 있다는 사전 고지를 본다(선톡 발송 정책은 DEE-131).

---

3. 핵심 기능 요구사항

3-1. 클라이언트 (앱)

메신저 surface (Chat 메뉴 · 채팅방 리스트)

• 주요 동작: Chat 메뉴(메신저 surface)에서 유저가 시작했거나 메시지를 주고받은 모든 캐릭터의 채팅방을 최신순으로 보여준다.
• 비즈니스 룰:
  • 1 캐릭터 = 1 채팅방 (글로벌). 에피소드가 바뀌어도 채팅방은 합쳐진다.
  • 이번 MVP에서는 채팅방 나가기/삭제를 제공하지 않는다. 한 번 생성된 (user, Soul) Chat Thread는 유지되며, 캐릭터 비공개/삭제 등 예외 상태에서는 read-only/전송 차단으로 처리한다.
  • 정렬: 마지막 메시지 시각 desc. 페이지네이션 정책은 spec.
  • 빈 상태: "아직 대화한 캐릭터가 없어요" 안내 + 캐릭터 추천 CTA. 추천 카드 내부에 해당 캐릭터의 관련 에피소드 정보를 보조로 노출할 수 있다(주 CTA는 캐릭터 탐색/시작이지, 에피소드 탐색이 아니다).
  • 채팅방 행에는 캐릭터 프로필 이미지·표시명·상태 메시지·마지막 메시지 프리뷰·읽지 않은 카운트 노출. 캐릭터 프로필 메타는 스튜디오 [소울 관리]에서 관리되며 라이브 반영(§3-2).
• 상태별 동작:
  • 한 번도 대화 안 함: 빈 상태.

채팅방 진입점 (MVP 범위)

본 PRD MVP 진입점은 두 군데로 한정한다.

• Chat 메뉴 (메신저 surface) — 채팅방 리스트에서 기존 채팅방 진입.
• 에피소드 상세 — 등장 캐릭터의 "이 캐릭터와 대화하기" 진입점. 누르면 해당 캐릭터의 글로벌 채팅방으로 진입(기존 채팅방이 있으면 재사용, 없으면 신규 생성).
• (범위 외) 디렉터/캐릭터 프로필 페이지 진입점, MY 탭, 캐릭터 카드 등 추가 진입점은 후속.

채팅방 화면

• 주요 동작: 한 캐릭터와의 1:1 채팅 화면. 메시지 입력·전송·캐릭터 응답 수신·연출.
• 헤더 / 캐릭터 메타:
  • 캐릭터 프로필 이미지 · 표시명 · 상태 메시지 노출. 모두 스튜디오 [소울 관리]의 라이브 값(§3-2).
  • 관계 표시: Chat 헤더에는 노출하지 않고, 캐릭터 프로필 이미지를 눌러 진입하는 프로필 상세에서 관계 Lv.N + Exp progress bar를 시각적으로 노출. raw score/포인트 숫자는 노출하지 않는다. (system/도메인 term: Bond / Bond Exp / Bond Level — Character-only가 아니라 (user, Soul) 단위로 episode 소스 + Chat 소스를 aggregate한 값. 유저 노출 문구: 관계 레벨, 관계 Lv, Exp. 데이터 적재는 DEE-71.) 노출은 Chat Thread가 생성/연결된 Soul에서만 — Chat 미연결 Character나 에피소드 단독 노출면에서는 숨긴다.
  • 채팅방 옵션(최근 기억 불러오기, User Relational Persona 편집, 선톡 더 자주 받기 등)은 우상단 햄버거 메뉴에서 제공한다. 메뉴 내 위치·표현은 spec.
• 메시지 단위 (두 레벨):
  • Bubble (말풍선) — 유저에게 보이는 UI 송신 단위. 유저가 전송 버튼을 누를 때마다 1개의 bubble이 즉시 노출된다. 메시지 1 bubble = 텍스트 1건 또는 사진 1건.
  • Generation Unit (생성 단위) — 실제 LLM 생성 호출 1회의 입출력 단위. 여러 개의 유저 bubble이 하나의 generation input으로 묶일 수 있고, 1회의 generation output은 1개 또는 여러 개의 캐릭터 bubble로 렌더링될 수 있다.
  • 두 레벨은 PRD/도메인 차원에서 명시적으로 분리한다(UL §6 참고). delimiter token/이름 등 실 표현은 spec.
• 생성 트리거 (1초 비활성 정책):
  • 유저가 마지막 입력(전송 또는 타이핑) 이후 1초 이상 추가 입력이 없으면, 직전 성공 generation 시점 이후 쌓인 모든 pending 유저 bubble을 묶어 1회의 generation input으로 만들어 생성을 시작한다.
  • 묶을 때는 명시적인 bubble delimiter를 사용해 input/output 양쪽에서 bubble 경계가 보존되도록 한다(delimiter 토큰명은 spec).
  • 사진은 텍스트와 동일한 generation input 요소로 취급된다(아래 "사진" 참고).
• 응답 표시 흐름 (읽음/타이핑):
  • 유저 bubble 옆에는 카카오톡 스타일의 1 (미확인) 표시가 붙는다.
  • 해당 bubble들이 포함된 generation이 성공적으로 완료되는 시점에 1 표시가 사라진다.
  • 1 사라진 직후, 응답 길이에 비례하는 시간 동안 타이핑 인디케이터가 노출된다.
  • 타이핑이 끝나면 캐릭터 bubble(들)이 순차적으로 노출된다.
• 사진 송수신 (in scope, 부분):
  • 유저 → 캐릭터 사진 전송: 1회 전송 액션당 사진 1장만 첨부 가능(메시지 1 bubble = 사진 1건). 사진은 generation input에서 텍스트와 동등한 입력 요소로 취급된다. 1초 비활성 정책상 한 generation input에 여러 장의 사진이 들어가는 경우는 일반적으로 발생하지 않지만, 구조는 photo-as-input 가정과 충돌하지 않게 정의된다.
  • 캐릭터 → 유저 사진 전송: MVP에서는 캐릭터가 사진을 보낼 수 있는 능력/구조(메시지 타입, 렌더링, 저장)만 깐다. 실제 사진 생성 모델·디렉터 제공 사진 자산은 후속 enhancement.
  • 사진 보안·검열·저장 정책 디테일은 spec.
• 입력창 / 전송 룰:
  • 텍스트 메시지 최대 길이 300자.
  • 전송 버튼은 입력값 길이가 0인 경우에만 비활성. 그 외에는 항상 활성(스타 잔액 부족 등은 전송 시도 시점에 처리, §3-1 BM 정책).
• 시간/날짜 표시:
  • 각 bubble의 옆에는 실제 발송 시각(real-world time)을 표시한다.
  • 날짜가 바뀌면 일반 메신저 UX처럼 채팅 중앙에 날짜 구분선을 노출한다.
• 메신저 호흡 연출(말풍선 형태, 인디케이터 디자인 등 시각 디테일)은 Instagram DM + 카카오톡 레퍼런스 기반으로 spec에서 확정.
• 메모리 동작:
  • 초기 로딩: 채팅방을 처음 시작할 때, 해당 캐릭터에 대해 유저가 마지막으로 진행한 에피소드 컨텍스트로 메모리가 자동 로딩된다(스타 소모 없음, 최초 1회).
  • "최근 기억 불러오기": 채팅방 우상단 햄버거 메뉴에서 사용자가 명시적으로 "최근 기억 불러오기"를 누르면, 그 시점 기준 최신 에피소드 메모리를 캐릭터에게 다시 불러온다.
    • 버튼 라벨은 정확히 "최근 기억 불러오기".
    • 메모리 업데이트는 스타가 소모된다(차감액 = §3-1 BM 정책의 메모리 업데이트 비용, 실 수치 TBD §7).
    • 누르기 전에 비용·효과 사전 안내(다이얼로그/시트) 노출.
  • Chat ↔ 에피소드 메모리는 단방향. Chat 대화가 에피소드 플레이에 영향을 주지 않는다.
• User Relational Persona (User Relational Persona / 유저 측 대화 프로필):
  • 정의: User Relational Persona은 특정 (user, Soul) Chat Thread에서 적용되는 유저 측 대화 프로필이다. Play Profile이 play 컨텍스트에 적용되는 것과 동일하게, User Relational Persona은 Chat Thread 컨텍스트에 적용된다. 같은 유저라도 Soul/Thread마다 다른 User Relational Persona을 가질 수 있다. 전역 계정 프로필이 아니며, 다른 Soul의 User Relational Persona에 영향을 주지 않는다.
  • Soul Prompt와 구분: Soul Prompt는 디렉터가 스튜디오 [소울 관리] / Soul Management에서 입력하는 Soul 측 톤/성격/응답 instruction. User Relational Persona은 유저 측 대화 프로필. 두 값은 서로 다른 entity.
  • Chat 시작 시, 해당 (user, Soul)용 User Relational Persona이 자동 작성된다. 유저는 편집 가능(자유 텍스트 + 필요한 필드는 spec).
  • 편집 자체는 스타 소모 없음.
  • 이전 표기 "유저 페르소나 / User Relational Persona"는 본 PRD에서 User Relational Persona로 정렬한다. 유저 노출 라벨 후보는 "대화 프로필" 또는 "User Relational Persona" — 최종 UX writing은 디자인 단계에서 확정.
• 채팅방 메뉴:
  • 채팅방 오른쪽 상단 햄버거 메뉴에서 최근 기억 불러오기, 내 User Relational Persona 수정, 선톡 더 자주 받기 등 채팅방 단위 옵션에 진입한다. 기본 선톡 수신 자체를 끄는 ON/OFF가 아니다.
  • 메뉴 내 항목 구성·순서·라벨은 spec.
• 관계 Lv / Exp 연동:
  • Chat 응답 생성 성공 시 Bond Exp 적재(Chat 소스) 이벤트 발화. Exp → Lv 매핑·시스템 정의는 DEE-71 (도메인 term: Bond / Bond Exp / Bond Level — (user, Soul) 단위로 episode 소스 + Chat 소스 aggregate. 유저 노출 문구: 관계 Lv, Exp).
  • 캐릭터 프로필 상세는 raw score가 아닌 관계 Lv.N + Exp progress bar만 노출. 채팅방 헤더에는 관계 정보를 노출하지 않는다. 노출 조건: Chat Thread가 생성/연결된 (user, Soul)에서만 노출.

스타 결제 (BM 정책)

본 PRD는 BM policy 골격을 결정한다. 결제 funnel 최적화·번들·프로모션 등은 후속.

• 별도 무료 메시지 한도 없음: "일일 무료 N건"이라는 별도 한도는 두지 않는다. 무료 사용은 Frontia의 일일 무료 스타 발급으로 자연스럽게 흡수.
• Generation당 스타 차감 (bubble당이 아니라 generation 단위):
  • 1회의 generation이 성공적으로 완료되어 유저에게 노출 가능한 시점에 10스타를 차감한다. 가차감/사전차감 없음 — 성공 시에만 차감한다.
  • 여러 user bubble이 1개의 generation input으로 묶인 경우에도 차감 단위는 generation 1회이며, 차감액은 10스타다.
• 생성 실패 시 처리 (timeout, LLM 안전 가드 차단, 서버 오류 등):
  • 스타를 차감하지 않는다 (사전 차감하지 않고, 성공 시에만 받는다).
  • 유저에게는 토스트 모달(혹은 모달성 토스트) 로 "생성이 실패해 스타가 차감되지 않았어요" 류 안내를 명확히 노출. 몰입을 일부 깨더라도 차감 안 됨을 분명히 전달.
  • 실패 시 pending 상태였던 유저 bubble들은 사라지지 않고 그대로 유지된다. 유저가 다음 메시지를 보낼 때, 마지막 성공 generation 이후 누적된 모든 유저 bubble(이전 실패분 포함)을 새 generation input으로 묶어 재시도한다.
• 메모리 업데이트 스타 차감:
  • "최근 기억 불러오기" 실행 시 스타 M개 차감. 차감 시점 = 메모리 업데이트가 성공적으로 반영된 시점. 실패 시 차감 안 함.
  • 단가 M 실수치는 메모리/모델 비용 리서치 후 확정(§7).
• 잔액 부족 시: 결제 안내 + 스타 상점 진입 CTA. 메시지/메모리 업데이트 자체는 차단.
• 스타 차감 사전 고지 (first-consumption only):
  • 유저가 Chat에서 처음으로 스타가 차감되는 액션(첫 generation 성공 시점)에 한해, Play surface와 유사한 바텀시트 안내로 "Chat 사용 시 스타가 차감된다"는 사실을 고지한다.
  • 이후에는 반복 고지하지 않는다. 확인 여부는 로컬 스토리지에 ack 저장.
  • 정확한 카피·바텀시트 레이아웃은 spec.

선톡 더 자주 받기 설정 (surface만)

• 주요 동작: 사용자는 기본으로 제공되는 캐릭터 선톡 위에, 추가 빈도의 선톡을 더 자주 받을지 신청/해제할 수 있다. 기본 선톡 수신 자체를 끄는 ON/OFF는 본 범위가 아니다.
• 위치: 채팅방 오른쪽 상단 햄버거 메뉴 안의 채팅방 옵션.
• 사전 고지: 추가 빈도 신청 시 자동 생성/모델 비용 = 스타를 소모할 수 있다는 사실을 사용자에게 사전 고지(설정 진입 시점 + 신청 시점).
• 선톡 생성·예약·기본 빈도·실 차감 정책은 본 PRD 범위 외 — DEE-131이 책임. 본 PRD는 추가 빈도 surface + 사전 고지 + 설정 이벤트 발화만 책임.

LLM 안전 가드

• Chat의 LLM 응답에는 기존 Frontia LLM 응답 안전 정책 룰셋을 그대로 적용한다(별도 신규 룰셋을 정의하지 않는다는 의미. 본 PRD는 신규 안전 워크플로우 — 신고·차단·운영 큐 등 — 도 정의하지 않는다. 대상이 사용자가 아닌 캐릭터이기 때문).
• 안전 가드로 응답이 차단되는 경우는 생성 실패의 한 종류로 취급된다. 차감은 generation 성공 시점에만 일어나므로 안전 가드 차단 시 스타는 차감되지 않는다. 유저에게는 §3-1 BM의 생성 실패 토스트와 동일한 흐름으로 안내한다.

푸시 알림

• 주요 동작: 캐릭터(Soul)의 응답 메시지 수신을 푸시로 알림. 사람이 메시지를 보낸 것처럼 느껴지는 메신저 푸시가 목표.
• 비즈니스 룰:
  • 기본: 앱 미이용/백그라운드 상태에서 응답 수신 즉시 푸시 발송.
  • Human-like push 정책: Chat 응답 푸시는 카카오톡/인스타그램 Chat 푸시처럼 "사람이 보낸 메시지"로 느껴지게 구성한다.
    • title = Soul/캐릭터 display name (앱 이름이 아님).
    • body = 메시지 스니펫.
    • sender display(아이콘/아바타) = 가능한 한 캐릭터(Soul) 프로필 이미지. 단 OS/푸시 SDK는 일반적으로 앱 아이콘을 시스템 영역에서 사용하므로, sender 영역(notification large icon / avatar)에 Soul 이미지 적용이 가능한지를 SDK·OS별로 검증해서 spec에서 확정한다.
    • Chat 응답 푸시는 선톡(proactive message) 푸시와 정책을 분리한다. 선톡 푸시 정책은 DEE-131.
  • 앱 이용 중이면 푸시 알림을 보내지 않는다. 인앱 unread/상태 변화로만 표시한다.
  • 여러 응답을 별도 묶음 푸시로 합쳐 보내지 않는다. 현재 푸시 정책과 동일하게 처리한다.
  • 푸시 종류 on/off 토글: 기존 알림 설정 surface에 "Chat 알림" 항목 추가. 본 PRD는 항목 추가만 책임.
  • 읽음/안읽음 모델: 채팅방 리스트에 unread 뱃지/카운트 노출. 모델 정의는 spec.
• 선톡 푸시는 DEE-131 범위. (단, human-like 형태감의 기본 원칙은 본 PRD의 Chat 응답 푸시에 한정해 박는다.)

3-2. 스튜디오 ([소울 관리] 탭 신설 / Soul Management)

스튜디오에 [소울 관리] 탭을 [에피소드 관리]와 동일 위계로 추가한다. UI 라벨은 [소울 관리]로 확정한다. 기능/도메인 term은 Soul Management — Chat 도메인에서는 디렉터가 관리하는 entity를 "Soul"이라 부른다. (UL §6 참고: Soul = Studio-managed Chat/도메인 entity, Character = episode-internal 등장 인물. Chat 대화의 상대는 도메인적으로 Soul.)

• 주요 동작: 디렉터는 [소울 관리]에서 Soul을 먼저 생성하고, 필요하면 이후 기존 에피소드 Character를 연결한다. Soul은 Episode Character보다 먼저 존재할 수 있는 독립 Chat entity다.
• CRUD 범위:
  • Soul 생성 · 수정 · (정책에 따라) 삭제/비공개.
  • 기존 에피소드 Character와의 연결(매핑) 관리. Episode Character 매핑은 optional이며, 연결된 Character가 0개여도 Soul 생성/자동 저장/적용이 가능하다. Soul 1개당 연결 가능한 Episode Character는 최대 10개이며, Episode Character 1개는 동시에 여러 Soul에 연결될 수 없다.
• 필수/선택 입력 필드:
  • 프로필 이미지 — 채팅방 헤더·리스트·푸시 sender 이미지에 활용.
  • 표시명 (display name) — 채팅방 헤더·리스트·푸시 title에 활용.
  • 상태 메시지 — 채팅방 헤더에 표시.
  • Soul Prompt (Chat/메신저용 캐릭터 프롬프트, 신규 필수) — 디렉터가 입력하는 Soul 측 톤/성격/응답 instruction. Studio 입력 중 소울 정보가 Soul Prompt / soul_default_persona의 1차 source다. 채팅 상황 설정은 별도 선택 입력값으로, Chat을 처음 시작할 때 recent_context가 없는 initial/recent context 위치에 붙는다(BE 변수명 chat_initial_situation). 유저 측 User Relational Persona과 명확히 분리 — Soul Prompt = counterpart(Soul) 측 instruction, User Relational Persona = 유저 측 대화 프로필.
  • 추가 메타(설명/태그 등)는 spec.
• 자동 저장 / 적용: Soul 설정 내용은 편집 중 자동 저장된다. 다만 유저-facing Chat에 반영되는 시점은 별도 [적용] 액션 이후다. [적용] 성공 후에는 에피소드처럼 “발행 후 새 플레이부터 스냅샷 적용”되는 모델이 아니라, 해당 Soul을 참조하는 Chat surface에 active Soul settings로 라이브 반영된다. 이미 시작된 Chat generation에는 소급 반영하지 않고, [적용] 성공 이후 시작되는 다음 generation부터 최신 active Soul settings를 사용한다.
• 비공개/삭제 처리: 디렉터가 Soul을 비공개/삭제하면 유저는 해당 Soul과 더 이상 대화할 수 없다. 기존 채팅방과 이전 대화 기록은 확인 가능하지만, 입력창은 비활성화하고 placeholder로 대화 불가 사유를 안내한다.
• 권한: 디렉터(작품 소유자). 권한 모델 디테일은 spec.

본 PRD는 어드민(운영자) 신규 화면을 만들지 않는다. Chat 메시지 신고·캐릭터 차단·신고 큐 등 모더레이션 surface는 정의하지 않는다(대상이 사용자가 아닌 캐릭터이기 때문).

3-3. 딥링크 / URL 구조

• 신규 path:
  • /chat — Chat 메뉴 (채팅방 리스트).
  • /chat/character/:characterId — 특정 캐릭터의 채팅방.
• 앱 미설치 시 fallback: 마켓 (Chat은 앱 전용 — 본 PRD는 앱 MVP 범위. 웹 surface는 범위 외).
• 신규 path 2개는 엔지니어 확정 후 DeepLink 노션 doc + 본 표 반영(§7).

3-4. Scope

포함 (In scope)

• Chat 메뉴(메신저 surface) + 캐릭터별 1:1 채팅방.
• 1 캐릭터 = 1 Chat Thread 보장. 채팅방 나가기/삭제 미제공 및 예외 상태 read-only/전송 차단 처리.
• 에피소드 상세 → Chat 진입점.
• 채팅방 화면(텍스트 메시지 송수신, 메신저 호흡 연출).
• 사진 송수신: 유저 → 캐릭터 (전체 기능), 캐릭터 → 유저 (구조/능력만, 실 사진은 후속).
• 메모리 초기 로딩 + 우상단 햄버거 메뉴의 "최근 기억 불러오기"(스타 소모).
• User Relational Persona (per (user, Soul) Thread) 자동 생성 + 편집.
• 스타 결제 정책(generation·메모리 업데이트 차감, 성공 시점 차감, 실패 시 미차감).
• 선톡 더 자주 받기(유료 추가 빈도) + 사전 고지(생성·발송 정책은 DEE-131).
• 푸시 알림(응답 수신) + 알림 on/off 항목 추가.
• (user, Soul) Bond Exp 적재(Chat 소스) 이벤트 발화 + 캐릭터 프로필 상세에 관계 Lv/Exp progress 노출(Chat Thread 연결 시에만).
• 스튜디오 [소울 관리] 탭(Soul 생성/편집, optional Episode Character mapping, Character 0개 Soul 생성 허용, Soul 1개당 Episode Character 최대 10개 연결, Episode Character 1개는 여러 Soul에 중복 연결 불가, 프로필/표시명/상태 메시지/Soul Prompt 관리, 자동 저장 + [적용] 액션 기반 Chat 라이브 반영).
• 로깅 이벤트, 신규 딥링크 path 2개.
• 데이터 모델 확장성: Chat 도메인 raw 데이터(Chat Thread/메시지/사진/메모리/User Relational Persona/Soul Prompt/빌링 이벤트)는 후속 정책 변경 시 데이터 리셋 없이 진화 가능해야 한다.

제외 (Out of scope)

• 단톡(그룹 채팅).
• 캐릭터가 보내는 사진의 실 생성 모델 / 디렉터 제공 사진 자산 (구조만).
• 선톡 생성·예약·빈도·실 차감 정책 (DEE-131).
• 톤 변화, 잠금해제 등 관계 레벨 기반 효과 — 후속 layer.
• Chat → 에피소드 메모리 역방향 반영.
• 채팅방 나가기/삭제, 대화 기록 삭제, 숨김/아카이브.
• 결제 funnel 최적화·번들·프로모션·구독.
• 메시지 신고, 캐릭터 차단/차단 해제, 모더레이션 큐 등 안전 워크플로우 (대상이 사용자가 아니라 캐릭터).
• 디렉터/캐릭터 프로필 페이지 진입점, MY 탭 등 추가 진입점.
• 어드민(운영자) 신규 화면.

---

4. 에러 처리 및 예외 상황

상황	처리 방향
LLM 응답 생성 실패 (timeout / 안전 가드 차단 / 서버 오류)	스타 차감 없음. 토스트성 모달로 "생성 실패, 스타 차감되지 않음" 명시. pending 유저 bubble은 유지되며 다음 메시지 전송 시 누적분이 새 generation input으로 묶임
메모리 업데이트 실패	스타 차감 안 함 + 안내. 기존 메모리 상태 유지
사진 업로드 실패 (용량/포맷/네트워크)	메시지 미전송 처리 + 재시도 안내
스타 잔액 부족	메시지/메모리 업데이트 차단 + 결제 안내 / 스타 상점 진입 CTA
캐릭터/에피소드 비공개 또는 삭제	채팅방 기록은 보존하되 입력창 비활성화 + placeholder로 대화 불가 사유 안내
푸시 권한 미허용	인앱 unread 뱃지로만 알림. 권한 안내는 별도 자리
User Relational Persona 편집 동시성 충돌	마지막 저장 우선. 디테일은 spec
Episode Character가 0개인 Soul	Soul 생성/자동 저장/적용 허용. 에피소드 상세 기반 진입점은 없지만, Chat 메뉴/추천/직접 노출 여부는 rollout 정책을 따른다
Episode Character 연결 10개 초과	Soul 1개당 Episode Character 최대 10개까지만 허용. 초과 선택/적용은 차단하고 기존 연결 해제 또는 다른 Soul 선택을 안내한다
Episode Character 중복 연결	Episode Character 1개는 동시에 여러 Soul에 연결할 수 없다. 이미 다른 Soul이 점유한 경우 충돌 안내 후 연결을 차단한다
Soul 설정 자동 저장 후 미적용	Studio draft 상태로 보존. 유저-facing Chat에는 마지막 active 설정 유지
Soul 설정 적용 실패	자동 저장본은 유지. 유저-facing Chat에는 마지막 active 설정 유지 + Studio toast/error 노출
적용 중 이미 시작된 Chat generation	이미 시작된 generation에는 새 설정을 소급 반영하지 않음. [적용] 성공 이후 시작되는 다음 generation부터 최신 active Soul settings 사용
디렉터가 [소울 관리]에서 Soul을 비공개/삭제	기존 채팅방과 이전 대화 기록은 보존. 입력창 비활성화 + placeholder 안내

---

5. 데이터 분석

5.1 핵심 지표

1. Chat 진입율 — 메인 (§1.5).
2. Chat 재방문율 (WoW) — 메인 (§1.5).
3. 유료 스타 결제 메시지 비율 — BM 가설.
4. 메시지당 LLM 응답 비용 — 가드레일.
5. 일일 무료 스타 발급 비용 — 가드레일 (무료 사용 흡수 비용).
6. "최근 기억 불러오기" 사용율 — 메모리 surface 효용 확인.

5.2 로깅 이벤트

컨벤션: snake_case, 동사_명사. 기존 그룹·이벤트 재사용 우선. 신규는 "상태" 열에 🆕.

spec 진입 전 PM 세션에서 event-docs.frontia.dev의 기존 메시지/채팅/알림 관련 그룹과 매핑을 확정하고 본 표를 갱신한다(§7).

타입	이름	용도	파라미터	그룹	상태
Event	view_chat_tab	Chat 메뉴 진입	source(bottom_tab / push / deeplink / etc)	chat	🆕 신규
Event	view_chat_thread	채팅방 화면 진입	soul_id, character_id?, source(chat_menu / episode_detail / push / deeplink / etc)	chat	🆕 신규
Event	click_chat_start	"대화하기" 등 Chat 시작 클릭	soul_id, character_id?, entry_source(chat_menu / episode_detail / etc), is_first_thread(bool), episode_id(nullable)	chat	🆕 신규
Event	send_chat_message	유저 텍스트 bubble 전송	thread_id, soul_id, bubble_id, text_length	chat	🆕 신규
Event	send_chat_photo	유저 사진 bubble 전송	thread_id, soul_id, bubble_id	chat	🆕 신규
Event	complete_chat_generation	generation 성공 완료 및 스타 차감	thread_id, soul_id, generation_id, input_bubble_count, output_bubble_count, star_cost, response_latency_ms	chat	🆕 신규
Event	edit_chat_persona	User Relational Persona 편집 저장	thread_id, soul_id	chat	🆕 신규
Event	toggle_chat_proactive_message_receive	캐릭터 선톡/먼저 말 걸기 수신 설정 토글	soul_id(nullable, 전역 토글이면 null), character_id?, to_state(on / off)	chat	🆕 신규

관계 Exp 적재 source는 DEE-71 기준 chat_response_generated로 정렬한다. complete_chat_generation 직후/동일 트랜잭션에서 실제 star 차감값을 기준으로 적재하며, 이벤트명/페이로드는 DEE-71과 event-docs 매핑에 맞춘다. 개인화 선톡은 유저 측 수신 성공 시 star가 차감되면 DEE-71의 별도 source(personalized_proactive_message_received)로 적재한다. 선톡 생성·발송 관련 상세 이벤트는 DEE-131에서 정의.

---

6. Ubiquitous Language

Term	Korean	Definition	Do Not Confuse With	Primary Domain	상태
Soul	소울	Studio에서 디렉터가 만들고 운영하는 Chat/도메인 entity. Chat 대화의 상대로서 (user, Soul) 단위로 Thread·Bond를 갖는다. 에피소드 Character와 optional하게 매핑될 수 있으며, 연결된 Character가 0개여도 생성/적용 가능하고 최대 10개까지 연결 가능하다. 설정은 자동 저장 후 [적용] 액션으로 active settings가 갱신되고 Chat에 라이브 반영된다. UI 라벨과 도메인 term 모두 Soul/Soul Management 기준.	에피소드 내 등장 인물 Character, 유저 계정 프로필	Chat / Studio (신규 도메인)	신규
Character	캐릭터	에피소드 콘텐츠·플레이에 등장하는 이야기 속 인물. Chat 도메인에서는 Soul과 매핑되는 episode-internal entity. Episode Character 1개는 동시에 여러 Soul에 연결될 수 없다. 사용자 노출 표현 "캐릭터와 대화"는 자연 카피로 유지되며, 도메인 모델상 대화 상대는 Soul.	Soul(위), 유저 프로필	Episode Content	기존
Chat Thread	채팅방 / 채팅방	(user, Soul) 쌍에 대한 단 하나의 글로벌 1:1 대화 entity. 사용자에게는 "채팅방" 또는 "채팅방"으로 노출되고, 시스템/도메인 언어로는 "Chat Thread"로 부른다. 에피소드와 무관하게 합쳐지는 persistent entity이며, 이번 MVP에서는 나가기/삭제되지 않는다.	에피소드별 스레드(채택 안 됨), 단톡(범위 외), 삭제 가능한 임시 채팅방	Messenger (신규 도메인)	신규
Chat Bubble	말풍선 / bubble	유저에게 보이는 1개의 UI 송수신 단위. 유저는 전송 1회당 1개의 bubble을 만들며, 한 generation의 응답은 1개 또는 여러 개의 Soul bubble로 렌더링될 수 있다. 페이로드 = 텍스트 또는 사진.	Generation Unit(아래), 에피소드 내 turn/scene/frame	Messenger	신규
Chat Generation Unit	Chat 생성 단위	LLM 생성 호출 1회의 입출력 단위. 여러 개의 유저 bubble이 1초 비활성 정책에 따라 하나의 generation input으로 묶인다. 1 generation = 1 차감 단위(성공 시에만 차감). input/output에서 bubble 경계는 명시 delimiter로 보존된다.	Chat Bubble(위)	Messenger	신규
Bond / Bond Exp / Bond Level	관계 / 관계 Lv / Exp	(user, Soul) 단위 누적 친밀 정도. episode 소스(scene 등장)와 Chat 소스(응답 생성)를 aggregate하여 산출한다. 도메인 top-level term은 Character-only가 아닌 Bond. 유저 노출 문구는 "관계 Lv.N + Exp progress". raw score/숫자는 유저에게 노출하지 않는다. UI 노출 조건: Chat Thread가 생성/연결된 (user, Soul)에서만. 데이터·매핑은 DEE-71.	전역 유저 레벨/경험치, Character-only 친밀도	Chat / Relationship	신규
User Relational Persona	User Relational Persona / 대화 프로필	특정 (user, Soul) Chat Thread에 적용되는 유저 측 대화 프로필. Chat 시작 시 자동 생성되고 유저가 편집 가능. 다른 Soul/Thread의 User Relational Persona에 영향 없음. Play Profile이 play 컨텍스트에 적용되듯, User Relational Persona은 Chat Thread 컨텍스트에 적용. 이전 표기 "User Relational Persona / 유저 페르소나"를 본 PRD에서 정렬.	전역 계정 프로필, Soul Messenger Bio, Soul Prompt(아래)	Messenger	신규
Soul Messenger Bio	소울 메신저 바이오	Studio [소울 관리]에서 디렉터가 작성하는 Soul의 메신저 표시 정보. 표시명 + 상태 메시지로 구성되며, 채팅 프롬프트(Chat v6)의 durable slot soul_messenger_bio로 주입된다. 채팅 surface에서는 Soul Chat Profile의 텍스트 파트로 표시된다.	Soul Chat Profile(이미지/background 포함 UI 표시 프로필), Soul Prompt(성격/응답 instruction)	Studio / Chat	신규
Soul Prompt	소울 프롬프트 / 캐릭터 프롬프트	디렉터가 Studio [소울 관리] / Soul Management에서 입력하는 Soul 측 톤/성격/응답 instruction. 소울 정보가 soul_default_persona source이며, 채팅 상황 설정은 Soul Prompt가 아니라 선택형 첫 Chat의 chat_initial_situation context로 합성된다. 첫 요약 이후에는 같은 위치를 recent_context가 대체한다.	User Relational Persona(유저 측), Soul Messenger Bio, 채팅 상황 설정, 에피소드 캐릭터성 설정	Studio / Chat	신규
Recent Memory Load	최근 기억 불러오기	채팅방 우상단 햄버거 메뉴에서 사용자가 명시적으로 호출하는 동작. 그 시점 기준 최신 에피소드 메모리를 Soul에게 반영. 스타 소모.	Chat 시작 시 초기 메모리 로딩(자동, 무료)	Messenger / Play	신규
Soul Management (Studio)	소울 관리 (UI 라벨) / Soul Management (functional/도메인 term)	스튜디오의 [소울 관리] 탭. [에피소드 관리]와 동일 위계. 디렉터가 Soul을 만들고 optional하게 episode Character와 연결하며 프로필 이미지·표시명·상태 메시지·Soul Prompt를 관리한다. Soul 설정은 자동 저장되고 [적용] 액션 후 Chat에 라이브 반영된다. UI 라벨은 [소울 관리]로 확정, 도메인 term은 Soul Management.	에피소드 안의 등장 Character 메타	Studio / Messenger	신규

---

7. Open Questions

• [x] Chat generation 1회당 스타 단가 — 성공 완료/노출 가능 시점에 10스타 차감으로 확정. — PM(momo).
• [ ] 메모리 업데이트 스타 단가 M — 메모리/모델 비용 리서치 후 확정. — PM + 모델 담당.
• [ ] 신규 딥링크 path 2개 (/chat, /chat/character/:characterId) — 엔지니어 확정 후 DeepLink 노션 doc + §3-3 표 반영. — 엔지니어.
• [ ] 로깅 이벤트 그룹 / 재사용 매핑 — event-docs.frontia.dev의 기존 메시지/채팅/알림 그룹에서 재사용 가능한 항목 매핑. 관계 Exp 소스 B 이벤트와의 발화 순서 정렬. — PM (Cloudflare Access 세션).
• [ ] DEE-131(선톡)과의 sequencing — 본 PRD ship 시점에 DEE-131이 ship 되지 않은 경우, 선톡 더 자주 받기 추가 빈도 설정의 표시/동작 degrade 방식(예: 토글 비활성·"준비 중" 안내). — PM + DEE-131 담당.
• [ ] 캐릭터 → 유저 사진 전송의 실 생성 방법 (후속 enhancement 진입 시) — 모델 생성 vs 디렉터 업로드 자산 vs 혼합. 본 PRD MVP는 구조만. — PM + 디렉터 운영팀.
• [ ] User Relational Persona 자동 생성의 입력 소스 — 에피소드 플레이 히스토리 / 기존 활동 / Soul 캐릭터성 등 어떤 신호를 기반으로 초안을 만들지. — PM + 모델 담당.

---

부록: 메타 정보

Required artifacts

• [x] Spec (needs-spec) — Chat 메뉴·채팅방·진입점 컴포넌트 명세, bubble/generation unit 분리, 1초 비활성 generation 정책, 메신저 호흡 연출(읽음 1/타이핑/도착 타이밍), 빌링 성공 시점 차감·실패 미차감 흐름, "최근 기억 불러오기" UX, User Relational Persona 편집 UX, 사진 송수신 UX, 선톡 더 자주 받기 자리, 스튜디오 [소울 관리] (Soul Management, Soul Prompt 포함) 화면, unread 모델, human-like 푸시 페이로드.
• [x] Design (needs-design) — Figma: Chat 메뉴, 채팅방 리스트, 채팅방 화면(헤더·말풍선·읽음 1·타이핑·첫 소비 바텀시트·메모리 불러오기 버튼·User Relational Persona 편집·사진 송수신), 캐릭터 프로필 상세(관계 Lv/Exp progress — Chat 연결 시), 캐릭터 추천 빈 상태, 스튜디오 [소울 관리] 탭(Soul Prompt 입력 포함).
• [ ] QA scenarios (needs-qa-scenarios) — Sprint planning에서 작성.
• [x] Migration plan (needs-migration) — 신규 Chat 도메인 테이블(Chat Thread/메시지/사진/메모리/User Relational Persona), 스튜디오 Soul 엔티티(프로필 메타 + Soul Prompt + episode Character 매핑). 초기 backfill 없음(lazy create).
• [x] Tracking events (needs-tracking) — §5.2.

Size & Risks

• Size: L
• Confidence: medium
• 추정 근거: 신규 도메인(메신저) + 신규 surface(Chat 메뉴) + 스튜디오 신규 탭([소울 관리] / Soul Management) + LLM 응답·결제·메모리·User Relational Persona·사진·푸시·Bond Lv/Exp·DEE-131(선톡) 인접 영역 다수.

주요 위험 요소

위험	영향	대응
LLM 응답 비용이 예상 초과	BM 가드레일 악화	메시지 단위 비용 적재 + 단가 K를 출시 직전 데이터로 조정
무료 스타 발급 비용 증가	BM 가드레일 악화	일일 무료 스타 발급 비용 가드레일 모니터링 + 단가 K/M 재조정
"최근 기억 불러오기"가 헷갈리거나 비용 인지 부족	CS 이슈, 환불 요청	클릭 전 비용·효과 사전 안내 강제, 라벨/문구 정확성 검토
캐릭터 → 유저 사진 구조만 깔고 실 사진은 없음	사용자 기대치 mismatch	MVP는 능력 노출 최소화, 실 사진은 후속 enhancement에서 점진적 활성화
스튜디오 [소울 관리] 데이터와 에피소드 캐릭터 연결 충돌	캐릭터 메타 불일치	연결 모델·라이브 반영 규칙을 spec에서 명확화, 충돌 시 마지막 저장 우선

의존성

• DEE-71 (관계 레벨 / Bond 체계): 본 PRD는 Chat 소스(chat_response_generated) 이벤트 발화자이며, 관계 Lv/Exp progress는 Chat 헤더가 아니라 캐릭터 프로필 상세에서 노출한다. 에피소드 상세 Episode Character 정보 섹션도 linked Soul 조건으로 관계 Lv/progress를 노출할 수 있다.
• DEE-131 (선톡 / 캐릭터 발신 시작): 선톡 생성·발송 정책 owner. 본 PRD는 선톡 더 자주 받기(유료 추가 빈도) surface만 책임.
• DEE-66/79 (에피소드 상세): Chat 진입점 제공.
• 알림 종류 on/off + 알림센터: Chat 알림 항목 추가 자리.
• 스타 상점 / 결제 SDK: 기존 재화·결제 통로 재사용.
• LLM 응답 가드(기존): 안전 정책 재사용.

References

• Linear:
  • DEE-71 [앱] 관계 레벨 / Bond 체계 — Chat 응답 생성 소스
  • DEE-131 선톡 (캐릭터 발신 시작) — 선톡 정책 owner
  • DEE-66 / DEE-79 에피소드 상세 — Chat 진입점
• Frontia UL wiki: wiki/foundation/ubiquitous-language.md — Character, Episode, Play, Credit(스타) 정의
• 외부 레퍼런스:
  • Instagram DM — 가벼운 Chat surface·진입 느낌(메신저 탭·채팅방 리스트 톤).
  • 카카오톡 — 메시지 교환 호흡(읽음 상태·타이핑·말풍선·시간 표시·실시간감).

prd-review 보기

PRD Review — [앱] Chat 메신저 기능

Linear Project: [앱] Chat 메신저 기능 (8aea9b7ef906) / DEE-72 Reviewed: 2026-05-15 Reviewer: agent (momo) Linked PRD: ./PRD.md

---

2026-05-15 PM direction alignment

본 PRD가 반영한 PM 방향(2026-05-15):

• 이니셔티브 위치: "캐릭터 관계/메신저 경험 기반 구축"의 첫 surface. 완성된 관계 시스템이 아니라 foundation.
• MVP 목적: 유저가 캐릭터와 1:1 Chat에 진입하고 계속 대화하는가의 빠른 검증. surface 가설(진입 + 체류)에 집중.
• scope 균형: Chat MVP는 검증 흐름을 막지 않는 선에서 작게. 관계 효과 layer(선톡·톤 변화·잠금해제)는 본 PRD 범위 외.
• MVP에 포함: 신고/차단 + 무료 일일 한도 + 스타 결제 = 본 PRD에 policy 형태로 함께. 별 PRD로 분리하지 않는다.
• DEE-115와의 관계: 메모리/컨텍스트의 철학·정책은 DEE-115가 owner. 본 PRD는 integration contract + UX surface(컨텍스트 칩) 만 정의하고 정책 결정은 DEE-115로 미룬다.
• 확장성 원칙: thread identity / 메시지·도메인 이벤트 / 빌링 / 안전 / 컨텍스트 참조의 raw 데이터는 후속 정책 변경 시 데이터 리셋 없이 진화 가능해야 함. seed의 가정(1:1 only, 무료/스타 하이브리드 등)은 정책으로만 박고 데이터 모델은 흔들 여지를 남긴다.

본 PRD는 위 방향을 §1.2 근거, §1.3 채택 근거, §3-1 룰, §3-4 Scope, §6 위험표/의존성에 반영했다.

---

Review-driven 주요 변경

1. §1.5 메인 지표 = 진입율 + 재방문율 둘 다. 재방문율 단독이면 분모(진입자) 작아질 때 surface 실패 신호를 가린다. surface 가설은 진입·체류의 conjunction이므로 두 지표 모두 메인.
2. §3-1 컨텍스트 칩 degrade ship 정책 명시. DEE-115가 늦어지면 칩을 "현재 에피소드 컨텍스트(= 마지막 클리어 에피소드)" 단일 상태로 degrade ship, 토글은 비활성. DEE-115 ship 시 활성화.
3. §3-1 잔량 노출 = 항상 노출. BM 가설 검증을 위해 의식적 시그널 필요. 위치·문구만 spec.
4. §3-1 친밀도 매핑은 DEE-71 결정으로 위임. 본 PRD는 소스 B 이벤트 발화만 책임. "+1" 같은 수치는 PRD에서 빼고 DEE-71로 넘김.
5. §3-3 백엔드/시스템 섹션 삭제. 확장성 요구는 §3-4 Scope의 라인 하나로 통합. 구현 구조는 spec 책임.
6. §5.2 재사용 매핑 책임 명확화. "spec 진입 전 PM 세션에서 event-docs 매핑 확정"으로 PRD가 책임을 지고, §7 OQ에 spec 게이트로 보존.
7. §7 Open Questions 정리. 디자인·spec 결정 사항(타이핑 수식, 읽음/안읽음, 어드민 운영 흐름, 임계+베이스라인 운영 의례)을 제거하고, 실제 PM 결정으로만 남김.
8. 부록 위험표 정리. degrade ship 정책은 §3-1로 옮기고, 위험표엔 LLM 비용·안전 회귀·DEE-66/79 미ship 진입율 분모 부재만 유지.

---

Remaining PM decisions

본 PRD가 spec/design 단계로 넘어가기 전 PM(momo)이 결정해야 할 사항. 본 PRD §7 Open Questions와 동기.

• 무료 일일 N건: 한도 수치. BM 가설 임계 + LLM 비용 가드레일과 맞물림.
• 스타 단가 K: 메시지/응답/턴 중 어느 단위로 차감할지 + 1건당 K 스타. 묶음 결제(예: 10건 패키지) 포함 여부.
• BM 실차감 vs CTA-only MVP: BM 가설이 "0이 아님 시그널 확인"이라면 실차감을 후속으로 미루는 옵션 존재. 현재 PRD는 실차감 포함이지만 OQ로 재고 여지.
• 타이핑 인디케이터 노출·딜레이 수식: 메신저감 vs 응답 비용 가시화 vs 대기 인내심의 trade-off. spec에서 확정 (디자이너와).
• 미디어 송수신 범위: 현재 PRD는 텍스트 only로 out-of-scope. 이미지/오디오/비디오/이모지 reaction 중 어디까지 후속에 포함할지 큐 관리.
• 푸시 / 읽음·안읽음 정책: 읽음 모델(thread 단위 vs message 단위), 푸시 read receipt 연동, 푸시 발송 timing(즉시 vs 묶음). 일부 spec 결정, 일부 PM 결정.
• 신고/차단 edge policy: 신고 즉시 숨김의 reversibility, 차단된 캐릭터의 스레드 기록 보존 기간, 같은 캐릭터의 다른 작품 재만남 시 차단 적용 범위.
• Chat rollout / 대화 가능 캐릭터 범위: 전 캐릭터 일괄 ship vs 작품/캐릭터 단위 단계 rollout. 디렉터 설정(대화 허용/거부) 필요 여부.
• DEE-115 ship 후 컨텍스트 칩 카피·기본값 변경 흐름: DEE-115 정책이 굳어지면 칩의 default 컨텍스트·전환 시 안내 카피·메모리 영향 안내 문구. DEE-115 spec/디자인 단계와 동기화.
• 로깅 이벤트 재사용 매핑: event-docs.frontia.dev 기존 그룹과 §5.2 표 매핑 확정. spec 진입 전.
• 신규 딥링크 path 2개 확정: /chat, /chat/character/:characterId. 엔지니어 확정 후 DeepLink 노션 doc + §3-3 표 반영.
• §1.5 임계·베이스라인 수치: 정책은 PRD에서 결정 완료, 베이스라인은 출시 직전 momo + 데이터 agent.

---

Out of scope (재확인)

본 PRD가 의도적으로 다루지 않는 항목. 후속 PRD 큐에서 추적.

• 선톡(캐릭터 발신 시작), 톤 변화, 잠금해제 등 친밀도 기반 관계 효과 layer.
• 메모리/컨텍스트 정책 결정 자체 → DEE-115.
• 단톡(그룹 채팅), 미디어 송수신.
• Chat → 에피소드 메모리 역방향 반영.
• 결제 funnel 최적화·번들·프로모션·구독.
• 어드민 신규 화면 (기존 신고/차단 도구 재사용).
• 다른 surface 진입점 확장(캐릭터 카드, MY 탭 등).

2026-05-20 Soul/Character terminology update

• Chat counterpart/domain entity를 Soul로 정렬하고 Episode Character와 분리.
• User Relational Persona은 (user, Soul) Thread별 유저 측 대화 프로필로 정의, Soul Prompt와 분리.
• Bond/Bond Exp/Bond Level은 (user, Soul) aggregate 기준, Chat Thread 연결 시에만 노출.
• Chat 응답 푸시는 human-like messenger push 원칙(title=Soul/character display name, body=snippet) 추가.

2026-05-20 Soul apply model update

• Soul은 Episode Character 연결 없이도 먼저 생성/자동 저장/[적용] 가능하도록 정책 명시.
• Soul 설정은 자동 저장 후 [적용] 성공 이후 시작되는 다음 Chat generation부터 active settings로 반영.
• 에피소드 발행/플레이 스냅샷 모델과 달리 Chat은 active Soul settings를 라이브 참조하는 모델로 정렬.