웹서비스 앞에 방화벽과 침입방지시스템을 설치해도 대규모 DDoS 공격을 막지 못할 수 있다. 장비가 공격 패킷을 정확히 구분하더라도 인터넷 회선이 먼저 가득 차면 정상 사용자의 요청이 방어 장비까지 도착하지 못하기 때문이다. 반대로 트래픽이 많다는 이유만으로 모두 차단하면 이벤트·티켓 예매처럼 정상적인 접속 급증을 공격으로 오인할 수 있다.
Anti-DDoS 시스템의 핵심은 단순한 임계치 차단이 아니다. 평상시 트래픽과 서비스 상태를 기준으로 공격 가능성을 판단하고, 서비스 회선보다 앞단의 충분한 처리 용량에서 악성 트래픽을 제거한 뒤 정상 트래픽만 원래 서버로 전달하는 체계다. 탐지 정확도, 우회 속도, 세정 용량, 원본 서버 보호와 운영 절차가 함께 맞아야 실제 가용성을 지킬 수 있다.
1. Anti-DDoS는 탐지·전환·세정·복귀가 이어지는 체계다
Anti-DDoS는 특정 장비 한 대의 이름이라기보다 탐지 센서, 정책 엔진, 트래픽 전환 수단, 세정 설비, 모니터링과 대응 절차를 묶은 방어 체계로 보는 편이 정확하다. 일반적인 흐름은 다음과 같다.
- 네트워크 흐름, 패킷·요청 특성, 서버 응답 상태를 관찰한다.
- 정상 기준선이나 알려진 공격 특성과 비교해 의심 트래픽을 식별한다.
- 인라인 장비가 즉시 처리하거나, 트래픽 경로를 통신사·클라우드의 세정센터로 전환한다.
- 세정 구간에서 공격 트래픽을 폐기·제한하고 정상 트래픽을 원본 서버로 전달한다.
- 공격이 끝난 뒤 정책과 경로를 정상화하고, 오탐·미탐과 서비스 영향을 분석한다.
KISA의 DDoS 공격 대응 가이드는 공격을 대역폭 소진, 자원 소진, 웹·DB 부하 공격 등으로 나누어 설명한다. 이 구분이 중요한 이유는 공격의 병목이 서로 다르기 때문이다. 회선을 채우는 공격에는 상위 네트워크의 대용량 세정이 필요하고, 연결 상태를 고갈시키는 공격에는 프로토콜 검증이, 정상 형식의 HTTP 요청으로 애플리케이션을 압박하는 공격에는 요청 맥락을 보는 계층 7 분석이 필요하다. KISA 보호나라&KrCERT/CC — DDoS 공격 대응 가이드
2. 탐지는 한 가지 임계치가 아니라 여러 신호의 결합이다
트래픽 양과 변화율
bps, pps, 연결 수, 초당 요청 수가 평소 범위를 크게 벗어나는지 보는 방식이다. 단순하고 빠르지만 고정 임계치만 사용하면 정상적인 행사 트래픽을 차단하거나, 임계치 아래에서 천천히 증가하는 공격을 놓칠 수 있다. 요일·시간대·서비스별 정상 기준선을 함께 관리해야 하는 이유다.
프로토콜과 패킷 특성
IP·TCP·UDP·ICMP 헤더가 정상 구조인지, 특정 포트와 플래그 조합이 비정상적으로 반복되는지, 연결 성립 과정이 타당한지를 검사한다. AWS Shield의 공식 문서는 패킷 검증, ACL과 속도 제한, 의심도 점수, 무상태 TCP SYN 프록시 등을 완화 기능의 예로 설명한다. 이는 특정 제품의 구현 사례이지만, Anti-DDoS가 단순 IP 차단보다 패킷 유효성과 연결 행위를 함께 본다는 점을 잘 보여준다. AWS — List of AWS Shield DDoS mitigation features
정상 기준선과 이상 징후
출발 지역, 사용자 에이전트, URL, 요청 비율, 오류율 같은 분포가 평소와 얼마나 달라졌는지 분석한다. Google Cloud Armor Adaptive Protection은 백엔드별 트래픽을 학습해 이상 활동을 탐지하고 공격 시그니처와 완화 규칙 후보를 만든다. 공식 문서도 학습 기간이 필요하고, 새 보안 정책을 만들면 기존 기준선이 폐기되어 다시 학습해야 한다고 설명한다. 따라서 ‘AI 탐지’라는 기능명보다 기준선이 무엇이고 변경·신규 서비스 기간을 어떻게 처리하는지 확인해야 한다. Google Cloud — Adaptive Protection overview
서비스 상태와의 상관관계
트래픽 증가만 보지 않고 지연시간, 오류율, CPU·메모리, 연결 큐와 같은 서비스 상태를 함께 본다. 정상 트래픽이 늘어도 서버가 건강하다면 공격 확신을 높이지 않을 수 있고, 상대적으로 작은 트래픽이라도 특정 자원을 고갈시켜 장애가 발생하면 빠르게 대응할 수 있다. 다만 상태 점검 자체가 실패하거나 관측 구간이 좁으면 판단도 흔들리므로 네트워크와 애플리케이션 관측을 분리해 확인해야 한다.
3. 대규모 공격은 회선 앞단에서 막아야 한다
사내에 설치한 Anti-DDoS 장비의 처리 성능이 충분해도 인터넷 회선 용량을 넘는 공격에는 한계가 있다. 공격 패킷이 장비에 도달하기 전에 통신사 구간과 기업 회선이 포화되기 때문이다. 온프레미스 장비는 세밀한 내부 정책과 빠른 로컬 대응에 유리하지만, 대역폭 공격에는 ISP나 클라우드 기반 세정 서비스와의 연계가 필요하다.
세정 구조는 크게 두 형태로 이해할 수 있다.
- 상시 인라인·상시 프록시 방식: 모든 트래픽이 평소부터 사업자의 엣지나 클라우드 네트워크를 거친다. 탐지 후 별도 경로 전환 시간이 짧지만, 서비스 진입점·DNS·인증서·원본 서버 접근제어를 그 구조에 맞춰 설계해야 한다.
- 공격 시 우회 방식: 평소에는 기존 경로를 사용하다가 공격 때 BGP 경로 광고나 DNS 변경 등으로 트래픽을 세정센터에 보낸다. 기존 구성을 유지하기 쉽지만, 탐지부터 우회가 실제 전파될 때까지의 시간과 복귀 절차를 시험해야 한다.
KISA DDoS 사이버대피소는 보호 대상 사이트의 IP 주소나 도메인을 대피소로 이동시키고, 유입 트래픽을 분석해 정상 트래픽만 원래 사이트로 연결하는 구조를 설명한다. 안내 절차에는 사전 등록과 환경 분석, 공격 발생 후 방어 적용, DNS 정보 변경, 모니터링과 결과 통보가 포함된다. 이는 세정 용량만 구매한다고 준비가 끝나는 것이 아니라 사전 등록과 전환 조건이 필요하다는 실무적 사례다. KISA 보호나라&KrCERT/CC — DDoS 사이버대피소
4. 공격 유형에 따라 완화 동작도 달라진다
| 공격이 노리는 지점 | 탐지에 쓰는 신호 예시 | 대표적인 완화 방식 | 운영상 주의점 |
|---|---|---|---|
| 회선 대역폭 | bps·pps 급증, 출발지·프로토콜 분포 변화 | 상위망 세정, ACL, 속도 제한, 분산 흡수 | 기업 회선에 도달하기 전에 처리해야 함 |
| 네트워크·전송 계층 상태 | SYN 비율, 비정상 플래그, 연결 실패 | 패킷 검증, SYN 프록시·쿠키, 비정상 패킷 폐기 | 정상 연결의 지연과 장비 상태 테이블 보호를 함께 확인 |
| DNS 등 특정 프로토콜 | 질의 유형, 응답 크기, 반사·증폭 패턴 | 프로토콜별 검증, 비율 제한, Anycast 분산 | 권한 DNS와 원본 서버의 실제 수용량을 따로 점검 |
| 웹·API·애플리케이션 | URL·세션·오류율·요청 분포·백엔드 상태 | WAF 규칙, 요청 속도 제한, 캐시, 챌린지 | 로그인·결제 같은 고비용 정상 요청의 오탐 가능성 |
IP 주소만 차단하는 방식은 분산된 봇넷이나 주소 위조가 사용될 때 효과가 제한적이다. 반대로 속도 제한을 넓게 적용하면 통신사 NAT나 기업 프록시 뒤의 정상 사용자까지 함께 막을 수 있다. 탐지 규칙은 ‘공격을 얼마나 많이 버렸는가’뿐 아니라 정상 요청의 손실, 백엔드 부하, 사용자 오류율을 함께 보며 조정해야 한다.
완화가 공격 트래픽을 완전히 없앤다고 가정해서도 안 된다. 탐지와 세정이 작동한 뒤에도 남은 트래픽을 애플리케이션이 처리할 수 있는지, 원본 서버가 우회 경로로 직접 노출되지 않는지까지 확인해야 한다. 방어 효과는 차단량 하나가 아니라 서비스 지연과 오류, 정상 요청 성공률을 함께 보며 검증해야 한다.
5. 자동 차단보다 전환 조건과 통신 절차가 먼저다
대규모 공격 대응은 보안 장비 설정만으로 끝나지 않는다. 관제 담당자, 네트워크 운영자, 서비스 책임자, 통신사·클라우드 사업자가 같은 기준으로 움직여야 한다. 최소한 다음 항목은 공격 전에 합의해야 한다.
- 어떤 서비스 지표와 공격 신호가 충족되면 우회를 시작하는가?
- 자동 완화와 사람 승인이 필요한 조치의 경계는 어디인가?
- 24시간 연락 가능한 담당자와 대체 담당자는 누구인가?
- 전환 중 DNS, BGP, 방화벽 허용 목록과 원본 서버 접근제어는 누가 바꾸는가?
- 정상 트래픽 손실과 세정 효과를 어떤 로그·지표로 확인하는가?
- 공격 종료 후 언제, 어떤 단계로 원래 경로에 복귀하는가?
IETF RFC 8782는 DDoS 공격을 받은 측의 클라이언트가 완화 사업자 측 서버에 보호를 요청하고 상태를 확인하는 DOTS 신호 채널을 표준화한다. 특정 조직이 반드시 DOTS를 도입해야 한다는 뜻은 아니지만, 회선이 포화되는 상황에서도 ‘누가 어떤 대상을 보호해 달라고 요청하고, 적용 상태를 어떻게 확인할지’를 사전에 정형화해야 한다는 점을 보여준다. IETF — RFC 8782, Distributed Denial-of-Service Open Threat Signaling Signal Channel Specification
6. 실무에서는 방어 용량보다 운영 가능성을 검증한다
제품 비교표의 최대 처리량만으로는 서비스 보호 수준을 판단하기 어렵다. 패킷 크기와 프로토콜, 암호화 트래픽 검사, 동시 연결 수에 따라 실제 처리 여유가 달라지며, 상위 사업자의 세정 용량이 커도 고객별 정책 적용과 경로 전환이 늦으면 장애 시간은 길어진다.
도입 전에는 다음을 시험하는 편이 실용적이다.
- 정상 피크와 공격 임계치를 구분할 수 있도록 서비스별 기준선을 보유하는가?
- 원본 서버는 세정 사업자나 승인된 경로에서만 접근할 수 있는가?
- 우회 후에도 TLS, 세션, 클라이언트 IP 전달, API 인증이 정상 동작하는가?
- 탐지 시간, 완화 시작 시간, 정상 트래픽 회복 시간을 각각 측정하는가?
- 통신사 장애나 세정 서비스 장애 때 사용할 대체 경로가 있는가?
- 이벤트와 정기 점검 후 예외 규칙을 회수하고 기준선을 다시 검토하는가?
소규모 조직은 자체 세정센터를 구축하기보다 사전 등록형 외부 서비스와 관리형 CDN·DDoS 방어를 조합하는 편이 현실적일 수 있다. 대규모 조직은 여러 회선과 지역, 자체 장비와 외부 세정 서비스를 함께 운영할 수 있지만 경로·정책·로그가 늘면서 관리 복잡성도 커진다. 멀티벤더 구성은 용량을 더하는 문제가 아니라 탐지 주체, 전환 권한, 정책 우선순위와 장애 책임을 명확히 하는 문제다.
Anti-DDoS 체계의 성패는 공격 트래픽을 많이 버리는 데만 있지 않다. 정상 사용자가 서비스를 계속 이용하도록 악성 트래픽을 회선 앞단에서 줄이고, 필요한 정책을 빠르게 적용한 뒤 그 결과를 검증하는 것이 목적이다. 도입 검토에서는 최대 방어 수치보다 정상 기준선의 품질, 실제 전환 시간, 원본 서버 보호, 오탐 처리와 복귀 훈련을 먼저 확인해야 한다.
참고자료
자료 확인 기준: 2026년 10월 9일. AWS와 Google Cloud 자료는 특정 서비스의 구현 예시로 활용했으며, 모든 Anti-DDoS 제품이 동일하게 동작한다는 의미가 아니다.