데이터 레이크 vs. 클라우드 데이터 웨어하우스: 데이터 사이언티스트를 위한 실무 가이드

데이터 레이크는 저비용 클라우드 오브젝트 스토리지를 사용하여 정형, 반정형, 비정형 등 원래 형식 그대로의 원시 데이터를 저장하는 중앙 저장소입니다. 데이터를 로드하기 전에 사전 정의된 스키마를 적용해야 하는 클라우드 데이터 웨어하우스와 달리, 데이터 레이크는 데이터를 읽을 때만 구조를 적용하므로 데이터 사이언티스트와 데이터 엔지니어가 사전에 데이터를 변환하지 않고도 다양한 데이터 유형을 유연하게 다룰 수 있도록 지원합니다. 두 아키텍처 모두 클라우드 인프라를 기반으로 하지만, 대규모 데이터를 수집, 처리, 검색하는 방법에 대해 근본적으로 다른 해결책을 제시합니다.

이 가이드는 특정 업체의 홍보가 아닌, 실질적인 의사결정 프레임워크가 필요한 데이터 사이언티스트, 데이터 엔지니어, 분석 리더를 위해 작성되었습니다. 이 가이드를 읽고 나면 데이터 레이크와 클라우드 데이터 웨어하우스의 핵심 차이점, 데이터 레이크하우스가 그 격차를 좁히는 시점, 그리고 특정 워크로드에 맞는 적절한 데이터 스토리지 아키텍처를 선택하는 방법을 이해하게 될 것입니다.

추천 요약

자세한 작동 원리를 알아보기 전에, 대부분의 팀에 먼저 필요한 실질적인 가이드를 소개합니다.

머신러닝, 데이터 사이언스 또는 아직 정의되지 않은 미래의 분석 사용 사례를 위해 페타바이트 규모의 다양한 형식의 원시 데이터를 저장하는 것이 주된 목적인 경우 데이터 레이크를 선택하세요. 데이터 레이크는 클라우드 데이터 웨어하우스보다 기가바이트당 비용이 저렴하여 뛰어난 확장성을 제공하며, 수집 전에 스키마를 정의할 필요 없이 모든 데이터 유형을 지원합니다.

대시보드, 재무 보고서, 고객 계정 명세서, 운영 분석 등 낮은 쿼리 대기 시간과 높은 동시성이 스토리지 유연성보다 더 중요한 정형 비즈니스 데이터에 대한 빠르고 동시성 높은 SQL 쿼리가 워크로드의 중심일 때는 클라우드 데이터 웨어하우스를 선택하세요.

조직에서 머신러닝과 비즈니스 인텔리전스(BI) 워크로드를 모두 실행하고 레이크와 웨어하우스 간의 데이터 중복을 제거하는 통합 플랫폼이 필요한 경우 데이터 레이크하우스를 선택하세요. 레이크하우스는 레이크 스토리지에서 직접 ACID 트랜잭션을 지원하므로 대부분의 현대적인 데이터 플랫폼에서 실질적인 기본 선택지가 됩니다.

데이터 레이크란 무엇인가요?

데이터 레이크는 분석에 필요할 때까지 모든 데이터(정형, 반정형, 비정형)를 원래의 원시 형식 그대로 저장하도록 설계된 중앙 저장소입니다. 데이터 레이크는 기존의 관계형 데이터베이스와 데이터 웨어하우스가 경제적으로 수용할 수 없었던 비정형 데이터 스토리지 수요의 폭발적인 증가를 해결하기 위해 특별히 등장했습니다.

데이터 레이크의 가장 큰 특징은 Extract, Load, Transform (ELT) 방법론을 사용하여 데이터를 즉시 수집하고, 쓰기 시 스키마(schema-on-write) 대신 읽기 시 스키마(schema-on-read)를 적용한다는 점입니다. 즉, 데이터 엔지니어는 데이터가 어떻게 쿼리될지 먼저 정의하지 않고도 로그 파일, JSON 이벤트, 이미지, 비디오, 센서 스트림, 데이터베이스 테이블을 동일한 시스템에 수집할 수 있습니다. 데이터 사이언티스트는 어떤 형식으로든 도달한 가공되지 않은 원시 데이터에 직접 액세스할 수 있으며, 이는 피처 엔지니어링 및 머신러닝 모델 개발에 필수적입니다.

클라우드 데이터 레이크는 일반적으로 사실상 무제한의 용량을 제공하는 오브젝트 스토리지 서비스인 Amazon S3, Azure Data Lake Storage (ADLS), Google Cloud Storage에서 실행됩니다. 데이터 레이크는 고정된 제한 없이 페타바이트 규모의 정보를 저장할 수 있으며, 기가바이트당 비용은 기존 데이터 웨어하우스에서 사용하는 독점 스토리지보다 훨씬 저렴합니다. 기가바이트당 비용이 저렴하면서도 이러한 확장성을 제공하므로 데이터 레이크는 용량이 가장 중요한 빅데이터 스토리지를 위한 실질적인 선택이 됩니다.

데이터 레이크는 정형 데이터베이스 내보내기, JSON 및 Parquet와 같은 반정형 형식, 텍스트 코퍼스, 오디오, 이미지와 같은 완전한 비정형 콘텐츠를 포함한 모든 데이터 유형을 지원합니다. 이러한 다양성 덕분에 데이터 레이크는 수집 시점에 아직 정의되지 않은 사용 사례를 포함하여 향후 분석을 위해 원시 데이터를 보존해야 하는 모든 조직에 자연스러운 랜딩 존이 됩니다.

