0x03. 데이터 레이크 vs 데이터 웨어하우스

데이터 플랫폼을 설계할 때 반드시 마주하는 질문이 있다. "데이터를 어디에 저장할 것인가?" 정형화된 데이터를 분석용으로 정제해 저장할 것인가(웨어하우스), 아니면 원본 데이터를 그대로 보존할 것인가(레이크). 이 두 접근은 근본적으로 다른 철학을 가지며, 최근에는 이 둘을 합치는 Lakehouse 패러다임이 부상하고 있다.

데이터 웨어하우스(Data Warehouse)

개념

데이터 웨어하우스는 비즈니스 의사결정을 위해 정제되고 구조화된 데이터를 저장하는 중앙 저장소이다. 1990년대 Bill Inmon과 Ralph Kimball이 개념을 정립했다.

핵심 특성:

• Schema-on-Write: 데이터를 쓸 때 스키마가 확정된다. 구조화된 데이터만 저장한다
• ETL: Extract → Transform → Load. 데이터를 먼저 변환한 후 적재한다
• SQL 중심: SQL로 모든 분석을 수행한다
• 높은 데이터 품질: 적재 전에 검증과 정제를 거친다

아키텍처

전형적인 웨어하우스 아키텍처는 스타 스키마 또는 스노우플레이크 스키마로 설계된다.

         ┌─────────────┐
         │  Fact Table  │
         │  (orders)    │
         └──┬──┬──┬──┬─┘
            │  │  │  │
   ┌────────┘  │  │  └────────┐
   ↓           ↓  ↓           ↓
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ dim_ │ │ dim_ │ │ dim_ │ │ dim_ │
│ user │ │ prod │ │ date │ │ store│
└──────┘ └──────┘ └──────┘ └──────┘
         Star Schema

• Fact Table: 측정값(매출, 수량 등)을 저장. 매우 큰 테이블
• Dimension Table: 분석 축(사용자, 제품, 날짜 등)을 저장. 비교적 작은 테이블

대표 솔루션

• Amazon Redshift: AWS 관리형 웨어하우스
• Google BigQuery: 서버리스 분석 엔진
• Snowflake: 멀티클라우드 웨어하우스
• Apache Hive: Hadoop 기반 오픈소스 웨어하우스

장점과 한계

장점:

• 빠른 쿼리 성능 (사전 최적화)
• 높은 데이터 품질과 일관성
• SQL로 바로 분석 가능
• 거버넌스와 보안이 잘 지원됨

한계:

• 비정형 데이터(이미지, 로그, JSON) 저장 어려움
• ETL 파이프라인 구축/유지 비용이 큼
• 스키마 변경이 어렵다
• 저장 비용이 높다 (전용 스토리지)

데이터 레이크(Data Lake)

개념

데이터 레이크는 모든 형태의 데이터를 원본 그대로 저장하는 대규모 저장소이다. 구조화, 반구조화, 비정형 데이터를 모두 수용한다.

핵심 특성:

• Schema-on-Read: 데이터를 읽을 때 스키마를 적용한다. 저장 시에는 구조를 강제하지 않는다
• ELT: Extract → Load → Transform. 먼저 원본을 저장하고, 필요할 때 변환한다
• 다양한 포맷: Parquet, JSON, CSV, 이미지, 동영상 등 무엇이든 저장
• 저렴한 스토리지: 오브젝트 스토리지(S3, GCS, ADLS)를 사용하여 비용이 낮다

아키텍처

데이터 소스                Data Lake (S3/GCS)
──────────              ─────────────────────
DB          ─→  Raw Zone    (원본 그대로)
API 로그     ─→       ↓
IoT 센서     ─→  Curated Zone (정제/변환)
이미지/영상  ─→       ↓
             Analytics Zone (분석용 집계)

존(Zone) 으로 데이터 성숙도를 구분한다:

• Raw/Bronze Zone: 원본 데이터 그대로 저장
• Curated/Silver Zone: 정제, 중복 제거, 타입 변환이 완료된 데이터
• Analytics/Gold Zone: 비즈니스 로직이 적용된 분석용 데이터

장점과 한계

장점:

• 모든 형태의 데이터를 저장할 수 있다
• 저장 비용이 매우 낮다
• 스키마가 유연하다
• 머신러닝/AI 워크로드에 적합하다

한계:

