티스토리 뷰

STUDY

마이크로서비스 아키텍처와 API Gateway 기본: 왜 필요하며 어떤 선택지가 있을까

ebson 2026. 3. 16. 20:31

마이크로서비스 아키텍처를 처음 접했을 때 가장 먼저 느끼는 변화 중 하나는 서비스 간 통신 방식입니다. 모놀리스 환경에서는 내부 메서드 호출로 해결되던 문제들이 마이크로서비스에서는 네트워크 호출로 바뀝니다. 단순히 서비스가 분리되는 것처럼 보이지만 실제로는 시스템의 복잡도가 다른 차원으로 이동하게 됩니다.

 

특히 클라이언트와 백엔드 서비스 간 통신 구조를 설계할 때 많은 팀이 비슷한 문제를 경험합니다. 서비스 수가 증가하면서 클라이언트는 여러 개의 서비스와 직접 통신해야 하고, 인증이나 로깅 같은 공통 기능이 여러 서비스에 중복 구현되는 상황이 발생합니다. 이러한 문제를 해결하기 위해 등장한 대표적인 아키텍처 패턴이 API Gateway입니다.

 

이 글에서는 API Gateway 패턴이 등장하게 된 배경을 살펴보고, 다양한 정의를 비교하면서 패턴 자체의 의미를 정리합니다. 또한 BFF나 Service Mesh와 같은 관련 아키텍처 패턴과의 관계를 살펴보고, Zuul에서 Envoy와 Istio에 이르기까지 API Gateway 생태계가 어떻게 발전해 왔는지도 함께 정리합니다. 마지막으로 어떤 상황에서 API Gateway를 도입하는 것이 적절한지, 반대로 언제는 오버엔지니어링이 될 수 있는지도 함께 생각해 보겠습니다.


마이크로서비스에서 등장한 통신 복잡도

 

모놀리스 아키텍처에서는 대부분의 기능이 하나의 애플리케이션 내부에 존재합니다. 사용자 요청이 들어오면 동일한 프로세스 내부에서 여러 모듈이 협력하여 처리합니다. 네트워크 호출이 거의 없기 때문에 인증, 로깅, 캐싱 같은 공통 기능도 애플리케이션 내부에서 일관되게 처리할 수 있습니다.

 

하지만 시스템이 성장하면서 모놀리스는 점점 관리하기 어려워집니다. 기능 간 결합도가 높아지고, 작은 변경이 전체 시스템에 영향을 미칠 가능성이 커집니다. 이러한 문제를 해결하기 위해 서비스 단위로 시스템을 분리하는 SOA(Service-Oriented Architecture)가 등장했고, 이후 더 작은 단위로 서비스를 분리하는 마이크로서비스 아키텍처가 널리 사용되기 시작했습니다.

 

마이크로서비스 환경에서는 하나의 사용자 요청을 처리하기 위해 여러 서비스가 협력해야 합니다. 예를 들어 전자상거래 시스템을 생각해 보면 주문 서비스, 결제 서비스, 재고 서비스, 배송 서비스 등이 각각 독립된 서비스로 존재합니다. 클라이언트가 주문을 생성하려면 여러 서비스와 통신해야 할 수도 있습니다.

 

이 과정에서 가장 먼저 등장하는 문제가 바로 통신 구조의 복잡도입니다. 서비스 수가 증가하면 클라이언트와 서비스 간 연결 관계가 급격히 증가합니다. 클라이언트가 직접 여러 서비스를 호출하는 구조에서는 N개의 클라이언트와 M개의 서비스 사이에 N×M 형태의 통신 관계가 만들어질 수 있습니다. 서비스가 조금만 늘어나도 네트워크 호출 구조가 매우 복잡해집니다.

 

또 다른 문제는 횡단 관심사(Cross-Cutting Concern)입니다. 인증, 권한 검증, 로깅, Rate Limiting, 모니터링과 같은 기능은 대부분의 서비스에서 공통적으로 필요합니다. 만약 각 서비스에서 이러한 기능을 각각 구현하게 되면 코드 중복이 발생하고 정책을 변경할 때도 모든 서비스를 수정해야 합니다.

 

이러한 문제는 마이크로서비스 환경에서 자연스럽게 나타나는 구조적 특성이라고 볼 수 있습니다. 그리고 이 문제를 해결하기 위한 대표적인 설계 접근 방식이 바로 API Gateway 패턴입니다.

 



