Skip to content

[앱/웹] 플레이 모먼트 공유 PRD

Backlog grooming 단계의 산출물. 무엇을 만들지·왜 만들지·핵심 비즈니스 룰을 정의한다.


Status: draft Created: 2026-05-13 Last updated: 2026-05-13 Linear Project: [앱/웹] 플레이 모먼트 공유 (c95e168a2297) Linear Issue: DEE-69Author: prd-writer (agent) 앱/웹/스튜디오: 앱 + 웹


1. 목표 및 배경

1.1 문제

플레이 중 인상적인 모먼트(한 씬 또는 연속된 몇 씬)를 만났을 때 외부로 꺼낼 공식 단위가 없다. 현재는 본인 앱 화면에 머무르고, 스크린샷 외에는 외부 공유 수단이 없다.

  • 사용자 정의 (segment): 에피소드 플레이를 1회 이상 의미 있는 지점까지 진행한 플레이어. 특히 인상적인 씬·구간을 만난 플레이어.
  • 상황 (when, where): 플레이 도중 "이 장면(또는 이 흐름) 누구한테 보여주고 싶다"는 충동이 생긴 순간. 카톡·DM·SNS 등 외부 채널로 옮겨가려는 순간.
  • 불편 / 미충족 needs:
    • 공식 공유 수단 부재 → 스크린샷·녹화로 우회 → 작품 출처(에피소드/디렉터)가 끊기고 재플레이 동선이 사라진다.
    • 수신자가 링크를 받아도 "이게 뭔지, 어디서 보는지" 알 수 없다.
    • 작품 입장에서는 가장 강력한 바이럴 자산(플레이어가 만든 ‘내 플레이’)이 외부로 새지 않는다.

1.2 근거

  • issue seed (DEE-69): "‘공유’는 source. 단위(링크/카드)·수신자 동선은 추론." — 사내 첫 외부 공유 단위 정의.
  • 인접 시그널: Notification 도메인에 이미 "플레이 이어하기 push"가 정의돼 있을 만큼, 플레이는 재진입 동선이 핵심 자산. (wiki/domains/notification/capabilities.md)
  • Play 도메인: EpisodePlay aggregate가 publish snapshot + local play config를 결합. 공유 단위 후보(전체 플레이 / 특정 씬 / 엔딩)가 모두 이 aggregate 안에서 식별 가능. (wiki/domains/play/capabilities.md)
  • 사내 선례: Linear에서 "공유 / share / 캡쳐 / 딥링크" 키워드로 active project 검색 결과 본 프로젝트 외 hit 0건.
  • 외부 유입·VOC 실측: Dara 응답 대기 (§7).

1.3 아이디어 (해결 방향)

플레이 중의 인상적인 **모먼트(씬 범위)**를 "공유 가능한 단위(Shared Play Moment)"로 패키징하고, 공유 링크를 통해 수신자(로그인 필수)가 미리보기 → 원본 에피소드 플레이로의 진입 동선을 타도록 만든다.

  • 옵션 1 — Replay Link: 플레이 전체를 read-only로 외부 노출. "내가 만든 이야기"의 양감이 강하지만 viewer UI·spoiler·노이즈 노출 부담 큼.
  • 옵션 2 — Moment Link: 사용자가 지정한 씬 범위(시작 씬~끝 씬, 씬 경계로 스냅)를 외부 공유. OG 카드+미리보기. 구현 부담 작고 캡쳐 대체재로 자연스러움.
  • 옵션 3 — Ending Card: 엔딩·미션 클리어만 공유. 자랑·인증 동기와 매칭. "엔딩" 정의 필요·발화 빈도 낮음.

추천: 옵션 2 (Moment Link)를 첫 출시로 채택. 옵션 1·3는 후속 사이클. 사내 첫 외부 공유 단위라 수신자 동선·OG·권한 정책 변수가 많다. 가장 가벼운 단위로 한 사이클 먼저 돌리고 시그널 확인 후 확장한다. 옵션 2 산출물(공유 record, OG, 수신자 viewer, 재플레이 CTA)이 옵션 1·3 토대로 그대로 재사용된다.

