데이터 메시를 읽고

회사가 커지고 데이터를 보고자 하는 조직이 많아지면 중앙집중식 데이터팀에서 모든 데이터 요청을 처리하기가 힘들어지는 순간이 온다. 특히 데이터팀은 운영데이터의 소비자로서 운영데이터를 만드는데는 직접적으로 관여하지 않고, 운영데이터는 말그대로 서비스 운영에 최적화 되어있지 데이터 수집 관점에서는 최적화되어있지 않다. 조직에서는 (특히 스타트업) 기능이 날마다 빠르게 추가되기 때문에 운영데이터 또한 변경이 빠르고 자주 일어난다. 그래서 항상 확장가능성을 생각하고 데이터 파이프라인을 작업해도 항상 스키마와 변환 로직은 깨지기 일쑤이고, 매번 신기능에 대해 요청이 들어오면 신기능의 데이터 구조를 파악하느라 빠른대처가 불가능하다. 운영에서는 빠르게 실험하고 분석결과를 보고싶어하는데, 중앙 데이터팀은 매번 새로운 데이터를 파악하고 기존 파이프라인을 유지보수를 하느라 시간을 다 써버린다.

이런점을 해결하기 위해 이 책에서는 ‘데이터 메시’ 라는 데이터 플랫폼 설계 방식을 제시한다. 중앙 집중식 데이터 웨어하우스나 데이터 레이크가 아니라, 데이터를 생성하는 비즈니스 도메인 별로 데이터에 대한 책임을 갖고 데이터를 관리하는 것이 데이터 메시의 기본 개념이다. 앞서 말한 것처럼 중앙 집중식 데이터팀은 기본적으로 다른 팀과 거대한 사일로가 있다. 이를 중앙 집중팀이 아닌 도메인 팀으로 분산시켜 해당 도메인에서 발생하는 데이터와 그 데이터로 만든 데이터 프로덕트에 대한 책임과 운영을 맡기는 방법론이다.

그렇다면 각 도메인에서 어떤식으로 분석데이터의 퀄리티를 유지하고 제공 할 수 있을까? 데이터 메시에서는 모든 제공하는 분석데이터는 제품(프로덕트)으로 다뤄서 이를 해결 할 수 있다고 한다. 데이터 프로덕트라는 것은 데이터뿐 아니라 코드, 문서, 정책, 메타데이터 등 해당 프로덕트의 전반을 파악할 수 있는 표준화된 제품 형태로 데이터를 제공하는 것을 말한다. 프로덕트는 그 자체로 엔드투엔드 제품이기 때문에 빌드, 테스트, 배포, 인프라 등의 모든 특성을 구현해야하고 이를 최대한 자동화해야 운영 관리가 쉬워진다. 이렇게 완성된 데이터 프로덕트를 전체 조직에 걸친 표준과 정책을 수립하여 이를 준수하면서 플랫폼 위에서 데이터 소비자에게 제공하는 것이 데이터 메시의 기본 구조이다.

우리 조직도 마찬가지로 복잡해지는 운영 데이터 + 늘어나는 조직원들과 요청사항 + 파편화된 파이프라인에 따른 중복 작업이 극에 달할때 쯤 이 책과 데이터 메시에 대한 개념을 접하게 되었다. 일을 하며 힘들지만 어떤 것이 힘든지 명확히 알기 어려웠는데, 이 책에서 그간 우리가 겪어온 데이터팀의 고충들을 너무나 정확히 집어줘서 다 비슷한 문제를 겪는구나 알게되었고 위로 아닌 위로도 받았다.

데이터 메시를 읽으면 매우 이상향적인 이야기를 하고 있어서 당장 이걸 적용해보고 싶다! 라고 생각하다가도 여러가지 제약 때문에 멈칫 하게된다. 데이터메시에서 제안하는 것들은 도메인 팀별로 자율적으로 데이터를 관리하자! 라는 것인데, 사실 엄격한 표준과 규칙이 먼저 있어야 그 위에서 무언가 자율적인 작업을 할 수 있다. 또한 선행 조건으로 일단 도메인팀이 나뉘어 있어야 하고, 도메인팀 별로 데이터 개발자도 있어야한다. 그래서 작은 조직에서는 적용하기 어렵고, 조직 차원에서 이미 익숙한 중앙 집중팀을 구조를 갈아엎어 생소한 개념인 도메인 팀별로 데이터 개발자를 배치할지도 의문인 면이 있다. 오히려 스타트업보다는 어느정도 안정되고 충분히 인적 인프라가 갖춰진 조직에서 적용하기가 더 수월하지 않을까 싶다.

하지만 꼭 완벽하게 데이터 메시를 적용해야 하는 것만은 아니다. 각 조직의 사정에 맞춰 제일 필요한 것부터, 작은 것부터 하나씩 바꿔나가는 식으로 접근할 수 있다. 나같은 경우에는 당장 중앙 집중팀을 벗어 날 순 없어도, 데이터 프로덕트를 만드는 것은 개인이 어느정도 할 수 있기 때문에 앞으로 이 부분을 적용해서 작업을 해보려고 한다. 이 또한 당장 멋드러진 완성된 제품을 만들 순 없어도 한걸음씩 문제를 해결하다 보면 경험이 쌓이고 체계가 잡히게 되지 않을까?

한줄평 - 나와 같이 고통받고 있는 중앙 데이터팀들이 읽으면 좋을만한 책