클라우드 데이터 웨어하우스 및 관계형 데이터베이스 컨텍스트

클라우드 데이터 웨어하우스는 정형화되고 비즈니스에 바로 사용할 수 있는 데이터에 대한 동시성 높은 SQL 쿼리에 최적화된 관리형 분석 데이터베이스입니다. 실시간으로 개별 행을 삽입하고 업데이트하는 트랜잭션 워크로드용으로 설계된 관계형 데이터베이스와 달리, 클라우드 데이터 웨어하우스는 대량의 기록 데이터를 스캔하여 집계, 보고서, 대시보드를 생성하는 분석 워크로드용으로 구축되었습니다.

클라우드 데이터 웨어하우스는 쓰기 시 스키마(schema-on-write) 모델을 적용합니다. 즉, 데이터를 로드하기 전에 정리하고 유형을 지정하고 사전 정의된 스키마에 맞춰야 합니다. 이러한 제약 조건은 웨어하우스의 가장 큰 장점이자 가장 큰 한계이기도 합니다. 모든 테이블의 모든 행이 알려진 구조를 따르기 때문에 열 지향(columnar) 스토리지 및 쿼리 가속화 기술(조건절 푸시다운, 존 맵, 결과 캐싱)을 적극적으로 적용할 수 있어, 비즈니스 사용자와 데이터 분석가가 대시보드에서 기대하는 1초 미만의 쿼리 성능을 제공합니다.

Amazon Redshift, Google BigQuery, Snowflake, Databricks Lakehouse를 비롯한 주요 클라우드 데이터 웨어하우스 제공업체는 컴퓨팅과 스토리지를 분리하여 저장된 데이터와 무관하게 쿼리 용량을 독립적으로 확장할 수 있도록 했습니다. 이 아키텍처는 수백 명의 사용자가 충돌 없이 동시에 쿼리를 실행하는 고동시성 워크로드를 지원합니다. 매출 보고, 고객 계정 명세서, 재고 분석과 같은 비즈니스 인텔리전스(BI) 사용 사례의 경우 쿼리 성능과 데이터 일관성이 타협할 수 없는 요소이기 때문에 클라우드 데이터 웨어하우스가 여전히 주된 선택지로 남아 있습니다.

클라우드 데이터 웨어하우스가 어려움을 겪는 부분은 관계형 모델에 맞지 않는 데이터 유형인 비정형 텍스트, 원시 센서 스트림, 이미지 임베딩, 반정형 이벤트 로그 등입니다. 이러한 데이터를 웨어하우스에 로드하려면 상당한 변환 작업이 필요하며, 스키마에 맞추기 위해 데이터를 폐기하거나 근사치로 처리해야 하는 경우가 많아 머신러닝 워크로드에 필요한 데이터의 완전성을 저해합니다.

데이터 레이크 아키텍처 및 스토리지 솔루션

데이터 레이크 아키텍처는 일반적으로 세 개의 영역으로 구성되며, 각 영역은 점진적으로 더 높은 수준의 데이터 품질과 비즈니스 준비 상태를 나타냅니다.

원시 영역 (브론즈 레이어)

원시 영역은 외부 소스 시스템에서 수집된 데이터가 처음 도달하는 랜딩 영역입니다. 데이터는 데이터베이스 내보내기, API 응답, 스트리밍 이벤트, 플랫 파일 등 원래 형식 그대로 도달하며, 최소한의 변환만 거쳐 오브젝트 스토리지에 기록됩니다. 목표는 정확성(fidelity)입니다. 즉, 다운스트림 로직이 변경될 경우 전체 파이프라인을 처음부터 다시 실행할 수 있도록 원본 레코드를 보존하는 것입니다. 메타데이터, 로드 타임스탬프, 소스 식별자가 추가되지만 데이터 자체는 수정되지 않습니다.

정제 영역 (실버 레이어)

정제 영역에서는 원시 데이터를 매칭, 병합 및 조정하여 통합된 기업 뷰로 만듭니다. 데이터 품질 검사가 적용되고, 중복 레코드가 해결되며, 여러 소스의 데이터가 고객, 트랜잭션, 제품과 같은 일관된 엔티티로 결합됩니다. 이 레이어는 다운스트림 소비자에게 가공되지 않은 원시 데이터를 노출하지 않고 탐색적 분석, 애드혹 보고 및 데이터 사이언스 실험을 지원합니다.

큐레이션 영역 (골드 레이어)

큐레이션 영역에는 대시보드, 운영 분석, 머신러닝 모델에서 바로 사용할 수 있는 프로덕션 등급의 비즈니스 수준 집계 데이터가 포함되어 있습니다. 이 레이어의 데이터는 모든 품질 검증 단계를 통과했으며, 고성능 쿼리를 지원하는 스타 스키마, 와이드 테이블, 사전 집계된 메트릭 등 바로 사용할 수 있는 구조로 구성되어 있습니다. 브론즈, 실버, 골드를 고유한 파이프라인 단계로 공식화하는 메달리온 아키텍처는 데이터 레이크 아키텍처를 구성하는 데 가장 널리 채택되는 패턴입니다.

