GraphQL Federation (Apollo) 도입기: 모놀리식 API 게이트웨이의 붕괴를 막는 스키마 스티칭의 융합

조직이 거대해지면서 백엔드 코드 베이스가 덩달아 거대해지는 모놀리식(Monolithic)의 저주가 찾아왔습니다. 마이크로서비스로 분리(MSA)하려니, 프론트엔드 입장에서는 흩어진 수십 개의 REST API 엔드포인트를 각기 호출하여 조합해야 하는 지옥이 펼쳐졌습니다. 이를 묶어 보겠다고 거대한 단일 GraphQL 게이트웨이 서버를 구축했으나, 이번에는 모든 팀의 개발자들이 단일 스키마 파일 하나에 몰려들어 커밋 충돌과 릴리즈 병목을 일으켰습니다. 이 구조적 모순을 혁파한 혁신이 바로 Apollo Federation의 도입이었습니다. 각 팀(주문 팀, 유저 팀, 상품 팀)은 더 이상 중앙 게이트웨이 코드를 건드리지 않습니다. 자신들의 마이크로서비스 내에서 각자 독립적인 스몰 GraphQL 서버(Subgraph)를 띄웁니다. 주문 팀은 자신들의 스키마에 `extend type User { id: ID! }` 라며 유저 팀의 타입을 껍데기만 빌려오고 연관 관계를 던져놓습니다. 그러면 최상단의 매니저 체급인 Apollo Gateway 라이브러리가 런타임에 이 수십 개의 서브 그래프 스키마들을 끌어모아 단 하나의 거대한 슈퍼그래프(Supergraph)로 스티칭(Stitching) 해버립니다. 프론트엔드가 "사용자 이름과 그가 마지막으로 주문한 상품 리스트"를 하나의 쿼리로 던지면, 게이트웨이는 이 쿼리를 자동으로 분해하여 유저 팀과 상품 팀 서버에 병렬로 던진 후 결과를 JSON으로 합쳐 돌려줍니다. 기술적 결합도를 느슨하게 풀면서도, 클라이언트에게는 완벽히 타이트한 단일 데이터 인터페이스 지형을 제공하는 MSA의 궁극적 해답이었습니다.