데이터 레이크하우스(Data Lakehouse)

•

2026년 10월 18일 발행•2026년 10월 18일 수정

요약

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

중급

데이터 레이크와 데이터 웨어하우스, 분산 처리 엔진의 기본 구조를 알아야 하며, 트랜잭션과 파일 포맷, 메타데이터 관리에 대한 이해가 필요하다.

태그

데이터 레이크 데이터 웨어하우스 빅데이터 데이터 거버넌스 데이터 파이프라인

#개념

데이터 레이크하우스(Data Lakehouse)는 데이터 레이크의 저렴하고 개방된 저장소 위에 데이터 웨어하우스의 트랜잭션, 스키마 관리, 성능 최적화 기능을 얹은 데이터 아키텍처이다. 하나의 데이터 사본으로 BI 리포팅과 머신러닝을 함께 처리하는 것을 목표로 한다.

레이크하우스라는 개념은 Databricks가 2020년경 널리 알렸고, Armbrust 등(2021)이 CIDR 논문에서 개방형 파일 포맷, 메타데이터 계층, 고성능 SQL, 데이터 과학 도구 지원을 핵심 요소로 정리하였다. 이후 Snowflake, AWS, Google Cloud 등 주요 데이터 플랫폼도 비슷한 방향의 기능을 제공하면서 업계 표준 아키텍처로 확산되었다.

레이크하우스 이전에는 원천 데이터를 데이터 레이크(Data Lake)에 쌓고, 정제한 일부를 데이터 웨어하우스(Data Warehouse)로 다시 적재하는 2계층 구조가 일반적이었다. 이 구조는 다음과 같은 한계를 가진다.

2계층 구조의 한계

데이터 중복과 비용: 같은 데이터가 레이크와 웨어하우스에 이중으로 저장되고, 둘 사이를 잇는 ETL 파이프라인을 따로 운영해야 한다.
신선도 저하: 레이크에서 웨어하우스로 옮기는 단계가 추가되어 분석에 쓰이는 데이터가 늦어지고 불일치가 생긴다.
신뢰성 부족: 데이터 레이크는 트랜잭션을 지원하지 않아 쓰기 중 실패나 동시 쓰기로 파일이 깨지기 쉽다.
ML 지원 미흡: 웨어하우스의 독점 포맷은 파이썬 기반 ML 도구가 직접 읽기 어려워, 데이터 과학자는 다시 레이크의 날것 데이터를 써야 한다.

레이크하우스는 이 문제를 오픈 테이블 포맷(Open Table Format)으로 해결한다. 데이터 파일은 Parquet처럼 개방된 형식으로 객체 스토리지에 저장하고, 그 위에 어떤 파일이 테이블의 어느 버전에 속하는지를 기록하는 트랜잭션 로그나 메타데이터 파일을 둔다. 엔진은 파일 목록을 직접 훑는 대신 이 메타데이터를 읽어 일관된 스냅숏을 얻는다.

대표적인 오픈 테이블 포맷은 다음과 같다.

주요 오픈 테이블 포맷

델타 레이크(Delta Lake): Databricks가 공개한 포맷으로, _delta_log 디렉터리에 JSON 트랜잭션 로그와 체크포인트를 기록한다. Spark와의 통합이 깊고 Databricks 플랫폼의 기본 포맷이다.
아파치 아이스버그(Apache Iceberg): Netflix에서 시작된 포맷으로, 메타데이터 파일·매니페스트 목록·매니페스트로 이어지는 계층 구조를 쓴다. 숨은 파티셔닝과 파티션 진화를 지원하며 여러 엔진과 벤더가 폭넓게 채택했다.
아파치 후디(Apache Hudi): Uber에서 시작된 포맷으로, 레코드 단위 업서트와 증분 처리에 강하다. 쓰기 시 병합(Copy-on-Write)과 읽기 시 병합(Merge-on-Read) 방식을 선택할 수 있다.

오픈 테이블 포맷이 제공하는 핵심 기능은 다음과 같다.

테이블 포맷의 핵심 기능

