API Gateway — 모든 요청이 지나는 단일 현관
서비스를 잘게 쪼개고 나면, 그걸 호출하는 클라이언트 입장에서 새로운 골치가
생긴다. 회원은 member-service, 주문은 order-service, 결제는
payment-service… 프론트엔드가 이 수십 개 서비스의 주소를 전부 알아야 하나?
서비스 하나가 둘로 쪼개지면 프론트도 같이 고쳐야 하나? 인증 토큰 검사는
서비스마다 똑같이 또 넣어야 하나?
API Gateway는 이 모든 외부 요청이 지나는 단일 현관을 둬서 푼다. 클라이언트는 오직 게이트웨이 한 주소만 알면 되고, 게이트웨이가 요청을 보고 적절한 내부 서비스로 넘긴다(라우팅). 그리고 인증·CORS·로깅·속도 제한처럼 모든 요청에 공통인 처리를 게이트웨이가 한 번에 맡아, 각 서비스는 자기 본업에만 집중하게 한다.
게이트웨이는 본질적으로 리버스 프록시(reverse proxy) 다 — 클라이언트 대신 요청을 받아 뒤의 서버로 전달한다. 다만 단순 전달을 넘어 인증· 변환·집계 같은 애플리케이션 차원의 일까지 한다는 점에서 Nginx 같은 일반 프록시보다 역할이 넓다.
1. 게이트웨이 없이 직접 부르면 생기는 일
왜 입구를 하나로 모을까? 클라이언트가 각 서비스를 직접 부르는 그림을 떠올리면 문제가 줄줄이 나온다.
- 1클라이언트가 내부 구조를 다 알아야 한다
어떤 기능이 어느 서비스·주소인지 프론트가 추적한다.
내부 서비스를 쪼개거나 합치면 클라이언트도 따라 고쳐야 한다. 내부 구조가 외부로 새어 나가, 둘이 강하게 묶인다.
- 2공통 처리가 서비스마다 중복된다
인증·CORS·로깅·속도제한을 모든 서비스가 각자 구현.
같은 토큰 검증 코드가 10곳에 복사되고, 정책이 바뀌면 10곳을 다 고쳐야 한다. 한 곳만 빠뜨려도 보안 구멍이 된다.
- 3내부 서비스가 외부에 직접 노출된다
공격 표면이 서비스 수만큼 늘어난다.
모든 서비스가 인터넷에 열려 있으면 그만큼 지킬 곳이 많아진다. 입구를 하나로 모으면 방어선을 한 곳에 집중할 수 있다.
문제들의 공통점은 "외부가 내부의 복잡함을 그대로 떠안는다"는 것이다. 그 복잡함을 한 겹 막으로 가려주는 게 게이트웨이의 일이다.
2. 요청 하나가 게이트웨이를 지나는 길
게이트웨이가 요청을 받아 내부로 넘기기까지의 흐름을 보자. 단순 전달이 아니라 여러 관문을 순서대로 통과한다.
게이트웨이 단일 주소로
공통 관문을 한 곳에서
/api/orders/** → 주문 서비스
Eureka 등에서 인스턴스 선택
응답을 클라이언트로 되돌림
- 1라우팅 — 경로를 보고 대상 결정
URL·헤더 규칙으로 어느 서비스로 보낼지 정한다.
/api/orders/**는 주문 서비스,/api/pay/**는 결제 서비스 식으로 매핑한다. 클라이언트는 이 매핑을 몰라도 되고, 내부에서 서비스를 재배치해도 게이트웨이 규칙만 바꾸면 된다. - 2필터 — 전후로 공통 처리 끼우기
인증·헤더 가공·로깅을 전달 전후에 수행한다.
요청 전(pre) 필터에서 토큰을 검증하고, 응답 후(post) 필터에서 헤더를 정리하는 식이다. 모든 요청에 공통인 일을 여기 모아, 각 서비스는 비즈니스 로직만 갖게 한다.
- 3디스커버리 연동 — 이름으로 전달
고정 IP가 아니라 서비스 이름으로 대상을 찾는다.
게이트웨이는 Eureka 같은 디스커버리와 연동해
order-service라는 이름을 실제 주소로 바꿔 전달한다. 인스턴스가 늘거나 옮겨도 게이트웨이가 알아서 따라간다.
3. 게이트웨이가 흔히 맡는 일들
라우팅은 시작일 뿐이다. "모든 요청이 반드시 여기를 지난다"는 위치 덕분에, 게이트웨이는 횡단 관심사(cross-cutting concern)를 모아 처리하기 좋은 자리가 된다.
- ·인증·인가의 1차 검사 (토큰 유효성)
- ·속도 제한(rate limit)·요청 수 제어
- ·CORS·공통 헤더·로깅·추적 ID 부여
- ·여러 서비스 응답을 합치는 집계(BFF)
- ·라우팅·카나리/블루그린 트래픽 분배
- ·특정 도메인의 비즈니스 로직
- ·서비스별 상세 권한 판단 전부
- ·무거운 연산·긴 트랜잭션 처리
- ·한 서비스에만 쓰이는 데이터 가공
모든 트래픽이 한 곳을 지난다는 건, 그곳이 죽으면 전부 막힌다는 뜻이기도 하다. 그래서 게이트웨이는 보통 여러 대로 띄워 이중화하고, 무거운 로직을 넣어 느려지지 않게 한다. "공통 처리를 모은다"는 장점과 "병목·단일 장애점"이라는 위험은 한 몸이다.
모바일 앱과 웹은 필요한 데이터 모양이 다르다. BFF(Backend For Frontend) 는 클라이언트 종류마다 전용 게이트웨이를 둬서, 여러 서비스 호출을 대신 모아 그 화면에 딱 맞는 응답으로 빚어 준다. 게이트웨이를 "단순 전달"을 넘어 "조립" 계층으로 쓰는 패턴이다.
정리하면 API Gateway는 외부와 내부 사이의 단일 현관이다. 클라이언트에겐 복잡한 내부를 하나의 주소로 가려주고, 내부엔 공통 처리를 모아 각 서비스를 가볍게 한다. 라우팅·필터·디스커버리 연동이 핵심 동작이고, 그 대가로 병목과 단일 장애점을 관리해야 한다는 책임이 따라온다.
한 장 요약
- 1문제
서비스가 쪼개지면 클라가 주소를 다 알아야 하고 공통 처리가 중복된다.
- 2단일 현관
모든 외부 요청을 게이트웨이가 받아 적절한 내부 서비스로 넘긴다.
- 3라우팅
URL·헤더 규칙으로 대상 서비스를 정하고 디스커버리로 실제 주소를 찾는다.
- 4필터
인증·CORS·속도제한·로깅 등 공통 처리를 전후 필터로 한 곳에서.
- 5역할 경계
횡단 관심사는 모으되 비즈니스 로직은 각 서비스에 둔다.
- 6대가
병목·단일 장애점이 되므로 이중화하고 가볍게 유지해야 한다.