Frontia Sprint Artifacts

Appearance

[앱/웹] 좋아요한 에피소드 모아보기 PRD ​

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

Status: draft Created: 2026-05-13 Last updated: 2026-05-13 Linear Project: [앱/웹] 좋아요한 에피소드 모아보기 (264f8bdd52d7) Author: agent (prd-writer) / momo 앱/웹/스튜디오: 앱 + 웹

1. 목표 및 배경 ​

1.1 문제 ​

  • 사용자 정의 (segment): 에피소드에 좋아요를 누른 적 있는 플레이어(앱·웹).
  • 상황 (when, where): 홈/검색/추천 surface에서 발견한 에피소드에 좋아요를 누른 뒤, 며칠 후 그 에피소드를 다시 듣거나 이어보고 싶을 때.
  • 불편 / 미충족 needs: 좋아요를 누른 에피소드를 본인 surface에서 다시 꺼낼 진입점이 없다. 좋아요가 일회성 반응으로 끝나 큐레이션 → 재소비 동선이 닫혀 있지 않다.

1.2 근거 ​

  • VOC / 백로그 시그널: Linear DEE-17(제품팀 백로그 분류본 A#23, source_rows 115) — "좋아요한 에피소드를 다시 찾아갈 진입점이 없다"는 의견이 반복적으로 나옴. 진입점은 [내 플레이] 탭으로 컨펌됨.
  • 도메인 사실 (Frontia wiki): EpisodeLike은 social-community 도메인의 production unique relation. 현재 좋아요 카운터 동기화 / 푸시 source 외에 유저 본인 surface에서 다시 노출하는 진입점이 없음.
  • 인접 데이터 포인트: EpisodePlay의 lastPlayedAt은 Continue notification(외부 푸시) source로 쓰이지만, 유저가 자기 의사로 다시 찾아 들어오는 in-app 동선은 빈약.
  • 데이터 (미수령): 좋아요 누른 유저 비율 / 인당 평균 좋아요 수 / 좋아요 후 동일 에피소드 재진입 비율은 현재 미측정. 데이터 agent 호출 필요(§7 참조).

1.3 아이디어 (해결 방향) ​

  • 옵션 1: [내 플레이] 탭 내부 영역으로 "좋아요한 에피소드"를 신설. 좋아요 단일 개념으로 큐레이션 surface 통합. (추천)
  • 옵션 2: 별도 "북마크/저장" 개념을 신규 도입해 좋아요와 분리.
  • 옵션 3: 에피소드 상세 화면에서만 "내가 좋아요한 에피소드 옆에 띄우기" 형태로 inline 노출.

추천 옵션과 이유: 옵션 1. 백로그 시그널의 핵심 페인은 "좋아요한 걸 다시 보고 싶다"로 명확해, *새 모델(북마크)*을 도입하는 학습 비용을 감수할 근거가 약하다. 좋아요를 공개적 반응 + 사적 큐레이션으로 의미 확장하여 한 모델로 흡수한다.

1.4 가설 ​

  1. 가설 A (1차 검증) — 좋아요한 에피소드를 본인 surface에서 다시 꺼내볼 수 있게 하면, 좋아요 목록 영역을 통한 동일 에피소드 상세 재진입이 유의미하게 발생한다.
  2. 가설 B (관찰) — 좋아요 모아보기 영역의 존재가 좋아요 누르기 행동 자체의 빈도/유저 비율도 함께 끌어올린다(좋아요에 "저장" 의미가 부여되기 때문).
  3. 가설 C (관찰) — [내 플레이] 탭의 방문 빈도와 체류가 증가한다.

1차 검증 대상은 A. B·C는 부수 신호로 관찰.

1.5 성공 지표 ​

베이스라인 미수령 — 임계값은 모두 베이스라인 받은 후 확정. 본 PRD에서는 측정 항목과 합/불 판단 절차만 정의.

지표현재목표측정 방법
좋아요한 에피소드 영역 노출률 (분모: [내 플레이] 진입)미측정베이스라인 후 결정view_my_play_likes / [내 플레이] 진입
영역 내 항목 클릭률미측정베이스라인 후 결정click_my_play_like_episode / view_my_play_likes
좋아요 목록 영역을 통한 동일 에피소드 상세 재진입률 (가설 A)미측정베이스라인 후 결정click_my_play_like_episode / view_my_play_likes, 분모는 unique profile×episode
좋아요 1개 이상 누른 유저 비율 / 인당 평균 좋아요 수 (가설 B)미측정before vs after 상승전체 활성 유저 분모
[내 플레이] 탭 진입 DAU / 진입률 (가설 C)미측정before vs after 상승전체 활성 유저 분모
  • 메인 지표: 좋아요 목록 영역을 통한 동일 에피소드 상세 재진입률 (가설 A 검증용).
  • 가드레일 지표 (관찰용):
    • 에피소드 좋아요 카운터(공개 반응 시그널) 총량 — 좋아요의 의미 변화로 누르기 자체가 줄지 않는지 관찰.
    • [내 플레이] 탭 외 다른 surface(홈/추천)의 진입률 — 카니발리제이션 가능성 관찰.
    • 현재 PRD에서는 실패 임계값을 별도 지정하지 않는다. 제품 맥락상 좋아요 목록이 기존 surface를 직접 대체하는 기능은 아니므로, 이상 하락이 관측될 때 분석팀/PM이 원인 확인하는 모니터링 지표로 둔다.

2. 타깃 사용자 ​

2.1 주요 사용자 ​

  • 에피소드에 좋아요를 1회 이상 누른 적 있는 플레이어(앱·웹).
  • 사용 빈도: 좋아요를 큐레이션 신호로 쓰는 활성 유저 — 좋아요한 에피소드를 며칠~몇 주 후에 다시 꺼내보고 싶을 때.
  • 세그먼트별 차이: 좋아요 0개인 신규/저참여 유저는 빈 상태 UX로 "기능을 가르치는" 역할 동시 수행.

2.2 핵심 시나리오 ​

  1. 재소비 (Happy path) — 좋아요 5~30개 누른 플레이어가 충분히 존재한다고 가정하고, 며칠 후 앱을 열어 [내 플레이] 탭에서 "좋아요한 에피소드" 영역의 항목을 탭해 에피소드 상세로 이동한다.
  2. 큐레이션 정리 — 좋아요 목록이 길어진 플레이어가 영역 안에서 좋아요를 해제해 본인 큐레이션을 줄인다. 오조작 시 토스트의 "되돌리기"로 복구.
  3. 신규/저참여 유저의 발견 — 좋아요 0개인 유저가 [내 플레이] 탭 상단 메뉴 리스트에서 "좋아요한 에피소드"를 발견하고, 빈 상태의 "추천 에피소드 보러가기" CTA로 홈 추천 영역으로 이동해 좋아요 행동을 시작한다.

3. 핵심 기능 요구사항 ​

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

좋아요한 에피소드 영역 — IA / 진입 ​

  • 주요 동작: 플레이어가 [내 플레이] 탭에서 자신이 좋아요한 에피소드를 한 곳에서 본다.
  • 비즈니스 룰:
    • 영역은 [내 플레이] 탭 내부 항목으로 신설. 별도 탭/페이지 신설 없음.
    • 노출 형태: [내 플레이] 탭 상단 메뉴 리스트 형태. 이번 범위에서 우측 상단 단독 아이콘 노출은 제외 (발견성이 낮음). 리스트 내 순서·아이콘 스타일은 디자인 단계에서 확정.
    • 영역 명칭(잠정): "좋아요한 에피소드". 카피 최종은 디자인 단계.
    • 상단 메뉴 리스트에서는 숫자 배지/카운트(예: 0개, N개)를 이번 범위에서 표시하지 않는다. 진입 후 빈 상태/목록 상태로 안내한다.
    • 가시성: 본인 전용 사적 surface. 타 유저·디렉터에게 노출되지 않음.
  • 진입 경로:
    1. 앱/웹 하단 또는 사이드 네비의 [내 플레이] 탭.
    2. [내 플레이] 상단 메뉴 리스트의 "좋아요한 에피소드" 항목.
    3. (후속 범위) 에피소드 상세 좋아요 토스트의 "내 플레이에서 보기" 액션.

목록 표시 / 정렬 / 페이지네이션 ​

  • 주요 동작: 좋아요한 에피소드들이 좋아요를 누른 시점 최신순으로 표시. 항목 탭 시 에피소드 상세로 이동.
  • 비즈니스 룰:
    • 기본 정렬: EpisodeLike.createdAt desc (좋아요 누른 시점 최신순). 근거: 백로그 시그널이 "최근에 좋아요한 걸 다시 찾는다"에 가까움. 에피소드 발행 시점 기준은 유저의 발견 행동과 어긋남.
    • 유저 토글: 이번 범위는 고정 단일 정렬. 토글 도입은 사용량 데이터 본 뒤 후속 결정.
    • 페이지네이션: 무한 스크롤. 초기 로드 1페이지.
    • 항목 탭 동작: 해당 에피소드 상세로 이동. 목록에서 직접 이어하기/처음부터를 분기하지 않는다.
  • 정렬/필터/페이지네이션: 정렬 1종 고정 / 필터 없음 / 무한 스크롤.
  • 상태별 동작:
    • 로그인: 본인의 EpisodeLike 목록 표시.
    • 비로그인: 앱은 비로그인 진입 자체가 차단되며, 웹에서도 [내 플레이] 탭은 비로그인 진입 불가. 본 영역 별도 분기 없음.
    • 데이터 없음(좋아요 0개): "빈 상태 UX" 절 참조.
    • 권한 없음: 본인 데이터만 노출이므로 권한 분기 없음.

좋아요 해제 (영역 내) ​

  • 주요 동작: 영역 내 항목의 좋아요 아이콘을 다시 눌러 큐레이션을 정리할 수 있다.
  • 비즈니스 룰:
    • 해제 시 즉시 목록에서 제거 (옵티미스틱 UI).
    • 해제 직후 토스트 1회 "좋아요 해제됨" + "되돌리기" 액션 노출 (3~5초 범위, 이번 범위에 포함). 되돌리기 누르면 해당 항목의 좋아요 상태 / 목록 표시 복구.
    • 서버 실패 시 옵티미스틱 롤백 + 에러 토스트.
    • 카운터 동기화는 social-community 표준 규칙 따름(에피소드 좋아요 카운터 -1).
  • 상태별 동작:
    • 네트워크 오류: 옵티미스틱 UI 롤백 + "다시 시도해 주세요" 토스트.

빈 상태 UX ​

  • 주요 동작: 좋아요 0개 유저에게 영역을 숨기지 않고 노출해 기능 발견성을 확보한다.
  • 비즈니스 룰:
    • 영역 노출 유지. 안내 카피: "좋아요한 에피소드가 아직 없어요" + 짧은 가이드 한 줄(예: "홈에서 마음에 드는 에피소드에 ♥ 눌러보세요").
    • CTA: "추천 에피소드 보러가기" — 홈 추천 영역으로 이동. 이번 범위에 포함.
    • 카피·CTA 스타일은 디자인 단계에서 상세화.

3-2. 어드민 ​

  • 본 PRD 범위 외. 어드민이 본인 좋아요 surface에 영향 주는 동작은 visibility 변경에 한정되며, 이는 기존 Trust & Safety / episode-content 표준을 inherit (별도 어드민 기능 신설 없음).

3-3. Scope ​

포함 (In scope) ​

  • 앱 + 웹 동시 첫 출시.
  • [내 플레이] 탭 상단 메뉴 리스트 형태 노출.
  • 좋아요 누른 시점 최신순 단일 정렬, 무한 스크롤.
  • 항목 탭 → 에피소드 상세 이동 (목록에서 이어하기/처음부터 직접 분기 없음).
  • 영역 내 좋아요 해제 + "되돌리기" 토스트 (이번 범위에 포함).
  • 빈 상태 UX 노출 + "추천 에피소드 보러가기" CTA (이번 범위에 포함).
  • visibility 규칙 inherit (episode-content / trust-safety / social-community).
  • 신규 로깅 이벤트 + 기존 이벤트 entry_point 표준화.

제외 (Out of scope) ​

  • 별도 북마크/저장 신규 개념 도입 (좋아요 단일 모델로 통합).
  • 최근 본 에피소드 영역 (별 트랙).
  • 좋아요한 에피소드의 공개·공유 (타 유저가 내 좋아요 목록을 보는 것).
  • 좋아요 폴더/태그/카테고리.
  • 좋아요 모아보기 기반 푸시 알림 트리거 (별 트랙).
  • 정렬 유저 토글 (이번 범위는 단일 정렬 고정).
  • 우측 상단 단독 아이콘 노출 (이번 범위에서는 제외, 상단 메뉴 리스트로 충분).
  • 에피소드 상세 좋아요 토스트의 "내 플레이에서 보기" CTA (후속 확장 후보).

4. 에러 처리 및 예외 상황 ​

상황처리 방향
좋아요한 에피소드가 비공개·발행 취소됨목록에서 자동 숨김(좋아요 row 유지). 발행 복귀 시 자동 재노출. (바로 사라지지 않고 썸네일을 클릭하여 들어갔을 때 비공개/취소된 에피소드임을 알려주는 현재 형태와 통일해도 상관없음)
좋아요한 에피소드가 영구 삭제됨목록에서 영구 숨김. 좋아요 row는 social 표준 cascade 따름. (바로 사라지지 않고 썸네일을 클릭하여 들어갔을 때 삭제된 에피소드임을 알려주는 현재 형태와 통일해도 상관없음)
admin 운영 차단 / report visibility 제한trust-safety 표준 visibility 규칙대로 숨김 (조용히 숨김 아님 — QA 시나리오에 포함).
본인이 ProfileBlock한 디렉터의 에피소드Discovery 표준 visibility 따름(숨김).
좋아요 해제 → 서버 실패옵티미스틱 UI 롤백 + 에러 토스트. 카운터 정합성은 표준 동기화 규칙.
네트워크 오류 (목록 로드)재시도 가능한 에러 상태 + 다시 시도 액션.
좋아요 0개빈 상태 UX (영역 노출 유지) + "추천 에피소드 보러가기" CTA.
데이터 결손 (썸네일/제목 누락)episode-content 표준 fallback (placeholder, "(제목 없음)").
페이지네이션 끝 도달더 이상 항목 없음 상태로 자연 종료.

5. 데이터 분석 ​

5.1 핵심 지표 ​

  1. 좋아요 목록 영역을 통한 동일 에피소드 상세 재진입률 (가설 A 메인): 좋아요 목록 영역에서 항목을 클릭해 동일 에피소드 상세에 진입한 비율. 분모는 unique profile×episode 및 영역 노출(view_my_play_likes) 기준으로 분석팀과 확정. 이번 기능 효과 귀인을 위해 모든 경로 재진입이 아니라 좋아요 목록 영역 경유만 메인으로 본다.
  2. 영역 사용률 (leading): view_my_play_likes / [내 플레이] 탭 진입.
  3. 영역 항목 클릭률 (leading): click_my_play_like_episode / view_my_play_likes.
  4. 좋아요 행동 빈도 (가설 B, 관찰): 전체 활성 유저 중 좋아요 1개 이상 누른 유저 비율 / 인당 평균 좋아요 수.
  5. [내 플레이] 탭 진입 (가설 C): 진입 DAU / 진입률.

분모 함정 주의: "좋아요 목록 영역을 통한 동일 에피소드 상세 재진입률"의 분모를 전체 좋아요 row가 아니라 유저-에피소드 unique와 영역 노출 기준으로 잡는다. 헤비 좋아요 유저 편향 방지. self-selection 한계: "좋아요를 누른 유저"는 활성 유저로 자기-선택된 코호트라, cross-user 비교(좋아요한 사람 vs 안 한 사람)는 인과 식별 불가. 비교는 시간 기반 before/after로만 유효. A/B 미사용: 분배 매커니즘 없이 시간 기반 비교로 충분. feature flag는 클라이언트 표준 점진 롤아웃에서만 사용.

5.2 로깅 이벤트 ​

컨벤션: snake_case, 동사_명사 패턴 (event-docs.frontia.dev).

타입이름용도파라미터비고
Eventview_my_play_likes영역 노출/스크롤 진입 시점 측정item_count(int)신규. placement는 이벤트명 자체가 영역을 포함하므로 중복이라 제외. is_empty는 item_count=0으로 판별 가능해 제외.
Eventclick_my_play_like_episode영역 내 항목 클릭episode_id, episode_title신규
Eventclick_my_play_likes_empty_cta빈 상태 "추천 에피소드 보러가기" CTA 클릭cta_target(home_recommend 등)신규
Eventview_episode_detail (기존)영역에서 항목 클릭으로 진입 시에도 호출entry_point에 my_play_likes 추가기존 확장

6. Ubiquitous Language ​

본 PRD에 신규/변경되는 도메인 용어 없음. Episode Like 등 기존 용어는 Frontia wiki UL(wiki/foundation/ubiquitous-language.md)을 그대로 따른다.

본 PRD 내부 약속어 (UL 비등재):

  • "좋아요한 에피소드" 영역 = 본 PRD가 [내 플레이] 탭 내에 추가하는 신규 섹션. 화면 영역 이름이라 UL 비등재.
  • "되돌리기 토스트" = 좋아요 해제 직후 3~5초 노출되는 1회성 토스트의 액션. 컴포넌트 이름이라 spec/디자인 시스템 영역.

7. Open Questions ​

  • [ ] 베이스라인 수치 수령 — 분석팀(데이터 agent): 좋아요 1개 이상 누른 유저 비율 / 인당 평균 좋아요 수 / 좋아요 목록 영역을 통한 동일 에피소드 상세 재진입률 / [내 플레이] 탭 진입률. 받은 후 §1.5 임계값 확정.
  • [ ] 인접 항목 머지 검토 시점 — PM: 추후 "북마크/저장" 또는 "최근 본 에피소드"가 등장하면 별 영역으로 두는지 통합하는지. 첫 출시 후 검토.

부록: 메타 정보 ​

Required artifacts ​

  • [x] Spec (needs-spec) — 화면별 컴포넌트·상태·인터랙션 명세 (영역 노출 형태, 빈 상태, 되돌리기 토스트 디테일).
  • [x] Design (needs-design) — Figma 화면 시안 ([내 플레이] 상단 메뉴 리스트, 영역 카드, 빈 상태 + CTA, 해제 토스트).
  • [ ] QA scenarios (needs-qa-scenarios) — Sprint planning에서 작성.
  • [ ] Migration plan (needs-migration) — 데이터 모델 신규/변경 없음.
  • [x] Tracking events (needs-tracking) — 신규 이벤트 + 기존 이벤트 entry_point 표준화.
  • [ ] 기타: —

Size & Risks ​

T-shirt Size ​

  • Size: S~M (앱+웹 동시, 클라이언트 신규 섹션 1개, 로깅 다건).
  • Confidence: medium.
  • 추정 근거: 데이터 모델 신규 없음(EpisodeLike 재사용), visibility 규칙 inherit, 인접 도메인 영향 적음. 앱+웹 동시 출시가 비용을 끌어올림.

의존성 ​

  • 다른 작업: 없음(독립 출시 가능).
  • 다른 팀: 분석팀(이벤트 컨벤션 합의, 베이스라인 수령). 디자인([내 플레이] 상단 메뉴 리스트 상세).
  • 외부 요인 (API, 라이브러리): 없음. social-community / episode-content / trust-safety 표준 visibility 헬퍼 재사용.

References ​

  • 관련 데이터 대시보드: (베이스라인 수령 후 추가)
  • 관련 위키 문서:
    • wiki/foundation/ubiquitous-language.md (Episode Like 정의)
    • wiki/social-community/capabilities.md (EpisodeLike unique relation)
    • wiki/foundation/의 trust-safety / discovery visibility 규칙
  • 외부 레퍼런스: 로깅 컨벤션 — https://event-docs.frontia.dev/
prd-review 보기

Review log ​

2026-05-13 — prd-review ​

채택 ​

  • Q1 메인 지표 귀인
    • A: 메인 지표는 모든 경로 재진입이 아니라 좋아요 목록 영역을 통한 동일 에피소드 상세 재진입으로 본다.
    • → PRD §1.4, §1.5, §5.1 수정.
  • Q4 happy path 유저 규모
    • A: 좋아요 5~30개 유저가 충분하다고 가정한다.
    • → PRD §2.1/§2.2에 가정 반영.
  • Q5 항목 탭 동작
    • A: 목록에서 이어하기/처음부터를 직접 분기하지 않고 에피소드 상세로 이동한다.
    • → PRD §2.2, §3-1, §3-5 수정.
  • Q6 빈 상태 진입 동선
    • A: 상단 메뉴 리스트에 숫자/카운트 표시는 필요 없다.
    • → PRD §3-1에 숫자 배지/카운트 미표시 명시.
  • Q7~Q13 문서 청소
    • A: 중복·메타·일반 디자인/spec 작업은 본문에서 정리한다.
    • → PRD §3-5, §6, §7, 부록, 검토 필요 섹션 정리.

보류 / 설명 필요 ​

  • Q14 가드레일 임계 정책
    • A: momo가 맥락 이해가 어렵다고 답변.
    • 처리: 좋아요 카운터/타 surface 진입률은 실패 임계값이 아니라 관찰용 가드레일로 낮추고, 이상 하락 시 PM/분석팀 확인으로 정리.

Skip ​

  • 없음.

추가 피드백 반영 ​

  • 용어: v1 표현은 PM 문서에서 모호하므로 이번 범위, 후속 범위, 첫 출시로 치환.
  • 구조: 3-3. 백엔드 / 시스템 섹션은 PRD 단계에서 불필요한 구현/시스템 설명이라 통째로 삭제. 이후 딥링크/Scope 섹션 번호 재정렬.

2026-05-13 — 추가 피드백 반영 (2차) ​

채택 ​

  • 비로그인 진입 정책 명확화
    • A: 앱은 비로그인 진입 불가, 웹의 [내 플레이]도 비로그인 진입 불가.
    • → PRD §3-1 상태별 동작 갱신, §4 "비로그인 진입" 행 삭제.
  • 딥링크 / URL 구조 섹션 불필요
    • A: PRD §3-3 딥링크 섹션 전체 삭제. 이후 §3-4 → §3-3 (Scope) 번호 재정렬.
  • §4 비공개·취소/영구 삭제 행 안내 보강
    • A: "바로 사라지지 않고 썸네일을 클릭하여 들어갔을 때 비공개/삭제된 에피소드임을 알려주는 현재 형태와 통일해도 상관없음" 부연을 두 행에 추가.
  • §5.2 로깅 이벤트 정리
    • A: view_my_play_likes_empty, click_my_play_like_toggle, toggle_episode_like 행 삭제.
    • A: click_my_play_like_item → click_my_play_like_episode 이름 변경 (전역).
    • A: click_episode (기존) → view_episode_detail (기존)으로 치환.
  • §5.2 "분석팀 합의 필요" 블록 전체 삭제
    • A: §5.2 본문 quote의 "정확한 props는 분석팀 합의 필요" 문구 및 하단 합의 항목 3개 모두 제거.
    • → §7 Open Questions의 로깅 컨벤션 합의 항목도 함께 정리.
  • §6 UL — Episode Like 행 + 의미 확장 노트 삭제
    • A: PRD-template 기준 "본 PRD에 신규/변경되는 도메인 용어"만 등재. Episode Like는 wiki UL을 그대로 따르고 본 PRD에서 의미를 새로 신설/변경하지 않으므로 비등재.
    • → UL 표 자리에 "신규/변경 용어 없음" 한 줄로 대체. 내부 약속어 노트만 유지.
  • Size & Risks "주요 위험 요소" 표 삭제.
  • "🔍 검토 필요" 섹션 전체 삭제 (외부 agent 호출 안내는 PRD 본문 §1.2 / §7 Open Questions로 충분).

부수 정리 ​

  • §1.2 데이터(미수령) 각주 cross-ref에서 "🔍 검토 필요" 제거 → "§7 참조"로 단축.
  • §1.3 추천 옵션 이유 끝의 "(트레이드오프는 §6 D1)" 제거 — D1 표기 부재.
  • §3-3 (구 §3-4) Scope: "좋아요 단일 모델로 통합 — D1" → "좋아요 단일 모델로 통합". "로깅 이벤트 5종" → "로깅 이벤트"로 단축, 표준화 대상에 entry_point 추가.
  • 부록 Tracking events 라인도 동일 표현으로 통일.
  • Size 추정 근거의 "로깅 5종" → "로깅 다건".

2026-05-13 — 추가 피드백 반영 (3차) ​

채택 ​

  • BE 설계 문구 제거
    • A: PRD 본문에서 BE 관련 설계 문구는 모두 삭제.
    • → §3-1 페이지네이션 "(BE 합의)" 삭제, "정렬/필터/페이지네이션" 요약에서 "(20~30)" 삭제, Size & Risks의 "신규 API 1개 또는 기존 확장" 문구 삭제.
  • click_my_play_like_episode 파라미터 축소
    • A: episode_id, episode_title만 남기고 position, liked_at, placement 삭제.
    • → §5.2 표 반영. §1.5/§5.1의 메인 지표 정의는 episode_id 기준 unique profile×episode로 여전히 측정 가능 — 별도 수정 불필요.

Skip ​

  • "event-docs 그룹 매핑" 질문
    • 사유: 모모가 맥락을 잡기 어렵다 응답. PRD 본문/OQ에 남기지 않고 미반영 처리.