데이터 레이크를 구축했는데 분석이 여전히 느리다면: Lakehouse가 해결하는 문제

데이터 레이크를 구축하고 나서 이런 말을 들어본 적 있을 것이다. "S3에 데이터는 쌓이는데, Redshift에 올리기 전까지는 분석을 못 해요." 데이터는 있는데 쓸 수 없는 상황, 혹은 데이터를 복사해야만 질의가 가능한 상황. 이 문제를 해결하기 위해 등장한 구조가 Lakehouse다.

요약

Lakehouse는 데이터 레이크의 저장 규모와 데이터 웨어하우스의 질의 성능을 하나의 아키텍처에서 구현하는 데이터 플랫폼 패러다임이다. 2021년 Databricks가 이 개념을 체계화한 이후, AWS와 Azure 모두 공식적으로 Lakehouse 아키텍처를 자사 플랫폼의 기반 개념으로 채택했다. 이 글에서는 왜 Lakehouse가 현재 데이터 플랫폼의 기본 구조로 자리잡았는지, 실무 관점에서 어떤 계층으로 구성되는지를 설명한다.

이 글이 필요한 사람

데이터 레이크와 데이터 웨어하우스를 각각 운영하고 있거나, 신규 데이터 플랫폼 도입을 검토 중인 클라우드 운영자, 데이터 엔지니어, 인프라 담당자를 위한 글이다. Lakehouse라는 용어를 들어봤지만 실제로 무엇을 의미하는지 정확히 파악하지 못한 분들에게도 적합하다.

왜 지금 이 주제인가

2024년 말 AWS는 Amazon S3 Tables를 출시하며 Lakehouse를 서비스 수준에서 지원하기 시작했다. Microsoft는 Microsoft Fabric에서 OneLake를 핵심 스토리지로 내세우며 모든 분석 워크로드를 단일 Lakehouse 위에 올리는 방향으로 플랫폼을 재편했다. Apache Iceberg 기반의 범용 카탈로그 표준인 Apache Polaris도 2026년 초 프로덕션 수준에 도달했다. 단순한 트렌드 용어가 아니라, 지금 클라우드 데이터 플랫폼을 구축하거나 개선하는 모든 팀이 실질적으로 선택해야 하는 구조가 됐다.

데이터 레이크와 데이터 웨어하우스: 각자의 한계

두 구조의 차이를 먼저 짚는 것이 중요하다.

데이터 레이크는 원시 데이터를 저렴하게 대량으로 보관할 수 있다. S3나 ADLS Gen2 같은 오브젝트 스토리지에 CSV, JSON, Parquet 형태로 쌓는 방식이다. 스키마 제약이 없고, 다양한 형식을 받아들인다. 그러나 SQL 기반의 직접 질의가 느리거나 불편하고, 데이터 품질을 보장하기 어렵다. 트랜잭션 지원이 없어 동시 쓰기 충돌이 발생하기 쉽고, 특정 시점의 데이터 상태를 추적하기도 까다롭다.

데이터 웨어하우스는 반대 특성을 가진다. Redshift, BigQuery, Azure Synapse 같은 시스템은 구조화된 데이터에 대해 빠른 SQL 질의를 제공한다. ACID 트랜잭션, 스키마 강제, 최적화된 쿼리 플랜을 갖추고 있다. 하지만 비용이 크고, 비정형 데이터나 머신러닝 워크로드를 다루기 어렵다. 무엇보다 데이터 레이크에서 웨어하우스로 데이터를 복사하거나 ETL을 거쳐야 한다는 점이 실무에서 가장 큰 병목이 된다.

결과적으로 많은 조직에서 같은 데이터를 두 곳에서 관리하게 된다. 레이크에는 원시 데이터, 웨어하우스에는 분석용 데이터. 이 이중화가 데이터 불일치, 파이프라인 복잡도, 운영 비용 증가로 이어진다.

Lakehouse가 등장한 배경

Lakehouse는 이 이중 구조를 단일 계층으로 통합하려는 시도다.

핵심 아이디어는 간단하다. 오브젝트 스토리지(S3, ADLS Gen2 등)를 기반으로 하되, 그 위에 테이블 포맷 계층과 카탈로그 계층을 추가해 데이터 웨어하우스 수준의 기능을 제공한다는 것이다. 데이터를 복사하지 않고 원본 위치에서 직접 SQL 질의하고, 동시에 스파크나 파이썬 기반의 ML 워크로드도 같은 데이터를 쓸 수 있게 한다.

