GraphQL 생태계 2026 — Apollo / GraphOS / Yoga / urql / Relay / Pothos / Hasura DDN 심층 비교

프롤로그 — "GraphQL은 죽었다"가 죽었다

2023년쯤부터 X(구 Twitter)와 Reddit, HN에는 주기적으로 "GraphQL is dead" 류의 글이 올라왔다. tRPC가 빠르게 떠오르고, Netflix의 Federation 사례에 대한 회의론이 늘어나고, Shopify가 일부 신규 API를 REST로 회귀한 것이 자주 인용됐다. 2024년에는 한 컨퍼런스 키노트가 "GraphQL은 마이크로서비스처럼 과도하게 쓰인 도구다"라고 말하면서 다시 한 번 논쟁이 불붙었다.

2026년 5월 현재, 그 논쟁의 결말은 비교적 명확해졌다.

• GraphQL은 죽지 않았다. 하지만 "모든 API의 디폴트"라는 환상도 죽었다.
• GraphQL은 명확한 영역(BFF, 모바일 클라이언트, 페더레이션된 백엔드, 공개 API)에서 더 강력해졌다.
• 작은 단일 백엔드, 내부 RPC는 tRPC, gRPC, REST가 가져갔다.
• 그래도 시장은 여전히 크다. State of JS, JetBrains, StackOverflow의 2025 조사에서 GraphQL 사용률은 30~40% 사이에서 안정화됐다.

이 글은 그 시장 위에 어떤 도구들이 어떻게 자리잡았는지, 그리고 2026년에 새 프로젝트를 시작할 때 무엇을 골라야 하는지를 정리한다. Apollo / GraphOS 같은 매니지드 진영, Yoga / Mesh / urql / Pothos 같은 The Guild 진영, Relay / Pothos / Nexus 같은 코드 우선 진영, Hasura DDN / Hot Chocolate / gqlgen / Strawberry / graphql-rust 같은 언어별 서버, Stellate 같은 인프라 — 한 글에서 다 본다.

1장 · 2026년 GraphQL 생태계 — "GraphQL은 죽었다" 논쟁 이후

먼저 2025~2026 사이의 사실관계를 정리하자.

• Apollo는 여전히 시장 1위. Server 5(2025년 출시), Client 4가 표준 스택.
• GraphOS는 Apollo의 매니지드 페더레이션 플랫폼. Apollo Studio는 GraphOS로 흡수.
• The Guild는 OSS 진영의 카운터. GraphQL Yoga 5, Mesh 1, GraphQL Code Generator, Envelop, GraphQL Hive.
• urql(Formidable, 이후 Hasura가 일부 후원)은 Apollo Client의 가벼운 대안. v5에서 React 19, Suspense 통합.
• Relay는 Meta가 계속 유지. 18에서 React 19/Server Component 지원.
• Pothos는 TypeScript 코드 우선의 새 표준. Nexus는 사실상 유지보수 모드.
• Hasura는 DDN(2024)으로 v2 시절의 문제(스케일, 락인, 라이선스)를 정리.
• 언어별 서버는 Hot Chocolate(.NET), gqlgen(Go), Strawberry(Python), async-graphql/juniper(Rust).
• 인프라는 Stellate(GraphQL CDN), Apollo Router, Hive, Inigo, Tyk GraphQL Proxy.

큰 흐름은 세 가지다.

1. 페더레이션의 일반화 — 회사 1곳 = 그래프 1개의 단일 거대 스키마는 사라졌다. 도메인별 subgraph + 게이트웨이가 표준.
2. 코드 우선의 부상 — SDL 우선이 아니라 코드(TypeScript/Python/.NET)에서 스키마를 추론. Pothos, Strawberry, Hot Chocolate, gqlgen 모두 같은 흐름.
3. REST/tRPC와의 공존 — GraphQL은 BFF·집계·페더레이션 계층, tRPC/REST는 내부·단일 서버. 종교 전쟁은 끝났다.

이 책 같은 글의 출발점은 이 셋이다.

2장 · GraphQL vs tRPC vs REST — 언제 무엇을 골라야 하나

가장 흔한 질문 먼저 풀자. 셋의 차이를 한 표로.

