데이터 레이크 (Data Lake)

#개념

데이터 레이크(Data Lake)는 조직에서 발생하는 모든 형태의 데이터를 사전 가공 없이 원본(raw) 그대로 대규모로 저장하는 중앙 저장소다. 관계형 데이터베이스의 테이블 같은 정형 데이터뿐 아니라 JSON·로그 같은 반정형 데이터, 이미지·음성·문서 같은 비정형 데이터를 하나의 저장소에 담을 수 있으며, 저장 시점에는 용도를 확정하지 않는다. 이 용어는 2010년 제임스 딕슨(James Dixon)이 병에 담아 판매하는 정제된 물(데이터 마트)에 대비하여 자연 상태의 물이 흘러드는 호수에 비유하면서 널리 알려졌다. 데이터 레이크의 핵심 철학은 먼저 저장하고 나중에 활용 방법을 결정한다는 것으로, 저장 비용이 극적으로 낮아지고 머신러닝처럼 원본 데이터 자체를 필요로 하는 워크로드가 늘어나면서 기업 데이터 아키텍처의 중심으로 자리 잡았다.

스키마 온 리드

데이터 레이크를 데이터 웨어하우스(Data Warehouse)와 구분 짓는 가장 근본적인 차이는 스키마를 적용하는 시점이다. 웨어하우스는 데이터를 적재하기 전에 테이블 구조를 정의하고 이에 맞게 변환하는 스키마 온 라이트(schema-on-write) 방식을 따르므로, 적재된 데이터는 일관성이 보장되지만 새로운 원천이나 형식을 수용하려면 사전 모델링이 필요하다. 반면 데이터 레이크는 데이터를 있는 그대로 저장한 뒤 읽는 시점에 용도에 맞는 구조를 해석하는 스키마 온 리드(schema-on-read) 방식을 취한다. 같은 원본 로그를 분석가는 세션 단위 테이블로, 데이터 과학자는 이벤트 시퀀스로 각기 다르게 해석할 수 있어 유연성이 높고 수집 속도가 빠르다. 그러나 구조 해석의 책임이 소비자에게 넘어가므로, 데이터의 의미와 형식이 문서화되지 않으면 활용 자체가 어려워지는 대가가 따른다.

오브젝트 스토리지 기반 구조

초기 데이터 레이크는 하둡 분산 파일 시스템(Hadoop Distributed File System, HDFS) 위에 구축되었으나, 오늘날에는 Amazon S3, Azure Data Lake Storage, Google Cloud Storage 같은 클라우드 오브젝트 스토리지(object storage)가 사실상의 표준이다. 오브젝트 스토리지는 저장 용량이 사실상 무제한이고 용량당 비용이 매우 낮으며 높은 내구성을 제공한다. 무엇보다 저장과 연산이 분리되어 Spark, Trino, Presto, Flink 등 여러 처리 엔진이 동일한 데이터를 동시에 읽을 수 있고, 각 엔진을 독립적으로 확장하거나 종료할 수 있다. 데이터는 일반적으로 Apache Parquet이나 ORC 같은 열 지향(columnar) 개방형 파일 형식으로 저장되어 압축률과 분석 쿼리 성능을 높이며, 날짜·지역 같은 기준으로 디렉터리를 나누는 파티셔닝(partitioning)을 통해 쿼리가 필요한 파일만 읽도록 한다. 다만 오브젝트 스토리지는 파일 단위의 추가·삭제만 지원하고 원자적인 다중 파일 갱신이나 트랜잭션을 제공하지 않으므로, 쓰기 도중 읽기가 발생하면 불완전한 결과를 볼 수 있고 작은 파일이 대량으로 쌓이면 성능이 급격히 저하되는 문제가 있다.

데이터 스웜프 문제

스키마 온 리드의 유연성은 관리가 뒷받침되지 않으면 곧바로 약점이 된다. 어떤 데이터가 어디에 있는지, 누가 언제 만들었는지, 어떤 의미인지, 신뢰할 수 있는지를 알 수 없는 상태로 데이터가 쌓이면 데이터 레이크는 아무도 사용할 수 없는 데이터 스웜프(data swamp, 데이터 늪)로 전락한다. 스웜프는 메타데이터 관리 부재, 소유권과 품질 기준의 미정의, 접근 통제 없는 무분별한 적재, 중복 데이터 방치가 누적된 결과다. 이를 막기 위해서는 저장 자체보다 거버넌스와 카탈로그가 먼저 설계되어야 하며, 저장 영역을 정제 수준에 따라 구분하고 각 영역의 진입 조건을 명확히 하는 것이 필요하다.

