Reverse Proxy vs Load Balancer vs API Gateway

Alert

이 글은 Claude Code의 도움을 받아 작성되었습니다

TL;DR

• Reverse Proxy: 백엔드 서버 앞에서 SSL 종료, 캐싱, 압축, 보안을 처리하는 중개 계층
• Load Balancer: Reverse Proxy에 지능적 트래픽 분배 능력이 추가된 것. L4(TCP)와 L7(HTTP) 방식 존재
• API Gateway: HTTP를 이해하는 것을 넘어 API 비즈니스 로직(인증, 속도 제한, 버전 관리)까지 중앙 처리
• 실제 도구들(Nginx, Kong, Envoy)은 세 역할의 경계를 넘나들며 동작

Source

• Reverse Proxy vs Load Balancer vs API Gateway: The Real Difference? - CsMadeEz

---

1. 단일 서버의 한계

가장 단순한 웹 구조는 클라이언트가 서버에 직접 요청을 보내고 응답을 받는 것이다.

클라이언트 → 서버 → 클라이언트

개발 환경이나 트래픽이 적을 때는 문제없지만, 서버가 공개 인터넷에 직접 노출되면 여러 문제가 생긴다.

• SSL/TLS 처리 부담: 모든 HTTPS 요청마다 TLS 핸드셰이크를 서버가 직접 처리. 암호화 연산은 CPU를 많이 소비한다
• 다중 역할 과부하: 애플리케이션 로직 실행, 데이터베이스 쿼리, 정적 파일 서빙, 응답 압축을 한 서버가 전부 담당
• 보안 노출: 서버 IP가 DNS에 공개되어 있어 누구나 스캔, 탐색, 공격이 가능

비유

외과의사가 수술을 하면서 동시에 환자 접수, 장비 소독, 전화 응대, 청구 업무까지 처리하는 상황과 같다. 결국 수술 품질이 떨어진다.

---

2. Reverse Proxy

이 문제를 해결하기 위해 서버 앞에 놓는 보호 계층이 Reverse Proxy다.

Forward Proxy vs Reverse Proxy

두 개념은 이름이 비슷하지만 방향이 반대다.

구분	Forward Proxy	Reverse Proxy
대리 대상	클라이언트	서버
위치	클라이언트 앞	서버 앞
서버 입장	원래 클라이언트를 모름	클라이언트가 실제 서버를 모름
예시	회사 VPN, IP 마스킹 서비스	Nginx, Caddy, HAProxy

Forward Proxy는 클라이언트를 대신해서 인터넷에 요청을 보내는 것이고, Reverse Proxy는 서버를 대신해서 클라이언트의 요청을 받는 것이다.

Reverse Proxy가 하는 일

SSL 종료 (SSL Termination)

TLS 핸드셰이크는 암호화, 키 교환, 인증서 검증을 포함하는 비용이 큰 작업이다. Reverse Proxy가 엣지에서 이 작업을 한 번 처리하면, 백엔드 서버는 신뢰할 수 있는 내부 네트워크에서 평문 HTTP만 받으면 된다.

클라이언트 ─HTTPS─→ [Reverse Proxy] ─HTTP─→ 백엔드 서버
                    (SSL 종료)          (내부 네트워크)

캐싱

같은 상품 카탈로그를 1,000명이 요청한다고 하자. Reverse Proxy가 없으면 백엔드가 동일한 응답을 1,000번 생성한다. Reverse Proxy가 있으면 첫 번째 요청만 백엔드에 도달하고, 나머지 999개는 프록시 메모리에서 즉시 응답한다.

압축

응답이 프록시를 떠나기 전에 gzip이나 Brotli로 압축한다. 페이로드가 작아지고, 대역폭이 줄고, 응답 시간이 빨라진다. 백엔드는 압축에 CPU를 쓰지 않는다.

보안

실제 서버 IP는 프록시 뒤에 숨겨진다. 공격자는 프록시 계층만 볼 수 있다. 속도 제한, 헤더 검증, 의심스러운 패턴 차단, 잘못된 형식의 요청 거부를 프록시 단에서 처리한다.

Reverse Proxy의 한계

Reverse Proxy는 범용적이다. 연결과 라우팅 수준에서 동작하며, 비즈니스 로직을 이해하지 못한다. /users와 /orders의 차이를 모르고, 요청이 인증되었는지, 어떤 API 버전인지도 모른다. 설정된 규칙에 따라 트래픽을 전달할 뿐이다.

대표 도구

• Nginx
• HAProxy
• Caddy
• Envoy

---

3. Load Balancer

