02 — History & Spec
한 줄 답: GraphQL은 2012년 Facebook 모바일 News Feed에서 태어나, 2015년 오픈소스화, 2018년 Linux Foundation 산하 GraphQL Foundation으로 이관, 2021년 October 사양으로 안정화됐다.
Why — 왜 역사를 알아야 하나
라이브러리는 짧으면 1년에 한 번 부서지고, 표준은 길면 10년에 한 번 바뀐다. GraphQL을 라이브러리로 보면 미래가 무섭고, 표준으로 보면 안정적이다. 어느 쪽이 진실인지는 누가 통제권을 쥐고 있나를 봐야 알 수 있다.
또 하나, 사양이 어떻게 만들어졌는지를 알면 왜 이런 선택을 했나가 보인다 — 왜 single endpoint인가, 왜 partial response인가, 왜 mutation은 순차 실행인가. 이 모두 2012년 Facebook iOS 앱의 N+1 문제에서 시작된 결정이다.
How — 어떻게 만들어졌나
출생부터 표준화까지의 타임라인
다섯 개의 결정적 순간
① 2012년 봄 — Facebook iOS의 N+1 사고
당시 Facebook은 HTML5 앱에서 네이티브 앱으로 전환하던 중이었다. 모바일 셀룰러 네트워크에서 News Feed 한 화면을 그리려면 REST endpoint를 수십 번 호출해야 했고, 사용자는 빈 화면을 보며 기다렸다.
Nick Schrock·Dan Schafer·Lee Byron 세 사람이 “응답 모양을 클라이언트가 선언하면 N+1이 1번이 되지 않나”라는 아이디어로 SuperGraph라는 프로토타입을 만들었다. 2월에 prototype, 8월에 production iOS 앱.
② 2015년 7월 — 오픈소스 공개
3년간 Facebook 내부에서 모바일 트래픽 대부분을 받아내며 검증된 뒤, 2015년 React Europe에서 공개. 동시에 다음이 풀렸다.
graphql-js— JS 참조 구현- Working Draft Spec — 사양 문서
graphql.org— 학습 사이트
이 시점부터 GraphQL은 Facebook의 사내 도구가 아니라 오픈 표준 후보가 됐다.
③ 2018년 11월 — Linux Foundation으로 이관
Facebook은 GraphQL의 상표·저작권·도메인을 모두 Linux Foundation 산하 GraphQL Foundation으로 넘겼다. founding member에 Airbnb·Apollo·Coursera·Elementl·GitHub·Hasura·Prisma·Shopify·Twitter가 합류.
이 결정의 의미는 단순하지 않다 — 언어를 만든 회사가 통제권을 놓는 순간에야 그 언어는 비로소 표준이 된다. Java가 Oracle 손에서 못 벗어나 받은 비판을 GraphQL은 받지 않는 이유.
④ 2019년 3월 — JDF와의 협업
GraphQL Foundation은 Joint Development Foundation(JDF)와 협업해 표준화 트랙에 들어갔다. JDF는 W3C 같은 표준화 기구의 경량 버전으로, 오픈소스 프로젝트를 ISO 표준으로 끌어올리는 다리 역할을 한다. GraphQL은 JDF + Linux Foundation 협업의 첫 사례였다.
⑤ 2021년 10월 — 첫 ratified spec
spec.graphql.org/October2021/ — 이전까지의 모든 Working Draft를 통합해 정식 비준된 첫 사양. 이전 버전(June2018)이 사실상 표준 역할을 했지만, 공식적으로 ratified된 것은 October 2021이 처음이다.
이후로는 spec.graphql.org/draft에서 working draft가 진행되고, 일정 시점마다 새 ratified version이 찍히는 IETF/W3C식 모델로 운영된다.
What — 구체 사양
Spec 문서의 구조
spec.graphql.org/October2021/은 단일 HTML 문서다. 다음 7개 절로 구성된다.
| 절 | 제목 | 다루는 것 |
|---|---|---|
| §1 | Overview | 목적, 비전, 비용 모델 |
| §2 | Language | 문법(BNF), 토큰, 주석, fragment |
| §3 | Type System | Scalar/Object/Interface/Union/Enum/Input/Directive |
| §4 | Introspection | __schema, __type, __typename 메타 필드 |
| §5 | Validation | 100+ 정적 규칙 (e.g. “Fields must exist on type”) |
| §6 | Execution | 쿼리 → 응답 변환 알고리즘 |
| §7 | Response | data / errors / extensions 형식 |
누가 통제하고 누가 구현하나
- Linux Foundation: 법적·재정적 모회사
- GraphQL Foundation: 상표·도메인·자금 관리 (2018~)
- GraphQL Working Group: 실제 spec 변경을 제안·논의·승인하는 곳. 매월 공개 회의, 회의록은 GitHub
graphql/graphql-wg리포지토리에 공개 - 참조 구현:
graphql-js(Facebook이 만들었고 지금도 maintainer가 운영). spec 변경 시 먼저 여기에 구현돼야 ratified될 수 있는 관행
Spec이 다루지 않는 것 (생태계의 합의)
| 영역 | 사실상 표준 |
|---|---|
| HTTP transport | graphql-over-http (graphql.org가 별도 draft 운영) |
| WebSocket transport | graphql-ws (graphql-transport-ws 라이브러리) |
| SSE transport | graphql-sse |
| Pagination | Relay Connection Spec (cursor 기반) |
| Federation (다중 서비스 합성) | Apollo Federation v2 — de facto이지만 spec은 아님 |
| Authentication | 사양 외 — HTTP 헤더에 위임 |
| Persisted queries | 사양 외 — Apollo APQ가 사실상 표준 |
→ 즉 GraphQL은 언어 spec만 표준화돼 있고, 그 주변 생태계는 라이브러리·회사들이 합의한 결과물이다.
버전 관리 정책
GraphQL은 버전 번호가 없다. 정확히는 Spec에는 release date만 있다 (October 2021).
이유: spec 변경은 항상 backward-compatible이어야 한다는 규칙. 기존 쿼리가 깨지는 변경은 spec에 들어가지 않는다. — 새 기능은 추가 형태로만 들어간다 (e.g. @oneOf directive는 2024 working draft에 추가됐지만 기존 쿼리는 그대로 동작).
What-if — 잘못 이해하면
1) “GraphQL의 미래 = Facebook의 의지”라고 보면
→ 2018년 이후 통제권은 Linux Foundation에 있다. Facebook이 사라져도 spec은 살아남는다. 증거: Apollo·GitHub·Shopify가 founding member이며, working group 의사결정은 합의제.
2) Spec과 Apollo Federation을 혼동하면
→ Federation은 Apollo가 만든 다중 서비스 합성 spec이지 GraphQL spec이 아니다. 대응: 표준화된 대안은 Composite Schemas Working Group(2023~)에서 진행 중. Federation에 lock-in되기 전에 다른 옵션이 있는지 확인.
3) “Working Draft를 따라가야 한다”라고 믿으면
→ Production은 ratified spec (October 2021)을 따라야 한다. Draft는 변경될 수 있다.
대응: 라이브러리가 어떤 spec 버전을 지원하는지 README에서 확인. graphql-js 17.x는 October 2021 + 일부 draft 기능.
4) “Subscription = 표준”이라고 믿으면
→ Subscription은 spec에 operation type만 정의됐고, transport는 사양 외다. WebSocket을 통한 표준 프로토콜은 graphql-ws라는 라이브러리 차원의 합의다.
대응: 클라이언트·서버 라이브러리가 같은 transport spec을 쓰는지 먼저 확인.
5) “GraphQL은 ISO 표준이다”라고 말하면
→ 아직 아니다. JDF 협업으로 표준화 트랙에 들어갔지만, 2026년 5월 기준 ISO/IETF RFC 번호가 부여된 것은 아니다. 사실상 표준(de facto)일 뿐.
Insight — 흥미로운 이야기
”Lee Byron, Dan Schafer, Nick Schrock — 그리고 documentary”
2022년, Honeypot이 GraphQL: The Documentary를 공개했다. 30분짜리 영상에서 세 창시자가 직접 출생 이야기를 한다 — Nick이 처음 SuperGraph를 만들었고, Dan은 타입 시스템을 밀어붙였고, Lee는 문법과 사양 문서를 잡았다. 셋의 역할 분담이 명확해서 디자인 by committee가 빚을 단점이 거의 없었다는 게 다른 표준들과 GraphQL의 차이다.
”왜 2018년에 손을 놓았나”
2017년쯤 Apollo·GitHub·Shopify가 GraphQL을 production에 깊게 쓰면서, Facebook 한 회사가 spec을 통제하는 것에 대한 불안이 커졌다. React가 같은 이유로 한때 PATENTS 라이선스 논란을 겪었던 트라우마가 컸다. Facebook은 그 학습을 살려 react는 BSD3로, GraphQL은 Linux Foundation으로 넘겼다 — 같은 회사의 두 다른 처방.
”October 2021이 첫 ratified spec인 이유”
2015년부터 2021년까지 6년간 GraphQL은 Working Draft 상태였다. 그 사이에 Apollo·Relay·Hasura 같은 거대 생태계가 Working Draft 위에 production을 올렸다. 2021년 10월 ratified를 찍을 때 가장 큰 논점은 “이미 production에서 굳어진 패턴을 어디까지 spec에 흡수할 것인가”였다. 결과적으로 spec은 최소한만 가져갔고, Federation·persisted query·pagination 같은 것들은 생태계 합의로 남겼다 — 이 보수성이 GraphQL을 깨지지 않게 유지하는 핵심이다.
요약 + 다이어그램
GraphQL은 Facebook이 만들었지만 더 이상 Facebook의 것이 아니다. 2012년 모바일 N+1을 풀려고 만들었고, 2015년에 풀어줬고, 2018년에 표준화 길로 보냈으며, 2021년에 처음으로 ratified spec을 얻었다. 사양은 언어·타입·실행만 정의하고, 그 외(transport·federation·pagination)는 생태계 합의다.
다음 문서:
03-graphql-vs-rest.mdx— GraphQL이 REST를 대체하나? 아니, 다른 문제를 푼다.