데이터 레이크, 스키마는 나중에 정해도 되는 이유
오브젝트 스토리지·스키마 온 리드·Delta/Iceberg/Hudi 테이블 레이어로 원본 데이터를 그대로 보존하며 ML·BI를 함께 지원하는 데이터 레이크 아키텍처를 정리한다
2026-08-12 · 최초 발행 2025-12-09
기업이 내·외부의 정형/반정형/비정형 데이터를 원형 그대로 수집·보관하면서, 페타바이트 규모까지 확장하고 머신러닝·딥러닝·시각화 워크로드를 일관되게 지원하려면 스키마를 먼저 정하지 않는 저장소가 필요하다. 데이터 레이크는 오브젝트 스토리지를 기반으로 모든 형태의 데이터를 스키마 온 리드(schema-on-read) 방식으로 저장하는 중앙 저장소다. 원천 데이터 보존을 전제로 Raw/Bronze, Curated/Silver, Served/Gold 같은 영역화된 레이어로 정제·관리하며, 컴퓨트와 스토리지를 분리하고 오픈 포맷(Parquet/ORC) 및 ACID 테이블 레이어(Delta/Iceberg/Hudi)로 거버넌스와 일관성을 확보하는 데이터 플랫폼이다.
존을 나누고, 포맷을 열어두고, 락을 건다
스토리지 레이어는 S3/GCS/ADLS 같은 페타바이트급 오브젝트 스토리지를 기반으로 비용 대비 용량 효율을 확보한다. Raw → Curated → Served 존을 분리해 수집·정제·서비스 단계별로 데이터 품질과 접근 제어를 나눈다.
메타데이터·카탈로그·거버넌스는 Glue/Unity/Atlas 같은 데이터 카탈로그로 스키마·라인리지·데이터 품질 메타데이터를 관리하고, RBAC/ABAC 보안 정책과 행/열 단위 마스킹, 공유·가명처리 정책을 일원화한다.
포맷·테이블 포맷·일관성 쪽에서는 Parquet/ORC 같은 컬럼 지향 포맷으로 압축·프루닝·벡터화 스캔을 최적화하고, Delta/Iceberg/Hudi로 스냅샷 격리·타임트래블·스키마 진화·옵티미스틱 락을 제공한다. 이 테이블 레이어가 스키마 온 리드의 최대 약점이던 일관성 문제를 상당 부분 메워준다.
컴퓨트 엔진과 쿼리 레이어는 Spark/Flink로 대규모 배치·스트리밍을 처리하고, Presto/Trino/Athena/BigQuery 외부 테이블로 대화형 분석을 지원한다. 머신러닝·딥러닝 파이프라인은 Feature Store와 연계해 학습·추론 자산을 재사용한다.
비용·운영·멀티클라우드 측면에서는 스토리지-컴퓨트 분리로 탄력적 스케일 아웃과 비활성 시간대 컴퓨트 비용 절감이 가능하고, 개방형 포맷과 표준 테이블 레이어로 벤더 종속성을 완화해 하이브리드·멀티클라우드 운영이 수월해진다.
데이터 흐름과 실패 처리
입력(내부 시스템, 외부 API/파일/이벤트) → 수집(배치/스트리밍) → 저장(Raw/Curated/Served) → 처리(Spark/SQL/ML) → 출력(BI/ML/서빙) 순으로 흐른다. 스키마 드리프트를 검출하고 품질 규칙 실패 시 격리·정정하는 재처리 큐를 운영하며, 테이블 레이어의 커밋 로그 기반 스냅샷 격리와 옵티미스틱 동시성 제어, 메타데이터 GC 주기화로 트랜잭션 일관성을 관리한다.
실무에서는 이렇게 쓴다
고객 360/퍼스널라이제이션은 웹/앱 이벤트, CRM, CS 로그를 통합해 세그먼트·피처를 추출하고 실시간 추천·캠페인 최적화 파이프라인을 돌린다. 예측 정비/IoT 분석은 센서 스트리밍 데이터를 수집해 피처 엔지니어링 후 이상탐지 모델을 학습시키고 장비 단위 서빙·경보 시스템과 연동한다. 로그 분석·보안 분석은 애플리케이션·네트워크 로그를 중앙화해 규칙과 ML 기반으로 탐지하고, 장기 보관으로 컴플라이언스 대응과 포렌식 조회를 지원한다. 생성형 AI 데이터셋 관리는 문서·이미지·오디오 원천을 보관하며 데이터 정합성·라이선스 메타데이터를 관리하고 필터링/디덥/라벨링 파이프라인과 학습 아티팩트 버저닝을 운영한다. 데이터 공유/클린룸은 파트너사와 열/행 수준 접근 제어 기반으로 안전하게 조인·분석하고, 감사 추적과 정책 기반 사용량 청구 모델을 연계한다.
레이크 vs 웨어하우스 vs 레이크하우스
| 항목 | 데이터 레이크 | 데이터 웨어하우스 | 레이크하우스 |
|---|---|---|---|
| 성능 | 대화형 SQL은 엔진·캐시 의존, 대규모 스캔 지향 | MPP 최적화, 일관된 대화형 성능 | ACID 테이블+인덱싱/캐시로 혼합 워크로드 우수 |
| 확장성 | 오브젝트 스토리지로 페타바이트+ 수평 확장 | 스토리지-컴퓨트 결합 시 확장 제약 | 스토리지-컴퓨트 분리, 자동 스케일 |
| 일관성 | 스키마 온 리드, ACID 계층 도입 시 개선 | 스키마 온 라이트, 강한 일관성 | 스키마 온 라이트+온 리드 혼용, 스냅샷 격리 |
| 안정성 | 포맷/메타 관리 품질에 좌우 | 벤더 관리로 높은 안정성 | 오픈 포맷+관리 기능 결합 |
| 운영 편의 | 유연하나 거버넌스 설계 필수 | 규칙·툴 표준화 용이 | 유연성+표준화 균형 |
파이프라인을 코드로 보면
입력 단계에서는 RDBMS CDC, API, 파일, 이벤트 로그를 소스로 삼고 스키마 유효성·품질 규칙(누락/범위/중복)·PII를 검증한다. 처리 단계는 Raw 존에 스키마 온 리드로 원천을 적재한 뒤 표준화·조인·집계를 거쳐 품질 마크다운과 라인리지를 기록하고, 테이블 레이어에 단일 커밋으로 스냅샷을 교체하며 옵티미스틱 충돌을 해결한다. 출력 단계는 BI 데이터셋·큐브, 피처 스토어 등록, 모델 아티팩트 저장으로 이어지고, 실패 시 DLQ(Dead Letter Queue)와 재처리 파이프라인, 알림·사후 분석 보고로 대응한다.
아래는 Spark 3.4+, Hadoop AWS 커넥터, IAM 권한, Delta Lake 2.x 환경에서 JSON 원천을 Parquet으로 변환해 Delta 테이블에 커밋하고 대화형 SQL로 조회하는 예시다.
# pyspark --packages io.delta:delta-spark_2.12:2.4.0,org.apache.hadoop:hadoop-aws:3.3.4
from pyspark.sql import SparkSession
spark = (SparkSession.builder
.appName("lake-ingestion")
.config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension")
.config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog")
.getOrCreate())
raw_path = "s3://my-bucket/raw/events/2025-12-01/"
delta_path = "s3://my-bucket/curated/events_delta/"
df = spark.read.json(raw_path)
# 품질 규칙 예: 필수 컬럼 필터링
df_clean = df.filter("event_id IS NOT NULL AND ts IS NOT NULL")
# 파티션 예: 날짜 파티션, 소파일 방지 위해 coalesce
(df_clean
.coalesce(16)
.write
.format("delta")
.mode("append")
.partitionBy("event_date")
.save(delta_path))
# 타임트래블/스냅샷 조회
spark.read.format("delta").load(delta_path).createOrReplaceTempView("events")
spark.sql("""
SELECT event_date, event_type, count(*) AS cnt
FROM events
GROUP BY event_date, event_type
ORDER BY event_date DESC, cnt DESC
""").show(20, truncate=False)소파일이 쌓이면 OPTIMIZE/COMPACT를 주기적으로 돌리고, VACUUM으로 오래된 스냅샷을 정리하며, 처리량·지연·에러율 메트릭을 모니터링한다.
유연함의 대가와 보상
포맷·파일 관리는 Parquet을 기본으로 컬럼형 압축(ZSTD/Snappy), 파티션+클러스터링, 소파일 컴팩션 배치 운영이 모범사례지만, 과도한 파티션 분할은 메타데이터 폭증과 컴팩션 비용 증가로 돌아온다. 테이블 레이어는 Delta/Iceberg/Hudi 중 조직 표준을 정해 타임트래블·청크 머지·VACUUM 정책을 세워야 하는데, 기능·커뮤니티 성숙도·엔진 호환성 차이만큼 관리 복잡도도 늘어난다. 스트리밍과 배치는 CDC·이벤트는 스트리밍으로, 집약 계산은 마이크로배치로 혼용하며 멱등·Exactly-once를 설계해야 하지만 지연 최적화와 비용, 상태 저장 스트리밍의 운영 난이도 사이에서 저울질이 필요하다. 거버넌스·보안은 IAM 최소 권한, 분류·민감도 태깅, 컬럼/행 수준 마스킹, 전송/저장 암호화, 감사 로깅이 기본이지만 세분화된 정책은 쿼리 성능을 떨어뜨릴 수 있다. 비용 최적화는 수명주기 정책과 스토리지 클래스 티어링으로 이뤄지지만, 과도한 티어링은 콜드에서 핫으로 복구할 때 지연을 키운다.
숫자로 보는 효과
오브젝트 스토리지 단가와 콜드 티어링을 활용하면 데이터 웨어하우스 대비 3070% 저장 비용 절감이 가능하다(워크로드·지역·티어에 따라 변동). 스토리지-컴퓨트 분리로 비활성 시간대 컴퓨트 비용도 줄어든다. 신규 데이터 소스 온보딩 리드타임은 50% 이상 단축되고, 스키마 온 리드 덕분에 초기 모델링 부담도 줄어든다. 컬럼형 포맷·프루닝·캐시를 결합하면 대규모 스캔 성능이 10100배 I/O 절감 사례로 보고되며, ACID 테이블로 일관성과 타임트래블을 확보해 재현 가능한 분석·학습 파이프라인을 만들 수 있다. ML/DL 학습용 대용량 데이터셋을 안정적으로 공급하고 피처 스토어를 재사용하면서 BI·대화형 분석과 공존하는 셀프서비스 문화도 함께 자리 잡는다.
결국 데이터 레이크는 모든 형태의 원천 데이터를 장기 보존하면서 페타바이트급 확장성과 유연한 처리 엔진으로 분석·ML/DL·시각화를 단일 플랫폼에서 실행하는 기반 아키텍처다. 오픈 포맷과 ACID 테이블 레이어, 견고한 거버넌스·보안 체계를 결합한 레이크하우스 지향 설계가 실무 적용의 방향이다.