오브젝트 스토리지는 세 가지 영역 모두의 기반입니다. Apache Parquet 및 Apache ORC와 같은 형식은 스토리지 공간을 줄이고 분석 스캔을 가속화하는 열 지향 인코딩을 제공합니다. 오픈 형식은 특정 공급업체의 처리 엔진에서 데이터를 분리하므로 복사하지 않고도 여러 도구에서 동일한 파일을 쿼리할 수 있습니다.

데이터 스토리지 비용 및 확장성

현대적인 아키텍처는 스토리지와 컴퓨팅을 분리하므로 데이터 레이크와 클라우드 데이터 웨어하우스 간의 비용 비교 시 두 요소를 모두 개별적으로 고려해야 합니다.

클라우드 오브젝트 스토리지 티어의 데이터 레이크 스토리지는 독점 웨어하우스 스토리지보다 훨씬 저렴하며, 기가바이트당 원시 가격 기준으로 종종 수십 배 더 저렴합니다. 쿼리 빈도가 낮은 대량의 원시 데이터 또는 기록 데이터를 저장하는 조직의 경우, 콜드 스토리지 티어(Amazon S3 Glacier, Azure Archive)를 사용하면 검색 대기 시간은 길어지지만 비용을 더욱 절감할 수 있습니다. 데이터 레이크가 데이터 웨어하우스보다 비용 효율적인 이유는 오브젝트 스토리지가 쿼리 성능이 아닌 내구성과 확장성을 위해 설계되었기 때문입니다.

클라우드 데이터 웨어하우스는 쿼리당 또는 컴퓨팅 단위당 요금제를 적용하므로 정기적이고 가치가 높은 워크로드에는 비용 효율적이지만, 대규모 데이터 세트에 대한 애드혹 또는 탐색적 쿼리에는 비용이 많이 들 수 있습니다. 현대적인 클라우드 데이터 웨어하우스의 종량제 요금제(고정된 클러스터 크기가 아닌 실행된 쿼리에 대해 비용 지불)가 도움이 되지만, 처리된 데이터 테라바이트당 비용은 여전히 레이크 스토리지보다 훨씬 높습니다.

실질적인 의미는 데이터 스토리지 아키텍처 결정이 양자택일인 경우가 거의 없다는 점입니다. 많은 조직이 비용 효율성을 위해 모든 데이터를 레이크에 저장한 다음, 동시성이 높은 BI를 위해 정제된 데이터 세트를 선택적으로 웨어하우스로 이동합니다. 레이크와 웨어하우스에 각각 하나씩 두 개의 복사본을 유지하는 데 드는 중복 비용이 레이크하우스 도입의 가장 큰 원인입니다.

데이터 과학자를 위한 머신러닝 및 고급 분석

데이터 레이크는 머신러닝을 위해 구축되었습니다. 원시 데이터를 원래 형식 그대로 저장할 수 있으므로 데이터 과학자는 사전 집계되거나 스키마 제한이 있는 하위 세트가 아닌, 과거 데이터의 완전한 원본에 액세스할 수 있으며, 이는 고품질 모델을 학습시키는 데 필수적입니다.

머신러닝을 위한 피처 엔지니어링에는 다양한 데이터 유형에 걸친 반복적이고 탐색적인 변환이 필요합니다. 이상 거래 탐지 모델을 학습시키는 데이터 과학자에게는 원시 거래 로그, 기기 지문 데이터, 행동 시퀀스, 계정 이력이 필요하며, 이들 대부분은 관계형 스키마에 깔끔하게 들어맞지 않습니다. 데이터 레이크는 ML 파이프라인에 필요한 원시 형식을 보존하면서 다양한 애플리케이션 간에 핵심 데이터 일관성을 제공합니다.

데이터 레이크는 데이터 과학 및 고급 분석 도구와 네이티브로 통합됩니다. Apache Spark는 대규모 분산 ML의 사실상 표준이며, 개방형 형식을 사용하여 오브젝트 스토리지에서 직접 읽습니다. 모델 학습에 사용되는 Python 라이브러리(PyTorch, TensorFlow, scikit-learn)는 동일한 S3 호환 API를 통해 레이크 스토리지에 액세스합니다. 데이터 엔지니어는 데이터를 별도의 시스템으로 이동하지 않고도 실시간 피처를 모델에 공급하는 스트리밍 데이터 파이프라인을 실행할 수 있습니다.

클라우드 데이터 웨어하우스는 주로 추론 및 스코어링 단계에서 ML 워크플로우에 기여합니다. 모델이 학습되면 구조화된 웨어하우스 테이블에 대한 운영 스코어링(고객 테이블에서 이탈 예측 실행, CRM 내보내기에서 리드 스코어링 등)은 웨어하우스의 인덱싱 및 쿼리 최적화의 이점을 누릴 수 있습니다. 성숙한 ML 아키텍처는 피처 스토어를 경계에 둡니다. 즉, 원시 피처 계산은 레이크에서 발생하고, 서빙 준비가 완료된 피처 테이블은 웨어하우스와 모델 서빙 레이어 모두에서 액세스할 수 있는 형식으로 구체화됩니다.

데이터 분석 및 BI 워크로드

