166. API 게이트웨이 (API Gateway)

핵심 인사이트: 마이크로서비스(MSA)로 시스템을 100개로 쪼개놓으면, 클라이언트(스마트폰)는 100개의 주소를 다 외워야 할까? API 게이트웨이는 이 복잡한 구조를 숨겨주는 '친절한 호텔 프론트 데스크'다. 손님은 프론트에만 요청하면, 프론트가 알아서 주방, 객실, 세탁실로 심부름을 보내고 결과를 모아다 준다.

Ⅰ. API 게이트웨이(API Gateway)의 개념

마이크로서비스 아키텍처(MSA) 환경에서, 수십~수백 개로 분산된 내부 백엔드 서비스들 앞단에 위치하여 클라이언트의 모든 요청(Request)을 단일 진입점(Single Entry Point)으로 받아들이는 서버입니다. 클라이언트와 내부 서비스 사이의 거대한 방파제이자 프록시(Proxy) 역할을 수행합니다.

Ⅱ. API 게이트웨이가 필요한 이유 (도입 전후 비교)

[ API Gateway가 없는 경우 (지옥) ]
스마트폰 ───▶ [주문 서비스: 10.0.0.1:8080] (각각 인증/보안 로직 100번 구현해야 함)
스마트폰 ───▶ [결제 서비스: 10.0.0.2:9090] (주소가 바뀔 때마다 앱 업데이트 해야 함)
스마트폰 ───▶ [리뷰 서비스: 10.0.0.3:7070] (호출 횟수가 너무 많아 배터리 광탈)

[ API Gateway 도입 후 (천국) ]
스마트폰 ───▶ ┌────────────────────┐ ───▶ [주문 서비스]
             │ 🌟 API Gateway 🌟│ ───▶ [결제 서비스]
             │(api.mycompany.com)│ ───▶ [리뷰 서비스]
             └────────────────────┘

Ⅲ. API 게이트웨이의 5대 핵심 기능

기능	설명
1. 라우팅 (Routing)	`api.com/order`로 오면 주문 서비스로, `api.com/pay`로 오면 결제 서비스로 길을 찾아(Proxy) 줍니다. 내부 서비스의 IP가 바뀌어도 클라이언트는 모릅니다.
2. 인증 및 인가 (Auth)	수백 개의 마이크로서비스가 각자 로그인 검사를 할 필요 없이, 게이트웨이에서 한 번에 JWT 토큰을 검사하여 불법 요청을 튕겨냅니다. (보안 중앙화)
3. 응답 통합 (Aggregation)	클라이언트가 한 번만 요청을 보내도, 게이트웨이가 내부적으로 주문, 배송, 리뷰 3군데를 찔러서 응답을 하나의 JSON으로 예쁘게 모아(조립하여) 던져줍니다. (네트워크 횟수 감소)
4. 트래픽 제어 (Rate Limiting)	특정 클라이언트가 1초에 1만 번 호출하여 서버를 죽이려 할 때(DDoS 등), 게이트웨이 단에서 "1초에 10번만 허용"하도록 스로틀링(Throttling)을 걸어 차단합니다.
5. 프로토콜 변환	클라이언트는 REST(HTTP/JSON)로 요청했지만, 내부 서비스끼리는 엄청나게 빠른 gRPC나 비동기 메시지(AMQP)로 통신하도록 번역해 줍니다.

Ⅳ. 병목 현상(SPOF)의 위험

모든 트래픽이 API 게이트웨이라는 하나의 문으로 몰리기 때문에, 게이트웨이 서버가 죽으면 회사 전체 시스템이 마비되는 단일 장애점(SPOF) 이 될 수 있습니다. 따라서 반드시 이중화(HA)와 스케일 아웃(Scale-out)이 완벽하게 구성되어야 합니다.

📢 섹션 요약 비유: 대형 백화점의 '통합 안내 데스크'입니다. 손님이 직접 1층 화장품, 3층 남성복, 5층 식당가 매장 번호를 다 외워서 전화(직접 호출)할 필요 없이, 안내 데스크(API 게이트웨이) 번호 하나만 누르면 직원이 "고객님 인증 확인되셨고요, 남성복 매장으로 연결해 드리겠습니다(라우팅)"라고 알아서 다 처리해 주는 쾌적한 구조입니다.