데이터 웨어하우스 유형: 아키텍처 및 사용 사례 완벽 가이드

데이터 웨어하우스는 분석가와 데이터 과학자가 복잡한 쿼리를 실행하고, 보고서를 생성하며, 비즈니스 인텔리전스(BI) 워크로드를 지원할 수 있도록 조직 전반의 정형 데이터를 수집, 정리 및 저장하는 중앙 집중식 저장소입니다. 트랜잭션 처리를 위해 설계된 운영 데이터베이스와 달리, 데이터 웨어하우스는 여러 소스의 데이터 결합, 수개년에 걸친 이력 데이터 보존, 전략적 의사 결정에 필요한 거버넌스 기반 제공 등 분석 워크로드를 위해 구축되었습니다.

플랫폼을 결정하거나 마이그레이션을 시작하기 전에 다양한 데이터 웨어하우스 유형을 이해하는 것이 필수적입니다. 각 유형은 확장성, 지연 시간, 비용 및 주제 범위 간의 고유한 아키텍처적 절충안을 반영합니다. 이 가이드에서는 기존의 엔터프라이즈 데이터 웨어하우스부터 현대적인 레이크하우스 아키텍처에 이르기까지 모든 주요 데이터 웨어하우스 유형을 다루고, 각 유형이 언제 적합한 선택인지 명확한 지침을 제공합니다.

데이터 웨어하우스의 세 가지 주요 유형

이 분야에서는 현대 데이터 아키텍처의 기반을 형성하는 세 가지 핵심 데이터 웨어하우스 유형으로 엔터프라이즈 데이터 웨어하우스(EDW), 데이터 마트(Data Mart), 운영 데이터 저장소(ODS)를 정의합니다. 이 외에도 조직은 워크로드 요구 사항, 데이터 볼륨 및 거버넌스 복잡성에 따라 클라우드 기반 데이터 웨어하우스, 가상 데이터 웨어하우스, 하이브리드 데이터 웨어하우스 및 레이크하우스 플랫폼을 배포하기도 합니다.

각 유형은 데이터를 저장하는 방식, 소유 주체, 지원하는 지연 시간, 잘 처리하는 분석 쿼리 측면에서 서로 다릅니다. 올바른 선택은 데이터 소스, 팀 구조, 데이터 품질 요구 사항 및 지원해야 하는 분석 사용 사례에 따라 달라집니다.

엔터프라이즈 데이터 웨어하우스(EDW)

엔터프라이즈 데이터 웨어하우스(EDW)는 전체 조직을 위한 단일의 신뢰할 수 있는 소스(single source of truth) 역할을 하도록 설계된 가장 포괄적인 유형의 데이터 웨어하우스입니다. EDW는 영업, 재무, 운영, 인사, 고객 관계 관리(CRM) 시스템, 재고 관리 시스템 등 모든 주요 비즈니스 부서의 데이터를 일관된 데이터 품질 표준 및 액세스 제어에 의해 관리되는 하나의 중앙 집중식 데이터 웨어하우스로 통합합니다.

아키텍처 및 범위

엔터프라이즈 데이터 웨어하우스의 결정적인 특징은 조직 전반을 아우르는 범위에 있습니다. 여러 소스의 데이터는 추출, 변환, 로드(ETL) 프로세스를 거쳐 웨어하우스에 저장되며, 이곳에서 비즈니스 규칙, 데이터 정제 및 검증을 통해 팀 간의 일관성을 보장합니다. 그 결과 부서에 관계없이 모든 분석가가 동일한 버전의 비즈니스 데이터를 쿼리할 수 있는 거버넌스가 확보된 저장소가 구축됩니다.

EDW는 일반적으로 3계층 아키텍처를 구현합니다. 최하위 계층(bottom tier)은 운영 시스템에서 원시 데이터를 수집하고 변환하는 데이터 소스 및 ETL 프로세스를 처리합니다. 중간 계층(middle tier)은 다차원 분석을 위해 데이터에 액세스할 수 있도록 하는 OLAP 서버를 호스팅합니다. 최상위 계층(top tier)은 비즈니스 사용자가 데이터를 분석하는 대시보드 및 BI 애플리케이션과 같은 프론트엔드 도구를 제공합니다. 이러한 계층형 설계는 수집 복잡성과 분석 성능을 분리하여 각 계층을 독립적으로 최적화할 수 있도록 합니다.

EDW를 선택해야 하는 경우