1.4 가설

  1. 공식 공유 버튼이 생기면 플레이어는 스크린샷 대신 그것을 쓴다 — 스크린샷 캡처 37,405건/1,246명이 현재 공유 욕구의 하한이다.
  2. 공유 링크 수신자의 비-자명한 비율이 원본 에피소드 플레이로 진입한다 — viewer → 플레이 시작 CTR 시그널 확인.
  3. (보조) 공유 링크 유입 중 일정 비율이 신규 가입/플레이 시작으로 전환된다 — 신규 외부 유입 채널로 기능.
    • 보조 위치 이유: 비프론티아 수신자 비율 base rate 미확보. 본 출시로는 funnel 끝까지 따라가 추정만 한다.

1.5 성공 지표

본 출시는 funnel 두 단계 모두 본다. 기준선 기간은 2026-04-15 ~ 2026-05-12. Dara 정정 조회값: 플레이 시작 267,400건 / 19,128명, 스크린샷 캡처 37,405건 / 1,246명, 기존 share_content 123건 / 63명. 이 기능은 "완료 후 공유"가 아니라 플레이 중 욕구 포착이므로 기준 분모는 완료 씬/완료 플레이가 아니라 click_play_start 기준 플레이 시작으로 둔다. 공유 욕구 기준선은 죽은 지표인 기존 share_content가 아니라 스크린샷 하한 + 외부 진입 CTR 프록시로 잡는다.

지표현재/프록시목표측정 방법
(메인 A1) Moment 공유 유저율스크린샷 유저 / 플레이 시작 유저 6.5%. 기존 공유 유저 / 플레이 시작 유저 0.33%플레이 시작 유저의 2%+ (28일 기준 약 383명+)submit_share_play unique user / click_play_start unique user
(메인 A2) Moment 공유 발생률스크린샷 / 플레이 시작 14.0%. 기존 공유 / 플레이 시작 0.046%플레이 시작의 0.5%+ (28일 기준 약 1,337건+)submit_share_play / click_play_start
(메인 B) 공유 viewer → 플레이 시작 CTR웹 앱다운로드 배너 클릭률 8.3%, 에피소드 상세 → 플레이 시작 34.8%최소 8%, 목표 12%+click_share_viewer_cta / view_share_viewer
  • 스크린샷 14.0%가 핵심 신호: 플레이 도중 공유 욕구가 이미 있고, 공식 공유는 이 욕구를 캡처·전환하는 기능이다.
  • 기존 share_content는 기준선 제외: 플레이 시작 대비 0.046%, 유저 기준 0.33%로 너무 낮아 기존 기능/이벤트가 죽은 지표에 가깝다.
  • 완료 씬/완료 플레이는 denominator 제외: 공유는 완료 씬이 없어도 가능하므로 발행률 denominator로 쓰지 않는다.
  • 메인 지표를 두 축으로 두는 이유: 발행이 0에 수렴하면 CTR 100%여도 outcome은 실패. 발행량(채택)과 전환(바이럴)을 동시에 본다.
  • 가드레일:
    • 플레이 화면 체류 시간 / 진행률 (공유 UI가 방해 안 되는지)
    • 콘텐츠 신고 수 (공유로 부적절 콘텐츠가 외부 노출)
    • 디렉터 이의/만족도 시그널

2. 타깃 사용자

2.1 주요 사용자

  • 공유자(발신자): 플레이 중인 플레이어. 인상적인 씬·구간을 만난 순간에 공유 충동을 느끼는 사람.
  • 수신자: 공유자의 외부 채널(카톡/DM/SNS) 친구. viewer 진입에는 로그인 필수(비로그인 수신자는 viewer 자체를 볼 수 없고 로그인/가입 게이트로 이동).
  • 2차 수익자: 해당 에피소드의 디렉터. 자기 작품이 외부로 알려지는 채널이 생김.

