데이터 메쉬 (Data Mesh) 원칙 — 도메인 소유권 (domain ownership), 데이터의 제품화 (data as a product), 셀프 서비스 데이터 플랫폼 (self-serve data platforms), 그리고 연합 거버넌스 (federated governance) — 는 기업이 데이터 아키텍처를 조직하는 방식을 재편하고 있습니다. 하지만 데이터 메쉬는 새로운 과제를 만들어냅니다. 만약 데이터가 개별 도메인에 의해 소유되고 셀프 서비스 플랫폼을 통해 소비된다면, 비즈니스 사용자들이 데이터 엔지니어가 되지 않고도 어떻게 도메인 간의 데이터를 발견하고, 이해하며, 쿼리(query)할 수 있을까요? MCP 통합 및 시맨틱 레이어 (semantic layers)를 갖춘 대화형 BI (Conversational BI)가 비기술적 소비자들을 위해 데이터 메쉬를 작동하게 만드는 사용자 접점 레이어로 부상하고 있습니다.

핵심 통찰 (Key Insight): 대화형 BI를 통해 데이터 메쉬를 구현하는 조직들은 도메인 간 데이터 액세스 속도가 50% 빨라지고, 데이터 엔지니어링 티켓(tickets)이 35% 감소했다고 보고합니다. 이는 비즈니스 사용자들이 맞춤형 데이터 파이프라인을 요청하는 대신 자연어를 통해 도메인 간 데이터를 쿼리하기 때문입니다.

데이터 메쉬 (Data Mesh): 빠른 요약

Zhamak Dehghani가 정의한 데이터 메쉬 (Data Mesh)는 도메인 중심의 셀프 서비스 데이터 인프라 아키텍처입니다. 네 가지 원칙은 다음과 같습니다: 도메인 소유권 (domain ownership, 데이터는 중앙 데이터 팀이 아닌 데이터를 생성하는 도메인에 의해 소유되고 관리됨), 데이터의 제품화 (data as a product, 각 데이터 도메인은 명확한 계약, 품질 SLA, 소비자 문서화를 갖춘 제품으로서 데이터를 취급함), 셀프 서비스 데이터 플랫폼 (self-serve data platforms, 중앙 집중식 데이터 엔지니어링 없이 도메인 팀이 데이터 제품을 구축하고 공유할 수 있게 하는 인프라), 그리고 연합 거버넌스 (federated governance, 거버넌스 표준과 정책은 중앙에서 정의되지만 자동화된 도구를 통해 도메인 수준에서 집행됨).

데이터 메쉬 (Data Mesh)의 가치 제안은 매우 설득력이 있습니다. 중앙 집중식 데이터 아키텍처 — 중앙 데이터 팀이 관리하는 데이터 웨어하우스 (Data Warehouse) 및 데이터 레이크 (Data Lake) — 는 조직이 확장됨에 따라 병목 현상을 초래합니다. 새로운 데이터 유스케이스 (Use case)가 발생할 때마다 중앙 팀은 파이프라인을 구축하고, 데이터를 모델링하며, 액세스 메커니즘을 생성해야 합니다. 이로 인해 중앙 팀은 데이터 기반 의사결정의 제약 요인이 되며, 데이터 요청 백로그 (Backlog)는 팀의 처리 속도보다 더 빠르게 증가합니다. 데이터 메쉬는 데이터 소유권과 인프라를 각 도메인 (Domain)으로 분산함으로써 이러한 중앙 병목 현상을 해결합니다.

하지만 데이터 메쉬는 소비 (Consumption) 측면의 과제를 발생시킵니다. 데이터가 각기 다른 데이터 제품 (Data product), 스키마 (Schema), 정의를 가진 도메인 전반에 분산되면, 비즈니스 사용자들은 데이터 메쉬가 해결하고자 했던 액세스 문제보다 어쩌면 더 어려운 발견 및 이해 문제에 직면하게 됩니다. 고객 데이터 (CRM 도메인 소유), 트랜잭션 데이터 (영업 도메인 소유), 그리고 참여 데이터 (마케팅 도메인 소유)를 결합하려는 마케팅 분석가는 이러한 데이터 제품들을 찾아내고, 그들의 스키마와 정의를 이해하며, 이들을 정확하게 조인 (Join)하는 쿼리를 작성해야 합니다. 이는 대부분의 비즈니스 사용자가 갖추지 못한 데이터 엔지니어링 (Data engineering) 기술을 요구합니다.

데이터 메쉬 소비 계층으로서의 대화형 BI (Conversational BI)