핵심 의사 결정 트리.

1. 프런트와 백이 같은 TS 모노레포고 다른 언어가 안 끼면 tRPC가 가장 빠르다.
2. **모바일 또는 다중 클라이언트(iOS/Android/Web/임베디드)**가 있고, 각자 필요한 필드가 다르면 GraphQL.
3. 다른 팀의 백엔드(여러 서비스)를 하나로 합쳐 보여줘야 하면 GraphQL Federation.
4. 공개 API, 외부 파트너 통합, 단순 CRUD라면 REST(OpenAPI)가 안전.
5. 내부 마이크로서비스 간 호출, 고성능이면 gRPC.

2026년 현실은 한 회사에 셋 다 있다. 외부 공개 API는 REST, 모바일·웹 BFF는 GraphQL, 내부 서비스 간은 gRPC, TS 단일 풀스택 서비스는 tRPC. "하나만 골라"라는 질문 자체가 옛날이야기.

3장 · Apollo Server 5 / Client 4 — 표준의 자리

Apollo는 2025년에 Server 5, Client 4를 출시했다. 두 메이저 릴리스는 같이 가야 의미가 있다.

Apollo Server 5의 주요 변화

• Node.js 18 이하 지원 종료, ESM 우선.
• @apollo/server로 통합(이전 apollo-server-express, apollo-server-fastify 등의 패키지를 한 줄로).
• 표준 통합 헬퍼는 startStandaloneServer, expressMiddleware, koaMiddleware.
• HTTP/2, gRPC 변환 지원 확대.
• Built-in plugin 정리(랜딩 페이지, 사용량 리포팅, 캐시 컨트롤).

서버 부트스트랩의 모양.

// server.ts
import { ApolloServer } from '@apollo/server'
import { startStandaloneServer } from '@apollo/server/standalone'
import { typeDefs } from './schema'
import { resolvers } from './resolvers'

const server = new ApolloServer({
  typeDefs,
  resolvers,
  introspection: process.env.NODE_ENV !== 'production',
})

const { url } = await startStandaloneServer(server, {
  listen: { port: 4000 },
  context: async ({ req }) => ({
    user: await getUserFromToken(req.headers.authorization),
  }),
})

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

Apollo Client 4의 주요 변화

• React 19 / Suspense 1차 시민. useSuspenseQuery, useReadQuery가 표준.
• 캐시 정책 단순화. 정규화 캐시는 여전.
• defer / stream 디렉티브 지원.
• Local state 관리는 reactive vars 위주(Apollo Link State는 폐기).
• 번들 크기 감소(Tree shaking 강화).

// client.ts
import { ApolloClient, InMemoryCache, HttpLink } from '@apollo/client'

export const client = new ApolloClient({
  link: new HttpLink({ uri: '/graphql' }),
  cache: new InMemoryCache(),
})

React에서 쓸 때.

import { useSuspenseQuery } from '@apollo/client/react'
import { gql } from '@apollo/client'

const ME = gql`
  query Me {
    me {
      id
      name
      email
    }
  }
`

export function Profile() {
  const { data } = useSuspenseQuery(ME)
  return <div>{data.me.name}</div>
}

강점

• 가장 성숙. 거의 모든 패턴이 문서화돼 있다.
• 페더레이션 도구(Rover, Studio, Router)와의 통합.
• 엔터프라이즈 지원.

약점

• 번들이 여전히 크다. Client만 50KB+ 압축 후.
• "Apollo가 무겁다"는 인상이 굳어 있어 신규 팀은 urql을 먼저 고려.
• Apollo Studio가 GraphOS로 흡수되면서 무료 티어가 줄었다.

4장 · GraphOS — Apollo의 매니지드 페더레이션

GraphOS는 Apollo가 만든 페더레이션 플랫폼이다. 핵심 컴포넌트는 셋.

1. Apollo Router — Rust로 작성된 게이트웨이. subgraph 라우팅, 쿼리 플래닝, 캐싱.
2. Schema Registry — subgraph 스키마의 중앙 저장소. 변경 감지, 호환성 체크.
3. Studio(GraphOS UI) — 사용량 메트릭, 쿼리 분석, 운영 도구.

Apollo Router

