[앱/웹] 캐릭터 페르소나 기반 일괄 선톡 PRD

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

---

Status: draft Created: 2026-06-01 Last updated: 2026-06-01 Linear Project: [앱/웹] 캐릭터 페르소나 기반 일괄 선톡 (00b64b6996de) Linear Issue (PRD writing): DEE-300 Author: agent (prd-writer) / momo 앱/웹/스튜디오: 앱 (유저 surface) + 어드민 (운영 발송 도구) + 서버

---

Reversal Risk Summary

이 PRD에서 어떤 레이어를 출시 전 신중하게 픽스해야 하는지 빠르게 판단하기 위한 요약.

Layer	R-level	Review focus
Policy / Rule	R2	발송 전 운영 검수 게이트, 빈도·중복 cap, 무료 수신 정책 — 누락 시 스팸·신뢰 훼손. 출시 전 고정.
Data / Backend	R2	캠페인/발송 로그/dedup·frequency state — 중복 발송·정합성. 되돌림 시 데이터 재작업.
User-facing Surface	R1	선톡은 DEE-72 Chat Thread·푸시 surface에 적재 (재사용). 단 "선톡이 Chat Thread를 신규 생성" 정책은 R2.
Copy / Visual Presentation	R1	선톡 메시지 톤·문구는 캠페인 단위로 출시 후 조정 가능. 단 페르소나 톤 품질은 가치의 핵심이라 검수로 보증.

• R1: 출시 후 빠르게 조정 가능. 기본값 제안 후 진행.
• R2: 되돌릴 수 있지만 개발/데이터/운영 재작업 필요. 근거·대안 기록.
• R3: 되돌림 비용이 크거나 정산/신뢰/계약/데이터 정합성에 영향. 별도 싱크/승인.

---

1. 목표 및 배경

1.1 문제

• 사용자 정의 (segment): 가입했거나 에피소드를 플레이했지만, 다음날 다시 들어올 능동적 이유가 없는 유저. 특히 특정 캐릭터(Soul)와 접점이 생겼지만 본인이 먼저 말을 걸지 않으면 관계가 멈추는 유저.
• 상황 (when, where): 앱을 떠난 뒤(주로 다음날). 채팅은 유저가 먼저 말을 걸어야만 시작되는 구조라, 유저가 행동하지 않으면 캐릭터와의 관계가 살아있는 느낌이 약하다.
• 불편 / 미충족 needs: "다음날 들어올 이유"가 외부에서 주어지지 않는다. 캐릭터가 먼저 안부를 건네는 채널이 없어, 메신저(Chat)는 유저가 자발적으로 진입할 때만 활성화된다.

1.2 근거

• 6월 Product Current Focus Goal: "가입한 유저들이 다음날 들어올 이유를 만든다." 본 PRD는 그 목표에 직접 대응하는 push-channel surface.
• 인접/선행 작업:
  • DEE-72 / chat-messenger (8aea9b7ef906): 캐릭터별 1:1 Chat Thread·메신저 surface·human-like 푸시·unread 모델을 정의. 그 PRD는 선톡 생성·예약·빈도·발송 정책을 본 프로젝트(당시 "DEE-131")로 위임했고, 자기 범위는 "선톡 더 자주 받기(유료 추가 빈도) surface + 사전 고지"로 한정. 본 PRD가 그 위임받은 발송 정책의 owner다.
  • DEE-71 / character-bond-system: (user, Soul) Bond Exp 적재. 선톡 수신 후 유저가 답장해 generation이 성공하면 Chat 소스로 Exp가 적재되고, 개인화 선톡 수신 자체에 별도 source(personalized_proactive_message_received)가 정의돼 있음.
  • deployed/2026-03-03_조건별 푸시 PRD.md: 세그먼트 조건·배치 발송·야간 제한·변수 치환(닉네임/에피소드/스타) 패턴. 본 PRD의 대상 조건·타이밍·중복 제한은 이 패턴을 재사용·확장한다.
  • DEE-76 / notification-center: 인앱 알림 히스토리. 현재 MVP 알림 타입에서 DM/선톡을 제외하고 있어, 선톡의 알림센터 적재 여부는 본 PRD에서 결정해야 함(§7).

⚠️ 정량 베이스라인(현재 D1 리텐션, Chat 자발 진입율, 푸시 opt-out율)은 데이터 agent 호출 필요 — §1.5·§7 참조. 출시 직전 책임자(momo)가 채운다.

