Sequence Email Worker의 발송 직전 검증(MillionVerifier 3-tier cascade)이 모든 워크스페이스에 적용되는가? 코드 게이트 + beta 프로덕션 DB 전수조사로 검증.
코드상 워크스페이스·티어·플래그 단위의 on/off 분기가 존재하지 않는다. 발송 직전 Step 2의 검증 파이프라인은 모든 시퀀스 발송에 강제 실행되며, 끌 수 없다(opt-out 불가). 적용을 우회하는 경로는 ① 크레딧 고갈 시 fail-OPEN, ② 60일 내 verified 캐시 두 가지뿐이다 — 둘 다 워크스페이스 선택이 아니라 전역 동작이다.
검증 경로(verify-email/ + verification-cascade.service.ts)에서 workspace/tier/feature-flag 조건분기를 전수 검색한 결과, 해당 분기가 하나도 없다.
$ grep -rniE "workspace|tier|flag|enabled|getWorkspace|featureFlag" \
verify-email/ verification-cascade.service.ts
# → 매칭된 건 전부 주석 또는 provider circuit 설정(enabled:true)뿐.
# 워크스페이스 단위 조건분기: 0건호출 체인 전체가 워크스페이스와 무관하게 동작한다:
worker.ts:940 startSequenceEmailWorker() ← 부팅 시 기동
└ processor.ts:66 verifyAndDedup(ctx, email) ← 모든 발송 잡의 Step 2
└ pipeline.ts DEFAULT_PIPELINE = [format, role, dummy,
disposable, dedup, mvFailOpen] ← 6 gate 강제
└ mvFailOpen → verifyEmailCascade(maxTier:1, caller:"send_time")2026-05-31 cleanup으로 VERIFY_SEND_TIME_* 등 feature flag 3종이 제거됐다. 게이트 주석: "Tier 1 SSOT trust skip 2026-05-31 제거 — 항상 활성화." 워크스페이스별은 물론, 전역 토글조차 없다.
검증 로직에 내부/테스트 워크스페이스 제외 분기가 없다. 즉 그린다 자체 운영 계정(린다세일즈 등)도 동일하게 검증을 거친다 — 데이터 해석 시 내부 계정 분리가 필요한 이유(아래 §3).
"코드상 전부 적용"이 사실이라도, 실제로 cascade가 결과를 산출한 워크스페이스는 발송·enrich가 일어난 곳뿐이다. beta 프로덕션 DB로 전수집계했다.
174개 발송 WS 전부에 코드상 적용되고, 그중 134개에서 cascade가 실제 verdict를 찍었다. 나머지 40개는 #8103(6/2) 적용 후 신규 발송·enrich가 없었던 WS(legacy 구데이터만 보유).
| status | 건수 | 의미 |
|---|---|---|
legacy | 1,007,026 | 검증 cascade 도입 이전 구데이터 (발송 시 새로 검증) |
verified | 108,763 | cascade send → 발송 적격 |
inconclusive | 24,071 | catch-all 등 판정불가 → 발송 차단 |
unverified | 19,786 | 신규, 아직 미검증 |
failed | 96 | 명확히 부정 → 발송 차단 |
| status | 건수 |
|---|---|
| pending | 948,802 |
| sent | 725,318 |
| skipped | 415,146 |
| failed | 127,231 |
| delivered | 116,700 |
※ step_executions에 reason 텍스트 컬럼이 없어 skip 415k 중 send-time 검증 차단분만 분리 불가. verdict 차단의 직접 증거는 inconclusive 24,071 + failed 96.
신규 검증 결과(verified+inconclusive+unverified+failed)가 많은 순. 🏠 내부 = 그린다 자체 운영 계정.
| 워크스페이스 | sent | skipped | verified | incon | unv | legacy |
|---|---|---|---|---|---|---|
| 글로벌 린다세일즈 🏠 | 157,133 | 142,277 | 36,028 | 12,777 | 750 | 224,725 |
| 린다세일즈 🏠 | 455,334 | 197,576 | 25,232 | 2,211 | 7,795 | 664,460 |
| (주)플라이쿱 | 67 | 35 | 7,392 | 1,889 | 16 | 70 |
| 제이에이치유통 | 12,058 | 17,038 | 5,750 | 700 | 4 | 456 |
| YS Medi | 13,385 | 4,506 | 3,103 | 2 | 0 | 2,658 |
| 주식회사 인톡 | 3,309 | 6,514 | 2,721 | 1 | 0 | 2,325 |
| 스페로네_0430 | 3,399 | 2,590 | 1,713 | 386 | 111 | 811 |
| 주식회사 포메데시 | 539 | 194 | 1,140 | 406 | 515 | 0 |
| aeroway | 9,461 | 1,792 | 1,606 | 20 | 47 | 906 |
내부 2개 WS(글로벌 린다세일즈·린다세일즈)가 verified의 56%, inconclusive의 62%를 차지한다. 외부 고객 영향만 보려면 내부 WS 제외 재집계가 필요하다.
"모든 WS 적용"의 예외는 워크스페이스 선택이 아니라 전역 동작 2가지뿐이다.
| 경로 | 조건 | 결과 |
|---|---|---|
| 크레딧 고갈 fail-OPEN | MV credits ≤ 0 → CreditsExhaustedError | 검증 건너뛰고 그대로 발송 (워커 정지 방지). catch-all·invalid도 통과 가능 — 유일한 구멍 |
| 60일 verified 캐시 | 같은 lead 이메일이 60일 내 verified | 재검증 없이 즉시 통과 (isAlreadyVerified) |
둘 다 특정 워크스페이스를 봐주는 게 아니라, 모든 WS에 동일하게 적용되는 비용·성능 최적화다. 워크스페이스 단위 quota·rate limit·예외 화이트리스트는 존재하지 않는다.
| 분류 | 제한 | 값 / 동작 |
|---|---|---|
| Rate limit | MillionVerifier | 144 req/s (PQueue, 공식 160/s의 10% 마진). 429 → MX fallback |
| 분산 rate limiter | 기본 OFF — 워커 N대면 144×N/s로 공식 한도 초과 가능 (예약 플래그) | |
| Timeout | cascade 전체 | 30,000ms · Redis read 100~250ms |
| 장애 보호 | 재시도 / 회로 | tier당 2회(250·750ms) · 연속 3회 실패 → 5분 회로 open |
| 분산 회로 | 기본 OFF — 회로 상태가 워커별로 따로 놂 | |
| Credit | 잔액 차단 | ≤0 fail-OPEN · <100 warn · <1000 info |
| Cache TTL | send / verified 신뢰창 | 60일 |
| block | 7일 | |
| inconclusive | 1시간 (곧 재시도 → 그 사이 반복 차단) | |
| 동시성 | single-flight | 같은 이메일 동시요청 1건만 실행·공유 (중복 과금 방지) |
| 비용 | send-time maxTier | 발송 직전엔 MV 단일 tier만 (Findymail·Hunter 미호출) |
분산 회로·분산 rate limiter 둘 다 기본 OFF. 다중 워커 환경에서 ① MV 호출이 144×워커수/s로 공식 160/s를 넘길 수 있고, ② 회로 차단 상태가 워커마다 독립이라 한 워커가 차단해도 다른 워커는 계속 호출한다. 코드 주석도 "입증되면 켜라"고 예약만 해둔 상태.