[아이티데일리] 전 세계 데이터 산업계가 새로운 변화를 맞이하고 있다. 대부분의 기업들은 데이터 웨어하우스(DW, Data Warehouse)와 데이터 레이크(Data Lake)를 이용해 자사의 데이터들을 관리해왔지만, 서로 반대되는 장점과 단점을 보유한 두 가지 기술들을 유지하면서 관리가 복잡해지고 비용이 증가하는 문제를 겪고 있다. 이에 데이터 웨어하우스와 데이터 레이크의 장점을 결합한 데이터 레이크하우스(Data Lakehouse)가 새롭게 부각되고 있다.

전 세계 데이터 산업계가 새로운 변화를 맞이하고 있다. 대부분의 기업들은 데이터 웨어하우스(DW, Data Warehouse)와 데이터 레이크(Data Lake)를 이용해 자사의 데이터들을 관리해왔지만, 서로 반대되는 장점과 단점을 보유한 두 가지 기술들을 유지하면서 관리가 복잡해지고 비용이 증가하는 문제를 겪고 있다. 이에 데이터 웨어하우스와 데이터 레이크의 장점을 결합한 데이터 레이크하우스(Data Lakehouse)가 새롭게 부각되고 있다.

데이터 기술의 양대산맥, 데이터 웨어하우스&레이크

데이터 웨어하우스 기술은 오랫동안 기업의 BI(Business Intelligence) 프로세스에서 핵심적인 부분을 담당했다. 개별 시스템에 종속된 데이터베이스(DB, Database)와 달리 사용자의 목적에 따라 다양한 데이터들을 통합하고 정제해 활용하기 쉽게 만들 수 있기 때문이다. 여러 장소에 흩어져 있는 데이터를 목적에 맞게 찾고 모아서 하나로 통합하는 것은 상당한 공수가 들어가는 일이기 때문에, 전통적인 BI 프로세스는 데이터 웨어하우스를 구축하는 데에 80% 이상의 시간을 소요하기도 했다. 그럼에도 불구하고 잘 만든 데이터 웨어하우스는 그 당시 선택할 수 있는 가장 효과적인 데이터 관리 방법론이었다.

하지만 2000년대 후반에 들어서면서 데이터 웨어하우스로는 대응할 수 없는 문제들이 일어나기 시작했다. 가장 큰 문제는 기업이 수집하는 데이터의 양과 종류가 빠르게 증가하고 있다는 점이었다. 더군다나 이렇게 모아둔 데이터가 모두 유용한 가치를 가지고 있다고 보기도 어려웠다. 구축하는 데에 많은 공수를 필요로 하는 데이터 웨어하우스로는 빠르게 증가하는 데이터에 대응할 수 없고, 기껏 구축해놨더니 무가치한 데이터로 판명될 위험이 있었다.

그래서 기업들은 데이터의 종류를 가리지 않고 원시 데이터(raw data) 그대로 저장하는 데이터 레이크를 구축하기 시작했다. 저장하는 과정에서 별다른 처리를 하지 않기 때문에 빠르게 증가하는 데이터들을 신속하게 담아둘 수 있었다. 또한 데이터 레이크의 특징 중 하나인 데이터를 저장할 때는 스키마를 정의하지 않고(schemaless) 우선 모아두었다가, 해당 데이터가 필요해서 읽어올 때 스미카를 정의하는 것(schema on read) 역시 쓸모있는 데이터에만 공수가 들어간다는 점에서 매우 효과적이었다.

지난 10년 간 데이터에 대한 기업들의 본질적인 요구는 크게 변하지 않았다. 다양한 데이터를 통합해 분석하면서 유용한 인사이트를 찾아내고, 한편으로는 생성되는 속도가 점점 더 빨라지고 있는 방대한 데이터들을 잘 모아두는 것이다. 따라서 대다수 기업들은 목적에 맞게 구축한 여러 개의 데이터 웨어하우스와 모든 데이터를 날것 그대로 모아두는 데이터 레이크라는 두 가지 체계를 동시에 운영하고 있다. 그러나 이렇게 두 개 계층으로 이뤄진 아키텍처는 사용자들을 충분히 만족시키기 어려웠다.

복잡하고 관리 어려운 이중 데이터 아키텍처

먼저 문제가 터져나오기 시작한 것은 데이터 레이크 쪽이다. 데이터 레이크는 폭발적으로 늘어나는 데이터들을 빠르게 수집하는 데에는 유리하지만, 원천 데이터를 그대로 저장해둔 것이다보니 이를 활용하는 데에는 더 많은 역량을 필요로 한다.