2.2 핵심 시나리오

  1. 플레이 중 인상적 모먼트 → 공유: 플레이어가 플레이 도중 인상적인 흐름을 만나, 시작 씬·끝 씬을 지정해 그 씬 범위를 외부 채널로 공유한다. 수신자가 OG 카드를 클릭 → (필요 시 로그인) → viewer에서 모먼트를 본 뒤 "지금 바로 플레이하기" CTA로 해당 에피소드 플레이에 진입한다.
  2. 수신자가 신규: viewer 접근 시 로그인/가입 게이트 → 가입 완료 → viewer 복귀 → CTA로 동일 에피소드 플레이 시작.
  3. 수신자가 이미 프론티아 유저: 로그인 세션으로 viewer 진입 → CTA로 플레이 진입(이어보기 룰은 §7).

3. 핵심 기능 요구사항

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

A. 플레이 화면 공유 진입 (Share Entry)

  • 주요 동작: 플레이 중 플레이어가 인상적인 모먼트를 외부로 공유한다. 진입은 플레이 화면 내부에서만(플레이 종료 후 진입 동선은 본 출시 미포함).
  • 비즈니스 룰:
    • 공유 단위: 씬 범위(Scene range) — 시작 씬과 끝 씬을 사용자가 지정. 비디오 편집의 in/out 지점 선택과 유사하나, in/out은 씬 경계로 스냅된다. 1개 이상의 씬을 포함하며, 한 씬(시작=끝)만 선택해도 valid. 임의 프레임·시간 단위 컷은 불가. 한 씬 = LLM main call 1회의 narrative 응답.
    • 선택 가능 범위: 프롤로그 이후 사용자에게 이미 노출된 씬은 선택 가능. completed 씬이 없어도 현재 플레이 중인 씬(in_progress)을 단일 모먼트로 공유할 수 있다. 단, 아직 생성/노출되지 않은 미래 씬은 시작/끝 어디에도 포함 불가.
    • 공유 발행 1개 = 공유 record 1개: 동일 범위 재공유 시에도 share_id는 새로 발급(통계 단순화).
    • 공유 발행 차단: 범위 내 어떤 씬이라도 운영 정책 ruleset 위반(금지 키워드/이미지)이면 공유 발행 차단 + 안내. ruleset connect는 §7.
  • 상태별 동작:
    • 본인 플레이: 가능 (플레이는 로그인 필수)

B. 공유 채널 시트 (Channel Sheet)

  • 주요 동작: 공유 발행 시 OS 네이티브 share sheet로 외부 채널 전송. 웹은 Web Share API + 클립보드 복사 fallback.
  • 공유 페이로드: 공유 URL + 공유 텍스트(에피소드명 + 한 줄 hook + 출처) + OG 미리보기 이미지(서버 렌더링).
  • URL 포맷: https://<web 도메인>/<prefix>/<share_id> — prefix 컨벤션은 §7.

C. 수신자 viewer 페이지 (Web)

  • 주요 동작: 수신자(로그인 사용자)가 공유 URL을 열면 웹 viewer가 (a) 공유된 씬 범위의 narrative 텍스트(시작 씬부터 끝 씬까지 순서대로), (b) 시작 씬의 첫 frame을 대표 비주얼로, (c) 메타(에피소드명·디렉터·간단 설명), (d) CTA "지금 바로 플레이하기"를 보여준다.
  • 공유 단위 노출 범위: 지정된 씬 범위 내 모든 씬의 narrative + 시작 씬의 첫 frame 1장(대표 비주얼, 자동). 범위 밖 씬은 미노출.
  • 수신자 권한:
    • 로그인 필수: viewer 페이지 자체가 로그인 사용자에게만 노출된다. 비로그인 사용자가 공유 URL을 열면 viewer를 보여주지 않고 곧장 로그인/가입 게이트로 이동, 완료 후 동일 viewer URL로 복귀해 정상 노출.
  • 재플레이 동선: CTA "지금 바로 플레이하기" 클릭 → /episode-play/:episodeId로 진입. 이어보기/처음부터 룰은 §7. (viewer 자체가 로그인 게이트 이후라 CTA에서 추가 게이트 없음.)
  • 상태별 동작:
    • 공유 record active + 에피소드 정상: 정상 표시
    • 공유 record 만료: "더 이상 볼 수 없는 페이지" 안내 + 홈 CTA
    • 에피소드 비공개/삭제: "이 작품은 더 이상 공개되어 있지 않습니다" 안내 + 홈 CTA