ACID 트랜잭션: 낙관적 동시성 제어로 여러 작업이 동시에 써도 커밋 단위로 원자성과 격리성을 보장한다.
스키마 강제와 진화: 잘못된 스키마의 쓰기를 거부하고, 컬럼 추가·이름 변경 같은 변경은 기존 데이터를 다시 쓰지 않고 반영한다.
타임 트래블(Time Travel): 과거 버전이나 시점의 스냅숏을 조회할 수 있어 감사, 롤백, 모델 학습 데이터 재현에 쓰인다.
업서트와 삭제: MERGE, UPDATE, DELETE를 지원해 변경 데이터 캡처(CDC)와 개인정보 삭제 요청 처리를 가능하게 한다.

테이블 포맷 위에는 테이블 이름, 스키마, 위치, 권한을 관리하는 카탈로그(Catalog) 계층이 놓인다. Databricks의 Unity Catalog는 테이블뿐 아니라 파일, ML 모델, 함수까지 통합 관리하며 2024년 오픈소스로 공개되었고, Snowflake가 공개한 Apache Polaris는 Iceberg REST 카탈로그 사양을 구현한다. AWS Glue Data Catalog나 Hive 메타스토어도 카탈로그로 쓰인다.

카탈로그는 접근 제어, 감사 로그, 데이터 리니지(Data Lineage) 수집 같은 데이터 거버넌스(Data Governance) 기능의 중심이 된다. 여러 엔진이 같은 카탈로그를 바라보면 Spark로 쓴 테이블을 Trino나 Snowflake에서 그대로 읽는 식의 상호 운용이 가능해진다.

레이크하우스에서는 데이터를 정제 단계별 계층으로 나누는 메달리온 아키텍처(Medallion Architecture)가 흔히 쓰인다.

메달리온 아키텍처의 계층

브론즈(Bronze): 원천 시스템의 데이터를 거의 원형 그대로 적재한 계층이다. 적재 시각 등 메타데이터를 붙여 재처리와 이력 보존에 쓴다.
실버(Silver): 브론즈 데이터를 정제·중복 제거·조인해 고객, 주문, 상품 같은 핵심 엔티티 단위로 정리한 계층이다.
골드(Gold): 특정 보고서나 서비스에 맞춰 집계·비정규화한 계층으로, BI 대시보드와 피처 테이블이 여기서 만들어진다.

레이크하우스는 저장과 계산의 분리(Separation of Storage and Compute)를 전제로 한다. 데이터는 S3, ADLS, GCS 같은 객체 스토리지에 한 번만 저장되고, SQL 웨어하우스, Spark 클러스터, 스트리밍 작업, ML 학습 작업이 필요할 때마다 독립적으로 확장되는 계산 자원을 띄워 같은 테이블을 읽는다. 따라서 워크로드별로 비용과 성능을 따로 조정할 수 있다.

이런 구조 덕분에 BI와 ML이 하나의 플랫폼을 공유한다. 분석가는 SQL로 골드 테이블을 조회하고, 데이터 과학자는 같은 테이블을 데이터프레임으로 읽어 모델을 학습하며, 타임 트래블로 학습 시점의 데이터를 고정해 실험을 재현할 수 있다. 피처 스토어(Feature Store)와 모델 레지스트리도 같은 카탈로그 아래 관리되는 경우가 많다.

객체 스토리지는 지연 시간이 길고 인덱스가 없으므로, 레이크하우스는 웨어하우스 수준의 성능을 내기 위해 여러 최적화를 사용한다.

주요 성능 최적화 기법

데이터 스키핑(Data Skipping): 파일별 컬럼 최솟값·최댓값 통계를 메타데이터에 저장하고, 조건에 맞지 않는 파일은 읽지 않는다.
Z-순서(Z-order) 정렬: 여러 컬럼 값을 공간 채움 곡선으로 섞어 정렬해, 여러 필터 컬럼에 대해 데이터 스키핑 효과를 높인다. 최근에는 리퀴드 클러스터링 같은 점진적 방식도 쓰인다.
컴팩션(Compaction): 스트리밍이나 잦은 소량 쓰기로 생긴 작은 파일들을 큰 파일로 합쳐 메타데이터와 읽기 비용을 줄인다.
캐싱과 벡터화 엔진: 자주 읽는 데이터를 로컬 SSD에 캐시하고, Photon 같은 벡터화 실행 엔진으로 연산을 가속한다.

