넷플릭스와 인튜이트 같은 글로벌 기술기업이 데이터 메시(Data Mesh) 아키텍처를 도입했을 당시만 해도, 차세대 데이터 관리 혁신이라는 기대감이 가득했다. 분산형 데이터 거버넌스와 자율적 데이터 소유를 결합한 새로운 접근법이 기업 데이터 전략의 판도를 바꿀 것이라는 전망이 이어졌다.

데이터 메시에 대한 다양한 평가가 오가는 지금, 여전히 이 아키텍처의 도입을 고민하고 있다면, 그리고 이 기술이 과연 시간의 시험을 견딜 수 있을지 궁금하다면, 지금이 바로 그 답을 찾아볼 때다.

데이터 메시가 인기를 얻게 된 배경

시간을 조금 되돌려 보자. 데이터 메시 아키텍처가 처음 등장한 것은 2010년대 후반이었다. 당시 많은 기업이 데이터를 데이터 레이크로 옮기며 분석 중심의 워크플로우를 구축하는 데 집중하고 있었다. 데이터 레이크는 모든 데이터를 한곳에 모아 분석에 활용할 수 있는 중앙집중형 저장소로, 기업의 데이터 관리 문제를 해결할 완벽한 해법처럼 보였다. 그러나 2020년대 초반에 접어들면서 데이터 레이크 시스템의 한계가 뚜렷해졌고, 그동안 감춰져 있던 구조적 허점이 수면 위로 드러났다.

데이터 레이크가 가진 가장 큰 문제 중 하나는 시스템이 별도의 엔지니어링 팀이나 분석팀에 의해 구축·운영된다는 점이었다. 이들은 실제 데이터를 생산하는 소스팀만큼 데이터의 맥락을 깊이 이해하지 못했다. 그 결과, 동일한 데이터의 복사본이나 약간 변형된 버전이 여러 형태로 존재했고, 정확성과 완전성 문제도 잦았다. 데이터에 오류가 발생하면 여러 차례의 논의를 거쳐 결국 원본 데이터를 관리하는 소스팀으로 되돌아가 수정해야 했다. 또한 원본 테이블에 새로운 컬럼이 추가될 때마다 여러 팀의 워크플로우를 수정해야 했으며, 이 과정에서 데이터가 분석팀에 도달하기까지 시간이 지연되거나 일부 데이터가 손실되기도 했다. 이처럼 소스팀과 분석팀 사이의 구조적 간극은 프로젝트 일정의 지연과 데이터 품질 저하로 이어졌고, 많은 팀이 데이터를 중앙집중형 데이터 레이크에 맡기는 것에 점점 회의감을 갖기 시작했다.

데이터 메시 아키텍처는 이런 문제를 해결하겠다는 목표로 등장했다. 데이터 레이크와는 정반대의 접근 방식을 취한 데이터 메시의 핵심은 ‘데이터 소유권’을 현업 소스팀에 부여하는 것이었다. 각 팀이 자신이 생성한 데이터를 직접 관리하고 필요한 부서에 제공하는 구조로, 더 이상 중앙집중형 데이터 레이크를 거치지 않고 소스 시스템에서 바로 접근할 수 있도록 설계됐다. 데이터 메시의 철학은 ‘데이터 레이크가 하지 못했던 모든 것’을 가능하게 하는 데 있었다. 데이터 이전을 위한 별도의 워크플로우가 필요하지 않았고, 중복 검증 절차가 줄어들었으며, 데이터의 정확성과 일관성이 크게 향상됐다. 데이터 복제 문제도 감소했고, 데이터 오류 발생 시 수정 속도 역시 빨라졌다. 무엇보다 중요한 점은, 각 데이터셋이 그 데이터를 가장 잘 이해하는 팀에 의해 유지·관리되기 때문에 데이터 활용자가 그 품질을 훨씬 더 신뢰할 수 있게 됐다는 것이다.

데이터 메시가 신뢰를 잃은 이유

그러나 데이터 메시에 대한 기대감은 오래가지 않았다. 시간이 지나면서 많은 사용자가 실망감을 드러냈다. 겉으로는 효율적인 분산형 구조처럼 보였지만, 실제로는 데이터 제공자와 데이터 활용자 사이의 거의 모든 병목 현상이 구현 단계에서 새로운 장애물로 드러났다. 가장 큰 문제는 데이터 메시가 단순히 한 번 도입하면 끝나는 시스템이 아니라, 장기적으로 일관된 데이터 스키마를 유지해야 하는 구조라는 점이었다. 각 소스팀이 자신의 데이터셋을 소유하긴 하지만, 데이터를 복제하지 않고 후속 시스템이 데이터를 읽을 수 있도록 스키마를 지속적으로 관리해야 했다. 그러나 대부분 조직에서 관련 교육이 부족했고, 경영진 차원의 명확한 의사결정과 지원도 미흡했다. 이로 인해 잘못된 스키마 설계가 빈번하게 발생했고, 그 결과 여러 팀이 동일한 데이터에 대해 비슷한 작업을 반복 수행하게 됐다. 이런 중복은 데이터와 업무의 비효율을 초래했을 뿐 아니라, 컴퓨팅 자원 사용량 증가로 이어져 운영 비용을 높이는 또 다른 문제를 낳았다.

