모두에게 맞는 한 가지 사이즈는 없다: 여러분에게 맞는 데이터 메시 만들기

참고: 이 내용은 2021. 12. 1에 게시된 컨텐츠(No One Size Fits All: Make the Right Data Mesh for You)에서 번역되었습니다.

데이터 조직의 구조 중 두루 적용되는 구조는 정말로 없습니다. 이전 블로그에서 허브 앤 스포크(hub-and-spoke) 조직 모델에 대해 설명했습니다. 이러한 우수 센터는 중앙 집중식 조직 구조로 여겨지는 경향이 있습니다(이름에 ‘센터’라는 단어가 있기 때문일 수 있음). 그러나 허브 앤 스포크 모델을 사용하면 스포크 내에서 수행할 수 있거나 수행해야 하는 모든 작업을 중앙 집중화할 필요가 없습니다. 저는 CoE를 조정 메커니즘에 가깝게 생각하고 싶습니다. 이를 Coordination of Excellence라고 부릅시다. 다행히 CoE라는 약어를 유지할 수 있겠습니다.

성숙해짐에 따라 구심력이 발생

모든 스포크가 동등하게 성숙한 것은 아니며 성숙도는 시간이 지남에 따라 변경될 수 있습니다. 그렇다면 문제는 책임을 어떻게 분담할 것인가입니다. 일부 사업부 또는 기능은 더 많은 자율성을 원하거나 필요로 합니다. 예를 들어, 마케팅 팀이 고객 데이터 수집 및 사용에 있어 더욱 성숙해짐에 따라 고객 데이터 플랫폼(CDP)을 보다 긴밀하게 관리하고 마케팅 지원, 캠페인 타겟팅 및 기여를 최적화하기 위한 자체 의제를 개발하고 싶어할 수 있습니다. 또는 제품 팀이 제품 기능을 개선하고 수요를 예측하며 고객에게 직접 통찰력을 제공하기 위해 제품 데이터를 분석하는 기능을 구축합니다. 그들은 파이프라인을 위한 중앙 데이터 엔지니어링 팀이나 분석을 위한 중앙 BI 또는 분석을 위한 데이터 과학 팀에 덜 의존하고자 합니다. 또 다른 시나리오는 지역 조직 중 인수한 곳이 자체 데이터 인프라와 전문 지식을 갖고 있고 어느 정도 독립성을 유지하려는 경우입니다.

대신에 반드시 중앙 집중화가 아닌 조정을 통해 이러한 구심력을 충족시키는 것이 답입니다. 그리고 이것이 CoE 허브가 처음에 일관된 데이터 거버넌스 정책, 공통 정의 및 형식, 표준 데이터 활용 능력 및 기타 교육, 공유된 모범 사례 및 기타 조정된 기능 및 서비스와 함께 수행하도록 의도된 것입니다. 데이터 파이프라인 및 데이터를 ‘소유’할 수 있는 데이터 생산자와 소비자가 사용하도록 합시다. 잘 통제된 데이터 생태계 내에서 사용 사례의 우선순위를 지정하고 실행합니다.

기술이나 성숙도가 없는 다른 사람들을 위해 CoE에는 대여 및 스포크에 포함할 전문가 벤치가 있을 수 있습니다. 예를 들어 HR은 채용을 개선하거나 직원 유지율을 높이거나 복리후생 패키지를 최적화하기를 원할 수 있습니다. 스톡홀름에서 열린 최근 컨퍼런스에서 Bombardier Recreational Products의 CDO는 이러한 종류의 하이브리드 조직 모델을 옹호했습니다.

