Ch16. 데이터 메시
이번 장에서는 분석 데이터 관리 아키텍처(analytical data management architecture), 일명 메시(data mesh)에 대해서 배워보자.
[분석 데이터 모델과 트랜잭션 데이터 모델의 비교]
분석 데이터는 회사에 축적된 데이터를 활용하여 비즈니스를 최적화하는 방법에 대한 통찰을 얻고 고객의 요구사항을 더 잘 이해하며 기계 학습(ML) 모델의 훈련을 통해 자동으로 의사결정을 내릴 수 있는 힘을 준다.
분석 모델(OLAP)과 실시간 데이터 모델(OLTP)은 서로 다른 유형의 사용자를 지원하고, 다른 종류의 유스케이스를 구현하며, 그래서 결국에는 다른 설계 원칙을 따른다.
실시간 데이터 모델은
- 시스템의 비즈니스 도메인에 속한 다양한 엔티티를 중심으로 구축되고, 이들의 수명주기를 구현, 상호작용을 조율한다.
- 즉 실시간 비즈니스 트랜잭션을 지원하도록 최적화되야 한다.
반면 분석 모델은
- 실시간 데이터 처리 시스템에 대한 다양한 통찰을 제공하도록 고안됨
- 비즈니스 활동의 성과에 대한 통찰을 제공을 목표
- 더 중요한 건 더 많은 비즈니스 가치를 얻도록 운영을 최적화하는 방법 제공을 목표
팩트 테이블
팩트(fact)는 이미 발생한 비즈니스 활동을 나타낸다.
예를 들어 팩트 테이블 Fact_Sales는 확약된 판매 레코드를 담는다.
또한 도메인 이벤트와 비슷하게 팩트 레코드는 절대로 삭제되거나 수정되지 않는다.
현재 데이터가 만료됐다는 것을 표현하는 유일한 방법은 새로운 레코드를 추가하는 것이다.
OLAP와 OLTP 모델의 또 다른 차이점은 데이터의 세분화 정도이다.
실시간 데이터 처리 시스템은 가장 정밀한 데이터가 필요하다.
디멘전 테이블
분석 모델에서 또 다른 중요한 구성요소는 디멘전이다.
팩트가 비즈니스 절차 또는 동작을 표현한다면(동사), 디멘전은 팩트를 묘사한다(형용사).
디멘전은 팩트의 속성을 설명하도록 고안되어 팩트 테이블에 있는 외부 키로 디멘전 테이블을 참조한다.
디멘전이 고도로 정규화된 이유는 분석 시스템에서 유연한 질의를 지원해야 하기 때문이다.
그래서 분석 모델은 정규화를 통해서 동적인 질의 및 필터링을 지원하고, 다양한 팩트 데이터에 대한 그룹화를 지원한다.
분석 모델
그림 16-5에 표현된 테이블 구조를 스타 스키마(star schema)라고 부른다.
팩트와 디멘전의 관계가 다대일(many-to-one)인 경우다.
또 다른 지배적은 분석 모델은 스노플레이크 스키마(snowflake schema)이다.
스타 스키마와 다른점은 디멘전이 여러 수준으로 구성된다.
추가적인 정규화로 인해 스노플레이크 스키마는 더 작은 공간에 디멘전 데이터를 저장할 수 있다.
스타 시크마와 스노플레이크 스키마 모두 데이터 분석가가 비즈니스 성과를 분석하고 무엇을 최적화할지에 대한 통찰을 얻게 하며 BI(Business Intelligence) 리포트를 만들 수 있게 한다.
[분석 데이터 관리 플랫폼]
이제부터 데이터를 생성하고 분석 데이터를 제공하는 데이터 관리 아키텍처에 대해 논의해보자.
이번 절에는 데이터 웨어하우스와 데이터 레이크, 두개의 일반적은 분석 데이터 아키텍처에 대해 논의해보자.
데이터 웨어하우스
데이터 웨어하우스(DWH)의 아키텍처는 비교적 간단하다.
기업의 모든 실시간 데이터 처리 시스템에서 데이터를 추출해 분석 모델로 변환 후, 분석 지향 데이터베이스에 적재한다.
이 데이터베이스가 바로 데이터 웨어하우스다.
데이터 관리 아키텍처는 기본적으로 ETL(extract-transform-load) 스크립트를 기반으로 한다.
데이터는 실시간 데이터 처리 데이터베이스, 스트림 이벤트, 로그 등 다양한 원천에서 수집된다.
원천 데이터를 팩트/디멘전 기반 모델로 변환하는 것과 더불어 변환 단계에서는
- 민감한 데이터 삭제 및 중복 레코드 제거
- 이벤트의 순서 조정 및 작은 크기의 이벤트를 합치는
등의 추가 작업도 진행될 수 있다.
위 그림을 살펴보면 우선 데이터 웨어하우스 아키텍처의 중심에는 엔터프라이즈 전반의 모델을 구축하는 목표가 있다.
모델은 기업의 모든 시스템에서 생성되는 데이터를 묘사하고, 다양한 분석 데이터의 사용 사례를 다뤄야 한다.
(비즈니스 최적화, 운영 비용 절감, 지능적인 비즈니스 의사결정, 리포팅, ML 모델 훈련 등)
모든 상황을 아우르는 모델을 구축하기 어려울 땐 데이터 마트(data mart)를 통해 해결할 수 있다.
데이터 마트는 단일 비즈니스 부서의 분석과 같이, 잘 정의된 분석 요구사항에 관련된 데이터를 저장하는 일종의 데이터베이스다.
데이터 웨어하우스 아키텍처의 어려운 점은 ETL 프로세스 분석가(OLAP) 시스템과 실시간 데이터 처리(OLTP) 시스템 간에 강력한 결합을 만든다는 것이다.
이러한 몇 가지 단점은 데이터 레이크 아키텍처(data lake architecture)에서 해결한다.
데이터 레이크
데이터 레이크 기반 시스템은 실시간 데이터 처리 시스템으로부터 데이터를 받는다.
그러나 바로 변환하는 것이 아니라 원본 형태, 즉 원래의 실시간 데이터 모델로 보관한다.
그러므로 원본 데이터는 데이터 분석의 요건에 맞지 않는다.
데이터 엔지니어와 BI 엔지니어는 데이터 레이크의 데이터를 이해하고 분석 모델을 생성하는 ETL 스크립트를 구현하며, 이를 데이터 웨어하우스에 제공해야 한다.
그림 16-10에 데이터 레이크 아키텍처를 표현했다.
실시간 데이터 처리 시스템의 데이터는 원본 형태로 저장되고 나중에 변환되므로 데이터 레이크에서는 다양한 작업 지향 분석 모델을 작동시키는 것이 가능하다.
예를 들어 어떤 모델은 리포팅에, 다른 모델은 ML 훈련에 사용하는 식이다.
데이터 웨어하우스와 데이터 레이크 아키텍처의 도전과제
모델링 관점에서 보면 두 아키텍처 모두 실시간 데이터 처리 시스템의 경계를 침범해서 구현 상세에 대한 의존성을 생성한다.
이 같은 구현 모델에 대한 결합도는 종종 분석 시스템의 ETL 작업이 깨지지 않도록 실시간 데이터 모델에 대한 변경을 막는 지경까지 이르게 된다.
데이터 웨어하우스와 데이터 레이크의 이러한 한계는 새로운 분석 데이터 관리 아키텍처인 데이터 메시의 탄생에 영감을 준다.
[데이터 메시]
어떤 의미에서 데이터 메시 아키텍처는 분석 데이터를 위한 도메인 주도 설계라고 볼 수 있다.
데이터 메시 아키텍처는 분석 데이터에 대한 모델과 소유 경계를 정의하고 프로젝션한다.
데이터 메시 아키텍처는
- 도메인 기준의 데이터 분리
- 제품 관점에서 데이터 다루기
- 자율성 활성화
- 에코시스템 구축
의 네 가지 핵심 원칙을 기반으로 한다.
도메인 기준의 데이터 분리
데이터 메시 아키텍처는 모놀리식 분석 모델을 구축하는 대신, 실시간 데이터를 위한 솔루션, 즉 원천 데이터에 분석 모델을 일치시켜서 데이터를 사용하므로 여러 분석 모델을 사용할 수 있다.
즉, 분석 모델의 소유권 경계를 자연스럽게 바운디드 컨텍스트의 경계와 일치시키게 된다.
각 바운디드 컨텍스트는 이제 자신의 실시간 데이터 처리(OLTP) 모델과 분석(OLAP) 모델을 소유한다.
결과적으로 실시간 데이터 모델을 소유한 팀이 이제 그것을 분석 모델로 변환하는 책임을 진다.
제품 관점에서 데이터 다루기
제품 관점에서 데이터 다루기 원칙에서는 분석 데이터를 제일 중요하게 다뤄야 한다.
데이터 메시 기반 시스템에서는 그림 16-13의 예시처럼 바운디드 컨텍스트가 잘 정의된 출력 포트를 통해 분석 데이터를 제공한다.
분석 데이터는 통상적인 퍼블릭 API와 동일하게 취급돼야 한다.
- 필요한 앤드포인트인 데이터 출력 포트를 쉽게 찾을 수 있어야 한다.
- 분석 엔드포인트는 제공하는 데이터와 형식을 설명하는 잘 정의된 스키마를 가져야 한다.
- 분석 데이터는 신뢰할 수 있어야 하고 서비스 수준 계약(SLA)을 정의하고 모니터링 해야 한다.
- 분석 모델은 버전 관리를 하고, 연동을 망가뜨리는 변경을 관리해야 한다.
분석 데이터 관리 아키텍처의 목표는 조직의 데이터 분석 요건을 충족할 수 있도록 작은 크기의 분석 모델이 엮일 수 있게 하는 것이다.
마지막으로 사용자마다 여러 형태의 분석 데이터가 필요할 수도 있다.
결국 데이터 제품은 다양한 사용자의 요구사항을 충족하는 여러 형태의 데이터를 제공해야 한다.
자율성 활성화
제품 팀은 자신의 데이터 제품을 만들 수도 있고, 다른 바운디드 컨텍스트에서 제공하는 데이터 제품도 사용할 수 있어야 한다.
즉, 데이터 제품은 상호운용이 가능해야 한다.
분석 데이터를 제공하기 위해 각 팀이 자신의 솔루션을 구축하는 것은 소모적이고, 효과적이지 않으며 연동도 어렵다.
이를 방지하려면 플랫폼이 상호운용이 가능한 데이터 제품의 구축, 실행, 유지보수의 복잡성을 추상화해야 한다.
에코시스템 구축
마지막으로 분석 데이터 관점에서 상호운용과 에코시스템을 가능하게 할 연합 거버넌스 기구를 임명하자.
거버넌스 그룹은 상호운용이 가능한 정상적인 에코시스템을 보장하는 규칙을 정의할 책임이 있다.
데이터 메시와 도메인 주도 설계 엮기
데이터 메시 아키텍처가 기반으로 하는 네 가지 규칙이 있다.
- 유비쿼터스 언어와 결과 도메인 지식은 분석 모델 설계를 위한 필수 요소다.
- 자신의 실시간 데이터 모델과 다른 모델로 바운디드 컨텍스트 데이터를 노출하는 것은 오픈 호스트 패턴이다.
- CQRS 패턴은 동일한 데이터에 대한 여러 모델을 쉽게 생성해준다.
- 데이터 메시 아키텍처는 분석 유스케이스를 구현하기 위해 다양한 바운디드 컨텍스트 모델을 묶는다.
- 때문에 실시간 데이터 모델을 위한 바운디드 컨텍스트의 연동 패턴은 분석 모델에도 적용된다.
[결론]
데이터 메시 아키텍처는 전통적인 데이터 관리 아키텍처의 어려움을 해결하는 데 목적이 있다.
발전 과정은
- 데이터 웨어 하우스 → 데이터 레이크 → 데이터 메시
이다.
데이터 메시 아키텍처는 도메인 주도 설계와 동일한 원칙이 적용된다.
결국 CQRS와 바운디드 컨텍스트 연동 패턴은 데이터 메시 아키텍처의 구현을 지원한다.
✅ Ch16 요약 섹션
핵심 포인트 (Key Takeaways)
- 데이터 웨어하우스는 기업 전반의 분석 모델을 목표로 하지만, ETL이 OLTP와 강한 결합을 만들 수 있어 운영 부담이 크다.
- 이를 보완하는 방식으로 데이터 마트 등 분석 요구에 맞춘 확장 방식이 등장한다.
- 즉 분석 아키텍처는 단순 저장이 아니라, “조직 전체 의사결정/리포팅/ML”을 지원하기 위한 구조적 선택이다.
실무 연결 포인트 (How to apply)
- 운영 DB로 분석까지 해결하려는 순간 병목/결합이 생긴다 → 분석 모델을 별도로 분리해야 한다.
- 결국 데이터 설계는 기능 개발과 별개로, “조직이 무엇을 보고 의사결정하는지”와 직접 연결된다.
- 광고/배치/정산 시스템처럼 지표가 중요한 조직일수록 데이터 아키텍처는 성능보다 “결합 제거”가 핵심이다.
한 줄 인사이트
트랜잭션 모델이 ‘정확한 처리’를 위한 것이라면, 분석 모델은 ‘더 나은 의사결정’을 위한 제품이다.
'Book Notes' 카테고리의 다른 글
| [개발서적] 도메인 주도 설계 첫걸음 4부(ch14~15) 요약 (1) (0) | 2026.01.13 |
|---|---|
| [개발서적] 도메인 주도 설계 첫걸음 3부(ch12~13) 요약 (2) (0) | 2026.01.11 |
| [개발서적] 도메인 주도 설계 첫걸음 3부(ch10~11) 요약 (1) (0) | 2026.01.11 |
| [개발서적] 도메인 주도 설계 첫걸음 2부(ch7~9) 요약 (2) (0) | 2026.01.11 |
| [개발서적] 도메인 주도 설계 첫걸음 2부(ch5~6) 요약 (1) (0) | 2026.01.11 |