조직에 전사적 분석, 규정 준수 보고 또는 현재 데이터 사일로에서 운영 중인 비즈니스 부서 전반의 단일 신뢰 소스가 필요한 경우 EDW가 적합한 기반이 됩니다. 규제 보고를 관리하는 금융 서비스 기업, 환자 데이터를 관리하는 의료 기관, 공급망 및 생산 데이터를 통합하는 대형 제조업체와 같이 복잡한 데이터 거버넌스 요구 사항이 있는 조직은 EDW가 제공하는 중앙 집중식 거버넌스의 혜택을 가장 많이 누릴 수 있습니다.

기존 데이터 웨어하우스의 주요 과제는 확장성입니다. 데이터 볼륨이 증가함에 따라 독점 테이블 형식과 고정된 하드웨어 구성으로 인해 온프레미스 EDW 배포의 확장 비용이 많이 듭니다. 이러한 제약에 직면한 많은 조직은 EDW의 거버넌스 모델을 유지하면서 인프라의 한계를 제거하는 클라우드 기반 또는 레이크하우스 아키텍처로 마이그레이션하고 있습니다.

데이터 마트(Data Marts)

데이터 마트는 단일 부서, 비즈니스 기능 또는 분석 도메인으로 범위가 지정된 데이터 웨어하우스의 특정 주제별 하위 집합입니다. EDW가 조직 전체를 지원하는 반면, 데이터 마트는 마케팅 팀, 재무 부서 또는 지역 영업 부서와 같이 집중된 대상을 지원합니다. 데이터 마트는 특정 팀이 실행하는 특정 쿼리 및 보고서에 최적화된 형식으로 데이터를 저장하며, 일반적으로 조인 복잡성을 최소화하는 비정규화된 스타 스키마 또는 스노우플레이크 스키마 설계를 사용합니다.

종속형 및 독립형 데이터 마트

데이터 마트는 두 가지 아키텍처 패턴으로 나뉩니다. 종속형 데이터 마트는 기존 EDW에서 데이터를 가져오므로 중앙 저장소의 거버넌스 및 데이터 품질 표준을 상속받습니다. 이는 이미 EDW가 존재하는 경우 권장되는 접근 방식인데, 부서 간에 지표 정의가 충돌하는 것을 방지하기 때문입니다.

독립형 데이터 마트는 EDW를 거치지 않고 소스 시스템에서 직접 데이터를 수집합니다. 독립형 마트는 구축 속도가 더 빠르지만 위험이 따릅니다. 각 마트가 서로 다른 비즈니스 규칙을 적용하여 비즈니스 부서 간에 일관되지 않은 보고가 발생할 수 있으며, 이는 데이터 웨어하우스 아키텍처가 제거하고자 하는 바로 그 데이터 사일로를 생성하게 됩니다.

데이터 마트를 구축해야 하는 경우

특정 팀에 전체 EDW 구현을 기다릴 여유가 없는 분석 요구 사항이 있거나, 데이터 하위 집합에 대한 쿼리 성능을 독립적으로 최적화해야 하거나, 부서별 데이터 소유권이 거버넌스 요구 사항인 경우 데이터 마트를 구축하세요. 데이터 마트는 영업 데이터 분석, 마케팅 기여도 분석, 재무 보고 등 데이터 도메인이 명확하게 정의되고 대상이 집중되어 있는 사용 사례에 특히 효과적입니다.

운영 데이터 저장소(ODS)

운영 데이터 저장소(ODS)는 트랜잭션 데이터베이스와 분석용 EDW 사이에 위치하여 실시간에 가까운 보고 및 운영 의사 결정을 위해 설계된 데이터 웨어하우스 유형입니다. EDW가 수년에 걸쳐 축적된 이력 데이터를 저장하는 반면, ODS는 현재 및 최근의 운영 데이터를 보유하며(일반적으로 몇 분에서 몇 시간 간격으로 업데이트됨), 장기적인 트렌드보다는 비즈니스의 현재 상태를 반영하는 쿼리에 최적화되어 있습니다.

데이터 아키텍처에서 ODS의 역할

CRM 플랫폼, 재고 관리 시스템, 주문 처리 플랫폼과 같은 운영 시스템은 지속적으로 트랜잭션 데이터를 생성하지만 분석 쿼리를 위해 설계되지는 않았습니다. 프로덕션 트랜잭션 데이터베이스를 대상으로 복잡한 보고서를 실행하면 지원하는 운영 속도가 느려집니다. ODS는 운영 데이터를 별도의 환경으로 복제하여 분석가가 소스 시스템에 영향을 주지 않고 쿼리할 수 있도록 함으로써 이 문제를 해결합니다.