1.3 아이디어 (해결 방향)

운영/시스템이 캐릭터(Soul) 페르소나에 맞는 선톡(Proactive Message) 을 대상 유저에게 일괄 발송해, 캐릭터가 먼저 안부를 건네는 채널을 만든다. 선톡은 DEE-72의 Chat Thread에 Soul이 보낸 말풍선으로 적재되고, 푸시로 재진입을 유도한다. 유저가 답장하면 일반 Chat generation 흐름(스타 소모)으로 대화가 이어진다.

메시지 생성 방식 (핵심 결정 — §7 / §3 참조):

• 옵션 A — 운영 등록형 (추천, v1): 운영자가 캠페인 단위로 Soul·대상·타이밍을 설정하고, 각 Soul 페르소나(Soul Prompt) 기반으로 메시지를 등록 시점에 생성·검수(LLM 보조 가능)해 확정한다. 발송 시점에는 확정된 메시지 + 변수 치환(닉네임/에피소드명)만 한다. → 비용·품질·안전이 통제 가능하고 핵심 가설을 가장 싸게 검증.
• 옵션 B — 런타임 완전 개인화: 발송 시점에 유저별 컨텍스트(플레이 이력·User Relational Persona)로 1인 1메시지를 LLM 생성. 개인화는 강하지만 발송당 LLM 비용·검수 불가능·안전 리스크가 커 v1 제외, 후속.
• 추천: 옵션 A. "캐릭터 페르소나 기반"이라는 가치는 Soul별 메시지 차별화 + 변수 치환으로 v1에서 충분히 구현되고, 런타임 1:1 생성은 가설 검증 뒤 후속에서 단계적으로 연다.

전략 컨텍스트: 선톡은 "캐릭터가 먼저 말을 건다"는 return hook을 새로 만드는 surface다. 본 PRD 범위는 "운영이 페르소나 기반 선톡을 안전하게 일괄 발송하고, 그 효과를 대조군 대비 측정한다"에 한정. 관계 레벨별 선톡 변화·디렉터 셀프 선톡·완전 개인화는 후속 layer.

1.4 가설

1. 재진입 가설(핵심): 캐릭터가 먼저 보내는 선톡을 받으면, 받지 않은 유저(대조군)보다 다음날(D1) 재방문·메신저 진입 비율이 높다.
2. 대화 점화 가설: 선톡을 받은 유저의 일정 비율이 답장해 Chat 대화를 시작/재개한다 (선톡이 첫 Chat Thread를 점화).
3. 피로도 가설(역방향 감시): 선톡 빈도가 과하면 푸시 opt-out·앱 푸시 피로로 이어진다 → 빈도·중복 cap으로 통제 가능하다.

1.5 성공 지표

지표	현재	목표	측정 방법
선톡 발송군 D1 재방문율 − 대조군 D1 재방문율	(출시 직전 baseline, momo)	+유의미 (실험 종료 시 확정)	holdout 대조군 대비 diff. receive_dm_proactive_message 발송군 vs 미발송군 D1 재방문
선톡 → 메신저(Chat Thread) 진입율	0	(출시 직전 확정)	선톡 수신 유저 중 해당 Thread 진입(view_dm_thread source=proactive_push) 비율
선톡 → 답장율	0	"0이 아님" 시그널	선톡 수신 Thread 중 유저 답장(send_dm_message) 발생 비율

• 메인 지표: 선톡 발송군 vs 대조군의 D1 재방문율 diff. 6월 목표(다음날 들어올 이유)와 단위가 일치하고, 본 PRD 범위(일괄 선톡)에 귀속 가능한 형태. 전체 D1 리텐션 절대치는 단일 PRD로 닿지 않으므로 메인으로 쓰지 않고, diff로 본 기능의 기여만 측정한다.
• 보조 funnel 지표: 선톡 푸시 오픈율 → 메신저 진입율 → 답장율. 이 funnel의 절대 임계(예: 옵션 A 등록형을 유지할지 옵션 B 개인화로 전환할지 가르는 답장율 기준)는 본 PRD에서 굳히지 않고 실험 설계 시점에 확정한다(§7 옵션 A/B 결정과 연결).
• 가드레일 지표:
  • 선톡 수신군의 푸시 opt-out율 및 앱 알림 차단율 (대조군 대비 악화 금지).
  • 선톡 관련 CS/환불 문의.
  • 선톡 생성·발송 LLM 비용(옵션 A는 등록 시점 1회).