D. OG / 미리보기 카드

  • 주요 동작: 카톡·SNS·메신저에서 미리보기 카드가 자동 렌더링되어야 한다.
  • OG title: 에피소드명 (디렉터명 부기 가능)
  • OG description: 공유 범위 시작 씬의 첫 narrative line 또는 줄여서 80자 (카카오톡 호환). 추출 룰은 §7.
  • OG image: 서버 사이드 렌더링된 카드 이미지. 에피소드 썸네일 + 핵심 카피 + 프론티아 로고. 비율 1.91:1.

3-2. 어드민

본 출시 범위 없음. viewer가 로그인 사용자 한정이라 외부 무차별 노출이 차단되므로, 강제 비활성화·신고 UI는 본 출시에 포함하지 않는다. 운영 신호(신고/abuse 빈도) 확인 후 추가 여부를 결정 — §7 OQ.

3-4. 딥링크 / URL 구조

기존 path 재사용:

경로동작본 PRD 사용
/episode-play/:episodeId에피소드 플레이 (이어보기)viewer "지금 바로 플레이하기" CTA 직진

신규 path 필요 (개발자 확정 게이트):

  • 웹 공유 viewer 페이지 1개 — prefix 컨벤션 미정 (§7)
  • 앱 딥링크 1개 — viewer를 앱에서 그릴지 / 플레이 화면으로 바이패스할지 미정 (§7)

앱 미설치 fallback: 웹 viewer가 기본. 카톡 inApp browser에서도 그대로 렌더. 비로그인 접근 정책: viewer 진입 자체에 로그인 필수. 비로그인 사용자는 로그인/가입 게이트 → 완료 후 viewer URL로 복귀.

3-5. Scope

포함 (In scope)

  • 플레이 중 씬 범위(시작 씬~끝 씬, 씬 경계 스냅) 외부 공유 발행
  • 공유 record entity 신규 추가 (start/end scene 식별자 포함)
  • 웹 viewer 페이지 (씬 범위 미리보기 + "지금 바로 플레이하기" CTA, 로그인 사용자만 노출)
  • 서버 사이드 OG 카드 렌더링
  • 로깅 이벤트 (§5.2)

제외 (Out of scope)

  • 플레이 전체 공유 (옵션 1 Replay Link)
  • 엔딩/마일스톤 카드 (옵션 3)
  • 프레임 단위·임의 시간 컷 공유 (씬 경계 스냅 강제)
  • 플레이 종료 후 회고형 공유 진입 동선
  • 수신자에게 "이 씬부터 플레이하기" CTA (fork 플레이 생성)
  • 공유 viewer 내 댓글·좋아요 등 인터랙션
  • 수신자/공유자에게 보내는 알림·푸시
  • 디렉터별 공유 허용/차단 toggle
  • 어드민 강제 비활성화·신고 UI (§3-2 참조)
  • 비로그인 수신자 viewer 노출
  • 남의 플레이 공유 / 임베드(iframe)
  • 플레이어 본인 화면에 공유 이력 노출

4. 에러 처리 및 예외 상황

상황처리 방향
공유 발행 시 네트워크 오류재시도 가능. 발행 실패해도 플레이 진행에는 영향 없음
공유 record 만료 후 viewer 접근"더 이상 볼 수 없는 페이지" 안내 + 홈 CTA
에피소드 비공개/삭제 후 viewer 접근"이 작품은 더 이상 공개되어 있지 않습니다" 안내 + 홈 CTA
OG crawler가 OG image 캐시 미스on-demand 생성. 실패 시 에피소드 썸네일 default 카드로 fallback
비로그인 수신자가 viewer URL 접근로그인/가입 게이트로 이동 → 완료 후 동일 viewer URL로 복귀
씬 범위 선택 시 시작 > 끝 또는 아직 생성/노출되지 않은 미래 씬 포함발행 버튼 비활성 + 인라인 안내
본문이 운영 정책 ruleset 위반공유 발행 차단 + 안내

5. 데이터 분석

5.1 핵심 지표

§1.5와 동일. 메인 A(발행률), 메인 B(viewer→플레이 CTR), 보조(viewer PV/발행 수, 신규 가입·플레이 시작).

