04 — Netflix Studio Edge

한 줄 답: Netflix는 스튜디오 백오피스 50~60개 앱을 한 supergraph로 묶기 위해 Apollo Federation을 최대 규모로 운영한다. 그 도구로 DGS framework(Domain Graph Service)를 만들어 오픈소스로 풀었다. Federation이 조직 규모가 만드는 문제의 해답임을 가장 분명히 보여주는 사례.

Why — 왜 Netflix가 Federation의 표본인가

Netflix는 두 GraphQL을 운영한다 — Consumer (netflix.com/앱) 쪽과 Studio Edge(콘텐츠 제작·운영) 쪽. 이 챕터가 다루는 것은 Studio Edge다 — 내부 운영이지만 조직·기술 규모는 공개 API 못지않게 크다.

Netflix의 사례는 Federation이 어떤 조직 사이즈부터 의미가 있는지를 가르친다 — 수십 도메인 팀 + 단일 그래프 통합 요구가 동시에 있을 때.

How — 어떻게 운영하나

1) Studio Edge 아키텍처 (Apollo Federation)

공개된 수치 (Netflix Tech Blog 2020-12 / 2021-09 / Apollo blog):

• 150 subgraphs
• 3,000+ types
• 2,800+ queries and mutations
• 50~60 internal apps가 단일 supergraph 소비
• 한 supergraph가 조직 절반 이상의 데이터 모델을 통합

2) Federation 도입 동기 — Conway’s Law

InfoQ presentation(infoq.com/presentations/netflix-api-graphql-federation)에서 Netflix 엔지니어들이 명시한 동기:

“우리는 federation을 기술이 좋아서 선택한 게 아니라, 조직이 너무 커서 단일 schema를 한 팀이 소유할 수 없게 됐기 때문에 선택했다” — Netflix 컨퍼런스 토크의 반복 메시지.

이게 Conway’s Law의 GraphQL 버전이다 — 소프트웨어 아키텍처는 조직 구조를 반영한다. Netflix는 100명 단위로는 모놀리스 graph가 충분했고, 1,000명 단위로 federation이 필수가 됐다.

3) DGS Framework — Subgraph Authoring

Netflix는 subgraph를 Java/Kotlin + Spring Boot로 쓴다. 이를 위해 만든 프레임워크가 DGS (Domain Graph Service).

@DgsComponent
class ProductionFetcher(val service: ProductionService) {
 
    @DgsQuery
    fun production(@InputArgument id: String): Production? =
        service.findById(id)
 
    @DgsData(parentType = "Production", field = "talents")
    fun talents(dfe: DgsDataFetchingEnvironment): List<Talent> {
        val production = dfe.getSource<Production>()
        return talentService.findByProduction(production.id)
    }
}

핵심 특징 (netflix.github.io/dgs):

• 어노테이션 기반 — @DgsQuery, @DgsMutation, @DgsData, @DgsEntityFetcher
• graphql-java 위에 Spring Boot 통합
• Federation v2 지원 — @key, @external, @requires, @provides 자동 처리
• Code generation — schema → Java/Kotlin types (Gradle plugin)
• Testing framework — DgsQueryExecutor로 단위 테스트

오픈소스 타임라인:

외부 회사가 Netflix 규모가 아니어도 DGS를 쓰는 이유 — Spring Boot 생태계에서 Federation을 가장 쉽게 운영할 수 있는 도구.

4) GraphOS / Apollo Studio 운영

Netflix는 Apollo의 managed federation 제품(GraphOS, 옛 Apollo Studio)을 사용한다.

Schema registry가 조직의 절반 이상이 의존하는 API 계약을 관리한다 — production 변경의 single source of truth.

5) Federation v2 도입

Netflix는 Federation v1 → v2 마이그레이션 사례도 공개했다 (Apollo blog apollographql.com/blog/an-unexpected-journey-how-netflix-transitioned-to-a-federated-supergraph).

Netflix가 수십 도메인 팀의 동시 마이그레이션을 1년에 걸쳐 완료한 경험이 v2 spec 자체에 영향을 줬다.

What — 구체 사양

공개 수치 종합

Studio Edge가 Consumer Edge와 다른 점

같은 회사 안에서도 두 graph 모델이 다른 문제를 푼다.

DGS framework 채택 외부 사례 (공개 사용자)

DGS GitHub README에 나열된 채택 회사 (자발적 보고):

• IKEA
• Trustpilot
• Snipcart
• Atlassian (일부 팀)
• (지속 추가, github.com/Netflix/dgs-framework)

→ Spring Boot Java 생태계의 federation 표준 도구로 자리잡음.

What-if — 잘못 이해하면

1) “우리도 Netflix처럼 federation 가자” (50명 조직에서)

→ Federation은 조직 분할 + 단일 인터페이스 요구가 동시에 있을 때 의미가 있다. 50명이면 한 graph 한 팀이 더 빠름. 대응: 50~100명 사이는 모놀리스 graph + 모듈 분리, 200명 이상부터 federation 검토.