---

2. 타깃 사용자

2.1 주요 사용자

• 선톡 수신자(유저): 특정 Soul과 접점(에피소드 플레이 이력 등)이 있거나, 운영이 정의한 세그먼트 조건을 충족하는 유저. 빈도는 운영 캠페인·빈도 cap에 의해 통제.
• 운영자(내부): 어드민 발송 도구로 캠페인(Soul·메시지·대상·타이밍)을 만들고 검수·발송하는 Frontia 운영팀. v1의 발송 주체는 디렉터가 아니라 내부 운영.

2.2 핵심 시나리오

1. 운영자가 어드민 발송 도구에서 캠페인을 만든다 — Soul "A" 선택, 페르소나 기반 안부 메시지를 생성/검수해 확정, 대상 = "최근 7일 내 A 등장 에피소드를 플레이했고 아직 A와 Chat 안 한 유저", 발송 = 다음날 19:00. 검수 승인 후 예약.
2. 다음날 19:00, 시스템이 대상 유저별로 메시지를 발송한다. (user, A) Chat Thread가 없으면 생성하고 Soul "A"의 말풍선으로 선톡을 적재한다. unread +1, human-like 푸시 발송(야간 제한·빈도 cap 통과 시).
3. 유저가 푸시를 보고 메신저로 진입해 선톡을 읽고 답장한다. 답장은 일반 Chat generation(10스타) 흐름을 탄다. (user, A) Bond Exp가 Chat 소스로 적재된다.
4. 같은 유저가 이미 이번 주 빈도 cap에 도달했거나 직전 선톡에 무반응이면, 시스템이 다음 선톡을 보류/스킵한다(중복·피로 방지).
5. 대조군(holdout)으로 분류된 유저는 같은 조건이어도 선톡을 받지 않는다 → D1 재방문 diff 측정.

---

3. 핵심 기능 요구사항

3-1. 클라이언트 (앱) — 선톡 수신·표시

유저 측 메신저 surface(Chat Thread·말풍선·unread·human-like 푸시 렌더링)는 DEE-72에서 정의된 것을 재사용한다. 본 PRD는 선톡 특유의 동작 차이만 정의한다.

선톡 적재 (Soul → 유저)

• 주요 동작: 발송된 선톡은 해당 (user, Soul) Chat Thread에 Soul이 보낸 말풍선으로 적재된다. 유저 입력 없이 캐릭터가 먼저 보낸 메시지.
• 비즈니스 룰:
  • Thread 신규 생성 허용: (user, Soul) Chat Thread가 아직 없으면 선톡 적재 시점에 생성한다. 즉 선톡은 Chat Thread를 점화할 수 있다(유저의 첫 메시지가 아니어도). — R2 정책.
  • 선톡 적재 시 해당 Thread unread +1 (DEE-72 unread 모델 재사용).
  • 메시지에 변수(닉네임/에피소드명 등)가 있으면 발송 시점에 치환(조건별 푸시 변수 치환 패턴 재사용).
  • 선톡은 1캠페인·1대상 유저당 1개의 Soul 말풍선으로 적재된다(여러 말풍선 분할은 v1 범위 외).
• 상태별 동작:
  • Soul 비공개/삭제: 발송 대상에서 제외(§4). 이미 적재된 선톡은 DEE-72 read-only 정책을 따른다.
  • 유저가 해당 Soul과의 대화를 차단할 수단은 DEE-72에 없음(대상이 캐릭터). 본 PRD는 빈도 cap + 푸시 off로 대체한다.

선톡 수신 비용 (무료)

• 기본 일괄 선톡은 유저에게 무료다. 선톡을 받는 것 자체에 스타를 차감하지 않는다.
• 유저가 답장하면 그 시점부터 일반 Chat generation 정책(성공당 10스타, DEE-72)이 적용된다. 선톡은 무료로 도착하고, 대화 지속은 기존 BM을 탄다.

선톡 푸시