Apollo Router는 이전의 Apollo Gateway(Node 기반)를 대체한 Rust 게이트웨이다. 처리량이 한 자릿수 배 이상 빠르고, 메모리 사용도 적다. 2026년 시점에서 페더레이션 게이트웨이를 새로 깐다면 거의 무조건 Router.

# router.yaml
supergraph:
  introspection: false
include_subgraph_errors:
  all: true
telemetry:
  exporters:
    metrics:
      prometheus:
        enabled: true
    tracing:
      otlp:
        enabled: true
        endpoint: http://otel:4317

비용 모델

GraphOS는 무료(Serverless), 유료(Dedicated), 엔터프라이즈로 나뉜다. 무료 티어로도 작은 팀은 충분히 돌아가지만, 운영 트래픽이 늘어나면 빠르게 유료로 넘어가야 한다. Apollo의 비즈니스 모델이 GraphOS에 묶여 있어, 2024~2025 사이에 가격 인상이 한 번 있었다.

대안

GraphOS의 대안으로는 GraphQL Hive(The Guild), Inigo, **Stellate(주로 캐싱)**가 있다. Hive는 OSS로도 셀프 호스팅이 가능하고, 더 가벼운 페더레이션 운영을 원하는 팀이 많이 본다. 2026년에 신규로 시작한다면 Apollo Router + Hive 조합도 충분히 합리적.

5장 · GraphQL Yoga 5 + Mesh 1 (The Guild) — 가벼운 진영

The Guild는 GraphQL OSS 생태계를 사실상 주도하는 컬렉티브다. 2026년에 주력 프로젝트는 다음.

• GraphQL Yoga 5 — 가벼운 GraphQL 서버. Apollo Server의 대안.
• GraphQL Mesh 1 — 여러 데이터 소스(REST, OpenAPI, gRPC, DB)를 GraphQL로 자동 변환.
• Envelop — GraphQL 서버 플러그인 프레임워크.
• GraphQL Code Generator — 스키마 → TS/Java/Swift 코드 생성.
• Hive — 스키마 레지스트리·관측 도구(GraphOS 대안).
• GraphQL Tools — schema stitching, mocking, scalars 등 유틸리티 모음.

GraphQL Yoga 5

Yoga는 "Express와 Apollo Server의 좋은 점만 모아 가볍게"라는 컨셉으로 시작했다. 5에서는 Node 18+, Fetch API 기반, Bun/Deno 호환, 엣지 런타임(Vercel/Cloudflare) 1차 시민.

// yoga.ts
import { createYoga, createSchema } from 'graphql-yoga'
import { createServer } from 'node:http'

const yoga = createYoga({
  schema: createSchema({
    typeDefs: /* GraphQL */ `
      type Query {
        hello: String!
      }
    `,
    resolvers: {
      Query: {
        hello: () => 'Hello from Yoga 5',
      },
    },
  }),
})

createServer(yoga).listen(4000)

GraphQL Mesh 1

Mesh는 여러 소스(REST, gRPC, OpenAPI, JSON Schema, Postgres, MongoDB)를 자동으로 GraphQL로 합쳐주는 도구다. 1.x에서 구성 파일이 단순해지고, 페더레이션 통합이 강화됐다. Apollo Router 뒤에 Mesh subgraph를 놓는 패턴이 흔하다.

강점

• 가벼움. Yoga는 Apollo Server 절반 이하 크기.
• Web 표준 기반(Request/Response). 어디서나 돈다.
• OSS, 상업적 락인 없음.

약점

• 페더레이션 운영 도구는 Hive를 따로 깔아야 한다(GraphOS만큼 통합되지 않음).
• 문서는 Apollo만큼 풍성하지 않다.
• 엔터프라이즈 지원은 The Guild 컨설팅에 의존.

6장 · urql 5 (Formidable) — Apollo Client 대안

urql은 Formidable이 만든 가벼운 클라이언트로, "Apollo가 무겁다"는 사람이 가장 먼저 보는 대안이다. 5에서 React 19, Suspense, Server Component를 1차 지원한다.

핵심 차이

