스키마 스티칭과 Apollo Federation, 게이트웨이 설계의 차이
GraphQL 스티칭과 Apollo Federation을 공식 문서의 제품·버전 경계에 맞춰 비교하고, 팀 소유권·요청 위임·장애 동작을 검증하는 선택 기준을 설명합니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
여러 팀이 GraphQL API를 따로 운영할 때 클라이언트가 서비스별 주소와 응답을 직접 조합하게 두지 않고, 하나의 진입점 뒤에서 데이터를 연결할 수 있습니다. 흔히 비교되는 두 접근은 스키마 스티칭과 Apollo Federation입니다. 둘 다 여러 API를 한 그래프로 제공하려는 구현 방식이지만, 이름만으로 성능이나 운영 우위를 단정할 수는 없습니다. 실제 도구, 스키마 소유권, 요청 계획, 배포 책임을 함께 살펴야 합니다.
두 접근의 경계부터 확인하기
The Guild의 현재 @graphql-tools/stitch 문서는 여러 GraphQL 서비스의 스키마로 하나의 게이트웨이 프록시 스키마를 만들고, 요청의 일부를 해당 하위 스키마로 위임한다고 설명합니다. 문서가 소개하는 구성 선택지는 스키마 확장, 프로그램 방식의 타입 병합, 지시어 기반 타입 병합입니다. 이미 존재하는 스키마를 어떻게 연결하고 이름이나 타입 충돌을 다룰지에 따라 설계가 달라집니다.
Apollo의 현재 Federation 문서는 여러 API를 하나의 연합 GraphQL API로 선언적으로 묶는 Apollo 제품 아키텍처를 설명합니다. 클라이언트는 라우터에 요청하고, 라우터가 하위 API를 조정합니다. 전체 그래프를 supergraph, 구성 API를 subgraph라고 부릅니다. 이 용어와 지시어는 Apollo Federation의 설계에 속합니다. GraphQL 표준이 모든 서버에 이 구성을 요구한다는 뜻은 아닙니다.
변경을 누가 소유하고 합성하는가
스티칭에서는 게이트웨이 코드가 하위 스키마를 가져오고 연결하는 방식이 중심이 될 수 있습니다. 스키마 확장으로 관계를 추가할지, 타입 병합으로 같은 개체를 연결할지, 위임 규칙을 어디서 테스트할지 명시해야 합니다. 경계와 데이터 소유권이 불분명하면 게이트웨이에 통합 로직이 쌓이거나, 원격 스키마 변경이 배포 시점에 늦게 발견될 수 있습니다. 이는 도구가 자동으로 해결해 주는 문제가 아닙니다.
Federation에서는 팀별 subgraph가 전체 supergraph에 기여하고, 합성 규칙과 라우터가 그 경계를 반영합니다. Apollo 문서는 독립 팀이 각자 API를 개발하면서 클라이언트에는 단일 진입점을 제공하는 모델을 설명합니다. 그렇다고 팀 독립성이 자동으로 보장되는 것은 아닙니다. 공통 개체의 필드 소유권, 호환성 검사, 합성 실패 책임, 라우터 운영을 조직이 정해야 합니다.
비교표보다 먼저 시험할 질문
현재 시스템에서 가장 큰 문제를 구체화하세요. 여러 원격 스키마를 빠르게 묶는 일이 우선인지, 팀마다 변경을 제안하고 전체 그래프와의 호환성을 관리하는 일이 우선인지에 따라 시험 항목이 달라집니다. 작은 대표 쿼리를 정하고 데이터가 두 서비스에 걸쳐 있을 때의 위임·라우팅, 부분 장애, 오류 전달, 지연, 인증 경계, 스키마 변경 과정을 기록합니다. 각 도구의 현재 릴리스와 호환 서버도 확인하십시오.
비교 실험에서는 같은 데이터와 같은 쿼리를 사용하고, 캐시·네트워크·하위 서비스 시간을 분리해 측정해야 합니다. 요청이 한 곳에서 여러 하위 서비스로 fan-out될 때의 비용과 실패 양상은 배포 구성에 따라 달라집니다. 문서가 제공하는 기능 목록만으로 실제 운영 성능을 예측할 수 없습니다. 합성 시간, 개발자 워크플로, 관측성, 장애 대응을 함께 평가하세요.
운영 선택을 기록 가능한 질문으로 바꾸기
결정 전에 팀별로 스키마를 누가 수정하고, 합성 오류를 누가 해결하며, 하위 서비스 장애 때 클라이언트가 어떤 응답을 받는지 합의합니다. 동일한 테스트 쿼리와 실패 시나리오를 두 구현에서 실행하고, 변경 승인부터 배포까지 걸리는 과정도 비교합니다. 도입 비용에는 게이트웨이 운영뿐 아니라 서비스 팀의 학습, 모니터링, 버전 업그레이드가 포함됩니다. 하나의 통합 그래프가 실제로 줄이는 복잡성과 새로 생기는 운영 경계를 함께 문서화해야 합니다.
전문가 관점: 문서 버전과 운영 책임을 함께 고정한다
The Guild 문서는 GraphQL Tools v7부터 스티칭이 Federation과 상당히 비슷해졌다고 설명하지만, 이는 해당 라이브러리 문서의 버전 표기이지 모든 구현이 동등하다는 보증은 아닙니다. Apollo 문서도 Apollo의 라우터·supergraph·subgraph 모델을 설명합니다. 실무자는 비교표의 명칭보다 사용하는 라이브러리 버전, 합성 규칙, 팀의 소유권, 실패 시 동작을 명시한 재현 가능한 시험 결과를 결정 근거로 삼는 편이 안전합니다.