트래픽 폭증기 멀티 CDN·DDoS 이중 방어 설계법

4월 한 달 동안 두 번, 글로벌 CDN이 무너졌습니다

2026년 4월 26일부터 27일 사이, eBay가 글로벌 단위로 멈췄습니다. 결제와 체크아웃 API가 응답을 멈췄고, 313 Team이라는 그룹이 DDoS 공격을 자신들이 했다고 주장했어요(The Cyber Express 보도). 같은 달 4월 3일에는 Cloudflare 본체가 54분간 다운됐습니다(Statusfield 분석). 한 회사도 아니고 인터넷 트래픽의 상당 부분을 책임지는 CDN 본체가 멈춘 것이죠.

여기에 한 가지 데이터가 더 겹칩니다. Imperva의 2026년 Bad Bot Report에 따르면 웹 트래픽의 53%가 봇이고, 인간 트래픽은 47%까지 떨어졌습니다(Imperva 공식 보고서). Akamai의 같은 해 보고서는 AI 봇 트래픽이 전년 대비 300% 증가했다고 짚었고, 미디어·퍼블리싱 업종이 가장 큰 영향을 받았어요(Akamai AI Pulse). e-commerce도 시즌 트래픽 폭증 시 봇 비중이 함께 뛰는 만큼 같은 흐름의 영향권에 있습니다.

이 흐름이 5월 가정의 달 트래픽 시즌과 만나면 어떻게 될까요. 정상 사용자 트래픽이 평소 대비 30% 이상 뛰는 구간에, 같은 시간 봇 트래픽도 함께 폭증합니다. 월요일 글에서 정리한 단일 클라우드 SPOF의 CDN 레이어 버전이 바로 이 글에서 다룰 주제예요.

단일 CDN으로는 더 이상 못 버티는 이유 3가지

단일 CDN을 쓰는 것이 잘못은 아닙니다. 트래픽이 작고 글로벌이 아니면 단일 CDN이 운영도 단순하고 비용도 효율적이에요. 그러나 다음 세 가지 조건 중 하나라도 해당된다면 단일 CDN은 위험합니다.

특히 ③번이 2026년 들어 빠르게 늘고 있어요. Cloudflare가 발표한 Q1 2026 인터넷 장애 보고서는 분기 단위 인터넷 장애가 직전 분기 대비 큰 폭으로 증가했다고 짚었습니다. CDN 의존도가 높아질수록, CDN 자체가 새로운 SPOF가 되고 있다는 뜻이죠.

멀티 CDN, Active-Active와 Active-Passive 중 무엇을 고를까

멀티 CDN 구조는 크게 두 가지로 나뉩니다. 둘 중 무엇이 옳다는 정답은 없고, 트래픽 규모와 RTO 요구에 따라 선택이 달라져요.

한국 중견 e-commerce 기준으로는 Active-Passive에서 시작해 시즌마다 가중치를 조정하는 패턴이 가장 일반적입니다. 평소엔 메인 CDN에 95% 트래픽, 5월·11월 같은 트래픽 시즌엔 보조 CDN 비중을 20~30%로 끌어올리는 구조죠. 이렇게 하면 평소 비용은 거의 그대로면서, 시즌에는 메인 CDN의 부하를 분산해 장애 위험을 낮출 수 있어요.

DDoS 방어, L3·L4·L7 세 계층을 따로 봐야 합니다

DDoS는 한 종류가 아닙니다. 네트워크 계층(L3/L4)과 애플리케이션 계층(L7)에서 공격 양상이 완전히 다르고, 차단 방법도 다릅니다.

L3/L4, 볼류메트릭 공격

대량의 패킷이나 SYN flood로 회선 자체를 마비시키는 공격이에요. 대부분의 글로벌 CDN은 기본 차단합니다. Anycast 네트워크 위에서 트래픽을 자동 분산해 흡수하는 구조죠. 사용자 입장에서 별도 설정이 거의 필요 없습니다.

L7, 애플리케이션 공격

여기가 진짜 어렵습니다. HTTP flood, slowloris, 로그인 무차별 시도, 그리고 2026년 들어 가장 빠르게 늘고 있는 AI 봇 스크래핑까지. 정상 트래픽처럼 보이기 때문에 자동 차단이 어렵고, WAF와 Bot Management 정책을 별도로 설계해야 합니다.

봇 시그니처

2026년 AI 봇 트래픽이 전년 대비 300% 증가한 상황에서, 단순 IP 차단으로는 효과가 떨어집니다. User-Agent, JA3 fingerprint, 행동 패턴, JavaScript 챌린지를 조합한 다층 봇 식별이 표준이 됐어요. Fastly Next-Gen WAF, Cloudflare Bot Management, Akamai Bot Manager 같은 도구가 이런 다층 식별을 제공합니다.