대화형 BI (Conversational BI)는 도메인 간 데이터 액세스의 복잡성을 숨겨주는 자연어 인터페이스 (Natural language interface)를 제공함으로써 데이터 메쉬의 소비 문제를 해결합니다. 마케팅 분석가가 '우리 4분기 디지털 캠페인을 통해 유입된 고객의 고객 생애 가치 (Customer lifetime value)는 얼마인가요?'라고 질문하면, 대화형 BI 시스템은 관련 데이터를 어느 도메인이 소유하고 있는지 (고객 데이터는 CRM, 캠페인 데이터는 마케팅, 매출 데이터는 재무), 각 도메인 내에서 적절한 데이터 제품을 발견하고, 그들의 스키마와 정의를 이해하며, 정확한 도메인 간 쿼리를 생성해야 합니다. 이 모든 과정은 사용자에게 투명하게 이루어져야 합니다.

이를 가능하게 하는 기술은 세 가지 핵심 구성 요소로 이루어져 있습니다. MCP 커넥터 (MCP connectors)는 각 도메인의 데이터 제품 (data products)에 대한 표준화된 접근을 제공합니다. 각 도메인은 명확한 기능 설명을 포함한 MCP 커넥터를 통해 데이터를 노출하며, 이를 통해 대화형 BI 시스템이 사용 가능한 데이터 제품을 발견하고 그 내용을 이해할 수 있게 합니다. 시맨틱 레이어 (semantic layer)는 일관된 정의를 사용하여 사용자의 자연어 질문을 올바른 도메인 데이터 제품에 대한 쿼리로 변환하는 교차 도메인 비즈니스 어휘 (cross-domain business vocabulary)를 제공합니다. AI 추론 레이어 (AI reasoning layer)는 사용자의 의도를 이해하고, 어떤 데이터 제품이 필요한지 결정하며, 교차 도메인 쿼리를 오케스트레이션 (orchestrate) 합니다.

이 아키텍처는 데이터 메쉬 (data mesh) 원칙을 보존하면서도 이를 소비 가능하게 만듭니다. 도메인 소유권 (Domain ownership)은 유지됩니다 — 각 도메인은 여전히 자신의 데이터 제품을 소유하고 관리합니다. 데이터 제품으로서의 데이터 (Data-as-a-product) 개념은 강화됩니다 — 잘 정의된 기능을 가진 명확한 MCP 인터페이스는 데이터 제품을 더 쉽게 발견하고 사용할 수 있게 만듭니다. 연합 거버넌스 (Federated governance)는 시맨틱 레이어를 통해 강제되며, 이는 교차 도메인 쿼리가 일관된 정의를 사용하고 데이터 액세스 정책을 준수하도록 보장합니다. 셀프 서비스 (Self-serve)는 비즈니스 사용자가 데이터 엔지니어링 도구를 배우게 함으로써가 아니라, 기술적 복잡성을 처리하는 자연어 인터페이스를 제공함으로써 달성됩니다. Beehive Strategy의 플랫폼은 바로 이러한 소비 레이어를 제공합니다 — 데이터 제품 접근을 위한 MCP 커넥터, 교차 도메인 일관성을 위한 시맨틱 레이어, 그리고 자연어 쿼리를 위한 대화형 인터페이스가 그것입니다.

데이터 메쉬를 위한 대화형 BI 구현

데이터 메쉬 (Data Mesh) 소비 계층 (consumption layer)으로서 대화형 BI (conversational BI)를 구현할 때는 데이터 메쉬 자체의 도메인 주도 방식 (domain-driven approach)을 따라야 합니다. 잘 정의된 데이터 제품 (data products)과 명확한 교차 도메인 유스케이스 (cross-domain use case)를 가진 2~3개의 도메인부터 시작하십시오. 예를 들어, 영업 (sales), 마케팅 (marketing), 재무 (finance) 도메인은 캠페인 ROI, 고객 획득 비용 (customer acquisition costs), 수익 귀속 (revenue attribution)에 관한 교차 도메인 질문에 답해야 하는 경우가 많습니다. 각 도메인의 데이터 제품을 위한 MCP 커넥터를 구축하고, 교차 도메인 시맨틱 모델 (semantic model)을 정의한 다음, 공유된 유스케이스를 위해 대화형 BI를 배포하십시오.