비즈니스 인텔리전스 워크로드(대시보드, 예약된 보고서, 비즈니스 분석가의 임의 쿼리)는 머신러닝과 근본적으로 다른 요구사항을 가집니다. BI 사용자는 낮은 대기 시간의 응답(대시보드 로드에 1초 미만), 동시 사용자 간의 일관된 결과, 원시 소스 값이 아닌 합의된 비즈니스 정의를 반영하는 데이터를 필요로 합니다.

클라우드 데이터 웨어하우스는 이러한 요구사항에 맞게 목적 기반으로 구축되었습니다. 열 지향 스토리지, 결과 캐싱, 구체화된 뷰를 통해 데이터가 증가하더라도 일반적인 대시보드 쿼리가 수 밀리초 내에 반환됩니다. 세분화된 액세스 제어를 통해 데이터 분석가는 다른 부서의 민감한 레코드를 노출하지 않고도 해당 부서의 데이터를 쿼리할 수 있습니다. 비즈니스 사용자는 기본 데이터 스토리지 옵션이나 파일 형식을 이해하지 않고도 구조화된 테이블에 대해 SQL을 직접 실행할 수 있습니다.

데이터 레이크는 SQL 쿼리 엔진(Apache Hive, Presto, Trino, Spark SQL)을 통해 BI 워크로드를 지원할 수 있지만, 기존에는 목적 기반 웨어하우스에 비해 쿼리 성능이 떨어졌습니다. 읽기 시 스키마(schema-on-read)의 유연성에는 높은 동시성 환경에서 두드러지는 쿼리 계획 오버헤드가 수반됩니다. 실시간 대시보드 및 높은 동시성의 비즈니스 인텔리전스를 위해서는 클라우드 데이터 웨어하우스나 고성능 SQL 레이어가 있는 레이크하우스가 적절한 선택입니다.

실시간 대시보드를 위한 스트리밍 데이터(센서 판독값, 웹사이트 클릭스트림, 결제 이벤트)가 점점 더 보편화되고 있습니다. 데이터 레이크와 클라우드 데이터 웨어하우스 모두 Kafka, Kinesis 및 유사한 시스템에 대한 커넥터를 통해 스트리밍 수집을 지원하지만, 스키마 제약이 없는 스트리밍 데이터 파이프라인에 대한 레이크의 지원 덕분에 고속의 가변 스키마 이벤트 스트림을 수집하는 데 더 자연스러운 랜딩 존이 됩니다.

주요 차이점: 레이크 vs. 클라우드 데이터 웨어하우스

다음 비교는 아키텍처 결정에서 가장 중요한 요소를 다룹니다.

스키마 모델

데이터 레이크는 읽기 시 스키마(schema-on-read) 방식을 사용합니다. 즉, 데이터가 기록될 때가 아니라 쿼리될 때 구조가 적용됩니다. 사전 설계 없이도 모든 데이터 유형을 즉시 수집할 수 있습니다. 클라우드 데이터 웨어하우스는 쓰기 시 스키마(schema-on-write) 방식을 요구합니다. 데이터는 로드하기 전에 미리 정의된 구조를 따라야 하므로, 데이터 품질은 보장되지만 수집이 느려지고 유연성이 제한됩니다. 이러한 차이로 인해 아래의 다른 대부분의 차이점이 발생합니다.

쿼리 성능

클라우드 데이터 웨어하우스는 구조화된 SQL 기반 워크로드, 특히 높은 동시성 환경에서 우수한 쿼리 성능을 제공합니다. 목적 기반 열 지향 엔진, 지능형 캐싱, 쿼리 컴파일 최적화 덕분에 일반적인 BI 패턴에 대해 1초 미만의 응답 속도를 제공합니다. 기존 데이터 레이크 쿼리 엔진은 동시 SQL의 경우 더 느리지만, 현대적인 벡터화 엔진을 통해 크게 개선되었습니다. 데이터 레이크는 웨어하우스 컴퓨팅 비용이 엄청나게 비쌀 수 있는 대규모 배치 처리 및 ML 학습 워크로드에서 여전히 더 빠릅니다.

데이터 거버넌스 및 정제 성숙도

클라우드 데이터 웨어하우스는 테이블 수준 및 열 수준 액세스 제어, 감사 로깅, 데이터 계보 추적, 강제 데이터 유형 등 더 성숙한 내장 거버넌스 기능을 표준으로 제공합니다. 기존 데이터 레이크는 동등한 수준의 거버넌스 성숙도에 도달하기 위해 데이터 카탈로그, 메타데이터 관리 레이어, 외부 액세스 제어 시스템과 같은 추가 도구가 필요합니다. Unity Catalog와 같은 카탈로그 서비스를 통해 격차가 크게 줄어들었지만, 엄격한 규정 준수 요구사항이 있는 조직의 경우 여전히 웨어하우스가 우위에 있습니다.

테라바이트당 비용

데이터 레이크는 클라우드 데이터 웨어하우스보다 테라바이트당 비용이 훨씬 저렴하며, 스토리지 계층과 쿼리 빈도에 따라 종종 10~100배 더 저렴합니다. 대용량 데이터, 과거 데이터, 원시 수집의 경우 레이크의 비용 우위가 결정적입니다. 정제되고 자주 쿼리되는 비즈니스 데이터의 경우 웨어하우스의 성능이 더 높은 비용을 정당화합니다.

