05 — Airbnb Supergraph & Viaduct

한 줄 답: Airbnb는 Java/Thrift 모놀리스 위에 GraphQL을 한 줄도 안 끊고 점진적으로 얹어 supergraph를 만들었고, 그 결과물(Viaduct)을 2026년 1.0으로 오픈소스했다. Netflix가 처음부터 큰 federation이라면 Airbnb는 점진 채택의 표본이다 — 갈아엎지 않고 가는 길.

Why — 왜 Airbnb 사례가 중요한가

대부분의 회사는 Netflix 같은 신생 그래프를 만들 사치가 없다. 수백 명 엔지니어가 이미 짠 코드 위에서 GraphQL을 도입해야 한다. Airbnb는 그 대다수의 회사가 처할 상황의 모범 답안이다.

Airbnb의 사례는 기술 자체보다 마이그레이션 전략을 가르친다 — 어떻게 안 깨고 옮기는가.

How — 어떻게 운영하나

1) 출발점 — Java/Thrift 모놀리스

Airbnb의 백엔드는 오랫동안 Java + Thrift RPC가 중심이었다. UI 팀은 Thrift 서비스를 직접 호출하거나 *BFF(Backend-for-Frontend)*를 짜서 화면당 데이터를 조립했다.

문제 — BFF 폭발:

• UI팀마다 자기 BFF를 만든다 → 중복 코드 폭증
• 새 화면이 Listing + Pricing + Reviews를 묶으려면 세 Thrift 호출 + 변환 코드
• 프론트엔드 변경이 백엔드 BFF 변경을 트리거 → 배포 사슬
• 데이터 모델이 BFF마다 미묘하게 다름 → 일관성 깨짐

이게 GraphQL 도입 직전의 Airbnb다. 2018년 Adam Neary의 “Moving 10x Faster” 글이 가리키는 상태.

2) 점진 채택 (Incremental Adoption)

Airbnb의 결정 — 갈아엎지 않는다. 대신 GraphQL을 Thrift 위의 통합층으로 놓는다.

핵심 결정 셋 (medium.com/airbnb-engineering/how-airbnb-is-moving-10x-faster-at-scale-with-graphql-and-apollo):

1. subgraph가 Thrift 서비스를 그대로 호출 — 비즈니스 로직 중복 없음.
2. 화면 단위로 GraphQL 도입 — 신규 화면부터 GraphQL, 기존 화면은 그대로 유지.
3. Apollo Client 표준화 — 모든 UI팀이 같은 클라이언트를 쓰도록.

5년에 걸쳐 수백 개 entity가 GraphQL 통합 schema로 옮겨졌다. 모놀리스를 단번에 끊은 게 아니라 한 entity씩.

3) Reconciling GraphQL and Thrift

Airbnb 엔지니어링 블로그의 “Reconciling GraphQL and Thrift at Airbnb”(medium.com/airbnb-engineering/reconciling-graphql-and-thrift-at-airbnb-a97e8d290712)가 핵심 도구를 공개한다.

Thrift를 그대로 둔 채 GraphQL을 얹는다는 단순한 아이디어가 수만 줄의 코드로 구현됐다는 점이 중요. 재발명하지 말 것 — Airbnb의 글을 참고.

4) Federation 도입

Airbnb는 2020년 전후로 단일 GraphQL gateway에서 Apollo Federation으로 옮겼다 (Adam Miskiewicz 인터뷰, InfoQ).

옮긴 동기 — Netflix와 동일 (Conway’s Law):

• 한 gateway 팀이 모든 도메인 schema 변경에 묶임
• 도메인 팀이 gateway PR을 기다리느라 속도 저하
• Schema review가 cross-team 동기화 비용으로

→ Federation으로 도메인별 schema 소유권을 분산.

5) Viaduct — 한 단계 더

2020년 발표(medium.com/airbnb-engineering/taming-service-oriented-architecture-using-a-data-oriented-service-mesh), 2025~2026년 1.0과 오픈소스 공개(github.com/airbnb/viaduct).

Viaduct는 단순 federation gateway가 아니다:

핵심 차별점:

• Re-entrancy: 한 resolver가 다른 resolver를 GraphQL fragment로 호출 가능 → modularity
• 단일 거대 schema: federation처럼 복수 subgraph가 아니라 한 schema인데, 내부적으로 분산 실행
• Data-oriented service mesh: 서비스 mesh가 RPC routing이 아니라 데이터 access 중심

Viaduct는 Airbnb가 5년 동안 federation과 모놀리스 사이에서 발견한 새 균형점이다. Federation의 변형이라고 볼 수도, 모놀리스 graph의 진화라고 볼 수도 있다.

What — 구체 사양

공개된 사실

도입 전략의 세 단계

한 번에 federation 간 게 아니다. 모놀리스 → federation → Viaduct로 5~7년에 걸친 점진 진화.

”10x Faster”의 측정 (2018 Adam Neary 글)

블로그가 인용하는 효과:

• 데이터 페치 코드가 화면 코드의 60% → 10%
• 새 화면 prototype 시간이 일주일 → 하루
• 서버 round trip 평균 3~5회 → 1회

정량 효과보다 의미 있는 건 프론트엔드 개발자가 “데이터 어디서 오는지” 신경 안 써도 됨이라는 정성 효과.

What-if — 잘못 이해하면

1) “Thrift를 GraphQL로 바꿔야 한다”고 믿으면

→ Airbnb는 Thrift를 그대로 둔다. GraphQL은 통합층이지 RPC 대체가 아님. 대응: 이미 잘 굴러가는 RPC는 유지, GraphQL은 그 위에 얹는다.

