본문으로 건너뛰기

Databricks vs Microsoft Fabric: 의사결정 가이드

주요 산출물이 Power BI인 Microsoft 중심 조직에는 Fabric이 더 빠른 길입니다. 엔지니어링과 ML 플랫폼으로는 Databricks가 더 강합니다. 많은 조직이 결국 둘 다 운영하며, 의도적으로 설계한다면 그것이 정답일 수 있습니다.

화이트보드에 데이터 아키텍처 스케치가 있는 유리 회의실 옆, 밝은 사무실에 있는 Noel D'Costa
목차
  1. 두 플랫폼은 어떻게 만들어져 있을까요
  2. Databricks vs Fabric 가격: 용량 대 소비량
  3. 나란히 비교
  4. "둘 다 쓰는" 패턴, 솔직하게
  5. 방위 산업과 제조업에서 고려할 점
  6. 의사결정 기준: Fabric, Databricks, 또는 둘 다
  7. 다음에 할 일
  8. 자주 묻는 질문

Databricks vs Microsoft Fabric의 선택은 결국 누가 데이터를 소비하느냐로 귀결됩니다. 데이터 대부분이 Power BI로 가고 팀이 SQL로 생각한다면, 보통 Fabric이 더 빠르고 단순한 선택입니다. 어려운 문제가 엔지니어링, 스트리밍, 머신러닝, 또는 둘 이상의 클라우드라면 Databricks가 더 강한 플랫폼입니다.

Microsoft 중심의 많은 조직에게 솔직한 답은 둘 다입니다. 무거운 엔지니어링은 Azure Databricks가 맡습니다.

Fabric과 Power BI는 현업을 지원합니다. 이 방식은 효과가 있지만, 둘 사이의 이음매를 의도적으로 설계할 때만 그렇습니다.

제가 참여한 제조와 방위 산업 프로그램에서 결정이 기능 목록으로 갈리는 경우는 드물었습니다. 비용 모델, 역량, 보안 경계, 그리고 데이터가 어디에 있어도 되는지로 결정됩니다.

둘 다 개방형 테이블 포맷 위의 레이크하우스입니다. 차이는 스토리지를 누가 소유하는지, 컴퓨트 비용을 어떻게 내는지에 있습니다.

Microsoft Fabric은 SaaS 플랫폼입니다. 모든 데이터는 테넌트당 하나의 논리적 레이크인 OneLake에 들어가며, 테이블은 Delta 포맷으로 저장됩니다. 레이크하우스, 웨어하우스, 파이프라인, Real-Time Intelligence, Power BI가 모두 하나의 공유 용량을 사용합니다.

바로 가기(shortcut)는 다른 저장소의 데이터를 복사하지 않고 가리킵니다. 미러링은 데이터베이스와 외부 카탈로그를 가져옵니다.

Databricks는 귀사의 클라우드 계정에서 실행됩니다(Azure에서는 Microsoft의 퍼스트 파티 서비스인 Azure Databricks). 데이터는 귀사 소유의 스토리지에 있고 Unity Catalog가 거버넌스를 맡습니다. 컴퓨트는 클러스터, SQL 웨어하우스, 서버리스이며 워크로드별로 Databricks Units(DBU) 단위로 계량됩니다.

개방성 측면에서는 격차가 좁혀졌습니다. OneLake는 메타데이터를 가상화하므로 Delta 테이블을 Iceberg로, Iceberg 테이블을 Delta로 읽을 수 있습니다. 실제 제약도 있습니다. Parquet만 지원하고, Iceberg 출력은 V2이며, equality delete가 있으면 변환이 깨집니다.

Unity Catalog의 관리형 Iceberg 테이블은 정식 제공(GA) 중이며, 외부 엔진은 Unity Catalog의 Iceberg REST Catalog API를 통해 읽고 씁니다. 어느 플랫폼도 데이터를 독점 포맷에 가두지 않습니다. 둘 다 파이프라인, 보안 모델, 역량을 묶어 두며, 실제 전환 비용은 거기에 있습니다.

Microsoft 중심 조직에게 가장 중요한 것은 둘 사이의 다리입니다. Fabric은 Azure Databricks Unity Catalog를 미러링해 카탈로그 항목으로 둘 수 있으며, 이 기능은 정식 제공 중입니다. 미러링되는 것은 메타데이터뿐입니다.

