09-real-world-cases — 실전 사례
이 챕터가 답하는 질문: GraphQL을 큰 회사들이 실제로 어떻게 쓰고 있는가? 그 차이에서 무엇을 배울 수 있나? 한 줄 답 (Pyramid Top): “같은 도구가 Meta(모바일)·GitHub(공개 API)·Shopify(상점)·Netflix(스튜디오)에서 전혀 다른 문제를 푼다 — 도구는 문제의 모양을 따른다.”
한 문장 답
GraphQL을 “어떻게 쓰는가”는 그 회사가 어떤 문제를 푸는가가 결정한다. Meta는 모바일 News Feed의 라운드트립을, GitHub는 공개 API의 가변 응답을, Shopify는 지속 가능한 외부 트래픽을, Netflix는 수십 팀의 그래프 통합을, Airbnb는 모놀리스의 점진적 해체를 푼다. 이 챕터는 6개 회사를 비교하며 *“GraphQL은 무엇을 위한 도구인가”*를 사례에서 거꾸로 추출한다.
챕터 지도 (Mermaid)
Why — 왜 사례를 비교하는가
GraphQL 문서·튜토리얼·컨퍼런스 토크의 90%는 기술 자체를 설명한다. “스키마를 이렇게 짜고, resolver를 이렇게 쓰고, federation을 이렇게 붙인다.” 하지만 실제로 production에서 어떤 문제가 풀리고, 어떤 트레이드오프가 남는가는 사례에서만 보인다.
이 챕터는 6개 회사의 사례를 비교한다. 비교가 가르치는 것은 다음 셋이다.
- 공통 패턴 — 어느 회사든 비슷하게 도달한 해법. (단일 그래프, persisted query, schema registry)
- 분기점 — 회사마다 다르게 푼 문제. (cost system 도입 여부, federation 시점, 공개 vs 내부)
- 가능성 공간 — “GraphQL로 이것까지 할 수 있다”는 범위. (Meta 규모 → 우리도 가능)
“다른 회사가 어떻게 쓰는지”는 우리의 결정을 빠르게 만든다 — 처음부터 다시 발명하지 않기 위해.
How — 어떻게 읽나
다음 7개 문서를 순서대로 읽으면 한 시간 반 정도 걸린다. 각 문서는 독립적으로 읽혀도 되지만, 시간순(Meta → GitHub → Shopify → Netflix → Airbnb)으로 흐른다.
| # | 파일 | 읽는 데 | 핵심 키워드 |
|---|---|---|---|
| 01 | 01-meta-the-origin.mdx | 14분 | 2012 SuperGraph, News Feed, Relay 2015, hundreds of billions/day |
| 02 | 02-github-public-api-v4.mdx | 13분 | 2016 공개, point system, schema previews, REST v3 공존 |
| 03 | 03-shopify-storefront-api.mdx | 12분 | Storefront vs Admin, leaky bucket, money/decimal, Hydrogen |
| 04 | 04-netflix-studio-edge.mdx | 14분 | 150 subgraphs, Federation v2, DGS framework, GraphOS |
| 05 | 05-airbnb-supergraph.mdx | 12분 | Thrift 공존, 점진 채택, Viaduct, schema 통합 |
| 06 | 06-atlassian-and-others.mdx | 10분 | Atlassian gateway, PayPal Checkout, Coursera, AppSync |
| 07 | 07-patterns-distilled.mdx | 18분 | 공통 패턴 8개, 결정 트리, 안티패턴 |
의존성: 07은 0106을 가정한다. 0106은 서로 독립적이지만 시간순으로 읽으면 생태계의 진화가 보인다.
What — 사례 비교 표 (한 페이지 요약)
| 회사 | 도입 동기 | 출발 시점 | 공개/내부 | Federation | 규모 (공개된 수치) | 돌아갈 챕터 |
|---|---|---|---|---|---|---|
| Meta | 모바일 News Feed N+1 라운드트립 | 2012 | 내부 | (내부 graph) | 수천억 호출/일 | 00-foundations, 02-execution-resolvers |
| GitHub | REST v3의 응답 고정성 한계 | 2016 (v4 GA) | 공개 | 단일 그래프 | 5,000 points/h per user | 07-security-governance |
| Shopify | headless 상점 + 외부 앱 생태계 | 2018~ | 공개 (Storefront + Admin) | (분리된 두 API) | 1,000 points/s burst | 05-cache-performance, 07-security-governance |
| Netflix | 스튜디오 백오피스 + 50~60 내부 앱 | 2018~ Studio Edge | 내부 | Federation v2 | 150 subgraphs, 3000+ types | 06-federation |
| Airbnb | Java/Thrift 모놀리스의 데이터 페칭 복잡도 | 2018~ | 내부 | Federation + Viaduct OSS | 수백 entity 통합 | 06-federation |
| Atlassian | 멀티 프로덕트(Jira/Confluence) 통합 게이트웨이 | 2020~ | 공개 | 단일 gateway | (api.atlassian.com/graphql) | 06-federation |
표의 분기점은 두 개다 — (1) 공개 API인가, (2) federation을 도입했는가. 이 두 축이 거의 모든 운영 결정을 가른다.
What-if — 이 챕터를 건너뛰면
- 사례를 안 보면: “우리도 Netflix처럼 federation 가자”가 조직 200명 미만에서 나온다 — federation은 조직 사이즈가 만든 문제의 해답이다.
- GitHub의 cost system을 모르면: 공개 GraphQL을 깔고 DDoS-by-query를 겪는다 — 이미 GitHub이 해법을 공개해 두었다.
- Shopify Storefront/Admin 분리를 모르면: 하나의 graph로 공개·내부 권한을 섞어 쓰다가 권한 모델이 폭발한다.
- Meta의 시작 동기를 모르면: GraphQL이 모바일 라운드트립을 위해 태어났다는 사실을 잊고, 단일 페이지 SSR에 무리하게 끼워 넣는다.
Insight — 한 단락 이야기
“GitHub이 v4를 공개한 2016년 9월이 GraphQL의 두 번째 탄생일이다”
2015년 오픈소스 직후 GraphQL은 “Facebook이 쓴다”는 후광 외에는 외부에서 어떻게 운영하는지 아무도 몰랐다. 2016년 9월 14일, GitHub은 새 공개 API의 기본을 GraphQL로 발표한다 — REST v3는 그대로 두지만 v4는 GraphQL이다. 동시에 “rate limit은 호출 수가 아니라 쿼리 비용으로 계산한다”는 point system을 공개했다. 이 한 문서가 그 뒤 5년간 모든 공개 GraphQL API의 청사진이 되었다 — Shopify의 cost system도, AWS AppSync의 cache directive도 여기서 출발한다. Facebook이 만든 도구가 GitHub이 검증한 도구가 되는 데 1년이 걸렸다.
한 단락 요약
6개 회사의 사례는 같은 도구가 전혀 다른 문제를 푸는 모습을 보여준다. Meta는 모바일 라운드트립을, GitHub은 공개 API의 가변 응답을, Shopify는 지속 가능한 외부 트래픽을, Netflix·Airbnb는 수십 팀의 그래프 통합을, Atlassian과 다른 회사들은 멀티 프로덕트 게이트웨이를 푼다. 마지막 문서(
07-patterns-distilled)는 이 차이에서 공통 패턴 8개와 3개의 분기점을 추출한다 — 결국 GraphQL을 도입할지 말지의 결정은 “당신의 문제 모양이 이 6개 중 어디에 가까운가”로 환원된다.
다음 문서:
01-meta-the-origin.mdx— 모든 사례의 출발점, 2012년 Facebook 모바일 팀의 회의실로 돌아간다.