Appearance
다중 프롤로그 및 플레이 전 프롤로그 선택 PRD
Backlog grooming 단계의 산출물. 무엇을 만들지·왜 만들지·핵심 비즈니스 룰을 정의한다. 화면별 디테일(컴포넌트·상태·인터랙션)은 spec.md로.
Status: draft Created: 2026-07-10 Last updated: 2026-07-10 Linear Project: 다중 프롤로그 및 플레이 전 프롤로그 선택 (Triage 파생: DEE-700) Author: agent (prd-writer) / momo 앱/웹/스튜디오: 앱(플레이 진입) + 스튜디오(다중 프롤로그 저작·대표 지정)
Reversal Risk Summary
이 PRD에서 어떤 레이어를 출시 전 신중하게 픽스해야 하는지 빠르게 판단하기 위한 요약. 모든 세부 결정에 R등급을 붙이지 않는다.
| Layer | R-level | Review focus |
|---|---|---|
| Policy / Rule | R2 | 프롤로그 최대 5개·publish "1~5개"·대표 프롤로그 필수 룰 — 출시 후 되돌릴 수 있으나 저작/발행 검증·기존 콘텐츠에 영향 |
| Data / Backend | R2 | 대표 프롤로그 식별 필드 도입 + 선택된 프롤로그 저장/로그. backfill이 대규모 migration으로 판명되면 R3로 승격 (§7·🔍) |
| User-facing Surface | R1 | 에피소드 상세 드롭다운 위치·스튜디오 저작 UI — 출시 후 조정 가능 |
| Copy / Visual Presentation | R1 | 드롭다운 문구·프롤로그 제목 표시·[대표로 지정] 버튼 표현 — 조정 가능 |
1. 목표 및 배경
1.1 문제
- 사용자 정의: (1) 플레이어 = 에피소드를 플레이하려는 모든 유저(로그인 진입자). (2) 디렉터 = 에피소드를 저작하는 상위 제작자(스튜디오 사용자).
- 상황: 플레이어가 에피소드 상세에서 플레이를 시작할 때, 그리고 디렉터가 스튜디오에서 에피소드 도입부(프롤로그)를 저작할 때.
- 불편 / 충족되지 않은 요구: 에피소드의 첫 경험인 프롤로그가 에피소드당 1개로 고정돼 있다. 디렉터는 서로 다른 도입(다른 관계 설정·상황·톤)을 하나의 에피소드로 제공할 수단이 없고, 플레이어는 자기 취향의 첫 장면을 고를 수 없어 진입 경험이 획일적이다.
1.2 근거
- 선행 방향:
deployed/2026-03-05_프롤로그와 전체 이벤트 공간 분리 PRD.md— 프롤로그를 전체 이벤트 공간과 분리해 "첫 메시지만으로 에피소드 성립"하게 한 건. "프롤로그 = 진입 단위" 개념이 이미 확립돼 있어, 그 진입 단위를 복수로 여는 자연스러운 확장이다. - 관련 진행 건: DEE-506
new-user-prologue-funnel(배포) — 비인증 프롤로그 미리보기 퍼널이 이미 프롤로그를 진입 hook으로 쓰고 있다. 다중화 시 미리보기 대상 정책이 파생된다(§3-1 대표 프롤로그). - feasibility: BE/FE 모두 "구현 가능하나 단순 limit 변경 아님, PRD/spec 필요" 의견(Agent Feasibility 스레드). 저장 모델 신규 구축은 불필요하다고 봄.
1.3 해결 방향
- 선택형 — 유저가 플레이 시작 전 에피소드 상세에서 어떤 프롤로그로 진입할지 직접 고른다. (요청자 확정)
- 진입 UI는 에피소드 상세 페이지의 프롤로그 선택 드롭다운(등장 캐릭터와 대표 댓글 사이). 별도 선택 화면/퍼널을 만들지 않는다 — 프롤로그가 1개인 에피소드도 스킵 로직 없이 자연히 동일 동작.
- 조건형(플레이어 상태에 따라 자동 분기)은 이번 범위의 non-goal.
1.4 가설
- 플레이어가 취향에 맞는 도입을 고를 수 있으면 first-play 진입 후 몰입·지속이 높아진다. (측정: 선택 프롤로그별 씬 도달률 — 참고 지표)
- 디렉터가 한 에피소드로 여러 도입을 제공할 수 있으면 에피소드당 저작 표현력이 늘어 콘텐츠 다양성이 커진다. (측정: 프롤로그 선택 분포 + 대표 외 지정률)
- 진입 다양성이 first-play 전환에 긍정적으로 작용한다. (측정: 같은 에피소드 다중화 전/후 전환 — 참고 지표)
1.5 성공 지표
| 지표 | 현재 | 목표 | 측정 방법 |
|---|---|---|---|
| 프롤로그 선택 분포 | — (신규) | 측정 시작 | 프롤로그 선택 로그 / 다중 프롤로그 에피소드 진입 (self-selection 없는 축) |
| 같은 에피소드 다중화 전/후 first-play 전환 | 기준선 확보 | 다중화 후 개선 | 다중화 전/후 동일 에피소드 전환 비교 (참고 지표) |
| 다중 프롤로그 first-play 후 N씬 도달률 | — (신규) | 측정 시작 | 선택 프롤로그별 첫 세션 씬 진행 (참고 지표) |
- 메인 지표: 프롤로그 선택 분포 — 가설 2·3(진입 다양성 활용)을 self-selection bias 없이 검증.
- 가드레일 지표: 단일 프롤로그 에피소드의 진입 전환(회귀 없음), 기존 published 에피소드 play 정상 동작.
- 참고 지표: 같은 에피소드 다중화 전/후 first-play 전환(가설 3), 선택 프롤로그별 first-play 후 씬 도달률(가설 1 몰입·지속). 다중 vs 단일 에피소드 비교는 콘텐츠 자체가 달라(디렉터 자발 저작) self-selection bias가 있으므로 판정 축으로 쓰지 않는다.
2. 타깃 사용자
2.1 주요 사용자
- 플레이어: 에피소드를 플레이하려는 로그인 유저. 에피소드 상세에서 플레이 시작 시 프롤로그 드롭다운을 만난다(다중일 때).
- 디렉터: 스튜디오에서 에피소드를 저작하는 유저. 프롤로그를 여러 개 만들고 대표를 지정한다.
- 비인증 방문자(간접): 프롤로그 미리보기 퍼널에서 대표 프롤로그를 본다.
2.2 핵심 시나리오
- 디렉터가 에피소드에 도입부 A(첫 만남)·B(오래된 연인)를 각각 프롤로그로 만들고, 그중 하나를 대표로 지정해 발행한다.
- 플레이어가 에피소드 상세에서 프롤로그 드롭다운으로 A/B 중 하나를 고르고 플레이를 시작하면, 고른 프롤로그로 첫 씬이 시작된다.
- 프롤로그가 1개인 에피소드(기존 published 포함)는 드롭다운에 별도 선택지가 없어 기존과 동일하게 진입한다.
3. 핵심 기능 요구사항
3-0. 정책 변경 요약 (As-is → To-be)
As-is는 frontia-wiki(
episode-authoring/capabilities.md,play/capabilities.md,studio-authoring-editor.md)에서 검증.
| 영역 | As-is | To-be | R-level | 비고/근거 위치 |
|---|---|---|---|---|
| 프롤로그 개수 | 에피소드당 정확히 1개 | 에피소드당 1~5개 | R2 | §3-1 디렉터 저작 / Reversal Risk |
| Publish 검증 | 프롤로그 "정확히 1개" 요구 | 프롤로그 "1개 이상 5개 이하" 통과 (기존 1개 에피소드 그대로 통과) | R2 | §3-1 저작 |
| 대표 프롤로그 | 개념 없음 (프롤로그가 곧 유일) | 대표 프롤로그 정확히 1개 필수 — default 생성분이 최초 대표, 변경 가능 | R2 | §3-1 대표 지정 |
| 플레이 첫 씬 진입 | 유일 프롤로그로 자동 첫 씬 | 선택된 프롤로그로 첫 씬 (단일이면 그 프롤로그로 자동) | R2 | §3-1 플레이 진입 |
| 프롤로그 미리보기(비인증) | 최신 snapshot 프롤로그(단수) 렌더 | 대표 프롤로그 1개 렌더 | R1 | §3-1 대표 프롤로그 |
- 이 표의 R-level은 상단 Reversal Risk Summary와 정합.
- 화면 컴포넌트 변화(드롭다운 형태·노드 배치 등)는 spec의 일.
3-1. 클라이언트 (앱/스튜디오)
다중 프롤로그 저작 (스튜디오)
- 목적: 디렉터가 한 에피소드에 여러 도입을 프롤로그로 제공할 수 있게 한다.
- 주요 동작: 디렉터는 스튜디오 이벤트 만들기(+)에서 프롤로그를 추가하고, 각 프롤로그를 편집·삭제할 수 있다.
- 비즈니스 룰:
- 한 에피소드의 프롤로그는 최소 1개, 최대 5개. Publish 검증은 이 범위를 만족하면 통과하며, 기존 프롤로그 1개 에피소드는 그대로 통과한다(하위호환).
- 이벤트 그래프에서 프롤로그는 기존 프롤로그 노드에서 아래로 이어져 배치된다(별도 레인/그룹 노드가 아니라 프롤로그 노드가 적층되는 형태). 프롤로그는 항상 시작점 성격이며 다른 이벤트의
toEvent가 되지 않는다(As-is 유지).
- 상태별 동작 (유저가 보는 결과):
- 프롤로그 1개: 기존과 동일한 단건 저작 경험.
- 프롤로그 5개: 추가 버튼 비활성/차단(6개째 생성 불가).
대표 프롤로그 지정 (스튜디오)
- 목적: 다중 프롤로그 중 에피소드를 대표하는 도입을 한정한다 — 미리보기·프롤로그 탭 등 "1개만 보여야 하는" 자리의 기준.
- 주요 동작: 디렉터가 프롤로그 설정에서 특정 프롤로그를 대표로 지정한다.
- 비즈니스 룰:
- 에피소드에는 항상 대표 프롤로그가 정확히 1개 존재한다(필수값 — 없을 수 없음).
- 프롤로그가 default로 하나 생성되며, 그 프롤로그가 최초 대표다.
- 프롤로그 설정 안에 [대표로 지정] 버튼이 있다. 해당 프롤로그가 이미 대표이면 버튼 비활성화. 대표가 아닌 프롤로그에서 누르면 그 프롤로그가 대표가 되고, 이전 대표는 해제된다(대표는 언제나 1개).
- 대표 여부는 이벤트 노드에서도 확인 가능하다.
- 스튜디오 웹의 프롤로그 탭에 표시되는 프롤로그 내용은 대표 프롤로그다.
- 상태별 동작:
- 프롤로그 1개: 그 프롤로그가 대표이고 [대표로 지정] 버튼은 비활성.
플레이 전 프롤로그 선택 (앱)
- 목적: 플레이어가 자기 취향의 도입으로 진입할 수 있게 한다.
- 주요 동작: 플레이어가 에피소드 상세에서 프롤로그를 고르고 플레이를 시작한다.
- 비즈니스 룰:
- 선택 UI는 에피소드 상세 페이지의 프롤로그 선택 드롭다운이며, 위치는 등장 캐릭터와 대표 댓글 사이다.
- 드롭다운 항목에 표시하는 필드는 프롤로그 제목만.
- 나열 순서는 대표 프롤로그가 최상단(기본 선택값과 일치)이고, 나머지는 디렉터 저작 순서를 따른다.
- 선택된 프롤로그로 첫 씬이 생성된다 — 첫 씬은 user input 없는 프롤로그로 시작하며 credit 차감/paid-turn 대상이 아니다(As-is 유지).
- DEE-399 "플레이 전 플레이 프로필 선택"과는 별개 플로우다(같은 화면으로 통합하지 않는다).
- 상태별 동작 (유저가 보는 결과):
- 프롤로그 2~5개: 드롭다운에서 선택 → 선택분으로 첫 씬 시작.
- 프롤로그 1개(기존 published 포함): 선택지가 하나뿐이라 별도 선택 없이 기존과 동일하게 진입(회귀 없음).
- 드롭다운 미조작 시 기본 선택값 = 대표 프롤로그(⚠️ 추정 — §7).
3-5. Scope
포함 (In scope)
- 디렉터의 다중 프롤로그(1~5) 저작·편집·삭제 + 대표 프롤로그 지정.
- 플레이어의 에피소드 상세 드롭다운 프롤로그 선택 → 선택분으로 첫 씬 진입.
- Publish 검증 변경(1~5) + 기존 published 하위호환.
- 비인증 미리보기 대표 프롤로그 렌더.
제외 (Out of scope)
- 프롤로그별 서로 다른 이벤트 트리/엔딩으로의 분기.
- 엔딩 구조 변경, 이벤트/엔딩 한도 상향(DEE-231).
- 조건형 자동 분기(플레이어 상태에 따른 프롤로그 자동 선택).
- DEE-399 플레이 프로필 선택과의 화면 통합.
- 드롭다운 항목에 제목 외 메타(요약/썸네일) 노출.
4. 에러 처리 및 예외 상황
| 상황 | 처리 방향 |
|---|---|
| 프롤로그 0개 상태로 발행 시도 | 기존 정책대로 발행 차단(최소 1개 요구 유지) |
| 프롤로그 6개째 생성 시도 | 추가 차단 + 최대 5개 안내 |
| 대표 프롤로그 삭제 시도 | 대표는 필수이므로, 삭제 시 다른 프롤로그로 대표 이전 필요(처리 방식은 spec — §7) |
| 선택된 프롤로그가 진입 시점에 없음(삭제·비발행) | 안내 후 대표 프롤로그로 폴백 또는 재선택 유도(⚠️ 추정 — §7) |
| 네트워크 오류(선택 전달 실패) | 재시도 가능하게 |
5. 데이터 분석
5.1 핵심 지표
- 프롤로그 선택 분포(메인): 다중 프롤로그 에피소드에서 어떤 프롤로그가 얼마나 선택되는가 — 같은 에피소드 내 선택이라 self-selection bias 없음.
- 같은 에피소드 다중화 전/후 first-play 전환(참고): 동일 에피소드가 다중 프롤로그가 되기 전/후의 상세→플레이 전환 비교. 다중 vs 단일 에피소드 비교는 콘텐츠 편향 때문에 쓰지 않는다.
- 선택 프롤로그별 first-play 후 씬 도달률(참고): 가설 1(몰입·지속) 관찰용.
- 대표 프롤로그 지정 활용: 디렉터가 대표를 default 외로 변경하는 비율(저작 표현력 신호).
5.2 로깅 이벤트
컨벤션·기존 목록: https://event-docs.frontia.dev/ (Cloudflare Access). 기존
episode-player그룹 재사용 우선.
| 타입 | 이름 | 용도 | 파라미터 | 그룹 | 상태 |
|---|---|---|---|---|---|
| Event | select_prologue | 플레이어가 에피소드 상세 드롭다운에서 프롤로그를 선택 | episode_id, prologue_id, prologue_count | episode-player | 🆕 신규 |
| Event | view_prologue_select | 다중 프롤로그 드롭다운 노출 | episode_id, prologue_count | episode-player | 🆕 신규 |
6. Ubiquitous Language
| Term | Korean | Definition | Do Not Confuse With | Primary Domain | 상태 |
|---|---|---|---|---|---|
| Representative Prologue | 대표 프롤로그 | 다중 프롤로그 중 에피소드를 대표하는 프롤로그. 에피소드당 정확히 1개 필수. 미리보기·스튜디오 프롤로그 탭 등 "1개만 보이는" 자리의 기준 | (일반) Prologue — 대표는 그중 지정된 1개 | episode-authoring | 신규 |
| Prologue | 프롤로그 | 플레이 첫 메시지/초기 scene. 이벤트 구조 없이 episode를 성립시키는 기본 작성 단위 | Main/Sub 이벤트 | episode-authoring | 기존 |
7. Open Questions
- [ ] 선택값 API 위치 — play 생성 시점 vs 첫 scene 생성 시점 — 누구에게: 백집사(BE). 추천: play 생성 시점(진입 방향과 정합).
- [ ] 선택된 프롤로그 저장/로깅 정책 —
EpisodePlay명시 저장 vs 첫 sceneeventMetaId로만 추적 — 누구에게: 백집사(BE). 추천: 저장 또는 최소 이벤트 로그(선택률·전환 측정 필요). - [ ] 기존 published(프롤로그 1개) backfill 필요 여부 + 대표 필드 도입 시 기존 단일 프롤로그의 대표 처리 — 누구에게: 백집사(BE). 추천: backfill 불필요(단일=대표 간주). 대규모 migration이면 자동 Needs Decision.
- [ ] 대표 프롤로그 삭제 시 대표 이전 UX — 누구에게: 티모(FE)/디자이너. 추천: 삭제 전 다른 프롤로그를 대표로 지정하게 강제 or 삭제 시 자동 이전.
- [ ] 선택 프롤로그가 진입 시점에 사라진 경우 폴백 — 누구에게: 티모(FE)/백집사(BE). 추천: 대표 프롤로그로 폴백.
🔍 검토 필요
🚨 결정 필요 (큰 결정)
- 기존 published 에피소드 backfill 규모 — 단일 프롤로그를 대표로 간주하는 방식이 스키마상 backfill 없이 성립하는지 백집사 확인 전까지 미확정. 대규모 migration으로 판명되면 Data/Backend R2 → R3 승격 + 별도 싱크.
⚠️ 추정 (정보 부족하지만 진행)
- 선택 프롤로그 소실 시 대표 프롤로그 폴백으로 가정(§4) — 확정 필요.
- 성공 지표 방향성 조정(메인=선택 분포, 전환은 다중화 전/후 참고 지표)은 self-selection bias 회피 위한 agent 판단 — 요청자 확정 필요.
- 로깅 이벤트명(
select_prologue·view_prologue_select)·그룹(episode-player)은 컨벤션 기준 추정 — 기존 이벤트 재사용/정합 미확인. - 성공 지표 현재값 미확보 — 데이터 필요.
❓ 외부 agent 호출 필요
- 데이터 agent: 다중 프롤로그 대상 에피소드 규모, first-play 전환 기준선, 프롤로그 선택률 측정 셋업.
- 코드 agent(feasibility 확정은 백집사/티모):
EpisodePlay스키마에 프롤로그 선택 저장 가능 여부, 대표 프롤로그 식별 필드 도입 방식.
부록: 메타 정보
Required artifacts
- [x] Spec (
needs-spec) — 에피소드 상세 드롭다운·스튜디오 다중 프롤로그 저작·대표 지정 화면 명세 - [x] Design (
needs-design) — 드롭다운·[대표로 지정] 버튼·이벤트 노드 대표 표시 시안 - [x] QA scenarios (
needs-qa-scenarios) — 1/5/6개 경계·대표 전환·하위호환 - [ ] Migration plan (
needs-migration) — backfill 필요 판명 시 부착 - [x] Tracking events (
needs-tracking) —select_prologue등 신규 이벤트 - [ ] 기타:
Size & Risks
T-shirt Size
- Size: M
- Confidence: medium
- 추정 근거: 단일 프롤로그 전제가 생성 제한·publish 검증·단수 조회·첫 씬 생성·미리보기·이벤트 플로우·FE 상수 6~7개 지점에 박혀 있어 동시 변경. 단 저장 모델 신규 구축은 불필요(BE 의견).
주요 위험 요소
| 위험 | 영향 | 대응 |
|---|---|---|
| 기존 published 하위호환 깨짐 | 기존 에피소드 play 불가 | 단일=대표 간주로 backfill 최소화, 회귀 QA 필수 |
| 다중 시작점 그래프 검증 복잡화 | 스튜디오 저작 버그 | 프롤로그 노드 적층 형태로 범위 제한(별도 레인 아님) |
| 대표 필수 제약 위반(대표 0개 상태) | 미리보기·탭 렌더 실패 | 대표 삭제 시 이전 강제 + 최소 1 대표 불변식 |
의존성
- 다른 작업: DEE-399(플레이 프로필 선택) — 별개 플로우지만 같은 에피소드 상세/플레이 진입 구간이라 화면 정합 주의.
- 다른 팀: BE(백집사) API 계약·저장·하위호환 / FE(티모) 스튜디오 그래프·앱 드롭다운.
- 외부 요인: 없음.
References
- 관련 위키 문서:
wiki/domains/episode-authoring/capabilities.md,wiki/domains/play/capabilities.md,wiki/client/studio-authoring-editor.md - 관련 Linear 이슈: DEE-700(Triage 원문), DEE-399(플레이 프로필 선택), DEE-506(프롤로그 미리보기 퍼널), DEE-231(이벤트/엔딩 한도 — 별개)
- 관련 산출물:
draft/multi-prologue-select/requirement-packet.md(주 인풋),draft/prologue-play-profile-select/PRD.md,deployed/2026-03-05_프롤로그와 전체 이벤트 공간 분리 PRD.md
prd-review 보기
Review log
2026-07-10
자율 실행(요청자 미참여) — prd-reviewer 질문에 리뷰어 동봉 추천안을 채택해 반영. 모두 지표 정의·순서 규칙 수준의 R1 결정이며, 요청자가 뒤집을 수 있음(핸드오프 🔍에 명시).
채택
- Q: first-play 전환 "비열세"의 모집단 비교에 self-selection bias — 다중 프롤로그 에피소드는 디렉터 자발 저작이라 단일과 콘텐츠가 다름. 가설 3(긍정 작용)도 "비열세"로는 검증 불가.
- A(추천 채택): 메인 지표를 프롤로그 선택 분포(같은 에피소드 내 선택 → bias 없음)로. 전환은 같은 에피소드 다중화 전/후 참고 지표로 강등.
- → §1.5 지표 표·불릿 재작성, §5.1 재정렬
- Q: 가설 1 "몰입·지속"이 지표에 없음(측정 공백).
- A(추천 채택): 선택 프롤로그별 first-play 후 씬 도달률을 참고 지표로 추가. 가설 1~3에 측정 방법 병기.
- → §1.4 가설, §1.5, §5.1
- Q: 드롭다운 프롤로그 나열 순서 규칙 부재.
- A(추천 채택): 대표 최상단(기본 선택값 일치) + 나머지 디렉터 저작 순서.
- → §3-1 플레이 전 프롤로그 선택
청소 (일괄 적용)
- §3-3 백엔드/시스템 섹션 제거 — BE 설계 문구 + §3-0/§3-1/§7 중복(신규 정보 없음). publish·하위호환·미리보기는 §3-0·§3-1·Scope로, 선택값 전달·저장은 §7로 흡수.
- §1.5·§5.2 말미 nav ⚠️ 불릿 제거 (§🔍와 중복).
- §3-1 드롭다운 "제목만(요약·썸네일 없음)"의 negative spec 괄호 제거 — Scope 제외에 이미 있음.
- 부록 진행 패턴 "Pattern 1" 제거 — 공통 메타(SKILL 정의).
- §7·§🔍 "드롭다운 기본 선택값" 항목 제거 — §3-1에 확정 반영.
Skip
- 이미 §7·🔍에 명시된 BE 3건(API 위치·저장/로깅·backfill)·대표 삭제 UX·소실 폴백·로깅 재사용은 재질문 안 함(reviewer도 skip).
- 그래프 노드 적층 vs toEvent 불가 — §3-1이 이미 못 박음.
요청자 인라인 피드백 (criteria 후보)
- self-selection bias: 다중 vs 단일 "에피소드" 비교도 콘텐츠 자발 저작 편향이라는 케이스 — 기존 criteria "기능 본 vs 안 본"의 변주로 이미 커버되나, "콘텐츠 저작자 자발성" 축을 명시할 가치 있음.