들어가며: 데이터 플랫폼의 스케일이 만드는 두 가지 고통

넷플릭스의 데이터 플랫폼은 어마어마한 규모입니다. 수백만 개의 테이블, 수만 개의 예약된 워크플로우가 매일 실행됩니다. 이 모든 자산 뒤에는 엔지니어, 팀, 이니셔티브가 있고, 그 뒤에는 '누가 무엇에 접근할 수 있는가', '워크로드는 어떤 권한으로 실행되는가'라는 근본적인 질문이 있습니다.

전통적인 방식은 개별 자산 단위로 접근 제어를 관리하는 것이었습니다. 모든 테이블에는 자체 ACL(Access Control List)이 있었고, 모든 워크플로우는 작성자의 신원으로 실행되었습니다. 하지만 인력이 유동적인 환경에서 이 세분화된 모델은 두 가지 방식으로 무너졌습니다.

문제 1: 조직 변경을 따라잡지 못하는 권한 팀이 수백 개의 테이블을 소유하고 있다고 가정해봅시다. 조직 개편으로 이웃 팀이 합쳐져 또 수백 개의 테이블을 인수했습니다. 이제 모든 테이블의 ACL을 찾아서 누가 접근 권한을 가져야 하는지 파악하고, 하나씩 업데이트해야 합니다. 이걸 회사의 모든 팀, 모든 개편에 대해 반복해야 합니다. 결과는 두 가지입니다:

  • 지원팀이 일에 파묻힙니다. 지원 요청의 상당 부분이 조직 변경에 따른 대량 테이블 권한 업데이트입니다. 셀프 서비스 도구가 있지만 준수율이 일관되지 않습니다.
  • 접근 권한이 지나치게 광범위해집니다. 세분화된 ACL을 유지하기보다 팀 전체에 테이블 접근을 열어버리는 경우가 많습니다. 이러면 ACL의 존재 의미가 사라집니다.

문제 2: 인간 신원에 묶인 워크로드 예약 및 비동기 워크로드(Maestro 워크플로우, 데이터 이동 작업, Spark 파이프라인 등)는 실행될 신원(identity)이 필요합니다. 전통적으로는 인간, 즉 워크플로우를 작성한 엔지니어의 신원을 사용했습니다.

인간의 신원은 지속적이지 않습니다. 사람들은 팀을 옮기고, 역할이 바뀌고, 퇴사합니다. 그러면 해당 신원으로 실행되던 워크플로우가 실패하기 시작합니다. 해결책은 동료의 신원으로 교체하는 것인데, 동료는 다른 권한을 가지고 있어 '권한 두더지 잡기' 게임이 시작됩니다. 그리고 결국 그 동료도 떠나고, 사이클이 반복됩니다.

Netflix data platform server racks representing massive scale of data assets System Abstract Visual

Data Projects: 문제의 정수(正數)를 해결하다

넷플릭스는 Data Projects라는 개념을 도입했습니다. 핵심은 단순합니다. 개별 자산이 아니라 의미 있는 컨테이너(프로젝트) 단위로 관리를 올리는 것입니다.

Data Project는 두 가지로 구성됩니다:

  1. 관련 자산을 그룹화하는 컨테이너: 테이블, 워크플로우 등 관련 데이터 자산을 하나의 논리적 우산 아래 묶습니다.
  2. 합성되고 지속 가능하며 가정 가능한(assumable) 신원: 비동기 및 예약 워크로드가 인간의 생애주기와 무관하게 실행될 수 있는 신원입니다.

쉽게 말해, 500개 테이블의 권한을 각각 관리하는 대신, 그 500개 테이블을 포함하는 하나의 프로젝트에 대한 권한만 관리하면 됩니다.

Grants와 Roles

각 Data Project는 소유 팀이 관리하는 일련의 Grant를 가집니다. 다양한 신원 유형(사용자, 그룹, 애플리케이션, CI 작업)을 Grant로 추가할 수 있으며, 각 Grant는 프로젝트 내에서 수행할 수 있는 작업을 결정하는 Role을 가집니다. 예를 들어, Contributor는 읽기/쓰기 권한, Viewer는 읽기 전용 권한을 가집니다. 누군가 팀에 합류하거나 떠날 때 수백 개의 ACL을 다시 쓰는 대신, 하나의 프로젝트 Grant만 업데이트하면 됩니다.

Identity Umbrella: Netflix IAM과의 통합

