▲

한 번 모델링하고 어디서나 표현: Netflix의 UDA (Unified Data Architecture)

 (netflixtechblog.com)
6P by GN⁺ 19시간전 | ★ favorite | 댓글 1개
  • Netflix는 비즈니스 도메인(예: 영화, 배우, 시리즈 등)의 데이터 모델링이 각 시스템마다 중복·불일치·비표준 용어로 인해 협업 및 데이터 품질 문제에 직면함
  • UDA(통합 데이터 아키텍처)는 '한 번 모델링, 어디서나 표현'을 목표로 도메인 개념을 한 번 정의하고, 다양한 시스템에 일관되게 투영·연결하는 지식 그래프 기반 인프라임
  • UDA는 도메인 모델→데이터 컨테이너(예: GraphQL, Avro, Iceberg 등)로 자동 스키마 생성·매핑·데이터 이동 자동화를 지원
  • 비즈니스 사용자는 Sphere·PDM 같은 UDA 활용 도구를 통해, 용어 검색만으로 데이터 탐색·보고서 생성·참조 데이터 관리 가능
  • RDF·SHACL 등 시맨틱 기술 위에 자체 Upper 메타모델을 적용하여 대규모 협업·거버넌스·스키마 일관성·확장성을 모두 달성함

Netflix 시스템의 복잡성 증가와 도메인 모델의 도전 과제

  • Netflix 서비스가 영화, 시리즈, 게임, 라이브 이벤트, 광고 등으로 확대됨에 따라, 이를 지원하는 시스템 복잡성도 크게 증가함
  • ‘actor’, ‘movie’와 같은 핵심 비즈니스 개념이 서로 다른 시스템(Enterprise GraphQL Gateway, 자산 관리 플랫폼, 미디어 컴퓨팅 등)에서 개별적으로 정의되고, 협력이나 공유 없이 분절적으로 운용됨
  • 이로 인해 다음과 같은 문제 발생
    • 중복 및 불일치 모델: 각기 다른 시스템에서 같은 엔터티를 재정의, 충돌 방지 어려움
    • 용어 불일치: 동일한 시스템 내에서도 서로 다른 용어 사용 또는 같은 용어의 중복 사용으로 소통 혼선
    • 데이터 품질 문제: 수많은 마이크로서비스 간 불일치·참조 오류 존재, 식별자나 외부 키 관리도 미흡해 수동 개선 필요
    • 연결성 한계: 시스템 내 관계성 제한 및 시스템 간 연계 미흡
  • 이런 문제를 해결하려면, 한 번 개념 모델 정의 후 모든 곳에서 재사용하고, 실 시스템 및 데이터와 실질적으로 연결·통합하는 기반이 필요함

UDA(통합 데이터 아키텍처) 개요

  • UDA는 Netflix Content Engineering 내 데이터 연결성 기반 플랫폼
  • 도메인 모델(비즈니스 개념)을 한 번 정의하여, 모든 시스템에 일관 투영 및 자동화·발견·시맨틱 상호운용성 지원
  • UDA로 가능한 주요 기능
    • 도메인 모델 등록 및 연결: 공식 개념 정의를 단일 소스로 사용해, 팀 간 혼동·중복 모델링 방지
    • 도메인 모델과 데이터 컨테이너 매핑: 비즈니스 개념과 실제 데이터가 저장된 위치(데이터베이스, 테이블, 서비스 등)와 구조를 쉽게 파악할 수 있도록 그래프 구조로 표현
    • 도메인 모델을 스키마 정의 언어로 변환: GraphQL, Avro, SQL, RDF, Java 등 다양한 시스템별로 자동 변환, 수작업 최소화와 오류 감소 실현
    • 데이터 컨테이너 간 신뢰성 있는 데이터 이동: GraphQL 엔티티, Data Mesh, CDC, Iceberg 등 시스템 간 데이터 변환·이동 자동 처리
    • 도메인 개념 탐색 및 검색: 비즈니스 개념 간 관계를 탐색 및 검색 가능, 정확한 정보 획득 용이
    • 지식 그래프 프로그래밍적 인트로스펙션 제공: Java, GraphQL, SPARQL로 연결된 비즈니스 정보 활용, 자동화 및 인사이트 도출