데이터 레이크에 들어있는 데이터는 기초적인 손질도 되지 않은 날것 그대로의 식재료다. 원하는 조리법대로 만들기는 좋겠지만, 식재료를 다루는 과정에서 더 많은 기술과 시간이 필요하다. 심지어 분류조차 되지 않은 채 뭉텅이로 뒤섞여있다면 원하는 데이터를 찾는 데에만 한세월이 소요된다. 만약 사용자가 원천 데이터를 다룰 수 있을 정도의 역량을 보유하지 못했다면, 혹은 원천 데이터를 목적에 맞게 가공하는 데에 너무 많은 시간이 소요된다면 데이터 레이크는 잘못된 선택이다. 이 경우 데이터 레이크는 그저 데이터들을 모아놓기만 했을 뿐인 쓰레기장, 데이터 늪(swamp)으로 불리기도 한다.

한편 데이터 웨어하우스는 꺼내서 사용하기에는 편하지만 저장할 때는 많은 공수가 들어간다. 데이터 웨어하우스에 들어있는 데이터는 일종의 밀키트 제품과 같아서, 포장지를 뜯고 정해진 조리법에 따라 굽거나 끓이기만 누구나 손쉽게 맛있는 요리를 만들 수 있다. 대신 밀키트를 만드는 과정에 시간이 많이 걸리기 때문에 실시간으로 생성되는 데이터들을 활용할 수 없고, 정형 데이터에 최적화돼있어서 최신 트렌드인 머신러닝 등이 요구하는 비정형 데이터 처리 등에도 적합하지 않았다.

대량의 데이터를 보관하기에는 비용효율적이지도 않다. 데이터 웨어하우스를 만드는 데에 많은 시간과 예산을 투자했더라도, 가성비를 높이기 위해 여러 가지 용도로 돌려쓰기도 어렵다. 일반적으로 데이터 웨어하우스는 설계하는 과정에서 필요한 데이터만을 선택적으로 통합하기 때문에 처음에 의도한 것 이상의 가치를 얻어내기 어렵기 때문이다. 이미 밀키트로 가공이 끝나 있으니 색다른 조리법을 적용하기 어렵다는 뜻이다. 그래서 기업들은 새로운 분석 요구가 발생할 때마다 그에 맞는 새로운 데이터 웨어하우스를 구축해 사용하는 경우가 많고, 늘어나기만 하는 데이터 웨어하우스의 숫자는 기업의 데이터 아키텍처의 복잡성을 크게 높이고 운영 비용을 높이는 이유가 된다.

두 개 계층으로 분리된 데이터 아키텍처는 관리자 입장에서도 많은 어려움을 야기한다. 대개 데이터 레이크에서 원하는 데이터를 찾아 이를 데이터 웨어하우스 등으로 복제해 사용하는데, 이 과정에서 적지 않은 비용이 들고 같은 데이터를 이중으로 저장하게 되면서 관리 포인트가 복잡해지는 문제를 야기한다. 한 번 구축한 데이터 웨어하우스를 쓸모없게 만들지 않으려면 지속적으로 새로운 데이터를 업데이트 해야 하니, 비용과 관리 문제 역시 지속적으로 발생한다.

양자의 장점 결합한 데이터 레이크하우스

그렇다면 데이터 웨어하우스와 데이터 레이크 각각이 가진 문제를 해결할 수 있는 방법은 없을까? 이러한 관점에서 데이터 레이크하우스(Data Lakehouse)가 탄생했다.

데이터 레이크하우스 아키텍처는 데이터 레이크 계층 위에 데이터 웨어하우스 역할을 하는 계층을 통합하는 것이다. 가장 쉽게 생각할 수 있는, 양자를 통합해 장점은 부각시키고 단점은 가리는 방법이다. 데이터 레이크하우스는 데이터 웨어하우스가 가진 고품질의 데이터 관리와 구조화 기능을 구현하지만, 이를 별도의 값비싼 데이터 웨어하우스 스토리지가 아닌 데이터 레이크의 유연하고 저렴한 스토리지 비용 위에서 실현한다는 점이 차별점이다.

데이터 레이크하우스는 기존에 운영하고 있던 아마존웹서비스(AWS), 마이크로소프트 애저, 구글 클라우드 등에 구축된 데이터 레이크 계층 위에 새로운 레이크하우스 계층으로 올려진다. 데이터는 여전히 데이터 레이크에 저장되기 때문에 저장 과정에서의 용이함이나 저렴한 스토리지 비용 등의 장점을 그대로 유지할 수 있다. 다른 저장소로 데이터를 복제하지 않더라도 데이터 레이크에 있는 원천 데이터를 직접 BI 도구들과 연결할 수 있어, 데이터 웨어하우스의 단점이었던 데이터의 중복 저장이나 최신화가 어렵다는 문제도 해결한다.

