Appearance
플레이 이벤트 맵 (앱) PRD
Backlog grooming 단계의 산출물. 무엇을 만들지·왜 만들지·핵심 비즈니스 룰을 정의한다. 화면별 디테일(컴포넌트·상태·인터랙션)은 spec.md로.
Status: draft Created: 2026-06-22 Last updated: 2026-07-01 Linear Project: DEE-343 [앱] 플레이 이벤트 맵 (issue) Author: prd-writer (agent) / Dreamy update from Zen source 앱/웹/스튜디오: 앱
0. Reversal Risk Summary
| Layer | R-level | Review focus |
|---|---|---|
| Policy / Rule | R2 | 에피소드 상세과 플레이의 목적·데이터 기준·카운트 표현이 다르다. 출시 전 고정 필요 |
| Data / Backend | R2 | 최신 스냅샷, 현재 플레이 스냅샷, 누적 경험 set, 현재 플레이의 지나온 이벤트/경로, alert dot 계산 기준이 필요 |
| User-facing Surface | R1 | 진입점 위치, 포인트 상태 색상, 모달 copy는 출시 후 조정 가능 |
| Copy / Visual Presentation | R1 | 노드 아이콘·label·alert dot 색상은 디자인 검수 후 빠르게 조정 가능 |
- R1: 출시 후 빠르게 조정 가능. 기본값 제안 후 진행.
- R2: 되돌릴 수 있으나 개발/데이터 재작업 필요. 근거·대안 기록.
- R3: 되돌림 비용이 크거나 정합성에 영향. 별도 싱크 필요.
1. 배경과 문제
AI 챗 기반 에피소드는 유저가 장면을 생성하며 진행한다. 유저 입장에서는 “내가 이 에피소드에서 얼마나 봤는지”, “아직 남은 이벤트가 얼마나 되는지”, “현재 플레이에서 내가 어디쯤이고 다음으로 가려면 무엇을 해야 하는지”가 잘 보이지 않는다.
기존 이벤트맵 기획은 수집 현황과 플레이 중 진행 안내를 한 화면/한 규칙으로 섞어 다루면서 다음 문제가 있었다.
- 에피소드 상세에서 필요한 것은 전체 에피소드 기준의 수집 욕구 자극인데, 플레이 중 경로 안내와 같은 인터랙션/정보를 요구했다.
- 플레이 중 필요한 것은 현재 플레이 기준의 위치·경로·다음 조건 이해인데, 전체 수집률/프로그레스 중심으로 보일 위험이 있었다.
- 리스트 형태 탐색은 있으면 좋지만, 이번 개편의 핵심 목적에는 직접 기여하지 않아 범위를 키운다.
따라서 이번 개편은 이벤트맵을 하나의 도메인으로 유지하되, 진입 위치별 목적·데이터 기준·상태 표현을 명확히 분리한다.
2. 목표
2.1 에피소드 상세 이벤트맵의 목표
에피소드 상세에서 보여지는 이벤트맵은 수집욕을 자극한다.
유저가 에피소드 상세에서 다음을 알 수 있어야 한다.
- 이 에피소드 전체 이벤트 중 내가 몇 개를 경험했는지
- 메인/서브 포인트를 포함해 어떤 포인트를 한 번이라도 경험했는지
- 아직 비어 있는 포인트가 얼마나 남았는지
- 디렉터가 최신으로 구성한 이벤트 구조에서 내 수집 상태가 어떻게 보이는지
2.2 플레이 이벤트맵의 목표
플레이에서 보여지는 이벤트맵은 내가 지금 어디에 위치해 있고 다음으로 가려면 어떻게 해야 하는지 알려준다.
유저가 플레이 중 다음을 알 수 있어야 한다.
- 현재 플레이에서 지나온 이벤트가 무엇인지
- 현재 플레이 스냅샷 기준으로 어떤 연결 경로가 있는지
- 내가 지나온 경로와 아직 지나오지 않은 연결이 어떻게 다른지
- 특정 포인트의 이름, 연결 가능한 다음 포인트, 트리거 공개 상태를 이해할 수 있어야 한다
- 아직 경험하지 않은 이벤트/엔딩의 조건은 300 스타를 소모해 영구 공개할 수 있어야 한다
3. Scope / Non-goals
3.1 In scope
- 에피소드 상세 화면의 이벤트맵 진입점 재배치
- 에피소드 상세 진입 이벤트맵의 경로 view 개편
- 플레이 화면 내 이벤트맵 바로가기 진입점 추가
- 플레이 메뉴 내 이벤트맵 진입점 추가
- 플레이 진입 이벤트맵의 경로 view 개편
- 플레이 이벤트맵에서 포인트 상세 모달 제공
- 비활성 이벤트/엔딩 조건 잠금 해제(300 스타 고정, 구매 후 영구 공개)
- 포인트 상태/행 배치/연결선/alert dot 정책 정의
3.2 Out of scope
- 리스트 view: 이번 기획 목적에서는 good-to-have이므로 삭제하고 후순위로 미룬다.
- Studio 이벤트 저작 UX 변경
- 이벤트 그래프 API/DB schema 상세 설계
- 이벤트맵 공유/외부 링크
- 에피소드 상세 이벤트맵의 포인트 클릭/상세 모달
4. 핵심 정책
4.1 진입점별 목적과 데이터 기준
| 구분 | 에피소드 상세 | 플레이 |
|---|---|---|
| 목적 | 수집욕 자극 | 현재 위치와 다음 진행 조건 이해 |
| 데이터 기준 | 최신 스냅샷 | 현재 플레이 스냅샷 |
| 활성화 기준 | 유저가 한 번이라도 경험한 포인트 | 이 플레이에서 경험한 포인트 / 지나온 경로 |
| 카운트 표현 | 내가 본 이벤트 / 전체 이벤트 | 지나온 이벤트 n |
| 프로그레스바 | 표시, 퍼센트 포함 | 삭제 |
| 포인트 연결선 | 표시하지 않음 | 모든 연결선 표시, 지나온 경로는 활성 연결선 |
| 포인트 탭 | 불가 | 가능, 포인트 상세 모달 노출 |
4.2 이벤트 타입
| 타입 | 설명 | 표시 그룹 |
|---|---|---|
| 프롤로그 | 에피소드의 시작점 | 메인 포인트 |
| 메인 이벤트 | 본줄기 이벤트 | 메인 포인트 |
| 메인 엔딩 | 본줄기 결말 | 메인 포인트 |
| 서브 이벤트 | 메인 흐름 중 연결/발생하는 사이드 이벤트 | 서브 포인트 |
| 서브 엔딩 | 서브 흐름에서 종료되는 결말 | 서브 포인트 |
4.3 행 배치 정책
경로 view의 포인트 행은 다음 규칙을 따른다.
- 기본 행은
프롤로그로부터 최대 도달 가능 횟수를 기준으로 계산한다. - 앞 행이 비어 있다면 빈 행을 압축해 한 행 상승시킨다.
- 서브 포인트는 메인 경로 depth와 별개로 최하단에 배치한다.
- 예: 프롤로그로부터 1단계, 3단계, 5단계로 거쳐 갈 루트가 있는 에피소드라면 해당 포인트는 5행 기준으로 배치한다.
- 예: 1단계 이벤트 이후 모두 5단계 도달 이벤트라면, 중간 빈 행을 압축해 5단계 이벤트들은 2행에 배치한다.
5. 에피소드 상세
5.1 에피소드 상세 진입점
에피소드 상세 상단 정보 구조를 재배치한다.
내가 본 미디어 수 / 전체 미디어 수를 에피소드 제목 하단으로 이동한다.내가 본 이벤트 수 / 전체 이벤트 수를 에피소드 제목 하단으로 이동한다.내가 본 이벤트영역은 에피소드 상세 진입 이벤트맵의 CTA다.- 업로드 날짜, 장르, 엔딩 개수, 보기 방식은 하단
에피소드 정보영역으로 이동한다.
5.2 에피소드 상세 Alert Dot
내가 본 이벤트 영역에는 Green 400 alert dot을 표시할 수 있다.
활성화 조건:
- 플레이어가 새롭게 본 이벤트가 추가되었을 때
- 디렉터가 새로운 이벤트를 추가했을 때
비활성 조건:
- 디렉터가 이벤트를 삭제했을 때는 alert dot을 활성화하지 않는다.
의도: 삭제 알림이 아니라, 유저가 새로 확인할 만한 수집/구조 변화가 생겼다는 신호다.
5.3 에피소드 상세 진입 이벤트맵
에피소드 상세 진입 이벤트맵은 최신 스냅샷 기준의 수집 현황 화면이다.
상단에는 다음을 표시한다.
- 에피소드 제목
내가 본 이벤트 / 전체 이벤트- 메인/서브 경험 수 breakdown
- 프로그레스바
- 퍼센트
본문은 경로 view만 제공한다.
- 리스트 view는 제공하지 않는다.
- 포인트 간 연결선은 표시하지 않는다.
- 모든 포인트는 클릭 불가다.
- 포인트 활성화 여부만으로 수집 상태를 표현한다.
- 메인 포인트와 서브 포인트 모두 전체 이벤트 수와 경험 수 계산에 포함한다.
6. 플레이
6.1 플레이 진입점
플레이 중 이벤트맵 진입점은 두 곳이다.
플레이 화면 상단 아이콘
- 플레이 아이콘 메뉴 2번째에 위치한다.
- GreenAlertDot과 함께 표시할 수 있다.
- 해당 플레이에서
지나온 이벤트개수에 변화가 있으면 노출한다. - 변화에는 새로운 이벤트 등장과 다시 생성으로 인한 이벤트 경로 삭제를 모두 포함한다.
플레이 메뉴 내 아이콘 리스트
- 아이콘 리스트 3번째에 위치한다.
- alert dot을 표시할 수 있다.
- 색상은 source 내
RedAlertDot/GreenAlertDot표기가 충돌하므로 검토 필요에 남긴다. - 메뉴 리스트 내 카운트 표현은
내가 본 포인트 수 / 전체 포인트 수로 제안되어 있으나, 플레이 이벤트맵 본 화면은지나온 이벤트 n만 표시한다. 메뉴 리스트 카운트는 검토 필요에 남긴다.
6.2 플레이 이벤트맵
플레이 이벤트맵은 현재 플레이 스냅샷 기준의 진행 안내 화면이다.
상단에는 다음을 표시한다.
- 에피소드 제목
지나온 이벤트 n- 메인/서브 breakdown
본문은 경로 view만 제공한다.
- 리스트 view는 제공하지 않는다.
- 프로그레스바는 제공하지 않는다.
- 전체 이벤트 중 몇 개를 봤는지가 아니라, 이 플레이에서 경험한 이벤트 개수만 보여준다.
- 전체 연결선을 표시한다.
- 이 플레이에서 지나온 경로는 활성 연결선으로 표시한다.
- 포인트 탭 시 포인트 상세 모달을 연다.
7. 포인트 상태 정책
7.1 메인 포인트
대상: 프롤로그, 메인 이벤트, 메인 엔딩
| 상태 | 프롤로그 | 메인 이벤트 | 메인 엔딩 |
|---|---|---|---|
| 비활성 | 없음 | ? 표기, tertiary | [엔딩] 아이콘, tertiary |
| 활성 | [프롤로그] 아이콘, Primary, Brand opacity 20 | [체크] 아이콘, Primary, Brand opacity 20 | [엔딩] 아이콘, Primary, Brand opacity 20 |
7.2 서브 포인트
대상: 서브 이벤트, 서브 엔딩
| 상태 | 서브 이벤트 | 서브 엔딩 |
|---|---|---|
| 비활성 | ? 표기, tertiary | [엔딩] 아이콘, tertiary |
| 활성 | [체크] 아이콘, Pink 500, Pink 500 opacity 20 | [엔딩] 아이콘, Pink 500, Pink 500 opacity 20 |
플레이 이벤트맵에서 서브 포인트가 활성화된 경우, 특정 메인 요소에서 연결되었다는 정보로 [체크] 아이콘을 표시한다. 2개 이상의 메인 요소에서 연결되어도 체크 아이콘은 1개만 노출한다.
8. 포인트 상세 모달
포인트 상세 모달은 플레이 이벤트맵에서만 제공한다.
모든 포인트 모달 공통 구성:
- 포인트 종류
- 포인트 이름
- 연결 가능 포인트 리스트
- 닫기
조건부 구성:
- 포인트 조건/트리거 내용: 프롤로그를 제외한 활성 포인트와, 300 스타 조건 잠금 해제를 구매한 비활성 이벤트/엔딩에서 표시한다.
- 서브 포인트 연결 여부: 메인 포인트에서만 표시한다.
상태별 주요 차이:
- 활성화 메인 이벤트 모달은 메인 이벤트 아이콘/이름, 서브 이벤트 연결 메시지, 트리거, 연결 가능 이벤트 리스트를 보여준다.
- 비활성 이벤트/엔딩 모달은
?또는 엔딩 아이콘과 비활성 톤으로 표시한다. 연결 가능 이벤트 정보는 노출하되, 조건/트리거는 기본 잠금 처리한다. - 비활성 이벤트/엔딩 조건은
이벤트 조건 확인 ✦ 300CTA를 통해 열람한다. 가격은 이벤트 타입/중요도와 무관하게 300 스타 고정이다. - 최초 1회에 한해 300 스타 사용 안내 모달을 노출한다. 유저가
취소를 누르면 차감하지 않고 기존 모달로 복귀한다. - 스타가 충분한 상태에서 CTA/안내 모달을 확정하면 300 스타를 차감하고 해당 이벤트/엔딩 조건을 영구 공개한다. 이후 같은 이벤트/엔딩 모달에서는 CTA 없이 조건/트리거가 바로 노출된다.
- 스타가 부족하면 차감하지 않고 부족 안내/충전 CTA를 노출한다. 충전 완료 후 원래 비활성 이벤트/엔딩 모달로 복귀하더라도 자동 공개하지 않으며, 유저가
이벤트 조건 확인 ✦ 300CTA를 다시 눌러야 차감·공개된다.
9. 성공 지표
| 지표 | 현재 | 목표 | 측정 방법 |
|---|---|---|---|
| (메인) 같은 에피소드의 이벤트맵 배포 전/후 완주율 | 배포 전 기간 완주율 | 배포 후 유의하게 상승 | 동일 에피소드 모집단에서 기능 배포 전 기간 vs 후 기간 비교 |
| 이벤트맵 진입률 | — | 발견성 모니터링 | 이벤트맵 조회 유저 / 에피소드 플레이 유저 |
| 재플레이 전환율 | — | 보조 모니터링 | 이벤트맵 조회 후 같은 에피소드 재시작/이어하기 |
| 서브 이벤트 발견율 | — | 보조 모니터링 | 서브 포인트 활성화 유저 비율 |
맵 조회 유저 vs 미조회 유저완주율 비교는 self-selection bias가 있으므로 참고 지표로만 사용한다.- 플레이 화면 → 맵 진입 후 플레이 미복귀율은 가드레일로 본다.
10. 로깅 초안
데이터 위키(event-docs.frontia.dev) 기준으로 에피소드/플레이 진입 경로 property는
entry_source를 사용한다.episode_id가 포함되는 이벤트는episode_title도 함께 포함한다.
포인트는 기존 이벤트/엔딩 도메인을 이벤트맵 UI에서 묶어 표현하는 개념이다. analytics에서는 이벤트맵 UI 포인트 식별자로 event_point_id와 event_point_type을 사용한다.
| 구분 | 이벤트 | 목적 | 주요 property 초안 |
|---|---|---|---|
| Event | view_event_map | 이벤트맵 화면 진입 | episode_id, episode_title, entry_source(episode_detail/episode_player/play_menu), play_id |
| Event | click_event_map_point | 플레이 이벤트맵 포인트 탭 | episode_id, episode_title, play_id, event_point_id, event_point_type, event_point_state |
| Event | view_event_map_point_modal | 플레이 이벤트맵 포인트 상세 모달 노출 | episode_id, episode_title, play_id, event_point_id, event_point_type, event_point_state, trigger_preview_state(locked/unlocked) |
| Event | click_event_trigger_preview_purchase | 비활성 이벤트/엔딩 조건 확인 CTA 또는 최초 1회 안내 모달 버튼 탭 | episode_id, episode_title, play_id, event_point_id, event_point_type, price_star=300, purchase_step(cta/confirm_modal), purchase_result(success/insufficient_star/cancelled) |
11. 검토 필요
| 구분 | 항목 | 확인 필요 내용 | Owner |
|---|---|---|---|
| 🚨 결정 필요 | 플레이 메뉴 내 alert dot 색상 | source에 RedAlertDot과 GreenAlertDot이 함께 적혀 있음. 최종 색상 확정 필요 | Design/PM |
| 🚨 결정 필요 | 플레이 메뉴 내 카운트 표현 | 메뉴 리스트에서 내가 본 포인트 수 / 전체 포인트 수를 보여줄지, 본 화면처럼 지나온 이벤트 n만 보여줄지 확정 필요 | Design/PM |
| ⚠️ 추정 | 포인트 모달 종류 | source에서 활성화 메인엔딩이 중복되어 있어 누락 항목을 활성화 서브엔딩으로 추정 | PM |
| ❓ 외부 확인 필요 | 최신/현재 플레이 스냅샷 데이터 가용성 | 누적 경험 set, 현재 플레이의 지나온 이벤트, 경로 삭제/재생성 변화를 계산할 수 있는지 확인 필요 | BE |
| ✅ 결정 완료 | 포인트 식별자 | analytics에서는 event_point_id/event_point_type을 사용한다. | Data |
12. References
- Linear: DEE-343 [앱] 플레이 이벤트 맵
- Historical PRD (Notion): 에피소드 이벤트 맵 PRD
- Source: Zen Slack thread requirements, 2026-06-30
prd-review 보기
Review log
2026-06-22 — Notion 원문 보존형 재작성 (prd-review skill)
표준 grilling walk-through 대신, 모모가 사전 결정한 directed rewrite로 진행. 기존 sprint-artifacts 초안이 Notion historical PRD의 구체성을 과도하게 추상화해 날린 것을 복원하고, 모모 결정 3건을 반영.
소스: Notion historical PRD(31b996f950668006b732dacb4ee6bf64)를 MCP로 직접 fetch 성공.
채택 (모모 결정)
Q: 메인 목표 지표를 무엇으로?
- A: "같은 에피소드 내 이벤트 맵 배포 전/후 완주율 비교"를 메인으로. "맵 조회 vs 미조회 유저 비교"는 self-selection bias가 있어 메인에서 제외, 참고 지표로만.
- → §1.5 메인 지표 교체 + 참고 지표로 강등 명시 / §5.1-1·5.1-7 / §7 OQ 베이스라인을 "배포 전 기간"으로 수정
Q: 추가 기능 — 다음 이벤트 트리거 조건 노출
- A: 바로 연결된 다음 이벤트의 트리거 조건을, 사용자가 노드/연결 정보를 탭하면 볼 수 있는 depth로. 디렉터가 Studio에 작성한 trigger를 읽기 전용 노출. PRD엔 user-facing 가치·요구사항으로, 화면 배치/상세 UX는 spec.
- → §1.3 / §1.4 가설4 / §2.2 시나리오2 / §3-1 연결 규칙 / §3-2 기능 단위 1·2 노드 상세 + 기능 단위 3 신설 / §3-4 / §3-5 Scope / §4 예외(트리거 미작성) / §5.2
view_next_event_trigger신규 / §6 약속어 / §7 OQ(앱 조회 가용성)
Q: Notion 원문 구체성 보존
- A: 예시·케이스·트리 구조·조건 설명을 가능한 한 살린다.
- → §3-1 이벤트 타입 표·연결 규칙·서브이벤트/서브엔딩 동작 원리 복원 / §3-3 예시 A~D(선형/복잡/순환) 전체 복원 — 연결 관계·서브이벤트 트리거 관계·depth 테이블·플레이어 경로 예시 포함 / "두근두근 애프터 데이트" 기준 명시
최신화 (stale/충돌 조정)
- 진행바: Notion §4 "상단 프로그레스 바와 함께 목차 표시" vs §3-2/§3-5 "프로그레스 바 없음"이 원문 내 충돌. 최신 결정인 프로그레스 바 없음(목차 리스트가 위치를 보여줌)을 채택.
- 앱/웹: Notion은 앱+웹. DEE-343이 [앱] 범위이므로 앱 only로 유지.
- 진입점 B: Notion "플레이 화면 상단 바 아이콘" → 현재 Frontia 플레이 화면의 메뉴 모드(중앙 1/3 탭) 진입 후 상단 맵 아이콘으로 최신화 (초안 author 반영분 유지). 정확한 진입 위치는 spec/디자인에서 확정.
Skip / 미임베드
- Notion §3 예시의 프로토타입 스크린샷 이미지: 서명된 S3 링크(만료성)라 본문 임베드 제외. 텍스트 구조(연결·depth·경로)는 전량 보존. 시각 표현은 Design 단계 Figma 시안에서 재현. (§부록 Fuzzy points에 명시)
- Notion §3 "피그마 문서 링크 / 프로토타입" callout(빈 값·jsx 첨부): 결정 내용 없어 본문 미반영. Figma 링크는 Design 단계에서 채움.
모모 인라인 피드백 (criteria 후보)
- self-selection bias가 있는 "조회 유저 vs 미조회 유저" 비교를 메인 지표로 쓰지 말 것. 같은 모집단의 시간축 전/후 비교가 bias-free. → criteria "메인 지표" 항목에 반영.
- Notion 등 historical 원문이 있을 때, 요약·추상화로 예시/케이스/구조를 날리지 말고 다음 단계가 일할 수 있는 구체성을 보존할 것. → criteria 작동성 항목 반영 후보.
미반영 / 후속
- Linear write(이슈 상태·생성): 모모 승인 사안 → 미실행.
- 같은 폴더
PRD 2.md(iCloud 중복 추정): 이번 rewrite와 무관 → 미수정.