• 데이터 늪(Data Swamp): 관리 없이 데이터만 쌓으면 쓸 수 없는 늪이 된다
• ACID 트랜잭션이 없다 (전통적 레이크)
• 쿼리 성능이 웨어하우스보다 느리다
• 데이터 품질 보장이 어렵다
• 거버넌스와 접근 제어가 복잡하다

데이터 레이크 vs 웨어하우스 비교

Lakehouse: 두 세계의 통합

등장 배경

실무에서는 웨어하우스와 레이크를 모두 운영하는 경우가 많았다. 원본은 레이크에, 분석용 데이터는 웨어하우스에 저장했다. 하지만 이 Two-tier 아키텍처는 문제가 있었다.

[데이터 소스] → [Data Lake] → ETL → [Data Warehouse] → [BI/분석]
                    ↓
              [ML 플랫폼]

• 데이터가 두 번 복사된다 (비용, 일관성 문제)
• 레이크와 웨어하우스 간 ETL 파이프라인 관리 부담
• 레이크의 데이터와 웨어하우스의 데이터가 불일치할 수 있다

Lakehouse란?

Lakehouse는 데이터 레이크의 저비용 스토리지와 데이터 웨어하우스의 관리 기능(ACID, 스키마, 성능) 을 결합한 아키텍처이다.

[데이터 소스] → [Lakehouse (S3/GCS + 테이블 포맷)] → [BI / ML / 분석]

핵심 기술은 오픈 테이블 포맷이다:

• Delta Lake: Databricks 주도. Spark 에코시스템과 깊은 통합
• Apache Iceberg: Netflix 개발. 벤더 중립적, 대규모 테이블에 최적화
• Apache Hudi: Uber 개발. 증분 처리(Incremental Processing)에 강점

오픈 테이블 포맷이 제공하는 것

이 포맷들은 Parquet 파일 위에 메타데이터 레이어를 추가하여 다음을 지원한다:

Iceberg 예시

-- Iceberg 테이블 생성
CREATE TABLE orders (
    id BIGINT,
    user_id STRING,
    amount DECIMAL(10,2),
    created_at TIMESTAMP
) USING iceberg
PARTITIONED BY (days(created_at));

-- MERGE (UPSERT)
MERGE INTO orders target
USING new_orders source
ON target.id = source.id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

-- 타임 트래블
SELECT * FROM orders VERSION AS OF 123456789;

-- 스키마 진화: 컬럼 추가
ALTER TABLE orders ADD COLUMN category STRING;

S3 위의 Parquet 파일이지만, 웨어하우스 수준의 기능을 사용할 수 있다.

아키텍처 선택 가이드

순수 웨어하우스가 적합한 경우

• BI/리포팅이 주 목적이다
• 정형 데이터만 다룬다
• SQL 분석가가 주 사용자이다
• 관리형 서비스(BigQuery, Snowflake)로 운영 부담을 최소화하고 싶다

순수 데이터 레이크가 적합한 경우

• 비정형 데이터(이미지, 로그)가 많다
• ML/AI 워크로드가 핵심이다
• 저장 비용이 중요하다
• 데이터 과학자가 주 사용자이다

Lakehouse가 적합한 경우

• BI와 ML을 모두 지원해야 한다
• 데이터 복사를 최소화하고 싶다
• 최신 기술 스택을 도입할 수 있다
• 벤더 독립적인 오픈소스를 선호한다

실무에서는 점점 더 많은 조직이 Lakehouse 방향으로 이동하고 있다. 특히 Iceberg의 채택이 빠르게 늘어나고 있으며, AWS, Google Cloud, Snowflake 등 주요 플랫폼이 모두 Iceberg를 지원하기 시작했다.

정리

• 데이터 웨어하우스는 정제된 정형 데이터를 SQL로 분석하는 데 최적화되어 있다
• 데이터 레이크는 모든 형태의 데이터를 저비용으로 저장하지만, 관리 기능이 부족하다
• Lakehouse는 오픈 테이블 포맷(Delta Lake, Iceberg, Hudi)으로 두 패러다임을 통합한다
• 오픈 테이블 포맷은 ACID 트랜잭션, 스키마 진화, 타임 트래블을 데이터 레이크에 제공한다
• 아키텍처 선택은 데이터 형태, 주 사용자, 워크로드에 따라 결정한다