• 번들 ~10KB(Apollo Client의 1/5).
• Exchange(미들웨어) 기반. 캐시·인증·재시도 같은 기능을 조립.
• 기본은 document cache. 정규화 캐시는 @urql/exchange-graphcache 옵션.

import { Client, fetchExchange, cacheExchange, Provider } from 'urql'

const client = new Client({
  url: '/graphql',
  exchanges: [cacheExchange, fetchExchange],
})

function App() {
  return (
    <Provider value={client}>
      <Profile />
    </Provider>
  )
}

React 컴포넌트에서.

import { useQuery } from 'urql'

const ME = `
  query Me {
    me { id name }
  }
`

function Profile() {
  const [result] = useQuery({ query: ME })
  if (result.fetching) return <p>Loading...</p>
  if (result.error) return <p>Error</p>
  return <p>{result.data.me.name}</p>
}

강점

• 작다. 번들 크기에 민감한 모바일 웹·embed 위젯에 적합.
• API가 단순. 처음 만지는 사람도 30분이면 익숙해진다.
• React/Vue/Svelte/Preact 모두 지원.

약점

• 정규화 캐시는 별도 패키지. 기본은 document cache(쿼리 단위 캐싱).
• 페더레이션 운영 도구는 없다(클라이언트만).
• 커뮤니티는 Apollo의 1/10 수준.

언제 urql인가

• 번들이 중요한 임베드 위젯, 마케팅 사이트.
• 정규화가 필요 없는 단순한 페이지.
• Apollo Client의 복잡성이 부담스러운 작은 팀.

7장 · Relay 18 (Meta) — 페이스북 내부 표준

Relay는 Meta가 만들고 사내에서 쓰는 GraphQL 클라이언트다. Apollo/urql과는 철학이 다르다. "성능을 위해 컴파일 타임에 최대한 보장한다"는 입장.

핵심 개념

• Fragment colocation — 컴포넌트가 자기에게 필요한 필드를 직접 선언.
• Compiler — 빌드 타임에 쿼리를 분석·최적화. persisted queries를 자동 생성.
• Store — 정규화된 클라이언트 사이드 데이터베이스.
• Suspense + Concurrent — React 18+의 Suspense, Concurrent Mode와 깊게 통합.
• GraphQL Server 요구사항 — Connection 스펙(cursor-based pagination), Node 인터페이스(global ID) 등.

// UserProfile.tsx
import { useFragment, graphql } from 'react-relay'

const UserProfileFragment = graphql`
  fragment UserProfile_user on User {
    name
    avatarUrl
  }
`

export function UserProfile({ user }: { user: UserProfile_user$key }) {
  const data = useFragment(UserProfileFragment, user)
  return <h1>{data.name}</h1>
}

Relay 18의 새 점

• React 19 / Server Component 지원.
• Relay Resolvers GA — 클라이언트 사이드 derived 필드.
• DataDriven Dependency(DDD) — 컴포넌트와 데이터 페이로드를 동시에 fetch.
• Live Queries 베타.

강점

• 대규모 앱에서 최고의 성능. Meta가 페이스북·인스타그램·왓츠앱에서 검증.
• 빌드 타임 분석. 런타임 오버헤드 최소.
• Concurrent React와의 통합이 가장 깊다.

약점

• 학습 곡선이 가파르다. Apollo의 3~5배.
• 서버가 Relay 규약을 따라야 한다(Connection, Node).
• 작은 팀에는 과한 인프라.

언제 Relay인가

• 화면이 수백 개인 대형 SPA.
• 페이스북·핀터레스트·Linear 같은 데이터 집약 앱.
• Meta 출신 엔지니어가 많은 팀.

8장 · Pothos — TypeScript 코드 우선 스키마 빌더

Pothos(이전 GiraphQL)는 TypeScript에서 GraphQL 스키마를 코드 우선으로 정의하는 라이브러리다. 2024~2025 사이에 Nexus를 밀어내고 사실상 표준이 됐다.

코드 우선이 뭐고 왜 좋은가

전통적인 SDL 우선 워크플로는 이렇다.

1. schema.graphql에 타입을 SDL로 작성.
2. graphql-codegen으로 TS 타입 생성.
3. 리졸버에 그 타입을 import.

