[데이터 메시] - 2편. 데이터의 도메인 오너십 원칙

데이터 메시의 핵심은 도메인별로 데이터 책임을 분배하고 탈중앙화하는 것입니다. 이는 조직의 스케일 아웃 아키텍처와 지속적이고 빠른 변경 주기를 지원하기 위한 전략으로, 데이터 관리와 분석을 각 도메인 팀에게 이전하여 데이터 활용의 효율성과 유연성을 높입니다. 각 도메인에서 가장 잘 알고 있는 사람이 데이터에 대한 책임을 맡게 되고, 해당 데이터의 일급 사용자이거나 데이터의 오리진을 제어하는 도메인이 책임을 맡는데, 이를 데이터의 도메인 오너십 원칙이라고 합니다.

•

예를 들어, 마케팅 도메인과 판매 도메인이 있다고 가정해봅시다. 마케팅 팀은 캠페인 성과 데이터를 관리하고, 판매 팀은 판매 실적 데이터를 관리합니다. 중앙에서 모든 데이터를 관리하려 하면, 두 도메인의 데이터 요구사항이 충돌할 수 있지만, 데이터 메시에서는 각 도메인이 독립적으로 데이터를 관리하고 필요할 때 데이터를 공유할 수 있습니다. 이를 통해 각 도메인은 자신의 데이터에 대해 책임을 지고, 필요한 데이터를 효율적으로 활용할 수 있습니다.

DDD 전략의 배경

도메인 주도 설계(Domain-Driven Design, DDD)는 비즈니스의 이음매(seam)를 기반으로 소프트웨어 설계와 팀 할당을 분해하는 접근 방식입니다. 여기서 도메인을 '지식, 영향력, 또는 활동의 영역'으로 정의하며, 이는 해당 도메인에서 발생하는 이벤트, 적용되는 규칙, 생성되는 데이터 등에 대한 깊은 이해를 필요로 합니다.

DDD를 통해 복잡한 시스템을 각 도메인의 특성에 맞게 분산 서비스로 구축하고, 도메인이 독립적이고 자율적으로 운영될 수 있도록 지원합니다. 이는 데이터 메시에서도 동일하게 적용되어, 분석 데이터 관리에서도 도메인 중심의 탈중앙화된 오너십을 채택하게 합니다.

DDD를 적용하지 못한 데이터 플랫폼 아키텍처

운영 시스템에서 도메인 중심의 탈중앙화된 오너십을 채택한 것처럼, 분석 데이터 범위에서도 동일한 접근이 필요합니다. 하지만 대부분의 데이터 플랫폼 아키텍처는 이를 제대로 반영하지 못했습니다. 기존 아키텍처는 중앙 집중식 모델링을 통해 모든 도메인의 데이터를 하나로 통합하려 했으나, 이는 다음과 같은 문제를 초래했습니다:

중앙 집중화된 모델링의 한계

모든 도메인 모델을 하나로 통일하는 것은 비효율적이며, 변경 시 병목 현상을 유발합니다.

•

예를 들어 정답률이라는 데이터 프로덕트를 만들려고 할 때, 콘텐츠 관점에서는 한 문제에 대한 누적된 데이터를 통한 정답률이 될 수도 있고, 선생님 관점에서는 한 학생이 시험 문제를 얼마나 많이 맞췄는지를 확인하는 데이터가 될 수도 있습니다. 이처럼 다양한 관점의 데이터를 모델링한다는 것은 매우 오래 걸리고 구조가 복잡해집니다.

•

데이터 웨어하우스에 특정 데이터 프로덕트와 관련된 데이터를 현재 시점을 기준으로 모델링해서 모두 수집한 후, 칼럼의 갯수를 엄청나게 늘려서 저장할 수 있습니다. 하지만 모델링 이후에 실제 서비스 요구 사항에 맞춰 테이블에 칼럼이 추가되거나, 각 도메인에 변화가 생기면 이러한 부분을 모두 따라가기 매우 힘든 구조가 됩니다.

내부 모델의 사일로화

부서 간 데이터와 인사이트가 공유되지 않아 조직 전체의 효율성이 저하됩니다.

•

서로 다른 시스템, 데이터베이스, 애플리케이션 간의 연결 및 통합이 제한적이라는 것을 의미하고, 시스템 간 데이터 전송 및 처리에 있어서 비효율성을 초래하게 됩니다.

•

ETL이 파편화되기 쉽고 이러한 과정이 파편화되면, 데이터의 흐름이 불편리하고 비효율적이게 되어 각 애플리케이션은 정보의 고립된 섬처럼 되어버려 누구도 와서 활용할 수 없는 단계가 됩니다. 특히 데이터팀에서 다른 팀의 요청으로 ETL 파이프라인을 추가하였지만, 실제 요청한 팀에서 더 이상 사용하지 않아도 계속된 리소스만 사용될 수도 있습니다.

의도적인 모델링 부재

데이터 레이크에 미가공 데이터를 덤핑하는 등 체계적인 데이터 관리가 부족합니다.

