디도스 공격 비용을 계산하고 대비하는 방법

얼마 전 작은 쇼핑몰의 장애 기록을 봤는데, 처음엔 디도스 공격 때문에 서버를 올려야 한다는 얘기가 나왔습니다. 그런데 로그를 보니 평소에도 느린 검색 페이지에 요청이 몰리면서 데이터베이스 연결이 먼저 찼습니다. 이럴 때 서버 사양부터 올리면 비용은 늘지만 같은 장애가 다시 날 수 있습니다. 디도스 공격 비용은 ‘공격을 막는 상품 가격’ 하나로 계산하기 어렵습니다. 평소 방어비, 공격 중 늘어난 사용료, 복구에 든 시간을 나눠 봐야 합니다.

먼저 평소 트래픽과 서버 한계를 적는다

월 방문자 수만으로 요금제를 고르면 빗나가기 쉽습니다. 하루 1만 명이 각자 1MB를 받는 사이트라면 하루 전송량은 약 10GB입니다. 하루 전체로 나눈 평균은 약 0.9Mbps지만, 방문이 몰리는 시간에는 이보다 훨씬 높을 수 있습니다. 또 이미지가 캐시에 들어가는 사이트와 매 요청마다 데이터베이스를 조회하는 사이트는 같은 방문자 수라도 서버 부담이 다릅니다.

최소한 평소 초당 요청 수, 바쁜 시간대의 최대치, 서버 응답 시간, 데이터베이스 연결 수, 네트워크 전송량을 기록해 둡니다. 공격이 의심될 때 비교할 기준이 됩니다. 작은 블로그라면 처음부터 고가의 전용 방어 서비스를 계약하기보다 기존 호스팅의 방어 범위와 무료 CDN 기능을 확인하는 편이 현실적입니다. 다만 무료 요금제라는 말만 보고 모든 공격과 운영 지원이 포함된다고 생각하면 곤란합니다.

청구서에 붙는 비용은 어디서 생기나

대량의 요청이 들어왔다고 그 바이트가 전부 전송량 요금으로 청구되는 것은 아닙니다. 제공업체마다 들어오는 트래픽과 나가는 트래픽의 과금 기준이 다릅니다. 실제 청구서에서는 서버가 공격 요청에 응답하며 내보낸 데이터, 로드 밸런서 처리량, 방화벽 요청 수, 자동 증설된 서버의 사용 시간이 문제 되는 경우가 많습니다.

계산할 때는 ‘기본 월요금 + 방어 서비스 요금 + 요청·처리량 증가분 + 증설분 + 복구 작업 비용’으로 나눕니다. 예를 들어 공격으로 추가된 응답이 평균 20KB이고 실제 원본 서버가 500만 건에 응답했다면, 단순 계산으로 약 100GB를 내보낸 셈입니다. 반대로 앞단에서 요청을 차단했다면 원본 서버의 전송량과 부하는 크게 줄 수 있습니다. 어느 지점에서 차단했는지가 비용을 가릅니다.

공식 요금표만 봐도 차이가 큽니다. Cloudflare는 무료 요금제에도 계량하지 않는 디도스 방어를 안내합니다. AWS Shield Standard 역시 추가 요금 없이 기본 보호를 제공합니다. 반면 AWS Shield Advanced는 월 3,000달러의 구독료와 보호 대상의 데이터 전송 관련 요금이 붙습니다. Google Cloud Armor는 표준형에서 정책·규칙·요청 수 등을 기준으로 과금하고, Enterprise는 별도의 기본요금과 처리량 요금이 있습니다. 이 숫자만 놓고 어느 업체가 싸다고 판단하지 말고, 현재 쓰는 서버와 연결할 때 발생하는 전체 요금을 봐야 합니다.

작은 사이트는 방어 설정에 먼저 돈을 쓴다

제가 운영하는 소규모 사이트라면 첫 단계는 원본 서버가 외부에 그대로 드러나는지 확인하는 일입니다. CDN을 켜도 공격자가 원본 IP로 직접 요청할 수 있으면 앞단의 방어 효과가 줄어듭니다. 원본 접속 허용 범위를 확인하고, 관리자 페이지와 로그인 경로에는 별도의 접근 제한을 둡니다. 정상 방문자가 많은 경로까지 무턱대고 막으면 장애를 스스로 만드는 셈이라 규칙 적용 전후의 오류율도 봐야 합니다.

그다음은 캐시와 요청 제한입니다. 이미지와 변하지 않는 파일은 캐시하고, 로그인 시도나 검색처럼 서버 비용이 큰 요청은 경로별로 제한합니다. 제한값을 너무 낮게 잡으면 정상 이용자도 막힙니다. 평소 바쁜 시간대 수치를 기준으로 여유를 두고, 차단 기록을 보며 조정하는 편이 안전합니다. 월 몇 만 원을 더 쓰기 전에 이런 설정부터 바로잡는 게 보통 효과가 큽니다.

백업도 비용 계산에 넣어야 합니다. 공격 자체가 데이터를 지우지 않더라도 장애 대응 중 설정을 잘못 바꾸거나 급히 서버를 옮기면서 문제가 생길 수 있습니다. 데이터베이스와 파일 백업의 주기, 보관 위치, 실제 복원에 걸린 시간을 확인해 둡니다. 복원 시험을 하지 않은 백업은 장애 시간 추정에 쓸 수 없습니다.

공격이 시작되면 비용과 장애를 함께 확인한다

먼저 모니터링에서 요청 수와 응답 코드, CPU, 메모리, 데이터베이스 연결 수를 같은 시간대로 맞춰 봅니다. 5분 사이 요청만 급증했는지, 특정 경로의 응답 시간이 먼저 늘었는지 확인해야 대응이 달라집니다. 502나 504 오류가 늘었다면 원본 서버와 데이터베이스의 포화 여부를 확인합니다. 네트워크가 포화됐다면 서버 안의 차단 규칙만으로는 회선을 살리기 어려우므로 호스팅 업체의 네트워크 방어 범위를 확인해야 합니다.

차단 규칙은 한 번에 넓게 걸기보다 공격이 몰리는 경로와 패턴부터 적용하고 정상 이용자의 오류율을 함께 봅니다. 동시에 과금 알림과 자동 증설 상한을 확인합니다. 무제한 증설은 사이트를 잠시 버티게 할 수 있어도 예상 밖의 청구서를 남길 수 있습니다. AWS의 유료 방어 상품처럼 공격에 따른 일부 사용료 증가분을 크레딧으로 신청할 수 있는 경우도 있지만, 적용 조건과 신청 절차가 있으므로 자동 환급으로 계산해서는 안 됩니다.

디도스 공격 비용을 물으면 저는 먼저 월 방어 상품 가격보다 ‘어디까지 버틸 수 있고, 몇 시간 안에 되돌릴 수 있는가’를 적습니다. 작은 사이트는 무료 보호와 기본 설정만으로 충분한 구간이 꽤 있습니다. 그 구간을 넘어서는 신호가 실제 지표로 보일 때 방어 서비스와 서버 예산을 늘리는 편이 납득 가능한 지출입니다.