Skip to content

필사 모드: 리버스 프록시 & 엣지 서버 2026 완벽 가이드 - nginx · Caddy · Traefik · HAProxy · Envoy · OpenResty · Pingora · FrankenPHP 심층 분석

한국어
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.
원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 왜 리버스 프록시가 인프라의 심장인가

2026년 신입 백엔드 엔지니어가 처음 마주치는 질문: "그냥 Node.js 서버를 3000 포트에 띄우고 끝 아닌가요? 왜 앞에 nginx를 또 띄워야 하죠?"

3개월 뒤 현실: TLS 인증서가 만료됐는데 코드를 재배포해야 하고, 트래픽이 3배 늘었더니 Node 한 대로는 못 버티고, 어떤 IP가 1초에 1만 번 요청을 날려도 막을 방법이 없고, 정적 파일을 Node가 직접 서빙하느라 CPU가 80%고, 새 마이크로서비스를 추가할 때마다 DNS 레코드를 새로 파야 한다.

이 모든 문제의 답이 **리버스 프록시(reverse proxy)**다. 클라이언트와 애플리케이션 서버 사이에 끼어들어 TLS 종료, 로드 밸런싱, 캐싱, 인증, 레이트 리미팅, 관측성을 모두 처리하는 **인프라의 심장**이다.

이 글은 2026년 5월 기준 리버스 프록시와 엣지 서버 풀스택을 해부한다. **nginx 1.27**(F5)과 **freenginx** 포크 드라마, **Caddy 2.8**의 자동 HTTPS, **Traefik 3**의 동적 라우팅, **HAProxy 3.x**의 L4/L7 로드 밸런서, **Envoy 1.32** 서비스 메시 데이터 플레인, **OpenResty** Lua, **Cloudflare Pingora**의 Rust 리라이트, **FrankenPHP**, **K8s Ingress**와 **Gateway API**, **Cloudflare Workers**·**Fastly Compute@Edge**·**Vercel Edge**·**Netlify Edge**·**Lambda@Edge**·**CloudFront Functions** 같은 엣지 런타임까지.

1장 · 리버스 프록시란 무엇인가 — 5가지 핵심 역할

**리버스 프록시는 클라이언트가 직접 백엔드에 닿지 않게 하는 중간 계층**이다. forward proxy(클라이언트 측)와 반대 방향이라 "리버스"다.

핵심 역할 다섯 가지.

- **로드 밸런싱(load balancing).** 같은 앱의 인스턴스 N개에 트래픽을 분산. round-robin, least-conn, IP hash, consistent hash 알고리즘.

- **TLS 종료(TLS termination).** HTTPS를 프록시가 풀고 내부는 HTTP로 통신. 인증서 관리가 한곳으로 모인다.

- **캐싱(caching).** 정적 파일과 HTTP 응답을 메모리·디스크에 저장. 백엔드 부하를 90% 줄일 수 있다.

- **인증·인가(auth).** OAuth, JWT 검증, mTLS, IP 화이트리스트. 앱이 매번 검증할 필요가 없다.

- **레이트 리미팅·WAF(rate limit · WAF).** "1초에 100번 이상은 거부", "SQL injection 패턴 탐지". 보안 1차 방어선.

여기에 더해 **관측성(observability)** — 모든 요청을 로깅하고 Prometheus 메트릭으로 노출 — 이 필수가 됐다. 2026년 기준 리버스 프록시는 단순한 라우터가 아니라 **L7 보안 게이트웨이 + 관측성 허브**다.

2장 · 시장 지도 — 8개 진영

2026년 리버스 프록시·엣지 시장을 큰 그림으로 정리하면 여덟 진영이다.

**1. nginx 진영.** nginx 1.27 (F5 Networks), nginx Plus, freenginx (Maxim Dounin 포크), OpenResty (nginx + Lua). 시장 1위, 가장 오래된 베테랑.

**2. Caddy 진영.** Caddy 2.8+ (Matt Holt). 자동 HTTPS, Go로 작성. FrankenPHP (Kévin Dunglas) 가 Caddy 위에 PHP 런타임 통합.

**3. Traefik 진영.** Traefik 3.x (TraefikLabs). Docker · K8s 네이티브, 동적 config, 플러그인.

**4. HAProxy 진영.** HAProxy 3.x (Willy Tarreau). L4/L7 로드 밸런서, 가장 빠른 TCP 처리.

**5. Envoy 진영.** Envoy Proxy 1.32 (CNCF, Lyft 출신). Istio · Linkerd2 · Consul Connect 데이터 플레인. Envoy Gateway · Contour 가 K8s 게이트웨이.

**6. Rust 신생.** Cloudflare Pingora (2024년 오픈소스), Sozu, Hyper (라이브러리). 메모리 안전성과 성능.

**7. 엣지 서버리스.** Cloudflare Workers · Fastly Compute@Edge · Vercel Edge · Netlify Edge Functions · Lambda@Edge · CloudFront Functions · Akamai EdgeWorkers.

**8. K8s 인그레스.** NGINX Ingress, Traefik Ingress, Contour, Istio Gateway, Kong Ingress, HAProxy Ingress, Cilium Gateway API, Gateway API 표준.

여기에 **CDN 통합 LB** (Cloudflare Load Balancer, AWS CloudFront, Akamai, Fastly, Azure Front Door, Google Cloud CDN) 가 별도 계층으로 존재한다.

진영을 외워두면 의사결정이 빨라진다. **전통 정적 사이트는 nginx, 자동 TLS 작은 팀은 Caddy, K8s 네이티브는 Traefik · Envoy, 초고성능 L4는 HAProxy, 글로벌 엣지는 Cloudflare Workers** 가 기본 매핑이다.

