API Gateway 정리

핵심 요약

• API Gateway는 클라이언트 앞단에서 여러 백엔드 서비스를 하나의 진입점으로 묶는 계층이다.
• 면접에서는 "왜 필요한가", "로드 밸런서와 뭐가 다른가", "게이트웨이에 너무 많은 책임을 몰면 어떤 문제가 생기나"까지 이어서 말하면 좋다.
• 인증, 라우팅, 공통 로깅, rate limiting 같은 횡단 관심사를 한곳에서 처리하기 좋다.
• 대신 병목 지점이 되기 쉽고, 게이트웨이가 비대해지면 또 다른 모놀리식 장애 지점이 될 수 있다.

API Gateway를 왜 두나

서비스가 하나일 때는 클라이언트가 서버를 직접 호출해도 큰 문제가 없다.
그런데 마이크로서비스가 늘어나면 클라이언트가 인증 서비스, 주문 서비스, 결제 서비스를 각각 알아야 하는 상황이 생긴다.

이때 API Gateway를 두면 클라이언트는 게이트웨이만 바라보고, 내부 서비스 위치나 조합 방식은 게이트웨이가 맡을 수 있다.
즉, 클라이언트와 내부 서비스 구조 사이에 완충층을 하나 두는 개념이다.

어떤 일을 맡나

라우팅

요청 경로에 따라 적절한 서비스로 전달한다.
예를 들어 /orders는 주문 서비스로, /users는 회원 서비스로 보내는 식이다.

인증과 인가 보조

JWT 검증이나 토큰 전달 같은 공통 인증 처리를 게이트웨이에서 먼저 할 수 있다.
다만 정말 세밀한 권한 판단까지 전부 게이트웨이에 몰아넣는 건 조심해야 한다.

공통 정책 적용

로깅, rate limiting, CORS, 요청 크기 제한, 헤더 정규화처럼 서비스마다 반복되는 정책을 게이트웨이에 모을 수 있다.

응답 조합

클라이언트가 한 화면을 만들기 위해 여러 서비스를 호출해야 한다면, 게이트웨이가 여러 응답을 묶어서 한 번에 내려주는 방식도 가능하다.

로드 밸런서와 차이는 뭐냐

둘 다 앞단에 있다는 점 때문에 헷갈리기 쉽다.
로드 밸런서는 주로 같은 역할을 하는 여러 서버 인스턴스에 트래픽을 분산하는 데 집중한다.

반면 API Gateway는 단순 분산보다 더 상위 개념이다.
서비스별 라우팅, 인증, 정책 적용, 응답 조합 같은 애플리케이션 레벨 기능을 같이 담당한다.

면접에서는 "로드 밸런서는 분산, 게이트웨이는 진입점과 정책 관리" 정도로 구분해서 말하면 전달이 잘 된다.

장점이 뚜렷한 상황

클라이언트 종류가 많을 때

웹, 앱, 파트너 API가 각각 다른 요구사항을 가지면 게이트웨이에서 버전 관리나 응답 포맷 조정을 하기가 편하다.

마이크로서비스가 늘어났을 때

내부 서비스 주소가 바뀌거나 서비스 수가 늘어나도 클라이언트는 게이트웨이 주소만 알면 되니 결합도를 낮추기 좋다.

공통 정책을 중앙 관리하고 싶을 때

각 서비스에 똑같은 필터를 중복 구현하는 대신, 앞단에서 공통 제어를 걸 수 있다.

조심해야 할 점

단일 장애 지점

게이트웨이가 죽으면 뒤 서비스가 멀쩡해도 전체 진입이 막힌다.
그래서 이중화, 오토스케일링, 헬스체크 같은 운영 설계가 중요하다.

게이트웨이 비대화

처음에는 편해서 기능을 계속 넣게 되는데, 나중에는 비즈니스 로직까지 들어와서 "거대한 관문 서비스"가 되기 쉽다.
게이트웨이는 공통 관심사 위주로 두고, 도메인 판단은 각 서비스에 남겨 두는 편이 안전하다.

추가 네트워크 홉

무조건 한 단계를 더 거치기 때문에 지연 시간과 디버깅 복잡도가 늘 수 있다.

면접 답변 예시

API Gateway는 여러 백엔드 서비스를 클라이언트 앞에서 하나의 진입점으로 묶는 계층입니다. 클라이언트는 내부 서비스 구조를 몰라도 되고, 게이트웨이가 서비스별 라우팅, 인증 보조, 공통 로깅이나 rate limiting 같은 정책을 처리할 수 있습니다. 로드 밸런서가 같은 서버군에 트래픽을 분산하는 데 더 가깝다면, API Gateway는 그보다 상위에서 진입점과 공통 정책을 관리하는 역할에 가깝습니다. 다만 게이트웨이가 병목이나 단일 장애 지점이 될 수 있고, 비즈니스 로직이 과하게 들어가면 비대해질 수 있어서 책임을 잘 제한해야 합니다.

장점

• 클라이언트가 내부 서비스 구조를 덜 알아도 된다.
• 인증, 로깅, rate limiting 같은 공통 정책을 중앙에서 관리하기 좋다.
• 서비스 분리와 API 버전 관리가 쉬워진다.

단점

• 장애가 나면 전체 진입점이 막히기 쉽다.
• 네트워크 홉이 늘어 지연과 디버깅 복잡도가 커질 수 있다.
• 기능을 너무 많이 넣으면 게이트웨이 자체가 비대해진다.

주의사항 / 실무 팁

• 면접에서는 로드 밸런서와의 차이를 꼭 같이 설명하는 편이 좋다.
• 인증을 게이트웨이에서 일부 처리하더라도 최종 권한 검증 책임은 서비스 안에서 다시 가져가는 경우가 많다.
• 게이트웨이에 비즈니스 규칙을 많이 넣기 시작하면 경계가 무너지기 쉽다.
• "공통 관심사는 앞단, 도메인 판단은 각 서비스"라는 기준을 같이 말하면 실무 감각이 드러난다.