마이크로서비스 아키텍처를 도입하면 자연스럽게 따라오는 구성 요소가 있다. 바로 API Gateway다. 많은 팀이 API Gateway를 도입하면서 “이제 외부 요청 처리는 깔끔해졌다”고 말한다. 인증, 라우팅, 로깅, 속도 제한까지 한 곳에서 관리할 수 있기 때문이다.
하지만 시간이 지나면 또 다른 이야기가 들린다. API Gateway가 또 하나의 병목이 되었다는 말이다.
API Gateway는 원래 클라이언트와 여러 마이크로서비스 사이의 진입점을 단순화하기 위해 등장했다. 각 서비스가 직접 외부와 통신하지 않도록 하고, 공통 기능을 중앙에서 처리하게 함으로써 중복을 줄이고 일관성을 유지하려는 목적이었다.
문제는 이 중앙화가 다시 결합도를 만들어낸다는 점이다.
모든 요청이 하나의 관문을 통과하게 되면, 그 지점은 자연스럽게 단일 실패 지점이 된다. 확장을 제대로 설계하지 않으면 트래픽이 몰릴 때 성능 저하가 발생한다. 더 나아가 인증, 인가, 변환 로직, 버전 관리, 정책 제어가 계속 추가되면서 Gateway는 점점 비대해진다.
처음에는 단순한 라우팅 계층이었지만, 어느 순간 비즈니스 로직 일부까지 들어오기 시작한다. 이 시점부터 구조는 흐트러진다.
또 다른 문제는 책임의 경계가 모호해진다는 점이다. 인증은 Gateway가, 권한 검증은 각 서비스가, 일부 데이터 가공은 다시 Gateway가 담당하는 식으로 역할이 분산되면 디버깅은 급격히 어려워진다. 장애가 발생했을 때 원인이 Gateway인지, 백엔드 서비스인지, 네트워크인지 구분하는 데 시간이 오래 걸린다.
운영 관점에서도 부담은 커진다. TLS 관리, 인증서 갱신, 레이트 리미팅 정책, 보안 규칙 변경 등 모든 정책 변경이 Gateway에 집중된다. 결과적으로 Gateway는 단순한 입구가 아니라, 거대한 정책 엔진이 된다.
그렇다고 API Gateway가 불필요하다는 뜻은 아니다. 오히려 잘 설계된 Gateway는 분산 환경에서 필수적인 요소다. 다만, 모든 문제를 Gateway로 해결하려는 접근이 위험하다는 것이다.
Gateway는 교통 정리를 하는 곳이지, 비즈니스를 수행하는 곳이 아니다. 인증과 공통 정책은 처리하되, 도메인 로직까지 끌어들이는 순간 다시 모놀리식의 그림자가 생긴다.
결국 핵심은 균형이다. 중앙 집중과 분산 책임 사이에서 어디까지를 Gateway의 역할로 둘 것인지 명확히 정의해야 한다. 그렇지 않으면 우리는 마이크로서비스 위에 또 다른 거대한 모놀리식을 쌓게 된다.
아키텍처는 도구의 문제가 아니다. 도구를 어디까지 사용할 것인지 결정하는 경계의 문제다.
API Gateway는 해결책이 아니라, 설계 선택지 중 하나일 뿐이다.