이 구조를 처음 체계적으로 명명하고 확산시킨 곳은 Databricks다. Delta Lake 프로젝트를 통해 ACID 트랜잭션, 스키마 진화, 타임트래블(특정 시점 데이터 조회) 기능을 오픈 소스로 제공하면서 Lakehouse라는 개념을 실체화했다.

Lakehouse의 핵심 구조

Lakehouse는 보통 세 개의 계층으로 설명된다.

스토리지 계층은 오브젝트 스토리지다. S3, ADLS Gen2, GCS가 대표적이다. Parquet 포맷 파일을 기본 단위로 저장한다. 이 계층 자체는 기존 데이터 레이크와 동일하다.

테이블 포맷 계층이 Lakehouse를 레이크와 구분 짓는 핵심이다. 오픈 테이블 포맷(Open Table Format)이 파일 시스템 위에서 트랜잭션, 스키마 관리, 통계, 파티셔닝 메타데이터를 담당한다. 현재 주요 포맷은 세 가지다.

• Delta Lake: Databricks가 시작한 포맷으로, Microsoft Fabric과 Azure Databricks에서 표준으로 사용된다.
• Apache Iceberg: Netflix에서 시작되어 AWS가 공식 지원 포맷으로 채택했다. 현재 가장 빠르게 생태계가 확장되고 있다.
• Apache Hudi: Uber에서 시작된 포맷으로, 스트리밍 수집과 레코드 수준 업데이트에 강점이 있다.

세 포맷 모두 ACID 트랜잭션, 스키마 진화, 타임트래블을 지원하며, 서로 다른 클라우드와 쿼리 엔진에서 상호 운용 가능하도록 표준화가 진행 중이다.

카탈로그 계층은 어떤 테이블이 어디 있는지 추적하는 메타데이터 레지스트리다. AWS Glue Data Catalog, Apache Hive Metastore, Unity Catalog(Databricks), AWS S3 Tables의 내장 카탈로그, Microsoft Fabric의 통합 카탈로그 등이 있다. 2026년 초 Apache Polaris가 프로덕션 수준에 도달하면서 Iceberg, Delta Lake, Hudi를 모두 지원하는 벤더 중립 카탈로그 표준도 자리를 잡아가고 있다.

Medallion Architecture: Bronze, Silver, Gold

Lakehouse를 설명할 때 항상 따라오는 개념이 Medallion Architecture다. 데이터를 품질 단계에 따라 세 레이어로 구분하는 설계 패턴이다.

Bronze 레이어는 수집된 원시 데이터를 그대로 보관한다. 최소한의 변환만 거치며, 데이터 히스토리와 감사 추적을 위해 유지된다.

Silver 레이어는 정제된 데이터다. 중복 제거, 타입 정규화, 기본적인 데이터 품질 검증이 이루어진다. 분석 및 보고에 재사용 가능한 수준의 데이터가 된다.

Gold 레이어는 비즈니스 목적에 맞게 집계되고 최적화된 데이터다. 대시보드, BI 툴, 핵심 지표 계산에 직접 쓰인다.

이 패턴은 AWS와 Azure 모두 공식 권장 구조로 채택했다. Microsoft Fabric 문서도 OneLake에서의 Medallion 구현을 기본 예시로 제시한다.

AWS 관점: Amazon SageMaker Lakehouse와 S3 Tables

AWS에서 Lakehouse는 Amazon SageMaker Lakehouse라는 이름으로 구체화됐다. Apache Iceberg를 기반으로 하며, Amazon S3와 Amazon Redshift에 있는 데이터를 하나의 통합된 카탈로그(AWS Glue Data Catalog)에서 접근할 수 있게 한다.

2024년 12월 GA된 Amazon S3 Tables는 한 단계 더 나아간 서비스다. 기존에는 일반 S3 버킷에 Iceberg 테이블을 직접 관리해야 했지만, S3 Tables는 테이블 버킷이라는 전용 버킷 타입을 제공하고 파일 컴팩션, 스냅샷 관리, 비참조 파일 제거를 자동으로 처리한다. AWS 발표에 따르면 S3 Tables는 자체 관리 Iceberg 테이블 대비 질의 처리량 3배, 초당 트랜잭션 수 10배 수준의 성능을 제공한다.

AWS Glue Data Catalog는 S3 Tables와 일반 Iceberg 테이블을 모두 통합 관리할 수 있으며, Athena, EMR, Redshift Spectrum 등 다양한 쿼리 엔진에서 동일한 카탈로그로 접근 가능하다.

Azure 관점: Microsoft Fabric과 OneLake

