Microsoft Fabric 아키텍처 이해하기: Lakehouse와 Warehouse 비교

By Mirko Peters · 2026-08-27

블로그에 다시 오신 것을 환영합니다! 최근 팟캐스트 에피소드를 따라오셨다면, 데이터 플랫폼, 최신 분석, 엔터프라이즈 아키텍처라는 빠르게 변화하는 영역을 깊이 다루고 있다는 것을 아실 겁니다. 분석 환경을 설계하는 일은 한 가지 정답이 있는 작업이 아니지만, Microsoft Fabric이 등장하면서 조직은 데이터 엔지니어링, 데이터 웨어하우징, 비즈니스 인텔리전스, AI를 하나의 운영 체계 아래 묶은 통합 환경을 갖추게 되었습니다. 다만 플랫폼이 통합되어 있다고 해서 아키텍처 선택이 사라지는 것은 아닙니다. Microsoft Fabric 여정을 시작할 때 데이터 아키텍트와 엔지니어링 팀이 맞닥뜨리는 가장 첫 번째 결정 중 하나는 Lakehouse와 Data Warehouse 중 무엇을 선택할지입니다.

Automatically translated with AI from the original post. Read the English original

블로그에 다시 오신 것을 환영합니다! 최근 팟캐스트 에피소드를 따라오셨다면, 데이터 플랫폼, 최신 분석, 엔터프라이즈 아키텍처라는 빠르게 변화하는 영역을 깊이 다루고 있다는 것을 아실 겁니다. 분석 환경을 설계하는 일은 한 가지 정답이 있는 작업이 아니지만, Microsoft Fabric이 등장하면서 조직은 데이터 엔지니어링, 데이터 웨어하우징, 비즈니스 인텔리전스, AI를 하나의 운영 체계 아래 묶은 통합 환경을 갖추게 되었습니다. 다만 플랫폼이 통합되어 있다고 해서 아키텍처 선택이 사라지는 것은 아닙니다. Microsoft Fabric 여정을 시작할 때 데이터 아키텍트와 엔지니어링 팀이 맞닥뜨리는 가장 첫 번째 결정 중 하나는 Lakehouse와 Data Warehouse 중 무엇을 선택할지입니다.

이 아키텍처 결정은 조직이 데이터를 저장하고, 처리하고, 제공하는 방식의 기반이 됩니다. Lakehouse의 유연성과 오픈소스 특성을 활용해야 할까요, 아니면 전통적인 Data Warehouse의 정형화되고 관계형인 강점을 유지해야 할까요? 이 선택을 제대로 이해하려면 Microsoft Fabric 스토리지의 여러 층을 하나씩 벗겨 보고, 팀의 기술 역량이 이 결정에 어떻게 영향을 미치는지 분석하며, Delta Lake 같은 최신 데이터 형식이 두 접근 방식 사이의 간극을 어떻게 메우는지 살펴봐야 합니다. 이제 Microsoft Fabric 아키텍처를 명확히 이해하고, 조직에 맞는 길을 고르는 방법을 함께 알아보겠습니다.

Microsoft Fabric 스토리지 옵션 소개

Microsoft Fabric 이전에는 포괄적인 데이터 플랫폼을 구축하려면 Azure 전반에 걸쳐 여러 서비스를 따로 연결해야 하는 경우가 많았습니다. Azure Data Lake Storage를 설정하고, 전용 SQL 풀을 프로비저닝하고, Azure Databricks 클러스터를 관리하고, Power BI 워크스페이스를 연결하는 식이었습니다. 강력하기는 했지만, 이런 방식은 데이터 사일로와 중복 복사본을 낳기 쉬웠고, 서로 다른 서비스에 걸쳐 보안과 컴퓨팅 리소스를 관리하는 데 행정적 부담도 컸습니다.

Microsoft Fabric은 OneLake를 도입해 이 분절 문제를 해결합니다. OneLake는 조직 데이터를 위한 OneDrive와 같은 역할을 하는, SaaS 기반의 멀티 테넌트 통합 데이터 레이크입니다. Fabric의 모든 요소, 즉 Lakehouse, Data Warehouse, KQL 데이터베이스, Power BI 시맨틱 모델은 모두 OneLake 위에 놓입니다. 이 통합 스토리지 계층 안에서 조직은 분석 데이터를 어떻게 구조화하고 상호작용할지 선택할 수 있습니다. Fabric에서 분석 데이터를 저장하고 쿼리하는 두 가지 주요 엔진이 바로 Lakehouse와 Data Warehouse입니다. 두 가지는 공통된 기반 기술을 공유하지만, 서로 다른 워크로드, 사용자 페르소나, 운영 패러다임을 염두에 두고 설계되었습니다.

Microsoft Fabric Lakehouse 이해하기

Microsoft Fabric Lakehouse는 데이터 레이크와 데이터 웨어하우스의 장점을 하나의 환경에 결합하도록 설계된 데이터 아키텍처 패턴입니다. 파일 기반 데이터 엔지니어링 워크로드와 정형 분석 쿼리 모두에 최적화되어 있어 데이터 엔지니어와 데이터 과학자들이 특히 선호합니다.