데이터는 바로 가기를 통해 원래 위치에서 읽습니다. 함정이 하나 있습니다. Unity Catalog 권한은 넘어가지 않습니다. Fabric은 자체 권한 모델을 적용합니다.

Fabric은 F2부터 F8192까지 F-SKU로 용량을 판매하며, 용량 단위(CU)로 측정합니다. Azure는 약정 없이 초 단위로 청구하거나, 1년 예약으로 구매할 수 있습니다. East US의 종량제 정가는 CU-시간당 $0.18입니다.

그러면 F64는 시간당 약 $11.52이고, 계속 켜 두면 월 약 $8,400입니다. Microsoft는 예약을 하면 종량제 대비 약 41%를 절감한다고 말합니다.

OneLake 핫 스토리지 정가는 GB당 월 $0.026입니다. Microsoft Fabric 가격 페이지를 참고하십시오.

F64는 라이선스 기준선이기도 합니다. Fabric 라이선스 문서에 따르면 F64 미만에서는 Power BI 콘텐츠를 보는 모든 사람에게 Pro 또는 Premium Per User 라이선스가 필요합니다.

F64 이상에서는 무료 라이선스와 뷰어 역할을 가진 사용자도 리포트를 볼 수 있습니다. 리포트 열람자가 수백 명이라면 이것 하나로 SKU가 결정될 수 있습니다.

Azure Databricks는 워크로드 유형별로 DBU를 청구하며, 클래식 컴퓨트의 경우 그 아래의 Azure 가상 머신 비용이 추가됩니다. 서버리스 요금에는 컴퓨트가 포함됩니다.

East US Premium 정가는 아래와 같습니다. Azure Databricks 가격 페이지를 참고하십시오.

  1. Jobs 컴퓨트: DBU-시간당 $0.30.
  2. All-purpose 컴퓨트(대화형 노트북): DBU-시간당 $0.55.
  3. SQL Pro: DBU-시간당 $0.55. Serverless SQL: DBU-시간당 $0.70.
  4. 서버리스 작업: DBU-시간당 $0.45. 서버리스 대화형 컴퓨트: DBU-시간당 $0.95.

모든 수치는 East US 기준 정가이며, 2026년 10월에 확인했습니다. 다른 리전은 다릅니다.

엔터프라이즈 계약, Databricks 사전 구매 약정, Azure 예약이 실제 금액을 바꿉니다. DBU에 대해서는 제 Databricks 가격 가이드에서 더 깊이 다룹니다.

실무에서 이것이 의미하는 바는 다음과 같습니다.

  1. Fabric은 예측 가능하지만 공유됩니다. 무거운 Spark 작업 하나가 같은 용량의 Power BI 리포트를 느리게 만들 수 있습니다. 누군가는 공유 서버처럼 용량을 관리해야 합니다.
  2. Databricks는 세분화되어 있지만 새는 곳이 있습니다. 각 워크로드는 사용한 만큼 정확히 비용이 듭니다. 켜 둔 채 방치된 클러스터, 과도한 크기의 웨어하우스, 예약 작업에 쓰인 all-purpose 컴퓨트가 흔한 누수 지점입니다.
  3. 실제 워크로드로 총비용을 비교하십시오. 상위 10개 파이프라인과 가장 바쁜 리포팅 시간대를 두 플랫폼에서 각각 견적 내십시오. 정가를 나열한 스프레드시트는 아무것도 증명하지 못합니다.

아래 표는 Microsoft 중심 조직에서 보통 결정을 좌우하는 항목을 다룹니다.

기준Microsoft FabricDatabricks(Azure Databricks)
제공 모델SaaS, 테넌트 전체에 하나의 OneLake귀사의 클라우드 계정과 스토리지 안의 플랫폼
가격F-SKU 용량, 종량제 또는 예약워크로드별 DBU, 클래식 컴퓨트는 VM 비용 추가
데이터 엔지니어링 깊이SQL, 파이프라인, Dataflows, Spark 노트북에 적합더 깊음: Spark 튜닝, 스트리밍, 선언적 파이프라인, CI/CD
ML과 생성형 AICopilot in Fabric, Fabric 데이터 에이전트(GA), ML 모델과 실험모델 서빙, MLflow, Genie, Agent Bricks
Power BI네이티브, OneLake 위의 Direct LakeFabric으로 미러링하거나 DirectQuery 및 Import 사용
거버넌스Fabric 권한, OneLake 보안, Purview, 민감도 레이블Unity Catalog, Purview로 스캔 가능
멀티 클라우드Azure 전용Azure, AWS, Google Cloud
역량 적합성Power BI, SQL, Microsoft 데이터 팀데이터 엔지니어, Python과 Spark, ML 엔지니어

