알림센터 (인앱 히스토리·읽음/안읽음) PRD

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

---

Status: draft Created: 2026-05-21 Last updated: 2026-05-21 Linear Project: [앱/웹] 알림센터 (인앱 히스토리·읽음/안읽음)Linear Issue (PRD writing): DEE-76 Author: agent (prd-writer) / momo 앱/웹/스튜디오: 앱 + 웹 (스튜디오 제외)

---

1. 목표 및 배경

1.1 문제

푸시 알림은 발송되지만, 인앱에 알림을 모아 다시 볼 surface가 없다. 푸시를 놓치거나 무심코 스와이프해 지우면 복구 경로가 사라지고, 어떤 알림을 이미 확인·처리했는지 추적도 안 된다.

• 사용자 정의 (segment):
  • 디렉터(작품 운영자): 자기 작품에 달린 댓글/반응 알림을 신경 써서 따라가는 사람.
  • 일반 유저: 댓글/답글, 좋아요·반응, 팔로우, 팔로우한 디렉터의 새 작품, 공지사항 알림을 받는 사람.
• 상황 (when, where):
  • 디렉터가 작품마다 들어가 새 댓글이 달렸는지 일일이 확인.
  • 알림이 와도 푸시 알림창에서 사라지면 인앱에서 다시 볼 수 없음.
  • "어제 뭐 알림 왔었는데?" 같은 회상이 안 되고, "이미 본 알림인지 모르겠어서 또 들어감" 케이스 발생.
• 불편 / 미충족 needs:
  • 알림 누락 복구 불가능
  • 이미 본 알림 vs 안 본 알림 구분 불가능
  • "내가 신경 써야 할 게 어디 있는지" 한눈에 보는 surface 없음

1.2 근거

• VOC: 디렉터들이 "댓글 알림 놓치면 끝", "내 작품에 뭐가 달렸는지 일일이 보러 다닌다" 류 발언 (Discord — issue seed 인용).
• 일반 알림 관련 인접 작업: DEE-41 알림 종류 on/off + 푸시 권한(taxonomy 정의).
• 유사 product 패턴: 인스타그램 활동 탭, 디스코드 inbox, GitHub notifications — 모두 "푸시는 알림, 인앱은 inbox" 분업이 표준.

⚠️ 정량 데이터(알림 종류별 발송량, 알림 누락 VOC 빈도)는 데이터 agent 호출 필요 — §🔍 검토 필요 참조.

1.3 아이디어 (해결 방향)

푸시 = 'now' 신호, 알림센터 = 'inbox / 히스토리'로 역할을 분리. 댓글/좋아요·반응/팔로우/팔로우한 디렉터의 새 작품은 실제 푸시 대상이지만, 유저가 푸시 알림을 꺼도 알림센터에는 적재된다. 공지사항은 푸시로 보내지 않고 알림센터에만 적재한다. 알림센터는 인앱 진입점(상단 종 모양 아이콘 후보)에서 열고, 종류별/통합 리스트로 본다.

• 옵션 A — 상단 종 모양 진입점 + 단일 리스트 (추천): 표준 패턴, 디스커버리 비용 낮음. 종 모양에 unread 뱃지.
• 옵션 B — 별도 바텀 탭 1칸 확보: 디스커버리 최강이지만 바텀 탭이 이미 포화(Home/Play/My). 신중.
• 옵션 C — MY 탭 안 sub-entry: 디스커버리 약함. 알림센터를 일등 surface로 보기엔 부족.

본 PRD는 옵션 A를 기본 가정으로 진행하되, 진입점 위치 자체는 §7 Open Questions로 남긴다(디자인 단계에서 확정).

전략 컨텍스트: 알림센터는 이미 만들어진 return hook을 증폭·복구하는 surface지 D1 retention의 본체가 아님. 본 PRD 범위는 "지난 알림을 다시 볼 수 있게 한다 + 읽음 상태로 처리 흐름을 명확히 한다"에 한정.