API Gateway 패턴의 정의

 

API Gateway라는 용어는 특정 제품을 의미하는 경우도 있지만, 원래는 하나의 아키텍처 패턴을 의미합니다. 여러 아키텍처 문서에서도 API Gateway를 패턴으로 설명하고 있으며, 대표적으로 Chris Richardson, Martin Fowler, Microsoft Azure Architecture Center에서 관련 내용을 확인할 수 있습니다.

 

Chris Richardson이 운영하는 microservices.io에서는 API Gateway 패턴을 다음과 같은 방식으로 설명합니다. 클라이언트와 마이크로서비스 사이에 하나의 게이트웨이 계층을 두어 모든 요청을 이 계층을 통해 전달하도록 하는 구조입니다. 클라이언트는 개별 서비스의 위치나 내부 구조를 알 필요 없이 게이트웨이를 통해 통신하게 됩니다.

 

Martin Fowler 역시 비슷한 맥락에서 API Gateway를 설명합니다. 여러 개의 백엔드 서비스를 하나의 진입점으로 통합하여 클라이언트와 서비스 간 결합도를 낮추는 역할을 한다고 정리합니다. 특히 다양한 클라이언트 환경—웹, 모바일, 파트너 시스템—을 지원하는 상황에서 이러한 구조가 유용하다고 설명합니다.

 

Microsoft Azure Architecture Center에서도 API Gateway 패턴을 마이크로서비스 아키텍처의 핵심 구성 요소 중 하나로 소개합니다. 클라이언트 요청을 적절한 서비스로 라우팅하고, 인증, SSL 종료, 캐싱, 요청 변환 같은 공통 기능을 처리하는 역할을 한다고 설명합니다.

 

여기서 중요한 점은 API Gateway가 패턴이라는 사실입니다. 즉 특정 제품이나 프레임워크가 아니라 문제를 해결하기 위한 설계 방식입니다.

 

예를 들어 다음과 같은 기술들은 API Gateway 패턴을 구현하는 제품입니다.

 

Spring Cloud Gateway

Kong

AWS API Gateway

Netflix Zuul

 

패턴과 제품을 구분해서 이해하는 것은 실제 아키텍처를 설계할 때 중요한 기준이 됩니다. 패턴을 이해하지 못한 채 특정 제품만 도입하면 시스템 구조와 맞지 않는 선택을 할 가능성이 있기 때문입니다.

 

BFF, Edge Gateway, Internal Gateway와의 관계

 

API Gateway 패턴을 이야기하다 보면 자주 함께 등장하는 용어들이 있습니다. 대표적으로 BFF, Edge Gateway, Internal Gateway 같은 개념입니다.

 

BFF(Backend for Frontend)는 특정 클라이언트를 위해 맞춤형 API를 제공하는 게이트웨이입니다. 웹, 모바일, 태블릿 등 서로 다른 클라이언트가 서로 다른 API 형태를 필요로 하는 경우가 많기 때문에 각 클라이언트에 맞는 백엔드 계층을 두는 방식입니다.

 

예를 들어 모바일 애플리케이션은 네트워크 요청 수를 최소화하는 것이 중요하기 때문에 여러 서비스를 호출한 결과를 하나의 API로 묶어 제공할 수 있습니다. 반면 웹 애플리케이션은 보다 세분화된 API를 사용할 수도 있습니다.

 

Edge Gateway는 외부 트래픽이 시스템 내부로 들어오는 지점에서 동작하는 게이트웨이를 의미합니다. 일반적으로 인증, TLS 종료, 요청 라우팅 같은 기능을 수행합니다. 클라우드 환경에서는 이 계층이 Load Balancer와 함께 동작하는 경우도 많습니다.

 

Internal Gateway는 서비스 내부 통신을 위한 게이트웨이입니다. 외부 클라이언트가 아니라 내부 서비스 간 호출을 관리하는 역할을 합니다. 대규모 조직에서는 내부 API 관리 정책을 일관되게 유지하기 위해 이런 구조를 사용하기도 합니다.

 

이러한 개념들은 서로 경쟁 관계라기보다는 서로 다른 문제를 해결하는 방식이라고 볼 수 있습니다.

 



Service Mesh와의 역할 분담

 