Power BI와 Direct Lake. Direct Lake를 사용하면 Power BI 시맨틱 모델이 OneLake의 Delta 테이블을 가져오기 새로 고침 없이 바로 메모리로 읽습니다. Fabric을 쓸 가장 강력한 이유입니다.

Fabric 용량이 필요하며, 테이블 한도는 SKU에 따라 올라갑니다. 미러링된 Azure Databricks 카탈로그는 지원되는 Direct Lake 소스이므로, Databricks에서 만든 골드 테이블이 Direct Lake 리포트에 데이터를 공급할 수 있습니다.

ML과 생성형 AI. OneLake 데이터에 대한 일상 언어 질문에 답하는 Fabric 데이터 에이전트는 정식 제공 중입니다. Microsoft 365 Copilot에서 이를 사용하는 것 같은 일부 통합은 아직 프리뷰입니다. Copilot in Fabric은 유료 F2 이상의 용량이 필요하며 그 용량을 소비합니다.

Databricks에서는 Genie를 통해 현업 사용자가 거버넌스가 적용된 테이블에 일상 언어로 질의할 수 있습니다. Agent Bricks는 코드로 맞춤형 에이전트를 구축하고 배포하는 플랫폼입니다.

Databricks는 현재 Knowledge Assistant와 Supervisor Agent를 레거시로 분류하고, 새로운 로우코드 작업은 Genie Agents로 안내합니다. 자세한 내용은 제 Genie와 Agent Bricks 글에서 다룹니다.

거버넌스. Unity Catalog는 여러 워크스페이스와 클라우드에 걸쳐 테이블, 모델, 계보, 세분화된 접근을 관리하는 단일 컨트롤 플레인으로서 더 성숙합니다. Fabric 거버넌스도 빠르게 개선되고 있습니다.

Microsoft 환경에서는 Purview가 이미 전사 카탈로그인 경우가 많으며, Unity Catalog의 메타데이터와 계보를 스캔할 수 있습니다. Databricks 쪽은 제 Unity Catalog 거버넌스 가이드에서 다룹니다.

실패하는 것은 대개 플랫폼이 아닙니다. 두 플랫폼 사이의 운영 모델입니다.

제가 보는 Microsoft 중심 조직 대부분은 하나만 고르지 않습니다. 수집, 엔지니어링, ML은 Azure Databricks에서 실행하고, 정제된 테이블을 Power BI용으로 Fabric에 노출합니다. 카탈로그 미러링과 Direct Lake 덕분에 이 패턴은 이제 잘 지원됩니다.

이 패턴은 세 가지가 충족될 때 효과가 있습니다.

  1. 계층마다 하나의 플랫폼이 소유합니다. 브론즈부터 골드까지는 Databricks가 소유합니다. 시맨틱 모델과 리포트는 Fabric이 소유합니다. 같은 테이블을 양쪽에서 다시 만드는 사람은 없습니다.
  2. 보안은 두 번 설계하되, 한 번에 설계합니다. 미러링은 Unity Catalog 권한을 복사하지 않습니다. Fabric에서 행 수준과 열 수준 규칙을 누가 소유할지 정하고, 그 매핑을 문서화하십시오.
  3. 두 플랫폼의 청구서를 한 사람이 책임집니다. DBU와 용량은 서로 다른 비용 항목에 있습니다. 책임자가 한 명이 아니면 팀마다 자기 플랫폼만 최적화하고 총액은 올라갑니다.

Fabric이 슬그머니 두 번째 엔지니어링 플랫폼이 되어, 서로 맞지 않는 골드 계층이 두 개 생길 때 이 패턴은 실패합니다. 제가 본 "둘 다 쓰기"가 잘못된 경우는 두 가지로 귀결되었습니다. 플랫폼 간 통합이 제대로 되지 않았고, 어느 플랫폼이 데이터를 소유하는지 아무도 몰랐습니다. 저는 나중에 엉킨 것을 푸느니 첫날 규칙을 정하겠습니다.

ERP 데이터(SAP, Oracle, Microsoft Dynamics 365)에도 같은 논리가 적용됩니다. 한 곳에서 한 번만 적재하고 모델링하십시오. ERP 쪽이 플랫폼만큼 중요한 이유는 ERP 현대화와 클린 코어에 관한 제 글에서 설명합니다.

