06 — Atlassian and Others

한 줄 답: 한 회사 깊이 본 뒤, 다섯 사례를 짧게 훑는다. Atlassian(멀티 프로덕트 게이트웨이), PayPal(신규 앱부터), Coursera(1000개 REST 통합), Twitter(내부만 쓰고 공개는 REST), AWS AppSync(관리형 서비스). 같은 도구가 조직 사정에 따라 다섯 가지 모양으로 도입된다는 증거.

Why — 왜 짧은 사례들을 한 챕터에 모으는가

앞 5개 사례(Meta·GitHub·Shopify·Netflix·Airbnb)는 전형적 도입 패턴 5개를 보여준다. 하지만 현실의 GraphQL 도입은 그보다 다양하다. 이 챕터는 5개의 짧은 사례를 모아 변이의 폭을 보여준다.

다섯 사례를 분류표에서 보면 — 같은 도구가 얼마나 다른 모양으로 자라는지 보인다.

How — 5개 사례 빠르게

1) Atlassian — 멀티 프로덕트 단일 GraphQL Gateway

상황: Atlassian은 Jira, Confluence, Trello, Bitbucket 등 여러 SaaS 프로덕트를 운영한다. 각 프로덕트는 자체 REST API를 가졌고, 통합 사용자는 수십 API를 학습해야 했다.

해법: api.atlassian.com/graphql 단일 endpoint로 모든 프로덕트 데이터를 통합 게이트웨이.

핵심 특징 (developer.atlassian.com/platform/atlassian-graphql-api):

의미: 멀티 프로덕트 SaaS가 통합 API 표면을 만들 때 GraphQL이 가장 빠른 길. Confluence GraphQL API는 베타로 점진 추가되며 — Atlassian이 GitHub 패턴(preview)을 차용.

돌아갈 챕터: 06-federation — Atlassian 내부는 federation 또는 schema stitching (정확한 구현은 비공개).

2) PayPal — 신규 앱 + Checkout부터 점진 확산

상황: PayPal은 수백 개 내부 앱과 Checkout flow를 운영한다. UI 개발자가 시간의 2/3을 데이터 페치 코드에 쓰고 있었다.

해법: Checkout 팀이 처음으로 GraphQL 도입 (2018). 효과가 보이자 전사 확산.

타임라인 (medium.com/paypal-tech/graphql-at-paypal-an-adoption-story-b7e01175f2b7):

핵심 결정:

• Checkout이 증명자 — 가장 critical한 앱에서 효과를 본 뒤 확산
• 명명·헤더·directive 사내 표준 — 모든 팀이 같은 규약
• 공유 라이브러리 + 템플릿 — 새 팀이 zero-to-graph 빠르게

의미: 전사 mandate 없이 한 critical 앱에서 효과 → 자발적 확산. 수백 명 조직에서 가장 현실적인 도입 경로.

돌아갈 챕터: 08-theory-and-alternatives (REST와의 비교), 07-security-governance (사내 표준 만들기)

3) Coursera — 1000개 REST 위의 GraphQL

상황: 2016년 Coursera는 1000개 이상의 REST endpoint를 가지고 있었다. 새 화면을 그리려면 수십 호출 오케스트레이션 + 변환 코드가 필수.

해법: REST endpoint를 지우지 않고, 그 위에 GraphQL layer를 얹음.

타임라인 (medium.com/coursera-engineering):

Coursera가 만난 후기 문제 (2019, Evolving the Graph):

의미: GraphQL 도입 후 5년쯤에 만나는 schema 거대화 문제를 가장 일찍 공개한 사례. Netflix·Airbnb의 federation 도입 결정에 영향을 줬다.

돌아갈 챕터: 06-federation (schema 거대화의 답), 07-security-governance (schema governance)

4) Twitter — 내부 GraphQL · 공개 REST

상황: Twitter는 2017년부터 내부에서 GraphQL 사용 (X.com 엔지니어링 블로그, blog.x.com/engineering/en_us/topics/infrastructure/2020/rebuild_twitter_public_api_2020). 웹·iOS·Android가 모두 GraphQL endpoint를 호출한다.

