API Gateway: 마이크로서비스가 필요하다는 걸 몰랐던 바운서
발행: (2025년 12월 24일 오후 04:45 GMT+9)
9 min read
원문: Dev.to
Source: Dev.to
위에 제공된 링크 외에 번역할 텍스트가 포함되어 있지 않습니다. 번역을 원하는 본문을 알려주시면 한국어로 번역해 드리겠습니다.
API 게이트웨이가 하는 일
API 게이트웨이는 입구에 있는 사람과 같습니다:
- 신분증 확인 (인증/인가)
- 인원 통제 (속도 제한, 스로틀링)
- 올바른 방으로 안내 (라우팅)
- 가끔 누군가가 화재를 일으키는 것을 방지 (보안, WAF)
실제로 게이트웨이는 외부 요청을 위한 단일 진입점입니다. 서비스 앞에 위치해 공통 작업을 처리하므로 각 서비스가 이를 다시 구현할 필요가 없습니다.
| 작업 | 예시 |
|---|---|
| 라우팅 | GET /orders → 주문 서비스 |
| 인증/인가 | “토큰을 보여 주세요. 토큰이 없으면 입장할 수 없습니다.” |
| 속도 제한 | “4초 안에 10 000개의 요청을 보냈습니다. 잠시 물러나 주세요.” |
| 로드 밸런싱 | “인스턴스 #3이 피곤해 보입니다. #4로 이동하세요.” |
| 캐싱 | “이미 답변을 했습니다. 여기 캐시된 응답이 있습니다.” |
| 집계 | “클라이언트는 하나의 응답을 원하고, 백엔드는 5개의 호출이 필요합니다 → 이를 결합합니다.” |
| 프로토콜 변환 | “클라이언트는 REST, 서비스는 gRPC → 나는 양쪽을 모두 이해합니다.” |
게이트웨이를 사용하는 이유?
게이트웨이 없이
- 클라이언트는 모든 서비스 URL을 알아야 합니다.
- 각 서비스가 자체 인증, 속도 제한, 로깅 등을 구현합니다.
- 서비스 엔드포인트를 변경하면 클라이언트도 변경해야 합니다.
게이트웨이와 함께
- 모든 것을 제어하는 하나의 URL – 클라이언트는 단일 엔드포인트를 호출합니다.
- 중앙 집중식 정책(보안, 스로틀링, 가시성).
- 백엔드 서비스는 클라이언트를 깨뜨리지 않고 진화할 수 있습니다.
- 인증/인가가 가장자리에서 한 번만 수행되어 중복이 줄고 일관성이 향상됩니다.
- 모바일, 웹, 서드파티 클라이언트 모두 동일한 게이트웨이를 사용합니다.
- 캐싱, 압축, 요청 형태 조정, 응답 집계가 전체 호출 수를 줄이고 백엔드 부하를 완화합니다.
- 메트릭, 로그, 트레이싱 연관 및 전역 정책을 한 곳에서 관리합니다.
- 모든 서비스가 레거시 부담을 안게 하지 않고도 (
/v1,/v2) 버전 관리를 쉽게 할 수 있습니다.
단점 및 트레이드‑오프
- 추가된 구성 요소 → 또 다른 잠재적인 장애 지점.
- 게이트웨이가 다운되면 전체 API가 사용 불가능해집니다.
- 추가 홉을 도입하여 지연 시간이 증가합니다(보통은 허용 가능).
- 적절한 설정이 필요합니다; 플러그인을 과도하게 로드하면 기능이 “크리스마스 트리”처럼 복잡해질 수 있습니다.
- 관리형 게이트웨이는 비용이 들고, 자체 호스팅 게이트웨이는 엔지니어링 노력이 필요합니다.
- 일부 솔루션은 특정 클라우드 생태계에 종속되게 합니다.
트래픽 유형 및 배치
| 트래픽 | 일반 레이어 | 일반적인 우려 사항 |
|---|---|---|
| North‑south (client → service) | L4/L7 (네트워크 또는 애플리케이션) | 인증, 속도 제한, 버전 관리, 변환, 집계 |
| East‑west (service → service) | L4/L7 클러스터 내부 | mTLS, 재시도, 회로 차단, 트래픽 셰이핑 |
게이트웨이는 서비스‑메시 데이터 플레인과 함께 존재할 수 있으며, 심각한 시스템에서는 종종 함께 사용됩니다.
인기 API 게이트웨이 솔루션
- AWS API Gateway – 서버리스 환경에서 일반적(
API Gateway → Lambda). - Kong – Kubernetes와 마이크로서비스에서 인기; 플러그인 기반이며 매우 확장 가능.
- NGINX – 세밀한 제어가 가능한 게이트웨이/리버스 프록시로 구성 가능.
- Traefik – 자동 탐지 기능을 갖춘 클라우드 네이티브 라우터.
환경, 거버넌스 요구사항, 그리고 직접 담당하고 싶은 플랫폼 엔지니어링 수준에 따라 선택하세요.
게이트웨이를 사용해야 할 때
- 다중 서비스와 다중 클라이언트 유형.
- 중앙 집중식 보안, 스로틀링 및 모니터링이 필요함.
- 내부 서비스가 진화하는 동안 안정적인 외부 API를 원함.
When You Might Skip It
- 현재는 단일 서비스만을 갖는 작은 시스템.
- 아직 교차 적용 정책이 필요하지 않음.
- 추가 인프라를 운영하고 싶지 않음.
비유 요약
| 역할 | API Gateway 등가물 |
|---|---|
| 정문 | One entry point |
| 보안 요원 | Auth and quotas |
| 교통 경찰 | Routing and load balancing |
| 번역가 | Protocol and payload shaping |
| 접수 담당자 | Aggregation and consistent error responses |
Production을 위한 주요 고려사항
- 고가용성 – 다중 인스턴스, 다중 영역 배포.
- 가시성 – 메트릭, 로그, 트레이싱.
- 보안 제어 – 인증, mTLS/TLS, 선택적 WAF 통합.
- 속도 제한 / 할당량 – 백엔드 리소스 보호.
- 배포 전략 – 구성 변경을 위한 블루/그린 또는 카나리.
- 명확한 소유권 – 게이트웨이를 유지 관리할 사람이 필요함.
결론
API 게이트웨이는 마법이 아니며, 책임을 집중시킵니다. 잘 구현하면 마이크로서비스 환경 전반에 걸쳐 라우팅, 보안 및 가시성을 단순화합니다. 반대로 잘못 구현하면 비용이 많이 드는 병목이 되고, 문제가 발생했을 때 모두가 가장 먼저 비난하는 대상이 됩니다.
마이크로서비스를 구축하고 있다면, 어쩔 수 없이 게이트웨이를 사용하게 될 것입니다—차라리 의도적으로 설계하는 것이 좋습니다.
추가 글을 원하시나요? “API Gateway vs. API Management” 혹은 “Kubernetes: Ingress vs. Gateway API vs. Service Mesh”에 대한 실제 배포 패턴을 포함한 2부를 작성해 드릴 수 있습니다.