API Gateway와 함께 자주 언급되는 또 하나의 기술이 Service Mesh입니다. 처음 접하면 두 기술이 비슷한 역할을 하는 것처럼 보이기도 합니다.

 

Service Mesh는 서비스 간 통신을 관리하기 위한 인프라 계층입니다. Istio나 Linkerd 같은 Service Mesh는 서비스 간 네트워크 트래픽을 프록시 레이어에서 제어합니다. 일반적으로 각 서비스 옆에 사이드카 프록시가 배치되고 이 프록시가 트래픽을 관리합니다.

 

API Gateway와 Service Mesh의 가장 큰 차이는 적용 범위입니다. API Gateway는 주로 클라이언트와 서비스 사이의 통신을 관리합니다. 반면 Service Mesh는 서비스 간 내부 통신을 관리합니다.

 

예를 들어 인증, 요청 라우팅, API 버전 관리 같은 기능은 API Gateway에서 처리하는 경우가 많습니다. 반면 서비스 간 트래픽 제어, retry 정책, circuit breaker 같은 기능은 Service Mesh가 담당하는 경우가 많습니다.

 

실제 대규모 마이크로서비스 환경에서는 API Gateway와 Service Mesh를 함께 사용하는 경우도 많습니다. 각각 해결하려는 문제가 다르기 때문입니다.

 



API Gateway 생태계의 진화

 

API Gateway 기술은 마이크로서비스 아키텍처의 확산과 함께 빠르게 발전했습니다. 초기에는 Netflix가 개발한 Zuul이 대표적인 구현체였습니다.

 

Zuul은 Netflix OSS 생태계의 일부로 등장한 API Gateway입니다. Java 기반으로 구현되었으며 필터 기반 구조를 통해 요청을 처리합니다. Spring Cloud Netflix 프로젝트에서도 Zuul을 API Gateway로 사용할 수 있도록 지원했습니다.

 

하지만 Zuul은 Servlet 기반 구조였기 때문에 비동기 처리나 고성능 네트워크 처리에 한계가 있었습니다. 이러한 이유로 Spring Cloud에서는 이후 Spring Cloud Gateway를 새롭게 개발하게 됩니다.

 

Spring Cloud Gateway는 Netty 기반의 비동기 논블로킹 아키텍처를 사용합니다. Spring WebFlux 기반으로 동작하기 때문에 높은 동시성을 처리할 수 있으며 필터 체인을 통해 다양한 기능을 확장할 수 있습니다.

 

한편 클라우드 환경에서는 Kong과 AWS API Gateway 같은 제품이 널리 사용되기 시작했습니다. Kong은 Nginx 기반으로 동작하는 API Gateway로 플러그인 방식 확장이 특징입니다. 다양한 인증 방식, Rate Limiting, 로깅 기능을 플러그인 형태로 제공하며 Kubernetes 환경에서도 널리 사용됩니다.

 

AWS API Gateway는 완전 관리형 서비스로 제공되는 API Gateway입니다. 서버를 직접 운영할 필요 없이 REST API와 HTTP API를 구성할 수 있으며 AWS Lambda와 같은 서버리스 서비스와 함께 사용하는 경우가 많습니다.

 

최근에는 Envoy 기반 게이트웨이 아키텍처가 점점 더 널리 사용되고 있습니다. Envoy는 고성능 L7 프록시로 다양한 프로토콜을 지원하며 확장성이 뛰어난 것이 특징입니다. Istio 역시 내부적으로 Envoy 프록시를 사용합니다.

 

이러한 흐름을 보면 API Gateway 기술은 단순한 요청 라우팅 도구에서 점점 더 복잡한 트래픽 관리 플랫폼으로 발전하고 있다는 점을 확인할 수 있습니다.

 



API Gateway 도입 판단 기준

 

API Gateway는 매우 유용한 패턴이지만 모든 시스템에서 반드시 필요한 것은 아닙니다. 시스템 규모와 아키텍처에 따라 도입 여부를 판단하는 것이 중요합니다.

 

Spring 기반의 중소 규모 서비스에서는 Spring Cloud Gateway 같은 프레임워크 하나로 충분히 API Gateway 역할을 구현할 수 있습니다. 서비스 수가 많지 않다면 오히려 구조를 단순하게 유지하는 것이 운영 측면에서 더 유리할 수도 있습니다.

 

