DDoS 방어와 WAF는 무엇이 다릅니까

보안 문진표나 점검 결과지에서 “DDoS 방어”와 “WAF”가 나란히 적혀 있는 것을 보면, 대개 둘 다 채워야 한다는 것은 알겠는데 무엇이 어떻게 다른지는 분명하지 않은 채로 넘어갑니다. 두 항목이 같은 줄에 놓여 있고 같은 자리에서 함께 팔리다 보니, 이름만 다른 비슷한 물건으로 읽히기 쉽습니다.

이 글은 두 장치의 기능을 각각 소개하기보다 둘이 어느 축에서 갈리는가에 무게를 둡니다. 그 축을 먼저 잡아 두면, 하나만 켰을 때 어디가 비는지, 왜 둘을 함께 두는지, 둘 다 두어도 남는 것이 무엇인지가 순서대로 풀립니다.

둘은 같은 것이 아닙니다

DDoS 방어와 WAF는 보는 대상이 다릅니다. DDoS 방어는 트래픽의 양과 형태를 보고, WAF는 요청 하나하나의 내용을 봅니다.

이 한 문장이 나머지 차이를 거의 다 만듭니다. 서비스를 마비시키려는 공격은 대량의 트래픽을 몰아 자원을 고갈시키는 방식이라, 막는 쪽도 개별 요청의 내용을 읽기 전에 양과 흐름을 보고 걸러 냅니다. 반대로 입력값에 공격 문자열을 섞거나 취약점을 노리는 공격은 요청 한 건 안에 흔적이 남는 방식이라, 막는 쪽도 그 한 건의 경로·헤더·본문을 읽어 판단합니다.

그래서 “둘 중 뭐가 더 센가”는 성립하지 않는 질문입니다. 세기가 아니라 맡는 축이 다르기 때문입니다. 한 번의 요청으로 데이터를 빼내려는 시도는 양이 적어 트래픽 기준에 걸리지 않고, 정상적인 모양의 요청이 감당 못 할 만큼 몰리는 상황은 내용 검사만으로는 걸러지지 않습니다.

DDoS 방어는 무엇을 보는가

DDoS(분산 서비스 거부) 공격은 여러 출처에서 트래픽을 한꺼번에 보내 서비스가 정상 요청을 처리하지 못하도록 자원을 소진시키는 공격입니다. 목표는 데이터를 빼내는 것이 아니라 멈추게 하는 것이고, 그래서 개별 요청이 정교할 필요가 없습니다. 양 자체가 무기입니다.

DDoS 방어는 이 양과 형태를 봅니다. 짧은 시간에 비정상적으로 몰리는 흐름, 특정 프로토콜의 반복된 패턴, 정상 사용과 구분되는 트래픽 특성을 근거로 완화합니다. Cloudflare의 DDoS protection 문서는 이 방어가 두 층위에서 동작한다고 설명합니다.

• 네트워크·전송 계층(L3/4) — 요청의 내용을 읽기 전에, 패킷과 연결 수준에서 몰려드는 양을 걸러 내는 층입니다. 웹 요청의 모양과 무관하게 회선과 자원을 고갈시키려는 공격이 여기서 다뤄집니다.
• 애플리케이션 계층(L7) — 정상적인 모양의 웹 요청을 대량으로 보내 서버가 처리에 매달리게 만드는 공격을 다루는 층입니다. 여기서는 요청의 형태와 빈도를 함께 봅니다.

핵심은 DDoS 방어가 요청 하나가 착한지 나쁜지를 판별하려는 장치가 아니라는 점입니다. 각 요청은 평범해도 전체가 몰리면 문제가 되는 상황을 다루기 때문에, 판단의 기준이 개별 내용이 아니라 흐름과 양에 놓입니다.

WAF는 무엇을 보는가

WAF(웹 방화벽)는 반대편에 섭니다. 트래픽의 양이 아니라 요청 한 건의 내용을 읽어, 그 요청이 정상적인 모양인지 판단합니다. 요청의 경로와 질의 문자열, 헤더, 본문에 알려진 공격 패턴이 담겨 있는지를 봅니다. Cloudflare의 WAF 문서가 검사 대상으로 삼는 것이 바로 이 요청의 속성들입니다.

그래서 WAF가 잘 걸러 내는 것은 모양으로 판별되는 공격입니다. 입력값에 SQL 구문이나 스크립트 조각을 섞어 보내는 주입 계열 시도, 공개된 취약점을 노려 정형화된 경로와 파라미터로 들어오는 요청, 존재하지 않는 관리자 경로를 순서대로 두드리는 자동화 스캔 같은 부류입니다. 이런 공격은 요청 하나에 특징이 남기 때문에 내용 검사로 잡힙니다.