지원되는 데이터 유형 및 형식

데이터 레이크는 구조화된 관계형 내보내기, 반구조화된 JSON 및 XML, 비구조화된 텍스트, 이미지, 오디오, 바이너리 파일 등 모든 데이터 유형을 지원합니다. 웨어하우스는 데이터베이스 테이블에 저장된 구조화된 데이터에 최적화되어 있으며, 비구조화 및 반구조화 데이터에 대한 네이티브 지원은 제한적이거나 제공되지 않습니다. 금융 거래 및 이미지 메타데이터와 함께 로그 파일을 저장하는 등 다양한 데이터를 저장하는 것이 레이크의 주요 사용 사례입니다.

주요 사용자 페르소나

데이터 엔지니어와 데이터 과학자는 데이터 레이크 환경의 주요 사용자입니다. 이들은 파이프라인 개발 및 모델 학습을 위해 원래 형식의 모든 데이터에 대한 원시 액세스가 필요합니다. 데이터 분석가와 비즈니스 사용자는 클라우드 데이터 웨어하우스의 주요 소비자입니다. 이들은 SQL 쿼리 및 보고를 위해 깨끗하고 신뢰할 수 있으며 신속하게 응답하는 데이터가 필요합니다. 데이터 레이크하우스는 단일 플랫폼에서 두 페르소나를 모두 지원하므로 빠르게 도입되고 있는 가장 큰 이유입니다.

데이터 레이크하우스: 레이크와 웨어하우스의 가교 역할

데이터 레이크하우스는 단일 통합 시스템에서 데이터 레이크의 저비용 및 유연한 스토리지와 데이터 웨어하우스의 데이터 관리 기능 및 쿼리 성능을 결합한 데이터 플랫폼 아키텍처입니다. 레이크하우스는 두 시스템 아키텍처에서 가장 비용이 많이 드는 운영 비용인 웨어하우스에 정제된 데이터의 별도 복사본을 유지하는 문제를 해결합니다.

트랜잭션 스토리지 레이어가 핵심 혁신입니다. 개방형 테이블 형식인 Delta Lake, Apache Iceberg, Apache Hudi는 오브젝트 스토리지에 직접 ACID 트랜잭션 지원을 추가합니다. ACID 트랜잭션은 모든 쓰기 작업이 완전히 성공하거나 완전히 롤백되도록 보장하여 동시 쓰기로 인한 데이터 손상을 방지합니다. 데이터 웨어하우스가 수십 년 동안 제공해 온 이 보장 기능은 과거 데이터 레이크에서는 사용할 수 없었습니다. 레이크하우스는 레이크의 개방형 형식과 비용 구조를 유지하면서 데이터 신뢰성을 위한 ACID 트랜잭션 지원을 제공합니다.

Delta Lake는 가장 널리 채택된 레이크하우스 테이블 형식입니다. 클라우드 오브젝트 스토리지의 Parquet 파일에 데이터를 저장하고 모든 스키마 변경, 삽입, 업데이트, 삭제를 기록하는 트랜잭션 로그를 유지합니다. SQL에서 쿼리할 수 있는 Time Travel 기능을 통해 데이터 과학자와 감사자는 테이블의 모든 과거 스냅샷을 읽을 수 있습니다. 자동 파일 압축 및 데이터 건너뛰기 인덱스는 수동 튜닝 없이도 쿼리 성능을 가속화합니다. Delta Lake는 오픈 소스이고 클라우드에 구애받지 않으며 Apache Spark 및 SQL 엔진과 기본적으로 통합되기 때문에 레이크하우스 아키텍처에서 흔히 사용되는 기술입니다.

Apache Iceberg 및 Apache Hudi는 서로 다른 설계 절충안을 통해 유사한 기능을 제공합니다. Iceberg는 복잡한 분석 워크로드를 위해 더 강력한 스키마 진화 및 숨겨진 파티셔닝을 제공합니다. Hudi는 레코드 수준의 업서트(upsert) 및 스트리밍 수집 패턴을 전문으로 합니다. 세 가지 형식 모두 Apache XTable과 같은 개방형 표준을 통해 상호 운용성이 점점 더 높아지고 있습니다.

2025년까지 레이크하우스는 레이크와 웨어하우스를 동기화하는 대신 하나의 플랫폼을 관리하는 운영상의 단순성에 힘입어 엔터프라이즈 분석 워크로드의 절반 이상을 차지할 것입니다. 새로운 데이터 플랫폼을 구축하는 조직의 경우 레이크하우스가 실질적인 기본 선택지입니다.

관계형 데이터베이스 및 데이터 마트와의 통합 패턴

다른 시스템과 비교하여 데이터 레이크와 클라우드 데이터 웨어하우스가 어디에 위치하는지 이해하면 각각을 언제 사용해야 하는지 명확해집니다.

온라인 트랜잭션 처리(OLTP) 관계형 데이터베이스(MySQL, PostgreSQL, Oracle)는 운영 애플리케이션을 위한 원천 시스템(system of record)으로 계속 사용되고 있습니다. 이 데이터베이스는 주문 관리, 재고 추적, 사용자 인증 등 쓰기 작업이 많은 트랜잭션 워크로드에 최적화되어 있습니다. 쿼리 부하가 애플리케이션 트랜잭션과 경합하기 때문에 분석 워크로드를 OLTP 데이터베이스에서 직접 실행해서는 안 됩니다. 표준 패턴은 운영 성능에 영향을 주지 않으면서 소스 데이터베이스의 행 수준 변경 사항을 이벤트로 스트리밍하는 기술인 CDC(Change Data Capture)를 통해 OLTP 데이터를 레이크나 웨어하우스로 복제하는 것입니다.