2) “DGS를 쓰면 federation이 공짜가 된다”고 믿으면

→ DGS는 subgraph 작성을 쉽게 한다. supergraph 운영(composition·schema check·router 튜닝)은 별도 인프라. 대응: Federation 도입은 subgraph 도구 + supergraph 도구 두 축을 함께 준비.

3) Federation v1 그대로 production에 두면

→ v1은 2023년 deprecated. composition 규칙이 약하고 v2의 @shareable/@override 같은 마이그레이션 도구가 없다. 대응: v2로 마이그레이션 (Apollo Router는 두 버전 모두 지원).

4) Schema registry 없이 수동 composition하면

→ subgraph 한 팀의 깨진 변경이 전체 supergraph를 다운시킴. CI에서 rover subgraph check가 필수. 대응: Schema registry는 federation의 안전벨트 — 빠뜨리지 말 것.

5) DGS 코드 생성을 옵션으로 두면

→ Schema와 Java types이 수동 동기화되면 drift가 발생한다. 대응: Gradle code-gen plugin을 빌드 파이프라인에 박아 둠.

Insight — 흥미로운 이야기

”한 번에 federation 한 게 아니다”

Apollo blog의 *“An Unexpected Journey”*에 나오는 디테일 — Netflix는 Studio Edge를 처음부터 federated로 만들지 않았다. 처음엔 모놀리스 GraphQL gateway였고, 그것이 팀 사이의 머지 충돌, schema PR 큐, 단일 deploy 단위로 깨지기 시작했을 때 어쩔 수 없이 federation으로 갔다. 즉 federation은 예측해서 선택한 게 아니라 압력에 의해 선택되었다 — 반대 방향으로 가는 결정을 한 사람이 거의 없다는 사실이 의미심장.

”Self-service adoption까지 1년”

Apollo blog 인용 — “Netflix spent a year building core platform capabilities before achieving self-service adoption”. 즉 처음 1년은 플랫폼 팀이 도메인 팀의 subgraph를 수동으로 받아주는 단계였고, 1년 뒤에야 도메인 팀이 자력으로 subgraph를 만들고 deploy하게 됐다. 외부 회사가 federation을 도입할 때 이 1년의 플랫폼 비용을 모르면 기술이 안 좋아서 실패했다고 오해한다.

”Productivity multiplier”라는 표현

Netflix 엔지니어들이 반복적으로 쓰는 표현 — “GraphQL and Federation have been a productivity multiplier.” 곱셈이라는 단어가 중요하다. 덧셈이 아니다. 100명 팀이 200명 팀으로 늘 때 생산성이 1.5배가 아니라 1.0배 미만으로 떨어지는 게 보통인데, federation이 팀별 독립 + 통합 인터페이스를 동시에 줘서 조직 확장의 비용 곡선을 평탄하게 만들었다는 회고.

”Consumer Edge는 다른 graph”

자주 헷갈리는 부분 — Studio Edge(이 문서가 다루는 것)와 Consumer Edge(netflix.com 앱)는 다른 graph다. Consumer Edge는 수억 동시 사용자를 받기 때문에 trade-off가 완전히 다르다 (캐시·CDN·persisted query 중심). Netflix는 같은 회사 안에서 두 graph 운영 모델을 모두 가진 매우 드문 사례다 — Federation을 어디 쓰고 어디 안 쓰는지의 살아있는 비교.

요약 + 다이어그램

Netflix Studio Edge는 Federation 운영의 최대 사례다 — 150 subgraphs, 3,000+ types, 50~60 consumer apps. Conway’s Law의 압력에서 출발해 DGS framework를 오픈소스로 풀고, GraphOS schema registry로 변경을 통제한다. Federation v1 → v2 마이그레이션까지 공개해 spec 자체에 기여.

참고 자료

• How Netflix Scales its API with GraphQL Federation (Part 1) — netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2
• How Netflix Scales its API with GraphQL Federation (Part 2) — Netflix TechBlog
• Open Sourcing the Netflix DGS Framework — netflixtechblog.com/open-sourcing-the-netflix-domain-graph-service-framework-graphql-for-spring-boot-92b9dcecda18
• An Unexpected Journey: How Netflix Transitioned to a Federated Supergraph — apollographql.com/blog/an-unexpected-journey-how-netflix-transitioned-to-a-federated-supergraph
• Redefining API Strategy: Why Netflix Platform Engineering Chose Federated GraphQL — apollographql.com/blog/redefining-api-strategy-why-netflix-platform-engineering-chose-federated-graphql
• DGS Framework documentation — netflix.github.io/dgs
• DGS Framework GitHub — github.com/Netflix/dgs-framework

다음 문서: 05-airbnb-supergraph.mdx — Netflix의 처음부터 큰 federation과 다른, Airbnb의 모놀리스에서 점진 federation 사례.