1.4 가설

1. 디렉터는 알림센터에서 작품별 댓글 알림을 모아보면, 작품을 일일이 순회하지 않게 되어 응대 누락이 줄어든다.
2. 일반 유저는 푸시를 놓쳐도 인앱에서 회수할 수 있어, "알림 받았는데 복구 불가" 류 불만이 줄어든다.
3. 읽음/안읽음 상태가 있으면, 유저가 "처리 안 된 것"에 집중해 알림 처리 효율이 올라간다(전체 발송 대비 클릭 전환율 ↑).

1.5 성공 지표

지표	현재	목표	측정 방법
알림 → 상세 진입 전환율(푸시 단독 / 푸시+알림센터 합산)	(TBD)	푸시 단독 대비 +X%p	receive_* / click_* 이벤트 비교
알림센터 주간 활성(열어본 유저 / 푸시 수신 유저)	0	의미 있는 base rate(TBD)	view_notification_center event
디렉터 작품 댓글 응대 latency(P50)	(TBD)	-X%	댓글 작성 → 디렉터 응답까지 시간

• 메인 지표: 알림센터 주간 활성 비율 + 알림 → 상세 진입 전환율 변화
• 가드레일 지표:
  • 푸시 발송량 자체에는 변화 없음(알림센터 도입이 푸시 정책을 바꾸지 않음)
  • 알림센터 도입으로 인한 앱 로딩 지연 없음(P95 응답 시간)

---

2. 타깃 사용자

2.1 주요 사용자

• 디렉터: 자기 작품에 달린 댓글·반응 알림이 핵심. 알림센터를 자주 열고 "내 작품" 필터로 본다.
• 일반 플레이 유저: 댓글/답글, 좋아요·반응, 새 팔로워, 팔로우한 디렉터의 새 작품, 공지사항 알림을 가볍게 훑어보는 사람.

2.2 핵심 시나리오

1. 디렉터가 외출 중 푸시 알림을 못 봤다 → 저녁에 앱 켜서 종 모양 뱃지 보고 알림센터 진입 → 자기 작품 댓글 5건이 쌓여 있는 걸 한 번에 확인 → 각 댓글로 deep-link 이동해 응답.
2. 일반 유저가 팔로우한 디렉터의 새 작품 알림을 받았는데 무심코 스와이프 → 인앱 진입해서 알림센터에서 새 작품 항목을 발견 → 탭해서 작품 상세로 이동, 자동으로 읽음 처리.
3. 유저가 알림센터를 열어 unread만 빠르게 훑고 "모두 읽음" 처리 → 이후 다시 들어왔을 때 새 unread만 다시 보임.

---

3. 핵심 기능 요구사항

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

진입점 & 글로벌 red dot

• 주요 동작: 인앱 헤더(상단) 종 모양 아이콘 → 탭 시 알림센터 화면 진입. 종 모양 위에 unread red dot 표시.
• 비즈니스 룰:
  • 진입점은 Home 헤더만 사용. Play / My / 기타 surface, 풀스크린 플레이 화면 등에선 노출 안 함(spec에서 확정).
  • 진입점 red dot: 인앱 unread 존재 여부 = read=false 알림이 1건 이상이면 노출. 숫자 카운트는 MVP 범위 아님.
  • 비로그인 상태: 진입점 자체를 숨김(또는 탭 시 로그인 유도) — §7 Open Questions.
• 상태별 동작:
  • unread = 0: 종 모양만, red dot 없음
  • unread > 0: 종 모양에 red dot 노출
  • 비로그인: 노출 정책 — §7

알림센터 화면

