[Daily morning study] API Gateway 패턴과 역할

in Daily morning study / Backend

#daily morning study

Image

API Gateway란

클라이언트가 여러 백엔드 서비스에 직접 접근하는 대신, 단일 진입점(single entry point) 역할을 하는 서버 컴포넌트다. 클라이언트 요청을 받아 적절한 내부 서비스로 라우팅하고, 공통 기능을 중앙에서 처리한다.

마이크로서비스 아키텍처에서 특히 중요한데, 수십 개의 서비스가 있을 때 클라이언트가 각 서비스의 주소를 알고 직접 호출하면 관리가 불가능해지기 때문이다.

핵심 기능

1. 라우팅 (Routing)

요청 경로, 헤더, 메서드를 기반으로 어느 백엔드 서비스로 보낼지 결정한다.

/api/users/123     → User Service
/api/orders/456    → Order Service
/api/products      → Product Service

2. 인증 & 인가 (Authentication & Authorization)

JWT 검증, API Key 확인 같은 인증 로직을 각 서비스가 개별적으로 구현하는 대신 게이트웨이에서 한 번에 처리한다. 인증 통과 후에는 사용자 정보(user_id, role 등)를 헤더에 담아 내부 서비스로 전달한다.

Authorization: Bearer <jwt>
→ 게이트웨이에서 검증 후 내부 전달
X-User-Id: 123
X-User-Role: admin

3. Rate Limiting

클라이언트 IP 또는 API Key 기준으로 초당/분당 요청 수를 제한해 백엔드 서비스를 보호한다.

4. 요청/응답 변환 (Request/Response Transformation)

프로토콜 변환 (HTTP → gRPC), 헤더 추가/제거, 응답 구조 변경 등을 처리한다.

5. 로드 밸런싱

같은 서비스의 여러 인스턴스 중 하나를 선택해 트래픽을 분산한다.

6. 서킷 브레이커 연동

특정 서비스가 응답하지 않으면 즉시 실패 응답을 반환하고 해당 서비스로의 요청을 차단해 장애 전파를 막는다.

7. 모니터링 & 로깅

모든 요청이 게이트웨이를 거치기 때문에 중앙 집중식 로깅, 메트릭 수집, 분산 추적(tracing)의 진입점이 된다.

BFF (Backend for Frontend) 패턴

API Gateway의 변형으로, 클라이언트 종류(모바일, 웹, IoT 등)마다 별도의 게이트웨이를 두는 패턴이다.

Mobile App    → Mobile BFF → 내부 서비스들
Web App       → Web BFF    → 내부 서비스들
3rd Party     → Public API → 내부 서비스들

왜 BFF가 필요한가?

클라이언트필요한 데이터
모바일 (저대역폭)필드 최소화, 단일 집약 응답
웹 (풍부한 UI)더 많은 데이터, 여러 번 요청 가능
외부 파트너표준화된 REST, 버전 관리

각 클라이언트의 요구에 맞게 응답을 최적화할 수 있다. 일반 API Gateway가 모든 클라이언트에 동일한 인터페이스를 제공하는 것과 달리, BFF는 클라이언트별 최적화된 집약(aggregation)을 담당한다.

주요 구현 도구

도구특징
KongNginx 기반 오픈소스, 플러그인 생태계가 풍부
AWS API Gateway완전 관리형, Lambda와 통합 용이
NGINX직접 구성 가능, 고성능
Traefik컨테이너 환경(Docker, Kubernetes)에 최적화
EnvoyL7 프록시, Istio의 데이터 플레인으로 사용됨
Spring Cloud GatewayJava/Spring 생태계에서 주로 사용

API Gateway vs Service Mesh

자주 혼동되는 개념이라 비교해둔다.

 API GatewayService Mesh
위치외부 ↔ 내부 경계내부 서비스 간 통신
대상클라이언트 요청서비스 간 요청
역할인증, 라우팅, Rate Limit로드밸런싱, 서킷 브레이커, mTLS
예시Kong, AWS API GWIstio, Linkerd

두 개를 함께 쓰는 경우가 많다. API Gateway는 외부 트래픽 진입점, Service Mesh는 내부 트래픽 제어.

단점 및 주의사항

단일 장애 지점 (Single Point of Failure)
게이트웨이가 다운되면 전체 서비스가 영향받는다. 고가용성(HA) 구성이 필수다.

지연(Latency) 추가
모든 요청이 게이트웨이를 거치므로 홉(hop)이 하나 추가된다. 일반적으로 수 ms 수준이지만 무시할 수 없다.

병목(Bottleneck) 가능성
트래픽이 집중되므로 게이트웨이 자체의 수평 확장이 필요하다.

복잡성 증가
설정이 잘못되면 디버깅이 어렵다. 게이트웨이 계층에서 발생하는 문제가 서비스 문제처럼 보일 수 있다.

정리

API Gateway는 마이크로서비스 아키텍처에서 공통 횡단 관심사(cross-cutting concerns)를 한 곳에 모으는 역할을 한다. 인증, Rate Limiting, 로깅을 각 서비스마다 중복 구현하는 대신 게이트웨이에 위임해 개발 생산성을 높인다.

다만 게이트웨이가 너무 많은 비즈니스 로직을 담으면 “fat gateway” 안티패턴이 되니, 공통 인프라 관심사만 처리하도록 역할 경계를 명확히 유지해야 한다.