팀 간의 조율 부족은 또 다른 문제를 낳았다. 데이터 테이블이 불완전하거나 서로 연결되지 못하는 사례가 빈번하게 발생한 것이다. 컬럼이 누락된 분석용 테이블이나 서로 관계를 맺지 못하는 테이블은 사실상 재앙에 가까웠다. 결국 모든 팀이 출발점으로 되돌아가야 했다. 이처럼 불완전한 테이블은 데이터 레이크에서 겪었던 문제를 그대로 반복하게 만들었다. 각 팀이 소스 시스템 위에 자체적인 데이터 계층을 쌓고, 필요한 컬럼을 직접 추가하기 시작한 것이다. 그 결과, 데이터셋이 다시 여러 버전으로 복제되며 데이터 메시의 근본적인 목적이 완전히 무너졌다.

한때의 유행에 불과했을까?

데이터 메시는 단순한 유행도, 모든 데이터 문제를 해결할 차세대 만능 기술도 아니다. 그러나 많은 기업에서 데이터 메시를 올바르게 구현한다면, 데이터 관리 부담을 크게 줄이면서 동시에 데이터 품질을 향상시킬 수 있는 강력한 수단이 될 수 있다.

본질적으로 데이터 메시란 ‘데이터를 바라보는 사고방식의 전환’이다. 조직은 데이터를 하나의 ‘제품’으로 인식해야 하며, 각 소스팀이 자신들의 데이터셋을 책임지고 관리하는 문화를 정착시켜야 한다. 이 과정에서 중복 생성을 방지하고, 지속적인 관리 의지를 보여야 한다. 또한 새로운 기능을 개발할 때, 분석 데이터의 요구사항을 부차적인 요소가 아닌 ‘핵심 요건’으로 다뤄야 한다. 다시 말해, 모든 후속 시스템의 요구사항을 충족할 수 있도록 데이터 스키마를 설계하는 접근이 필요하다.

예를 들어 제조 데이터를 데이터 메시 구조로 전환한다고 가정해보자. 이 경우 구매 주문 테이블은 재무, 마케팅, 조달, 물류, 분석 등 각 부서가 필요로 하는 모든 컬럼을 포함해야 한다. 즉, 어느 팀도 이 테이블을 다시 복제하거나 별도의 변환 작업을 거치지 않고도 바로 활용할 수 있어야 한다. 이것이 데이터 메시가 지향하는 이상적인 형태다.

데이터 메시가 모든 조직에 적합한 해법은 아니다. 데이터셋 규모가 작고 관리 범위가 제한된 소규모 팀이라면, 각 소스팀마다 별도의 워크플로우를 운영하기보다는 중앙집중형 데이터 레이크를 구축하는 편이 여전히 효율적일 수 있다. 반면, 대규모 데이터를 다루며 여러 팀이 동일한 원본 데이터셋을 지속적으로 수정·활용하는 기업이라면 상황이 다르다. 이런 경우 분산형 구조가 훨씬 효과적일 수 있다. 각 소스팀이 자체적으로 완전한 데이터셋을 구축하고 이를 공유하는 편이, 모든 팀이 동일한 테이블을 복제하고 그 위에서 각각의 변환 작업을 수행하는 방식보다 훨씬 낫다. 중복된 데이터 처리 과정은 불필요한 컴퓨팅 자원 낭비로 이어질 뿐 아니라, 최종 데이터셋에 오류를 발생시키는 주요 원인이 되기 때문이다.

데이터 메시 아키텍처는 데이터 접근 과정의 복잡한 절차를 줄이고, 데이터의 정확도를 높여준다. 이를 제대로 구현한 기업들은 이미 눈에 띄는 성과를 얻고 있다. 예를 들어 한 글로벌 은행은 데이터 메시를 도입한 뒤 운영 업무에 소요되는 시간을 45% 단축하는 효과를 거뒀다. 이처럼 올바른 활용례와 명확한 목표 의식을 가진 기업이라면 데이터 메시는 분석팀이 더 적은 노력으로 고품질 데이터에 손쉽게 접근할 수 있도록 돕는 강력한 도구가 될 수 있다. 이는 단순한 기술 혁신이 아니라, 데이터 중심 조직으로 나아가기 위한 실질적인 기반이 된다.
dl-itworldkorea@foundryco.com