이게 한 번의 변경에 두 단계가 필요하다. 코드 우선은 거꾸로.

1. TS로 스키마를 빌더 API로 작성.
2. 빌더가 SDL을 자동 생성.

Pothos 예시

// schema.ts
import SchemaBuilder from '@pothos/core'

const builder = new SchemaBuilder({})

const User = builder.objectRef<{ id: string; name: string }>('User')

builder.objectType(User, {
  fields: (t) => ({
    id: t.exposeID('id'),
    name: t.exposeString('name'),
  }),
})

builder.queryType({
  fields: (t) => ({
    me: t.field({
      type: User,
      resolve: () => ({ id: '1', name: 'Alice' }),
    }),
  }),
})

export const schema = builder.toSchema()

Pothos의 강점

• 타입 안전성이 최강. 리졸버 반환 타입까지 추론.
• 플러그인 생태계 풍부 — Prisma, Drizzle, Relay, Federation, Scope Auth.
• 코드젠 단계 불필요.
• 페더레이션(Subgraph) 1차 지원.

Nexus와의 비교

Nexus는 Pothos보다 먼저 나왔고 한때 표준이었다. 하지만 타입 추론에서 Pothos가 더 강하고, Nexus 메인테이너의 활동이 줄면서 사실상 자리를 넘겨줬다. 신규는 거의 Pothos.

Prisma 통합 예시

import SchemaBuilder from '@pothos/core'
import PrismaPlugin from '@pothos/plugin-prisma'
import { prisma } from './prisma'

const builder = new SchemaBuilder<{
  PrismaTypes: PrismaTypes
}>({
  plugins: [PrismaPlugin],
  prisma: { client: prisma },
})

builder.prismaObject('User', {
  fields: (t) => ({
    id: t.exposeID('id'),
    name: t.exposeString('name'),
    posts: t.relation('posts'),
  }),
})

Prisma 모델에서 GraphQL 타입을 거의 자동으로 생성한다. N+1 문제도 플러그인이 자동으로 풀어 준다.

9장 · Hasura DDN — 새 아키텍처

Hasura는 Postgres·SQL Server·BigQuery 같은 DB 위에 GraphQL API를 자동 생성해 주는 도구로 유명해졌다. 그런데 v2까지 가면서 몇 가지 문제가 생겼다.

• 단일 거대 메타데이터 파일이 협업을 막았다.
• 멀티 데이터베이스, 비-DB 데이터 소스가 어색했다.
• Cloud 라이선스와 OSS 라이선스 변화로 커뮤니티가 흔들렸다.
• 성능·스케일링이 운영 시 골치였다.

DDN(Data Delivery Network)

2024년에 발표된 Hasura DDN은 v2의 한계를 정리한 새 아키텍처다.

• Subgraph 단위로 메타데이터 분리 — 도메인별 팀이 독립 작업.
• Data Connectors — Postgres뿐 아니라 ClickHouse, MongoDB, REST, gRPC 등을 1급 시민으로.
• 로컬 우선 — CLI로 로컬 개발, GitOps 친화.
• GraphQL Federation 호환 — DDN subgraph를 Apollo Router 뒤에 둘 수도 있다.

강점

• DB 위 자동 CRUD는 여전히 최강. 며칠 만에 풀스택 백엔드를 띄울 수 있다.
• 권한(Permission)을 SDL로 선언적으로 정의.
• 멀티 소스를 한 그래프로 합치는 시나리오에 강하다.

약점

• v2 → v3(DDN)의 마이그레이션은 사실상 새 작업.
• Cloud 가격이 비싸다는 평이 여전.
• 자유도 높은 비즈니스 로직은 결국 별도 서비스로 빠진다.

언제 Hasura DDN인가

• 데이터 모델이 명확하고 CRUD 위주인 백오피스/관리 콘솔.
• 여러 DB·SaaS API를 묶어 한 그래프로 보여줄 일이 많은 팀.
• 빠른 프로토타입.

10장 · Hot Chocolate (.NET) / gqlgen (Go) / Strawberry (Python) / graphql-rust

JS/TS 바깥의 언어 생태계도 정리하자.

Hot Chocolate (.NET — ChilliCream)