위의 스푸트니크 그래픽에서 설명하고 있지만 조직도에서는 어떻게 표시될까요? 분산 모델에서 각 기능 또는 비즈니스 단위에는 자체 데이터 팀이 있습니다. 이 모델은 사업부에 근접성을 제공하지만 종종 조정되지 않은 정책 및 관행의 사일로를 초래합니다. 중앙 집중식 모델은 허브가 데이터 프로젝트를 주도하고 우선순위를 관리하고 정책을 시행하기를 제안합니다. 하이브리드 모델에서 중앙 데이터 팀은 다른 부서에 자체 팀이 있는 일부 기능에 대한 데이터 프로젝트를 돕습니다. 유사한 하이브리드 모델에서 기능 데이터 팀은 두 그룹의 요구 사항을 충족할 수 있습니다. 하이브리드 모델에서 중앙 팀은 일관된 정책 세트와 모범 사례 공유를 조정하는 CoE 역할을 합니다.

데이터 메시 이해

그러나 놀이터 반대편에서는 데이터 아키텍처와 조직에 대해 다르지만 관련된 토론이 벌어지고 있는 것 같습니다. 비교적 새로운 데이터 메시 개념은 데이터 기능의 중앙 집중화에 관한 생각에 도전해오며, 데이터 아키텍처 및 소유권의 분산화를 주장했습니다. 그러나 그것이 조직 구조에 의미하는 바는 무엇일까요? 최근 블로그 데이터 메시: 허수아비 논쟁인가?는 현재 논의가 조직 구조와 인프라 아키텍처라는 두 가지 문제를 혼동하고 있음을 시사합니다.

블로그에서 지적했듯이, 데이터 메시 개념이 해결하는 주요 문제는 중앙 집중식 데이터 소유권으로 인해 발생하는 병목 현상입니다. 단일 팀이 여러 소스 도메인에서 여러 데이터 소비자에 이르는 파이프라인 요구 사항을 지원합니다. 중개자로서 이 팀은 요청에 압도되어 데이터를 ‘효과적이고 정확하게 변환’하기 위한 도메인 지식과 사용 사례 요구 사항이 모두 부족합니다. 그리고 그 중앙 팀 구조는 데이터 생산자를 다운스트림 처리 및 사용에서 제거합니다. 데이터 메시 개념은 데이터의 도메인 소유권을 옹호합니다. 데이터 소스를 가장 잘 이해하고 잠재적인 데이터 소비자와 직접 작업할 수 있는 사람이 보다 적절한 데이터 제품 및 서비스를 제공합니다. 그러나 데이터 파이프라인 소유권의 변화와 데이터 제품 개념의 도입이 반드시 하나의 특정 아키텍처를 지시하는 것은 아닙니다.

그 허수아비 논쟁은 모두 분산된 데이터 소유권을 허용하는 두 가지 경쟁하는 아키텍처를 대조하는 잠재적으로 유용한 비유를 제공합니다.

동일한 모양의 집에 따로 사는 가족과 큰 규모의 한 집에 여러 가족이 사는 경우에 비유하자면, 얻을 수 있는 점유의 수준이 다소 다릅니다. 전자의 경우 우리가 같은 건물을 공유할 때보다 타협의 필요성이 적으면서 주거의 모양을 만들어내는 능력이 훨씬 더 높습니다. 그러나 이것은 우리가 시행하고자 하는 표준에서 벗어날 위험이 더 큽니다. 아마도 진정한 목표는 표준화된 접근 통제가 이루어지고 접근 및 위치가 동일하면서도 각 개별 유닛이 점유자의 요구에 맞춰질 수 있는 아파트 블록에 더 가깝습니다. 여기에서 중앙 데이터 플랫폼이 데이터의 도메인 수준 소유권을 완전히 활성화하는 동시에 표준화 및 거버넌스가 다루기 힘든 도전이 되지 않도록 하는 것을 볼 수 있습니다.