모든 Data Project는 Netflix 애플리케이션 신원과 AWS IAM 역할(선택 사항)로 프로비저닝됩니다. 이것이 워크로드를 지속 가능하게 만드는 **'신원 우산(Identity Umbrella)'**입니다:

  • 프로젝트의 Netflix 신원은 비동기 워크로드(예: Maestro 워크로드)를 실행합니다. 이 신원은 프로젝트에 속하며, 어떤 사람에게도 속하지 않습니다.
  • 프로젝트의 IAM 역할은 Amazon EMR의 Spark 작업과 같은 AWS 특화 사용 사례를 지원합니다. 중요한 점은, IAM 역할을 프로젝트의 Netflix 신원과 암호학적으로 안전하게 교환할 수 있다는 것입니다.
  • 특권 역할을 가진 멤버는 프로젝트의 Netflix 신원을 **가정(assume)**할 수 있습니다. 이는 개발 환경(노트북, 노트북)에서 테스트 및 문제 해결에 매우 유용합니다. 예약된 워크로드가 실행되는 것과 똑같이 명령을 실행할 수 있습니다.

Gravity(중력): 자동 자산 소속

Data Projects의 가장 우아한 특성 중 하나는 Gravity입니다. 프로젝트 신원으로 실행되는 워크로드가 새 자산(예: Maestro 워크로드가 세 개의 테이블 생성)을 만들면, 해당 자산은 자동으로 프로젝트의 포함 자산(contained asset)으로 추가됩니다. 프로젝트는 그 신원으로 생성된 모든 것의 중심이 됩니다. 플랫폼이 이미 작동하는 방식의 부작용으로 조직화를 무료로 얻을 수 있으며, 관련 자산을 발견하고 접근 권한을 얻는 미래의 어려움을 제거합니다.

Cloud infrastructure diagram showing identity and access management for data projects Software Concept Art

Maestro 워크플로우의 실제 적용: 인간 신원에서 프로젝트 신원으로의 전환

넷플릭스의 주요 배치 분석 워크플로우 오케스트레이터인 Maestro는 예약된 ETL 파이프라인, 데이터 이동 작업, ML 트레이닝 등을 처리합니다. 워크플로우는 원래 사용자가 없어도 스케줄에 따라 실행될 수 있기 때문에, Maestro는 **신뢰할 수 있는 워크로드 관리자(TWM)**로 지정되어, 관리하는 워크로드를 대신하여 새로운 신원 토큰을 발급할 권한이 있습니다.

인간 신원의 문제점 기존 패턴은 워크로드를 OBO(On-Behalf-Of) 자격 증명으로 실행하는 것이었습니다. 예: maestro OBO alice@netflix.com. 이렇게 하면 워크로드에 Maestro와 인간의 권한 합집합이 부여되지만, 동시에 워크로드의 권한이 그 사람의 권한에 묶이게 됩니다. 그 사람이 팀을 옮기거나 퇴사하면 워크로드가 중단됩니다. 동료가 인수하더라도 이전 소유자와 동일한 접근 권한을 거의 갖지 못하기 때문에, 권한이 정리되는 동안 며칠 동안 워크로드가 중단됩니다. 수만 개의 예약된 워크로드, 그중 많은 것이 비즈니스 크리티컬한 상황에서 이는 지속 불가능했습니다.

Data Projects의 해결책: 지속 가능한 신원 Data Projects는 사용자-신원을 지속 가능한 팀 소유 Netflix 애플리케이션 신원으로 대체합니다. 이 신원은 팀을 옮기지 않고, 휴가를 가지 않으며, 퇴사하지 않습니다. 각 프로젝트는 관련 워크로드, 테이블, 시크릿 및 기타 자산을 단일 일관된 신원으로 그룹화하며, Maestro는 프로젝트 아래에서 워크로드를 실행하기 전에 호출자의 프로젝트 접근 권한을 검증합니다.

개선 효과:

  • 실행 중 생성된 테이블은 Gravity를 통해 프로젝트 신원과 자동으로 연결되어 추가 구성 없이 접근 제어를 상속합니다.
  • 시크릿은 프로젝트 정책으로 범위가 지정되므로, 소유권 이전이 더 이상 자격 증명을 좌초시키지 않습니다.
  • 접근은 프로젝트 수준에서 한 번 관리되며, 워크로드가 접촉하는 모든 자산에 대한 분산된 사용자별 Grant를 대체합니다.

결과적으로 안정적이고 감사 가능하며, 조직 변화에서 살아남을 수 있는 워크로드 신원 모델이 탄생했습니다.

