Next Plan · 캠페인 상태별 전수

마스킹 복구 — 다음 계획

beta · 마스킹 영향 enrollment 4,881 · 이메일 복구 8,852(74%) 완료 · 2026-06-04

선행 완료 + 현재

✅ 구조차단(DB CHECK) · 백업(11,958) · 이메일 복구 8,852/74% · VACUUM · 성능 정상. 이제 스킵·중단된 캠페인을 어떻게 재가동/정리할지가 다음 단계.

0 마스킹 영향 enrollment 전수 (4,881)

상태	총	복구됨	일부발송	미발송	pending	성격
active	2,446	2,180	3	2,443	2,446	진행중·깨짐(인트로 없이 팔로업)
stopped	2,208	1,848	0	2,208	0	중단·전 스텝 미발송
bounced	157	102	137	20	0	실제 반송
completed	37	32	0	37	0	⚠️ 스킵된 채 완료(침묵 실패)
paused	33	29	0	33	0	정지·미발송

핵심: bounced(실제 발송)를 빼면 대부분 한 통도 안 나간 채 깨졌거나 끝남. 특히 completed 37건은 한 통도 안 나갔는데 "완료"로 마감된 침묵 실패.

1 버킷별 다음 조치

① active 2,446 (복구 2,180) 누적 재스케줄

step1 미발송 + step2~8 pending(상당수 overdue). → execution 삭제 후 step1부터 now+Σdelay 재생성. still-masked 266은 재enrich 후.

② stopped 2,208 (복구 1,848) 재활성 + 재스케줄

status→active + 누적 재스케줄. ⚠️ unreachable(~1,628)만 — email_account_removed·기타 사유 제외. 발송 직전 재검증으로 진짜 수신불가 자동 필터.

③ completed 37 (복구 32) 재enroll ⚠️ 침묵 실패

한 통도 안 나갔는데 "완료". completed는 resume 불가 → 새 enrollment 생성(step1부터). 32건 복구분.

④ paused 33 (복구 29) 복구 후 재개+재스케줄

의도된 pause 확인 후 재개. 과거 scheduled_at overdue라 그대로 재개 금지 → 누적 재스케줄.

⑤ bounced 157 제외

137건 실제 발송→반송. 재활성 금지(평판). 복구 102건도 재발송 X.

⑥ still-masked 266 / 잔량 2,971 재enrich

원본 부재 → contact-enrichment 도메인 재탐색. 확보분만 위 버킷 합류.

2 공통 해법 — 누적 재스케줄

기존 reEnrollFailedEnrollments의 cadence 버그(now+delay 평면 → 하루 폭탄) 회피:

1) execution 스냅샷 (seq_recovery_backup) — 롤백/감사
2) 미발송 execution 삭제 (sent/delivered 보존)
3) step1부터 재생성: scheduled_at = base + Σ(delay_days[1..n])
   step1=오늘, step2=+5d, step3=+10d ...  (timezone·주말·발송시각)
4) enrollment current_step_order=0, status=active  (③ completed는 새 enrollment)
5) is_verified=false → 발송 직전 cascade 재검증 (deliverable만)
6) 워커 throttle + 분할 적용으로 버스트 방지

절대: current_step_order 수동 진행 금지 · raw SQL now+delay 평면 적용 금지(폭탄). 반드시 누적.

3 실행 순서

1. execution 스냅샷 (전 영향 enrollment)
2. [코드] 누적 재스케줄 — 1회 스크립트 or reEnroll 버그 PR
3. dry-run: 버킷별 대상수 + 재스케줄 날짜 분포 검증
4. 점진 적용(워크스페이스/캠페인 단위, 모니터):
   ① active 2,180 → ② stopped 1,628 → ④ paused 29 → ③ completed 32
5. 발송 모니터 — 일일량/실패율/바운스/평판
6. 잔량 2,971 재enrich → 재합류
7. 마스킹 0 → CHECK VALIDATE
8. 코드 가드 PR (isMaskedEmail SSOT + updateLead + cadence 버그)

4 결정 필요

1	재가동 범위/순서 — 전체 / 워크스페이스 우선순위?
2	completed 37 재enroll 포함?
3	bounced 157 제외 확정?
4	발송 계정 유지 / 시작 시각 / 일일 상한?
5	cadence: 1회 스크립트 vs 함수 PR 수정?