• 주요 동작: 시간 역순 리스트. 각 항목은 (아이콘/썸네일 + 타이틀 + 본문 요약 + 시각 + read/unread 시각 표시).
• 비즈니스 룰:
  • 정렬: 최신순(생성 시각 desc). 페이지네이션 또는 무한 스크롤.
  • 읽음 처리 트리거 (Default 가정):
    • 리스트에서 해당 항목이 노출(impression)되면 read=true 처리 — "푸시를 본 적 있어도 인앱에서 한 번 더 보면 read로 간다"는 가장 표준적 모델.
    • 단, "노출 = read"는 디렉터가 알림센터를 한 번 슥 열어본 것만으로 모든 댓글이 read 처리돼서 "처리해야 할 것"을 잃어버리는 부작용 가능 → §7 Open Question.
    • 대안: 노출은 "seen", 탭(click)이 "read". seen/read 2-state는 복잡도 증가.
  • 알림 항목 모델 (3-3 참조): 각 항목은 type, payload, deep-link, created_at, read_at을 가진다.
  • 그룹핑: 동일 source(예: 같은 에피소드에 여러 댓글)는 1건으로 묶어 "댓글 3개" 식으로 합치는 것이 표준. 본 PRD에서는 MVP는 그룹핑 없이 flat list로 시작. 그룹핑은 v2.
  • 필터/탭: MVP는 단일 리스트(필터 없음). "댓글만", "내 작품만" 같은 필터는 v2.
  • 액션: 항목 탭 시 deep-link로 이동(자동 read 처리). 알림센터 내 inline action(예: 댓글 답글 작성, 좋아요 즉시 답방)은 MVP 범위 외.
  • 벌크 액션: "모두 읽음" 버튼 제공. "전체 삭제"는 v2.
• 정렬/필터/페이지네이션:
  • 최신순, page size 20~30(spec에서 확정), 무한 스크롤
• 상태별 동작:
  • 데이터 없음(알림 0건): empty state ("아직 알림이 없어요" 류)
  • 비로그인: 알림센터 진입 차단 또는 로그인 유도
  • 권한 없음: 해당 없음(알림센터는 본인 알림만 봄)
  • 삭제된 리소스(예: 알림 항목의 대상 에피소드가 삭제됨) → 탭 시 "삭제된 콘텐츠" 안내 후 상위 화면

알림 항목 타입 (MVP 포함 타입)

아래 타입을 MVP 포함 범위로 확정한다. 실제 발송 이벤트명·payload는 DEE-41 taxonomy와 align한다.

• 댓글: 내 작품/내 댓글에 새 댓글/답글
• 좋아요·반응: 내 작품/댓글에 좋아요
• 팔로우: 새 팔로워
• 팔로우한 디렉터의 새 작품: 내가 팔로우한 디렉터가 새 작품을 공개/업로드
• 공지사항: 점검, 이벤트, 공지사항

MVP 알림 타입에서 DM, 보상(일일 미션/가입 보상/정산 등), 추천("이 작품 어때요?" 류)은 제외한다. 해당 항목은 별도 PRD/정책에서 필요성이 확정될 때 후속으로 추가한다.

실제 푸시가 가는 타입은 댓글 / 좋아요·반응 / 팔로우 / 팔로우한 디렉터의 새 작품이다. 단, 유저가 OS 또는 앱에서 푸시 알림을 꺼도 해당 이벤트는 알림센터에 적재된다. 공지사항은 푸시로 보내지 않고 알림센터에만 적재한다.

시각적 표시 (종 모양 + 뱃지)

• 종 모양 아이콘 + red dot(읽지 않은 알림이 1건 이상 있을 때)
• 각 알림 항목에도 read=false일 때 red dot 표시
• read=true 항목은 red dot 제거 + 시각적 강조 해제

3-2. 어드민

알림센터는 본인 알림만 표시. 어드민 추가 기능 없음 — 단, 공지사항/이벤트 알림을 알림센터에 적재하는 발행 경로는 필요하다. 공지사항은 푸시 발송 대상이 아니며 알림센터 전용 항목으로 처리한다.

3-3. 시스템 룰 (PRD 수준)

