이벤트나 언론 노출로 트래픽이 갑자기 몰리는 순간과, 악의적인 디도스(DDoS) 공격이 들어오는 순간은 서버 입장에서 처음엔 비슷하게 보입니다. 웹 방화벽(WAF)과 CDN을 함께 도입하면 정상 트래픽은 빠르게 분산 처리하고 비정상 트래픽은 원서버 도달 전에 차단할 수 있습니다. 도입 시 판단 기준과 설정 포인트를 정리합니다.
WAF와 CDN, 역할이 다른 두 개의 방어선
CDN(Content Delivery Network)은 전 세계 분산된 엣지 서버에 콘텐츠를 캐싱해 물리적으로 가까운 곳에서 응답함으로써 원서버 부하를 줄입니다. WAF(Web Application Firewall)는 요청 내용을 검사해 SQL 인젝션, 비정상 요청 패턴, 봇 트래픽을 원서버에 도달하기 전에 걸러냅니다.
둘은 겹치는 부분도 있지만, CDN은 "빠르게 나눠주는" 역할이고 WAF는 "나쁜 요청을 걸러내는" 역할로 구분하면 도입 판단이 쉬워집니다.
도입이 필요한 신호
- 특정 이벤트·공지 이후 짧은 시간에 평소 대비 10배 이상 트래픽 급증 경험이 있음
- 서버 로그에 짧은 시간 내 동일 IP·패턴의 대량 요청이 반복적으로 관찰됨
- 해외에서 유입되는 비정상적인 요청 비율이 높음
- 로그인 폼·게시판에 자동화된 스팸·크리덴셜 스터핑 시도가 잦음
이 중 하나라도 해당된다면 CDN·WAF 도입을 검토할 시점입니다.
디도스 공격 유형과 방어 계층
| 공격 유형 | 특징 | 주요 방어 계층 |
|---|---|---|
| 네트워크 계층(L3/L4) | 대량 패킷으로 회선·인프라 자체를 마비 | CDN/클라우드의 네트워크 레벨 스크러빙 |
| 애플리케이션 계층(L7) | 정상 요청처럼 보이는 대량 HTTP 요청 | WAF 룰, 레이트 리미팅, 봇 탐지 |
| 봇넷 크롤링·스크래핑 | 콘텐츠 대량 수집, 로그인 시도 | WAF 봇 관리, CAPTCHA, IP 레퓨테이션 |
WAF 규칙 설계 기본 원칙
WAF를 처음 도입할 때는 전면 차단보다 탐지 모드로 먼저 운영하는 것이 안전합니다.
- 1~2주간 로그 모드(차단 없이 기록만)로 운영해 오탐(false positive) 패턴 확인
- 정상 사용자 요청이 걸리는 규칙은 예외 처리(화이트리스트)
- 확인 후 실제 차단 모드로 전환
- 차단 로그를 주기적으로 리뷰해 규칙을 계속 다듬음
처음부터 강하게 차단 모드로 켜면 정상 고객의 결제·문의가 막히는 사고로 이어질 수 있습니다.
CDN 캐시 정책과 오리진 보호
CDN을 도입할 때 캐시 정책을 잘못 잡으면 오히려 원서버로 요청이 그대로 넘어가 방어 효과가 없습니다.
- 정적 자산(이미지·CSS·JS)은 장기 캐시 + 파일명에 버전 해시 부여
- 동적 페이지(게시판 목록 등)는 짧은 캐시 또는 캐시 제외, 대신 레이트 리미팅으로 보호
- 오리진 서버는 CDN IP 대역에서만 접근을 허용해 직접 우회 공격을 차단
레이트 리미팅 설정 예시
로그인·검색·API처럼 남용되기 쉬운 엔드포인트는 별도로 요청 빈도를 제한합니다.
# Nginx 레이트 리미팅 예시
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location /bbs/login_check.php {
limit_req zone=login burst=10 nodelay;
}WAF·CDN 서비스를 이용 중이라면 위와 유사한 규칙을 관리 화면에서 IP·경로 단위로 설정할 수 있습니다.
공격 발생 시 대응 순서
- 서버 응답 지연 확인 즉시 접속 로그에서 이상 패턴(특정 경로·IP 집중) 식별
- WAF·CDN 관리 화면에서 해당 국가·IP 대역 임시 차단 또는 "공격 방어 모드(under attack)" 활성화
- DB·애플리케이션 서버 리소스(CPU, 커넥션 수) 실시간 확인
- 공격 종료 후 로그 분석으로 재발 방지 규칙 추가
SEO 관점에서 CDN·WAF가 미치는 영향
속도 개선은 코어 웹 바이탈 지표에 직접 영향을 줘 검색 순위에도 긍정적입니다. 다만 설정을 잘못하면 오히려 SEO에 해가 될 수 있습니다.
- WAF가 검색엔진 크롤러의 User-Agent나 IP를 실수로 차단하면 색인 누락으로 이어짐
- CDN 엣지 서버의 캐시된 페이지가 오래되어 최신 콘텐츠가 검색 결과와 불일치
- 봇 차단 규칙이 과도해 정상적인 SEO 진단 도구(사이트 감사 크롤러)까지 막힘
도입 후에는 서치 콘솔의 크롤링 통계에서 요청 실패율이 늘지 않았는지 반드시 함께 확인해야 합니다.
실무 정리
WAF·CDN은 평소에는 존재감이 없지만, 트래픽 급증이나 공격 상황에서 서비스 생존을 가르는 인프라입니다. 서버 이전이나 도메인 이관을 준비 중이라면 DNS 무중단 이관 절차와 함께 CDN 전환 시점을 조율하는 것이 좋습니다. 트래픽 급증 대응 인프라 설계가 필요하면 무료 견적요청으로 현재 트래픽 패턴을 공유해 주세요.
자주 묻는 질문 (FAQ)
CDN만 도입하면 디도스 방어가 충분한가요? +
CDN은 네트워크 계층 공격 분산에는 효과적이지만, 애플리케이션 계층의 정교한 요청 공격은 WAF의 규칙 기반 탐지가 함께 있어야 방어력이 올라갑니다.
방문자가 적은 소규모 사이트도 WAF가 필요한가요? +
트래픽 규모와 무관하게 로그인 폼, 게시판 스팸, 취약점 스캔 시도는 소규모 사이트에도 상시 발생합니다. 기본적인 봇 차단·레이트 리미팅은 규모와 무관하게 권장됩니다.
WAF 규칙이 너무 강하면 정상 고객도 차단되나요? +
네, 특히 특수문자가 많은 문의 내용이나 해외 VPN 사용자가 오탐으로 차단되는 사례가 있어, 도입 초기에는 로그 모드로 먼저 운영해 조정하는 것이 안전합니다.
CDN 도입 후 콘텐츠 업데이트가 바로 반영되지 않습니다. +
캐시가 남아있는 상태입니다. 관리 화면의 캐시 무효화(purge) 기능을 사용하거나, 파일명에 버전을 붙여 캐시를 우회하는 방식을 함께 사용하세요.
무료 CDN·WAF로도 충분한가요? +
소규모 사이트라면 무료 플랜으로도 기본적인 방어가 가능하지만, 커머스·회원제처럼 중요 데이터를 다루는 사이트는 SLA와 규칙 커스터마이징이 가능한 유료 플랜을 권장합니다.
공격을 받는 도중에 CDN·WAF를 새로 붙일 수 있나요? +
DNS 전환만으로 적용되는 서비스는 긴급 상황에서도 비교적 빠르게 붙일 수 있지만, 근본적인 안정성을 위해서는 평소에 미리 도입해 규칙을 다듬어 두는 것이 훨씬 안전합니다.