3장 · nginx 1.27 — 시장의 베테랑, F5 인수 이후

nginx는 2004년 Igor Sysoev 가 만든 1세대 리버스 프록시다.

**역사 요약.**

- **2004**: Igor Sysoev 가 Rambler를 위해 nginx 0.1 출시.

- **2011**: Nginx, Inc. 설립. Plus(유료) 출시.

- **2019**: F5 Networks 가 6.7억 달러에 인수.

- **2024**: Maxim Dounin (오래된 핵심 개발자)이 F5 의 보안 패치 정책에 반발해 **freenginx** 포크. 커뮤니티 분열.

- **2025~2026**: nginx 1.27 메인라인 + freenginx 1.27 병행 개발.

**핵심 강점.**

- **압도적인 시장 점유율** — 2026년 기준 전 세계 웹사이트의 약 30%가 nginx 사용 (Apache 추월).

- **모듈형 아키텍처** — 비동기 이벤트 루프, 워커 프로세스 N개.

- **풍부한 모듈** — HTTP, mail, stream(TCP/UDP), gRPC, HTTP/3 QUIC (1.25+).

- **거대한 문서·튜토리얼 생태계** — 검색해서 안 나오는 게 없다.

**설정 예시.**

upstream backend {

least_conn;

server app1.internal:3000 weight=3;

server app2.internal:3000 weight=2;

server app3.internal:3000 backup;

}

server {

listen 443 ssl http2;

listen 443 quic reuseport;

server_name example.com;

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

location / {

proxy_pass http://backend;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_http_version 1.1;

}

location /static/ {

alias /var/www/static/;

expires 1y;

}

}

**약점.** 동적 설정이 약하다 — config 파일을 고치고 `nginx -s reload` 를 쳐야 한다. Plus(유료)만 진짜 동적 API 가 있다. 또 모듈 컴파일은 빌드 시점에 결정 — 동적 모듈(.so) 이 있긴 하지만 제한적이다.

4장 · freenginx — Maxim Dounin 의 커뮤니티 포크

2024년 2월, nginx 의 오래된 핵심 개발자 **Maxim Dounin** 이 F5 의 의사결정(보안 취약점 패치 정책)에 반발해 **freenginx** 라는 포크를 시작했다.

**핵심 주장.** "F5 가 CVE 발급 없이 조용히 패치하는 정책으로 갔는데, 이는 보안 투명성에 반한다. 진정한 오픈소스로 가야 한다."

**현황 (2026년 5월).**

- freenginx 1.27 메인라인 운영 중.

- 커뮤니티 패치 수십 개 머지.

- 일부 사용자(특히 보안 민감 환경)는 freenginx 로 이전.

- 다만 시장 점유율은 nginx 메인라인이 압도적 — freenginx 는 1~2% 수준.

**선택 가이드.**

- 기존 nginx 사용자 → 큰 차이 없으니 nginx 메인라인 유지.

- 보안 투명성에 민감하거나 F5 거버넌스가 싫으면 → freenginx.

- 엔터프라이즈 지원 필요 → nginx Plus (F5).

포크는 "오픈소스 거버넌스가 어떻게 깨질 수 있는지" 보여주는 사례 연구다. Redis-Valkey, Terraform-OpenTofu, Elasticsearch-OpenSearch 와 같은 패턴이다.

5장 · Caddy 2.8 — 자동 HTTPS의 혁명

**Caddy** 는 2015년 Matt Holt 가 시작한 Go 기반 웹 서버다. 2026년 5월 기준 2.8.x.

**1.x 시절 (2015~2018).** "config 파일 한 줄이면 자동 HTTPS" 가 셀링 포인트. 단일 바이너리 배포.

**2.x (2019~2026).** 완전 재작성. 모듈러 아키텍처, JSON 기반 config, 플러그인 시스템, REST API.

**핵심 강점.**

- **자동 HTTPS** — Let's Encrypt 와 ZeroSSL 을 자동 통합. 도메인만 적으면 인증서가 알아서 발급·갱신.

- **단일 바이너리** — Go 로 작성, 의존성 없는 정적 바이너리.

- **모듈러** — DNS provider, storage backend, 미들웨어를 플러그인으로.

- **REST API** — 런타임에 설정 동적 변경.

- **HTTP/3 기본 지원** — QUIC 가 별도 설정 없이 켜진다.

**Caddyfile 예시.**