WAF는 요청 수를 세어 남용을 다루는 속도 제한 같은 기능도 갖지만, 이때도 판단의 출발점은 여전히 개별 요청입니다. 어떤 클라이언트가 어떤 요청을 얼마나 보내는지를 요청 단위로 세는 것이지, 네트워크 수준에서 흐름을 걸러 내는 것과는 다른 층위의 일입니다. WAF가 정확히 무엇을 걸러 내고 무엇을 걸러 내지 못하는지, 켠 뒤에도 계속 손봐야 하는 것이 무엇인지는 Cloudflare WAF가 막는 것과 막지 못하는 것에서 따로 다룹니다.

왜 다른 계층에서 동작하나

두 장치가 보는 대상이 다른 이유는, 애초에 동작하는 계층이 다르기 때문입니다. 통신은 여러 층으로 나뉘어 이뤄지는데, 아래층일수록 주소와 연결 같은 기반을 다루고 위층일수록 사람이 주고받는 요청의 내용을 다룹니다.

• 네트워크·전송 계층(L3/4) — 데이터가 어디에서 어디로, 어떤 방식으로 오가는지를 다루는 아래층입니다. 요청의 내용이 무엇인지는 아직 보이지 않고, 흐름과 양이 보입니다.
• 애플리케이션 계층(L7) — 실제 웹 요청이 만들어지는 위층입니다. 어떤 주소로 무슨 값을 붙여 들어왔는지, 본문에 무엇이 담겼는지가 이 층에서 드러납니다.

DDoS 방어는 아래층과 위층에 걸쳐 있습니다. 회선과 자원을 겨냥한 양은 아래층에서 걸러 내야 하고, 정상적인 모양의 요청을 대량으로 보내는 공격은 위층에서 흐름을 봐야 하기 때문입니다. 반면 WAF는 요청의 내용을 읽어야 하므로 그 내용이 드러나는 위층에서만 동작합니다. 아래층에서 몰려드는 양은 WAF가 요청을 읽는 단계까지 오기 전의 문제라, 구조적으로 WAF의 관할이 아닙니다.

이 계층 차이가 앞서 본 “보는 대상의 차이”의 밑바탕입니다. 다른 층에 서 있으니 다른 것이 보이고, 다른 것이 보이니 다른 공격을 맡습니다.

한쪽만 켜면 어떻게 되나

이 글에서 무게가 실리는 부분입니다. 두 장치가 다른 축을 맡는다는 말은, 하나를 켜도 다른 쪽 자리는 그대로 빈다는 뜻이기 때문입니다.

• DDoS 방어만 켰을 때 — 서비스를 마비시키려는 대량 트래픽은 걸러지지만, 정상적인 모양으로 들어와 입력값에 공격 문자열을 섞거나 취약점을 노리는 요청은 그대로 통과합니다. 양이 적은 공격은 트래픽 기준으로는 눈에 띄지 않기 때문입니다. 서비스는 멈추지 않는데 데이터가 새는 상황이 이 자리에서 생깁니다.
• WAF만 켰을 때 — 공격 패턴을 담은 요청은 걸러지지만, 정상적인 모양의 요청이 감당 못 할 만큼 몰려드는 상황은 막지 못합니다. WAF는 요청 하나하나를 읽어 판단하는 장치라, 읽어야 할 요청 자체가 자원을 고갈시킬 만큼 쏟아지면 판별의 문제가 아니라 처리량의 문제가 됩니다. 요청은 하나하나 정상이라 걸릴 이유가 없는데 서비스는 멈추는 상황이 이 자리에서 생깁니다.

즉 한쪽만 켜면 그 장치가 잘하는 공격은 잘 막지만, 다른 축의 공격에는 방어가 없는 상태에 가깝습니다. 도입 후 첫 사고에서야 비어 있던 자리가 드러나는 경우가 여기에 해당합니다. “보안 장비를 하나 넣었으니 됐다”가 아니라 “어느 축을 덮었고 어느 축이 비었는가”로 물어야 하는 이유입니다.

왜 같은 엣지에 함께 놓이는가

두 장치가 나란히 팔리고 같은 지점에 놓이는 것은 우연이 아닙니다. 서로 다른 축을 맡기 때문에 한자리에 두어야 서로를 채웁니다.

트래픽이 서비스로 들어오는 경로에는 순서가 있습니다. 바깥에서 온 요청이 먼저 양과 흐름 기준으로 걸러지고(DDoS 방어), 그 관문을 통과한 요청이 내용 검사를 받고(WAF), 남은 것이 원본 서버에 닿습니다. 앞단에서 대량 트래픽을 덜어 내야 뒤의 내용 검사가 정상 요청에 집중할 수 있고, 내용 검사가 있어야 앞단을 통과한 정교한 요청이 걸러집니다. 두 층이 같은 엣지에 함께 놓이는 구조가 이래서 자연스럽습니다.

