모놀리식·API 게이트웨이·연합 게이트웨이, GraphQL API 환경에서 누가 이기나
마이크로서비스로 전환하면 API 게이트웨이를 어떻게 구성할지가 고민이다. 단일 진입점을 둘지, 각 서비스가 독립적으로 API를 제공할지, 아니면 연합(federated) 게이트웨이로 통합할지. GraphQL이 등장하면서 이 선택이 더 복잡해졌다. GraphQL은 클라이언트가 원하는 데이터만 가져갈 수 있어 게이트웨이 패턴에 따라 성능 차이가 크다.
EECSI 학술대회에 발표된 연구는 모놀리식, 마이크로서비스 API 게이트웨이, 마이크로서비스 연합 게이트웨이 세 가지 아키텍처를 GraphQL API 기반 웹 애플리케이션에서 비교 분석한다.
연구는 동일한 기능을 세 가지 아키텍처로 구현하고 응답 시간, 처리량, 자원 사용량, 개발 복잡도를 측정했다. 모놀리식은 모든 기능이 단일 애플리케이션에 통합된 구조, API 게이트웨이는 단일 진입점이 하위 서비스로 요청을 라우팅하는 구조, 연합 게이트웨이는 각 서비스가 자체 GraphQL 스키마를 가지고 게이트웨이가 이를 병합하는 구조다.
핵심 결과를 보면, 응답 시간에서는 모놀리식이 가장 빨랐다. 내부 메서드 호출이 네트워크 호출보다 빠르기 때문이다. 하지만 트래픽이 집중되면 모놀리식은 전체가 영향을 받는 반면, 마이크로서비스는 특정 서비스만 부하를 받아 장애 격리가 가능했다. API 게이트웨이 패턴은 구현이 단순하지만, 모든 요청이 게이트웨이를 거쳐 병목이 발생할 위험이 있었다. 연합 게이트웨이 패턴은 복잡한 데이터 결합 쿼리에서 가장 효율적이었다. 각 서비스가 자체 스키마를 관리하므로 팀 간 독립성도 가장 높았다.
개발 복잡도 측면에서 모놀리식이 가장 낮았고, 연합 게이트웨이가 가장 높았다. 하지만 장기적으로 연합 게이트웨이는 스키마 진화와 팀 독립성에서 이점이 컸다.
이 연구의 시사점은 GraphQL과 마이크로서비스의 조합에서 게이트웨이 패턴 선택이 전체 아키텍처 성능에 결정적 영향을 미친다는 것이다. 단순한 CRUD 중심의 서비스라면 API 게이트웨이로 충분하지만, 복잡한 데이터 결합과 팀 독립성이 중요하면 연합 게이트웨이를 고려해야 한다.
한계로는 규모가 제한된 실험 환경이라 대규모 엔터프라이즈 환경에서의 검증이 필요하고, 세 패턴의 장기적 유지보수 비용 비교가 부족하다.
GraphQL 기반 마이크로서비스를 설계 중이라면 먼저 데이터 결합의 복잡도를 파악하라. 단순한 조회가 대부분이면 API 게이트웨이로 시작하고, 다중 서비스 간 데이터 결합이 빈번하면 연합 게이트웨이로 전환하는 접근이 현실적이다. Apollo Federation이나 Schema Stitching 같은 도구로 점진적 도입이 가능하다.
📖 *Comparative Analysis of Monolith, Microservice API Gateway and Microservice Federated Gateway on Web-based application using GraphQL API (학술 논문)* | 논문 원문
※ 이 기사는 학술 논문을 바탕으로 작성되었습니다. 실제 적용 시 환경에 따라 다를 수 있으니 전문가와 상담하세요.