교차 도메인 시맨틱 모델은 가장 중요한 구현 산출물입니다. 이는 개념이 도메인 간에 어떻게 번역되는지를 정의해야 합니다. CRM 도메인의 '고객 (Customer)'은 영업 도메인의 '계정 (Account)' 및 재무 도메인의 '지불인 (Payer)'으로 매핑될 수 있습니다. 영업 도메인의 '수익 (Revenue)'은 예약 (bookings)을 의미할 수 있는 반면, 재무 도메인의 '수익 (Revenue)'은 인식된 수익 (recognised revenue)을 의미할 수 있습니다. 시맨틱 레이어 (semantic layer)는 이러한 매핑 문제를 해결하고 대화형 BI 시스템에 통일된 비즈니스 어휘를 제공합니다. 이를 통해 사용자는 어떤 도메인이 어떤 데이터를 소유하고 있는지, 또는 개념이 도메인 경계를 넘어 어떻게 매핑되는지를 알 필요 없이 자연스러운 비즈니스 언어를 사용하여 질문할 수 있습니다.

이 방식을 구현한 조직들은 두 가지 주요 이점을 보고하고 있습니다. 첫째, 교차 도메인 데이터 액세스 속도가 50% 빨라졌습니다. 비즈니스 사용자가 데이터 엔지니어링 지원을 요청하는 대신 자연어를 통해 도메인 간에 직접 쿼리할 수 있기 때문입니다. 둘째, 데이터 엔지니어링 티켓 (data engineering tickets)이 35% 감소했습니다. 이전에는 맞춤형 파이프라인 개발이 필요했던 많은 교차 도메인 데이터 요청이 이제 대화형 BI 시스템에 의해 처리되기 때문입니다. 이를 통해 데이터 엔지니어들은 개별 분석가의 요청을 위한 임시 (ad-hoc) 교차 도메인 파이프라인을 구축하는 대신, 자신의 도메인 내에서 새로운 데이터 제품을 구축하는 데 집중할 수 있습니다.

연합 데이터 아키텍처 (Federated Data Architecture)에서의 거버넌스 (Governance)

연합 거버넌스 (Federated governance)는 대부분의 조직이 구현하는 데 가장 어려움을 겪는 데이터 메쉬 (Data Mesh) 원칙입니다. 과제는 중앙 집중식 거버넌스 병목 현상을 만들지 않으면서, 독립적으로 관리되는 도메인 전반에 걸쳐 일관된 데이터 품질, 정의 및 액세스 정책을 보장하는 것입니다. 시맨틱 레이어 (Semantic layer)를 갖춘 대화형 BI (Conversational BI)는 우아한 해결책을 제공합니다. 즉, 거버넌스가 별도의 거버넌스 프로세스에 의해 강제되는 것이 아니라, 모든 교차 도메인 쿼리가 통과해야 하는 시맨틱 모델 (Semantic model) 내에 내장됩니다.

사용자가 교차 도메인 질문을 던질 때, 시맨틱 레이어는 여러 거버넌스 메커니즘을 집행합니다. 첫째, 액세스 제어 (Access control) — 시맨틱 레이어는 각 도메인의 액세스 정책을 존중하며, 사용자가 질문에 답하는 데 필요한 데이터 제품 (Data products)에 접근할 권한이 있는지 확인합니다. 둘째, 정의 일관성 (Definition consistency) — 시맨틱 레이어는 어떤 도메인의 데이터 제품이 기초 데이터를 제공하든 관계없이 동일한 비즈니스 개념이 동일한 정의를 사용하도록 보장합니다. 셋째, 품질 투명성 (Quality transparency) — 시맨틱 레이어는 쿼리 결과에 품질 점수와 신선도 지표 (Freshness indicators)를 부착할 수 있어, 사용자가 답변의 근거가 되는 데이터의 신뢰성을 알 수 있게 합니다.

이러한 거버넌스 접근 방식은 전통적인 중앙 집중식 데이터 거버넌스보다 더 효과적이며 관료주의적이지 않습니다. 거버넌스는 수동 검토 프로세스가 아닌 쿼리 시점에 자동으로 집행됩니다. 도메인 팀은 자신의 데이터 제품에 대한 자율성을 유지하는 동시에, 시맨틱 레이어는 교차 도메인 소비가 기업 표준을 충족하도록 보장합니다. 그 결과, 데이터 메쉬를 제약하는 것이 아니라 데이터 메쉬와 함께 확장되는 거버넌스 모델이 만들어집니다. 이는 데이터 메쉬 이론이 요구하지만 대부분의 조직이 실제로는 달성하기 어려워하는 바로 그 균형입니다.

이 기사는 원래 Beehive Strategy에 게시되었습니다. AI 기반 분석에 대한 더 많은 통찰력을 보려면 저희 블로그를 방문하세요.