• .NET에서 사실상 표준. 2026년 메이저 14 출시.
• 코드 우선이 기본. 어트리뷰트 기반 스키마 정의.
• Federation, Subscriptions, Persisted Queries 등 다 지원.
• Banana Cake Pop이라는 GraphQL IDE 제공.

public class Query
{
    public Book GetBook() =>
        new Book { Title = "C# in Depth", Author = new Author { Name = "Jon Skeet" } };
}

var builder = WebApplication.CreateBuilder(args);
builder.Services
    .AddGraphQLServer()
    .AddQueryType<Query>();

var app = builder.Build();
app.MapGraphQL();
app.Run();

gqlgen (Go — 99designs)

• Go에서 가장 인기. SDL 우선 + 코드 생성.
• schema.graphqls에 SDL 작성 → gqlgen generate로 리졸버 인터페이스 생성.
• DataLoader, Federation, Subscriptions 지원.
• 99designs/Vista가 유지보수.

Strawberry (Python)

• Python에서 가장 빠르게 성장 중. Graphene의 대안.
• 타입 힌트 기반 코드 우선. 데코레이터로 스키마 정의.
• Django/FastAPI 통합 우수.
• Federation, Subscriptions 지원.

import strawberry

@strawberry.type
class User:
    id: strawberry.ID
    name: str

@strawberry.type
class Query:
    @strawberry.field
    def me(self) -> User:
        return User(id="1", name="Alice")

schema = strawberry.Schema(query=Query)

graphql-rust (async-graphql / juniper)

• Rust 진영은 둘로 나뉜다. async-graphql(더 활발), juniper(오래된 표준).
• async-graphql은 Federation, Subscriptions, Apollo Tracing까지 다 지원.
• Actix, Axum, Warp, Rocket 같은 웹 프레임워크와 결합.
• 성능이 압도적. Rust로 GraphQL 서버를 짤 이유가 거기에 있다.

언어별 선택 가이드

11장 · Stellate — GraphQL CDN 캐싱

GraphQL의 약점 중 하나는 캐싱이다. 같은 쿼리도 변수에 따라 다른 응답이 나오고, 모든 요청이 POST라 표준 HTTP 캐싱이 어렵다. Stellate는 그 문제를 위한 GraphQL 전용 CDN이다.

핵심 개념

• Query별 캐시 — 쿼리 해시 + 변수로 키 생성, 결과 캐싱.
• Edge cache — 전 세계 PoP에서 캐시 응답.
• 자동 무효화(invalidation) — 뮤테이션이 어떤 타입을 바꾸는지 추적해 관련 캐시 만료.
• Rate limiting / Persisted queries도 같이.

사용 예시

Stellate에 GraphQL 엔드포인트를 등록하면, 그 앞에 CDN URL이 생긴다. 클라이언트는 원래 엔드포인트 대신 Stellate URL을 호출. 쿼리 응답은 5초~수 분 캐시되고, 뮤테이션이 발생하면 자동으로 관련 캐시가 무효화된다.

강점

• 같은 GraphQL 쿼리를 자주 호출하는 모바일 앱·홈 화면에서 효과가 크다.
• 백엔드를 거의 손대지 않고 캐시 도입.
• Apollo, urql, Relay 등 클라이언트 무관.

약점

• 유료 SaaS. 가격이 트래픽에 비례.
• 사용자별로 다른 응답이 필요한 쿼리는 캐시 효율이 떨어진다.
• 자체 인프라(Apollo Router + Redis + Varnish)로 대체 가능.

12장 · Federation 2 + subgraph composition 패턴

GraphQL Federation은 여러 subgraph(독립 서비스의 그래프)를 하나의 supergraph로 합치는 방식이다. Apollo가 표준을 정의했고, 2.x에서 안정화됐다.

핵심 디렉티브

• @key(fields: "id") — 엔티티의 식별자 정의.
• @extends — 다른 subgraph의 타입을 확장.
• @external / @requires / @provides — 필드 의존성 명시.
• @shareable — 같은 필드를 여러 subgraph에서 정의 가능.
• @inaccessible — 외부 노출 제외(내부 전용).

Subgraph 예시 (Users)

type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
}

type Query {
  me: User
  user(id: ID!): User
}

