API Gateway의 정의
마이크로서비스 아키텍처를 도입하면 하나의 애플리케이션이 주문 서비스, 결제 서비스, 회원 서비스처럼 여러 개의 작은 서비스로 쪼개집니다. 문제는 클라이언트(웹, 앱)가 이 수많은 서비스에 각각 직접 요청을 보내야 한다면 관리가 매우 복잡해진다는 점입니다. API Gateway는 이런 여러 마이크로서비스 앞단에 위치해서 모든 외부 요청을 받아들이는 ‘단일 진입점(Single Entry Point)’ 역할을 하는 서버입니다.
비유하자면 API Gateway는 호텔의 프런트 데스크와 같습니다. 투숙객(클라이언트)은 각 부서(청소, 룸서비스, 시설관리)에 직접 연락하지 않고 프런트에만 요청하면, 프런트가 알아서 적절한 부서로 연결해줍니다. 클라이언트 입장에서는 여러 서비스의 주소를 몰라도 되고, 오직 Gateway의 주소 하나만 알면 됩니다.
동작 원리와 주요 기능
클라이언트가 /api/orders로 요청을 보내면 API Gateway는 이를 주문 서비스로, /api/users는 회원 서비스로 라우팅합니다. 이 과정에서 단순히 요청을 전달하는 것 외에도 다양한 부가 기능을 처리합니다.
- 라우팅: 요청 경로에 따라 알맞은 마이크로서비스로 전달
- 인증/인가: 각 서비스마다 로그인 검증 로직을 넣지 않고 Gateway에서 토큰 검증을 일괄 처리
- 로드 밸런싱: 동일 서비스의 여러 인스턴스에 트래픽을 분산
- 속도 제한(Rate Limiting): 특정 사용자가 짧은 시간에 과도한 요청을 보내지 못하도록 제어
- 로깅/모니터링: 모든 요청과 응답을 한곳에서 기록해 장애 추적을 쉽게 함
예를 들어 넷플릭스나 아마존 같은 대규모 서비스는 수백 개의 마이크로서비스를 운영하는데, 만약 인증 로직을 서비스마다 따로 구현한다면 유지보수가 악몽이 될 것입니다. Gateway에서 한 번에 처리하면 코드 중복도 줄고 보안 정책 변경도 한 곳만 수정하면 됩니다.
실무에서 왜 필요한가
API Gateway 없이 마이크로서비스를 운영하면 클라이언트가 각 서비스의 IP, 포트, 프로토콜 차이까지 모두 알아야 하고, 서비스가 늘어날수록 클라이언트 코드도 계속 수정해야 합니다. Gateway를 두면 내부 서비스 구조가 바뀌어도 클라이언트는 영향을 받지 않습니다. 대표적인 오픈소스/상용 솔루션으로는 Kong, AWS API Gateway, Spring Cloud Gateway, Nginx 기반 게이트웨이 등이 있으며, 각각 라우팅 규칙 설정과 플러그인 확장 방식이 조금씩 다릅니다.
결국 API Gateway는 마이크로서비스 아키텍처의 복잡성을 클라이언트로부터 숨기고, 인증·트래픽 제어 같은 공통 관심사를 한곳에 모아 처리하는 핵심 인프라 컴포넌트라고 할 수 있습니다.