서비스를 여러 개로 쪼개면(마이크로서비스) 클라이언트가 곤란해집니다. 인증은 어디서? 주소가 바뀌면? 서비스마다 인증과 로깅을 따로 구현해야 하나? API 게이트웨이는 이 모든 트래픽이 지나가는 하나의 정문입니다. 클라이언트는 게이트웨이 하나만 알면 되고, 게이트웨이가 인증·라우팅·속도 제한 같은 공통 일을 처리한 뒤 적절한 내부 서비스로 요청을 넘깁니다.
게이트웨이가 하는 일
| 역할 | 설명 | 없으면 생기는 문제 |
|---|---|---|
| 라우팅 | 경로별로 알맞은 서비스로 전달 | 클라이언트가 모든 서비스 주소를 알아야 함 |
| 인증/인가 | 토큰 검증을 한곳에서 | 서비스마다 인증 중복 구현 |
| 속도 제한 | 과도한 요청 차단 | 특정 사용자가 시스템 과부하 유발 |
| 집계 | 여러 서비스 응답을 묶어 반환 | 클라이언트가 여러 번 호출 |
핵심은 "공통 관심사를 서비스 밖으로 빼내 한곳에 모은다"입니다. 각 서비스는 자기 비즈니스 로직에만 집중하면 됩니다.
요청이 흐르는 순서
사용자가 주문을 조회하는 상황을 따라가 봅니다.
TEXT
클라이언트 → API 게이트웨이
1) JWT 토큰 검증 (인증)
2) 분당 요청 수 확인 (속도 제한)
3) /orders 경로 → 주문 서비스로 라우팅
주문 서비스 → 게이트웨이 → 클라이언트
클라이언트는 api.example.com/orders 하나만 호출합니다. 내부에 주문·결제·재고 서비스가 몇 개든, 주소가 어떻게 바뀌든 클라이언트는 알 필요가 없습니다. 인증에 실패하면 게이트웨이 단계에서 바로 401을 돌려주므로 내부 서비스까지 요청이 들어가지도 않습니다. 보안 경계가 명확해지는 셈입니다.
로드 밸런서와 헷갈리지 않기
비슷해 보이지만 역할이 다릅니다.
| 구분 | 로드 밸런서 | API 게이트웨이 |
|---|---|---|
| 주 관심 | 트래픽 분산(L4/L7) | 애플리케이션 로직(L7) |
| 판단 기준 | 서버 부하·상태 | 경로·토큰·요청 내용 |
| 대표 기능 | 동일 서비스 인스턴스 분배 | 인증, 라우팅, 변환, 집계 |
로드 밸런서는 "같은 서비스의 여러 복제본에 골고루 나눠주는" 역할이고, 게이트웨이는 "요청 내용을 보고 어떤 서비스로 보낼지, 통과시킬지"를 판단합니다. 실제 운영에서는 둘을 함께 씁니다. 게이트웨이 앞에 로드 밸런서를 두기도 합니다.
요점 정리
- API 게이트웨이는 모든 클라이언트 요청이 지나는 단일 진입점이다.
- 인증·라우팅·속도 제한 같은 공통 관심사를 한곳에 모아 서비스를 가볍게 만든다.
- 로드 밸런서가 부하를 분산한다면, 게이트웨이는 요청 내용을 보고 라우팅·인증을 판단한다.
게이트웨이를 거쳐 인증과 라우팅이 어떻게 동작하는지 직접 호출해 보는 실습은 클라우드 트랙에서 회원가입 없이 무료로 할 수 있습니다.