2026년에 클라우드 WAF에서 트래픽 일부를 옮긴 이유

Source: Dev.to

번역을 진행하려면 실제 텍스트 내용이 필요합니다. 번역하고 싶은 전체 글이나 해당 부분을 제공해 주시면 한국어로 번역해 드리겠습니다.

대부분이 사용하는 기본 아키텍처

만약 오늘날 일반적인 웹 서비스를 운영하고 있다면, 아키텍처는 아마 다음과 같을 것입니다:

Internet
   │
   ▼
Cloud WAF / CDN
   │
   ▼
Origin server
   │
   ▼
Application

장점

• 원본 IP가 숨겨짐
• 대규모 DDoS 방어
• 전 세계 캐싱
• 자동 WAF 규칙

클라우드 WAF는 트래픽이 프록시 네트워크를 단순히 통과하기 때문에 배포가 쉽습니다—대부분 경우 DNS 변경만으로도 됩니다. 공개 웹사이트와 API의 경우, 이 편리함을 능가하기 어렵습니다.

하지만 이 아키텍처 뒤에서 여러 서비스를 운영하면서, 모델이 이상적인 상황이 아닌 엣지 케이스들을 만나기 시작했습니다.

Problem 1 – 모든 서비스가 CDN 뒤에 있어야 하는 것은 아니다

첫 번째 문제는 비전통적인 웹 트래픽을 처리하기 시작하면서 나타났습니다:

• VPN을 통해 노출되는 내부 대시보드
• 개발자 도구
• 웹훅 엔드포인트
• 대용량 파일 업로드
• 내부 API

이러한 워크로드는 공개 웹사이트와 동작 방식이 다릅니다. 일반적으로 다음과 같은 요소를 포함합니다:

• 인증된 클라이언트
• 대용량 요청 본문
• 장시간 유지되는 연결
• 비정형 헤더 또는 프로토콜

CDN에 최적화된 WAF는 어색하게 맞을 수 있습니다. 예를 들어, 많은 WAF 엔진은 요청 본문을 일정 크기까지만 검사합니다(플랜에 따라 다름). 이는 일반 웹 트래픽에는 문제가 없지만, 애플리케이션이 대용량 페이로드를 자주 처리한다면 보안 레이어가 부분적인 검사만 하거나 일부 검사를 우회하는 상황을 마주할 수 있습니다.

Problem 2 – The “Black Box” Problem

클라우드 보안 플랫폼은 강력하지만 추상화되어 있습니다. 보통 다음과 같은 것들을 제공합니다:

• 대시보드
• 규칙 토글
• 집계된 로그

하지만 원시 요청 동작을 자세히 보는 경우는 거의 없습니다. 공격 트래픽을 디버깅할 때 저는 다음과 같은 질문에 대한 답이 필요했습니다:

• 어떤 정확한 페이로드가 규칙을 트리거했나요?
• 요청 본문은 어떻게 생겼나요?
• 어떤 스캐너가 이를 생성했나요?
• 요청이 차단되기 전에 무슨 일이 일어났나요?

클라우드 대시보드는 일반적으로 결정 결과만 보여주고 전체 컨텍스트는 제공하지 않습니다. 이러한 추상화는 의도된 것으로, 단순함을 유지하기 위함이지만 때때로 더 많은 제어가 필요합니다.

Problem 3 – 모든 것을 하나의 네트워크를 통해 라우팅하는 비용

모든 트래픽이 클라우드 WAF를 통과하면 다음 구성 요소들이 긴밀하게 결합됩니다:

• DNS
• 트래픽 라우팅
• 보안
• 캐싱
• (때때로) 로드 밸런싱

대부분의 경우 이는 괜찮지만, 때때로 다음과 같은 유연성이 필요합니다:

• 서비스를 일시적으로 노출
• 특정 트래픽을 직접 라우팅
• 프라이빗 엔드포인트 운영
• 프록시 레이어 없이 인프라 테스트

단일 엣지 네트워크가 이러한 모든 요소를 소유하면 이러한 실험이 더 어려워집니다.

최종적으로 선택한 하이브리드 접근 방식

클라우드 WAF를 완전히 제거하는 대신, 나는 분할 아키텍처를 사용하게 되었다:

Internet ─────► Cloud WAF / CDN ─────► Public Web Apps
                     │
                     ▼
               Internal Gateway
                     │
                     ▼
               Self‑Hosted WAF Layer
                     │
                     ▼
                    Services