•

모델링을 너무 하기 힘들어서 나중에 사용하겠지라는 생각으로 모든 데이터를 덤핑한 후에 그냥 방치하는 경우도 많이 존재합니다.

왜 DDD를 사용해야 하는가?

데이터 메시에서 DDD를 도입하는 이유는 다음과 같습니다.

1. 비즈니스 복잡성 관리

대규모 조직에서는 다양한 비즈니스 도메인이 존재하며, 각 도메인은 고유한 규칙과 데이터를 가지고 있습니다. DDD는 이러한 복잡성을 관리하기 위해 도메인을 명확히 정의하고, 각 도메인이 독립적으로 발전할 수 있는 기반을 제공합니다. 이를 통해 비즈니스 요구 사항의 변화에 유연하게 대응할 수 있습니다.

2. 팀 간의 명확한 경계 설정

DDD는 팀을 도메인별로 분할하여 각 팀이 자신의 도메인에 집중할 수 있도록 합니다. 이는 팀 간의 의존성을 줄이고, 각 팀이 독립적으로 작업할 수 있는 환경을 조성합니다. 결과적으로 개발 속도가 빨라지고, 병목 현상이 줄어들며, 전체적인 생산성이 향상됩니다.

3. 데이터 일관성과 품질 보장

각 도메인이 자체적으로 데이터 모델을 관리함으로써 데이터의 일관성과 품질을 높일 수 있습니다. 도메인 전문가들이 데이터를 관리하기 때문에 데이터의 맥락과 의미를 정확히 이해하고 반영할 수 있습니다. 이는 데이터 분석의 정확성을 높이고, 신뢰할 수 있는 인사이트를 도출하는 데 기여합니다.

4. 유연한 데이터 통합과 확장성

DDD는 경계 콘텍스트(boundary context)와 콘텍스트 매핑(context mapping)을 통해 서로 다른 도메인 간의 데이터 통합을 용이하게 합니다. 이는 새로운 도메인이 추가되거나 기존 도메인이 변경될 때, 전체 시스템에 미치는 영향을 최소화하고, 유연하게 확장할 수 있는 구조를 제공합니다.

5. 효율적인 데이터 거버넌스

DDD는 각 도메인이 자체적으로 데이터 거버넌스를 관리할 수 있도록 하여, 중앙 집중식 거버넌스의 복잡성과 병목 현상을 줄입니다. 각 도메인이 자신들의 데이터에 대한 책임을 지고, 정책과 표준을 준수함으로써 조직 전체의 데이터 품질과 일관성을 유지할 수 있습니다.

경계 콘텍스트와 콘텍스트 매핑

데이터 메시에서는 DDD의 경계 콘텍스트(boundary context) 개념을 도입하여, 각 도메인마다 독립적인 데이터 모델을 관리하고, 이를 명확하게 연결하는 콘텍스트 매핑(context mapping)을 통해 데이터의 일관성과 상호작용을 유지합니다. 경계 콘텍스트는 특정 모델이 적용되는 범위를 정의하는 것으로, 특정 도메인 또는 비즈니스의 부분에 대해 만들어진 모델이며, 이 경계 안에서는 모델이 일관되고 명확하게 적용되고, 각각 독립적으로 개발될 수 있으며, 서로 다른 부문이나 팀이 관리할 수 있습니다.

•

사용자 관리 도메인과 결제 관리 도메인이 있다고 할 때, 두 도메인은 서로 다른 경계 콘텍스트를 가집니다. 사용자 관리 도메인은 사용자 정보와 관련된 모든 데이터를 관리하고, 결제 관리 도메인은 결제와 관련된 데이터를 관리합니다. 이 두 도메인 간의 데이터 상호작용은 콘텍스트 매핑을 통해 명확히 정의되어, 데이터 충돌 없이 효율적으로 통합될 수 있습니다.

데이터 메시와 DDD의 통합

데이터 메시를 구현할 때, DDD를 활용하여 각 도메인의 데이터 프로덕트를 파악하고, 비즈니스 구조를 도메인별로 분해하여 데이터를 모델링합니다. 이를 통해 데이터 관리의 복잡성을 줄이고, 각 도메인이 자율적으로 데이터를 관리할 수 있도록 지원합니다.

도메인 데이터의 아키타입

데이터 메시를 조직과 그 도메인에 매핑할 때, 몇 가지 도메인 데이터 아키타입이 존재합니다. 이는 데이터의 유형과 관리 방식을 정의하는 중요한 요소입니다.

소스 도메인 데이터

소스 도메인 데이터는 비즈니스의 사실을 나타내는 데이터로, 운영 시스템이 생성한 분석 데이터를 의미합니다. 이 데이터는 트랜잭션 워크로드에 최적화되어 저장되고 구조화되며, 운영 데이터와는 별개로 관리됩니다. 소스 도메인 데이터는 직접 드러내는 것은 안티패턴으로, CDC(Change Data Capture)나 데이터 가상화와 같은 방법을 통해 관리됩니다.

