결론 먼저 — 최근 적용한 인덱스 속도 개선이 오래된 미발송 건을 한꺼번에 발송하는 문제는 없습니다. 발송 가능한 stale 건(7일+ 과거)이 실측상 0건 이고, 최근 발송 지연도 최대 7.6시간(당일 내 throttle)입니다. 발견된 정리 누락들은 모두 발송 정합성과 무관한 데이터 위생 이슈이며, 이번 변경과 무관한 기존 항목 입니다.
검증 항목 실측값 의미 active 하 stale sendable (7일+ 과거 pending) 0 빨라진 로더가 flush할 오래된 발송 건 자체가 없음 안전 최근 3시간 발송 max lag 7.6h 전부 당일 내 throttle 지연 — stale flush 아님 안전 비active enrollment 하 pending/deferred 11,457 로더가 e.status='active' 요구 → 속도와 무관하게 영구 제외(발송X) 발송X 로더 결과 (인덱스 ON vs 강제 seqscan) 24 = 24 접근경로만 변경, 결과 동일 → 미발송·중복발송 불가능 동일
항목 beta 실측 영향 위험도 terminal(stopped/bounced/unsub) enrollment 잔존 pending 미skip 11,457* step_executions 테이블 bloat (발송 안 됨) 중 deferred 무한연기 가드 부재 (미래 7일+ 밀림) 180 소수 발송 지연 가능 낮 processing 30분+ stuck 5 30분 주기 reconciler가 자동복구 (이미 커버) 낮 awaiting_enrichment 타임아웃 부재 0 enrichment API 장애 시만 (현 피해자 0) 이론 NULL account active enrollment 0 발송불가 고아 (현 피해자 0) 낮 orphan 정리 cron 미자동화 (1회성 스크립트 의존) — 수동 운영 의존 낮 발송 워커 staleness 가드 부재 — 현재 무해(stale 0). 미래 백로그 형성 시 대비 필요 예방
* recompute_sequence_pending_work는 se.status IN ('active','paused')만 카운트 → stopped/bounced/unsubscribed 잔존 pending은 has_pending_work·완료판정에 영향 없음 . 순수 테이블 bloat 이슈.
stuck processing 복구 — 30분 초과 processing을 pending으로 리셋·재주입 (5분 주기)
completed enrollment 잔존 pending → skipRemainingExecutionsOnComplete()로 정리
cascade delete — sequence/lead 삭제 시 step_execution 고아 방지 (FK RESTRICT/CASCADE)
stranded 재주입 — active sequence의 10분+ pending/deferred 재주입 (reconciler)
has_pending_work 트리거 self-heal (reconcileHasPendingWork)
deferPendingExecutionsForAccount: today/future 2쿼리 → UNION 통합 가능recoverStuckProcessingExecutions: 재enqueue 개별 루프 → bulk APIreconcileActiveSequencesBatch: LIMIT 200 고정 → 활성 시퀀스 수 대비 동적 조정
우선 항목 방법 중 terminal 전이 시 pending skip 누락 enrollment가 stopped/bounced/unsubscribed로 갈 때도 skipRemainingExecutions 호출(현재 completed만). dual-DB 검증 후 패치 낮 deferred 무한연기 방지 deferral_count 또는 max-attempts → 초과 시 failed/skip낮 orphan 정리 자동화 1회성 스크립트 → daily cron worker 예방 staleness 가드 send-email에 scheduledAt < NOW()-7d → skip (미래 백로그 대비)
요약 — 인덱스 속도 개선은 발송 정합성에 안전(stale sendable 0, 결과 동일성 24=24, max lag 7.6h). 발견된 정리 누락(terminal 잔존 pending 11k bloat 등)은 전부 pre-existing 데이터 위생 이슈로 발송 영향 없음 . 개선은 발송 로직과 분리된 저위험 별도 트랙으로 권장.