공용 트래픽은 여전히 엣지 네트워크를 사용하지만, 일부 서비스는 이를 우회하여 로컬 보안 계층을 통과한다. 이 접근 방식은 클라우드 엣지의 이점—전 세계적인 성능, 대규모 DDoS 방어, 손쉬운 캐싱—을 유지하면서 특수 서비스에 대한 제어를 더 많이 제공한다.

자체 호스팅 WAF가 여전히 빛나는 이유

다시 로컬 필터링 레이어를 실험하기 시작했을 때, 클라우드 WAF가 등장하기 전 왜 그것들이 인기가 있었는지 떠올랐습니다. 자체 호스팅 WAF는 인프라에 직접 배치됩니다:

Internet
   │
   ▼
Reverse Proxy + WAF
   │
   ▼
Application

이 배치는 클라우드 플랫폼에서는 항상 제공되지 않을 수 있는 몇 가지 장점을 제공합니다:

전체 요청 가시성

• 원시 페이로드
• 헤더
• 요청 본문
• 전체 트래픽 로그

이를 통해 공격을 디버깅하는 것이 훨씬 쉬워집니다.

세밀한 제어

환경 내에서 실행되기 때문에 다음과 같은 규칙을 구현할 수 있습니다:

• 엔드포인트별 정책
• 서비스별 속도 제한
• 내부 로직에 기반한 행동 규칙

클라우드 WAF도 사용자 정의 규칙을 지원하지만 보통 플랫폼 제약 내에서 동작합니다. 자체 레이어를 운영하면 이러한 제한을 없앨 수 있습니다.

로컬 트래픽 필터링

많은 공격이 애플리케이션에 도달하기도 전에 차단됩니다. 흔히 사용되는 탐색 예시는 다음과 같습니다:

GET /.env
GET /.git/config
GET /wp-login.php
GET /phpmyadmin

로컬 WAF는 이러한 요청을 즉시 차단하여 상위 서비스에 부담을 주지 않습니다.

제가 자체 호스팅 WAF에서 찾는 것

• 봇 챌린지
• 요청 필터링
• 속도 제한
• 좋은 트래픽 가시성

기업 수준의 보안 장비가 반드시 필요한 것은 아니며, 서비스 앞에 배치되어 잡음을 줄여줄 무언가만 있으면 됩니다.

최근 저는 SafeLine WAF를 실험하고 있습니다. 이 제품은 이러한 기능들을 비교적 쉽게 실행할 수 있는 자체 호스팅 시스템으로 패키징했습니다. 흥미로운 점은 클라우드 WAF를 대체한다는 것이 아니라, 위에서 설명한 하이브리드 모델에 잘 맞아, CDN을 거치지 않아도 되는 트래픽에 대한 보안 계층으로 작동한다는 것입니다.

궁금하시다면 그들의 웹사이트를 확인해 보세요.

Safepoint Cloudline이 여기 있습니다:

클라우드 WAF를 반드시 유지해야 할 때

분명히 말하자면, 클라우드 WAF는 여전히 많은 상황에서 최선의 선택입니다.

귀하의 애플리케이션이 다음과 같은 경우:

• 공개 웹사이트
• 글로벌 SaaS 제품
• 높은 캐시 가능성
• 전 세계적으로 지연에 민감

그렇다면 엣지 네트워크의 장점은 막대합니다. Cloudflare와 같은 제공업체의 글로벌 규모는 로컬에서 복제할 수 없습니다.

최종 생각

운영 서비스를 운영하면서 얻은 가장 큰 교훈은 보안 아키텍처는 거의 정적이지 않다는 것입니다. 작은 웹 앱에 적용되는 것이 다음과 같은 경우에는 적용되지 않을 수 있습니다:

• 내부 도구
• API
• 대용량 업로드
• 특수 인프라

클라우드 WAF는 개발자에게 많은 문제를 해결해 주었지만, 동시에 새로운 패턴을 도입했습니다: 모든 것이 엣지 네트워크를 통해 흐른다.

• 때로는 그것이 완벽합니다.
• 때로는 그렇지 않습니다.

저에게는 해결책이 어느 한 모델을 선택하는 것이 아니라, 상황에 맞게 두 가지를 모두 사용하는 것이었습니다.