💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 2026년, GraphQL은 죽었나 살았나

2023년 GitHub은 REST로 회귀했고, 2024년에는 "GraphQL is dead"라는 블로그 글이 매달 한 편씩 올라왔다. 그런데 2026년 현재 GraphQL은 죽지 않았다. 죽기는커녕, Apollo가 인수한 Stellate, WunderGraph의 Cosmo Router, Inigo, Grafbase 같은 게이트웨이 시장이 새로 생겨났고, Mercari·Coupang·LINE Yahoo·Netflix·GitHub 내부 등 거대 조직은 여전히 Federation으로 모놀리식 그래프를 분해하고 있다.

> **GraphQL은 죽지 않았다. 다만, "쉬운 API"라는 자리에서 "거대한 분산 그래프를 조립하는 인프라"라는 자리로 이사 갔을 뿐이다.** 작은 팀에는 tRPC가 더 자연스럽다. 그러나 수십~수백 개 마이크로서비스를 하나의 그래프로 표현해야 하는 조직에는 여전히 GraphQL이 정답이다.

이 글은 2026년 GraphQL 생태계의 모든 주요 플레이어를 한 번에 본다. 게이트웨이 · DB-퍼스트 · 서버 프레임워크 · 클라이언트 · 도구 · 표준 · 대안 기술. 그리고 한국 · 일본 기업의 실제 도입 사례까지.

이 글에서 다루는 것:

1. 2026년 GraphQL 지도 — 누가 만들고 누가 쓰나

2. GraphQL 스펙 2024-25와 Composite Schemas WG

3. "GraphQL은 죽었나" 논쟁 정리

4. Federation v2 vs Schema Stitching vs Module Federation

5. Apollo Router — Rust로 다시 쓴 Federation 2 게이트웨이

6. Apollo Server 4와 Apollo Client 3.11+

7. GraphQL Yoga 5 — The Guild의 배터리 포함 서버

8. graphql-mesh와 GraphQL Hive

9. Hasura v2와 PostGraphile 5 — DB-퍼스트 진영

10. Supabase GraphQL과 WunderGraph

11. Stellate · Inigo · Cosmo · Grafbase — 게이트웨이 전쟁

12. Relay 18 · urql 4 · Apollo Client 3.11 클라이언트 비교

13. GraphQL Code Generator와 타입 안전성

14. Node.js 서버 — Mercurius · Pothos · NestJS · TypeGraphQL

15. Python — Strawberry · Ariadne · Graphene

16. Go — gqlgen · graphql-go

17. Rust — async-graphql · juniper

18. JVM · .NET · Ruby · Elixir · PHP · Swift

19. Subscriptions와 graphql-ws

20. N+1 문제와 DataLoader 패턴

21. Persisted Queries와 신뢰 가능 쿼리

22. GraphQL vs REST vs tRPC vs gRPC

23. 한국 · 일본 기업의 GraphQL 도입

24. 참고 자료

1장 · 2026년 GraphQL 지도

큰 그림부터. GraphQL을 둘러싼 도구는 크게 다섯 진영이다.

**게이트웨이 진영** — 여러 서브그래프를 하나의 그래프로 합치는 라우터. Apollo Router (Rust, Apollo), Cosmo Router (WunderGraph), Inigo, Stellate (Apollo 자회사), Grafbase가 이 시장에서 경쟁한다. Apollo Router는 Federation 2의 사실상 표준이지만 라이선스가 Elastic v2로 바뀐 뒤로 Cosmo Router가 Apache-2.0 대안으로 인기를 얻고 있다.

**서버 프레임워크 진영** — 단일 서비스에서 GraphQL 스키마를 정의하고 리졸버를 짠다. Node.js의 Apollo Server 4, GraphQL Yoga 5, Mercurius, NestJS GraphQL, Python의 Strawberry, Ariadne, Go의 gqlgen, .NET의 Hot Chocolate, Ruby의 graphql-ruby, Elixir의 Absinthe.

**DB-퍼스트 진영** — 데이터베이스 스키마에서 GraphQL 스키마를 자동 생성한다. Hasura v2, PostGraphile 5 (Benjie Gillam), Supabase GraphQL. CRUD 비중이 높은 서비스에서 90% 코드를 줄여 준다.

**클라이언트 진영** — 브라우저·모바일에서 GraphQL을 호출한다. Apollo Client 3.11+ (시장 점유 1위), Relay 18 (Meta), urql 4 (Formidable·이제 The Guild), graphql-request + TanStack Query (DIY), Houdini (SvelteKit). Apollo iOS · Apollo Kotlin이 모바일 진영.