5.2 로깅 이벤트

컨벤션: https://event-docs.frontia.dev/ (Cloudflare Access 보호). 기존 그룹 재사용 → 없을 때만 신규.

본 PRD에서 그룹 확정에 필요한 event-docs는 모모 세션에서만 접근 가능 → 재사용 vs 신규 그룹 판단 §7에서 모모가 확정. 아래는 컨벤션(snake_case, 동사_명사) 기반 초안.

타입이름용도파라미터그룹
Eventclick_share_play플레이 화면 공유 버튼 클릭episode_id, episode_play_id, current_scene_id, view_modeepisode-player 재사용 후보
Eventsubmit_share_play공유 채널 시트에서 채널 선택해 발송 완료share_id, episode_id, start_scene_id, end_scene_id, scene_count, channelepisode-player 재사용 후보
Eventview_share_viewer로그인 수신자가 공유 viewer 진입share_id, episode_id, referrer신규 play-share 후보
Eventclick_share_viewer_ctaviewer에서 플레이 CTA 클릭share_id, episode_id신규 play-share 후보
Eventblock_share_play정책 ruleset 위반으로 공유 발행 차단episode_id, start_scene_id, end_scene_id, reason신규 play-share 후보
Eventblock_share_viewer_unauth비로그인 수신자가 viewer URL 접근해 로그인 게이트로 이동share_id, episode_id신규 play-share 후보

6. Ubiquitous Language

TermKoreanDefinitionDo Not Confuse WithPrimary Domain상태
Shared Play Moment공유 플레이 모먼트EpisodePlay의 연속된 EpisodeScene 범위(start_scene ~ end_scene, 1개 이상)를 외부 공유 가능한 read-only 단위로 묶은 record. share_id로 식별EpisodePlay 자체 / 단순 스크린샷Play신규
Share Viewer공유 viewer공유 URL을 받은 로그인 수신자가 모먼트(씬 범위) 미리보기 + 플레이 CTA를 보는 웹 페이지에피소드 상세 페이지Play신규

기존 용어(Episode, EpisodePlay, EpisodeScene, EpisodeFrame)는 Frontia UL 기존 정의 그대로 사용.


7. Open Questions

  • [ ] CTA 진입 시 이어보기 vs 처음부터/episode-play/:episodeId 진입 시 기존 이어보기 룰이 수신자 의도("내가 본 그 모먼트를 직접 해보고 싶다")와 맞는가, 아니면 "처음부터" 강제할지. — 엔지니어 + PM
  • [ ] 공유 record 만료 정책 — 무기한 / 30일 / 디렉터 비공개 전환 시 자동 만료 등 — 운영 + 엔지니어
  • [ ] 신고·abuse 대응 필요 여부 — viewer 로그인 게이트만으로 부적절 콘텐츠 노출 위험이 충분히 낮춰지는지, 운영 신호 보고 후속 사이클에 신고 UI/강제 비활성화 추가 여부 결정 — 운영
  • [ ] OG description 추출 룰 — 범위 시작 씬의 첫 narrative line / 범위 hook / 디렉터 작성 hook 중 무엇 — PM + 디렉터
  • [ ] OG image 카드 디자인 — 컨셉(에피소드 썸네일 우선 / 시작 씬 비주얼 우선 / 추상 카드) — 디자이너
  • [ ] 공유 URL prefix 컨벤션/m/:share_id vs /share/moment/:share_id vs /moment/:share_id. 향후 다른 공유 단위(에피소드·디렉터 프로필)와의 정합성 — 엔지니어
  • [ ] 앱 딥링크 동작frontia://share/moment/:share_id 진입 시 viewer를 앱에서 그릴지, 플레이 화면으로 바이패스할지 — 엔지니어 + 디자이너
  • [ ] 씬 범위 선택 UI — 플레이 화면 내 in/out 지정 UX (씬 리스트 multi-select vs in/out 슬라이더형) — 디자이너 + PM
  • [ ] 카카오톡 OG description 80자 제한 실측 — 엔지니어
  • [ ] 로깅 이벤트 그룹 재사용 vs 신규 확정 — event-docs(모모 세션)에서 episode-player 그룹의 기존 share-류 이벤트 유무 확인 후 §5.2 그룹·이름 확정 — 모모 + 엔지니어
  • [ ] 부적절 콘텐츠 발행 차단 ruleset connect — 기존 운영 정책 ruleset 재사용 — 운영

