by
May 08. 2022
데이터 댐과 데이터 레이크
feat. 데이터 웨어하우스와 데이터 마트
데이터에 관심이 조금 있는 분들이라면 데이터 웨어하우스라는 말은 어렴풋이라도 들어보셨을 것입니다. 자매품으로 데이터 마트가 있는데요, 문재인 정부에선 또 데이터 댐이라는 개념을 정책적으로 만들어서 대대적으로 지원한 바가 있습니다. 그리고 디지털 플랫폼 정부를 내세운 윤석열 새 정부에선 플랫폼 구현을 위한 데이터 레이크라는 키워드가 자주 등장합니다. 이쯤 되면 헷갈리기 시작합니다. 웨어하우스는 무엇이고 마트는 무엇이고, 댐이랑 레이크는 또 무슨 차이인가?
이들은 모두 데이터를 저장하고 관리하는 체계를 의미합니다. 그냥 '비슷한 이름들이니 비슷한 개념을 다양한 이름으로 부르는 건가?'라고 생각하실 수 있지만 그것은 아닙니다. 이들은 일단 각각 고유한 특성을 가진 시스템이며, 등장한 순서도 다른, 발전의 계보가 있는 시스템들입니다. 또한 창고(웨어하우스), 마트(우리가 아는 그 마트), 호수(레이크) 등의 누가 지었는지 모를 이름들은, 찰떡같다고 할 순 없을지라도 그 시스템의 용도나 특성이 고려되어서 명명된 비유적인 이름들입니다.
1. 데이터 웨어하우스
일단 가장 먼저 등장한 개념은 데이터 웨어하우스입니다. (각주1) 실무적으론 흔히 DW라고 불립니다. 대기업에 계신 분들이라면 본인이 직접 데이터 업무를 하지 않더라도 DW라는 말이 흔히 사용되는 것을 보셨을 겁니다. 이제는 ERP, SCM, CRM처럼 꽤나 대중적으로 사용되는 말이기도 합니다. 더 나아가서 요즘은 EDW(Enterprise Data Warehouse), RDW(Real-time Data Warehouse) 등의 파생 개념이나 솔루션 제품들이 많이 나오고 있죠.
이렇게 대중화되어 사용되고 있는 개념은, 관련 업무를 해 보신 분들은 본인의 경험을 기반으로 그 의미를 이해할 수 있지만 그 주변에서 개념을 공부하는 입장에선 더 곤욕스러울 수 있습니다. 이 사람이 말하는 데이터 웨어하우스와 저 사람이 말하는 데이터 웨어하우스가 다 다르기 때문인데요. 아까 말씀드렸듯이 기술이 무르익고 발전을 거듭하여 기존의 데이터 웨어하우스에 비해 발전된 다양한 파생 개념 및 기술들이 등장해서 기업마다 구축·운용하는 형태가 조금씩 다르기 때문입니다. 그래서 저는 데이터 웨어하우스가 등장하게 된 배경을 바탕으로 가장 고전적인 데이터 웨어하우스에 대해 설명을 하고자 합니다. 먼저 IT위키에 나오는 데이터 웨어하우스의 특징은 아래와 같습니다.
주제 중심적(Subject Oriented): 분석하고자 하는 주제를 중심으로 데이터를 구성하나, 특정 업무 기능이나 응용 프로그램에 종속되지 않는 데이터 구조를 지원
통합 구조(Integrated): 업무 기능별로 관리되는 다수의 운영 데이터를 통합하여 전사적 관점에서 중복을 최소화하고 데이터의 정합성과 물리적 통일성을 갖는 통합된 데이터 구조를 지원
시계열성(Time Variant): 오랜 기간 시계열적으로 데이터를 축적하여 과거와 현재의 차이 및 경향 분석에 용이
비휘발성(Non Volatile): 초기 데이터 적재 이후에는 데이터의 갱신·삭제 없이 검색·조회만 수행하여, 장애 발생 시 데이터의 복구, 트랜잭션과 데이터의 무결성 유지, 교착상태의 탐지·대응이 단순해짐
특징만 봐선 개념이 쉽게 이해되지 않을 겁니다. 하지만 데이터 웨어하우스가 생겨난 배경에 대해 이해하면 데이터 웨어하우스의 특징을 좀 더 수월하게 이해할 수 있습니다.
최근 들어 4차 산업혁명이라는 시대적 흐름 앞에 전 세계적으로, 그리고 전방위적으로 디지털 전환(Digiter Transformation)이 이루어지고 있고 인공지능 등 IT 미래기술에 대한 기대감도 높아지고 있습니다. 하지만 사실 그 이전 3차 산업혁명에 따른 정보화가 이루어질 때부터 큰 기업들에선 기업 내 데이터를 모아서 활용하고자 하는 움직임이 활발했습니다. (각주2) 그 당시에 화두가 되었던 데이터 관련 기술 개념들이 BI, OLAP, DW, ETL 등입니다. 하나하나 설명해드리긴 지면상 어렵지만, 서사적이면서 포괄적으로 하나씩 설명을 해보겠습니다.
여러 선도적인 기업들에선 기존엔 경영자들의 경험과 통찰력에 의존하여 의사결정을 해왔다면, 이젠 객관적인 데이터를 기반으로 한 의사결정을 내려보기로 합니다. 통계학을 기반으로 IT기술이 접목되어 데이터 과학이 탄생하는 그 시점의 이야기입니다. 그러기 위해선 기업의 다양한 영역에 있는 데이터를 모아야 합니다. 예를 들어 제조 기업인 경우 원자재 구매 데이터, 제조 공정 데이터, 고객 데이터, 유통 데이터, 마케팅 데이터 등 여러 팀·부서·본부 등의 조직에서 각자의 시스템을 운용하면서 생산되는 데이터를 한 곳에 모으는 것입니다. 데이터를 이렇게 모으는 것은 회사의 종합적인 상황을 분석하기 위한 것입니다. 원자재 구매팀에서 그들의 관점에서 분석하여 보고하는 정보와 마케팅 팀에서 그들의 관점에서 분석하여 보고하는 정보들은 아무래도 각자의 시각에서만 분석된 정보들이고, 종합적인 상황을 파악해야 하는 중역 들일수록 각자의 시각에서 개별적으로 분석된 정보에 의존하여 자신의 통찰력을 통해 인사이트를 파악하고 의사결정을 내려야 했죠. 하지만 여러 관점의 데이터를 모두 한데 모아서 분석을 할 경우 개별 보고서를 여러 개 보는 것보다 효율적으로 인사이트를 도출해낼 수 있습니다.
이렇게 여러 관점의 데이터를 일목요연하게 볼 수 있으려면 어느 정도 통일된 형태를 가져야 합니다. 데이터를 저장하고 표현하는 형식이 완전히 다를 경우 모아 놓은 의미가 없죠. 그냥 개별 보고서를 보는 것보다 불편해질 수 있습니다. 그래서 도출되는 특징이 주제 지향적(Subject Oriented)이면서 통합된 구조(Integrated)라는 것입니다. 각 업무 주제별로 데이터가 저장되어 있지만 잘 정돈된 형태로 볼 수 있게 되어 있다는 것이죠. 하지만 각자의 시스템에서 각 업무 특성에 맞게 저장되고 관리되던 데이터를 일관된 형태로 모으려면 변환이 필요합니다. 이럴 때 사용되는 것이 아까 나열했던 기술 중 하나인 ETL입니다. ETL은 각 업무시스템에 연결되어 그 업무 시스템의 데이터를 추출(Extraction)하고 고유한 데이터 형태를 데이터 웨어하우스의 일관된 형태로 변환(Tranformation)하여 데이터웨어하우스에 적재(Load)해주는 중계기 같은 역할의 시스템입니다. 이때 데이터의 구조를 바꾸거나 데이터의 값을 표준화된 값으로 변환하기도 합니다. 예를 들어 업체 코드별(ex. A20102)로 관리되고 있는 데이터가 있다고 가정했을 때 업체 코드를 단순히 업체 명(ex. A20102 -> OO물산)으로 바꿀 수도 있고, 업체 명이 중요하지 않고 업체의 소재지가 중요하다면 지역별로 집계화 할 수도 있는 거죠. 이렇게 추출하여 변환된 데이터들은 비로소 데이터 웨어하우스에 저장됩니다.
하지만 데이터는 끊임없이 업데이트됩니다. 재고량이나 원자재 가격은 시시각각 변하고 거래처로 새롭게 생겨나고 사라지고를 반복합니다. 아무리 ETL을 쓴다고 해도 이미 데이터웨어하우스에 맞게 변환되어 적재된 데이터를 업데이트하긴 쉬운 일이 아닙니다. 그리고 업데이트라는 것은 기존 값을 대체하는 것으로, 이전의 값은 소실되는 방식입니다. 현재 상황만큼이나 변화의 추이를 파악하는 게 중요한 중역의 입장에선 과거의 값을 또한 매우 중요합니다. 그래서 데이터 웨어하우스는 한번 쌓인 값을 삭제하거나 갱신하지 않습니다. 하루에 한 번, 또는 며칠에 한번 정도 ETL이 동작하는데, 과거 데이터를 업데이트하는 방식이 아닌 과거 데이터를 그대로 두고 최신 데이터를 한 벌(Set) 더 만드는 방식을 사용하는 것입니다. 가령 7월 1일 기준 데이터, 7월 2일 기준 데이터, 7월 3일 기준 데이터가 끊임없이 쌓이는 것입니다. 이렇게 데이터를 누적해서 쌓으면 용량은 많아지겠지만 변화 추이를 시계열로 분석하기엔 무척 유리합니다. 물론 앞서 설명했듯이 바뀐 값을 찾아 업데이트하는 것보다 훨씬 수월하기도 하죠. 이런 이유로 데이터 웨어하우스는 시계열성(Time Variant) 및 비휘발성(Non Volatile)의 특징을 가지는 것입니다.
이제 데이터 웨어하우스가 어떤 개념인지 이해하셨나요? 간단히 정리하면 여러 군데에 나누어 저장 및 관리되고 있는 데이터를 한 곳에 모으는데, 데이터를 계속 중복해서 쌓아나가는 방식으로 모아 분석용으로 사용하는 것이라 할 수 있습니다. 데이터 웨어하우스에 대해 이렇게 지면을 많이 할애하여 설명한 것은 뒤에서 설명할 데이터 마트, 데이터 레이크, 데이터 댐 등도 모두 데이터 웨어하우스에서 출발된 개념이기 때문입니다.
2. 데이터 마트
데이터 마트는 데이터 웨어하우스의 좀 더 경량화된 형태라고 할 수 있습니다. 전사적으로 운영되는 데이터 웨어하우스와 다르게 주로 본부별, 부서별, 또는 업무 영역별로 구성되는 소규모 데이터 웨어하우스입니다. 데이터 웨어하우스가 태생적으로 전사적인 상황 파악이 필요한 중역들을 위한 것이라면 데이터 마트는 각 부서의 관리자들을 주요 사용자로 하는 경우가 많습니다. 데이터 웨어하우스는 전사적으로 단 하나만 존재하는데 반해 데이터 마트는 업무 영역별로 여러 개가 존재할 수 있습니다.
데이터 마트가 등장하게 된 배경은 크게 두 가지입니다. 첫 번째는 데이터 웨어하우스를 구축하는 것이 어렵기 때문입니다. 데이터 웨어하우스를 구축하려면 회사의 각 업무 조직에서 사용하는 시스템들을 모두 파악해야 하고, 업무별로 전혀 다른 데이터 구조를 맞춰줘야 하는 대대적인 프로젝트가 필요합니다. 하지만 특정 업무 영역 내로 한정한다면 데이터의 구조적 차이가 적어 데이터를 모으기가 훨씬 수월해집니다. 중역들에게 보고하기 위한 데이터가 아니므로 좀 더 러프하게 운영할 수 있습니다. 데이터를 매일 추출하여 적재하는 것이 아니라 필요할 때만 추출할 수도 있고 오랫동안 저장하지 않을 수도 있습니다. 그리고 데이터가 자동으로 분석되고 시각화되어 중역들이 보기 좋은 깔끔한 보고서 형태로 출력되는 기능을 빼버리기도 합니다. 중간 관리자들이 실무적인 관점에서 보는 것이므로 좀 더 날 것(Raw) 그대로의 데이터가 보여도 되는 것이죠.
두 번째는 데이터 웨어하우스와 같이 전사적인 데이터를 모두 봐야 하는 사람은 많지 않으며, 좀 더 작은 영역에 한정되어 모아둔 데이터를 봐야 하는 사람들은 많기 때문입니다. 즉 데이터 기반 경영을 좀 더 하위 레벨로 대중화한 것이죠. 의사결정이 Top-down 중심으로 이루어지던 예전 기업문화에서 각자의 업무 영역에서의 전문성을 존중하고 Bottom-up으로 경영이 이루어지는 합리적인 기업문화일수록 중간 관리자들의 의사결정 역량이 더 중요해질 수밖에 없습니다. 그렇다고 이런 중간 관리자나 실무자들이 모두 데이터 웨어하우스에 접근하여 분석하는 것은 바람직하지 않습니다. 위에서 설명드렸듯이 데이터 웨어하우스는 중역들이 보기 편하도록 전사적인 관점에서 정형화된 형태로 가공된 데이터를 모아둔 시스템이라 각 업무 영역에선 보기 편한 구조가 아닐 수 있고, 특정 업무 영역에 있는 직원이 전사적인 데이터를 모두 열람하는 것은 보안의 측면에서도 바람직하지 않으며, 데이터 웨어하우스는 단일 시스템이라 불특정 다수가 접근해서 사용하기엔 부하 및 권한 통제 등 고려할 부분이 한두 가지가 아니기 때문입니다.
이런 이유들 때문에 데이터 웨어하우스가 있더라도 이를 쪼개든, 새롭게 구성하든 데이터 마트를 별도로 만드는 기업들도 많고, 애초에 각 조직별로 데이터 마트가 구축되고, 데이터 마트를 운영하는 조직이 많아질 경우 데이터 마트를 모아 데이터 웨어하우스를 구성하는 경우도 있습니다.
3. 데이터 레이크
데이터 레이크는 데이터 마트와는 반대로 데이터를 더 많이 모으기 위해 등장한 개념입니다. 물론 여기서 더 많이 모은다는 것은 전사적, 비전사적을 가리지 않습니다. 많은 업무영역에서 데이터를 모은다기 보단 더 다양한 종류의 데이터를 모으는 관점에서 고안된 개념이기 때문입니다.
데이터 웨어하우스는 일관된 관점으로 데이터를 볼 수 있도록 데이터를 정제한다고 말씀드렸습니다. 이렇게 구조를 맞추어 저장할 수 있는 데이터는 정형 데이터뿐입니다. 즉 사진이나 줄글(Text)로 이루어진 보고서, 음성이나 영상은 저장할 수 없습니다. 마치 잘 정리된 엑셀 파일처럼, 구조화된 데이터베이스에 저장된 데이터만 모아서 저장할 수 있는 것입니다. 데이터 분석 기술에 한계가 있던 예전만 해도 이렇게 정형 데이터를 모든 것만으로도 분석하기 벅찬 경우가 많았습니다. 하지만 정형화된 데이터들을 여유롭게 분석할 만큼 컴퓨팅 기술 및 분석 기술이 좋아진 뒤에는 분석을 고도화하기 위해 다양한 비정형 데이터를 활용하게 됩니다. 자연스럽게 비정형 데이터에서 정보를 추출하는 기술도 발전들 하게 되고, 비정형 데이터를 잘 보관하고 활용하는 것도 중요하게 됩니다. 여태 정형 데이터는 데이터 웨어하우스를 통해 시계열로 잘 저장되고 관리되어 왔지만 비정형 데이터는 체계적으로 관리되지 못해 소실되는 경우가 많았습니다.
그래서 점점 데이터를 잘 정리해서 모아야 된다는 생각보단 비록 일관된 형태를 갖추진 못할지라도 정형이든 비정형이든 가리지 않고 체계적으로 모아두면 언젠가 유익하게 활용할 수 있겠다는 생각에 이르게 됩니다. 그렇게 나온 것이 데이터 레이크입니다. 잘 정돈된 데이터뿐만 아니라 이미지, 동영상, 한글이나 엑셀, PDF 등 비정형 데이터를 모두 저장하여 관리할 수 있는 시스템을 구축하기로 한 것입니다. 실제로 아마존(Amazone) 등 해외 유수 기업들에서 사용되어 좋은 성과를 내기도 했고 국내 일부 대기업에서도 도입을 하였습니다.
데이터 마트가 쉽게 사용할 수 있도록 정제되고, 포장되었으며, 구조화된 생수병 저장고(a store of bottled water - cleaned and packaged and structured for easy consumption)라면 데이터 레이크는 더 자연 그대로 상태인 호수(a large body of water in a more natural state)이다. 호수의 여러 사용자들은 호수를 조사하거나 들어가서 샘플을 가져갈 수 있다.
하지만 데이터 레이크는 적어도 아직까진 데이터 웨어하우스에 비해 무척이나 막연한 개념입니다. 이유는 여러분도 어렴풋이 떠오르실 것입니다. 바로 '그런 다양한 데이터를 어떻게 저장해서 어떻게 활용하겠다는 것이지?'라는 의구심이죠. 실제로 데이터 레이크는 구축하여 활용하기가 데이터 웨어하우스나 데이터 마트에 비해 훨씬 까다롭습니다.
어떻게 보면 구축 자체는 쉬울지도 모릅니다. 데이터 웨어하우스는 전사의 다양한 데이터를 어떻게 잘 추출하고 정제하여 통합된 형태로 구축할 수 있을까에 대해 고민해야 한다면 데이터 레이크는 그냥 모든 데이터를 다 저장할 수 있는 스토리지를 개발해두면 되니깐요. 하지만 그냥 이렇게 스토리지에 모아두기만 하면 나중에 활용을 하려면 엄청난 정제 작업이 수반되어야 하므로 향후 활용 측면에서 고려하면 올바른 방법은 아닙니다. 애초에 저장할 때부터 체계적이고 활용이 용이하도록 저장을 해야 하겠죠. 이에 대한 방법론이 아직까지는 일반화되지 않았습니다. 데이터 웨어하우스의 한계, 데이터 레이크의 필요성은 누구나 공감하지만 그렇다고 데이터 레이크를 어떻게 만들어 운영할지에 대해선 다양한 방법론들이 적용되어 경험을 쌓고 있는 중이라고 볼 수 있습니다.
말씀드렸듯이 일부 대기업들 위주로 데이터 레이크가 구축이 되고 있지만 방향성은 모두 다릅니다. 사실 그럴 수밖에 없는 것이 데이터 웨어하우스에서 관리하는 정형 데이터는 아무리 다른 데이터라 할지라도 엑셀의 스프레드시트와 같은 반듯한 데이터들이라면 데이터 레이크에 저장되어야 하는 다양한 데이터들은 기업에 따라 형태의 차이가 극과 극을 달릴 수 있기 때문입니다. AI 스피커를 개발하는 기업에선 음성 데이터가 주가 될 것이고, OTT를 운영하는 기업에선 동영상 데이터가 주가 될 수 있습니다. 법이나 특허를 다루는 기업에선 텍스트 데이터가 많을 것이고 제조 기업에선 반정형화된 로그파일들이나 도면 이미지가 많을 수 있습니다. 이렇게 데이터 레이크는 기업에서 주로 다루는 데이터들에 맞추어 구축하고 활용해야 하기 때문에 특정 솔루션을 구매하여 그대로 이용하기 보단 체계적인 설계에 따라 고유한 시스템을 개발해내야 하죠.
데이터 웨어하우스와 데이터 레이크 비교하지만 구축이 성공적으로 이루어지고 나면 데이터 활용 측면에서의 호용성은 클 것으로 기대됩니다. 데이터 웨어하우스나 데이터 마트와는 다르게 데이터 레이크의 주된 사용자는 데이터 사이언티스트입니다. 전사적인 데이터를 통해 제약 없이 자신의 능력을 마음껏 발휘할 수 있죠. 다양한 조직에서 취합된 정형 데이터를 마음껏 사용할 수 있음은 물론이고 비정형 데이터도 필요할 때마다 같이 조합하여 분석할 수 있습니다. 비정형 데이터는 이미지나 음성, 영상 등을 자체적으로 학습시킬 수도 있지만 요즘은 정형화된 정보를 추출할 수 있는 기술도 다양하게 활용할 수 있습니다.
데이터 레이크는 데이터 사이언티스트에겐 천국이나 다름없습니다. 전사적인 전략 수립뿐만 아니라 기업 내의 각 조직에 제약 없이 다른 조직의 데이터까지 참고하여 그 조직의 목표에 맞는 데이터 분석 또한 가능합니다. 기존에 데이터 웨어하우스에서 데이터 마트가 나오게 된 방향성과는 조금 배치되는 측면이 있죠? 기존엔 데이터 웨어하우스에 아무나 접근하는 것을 지양하는 방향에서 데이터 마트가 나오기도 했었는데 이젠 데이터 활용에 따른 리스크 보단 그 호용을 더 크게 보게 되었다는 시사점이기도 합니다.
이런 이유들로 인해 데이터 레이크를 구축하여 활용하려면 데이터에 전문적인 역량을 가진 인력들이 꼭 필요합니다. 그냥 엑셀이나 SQL 수준으로 간단한 통계치만 뽑아왔거나, 사용성 좋게 잘 구현된 OLAP나 BI만 사용해왔던 기업에서 전문 인력 없이 데이터 레이크만 구축할 경우엔 힘들여 구축해놓은 보람이 없을 것입니다. 게다가 정형 비정형 막론하고 데이터를 최대한 모으고자 하는 취지를 가진 데이터 레이크인 만큼 보안과 관련하여 신경 쓸 부분도 한두 가지가 아닙니다. 자칫해서 기업의 기밀 데이터가 권한이 없는 직원에게 보여지면 안 될 것이고, 누가 어떤 데이터에 접근했는지 기록·관리 또한 철저히 해야 합니다. 큰 구축 비용과 운영비용을 감내하고서라도 큰 효과를 내기 위해선 그만큼 잘 기획하여 잘 만들고 잘 활용할 수 있는 전문 인력이 필수적입니다.
4. 데이터 댐
데이터 댐은 문재인 정부 때 과학기술정보통신으로 추진되었던 데이터 구축사업, 또는 그 사업에 따라 구축된 데이터들을 의미하는 말입니다. 즉 데이터 댐은 앞서 소개한 데이터 웨어하우스, 데이터 마트, 데이터 레이크와 다르게 전 세계적으로 통용되는 용어가 아니라 우리나라 정부에서 만들어낸 용어입니다. 지난 정부의 사업임에도 가장 마지막에 소개하는 이유는 시기적으로 가장 늦게 등장한 개념이며, 데이터 레이크의 영향을 받아 명명한 것으로 추정되기 때문입니다. 그리고 문재인 정부는 데이터 댐을 추진했던 반면 윤석열 정부는 데이터 레이크를 내세우고 있어서 그 정책적 차이에 대해도 비교해보려고 합니다.
먼저 데이터 댐은 한국형 디지털 뉴딜의 일환으로 추진된 프로젝트입니다. 한국형 디지털 뉴딜이란 미국 대공황 시기 미국의 루즈벨트 대통령이 실업자들에게 일자리를 부여하고 경제 기반을 마련하기 위해 추진한 뉴일(New Deal) 정책을 참고한 프로젝트입니다. 코로나 시기로 어려운 경제 상황을 타개하기 위해 4차 산업혁명에 맞는 디지털 분야에 관련된 다양한 기반 사업을 추진함으로써 디지털 분야의 새로운 사업자들이 등장하고 일자리가 늘어나도록 하는 것입니다. 예를 들어 정부에서 R&D 비용을 지원하고, 정부에서 데이터를 공급하고, 데이터 활용에 필요한 비용을 지원함으로써, 데이터를 활용하는 새로운 기업, 또는 기존 기업의 새로운 사업 영역이 생겨나도록 함으로써 자연스럽게 일자리와 부가가치 또한 발생되게 하는 것이죠. 이러한 큰 맥락 아래서, 정부가 각종 공공 데이터나, 인공지능 학습 등 다양한 분야에 필요한 가치 있는 데이터를 공급한 프로젝트를 데이터 댐이라고 합니다.
'댐'이라는 표현을 사용한 것은 여러 가지가 이유가 있어 보입니다. 첫째로 미국의 뉴딜 정책에서 주요하게 추진되었던 프로젝트 하나가 댐 건설 (각주3) 이었습니다. 국내에서도 한국형 '뉴딜'을 표방하고 있었으므로 그런 상징성도 있었을 테고, 또 하나는 댐이라는 것이 물을 모아놨다가 필요한 적시에 물을 공급해주는 역할도 있다 보니 데이터 공급에 대한 의미도 내포하였을 것입니다. 마지막으로 제 주관적인 생각입니다만, 기존에 산업계에서 트렌디하게 언급되던 데이터 레이크와의 유사성을 들 수 있겠습니다. 데이터 레이크는 위에서 설명드렸듯이 정형, 비정형을 가리지 않고 다양한 데이터를 포용합니다. 데이터 댐 또한 특허, 법률, 이미지, 음성, 영상, 말뭉치 등 정말 다양한 포맷의 데이터를 공급하는 프로젝트였습니다. 또한 데이터 레이크가 마치 자연적으로 형성되는 호스처럼 날것 그대로의 데이터가 그대로 흘러들어 가 보관되는 형태를 비유적으로 표현한 것이라면 댐은 정부가 인공적으로 데이터셋을 구축해서 공급한다는 측면에서도 비유적인 의미가 있을 것입니다.
5. 데이터 댐과 데이터 레이크
문재인 정부와 달리 윤석열 정부에서는 정부 주도로 구축하는 데이터 레이크를 강조하고 있습니다. 정부가 각종 정부 기관, 지자체, 공공기관 등에서 추출해낼 수 있는 여러 종류의 공공 데이터를 네거티브 원칙 하에 전면 개방하여 한 곳에 모아서 제공하는 시스템을 구축하겠다는 것입니다. (각주4) 문재인 정부의 데이터 댐과는 어떤 차이가 있을까요?
먼저 공공 데이터를 활용하고, 정부 주도로 데이터 공급이 이루어진다는 측면에선 공통점이 있습니다. 공공 데이터란 다른 장에서 따로 다루겠지만, 짧게 설명하면 국가나 지자체 등이 고유한 업무를 하기 위해 세금을 들여서 생산한 데이터들을 국민들에게 돌려주는 것입니다.「공공데이터법」이라는 개방 의무화 법률까지 이미 제정되어 있고 데이터는 공공데이터포털(data.go.kr)을 통해 개방되고 있습니다.
아무리 여러 기업들이 좋은 데이터를 많이 가지고 있다고 해도 기업은 이런 데이터를 아무나 사용할 수 있도록 개방하지 않습니다. 데이터는 기업의 자산이자 영업 기반입니다. 즉 데이터를 이미 확보한 기업들이 항상 우위에 설 수 있는 것입니다. 하지만 웬만한 대기업들 수십 개를 합친 것보다 더 큰 정부라는 조직에서 생산되는 데이터를 최대한 개방하게 되면 기존에 데이터를 만들거나 구매하기 어려웠던 중소기업들까지 이런 데이터를 통해 데이터 분석에 관한 연구도 할 수 있고, 데이터를 활용한 서비스들을 개발할 수 있게 되는 겁니다.
이런 상황에서 데이터 댐은 정부에서 자연스럽게 발생되는 데이터뿐만 아니라, 실제로 민간에서 필요로 하는 데이터, 즉 자금력이 충분한 대기업들이 자신들의 사업 역량 강화를 위해서 돈 주고 만들어 내거나 외부에서 비싸게 사 오는 그런 데이터들을 정부가 만들어서 공급한다는 계획 하에 이루어진 프로젝트라고 보시면 됩니다. 공공 데이터 + 알파(α)라고 보시면 됩니다. 데이터 댐은 확실히 민간에게 데이터를 공급하는 것을 주목적으로 한 프로젝트입니다.
반면 데이터 레이크는 + 알파(α) 보단 공공 데이터 그 자체에 더 방점을 두고 있습니다. 네거티브 방식이니, 정부 데이터 전면 개방이니 그런 정책들은 기존에도 10년 간 이루어졌던 정책의 연장선에 있는 내용입니다. 다만 디지털 플랫폼 정부와 데이터 레이크가 의미가 있는 것은 데이터의 활용 측면이 강조가 되고 있는 것입니다. 기존의 공공데이터포털은 단순히 국민들, 산업계에서 정부의 데이터를 필요하면 가져다 쓸 수 있도록 카탈로그화 하여 제공하는 시스템이었습니다. 하지만 디지털 플랫폼 정부의 기반이 되는 데이터 레이크는 공공 데이터를 모두 한 시스템에 두고 융합해서 활용하겠다는 것입니다. 마치 기업에서 여러 업무 조직에서 발생하는 데이터를 데이터 레이크에 넣고 각 조직이나, 전사적인 데이터 사이언티스트들이 분석을 하도록 하듯이, 정부도 공공 분야가 가진 데이터를 죄다 모아놓고 마치 정부 전체가 하나의 큰 기업인양 데이터를 통합하여 활용하겠다는 것이죠.
디지털 플랫폼 정부 개념도(인수위 발표 자료 발췌)