Reverse Proxy가 SSL, 캐싱, 압축, 보안을 처리해도 근본적인 문제가 남는다. 애플리케이션 코드를 실행하는 서버가 여전히 한 대라는 것이다.

트래픽이 갑자기 2배, 3배로 증가하면 Reverse Proxy는 모든 요청을 그 한 대의 백엔드에 계속 전달하고, 백엔드는 과부하에 빠진다.

해결책은 서버를 추가하는 것이다. 하지만 서버가 여러 대가 되면 새로운 문제가 생긴다.

• 어떤 서버에 요청을 보낼지 어떻게 결정할 것인가?
• 한 서버에 비용이 큰 요청이 몰리면?
• 서버 한 대가 죽으면 어떻게 감지하고 제외할 것인가?

이것이 Load Balancer가 해결하는 문제다. Load Balancer는 Reverse Proxy에 지능적 트래픽 분배 능력이 추가된 것이다. 완전히 다른 무언가가 아니라, 한 가지 특화된 기술이 진화한 형태다.

분배 알고리즘

Round Robin

가장 단순한 방식. 요청을 서버 A → B → C → A → B → C 순서로 돌린다. 모든 서버의 성능이 같고, 모든 요청의 비용이 비슷할 때 잘 동작한다.

Least Connections

현재 활성 연결이 가장 적은 서버에 다음 요청을 보낸다. 요청마다 처리 시간이 다를 때 (캐시 히트 vs 무거운 DB 쿼리) 트래픽이 자연스럽게 여유 있는 서버로 흐른다.

Weighted

서버 성능이 다를 때 사용한다. RAM 64GB 서버에는 가중치를 높게, 16GB 서버에는 낮게 설정해서 강한 서버가 더 많은 트래픽을 받게 한다.

IP Hash

클라이언트 IP를 해시해서 항상 같은 백엔드 서버로 보낸다. 세션 친화성(session affinity)에 유용하지만, 요즘은 상태 비저장(stateless) 아키텍처가 확장에 유리하므로 선호도가 낮다.

L4 vs L7 Load Balancing

이 구분은 실무에서 매우 중요하다.

구분	L4 (전송 계층)	L7 (애플리케이션 계층)
이해하는 것	[[11. TCP와 UDP	TCP]] 연결, IP 주소, 포트 번호
라우팅 기준	네트워크 연결 단위	요청 내용 기반
속도	매우 빠름	상대적으로 느림
유연성	낮음 (내용을 모름)	높음 (URL 경로별 라우팅 가능)
AWS 예시	Network Load Balancer (NLB)	Application Load Balancer (ALB)

L7 Load Balancer는 /api/users 트래픽은 사용자 서비스 클러스터로, /api/payments 트래픽은 더 안전한 결제 서버 클러스터로 보내는 식의 콘텐츠 기반 라우팅이 가능하다.

헬스 체크

Load Balancer의 핵심 기능이다. 백엔드 서버에 지속적으로 “살아 있어?” 핑을 보내고, 응답이 없으면 즉시 트래픽 풀에서 제거한다.

• 트래픽은 자동으로 정상 서버로 재분배된다
• 새벽 3시에 엔지니어가 일어나서 수동으로 트래픽을 돌릴 필요가 없다
• 장애 서버가 복구되면 자동으로 풀에 재합류한다

Load Balancer가 해결하는 두 가지 문제

1. 수평 확장성: 서버를 추가하는 것만으로 더 많은 트래픽 처리 가능
2. 고가용성: 개별 서버 장애가 전체 서비스 다운으로 이어지지 않음

이 두 가지는 안정성을 위한 기술에서 다루는 이중화, 가용성 개념과 직접 연결된다.

---

4. API Gateway

서비스가 성장하면 모놀리스가 마이크로서비스로 쪼개지는 시점이 온다. 사용자 서비스, 주문 서비스, 결제 서비스, 알림 서비스가 독립적으로 배포되고 확장된다.

이론적으로는 완벽하지만, 실제로는 시스템 입구에서 완전히 새로운 문제가 발생한다.

마이크로서비스가 만드는 중복 문제

• 인증 중복: 모든 서비스가 JWT 검증, API 키 확인, 권한 체크를 각자 구현. 12개 서비스에 동일한 인증 로직 12벌
• 속도 제한 중복: 서비스마다 다른 규칙, 다른 임계값, 다른 버그로 제한 로직을 구현
• 모니터링 파편화: 한 팀은 지연시간을 이렇게, 다른 팀은 에러를 저렇게 로깅. 장애 시 전체 그림을 볼 수 없음
• 요청 변환 중복: 모바일 앱은 JSON, 레거시 결제 시스템은 XML. 각 서비스에 변환 로직이 비즈니스 로직 위에 얹혀짐