ODS는 여러 운영 소스의 데이터를 통합하고, 가벼운 변환을 적용하여 형식을 표준화하며, 통합된 운영 데이터를 보고에 사용할 수 있도록 합니다. ODS가 EDW를 대체하는 것은 아닙니다. 이력 트렌드 분석 및 전략적 계획 쿼리는 여전히 웨어하우스의 몫입니다. ODS는 현재 재고 수준, 당일 영업 실적, 활성 고객 지원 사례와 같이 시간에 민감한 운영 관련 질문을 처리합니다.

가상 데이터 웨어하우스

가상 데이터 웨어하우스(때로는 연합 데이터 웨어하우스라고도 함)는 데이터를 단일 저장 위치에 물리적으로 통합하지 않습니다. 대신 여러 소스 시스템에 걸쳐 있는 데이터를 제자리에서 쿼리하는 논리적 추상화 계층을 생성하여, 서로 다른 시스템을 통합된 분석 환경으로 보여줍니다.

가상 웨어하우스는 쿼리 연합(query federation) 기술에 의존하여 쿼리를 소스 시스템으로 전달하고 프레젠테이션 계층에서 결과를 집계합니다. 이 접근 방식은 물리적 통합에 따른 스토리지 및 ETL 인프라 비용을 제거하고, 데이터를 이동하지 않고도 운영 데이터베이스에 이미 존재하는 데이터를 분석할 때 더 빠른 가치 실현 시간(time-to-value)을 제공합니다. 주요 한계는 쿼리 성능입니다. 여러 시스템에 걸쳐 대규모 데이터 세트를 결합해야 하는 복잡한 쿼리는 각 쿼리가 분석 워크로드용으로 설계되지 않은 시스템에서 데이터를 검색해야 하므로 상당한 지연 시간을 유발합니다.

가상 데이터 웨어하우스는 탐색적 분석, 소규모 보고 또는 규제 제약으로 인해 데이터 이동이 불가능한 상황에 가장 적합합니다. 대용량 분석 쿼리나 대규모 데이터 처리가 필요한 AI 워크로드에는 적합한 아키텍처가 아닙니다.

클라우드 기반 데이터 웨어하우스

클라우드 기반 데이터 웨어하우스는 AWS, Microsoft Azure, Google Cloud 등의 클라우드 플랫폼에서 호스팅되며 데이터 웨어하우스 기능을 완전 관리형 서비스로 제공합니다. 클라우드 기반 데이터 웨어하우스를 운영하는 조직은 물리적 하드웨어를 프로비저닝하거나 유지 관리할 필요가 없습니다. 클라우드 제공업체가 인프라를 관리하는 동안 조직은 데이터 수집, 모델링 및 분석에 집중할 수 있습니다.

클라우드 배포의 장점

클라우드 기반 데이터 웨어하우스의 가장 큰 장점은 탄력적인 확장성입니다. 기존의 온프레미스 데이터 웨어하우스는 조직이 최대 부하에 맞춰 하드웨어 규모를 산정해야 하므로 정상 운영 중에 과도한 프로비저닝이 발생합니다. 클라우드 웨어하우스는 종량제 모델을 기반으로 수요에 따라 컴퓨팅 및 스토리지 리소스를 자동으로 확장하므로 조직은 사용한 만큼만 비용을 지불합니다. 또한 클라우드 배포는 가치 실현 시간을 단축합니다. 온프레미스 배포는 조달에서 프로덕션까지 수개월이 걸릴 수 있는 반면, 클라우드 데이터 웨어하우스는 몇 시간 내에 프로비저닝하고 데이터를 로드할 수 있습니다.

송신 비용(Egress Costs) 및 마이그레이션 준비도

클라우드 기반 데이터 웨어하우스는 조직이 평가해야 할 절충안을 제시합니다. 클라우드 제공업체의 네트워크 외부로 데이터를 이동할 때 발생하는 비용인 데이터 송신(egress) 수수료는 규모가 커짐에 따라 상당한 수준에 이를 수 있습니다. 여러 클라우드 제공업체를 이용하는 조직은 서로 다른 플랫폼 간의 데이터 통합, 보안 정책 및 거버넌스 프레임워크를 관리하는 데 있어 추가적인 복잡성에 직면하게 됩니다.

클라우드 데이터 웨어하우스로 마이그레이션하기 전에 플랫폼 외부로 유출될 데이터의 양을 평가하고, 벤더 종속(lock-in)을 줄이는 개방형 데이터 형식을 검토하며, 대상 플랫폼의 거버넌스 및 보안 기능이 규정 준수 요구 사항을 충족하는지 확인하세요.

하이브리드 및 현대적 데이터 웨어하우스