• 알림센터 적재 원칙: 댓글/좋아요·반응/팔로우/팔로우한 디렉터의 새 작품 이벤트는 푸시 권한/수신 설정과 무관하게 알림센터에 적재된다. 푸시는 허용된 유저에게만 best-effort로 발송한다. 공지사항은 알림센터 only로 적재한다.
• 보관 기간: 기본 90일 가정.
• 읽음 상태 동기화 규약:
  • 알림센터에서 항목 탭 → read=true
  • "전체 읽음" 액션

데이터 모델 필드·persist 지점·FCM/APNs 경로 분리 등 구현 세부는 spec 단계 / BE 설계로 이관.

3-4. 딥링크 / URL 구조

알림센터는 각 알림 type별로 기존 deep-link 규칙을 재사용:

알림 type	탭 시 이동
댓글	/episode/:episodeId/comments(해당 댓글로 스크롤 — payload에 commentId)
좋아요	대상 entity (/episode/:episodeId 또는 /user-profile/:profileId)
팔로우	/user-profile/:profileId
팔로우한 디렉터의 새 작품	/episode/:episodeId 또는 작품 상세
공지사항	공지 상세(웹뷰) 또는 인앱 안내

• 알림센터 자체 진입 deep-link: 신규 필요 — 예: /notification-center. 푸시 자체가 알림센터로 이동시키는 케이스는 없음(푸시는 곧장 해당 entity로). 하지만 외부에서 알림센터를 열어야 할 케이스(예: 공지사항에서 "전체 알림 보기" 안내)는 가능. — §🚨 신규 path 결정
• 앱 미설치 시 fallback: 마켓
• 비로그인 접근: 알림센터 자체는 본인 알림 surface라 로그인 필수 — §7

3-5. Scope

포함 (In scope)

• 인앱(앱+웹) 상단 진입점 + unread red dot
• 알림센터 화면(단일 리스트, 최신순, 무한 스크롤)
• 알림 항목 read/unread 상태 + "모두 읽음" 액션
• 댓글/좋아요·반응/팔로우/팔로우한 디렉터의 새 작품 이벤트의 알림센터 적재(푸시 권한 off여도 적재)
• 공지사항 알림센터 only 적재
• 항목 탭 → 기존 deep-link로 이동 + 자동 read 처리
• 보관 기간 정책(기본 90일 가정)
• 신규 deep-link path /notification-center(정의 필요)

제외 (Out of scope)

• 알림센터 내 inline action(댓글 답글 작성, 좋아요 즉시 답방 등) — v2
• 그룹핑(같은 대상에 여러 알림 합치기) — v2
• 알림 타입별 필터/탭 — v2
• 항목 개별 삭제 / 전체 삭제 — v2
• 알림 종류 on/off 설정 UI — DEE-41에서 처리(본 PRD는 taxonomy를 사용만 함)
• 스튜디오 어드민에서의 알림센터 — 별도
• 푸시 발송 정책 변경(어떤 알림을 보낼지/말지) — 본 PRD는 푸시 발송 여부가 아니라 알림센터 적재/읽음 처리를 정의

---

4. 에러 처리 및 예외 상황

상황	처리 방향
알림센터 fetch 실패	재시도 가능한 에러 UI, 캐시된 마지막 데이터 표시
알림 탭했는데 대상 리소스 삭제됨	"삭제되었거나 접근할 수 없는 콘텐츠" 안내 후 상위 화면, 알림 자체는 read 처리
알림 탭했는데 비공개/권한 변경	"접근할 수 없음" 안내
푸시 발송과 알림센터 적재 중 한쪽만 실패	알림센터 적재가 source of truth(푸시는 best-effort)
red dot 표시와 실제 unread 상태가 다름	알림센터 진입 시 서버 unread 상태로 재동기화
보관 기간 초과 항목 탭(cache로 남아있는 경우)	"오래된 알림은 더 이상 표시되지 않아요"
비로그인 진입	진입점 숨김 또는 로그인 유도(§7)
알림 타입이 클라이언트에서 인식 불가(앱 버전 차이)	fallback 표시("새로운 알림이 있어요") + deep-link만 시도

