List
논리적 아키텍처: 데이터 메시 구현의 핵심 요소
데이터 메시(Data Mesh)는 도메인 중심의 데이터 오너십, 제품으로서의 데이터, 셀프 서비스 데이터 플랫폼, 연합 컴퓨팅 거버넌스라는 4가지 핵심 원칙을 통해 전통적 모놀리식 아키텍처의 한계를 극복하고, 민첩하며 확장 가능한 데이터 생태계를 구현합니다. 이번 글에서는 논리적 아키텍처 관점에서 데이터 메시를 구성하는 핵심 요소들을 살펴보겠습니다. 도메인별 분석 데이터 공유 인터페이스 설계부터 아키텍처 퀀텀으로서의 데이터 프로덕트, 멀티플레인(Multiplane) 플랫폼 아키텍처, 그리고 각 데이터 프로덕트에 컴퓨팅 정책을 임베딩하는 연합 컴퓨팅 거버넌스까지 다뤄보겠습니다.
1. 도메인별 분석 데이터 공유 인터페이스
1) 데이터 도메인 오너십과 인터페이스 공유
데이터 메시에서는 분석 데이터를 도메인별로 소유하도록 하여 각 도메인이 자신의 데이터를 책임지고, 관리합니다. 그러나 이를 완성하기 위해서는 도메인이 생성하고 소유하는 분석 데이터를 어떻게 공유할지 아키텍처적으로 모델링해야 합니다. 즉, 각 도메인이 운영 인터페이스와 분석 인터페이스를 노출하여 다른 도메인에서도 필요한 데이터를 가져다 쓸 수 있도록 해야 합니다.
예시: 팟캐스트 도메인은 새 팟캐스트 에피소드를 생성하는 운영 API를 제공함과 동시에, 장기간에 걸친 데이터와 사용 통계를 검색할 수 있는 분석 인터페이스를 함께 제공할 수 있습니다.
2) 운영 인터페이스 설계
•
역할: 조직 내 운영 시스템이 데이터를 CRUD 형태로 관리할 수 있도록 지원하며, 실시간 혹은 준 실시간 스냅샷을 통해 시스템 상태를 확인할 수 있게 합니다.
•
특징:
◦
HTTP POST/artists-payments 등 CRUD 요청 방식
◦
HTTP GET/listeners-subscriptions?region=NA 등 특정 조건으로 필터된 상태 확인
•
데이터 메시와의 관계:
◦
엔터프라이즈 아키텍처의 기존 측면을 그대로 인정하며, 필요에 따라 운영 인터페이스를 통해 데이터 프로덕트가 생성될 수 있음.
3) 분석 데이터 인터페이스 설계
•
역할: 데이터 프로덕트가 노출하는 분석 데이터를 검색, 파악, 관찰, 공유할 수 있는 고수준 API를 제공합니다.
•
구현 방식:
◦
AWS S3의 Parquet 파일 같은 블롭 스토리지,
◦
Kafka 토픽 같은 이벤트 스트림,
◦
BigQuery 테이블 같은 테이블 등으로 리디렉션 가능
◦
액세스 정책이나 권한을 적용하여, 고객에게 허용된 형태의 분석 데이터 접근만 허용
•
주의점: 현재까지 이러한 기능을 표준화해주는 통일된 고수준 API 규칙은 없으므로, 조직의 요구사항과 기술 스택에 맞춰 자체적으로 설계해야 합니다.
4) 상호 도메인 분석 데이터 종속성
도메인들은 서로의 운영 인터페이스나 분석 인터페이스에 종속될 수 있습니다. 예를 들어, A 도메인은 B 도메인에서 제공하는 분석 데이터 없이 자체 분석이 불가능할 수 있습니다. 데이터 메시 아키텍처에서는 이러한 종속성을 비동기 이벤트나 동기 데이터 호출 등 다양한 방식으로 구현할 수 있으며, 데이터 프로덕트가 업스트림 소스와의 종속성을 명시적으로 정의함으로써 투명하고 제어 가능한 데이터 흐름을 구성합니다.
2. 아키텍처 퀀텀으로서의 데이터 프로덕트
1) 아키텍처 퀀텀(Quantum) 개념
아키텍처 퀀텀은 독립적으로 배포될 수 있고, 기능적 응집도가 높으며, 해당 기능에 필요한 구조적 요소를 모두 포함한 가장 작은 아키텍처 단위입니다. 데이터 메시에서는 각 데이터 프로덕트가 바로 이 아키텍처 퀀텀에 해당합니다.
2) 데이터 프로덕트의 구조적 구성 요소
데이터 프로덕트는 크게 다음 세 가지 범주로 구성됩니다:
1.
코드:
•
비즈니스 로직(데이터 생성·변환·공유·접근 관리 등)
•
분석 데이터 수명 주기를 독립적으로 제어
•
내부 변환 코드(파이프라인이 외부에 존재하지 않도록 캡슐화)
2.
데이터 및 메타데이터:
•
데이터 프로덕트 내에서 자체적으로 생성·관리
•
데이터 구조, 스키마, 품질 지표 등 각종 메타데이터 포함
3.
인프라 종속성:
•
빌드·배포·실행에 필요한 플랫폼 리소스
•
중앙에서 관리하되, 개별 데이터 프로덕트가 자율적으로 리소스를 할당받을 수 있어야 함
중요한 점: 기존에는 분석 변환 코드가 DAG 기반 외부 파이프라인 형태로 존재했다면, 데이터 메시에서는 이를 데이터 프로덕트 내부에 캡슐화하여 독립적인 변환 로직으로 관리합니다.
3. 멀티플레인(Multiplane) 데이터 플랫폼
데이터 메시 플랫폼은 단일 모놀리식 플랫폼으로 모든 기능을 제공하는 방식이 아니라, 개방형 인터페이스를 노출하는 느슨하게 통합된 서비스 세트로 구현됩니다. 이때 **플레인(Plane)**이라는 논리적 구성을 통해 플랫폼 기능을 나눌 수 있습니다.
1) 플랫폼 플레인(Plane)이란?
•
정의: 상호 보완적인 목표와 높은 기능적 응집력을 가진 특성들이 한 데 모여, 엔드 투 엔드로 특정 결과를 달성하는 논리적 집합
•
역할: 인프라 복잡성을 추상화하고, 표준화된 API를 통해 데이터를 주고받으며, 데이터를 관리·활용하는 과정을 용이하게 만듦
2) 데이터 인프라(유틸리티) 플레인
•
스토리지, 컴퓨팅, 아이덴티티 시스템 등 로우 레벨 인프라를 관리
•
데이터 메시의 기초를 이루는 자원들을 중앙에서 운영하지만, 도메인 팀이 자율적으로 활용할 수 있게 해야 함
3) 데이터 프로덕트 경험 플레인
•
데이터 프로덕트를 빌드, 유지 관리, 소비하기 위한 고수준 추상화 서비스 제공
•
데이터 프로덕트 수명 주기 관리: 초기화, 빌드, 테스트, 배포, 모니터링
•
데이터 프로덕트 출력 구독, 데이터 읽기 등 소비자 기능 지원
4) 데이터 메시 경험 플레인
•
메시 수준에서 여러 데이터 프로덕트를 검색하고, **리니지(Lineage)**를 따라가며 데이터를 탐색할 수 있도록 함
•
리니지: 데이터의 기원과 이동 경로, 변환 과정을 추적
•
트래버싱: 데이터 프로덕트 간 연결 고리를 탐색
4. 임베딩된 컴퓨팅 정책: 연합 컴퓨팅 거버넌스 구현
데이터 메시 아키텍처에서 연합 컴퓨팅 거버넌스를 실행하기 위해서는 각 데이터 프로덕트에 정책(Policy)을 코드로 내재화할 필요가 있습니다.
1) 데이터 프로덕트 사이드카
•
정의: 데이터 프로덕트의 런타임 환경을 장식(Decorate)하여, 분산된 거버넌스에서 공통으로 적용해야 하는 정책이나 기능(보안, 접근 제어, 감사 등)을 실행하는 별도 프로세스
•
특징:
◦
느슨하게 결합, 독립 프로세스 형태
◦
배포 시점에 “주입(Injection)” 가능
◦
시간이 지남에 따라 필요 정책을 확장하여 추가
2) 데이터 프로덕트 컴퓨팅 컨테이너
•
사이드카, 정책 구성, 변환 코드, 데이터, 공유 인터페이스 등 데이터 프로덕트의 모든 구조적 요소를 감싸는 컨테이너
•
목적: 아키텍처 퀀텀 단위로 배포·관리할 수 있도록 일체화
3) 컨트롤 포트(Control Port)
•
권한 높은 작업(예: GDPR 잊혀질 권리 실행, 글로벌 접근 제어 정책 설정 등)을 실행하기 위한 일련의 API를 노출
•
정책 구성:
◦
로컬 정책(도메인별)과 글로벌 정책(조직 차원) 모두 적용 가능
◦
예: 데이터 익명화는 로컬에서, 역할 기반 도메인 데이터 접근 제어는 글로벌에서 정의
마무리
이번 글에서는 데이터 메시를 논리적 아키텍처 관점에서 어떻게 구성해야 하는지 살펴보았습니다. 도메인별 분석 데이터 공유 인터페이스를 통해 자율적 도메인 오너십을 구현하고, 아키텍처 퀀텀으로서의 데이터 프로덕트를 활용해 변환 로직과 메타데이터·인프라 종속성을 캡슐화하며, 멀티플레인(Multiplane) 플랫폼을 통해 유연하고 확장 가능한 인프라를 제공할 수 있습니다. 또한, 각 데이터 프로덕트에 연합 컴퓨팅 거버넌스 정책을 임베딩함으로써, 분산된 환경에서도 일관된 보안과 품질을 유지할 수 있습니다.
다음 글에서는 멀티플레인 데이터 플랫폼 아키텍처를 한층 더 깊이 들여다봅니다. 사용자 경험 중심 접근 방식을 통해 어떻게 데이터 메시의 세 가지 플레인(인프라 유틸리티, 데이터 프로덕트 경험, 데이터 메시 경험)을 설계하고, 도메인 팀과 데이터 프로덕트 개발자·소비자·거버넌스 팀원 등 다양한 역할의 사용자 여정을 지원하는지 알아볼 예정입니다.