그러나 공개 API는 REST:

Twitter의 결정 이유 (블로그 인용):

“When considering exposing GraphQL directly to external developers, Twitter opted for a design most familiar to a broad set of developers in the form of a REST API.”

즉 — 내부는 GraphQL의 효율을 즐기지만, 외부 개발자에겐 학습 곡선이 낮은 REST를 제공.

의미: 공개 API의 선택은 기술 우월성이 아니라 개발자 친숙도가 결정. 모든 회사가 GitHub처럼 공개 GraphQL을 가야 하는 건 아니다.

흥미로운 부수효과 — Twitter 내부 GraphQL endpoint(SearchTimeline 등)는 역공학 커뮤니티가 추적해서 사용한다. 내부 API를 공개로 둘 때의 위험을 보여주는 사례.

돌아갈 챕터: 08-theory-and-alternatives (REST와의 trade-off)

5) AWS AppSync — 관리형 GraphQL 플랫폼

상황: AWS는 managed GraphQL 서비스로 AppSync를 운영한다. 사용자가 서버를 운영하지 않고 GraphQL API를 받는 PaaS.

특징 (aws.amazon.com/appsync):

핵심 가치: graphql-js 운영 인프라를 안 짜고도 GraphQL API를 받는다. 서버리스 + GraphQL의 결합.

한계:

• VTL이 학습 곡선 가팔라서 JS resolver로 점차 이전
• Federation 지원이 제한적 (merged API는 2023년 발표, federation v2와 다름)
• cost optimization이 직접 운영보다 예측 어려움

의미: 작은 팀 + AWS 생태계에 갇혔다면 가장 빠른 GraphQL 시작점. Netflix·Airbnb 같은 전사 그래프 운영에는 부적합.

돌아갈 챕터: 04-transport (관리형 transport 옵션)

What — 5개 사례 비교표

What-if — 잘못 이해하면

1) “Atlassian처럼 멀티 프로덕트 gateway를 만들자”고 세 프로덕트 회사에서

→ 멀티 프로덕트 gateway는 5개 이상 + 외부 통합 개발자가 많을 때 가치가 큼. 3개면 프로덕트별 GraphQL endpoint도 충분. 대응: gateway는 통합 사용자 수가 크리티컬 매스를 넘었을 때 도입.

2) “PayPal처럼 Checkout 같은 critical 앱에서 시작” — 그런데 실험 환경 없이

→ Critical 앱 = 실패하면 매출 즉시 타격. PayPal은 demo 앱 → critical 앱의 2단계 검증을 거쳤다. 대응: low-stake 앱에서 몇 달 실험 → high-stake 앱으로 이전.

3) Coursera의 7,000 types 위기를 미리 막을 수 있다고 믿으면

→ 5년 뒤 위기는 5년 동안의 도메인 확장의 결과. 예방보다 조기 감지 도구(field usage 추적)를 둠. 대응: schema registry + operation analytics를 처음부터 켜 둠.

4) “Twitter처럼 내부 GraphQL을 완전히 비공개로 둘 수 있다”고 믿으면

→ 클라이언트가 호출하는 endpoint는 네트워크 캡처로 노출된다. 내부 vs 공개의 경계는 정책이지 기술이 아니다. 대응: 내부 endpoint도 인증·서명·persisted query로 공격 면적 최소화.

5) AppSync를 큰 graph 운영에 쓰려고 하면

→ AppSync는 작은~중간 graph에 최적화. 100+ types, 다도메인이 되면 VTL 관리 + federation 제한에서 깨짐. 대응: 큰 graph는 Apollo Router + 자체 subgraph가 결국 더 싸다.

Insight — 흥미로운 이야기

”Twitter의 역공학 GraphQL 클라이언트 생태계”

Twitter 내부 GraphQL endpoint(SearchTimeline 등)는 공식 공개가 아니지만 브라우저 개발자도구로 추적 가능하다. 그 결과 GitHub에 Twitter GraphQL 역공학 라이브러리가 다수 등장(fa0311/TwitterInternalAPIDocument 등). Twitter는 주기적으로 GraphQL query ID·signing 알고리즘을 바꿔 차단하고, 커뮤니티는 다시 추적한다 — 무한 cat-and-mouse. 내부 API의 보안은 인증·서명·rate limit 외엔 사실상 없다는 교훈.