하이브리드 데이터 웨어하우스는 온프레미스와 클라우드 데이터 스토리지 기능을 결합하여, 조직이 민감하거나 규제 대상인 데이터를 자체 데이터 센터에 보관하는 동시에 수요 변화가 심한 분석 처리를 위해 클라우드의 확장성을 활용할 수 있도록 지원합니다.

현대적 데이터 웨어하우스의 특징

현대적 데이터 웨어하우스는 몇 가지 의미 있는 방식으로 기존 웨어하우스 모델을 확장합니다. 미리 정의된 스키마의 정형 데이터뿐만 아니라 반정형 및 비정형 데이터도 지원합니다. 컴퓨팅과 스토리지를 분리하여 각각 독립적으로 확장할 수 있도록 함으로써 대규모 데이터 처리 비용을 절감합니다. 스트리밍 데이터 파이프라인과 통합되어 지연 시간을 줄이고, 벤더 종속을 피하기 위해 개방형 데이터 형식을 지원하며, 기존 BI 및 보고 기능과 함께 머신러닝 및 AI 워크로드를 위한 네이티브 후크를 제공합니다.

또한 현대적 데이터 웨어하우스는 소스 시스템에서 시작하여 모든 변환 단계를 거쳐 최종 소비 지점에 이르기까지 데이터를 추적하는 강력한 데이터 계보(lineage) 기능을 통합합니다. 이 계보는 데이터 거버넌스 및 데이터 품질 보증에 필수적입니다. 분석가가 보고서의 숫자에 의문을 제기할 때, 계보 문서를 통해 데이터 팀은 해당 숫자가 어떻게 계산되었는지 정확히 추적할 수 있습니다.

데이터 레이크 및 레이크하우스 아키텍처

데이터 레이크는 미리 정의된 스키마 없이 원본 형식 그대로 원시 데이터를 저장하며, 모든 소스로부터 정형, 반정형, 비정형 데이터를 수용합니다. 데이터를 저장하고 쿼리하기 전에 ETL 프로세스를 거쳐 정의된 스키마를 따르도록 해야 하는 데이터 웨어하우스와 달리, 데이터 레이크는 읽기 시 스키마(schema-on-read)를 적용합니다. 즉, 스키마가 수집 시점이 아닌 쿼리 시점에 적용됩니다. 이러한 유연성 덕분에 데이터 레이크는 머신러닝 및 데이터 과학 탐색을 위한 대규모 원시 데이터를 저장하는 데 적합합니다.

대신 신뢰성이라는 절충안이 따릅니다. ETL 프로세스가 제공하는 데이터 품질 강제가 없으면 데이터 레이크에 일관성이 없거나 중복되거나 문서화가 제대로 되지 않은 데이터가 누적될 수 있으며, 분석가는 거버넌스가 적용된 BI 보고를 위해 이러한 데이터를 신뢰할 수 없게 됩니다.

통합 솔루션으로서의 레이크하우스

데이터 레이크하우스는 데이터 레이크의 유연성과 비용 효율성을 데이터 웨어하우스의 데이터 관리 기능과 결합합니다. 레이크하우스는 클라우드 오브젝트 스토리지에 데이터를 개방형 형식으로 저장한 다음, ACID 트랜잭션, 스키마 진화, 데이터 품질 제약 조건 및 타임 트래블(과거 특정 시점의 상태로 데이터를 쿼리하는 기능)을 강제하는 트랜잭션 메타데이터 및 거버넌스 레이어를 추가합니다.

그 결과 데이터 엔지니어는 ETL 파이프라인을 실행하고, 데이터 분석가는 거버넌스가 적용된 테이블을 대상으로 SQL 쿼리를 실행하며, 데이터 과학자는 모델 학습을 위해 원시 및 피처 엔지니어링된 데이터에 액세스할 수 있는 단일 플랫폼이 구축됩니다. 이 모든 과정에서 시스템 간에 데이터를 이동할 필요가 없습니다. 레이크하우스 배포에서 흔히 사용하는 메달리온 아키텍처(medallion architecture)는 데이터를 브론즈(원시), 실버(검증 및 통합), 골드(정제 및 소비 준비 완료) 레이어로 구성하여 각 단계에서 데이터 품질을 점진적으로 향상시킵니다. 골드 레이어는 기존 웨어하우스가 이미 운영 중인 데이터 마트 및 EDW 서빙 레이어에 직접 매핑되므로 아키텍처적으로 친숙하게 전환할 수 있습니다.

데이터 웨어하우스 아키텍처 및 스토리지

배포 모델에 관계없이 데이터 웨어하우스 아키텍처는 동일한 기본 원칙을 반영합니다. 즉, 데이터를 생성하는 애플리케이션에서 데이터를 분리하고, 거버넌스가 적용된 프로세스를 통해 정제 및 통합하며, 트랜잭션 쓰기보다는 분석 쿼리에 최적화된 형식으로 저장해야 한다는 것입니다.

