(midjourney 로 만든 어떤 DDP의 이미지. (몇 가지 추가한 단어들은 공개하지 않는다))
(1부에서 계속…)
이렇게 등장한 DDP(Data Discovery platform)란 과연 무엇일까? 뚜렷하게 공식적으로 정의가 되어 있지는 않지만, DDP로 나와있는 제품들의 제품 소개를 보면 대략 ‘기업의 다양한 데이터에 대해 설명을 기록하고, 필요한 데이터가 어디 있는지 빠르게 검색하고, 각 데이터의 출처와 용례를 이해하는 데에 도움을 줄 수 있는 플랫폼’ 정도로 이해할 수 있다.
현재 많은 회사에서는 자체적으로 DDP를 만들어서 사용하고, 일부는 오픈소스로 공개를 해두기도 했다. 대표적인 사례로는 LinkedIn에서 만든 Amundsen, Lyft에서 공개한 DataHub, WeWork의 Marquez, Hortonworks의 Atlas, Facebook의 Nemo 등이 있다. 대부분의 DDP는 최근 5년 이내에 공개되었으며, 전반적으로는 데이터 정보 검색 및 데이터 스키마 확인 기능을 기본으로 제공하고, 데이터 계보 기능 역시 많은 DDP에서 지원하고 있다. 그 외에도 각각의 DDP에서는 각각에 필요한 기능을 제공하고 있다. 자체적으로 만든 것을 공개한 경우가 많은 만큼, 아마도 각자 기업에서 필요한 이유가 있었을 것이다.
하지만 전반적으로, 이런 시스템까지 필요할 이유가 있을까? ERD(Entity-Relation Diagram)과 스키마 문서만으로 부족했을까? 물론 예전에도 이런 명세서가 시스템화 되어 있었으면 더 좋았을 지도 모른다. 하지만 단순히 기술이 발전해서 이런 시스템이 나온 것은 아닐 것이다. 모든 회사들은 바쁘고 인력이 부족한데, 굳이 이런 시스템을 만든 데는 다 이유가 있을 것이다.
우선, 과거에 비해서 데이터가 늘어났고, 기억해야 할 것이 많아졌다. 이는 ‘빅데이터’라는 말로 요약하도록 하자. 데이터의 양 뿐만 아니라 종류도 늘어났고, 데이터 업데이트 주기라든가, 데이터 변경사항 등 하나의 데이터에 대해서도 기록해야 할 것이 늘었다. 그리고 서비스가 발전해 가면서, 데이터의 기록 내용도 일부 변화하기도 한다. 코드값이 추가된다거나, 컬럼이 언제부터 추가되었다든가. 이에 대한 변경내역 기록도 필요하다. 메타 데이터를 계보화해서 기록하는 것은 이미 2014년 즈음부터 언급되기 시작했고, 그 중요성은 계속, 다들 알고 있으나, 이를 본격적으로 시도를 해서 무언가가 나오지는 않았다. 그러다 이제 데이터 탐색 관련 플랫폼이 나오면서, 자연스럽게 여기에 같이 도입된 것이 아닌가 싶다.
또한, 데이터의 사용자가 다변화되었다. 예전에는 데이터를 사용하는 사람이 개발자 정도로 한정되어 있었다. 하지만 오늘날은 제품과 직접 관련된 개발자 외에도 간접적으로 연관된 마케팅이나 경영진에서도 데이터에 직접 접근하기를 원하는 경우가 다반사다. 그리고 데이터에 접근하려는 각각의 사람들은 목적도, 보고자 하는 데이터도, 데이터를 사용하고자 하는 방안도 모두 다르다. 하지만 이 중 데이터를 오래 사용해 보았거나 데이터에 능한 사람은 흔치 않고, 기업의 데이터에 대해 모두 알고 있는 사람은 더 적다.
이 와중에, 데이터가 많아지고 종류도 다양해지면서, 데이터에 대해서 한 두 사람이 모두 알고 있는 경우보다, 일부의 데이터를 아는 사람이 여기저기 산재해 있는 경우가 대다수다. 그리고 오늘날에는 데이터를 한꺼번에 여러가지를 봐야 하는 경우도 많아서, 이럴 때마다 A 데이터는 가에게, B 데이터는 나에게 물어보러 다니는 것도 일이다. 그래서 데이터에 대한 내역을 하나로 모아서 정리하고, 어느 정도의 용례를 붙여두는 것이 필요하다.
이와 같은 내용들을 모두 문서로 만드는 것은 너무 어려운 일이다. 일단 문서의 양이 많고, 이를 파일로 관리하고 모든 사람이 이 파일을 공유하는 것에는 한계가 있다. 또한 앞서 말한 것처럼 서비스는 점점 빠르게 변하고, 이에 따른 데이터는 계속 변하고, 이를 매번 문서로 정리해서 배포하는 것 역시 일이다. 누군가는 데이터명세_ver_1, 다른 사람은 데이터명세_ver_2, 또 다른 사람은 데이터명세_최종, 누군가는 데이터명세_최종_final_2… 를 쓰게 되는 일도 허다할 것이다. 결국 이를 최소한 인트라넷에 공유하거나, 누구나 접근해서 데이터를 탐색할 수 있게 하는 중앙집중형 게시판 이상이 필요할 것이다. 실제로 웹서비스 데이터 명세서를 사용하는 경우도 여럿 보기도 했다. 여기에 좀 더 고도화된 검색과 어느 정도의 스키마 자동 연동 서비스를 붙인다면, 이 역시도 일종의 DDP가 될 것이다.
이런 DDP가 있으면, 사람들이 좀 더 쉽게 데이터를 사용할 수 있을 것이다. 데이터를 못 찾아서 헤메던 사람들에게 단비가 되어 줄 것이고, 데이터가 있다는 것은 대충 알고 있지만 이게 어떻게 연결되어 있고, 어떻게 사용해야 하는 지 고민하던 사람들에게 우물이 되어 줄 것이다. 사람들이 보다 원하는 데이터를 빨리 찾을 수 있고, 데이터의 중간에 변경이 있었다든가, 서비스 변경으로 데이터가 달라졌다든가 하는 데이터의 여러 함정들도 쉽게 건널 수 있을 것이다. 함부로 데이터에 걸려 넘어지지 않고, 보다 원활하고 빠르게 데이터를 익히고 사용할 것이고, 이는 곧 문화가 되어 기업에 널리널리 퍼질 것이다.
하지만 이런 말은 모두 부질없다. 이런 마음을 가지고 DDP를 거창하게 도입한 회사들 중, 지금까지 잘 쓰고 있는 곳은 얼마나 될까. 문서나, 웹서비스 명세서보다 얼마나 더 큰 도움이 되었을까. 시작은 창대했으나 끝은 미미한 기업들도 분명 여러 군데일 것이다.
이는 그다지 새로운 사실은 아니다. 아니, 어쩌면 이제 시니컬해진 많은 사람들은 ‘뭐, 그럴 줄 알았다’ 라고 쓴웃음을 지으며 말할런지도 모른다. 하지만 이는, 대부분 사람들이 아는 것처럼, 그다지 좋은 자세는 아니다. 근본적인 원인을 이해하기 위해서 노력해야 한다.
DDP는 사실 화두에 떠오른 지는 좀 되었고, 이제는 사실 어느 정도 정점을 찍었다가 내려오는 중이다. 늘 그렇듯이 대부분의 데이터와 관련된 것은 급할 때는 신나게 추종하면서 이걸로 뭘 하면 뭐라도 해결될 것처럼 굴지만 금방 잊어버리기 마련이다. 이제 데이터는 어느 정도 기업에서 사용하는 것이 정착이 되었을 것 같지만 늘 그렇다. 그리고 DDP의 경우, 이제는 Data Discovery and Management Solution/Platform/Software 로 한 단계 업그레이드되어 DDM이라고 불리는 경우가 더 많다. 하지만 이 역시도 기존의 DDP와 크게 다르지 않고, 사람들이 좋아하는 가트너 2022년 Hype graph for data management 를 보면, 여기서도 역시 살짝 하강세에 들어선 모습을 볼 수 있다.
행복한 집의 모습은 같고, 불행한 집은 각각 이유가 다르다지만, 그 이유를 크게 보면 아마도 몇 가지로 추릴 수 있을 지도 모른다. 데이터 관리의 경우는 특히 그렇다.
우선 DDP의 정의를 다시 한 번 살펴보자. ‘기업의 다양한 데이터에 대해 설명을 기록하고, 필요한 데이터가 어디 있는지 빠르게 검색하고, 각 데이터의 출처와 용례를 이해하는 데에 도움을 줄 수 있는 플랫폼’. 이는 마치 건강보조식품같다. ‘~에 도움을 줌’이라는 식약처발 1등급 기능성 원료가 아닌 2등급 기능성 원료라는 이야기다. ‘다이어트에 도움을 줌’이라는 알약을 먹는다고 바로 살이 빠지지는 않는다. 이는 그저 ‘보조식품’일 뿐이다. 안타깝게도, DDP도 결국 마찬가지일 지 모른다. 하지만-
(3부에서 계속…)