애그리거트 도메인 데이터

애그리거트 도메인 데이터는 여러 업스트림 도메인에서 집계된 분석 데이터를 의미합니다. 중요한 점은 애그리거트 도메인 데이터를 과도하게 생성하지 않는 것입니다. 모든 도메인의 데이터를 총체적으로 집계하면 데이터 관리가 복잡해질 수 있기 때문입니다.

소비자 도메인 데이터

소비자 도메인 데이터는 특정 사용 사례에 맞춰 변환되고 정렬된 데이터로, 주로 머신러닝 모델 학습에 사용됩니다. 이는 구체적인 비즈니스 요구에 맞춘 데이터로, 데이터 파이프라인을 통해 효율적으로 제공됩니다.

데이터의 도메인 오너십 원칙 적용하기

데이터 메시의 성공적인 구현을 위해서는 데이터의 도메인 오너십 원칙을 효과적으로 적용하는 것이 중요합니다. 다음은 이를 구현하기 위한 네 가지 주요 원칙입니다:

1. 데이터 오너십을 업스트림에 푸시하라

데이터의 생산지에서 직접 데이터 관리 책임을 지도록 함으로써, 데이터의 정확성과 효율성을 높입니다. 데이터 메시에서는 소스 도메인이 소스 운영 프로그램이 아닌 도메인의 분석 데이터를 직접 수취하여 사용할 수 있습니다. 데이터 관리의 초기 단계부터 데이터의 생산지에서 책임을 지는 것이 중요합니다.

•

마케팅 도메인이 캠페인 데이터를 생성할 때, 해당 도메인이 직접 데이터를 관리하고 책임지면 데이터의 정확성과 최신성을 보장할 수 있습니다. 이는 중앙 팀에 의존하지 않고도 데이터의 품질을 유지할 수 있게 합니다.

2. 여러 모델을 연결하여 정의하라

중앙 데이터 거버넌스 팀이 하나의 표준 모델을 찾기보다는, DDD의 경계 콘텍스트와 콘텍스트 매핑을 통해 서로 다른 도메인 간의 데이터 모델을 명확하게 정의하고 연결합니다. 이는 서로 다른 도메인에서 같은 개념을 가진 여러 모델이 존재해도 문제없이 관리할 수 있도록 합니다.

•

사용자 도메인과 판매 도메인에서 "고객"이라는 개념을 각각 다른 방식으로 모델링할 수 있습니다. 경계 콘텍스트와 콘텍스트 매핑을 통해 두 도메인의 "고객" 데이터가 어떻게 상호작용할지를 정의하면, 데이터 일관성을 유지하면서도 각 도메인의 독립성을 보장할 수 있습니다.

3. 관련성 높은 도메인 데이터를 수용하되, 단일 진실 공급원에 의존하지 마라

같은 데이터를 도메인별로 재형성하고 재구성하여, 단일 진실 공급원의 개념에 얽매이지 않도록 합니다. 이는 동적 토폴로지 환경에서 데이터의 유연성을 유지하는 데 필수적입니다.

•

재고 도메인과 주문 도메인이 같은 제품 데이터를 사용하더라도, 각 도메인은 자신의 필요에 맞게 데이터를 재구성하여 사용할 수 있습니다. 이는 단일 진실 공급원에 의존하지 않으면서도 데이터의 일관성을 유지할 수 있게 합니다.

4. 데이터 파이프라인을 도메인 내부에서 구현하듯이 은닉하라

데이터 파이프라인을 도메인 내부에서 관리하여, 데이터의 변환과 이동을 간소화하고 중복을 방지합니다. 데이터 메시의 데이터 파이프라인은 도메인 내에서 미리 이벤트를 클렌징하고 복사하여 보강하는 기능을 포함해야 합니다.

•

주문 도메인 내부에서 주문 데이터를 클렌징하고 필요한 형식으로 변환한 후, 다른 도메인으로 전달하는 파이프라인을 구현하면 데이터의 일관성과 품질을 유지할 수 있습니다. 이를 통해 데이터 이동 과정에서 발생할 수 있는 오류를 최소화할 수 있습니다.

마무리

데이터의 도메인 오너십 원칙은 데이터 메시의 성공적인 구현을 위한 핵심 요소입니다. 이를 통해 조직 내 데이터 관리의 효율성을 높이고, 도메인별로 데이터 책임을 분담함으로써 빠르게 변화하는 비즈니스 환경에 유연하게 대응할 수 있습니다.

데이터 메시와 DDD를 통합함으로써, 조직은 데이터 관리의 복잡성을 줄이고, 각 도메인이 자율적으로 데이터를 관리할 수 있는 기반을 마련할 수 있습니다. 이러한 접근법은 데이터의 일관성과 품질을 보장하면서도, 유연성과 확장성을 유지할 수 있게 합니다.

다음 시리즈에서는 제품으로서의 데이터 원칙에 대해 다루며, Data Product가 무엇인지 알아보도록 하겠습니다.