스토리지 및 스키마 디자인

현대적 데이터 웨어하우스는 컴퓨팅과 스토리지를 분리하여 각 차원을 독립적으로 확장할 수 있도록 합니다. 스토리지 시스템은 분석 쿼리 중에 스캔되는 데이터를 최소화하는 열 지향(columnar) 형식으로 데이터를 보관합니다. 예를 들어 50개 열 중 3개 열만 터치하는 쿼리는 모든 행을 전체적으로 스캔하는 대신 3개 열에 해당하는 데이터만 읽습니다.

스키마 디자인은 쿼리 성능에 큰 영향을 미칩니다. 스타 스키마(star schema)는 매출 트랜잭션이나 웹 세션과 같이 측정 가능한 이벤트가 포함된 중앙 팩트 테이블을 중심으로 데이터를 구성하고, 관련 엔티티(고객, 제품, 기간)를 설명하는 차원 테이블이 이를 둘러싸는 형태입니다. 스타 스키마에서의 조인(join)은 간단하고 빠릅니다. 스노우플레이크 스키마는 차원 테이블을 더욱 정규화하여 조인 복잡성이 증가하는 대신 스토리지 중복을 줄입니다. 갤럭시 스키마는 여러 팩트 테이블 간에 차원 테이블을 공유하여 서로 다른 비즈니스 프로세스에 걸친 분석 쿼리를 지원합니다.

스타 스키마는 읽기 성능을 우선시하기 때문에 데이터 마트와 레이크하우스의 골드 레이어에서 가장 흔히 선택됩니다. 적합한 스키마는 데이터 볼륨, 업데이트 패턴, 그리고 스키마가 지원해야 하는 분석 쿼리의 복잡성에 따라 달라집니다.

웨어하우스의 데이터 유형

데이터 웨어하우스는 역사적으로 관계형 데이터베이스, CRM 플랫폼, 금융 시스템, 재고 관리 시스템 등에서 가져온, 미리 정의된 데이터 유형과 스키마를 가진 행과 열 형태의 정형 데이터를 저장해 왔습니다. 정형 데이터는 표준 SQL을 사용하여 쉽게 쿼리할 수 있으며, ETL 파이프라인에 깔끔하게 통합됩니다.

정형, 반정형 및 비정형 데이터

반정형 데이터는 엄격한 관계형 스키마를 따르지 않지만 파싱이 가능하도록 하는 조직적 마커를 포함하고 있습니다. JSON 문서, XML 파일, 로그 기록, 클릭스트림 데이터가 모두 이 범주에 속합니다. 많은 현대적 데이터 웨어하우스 플랫폼은 네이티브 반정형 데이터 유형을 지원하므로, 데이터를 미리 평탄화(flattening)하지 않고도 SQL 쿼리가 중첩된 구조를 탐색할 수 있습니다.

비정형 데이터 — 이미지, 비디오, 자유 형식 텍스트 문서, 오디오 녹음 — 는 SQL로 직접 쿼리할 수 없지만, 조직이 AI 및 머신러닝 기능을 구축함에 따라 그 중요성이 점점 더 커지고 있습니다. 레이크하우스 아키텍처는 이러한 경계를 허물어 동일한 플랫폼 내에서 비정형 데이터를 정형 데이터와 함께 저장하고 관리할 수 있도록 지원합니다.

쓰기 시 스키마(schema-on-write, 기존 데이터 웨어하우스처럼 수집 시 구조를 강제함)와 읽기 시 스키마(schema-on-read, 데이터 레이크처럼 쿼리 시점까지 구조 정의를 미룸) 사이의 선택은 데이터 품질의 일관성과 수집 유연성 간의 근본적인 절충안을 반영합니다. 대부분의 성숙한 데이터 플랫폼은 거버넌스가 적용된 분석 테이블에는 쓰기 시 스키마를 사용하고, 탐색 및 원시 데이터 영역에는 읽기 시 스키마를 사용합니다.

외부 데이터 소스 및 통합

데이터 웨어하우스가 단일 소스에서만 데이터를 가져오는 경우는 드뭅니다. 전형적인 엔터프라이즈 배포에서는 운영 데이터베이스, CRM 시스템, ERP 플랫폼, 마케팅 자동화 도구, 재무 원장, 제3자 데이터 제공업체, 외부 API 등의 데이터를 통합합니다. 각각 고유한 스키마, 업데이트 빈도, 데이터 품질 특성을 가진 이러한 다양한 외부 데이터 소스를 관리하는 것은 데이터 웨어하우스 아키텍처의 핵심 과제 중 하나입니다.