그러나 데이터 메시 개념이 독립적이거나 동일한 주택을 규정하지 않기 때문에 그 주장은 그 자체로 허수아비입니다. 그러나 제안된 대안인 아파트에 대해 더 생각해 봅시다. 모든 아파트가 똑같을까요? 더 중요한 것은 위에서 논의한 바와 같이 일부 팀은 자체 아파트가 필요하지 않거나 이를 원하지 않거나 자체 아파트를 유지 관리할 전문 지식이 없을 수 있습니다. 아마도 그 아파트 건물에는 학생 숙소와 같이 자신의 아파트에 대한 자원이나 필요가 없는 사람들을 위한 기숙사 또는 공유 아파트가 있습니다.

또는 사무실 건물이 더 나은 비유일 수 있습니다. 모든 회사가 자신의 회사를 가지고 있는 것은 아닙니다. 일부는 그럴 것입니다. 그러나 그들은 자신의 것을 만들지 않을 것입니다. 대부분의 회사는 필요에 따라 사무실 공간을 임대하며 이러한 요구는 시간이 지남에 따라 바뀔 수 있습니다. 아마도 가장 좋은 비유는 WeWork와 같은 역동적인 사무실 공간일 것입니다. 회사는 처음에는 공간과 서비스를 공유하지만 성숙함에 따라 자체 공간을 차지하고 더 많은 자체 서비스를 관리할 수 있습니다. 또한 고객 또는 파트너 회의를 위해 일시적으로 더 많은 공간이 필요할 수 있습니다. 그들은 수요 급증을 수용하고 성장에 따라 확장할 수 있는 유연한 공간이 필요합니다. 공간에 대한 접근 정책과 사용 권한은 건물 전체에 걸쳐 공통적이며 조정됩니다. 그것은 아마도 데이터 아키텍처에 대한 최고의 비유일 것입니다.

데이터 인프라는 서비스로 제공됩니다. CoE는 해당 인프라를 유지 관리하거나 IT와 긴밀하게 협력하여 유지 관리하고 사용에 적용되는 정책을 수립합니다. 보다 성숙한 데이터 도메인은 이러한 서비스를 사용하여 데이터 파이프라인을 개발 및 유지 관리하여 소비자 또는 다른 사람이 사용할 수 있는 데이터 제품을 만듭니다. 그러나 자신의 공간이 없는 팀도 있을 것입니다. 다른 조직과 공유하거나 중앙 서비스에 의존하여 때때로 공간을 차지할 수 있습니다.

스푸트니크가 데이터 메시를 만남

이를 위의 스푸트니크 도표로 다시 가져오면 공통 인프라 및 정책을 조정하기 위한 CoE 또는 메커니즘이 있으며 사업부 또는 기타 기능 영역을 나타내는 스포크가 있습니다. 일부 스포크는 데이터 도메인일 수 있습니다. 나머지는 소비자 도메인일 수 있습니다. 일부는 위 예에서의 마케팅 및 제품 스포크와 같이 둘 다일 수 있습니다. 마케팅 및 제품 팀은 공통 인프라를 활용하고, 공통 거버넌스 정책을 존중하고, 데이터 파이프라인 및 제품을 구축하고, 조직 전체에서 사용할 수 있도록 자체 데이터 도메인을 관리합니다. 덜 성숙하거나 덜 숙련된 스포크는 필요한 데이터 서비스를 위해 마케팅 또는 제품과 같은 다른 영역에 의존할 수 있습니다. 그리고 다른 사람들은 일반 데이터 과학 ‘도메인’에서 제공하는 임시 데이터 서비스에 의존할 수 있습니다. 즉, 필요와 우선순위에 따라 할당된 리소스 풀입니다.

결론: 두루 적용되는 것은 없습니다. 그리고 지금의 상황에 맞는 것이 다른 상황에는 맞지 않을 수 있습니다. 조직 구조와 데이터 아키텍처는 조직 전체의 기술, 리소스, 데이터 및 분석 요구 사항을 반영해야 합니다. 그리고 여러분이 내리는 선택은 위의 모든 것에서 미래의 변화를 수용할 수 있어야 합니다.