이 글의 대상 독자: 마이크로서비스나 백엔드 아키텍처를 처음 공부하는 분들을 위해 작성했습니다.
코드보다는 개념과 흐름 위주로 설명하니, 사전 지식 없이도 읽을 수 있습니다.
1. API Gateway란?
API Gateway는 클라이언트와 백엔드 서비스 사이에 위치하는 중간 계층입니다.
모든 API 요청이 반드시 거쳐가는 단일 진입점(Single Entry Point) 역할을 합니다.
쉽게 말해, 건물의 로비 안내 데스크와 같습니다.
방문객(클라이언트)은 안내 데스크(API Gateway)에 먼저 들러 신원 확인 후,
원하는 부서(서비스)로 안내받습니다. 방문객은 각 부서의 내부 위치를 몰라도 됩니다.
2. 왜 필요할까?
마이크로서비스 환경에서는 수십~수백 개의 서비스가 존재합니다.
API Gateway 없이 클라이언트가 각 서비스에 직접 접근하면 어떻게 될까요?
왼쪽처럼 클라이언트가 서비스에 직접 접근하면 세 가지 문제가 생깁니다.
- 클라이언트가 모든 서비스의 주소를 직접 알아야 함
- 서비스마다 인증 로직을 따로 구현해야 함
- 서비스 주소가 바뀔 때마다 클라이언트도 함께 수정해야 함
API Gateway는 이 복잡성을 클라이언트로부터 숨겨줍니다.
3. 주요 기능
트래픽 관리
- 라우팅: 요청 URL이나 메서드에 따라 적절한 서비스로 전달
- 로드 밸런싱: 트래픽을 여러 인스턴스에 분산
- 레이트 리미팅: 초당 요청 수를 제한해 서버 과부하 방지
보안
- 인증/인가 처리 (JWT, OAuth 2.0, API Key)
- SSL/TLS 종료 — HTTPS를 게이트웨이에서 한 번만 처리
- IP 차단 및 허용 목록 관리
관측성 (Observability)
- 모든 요청/응답 로깅
- 모니터링 및 트레이싱 중앙화
- 메트릭 수집
변환 및 집계
- 요청/응답 데이터 형식 변환 (예: XML → JSON)
- 여러 서비스의 응답을 하나로 합치는 API 집계(Aggregation)
4. 리버스 프록시와 무엇이 다를까?
API Gateway를 처음 배우면 리버스 프록시와 헷갈리기 쉽습니다.
사실 API Gateway는 리버스 프록시를 기반으로 만들어진 개념이기 때문입니다.
리버스 프록시란?
클라이언트는 백엔드 서버의 존재를 모르고, 프록시하고만 통신하는 구조입니다.
주요 역할은 요청 전달, 백엔드 서버 은닉, SSL 종료, 캐싱 정도입니다.
포함 관계로 이해하기
초록 원(리버스 프록시)의 기능을 API Gateway가 모두 포함하면서,
파란 영역처럼 API에 특화된 기능들이 추가된 구조입니다.
기능 비교표
| 기능 | 리버스 프록시 | API Gateway |
| 요청 전달 | O | O |
| SSL 종료 | O | O |
| 로드 밸런싱 | O | O |
| 캐싱 | O | O |
| 인증/인가 (JWT, OAuth) | X | O |
| 레이트 리미팅 | X | O |
| API 버전 관리 | X | O |
| 요청/응답 변환 | X | O |
| API 집계 | X | O |
실제로 유명한 API Gateway 솔루션들도 내부적으로 리버스 프록시를 사용합니다.
- Kong → 내부적으로 NGINX 기반
- Istio → 내부적으로 Envoy 기반
5. Load Balancer와의 관계
또 하나 헷갈리기 쉬운 개념이 Load Balancer(LB)와의 관계입니다.
일반적인 구성: LB가 앞에 위치
보통 LB → API Gateway 순서로 구성합니다.
API Gateway 자체도 여러 인스턴스로 이중화해야 하므로, 그 앞에서 트래픽을 분산해주는 LB가 필요합니다.
역할 비교
| 항목 | Load Balancer | API Gateway |
| 동작 계층 | L4 (TCP/UDP) | L7 (HTTP/HTTPS) |
| 판단 기준 | IP, 포트 | URL 경로, 헤더, 메서드 |
| 주요 역할 | 트래픽 분산, 고가용성 | 인증, 라우팅, 변환 |
| 콘텐츠 내용 인식 | X | O |
LB는 "API Gateway 인스턴스들 사이의 분산" 을 위한 것이고,
API Gateway는 "어느 서비스로 보낼지" 를 결정합니다. 목적이 다릅니다.
6. Kubernetes에서의 API Gateway
Kubernetes 환경에서는 두 가지 컴포넌트가 API Gateway 역할을 나눠서 담당합니다.
Ingress Controller — 외부 → 내부 담당 (North-South)
외부에서 클러스터로 들어오는 트래픽을 처리합니다.
HTTP 라우팅, TLS 종료, 인증 등 API Gateway의 핵심 역할을 수행합니다.
Istio — 내부 서비스 간 통신 담당 (East-West)
클러스터 내부 서비스끼리의 통신을 제어합니다.
각 Pod 옆에 사이드카(Envoy 프록시)를 붙여 트래픽을 가로채는 방식으로 동작합니다.
mTLS(상호 인증), 트래픽 제어, 관측성 등을 제공합니다.
정리
| 컴포넌트 | 담당 트래픽 | 주요 기능 |
| Ingress Controller | 외부 → 내부 | HTTP 라우팅, TLS, 인증 |
| Istio (서비스 메시) | 내부 ↔ 내부 | mTLS, 트래픽 제어, 관측성 |
Kubernetes를 사용 중이라면 이미 이 두 패턴을 함께 활용하고 있을 가능성이 높습니다.
7. 대표 솔루션 정리
| 구분 | 솔루션 |
| 클라우드 관리형 | AWS API Gateway, Azure API Management, Google Apigee |
| 오픈소스 | Kong, Traefik, NGINX |
| Kubernetes 특화 | Ingress Controller (NGINX/Traefik), Istio Gateway |
8. 정리
| 개념 | 한 줄 요약 |
| API Gateway | 모든 API 요청의 단일 진입점. 인증·라우팅·변환 담당 |
| 리버스 프록시 | API Gateway의 기반 기술. 요청 전달·은닉에 특화 |
| Load Balancer | API Gateway 앞단에서 인스턴스 간 트래픽 분산 |
| Ingress | Kubernetes에서 외부 트래픽 진입 담당 (North-South) |
| Istio | Kubernetes에서 내부 서비스 간 통신 담당 (East-West) |
전체 트래픽 흐름 요약
사용자 → Load Balancer → API Gateway / Ingress → (Istio) → 백엔드 서비스
이 글이 도움이 되셨다면 다음 글도 확인해보세요!
다음 편: 서비스 디스커버리(Service Discovery)란? — 마이크로서비스의 자동 전화번호부