Fabric의 Lakehouse는 핵심적으로 전통적인 데이터 레이크처럼 파일과 폴더를 관리하지만, 오픈소스 Delta Parquet 형식을 사용하는 중요한 트랜잭션 계층을 추가합니다. 즉, 이미지, PDF, 오디오 파일, 원시 JSON 로그 같은 비정형 데이터를 정형 및 반정형 테이블 데이터와 나란히 저장할 수 있습니다. 또한 Lakehouse는 Apache Spark와 기본적으로 통합됩니다. 팀이 PySpark 노트북, 분산 데이터 변환, 대규모 데이터 엔지니어링에 의존한다면 Lakehouse가 가장 이상적인 작업 공간이 됩니다. 데이터 전문가는 이곳에서 복잡한 변환을 실행하고, 머신러닝 모델을 학습시키며, 코드 중심 방법론으로 견고한 데이터 파이프라인을 구축할 수 있습니다.

Microsoft Fabric Data Warehouse 이해하기

스펙트럼의 반대편에는 Microsoft Fabric Data Warehouse가 있습니다. 조직이 수년 동안 전통적인 엔터프라이즈 데이터 웨어하우스, SQL Server, 또는 전용 분석 데이터베이스에 의존해 왔다면, Fabric Data Warehouse는 즉시 익숙하고 편안하게 느껴질 것입니다.

Lakehouse가 여러 저장 형식을 아우르고 비정형 파일도 수용하는 것과 달리, Fabric Data Warehouse는 관계형 데이터와 정형 테이블에 집중합니다. 고성능 T-SQL 쿼리를 제공하도록 설계되었습니다. Fabric에서 Warehouse를 프로비저닝하면 관계형 작업, 복잡한 조인, 비즈니스 인텔리전스 보고에 최적화된, 스토리지와 컴퓨트가 분리된 모델을 사용하게 됩니다. 데이터베이스 관리자, SQL 개발자, 데이터 분석가는 Spark를 배우거나 클러스터 구성을 관리하지 않고도 표준 T-SQL 스크립트를 작성하고, 데이터베이스 스키마를 관리하고, 뷰를 만들고, 저장 프로시저를 적용할 수 있습니다. 또한 전통적인 엔터프라이즈 데이터 팀이 엔터프라이즈급 데이터 웨어하우스에 기대하는 예측 가능한 거버넌스, 보안, 트랜잭션 일관성을 제공합니다.

주요 아키텍처 차이: Lakehouse 대 Warehouse

Microsoft Fabric Lakehouse와 Data Warehouse를 나란히 비교하면, 차이는 Spark를 쓰느냐 T-SQL을 쓰느냐에 그치지 않습니다. 이러한 아키텍처상의 차이를 이해하면 팀이 과도하게 설계하거나, 운영 습관과 맞지 않는 스토리지 모델을 선택하는 일을 피할 수 있습니다.

먼저 각 옵션이 중시하는 데이터 유형을 살펴보겠습니다. Lakehouse는 원시 비정형 문서부터 정형 Delta 테이블까지 모든 데이터를 처리합니다. Data Warehouse는 정형 및 반정형 관계형 데이터에 맞게 엄격히 최적화되어 있습니다. 다음으로 컴퓨트 엔진을 보겠습니다. Lakehouse는 데이터 처리에 Apache Spark를 주로 사용하는 반면, Data Warehouse는 MPP(massively parallel processing) SQL 엔진을 활용합니다. 마지막으로 데이터 관리 방식을 보겠습니다. Lakehouse는 기반 파일에 대한 개방형 접근을 제공하므로, 데이터 과학자는 외부 도구나 Python 라이브러리를 사용해 Parquet 파일을 직접 읽을 수 있습니다. Warehouse는 기반 스토리지를 더 강하게 추상화하여, 분석 보고와 동시 쿼리 성능에 최적화된 깔끔한 관계형 SQL 데이터베이스 인터페이스를 제공합니다.

팀 역량에 맞춘 스토리지 선택

아키텍처 결정은 절대 진공 상태에서 내려서는 안 되며, 팀이 현재 보유한 역량의 현실을 반드시 고려해야 합니다. 기술의 효과는 그것을 다루는 사람에 따라 결정됩니다.

조직에 Power BI 개발자, 전통적인 데이터베이스 관리자, T-SQL에 익숙한 SQL 분석가가 많다면, 이들을 Spark 중심의 Lakehouse 아키텍처로 밀어 넣는 것은 불필요한 학습 곡선을 만들고 제공 속도를 떨어뜨릴 수 있습니다. 이런 경우 Fabric Data Warehouse는 익숙한 시작점을 제공하여, 기존 SQL 인재가 현재 전문성을 즉시 활용할 수 있게 합니다. 반대로 조직에 Python, Scala, 분산 컴퓨팅 프레임워크에 능숙한 데이터 엔지니어와 데이터 과학자가 있다면, Lakehouse가 고급 변환 파이프라인과 AI 솔루션을 구축하는 데 필요한 프로그래밍 유연성과 연산 규모를 제공합니다. 올바른 Fabric 스토리지 옵션을 고르려면 팀의 역량을 솔직하게 살펴보고, 팀을 소외시키지 않고 역량을 발휘하게 해 주는 아키텍처를 설계해야 합니다.

