API Gateway
▶아키텍처 다이어그램
점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
서비스가 여러 개로 나뉘면 클라이언트가 어느 요청을 어디로 보내야 하는지 직접 알아야 하는 문제가 생깁니다. 인증과 로깅, rate limit 같은 공통 처리도 서비스마다 중복되기 쉽습니다. 이렇게 되면 클라이언트와 백엔드가 강하게 얽히고, 내부 구조 변경이 외부 인터페이스에 바로 번집니다. API Gateway는 이 외부 접점 혼잡을 줄이기 위한 경계 장치입니다.
단일 서버 구조에서는 클라이언트가 접속할 대상이 비교적 명확했습니다. 하지만 서비스가 잘게 나뉘자 외부 계약은 단순해야 하는데 내부 경로는 더 복잡해졌습니다. 여기에 인증, rate limit, 추적 같은 공통 정책을 반복 구현하는 비용까지 커지면서, 외부 접점을 별도 계층으로 정리하는 필요가 커졌습니다. API Gateway는 그 운영 압력의 결과입니다.
클라이언트 요청은 먼저 게이트웨이에 도착하고, 게이트웨이는 경로와 정책에 따라 내부 서비스로 라우팅합니다. 이 과정에서 인증 검증, 공통 헤더 처리, 응답 조합, 관측 신호 수집 같은 횡단 관심사를 함께 수행할 수 있습니다. 핵심은 서비스 로직을 대체하는 것이 아니라, 여러 서비스 앞단에서 공통 입구를 정리하는 데 있습니다.
API Gateway와 Service Discovery는 모두 요청이 어디로 가야 하는지와 관련돼 보이지만 역할이 다릅니다. API Gateway는 외부 진입점에서 정책과 라우팅을 담당하고, Service Discovery는 내부에서 살아 있는 서비스 인스턴스의 위치를 찾는 메커니즘입니다. 즉 하나는 프런트도어에 가깝고, 다른 하나는 내부 주소록에 가깝습니다.
모바일, 웹, 파트너 API처럼 다양한 클라이언트를 상대하면서 내부 서비스는 계속 변하는 환경에서 API Gateway는 유용합니다. 특히 공통 정책을 한곳에서 적용하고, 외부 계약을 안정적으로 유지하고 싶을 때 효과가 큽니다. 다만 게이트웨이 자체가 비대해지지 않도록 도메인 로직이 아니라 접점 책임에 집중시켜야 합니다.
더 읽어보기
현재 페이지의 개념 설명을 본 뒤 배경 설명과 참고 문서를 이어서 볼 수 있습니다.