Subgraph 예시 (Orders)

extend type User @key(fields: "id") {
  id: ID! @external
  orders: [Order!]!
}

type Order @key(fields: "id") {
  id: ID!
  total: Float!
}

게이트웨이(Apollo Router)는 두 subgraph를 합쳐 supergraph를 만들고, 쿼리 플래너가 me { orders { total } }를 두 subgraph에 분할 요청한다.

Subgraph composition의 운영 패턴

• 도메인 단위 분리 — 팀 = subgraph가 가장 흔한 매핑.
• 공통 entity는 한 곳이 소유 — User는 Users subgraph가 owner, 다른 곳은 extends.
• CI 통합 — PR마다 Rover로 schema check, 호환성 위반 차단.
• 점진적 도입 — 한 거대 모놀리스 그래프를 subgraph로 쪼개는 작업은 보통 분기 단위.

안티패턴

• 너무 잘게 쪼개기 — subgraph가 20+ 개로 늘면 운영이 지옥.
• 모든 entity를 모든 subgraph에 노출 — @inaccessible 적극 활용.
• subgraph 사이 의존을 너무 깊게 — 한 쿼리가 5단계를 거치면 latency가 망가짐.

13장 · persisted queries / defer / stream / live queries

2025~2026 사이에 안정화된 GraphQL 고급 기능들을 짚자.

Persisted Queries

클라이언트가 쿼리 전문 대신 해시만 보내고, 서버는 미리 등록된 쿼리를 실행한다. 효과는 둘.

1. 네트워크 절약 — 모바일에서 큰 쿼리 페이로드를 매번 보내지 않아도 됨.
2. 보안 — 클라이언트가 임의 쿼리를 못 보냄. 공격 표면 축소.

Apollo Persisted Queries, Hive Persisted Documents, Relay Persisted Queries 모두 같은 컨셉. 모바일·임베드 클라이언트에서는 사실상 의무.

@defer / @stream

큰 응답을 한 번에 보내지 말고, 일부를 먼저 보내고 나머지를 스트리밍.

query Profile {
  me {
    id
    name
    ... on User @defer {
      slowField
    }
  }
}

서버는 청크 응답(multipart/mixed)으로 일부 데이터를 먼저 보낸다. 큰 페이지에서 초기 렌더링 시간을 크게 줄일 수 있다. Apollo Server 5 / Yoga 5 / Hot Chocolate 모두 지원.

Live Queries

쿼리 결과가 바뀌면 자동으로 클라이언트에 업데이트가 푸시된다. Subscription과 비슷하지만 — Subscription은 명시적으로 채널을 구독하는 반면, Live Query는 그냥 쿼리를 보내면 서버가 변경을 감지해 재푸시.

Relay 18이 베타로 지원, Yoga·Hot Chocolate에도 실험 구현. 아직 표준화는 진행 중이지만 채팅·대시보드 같은 시나리오에서 매력적.

Subscriptions (다시 정리)

• WebSocket 또는 SSE 위에서 동작.
• Apollo Server는 graphql-ws 권장(레거시 subscriptions-transport-ws는 deprecated).
• 서버리스 환경(Vercel, Cloudflare Workers)에서는 SSE 또는 Pub/Sub(Ably, Pusher) 조합이 흔하다.

14장 · 한국 (카카오, 라인) / 일본 (Mercari, ZOZO) GraphQL 사용

한국과 일본의 큰 회사들이 GraphQL을 어떻게 쓰는지 공개 자료 기준으로 정리한다.

카카오

• 카카오 일부 사내 서비스(2017년경부터)에서 도입.
• 채널톡 같은 외부 SaaS도 GraphQL API를 일부 제공.
• 카카오스타일(지그재그) 등 그룹사들이 BFF에 GraphQL을 적극 사용. Apollo Server + Apollo Client 조합이 흔하다.
• 카카오 기술 블로그에 페더레이션·캐싱 관련 글 다수.

라인 / LINE (LY 그룹)

• LINE의 모바일 메시징 일부 API에서 GraphQL을 내부적으로 사용.
• LY(LINE Yahoo!)로 합병된 후 야후재팬 일부 서비스도 GraphQL 도입.
• 라인 기술 블로그(엔지니어링 블로그)에 페더레이션 도입 사례 글 존재.