데이터 마트는 재무, 마케팅, 공급망 등 특정 비즈니스 기능을 위해 구성된 더 큰 데이터 웨어하우스 또는 레이크의 주제별 하위 집합입니다. 데이터 마트는 비즈니스 분석가가 전체 엔터프라이즈 데이터 모델을 이해하지 않고도 쿼리할 수 있도록 정제되고 미리 조인된 데이터 세트를 제공합니다. 데이터 마트는 부서마다 거버넌스 요구사항이 다르거나 성능을 위해 쿼리 격리가 필요한 조직에서 여전히 유용합니다. 레이크하우스 아키텍처에서 Gold 레이어 테이블은 별도의 물리적 시스템 없이도 데이터 마트 기능을 효과적으로 수행합니다.

ETL(Extract, Transform, Load)은 쓰기 시 스키마(schema-on-write) 시스템에 데이터를 로드하는 데 적합한 패턴입니다. 데이터가 웨어하우스에 들어가기 전에 변환이 적용되므로 대상 스키마와의 호환성이 보장됩니다. ELT(Extract, Load, Transform)는 읽기 시 스키마(schema-on-read) 시스템에 적합한 패턴입니다. 원시 데이터가 먼저 레이크에 저장된 다음, 쿼리 시점이나 파이프라인 단계에서 변환이 적용됩니다. 대부분의 현대적인 데이터 플랫폼은 레이크 수집에 ELT를 사용한 다음, ETL 방식의 정제를 적용하여 Gold 레이어 테이블을 생성합니다.

보안, 거버넌스 및 규정 준수

클라우드 데이터 레이크의 데이터 거버넌스에는 웨어하우스 시스템이 기본적으로 제공하는 명시적인 투자가 필요합니다.

권한이 없는 사용자가 오브젝트 스토리지의 원시 데이터를 읽지 못하도록 파일 수준에서 액세스를 제어하는 것이 가장 기본적인 요구사항입니다. 클라우드 제공업체는 버킷 수준 및 접두사(prefix) 수준의 액세스 정책을 제공하지만, 세분화된 열 수준 및 행 수준 제어를 위해서는 그 위에 거버넌스 레이어가 필요합니다. Unity Catalog는 Databricks의 통합 거버넌스 플랫폼으로, 데이터베이스 관리자에게 친숙한 표준 SQL DCL 구문을 사용하여 단일 인터페이스에서 레이크 및 웨어하우스 테이블 전체에 걸쳐 테이블 수준, 열 수준 및 행 수준 보안 정책을 제공합니다.

데이터 카탈로그 및 메타데이터 관리는 거버넌스의 두 번째 레이어입니다. 카탈로그는 어떤 테이블이 존재하는지, 스키마는 무엇인지, 소유자는 누구인지, 어떻게 생성되었는지 등 소스부터 소비에 이르기까지의 데이터 계보(data lineage)를 추적합니다. 카탈로그가 없으면 데이터 레이크는 데이터 늪(data swamp)이 됩니다. 즉, 문서화 없이 데이터만 쌓이고 엔지니어가 데이터를 분석하는 시간보다 찾는 데 더 많은 시간을 소비하는 저장소가 됩니다. Bronze 수집부터 Silver 조인, Gold 집계에 이르기까지의 변환 경로를 추적하는 자동화된 계보(lineage)는 파이프라인 디버깅, 규정 준수 검증, 스키마 변경의 영향 이해에 필수적입니다.

저장 데이터(data at rest) 및 전송 데이터(data in transit) 모두에 암호화가 필요합니다. 클라우드 오브젝트 스토리지는 서버 측 암호화를 사용하여 기본적으로 저장 데이터를 암호화하며, 전송 중인 데이터는 항상 TLS를 통해 암호화됩니다. 요구사항이 더 엄격한 조직은 클라우드 키 관리 서비스를 통해 고객 관리 키(CMK)를 사용하여 자체 암호화 키를 관리하므로, 명시적인 권한 부여 없이는 클라우드 제공업체조차 데이터를 복호화할 수 없습니다.

마이그레이션 및 아키텍처 의사 결정 프레임워크

데이터 레이크, 클라우드 데이터 웨어하우스, 데이터 레이크하우스 중 무엇을 선택할지 결정하려면 아키텍처 기능과 워크로드 요구사항을 일치시켜야 합니다.

워크로드 적합성 평가부터 시작하세요. 주요 사용자(데이터 과학자, 분석가, 비즈니스 사용자), 필요한 데이터 유형(정형, 반정형, 비정형), 쿼리 패턴(배치, 대화형, 스트리밍), 지연 시간 요구사항(초, 분, 시간)별로 분석 워크로드를 분류해 보세요. 정형 SQL 보고가 주를 이루는 워크로드는 웨어하우스에 적합합니다. 다양한 데이터 유형, ML 모델 학습 또는 향후 유연성이 필요한 워크로드는 레이크에 적합합니다. 혼합형 워크로드는 레이크하우스에 적합합니다.