• 주요 동작: 선톡 적재 시, 캐릭터(Soul)가 메시지를 보낸 것처럼 느껴지는 human-like 푸시를 발송한다.
• 비즈니스 룰:
  • 형태감은 DEE-72의 human-like 푸시 원칙을 그대로 따른다: title = Soul display name, body = 메시지 스니펫, sender 이미지 = Soul 프로필(가능 범위 내).
  • 선톡 푸시는 마케팅성 발송으로 취급한다 → 야간 발송 제한 적용(조건별 푸시 패턴). 야간 도착분은 익일 허용 시간대로 디퍼.
  • 빈도/중복 cap 적용(§3-3): cap 초과 시 선톡은 Thread에 적재하더라도 푸시는 생략할 수 있다(정책은 §3-3에서 결정).
  • 푸시 off 유저: 푸시는 보내지 않되 Thread 적재·unread는 유지(다음 진입 시 확인 가능).

3-2. 어드민 — 선톡 운영/발송 도구

내부 운영자가 선톡 캠페인을 만들고 검수·발송하는 도구. (디렉터 셀프 선톡 등록은 v1 범위 외 — §3-4.)

• CRUD 범위: 선톡 캠페인 생성·수정·복제·예약 취소. 발송 완료 캠페인은 read-only + 결과 요약.
• 필수 입력 필드:
  • 대상 Soul: 1개 캠페인 = 1개 Soul(페르소나 일관성). 다중 Soul 캠페인은 후속.
  • 메시지 본문: 페르소나 기반으로 생성/검수해 확정(옵션 A). LLM 보조 생성 → 운영자 편집·승인. 변수 placeholder 허용(닉네임/에피소드명).
  • 대상 조건(세그먼트): 조건별 푸시 패턴 재사용 — 예: 특정 Soul 등장 에피소드 플레이 이력, 가입 경과일, 해당 Soul과 Chat 미시작 여부, 푸시 수신 동의 등. 조건 조합으로 세그먼트 산출.
  • 발송 타이밍: 즉시 / 예약 시각 / (후속) 가입+N시간 같은 상대 트리거.
  • 대조군 비율(holdout): 대상 세그먼트 중 선톡을 받지 않을 대조군 비율(예: 10%). 실험 측정용.
• 검수 게이트(필수, R2): 발송 전 운영자 승인 단계를 강제한다. 승인 없이는 예약/발송 불가. 생성 메시지 샘플 + 대상 규모 + 변수 치환 미리보기를 검토.
• 결과 요약: 발송 수, 푸시 도달, 오픈, 메신저 진입, 답장, cap/중복 스킵 사유를 캠페인 단위로 본다. 대조군 대비 D1 diff 같은 실험 분석은 데이터 대시보드 책임이며 어드민 도구가 산출·표시하지 않는다(지표 정의는 §5).
• 권한: 내부 운영자.

3-3. 시스템 룰 (PRD 수준) — 타이밍·빈도·중복 제한

선톡이 스팸으로 느껴지지 않도록 하는 핵심 안전장치. 구현 세부(스케줄러·큐·저장 구조)는 spec/BE 설계로.

• 야간 발송 제한: 선톡 푸시는 야간 발송 금지(조건별 푸시 기준 시간대 재사용). 적재는 가능하되 푸시는 익일 허용 시간대로 디퍼.
• 유저당 빈도 cap: 한 유저가 일/주 단위로 받을 수 있는 선톡 최대 수를 제한한다. 전 캠페인·전 Soul 합산 기준의 글로벌 cap을 둔다(특정 유저에게 여러 Soul 선톡이 몰리는 것 방지). 구체 수치는 §7.
• 중복 제한(dedup):
  • 같은 캠페인은 같은 유저에게 1회만 발송한다.
  • 같은 Soul에서 직전 선톡에 유저가 무반응(미열람/미답장)이면 다음 선톡을 보류하거나 빈도를 낮춘다(무반응 누적 방지).
• 대조군(holdout) 분류: 캠페인 대상 세그먼트에서 지정 비율을 대조군으로 분리하고, 분류를 안정적으로 유지(같은 유저가 캠페인마다 군이 흔들리지 않게). diff 측정의 기준.
• 발송 자격 재확인: 발송 시점에 Soul 공개 상태·유저 탈퇴·푸시 동의·빈도/중복 cap을 재확인하고 통과한 대상만 발송.

3-4. Scope

포함 (In scope)