---

5. 데이터 분석

5.1 핵심 지표

1. 알림센터 진입율: MVP 알림 발생 유저 중 알림센터 진입 유저 비율(DAU 기준)
2. 알림 → 상세 진입 전환율(인앱 경로): 알림센터에서 항목 탭 → 대상 화면 진입율
3. Unread 소진율: 진입 시 unread count vs 진입 후 unread count 비율
4. 디렉터 댓글 응대 latency: 댓글 작성 시각 → 디렉터 첫 응답 시각(가드레일 + 가설 1 검증)

5.2 로깅 이벤트

event-docs.frontia.dev 기존 그룹·이벤트 재사용 우선. 본 PRD에선 신규 그룹 notification_center 신설 가정으로 작성. 기존 그룹(예: push, notification 등) 존재 여부 확인 필요 — §🔍 검토 필요.

타입	이름	용도	파라미터	그룹	상태
Event	view_notification_center	알림센터 화면 진입	has_unread, entry_source(home)	notification_center	🆕 신규 (또는 기존 매핑)
Event	click_notification_item	알림 항목 탭	notification_type, notification_id	notification_center	🆕
Event	click_mark_all_read	모두 읽음 액션	unread_count_before	notification_center	🆕

기존 푸시 receive_* / click_* 이벤트는 그대로 유지하고, 알림센터 경로는 별도 이벤트로 분리하여 비교 가능하게 한다. 진입 출처 파라미터명은 기존 로깅 컨벤션에 맞춰 entry_source를 사용하며, MVP 값은 home만 둔다.

---

6. Ubiquitous Language

Term	Korean	Definition	Do Not Confuse With	Primary Domain	상태
Notification Center	알림센터	인앱에서 알림 히스토리·읽음 상태를 모아보는 surface	Push Notification(전송 채널), 공지사항 목록	Notification	신규
Notification Item	알림 항목	알림센터에 적재되는 단위 record(id, type, payload, read_at)	Push payload	Notification	신규
Read / Unread	읽음 / 안읽음	알림 항목의 사용자 인지 상태. read_at != null = read	seen(노출만), OS 푸시 확인 여부	Notification	신규
Notification Red Dot	알림 레드닷	글로벌 헤더 종 모양 및 각 알림 항목에 표시되는 unread 존재 표시	숫자 카운트 뱃지, App icon badge(OS 레벨)	Notification	신규

Ubiquitous Language wiki 등재는 spec/구현 단계에서 확정 — Frontia wiki 동기화 필요.

---

7. Open Questions

• [ ] 진입점 위치 — 상단 종 모양 / MY 탭 sub-entry / 별도 바텀탭 중 어느 것? → 디자이너 + momo
• [ ] 읽음 처리 트리거 — 노출(impression)이 read인가, 탭(click)이 read인가? seen/read 2-state는 도입할 가치가 있나? → momo + 디자이너 (디렉터 케이스 부작용 검토)
• [ ] 보관 기간 — MVP 포함 타입에 90일이 적절한가? 무제한? 30일? → momo + 백엔드
• [ ] 그룹핑 MVP 도입 여부 — flat list로 시작 vs 같은 entity 묶기. 디렉터 케이스에선 그룹핑이 필수일 수도 → momo + 디자이너
• [ ] 비로그인 진입점 정책 — 종 모양 숨김 / 탭 시 로그인 유도 / 회색 처리? → 디자이너
• [ ] 신규 deep-link path — /notification-center 정의 필요. 푸시에서 알림센터로 직접 보내는 케이스가 있나? → 개발자 + momo
• [ ] 알림 타입 payload — MVP type은 댓글/좋아요·반응/팔로우/팔로우한 디렉터의 새 작품/공지사항으로 확정. 댓글/좋아요·반응/팔로우/팔로우한 디렉터의 새 작품은 푸시 대상, 공지사항은 알림센터 only. 각 type의 실제 발송/적재 이벤트명과 payload를 DEE-41 taxonomy 정의와 align → 데이터 + DEE-41 owner
• [ ] 로깅 이벤트 그룹 — event-docs.frontia.dev에 기존 notification 류 그룹이 있나? 재사용 가능한 이벤트? → PM (Cloudflare Access)
• [ ] 앱 vs 웹 우선순위 — 앱부터 / 동시 출시 / 웹은 v2? → momo
• [ ] 알림 항목 inline action 향후 로드맵 — MVP 외이지만 v2 시점/우선순위 합의 → momo

