데이터 레이크란 무엇인가 — 스키마 온 리드와 유연성의 대가
Data Lake vs Data Warehouse vs Lakehouse: A DE's Guide (2026) — DataVidhya (blog) What Is a Data Lake? / Where Data Lakes Work Really Well / Where Data Lakes Start to Break Down (pp.3-4)
이 모듈을 다 읽으면
- 데이터 레이크가 스키마 온 리드(schema-on-read) 방식을 택하는 이유를 설명할 수 있다
- 데이터 레이크가 유리한 상황과 데이터 스웜프(data swamp)로 전락하는 상황을 구분할 수 있다
데이터 레이크는 수집 시점에 구조를 강제하지 않고 원본 형태 그대로 데이터를 저장해, 활용 방식을 나중에 결정할 수 있게 하는 계층이다. 이 유연성은 탐색·백필·ML 피처 생성에는 강점이지만, 소유권과 규칙이 없으면 같은 데이터가 여러 형태로 중복되고 신뢰할 수 없는 데이터 스웜프로 전락한다.
스키마 온 리드 — 구조를 나중으로 미루는 설계
데이터 레이크는 데이터가 들어오는 시점에 형식이나 용도를 미리 정하지 않는다. JSON, CSV, Parquet 같은 원본 파일, 애플리케이션 로그, 이벤트 스트림, 클릭/센서 데이터, 미디어 파일까지 형태를 가리지 않고 저장할 수 있으며, 대개 S3·ADLS·GCS 같은 저비용 오브젝트 스토리지 위에 구축된다.
전통적인 데이터베이스가 저장 전에 구조를 강제하는 스키마 온 라이트(schema-on-write) 방식이라면, 데이터 레이크는 쿼리 시점에야 구조를 적용하는 스키마 온 리드(schema-on-read) 방식을 쓴다. 이 덕분에 팀은 나중에 바뀔 수도 있는 모델링 결정에 막혀 수집을 지연시키지 않고, 빠르게 대량의 데이터를 들여올 수 있다. 그래서 데이터 레이크는 대개 현대 데이터 플랫폼에서 빠르게 변하는 소스와 더 정제된 데이터가 필요한 다운스트림 시스템 사이의 버퍼 역할을 한다.
핵심 포인트
- 데이터 레이크는 스키마 온 리드 방식으로, 구조를 저장 시점이 아니라 쿼리 시점에 적용한다.
- 저비용 오브젝트 스토리지(S3, ADLS, GCS) 위에 원본 형태 그대로 데이터를 쌓아 후속 활용 방식을 열어둔다.
데이터 레이크가 잘 맞는 지점
데이터 레이크는 데이터가 아직 진화 중이고 질문이 완전히 정의되지 않은 단계에서 가장 강력하다. 다양한 소스에서 사전 모델링 없이 대량의 데이터를 수집하는 상황, 탐색·백필·실험을 지원해야 하는 상황, 머신러닝 파이프라인과 피처 생성 워크플로를 먹여 살려야 하는 상황이 대표적이다. 이 단계에서는 완성도보다 유연성이 더 중요하며, 데이터 레이크는 팀이 장기 구조에 커밋하기 전에 데이터를 먼저 이해할 여유를 준다.
핵심 포인트
- 사전 모델링 없는 대량 수집, 탐색/백필/실험, ML 피처 생성 워크플로에 데이터 레이크가 적합하다.
- 요구사항이 아직 불확실한 초기 단계에서는 완성도보다 유연성이 우선한다.
데이터 레이크가 무너지는 지점 — 데이터 스웜프
자유에는 책임이 따른다. 명확한 소유권과 규칙이 없으면 데이터 레이크는 서서히 데이터 스웜프(data swamp)로 전락한다. 같은 데이터셋이 서로 다른 포맷으로 여러 번 저장되고, 이름은 같지만 스키마가 조금씩 다른 파일들이 쌓이고, 실패한 잡 때문에 부분적으로만 쓰였거나 중복된 데이터가 남고, 디버깅 중에 무엇을 믿어야 할지 알 수 없는 상태가 된다. 이 지점에 이르면 데이터 엔지니어는 데이터를 활용하기보다 데이터를 설명하는 데 더 많은 시간을 쓰게 된다.
핵심 포인트
- 소유권과 컨벤션이 없으면 데이터 레이크는 데이터 스웜프로 전락한다 — 같은 데이터의 중복 저장, 미묘하게 다른 스키마, 실패한 잡의 잔여 데이터가 대표적 증상이다.
- 데이터 레이크는 유연성과 확장성을 주는 대신, 이를 유지하려면 규율과 명확한 컨벤션, 강한 거버넌스가 반드시 필요하다.