Kubernetes 기반 대규모 환경에서는 API Gateway와 Ingress Controller, Service Mesh가 함께 사용되는 구조가 일반적입니다. 이 경우 트래픽 관리와 보안 정책을 중앙에서 통제할 수 있습니다.

 

서버리스 환경에서는 AWS API Gateway 같은 관리형 서비스를 사용하는 것이 일반적입니다. 인프라를 직접 운영할 필요 없이 API 관리 기능을 사용할 수 있기 때문입니다.

 

폴리글랏 마이크로서비스 환경에서는 Kong이나 Envoy 기반 게이트웨이를 사용하는 경우도 많습니다. 다양한 언어로 구현된 서비스를 통합적으로 관리할 수 있기 때문입니다.

 

오버엔지니어링이 되는 경우

 

API Gateway는 강력한 패턴이지만 모든 상황에서 필요한 것은 아닙니다. 특히 서비스 수가 매우 적은 초기 단계에서는 게이트웨이를 도입하는 것이 오히려 복잡도를 증가시킬 수 있습니다.

 

예를 들어 단순한 CRUD 중심 서비스가 몇 개 정도 있는 상황이라면 클라이언트가 직접 API를 호출하는 구조도 충분히 관리할 수 있습니다. 이 경우 API Gateway를 도입하면 추가적인 운영 비용과 장애 지점이 생길 수도 있습니다.

 

또한 Gateway 계층이 지나치게 많은 기능을 담당하게 되면 또 다른 모놀리스가 되는 문제도 발생할 수 있습니다. 인증, 데이터 변환, 비즈니스 로직까지 게이트웨이에 집중되면 시스템 구조가 다시 복잡해질 가능성이 있습니다.

 

결국 API Gateway 역시 하나의 도구일 뿐이며 시스템의 규모와 요구사항에 맞게 선택하는 것이 중요합니다.

 



마무리

 

마이크로서비스 아키텍처는 시스템을 작은 단위로 분리함으로써 개발과 배포의 유연성을 높이는 장점이 있습니다. 하지만 서비스가 분리되면서 네트워크 통신 구조가 복잡해지고 공통 기능 관리가 어려워지는 문제도 함께 등장합니다.

 

API Gateway 패턴은 이러한 문제를 해결하기 위해 등장한 대표적인 아키텍처 접근 방식입니다. 클라이언트와 서비스 사이에 하나의 진입점을 두어 통신 구조를 단순화하고 공통 기능을 중앙에서 관리할 수 있도록 합니다.

 

다만 API Gateway는 특정 제품이 아니라 하나의 설계 패턴이라는 점을 이해하는 것이 중요합니다. 시스템의 규모와 요구사항에 따라 다양한 구현체와 아키텍처 선택지가 존재하기 때문입니다.

 

개인적으로 마이크로서비스 아키텍처를 공부하면서 느낀 점은, 새로운 기술을 도입할 때 항상 “왜 필요한가”를 먼저 생각하는 것이 중요하다는 점입니다. API Gateway 역시 마찬가지입니다. 기술 자체보다 그것이 해결하려는 문제를 이해하는 것이 아키텍처 설계에서 더 중요한 기준이 되는 것 같습니다.

'STUDY' 카테고리의 다른 글

마이크로서비스 아키텍처와 API Gateway 실전: 보안, 회복탄력성, 관측성 설계  (0) 2026.03.16
분산 트랜잭션에서 이벤트 기반 아키텍처로 전환하기 5편 : Saga 패턴 운영 완성 - 분산 트레이싱, 데이터 이상현상 대응, Eventual Consistency 설계  (0) 2026.03.11
분산 트랜잭션에서 이벤트 기반 아키텍처로 전환하기 4편 : Saga 패턴 에러핸들링 - 보상 트랜잭션, 재시도, Dead Letter Queue 실전 설계  (0) 2026.03.11
분산 트랜잭션에서 이벤트 기반 아키텍처로 전환하기 3편 : Transactional Outbox 패턴 - DB 변경과 메시지 발행을 원자적으로 처리하는 방법  (0) 2026.03.11
분산 트랜잭션에서 이벤트 기반 아키텍처로 전환하기 2편 : MSA Saga 패턴 완벽 이해 - Orchestration vs Choreography 비교와 비동기 메시징 설계  (0) 2026.03.11