**표준·툴 진영** — 사양과 거버넌스. GraphQL Foundation 산하의 GraphQL WG와 Composite Schemas WG. The Guild는 Hive · Mesh · Tools · YogaServer 같은 오픈소스 도구 묶음. Apollo는 Stellate를 인수해 엣지 캐시 시장을 잡았다.

이 다섯 진영이 매년 위치를 바꾼다는 게 GraphQL 생태계를 따라가기 어렵게 만드는 주된 이유다.

2장 · GraphQL 스펙 2024-25와 Composite Schemas WG

GraphQL 스펙 자체는 2024-25년 사이에 비교적 보수적으로 진화했다. 2024년 10월의 GraphQL 2024 후보안에서 다음이 정리되었다.

- `@oneOf` 입력 객체 — 클라이언트가 정확히 하나의 필드만 보내야 하는 union-유사 입력. 오랫동안 비표준이었던 패턴이 정식 디렉티브가 되었다.

- 클라이언트 제어 nullability — `field!`로 클라이언트가 명시적으로 non-null을 강제하고, 서버가 null을 보내면 클라이언트가 그 영역을 nullable 부모로 전파한다.

- defer / stream — 부분 결과를 스트리밍하는 응답. 무거운 쿼리에서 first-contentful-paint를 줄인다. 2024-25년에 클라이언트·서버 양쪽에서 GA로 정착했다.

- subgraph composition — GraphQL Foundation 산하의 Composite Schemas WG가 2025년에 만들어졌다. Apollo Federation 2의 표준화를 시도한다. WunderGraph · ChilliCream (Hot Chocolate) · The Guild · Apollo가 모두 참여한다.

> **Composite Schemas WG의 의미**: Federation 2가 더 이상 Apollo만의 사양이 아니라는 선언이다. Cosmo Router가 Federation 2를 호환한다고 주장할 수 있는 근거가 여기 있다. 2026년 현재 표준 작업은 1.0을 향해 가는 중이며, 2027년 정식 채택이 목표다.

3장 · "GraphQL은 죽었나" 논쟁

2023-24년 사이에 다음 사건이 겹쳤다.

- GitHub이 일부 API를 REST로 회귀했다 (정확히는 GraphQL을 제거한 게 아니라 REST와 병행). 이유: 모바일 클라이언트의 캐시 효율성, 외부 통합사의 학습 곡선.

- Shopify는 Storefront API를 REST에서 GraphQL로 통합했지만 동시에 "단순 사용자"용 admin REST도 유지한다고 발표했다.

- 페이스북(Meta) 내부에서 React Server Components가 자리 잡으면서 "Relay + GraphQL"의 일부를 RSC + 서버 액션이 대체한다는 분석이 나왔다.

- tRPC가 Node.js 풀스택 진영에서 빠르게 자리를 잡으며 "GraphQL 없이도 타입 안전한 API"의 대안으로 떠올랐다.

이 모든 흐름이 합쳐져서 "GraphQL은 한물 갔다"는 인상을 만들어 냈다. 그러나 실상은 다르다.

- **엔터프라이즈에서는 여전히 성장 중이다.** Netflix의 DGS, Mercari의 Apollo Federation, GitHub 내부의 단일 그래프, Coupang의 ELK 프런트, LINE Yahoo의 Hasura 도입 — 모두 2024-26년에 확장되었다.

- **Federation 2가 사실상의 인터페이스가 되었다.** 작은 팀이 직접 쓰지 않더라도 SaaS의 API 게이트웨이는 Apollo Router로 짜는 경우가 많다.

- **GraphQL은 "쉬운 API"가 아니라 "분산 그래프 합성 인프라"라는 자리로 이사 갔다.** 이 위치에서는 REST·tRPC·gRPC가 GraphQL을 대체하지 않는다.

> **결론**: GraphQL은 죽지 않았다. 다만 "어디서나 쓰는 기본 옵션"의 자리에서 내려와, "특정 문제(분산 그래프 합성)를 푸는 도구"의 자리로 이동했다. 2026년 GraphQL을 새로 도입한다면 그 자리를 먼저 확인해야 한다.

4장 · Federation v2 vs Schema Stitching vs Module Federation

여러 서브그래프를 하나로 합치는 세 가지 접근법이 있다.

**Schema Stitching (deprecated)** — Apollo Server 2 시절의 옛 방법. 각 서비스의 스키마를 게이트웨이에서 합치고, 충돌은 게이트웨이가 직접 리졸버를 짜서 푼다. 운영하기 어려워서 Federation 1로 대체되었고, Federation 2가 나오면서 사실상 사라졌다. 단, 일부 The Guild 도구 (graphql-tools의 stitching 모듈)는 2026년에도 살아있다.