멀티 CDN 4가지 구성 패턴 비교

실무에서는 한 가지만 쓰지 않고 가중치 + Geographic 조합이 가장 흔합니다. 한국·일본 사용자는 S-CDN PoP로 우선 보내고, 그 외 지역은 Fastly가 받는 구조에 평소 가중치를 조정하는 식이죠.

멀티 CDN 도입 전 반드시 점검할 5가지

설정만 바꾼다고 멀티 CDN이 작동하지 않습니다. 도입 전 다음 5가지를 함께 설계해야 실제 페일오버가 작동해요.

1. 오리진 동기화

두 CDN이 같은 오리진을 보더라도, Origin Shield 설정이 다르면 캐시 미스 패턴이 달라집니다. 두 CDN의 Origin Shield 정책을 동일 리전·동일 방식으로 맞추세요.

2. 인증서 동기화

SSL 인증서를 두 CDN에서 따로 관리하면, 갱신 시점에 한쪽만 만료되는 사고가 자주 발생합니다. ACME·Let's Encrypt 자동 갱신을 일원화하거나, 인증서 발급 워크플로를 하나의 도구로 통합해두세요.

3. 캐시 키 정합성

두 CDN이 같은 URL에 다른 캐시 키를 쓰면, 사용자가 CDN을 바꿀 때마다 캐시 미스가 발생해 오리진 부하가 두 배가 됩니다. Vary 헤더, 쿼리 파라미터 정렬, Cookie 처리 정책을 양쪽에서 동일하게 맞춰야 해요.

4. 관측·로그 통합

두 CDN이 별도 콘솔로 로그를 쌓으면, 장애 시 어디서 무엇이 막혔는지 추적이 어렵습니다. Datadog·New Relic 같은 외부 관측 도구로 두 CDN 로그를 한 곳에 모으는 구조가 표준입니다.

5. 비용 모델 통합

두 CDN의 과금 단위가 다르면 (전송량 vs 요청수 vs 둘 다) 시즌 트래픽 변동에 비용이 예측 불가능해집니다. 양쪽 과금 구조를 한 시뮬레이션 모델로 묶어두면, 시즌 가중치 조정이 비용 계산까지 한번에 가능해요.

실무에서 자주 보는 흔한 실수 3가지

1. 페일오버 테스트 누락. 메인 CDN 강제 다운 시뮬레이션을 분기마다 1번씩 돌려야 실제 작동을 검증할 수 있어요. 설정 직후 한 번만 테스트하고 6개월 잊으면 그 사이 정책 변경으로 페일오버가 깨져 있는 경우가 많습니다.

2. WAF 정책 한쪽만 업데이트. 새로운 봇 시그니처를 메인 CDN에만 적용하면, 페일오버 시 보조 CDN이 봇 트래픽을 그대로 통과시킵니다. 정책 동기화 자동화가 필요해요.

3. 비용을 메인 CDN 기준으로만 계산. 시즌에 보조 CDN 비중이 30%로 올라가면 그쪽 비용이 따로 발생합니다. 시즌 시뮬레이션을 둘 다 합쳐서 미리 계산해두지 않으면 청구서에서 깜짝 놀라요.

스피디의 멀티 CDN 설계 접근법

스피디는 Fastly Korea Authorized Reseller(№ IC-1036)이자 S-CDN 자체 브랜드 운영사입니다. 한국 시장에서 Fastly의 Deliver/Compute/Security 전체 라인업을 직접 재판매하면서, 동시에 자체 CDN 브랜드도 같은 회사가 운영하는 사실상 유일한 구조입니다. S-CDN 엣지 PoP 설계 가이드에서 한국·일본·동남아 PoP 구성을 더 자세히 다뤘습니다.

대표적인 두 가지 조합을 정리합니다.

• 한국·일본·동남아 트래픽 주력: S-CDN 메인(95%) + Fastly 보조(5%). 시즌엔 Fastly 가중치 20~30%로 조정

• 글로벌 트래픽 주력: Fastly 메인 + S-CDN 한국·일본 PoP 보조. Geographic 라우팅으로 지역 최적화

두 CDN을 한 회사가 운영하기 때문에 인증서 동기화, 캐시 키 정합성, 관측 통합, 비용 모델 통합 5가지 점검 항목을 한 번에 처리할 수 있습니다. 두 벤더에 따로 연락하고 따로 청구서를 받는 부담이 없죠.

이것만 기억하세요

자주 묻는 질문