부록: 메타 정보

Required artifacts

  • [x] Spec (needs-spec) — 플레이 화면 공유 entry(씬 범위 선택), 공유 viewer 페이지 명세
  • [x] Design (needs-design) — 공유 entry(범위 선택 UI) / viewer / OG card 시안
  • [x] QA scenarios (needs-qa-scenarios) — 공유 발행 → 로그인 수신자 동선 / 비로그인 게이트 / 만료 / 비공개 에피소드 / 범위 invalid 케이스
  • [x] Tracking events (needs-tracking) — §5.2 이벤트
  • [x] 기타: BE 설계 문서 (공유 record entity (start/end scene) / viewer endpoint / OG 렌더링 캐시 정책)

Size & Risks

  • T-shirt Size: M
  • Confidence: medium

주요 위험:

  • 카카오톡 OG 호환 미스 → QA에 OG crawler 시뮬레이션 케이스 포함
  • 디렉터 거부감 → 디렉터 커뮤니티 사전 공유, 옵트아웃 채널 마련
  • viewer 로그인 게이트가 외부 유입 funnel 손실로 작용할 가능성 → 게이트 전·후 이탈을 block_share_viewer_unauth → 가입 → viewer 복귀 funnel로 추적
  • 씬 범위 길이가 길면 viewer 로딩·읽기 부담 ↑ → 최대 씬 수 가드 검토 (§7 후속)

References

prd-review 보기

Review log

2026-05-13

사용자 부재 walk-through. criteria 기반 mechanical fix는 직접 반영, 정책·데이터 결정은 §7로 일괄 흡수.

채택

  • Q (D1): 메인 지표가 funnel 한 단만 측정. 발신자 발행 0이면 CTR 100%여도 실패.

    • A: 메인 지표를 두 개(메인 A 발행률, 메인 B viewer→에피소드 CTR)로 분리.
    • → §1.5 표 재구성 + 보조 지표는 viewer PV/발행 수, 신규 가입·플레이 시작으로 강등.
  • Q (D2): 정량 목표 모두 비어 있음. 채움 책임·시점 부재.

    • A: 임계는 출시 직전 데이터 agent로 채우고 책임자(모모 + 데이터)를 §1.5와 §7에 명시.
    • → §1.5 "목표" 열에 책임·시점 명시, §7에 채움 책임 OQ로 등재.
  • Q (D3): 가설 3(신규 가입 전환)이 base rate 없는데 메인급으로 등재.

    • A: 가설 3을 "보조" 등급으로 강등하고 사유(base rate 미확보) 본문에 명시.
    • → §1.4 가설 3에 "(보조)" + 사유 한 줄.
  • Q (D4): "이 씬부터 플레이하기" CTA가 OOS인데 §3-1·§7에 살아있어 정책 모순.

    • A: §3-1 viewer CTA를 "에피소드 보러가기" 단일로 고정. "이 씬부터"는 §3-5 OOS로 명시, §7에서도 제거.
    • → §3-1 C, §3-5, §7 동기화.
  • Q (Op1): §3-3 백엔드/시스템 섹션이 criteria reject 패턴.

    • A: §3-3 섹션 통째 삭제. "공유 record 신규 entity 필요" 한 줄만 §3-5 In scope에 남김. OG 서버 렌더링은 §3-1 D 비즈니스 룰로 흡수, 어드민 비활성화는 §3-2로 흡수.
    • → §3-3 제거.
  • Q (Op2): §🔍 검토 필요 메타 블록 — criteria가 "메타 섹션 만들지 말 것" 명시.

    • A: 통째 삭제. 외부 agent 의존은 §1.2 근거·§1.5 책임자·§7 OQ로 흡수.
    • → 섹션 제거.
  • Q (Op3): Negative spec 다수 (⚠️ MVP는 전자만, 프레임 단위는 후속 등).

    • A: inline ⚠️ 부연 제거, OOS는 §3-5 한 곳에만 집결.
    • → 본문 inline 제거 + §3-5 OOS 보강.
  • Q (Op4): 부록 위험 표·진행 패턴·추정 근거 산문.

    • A: 위험 표는 의례적 표 형식 대신 bullet 4개로 축약(실 위험만). 진행 패턴 블록 제거. 추정 근거 산문 제거.
    • → 부록 단순화.
  • Q (Op5): viewer 노출 단위가 "씬"인지 "씬+대표 frame"인지 spec 작업자 결정 불가.

    • A: "공유된 씬의 narrative + 그 씬의 첫 frame을 대표 frame으로 자동 사용" 단정. (디렉터/유저 선택은 후속.)
    • → §3-1 C에 단정문 추가.
  • Q (Op7): 딥링크 §3-4 항목이 §3-4·§7·§🚨 삼중 중복.

    • A: §🚨 메타 블록 삭제(Op2)에 묶여 자연 해소. §3-4는 "신규 path 2개 미정 — §7"로 1줄 압축.
    • → §3-4 단순화.
  • Q (Op8): §3-1 E "공유 이력 노출(선택, MVP 검토)"는 미정·미포함 후보를 본문에 둠.

    • A: 섹션 삭제. §3-5 OOS로 흡수 + §7에 이미 등재된 OQ 유지.
    • → §3-1 E 제거.