”PayPal Checkout이 증명자가 된 이유”

PayPal의 Checkout은 Stripe·Adyen 등과 경쟁하는 critical flow다. 거기서 GraphQL이 개발 속도를 올려준 것이 경영진을 설득하는 가장 강력한 증거가 됐다. 기술 도입은 작은 실험으로 시작해야 한다는 통념과 반대로 — 큰 효과를 빠르게 보여줄 수 있는 critical 앱에서 시작하는 게 전사 확산 속도에 가장 유리. 단 실패 비용을 감당할 백업 계획이 있다는 조건.

”Atlassian과 GitHub의 서로 다른 통합 모델”

Atlassian은 여러 프로덕트(Jira·Confluence·Trello)를 하나의 GraphQL gateway로 묶었다. GitHub은 한 프로덕트의 모든 도메인을 하나의 GraphQL schema로 묶었다. 둘 다 통합 표면이지만 경계가 다르다 — Atlassian은 프로덕트 사이의 통합, GitHub은 프로덕트 내부의 통합. 멀티 프로덕트 SaaS면 Atlassian 패턴, 단일 프로덕트면 GitHub 패턴.

”Coursera의 7000 types가 발표된 게 더 중요”

Coursera가 문제를 공개하지 않았다면, 다른 회사들이 같은 5년 후에 같은 문제를 처음부터 다시 발견했을 것이다. Evolving the Graph(2019)가 Netflix·Airbnb의 federation 결정에 공식 인용된 자료가 됐다. 기술 블로그가 생태계 학습 곡선을 압축하는 가장 분명한 예.

”AppSync = AWS의 GraphQL 흡수”

AppSync는 AWS가 GraphQL을 자기 PaaS 메뉴에 흡수한 사건이다. 이게 의미 있는 이유 — GraphQL이 PaaS 메뉴에 오르는 순간, 서버 안 짜는 회사들도 도입 가능해진다. AppSync 등장 전엔 GraphQL = 자체 서버 운영이었는데, 2017년 AppSync 발표 이후 GraphQL의 채택 곡선이 더 평평해졌다. 관리형 서비스가 도입 장벽을 낮춘다는 일반 법칙의 GraphQL 사례.

요약 + 다이어그램

다섯 사례는 같은 도구의 다섯 모양을 보여준다. Atlassian은 프로덕트 사이의 통합, PayPal은 critical 앱부터 점진, Coursera는 REST 위의 layer, Twitter는 공개는 REST 유지, AppSync는 관리형 PaaS. 어느 모양이 옳다가 아니라 문제 모양에 따라 선택한다는 것이 핵심.

참고 자료

• Atlassian GraphQL API — developer.atlassian.com/platform/atlassian-graphql-api
• Bringing you new Confluence GraphQL APIs in Beta — blog.developer.atlassian.com/bringing-you-new-confluence-graphql-apis-in-beta
• GraphQL at PayPal: An Adoption Story — medium.com/paypal-tech/graphql-at-paypal-an-adoption-story-b7e01175f2b7
• Scaling GraphQL at PayPal — medium.com/paypal-tech/scaling-graphql-at-paypal-b5b5ac098810
• Coursera’s Journey to GraphQL — apollographql.com/blog/courseras-journey-to-graphql-a5ad3b77f39a
• Evolving the Graph (Coursera) — medium.com/coursera-engineering/evolving-the-graph-4c587a4ad9a8
• Rebuilding Twitter’s public API — blog.x.com/engineering/en_us/topics/infrastructure/2020/rebuild_twitter_public_api_2020
• AWS AppSync — aws.amazon.com/appsync / docs.aws.amazon.com/appsync/latest/devguide/what-is-appsync.html

다음 문서: 07-patterns-distilled.mdx — 여섯 사례에서 공통 패턴과 분기점을 추출하는 결정 트리.