UDA의 핵심 아키텍처

  • Knowledge Graph 기반

    • RDF/SHACL 기반 지식 그래프로, 도메인 모델·스키마·데이터 컨테이너·매핑 등 모든 요소를 그래프 데이터로 연결
    • 명명된 그래프(named graph) 중심 정보모델로, 각 named graph가 규칙적 거버넌스 모델을 따르고, 해석 체계 및 모듈화, 운영 정책 실현

  • Upper 메타모델

    • Upper는 도메인 모델을 엄격히 정의하는 메타모델 언어
    • 도메인별 키 엔터티/속성/관계를 타입·계층구조로 모델링하며, RDF로 표현·버전 관리·쿼리 가능
    • Upper 자체도 Upper로 모델링(자기참조, 자기유효화)되어 모든 확장·투영에 일관성 제공
    • 속성 값에 대해 도메인별 맞춤 가능하고, 모든 개념은 conceptual RDF 및 named graph로 표현, introspection·검색·버전관리 지원
    • Upper는 고수준 추상화와 함께, RDFS/OWL/SHACL 등 W3C 의미 기술 중 핵심만 엄선 적용, 온톨로지 개념을 몰라도 효과적으로 도메인 모델링 가능
    • Upper 메타모델로부터 Jena 기반 Java API 및 GraphQL 스키마 자동 생성, 실 GraphQL 서비스와 연계

  • 데이터 컨테이너 및 매핑

    • Data Container: 실제 데이터 저장소(예: GraphQL 서비스의 엔티티, Data Mesh 소스의 Avro 레코드, Iceberg 테이블의 행, Java API의 오브젝트 등)
    • 매핑(Mappings): 도메인 모델의 특정 요소와 데이터 컨테이너(테이블, 필드 등) 간의 일대일 연결 정의
    • 매핑을 통해 도메인 개념→실제 데이터 위치 추적, 반대로 데이터→관련 도메인 개념 탐색 가능
    • 의도 기반 데이터 이동/자동화: 매핑 정보를 활용해 데이터 흐름/변환을 시스템이 자동 결정

  • Projections(투영)

    • 도메인 모델→타겟 시스템 스키마(예: GraphQL, Avro 등)로 자동 변환·생성(코드·스키마·파이프라인 자동화)
    • 스키마 일관성 보장, 중복 정의 및 동기화 이슈 최소화

실제 적용 사례

  • PDM(Primary Data Management)

    • 참조 데이터 및 택소노미(계층적 분류체계) 관리 플랫폼
    • 도메인 모델을 계층적 또는 평면 분류로 변환, 비즈니스 사용자를 위한 UI 자동 생성
    • 비즈니스 용어의 일관적인 정의, SKOS 모델 기반, UDA로 Avro·GraphQL 스키마/파이프라인 자동 생성
    • 도메인 모델만 입력하면, UI/데이터 파이프라인/GraphQL API가 자동 구성

  • Sphere(Operational Reporting)

    • 지식 그래프 기반 자가 서비스 운영 리포팅 도구
    • 도메인 용어 기반 검색·탐색·조인 전략 자동화, 기술적 복잡성 없이 데이터 발견/리포트 생성 가능
    • UDA 기반 메타데이터/매핑으로, 실제 데이터 위치와 조인 논리까지 시스템이 자동 파악·실행
    • ‘actor’, ‘movie’ 같은 친숙한 용어로 개념 탐색, 선택된 개념 기반으로 지식 그래프를 따라 SQL 쿼리 자동 생성, 별도 조인이나 기술 작업 없이 데이터 획득 가능

결론 및 전망

  • UDA는 Netflix 데이터 모델링·통합 방식의 근본적 변화를 이끌고 있음
  • 한 번의 도메인 모델 정의로, 조직 전체 시스템이 일관적·자동·확장성 있는 데이터 연동 가능
  • 앞으로 Protobuf/gRPC 등 추가 지원, 지식 그래프 실데이터화 등 적용 범위 확대 예정