2) “Viaduct = 더 좋은 federation”이라고 단정하면

→ Viaduct는 Airbnb의 운영 패턴에 최적화된 도구다. 일반 회사는 Apollo Federation이 더 적합할 수 있음. 대응: 두 모델의 trade-off를 이해 — Viaduct는 호스팅 통합, Apollo는 open ecosystem.

3) “한 번에 모든 화면을 GraphQL로 옮기자”고 결정하면

→ Airbnb는 *5년+*에 걸쳐 옮겼다. 한 번에는 팀의 학습 곡선·인프라 비용·롤백 위험이 모두 한꺼번에 폭발. 대응: 신규 화면부터. 기존 화면은 비즈니스 가치가 큰 것부터.

4) “Federation 없이 모놀리스 graph 한 평생 가도 된다”고 믿으면

→ 가능하다 — 조직이 작거나 안정적이면. Airbnb처럼 수백 엔지니어 + 도메인 빠르게 늘면 federation이 결국 필요. 대응: 현재 graph schema PR의 평균 리뷰 시간을 본다 — 이게 일주일 넘으면 federation 시기.

5) Apollo Client 없이 직접 fetch + caching하려고 하면

→ Airbnb의 효과는 Apollo Client cache + persisted query + codegen 묶음에서 왔다. fetch만으로는 재발명 비용. 대응: 클라이언트 표준화 — Apollo Client / Relay / urql 중 하나로 통일.

Insight — 흥미로운 이야기

”한 entity씩 옮긴다”

Airbnb의 마이그레이션 단위는 화면이 아니라 entity였다. 예를 들어 Listing이라는 entity를 GraphQL schema로 정의하면 — 그 entity를 쓰는 모든 화면이 한 번에 GraphQL로 옮겨졌다. 화면 단위 마이그레이션은 entity가 여러 화면에 흩어진 경우 어디서 끊는지 애매한데, entity 단위는 경계가 명확하다. 이 단위 선택이 5년 마이그레이션을 무사히 완주하게 만든 핵심 결정.

”BFF의 죽음”

Airbnb의 BFF for X 패턴은 GraphQL 도입 이후 거의 사라졌다. 한 supergraph가 모든 BFF의 책임을 흡수했다 — 화면이 원하는 데이터를 직접 선언하니까 중간 변환 코드가 불필요. Backend-for-Frontend 패턴 자체가 GraphQL을 만나면 사라진다는 패턴이 Airbnb 사례에서 가장 분명히 보인다.

”Viaduct는 Internal-First Open Source”

Viaduct는 2026년 1.0이 처음 외부에 진지하게 공개된 시점이다. 그 전 5년간은 *“Airbnb 내부 도구가 우연히 GitHub에 올라와 있는 상태”*였다. Adam Miskiewicz의 인터뷰(Software Engineering Daily 2026-02-05)는 — *“내부 도구를 진짜 OSS로 만드는 데 5년이 필요했다”*고 회고한다. 오픈소스 = 코드 공개가 아니라 외부 사용자를 받을 수 있는 API + 문서 + governance까지의 과정이라는 점.

”Hacker News 2019 토론”

2019년 *“Airbnb Is Moving Faster at Scale with GraphQL and Apollo”*가 Hacker News 1면에 올랐을 때 — 댓글의 절반은 *“우리도 모놀리스를 못 끊는데 어떻게 해?”*였다. Airbnb의 답이 *“안 끊는다 — 위에 얹는다”*였고, 이게 수많은 중규모 회사의 GraphQL 도입 결정을 가속했다. 한 회사의 사례 글이 생태계 채택 곡선을 바꾼 드문 사례.

요약 + 다이어그램

Airbnb는 Java/Thrift 모놀리스 위에 GraphQL을 5년에 걸쳐 점진적으로 얹었다. Reconciling GraphQL and Thrift 도구로 RPC와 공존, Federation으로 도메인 소유권 분산, Viaduct로 tenant API + 서버리스 호스팅까지 통합. 2026년 1.0 오픈소스 — 내부 도구가 외부 생태계로 나오는 데 5년.

참고 자료

• How Airbnb is Moving 10x Faster at Scale with GraphQL and Apollo (Adam Neary, 2018) — medium.com/airbnb-engineering/how-airbnb-is-moving-10x-faster-at-scale-with-graphql-and-apollo-aa4ec92d69e2
• Reconciling GraphQL and Thrift at Airbnb — medium.com/airbnb-engineering/reconciling-graphql-and-thrift-at-airbnb-a97e8d290712
• Taming Service-Oriented Architecture Using A Data-Oriented Service Mesh — medium.com/airbnb-engineering/taming-service-oriented-architecture-using-a-data-oriented-service-mesh-da771a841344
• Viaduct, Five Years On (Adam Miskiewicz, 2025) — airbnb.tech/data/viaduct-five-years-on-modernizing-the-data-oriented-service-mesh
• Viaduct 1.0 and the future of Airbnb’s data mesh (2026) — medium.com/airbnb-engineering/viaduct-1-0-and-the-future-of-airbnbs-data-mesh-6bab4ec98b89
• Viaduct GitHub — github.com/airbnb/viaduct
• Migrating to GraphQL at Airbnb (InfoQ) — infoq.com/news/2019/12/airbnb-graphql-migration

다음 문서: 06-atlassian-and-others.mdx — 한 회사 깊이 본 뒤, 여러 회사의 다양한 도입 모양을 짧게 훑는다.