운영 측면에서는 오래된 버전 파일 정리와 통계 관리도 중요하다. 타임 트래블을 위해 남겨둔 과거 파일은 VACUUM이나 스냅숏 만료 작업으로 주기적으로 지워야 저장 비용이 계속 늘지 않는다. 또한 파티션을 지나치게 잘게 나누면 작은 파일 문제가 심해지므로, 날짜처럼 카디널리티가 적당한 컬럼을 파티션 키로 고른다.

레이크하우스를 도입할 때는 기술과 조직 양쪽을 함께 검토해야 한다. 먼저 테이블 포맷과 카탈로그를 무엇으로 정할지가 장기적인 엔진 선택과 벤더 종속성을 좌우한다. 포맷 간 호환을 위해 Delta UniForm이나 Apache XTable처럼 하나의 데이터에 여러 포맷의 메타데이터를 생성하는 기술도 등장했다.

다음으로 기존 웨어하우스의 SQL과 권한 체계를 옮기는 마이그레이션 비용, 작은 파일·컴팩션 같은 운영 부담, 초저지연 대화형 질의에서의 성능 차이를 검토해야 한다. 조직 측면에서는 메달리온 계층별 소유 팀과 품질 기준, 카탈로그 기반의 권한 정책을 함께 설계해야 레이크하우스가 또 다른 데이터 늪이 되지 않는다.

데이터 레이크하우스는 저장소를 하나로 합치고 그 위에 다양한 엔진과 워크로드를 올리는 방향으로 데이터 플랫폼을 바꾸어 놓았다. 오픈 테이블 포맷과 카탈로그가 표준화될수록 데이터는 특정 엔진에 묶이지 않는 자산이 되며, 분석과 AI를 같은 데이터 위에서 일관되게 운영하는 기반이 된다.

#관련 용어

데이터 레이크

정형·비정형 데이터를 원형 그대로 저렴한 저장소에 모아 두는 저장소

데이터 웨어하우스

분석을 위해 정제·구조화된 데이터를 저장하고 고성능 SQL 질의를 제공하는 시스템

오픈 테이블 포맷

객체 스토리지의 파일 묶음을 트랜잭션과 스키마를 갖춘 테이블로 관리하는 개방형 메타데이터 규격

데이터 카탈로그

테이블과 데이터 자산의 메타데이터, 권한, 리니지를 관리하고 검색하게 하는 시스템

메달리온 아키텍처

데이터를 브론즈·실버·골드 계층으로 나누어 단계적으로 정제하는 설계 방식

타임 트래블

테이블의 과거 버전이나 특정 시점의 스냅숏을 조회하는 기능

#직무 연관도

Data Analyst높음

골드 계층 테이블을 SQL로 조회해 리포트와 대시보드를 만드는 주된 분석 환경

Data Scientist보통

학습 데이터 조회와 타임 트래블 기반 실험 재현, 피처 테이블 활용에 필요

Data Engineer밀접

테이블 포맷·카탈로그 선택, 파이프라인과 성능 최적화, 거버넌스 설계를 직접 담당

#사용 사례

전자상거래금융통신미디어제조

개요

데이터 레이크하우스는 대량의 로그와 거래 데이터를 다루면서 BI와 머신러닝을 함께 운영해야 하는 조직에서 쓰인다. 전자상거래와 미디어에서는 사용자 행동 로그 분석과 추천 모델 학습에, 금융과 통신에서는 규제 대응을 위한 감사 이력과 이상 탐지에, 제조에서는 센서 데이터의 실시간 수집과 품질 분석에 활용된다.

사례

전자상거래 기업이 주문·클릭 로그를 델타 레이크 브론즈 테이블에 스트리밍으로 적재하고, 실버·골드 테이블로 정제해 매출 대시보드와 추천 모델 학습 데이터를 같은 테이블에서 함께 제공한다.