외부 데이터가 웨어하우스에 들어가기 전에 예상되는 스키마 및 데이터 품질 규칙에 따라 유효성 검사를 거쳐야 합니다. 유효성 검사는 필수 필드 누락, 예상 범위를 벗어난 값, 참조 무결성 위반과 같은 일반적인 문제를 조기에 발견합니다. 수집 시점에 이러한 문제를 발견하는 것은 데이터가 보고서와 대시보드로 전파된 후에 발견하는 것보다 비용이 훨씬 적게 듭니다. 데이터 보강(enrichment)은 수집된 데이터에 참조 테이블이나 외부 데이터 세트의 컨텍스트를 추가하여 원시 소스 데이터를 분석가가 필요로 하는 비즈니스 준비 완료 데이터 세트로 변환합니다.

ETL 대 ELT 및 파이프라인 모니터링

데이터 통합 프로세스는 데이터가 소스 시스템에서 웨어하우스로 이동하는 방식과 변환되는 방식을 결정합니다. ETL(Extract, Transform, Load)은 기존의 접근 방식으로, 소스에서 데이터를 추출하고 별도의 처리 환경에서 변환한 다음 최종 정형 형태로 로드합니다. ELT(Extract, Load, Transform)는 이 순서를 뒤집어 원시 데이터를 먼저 로드한 다음 웨어하우스 자체의 처리 능력을 사용하여 웨어하우스 내에서 변환합니다. 현대적 클라우드 데이터 웨어하우스는 변환 단계에서 더 낮은 전체 비용으로 웨어하우스의 병렬 처리 기능을 활용할 수 있기 때문에 종종 ELT를 선호합니다. 아키텍처적 영향에 대해 더 자세히 알아보려면 ELT 대 ETL 비교에서 주요 절충안을 다루고 있으니 참고하세요.

데이터 파이프라인 모니터링은 수집 작업이 일정대로 완료되고, 데이터 볼륨이 예상과 일치하며, 데이터가 프로덕션으로 승격되기 전에 품질 검사를 통과하는지 확인합니다. 오류 없이 완료되지만 잘못된 결과를 생성하는 '자동 실패(fail silently)' 파이프라인은 데이터 웨어하우스 운영에서 가장 위험한 실패 모드 중 하나입니다.

데이터 보안 및 거버넌스

데이터 거버넌스와 데이터 보안은 모든 데이터 웨어하우스의 기본 요구 사항이며, 특히 규정 준수 대상인 민감한 데이터를 다루는 조직에 더욱 그렇습니다. 누가, 언제, 어떤 목적으로 어떤 데이터에 액세스했는지 증명할 수 없는 웨어하우스는 감사자를 만족시키거나 데이터를 보유하고 있는 고객의 신뢰를 유지할 수 없습니다.

액세스 제어, 암호화 및 감사 로깅

효과적인 데이터 보안은 역할 기반 액세스 제어(RBAC)에서 시작됩니다. RBAC는 개인 대신 역할에 데이터 액세스 권한을 부여하여 대규모 조직 전체에서 액세스 관리를 확장 가능하게 만듭니다. 액세스 제어는 카탈로그 수준, 테이블 수준, 열 수준(개인 식별 정보 마스킹에 중요), 행 수준(조직 소속 또는 데이터 소유권 기준) 등 여러 수준에서 작동해야 합니다.

데이터는 저장 및 전송 중 모두 암호화되어야 합니다. 저장 데이터 암호화는 스토리지 미디어에 대한 무단 액세스를 방지하며, 전송 중 암호화는 네트워크를 통한 가로채기를 방지합니다. 감사 로깅은 누가 언제 테이블을 쿼리했는지, 어떤 데이터가 반환되었는지 등 모든 액세스 및 수정 이벤트를 기록하여 보안 조사와 규정 준수 증명을 지원합니다. 데이터의 원천부터 모든 변환 과정을 거쳐 소비 지점까지 추적하는 데이터 리니지(lineage) 추적은 거버넌스와 데이터 품질 보증을 모두 지원합니다.

웨어하우스 유형별 데이터 분석 사용 사례

데이터 웨어하우스 유형마다 적합한 분석 워크로드가 다릅니다. 이러한 매핑을 이해하면 특정 워크로드 유형에만 최적화된 아키텍처를 배포하고 모든 사용 사례에서 동일한 성능을 기대하는 실수를 방지할 수 있습니다.

워크로드에 아키텍처 맞추기