• 어드민 선톡 운영/발송 도구(캠페인 생성·검수 게이트·예약·결과 요약).
• 페르소나 기반 메시지 등록형 생성(옵션 A) + 변수 치환.
• 대상 세그먼트 조건(조건별 푸시 패턴 재사용) + 대조군(holdout) 분류.
• 선톡의 Chat Thread 적재(없으면 Thread 신규 생성) + unread + human-like 푸시(야간 제한·빈도/중복 cap).
• 기본 일괄 선톡 무료 수신 정책(답장은 기존 Chat BM).
• 타이밍·빈도·중복 제한 시스템 룰.
• 로깅 이벤트 + 실험(발송군/대조군) 측정.

제외 (Out of scope)

• 런타임 완전 개인화(발송 시점 1인 1메시지 LLM 생성) — 후속(옵션 B).
• 디렉터 셀프 선톡 등록(Studio [소울 관리]에서 디렉터가 직접) — 후속.
• 다중 Soul 단일 캠페인.
• 관계 레벨/Bond 단계에 따른 선톡 내용 분기 — 후속 layer.
• 선톡 더 자주 받기(유료 추가 빈도) 유저 surface — DEE-72.
• 메신저 surface·말풍선·unread·human-like 푸시 렌더링 자체 — DEE-72.
• 그룹/단톡 선톡.

3-5. 딥링크 / URL 구조

선톡 푸시의 랜딩은 DEE-72가 정의한 기존 Chat Thread 경로를 재사용한다:

선톡 동작	탭 시 이동
선톡 푸시	해당 (user, Soul) 채팅방 /dm/character/:characterId (DEE-72 정의)

• 본 PRD는 신규 path를 정의하지 않는다. DEE-72의 /dm·/dm/character/:characterId 재사용.
• 앱 미설치 시 fallback: 마켓(Chat은 앱 전용, DEE-72 정책 동일).
• 비로그인: 선톡 대상은 로그인 유저뿐이므로 해당 없음.

---

4. 에러 처리 및 예외 상황

상황	처리 방향
발송 시점 Soul 비공개/삭제	해당 Soul 캠페인 발송 중단. 미발송 대상은 스킵, 운영자에게 캠페인 상태로 노출
발송 대상 유저 탈퇴/비활성	발송 대상에서 제외(발송 시점 재확인)
유저 푸시 미동의/푸시 off	푸시 생략, 선톡은 Thread 적재 + unread 유지
빈도/중복 cap 초과	잠정 기본값 = 해당 유저에게 이번 선톡 푸시 생략(Thread 적재는 유지), 캠페인 결과에 사유 집계. "적재까지 스킵" 강화는 §7에서 확정
변수 치환 실패(닉네임/에피소드 누락)	안전한 fallback 문구로 치환(예: 닉네임 → 기본 호칭). 치환 불가 메시지는 발송 스킵
선톡 적재 성공/푸시 발송 중 한쪽 실패	Thread 적재가 source of truth, 푸시는 best-effort(조건별 푸시·알림센터 패턴 동일)
검수 미승인 캠페인 발송 시도	차단. 승인 게이트 통과 전에는 예약/발송 불가
대상 세그먼트 0명	발송 없음 + 운영자에게 경고
대조군 분류 충돌(이전 캠페인과 군 불일치)	안정적 holdout 정책으로 유저별 군을 일관 유지(§3-3)

---

5. 데이터 분석

5.1 핵심 지표

1. 선톡 발송군 vs 대조군 D1 재방문율 diff — 메인 (§1.5).
2. 선톡 → 메신저 진입율 — 푸시 오픈 후 Thread 진입.
3. 선톡 → 답장율 — Thread 내 유저 답장 발생.
4. 선톡 수신군 푸시 opt-out율 / 알림 차단율 — 가드레일(피로도 가설).
5. 캠페인별 발송·도달·중복/cap 스킵 집계 — 운영 품질.

5.2 로깅 이벤트

컨벤션: snake_case, 동사_명사. 기존 그룹·이벤트 재사용 우선. 신규는 "상태" 열에 🆕. 본 PRD 이벤트는 DEE-72의 dm 그룹에 속한다. view_dm_thread·send_dm_message는 DEE-72에서 신규 정의 예정(아직 미ship) 이며, 본 PRD는 거기에 source/param만 추가한다 — 즉 이 이벤트들의 존재는 DEE-72 선행 ship에 의존한다(§7 sequencing). spec 진입 전 event-docs.frontia.dev dm 그룹과 매핑을 확정한다(§7).