example.com {

reverse_proxy app1.internal:3000 app2.internal:3000 {

lb_policy least_conn

health_uri /health

health_interval 10s

}

handle_path /static/* {

root * /var/www/static

file_server

}

encode gzip zstd

log {

output file /var/log/caddy/access.log

}

}

이 한 블록만으로 Let's Encrypt 인증서, HTTP/3, 로드 밸런싱, 헬스체크, 압축, 로깅이 모두 켜진다. nginx 였다면 50줄 이상.

**약점.** 성능은 nginx 와 HAProxy 보다 약간 떨어진다 (~10~20%). Go GC 오버헤드가 있고, 엣지 케이스에서 nginx 만큼 안정적이지 않다는 평. 그래도 **개발 속도와 운영 편의성이 압도적** 이라 작은 팀이 선호.

6장 · Traefik 3 — Docker · K8s 네이티브

**Traefik** 은 2015년 Containous(현 TraefikLabs) 가 만든 Go 기반 프록시다. 2026년 5월 기준 v3.x.

**핵심 컨셉.** "**자동 설정(automatic configuration)**". Docker 컨테이너에 라벨을 붙이거나, K8s Ingress · CRD 를 만들면, Traefik 이 알아서 라우팅을 추가한다. config 파일을 직접 쓸 일이 거의 없다.

**v3 신규 (2024).**

- 플러그인 시스템 안정화 (Yaegi Go 인터프리터).

- HTTP/3 정식 지원.

- Gateway API 표준 지원 (K8s Ingress 후계).

- gRPC, TCP/UDP 라우팅 강화.

- OpenTelemetry 트레이스 통합.

**Docker 라벨 예시.**

services:

app:

image: myapp:latest

labels:

- "traefik.enable=true"

- "traefik.http.routers.app.rule=Host(`example.com`)"

- "traefik.http.routers.app.tls=true"

- "traefik.http.routers.app.tls.certresolver=letsencrypt"

- "traefik.http.services.app.loadbalancer.server.port=3000"

이 라벨만 붙이면 Traefik 이 자동으로 라우팅과 인증서 발급을 처리한다. **K8s 에서는 IngressRoute CRD** 가 같은 역할을 한다.

**강점.** Docker · K8s 환경에서 압도적인 편의성, 실시간 대시보드, 자동 ACME, Let's Encrypt 와 DNS challenge 지원.

**약점.** 순수 성능은 nginx · HAProxy 보다 떨어진다. 메모리 사용량이 높은 편. 컨테이너 없는 전통 환경에서는 매력이 줄어든다.

7장 · HAProxy 3.x — 가장 빠른 L4/L7 로드 밸런서

**HAProxy** 는 2001년 Willy Tarreau 가 만든 C 기반 로드 밸런서다. 2026년 5월 기준 3.x.

**철학.** "**한 가지만 정말 잘하자**" — 로드 밸런싱. HTTP 서버가 아니라 순수 프록시. 정적 파일 서빙 안 함, PHP 안 돌림, TLS 종료만 함.

**핵심 강점.**

- **L4 (TCP) 가 압도적으로 빠름** — 단일 노드로 초당 100만 연결 처리.

- **L7 (HTTP) 도 nginx 와 비슷** — 헤더 기반 라우팅, ACL, sticky session.

- **observability 가 1급 시민** — Stats 페이지, Prometheus exporter 내장.

- **HTTP/2, HTTP/3, gRPC 지원** (2.6+, 3.x).

- **풍부한 LB 알고리즘** — roundrobin, leastconn, source, uri, url_param, hdr, random, first.

**설정 예시.**

frontend https

bind *:443 ssl crt /etc/haproxy/certs/example.pem alpn h2,http/1.1

bind quic4@:443 ssl crt /etc/haproxy/certs/example.pem alpn h3

default_backend app_pool

backend app_pool

balance leastconn

option httpchk GET /health

server app1 10.0.1.10:3000 check inter 2s

server app2 10.0.1.11:3000 check inter 2s

server app3 10.0.1.12:3000 check inter 2s backup

**약점.** 정적 파일 서빙, 다이렉트 PHP/FastCGI 같은 풀스택 웹 서버 기능은 없음 — 진짜 LB 가 필요한 곳에 nginx 와 결합해서 쓰는 패턴이 흔하다 (HAProxy 가 앞에, nginx 가 뒤에).

**누가 쓰는가.** GitHub, Stack Overflow, Reddit, Twitter (X), Tumblr — 트래픽 많은 사이트 다수.

8장 · Envoy Proxy 1.32 — 서비스 메시의 데이터 플레인

**Envoy** 는 2016년 Lyft 가 만들고 2017년 CNCF 에 기증한 C++ 기반 프록시다. 2026년 5월 기준 1.32.

**철학.** "**서비스 메시(service mesh)의 데이터 플레인이 되자**". 단순 LB 가 아니라 **마이크로서비스 간 통신의 모든 측면**을 다루도록 설계됐다.

**핵심 기능.**

- **xDS API** — 동적 설정 (LDS · CDS · RDS · EDS). control plane 이 push 하면 Envoy 가 즉시 반영.

- **gRPC 1급 시민** — gRPC 로드 밸런싱, transcoding (REST↔gRPC).

- **observability** — 상세한 메트릭, 분산 트레이싱 (Jaeger, Zipkin, OpenTelemetry).

- **회로 차단기(circuit breaker), retry, outlier detection** — 마이크로서비스 안정성 패턴이 빌트인.

- **HTTP/3, mTLS, gRPC-Web, WebSocket 모두 지원**.

**누가 Envoy 를 쓰는가.**

- **Istio** — K8s 서비스 메시. 모든 Pod 에 Envoy sidecar.

- **Linkerd 2** — 자체 Rust proxy(linkerd2-proxy) 도 쓰지만 일부 컴포넌트는 Envoy.

- **Consul Connect** — HashiCorp 서비스 메시.

- **Envoy Gateway** — K8s Gateway API 구현체.

- **Contour** — VMware Tanzu (현 Broadcom) K8s 인그레스.

- **AWS App Mesh** — Envoy 기반.

**약점.** 설정이 복잡하다. YAML 또는 JSON 으로 직접 쓰면 수백 줄이 기본. 그래서 보통 Istio · Envoy Gateway 같은 **컨트롤 플레인** 을 통해 다룬다.

9장 · OpenResty — nginx 위의 Lua 풀스택

**OpenResty** 는 Yichun Zhang(章亦春) 이 2011년부터 만든 nginx 배포판이다.

**핵심.** nginx 에 LuaJIT 을 임베드해서 **각 요청에서 Lua 코드를 실행**할 수 있게 했다. nginx 의 비동기 이벤트 루프 위에서 Lua coroutine 으로 비동기 로직을 자연스럽게 쓴다.

**사용 예시.**

location /api/auth {

access_by_lua_block {

local jwt = require "resty.jwt"

local token = ngx.var.http_authorization

local jwt_obj = jwt:verify("secret-key", token)

if not jwt_obj.verified then

ngx.status = 401

ngx.say("Unauthorized")

return ngx.exit(401)

end

ngx.req.set_header("X-User-Id", jwt_obj.payload.user_id)

}

proxy_pass http://backend;

}

**OpenResty 위에 만들어진 유명 프로젝트.**

- **Kong API Gateway** — OpenResty 기반 (현재 일부는 Go 로 재작성 중).

- **APISIX** (Apache) — OpenResty 기반 API 게이트웨이.

- **3scale** (Red Hat).

- **Cloudflare 의 일부 엣지 로직** — 2024년 Pingora 로 옮기기 전까지.

**강점.** nginx 의 성능 + Lua 의 동적 로직. 인증, 변환, 라우팅, A/B 테스트 같은 미들웨어를 빠르게 만들 수 있다.

**약점.** Lua 학습 곡선. 디버깅이 어렵다. 모놀리식 nginx 빌드라 모듈 추가가 번거롭다.

10장 · Cloudflare Pingora — Rust 리라이트의 야망

**Pingora** 는 Cloudflare 가 자체 엣지를 위해 만든 Rust 기반 프록시 프레임워크다. **2024년 2월 오픈소스화** 되면서 큰 주목을 받았다.

**왜 만들었는가.** Cloudflare 는 원래 nginx 를 엣지로 썼다. 하지만:

- 멀티프로세스 모델 — 연결이 워커 간 공유 안 됨.

- 메모리 안전성 — C 라서 보안 취약점이 계속 나옴.

- 커스텀 로직 추가 어려움 — Lua 와 C 모듈로 우회.

Cloudflare 는 **Rust 로 처음부터 다시 쓰는 게 낫다** 고 결정했고, 그 결과가 Pingora 다.

**스펙 (2026년 5월).**

- **언어**: Rust (안전성 + 성능).

- **모델**: 멀티스레드 워크 스틸링 (Tokio).

- **트래픽**: Cloudflare 가 **하루 1조 요청 이상** 을 Pingora 로 처리.

- **CPU/메모리**: nginx 대비 70% CPU, 67% 메모리.

- **HTTP/3, gRPC, WebSocket** 지원.

**오픈소스 = 프레임워크.** Pingora 는 라이브러리(crates) 로 제공된다. nginx 처럼 "설정 파일 쓰고 실행" 이 아니라 Rust 코드로 **자신만의 프록시를 만들어야 한다**.

**누가 쓰는가 (2026년).**

- Cloudflare 자체.

- Pingora 기반 OSS 프로젝트들: River (개발 중), pingora-load-balancing 예제.

- 일부 큰 회사가 자체 엣지에 도입 시도 중.

**약점.** "그대로 떨어뜨리면 되는" 솔루션이 아니라 Rust 엔지니어가 필요하다. 학습 곡선이 가팔라서 작은 팀에는 부적합.

11장 · FrankenPHP — Caddy 안에 PHP 런타임

**FrankenPHP** 는 Kévin Dunglas (Symfony 핵심 기여자, API Platform 창업자) 가 2022년 시작한 프로젝트다. 2026년 5월 기준 1.x 안정 버전.

**핵심 아이디어.** PHP-FPM 을 없애고, **PHP 인터프리터를 Caddy(Go) 안에 임베드**한다. PHP 가 long-running 프로세스 안에서 돈다.

**기존 PHP-FPM 의 문제.**

- 매 요청마다 PHP 프로세스가 새로 시작 (Opcache 가 도와도 한계).

- nginx → FastCGI → PHP-FPM → 다시 nginx 의 hop 이 많음.

- 워커풀 튜닝이 어렵다.

**FrankenPHP 의 해결.**

- PHP 가 Caddy 프로세스 안에서 long-running.

- HTTP/2, HTTP/3, WebSocket 자동.

- **Worker mode** — Laravel · Symfony · Drupal 을 octane 처럼 long-running 으로 돌림.

- **Early hints** (HTTP 103) 지원.

- 정적 바이너리 — 하나의 파일에 PHP 와 웹서버.

**벤치마크.** Symfony 데모 앱에서 PHP-FPM 대비 **3.5배 RPS**, 응답 지연 75% 감소.

**도입 사례.**

- API Platform 공식 통합.

- Laravel Octane 에서 워커 옵션으로.

- Symfony 공식 권장 옵션 중 하나.

PHP 가 2025~2026년에 다시 주목받은 이유 중 하나가 FrankenPHP 다. PHP 가 "느린 언어" 라는 인식을 바꿨다.

12장 · Sozu · 기타 Rust 프록시들

Rust 가 시스템 프로그래밍의 차세대 표준이 되면서, 리버스 프록시도 여럿 등장했다.

**Sozu** — CleverCloud 가 만든 HTTP 리버스 프록시. 핫 리로드(hot reload) 가 핵심 — 설정 변경에 다운타임 0. AGPL 라이선스로 일부 논란.

**Hyper** — Rust 의 가장 유명한 HTTP 라이브러리. 프록시 자체는 아니지만, 많은 Rust 프록시의 기반.

**Linkerd2-proxy** — Linkerd 2 가 자체 사이드카로 쓰는 Rust 프록시. 작고 빠르다.

**River** — Pingora 위에 만들어지는 OSS 프록시 (개발 중).

**그 외.** Tonic (gRPC), Tower (미들웨어 추상화), Hudsucker (MITM 프록시).

**Bun 의 내장 서버** — Node 진영이지만 언급할 가치가 있다. Bun.serve() 가 fetch API 기반 HTTP 서버를 제공하는데 Express/Node http 보다 5~10배 빠르다. 작은 마이크로서비스 앞에 nginx 없이도 직접 노출 가능한 수준의 성능이다.

13장 · K8s Ingress 컨트롤러 — 7가지 옵션

쿠버네티스에서 외부 트래픽을 받으려면 **Ingress 컨트롤러** 가 필요하다. 2026년 옵션이 다양하다.

**1. NGINX Ingress Controller** — K8s 공식 컨트롤러 중 하나. nginx 기반. 가장 많이 쓰임. ConfigMap + annotation 으로 설정.

**2. NGINX Ingress (F5 상용)** — 위와 다른 컨트롤러. nginx Plus 기반, 동적 설정. F5 가 공식 운영.

**3. Traefik Ingress** — Traefik 을 컨트롤러로. IngressRoute CRD 가 매력.

**4. Contour** — Envoy 기반, VMware (Broadcom). HTTPProxy CRD.

**5. Istio Gateway** — Envoy 기반, Istio 컨트롤 플레인. 서비스 메시까지 갖춰진다면 자연스러운 선택.

**6. Kong Ingress** — Kong API 게이트웨이를 컨트롤러로. OpenResty 기반.

**7. HAProxy Ingress** — HAProxy 를 컨트롤러로. L4 가 강하다.

**8. Cilium Gateway API** — eBPF 기반 데이터 플레인. Cilium 을 CNI 로 쓴다면 매력.

선택 기준:

- 단순한 시작 → NGINX Ingress (CNCF 졸업, 가장 많은 자료).

- 서비스 메시 통합 → Istio Gateway.

- 동적 설정·플러그인 → Traefik.

- API 게이트웨이 기능 → Kong.

14장 · Gateway API — Ingress 의 후계자

**Ingress** 는 2015년 K8s 1.1 에 도입된 첫 L7 라우팅 API 다. 10년이 지나면서 한계가 드러났다.

**Ingress 의 문제.**

- 너무 단순 — 호스트와 경로만, 헤더·메서드 라우팅 안 됨.

- 컨트롤러마다 annotation 이 다 다름 — nginx, traefik, contour, kong 모두 자기 방언.

- TCP/UDP 라우팅 부재.

- 권한 분리 안 됨 — 인프라팀과 앱팀 역할 구분 불가.

**Gateway API** (SIG Network) 는 이 모든 문제의 답이다. 2023년 GA, 2026년 5월 기준 v1.2.

**핵심 리소스.**

- **GatewayClass** — 어떤 구현체를 쓸지 (인프라팀 소관).

- **Gateway** — 실제 LB · 진입점 (인프라팀이 만듦).

- **HTTPRoute, TCPRoute, UDPRoute, TLSRoute, GRPCRoute** — 라우팅 규칙 (앱팀이 만듦).

- **ReferenceGrant** — 네임스페이스 간 참조 권한.

**HTTPRoute 예시.**

apiVersion: gateway.networking.k8s.io/v1

kind: HTTPRoute

metadata:

name: app-route

spec:

parentRefs:

- name: my-gateway

hostnames:

- "example.com"

rules:

- matches:

- path:

type: PathPrefix

value: /api/v1

headers:

- name: X-API-Version

value: "1"

backendRefs:

- name: app-v1

port: 80

weight: 80

- name: app-v1-canary

port: 80

weight: 20

**구현체 (2026년).** Istio, Envoy Gateway, Contour, Kong, Traefik, NGINX Gateway Fabric, Cilium Gateway API. **Ingress 는 deprecated 는 아니지만 신규는 Gateway API 로 가는 게 맞다**.

15장 · TLS · mTLS · ACME — 인증서의 생태계

**HTTPS 가 표준** 인 시대(2018년 Chrome 의 "Not Secure" 캠페인 이후) 가 되면서, 리버스 프록시의 가장 큰 책임이 TLS 인증서 관리다.

**ACME 프로토콜.** Let's Encrypt 가 만든 자동 인증서 발급 표준. HTTP-01 · DNS-01 · TLS-ALPN-01 challenge.

**무료 CA (2026년).**

- **Let's Encrypt** — 가장 많이 쓰이는 무료 CA. 한 달에 60일 인증서.

- **ZeroSSL** — 90일 또는 1년 (계정 가입). Caddy 가 기본으로 Let's Encrypt 와 ZeroSSL 둘 다 시도.

- **Google Trust Services** — 2024년부터 ACME 무료 발급.

**인증서 자동화 도구.**

- **Certbot** — Let's Encrypt 공식 클라이언트. systemd timer 로 갱신.

- **acme.sh** — bash 로 작성된 ACME 클라이언트. 가장 가볍다.

- **cert-manager** — K8s 에서 Issuer · Certificate CRD 로 자동화. 사실상 표준.

- **lego** — Go 로 작성, Traefik 내장.

**프록시별 ACME 통합.**

- Caddy — 빌트인, 추가 도구 불필요.

- Traefik — 빌트인.

- nginx — Certbot · acme.sh 외부 사용.

- HAProxy — Certbot · acme.sh 외부 사용.

- Envoy — cert-manager 또는 외부.

**mTLS (상호 TLS).** 클라이언트도 인증서로 인증. 서비스 메시(Istio, Linkerd)의 zero-trust 보안 모델 핵심.

**프라이빗 CA.**

- **step-ca** (smallstep) — 사내 CA. ACME 서버로 동작.

- **mkcert** (Filippo Valsorda) — 로컬 개발용 자체 서명 CA.

- **HashiCorp Vault PKI** — 엔터프라이즈 CA.

16장 · HTTP/3 · QUIC — UDP 위의 새로운 표준

**HTTP/3** 는 2022년 RFC 9114 로 표준화됐고, 2026년 5월 기준 글로벌 트래픽의 약 30%가 HTTP/3 다.

**핵심 차이.**

- **전송 계층 = QUIC (UDP 위에)** — TCP 아님.

- **TLS 1.3 통합** — 핸드셰이크가 1 RTT (TCP+TLS 의 3 RTT 대비).

- **헤드 오브 라인 블로킹 해결** — HTTP/2 의 한계 극복.

- **연결 마이그레이션** — 모바일이 Wi-Fi 에서 LTE 로 바뀌어도 연결 유지.

**프록시별 지원 (2026년 5월).**

- nginx 1.25+ — QUIC 정식 지원.

- Caddy 2.6+ — 빌트인, 별도 설정 없음.

- HAProxy 2.6+ — quic 바인딩.

- Envoy 1.27+ — HTTP/3 listener.

- Traefik 3.x — `experimental: { http3: true }`.

**클라이언트 지원.** Chrome 87+, Firefox 88+, Safari 14+, curl 7.66+ (옵션). 사실상 모든 주요 브라우저가 HTTP/3 사용.

**언제 켤까.** 2026년 기준 글로벌 사이트는 무조건 켜는 게 좋다. UDP 가 막힌 환경(일부 기업 방화벽)에서는 자동으로 HTTP/2 로 fallback 되므로 단점이 거의 없다.

17장 · 레이트 리미팅 — 토큰 버킷 · 슬라이딩 윈도우 · 누수 버킷

**레이트 리미팅(rate limiting)** 은 리버스 프록시의 핵심 보안 기능이다. "1초에 100번 이상 요청은 거부" 같은 정책으로 DoS · 스크래핑 · 브루트 포스를 막는다.

**3가지 알고리즘.**

- **토큰 버킷(token bucket)** — 일정 속도로 토큰을 채우고, 요청마다 토큰 소비. 버스트 허용. nginx `limit_req`, HAProxy stick-table.

- **슬라이딩 윈도우(sliding window)** — 최근 N 초 안의 요청 수 세기. 정확하지만 메모리 비용. Redis 와 결합.

- **누수 버킷(leaky bucket)** — 일정 속도로 처리, 초과는 큐잉 또는 드롭. nginx `limit_req` 의 기본 동작.

**nginx 예시.**

http {

limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;

server {

location /api/ {

limit_req zone=api burst=200 nodelay;

proxy_pass http://backend;

}

}

}

**분산 레이트 리미팅.** 여러 프록시 노드 간 카운트를 공유하려면 외부 저장소 필요. Redis 가 표준. Cloudflare Workers · Vercel · Lambda 같은 엣지에서도 마찬가지.

**API 게이트웨이 레벨.** Kong · Traefik · APISIX 가 더 풍부한 plugin 으로 IP, 사용자, API 키별 차별화된 레이트 리미트 제공.

18장 · WAF — ModSecurity · Coraza · 클라우드 WAF

**WAF(Web Application Firewall)** 는 SQL injection · XSS · path traversal · RCE 같은 L7 공격을 패턴 매칭으로 막는다.

**ModSecurity** — 2002년 시작된 오픈소스 WAF. Apache 모듈에서 시작, nginx 와 IIS 로 확장. **OWASP Core Rule Set(CRS)** 가 표준 룰셋. 그러나 2024년 Trustwave 가 ModSecurity 의 관리를 OWASP 에 이관했고, 미래는 약간 불확실하다.

**Coraza** — Go 로 작성된 ModSecurity 대체품. OWASP 가 직접 지원, Caddy · Traefik · Envoy 와 통합. **2026년 신규 프로젝트는 Coraza 권장**.

**클라우드 WAF (SaaS).**

- **Cloudflare WAF** — 가장 큰 글로벌 점유율, OWASP CRS + ML 룰.

- **AWS WAF** — CloudFront · ALB · API Gateway 와 통합.

- **Azure WAF** — Front Door · App Gateway 와 통합.

- **Google Cloud Armor** — Cloud Load Balancer 와 통합.

- **Akamai Kona** — 엔터프라이즈 전용.

- **Imperva** — 클래식 엔터프라이즈 WAF.

**한국 WAF.** AhnLab TrusGuard · WAPPLES · Penta Security Cloudbric. 금융권 컴플라이언스(전금감) 요구로 국내 솔루션이 강하다.

19장 · Cloudflare Workers · 엣지 서버리스의 챔피언

**Cloudflare Workers** 는 2017년 출시된 엣지 서버리스 런타임이다.

**스펙.**

- **런타임**: V8 isolate (각 요청이 별도 isolate 에서 실행, cold start 거의 0).

- **언어**: JavaScript, TypeScript, WebAssembly, (실험적) Python.

- **글로벌**: 330+ 도시 PoP.

- **레이턴시**: 사용자에서 50ms 이내.

**Cloudflare 의 풀스택 (2026년).**

- **Workers** — 컴퓨트.

- **R2** — 오브젝트 스토리지 (S3 호환, 무료 egress).

- **D1** — SQLite 기반 분산 DB.

- **KV** — 글로벌 key-value 스토어.

- **Durable Objects** — 상태 있는 단일 인스턴스.

- **Queues** — 메시지 큐.

- **Hyperdrive** — 외부 Postgres 캐싱.

- **Cloudflare Tunnel (cloudflared)** — 내부 서버를 엣지로 노출, IP 공개 안 함.

**Workers 예시.**

export default {

async fetch(request: Request, env: Env) {

const url = new URL(request.url)

if (url.pathname === '/api/hello') {

return Response.json({ greeting: 'hello world', region: request.cf.colo })

}

return fetch(request)

},

}

**왜 강한가.** 엣지 컴퓨트의 표준이 됐다. Vercel · Netlify 도 워커 비슷한 모델이지만 Cloudflare 의 규모와 가격 경쟁력이 압도적.

20장 · Vercel · Netlify · Fastly · AWS · Azure 엣지 비교

**Vercel Edge Functions / Middleware.** Cloudflare Workers 위에 빌드 (실제 인프라). Next.js · SvelteKit · Astro 와 깊은 통합. Edge Runtime 은 V8 isolate.

**Netlify Edge Functions.** Deno runtime 기반. **Deno Deploy** 인프라 사용. JSR · npm 양쪽 지원.

**Fastly Compute@Edge.** **WebAssembly 기반** — Rust, AssemblyScript, Go(JS) 로 코드 작성. cold start 0.1ms 미만. 보안 격리 강력.

**AWS Lambda@Edge.** CloudFront 와 통합되는 Lambda. Node.js, Python. cold start 100~500ms (다른 엣지 대비 느림).

**CloudFront Functions.** Lambda@Edge 의 더 가벼운 버전. ms 단위 실행, JS 만 지원. URL 재작성, 헤더 조작 등 단순 작업.

**Akamai EdgeWorkers.** JavaScript runtime, 300+ PoP. 엔터프라이즈 가격.

**Azure Front Door** + **Azure CDN** + **Azure Static Web Apps**.

**Google Cloud CDN** + **Cloud Load Balancer** + **Cloud Run**(엣지 아님).

비교 매트릭스:

| 플랫폼 | 런타임 | Cold Start | 가격 (1M 요청) |

| --- | --- | --- | --- |

| Cloudflare Workers | V8 isolate | ~0ms | 0.30 USD |

| Vercel Edge | V8 isolate | ~0ms | 0.65 USD |

| Netlify Edge | Deno | ~5ms | 2.00 USD |

| Fastly Compute | WASM | ~0.1ms | 1.00 USD |

| Lambda@Edge | Node/Python | 100~500ms | 0.60 USD |

| CloudFront Func | JS | ~1ms | 0.10 USD |

**선택 가이드.** Next.js 면 Vercel, 풀스택 엣지 데이터까지 필요하면 Cloudflare, AWS 락인이면 CloudFront Functions, 보안 격리·WASM 필요하면 Fastly.

21장 · 개발용 터널 — Cloudflare Tunnel · ngrok · Tailscale Funnel · Pinggy

로컬 머신에서 돌리는 서버를 인터넷에 노출하려면 **터널** 도구가 필수다.

**Cloudflare Tunnel (cloudflared).** Cloudflare 가 운영하는 무료 터널. 로컬 머신에 cloudflared 데몬을 띄우고 도메인을 매핑. IP 공개 안 됨. 프로덕션에서도 쓸 만큼 안정적.

**ngrok.** 가장 오래된 터널 SaaS. 무료 플랜은 랜덤 도메인, 유료는 고정 도메인. 한 달에 1GB 무료. 데모·웹훅 테스트의 표준.

**Tailscale Funnel.** Tailscale 의 새 기능. tailnet 안 노드를 인터넷에 노출. Tailscale 사용자라면 무료.

**Pinggy** — 인도 스타트업, ngrok 대안. SSH 한 줄로 터널.

**localtunnel · serveo** — 무료 오픈소스 대안, 안정성은 떨어짐.

**용도.**

- 로컬 개발 서버 데모 → ngrok · cloudflared.

- 웹훅 테스트 (Stripe, GitHub, Slack) → ngrok 이 표준.

- 사내 시스템 외부 노출 → Cloudflare Tunnel (프로덕션급).

- 임시 SSH → Tailscale Funnel.

22장 · API 게이트웨이 — 인접 카테고리

**API 게이트웨이** 는 리버스 프록시의 상위 카테고리 — L7 라우팅 + 인증 + 레이트 리미트 + 변환 + 분석. 2026년 주요 옵션.

**Kong Gateway.** OpenResty 기반 (일부 Go 로 이전 중). 가장 큰 플러그인 생태계. OSS 무료, Enterprise 유료.

**Tyk.** Go 기반, 오픈소스. Kong 의 경쟁자.

**KrakenD.** Go 기반, 선언적 config, 매우 빠름. 응답 aggregation 이 강점.

**APISIX (Apache).** OpenResty 기반, Kong 의 OSS 대안. etcd 가 저장소.

**Express Gateway.** Node.js 기반, 작은 팀용.

**Gravitee · WSO2.** 엔터프라이즈, API 관리 + 게이트웨이.

**Cloud 네이티브.** AWS API Gateway, Azure API Management, Google Cloud API Gateway, GCP Apigee.

**리버스 프록시 vs API 게이트웨이.** 경계는 흐릿하다. Traefik · Envoy 는 둘 다 가능. Kong · Tyk 는 API 게이트웨이에 더 집중. 핵심 차이는 **개발자 포털 · 빌링 · 분석** 같은 API 관리 기능의 유무.

23장 · 관측성 — Prometheus · OpenTelemetry · 액세스 로그

리버스 프록시는 **모든 트래픽이 지나는 지점** 이라 관측성의 황금 위치다.

**메트릭 (Prometheus).**

- **nginx** — 외부 nginx-prometheus-exporter, Plus 는 빌트인.

- **Caddy** — 빌트인 `/metrics` 엔드포인트.

- **Traefik** — 빌트인.

- **HAProxy** — 빌트인 또는 haproxy_exporter.

- **Envoy** — 빌트인, statsd · Prometheus 양쪽.

**핵심 메트릭.**

- requests per second

- latency p50, p95, p99

- error rate (5xx, 4xx)

- upstream health (active connections, queued, failed)

- TLS handshake duration

**트레이스 (OpenTelemetry).** Envoy · Traefik 은 OTel 빌트인. nginx 는 nginx-otel 모듈 (1.24+). 분산 트레이스는 마이크로서비스 디버깅의 표준.

**액세스 로그.** 모든 요청을 JSON 으로 로깅. ELK · Loki · Grafana 에서 분석. 액세스 로그는 보안 사고 포렌식에도 필수.

24장 · 한일 어댑션 — 클라우드 LB 와 WAF

**한국.**

- **NAVER Cloud Load Balancer** — ALB · NLB · CLB 라인업. Envoy 와 nginx 베이스.

- **Kakao Cloud Load Balancer** — 비슷한 라인업.

- **NHN Cloud Load Balancer** — 토스 페이먼츠 등 핀테크 다수.

- **AhnLab TrusGuard WAF · WAPPLES · Penta Security Cloudbric** — 금융권 WAF 의 사실상 표준.

- **NAVER · Kakao · Coupang 자체 엣지** — 내부에서 nginx/OpenResty/Envoy 조합 사용.

**일본.**

- **NTT Communications Smart Data Platform** — LB · CDN.

- **SAKURA Internet** — VPS · 클라우드 LB.

- **IIJ GIO** — 엔터프라이즈 클라우드 LB.

- **ConoHa** — 개인 · 중소기업.

- **AWS Tokyo · Osaka 리전** — 일본 기업의 80%가 AWS 사용. CloudFront + ALB 가 표준.

- **Mercari · LINE · Rakuten 자체 엣지** — Envoy · Istio 기반 서비스 메시.

**규제.** 한국은 K-ISMS, 일본은 ISMS-AC 와 PCI-DSS. 모두 WAF · TLS 1.2 이상 · 액세스 로그 보관(1년 이상)을 요구한다.

25장 · 의사결정 매트릭스 — 어떤 프록시를 고를까

**상황별 추천.**

- **단일 머신, 작은 팀, PHP 또는 정적 사이트** → nginx 또는 Caddy. Caddy 가 더 편함.

- **Docker · K8s, 자동화 우선** → Traefik 또는 NGINX Ingress.

- **마이크로서비스 + 서비스 메시** → Envoy (Istio 또는 Envoy Gateway 와 함께).

- **L4 초고성능 (DB 프록시, TCP 라우팅)** → HAProxy 또는 Envoy.

- **PHP 풀스택 (Laravel, Symfony)** → FrankenPHP.

- **글로벌 엣지 컴퓨트** → Cloudflare Workers + R2.

- **AWS 락인 엣지** → CloudFront + Lambda@Edge.

- **Next.js · SvelteKit 풀스택** → Vercel Edge.

- **사내 시스템 외부 노출** → Cloudflare Tunnel.

- **API 게이트웨이 (개발자 포털, 빌링)** → Kong 또는 Apigee.

- **레거시 nginx 안정 운영** → freenginx 또는 nginx 메인라인.

- **Rust 엔지니어 보유, 초고성능 커스텀** → Pingora.

**안티패턴.**

- "Caddy 가 자동 HTTPS 라서 모든 면에서 nginx 보다 낫다" — 성능과 모듈 생태계는 nginx 가 앞선다.

- "Envoy 가 가장 강력하니 다 Envoy 로" — 설정 복잡도, 작은 팀이 감당 못 함.

- "Cloudflare Workers 만 쓰면 인프라 끝" — 록인, 디버깅 어려움, 가격 스케일 주의.

26장 · References — 공식 문서와 좋은 글

- [nginx 공식 문서](https://nginx.org/en/docs/)

- [freenginx](https://freenginx.org/)

- [Caddy 공식 문서](https://caddyserver.com/docs/)

- [Traefik 공식 문서](https://doc.traefik.io/traefik/)

- [HAProxy 공식 문서](https://www.haproxy.com/documentation/)

- [Envoy Proxy 공식 문서](https://www.envoyproxy.io/docs)

- [OpenResty 공식](https://openresty.org/en/)

- [Cloudflare Pingora 발표 (2024)](https://blog.cloudflare.com/pingora-open-source/)

- [FrankenPHP 공식](https://frankenphp.dev/)

- [Sozu 공식](https://www.sozu.io/)

- [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/)

- [NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/)

- [Istio 공식](https://istio.io/)

- [Linkerd 공식](https://linkerd.io/)

- [Let's Encrypt](https://letsencrypt.org/)

- [cert-manager](https://cert-manager.io/)

- [step-ca (smallstep)](https://smallstep.com/docs/step-ca/)

- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)

- [Coraza WAF](https://coraza.io/)

- [HTTP/3 RFC 9114](https://www.rfc-editor.org/rfc/rfc9114.html)

- [Cloudflare Workers 공식](https://workers.cloudflare.com/)

- [Fastly Compute@Edge](https://www.fastly.com/products/edge-compute)

- [Vercel Edge Functions](https://vercel.com/docs/functions/runtimes/edge)

- [Netlify Edge Functions](https://docs.netlify.com/edge-functions/overview/)

- [AWS Lambda@Edge 공식](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html)

- [Kong Gateway 공식](https://docs.konghq.com/)

- [Apache APISIX](https://apisix.apache.org/)

- [Tailscale Funnel](https://tailscale.com/kb/1223/funnel)

- [ngrok](https://ngrok.com/docs)

현재 단락 (1/479)

2026년 신입 백엔드 엔지니어가 처음 마주치는 질문: "그냥 Node.js 서버를 3000 포트에 띄우고 끝 아닌가요? 왜 앞에 nginx를 또 띄워야 하죠?"

작성 글자: 0원문 글자: 20,220작성 단락: 0/479