DDD(1) - 데이터 메시(Data Mesh)
목차
- 1. OLTP(Online Transactional Processing) VS OLAP(Online Analytical Processing): 실시간 모델과 분석 모델의 구조적 차이
- 2. 분석 데이터 관리 플랫폼
- 3. 데이터 메시(Data Mesh)
- 참고 사이트 & 함께 보면 좋은 사이트
이 포스트에서는 실시간 데이터 처리 시스템에서 분석 데이터 관리 시스템으로 논의를 확장하고, 도메인 주도 설계와 데이터 메시 아키텍처가 어떻게 상호작용하는지를 살펴본다.
- 분석 데이터 컨텍스트에서도 효과적인 도메인 모델링
- 데이터 웨어 하우스, 데이터 레이크, 그리고 데이터 메시 아키텍처가 어떻게 그 단점을 해결하는지?
- DDD 와 데이터 메시가 공유하는 설계 원칙과 철학
<실시간 데이터 vs 분석 데이터: OLTP 와 OLAP>
현대 시스템은 일반적으로 2 가지 주요 데이터 처리 유형을 다룬다.
- OLTP(Online Transactional Processing)
- 주로 시스템 내부 트랜잭션에 사용되며, 실시간성과 정합성이 핵심
- 예) 결제 처리, 주문 생성, 사용자 정보 수정 등
- OLAP(Online Analytical Processing)
- 주로 비즈니스 의사결정과 데이터 분석에 사용되며, 대규모 집계 및 조회 중심
- 예) 일별 매출 집계, 사용자 행동 분석 등
실시간 트랜잭션을 위한 데이터 모델은 도메인 주도 설계를 통해 정교하게 설계되지만, 도메인 주도 설계 모델을 그대로 분석 용도로 재사용하는 데에는 아래와 같은 한계가 있다.
- 분석에 필요한 데이터 집계 및 변환 로직이 실시간 모델에는 없음
- 시점별 상태 이력이 실시간 모델에는 포함되지 않음
- 도메인 간 데이터 연계를 위한 공통 식별자, 관계 모델이 부족
<전통적인 분석 아키텍처인 데이터 웨어하우스와 데이터 레이크>
| 아키텍처 | 특징 | 한계 |
|---|---|---|
| 데이터 웨어 하우스 | 구조화된 정형 데이터, 스키마 명확 | 유연성 부족, 도메인 간 경계 불명확 |
| 데이터 레이크 | 비정형 + 정형 데이터를 유연하게 저장 | 데이터 품질, 신뢰성 부족 |
아래는 도메인 중심 분산형 분석 데이터 아키텍처인 데이터 메시의 특징이다.
- 도메인 중심 소유
- 분석 데이터도 해당 도메인을 가장 잘 아는 팀이 책임지고 소유
- 데이터를 제품처럼
- 데이터셋에 대한 SLA, 품질, 문서, 버전 등을 관리
- 자기 서비스 플랫폼
- 데이터 파이프라인, 카탈로그, 모니터링 등 공통 기능을 플랫폼화
- 컴포저블 거버넌스
- 조직 전체의 데이터 표준과 규칙을 느슨하게 연합 관리
데이터 메시가 기존 OLAP 구조보다 도메인 주도적이고, 제품화된 접근을 취한다는 점에서 DDD 와 매우 유사하다.
<DDD 와 데이터 메시의 조화>
| 항목 | DDD | 데이터 메시 |
|---|---|---|
| 모델링 기준 | 도메인 지식과 업무 흐름 | 도메인별 분석 유스케이스 |
| 경계 설정 | 바운디드 컨텍스트 | 데이터 프로덕트 도메인 |
| 소유권 | 도메인 팀 | 데이터 프로덕트 팀 |
| 통합 방식 | 컨텍스트 간 명시적 인터페이스 | 메타데이터 + 통합 규약 기반 인터페이스 |
결론적으로, DDD 는 트랜잭션 시스템의 설계에만 국한되지 않는다.
데이터 메시와 함께 사용하면 분석 시스템에서도 도메인 기반의 책임 분리, 데이터 소유권 명확화, 신뢰 가능한 데이터 제공을 구현할 수 있다.
1. OLTP(Online Transactional Processing) VS OLAP(Online Analytical Processing): 실시간 모델과 분석 모델의 구조적 차이
분석 데이터는 조직이 보유한 다양한 데이터를 기반으로 비즈니스 최적화 전략을 도출하고, 고객의 니즈를 정밀하게 파악하며, 머신 러닝(ML) 모델 훈련을 통해 자동화된 의사결정을 가능하게 하는 핵심 자산이다.
| 모델 유형 | 주요 사용자 | 유스케이스 | 목적 | 설계 철학 |
|---|---|---|---|---|
| OLTP(트랜잭션 모델) | 내부 시스템, 백오피스, API 호출자 | 주문 생성, 결제 처리 등 | 실시간 트랜잭션 수행 | - 도메인 중심의 엔티티와 그 수명주기를 반영하여 설계됨 - 도메인 간의 명확한 경계, 상태 전이, 비즈니스 규칙이 설계의 중심 |
| OLAP(분석 모델) | 데이터 분석가, BI 시스템, ML 엔지니어 | 매출 추이 분석, 리텐션 분석 등 | 통찰 도출과 전략 최적화 | - 비즈니스 이벤트를 기반으로 구성 - 엔티티보다는 팩트(Fact) 와 디멘전(Dimension) 중심의 테이블 설계 |
BI(Business Intelligence) 시스템
조직 내 다양한 데이터를 수집/통합/분석하여 의사결정에 필요한 인사이트를 제공하는 시스템
예) Tableau(태블로), Power BI(마이크로소프트), Looker(구글), Qlik, Metabase, Superset(오픈소스)BI 시스템이 하는 일
- 데이터 수집
- ERP, CRM, 트랜잭션 DB, 로그 등 다양한 소스에서 데이터 수집
- ETL 처리
- 데이터를 정제하고, 통합하며, 분석에 적합한 형태로 변환
- 데이터 저장
- 데이터 웨어하우스, 데이터 레이크 등에 분석 데이터 저장
- 시각화
- 대시보드, 리포트, 그래프 등으로 데이터 시각화
- 분석 및 통계
- KPI 모니터링, 트렌드 분석, 예측 분석
- 사용자 인터페이스
- 비즈니스 사용자도 쉽게 사용할 수 있는 UI 제공
BI 시스템의 목적
- 데이터 기반 의사결정 지원
- 비즈니스 성과 분석, 문제 조기 감지, 기회 포착
- 부서 간 데이터 공유를 통한 협업 강화
<자료 구조의 차이>
| 관점 | OLTP 모델(트랜잭션 모델) | OLAP 모델(분석 모델) |
|---|---|---|
| 중심 단위 | 도메인 엔티티 - 예) Order, Product | 팩트(Fact) 와 디멘전(Dimension) |
| 예시 | orders, products | order_fact, time_dimension |
| 목적 | 데이터 정합성, 실시간 반응성 | 집계 및 분석 최적화 |
<OLAP 에 OLTP 모델을 재사용할 수 없는 이유>
- 분석에 필요한 이력 정보나 상태 변경 내역이 부족
- 중복 제거, 정규화 중심 구조로 인해 집계가 어려움
- 도메인 간 조인을 어렵게 만드는 테이블 분산
반면, 분석 목적의 OLAP 모델은 이력성, 중복 허용, 빠른 집계 가능성을 고려하여 설계되며, 이는 실시간 시스템에 부적절할 수 있다.
1.1. 팩트(Fact) 테이블: 비즈니스 활동의 스냅숏
팩트는 이미 발생한 비즈니스 활동의 기록을 의미한다.
팩트 테이블은 주로 OLAP 모델에서 사용되며, 과거에 일어난 사건을 기반으로 분석 가능한 데이터 포인트를 제공한다.
팩트는 도메인 이벤트와 유사한 점이 있다.
둘 다 과거에 일어난 사건(event)을 기록하며, 일반적으로 삭제되거나 수정되지 않고 불변이다.
하지만, 팩트는 아래와 같은 점에서 도메인 이벤트와 다르다.
| 구분 | 도메인 이벤트 | 팩트 테이블 |
|---|---|---|
| 명명 방식 | 과거 시제 동사 예) OrderPlaced | 동사 형태를 강제하지 않음 예) Fact_SolvedCases |
| 설계 목적 | 트랜잭션 및 워크플로우 트리거 | 분석 및 집계 목적 |
| 사용 위치 | OLTP 시스템 | OLAP 시스템 |
| 수정 여부 | 불변 | 불변 |
분석 데이터는 추가만 가능하다.
따라서 팩트 테이블에 변경된 상태를 반영하려면 기존 레코드를 수정하는 것이 아니라 새로운 레코드를 추가해야 한다.
이렇게 시간이 지남에 따라 누적되는 팩트는 과거의 상태를 보존함으로써 시간에 따른 추세 분석, 전환율 측정, SLA 만족도 평가 등을 가능하게 한다.
세분화 수준: 정밀 vs 집계
OLTP 모델에서는 단일 트랜잭션 단위로 매우 정밀한 정보가 필요하다.
반면, OLAP 모델에서는 다양한 유스케이스를 위해 적절한 수준의 집계가 더 중요하다.
예를 들어 고객 서비스의 상태 변경 이력을 관리하는 Fact_CaseStatus 팩트 테이블이 있다고 해보자.
이 테이블은 30분마다 스냅숏을 찍어 저장된다.
이는 매 상태 변경 시점마다 레코드를 생성하는 것보다 성능이나 저장 비용 측면에서 더 효율적일 수 있다.
분석가는 유스케이스에 따라 아래와 같은 판단을 내린다.
| 집계 수준 | 장점 | 단점 |
|---|---|---|
| 매우 정밀(변경마다 기록) | 높은 정확도, 리얼타임 분석 | 비용 증가, 성능 부담 |
| 일정 주기 스냅숏 | 효율적, 구현 간단 | 변화 감지가 느림, 추정 필요 |
1.2. 디멘전 테이블: 팩트를 수식하는 형용사
팩트(Fact) 가 비즈니스 활동 자체(= 동사)를 의미한다면, 디멘전(Dimension) 은 그 활동을 설명하는 속성(= 형용사)이다.
디멘전 테이블을 팩트 테이블의 각 레코드를 보완하며, ‘누가, 언제, 어디서, 어떤 방식으로’ 같은 정보를 제공한다.
팩트 테이블은 디멘전 테이블을 외래키로 참조하며, 이를 통해 분석적 의미를 확장한다.
예를 들어 Fact_Sales 테이블은 아래와 같은 디멘전을 참조할 수 있다.
| 팩트 컬럼 | 참조 디멘전 |
|---|---|
| product_id | Dim_Product |
| customer_id | Dim_Customer |
| store_id | Dim_Store |
이러한 디멘전은 여러 팩트 테이블에서 재사용되며, 반복되는 속성값들을 분리하여 데이터 중복을 줄이고 분석의 일관성을 유지한다.
디멘전은 왜 고도로 정규화되어야 할까?
실시간 데이터 모델(OLTP) 은 명확한 요구사항에 기반해 만들어진다.
즉, ‘이 버턴을 클릭하면 이 API 를 호출하고, 이 데이터를 조회한다.’와 같이 질의 패턴을 예측할 수 있다.
하지만 분석 모델(OLAP) 는 다르다.
- 데이터 분석가는 매일 새로운 가설을 검증한다.
- 미래에 어떤 질의가 발생할 지 예측할 수 없다.
- 특정 조건, 범주, 시점별로 자유롭게 그룹화/필터링/집계를 해야 한다.
이렇게 분석 모델은 질의 패턴을 예측할 수 없기 때문에 디멘전은 정규화와 재사용성을 기반으로 설계된다.
정규화된 디멘전은 다대일 관계와 계층 구조를 표현할 수 있어, 유연한 분석 질의에 적합하다.
Dim_Date 테이블 예시
| date_id | full_date | year | quarter | month | day_of_week |
|---|---|---|---|---|---|
| 20250101 | 2025-01-01 | 2025 | Q1 | 1 | Wednesday |
이 하나의 디멘전을 통해 아래와 같은 다양한 분석 질의가 가능해진다.
- 월별 매출 추이
- 주중 vs 주말 구매 패턴
- 분기별 사용자 수
디멘전이 고도로 정규화된 이유는 분석 시스테에서 유연한 질의를 지원해야 하기 때문이다. 이것이 바로 실시간 데이터 모델과 분석 모델의 또 다른 차이점이다.
1.3. 분석 모델: 스타 스키마, 스노우플레이크 스키마
분석 데이터 모델은 팩트 테이블과 디멘전 테이블 간의 관계로 구성된다.
이 구조를 어떻게 설계하느냐에 따라 대표적으로 스타 스키마(star schema) 와 스노우플레이크 스키마(snowflake schema) 나뉜다.
아래의 테이블 구조는 스타 스키마라고 불리며, 중앙의 팩트 테이블과 그 주변의 디멘전 테이블들이 1:N 관계를 가지는 구조이다.
- 각 디멘전 레코드는 여러 팩트에서 공유된다.
- 단일 팩트 레코드는 각 디멘전에 대해 하나의 외래키를 가진다.
- 구조가 단순하고 조인 비용이 적어 조회 성능이 우수하다.
- 디멘전 테이블이 정규화되지 않아 중복된 데이터가 존재할 수 있다.
아래의 테이블 구조는 스노우플레이크 스키마라고 불리며, 디멘전 테이블이 더 세밀한 테이블로 정규화되어 다단계로 분해된 형태이다.
- 디멘전 테이블이 계층적 구조를 가지며, 여러 수준으로 나뉜다.
- 데이터 중복을 줄이고 저장 효율이 높다.
- 하지만 질의 시 더 많은 테이블을 조인해야 하므로 컴퓨팅 리소스가 더 필요하고 성능이 떨어질 수 있다.
- 복잡한 디멘전 구조를 정형화된 방식으로 표현할 수 있어 데이터 유지보수에 유리하다.
- 더 구조적인 질의가 가능하여 분석 유연성이 더 좋다.
2. 분석 데이터 관리 플랫폼
비즈니스 의사결정, 리포팅, 머신 러닝 등 데이터 기반 활동은 정제된 분석 데이터를 안정적으로 제공받는 시스템 위에서 이루어진다.
이를 위해 조직은 다양한 분석 데이터 관리 아키텍처를 도입한다.
여기서는 대표적인 두 가지 접근 방식인 데이터 웨어하우스(DWH: Data WareHouse) 와 데이터 레이크(Data Lake) 의 개념과 작동 방식, 그리고 그 한계에 대해 알아본다.
2.1. 데이터 웨어하우스(DWH: Data WareHouse)
데이터 웨어하우스는 기업 내 모든 실시간 데이터 처리 시스템에서 추출된 데이터를 통합하여 저장하는 분석 지향 DB 이다.
원천 데이터는 추출(Extract) → 변환(Transform) → 적재(Load) 라는 ETL 프로세스를 거쳐서 데이터 웨어하우스에 저장된다.
데이터는 실시간 데이터 처리 DB, 스트림 이벤트, 로그 등 다양한 원천에서 수집된다.
데이터 웨어하우스의 주요 목적은 다양한 비즈니스 시스템에서 생성되는 데이터를 통합하여 하나의 전사적 모델로 표현하고, 분석/리포팅/마이닝에 활용할 수 있는 형태로 만드는 것이다.
<데이터 웨어하우스>
- 데이터 흐름
- ETL 기반
- 스테이징 → 변환 → 적재
- 데이터 유형
- 정형 데이터 중심
- 활용 사례
- 리포팅, 분석, 마이닝
- 장점
- 품질 높은 통합 분석 모델
- 단점
- 강결합, 유연성 부족, 변경에 취약
변환 단계 과정에서는 아래와 같은 작업이 수행된다.
- 민감한 정보 제거
- 중복 데이터 제거 및 정합성 확보
- 이벤트 순서 조정 및 병합
- 스키마 변환 및 팩트/디멘전 모델로 구조화
이 때, 유입 중인 데이터를 임시 저장 및 정제 처리를 하기 위해 사용하는 저장소를 스테이징 영역이라고 한다.
스테이징 영역은 데이터 품질 확보에 중요한 역할을 한다.
위 그림를 보면
- 다양한 실시간 처리 시스템, 로그 등에서 데이터를 추출하여 변환 후 스테이징 영역을 거쳐 적재
- 최종적으로 엔터프라이즈 데이터 웨어하우스에 저장되어 사용자 분석에 활용
- 전사 데이터 모델을 기반으로 리포팅/분석/머신 러닝에 사용됨
데이터 웨어하우스 아키텍처 중심에는 엔터프라이즈 전반의 모델을 구축하는 목표가 있다. 모델은 기업의 모든 시스템에서 생성되는 데이터를 묘사하고 다양한 분석 데이터의 사용 사례를 다뤄야 한다.
전사적 모델을 하나로 수렴하는 것은 쉽지 않다.
이를 보완하기 위해 특정 부서 단위의 요구를 충족하는 데이터 마트가 도입된다.
- 데이터 마트는 마케팅, 고객 지원 등 특정 부서의 분석 요구에 맞게 설계된 소규모 분석 DB 이다.
- 어떤 마트는 데이터 웨어하우스에서 데이터를 추출하고, 어떤 마트는 실시간 처리 시스템으로부터 직접 데이터를 받는다.
- 다양한 마트를 분석에 활용할 경우 여러 DB 에 걸친 질의가 필요하기 때문에 조인 비용 증가 및 성능 저하가 발생할 수 있다.
2.1.1. 데이터 웨어하우스의 구조적 한계
- 과도한 결합도
- 퍼블릭 API 가 아닌 내부 DB 스키마에 의존한 ETL 방식은 위험함
- 실시간 시스템의 내부 스키마에 직접 의존하는 경우가 많다.
- 스키마 변경이 분석 시스템에 즉각적인 장애로 이어질 수 있다.
- 실시간 시스템과 분석 시스템이 조직적으로 분리되어 있어 커뮤니케이션 비용과 마찰이 크다.
- 퍼블릭 API 가 아닌 내부 DB 스키마에 의존한 ETL 방식은 위험함
- 모든 도메인을 아우르는 단일 모델의 어려움
- 다양한 도메인을 하나의 스키마로 수렴하려는 시도는 복잡성과 유지보수 부담을 야기한다.
- 부서별 요구사항을 우연하게 반영하기 어려우며, 분석 속도도 느려질 수 있다.
<데이터 레이크>
- 스키마 처리
- 스키마 온 리드
- 저장 방식
- 원시 데이터 그대로 저장
- 분석 모델 생성 시점
- 분석 시점에 동적으로 생성
- 장점
- 유연성, 다양한 유스케이스 지원
- 단점
- 정합성 부족, 복잡성 증가, 운영 난이도 상승
2.2. 데이터 레이크(Data Lake)
데이터 레이크는 실시간 데이터 처리 시스템으로부터 유입된 데이터를 원본 그대로 저장하는 분석 데이터 아키텍처이다.
데이터 웨어하우스와 마찬가지로 분석을 위한 ETL 기반 아키텍처이지만, 가장 큰 차이점은 “언제 데이터를 모델링하는가”에 있다.
데이터 웨어하우스는 데이터를 미리 모델링(스키마 온 라이트)한 뒤 적재하지만, 데이터 레이크는 원시 상태로 저장(스키마 온 리드)하고, 분석 시점에 데이터를 변환한다.
데이터는 원본 그대로 저장되고, 나중에 변환되어 데이터 웨어하우스에 적재된다.
- 데이터는 실시간 처리 시스템, 로그 등에서 그대로 수집
- 분석 모델 생성은 나중에 수행
- 데이터 엔지니어와 BI 엔지니어가 ETL 스크립트를 통해 다양한 목적의 모델을 구성하여 데이터 웨어하우스에 적재
데이터 레이크는 아래와 같은 유연성을 제공한다.
- 다양한 유스케이스에 맞는 분석 모델을 다중 버전으로 생성 가능
- 기존 데이터로부터 새로운 분석 모델을 초기화할 수 있음
- 머신 러닝, 리포팅, 대시보드 등 목적별로 다른 구조 설계 가능
하지만 이러한 유연성은 시스템의 복잡성을 높인다.
아래는 동일한 데이터 레이크에서 여러 ETL 버전을 병렬로 운영하는 예시이다.
- 변환 V1: 리포팅용 정형 모델
- 변환 V2: 머신 러닝용 비정형 + 정형 모델
- 동일한 원본에서 서로 다른 스키마로 파생
2.2.1. 데이터 레이크의 한계
데이터 레이크는 구조적 제약이 없기 때문에 데이터 수집은 쉽지만 활용은 어렵다.
- 스키마
- 없음
- 데이터 정합성
- 보장되지 않음
- 품질 관리
- 수신 단계에서 필터링 없음
- 사용 난이도
- 데이터 해석 및 활용이 어려움
- 리스크
- 규모가 커질수록 데이터 스웜프(Data Swamp) 가 될 가능성이 존재
데이터 스웜프(Data Swamp)
구조화되지 않은 채로 무분별하게 수집된 데이터가 쌓이면서 결국 아무도 제대로 활용할 수 없게 된 상태
스웜프로 변하는 이유
- 스키마없이 아무 데이터나 저장
- 누가 어떤 데이터를 만들었는지 모름(소유권 불명확)
- 버전 관리없이 덮어쓰기
- 메타데이터, 문서화 부족
- 동일한 데이터가 중복 저장됨
- ‘혹시 몰라서 저장’한 데이터들이 정체되어 방치됨
스웜프를 막는 방법
- 데이터 거버넌스: 소유자, 품질 기준, 변경 관리 체계 도입
- 메타데이터 관리: 카탈로그 도입, 태깅, 문서화
- 데이터 프로덕트화: 도메인 팀이 데이터를 직접 관리하고 책임지도록 구조화(= 데이터 메시와 연결됨)
- 정기적 클렌징 및 아카이빙 수행
2.3. 데이터 웨어하우스와 데이터 레이크 아키텍처의 도전과제
데이터 웨어하우스와 데이터 레이크는 모두 ‘데이터를 많이 모을수록 더 많은 통찰을 얻을 수 있다’는 가정에 기반한 아키텍처이다.
하지만 실제 운영 환경에서는 이러한 접근이 스케일의 저주와 조직적 마찰을 불러 일으킨다.
실시간 시스템과의 결합도 증가
두 아키텍처 모두 실시간 처리 시스템의 내부 모델(구현 스키마)에 의존하여 ETL 작업을 구성하는데 이는 아래와 같은 문제를 야기한다.
- ETL 스크립트가 실시간 시스템의 변경에 민감하게 깨짐
- 분석팀이 이러한 리스크를 피하려고 실시간 모델의 변경을 억제하려 듦
- 결과적으로 실시간 시스템 팀과 분석 시스템 간에 갈등이 생김
결합도가 높을수록 시스템의 유연성과 독립성은 낮아진다.
ETL 복잡도와 유지보수 부담
실시간 모델을 분석 모델로 전환하는 과정에서 아래와 같은 일이 벌어진다.
- 수많은 임시 ETL 스크립트가 생성됨
- 팀 내 문서화나 소유권이 불명확하여 테스트나 유지보수가 어려움
- 데이터 품질 저하, 중복 계산, 비효율적인 파이프라인 증가
결국 분석 시스템은 점점 기술 부채의 늪에 빠지게 된다.
도메인 지식의 단절
실시간 처리 시스템을 만드는 팀(백엔드 개발자)은 도메인에 깊이 관여되어 있는 반면, ETL 을 담당하는 데이터 분석가는 도메인을 간접적으로만 이해한다.
이로 인해 분석 모델은 도메인에 부합하지 않는 형태로 구성될 수 있으며, 도메인 모델 개선의 흐름과 분석 시스템의 진화가 서로 불협화음을 낸다.
DDD 와의 충돌
DDD 에서는 도메인 모델을 끊임없이 개선하고 진화시키는 것이 핵심이다.
하지만 데이터 웨어하우스와 데이터 레이크 아키텍처에서는 아래와 같은 문제가 생긴다.
- 실시간 시스템의 도메인 모델이 변경되면, 이를 참조하던 분석 시스템의 ETL 이 깨지고, 변경이 점점 억제되거나 왜곡되기 시작함
이는 DDD 의 핵심 가치인 자율성과 진화 가능성을 정면으로 위배한다.
이러한 구조적 한계들은 결국 새로운 분석 아키텍처의 등장을 이끌었다.
바로 도메인 중심의 분석 데이터 아키텍처인 데이터 메시(Data Mesh) 이다.
- 데이터 생산과 소비를 도메인 팀이 책임지고
- 데이터를 제품처럼 관리하며
- 분산된 구조에서 품질과 유연성을 동시에 달성할 수 있도록 설계된 접근 방식이다.
3. 데이터 메시(Data Mesh)
데이터 메시 아키텍처는 기존의 중앙 집중형 데이터 웨어하우스 및 데이터 레이크가 가진 확장성 문제, 도메인 이해 부족, 기술 부채 문제 등을 해결하기 위한 새로운 접근 방식이다.
특히 DDD 에서 강조하는 모델 경계, 자율성, 진화 가능성과 매우 닮아있다.
데이터 메시는 분석 데이터를 위한 도메인 주도 설계라고 볼 수 있다.
DDD 에서 바운디드 컨텍스트를 기준으로 경계를 나누고 그 내부의 도메인을 독립적으로 설계하듯, 데이터 메시에서도 각 도메인 팀이 분석 데이터를 직적 소유하고 제공하는 책임을 지도록 한다.
<데이터 메시 아키텍처의 4가지 설계 원칙>
- 도메인 기준 데이터 분리
- 데이터 제품(Data as a Product)
- 자율성과 책임
- 에코시스템으로서의 플랫폼
3.1. 도메인 기준의 데이터 분리
기존의 데이터 웨어하우스와 데이터 레이크 아키텍처는 전사 데이터를 하나의 통합 모델로 수렴하는 것을 목표로 한다.
하지만 이 방식은 현실적으로 아래와 같은 문제를 야기한다.
- 도메인별 요구 사항과 문맥(Context)을 반영하기 어려움
- 분석 모델이 너무 크고 복잡해져 유지보수가 어려움
- 데이터 소유권이 모호해지고, 책임의 경계가 흐려짐
데이터 메시에서의 접근법은 분산된 모델과 명확한 소유권이다.
데이터 메시 아키텍처는 실시간 데이터를 처리하는 도메인 바운디드 컨텍스트 내부에서 분석 모델을 함께 소유하게 만든다.
즉, 각 도메인 팀에 자신이 생성한 데이터를 분석 가능한 형태로 전환하고, 그 결과물도 직접 관리(= 각 팀은 분석 데이터를 ‘자신의 프로덕트’로 간주)한다.
(= 도메인 팀이 실시간 데이터 처리(OLTP) 모델과 분석(OLAP) 모델을 소유하고 관리함)
위와 같이 하면 아래와 같은 이점이 있다.
- 분석 모델의 경계가 도메인 경계와 일치하여, 소유권과 책임이 명확해짐
- 도메인 팀은 도메인에 대한 깊은 이해를 바탕으로 고품질의 분석 모델을 만들 수 있음
- 실시간 데이터 모델과 분석 모델이 논리적으로 연결되며, 의도한 방향으로 함께 진화할 수 있음
- 중앙 데이터 팀에 의존하지 않고도, 도메인 팀이 독립적으로 분석 데이터를 제공할 수 있음
데이터 메시는 분석 데이터를 위한 도메인 경계를 설정하고, 각 도메인 팀이 OLTP + OLAP 의 전체 흐름을 책임지는 구조를 지향한다.
이러한 접근은 DDD 의 바운디드 컨텍스트 개념과 본질적으로 맞닿아있다.
3.2. 제품 관점에서 데이터 다루기(Data as a Product)
기존이 데이터 웨어하우스와 데이터 레이크 기반 시스템은 분석 데이터를 찾고, 이해하고, 접근하기 어렵다.
특히 데이터 레이크의 경우 원시 데이터를 그대로 저장하기 때문에 데이터 품질과 문서화가 부족하여 신뢰하기 어렵다.
데이터 메시 아키텍처는 아리 그림과 같이 바운디드 컨텍스트 내부에서 분석 데이터를 직접 관리하고, 잘 정의된 출력 포트를 통해 외부에 노출하는 방식을 따른다.
- 분석 데이터를 퍼블릭 API 처럼 다룬다.
- 분석 엔드포인트를 통해 필요한 데이터를 쉽게 탐색할 수 있어야 한다.
- 제공하는 데이터는 명확한 스키마를 통해 설명되어야 하며, 신뢰성과 가용성이 보장되어야 한다.
데이터 메시에서는 분석 데이터가 단순한 내부 자산이 아닌, 소비자 중심의 데이터 제품으로 관리되어야 한다.
- 각 도메인 팀이 자신의 실시간 처리 데이터와 분석 모델을 함께 소유
- 분석 모델을 출력 포트(엔드 포인트)를 통해 외부에 제공
- 데이터는 제품처럼 설계되고, 스키마/SLA/소비 인터페이스를 갖춘다.
또한 분석 데이터는 사용자 관점에서 유용해야 하므로 소비자의 니즈를 반영한 형태로 제공되어야 한다.
<데이터 메시가 갖춰야 할 조건>
- 데이터 품질에 대한 명확한 소유와 책임이 설정되어야 함
- 다양한 소비 방식(SQL, 파일, API 등)을 고려하여 설계되어야 함
- 도메인 팀 안에 데이터 전문가(BI 엔지니어, 데이터 엔지니어 등)가 포함되어야 함
위와 같이 할 경우 아래와 같은 이점이 있다.
- 작고, 목적 지향적인 분석 모델이 유기적으로 연결 가능
- 다양한 바운디드 컨텍스트 간 조합을 통해 BI 리포트와 대시보드 유연성 향상
- 로컬 변환/조합이 용이해짐
3.3. 자율성과 책임
데이터 메시 아키텍처에서는 각 도메인 팀이 독립적으로 데이터 제품을 만들 수 있어야 한다.
이 자율성은 분석 데이터를 빠르게 제공하고, 소비가 요구를 반영하는데 핵심적인 역할을 한다.
그러나 자율성만 강조하면 각 팀이 제각기 분석 데이터를 구현하게 되어 중복된 투자와 연동의 복잡성이 발생한다.
이를 방지하기 위해서는 공통 플랫폼이 자율성과 표준화 사이의 균형을 제공해야 한다.
<플랫폼의 역할: 데이터 제품의 실행 기반 추상화>
- 데이터 메시 환경에서는 플랫폼이 제품 팀의 복잡도를 숨겨주는 역할을 함
- 각 팀은 자신의 도메인 데이터를 활용해 데이터 제품을 만들거나, 다른 팀이 만든 데이터 제품을 재사용할 수 있어야 함
- 이 때 데이터 제품의 생성, 배포, 접근, 보안, 모니터링을 지원하는 통합 플랫폼이 필요함
<데이터 인프라스트럭처 플랫폼 팀의 역할>
- 데이터 제품의 설계 청사진 제공
- 데이터 접근을 위한 단일화된 인터페이스와 패턴 정의
- 보안을 위한 접근 제어 정책 수립
- 다양한 데이터 제품 유형에 맞는 저장소 유형 제공
- 예) DB, Object Storage, Kafka 토픽 등
- SLA 보장을 위한 모니터링 및 품질 감시 체계 운영
즉, 데이터 메시에서 자율성을 보장하려면 자유로운 데이터 제품 생산과 소비가 가능해야 한다.
하지만 이 자율성이 조직 전체의 기술 부채로 이어지지 않도록 데이터 플랫폼 팀이 표준화된 기반을 제공하고 복잡성을 추상화하는 역할을 수행해야 한다.
그 결과로 조직은 자율성과 일관성이라는 두 마리 토끼를 모두 잡을 수 있게 된다.
3.4. 에코시스템으로서의 플랫폼
데이터 메시 아키텍처는 단일 데이터 허브를 없애는 대신, 여러 바운디드 컨텍스트가 독립적이면서도 유기적으로 연결되는 분석 데이터 네트워크를 지향한다.
이러한 분산 구조가 원활하게 작동하려면, 모든 제품이 일관된 규칙과 기준 아래에서 설계되고 상호작용해야 한다.
이를 가능하게 하는 것이 바로 연합 거버넌스(Federated Governance) 다.
<연합 거버넌스 그룹의 구성과 역할>
- 조직 내의 도메인 팀 제품 오너, 데이터 인프라스트럭처 플랫폼 팀 재표, 분석 데이터 사용 부서의 이해 관계자 참여하는 협업 체계
- 전사적 차원의 데이터 제품 설계 가이드라인 정의
- 공통 스키마/포맷/메타데이터 기준 제정
- 인터페이스 표준화, 문서화 및 검토
- SLA, 보안, 접근 제어, 품질 기준 등 운영 정책 수립
- 이행 여부를 감시하고, 에코시스템 전반의 일관성을 유지
- 즉, 바운디드 컨텍스트 내에서 자율적으로 설계된 제품들이 서로 호환되도록 만드는 규칙과 가이드라인을 정의하고 집행
데이터 메시 아키텍처가 성공적으로 정착되기 위해서는 각 팀의 자율성과 더불어 전사적 연합 거버넌스 체계가 필수적이다.
- 모든 데이터 제품은 호환성과 재사용성을 고려하여 설계되어야 하며,
- 이를 보장하기 위해 규칙과 문화는 거버넌스 그룹을 통해 정의되고 유지된다.
이로써 조직은 데이터 메시 기반의 지속 가능한 분석 생태계를 구축하게 된다.
3.5. 데이터 메시와 도메인 주도 설계를 엮기
데이터 메시 아키텍처는 DDD 와 동일한 철학적 기반 위에 있다.
경계를 명확히 설정하고, 경계 밖에서는 잘 정의된 출력 포트 뒤로 구현 상세를 감추는 방식은 DDD 의 바운디드 컨텍스트 개념과 완전히 일치한다.
<데이터 메시와 DDD 의 공통된 4가지 원칙>
- 유비쿼터스 언어와 도메인 지식 기반 설계
- 분석 모델은 해당 도메인 팀의 언어와 업무 맥락을 기반으로 설계되어야 함
- 데이터 웨어하우스와 데이터 레이크는 도메인 지식없이 만든 통합 모델이기 때문에 부족함
- 오픈 호스트 패턴
- 실시간 데이터 모델과는 다른 형태로 외부에 데이터를 제공하는 것은 오픈 호스트 패턴임
- 바운디드 컨텍스트에서 분석 모델 전용 포트를 외부에 노출하는 것이 이에 해당함
- CQRS 패턴
- 읽기(분석) 전용 모델을 분리하여 설계할 수 있음
- 동일한 도메인 데이터를 기반으로 여러 분석 모델 생성 가능
- 여러 버전의 분석 모델을 동시에 유지하는데 효과적
- 분석 모델 간 바운디드 컨텍스트 연동
데이터 메시는 단순한 분석 인프라 모델이 아니라 DDD 설계 원칙이 분석 영역으로 확장된 형태이다.
유비쿼터스 언어, 오픈 호스트, CQRS, 바운디드 컨텍스트 연동 패턴 모두가 분석 데이터 모델링에서도 그대로 활용될 수 있다.
즉, 데이터 메시 = 분석을 위한 DDD 기반 아키텍처 라고 볼 수 있다.
참고 사이트 & 함께 보면 좋은 사이트
본 포스트는 블라드 코노노프 저자의 도메인 주도 설계 첫걸음을 기반으로 스터디하며 정리한 내용들입니다.