엔터프라이즈 데이터 웨어하우스는 전년 대비 트렌드 분석, 부서 간 보고, 임원 대시보드, 여러 비즈니스 도메인의 데이터 결합이 필요한 규정 준수 보고 등 전략적 분석을 지원합니다. 데이터 마트는 영업 실적, 마케팅 기여도 분석, 재무 마감 보고, 고객 세분화 등 부서별 분석을 지원하며, 데이터 범위가 좁아 셀프 서비스 속도가 더 빠릅니다. 운영 데이터 저장소는 소매, 물류, 금융 서비스 환경에서 현재 비즈니스 상황을 모니터링하고 실시간 이벤트에 대응하는 운영 분석을 지원합니다.

클라우드 및 레이크하우스 아키텍처는 대규모 머신러닝 모델 학습, 자연어 처리 파이프라인, 추천 시스템 등 고급 분석과 AI를 지원합니다. 이러한 워크로드에는 거버넌스가 적용된 정형 데이터뿐만 아니라, 더 유연한 스토리지 아키텍처만 수용할 수 있는 원시(raw) 및 반정형 데이터도 필요합니다.

BI, 보고 및 고급 분석

BI 도구는 데이터 웨어하우스에 연결되어 SQL을 작성하지 않는 비즈니스 사용자가 액세스할 수 있는 대시보드와 보고서를 빌드합니다. 머신러닝 통합을 위해 데이터 사이언티스트는 피처 엔지니어링을 위한 거버넌스가 적용된 깨끗한 데이터와 모델 학습을 위한 원시 이력 데이터 모두에 액세스해야 합니다. 레이크하우스 아키텍처는 단일 플랫폼에서 두 가지 사용 사례를 모두 지원하므로, BI 및 ML 워크로드를 위해 별도의 데이터 복사본을 유지 관리하는 데이터 엔지니어링 오버헤드를 제거합니다.

데이터 웨어하우스 솔루션 선택 및 마이그레이션

적합한 데이터 웨어하우스 솔루션을 선택하려면 공급업체 관리형(vendor-managed) 옵션과 자체 호스팅(self-hosted) 옵션을 평가하고, 비용 구조를 이해하며, 플랫폼이 특정 분석 워크로드를 대규모로 지원할 수 있는지 검증해야 합니다. 공급업체 관리형 서비스는 일부 운영 제어 권한을 양보하는 대신 인프라 관리, 확장, 패치 및 고가용성을 처리합니다. 자체 호스팅 옵션은 엄격한 데이터 레지던시 요구 사항이나 복잡한 보안 정책에 대해 조직에 더 많은 유연성을 제공하지만, 팀이 직접 클러스터를 관리하고 업그레이드를 조율하며 용량 계획을 처리해야 합니다.

공급업체 및 비용 요소 평가

데이터 웨어하우스 비용은 스토리지 비용, 컴퓨팅 비용, 데이터 이동 비용의 세 가지 범주로 나뉩니다. 현대적인 클라우드 데이터 웨어하우스는 스토리지와 컴퓨팅 비용을 별도로 책정하므로 각각 독립적으로 확장할 수 있습니다. 중요한 프로덕션 워크로드를 위해 플랫폼을 도입하기 전에 실제 데이터와 쿼리 패턴으로 개념 검증(PoC)을 실행해 보세요. 합성 벤치마크는 실제 운영하는 데이터 규모에서의 실제 성능을 반영하지 못하는 경우가 많습니다.

단계별 마이그레이션 및 비용 최적화

기존 레거시 데이터 웨어하우스에서 현대적인 플랫폼으로 마이그레이션할 때는 비즈니스 도메인별로 구성된 단계별 접근 방식을 사용하는 것이 유리합니다. 데이터 요구 사항이 명확하게 정의되어 있고 적극적인 비즈니스 소유자가 있는 도메인부터 시작하세요. 다음 도메인으로 진행하기 전에 프로덕션 벤치마크를 통해 마이그레이션을 검증해야 합니다.

컴퓨팅과 스토리지의 분리는 현대적인 데이터 웨어하우스에서 가장 중요한 비용 최적화 수단 중 하나입니다. 기존 아키텍처에서는 컴퓨팅과 스토리지의 규모가 함께 조정되었습니다. 현대적인 클라우드 아키텍처는 이 두 요소를 분리하여 조직이 추가 컴퓨팅을 프로비저닝하지 않고도 스토리지를 추가할 수 있고, 스토리지 비용을 영구적으로 늘리지 않고도 피크 쿼리 기간에 맞춰 컴퓨팅을 확장할 수 있도록 합니다. 오토스케일링(autoscaling)은 피크 시간대의 리소스 부족(under-provisioning)과 유휴 시간대의 리소스 낭비(over-provisioning)를 모두 방지합니다.