결과적으로 12개의 독립 서비스가 아니라, 12개 팀이 각각 유지보수하는 같은 인프라 코드의 12개 복사본이 된다.

API Gateway의 역할

API Gateway는 여전히 Reverse Proxy지만, 전통적인 Reverse Proxy와 달리 API를 이해한다. 단순히 HTTP 요청을 전달하는 것이 아니라, 어떤 엔드포인트가 공개인지, 인증이 필요한지, 어떤 클라이언트가 어떤 등급인지 알고 있다.

중앙 집중 인증

클라이언트 → [API Gateway: JWT 검증] → 백엔드 서비스
                  ↓ (실패 시)
              즉시 거부 (백엔드 도달 전)

모든 서비스가 개별적으로 토큰을 검증하는 대신, 게이트웨이가 엣지에서 한 번 처리한다. 백엔드 서비스는 비즈니스 로직에만 집중할 수 있다.

중앙 집중 속도 제한

무료 사용자:   100 req/min
프로 사용자: 1,000 req/min
엔터프라이즈: 10,000 req/min

각 팀이 자체 제한 로직을 만드는 대신, 게이트웨이에서 일관되게 관리한다. 백엔드 서비스는 과금 등급이나 구독 로직을 알 필요가 없다.

요청/응답 변환

모바일 앱과 레거시 시스템이 다른 포맷을 사용해도, 게이트웨이가 중간에서 변환한다. 양쪽 다 상대방의 존재를 모르고 자신의 포맷으로만 통신한다.

API 버전 관리

/v1/* → 구 버전 백엔드
/v2/* → 신 버전 백엔드

마이그레이션 중에도 구 버전 클라이언트는 계속 동작하고, 새 클라이언트는 자연스럽게 신 버전으로 이동한다.

통합 관찰성 (Observability)

모든 요청이 하나의 진입점을 통과하므로, 어떤 엔드포인트에 트래픽이 몰리는지, 어떤 클라이언트가 에러를 많이 내는지, 어디서 지연이 발생하는지 한눈에 볼 수 있다.

대표 도구

• Kong (Nginx 기반)
• AWS API Gateway
• Apigee
• Tyk
• Envoy 기반 게이트웨이

---

5. 세 개념이 혼동되는 이유

실제 도구들이 세 역할의 경계를 존중하지 않기 때문이다.

Nginx 예시

Nginx 원래 = Reverse Proxy (SSL 종료, 캐싱, 압축)
  + 여러 백엔드 + 헬스 체크 = Load Balancer
  + 인증 플러그인 + 속도 제한 + OpenResty = API Gateway

하나의 소프트웨어가 설정에 따라 세 가지 모자를 동시에 쓰고 있다.

Kong 예시

Kong은 스스로를 API Gateway라고 부르지만, 내부적으로는 Nginx 위에 구축되어 있다. Reverse Proxy 동작과 Load Balancing을 내부에서 수행하고, 그 위에 API Gateway 기능을 추가한 것이다.

AWS 예시

AWS에는 Application Load Balancer(ALB)와 API Gateway가 별도 제품으로 있지만, 경계가 많이 겹친다. ALB도 이미 콘텐츠 기반 라우팅을 지원한다.

---

6. 실제 프로덕션에서의 계층 구조

대규모 시스템에서는 세 가지가 계층적으로 함께 동작한다.

[인터넷]
    ↓
[CDN / Edge Proxy]         ← SSL 종료, 정적 캐싱, DDoS 방어
    ↓
[API Gateway]              ← 인증, 속도 제한, 버전 라우팅
    ↓
[Load Balancer]            ← 트래픽 분배, 헬스 체크
    ↓
[백엔드 서비스 클러스터]     ← 비즈니스 로직만 처리

핵심 정리

구분	주요 역할	이해 수준	핵심 해결 문제
Reverse Proxy	SSL, 캐싱, 압축, 보안	연결/라우팅	서버 보호 + 부하 경감
Load Balancer	트래픽 분배 + 헬스 체크	TCP 또는 HTTP	수평 확장 + 고가용성
API Gateway	인증, 속도 제한, 변환, 버전 관리	API 비즈니스 로직	인프라 관심사의 중앙화

세 개념은 별개가 아니라 진화 관계다. Reverse Proxy → Load Balancer → API Gateway 순으로 더 많은 것을 이해하고, 더 많은 책임을 맡는다.