데이터 레이크하우스란 무엇인가: 레이크와 웨어하우스의 차이, 테이블 형식과 카탈로그까지

핵심 메시지

• 데이터 레이크하우스는 데이터 웨어하우스의 안정성과 데이터 레이크의 확장성을 하나의 공유 데이터 계층으로 합치려는 현대적 아키텍처다.
• 객체 스토리지는 저렴하고 확장성이 뛰어나지만 가공되지 않은 파일만 저장하므로, 데이터베이스 같은 일관성을 얻으려면 개방형 테이블 형식이 필요하다.
• Apache Iceberg·Delta Lake·Apache Hudi 같은 테이블 형식은 스냅샷과 커밋 기록을 유지해 모든 쓰기가 성공 또는 실패로 끝나고, 읽는 쪽은 항상 일관된 상태를 본다.
• 공유 카탈로그가 테이블 이름을 메타데이터·스키마·현재 버전에 매핑해 Spark와 Trino 같은 서로 다른 엔진이 같은 데이터를 단일 진실의 원천으로 참조한다.
• 레이크하우스는 중복 복사를 줄여 유연성과 확장성을 주지만, 작은 파일 병합·거버넌스 같은 플랫폼 엔지니어링 비용을 감수해야 한다.

쉽게 이해하기

데이터 레이크하우스를 이해하려면 먼저 이것이 대체하려는 두 시스템을 알아야 한다. 데이터 웨어하우스는 선별되고 분석 준비가 끝난 데이터를 저장하며, 보통 ACID 트랜잭션을 지원하고 빠른 SQL 쿼리에 최적화돼 있다. 예를 들어 재무팀은 웨어하우스로 정확한 일일 매출 보고서를 만든다. 반면 데이터 레이크는 저렴한 객체 스토리지에 방대한 원시·반정형·비정형 데이터를 담는다. 데이터 과학팀이 수백만 건의 클릭스트림 로그를 저장해 머신러닝 모델을 학습시키는 식이다.

전자상거래 플랫폼처럼 주문·결제·고객 지원 로그가 쏟아지는 환경에서는 보통 원시 파일은 레이크에, 선별된 분석 테이블은 별도의 웨어하우스에 둔다. 초기에는 잘 작동하지만, 플랫폼이 커지면 스키마 변경 한 번이 두 개의 수집 경로, 두 개의 품질 검사, 두 개의 접근 모델 모두에 영향을 준다. 결국 데이터 엔지니어는 새 데이터 제품을 만드는 대신 두 시스템을 동기화하는 데 시간을 쏟게 된다.

레이크하우스는 이 문제를 단 하나의 스토리지 계층에서 다시 설계한다. 원시 주문 이벤트와 선별된 분석 테이블을 모두 같은 객체 스토리지에 두고, 원시 데이터를 가공해 Parquet 같은 최적화된 파일 형식으로 다시 저장한다. 이렇게 하면 시스템 간 중복 복사가 사라진다. 다만 객체 스토리지는 가용성·내구성·확장성은 뛰어나도 그 안에 든 것이 데이터베이스 테이블인지는 알지 못한다. 그래서 쓰기 도중 작업이 끊기면 불완전한 테이블이 보이거나, 누군가 읽는 동안 다른 누군가 쓰면 일부 업데이트만 보일 수 있다.

이 빈틈을 메우는 것이 Apache Iceberg·Delta Lake·Apache Hudi 같은 개방형 테이블 형식이다. 이들은 원시 파일을 그대로 노출하는 대신 테이블 메타데이터, 스냅샷, 커밋 기록을 유지한다. 덕분에 모든 쓰기는 성공하거나 실패하게 되고, 동시 업데이트 중에도 읽는 쪽은 항상 일관된 화면을 본다. 또한 컬럼 이름 변경 같은 스키마 변경을 메타데이터 작업으로 처리해, 방대한 과거 데이터를 다시 쓰지 않고도 테이블을 발전시킬 수 있다. 여러 도구가 이 테이블을 찾으려면 공유 카탈로그가 필요한데, 카탈로그는 테이블 이름을 메타데이터·스키마·현재 버전에 매핑해 단일 진실의 원천을 만든다. 그 위에 AWS Lake Formation, Databricks Unity Catalog 같은 거버넌스 계층이 누가 어떤 민감 데이터를 읽을 수 있는지 관리한다.

형식, 카탈로그, 거버넌스가 갖춰지면 배치 작업, 스트리밍 작업, 머신러닝 모델이 모두 같은 데이터 계층에서 같은 테이블을 보게 된다. 값비싼 데이터 반복 복사도 사라진다. 그러나 절충점도 있다. 서로 다른 쿼리 엔진이 데이터 타입을 다르게 해석할 수 있어 표준을 세우고 핵심 타입을 여러 엔진에서 검증해야 한다. 작은 파일이 쌓이면 쿼리가 느려져 주기적인 병합 작업이 필요하고, 잘못된 스키마 변경 한 번이 재무 대시보드와 머신러닝 파이프라인을 동시에 망가뜨릴 수 있다. 빠른 분석이 우선이면 웨어하우스를, 저렴한 원시 저장과 머신러닝만 필요하면 레이크를, 둘 다 필요하고 운영 역량이 있으면 레이크하우스를 택하는 것이 합리적이다.

주요 인사이트

• 레이크와 웨어하우스를 따로 운영하면 스키마 변경 한 번이 수집 경로·품질 검사·접근 모델을 두 벌씩 건드려, 동기화 자체가 큰 운영 부담이 된다.
• 테이블 형식의 핵심 가치는 '원자적 쓰기'다. 작업이 중간에 끊겨도 테이블이 불완전하게 노출되지 않고, 동시 읽기·쓰기에서도 일관성이 보장된다.
• 스키마 변경을 메타데이터 작업으로 처리하기 때문에 컬럼 이름 변경 같은 작업에 방대한 과거 데이터를 다시 쓸 필요가 없다.
• 공유 카탈로그가 '단일 진실의 원천' 역할을 하므로, 한 엔진이 기록한 최신 데이터를 다른 엔진이 즉시 인식할 수 있다.
• 레이크하우스는 완전 관리형 데이터베이스가 아니다. 작은 파일 병합, 데이터 타입 표준화, 거버넌스 운영을 직접 책임져야 한다.

자주 묻는 질문

관련 AI 소식