API Gateway

홈 화면 하나를 그리려면 사용자 정보, 상품 목록, 주문 이력이 모두 필요합니다. 서비스가 분리돼 있으면 앱은 세 서비스 주소를 각각 알아야 하고, 각각에 맞는 인증 방식으로 요청을 보내야 합니다. 서비스 하나의 주소가 바뀌면 그걸 호출하던 클라이언트가 모두 함께 바뀌어야 합니다. rate limit을 추가하거나 로깅 포맷을 통일하려면 서비스마다 코드를 손봐야 합니다. 기능이 늘수록 클라이언트와 백엔드 사이의 결합이 강해지고, 공통 처리 코드가 서비스마다 쌓여 갑니다.

서버가 하나이던 시절에는 클라이언트가 접속하는 곳이 명확했습니다. 단일 서버가 전체 기능을 담당했으니 외부 주소도 하나였습니다. 2010년대 초, 빠르게 성장하던 서비스 팀들이 독립 배포를 위해 서비스를 수십, 수백 개 단위로 쪼개기 시작했습니다. 그러자 클라이언트에 노출되는 주소와 계약도 그만큼 늘어났고, 공통 처리를 어디에 둘지 결정하기 어려워졌습니다. 서비스 구조 변경이 외부 계약으로 번지는 것을 막고, 인증과 공통 정책을 한 자리에 모아야 한다는 운영 압력이 커지면서 외부 접점을 전담하는 별도 계층이 필요해졌습니다.

클라이언트 요청이 게이트웨이에 도착하면 먼저 인증 토큰이 유효한지 확인합니다. 통과되면 요청 경로와 HTTP 메서드를 보고 어느 서비스로 보낼지 결정합니다. 필요하면 여러 서비스를 동시에 호출하고 응답을 하나로 묶어 돌려줄 수도 있습니다. 이 과정에서 로깅, 속도 제한, 공통 헤더 처리가 서비스 코드와 분리된 채 게이트웨이 안에서 이루어집니다. 서비스 입장에서는 인증과 공통 처리는 이미 끝난 상태로 요청이 들어오니, 자기 도메인 로직에만 집중할 수 있습니다.

Load Balancer와 혼동하기 쉽습니다. 둘 다 트래픽을 어딘가로 보낸다는 인상을 주기 때문입니다. Load Balancer는 같은 서비스의 여러 인스턴스 사이에서 부하를 나눕니다. API Gateway는 서로 다른 서비스 사이에서 요청을 목적지로 보냅니다. 하나는 '같은 일을 하는 여러 서버 중 누가 처리할까?'이고, 다른 하나는 '이 요청은 어느 서비스로 가야 하나?'입니다. 규모가 커지면 게이트웨이 뒤에 로드 밸런서가 함께 붙는 구조도 흔합니다. BFF(Backend for Frontends) 패턴도 자주 비교 대상입니다. API Gateway는 모든 클라이언트를 하나의 진입점에서 받습니다. BFF는 모바일과 웹처럼 클라이언트 종류마다 별도의 진입점을 두어 각각에 맞는 응답을 만듭니다. 클라이언트별 응답 최적화가 핵심 과제라면 단일 게이트웨이보다 BFF가 더 적합합니다.

인증 코드가 여러 서비스에서 중복되기 시작했거나, 내부 서비스 주소가 바뀔 때마다 클라이언트 코드도 함께 수정해야 한다면 API Gateway를 두는 시점입니다. 내부 서비스 구조는 자유롭게 바꾸면서 외부 API 계약은 안정적으로 유지해야 할 때, 진입점을 한 계층에 두면 그 분리가 자연스럽게 생깁니다. 파트너 API를 별도로 관리하거나, 여러 클라이언트 유형이 같은 백엔드를 호출하는 플랫폼에서도 자주 등장합니다. 다만 게이트웨이에 도메인 로직이 들어오기 시작하면 병목이 됩니다. 공통 처리와 비즈니스 판단의 경계가 흐려지는 순간 게이트웨이가 무거워지고 배포가 느려집니다. 입구 관리에 집중하고 도메인 판단은 각 서비스에 남기는 원칙이 실무에서 중요합니다.