다양한 데이터 유형과 워크로드 처리

Microsoft Fabric에서 Lakehouse와 Data Warehouse 중 하나를 고를 때는 결국 워크로드 요구 사항과 데이터의 다양성이 가장 큰 결정 요인이 되는 경우가 많습니다. 모든 데이터가 관계형 테이블로 깔끔하게 정리되어 들어오지는 않으며, 모든 분석이 같은 모습인 것도 아닙니다.

수집 파이프라인이 대량의 원시 텔레메트리, IoT 센서 스트림, 비정형 텍스트 파일, 시스템 로그를 가져온다면 Lakehouse가 자연스러운 랜딩 영역입니다. Medallion 아키텍처의 Bronze 레이어에 원시 데이터를 빠르게 적재하고, Spark 노트북으로 처리한 뒤, 정제된 분석용 테이블로 다듬을 수 있는 유연성을 제공합니다. 반면 주요 워크로드가 깔끔하고 구조가 잘 잡힌 차원 데이터 모델을 기반으로 동시 접속이 많은 비즈니스 인텔리전스 대시보드를 지원하는 것이라면 Data Warehouse가 빛을 발합니다. T-SQL 엔진은 복잡한 분석 쿼리를 짧은 지연 시간으로 실행하도록 세밀하게 조정되어 있어, 비즈니스 사용자가 Power BI 시맨틱 모델에서 빠르고 신뢰할 수 있는 답을 얻도록 보장합니다.

통합 스토리지를 위한 Delta 형식 활용

Microsoft가 Fabric을 구축하면서 내린 가장 탁월한 아키텍처 결정 중 하나는, 모든 정형 테이블의 기반으로 오픈소스 Delta Parquet 형식을 채택한 것입니다. 이 선택 덕분에 Lakehouse와 Warehouse의 경계가 여러 면에서 강력하게 흐려집니다.

PySpark로 Fabric Lakehouse에서 데이터를 수집하고 처리하든, T-SQL로 Fabric Data Warehouse에 적재하든, OneLake에 저장되는 실제 물리 파일은 Delta 테이블 형식으로 저장됩니다. 이 개방형 저장 표준 덕분에 두 환경 모두에서 ACID 트랜잭션, 시간 여행(time travel), 높은 성능을 활용할 수 있습니다. Lakehouse와 Warehouse가 모두 Delta 테이블을 읽고 쓸 수 있으므로, 조직은 더 이상 독점 스토리지에 묶일 걱정을 하지 않아도 됩니다. 즉 데이터 엔지니어는 Lakehouse에서 Spark로 데이터를 준비하고, SQL 개발자는 데이터의 중복 물리 복사본을 만들지 않고도 Warehouse에서 T-SQL로 바로 그 같은 테이블을 쿼리할 수 있습니다.

조직에 맞는 접근 방식 선택을 위한 모범 사례

Microsoft Fabric 배포를 계획할 때, Lakehouse, Warehouse 중 무엇을 구현할지, 아니면 둘을 함께 쓸지는 어떻게 결정하시나요? 성공적인 조직은 Fabric 환경을 설계할 때 대체로 몇 가지 핵심 모범 사례를 따릅니다.

첫째, 필요한 경우 하이브리드 접근 방식을 採택하십시오. 아니, 다시 정정합니다: 첫째, 필요한 경우 하이브리드 접근 방식을 적극 활용하십시오. Microsoft Fabric은 동일한 테넌트와 워크스페이스 구조 안에서 Lakehouse와 Warehouse를 나란히 사용할 수 있도록 설계되어 있습니다. 원시 데이터 수집, 무거운 데이터 엔지니어링 변환, 데이터 과학 작업에는 Lakehouse를 사용하고, 하위 보고용 마트나 엔터프라이즈 공통 차원(conformed dimension)은 Data Warehouse에 두는 방식을 생각해볼 수 있습니다. 둘째, OneLake 바로 가기(shortcut)를 활용하여 도메인 간의 불필요한 데이터 이동과 중복을 피하십시오. 셋째, 항상 소비자를 염두에 두고 설계하십시오. 수집하는 데이터 유형, 데이터를 변환하는 사람들의 기술, 최종 인사이트를 사용하는 비즈니스 사용자의 성능 요구 사항을 평가해야 합니다.

원시 데이터 수집부터 경영진의 의사결정까지 이러한 아키텍처 구성 요소가 어떻게 맞물리는지에 대한 실제 사례 중심 분석을 듣고 싶으시다면, 관련 팟캐스트 에피소드 Microsoft Fabric End-to-End: From Raw Data to Business Decisions with Amit Chandak [MVP]를 꼭 들어보시기 바랍니다. 이 에피소드에서 Amit은 조직이 OneLake를 활용하고, Lakehouse와 Warehouse 중 선택하는 방법을 살펴보며, 변환 작업을 최적화하고, 사람과 AI 기반 경험 모두를 뒷받침하는 확장 가능한 분석 솔루션을 구축하는 방법을 소개합니다.