Email Send System / Beta

무한 워밍업 + 멀티도메인 = 무한 가속

Phase 3 · Active

2026-06-05

한 줄 요약

새 도메인은 30일 자동 워밍업 후 캠페인 풀에 자동 합류. 한도(분당 6건)는 그대로 유지하면서 도메인 수만 늘려 200× 가속.

핵심 지표

live · beta env

발송 도메인

19 → 200

목표

분당 발송 (목표)

1,200/min

200×

13만 건 발송

1.8h

13일 → 1.8시간

개발자 작업

자동 합류

발송 capacity 무한 확장 파이프라인

4 stages

이메일 워밍업 (Auto Warmup System)

새 도메인을 SES에 등록하면 6개 워커가 협력하여 sender reputation을 점진적으로 빌드. 사람처럼 자연스러운 메일 패턴을 시뮬레이션.

Phase 별 단계 — Alpha 실측 222 accounts

seed (day 0~7)일일 3~5건 · 221 accts

build (day 8~30)일일 15건 → 증가

graduate (day 30+)캠페인 풀 자동 합류

6 워커 협력

send · 1잡/3초

engage · open/reply

recovery · spam→inbox

reputation · 일일 metric

scheduler · phase 전환

bounce retry · 자동 재시도

Result

222개 도메인 자동 워밍업 → 30일 후 풀 자동 합류 → 도메인 무한 공급

도메인 풀 자동 추가 (무한 공급)

워밍업 완료된 도메인이 user_email_accounts에 status='active'로 등록되면 캠페인 발송 풀에 자동 합류. 도메인 추가에 코드 변경 불필요.

Result

19개 → 50개 → 100개 확장 가능. 발송 capacity N배 증가

멀티도메인 라운드로빈 분배

캠페인 생성 시 풀의 모든 도메인이 라운드로빈으로 enrollment에 균등 할당. 13만 leads = 도메인당 ~6,800 leads (편차 1).

Result

총 처리량 = 도메인 수 × 7건/분. 모든 도메인 동시 가동

Per-Account 격리 발송 (오늘 적용)

각 도메인에 전용 큐 + 전용 워커 배정. 한 도메인이 막혀도 다른 도메인 영향 0. 도메인별 한도가 병렬로 100% 활용.

Result

도메인 19개 → 분당 142건 이론, 실측 86건 (60% 활용)

Capacity Formula

총 처리량 = 도메인 수 (N) × 7 / 분

N을 늘리는 유일한 작업은 워밍업 1번 — 코드 변경 0, 자동 합류

⚠ 왜 도메인당 분당 7건 한계가 있나?

스팸 분류 방지를 위한 안전선입니다. 한 도메인에서 너무 빨리 발송하면:

Gmail / Outlook이 스팸으로 분류
SES가 도메인 reputation 강등 → bounce 율 ↑
최악의 경우 도메인 차단 (전체 캠페인 중단)

3단계 진화

06-02 → 06-05

P1 · BEFORE

단일 직원 한 명이 13만 통 처리

한 우체국 직원에게 13만 통의 편지를 모두 맡기는 상황. 분당 7통이 한계. 같은 직원이 너무 많이 보내면 수신자가 "이상한 발신처"로 의심 (스팸 분류).

accounts1

per_min7

eta~13d

spam_riskhigh

P2 · 06-04

19명의 직원, 한 줄로 줄 서기

19명의 우체국 직원을 두었지만 모든 편지가 하나의 대기줄에 줄 서서 차례로 나눠지는 구조. 일은 분산됐지만 큐 하나가 병목.

accounts19

per_min71.6

eta~1.3d

spam_riskmedium

P3 · TODAY

19개 창구, 각자 전용 대기줄

19명의 직원에게 각자 전용 대기줄. 처음부터 어느 직원이 처리할지 결정해서 그 직원의 대기줄에만 넣음. 한 줄이 막혀도 다른 줄 영향 없음. 같은 수신자의 후속 메일도 같은 직원이 담당.

accounts19

per_min86.5

queues98

spam_risklow

Before / After

phase 1 vs phase 3

Before

👤

1명 직원

7/min

13일 소요

→

After

👥👥👥

19명 + 전용 큐

86/min

1일 미만

멀티도메인의 6대 장점

6 advantages

⚡

발송 속도 N배

도메인 1개 = 7/min. N개 = 7N/min.

🛡

Reputation 분산

한 도메인 손상되어도 다른 도메인 정상.

📥

Inbox 도달율

분산 → 단일 대량 패턴 회피.

🎯

Per-Account 격리

한 큐 막혀도 다른 큐 영향 0.

♾

무한 확장

자동 워밍업 → 코드 변경 없이 추가.

🔄

자연 대화 흐름

같은 수신자 = 같은 발신자 (Sticky).

사업적 효과

measured

13×

발송 속도 — 13일 캠페인이 1일 내 완료

10일+

영업 follow-up 빠른 도달 — 골든타임 회수

19개

도메인 분산 — 한 계정 차단되어도 정상 발송

0건

중복 발송 — 3중 안전장치로 한 명에게 한 번만

쉬운 비유 — 우체국 직원

for non-engineers

이메일 발송 시스템을 우체국에 비유하면 이해하기 쉽습니다.

기술 용어	비유
발송 계정	우체국 창구 (직원 한 명)
이메일 한 통	편지 한 통
분당 7건 한도	직원 한 명이 분당 7장 처리 가능
SES (이메일 인프라)	우체국 본사 (속도 제한 있음)
Bounce (반송)	잘못된 주소로 돌아오는 편지
Reputation	우체국의 신뢰도 점수

시스템 구조

before · after

Before — 단일 큐 구조

phase 1

발송 대기 메일 ↓ [ 단일 큐 ] ↓ [ 1명 직원 ] ↓ 📧 분당 7건

After — 계정별 격리 큐 구조

phase 3

발송 대기 메일 ↓ [ 분배기 ] ─→ "어느 직원이 보낼지" 결정 ↓ ┌──────┬──────┬──────┬──────┬──────┐ │큐 #1 │큐 #2 │큐 #3 │ ... │큐 #19│ └──────┴──────┴──────┴──────┴──────┘ 👤 👤 👤 👤 ↓ ↓ ↓ ↓ 📧 분당 86건 (전체 합계)

진행 타임라인

4 events

2026-06-02 ~ 06-03

Phase 1 — 단일 계정 (chat.rinda.ai)으로 발송 시작

2026-06-04

Phase 2 — 19계정 균등 분배 (sender-pool reallocation) → 10× 가속

2026-06-05 19:21 KST

Phase 3 — Per-Account 모듈 활성화 (98 워커 자동 spawn) → +20%

2026-06-08 09:00 KST (예정)

단일계정 캠페인 5개 추가 활성화 — 19계정 풀로 재할당 완료

안전성 보장

6 layers

안전장치	역할
3중 중복 방지	같은 사람에게 두 번 보내지 않도록 큐 + DB + 워커 단계 모두 확인
발신자 고정 (Sticky)	첫 메일 보낸 사람이 후속도 담당 — 자연스러운 대화 흐름
이메일 검증	주소 검증 안 된 메일은 자동 차단 (스팸 보내지 않도록)
발송 한도 자동 관리	각 계정 분당 7.5건 자동 제한 (계정 평판 보호)
실시간 모니터링	문제 발생 시 즉시 Slack 알림
점진적 적용	한 캠페인씩 차근차근 적용 가능 (canary rollout)