사이트가 갑자기 먹통이 되고 접속 로그에 낯선 IP가 쏟아지면 DDoS를 의심하게 됩니다. 이때 많이 하는 첫 대응이 서버 사양을 올리는 건데요, 대부분의 경우 그건 답이 아닙니다. 공격 유형에 따라 손써야 할 곳이 완전히 다르기 때문이에요.
회선을 막는 공격과 서버를 지치게 하는 공격
크게 두 갈래로 나뉩니다. 하나는 대역폭을 통째로 채우는 공격이에요. 쓰레기 트래픽을 어마어마하게 쏟아부어 회선 자체를 막아버립니다. 이건 서버 사양과 무관합니다. 고속도로 입구가 막혔는데 집 안 살림을 늘리는 격이라, CPU를 아무리 키워도 소용이 없어요. 회선 앞단에서 걸러내야 합니다.
다른 하나는 정상 요청처럼 보이는 공격입니다. 트래픽 양은 크지 않은데 검색이나 로그인처럼 서버가 힘들어하는 요청만 골라서 반복해요. 이건 대역폭 그래프에 잘 안 잡혀서 원인을 찾기 어렵습니다. 웹 애플리케이션 단에서 요청 패턴을 보고 걸러야 합니다.
그래서 첫 단계는 어느 쪽인지 구분하는 것이에요. 대역폭 사용량이 평소보다 폭증했는지, 아니면 트래픽은 비슷한데 CPU나 DB만 치솟는지를 보면 방향이 잡힙니다.
어디까지가 호스팅사 몫일까
대역폭을 채우는 공격은 개별 서버에서 막을 수 없습니다. 이미 트래픽이 데이터센터 회선까지 도달한 뒤라서요. 이건 데이터센터와 통신사 구간에서 걸러야 하는 영역이라 호스팅 제공자의 방어 체계가 있느냐가 결정적입니다.
반면 애플리케이션을 노리는 공격은 고객 쪽에서 할 수 있는 일이 많습니다. 요청 빈도 제한을 걸고, 무거운 페이지에 캐시를 적용하고, 로그인 같은 민감한 경로에 추가 검증을 두는 식이에요. 이런 준비가 되어 있으면 같은 공격을 받아도 버티는 정도가 다릅니다.
계약할 때 DDoS 방어가 어느 규모까지 포함되는지 확인해두시는 게 좋습니다. 기본 제공 범위를 넘어서면 별도 서비스가 필요한 경우가 있어서, 사고가 난 뒤에 알게 되면 대응이 늦어집니다.
방어 용량은 숫자보다 단위를 먼저 보세요
방어 서비스 소개에 적힌 Gbps와 Mpps는 서로 다른 능력을 뜻해요. bps는 초당 전달되는 비트 수이고, pps는 초당 전달되는 패킷 수예요. Gbps는 십억 비트, Mpps는 백만 패킷을 기준으로 표시합니다. 같은 대역폭이라도 작은 패킷이 많이 들어오면 처리해야 할 개수가 늘어요. 그래서 회선 용량이 남아 있어도 라우터 같은 네트워크 장비가 먼저 부담을 받을 수 있습니다.
웹 요청을 다룰 때는 rps라는 단위도 나와요. 초당 요청 수를 뜻하며, 회선으로 들어오는 데이터의 양과는 구분해서 읽어야 합니다. 업체가 공개한 대역폭 수치만 보고 웹 요청 처리 능력까지 같은 수준이라고 생각하면 곤란해요. 견적서에 적힌 수치가 비트 기준인지, 패킷 기준인지, HTTP 요청 기준인지부터 확인해두세요.
상담할 때는 우리 서비스의 정상 사용량도 같은 단위로 준비하면 이야기가 쉬워져요. 평소 대역폭 그래프만 보여주기보다 패킷 수와 웹 요청 수를 함께 요청해보세요. 서로 다른 단위의 최고 수치를 한 줄에 놓고 비교하기보다, 어떤 자원이 먼저 한계에 닿는지를 묻는 쪽이 방어 범위를 이해하는 데 도움이 됩니다.
서버 증설로 풀리지 않는 HTTP/2 공격
2023년 10월 Cloudflare는 HTTP/2 Rapid Reset 공격을 공개했어요. 자사에서 관측하고 방어한 공격은 초당 2억 100만 요청을 넘었고, 여기에 사용된 봇넷은 약 2만 대 규모였다고 설명했습니다. 이 수치는 해당 업체가 관측한 사례예요. 내 서버가 버틸 수 있는 기준이나 모든 공격의 평균으로 받아들이면 안 됩니다.
이 공격은 HTTP/2에서 요청을 보낸 뒤 곧바로 취소하는 동작을 반복했어요. 취소되면 다시 요청을 열 수 있는 여지가 생기는데, 서버 쪽 정리가 늦어지면 처리 부담이 쌓이는 구조였어요. 무거운 검색 페이지를 계속 호출하는 방식과는 달리, 통신 규약의 동작 자체를 악용한 사례입니다. 사양표만으로 대응 여부를 판단하기 어려운 이유예요.
이런 사례를 보면 점검 대상도 넓어져요. 애플리케이션 개발자에게만 맡기기보다 HTTP/2 연결을 처리하는 웹 서버나 프록시 담당자에게 해당 취약점 대응 여부를 확인해보세요. 외부 방어 서비스를 쓴다면 그 서비스가 처리하는 구간도 함께 물어보면 좋아요. 서버를 얼마나 키울지 정하기 전에, 요청을 받는 소프트웨어에 알려진 문제는 없는지 확인하는 순서입니다.
자동 확장을 켜두면 비용도 확인해야 해요
자동 확장은 부하에 맞춰 자원을 늘려주는 기능이지만, 공격으로 늘어난 사용량도 비용 문제로 이어질 수 있어요. AWS는 DDoS 때문에 보호 대상 자원이 확장될 때 생기는 요금 증가를 별도로 다루고 있습니다. 서비스가 계속 접속된다는 사실과 청구서가 감당 가능한 수준이라는 사실은 따로 확인해야 하는 셈이에요.
2026년 10월 기준 AWS Shield Advanced 문서에는 공격에 따른 사용량 증가분에 대해 서비스 크레딧을 신청하는 절차가 있어요. 공격 중에 새로 보호 대상으로 추가한 자원은 비용 보호 대상이 아니며, 신청은 공격이 발생한 청구월이 끝난 직후 15일 안에 해야 합니다. 방어 서비스를 가입했다고 모든 추가 요금이 자동으로 없어지는 방식은 아니에요.
자동 확장을 쓰는 독자라면 공격 전에 어떤 자원을 보호 대상으로 등록해야 하는지, 비용 지원에 어떤 조건과 기한이 붙는지 확인해두세요. 이 조건은 AWS의 해당 상품에 관한 것이므로 다른 호스팅 계약에 그대로 적용하면 안 됩니다. 이용 중인 업체에도 공격 트래픽과 확장 자원의 과금 기준을 별도로 물어보면, 증설 결정에 필요한 비용 정보를 확보할 수 있어요.
공격받는 중에 할 일과 하지 말아야 할 일
가장 먼저 호스팅 제공자에 알리는 것입니다. 회선 구간의 상황은 그쪽에서만 볼 수 있고, 차단 조치도 그 단에서 이뤄집니다. 혼자 서버만 붙잡고 있으면 시간만 흘러갑니다.
반대로 서버 IP를 성급히 바꾸는 건 권하지 않습니다. 공격자가 도메인을 보고 있다면 새 IP도 금방 따라옵니다. 그 사이 DNS 전파 때문에 정상 이용자만 접속이 끊기는 일이 생겨요. 앞서 다룬 TTL을 평소 짧게 관리해두면 이럴 때 선택지가 넓어집니다.
그리고 로그를 남겨두세요. 공격이 지나간 뒤 어떤 경로로 무엇이 몰렸는지 분석해야 다음을 대비할 수 있습니다. 급한 마음에 로그를 지우거나 서버를 초기화하면 그 기회를 잃습니다.
TIDC는 국내 데이터센터를 직접 운영하며 DDoS 방어를 기본 제공합니다. 어느 수준까지 대비가 필요한지 서비스 성격에 맞춰 상담해드리니 편하게 문의해주세요.