Azure에서 Lakehouse의 핵심은 Microsoft Fabric과 OneLake다. OneLake는 ADLS Gen2 위에 구축된 테넌트 단위의 단일 데이터 레이크로, "데이터의 OneDrive"라는 콘셉트로 설명된다. 모든 Fabric 서비스(Data Factory, Synapse Analytics, Power BI, Real-Time Analytics 등)가 OneLake를 공유 스토리지로 사용한다.

OneLake는 모든 테이블 데이터를 Delta Parquet 포맷으로 저장한다. 덕분에 Spark, SQL, Power BI가 데이터를 복사하지 않고 동일한 파일을 직접 읽는다. Shortcut 기능을 통해 기존 ADLS Gen2나 S3의 데이터를 이동 없이 참조할 수도 있다.

Medallion Architecture는 Microsoft Fabric 공식 문서에서도 OneLake 위에서 Lakehouse를 구성하는 기본 패턴으로 권장된다.

실무 체크리스트

• 현재 데이터 레이크와 데이터 웨어하우스 사이의 ETL 파이프라인 복잡도와 지연 시간을 측정한다.
• 오픈 테이블 포맷 선택 시 주 클라우드 환경과 사용 중인 쿼리 엔진 호환성을 먼저 확인한다. AWS 중심이면 Iceberg, Azure/Databricks 중심이면 Delta Lake가 기본 출발점이다.
• 카탈로그 계층은 반드시 초기에 설계한다. 카탈로그 없이 스토리지부터 쌓으면 나중에 테이블 탐색과 거버넌스 구축 비용이 크게 증가한다.
• Medallion Architecture를 적용할 때 Bronze 레이어는 절대 삭제하지 않는 방침을 팀 수준에서 합의한다. 원시 데이터 보존이 나중에 재처리나 감사 시 핵심 자산이 된다.
• 데이터 품질 검증 로직은 Silver 레이어 진입 시점에 위치시킨다. Bronze에서 Gold로 바로 올라가는 로직은 운영 중 품질 이슈가 생겼을 때 추적이 어려워진다.
• 파일 크기 관리(컴팩션)와 스냅샷 정리는 운영 초기부터 자동화를 검토한다. S3 Tables는 이를 관리형으로 제공하고, AWS Glue에서도 자동화 설정이 가능하다.

흔한 실수

"Lakehouse는 Databricks 전용이다"라고 오해하는 경우. Databricks가 개념을 확산시켰지만, Delta Lake, Apache Iceberg, Apache Hudi는 모두 오픈 소스다. AWS, Azure, GCP 모두 자체 방식으로 Lakehouse를 제공하며 특정 벤더에 종속된 개념이 아니다.

카탈로그 없이 스토리지만 구성하는 경우. S3에 Parquet 파일을 쌓고 "레이크하우스를 구축했다"고 보는 시각이 있는데, 카탈로그 계층 없이는 테이블 수준의 ACID 보장이나 타임트래블이 불가능하다. 스토리지, 테이블 포맷, 카탈로그 세 계층이 모두 갖춰져야 Lakehouse라고 할 수 있다.

Gold 레이어를 웨어하우스처럼 쓰면서 별도 Redshift나 Synapse를 또 두는 경우. Lakehouse의 목적 자체가 이 이중화를 줄이는 것이다. 기존 웨어하우스를 유지해야 한다면 이행 계획 없이 Lakehouse를 병행하는 것은 복잡도를 오히려 높인다.

마무리

Lakehouse는 "데이터 레이크와 데이터 웨어하우스의 장점을 합쳤다"는 마케팅 언어처럼 들릴 수 있지만, 실제로는 오픈 테이블 포맷이라는 구체적인 기술적 해법 위에서 동작한다. AWS는 S3 Tables와 SageMaker Lakehouse로, Azure는 Microsoft Fabric과 OneLake로, 각각 이 아키텍처를 서비스화했다. 새로운 데이터 플랫폼을 구성한다면 레이크와 웨어하우스를 분리해서 출발하기보다 Lakehouse 구조를 기반으로 시작하는 것이 현 시점에서 합리적인 선택이다.

---

이 글이 유용했다면 다음 편도 확인해보세요. 다음 글: AI Agent 런타임은 왜 별도 운영 계층이 필요한가

References

• https://www.databricks.com/product/data-lakehouse
• https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-overview
• https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview
• https://aws.amazon.com/blogs/big-data/the-amazon-sagemaker-lakehouse-architecture-now-automates-optimization-configuration-of-apache-iceberg-tables-on-amazon-s3/
• https://docs.aws.amazon.com/sagemaker-lakehouse-architecture/latest/userguide/s3-tables-integration.html
• https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture
• https://promethium.ai/guides/data-lakehouse-architecture-complete-guide-2026/