---

부록: 메타 정보

Required artifacts

• [x] Spec (needs-spec) — 진입점/리스트/뱃지 컴포넌트 상태·인터랙션
• [x] Design (needs-design) — 종 모양 + 알림 항목 + 빈 상태 + read/unread 시각 차이
• [x] QA scenarios (needs-qa-scenarios) — 읽음 동기화 / 보관 기간 / deep-link 회귀 케이스
• [x] Migration plan (needs-migration) — Notification item table 신설(기존 푸시 발송 로그 재활용 여부도 검토)
• [x] Tracking events (needs-tracking) — 신규 notification_center 그룹 이벤트

Size & Risks

T-shirt Size

• Size: M (서버 데이터 모델 신설 + MVP 포함 알림 이벤트 적재 hook + 새 화면 + 앱/웹 양쪽)
• Confidence: medium
• 추정 근거: 새 entity + MVP 포함 알림 이벤트 적재 경로 touch. 비슷한 패턴(인스타 활동 탭, 깃허브 알림함) 다수 — UI 자체는 잘 알려진 영역.

주요 위험 요소

위험	영향	대응
MVP 포함 알림 이벤트에 알림센터 적재 hook 누락 발생	일부 알림이 알림센터에 안 뜸 → 신뢰 무너짐	이벤트 인벤토리 + 공통 wrapper로 단일 지점화
MVP 알림 type 풀 목록이 DEE-41 taxonomy와 어긋남	taxonomy 갱신 시 본 기능에 영향	DEE-41과 동시/직후 일정 정렬, taxonomy 의존

의존성

• 다른 작업:
  • DEE-41 알림 종류 on/off(taxonomy + 푸시 권한) — 알림 type 정의를 공유
  • 조건별 푸시 PRD(deployed) — 기존 푸시 대상 타입의 발송 path 참고
• 다른 팀: 데이터팀(알림 발송량 baseline 데이터)
• 외부 요인: FCM/APNs(푸시 발송)은 변경 없음

References

• 관련 위키 문서: Frontia UL wiki wiki/foundation/ubiquitous-language.md (Notification 도메인 — 추가 필요)
• 관련 Linear 이슈:
  • 본 프로젝트: [앱/웹] 알림센터 (인앱 히스토리·읽음/안읽음) (DEE-76)
  • DEE-41 [앱/웹] 알림 종류 on/off (taxonomy + 푸시 권한)
  • DEE-39 알림 켜기 유도(미선택), DEE-59 인앱푸시(미선택)
• 관련 PRD (sprint-artifacts):
  • deployed/2026-03-03_조건별 푸시 PRD.md
  • deployed/2026-03-04_푸시 허용 유도 모달 PRD.md
  • deployed/2026-03-24_플레이 이어하기 푸시 PRD.md
• 외부 레퍼런스: Instagram Activity Tab, Discord Inbox, GitHub Notifications, Slack Activity

prd-review 보기

PRD Review log — notification-center

2026-05-21

Reviewer: prd-reviewer subagent + 메인 agent 판정. Walk-through 모드 아닌 batch 리뷰 (모모 grilling 전 클린업 + 결정 필요 항목 정리).

채택 (criteria-mandated, low-risk patch)

