07 — Patterns Distilled

한 줄 답: 앞 6개 사례를 교차하면 공통 패턴 8개와 3개의 결정 분기점이 남는다. 모바일 우선이냐 / 공개 API냐 / 마이크로서비스 통합이냐가 도구의 모양을 결정한다. 이 문서는 사례를 추상화하여 당신의 문제에 적용 가능한 결정 트리로 압축한다.

Why — 사례에서 패턴을 뽑아야 하는 이유

사례 글을 그대로 따라 하면 작동하지 않는다. Netflix가 150 subgraphs를 운영한다고 우리도 federation 가자는 조직 크기를 무시한 결정이다. GitHub의 5,000 points/hour를 그대로 베끼면 우리 부하 패턴에 안 맞는 값을 쓰는 것.

사례에서 공통 패턴과 분기점을 분리하면 — 어떤 결정이 보편적이고 어떤 결정이 상황 의존적인지 보인다.

결정 트리 = 자기 상황을 사례에 매핑하는 도구. 이 문서가 이 챕터의 실용적 결론이다.

How — 패턴 추출 방법

1) 공통 패턴 — 모든 사례에 반복 등장

8개 패턴 — 6개 사례 중 최소 4곳 이상에서 확인된 것만 포함.

P1. 단일 endpoint + Introspection

→ 모든 사례가 단일 endpoint. REST의 path 라우팅을 완전히 포기. 대신 introspection으로 schema 탐색.

P2. Persisted Query

Persisted query가 푸는 문제:

• 네트워크 페이로드 — 매 요청에 쿼리 텍스트 안 보냄
• 보안 — 등록되지 않은 쿼리 거부 (introspection 차단 가능)
• 분석 — operation별 추적 용이

→ 대규모 production에서 거의 표준. 작은 팀은 DEV 모드만 raw query, PROD는 persisted.

P3. Schema Registry + Check

rover subgraph check 같은 명령이 CI에서 깨지는 변경을 차단한다. Federation은 schema registry 없이는 운영 불가.

P4. Connection Pagination (Relay)

type Query {
  issues(first: Int, after: String, last: Int, before: String): IssueConnection!
}
type IssueConnection {
  edges: [IssueEdge!]!
  pageInfo: PageInfo!
  totalCount: Int!
}
type IssueEdge {
  node: Issue!
  cursor: String!
}
type PageInfo {
  hasNextPage: Boolean!
  hasPreviousPage: Boolean!
  startCursor: String
  endCursor: String
}

→ offset pagination을 거의 안 쓴다. 이유: cursor가 분산 시스템에서 안정적, Relay client cache와 정합.

P5. 버전 없음 + Deprecation Policy

→ URL 버전을 피한다. 대신 field-level deprecation + 분석으로 안전성 확인.

P6. 클라이언트 라이브러리 표준화

→ 회사 안에선 Apollo Client 또는 Relay 하나로 표준화. 여러 클라이언트가 섞이면 cache 정합·devtools·codegen 모두 깨짐.

P7. REST/RPC와의 공존

→ GraphQL이 REST를 죽이지 않는다. 서로 다른 use case를 각자의 강점으로 푼다.

P8. Operation Analytics → Field Usage

*“이 필드를 누가 쓰는가”*를 추적할 수 없으면 deprecation을 영영 못 한다. Schema 거대화는 분석 부재에서 시작.

2) 결정 분기점 — 상황에 따라 다른 결정

분기점 1. 공개 API인가 / 내부인가

공개 API는 Day 1부터 cost system + deprecation policy. 내부는 시작은 가볍게 가능.

분기점 2. 조직 규모 100명 미만 / 200명 이상

100~200 사이는 모놀리스를 유지하면서 모듈 분리가 보통 더 싸다. Federation은 플랫폼 팀 1~3명 비용을 감당할 수 있을 때.

분기점 3. 처음부터 GraphQL / 기존 시스템 위

Brownfield가 압도적으로 흔하다. Airbnb의 점진 패턴이 기본 도입 경로.

3) 결정 트리 (실용)

4) 안티패턴 — 사례에서 반대로 가지 말라

What — 6개 사례의 최종 비교표

What-if — 패턴을 잘못 적용하면

1) 패턴을 순서 없이 도입하면

→ Federation 먼저 + Schema registry 나중 = 수개월간 깨진 supergraph 운영. 대응 순서:

1. 단일 graph 운영 안정화 (P1·P4·P6)
2. Persisted query·analytics (P2·P8)
3. Schema registry + deprecation (P3·P5)
4. Federation 검토 (조직이 200명 넘으면)
5. REST와의 공존 정책 명문화 (P7)

2) 분기점을 한 번만 보면

→ 도입 후 3년·5년 뒤에 조직 규모가 바뀌면 분기점도 다시 본다. 대응: 연 1회 분기점 재검토. Coursera는 3년 뒤 schema 거대화에서 다시 결정.

3) 안티패턴을 모르고 시작하면

→ 위 10개 안티패턴 중 3~4개를 동시에 밟는다 — 가장 흔한 실패 모드. 대응: 안티패턴 표를 PR 체크리스트로 만든다.

4) “큰 회사 사례 = 우리 사례”라고 믿으면