**Apollo Federation v1** — 2019년 발표. `@key`, `@external`, `@requires`, `@provides` 디렉티브로 서브그래프를 정의한다. 게이트웨이가 쿼리 플랜을 만들어 각 서브그래프에 분기한다.

**Apollo Federation v2** — 2022년 GA. v1의 한계를 정리했다. 공유 타입(`@shareable`), 인터페이스 객체(`@interfaceObject`), 진입점 분리(`@override`), 입력 객체 공유 등 v1에서 어려웠던 패턴을 표준화. 2026년 현재 사실상 표준.

**Module Federation (Webpack/Rspack)** — 이름이 비슷하지만 완전히 다른 개념. 프런트엔드 마이크로프런트엔드 번들 합성이다. GraphQL Federation과 혼동하지 말 것.

> Apollo Federation 2를 도입할 때 가장 큰 결정은 "서브그래프를 어떻게 나누나"다. 도메인 경계(Domain Boundary) 기준이 정답이며, 데이터 소스 기준이 아니다. Mercari의 사례에서도 처음에는 DB 기준으로 나눴다가 도메인 기준으로 재구성했다.

5장 · Apollo Router — Rust로 다시 쓴 Federation 2 게이트웨이

Apollo의 게이트웨이는 두 세대가 있다.

- **Apollo Gateway (Node.js)** — 2019년 출시. JavaScript로 짜인 Federation 게이트웨이. 단일 인스턴스 성능이 1k RPS 안팎이라는 한계가 있었다.

- **Apollo Router (Rust)** — 2022년 GA. Apollo Gateway를 Rust로 완전히 다시 짰다. 같은 하드웨어에서 10배 이상 처리량, p99 레이턴시도 절반 이하로 떨어졌다.

Apollo Router 1.x의 핵심 기능.

- 쿼리 플래너 — 들어온 쿼리를 어떤 서브그래프에 어떻게 분기할지 그래프로 계산.

- Rhai · Coprocessor — 게이트웨이 안에서 커스텀 로직 (인증, 변환, 로깅). Rhai는 임베디드 스크립트, Coprocessor는 외부 프로세스 RPC.

- Telemetry — OpenTelemetry 1급. 트레이스 · 메트릭 · 로그가 모두 OTel.

- Query Planner Cache — 동일 쿼리의 플랜을 캐시.

- Persisted Queries — 클라이언트가 미리 등록한 쿼리 해시만 받는다 (보안).

**라이선스 이슈**: 2024년 Apollo Router 1.x는 Elastic License v2로 바뀌었다. SaaS로 재판매가 금지되고, Apollo가 직접 호스팅하는 GraphOS의 경쟁자 사용을 제한한다. 이 조건이 부담스러운 조직은 Cosmo Router · Hot Chocolate Fusion · The Guild의 Hive Router 같은 Apache-2.0 대안을 찾기 시작했다.

router.yaml — Apollo Router 설정 예시

supergraph:

listen: 0.0.0.0:4000

introspection: false

telemetry:

metrics:

prometheus:

enabled: true

traffic_shaping:

router:

timeout: 30s

all:

deduplicate_query: true

6장 · Apollo Server 4와 Apollo Client 3.11+

Apollo의 다른 두 축.

**Apollo Server 4** (2023년 GA). 단일 그래프 서버 (Federation 서브그래프로도 쓸 수 있다). v3에서 v4로 가면서 Express·Fastify·Lambda·Cloudflare Workers 어댑터가 분리됐다. 코어는 transport-agnostic.

// Apollo Server 4 minimal