• §2.1 빈도 추정 "1~3회/일 진입 예상" 삭제.
  • 사유: 근거 없는 placeholder, 본 PRD 결정에 무영향. criteria "Placeholder 베이스라인" reject.
• §3-3 백엔드/시스템 → §3-3 시스템 룰 (PRD 수준)로 축소.
  • Notification item field table, 저장 방식("푸시 발송 트리거와 동일 지점에서 persist"), 외부 시스템 연동(FCM/APNs path 분리) 삭제.
  • 유지: 푸시↔알림센터 1:1 적재 룰, 보관 기간 정책, 읽음 동기화 규약, DM 의존 — PRD 수준 비즈니스 룰.
  • 사유: criteria 명시 reject — "BE 섹션이 사용자 가치·비즈니스 룰 결정이 아니라 API/저장소/구현 구조 설명이면 섹션째 삭제하고 spec/개발 설계로 넘긴다".
• §🔍 검토 필요 메타 섹션 (§🚨 결정 필요 / §⚠️ 추정 / §❓ 외부 agent 호출) 전체 삭제.
  • 사유: criteria 명시 reject — "외부 의존은 §1.2 근거나 §7 Open Questions로 흡수, 별도 섹션 만들지 말 것". 내용은 §7 OQ와 100% 중복.
• §부록 "#### 진행 패턴" 줄 삭제.
  • 사유: criteria 명시 reject — "모든 PRD에 공통 적용되는 메타 정보, SKILL에 정의됨, PRD 본문 X".
• §부록 주요 위험 요소 표에서 "노출=read 부작용", "보관 기간 사용자 기대 불일치" 행 삭제.
  • 사유: §7 OQ로 닫히면 사라지는 의례적 항목, 실제 mitigation이 §7 의존. 남은 3개 행은 구체적 대응이 있어 유지.

결정 필요 (모모 판단, PRD 패치 보류)

PRD 단계에서 닫혀야 spec/design 단계가 의미 있는 결정들. 추천 같이 적음.

1. §1.5 메인 지표가 원 문제와 단위가 안 맞는다 (방향성)

   • 원 문제 §1.1: "알림 누락 복구 + 읽음 추적 부재". 메인 지표 "주간 활성 비율"은 engagement proxy.
   • 추천: 메인 지표를 "푸시 미클릭 알림 중 알림센터 경로로 회수된 비율"로 교체하고, "주간 활성 비율"은 보조로 강등. 단위가 "복구" 문제와 같아짐.

2. §1.5 디렉터 응대 latency가 본 PRD 범위에서 도달 가능한가 (방향성)

   • §1.3에서 "알림센터는 D1 retention 본체 아님 / amplifier" 라고 못 박았는데 §1.5엔 그 정합성 안 보임.
   • 추천: 디렉터 응대 latency를 보조 지표로 강등 + "amplifier 측정용"이라고 명시. 본 PRD 단독 책임 못 짐.

3. DEE-41 dependency 단계가 본문에 안 박혀 있다 (방향성)

   • §3-5 Out-of-scope "알림 종류 on/off UI — DEE-41" 한 줄로는 dependency 강도 안 보임. "DEE-41이 늦으면 본 PRD가 멈추는가" 가 명확해야 함.
   • 추천: §3-5에 한 줄 추가 — "본 PRD MVP 출시 게이트: DEE-41의 알림 type 이름 목록 + 카테고리 그루핑 확정. on/off semantic은 의존하지 않음." 정도로 dependency depth 명시.

4. "노출 = read" vs "클릭 = read" — MVP default를 PRD에서 닫아야 함 (작동성)

   • 현재 §3-1 "노출=read Default 가정 + 부작용 + §7 OQ"로 미정 상태. 부작용(디렉터 댓글 read 처리)이 가설 1을 직접 깸 → spec/design 단계로 넘기면 시안 그리기 전부터 막힘.
   • 추천: 클릭(탭) = read 를 MVP default로 본문에 박는다. 노출은 아무 효과 없음. 가설 1과 정합. §7에서 해당 항목 삭제. seen/read 2-state는 v2.