데이터 웨어하우스와의 차이

데이터 웨어하우스는 정제되고 모델링된 정형 데이터를 저장하여 SQL 기반의 비즈니스 분석과 보고에 최적화된 시스템이다. 스키마 온 라이트, ACID 트랜잭션, 인덱스와 통계 기반의 쿼리 최적화, 세밀한 접근 제어를 갖추어 신뢰성과 성능이 높지만, 저장 비용이 비싸고 비정형 데이터나 머신러닝 워크로드에는 적합하지 않으며 데이터가 벤더의 독자 형식에 종속되는 경향이 있다. 데이터 레이크는 반대로 모든 형식의 데이터를 저렴하게 저장하고 다양한 엔진으로 접근할 수 있지만, 전통적으로 트랜잭션과 품질 보장, 쿼리 성능이 부족했다. 이 때문에 많은 조직이 레이크에 원본을 저장하고 정제된 일부를 웨어하우스로 복사하는 2계층 구조를 운영했는데, 이는 데이터 복제에 따른 비용, 두 저장소 간 불일치와 지연, ETL 파이프라인의 복잡성이라는 새로운 문제를 낳았다.

레이크하우스

레이크하우스(Lakehouse)는 오브젝트 스토리지와 개방형 파일 형식 위에 웨어하우스 수준의 관리 기능을 얹어 두 아키텍처의 장점을 하나로 통합하려는 접근이다. 핵심은 파일 집합 위에 트랜잭션 로그 기반의 메타데이터 계층을 두는 개방형 테이블 형식(open table format)으로, Delta Lake, Apache Iceberg, Apache Hudi가 대표적이다. 이들은 다음과 같은 기능을 제공한다.

ACID 트랜잭션 : 여러 파일에 걸친 쓰기를 원자적으로 커밋하여 동시 읽기·쓰기 시에도 일관된 스냅샷을 보장한다.
스키마 강제와 진화(schema enforcement & evolution) : 잘못된 형식의 데이터 유입을 차단하면서도 컬럼 추가·변경을 안전하게 지원한다.
타임 트래블(time travel) : 과거 특정 시점의 테이블 스냅샷을 조회하거나 되돌릴 수 있어 재현성과 감사에 유리하다.
행 단위 갱신·삭제(upsert/delete) : 개인정보 삭제 요청이나 변경 데이터 캡처(CDC) 반영처럼 파일 기반 저장소에서 어려웠던 작업을 SQL로 처리한다.
파일 최적화 : 작은 파일 병합(compaction), 데이터 스킵을 위한 통계 관리, 클러스터링을 통해 쿼리 성능을 높인다.

Delta Lake는 Databricks에서 시작되어 Spark 생태계와 결합이 긴밀하고, Iceberg는 Netflix에서 출발해 엔진 중립적인 설계와 숨겨진 파티셔닝(hidden partitioning)을 특징으로 하며 여러 벤더가 표준으로 채택하고 있고, Hudi는 Uber에서 증분 처리와 스트리밍 적재를 위해 개발되어 준실시간 upsert에 강점이 있다. 세 형식 모두 Apache-2.0 라이선스의 오픈소스이며, 최근에는 형식 간 상호 운용을 위한 변환 계층도 등장하고 있다.

메달리온 아키텍처

레이크 내부의 데이터를 정제 수준에 따라 단계적으로 구분하는 설계 패턴으로 메달리온 아키텍처(Medallion Architecture)가 널리 쓰인다.

브론즈(Bronze) : 원천 시스템의 데이터를 변경 없이 그대로 적재하는 영역으로, 적재 시각과 원천 정보 같은 메타데이터만 덧붙인다. 원본을 보존하므로 이후 단계의 오류 발생 시 언제든 재처리의 출발점이 된다.
실버(Silver) : 중복 제거, 형식 표준화, 결측 처리, 원천 간 키 정합 등 필수적인 정제를 거쳐 조직 전체가 공통으로 참조할 수 있는 정합된 데이터를 제공한다.
골드(Gold) : 특정 업무나 분석 목적에 맞게 집계·결합된 소비용 데이터로, 대시보드, 보고서, 머신러닝 특징 테이블이 직접 참조한다.

각 계층은 진입 조건과 품질 기준이 다르므로 스웜프화를 구조적으로 막아 주며, 계층 간 변환을 데이터 파이프라인(Data Pipeline)으로 자동화하고 리니지를 기록함으로써 데이터의 출처와 신뢰 수준을 추적할 수 있다.

