국가별 영업일 발송 게이트
beta 실데이터 기반 최적 설계

00 결론

01 실측 데이터 (beta)

delayed 97,216건이 KST 언제 발사되나 (전수 계산)

업무외(18–09 KST) 발사예정 49.4% — 단 상당부분은 해외 수신자 현지 낮시간을 노린 의도된 결과(기존 clampToBusinessHours가 수신자 tz 기준).

수신자 국가 분포 (60일 발송)

02 사용자 우려 해부 — "발송시 LLM 국가판단"

우려: "수신자국 영업일로 하려면 LLM으로 국가 판단해야 하고, 수십만건이라 문제 많다." → 실데이터로 보면 세 단계 모두 LLM이 불필요:

03 최적 아키텍처 — LLM을 발송경로에서 제거

계층 B — country→tz 우선순위 (싼 것부터, 결정론적)

1. lead.country(기지) → IANA tz 정적맵 — 공짜. 10,998 오발 즉시 해소 (현재 누락, 최고 ROI)
2. 이메일 ccTLD(.co.kr·.jp·.de) → country — 공짜·결정론적
3. 도메인→country Redis 캐시 — 고유 도메인 ≪ 발송건수 → 도메인당 1회 해소 후 영구 재사용
4. 잔여 모호 .com → 보수적 글로벌 디폴트 또는 배치 LLM(도메인당 1회·enrichment·영구 캐시) — LLM은 여기 한 곳, 발송경로 밖

// 발송 게이트: 잡에 이미 있는 tz로 순수 산술, LLM/DB/Redis 호출 0
const cal = businessCalendarFor(job.data.timezone)   // IANA 문자열
const w = decideSendWindow(new Date(), cal)        // luxon, DST 정확
if ('deferUntil' in w && cal.confident) {        // 디폴트 tz면 fail-open
  await job.moveToDelayed(w.deferUntil.getTime())
  throw new DelayedError()
}

04 비용 분석 (수십만건 1배치)

성능: 게이트는 메모리 산술 1회. BullMQ가 어차피 delayed 97k를 순회하므로 추가 부하 사실상 0. DB·Redis 추가 호출 없음(tz는 페이로드 동봉). Redis Lua/Function 불필요.

05 예상 오류 & 방어

06 권장 실행 순서 (ROI순)

1. (공짜·최고ROI) country→tz 변환 복구 — 기지 country 10,998 오발 즉시 해소. LLM·인프라 0.
2. (공짜) ccTLD + 도메인캐시 cascade — 미상 56.5% 잠식.
3. 발송 게이트 출시 — execution.timezone+luxon, 디폴트 tz는 fail-open.
4. (선택·저가) 잔여 도메인 배치 LLM — enrichment 1회·영구 캐시.
5. (phase 2) 국가별 공휴일.