▲
GN⁺ 19시간전  [-]
Hacker News 의견

  • 모든 장점에도 불구하고, 이 방식에는 자주 언급되지 않는 큰 문제가 있다는 생각임
    비즈니스 문제이면서 기술 문제에도 영향을 끼치기 때문에 결국 개발 속도에 영향을 미치는 부차적 기술 문제로 작용함
    전체 조직이 하나의 통합 데이터 정의를 신뢰할 수 있다는 계약이 비즈니스에 걸려 있다보니, 이제는 데이터를 정의, 수정할 때 자기 분야뿐만 아니라 조직 전체의 다양한 사용 사례를 고려할 수밖에 없음
    작은 변경조차 조직 전체에 영향을 주므로 다양한 이해관계자의 승인을 거쳐야 할 정도로 복잡한 절차가 생기는 것
    이건 대기업에서 "버튼 색 바꾸는 데 두 달 걸리는 이유"라는 고전적인 문제의 데이터 버전임
    물론 보통 데이터를 복제하거나 일관성 없이 분산시키는 게 더 심각한 문제라는 점은 인정함
    하지만 때로는 작고 고립된 변경을 빠르게 배포하고 싶을 때 이런 시스템이 큰 장애물로 작용함

    • 이걸 해결하려고 제품을 개발해본 적 있음
      기업 공통 모델을 따르면서도 로컬에서 모델을 손쉽게 특화할 수 있게 해주는 방식(프로로그 같은 데이터 정의 언어를 확장하고, 당장 필요한 게 아니라 현실에 기반한 기업 모델을 정말로 고민하는 것)을 시도함
      아쉽게도 NoSQL, Big Data 열풍이 한창일 때 시도해서 타이밍이 좋지 않았음
      NoSQL, Big Data는 느슨한 모델로 운영할 수 있고, 데이터가 일부 유실되거나 오해되어도 나중에 땜질하면 된다는 문화임
      초기에 강력한 모델을 설계하기보다 뒷수습이 쉽다는 분위기이고, 조금 아쉽지만 받아들였음

    • 본질적으로 비즈니스 문제라는 데 동의하고, 우리는 기술로 이걸 체계적으로 풀 수 있다고 봄
      엔터프라이즈 내에서 모델-퍼스트 지식 그래프를 도입, 배포하는 더 체계적인 방법을 마련했다는 자신감이 있음
      UDA는 요청받는 모든 것을 오히려 추가적인 관료적으로 만들지 않도록 신중히 접근함
      UDA는 기존 시스템과 나란히 존재하며 무조건 수용을 강요하지 않음
      하지만 자신들의 비즈니스 모델이 어디에서나 활용되고 쉽게 연결, 확장, 발견될 수 있게 하고 싶은 팀에게는 강력하고 쉬운 도구가 되게끔 하려 함
      (본인은 UDA 아키텍트 중 한 명임을 밝힘)

    • 경험상 회사 내 "큰 사람(big men)"의 주장 때문에 논리적이거나 일관된 데이터 모델이 만들어지지 않는 경우가 많았던 기억
      실무 기술자들이 데이터를 좀 더 합리적이고 표준에 맞게 다루려 해도, 영향력 있는 인물이 직접 머릿속 모델을 만들어서 개발자가 맞추도록 강요하는 현실
      이런 상징적인 사고방식이 한 번 들어서면, 그 회사에서 일관된 데이터 모델이 만들어질 가능성은 0에 수렴함
      결국 이런 문제 때문에 컨설턴트들에게 비효율적으로 많은 돈이 지불되는 구조라고 봄

    • SAP가 뭔지 오랫동안 궁금했다가, 실제로 알게 된 후 놀랐던 경험이 있음
      수많은 기업에서 SAP를 쓴다고 해서 엄청난 기술력이 있나 추측했었지만, 실제로는 고정된 스키마를 두고 고객에게 그 구조에 맞춰 적응하라고 요구하는 방식임을 알게 됨

    • 원문에서는 비즈니스 문제라는 점을 부정한다고 읽히지 않음
      정의된 모델들은 모든 역할에 걸쳐서 정의하며, 엔지니어링은 그 일부일 뿐이라는 관점

  • Semantic Web, RDF, OWL, SKOS 등 등장 시점보다 꽤 시간이 흘렀다는 생각
    W3C를 계속 지지하고, 이미 있는 바퀴를 다시 만들지 않은 것이 좋았음
    UDA 방식이 대중적으로 자리잡을지 모르겠지만, 조직 규모가 큰 곳에 DDD(도메인 주도 설계)와 시맨틱 개념을 적용할 때 어려움을 혁신적으로 줄이려는 시도라 기대감
    여러 개발팀에 같은 데이터 의미 체계를 공유하는 공통 도구와 기술셋을 제공해 ‘복리(compound interest)’ 효과를 도모할 수 있다면, 데이터 계약을 DTO, POST 등 네트워크 전송 때문에 억지로 평준화시키지 않아도 될 수도 있다는 점 흥미로움
    이런 흥미로운 실험을 공개하면서 추진하는 Netflix에 긍정적 시각

  • Uber에서 Dragon이라는 프로젝트가 떠오름
    Dragon schema at Uber 관련 작업을 했었으나 오픈소스화되지는 못함
    이후 Joshua가 LinkedIn으로 옮겨 LambdaGraph 프로젝트, Hydra 언어에 참여했고, 이들은 여기에서 오픈소스로 공개됨
    이러한 방식이나 10년 전 Semantic Web 흐름은 모두 개념을 공식화하고 유지해야 하는 부가 작업량이 너무 많았던 게 단점
    요즘은 LLM(대형 언어모델)로 이런 부담을 줄일 수 있을지 궁금증

  • 이번에 쓰인 ‘도메인 모델’이라는 용어 선택이 아쉬운 점
    여기서의 도메인 모델은 순전히 데이터 중심 개념인데, 실제 도메인 모델링은 데이터 구조보다는 행동(Behavior)에 대한 집중이 본질
    도메인 모델의 데이터는 행동을 가능하게 하려고 존재하는 역할이고, 행동 자체가 코드의 중심
    데이터 모델링을 관점에 따라 다양하게 표현하는 것 자체에 복잡함이 있지만, 이런 차이점은 오히려 기능으로 볼 수도 있다고 생각
    모든 상황에 똑같은 복잡성이나 세밀함이 요구되는 건 아니며, 표현 모델은 읽기 시나리오에 최적화하는 게 일반적임
    이런 방식을 사용하면 정보의 상황별 취급보다는 통일성에 더 치우칠 수 있고, 도메인 이해도가 높은 환경에는 확장성이 나을 수도 있지만, 실제로는 복잡 또는 미묘한 도메인 모델을 단순화하지 않으면 대부분의 사용 사례가 어려워진다는 경험

  • “이런 시도로 5% 이상 혹은 500만 달러 이상의 수치적인 비즈니스 개선이 나타난 사례를 본 적 있냐”는 질문
    데이터 테이블을 통합하려는 시도를 여러 번 경험했지만 실제로는 서로 다른 분석이 필요하면 테이블 통합이 의미 없었고, 다양한 분석이 여전히 각각 독립적으로 이루어졌음
    즉, 모두가 원하는 분석 방식에 맞춰 베이스 레이어를 통합해도 여전히 서로 다른 분석이 계속 별개로 진행됨
    그래도 이번 시도는 모든 것을 하나로 통합하게 만들진 않고, 폭넓은 접근의 용이성을 높이려는 것 같아서 현명해 보임
    공식적인 비즈니스 개념 정의를 모두가 통일해 혼란을 줄이려는 목적에는 깊이 공감함

    • “서로 다른 분석을 하는 팀들이 같은 정보를 다룬다고 해서 반드시 같은 사물이어야 하는 건 아니라는 점”에 크게 공감
      예를 들어, 모두가 마스터 프리즌 리스트를 원한다고 해도, 프리즌이 건물 자체인지, 수감자 집합(같은 부지 내 남·여 프리즌이 구분된 독립체)인지, 특정 계약으로 운영되는 기관인지는 정의에 따라 완전히 다름
      이런 점에서 조직의 관점마다 미묘하게 다른 객체를 필요로 함

  • 도메인 주도 설계(DDD)와 어떤 관련이 있는지 궁금
    DDD에서는 동일한 개념조차 시스템마다 다르게 표현될 수 있다는 걸 전제로 하지 않나 생각
    하지만 글 자체는 UML 느낌 때문에 끝까지 읽진 않음

    • upper:DomainModel에서의 Domain이 DDD의 D(도메인)과 동일함, DGS(Domain Graph Service)도 마찬가지
      DDD에서는 동시에 동일 개념이라도 시스템별로 표현 방식이 다름을 허용하지만, UDA에서는 각 도메인에 이런 다양한 개념이 명시적으로 공존하도록 설계
      “같음”이라는 개념이 주관적이 됨

    • "ubiquitous language(공통 언어)"라는 용어를 쓰지 않은 게 오히려 다행
      이 개념은 이번 시도와 완전히 반대되는 개념
      관련된 개념만 듣고 깊이 들여다본 적 없는 사람들은 차이점을 모를 수도 있음

  • Netflix 엔지니어링이 왜 Medium에 콘텐츠를 올리는지 의문
    Medium의 팝업 등으로 독자를 쉽게 잃는 상황인데, 그런 리스크를 감수할 가치가 있는지 궁금

    • hex로 된 Medium URL을 볼 때마다 scribe.rip을 통해 읽는 재미가 있음
      scribe.rip UDA 아티클

    • 마케팅팀이 이를 운영한다면 SEO까지 포함한 전략일 가능성

    • Medium이 주는 ‘발견’(discovery) 효과는 실제로 있음
      그리고 Medium에 글을 쓰는 스타일의 엔지니어들이 Netflix가 리크루팅하고 싶은 인재군일 가능성

    • 자체적으로 블로그를 관리하지 않아도 되어서 더욱 편리

  • 데이터 모델의 버전 관리 혹은 브레이킹 체인지에 어떻게 대응하는지 궁금
    모델을 더 분리해서 운영할 때는 기존 방식대로 조각 단위로 쉽게 고칠 수 있는데, 이런 통합 모델에서는 어떻게 하는지 의문
    Netflix 방식에서는 새로운 모델을 추가한 뒤 이전 모델은 점진적으로 사용 중단시키는 식일 것으로 추정

    • 버전 관리는 ‘깨도 되는 권한’을 부여하는 것과 같음
      UDA에서는 아직 완전히 구현은 안 됐지만 Federated GraphQL과 동일한 방식을 적용할 계획
      Federated GraphQL에서 검증된 deprecation 관리 모델을 도입할 예정이며, 500개 이상의 페더레이티드 GraphQL 스키마를 성공적으로 관리한 경험이 있음
      핵심은, projected models의 소비자를 추적하면서 deprecated 주기를 능동적으로 관리하는 로드맵임

  • 통합 그래프를 성공시키려면 비즈니스, 커뮤니케이션, 기술 세 가지 모두 해결해야 한다고 체감
    커뮤니케이션 문제는 ‘자율적인 팀의 은근한 독립성’을 깰 필요가 있음
    각 팀을 넘나드는 다리 역할을 하며, 데이터 모델도 분석해 줘야 함
    단순 스키마 공유만으로는 부족하고, 직접 사람들과 인터뷰하면서 협의하는 과정이 꼭 필요
    기술적 측면은 오히려 가장 쉽고, Microsoft Graph처럼 ‘두꺼운 스키마’를 강제 적용하면 간단
    이 과정엔 상당한 공감능력, 인내심이 필요함
    기술 해결은 경영진의 확고한 의사결정 및 실행 권한이 필수이고, 팀별로 자유롭게 움직일 수 있으면 어떤 아이디어도 소용 없음
    비즈니스 측면이 최상위 난이도
    20년 최적화된 프로세스와 용어를 한번에 바꾸는 건 사실상 불가능에 가까움
    결국 전사적인 buy-in이 완벽하게 이뤄져야만 이 어마어마한 일이 ‘평생에 걸쳐’ 투자 가치가 있음

  • 공통 어휘의 도입이 매우 유의미하다고 믿음
    하지만 기업 전체, 신규 인수, 다양한 비즈니스 프로세스, 시간축 등 조직이 넓어질수록 점점 어려워짐
    시스템 두 개만 연동하는 인터페이스 정도야 뚝딱 만들 수 있겠지만, 한 엔터프라이즈에 여러 레이어가 존재하고, 모든 지식을 카탈로그에 담는 이상적인 DB를 누가 만들고 계속 유지할 수 있을지는 의문
    성공적으로 남은 시도는 대부분 매우 추상적으로 운영하거나 특정 사용 사례에만 범위를 제한한 방식임

    • 경험적으로, 기업 전체 엔티티(예: 회사의 공식 개체)를 정의해도 각 부서별로 이걸 확장해야 할 필요가 생기며, 새로운 속성을 모든 부서에서 쓸 수 있게 할지, 해당 부서만 쓸지 등 정치적·낙관적 결정이 필요하게 됨
      공식 엔티티를 업데이트하면 전체 영향을 평가하며 철저한 체인지 관리가 필요
      올바르게 잘 구축하고, 엄격한 조직 문화가 뒷받침된다면 비용과 마찰이 크게 줄 수 있고, Netflix라면 가능성 있어 보임

    • 살아남은 유일무이한 대규모 공통 어휘 예시로 Wikidata 언급
      16억 5천만 개 그래프 노드가 표준 어휘 아래 계속 확장되고 있음

답변달기