→ 50명 조직이 Netflix를 따라가면 플랫폼 팀 비용으로 회사가 깨짐. 대응: 우리 조직 사이즈와 가장 가까운 사례를 기준으로 잡는다.

5) 패턴 적용 후 측정 없이 진행하면

→ “GraphQL 도입했는데 빨라졌나”를 정량 측정 못 함 — Airbnb의 10x faster 같은 회고가 안 나옴. 대응: 도입 전 baseline 메트릭 측정 (페이지 로드, 코드 라인 수, 배포 빈도).

Insight — 흥미로운 이야기

”패턴 8개 중 5개가 Meta 내부에서 먼저 검증”

P2(persisted query), P4(connection), P5(버전 없음), P6(Relay 클라이언트), P8(operation analytics)은 Meta가 내부에서 먼저 검증한 뒤 외부에 흘렸다. Facebook이 만든 것을 다른 회사가 검증하는 흐름이 아니라 — *Meta가 내부 운영 압력에서 발견한 패턴이 생태계 표준이 됐다는 점이 의미심장. 즉 생태계의 베스트 프랙티스 = Meta 14년 운영 노하우의 외부화.

”Federation은 기술이 아니라 조직 패턴”

Netflix·Airbnb·PayPal 모두 Federation을 기술 우월성이 아니라 Conway’s Law의 압력에서 도입했다. 즉 Federation 채택률은 조직 사이즈 분포와 상관관계가 있지 기술 성숙도와는 약하게 관계한다. 작은 조직은 Federation 거의 안 쓴다 — 그게 정답이지 덜 진화한 게 아니다.

”Public API GraphQL의 채택이 2017~2020년에 정체”

GitHub(2016), Shopify(2018) 이후 큰 공개 API GraphQL이 별로 안 나왔다. 이유는 cost system + deprecation policy 운영이 너무 비싸다. 대부분 회사는 내부 GraphQL + 공개 REST(Twitter 모델)로 정착. 공개 GraphQL은 GitHub·Shopify처럼 외부 개발자 생태계가 critical할 때만 가치가 있다.

”AppSync · Hasura · Postgraphile의 의미”

AppSync(2017), Hasura(2018), Postgraphile(2016) 같은 DB → GraphQL 자동 생성 도구의 등장은 GraphQL 도입 곡선의 두 갈래를 만들었다 — 직접 운영 (Meta 패턴) vs 자동 생성 (greenfield 패턴). 작은 팀이 GraphQL을 빠르게 받을 수 있는 길이 생겼고, 큰 회사의 내부 표준과 작은 회사의 빠른 시작이 다른 패턴으로 분기.

”Viaduct는 Federation의 진화 또는 회귀”

Airbnb의 Viaduct(2026)는 Federation에서 다시 단일 거대 schema로 일부 회귀한 패턴이다 — 단 분산 실행 엔진은 유지. 이 의미는 — Federation도 영원한 답이 아니다. 5~10년 운영하다 보면 다음 패턴이 나타난다. GraphQL 생태계는 아직 진화 중이고, 결정 트리도 5년 단위로 갱신해야 한다.

”사례 글이 생태계 학습 곡선을 압축”

이 챕터의 진짜 가치는 6개 회사가 5~14년에 걸쳐 발견한 패턴을 1.5시간에 압축한다는 점이다. 사례 글이 없었다면 — 각 회사가 처음부터 다시 같은 실수를 한다. 기술 블로그·컨퍼런스 토크·spec WG 참여가 생태계의 집단 학습 메커니즘. 다음 회사가 이 챕터를 읽고 1년을 단축할 수 있다.

요약 + 다이어그램

6개 사례에서 공통 패턴 8개(단일 endpoint, persisted query, schema registry, connection pagination, deprecation policy, 클라이언트 표준화, REST 공존, operation analytics)와 결정 분기점 3개(공개/내부, 100/200명, greenfield/brownfield)가 추출된다. 어떤 사례가 옳다가 아니라 우리 분기점에서 어느 쪽인가가 결정의 기준. 안티패턴 10개를 PR 체크리스트로 만들면 3~5년의 흔한 실수를 미리 차단할 수 있다.

이 챕터에서 다른 챕터로 돌아가는 링크

참고 자료 (이 챕터의 원천 자료 모음)

• (사례별 출처는 01~06 문서 각각 끝의 참고 자료 섹션 참고)
• Lee Byron, GraphQL Working Group — github.com/graphql/graphql-spec
• GraphQL Summit (Apollo) — youtube.com/c/ApolloGraphQL
• GraphQL Conf (Linux Foundation) — graphql.org/conf
• spec.graphql.org — October 2021 (현재 안정), @defer/@stream proposal (WG)
• Apollo Federation spec — specs.apollo.dev/federation/v2.x

챕터 종료: 이 챕터를 다 읽었다면, GraphQL이 무엇인가에서 우리 문제에 적용 가능한가까지의 전체 결정 경로를 가지고 있다. 다음 챕터는 없다. *글로서리(99-glossary)*로 가서 기억 안 나는 용어를 다시 정리하거나, 처음으로 돌아가 챕터 1을 지금의 눈으로 다시 읽는 것을 권한다 — 같은 글이 다르게 보일 것.