여기에 데이터 웨어하우스가 지원하는 장점, 즉 데이터의 정합성과 일관성이 유지되고 있음을 보장하는 ACID(Atomic, Isolated, Consistent, Durable) 트랜잭션에 대한 지원이나, 스타(star) 스키마나 스노우플레이크(snowflake) 스키마와 같은 주요 스키마들에 대한 지원이 가능하다. 심지어 정형 데이터에만 적용되던 ACID 트랜잭션이나 별도의 제품으로 구현되던 데이터 계보관리 기능을 비정형 데이터에도 모두 적용할 수 있게 된다. 데이터 레이크에 파일 수준으로 저장되던 비정형 데이터들을 아파치 아이스버그(Apache Iceberg)나 델타레이크(Delta lake) 등을 이용해 논리적 테이블 수준으로 변환해 관리하기 때문이다. 따라서 비정형 데이터를 활용한 머신러닝 프로젝트들을 손쉽게 수행할 수 있다.

이는 데이터 레이크하우스가 개방형 아키텍처를 중요시하기 때문에 가능하다. 예를 들어 오늘날 많은 빅데이터 프로젝트에서는 컬럼 기반 개방형 데이터 포맷인 파케이(Apache Parquet)를 사용하고 있는데, 특정 언어에 종속되지 않고 대부분의 분산형 쿼리 엔진이나 ETL 도구들이 파케이 포맷을 지원하기 때문에 손쉽게 데이터를 내보내고 공유할 수 있다. 데이터 레이크하우스는 데이터 포맷이나 API 등에서 오픈소스 기반의 개방형 아키텍처로 구축된다. 따라서 상대적으로 단일 기업에 친화적이고 일견 폐쇄적으로 구성되는 데이터 웨어하우스에 비해 보다 다양한 기능들을 효과적으로 사용하고 있다.

시장 양분하는 스노우플레이크와 데이터브릭스

현재 전 세계 시장에서 데이터 레이크하우스라는 용어를 가장 강하게 주장하고 있는 것은 데이터브릭스다. 데이터브릭스는 하둡(Hadoop)을 위시한 오픈소스 빅데이터 플랫폼 생태계에서 빼놓을 수 없는 아파치 스파크(Apache Spark)의 창시자가 창업한 기업이다. 미국 실리콘밸리에서 시작해 데이터 레이크하우스 플랫폼으로 세계 7,000개 이상의 고객을 보유하고 있다. 지난 4월에는 한국 지사를 설립하며 본격적인 국내 시장 공략을 선언했다.

데이터브릭스와 함께 데이터 레이크하우스 시장의 또 다른 대표 주자는 스노우플레이크다. 오라클 출신의 데이터 전문가들이 모여 공동 창업했으며, 지난 2020년 미국 뉴욕증권거래소(NYSE)에 상장하는 과정에서 워렌 버핏이 공모주 투자에 나서면서 빠르게 유명세를 얻었다. 지난해 11월 국내 지사를 설립해 활발히 시장 공략을 추진하고 있다.

데이터브릭스와 스노우플레이크는 데이터 웨어하우스와 데이터 레이크의 장점을 결합한다는 점에서는 공통점을 가지고 있지만, 서비스 방식에 대해서는 다소 차이가 있다. 데이터브릭스는 데이터 레이크하우스라는 용어를 강하게 미는 만큼 전형적인 형식의 데이터 레이크하우스다. AWS나 애저, 구글 클라우드 상에 구축된 데이터 레이크 위에 아파치 스파크를 기반으로 작동하는 자사의 데이터 레이크하우스 플랫폼을 결합한다.

반면 스노우플레이크는 SQL을 중심으로 하는 클라우드 데이터 웨어하우스에서 시작했다. 데이터 웨어하우스 기업이니만큼 기존에 구축된 데이터 레이크에 데이터 레이크하우스를 추가하는 것이 아니라, 클라우드 상에서 운영하던 다양한 웨어하우스들을 단일한 플랫폼으로 통합하고 연결하는 방법을 제시한다. 데이터 레이크를 기반으로 하는 방법과는 다소 차이가 있지만, 기업 내 모든 데이터에 접근 가능하면서 데이터 웨어하우스의 강력한 기능들을 활용할 수 있다는 장점은 동일하게 갖추고 있다. 이에 맞춰 스노우플레이크는 데이터 레이크하우스라는 용어보다는 데이터 클라우드(Data Cloud), 데이터 메시(Data Mesh)라는 용어를 강조하고 있다.

양사의 시작점에 차이가 있는 만큼 세부적인 기능에도 다소 차이가 있다. 한 업계 전문가는 “스노우플레이크는 데이터 레이크를 간접적으로 컨트롤할 수 있지만 근간은 데이터 웨어하우스 플랫폼이고, 고유의 스키마에 대한 이해가 필요한 것 같다. 반면 데이터브릭스 플랫폼은 스파크 기반이라서 기존에 하둡을 사용한 빅데이터 플랫폼을 운영한 인력이 있다면 편하겠지만, 그렇지 않다면 다소 까다로울 수 있다”고 조언했다.