Skip

  • Q (Op6): 로깅 이벤트 그룹 재사용 vs 신규를 PRD §5.2에서 확정해야 한다.
    • 사유: agent가 event-docs(Cloudflare Access)에 접근 불가. 모모 세션에서만 가능 → 본 PRD §7에 OQ로 명시하고 spec 진입 전 모모가 확정하도록 위임. (Walk-through에서 모모가 직접 답할 때 본문 §5.2 그룹 fix.)
    • → §5.2는 "재사용 후보 / 신규 후보" 표기로 두고 §7 OQ로 미룸.

모모 인라인 피드백 (criteria 후보)

(이번 세션은 walk-through 부재. 인라인 피드백 없음.)


2026-05-13 walk-through

모모와 7개 질문 walk-through. 폴더 rename도 본 세션에서 처리 — c95e168a2297-my-play-sharec95e168a2297-play-moment-share.

채택

  • Q: 공유 단위가 단일 씬으로 맞는가.

    • A: 씬 범위(scene range) 로 확장. 사용자가 시작 씬·끝 씬을 지정, 비디오 in/out 선택과 유사하되 씬 경계로 스냅. 여러 씬 가능, 임의 프레임/시간 컷은 불가.
    • → §1.3 옵션 2, §2.2 시나리오, §3-1 A 비즈니스 룰, §3-1 C viewer 노출 범위, §3-5 In scope·OOS, §4 에러 표, §5.2 파라미터 (start_scene_id/end_scene_id/scene_count), §6 UL Shared Play Moment, §7 신규 OQ "씬 범위 선택 UI"·"최대 씬 수 가드".
  • Q: 진입점은 어디인가 — 플레이 중 / 직후 / 양쪽.

    • A: 플레이 중만. 플레이 도중 원하는 모먼트에 즉시 공유.
    • → §1.1 상황·§2.1 발신자 정의 "플레이 중" 단정, §2.2 "플레이 직후 회고형" 시나리오 제거, §3-1 A "플레이 종료 후 진입 동선은 본 출시 미포함" 명시, §3-5 OOS에 "플레이 종료 후 회고형 공유 진입 동선" 추가.
  • Q: 수신자 CTA 목적지 — 에피소드 상세 vs 플레이 직진.

    • A: 플레이 직진 (/episode-play/:episodeId).
    • → §2.2 시나리오, §3-1 C CTA·재플레이 동선, §3-4 path 표, §4 에러 표 모두 "지금 바로 플레이하기" / /episode-play/:episodeId로 통일. §7 "이어보기 vs 처음부터" OQ로 남김.
  • Q: 비로그인 수신자가 viewer를 볼 수 있어야 하는가.

    • A: 불가. viewer 자체가 로그인 사용자에게만 노출. 비로그인은 로그인/가입 게이트 → 동일 viewer URL로 복귀.
    • → §2.1·§3-1 C 수신자 권한·§3-4 비로그인 접근 정책·§4 에러 표·§5.2 로깅(is_logged_in 파라미터 제거 + 신규 block_share_viewer_unauth)·§6 UL Share Viewer 정의 모두 동기화. §3-5 OOS에 "비로그인 수신자 viewer 노출" 추가.
  • Q: 디렉터 공유 toggle / 어드민 강제 비활성화 필요한가.

    • A: 디렉터 toggle 불필요. 어드민 강제 비활성화도 viewer 로그인 게이트로 abuse 위험이 충분히 낮아지므로 본 출시에선 제거. 운영 신호 보고 후속 사이클에 재검토.
    • → §3-2 섹션을 "본 출시 범위 없음" 한 문단으로 축소, §3-5 OOS에 "어드민 강제 비활성화·신고 UI" 추가, §4 에러 표에서 "어드민 강제 비활성화" 행 제거, §7 OQ "신고·abuse 대응 필요 여부" 추가 (디렉터 toggle OQ는 삭제).
  • Q: 정량 목표를 어떻게 채우는가.

    • A: Dara/데이터 reference 필요. 메인 agent가 Slack으로 Dara에게 문의 진행 중 (2026-05-13). PRD에서 모호한 "data agent" 표기 제거하고, 지표별로 어떤 reference가 필요한지 구체 명시.
    • → §1.2 근거 "데이터 agent" 표현 제거, §1.5 표 "목표" 열 각 지표마다 필요 reference 데이터 종류 명시 + 책임 "모모 + Dara", §7 OQ에 Slack 문의 진행 중 상태 기록.
  • Q: 타이틀/프레이밍을 "내 플레이 공유"로 유지할지.

    • A: A안 — "[앱/웹] 플레이 모먼트 공유". 목적은 인상적인 플레이 모먼트 공유로 align (전체 플레이/결과 공유 아님).
    • → 폴더 rename(-my-play-share-play-moment-share), PRD h1·Linear project 표기·UL term(Shared Play SnapshotShared Play Moment)·옵션 2 카피·§1.1 문제 정의 모두 모먼트(씬 범위) 중심으로 동기화.

