쉬운 설명
전통적인 데이터 웨어하우스는 '미리 깔끔하게 정리된 표'를 저장합니다. 깨끗해서 분석엔 편하지만, 새 데이터 형태가 들어오려면 매번 스키마를 손봐야 하고, 영상·이미지·로그 원본 같은 비정형 데이터는 잘 안 어울립니다.
데이터 레이크는 그 제약을 뒤집습니다. 들어오는 데이터를 일단 원본 그대로 호수에 던져 두고, 나중에 누가 어떤 질문을 할지 정해지면 그때 가공해서 답합니다. 저장 비용이 싸고 형식 제약이 적어, 머신러닝·실험 분석에서 유연합니다.
구현은 보통 객체 스토리지(AWS S3·GCS·Azure Blob) 위에 메타데이터 카탈로그·접근 권한·쿼리 엔진을 얹는 형태입니다. Spark·Trino·Athena·Databricks 같은 도구가 호수에 저장된 원본 파일을 SQL로 직접 쿼리할 수 있게 해 줍니다. 데이터를 옮기지 않고 같은 자리에서 분석할 수 있다는 점이 매력입니다.
단점은 분명합니다. '뭐가 있는지'를 잃기 쉽습니다. 메타데이터·카탈로그·접근 권한을 관리하지 않으면 '데이터 늪(swamp)'이 됩니다. 또 원본 그대로라 데이터 품질이 들쭉날쭉해, 분석가가 매번 정리부터 시작해야 하는 일이 많습니다.
최근에는 레이크와 웨어하우스의 장점을 섞은 레이크하우스(lakehouse) 아키텍처가 흔합니다. 객체 스토리지에 데이터를 저장하면서, 그 위에 트랜잭션·스키마 진화·시간 여행 같은 웨어하우스 기능을 더해 줍니다. Delta Lake·Apache Iceberg·Apache Hudi가 대표 기술이고, Databricks·Snowflake가 이 흐름을 상품화하고 있습니다.
비유로 보면
웨어하우스가 잘 정리된 도서관이라면, 데이터 레이크는 거대한 보관 창고에 가깝습니다. 들어오는 물건을 일단 다 보관해 두고, 누가 찾을 때마다 그 자리에서 분류·정리해 꺼냅니다. 창고가 잘 정리돼 있지 않으면 '뭐가 어디 있는지' 모르는 늪이 되기 쉽습니다.
어디에서 만나나
머신러닝 학습용 원본 데이터 보관, 로그·이벤트 같은 반정형 데이터 분석, 영상·이미지 같은 비정형 데이터 저장, 사후 분석을 위해 일단 다 쌓아 두는 '데이터 백업+분석' 통합 영역. AWS·구글·Azure의 클라우드 데이터 플랫폼이 모두 레이크 또는 레이크하우스 형태를 표준으로 제시하고 있습니다.
작은 예시
이커머스 회사가 결제·로그·고객 음성 녹음·앱 클릭 이벤트를 모두 S3 같은 객체 저장소에 원본으로 쌓아 두고, 분석가가 필요할 때 Spark로 쿼리해서 'A 캠페인이 콜센터 문의를 늘렸나'를 살펴봅니다. 이 저장소가 데이터 레이크입니다.
자주 하는 오해
한 줄 정리
데이터 레이크는 '일단 다 받고, 나중에 정리한다'는 발상의 저장소입니다. 잘 관리되면 강력하지만, 거버넌스 없이는 비싼 늪이 됩니다.