데이터 웨어하우스 유형 비교

자주 묻는 질문

주요 데이터 웨어하우스 유형에는 어떤 것이 있나요?

세 가지 주요 데이터 웨어하우스 유형은 엔터프라이즈 데이터 웨어하우스(EDW), 데이터 마트, 운영 데이터 저장소(ODS)입니다. 이러한 핵심 유형 외에도 조직은 클라우드 기반 데이터 웨어하우스, 가상 데이터 웨어하우스, 온프레미스와 클라우드 스토리지를 결합한 하이브리드 데이터 웨어하우스, 웨어하우스 거버넌스와 데이터 레이크의 유연성을 통합한 레이크하우스 아키텍처를 배포하기도 합니다. 각 유형은 데이터 범위, 지연 시간 요구 사항, 분석 워크로드에 따라 서로 다른 사용 사례에 적합합니다.

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

데이터 웨어하우스는 미리 정의된 스키마에 정형 데이터를 저장하고, 데이터가 로드되기 전에 ETL 프로세스를 통해 데이터 품질을 강제합니다. 반면 데이터 레이크는 수집 시 미리 정의된 스키마를 요구하지 않고 정형, 반정형, 비정형 등 원래 형식 그대로의 원시 데이터를 저장합니다. 데이터 웨어하우스는 복잡한 분석용 SQL 쿼리 및 BI 보고에 최적화되어 있으며, 데이터 레이크는 유연성과 대규모 데이터 과학 및 머신러닝 워크로드에 최적화되어 있습니다. 레이크하우스는 이 두 가지를 결합한 것으로, 데이터 레이크의 유연성을 갖춘 개방형 형식으로 데이터를 저장한 다음 데이터 웨어하우스의 신뢰성을 제공하는 거버넌스 및 트랜잭션 레이어를 추가합니다.

조직에서 EDW 대신 데이터 마트를 사용해야 하는 경우는 언제인가요?

데이터 마트는 특정 부서가 전체 EDW 구축보다 더 빠르게 분석 기능을 필요로 할 때, 좁은 데이터 도메인에 대한 쿼리 성능을 독립적으로 최적화해야 할 때, 또는 부서별 데이터 소유권이 거버넌스 요구 사항일 때 적합한 선택입니다. 데이터 마트는 기존 EDW 위에 구축된 종속형 저장소로서 소스 시스템에서 직접 수집하는 대신 중앙 리포지토리에서 데이터를 가져올 때 가장 효과적입니다. 중앙 EDW 없이 독립적인 데이터 마트를 구축하면 팀 전체에 일관되지 않은 지표 정의와 데이터 사일로가 발생할 위험이 있습니다.

운영 데이터 저장소(ODS)란 무엇이며 데이터 웨어하우스와 어떻게 다른가요?

운영 데이터 저장소(ODS)는 몇 분에서 몇 시간 간격으로 업데이트되는 현재 및 현재에 가까운 운영 데이터를 보유하며, 운영 보고 및 의사 결정을 위해 설계되었습니다. 반면 데이터 웨어하우스는 수년에 걸친 이력 데이터를 축적하며 트렌드 분석, 전략적 보고, 복잡한 다차원 쿼리에 최적화되어 있습니다. ODS는 운영 트랜잭션 시스템과 하루에 한 번만 업데이트될 수 있는 웨어하우스 간의 지연 시간 격차를 메워줍니다. 두 시스템은 종종 함께 배포되어, ODS는 당일 운영 가시성을 지원하고 웨어하우스는 장기적인 전략 분석을 지원합니다.

클라우드 데이터 웨어하우스는 온프레미스 데이터 웨어하우스와 어떻게 다른가요?

클라우드 데이터 웨어하우스는 클라우드 플랫폼에서 호스팅되며, 온프레미스 배포에 비해 탄력적인 확장성, 종량제 요금제, 인프라 관리 오버헤드 감소 등의 이점을 제공합니다. 기존의 온프레미스 데이터 웨어하우스는 최대 용량에 맞춰 크기를 산정해야 하므로 일반적인 운영 중에는 심각한 리소스 과다 프로비저닝(over-provisioning)이 발생하는 경우가 많습니다. 반면 클라우드 웨어하우스는 자동으로 확장되며 몇 시간 만에 프로비저닝할 수 있습니다. 단점으로는 대용량 데이터 전송 시 발생하는 데이터 송신(egress) 비용, 클라우드 제공업체의 가용성에 대한 의존성, 여러 클라우드 플랫폼을 운영하는 조직의 거버넌스 복잡성 등이 있습니다.

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