제조. 공장 데이터가 스트레스 테스트입니다. 히스토리안과 MES 피드, 고빈도 센서 스트림, ERP와 결합된 품질 및 정비 기록이 있습니다. Fabric의 Real-Time Intelligence(이벤트스트림과 이벤트하우스)는 운영 대시보드를 잘 처리합니다.

대규모 스트리밍 엔지니어링, 예지 정비를 위한 피처 파이프라인, 센서 데이터 기반 ML에는 저는 Databricks를 씁니다. 제 업무에서 Databricks가 제 몫을 하는 곳은 센서와 설비 데이터에 대한 스트리밍과 머신러닝입니다.

방위 산업. 주권과 분리가 먼저입니다. 기밀 환경과 비기밀 환경은 분리된 채로 유지됩니다. 수출 통제 데이터(범주로서의 ITAR)에는 엄격한 접근 통제와 감사가 필요합니다.

프로그램은 수십 년 동안 이어집니다. 여기서는 무엇이든 설계하기 전에 제공 여부를 확인하십시오. 정부 클라우드는 상용 Azure보다 늦기 때문입니다.

  1. GCC High의 Fabric. 2026년 10월에 확인한 Microsoft Learn에 따르면 Fabric은 US Gov Virginia와 US Gov Texas에서 실행됩니다. 레이크하우스, 웨어하우스, 파이프라인, Direct Lake를 포함한 Power BI 등 핵심 워크로드를 사용할 수 있습니다. 고객 관리형 키, 대부분의 미러링 소스, 워크스페이스 Private Link, Copilot for Power BI는 지원되지 않습니다. GCC High에 대한 FedRAMP High 인가는 아직 평가 중입니다.
  2. Azure Government의 Azure Databricks. 2026년 10월 1일에 업데이트된 Azure Databricks 리전별 기능 목록에 따르면 US Gov 리전은 Databricks SQL과 Unity Catalog를 지원하지 않습니다. 서버리스와 새로운 AI 기능도 없습니다. Databricks는 전체 플랫폼을 Azure Government에 제공할 계획을 발표했습니다. 결정하는 당일에 귀사 리전에서 실제로 제공되는 것을 확인하십시오.

미국 밖에서도 같은 원칙이 적용됩니다. 귀사가 묶여 있는 정확한 Azure 리전의 리전별 표를 확인하십시오. 일부 리전에서는 Databricks의 여러 서버리스 및 AI 기능이 지역 간 처리를 필요로 하며, 이는 주권 데이터에는 아예 불가능한 조건일 수 있습니다.

다음과 같은 경우 Fabric을 선택하십시오.

  1. Power BI가 주요 소비자이고 Direct Lake를 원하는 경우.
  2. 팀이 SQL, Power BI, Microsoft 중심이고 Spark 역량이 얕은 경우.
  3. 플랫폼 엔지니어링이 아니라 하나의 용량 청구서와 SaaS 운영을 원하는 경우.
  4. 리포트 열람자가 수백 명이고 F64 라이선스로 수치가 맞는 경우.

다음과 같은 경우 Databricks를 선택하십시오.

  1. 리포팅이 아니라 데이터 엔지니어링, 스트리밍, ML이 어려운 부분인 경우.
  2. 둘 이상의 클라우드에서 운영하거나 그럴 예정인 경우.
  3. 여러 워크스페이스에 걸친 단일 거버넌스 플레인으로 Unity Catalog가 필요한 경우.
  4. 워크로드별로 엄격하게 비용을 통제해야 하고, 이를 관리할 역량이 있는 경우.

둘 다 선택할 경우는 이미 Azure Databricks를 잘 운영하고 있고 현업이 Power BI 안에서 일하는 경우입니다. Unity Catalog를 Fabric으로 미러링하고, 리포트에는 Direct Lake를 쓰고, 각 계층을 누가 소유하는지 문서로 남기십시오.

이미 성숙한 Databricks 플랫폼을 운영하고 있다면 BI 비용을 아끼려고 Fabric으로 마이그레이션하지 마십시오. 더 넓은 관점은 제 Snowflake vs Databricks 비교를 참고하십시오.