성능과 함께 비용도 평가해 보세요. 기존 데이터 웨어하우스가 현재 워크로드에 대해 수용할 만한 성능을 보일 수 있지만, 다른 곳에 보관된 원시 데이터의 스토리지 비용, 데이터 중복 비용, 동기화 파이프라인 유지 관리에 따르는 엔지니어링 오버헤드를 포함한 총비용을 계산해야 합니다. 수 테라바이트 이상의 원시 데이터를 저장하는 대부분의 조직의 경우, 시간이 지남에 따라 레이크의 스토리지 비용 우위가 크게 누적됩니다.

팀의 기술 역량을 솔직하게 평가해 보세요. 클라우드 데이터 웨어하우스는 SQL 중심의 분석 팀이 더 쉽게 접근할 수 있는 도구를 제공합니다. 데이터 레이크는 파이프라인 개발, 카탈로그 관리, 거버넌스 도구에 더 깊은 엔지니어링 투자가 필요합니다. 레이크하우스는 이 격차를 줄여주지만, 대규모 워크로드의 경우 여전히 Spark 또는 이에 준하는 분산 처리 지식이 필요합니다.

기존 데이터 웨어하우스에서 마이그레이션하는 조직의 경우 단계별 접근 방식이 가장 효과적입니다. 파일럿 단계에서는 기존 웨어하우스가 제대로 처리하지 못하는 특정 ML 사용 사례나 데이터 유형 등 가치가 높은 단일 워크로드를 식별하여 레이크 또는 레이크하우스에 배치합니다. 확장하기 전에 기존 시스템과 비교하여 실제 비용, 성능, 거버넌스 결과를 측정하세요. 이를 통해 새로운 아키텍처가 검증되기 전에 운영 분석에 지장을 주는 일괄 전환(big-bang) 마이그레이션의 흔한 실패 사례를 방지할 수 있습니다.

데이터 레이크, 웨어하우스, 레이크하우스 중 선택하기

의사 결정 프레임워크는 주요 워크로드 유형에 따라 세 가지 경로로 단순화됩니다.

워크로드가 머신러닝, 데이터 과학 실험 또는 대용량 원시/비정형 데이터 저장 위주라면 데이터 레이크로 시작하세요. 비용 효율성과 포맷 유연성이 결정적인 장점이며, 향후 보고 요구사항이 늘어남에 따라 SQL 쿼리 레이어를 추가할 수 있습니다.

워크로드가 정형 SQL 분석, 높은 동시성의 대시보드, 엄격한 지연 시간 요구사항이 있는 비즈니스 보고 위주이고 소스 데이터가 이미 정형화되어 있다면, 클라우드 데이터 웨어하우스가 해당 특정 사용 사례에 대해 비용 대비 최고의 성능을 제공합니다.

조직에서 두 가지 유형의 워크로드를 모두 실행하고 있거나 12~18개월 이내에 모두 실행할 것으로 예상된다면 처음부터 레이크하우스 아키텍처를 기반으로 구축하세요. 나중에 성숙한 이중 시스템 아키텍처를 통합 레이크하우스로 마이그레이션하는 비용은 처음부터 통합된 기반 위에 구축하는 비용보다 훨씬 더 많이 듭니다.

모든 경우에 전체 마이그레이션을 진행하기 전에 파일럿 프로젝트를 통해 가정을 검증하세요. 파일럿을 시작하기 전에 P95의 쿼리 지연 시간, 월별 테라바이트당 비용, 원시 수집부터 분석 준비 완료 데이터까지의 시간, 신규 기능 개발 대비 파이프라인 유지 관리 비율 등 측정 가능한 성공 지표를 정의하세요. 이러한 지표는 자칫 조직 내 논쟁으로 이어질 수 있는 아키텍처 결정에 객관적인 근거를 제공합니다.

자주 묻는 질문 및 흔한 오해

데이터 레이크가 모든 경우에 클라우드 데이터 웨어하우스를 대체할 수 있나요?

데이터 레이크가 모든 경우에 클라우드 데이터 웨어하우스를 대체하는 것은 아닙니다. 데이터 레이크는 저렴한 비용으로 다양한 형식의 원시 데이터를 저장하고 머신러닝 워크로드를 지원하는 데 탁월하지만, 전통적인 데이터 레이크는 동시성이 높은 SQL 워크로드에 대해 전용 웨어하우스보다 느린 쿼리 성능을 보입니다. 비즈니스 인텔리전스 요구사항이 성숙한 조직은 클라우드 데이터 웨어하우스나 레이크 스토리지에서 직접 웨어하우스급 쿼리 성능을 제공하는 통합 아키텍처인 레이크하우스의 이점을 누릴 수 있습니다.

데이터 레이크는 기존 관계형 데이터베이스와 어떻게 다른가요?

데이터 레이크는 사전 정의된 스키마 없이 오브젝트 스토리지에 원시 데이터를 기본 형식으로 저장하는 반면, 관계형 데이터베이스는 고정된 스키마를 강제하고 데이터베이스 테이블에 정형 데이터를 저장하며 개별 레코드를 삽입하고 업데이트하는 트랜잭션 워크로드에 최적화되어 있습니다. 데이터 레이크는 페타바이트 규모의 분석 및 머신러닝 워크로드를 위해 설계되었으며, 관계형 데이터베이스는 개별 행에 대해 낮은 지연 시간으로 ACID 트랜잭션을 요구하는 운영 애플리케이션을 위해 설계되었습니다.