거버넌스와 카탈로그

데이터 레이크가 실제로 활용되기 위해서는 데이터가 어디에 있고 무엇을 의미하는지를 찾을 수 있게 하는 데이터 카탈로그(data catalog)가 필수적이다. 카탈로그는 테이블·파일의 스키마, 위치, 소유자, 설명, 태그, 품질 지표, 리니지 같은 메타데이터를 중앙에서 관리하며, Hive Metastore, AWS Glue Data Catalog, Unity Catalog, Apache Polaris 같은 기술적 카탈로그와 DataHub, OpenMetadata 같은 검색·협업 중심 카탈로그가 사용된다. 거버넌스 측면에서는 테이블·컬럼·행 수준의 접근 제어, 개인정보 컬럼의 마스킹과 암호화, 데이터 보존 기간과 삭제 정책, 데이터 소유자와 스튜어드의 책임 정의가 포함된다. 특히 개인정보 보호 규제에 따라 특정 개인의 데이터를 찾아 삭제해야 하는 요구는 파일 기반 레이크에서 어려운 과제였으며, 레이크하우스의 행 단위 삭제와 카탈로그 기반 데이터 발견이 이를 현실적으로 가능하게 했다.

결론적으로 데이터 레이크는 저렴한 오브젝트 스토리지 위에 모든 데이터를 원본 그대로 모아 두고 다양한 엔진으로 활용할 수 있게 하는 유연한 기반이지만, 그 유연성은 거버넌스, 카탈로그, 계층화된 정제 구조가 뒷받침될 때만 가치로 전환된다. 개방형 테이블 형식이 트랜잭션과 품질 보장을 더하면서 레이크와 웨어하우스의 경계는 빠르게 허물어지고 있으며, 오늘날 데이터 레이크를 설계한다는 것은 사실상 개방형 형식 위에 신뢰할 수 있는 레이크하우스를 구축하는 일을 의미한다.

#관련 용어

데이터 웨어하우스

분석과 보고를 위해 정제되고 모델링된 정형 데이터를 저장하는 중앙 저장소

스키마 온 리드

데이터를 원본 그대로 저장하고 읽는 시점에 구조를 해석하는 방식

오브젝트 스토리지

데이터를 파일과 메타데이터로 이루어진 객체 단위로 저장하는 확장성이 높은 저비용 저장소

레이크하우스

데이터 레이크의 개방형 저장소 위에 트랜잭션과 관리 기능을 더해 웨어하우스의 장점을 결합한 아키텍처

데이터 스웜프

메타데이터와 관리 체계가 없어 활용할 수 없는 상태로 방치된 데이터 레이크

데이터 파이프라인

데이터를 수집·변환·적재하여 활용 가능한 형태로 전달하는 자동화된 처리 흐름

#직무 연관도

Data Analyst보통

정제된 실버·골드 계층 데이터를 SQL로 조회하고 카탈로그를 통해 필요한 데이터를 찾는 데 활용한다

Data Scientist높음

원본 데이터와 비정형 데이터에 직접 접근하여 특징을 탐색하고 학습 데이터셋을 구성하는 기반이 된다

Data Engineer밀접

저장 계층 설계, 테이블 형식 선택, 파티셔닝과 최적화, 거버넌스 구축이 데이터 엔지니어의 핵심 책임이다

#사용 사례

전자상거래금융인터넷 서비스제조의료통신

개요

데이터 레이크는 로그와 이벤트의 장기 보관, 머신러닝 학습 데이터 저장, 여러 원천 데이터의 통합 분석, 비정형 데이터의 아카이브에 사용된다. 저장 비용이 낮고 다양한 엔진으로 접근할 수 있어 대규모 데이터 플랫폼의 기반 저장 계층으로 활용된다.

사례

온라인 커머스 기업은 클릭스트림 로그, 주문 데이터베이스의 변경 이력, 상품 이미지, 고객 문의 텍스트를 모두 S3 기반 데이터 레이크의 브론즈 계층에 원본 그대로 적재한 뒤, Iceberg 테이블로 정제한 실버 계층에서 사용자·상품 기준으로 정합하고, 골드 계층에서 매출 대시보드용 집계 테이블과 추천 모델용 특징 테이블을 생성한다. 개인정보 삭제 요청이 들어오면 카탈로그로 해당 사용자 데이터가 포함된 테이블을 찾아 행 단위로 삭제하고, 타임 트래블 기능으로 특정 시점의 학습 데이터를 재현한다.