성공 사례

  • 스트리밍 QoE (Quality of Experience): 핵심 관찰 가능성 파이프라인. 이전에는 워크플로우를 소유한 엔지니어에 따라 연속성이 좌우되었지만, 이제는 프로젝트 신원 아래에서 안정적으로 실행됩니다.
  • 멤버 분석(Member Analytics): 회원 데이터 제품을 위한 분석 모델 및 ETL 워크플로우. 수백 개의 개별 테이블과 워크플로우 대신 프로젝트 수준에서 접근이 관리됩니다.

더 넓게는, Data Projects가 전체 분석 도메인의 조직 원리로 채택되었습니다. 팀이 더 이상 자체 접근 정책, 임시 Grant 목록, '누가 무엇에 접근해야 하는지'에 대한 암묵적 지식을 유지할 필요 없이, 프로젝트가 유일한 답이 되었습니다.

Data analysis dashboard showing ETL workflows and asset management at scale Developer Related Image

실무 적용을 위한 고려사항과 한계

Data Projects 도입 방법

워크플로우를 Data Projects에 온보딩하는 것은 다음 단계로 이루어집니다:

  1. 자산의 논리적 그룹화를 위한 프로젝트 생성(또는 기존 적합한 프로젝트 사용)
  2. 적절한 사람과 그룹에 적절한 역할 부여(Grant)
  3. 워크플로우가 프로젝트의 신원으로 실행되도록 구성

Gravity 덕분에 프로젝트 워크플로우가 생성한 새 자산은 자동으로 프로젝트에 포함됩니다.

주의사항: 기존 워크플로우를 마이그레이션하는 것은 도전적입니다. 실행 신원을 변경하기 전에 Data Project에 적절한 권한을 설정해야 합니다. 넷플릭스는 기존 워크플로우의 접근 패턴을 추적하여 대상 프로젝트에 대한 정확한 권한 업데이트를 추천하는 인프라를 적극적으로 개발 중입니다.

국내 개발 생태계에서의 적용 맥락

국내 SI나 스타트업 환경에서도 유사한 고민이 발생합니다. 특히:

  • 조직 개편이 잦은 스타트업: 팀이 합쳐지고 나뉠 때마다 데이터베이스 테이블, 버킷, 파이프라인의 권한을 일일이 수정해야 하는 문제는 동일합니다.
  • 데이터 플랫폼 팀의 병목: ACL 관리가 데이터 플랫폼 팀의 주요 업무가 되어 버리는 경우가 많습니다.
  • 워크로드와 인간 신원의 결합: Airflow DAG를 특정 계정으로 실행하다가 그 계정의 권한이 변경되면 DAG가 실패하는 경험, 다들 있으실 겁니다.

넷플릭스의 Data Projects 접근법은 이런 문제에 대한 실용적인 청사진을 제공합니다. 물론 모든 회사가 넷플릭스 수준의 인프라를 갖출 필요는 없지만, 프로젝트 단위의 권한 관리와 서비스 계정(Service Account)의 적극적 활용이라는 핵심 원칙은 어디서나 적용 가능합니다.

이 기술의 한계 또는 주의사항

  • 초기 설정 비용: 기존에 개별 자산 단위로 관리되던 시스템을 프로젝트 단위로 전환하는 것은 상당한 노력이 필요합니다.
  • 프로젝트 설계의 어려움: '무엇이 하나의 프로젝트인가'에 대한 기준을 명확히 해야 합니다. 너무 크면 관리가 어렵고, 너무 작으면 세분화된 관리의 이점이 사라집니다.
  • Gravity로 인한 예상치 못한 자산 포함: 워크로드가 의도치 않은 자산을 생성할 경우, 자동으로 프로젝트에 포함되어 접근 권한이 확장될 수 있습니다. 모니터링과 감사가 필요합니다.

다음 단계 학습 방향

  1. IAM Role과 Service Account의 개념을 확실히 이해하세요. AWS IAM Role을 프로젝트 단위로 매핑하는 방법을 학습하면 좋습니다.
  2. 워크로드 오케스트레이터(Airflow, Maestro 등)의 인증/인가 모델을 분석해보세요. 어떤 신원으로 워크로드가 실행되는지, 그 신원이 어떻게 관리되는지가 핵심입니다.
  3. **권한 최소화 원칙(Principle of Least Privilege)**을 프로젝트 단위로 어떻게 적용할지 고민해보세요. 넷플릭스가 'Rightsizing'이라고 부르는 자동 권한 최적화는 미래의 방향입니다.

근거자료: Netflix Tech Blog - Data Projects: Managing Data Assets at Netflix Scale

함께 보면 좋은 글

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.