다만 이 순서는 엣지가 실제로 트래픽을 먼저 받을 때만 성립합니다. 앞단을 우회해 원본 서버로 직접 오는 경로가 열려 있으면, 두 장치를 아무리 잘 구성해도 그 요청은 어느 검사도 받지 않습니다. 여러 서비스를 겹쳐 앞단에 둘 때 순서가 어떻게 어긋나는지는 Cloudflare도 제3자 서비스와 DDoS 완화의 상호작용 문서에서 별도로 다룹니다. AWS 앞단에 Cloudflare를 두는 구성에서 이 경로와 클라이언트 IP가 어떻게 어긋나는지는 AWS와 Cloudflare를 함께 쓸 때 깨지는 자리에서 구체적으로 짚었습니다.

빌드업웍스의 운영 경험에서는, 두 장치를 넣었는지보다 트래픽이 정말 그 앞단을 먼저 거치도록 구성이 닫혀 있는지를 더 무겁게 봅니다. 장치는 있는데 우회 경로가 열려 있으면, 켜 두었다는 사실이 실제로 막고 있다는 뜻이 되지 못합니다.

둘 다 있어도 못 막는 것

두 장치를 함께 두어 트래픽의 양과 요청의 모양을 나눠 맡아도, 그것으로 위험이 사라지지는 않습니다. 두 장치 모두 판단할 근거가 없는 공격이 남기 때문입니다.

형식상 완전히 정상인 요청으로 이뤄지는 공격이 그것입니다. 로그인한 사용자가 주소창의 식별자만 남의 것으로 바꿔 조회하는 경우, 정상 권한을 가진 계정이 정상 절차로 데이터를 가져가는 경우, 각 요청은 유효한데 순서와 조합이 의도를 벗어나는 경우 — 이런 요청은 양으로도 눈에 띄지 않고 모양으로도 정상입니다. 그 요청을 보낼 권한이 있는지, 그 순서가 옳은지는 애플리케이션만 알기 때문에, 트래픽을 보는 장치도 내용을 보는 장치도 여기까지는 판단하지 못합니다. 이 영역이 OWASP Top 10 같은 자료가 상위 위험으로 다루는 자리입니다.

그래서 “둘 다 켰으니 안전하다”로 마무리하면 이 남은 위험을 놓칩니다. 웹 방화벽이 왜 여기까지 막지 못하는지, 그 다음에 무엇을 봐야 하는지는 Cloudflare WAF가 막는 것과 막지 못하는 것에서 자세히 다루므로, 이 글에서는 두 장치가 나눠 맡는 축의 바깥에 이 영역이 따로 있다는 점만 짚어 둡니다.

우리에게 무엇이 필요한가

판단은 장비 목록이 아니라 지금 걱정하는 것이 어느 축인가에서 시작하는 편이 정확합니다. 아래 질문에 답해 보시면 지금 무엇이 비어 있는지 가늠하실 수 있습니다.

• 외부에 공개된 웹 서비스가 있습니까. 있다면 트래픽의 양과 요청의 내용 두 축 모두를 고려 대상에 두어야 합니다.
• 지금 트래픽이 정말 앞단을 먼저 거쳐 들어옵니까. 원본 서버로 직접 오는 경로가 열려 있으면 어느 장치를 켜도 그 경로는 검사를 받지 않습니다.
• 켜 둔 장치가 어느 축을 덮고 있는지 말할 수 있습니까. “보안 장비가 있다”가 아니라 “양을 보는 방어와 내용을 보는 방어 중 무엇이 있는가”로 나눠 확인해야 합니다.
• 두 축을 모두 덮은 뒤에도 남는 위험(권한·인증·로직 결함)을 다룰 계획이 있습니까.

두 축 중 하나만 걱정되고 나머지는 구조적으로 해당하지 않는 상황도 있습니다. 그럴 때는 굳이 둘을 다 갖추기보다 필요한 축부터 확인하시는 편이 순서에 맞습니다. 다만 그 판단을 하려면 지금 무엇이 켜져 있고 무엇이 비어 있는지가 먼저 정리돼야 합니다.

다음 단계

지금 어느 축이 비어 있는지부터 확인하시는 것이 순서상 먼저입니다. 보안 진단에는 네트워크 보안 항목이 포함돼 있어, 이 글에서 나눈 두 축을 자신의 환경에 대입해 무엇이 채워져 있고 무엇이 비었는지 짚어 보실 수 있습니다. 연락처를 남기지 않아도 결과와 우선 과제는 바로 확인하실 수 있습니다.

방어 계층이 실제로 어떻게 나뉘는지 먼저 보고 싶으시면 통합 보안 서비스 범위에서 엣지·네트워크·데이터·탐지 각 층이 무엇을 맡는지 확인해 보십시오. 우리 서비스 기준으로는 어느 축부터 잡는 것이 맞을지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• Cloudflare Docs — DDoS protection 개요
• Cloudflare Docs — WAF 개요
• Cloudflare Docs — Rate limiting rules
• Cloudflare Docs — Third-party services and DDoS
• OWASP Top 10