실제 워크로드 세 가지로 2주간 동일 조건 테스트를 진행하십시오. 무거운 파이프라인 하나, 경영진용 Power BI 모델 하나, ML 또는 AI 활용 사례 하나입니다. 실행당 비용, 새로 고침 지연 시간, 팀에 필요했던 노력을 측정하십시오. 벤더나 SI에게 바로 그 조합을 귀사가 협상한 단가로 견적 내 달라고 요청하십시오.

각 벤더에게 세 가지를 물으십시오. 우리 리전에서 무엇이 GA이고 무엇이 프리뷰인지, 사용량이 두 배가 되면 비용이 어떻게 되는지, 그리고 이음매를 넘어 보안이 어떻게 작동하는지입니다.

플랫폼 결정이나 테스트 설계에 대해 독립적인 의견이 필요하시면, 저는 바로 이런 일을 돕고 있습니다. 30분 상담을 예약하실 수 있습니다.

Microsoft Fabric이 Azure Databricks를 대체합니까?

아닙니다. Azure Databricks는 여전히 Azure의 퍼스트 파티 서비스이며, Microsoft는 두 제품이 함께 작동하는 방식을 문서로 제공합니다. Fabric은 Azure Databricks Unity Catalog를 미러링할 수 있고(정식 제공), 따라서 Power BI가 데이터를 복사하지 않고 Direct Lake를 통해 Databricks 테이블을 사용할 수 있습니다. 많은 조직이 둘 다 운영합니다.

Fabric이 Databricks보다 저렴합니까?

워크로드 구성에 따라 다릅니다. Fabric은 공유 용량입니다(East US 정가 CU-시간당 $0.18, 1년 예약 시 약 41% 저렴). Databricks는 워크로드별 DBU에 더해 클래식 컴퓨트의 VM 비용을 청구합니다. 귀사의 주요 워크로드를 두 플랫폼에서 각각 견적 내십시오.

Power BI가 Fabric 없이 Databricks 데이터를 사용할 수 있습니까?

네. Power BI는 Import 또는 DirectQuery 모드로 Databricks SQL 웨어하우스에 연결됩니다. Direct Lake에는 Fabric 용량이 필요하며, 미러링된 Azure Databricks 카탈로그는 지원되는 Direct Lake 소스입니다.

Unity Catalog 보안이 Fabric으로 이어집니까?

아닙니다. Fabric이 Azure Databricks 카탈로그를 미러링할 때는 메타데이터를 미러링하고 바로 가기를 통해 데이터를 읽습니다. Unity Catalog 정책과 권한은 미러링되지 않으므로 Fabric 자체 권한 모델이 적용됩니다. Fabric 쪽에서 접근 규칙을 설계하고 문서화하십시오.

Microsoft Fabric은 Azure Government에서 사용할 수 있습니까?

Fabric은 GCC High 환경의 US Gov Virginia와 US Gov Texas에서 실행되며, 상용 Fabric보다 기능 범위가 좁습니다. 2026년 10월 Microsoft Learn 기준으로 고객 관리형 키, 대부분의 미러링 소스, Copilot for Power BI는 지원되지 않습니다. GCC High에 대한 FedRAMP High는 아직 평가 중입니다. 계획하기 전에 최신 목록을 확인하십시오.

머신러닝에는 Databricks와 Fabric 중 무엇이 더 낫습니까?

Databricks가 더 깊은 ML 및 생성형 AI 도구를 갖추고 있습니다. MLflow, 모델 서빙, Genie, 맞춤형 에이전트를 위한 Agent Bricks입니다. Fabric은 ML 실험과 모델, 데이터 에이전트(GA), Copilot을 제공하며, 데이터 에이전트는 Microsoft Foundry에서 사용할 수 있습니다(프리뷰). ML이 부가 기능이 아니라 핵심 역량이라면 보통 Databricks가 더 강한 기반입니다.

Noel D'Costa

글쓴이

Noel D'Costa

항공, 정부, 금융, 유통, 제조 분야의 SAP 및 Oracle ERP 프로젝트에서 25년을 일했습니다. 재무 출신입니다. 경영진이 혁신의 범위를 현실적으로 정하고, 어려움에 처한 프로젝트를 정상화하며, 운영 첫해를 견뎌 내는 시스템을 구축하도록 돕습니다.

다음 단계

지금 ERP 프로젝트를 진행 중이십니까?

이 글이 지금 진행 중인 프로젝트와 맞닿아 있다면, 30분 대화가 일주일간의 내부 분석보다 대개 더 많은 진전을 가져옵니다.