타입	이름	용도	파라미터	그룹	상태
Event	receive_dm_proactive_message	선톡이 유저 Thread에 적재된 시점	thread_id, soul_id, campaign_id, is_thread_created(bool), delivery(push / center_only / suppressed_cap)	dm	🆕 신규
Event	view_dm_thread	채팅방 진입(선톡 경로 식별)	soul_id, source(proactive_push 값 추가)	dm	DEE-72 신규 정의 예정 — 본 PRD는 source 값만 추가
Event	send_dm_message	유저 답장(선톡 답장 식별)	thread_id, soul_id, is_reply_to_proactive(bool), campaign_id(nullable)	dm	DEE-72 신규 정의 예정 — 본 PRD는 param만 추가
Event	fail_dm_proactive_send	선톡 발송 실패/스킵	campaign_id, soul_id, reason(soul_unavailable / user_inactive / cap_exceeded / var_substitution / etc)	dm	🆕 신규

• DEE-72의 toggle_dm_proactive_message_receive(선톡 수신·더 자주 받기 토글)는 DEE-72 유저 surface 전속이다. 본 PRD(발송 정책 owner)는 그 토글 상태를 발송 자격 재확인(§3-3)에서 읽기만 하고, 이벤트 정의·발화는 DEE-72 책임.
• 관계 Exp: 선톡 답장으로 generation이 성공하면 DEE-72/DEE-71의 Chat 소스(dm_response_generated)로 적재. 개인화 선톡 수신 자체 적재(personalized_proactive_message_received, DEE-71)는 옵션 B(런타임 개인화·유료) 도입 시에만 발화 — v1(무료 일괄)은 해당 없음.
• 운영 캠페인 액션(생성·검수·발송)은 유저 분석 이벤트가 아니라 어드민/서버 로그로 추적한다.

---

6. Ubiquitous Language

Soul, Character, Chat Thread, Chat Bubble, Bond, User Relational Persona, Soul Prompt 등은 DEE-72(chat-messenger) UL에 정의됨 — 본 PRD는 재사용하며 재정의하지 않는다. 아래는 본 PRD에서 새로 도입하는 도메인 term만 등재.

Term	Korean	Definition	Do Not Confuse With	Primary Domain	상태
Proactive Message	선톡	Soul이 유저 입력 없이 먼저 보내는 메시지. (user, Soul) Chat Thread에 Soul 말풍선으로 적재되며, Thread가 없으면 생성한다. 기본 일괄 선톡은 무료 수신.	유저 답장에 대한 Soul 응답(reactive), 조건별 푸시(앱 시스템 발신 푸시)	Messenger (신규)	신규
Proactive Campaign	선톡 캠페인	운영자가 어드민에서 등록하는 선톡 발송 단위. 1개 Soul + 메시지 + 대상 세그먼트 조건 + 타이밍 + 대조군 비율로 구성되고, 검수 승인 후 발송된다.	Soul(캐릭터 entity), 조건별 푸시 캠페인(앱 푸시)	Messenger / Ops (신규)	신규

---

7. Open Questions

• [ ] 메시지 생성 방식 확정 — 옵션 A(운영 등록형, 추천) vs 옵션 B(런타임 개인화)를 v1 범위로 확정. 본 PRD는 A 가정. 비용·검수·안전 영향이 커 BE 설계 전 합의 필요. — momo + 모델 담당.
• [ ] 선톡이 Chat Thread를 신규 생성하는 정책 — 선톡이 첫 Thread를 점화하는 것을 v1에 허용할지(본 PRD는 허용 가정), 아니면 기존 Thread 보유 유저로 한정할지. DEE-72 Thread 생성 모델과 정합 필요. — momo + DEE-72 담당.
• [ ] 빈도/중복 cap 수치 — 유저당 일/주 글로벌 선톡 최대 수, 무반응 시 보류 기준. baseline 푸시 피로도 데이터 참조해 확정. — momo + 데이터.
• [ ] cap 초과 시 동작 — 적재는 하되 푸시만 생략 vs 발송 자체 스킵. — momo.
• [ ] 선톡의 알림센터 적재 여부 — DEE-76은 현재 DM/선톡을 알림센터 MVP에서 제외. 선톡을 알림센터에도 적재할지, Chat unread+푸시로만 둘지. — momo + DEE-76 담당.
• [ ] DEE-72와의 sequencing — 선톡은 DEE-72 Chat Thread surface에 적재되므로 DEE-72 ship이 선행돼야 함. DEE-72 미ship 시 본 PRD의 degrade/대기 정책. — momo + DEE-72 담당.
• [ ] 로깅 이벤트 매핑 — event-docs.frontia.dev dm 그룹 기존 이벤트와 재사용/신규 매핑, source/param 추가 정렬. — momo (Cloudflare Access 세션).