Mercari

• Mercari는 GraphQL을 비교적 일찍 도입했다(2019년경 모바일 클라이언트).
• 마이크로서비스 백엔드 위에 BFF로 GraphQL 사용. 페더레이션 도입 사례를 메르카리 엔지니어링 블로그에서 공개.
• Souzoh 같은 자회사도 같은 스택을 쓴다.

ZOZO

• ZOZO Technologies가 GraphQL을 일부 신규 서비스에 채택.
• 코드젠 기반 워크플로(Apollo + graphql-codegen + TypeScript).
• WEAR 등 자사 앱에서 BFF 형태로 사용.

공통 패턴

• 모바일 BFF — iOS/Android 앱에 맞춰 필요한 필드만 골라 보내기 위해 GraphQL.
• 레거시 통합 — REST/gRPC 마이크로서비스 위에 GraphQL Mesh 또는 페더레이션 게이트웨이.
• Apollo 우세, Yoga/Pothos 점차 증가 — 신규는 Pothos 도입 사례가 늘고 있다.
• 사내 스키마 레지스트리 — GraphOS 대신 Hive를 셀프 호스팅하는 사례가 일본에 많음.

한국·일본 모두 "Apollo Server + 페더레이션 + Apollo Router + 사내 또는 SaaS 레지스트리"라는 큰 그림은 유사하다. 차이는 — 한국은 카카오·네이버 같은 거대 인하우스 백엔드 위주, 일본은 메르카리·ZOZO 같은 모바일 커머스 BFF가 메인.

결론 — 2026년에 GraphQL을 새로 고른다면

마지막으로 한 줄짜리 추천.

1. Node/TS 신규 단일 서버 — Yoga 5 + Pothos + Prisma. 클라이언트는 urql 또는 Apollo.
2. Node/TS 신규 페더레이션 — Apollo Server 5 + Apollo Router + GraphOS 또는 Hive. 클라이언트는 Apollo Client 4.
3. Meta급 대형 SPA — Relay 18 + Pothos. 인프라는 자체 운영.
4. 모바일 BFF — Apollo Server 5 + Apollo Client 4 + Persisted Queries + Stellate.
5. Python — Strawberry + FastAPI/Django. 페더레이션이면 Apollo Router 뒤에 둠.
6. Go — gqlgen + DataLoader. 클라이언트는 언어 무관.
7. .NET — Hot Chocolate 14. 거의 다른 선택지가 없다.
8. Rust — async-graphql + Axum. 성능이 진짜 중요하면.
9. DB 위 자동 CRUD — Hasura DDN. 단, 자유도 높은 비즈니스 로직은 별도 서비스로.

그리고 가장 중요한 한 가지. "GraphQL이냐 아니냐"는 더 이상 단일 선택이 아니다. 한 회사에 GraphQL(모바일 BFF), tRPC(TS 풀스택), REST(공개 API), gRPC(내부 RPC)가 동시에 있는 게 정상이다. GraphQL은 죽지 않았다 — 적절한 자리를 찾았을 뿐.

참고 / References

• GraphQL 공식 사이트
• Apollo GraphQL 공식 문서
• Apollo Server 4/5 마이그레이션 가이드
• Apollo Client React 문서
• GraphOS 소개
• Apollo Router 문서
• The Guild — GraphQL Yoga
• The Guild — GraphQL Mesh
• The Guild — GraphQL Hive
• The Guild — Envelop
• GraphQL Code Generator
• urql 공식 사이트
• Relay 공식 사이트
• Pothos GraphQL
• Nexus GraphQL
• Hasura DDN 문서
• ChilliCream Hot Chocolate
• gqlgen (Go)
• Strawberry (Python)
• async-graphql (Rust)
• Juniper (Rust)
• Stellate
• GraphQL Federation 스펙
• Persisted Queries (Apollo)
• GraphQL @defer / @stream 스펙
• graphql-ws
• State of GraphQL 2024 (The Guild)
• 카카오 기술 블로그
• LINE Engineering Blog
• Mercari Engineering Blog
• ZOZO TECH BLOG