데이터 레이크와 데이터 레이크하우스의 차이점은 무엇인가요?

데이터 레이크는 트랜잭션 보장 없이 오브젝트 스토리지에 원시 데이터를 저장하므로 동시 쓰기 및 스키마 진화가 복잡합니다. 데이터 레이크하우스는 레이크 스토리지에서 직접 ACID 트랜잭션 지원, 스키마 강제 적용, 데이터 품질 모니터링을 제공하는 Delta Lake, Apache Iceberg 또는 Apache Hudi와 같은 개방형 테이블 포맷 레이어를 추가합니다. 레이크하우스는 데이터 중복 없이도 레이크의 유연성과 비용 효율성, 웨어하우스의 신뢰성과 쿼리 성능을 모두 제공합니다.

데이터 레이크나 웨어하우스 대신 데이터 마트를 사용해야 하는 경우는 언제인가요?

특정 비즈니스 기능(재무, 마케팅, 영업 운영 등)에서 해당 기능의 쿼리 패턴에 최적화되고 정제되어 미리 조인된 데이터 세트가 필요할 때, 그리고 거버넌스나 성능상의 이유로 해당 데이터 세트를 더 넓은 엔터프라이즈 데이터 플랫폼으로부터 격리해야 할 때 데이터 마트를 사용하세요. 레이크하우스 아키텍처에서 Gold 레이어 테이블은 데이터 마트 기능을 효과적으로 수행하므로 별도의 물리적 데이터 마트와 이와 관련된 동기화 복잡성의 필요성을 줄여줍니다.

데이터 레이크가 "데이터 늪"이 되는 원인은 무엇이며, 이를 방지하려면 어떻게 해야 하나요?

데이터 레이크는 적절한 메타데이터 관리, 데이터 품질 제어 또는 액세스 거버넌스 없이 데이터가 축적될 때 '데이터 스웜프(data swamp)'가 됩니다. 이로 인해 사용자는 필요한 데이터를 찾거나, 신뢰하거나, 액세스하기 어려워집니다. 이를 방지하려면 세 가지 제어 장치가 필요합니다. 테이블 스키마, 소유권 및 계보(lineage)를 기록하는 데이터 카탈로그, 각 파이프라인 단계(Bronze, Silver, Gold)에 적용되는 데이터 품질 검사, 권한이 없는 쓰기 작업이 정제된 데이터 세트를 오염시키는 것을 방지하는 액세스 제어입니다. 메달리온 아키텍처는 품질 단계를 강제하여 원시 데이터(raw data)를 프로덕션 등급의 테이블과 격리된 상태로 유지합니다.

부록: 기술 패턴 및 도구

배치 및 스트리밍 샘플 아키텍처. 표준 배치 수집 패턴은 매일 원천 시스템 내보내기 데이터를 Bronze 레이크 스토리지로 로드하고, Silver 단계에서 정제 변환을 적용한 다음, BI 소비를 위해 Gold 집계를 구체화합니다. 스트리밍 패턴은 Apache Kafka 또는 클라우드 이벤트 스트리밍 서비스를 사용하여 실시간에 가깝게 이벤트를 Bronze로 전달하며, 스트리밍 테이블 프레임워크를 통해 증분 방식으로 Silver 및 Gold 업데이트를 구동합니다. 두 패턴 모두 동일한 레이크 스토리지에서 실행되며, Delta Lake가 두 수집 모드 간의 트랜잭션 격리를 처리합니다.

레이어별 인기 도구. 수집: Lakeflow, Apache Kafka, 클라우드 네이티브 CDC 서비스. 변환: Apache Spark (PySpark, Spark SQL), dbt (SQL 중심 팀용). 오케스트레이션: Apache Airflow, 클라우드 네이티브 워크플로우 서비스. SQL 분석: Databricks Lakehouse, BigQuery, Snowflake, Amazon Redshift. 거버넌스: Unity Catalog, Apache Atlas, 클라우드 네이티브 카탈로그 서비스. ML: MLflow, Apache Spark MLlib, 클라우드 네이티브 모델 학습 서비스.

스키마 디자인 템플릿. Gold 레이어 BI 테이블의 경우, 대시보드 성능을 위한 표준으로 킴볼(Kimball) 스타일의 스타 스키마(중앙의 팩트 테이블을 차원 테이블이 둘러싸고 있는 형태)가 여전히 사용됩니다. 팩트 테이블에는 이벤트(트랜잭션, 세션, 전환)가 포함되고, 차원 테이블에는 엔티티 속성(고객, 제품, 매장)이 포함됩니다. ML 피처 테이블의 경우, 엔티티당 하나의 행과 모든 피처를 열로 갖는 광범위한 비정규화 테이블을 사용하여 학습 중 조인 복잡성을 최소화합니다. 스트리밍 분석의 경우, 이벤트 타임스탬프 기준으로 파티셔닝된 추가 전용(append-only) 이벤트 테이블을 통해 실시간 대시보드를 위한 효율적인 시간 범위 스캔이 가능합니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)