글로벌 린다세일즈 — 시퀀스 이메일 발송 정지

원인 ①  stagger 누적에 cap이 없어 잡이 미래로 폭주

같은 계정의 잡마다 idx × 10초를 누적 가산하는데 상한이 없다. 단일 계정에 enrollment가 집중되면(33k+) idx가 수십만까지 올라 delay가 며칠~75일이 된다.

// staggerDelay 에 상한이 없음 — idx 가 곧 delay(분)
const STAGGER_INTERVAL_MS = 10_000
const staggerDelay = baseDelay + acctIdx * STAGGER_INTERVAL_MS   // ← cap 부재
// 6,487,500,393ms 관측 = idx 648,750 × 10,000 + jitter(0~1500)

보조: sequence-email-scheduler.ts:100의 MAX_FUTURE_MS cap은 Redis throttle 슬롯만 압축할 뿐, BullMQ delayed의 delay 값은 압축하지 않음(applySchedulingDelay는 jitter만 추가).

원인 ②  jobId dedup으로 미래 잡을 앞당겨 재적재 불가

모든 적재 경로가 jobId = seq-email-${executionId} 고정. BullMQ addBulk는 같은 jobId가 delayed에 이미 있으면 silently 무시(delay·data 갱신 안 함). 한 번 먼 미래로 박힌 잡은 어떤 경로로도 당길 수 없다 → loader가 매 tick 재적재해도 jobsEnqueued:0.

// getJob(jobId) 가 waiting/delayed/active 면 skip → 갱신 없이 그대로 둠
if (existing && ['waiting','delayed','active'].includes(state)) return  // 앞당기기 불가

원인 ③  daily-limit deferred 재활성 경로 부재

일일 한도 도달 시 그 계정의 오늘자 pending을 전부 deferred로 뒤집고 scheduled_at += 24h. 그러나 loader의 due 쿼리는 WHERE status='pending'만 잡고, deferred → pending을 되돌리는 크론·스케줄러가 코드 전체에 없다. 재진입은 오직 그 execution의 +24h delayed 잡이 fire될 때만 가능 → 그 잡이 원인 ①②로 안 풀리면 영구 정지.

원인 ④  paused 시퀀스의 pending execution 누수

시퀀스 pause 시 BullMQ 잡은 지우지만 sequence_step_executions.status는 건드리지 않아 overdue pending이 영구 잔존(글로벌 797건). 재개 시 rescheduleOverdueExecutions의 NOW-shift 부하와 완료판정 오염을 유발.

원인 ⑤  untracked send path → delivered 추적 6%

warmup 발송이 SES로 나가지만 emails가 아닌 warmup_message에만 기록 → 그 메일의 모든 SES 이벤트가 orphan 처리(emails row not found → orphan retry cap reached — deleting). delivered가 emails 통계로 환원되려면 emails.sesMessageId 매칭이 선행돼야 하는데 row가 없음.

원인 ⑥·⑦  부수 — skip 부풀림 / 외부 요인

• skip 55만(30%) — PER_ACCOUNT_SEND_ENABLED dual-write로 같은 execution이 양쪽 큐에 적재 → PG atomic claim이 한쪽만 통과, 나머지는 execution.gate에서 "already processed" skip. 이중발송은 막지만 카운트가 부풀려짐. execution.gate.ts:51–57
• Anthropic 크레딧 소진 — budgeted:claude-sonnet-4-6 호출이 credit balance too low로 실패 + gemini-3-flash 1500ms 타임아웃 반복. personalization/agent 기능 영향.
• orphan mission 재큐 루프 — sweepOrphanedApprovedMissions가 미완료 sequences.send_campaign mission을 계속 재enqueue.

A. 즉시 운영 복구 코드 배포 불필요 · 분 단위

지금 멈춘 22.5만 잡을 흐르게 하는 1회성 조치:

1. 먼 미래 잡 일괄 재스케줄 — sequence-email:delayed에서 score가 7일 초과인 잡을 대상 execution의 실제 scheduled_at 기준으로 changeDelay 또는 remove 후 재적재. (128,690건)
2. deferred 복원 — scheduled_at <= now()인 deferred execution을 pending으로 UPDATE → 다음 loader tick이 정상 enqueue.
3. paused 누수 정리 — 글로벌 "뷰티유통사신규영업"의 overdue pending 797을 보존상태로 마킹.

⚠️ 재스케줄 시 stagger를 다시 cap 없이 적용하면 재발 — 반드시 B-①을 먼저 핫픽스하거나, 재주입 시 천장을 건 스크립트로 수행.

B. 코드 핫픽스 재발 방지 · P0

①②③은 서로 맞물림 — 셋을 함께 배포해야 "밀림 → 고착 → 영구정지" 사슬이 끊긴다.

C. 후속 정리 P1–P2

④ paused execution 상태 일관화 · ⑤ SES warmup fallback lookup · ⑥ dual-write 단일화 · ⑦ Anthropic 크레딧/폴백. 발송 정지와 독립이므로 A·B 안정화 후 순차 진행.

두 결함은 서로 독립이지만 같은 증상(발송 0)으로 수렴한다:

1. #5862 — daily-limit 도달 계정의 execution이 deferred로 바뀌면 loader가 영영 다시 안 집어듦(write/read가 같은 enum을 영구히 어긋나게 사용). 되돌릴 크론이 코드 전체에 없음.
2. #7665 — 단일 계정 집중 enrollment(글로벌 33k+)에서 idx×10초가 누적돼 잡이 며칠~75일 미래로 박힘. dedup 때문에 loader가 당겨오지도 못함.

왜 6월에 터졌나 — ①②는 4~5월에 잠복해 있었고, 글로벌 린다세일즈가 6월에 단일 계정에 수만 건씩 집중 enrollment(뷰티유통사 33k 등)를 활성화하면서 stagger idx가 임계를 넘고 per-account canary(#8220)가 켜지며 동시 발화. 소규모 시퀀스 시절엔 idx가 작아 잡이 초~분 단위 미래라 자연 소화됐다.