const server = new ApolloServer({

typeDefs: `

type Query { hello: String }

resolvers: {

Query: { hello: () => 'world' },

})

const { url } = await startStandaloneServer(server, { listen: { port: 4000 } })

console.log(`server ready at ${url}`)

**Apollo Client 3.11+** (2024년). 시장 점유 1위 클라이언트. React · Vue · Angular · Svelte · 일반 JS에서 모두 쓴다. 핵심 기능.

- Normalized Cache — 응답을 정규화된 그래프로 저장. 같은 객체가 여러 쿼리에 등장하면 한 번만 저장.

- Reactive — 캐시가 바뀌면 구독하는 컴포넌트가 자동 리렌더.

- Optimistic UI — 서버 응답 전에 UI를 먼저 갱신, 실패 시 롤백.

- Pagination · Fragments · @client local resolver.

Apollo Client는 강력하지만 번들 크기가 크다(라이브러리만 35-40KB gzip). 작은 앱에는 부담이 된다. 그래서 urql · graphql-request의 자리가 생긴다.

7장 · GraphQL Yoga 5 — The Guild의 배터리 포함 서버

The Guild이 만든 Node·Bun·Deno 모두에서 동작하는 GraphQL 서버. 2023년 GraphQL Yoga 4로 큰 재작성을 거쳤고, 2024-25년 사이에 v5로 정착했다.

핵심 가치.

- **Web Standards** — Fetch API 기반. Cloudflare Workers · Deno · Bun · Vercel Edge에서 그대로 돈다.

- **Envelop 플러그인** — 인증 · 캐시 · 트레이싱 · 코스트 분석. The Guild의 다른 플러그인을 그대로 끼운다.

- **Subscriptions over SSE** — WebSocket이 부담스러운 환경에서 Server-Sent Events로 구독을 제공.

- **Federation 서브그래프** — Apollo Federation 2의 서브그래프로 그대로 쓸 수 있다.

Apollo Server 4와의 차이는 "배터리 포함" 정도다. Yoga는 즉시 동작하는 기본값이 많고, Apollo Server는 더 미니멀하다.

// GraphQL Yoga 5

const yoga = createYoga({

schema: createSchema({

typeDefs: 'type Query { hello: String }',

resolvers: { Query: { hello: () => 'yoga' } },

}),

})

createServer(yoga).listen(4000)

8장 · graphql-mesh와 GraphQL Hive

The Guild의 다른 두 큰 도구.

**graphql-mesh** — REST · gRPC · SOAP · OpenAPI · Postgres · MongoDB · Federation을 모두 GraphQL로 합쳐 주는 게이트웨이. 즉, 백엔드가 GraphQL이 아니어도 GraphQL 게이트웨이를 만들 수 있다. 마이그레이션 도구로도 자주 쓰인다.

**GraphQL Hive** — 스키마 레지스트리 + 모니터링. 어떤 클라이언트가 어떤 필드를 얼마나 자주 쓰는지 텔레메트리를 모은다. Apollo의 GraphOS Studio와 같은 자리에 있는 오픈소스 대안. 자체 호스팅 가능.

Hive와 Apollo Studio의 가장 큰 차이는 라이선스다. Hive는 MIT 오픈소스, Studio는 SaaS만. 자체 호스팅이 필수인 조직(공공기관·금융·헬스케어)은 Hive로 간다.

9장 · Hasura v2와 PostGraphile 5 — DB-퍼스트 진영

"DB 스키마에서 GraphQL 스키마를 자동 생성한다"는 패턴.

**Hasura v2** — Haskell로 짠 가장 유명한 DB-퍼스트 게이트웨이. PostgreSQL · MySQL · MS SQL Server · BigQuery · Snowflake 등을 모두 지원한다. 권한(roles, permission rules), Actions(사용자 정의 비즈니스 로직), Remote Schemas(다른 GraphQL 서비스 머지), Events(DB 변경 → 웹훅) 등이 1급 시민. 라이선스는 Apache-2.0 (오픈소스).

**PostGraphile 5** (Benjie Gillam) — Postgres 전용. PostGraphile은 Postgres의 인트로스펙션 정보를 깊이 활용한다. Smart Tags · 커스텀 plpgsql 함수 → GraphQL 필드 매핑. 2024-25년 사이에 v5 (Grafast 기반)로 큰 재작성. Apollo의 N+1 문제를 plan-based 실행으로 푸는 게 특징.

> **언제 DB-퍼스트가 맞나**: 비즈니스 로직보다 CRUD가 더 많은 서비스, 어드민 도구, 내부 도구, MVP 단계. 비즈니스 로직이 두꺼워지면 결국 코드를 직접 짜야 하고, 그때부터는 Apollo Server나 Yoga로 마이그레이션하게 된다.

10장 · Supabase GraphQL과 WunderGraph

**Supabase GraphQL** — Supabase의 Postgres 위에 자동으로 GraphQL 엔드포인트를 만들어 준다. 내부적으로 `pg_graphql` 확장을 쓴다. 이 확장은 Postgres 내부에서 SQL을 실행해 GraphQL을 처리하므로 N+1 문제가 없다. 단점은 권한 모델이 Postgres RLS에 종속된다는 것.

**WunderGraph** — 처음에는 Federation 게이트웨이로 시작했다가 지금은 풀스택 BaaS에 가까워졌다. Cosmo Router · Cosmo Studio · Cosmo CDN으로 구성. RPC-스타일 API와 GraphQL을 동시에 노출한다는 게 특징. "Operations" 개념으로 클라이언트가 GraphQL 쿼리를 직접 보내지 않고 등록된 작업만 호출하게 한다.

WunderGraph operations 패턴 — 클라이언트가 서버에 미리 등록

query Users {

users {

name

}

11장 · Stellate · Inigo · Cosmo · Grafbase — 게이트웨이 전쟁

2024-26년 사이에 GraphQL 게이트웨이 시장이 본격적으로 분화했다.

**Stellate** (옛 GraphCDN) — Apollo가 2023년 인수. CDN 엣지에서 GraphQL 응답을 캐시한다. POST 요청은 일반적으로 CDN 캐시 대상이 아니지만, Stellate는 쿼리 해시 기반으로 캐시한다.

**Inigo** — 게이트웨이 + 보안 + 가시성을 묶은 SaaS. Apollo Router의 대안. Rust로 짜였다.

**Cosmo Router** (WunderGraph) — Apache-2.0 라이선스. Federation 2 호환. Apollo Router의 라이선스 부담을 피하려는 조직이 선택한다. Cosmo Studio (대시보드) · CDN과 함께 패키지화.

**Grafbase** — 엣지 GraphQL 플랫폼. 자체 게이트웨이 + 스키마 레지스트리 + 엣지 캐시. Cloudflare Workers 위에서 동작.

**Hot Chocolate Fusion** — ChilliCream(.NET 진영)이 만든 Federation 호환 게이트웨이. .NET 진영의 Apollo Router.

**Hive Router** — The Guild이 새로 만든 Apache-2.0 게이트웨이. GraphQL Hive와 통합.

> 게이트웨이 시장의 결정 기준: 라이선스 (Apache vs Elastic), Federation 호환성 (대부분 Federation 2), 엣지 지원 (Cloudflare/Vercel/Fastly), 가시성 (Hive vs Studio).

12장 · Relay 18 · urql 4 · Apollo Client 3.11 클라이언트 비교

세 클라이언트의 결정적 차이.

**Apollo Client 3.11** — 시장 점유 1위. 모든 기능. 정규화 캐시. 단점은 번들 크기 (35-40KB gzip).

**Relay 18** (Meta) — Facebook 내부에서 쓰는 클라이언트. Fragment-driven. 컴포넌트가 자기 필요한 필드를 fragment로 선언하고, Relay는 그걸 모아 최적의 쿼리를 만든다. Compiler가 컴파일 타임에 쿼리를 정규화하고 최적화한다. 학습 곡선이 가파른 대신 대규모 앱에서 가장 효율적. Meta · Github · Stripe 일부 페이지가 사용.

**urql 4** (Formidable → The Guild) — 미니멀. 기본 번들 5-10KB gzip. Exchange 시스템으로 정규화 캐시 · 인증 · 재시도를 끼울 수 있다. 작은 앱부터 큰 앱까지 점진적 확장.

**graphql-request + TanStack Query** — DIY. graphql-request는 fetch 기반의 최소 클라이언트. TanStack Query가 캐시 · 재시도 · 구독을 담당. 가장 가볍지만 GraphQL 특유의 정규화 캐시 같은 기능은 직접 짜야 한다.

**Houdini** — SvelteKit · Kit · Vite를 위한 GraphQL 클라이언트. 컴파일 타임 코드 생성으로 런타임을 최소화.

| --- | --- | --- | --- | --- |

| Apollo Client | 35-40KB | 1급 | 중 | 일반적인 React/Vue 앱 |

| graphql-request | 1-2KB | 없음 | 낮음 | 단순 fetch 패턴 |

| Houdini | 컴파일 | 1급 | 중 | SvelteKit 앱 |

13장 · GraphQL Code Generator와 타입 안전성

GraphQL 자체는 타입 시스템이 있지만, TypeScript와 자동으로 이어지진 않는다. 이 다리를 놓는 도구가 GraphQL Code Generator (The Guild).

- 서버 스키마에서 TypeScript 타입을 생성.

- 클라이언트 쿼리에서 호출 함수의 인자·결과 타입을 생성.

- React Hook · Vue Composable · Svelte Store 생성.

codegen.yml

schema: ./schema.graphql

documents: ./src/**/*.graphql

generates:

src/gql/:

preset: client

plugins: []

`@graphql-codegen/client-preset`을 쓰면 `graphql()` 태그 함수가 컴파일 타임에 쿼리의 타입을 추론한다. 이 방식으로 Apollo Client · urql · graphql-request 모두에서 타입 안전한 쿼리를 짤 수 있다.

14장 · Node.js 서버 — Mercurius · Pothos · NestJS · TypeGraphQL

Node.js 진영에 서버 옵션이 너무 많다. 정리하면.

**graphql-js** — GraphQL의 공식 자바스크립트 구현. 모든 다른 라이브러리의 기반. 직접 쓰기에는 너무 저수준.

**Apollo Server 4** — 가장 보편. transport-agnostic.

**GraphQL Yoga 5** (The Guild) — Web Standards · 배터리 포함.

**Mercurius** — Fastify 진영. 같은 코드를 Apollo Server보다 빠르게 돌린다. Fastify를 이미 쓰는 팀에 자연스럽다.

**Pothos** (옛 GiraphQL) — Code-first. TypeScript 우선. 스키마를 TS 코드로 정의하면 자동으로 SDL이 생성된다. Type 추론이 매우 강해서 IDE 자동완성이 거의 완벽하다. 2024-26년에 빠르게 자리를 잡았다.

**TypeGraphQL** — 데코레이터 기반. NestJS 스타일 클래스 + 데코레이터로 스키마를 정의. 2024년 v2로 큰 재작성.

**NestJS GraphQL** — NestJS 프레임워크의 GraphQL 모듈. Apollo Server 또는 Mercurius 위에서 동작. 엔터프라이즈 Node 진영에서 사실상 표준.

// Pothos minimal

const builder = new SchemaBuilder({})

builder.queryType({

fields: (t) => ({

hello: t.string({ resolve: () => 'world' }),

}),

})

export const schema = builder.toSchema()

15장 · Python — Strawberry · Ariadne · Graphene

파이썬 진영의 세 플레이어.

**Strawberry GraphQL** — 데이터클래스 + 데코레이터 스타일. 가장 모던하고 2024-26년 사이에 가장 빠르게 점유율을 늘렸다. FastAPI · Django · Flask 통합이 모두 1급. Federation 2 지원. Apollo Studio · Hive 연동.

Strawberry minimal

@strawberry.type

class Query:

@strawberry.field

def hello(self) -> str:

return "world"

schema = strawberry.Schema(query=Query)

**Ariadne** — Schema-first. SDL을 직접 짜고 리졸버를 함수로 등록. Django · FastAPI 통합. Strawberry에 비해 코드가 조금 더 명시적이다.

**Graphene** — 오래된 라이브러리. 파이썬 진영에 GraphQL을 처음 가져왔다. Django · Flask · SQLAlchemy 통합이 풍부하지만 v3 이후 업데이트가 느려졌다. 신규 프로젝트는 Strawberry로 가는 경우가 많다.

16장 · Go — gqlgen · graphql-go

Go 진영은 비교적 정리되어 있다.

**gqlgen** (99designs → 커뮤니티). Schema-first · 코드 생성. SDL을 짜면 gqlgen이 Go 구조체와 리졸버 인터페이스를 생성. 컴파일 타임에 타입 안전. 2026년 현재 Go 진영의 사실상 표준.

// gqlgen 생성된 리졸버 구조

func (r *queryResolver) Hello(ctx context.Context) (string, error) {

return "world", nil

}

**graphql-go** (graphql-go/graphql) — 더 오래된 라이브러리. Schema를 Go 코드로 정의 (code-first). 신규 프로젝트는 거의 gqlgen로 간다.

**gophers/graphql-go** — 또 다른 옵션. SDL + 리졸버 함수 매칭이 간단해서 작은 프로젝트에 인기.

17장 · Rust — async-graphql · juniper

Rust 진영도 두 플레이어로 정리된다.

**async-graphql 7** — 가장 활발한 Rust GraphQL 서버. 데이터로더 · 구독 · Federation 2 · Apollo Studio 트레이싱 모두 지원. Actix · Axum · Warp · Poem 등 거의 모든 Rust 웹 프레임워크와 통합.

// async-graphql minimal

use async_graphql::{Object, Schema, EmptyMutation, EmptySubscription};

struct Query;

#[Object]

impl Query {

async fn hello(&self) -> &'static str { "world" }

}

let schema = Schema::new(Query, EmptyMutation, EmptySubscription);

**juniper** — 더 오래된 Rust 라이브러리. async-graphql이 나오기 전엔 가장 인기였다. 지금도 유지보수 중이지만 신규 프로젝트는 async-graphql로 가는 추세.

18장 · JVM · .NET · Ruby · Elixir · PHP · Swift

다른 언어 진영을 한 번에.

**JVM** — graphql-java (저수준 구현), DGS Framework (Netflix가 만든 Spring 통합), Sangria (Scala). Netflix가 DGS를 오픈소스로 풀면서 JVM 진영의 사실상 표준이 됐다.

**.NET** — Hot Chocolate 13 (ChilliCream). 가장 인기. Code-first. Federation 2 (Hot Chocolate Fusion). GraphQL.NET이 더 오래되었지만 Hot Chocolate가 모던 표준.

// Hot Chocolate minimal

public class Query {

public string Hello() => "world";

}

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddGraphQLServer().AddQueryType<Query>();

var app = builder.Build();

app.MapGraphQL();

app.Run();

**Ruby** — graphql-ruby. GitHub이 만든 라이브러리로 Ruby 진영의 사실상 표준. Shopify · GitHub 자체가 깊이 쓴다.

**Elixir** — Absinthe. Phoenix 통합. 함수형 스타일의 깔끔한 schema-first. Subscription을 Phoenix Channels 위에서 자연스럽게 돌린다.

**PHP** — Lighthouse (Laravel 통합). webonyx/graphql-php (저수준). GraphQLite (Symfony · Laravel · Slim 모두 호환).

**Swift / Apple** — Apollo iOS (Apollo의 공식 iOS 클라이언트). graphql-swift는 거의 죽었다. iOS는 사실상 Apollo iOS가 유일한 선택지.

19장 · Subscriptions와 graphql-ws

GraphQL 구독을 전송할 방법.

**graphql-ws 프로토콜** — The Guild이 표준화한 새로운 WebSocket 프로토콜. 옛 Apollo의 `subscriptions-transport-ws`를 대체. 2026년 현재 사실상 표준.

**SSE (Server-Sent Events)** — GraphQL Yoga와 The Guild이 밀고 있는 대안. WebSocket이 부담스러운 환경(서버리스 · 엣지 · 방화벽 뒤)에서 자연스럽다. HTTP/2 기반.

**HTTP multipart** — defer · stream의 전송 메커니즘.

// graphql-ws 메시지 흐름 (개념)

client -> connection_init

server -> connection_ack

client -> subscribe (id, query, variables)

server -> next (id, payload) (반복)

server -> complete (id)

> **추천**: 신규 프로젝트는 graphql-ws 프로토콜로 가라. Apollo의 옛 프로토콜은 deprecated. SSE는 서버리스·엣지가 우선이라면 매력적인 대안.

20장 · N+1 문제와 DataLoader 패턴

GraphQL 서버의 가장 흔한 함정.

이 쿼리 한 줄이 잘못 짜인 리졸버에서는 수백 번의 DB 호출이 된다

query {

posts {

author { name }

}

`posts`가 100개라면 `author`를 가져오는 쿼리가 100번 별도로 실행된다. 이게 N+1 문제다.

**DataLoader 패턴** (Facebook, 2016). 같은 틱(tick)에 들어온 ID들을 배치로 모아 한 번에 DB 호출. 결과를 ID 순서로 다시 분배.

// DataLoader minimal

const userLoader = new DataLoader(async (ids) => {

const users = await db.user.findMany({ where: { id: { in: ids } } })

return ids.map((id) => users.find((u) => u.id === id))

})

// 리졸버에서

const author = await userLoader.load(post.authorId)

이 패턴이 표준이 된 이유는 단순하다 — 잘 동작한다. 거의 모든 GraphQL 서버 프레임워크가 DataLoader를 1급으로 지원한다 (async-graphql · gqlgen · Strawberry · Hot Chocolate 모두).

PostGraphile 5의 Grafast는 다른 접근법을 쓴다. plan-based execution — 쿼리를 받자마자 실행 계획을 만들고, DataLoader 없이도 N+1을 회피한다. 이 접근이 더 깔끔하지만 구현 복잡도가 매우 높다.

21장 · Persisted Queries와 신뢰 가능 쿼리

GraphQL의 보안 모델은 까다롭다. 클라이언트가 어떤 쿼리든 보낼 수 있으므로, 악의적인 클라이언트가 무거운 쿼리로 서버를 고갈시킬 수 있다.

**Automatic Persisted Queries (APQ)** — 클라이언트가 쿼리 해시만 보내고, 서버가 모르면 그때 쿼리를 받는다. 캐시 효율과 페이로드 감소가 목적. 보안 효과는 약하다.

**Trusted Documents / Persisted Operations** — 클라이언트가 서버에 미리 등록한 쿼리만 실행 가능. 외부 클라이언트(공개 API)에는 부적합하지만 모바일·웹 같은 신뢰 클라이언트에는 가장 강력한 보안 모델. WunderGraph의 Operations · Relay의 persisted queries · Apollo의 Trusted Documents가 모두 같은 개념.

**Query Complexity / Depth Limit** — 쿼리의 비용을 미리 계산해서 한계를 넘으면 거부. graphql-shield · graphql-cost-analysis · Apollo Router의 Limits 플러그인.

// 깊이 제한 예시 (graphql-depth-limit)

server.use({ validationRules: [depthLimit(10)] })

22장 · GraphQL vs REST vs tRPC vs gRPC

2026년의 큰 그림.

| --- | --- | --- | --- | --- | --- |

> **추천 분야**:

> - 공개 API · 외부 통합 → REST + OpenAPI

> - 내부 풀스택 TS 앱 → tRPC

> - 모바일 클라이언트가 자주 다른 데이터 모양을 요구 → GraphQL

> - 마이크로서비스 간 → gRPC + grpc-web 또는 Connect (Buf)

> - 수십~수백 서비스를 단일 그래프로 → GraphQL Federation 2

GraphQL이 모든 자리에 맞지 않는다는 게 2026년의 합의다. 그러나 "분산 그래프 합성"이 필요한 자리에서는 여전히 GraphQL이 유일한 선택지에 가깝다.

23장 · 한국 · 일본 기업의 GraphQL 도입

**한국**

- **Coupang** — 일부 프런트 페이지 (특히 ELK 검색 결과 페이지)에서 GraphQL 게이트웨이를 운영. 모바일 앱이 다양한 데이터 모양을 요구하는 자리에서 자연스럽게 도입됨.

- **Toss** — 일부 내부 서비스에서 Apollo Federation으로 마이크로서비스를 합치는 사례. 자체 게이트웨이를 운영.

- **NCsoft** — 내부 인벤토리 · 게임 데이터 관리에 GraphQL을 도입. gqlgen 기반.

- **카카오** — 일부 서비스 (특히 광고·결제)에서 GraphQL 사용. 내부 도구·어드민 비중이 높음.

- **네이버 클로바** — 일부 AI 도구에서 GraphQL을 RAG 데이터 그래프로 활용.

**일본**

- **Mercari** — Apollo Federation 2의 본격 도입자. 수십 개 서브그래프로 마이크로서비스를 분해. 컨퍼런스에서도 자주 발표.

- **LINE Yahoo** — Hasura를 내부 도구·어드민에 광범위하게 도입. Postgres 기반 사내 도구의 90%가 Hasura 위에서 동작.

- **CyberAgent** — gqlgen 기반의 Go 마이크로서비스. 광고·게임 백엔드에 사용.

- **DeNA** — graphql-ruby와 Rails 기반의 일부 모바일 게임 백엔드.

- **Money Forward** — 회계 · 결제 도메인에서 Apollo Federation 도입을 발표 (2024).

> **공통 패턴**: 한국·일본 기업 모두 "처음에는 단일 그래프로 시작 → 비즈니스가 커지면 Federation으로 분해"라는 경로를 밟는다. 처음부터 Federation으로 가는 사례는 드물다.

24장 · 참고 자료

**스펙·표준**

- GraphQL 스펙: https://spec.graphql.org/

- GraphQL Foundation: https://graphql.org/foundation/

- Composite Schemas WG: https://github.com/graphql/composite-schemas-wg

- Federation v2 사양: https://www.apollographql.com/docs/federation/

**Apollo**

- Apollo Router: https://www.apollographql.com/docs/router/

- Apollo Server 4: https://www.apollographql.com/docs/apollo-server/

- Apollo Client: https://www.apollographql.com/docs/react/

- Stellate (옛 GraphCDN): https://stellate.co/

**The Guild**

- GraphQL Yoga: https://the-guild.dev/graphql/yoga-server

- GraphQL Hive: https://the-guild.dev/graphql/hive

- graphql-mesh: https://the-guild.dev/graphql/mesh

- GraphQL Code Generator: https://the-guild.dev/graphql/codegen

- graphql-ws: https://github.com/enisdenjo/graphql-ws

**DB-퍼스트**

- Hasura: https://hasura.io/

- PostGraphile 5: https://postgraphile.org/

- Supabase GraphQL: https://supabase.com/docs/guides/graphql

**WunderGraph · Cosmo**

- WunderGraph: https://wundergraph.com/

- Cosmo Router: https://cosmo-docs.wundergraph.com/

**서버 프레임워크**

- Strawberry GraphQL: https://strawberry.rocks/

- gqlgen: https://gqlgen.com/

- async-graphql: https://async-graphql.github.io/

- Hot Chocolate: https://chillicream.com/docs/hotchocolate/

- DGS (Netflix): https://netflix.github.io/dgs/

- Absinthe: https://hexdocs.pm/absinthe/

- graphql-ruby: https://graphql-ruby.org/

- Pothos: https://pothos-graphql.dev/

**클라이언트**

- Relay: https://relay.dev/

- urql: https://commerce.nearform.com/open-source/urql/

- Houdini: https://houdinigraphql.com/

**도구·패턴**

- DataLoader: https://github.com/graphql/dataloader

- graphql-shield: https://github.com/dimatill/graphql-shield

이 글은 2026년 5월 기준이다. 게이트웨이 시장과 Composite Schemas WG는 빠르게 움직이고 있다. Apollo Federation의 표준화 작업이 1.0에 도달하는 시점이 다음 변곡점이다.