Skip

(없음.)

모모 인라인 피드백 (criteria 후보)

  • "data agent로 확정" 같은 owner 모호 표기는 reject. 어떤 reference 데이터가 왜 필요한지까지 구체화해야 함. → prd-review-criteria.md의 "Placeholder 베이스라인" 항목에 흡수 반영(아래 참조).

2026-05-13 Dara 기준선 반영

채택

  • Q: §1.5 정량 목표를 어떤 기준선으로 채울 것인가.
    • A: Dara 정정 조회값(2026-04-15 ~ 2026-05-12)을 반영. 플레이 시작 267,400건 / 19,128명, 스크린샷 캡처 37,405건 / 1,246명, 기존 share_content 123건 / 63명. 기존 share_content는 플레이 시작 대비 0.046%, 유저 기준 0.33%라 죽은 지표로 보고 제외. 이 기능은 "완료 후 공유"가 아니라 "플레이 중 욕구 포착"이므로 기준 분모는 click_play_start.
    • → §1.4 가설, §1.5 성공 지표 업데이트. Moment 공유 유저율은 플레이 시작 유저의 2%+(약 383명+), Moment 공유 발생률은 플레이 시작의 0.5%+(약 1,337건+), viewer→플레이 시작 CTR 최소 8%/목표 12%+로 반영.

Skip

  • Q: 기존 share_content를 공유 기준선으로 쓸지.

    • 사유: 완료 씬 대비 0.005%로 너무 낮아 기존 공유 이벤트는 죽은 지표로 판단. PRD에는 명시적으로 기준선 제외.
  • Q: Moment 발행 수 denominator를 완료 씬 있는 플레이로 둘지.

    • 사유: 공유는 완료 씬이 없어도 가능하므로 완료 기준은 과소/왜곡. 발행률 denominator는 click_play_start 기준 플레이 시작 수로 변경.

모모 인라인 피드백 (criteria 후보)

(없음.)