---

부록: 메타 정보

Required artifacts

• [x] Spec (needs-spec) — 어드민 선톡 운영 도구(캠페인 생성·검수 게이트·대상 조건·대조군·예약·결과 요약) 화면 명세 + 선톡의 유저 측 적재/표시 차이(Soul 말풍선·unread·선톡 푸시 페이로드). 메신저 surface 본체는 DEE-72 spec 재사용.
• [x] Design (needs-design) — 어드민 발송 도구 화면. 유저 측은 DEE-72 시안 재사용(선톡 말풍선·푸시 형태 차이만 보강).
• [ ] QA scenarios (needs-qa-scenarios) — Sprint planning에서 작성(빈도/중복 cap·대조군 분류·야간 제한·Thread 생성·발송 자격 재확인 회귀).
• [x] Migration plan (needs-migration) — 신규 테이블: Proactive Campaign, 선톡 발송 로그, 유저별 빈도/dedup/holdout state. 초기 backfill 없음.
• [x] Tracking events (needs-tracking) — §5.2.

Size & Risks

T-shirt Size

• Size: L
• Confidence: medium
• 추정 근거: 신규 어드민 운영 도구 + 발송 파이프라인(타이밍·빈도·중복·대조군) + 페르소나 기반 메시지 생성/검수 + DEE-72(메신저 surface)·DEE-71(Bond)·조건별 푸시 인접. 유저 surface는 대부분 DEE-72 재사용이라 무게는 백엔드·운영 도구·실험 설계에 쏠림.

주요 위험 요소

위험	영향	대응
선톡이 스팸으로 인지되어 푸시 opt-out 증가	가드레일 악화, 전체 푸시 채널 신뢰 훼손	야간 제한 + 글로벌 빈도 cap + 무반응 dedup, 대조군 대비 opt-out 모니터링
페르소나 톤이 캐릭터와 어긋난 메시지 발송	캐릭터 신뢰·몰입 훼손	발송 전 검수 게이트 강제, Soul Prompt 기반 생성 + 운영자 승인
DEE-72 미ship 상태에서 선톡 적재 대상(Chat Thread) 부재	선톡이 도착할 곳 없음	sequencing 합의(§7), DEE-72 선행
중복/cap 로직 결함으로 동일 유저 다발 발송	피로·CS	dedup/holdout state 단일 지점화 + 발송 자격 재확인

의존성

• DEE-72 / chat-messenger (선행 필수): Chat Thread·말풍선·unread·human-like 푸시·/dm 경로. 선톡이 적재되는 surface.
• DEE-71 / character-bond-system: 답장 generation 성공 시 Bond Exp 적재, 개인화 선톡 수신 source(옵션 B 시).
• 조건별 푸시 (deployed): 세그먼트 조건·배치·야간 제한·변수 치환 패턴.
• DEE-76 / notification-center: 선톡 알림센터 적재 여부 정렬(§7).

References

• 관련 Linear/PRD:
  • DEE-72 [앱] Chat 메신저 기능 — 메신저 surface·선톡 위임 owner (draft/chat-messenger/PRD.md)
  • DEE-71 [앱] 관계 레벨 / Bond 체계 — 답장·선톡 수신 Exp 소스
  • DEE-76 [앱/웹] 알림센터 — 선톡 알림센터 적재 정렬 (draft/notification-center/PRD.md)
  • deployed/2026-03-03_조건별 푸시 PRD.md — 세그먼트·배치·야간 제한·변수 치환 패턴
• Frontia UL wiki: wiki/foundation/ubiquitous-language.md — Character, Episode, Star 정의(Soul/선톡 도메인은 DEE-72에서 신규 도입)
• 로깅 컨벤션: https://event-docs.frontia.dev/ (dm 그룹)