07. 대안 — Stitching · Mesh · Hot Chocolate Fusion · WunderGraph

Federation은 Apollo의 답이지 유일한 답이 아니다. 회사 스택이 .NET이면 Hot Chocolate Fusion이 있고, REST/gRPC를 GraphQL로 자동 래핑하고 싶으면 Mesh가 있고, 컴파일 타임 plan을 원하면 WunderGraph가 있다.

이 문서는 대안의 지도를 그린다 — 언제 어떤 도구를 골라야 하는지.

한 줄 답

Apollo Federation은 Node/JVM 생태계 + 그래프 통합의 사실상 표준이지만, ① REST/gRPC/OpenAPI → GraphQL 자동 변환이 필요하면 GraphQL Mesh, ② .NET 생태계면 Hot Chocolate Fusion, ③ 컴파일 타임 query plan과 persisted query 강제면 WunderGraph, ④ 레거시 GraphQL 서버 통합이면 옛 schema stitching도 여전히 유효.

Why — 대안이 있는 이유

Federation의 전제 4가지:

1. 모든 service가 GraphQL 서버다.
2. Apollo SDL 디렉티브를 쓸 수 있다.
3. 런타임 query plan이 허용된다.
4. 팀이 명확히 분리되어 있다.

이 전제 중 하나라도 깨지면 대안이 필요하다.

How — 도구별 상세

1. GraphQL Mesh — REST/gRPC/OpenAPI 자동 변환

the-guild.dev/graphql/mesh

핵심: *기존 API(REST, gRPC, OpenAPI, SOAP, …)*를 자동으로 GraphQL 스키마로 변환하고 런타임 stitching으로 합친다.

# .meshrc.yaml
sources:
  - name: Stripe
    handler:
      openapi:
        source: https://raw.githubusercontent.com/stripe/openapi/master/openapi/spec3.json
 
  - name: GitHub
    handler:
      graphql:
        endpoint: https://api.github.com/graphql
 
  - name: InternalUsers
    handler:
      grpc:
        endpoint: users-svc:50051
        protoFilePath: ./protos/users.proto

→ Mesh가 자동으로 GraphQL SDL을 생성. 클라이언트는 Stripe + GitHub + 내부 gRPC를 한 그래프로 본다.

언제 쓰나:

• 회사에 대부분 REST 서비스가 있고 통합 그래프만 만들고 싶다 (마이그레이션 없이).
• 3rd party API (Stripe, GitHub)를 내 그래프에 끼우고 싶다.
• Hasura 등 다른 GraphQL 서버를 Apollo federation 없이 통합.

한계:

• 자동 생성된 schema는 그래프적 모양이 약함 — 그냥 REST를 GraphQL로 wrap한 모양.
• 런타임 stitching이라 latency overhead.
• Apollo Federation 호환 모드가 있긴 함 (Mesh를 federation subgraph로 사용 가능).

2. Hot Chocolate Fusion — .NET 생태계

chillicream.com/docs/hotchocolate/fusion

핵심: ChilliCream이 만든 .NET용 federation 구현. Apollo Federation spec과 호환되되 자체 API.

// Fusion Composer (.NET)
services.AddFusionGateway()
    .AddSubgraph("Product", new Uri("http://product:5000/graphql"))
    .AddSubgraph("Review", new Uri("http://review:5000/graphql"));

언제 쓰나:

• 회사 백엔드가 대부분 .NET이다.
• Apollo Router(Rust)를 운영팀이 낯설어함.
• .NET 디버깅·관측 도구와 통합 필요.

한계:

• Apollo Federation v2 spec과 부분 호환 (모든 디렉티브가 동작하진 않음).
• 커뮤니티가 Apollo만큼 크지 않음 — 문제 검색이 어려울 수 있음.
• Rust router만큼 빠르진 않음 (.NET runtime overhead).

3. WunderGraph — Compile-time plan + Persisted query

wundergraph.com

핵심: 컴파일 타임에 모든 operations의 query plan을 생성하고, 클라이언트는 persisted query만 호출. 런타임에는 plan 계산 비용 0.

// wundergraph.config.ts
const productPage = createOperation.query({
  input: z.object({ id: z.string() }),
  handler: async ({ input, graph }) => {
    // 빌드 타임에 plan이 미리 계산됨
    const product = await graph.product.findById(input.id);
    const reviews = await graph.review.findByProductId(input.id);
    return { product, reviews };
  },
});

→ 클라이언트는 *GET /api/productPage?id=p1*만 호출. WunderGraph가 컴파일 타임에 최적 plan을 만들어 둠.

언제 쓰나:

• Edge runtime (Cloudflare Workers 등)에 배포할 때 — plan 계산 cold start 비용이 부담.
• Persisted query를 강제하고 싶다 — 클라이언트가 임의 쿼리를 못 보내게.
• Type-safe SDK가 필요 — WunderGraph는 Operation별 TypeScript 타입을 자동 생성.

한계:

• 동적 쿼리 불가 — 모든 operation이 사전 등록되어야 함.
• 학습 곡선 — Apollo federation과 다른 추상화 모델.
• 상대적으로 작은 커뮤니티.

4. Schema Stitching (옛 방식) — 여전히 유효한 자리

the-guild.dev/graphql/stitching

GraphQL Tools의 stitching은 Apollo가 deprecate했지만 the-guild.dev가 계속 유지하고 있다.

언제 stitching이 여전히 옳은가:

stitching의 진화: the-guild의 Schema Stitching은 type merging, batching, transformers를 추가해 현대화됐다. 2017년의 stitching과는 다른 도구가 됐다.

5. 그 외

• Mercurius (Node.js, Fastify 기반) — Apollo Federation 호환의 경량 대안
• Hasura — PostgreSQL/MySQL → GraphQL 자동 생성. Mesh와 비슷한 자리지만 DB 중심
• PostGraphile — Hasura 비슷하지만 Postgres only
• Grafbase — 서버리스 GraphQL Federation (managed)

What — 결정 트리

질문 1) 모든 서비스가 GraphQL인가?
  ├─ Yes → 질문 2로
  └─ No → GraphQL Mesh 또는 BFF

질문 2) Apollo SDL 디렉티브 쓸 수 있나?
  ├─ Yes → 질문 3으로
  └─ No → Schema Stitching (외부 API 통합 등)

질문 3) 어느 생태계?
  ├─ Node/JVM → Apollo Federation v2 (default)
  ├─ .NET → Hot Chocolate Fusion
  └─ Edge/serverless → WunderGraph 검토

질문 4) 런타임 plan 비용 견딜 수 있나?
  ├─ Yes → Apollo Router
  └─ No → WunderGraph (compile-time)

질문 5) 정말 federation이 필요한가?
  ├─ 팀 < 10명 → No, monolith가 더 빠름
  ├─ 팀 < 50명 → 검토, modular schema도 옵션
  └─ 팀 > 50명 → Yes

What — 정량 비교

What-if — 잘못 고르면 일어나는 일

Case 1: 작은 회사가 Apollo Federation을 도입

• 5명 팀, 3개 서비스
• federation 도입 → infrastructure 복잡도 폭증: GraphOS 비용, router 운영, schema publishing pipeline.
• 결국 다 한 사람이 관리 → bus factor 1 → 그 사람 휴가 가면 마비.

교훈: federation은 조직 비용을 줄이려는 도구. 조직이 작으면 그 비용이 없으니 도입 비용만 남는다.

Case 2: REST 회사가 Mesh 도입하고 Federation 기대

• 모든 백엔드가 REST. Mesh로 자동 wrap.
• 클라이언트는 그래프 모양이 어색함 — 단순 REST wrapping이라 cross-resource 쿼리가 안 됨.
• 결국 cross-resource 쿼리를 위한 ad-hoc resolver를 작성 → 다시 모놀리식 BFF가 됨.

교훈: Mesh는 통합 표면이지 그래프 모델링 도구가 아니다. 진짜 그래프가 필요하면 각 서비스에 GraphQL 서버를 만들어야 한다.

Case 3: 동적 쿼리가 필수인데 WunderGraph 도입

• 클라이언트가 각 화면마다 다른 쿼리를 보내야 함 (e.g., admin tool)
• WunderGraph는 operation 사전 등록 필요 → 매번 컴파일하고 배포해야 함.
• Apollo Federation으로 갔어야 했다.

교훈: WunderGraph는 클라이언트 쿼리가 안정적일 때 효과. 동적 쿼리가 많으면 Apollo가 낫다.

Insight — 흥미로운 이야기

“GraphQL Mesh는 the-guild.dev의 Stitching의 후예”

the-guild.dev는 Apollo가 stitching을 deprecate한 뒤 그것을 자기 프로젝트로 가져와 Mesh로 재탄생시켰다. 즉, Apollo가 *“느려서 안 됨”*이라고 한 stitching이 — 3rd party API 통합이라는 다른 use case를 찾아 재생했다. 기술의 두 번째 생애를 보는 흥미로운 사례.

“WunderGraph의 operations.graphql은 persisted query의 federation 버전”

Apollo의 persisted query는 모놀리식 한 서버에만 적용. WunderGraph는 federation에 persisted query를 강제해 clients can’t send arbitrary queries를 보장. 보안 + 성능을 동시에 잡는 영리한 위치.

*“Hot Chocolate은 spec 호환이 아니라 철학 호환”

ChilliCream은 Apollo의 spec을 다 따르지 않는다. 대신 .NET 친화적인 자기 SDL 확장을 둔다. 일부는 Apollo의 federation 사상을 .NET 식으로 재해석한 결과. 즉, federation은 spec 한 종이가 아니라 디자인 패턴에 가깝다.

“Netflix는 자기 구현을 고집한다”

Netflix DGS (Domain Graph Service)는 Apollo Federation spec 호환이지만 gateway 구현은 직접 (Java). 이유: 그들의 trace 시스템(Mantis)·feature flag(Lemur)·CI에 깊이 통합되어야 했음. spec이 열려 있어서 가능한 결정. open spec이 조직별 customization을 가능하게 한다는 사례.

“Federation은 기술이 아니라 movement”

Apollo가 federation spec을 공짜로 풀고 다른 구현체를 환영한 이유: federation을 기술이 아니라 업계 표준으로 만들어야 했다. 기술은 카피되지만 표준은 카피되지 않는다. 결과: federation이 Apollo의 영역이지만 Apollo만의 것은 아닌 묘한 위치.

요약 + Mermaid

Apollo Federation v2는 Node/JVM + 그래프 통합의 default다. 하지만 전제가 깨지면 대안이 있다 — Mesh(REST 통합), Hot Chocolate(.NET), WunderGraph(compile-time plan), Stitching(통제 밖 API). 가장 흔한 실수는 조직이 작은데 federation 도입 — 조직 비용을 줄이는 도구인데 그 비용이 없는 곳에 쓰면 도입 비용만 남는다.