06 — Federation & 모놀리식 그래프
질문: 한 회사의 거대 그래프를 여러 팀이 어떻게 나눠 가지나? 그리고 그것이 왜 자연스러운가? 한 줄 답: 모놀리식 그래프는 조직적으로 깨진다 — Federation은 팀 단위 subgraph를 supergraph로 합성해 팀 자율성과 클라이언트 단일 그래프를 동시에 잡는다.
GraphQL의 첫 다섯 챕터(00~05)가 한 서버의 한 그래프를 다뤘다면, 이번 챕터는 여러 팀, 여러 서버, 그러나 클라이언트에는 한 그래프라는 패러독스를 푼다.
이건 기술 문제가 아니라 조직 문제다 — Conway’s law의 그래프 버전이다.
챕터 지도
진화 다이어그램 — Monolith에서 Federation까지
읽는 순서
| 순서 | 문서 | 누구에게 |
|---|---|---|
| 1 | 01-the-monolithic-graph-problem | ”우리 회사 그래프가 왜 안 굴러가지?”가 궁금한 사람 |
| 2 | 02-history-stitching-to-federation | stitching에서 넘어와야 하는 사람, 또는 역사적 맥락이 궁금한 사람 |
| 3 | 03-federation-v2-fundamentals | Federation을 처음 도입하는 사람 — 워크플로 전체 |
| 4 | 04-entities-and-key-directive | @key와 _entities가 헷갈리는 사람 — 모든 federation의 심장 |
| 5 | 05-shareable-and-override | 두 팀이 같은 필드를 정의해야 하는 사람, 또는 소유권을 이전하려는 사람 |
| 6 | 06-router-and-query-planning | ”router가 뭘 하길래 비싸지?”가 궁금한 사람 |
| 7 | 07-alternatives-stitching-mesh | Apollo 외 대안(Mesh, Hot Chocolate Fusion 등)을 보는 사람 |
추천 동선: 1·3·4를 먼저 읽으면 왜·무엇·어떻게의 멘탈모델이 완성된다. 그 뒤 5(shared 필드)·6(런타임 비용)·7(대안)은 실전 시점에서 돌아오면 된다.
7개 문서 한 줄 요약
| # | 문서 | 한 줄 답 |
|---|---|---|
| 01 | 모놀리식 그래프 문제 | 한 schema.graphql을 N개 팀이 공유하면 PR 큐가 직렬화된다. Conway’s law의 그래프 버전. |
| 02 | Stitching → Federation 역사 | 2017 stitching은 런타임 합성이었고 느렸다. 2019 v1이 컴파일타임 합성을, 2022 v2가 shared ownership을 추가했다. |
| 03 | Federation v2 기본 | subgraph(자기 타입+entity 기여) + supergraph(자동 합성된 통합) + router(런타임 게이트웨이) 세 레이어다. |
| 04 | Entities & @key | @key는 primary key가 아니라 referential identity — “이 type은 다른 subgraph에서 확장 가능”이라는 표시. |
| 05 | @shareable & @override | @shareable은 동등한 공유, @override는 소유권 이전, @inaccessible은 공개 스키마에서 숨김. |
| 06 | Router & Query Plan | router는 한 쿼리를 최적 query plan으로 쪼개 여러 subgraph에 fan-out하고 결과를 merge한다. |
| 07 | 대안 — Stitching · Mesh | Mesh(REST→GraphQL 자동), Hot Chocolate Fusion(.NET), WunderGraph — federation이 답이 아닐 때가 있다. |
왜 이 챕터가 중요한가
| 흔한 의문 | 어느 문서가 답하는가 |
|---|---|
| ”왜 모놀리식 그래프가 안 되는데?“ | 01 — Conway’s law + PR 큐 직렬화 |
| ”stitching 안 쓰고 federation 쓰는 이유?“ | 02 — 런타임 비용 + 충돌 해석 부재 |
| ”subgraph와 supergraph 차이?“ | 03 — 자기 타입 vs 합성된 통합 |
| ”왜 모든 entity에 @key가 필요해?“ | 04 — referential identity 없이는 join이 불가능 |
| ”두 팀이 같은 필드 정의하면?“ | 05 — @shareable이 있어야 합성된다 |
| ”왜 router가 느려?“ | 06 — fan-out + sequential dep |
| ”Apollo 안 쓰는 federation도 있나?“ | 07 — Mesh, Hot Chocolate Fusion, WunderGraph |
강조 포인트
이 챕터를 관통하는 네 가지 반직관이 있다.
- Federation은 기술 문제가 아니라 조직 문제의 해결책이다. — 팀이 안 나뉘면 federation은 불필요하다. 5명짜리 회사는 monolith가 빠르고 단순하다.
- @key는 primary key가 아니다. — 그건 *“이 type을 외부에서 참조할 수 있다”*는 referential identity의 선언이다.
- @override는 마이그레이션 도구다. — A팀이 갖던 필드를 B팀이 점진적으로 가져갈 때 쓰는 합법적인 소유권 이전.
- Federation은 런타임 비용이 있다. — router fan-out과 sequential dependency가 latency 1.2~2배를 만든다. 그 비용 < 조직 비용일 때만 도입한다.
다음 챕터로
Federation이 클라이언트에 한 그래프를 보장하지만, 그 그래프의 공격 면적은 N개 subgraph의 합집합이 된다. 한 팀의 비싼 필드 하나가 전체 supergraph를 마비시킬 수 있다는 뜻이다. 그래서 거버넌스가 필요해진다.
다음: 07 — 보안 & 거버넌스 — depth·complexity·introspection·linting을 서버에서 강제하는 법.