5. §5.2 로깅 이벤트 — 기존 그룹 재사용 가능성 확인 안 됨 (작동성)

   • 현재 "신규 그룹 notification_center 신설 가정"으로 5개 모두 🆕. 기존 푸시 그룹의 view_*/click_* 이벤트에 source: notification_center 파라미터로 cover 가능한지 검증 안 됨.
   • 추천: PM(또는 데이터팀)에게 event-docs.frontia.dev 기존 그룹 18개 확인 요청 → 결과를 §5.2 본문에 한 줄 박는다 ("기존 푸시 그룹의 click/view 이벤트는 source 파라미터로 분기 못 함 → 신규 그룹 필요" 형태). §7 OQ로 옮기는 것도 OK.

6. §3-4 신규 deep-link /notification-center — MVP에 진짜 필요한가 (작동성)

   • 현재 "운영 공지에서 '전체 알림 보기' 가능"이라는 잠재 use case만으로 In-scope. MVP 실 use case 없으면 신규 path 정의도 필요 없음.
   • 추천: MVP에 실제 외부 진입 케이스 없으면 §3-4 신규 path 항목 + §3-5 In-scope "신규 deep-link path" 줄 삭제. 진입점은 인앱 상단 종 모양만으로 충분.

7. §1.5 baseline 채움 책임 명시 (작동성)

   • 현재 "(TBD)" placeholder만. criteria가 "owner 모호 표기 reject — 누가(실명) / 어떤 reference 데이터를 / 왜 쓰는지 본문 명시" 요구.
   • 추천: 표 footer에 한 줄 — "Baseline: 데이터팀 (담당자명) 가 현재 푸시 receive_* → click_* funnel rate로 출시 직전 채움" 형태. 담당자 실명은 모모가 채워줘야 함.

Skip / 보류

없음.

criteria 후보 (인라인 피드백)

• prd-review를 walk-through 없이 batch로 돌릴 때, criteria-mandated 패치는 메인 agent가 자체 판단으로 즉시 적용하고 product decision만 모모에게 모아 묻는다 — 결정 부담 ↓.
  • → criteria가 아닌 SKILL 운영 원칙. 별도 반영 없음.

2026-05-21 — 알림 타입 범위 반영

Source: momo Slack feedback.

채택

• §3-1 알림 항목 타입에서 DM / 보상 / 추천 제거.
• 운영/공지 명칭을 공지사항으로 변경.
• 팔로우한 디렉터의 새 작품 타입 추가.
• 사용자/시나리오/deep-link/scope/UL에서 DM·보상·추천 전제를 제거하고 MVP 포함 타입 기준으로 정리.

남은 확인

• DEE-41 taxonomy와 실제 푸시 이벤트명/payload 매핑 확인 필요.
• 공지사항 상세 deep-link/웹뷰 규약 확인 필요.

2026-05-21 — 푸시 대상/알림센터 적재 정책 반영

Source: momo Slack feedback.

채택

• 실제 푸시 대상 타입을 댓글 / 좋아요·반응 / 팔로우 / 팔로우한 디렉터의 새 작품으로 명시.
• 공지사항은 푸시 없이 알림센터 only로 적재하도록 변경.
• 유저가 푸시 알림을 꺼도 MVP 푸시 대상 이벤트는 알림센터에 계속 적재되도록 시스템 룰 수정.
• 읽음/안읽음 표시는 숫자 카운트가 아니라 진입점 종 모양 red dot + 각 알림 항목 red dot으로 정리.

Spec handoff

• spec은 red dot 중심 UI 상태(진입점/항목별), 푸시 권한 off 상태에서도 알림센터 적재가 유지되는 QA 케이스, 공지사항 center-only delivery_mode를 반드시 포함해야 함.