웹 트래픽의 관문 — 리버스 프록시와 보안 레이어

요청이 Spring Boot까지 도달하기 전에 거쳐야 하는 계층이 있다. 트래픽을 분산하고, SSL을 끊고, 악성 요청을 거르는 엣지(edge) 계층이다. 애플리케이션이 비즈니스 로직에만 집중할 수 있는 건 이 관문이 앞에서 막아주기 때문이다.

엣지 계층은 두 가지 역할을 한다. 연결과 트래픽을 효율적으로 처리하는 것(리버스 프록시), 그리고 해로운 요청을 걸러내는 것(보안). 전자는 Nginx, 후자는 WAF가 담당한다. 둘은 같은 관문에서 다른 일을 한다.

요청 하나가 애플리케이션에 닿기까지 거치는 계층을 그림으로 보면 이렇다.

  인터넷 (클라이언트)
      │
      ▼
┌─────────────┐
│ CloudFront  │  CDN — 엣지 캐싱, 정적 파일 응답, TLS 종단
│   (CDN)     │
└─────────────┘
      │
      ▼
┌─────────────┐
│    WAF      │  L7 보안 — SQLi/XSS 패턴 차단, Rate limit, Bot 감지
└─────────────┘
      │  (통과한 요청만)
      ▼
┌─────────────┐
│    ALB      │  L4/L7 로드밸런서 — 타깃 분산, 헬스체크, TLS 종단
└─────────────┘
      │
      ▼
┌─────────────┐
│   Nginx     │  리버스 프록시 — SSL 종료, keepalive, upstream 제어
└─────────────┘
      │
      ▼
┌─────────────┐
│   Spring    │  애플리케이션 — 비즈니스 로직, 인증/인가
│   (App)     │
└─────────────┘

각 계층은 자기 책임만 처리하고 통과시킨다. 앞단에서 걸러질수록 뒤로 갈수록 트래픽이 줄어든다.

① 트래픽 처리 — Nginx 리버스 프록시

Nginx는 단순 프록시가 아니다. 이벤트 기반(epoll) 비동기 모델로 적은 워커 프로세스로 수만 연결을 처리한다. SSL을 여기서 끊어 백엔드 부담을 덜고(X-Forwarded-For로 원본 IP 전달), keepalive로 연결을 재사용하고, upstream을 튜닝한다. SSE 같은 스트리밍을 뒤에 둘 때의 버퍼링 함정도 여기서 다뤄야 한다.

→ Nginx 실전 운영 — 단순 리버스 프록시를 넘어

② 보안 필터링 — AWS WAF

L4 방화벽(Security Group)은 IP·포트만 본다. SQL Injection이나 XSS는 정상 포트로 들어오는 정상 형식의 요청이라 L4로는 못 막는다. WAF는 레이어7에서 요청의 내용을 본다. Managed Rule Group으로 알려진 공격 패턴을 거르고, Rate-based Rule로 IP별 요청 폭주를 막고, Bot Control로 봇을 감지한다. CloudFront에 붙이냐 ALB에 붙이냐로 차단 위치가 달라진다.

→ AWS WAF — 단순 방화벽이 아닌 레이어7 보안 레이어

역할이 겹치는 듯 다르다

Nginx도 rate limiting을 하고 WAF도 한다. 겹쳐 보이지만 위치와 목적이 다르다. WAF는 트래픽이 인프라에 닿기 전(CloudFront/ALB 단)에서 광범위한 악성 패턴을 거르고, Nginx의 rate limit은 애플리케이션 바로 앞에서 세밀한 제어를 한다. 계층 방어(defense in depth)로 함께 쓴다. 앞단에서 걸러줄수록 뒤의 Spring Boot에 도달하는 요청이 줄어 안정성이 올라간다.

면접에서 이 그림이 유용한 이유

“요청이 들어오면 애플리케이션 앞에서 무슨 일이 일어나나”를 받으면 엣지 계층으로 답한다. “WAF가 L7에서 악성 요청을 먼저 거르고, Nginx가 SSL 종료·로드밸런싱·연결 관리를 한 뒤 백엔드로 넘긴다. 둘 다 rate limit을 하지만 위치가 달라 계층 방어가 된다.” 여기에 SSL 종료 시 X-Forwarded-For, SSE 버퍼링, WAF 오탐 대응 같은 실전 이슈를 붙이면 운영 경험이 드러난다.