제가 대화하는 대부분의 ISV(독립 소프트웨어 공급업체) 제품 팀들은 Microsoft Fabric 앱을 AppSource 등록과 아무도 관리하지 않는 Teams 앱 사이의 어딘가에 있는 "마켓플레이스 전략"으로 분류해 왔습니다. 이는 잘못된 사고 모델이며, 일부 팀에게는 자신들의 카테고리를 잃게 만드는 비용을 치르게 할 것입니다.

Fabric Workload Dev Kit으로 구축된 워크로드(Workload)는 Fabric 옆에 덧붙여진 애드인(add-in)이 아닙니다. 그것은 구매자의 데이터 팀이 이미 일과를 보내고 있는 도구 내부에서 Lakehouse, Power BI, 그리고 Data Factory 옆에 렌더링되는 네이티브 서피스(native surface)입니다. 이는 이것이 유통(distribution) 결정임을 의미하며, 락인(lock-in) 위험이 수반되는 유통 결정은 관망하는 자세가 아니라 실제적인 평가를 거쳐야 합니다. 여기 90일 이내에 그 결정을 내릴 수 있는 프레임워크가 있습니다.

Fabric 앱의 실제 정체 (그리고 정체가 아닌 것)

Ignite 2024에서 정식 출시(GA)된 Fabric Workload Development Kit을 사용하면 Fabric 테넌트(tenant)에 자신만의 아이템 유형을 등록할 수 있습니다. 여러분의 워크로드는 실제적인 존재감을 갖게 됩니다: 워크스페이스(workspace)에 존재하는 아이템, Fabric 셸(shell) 내부에서 렌더링되는 UI, OneLake에 대한 읽기 및 쓰기 권한, 그리고 on-behalf-of 토큰을 사용하여 Microsoft Entra ID를 통해 흐르는 인증을 통해, 여러분의 앱은 신급 권한을 가진 서비스 계정이 아니라 로그인한 사용자로서 동작합니다.

무엇이 자동이고 무엇이 자동이 아닌지에 대해 정확히 파악하십시오. Workload Hub를 통한 탐색과 Fabric 셸에서의 렌더링은 플랫폼과 함께 제공됩니다. Entra ID 인증 흐름, 아이템 생명주기 관리, 그리고 커스텀 아이템에 대한 거버넌스(governance) 동작은 개발 키트(dev kit)의 계약(contracts)에 따라 직접 구현해야 하는 사항들입니다. 그리고 여러분의 백엔드(backend)는 여러분 자신의 인프라에서 실행됩니다. Fabric은 여러분에게 요청을 중개(broker)할 뿐, 여러분의 컴퓨팅(compute)을 호스팅하지 않습니다.

이것은 ISV(독립 소프트웨어 공급업체)가 이전에 Microsoft 생태계에 출시했던 그 어떤 것과도 다른 종류의 것입니다. Power BI 커스텀 비주얼 (custom visual)은 렌더링 컴포넌트 (rendering component)입니다. Teams 앱은 협업 인터페이스 (collaboration surface)입니다. Azure Marketplace SaaS 리스팅 (listing)은 데이터 평면 (data-plane) 결합이 전혀 없는 상거래 계약입니다. 반면, Fabric 워크로드 (workload)는 고객의 테이블 바로 옆, 데이터 평면 (data plane) 자체에 위치합니다.

"앱 스토어"라는 프레임워크가 모호하게 만드는 한 가지 명확한 점은 다음과 같습니다. Workload Hub는 제품 내에서의 탐색(discovery)과 배포(deployment)를 담당합니다. 조달(procurement)과 수익화(monetization)는 여전히 여러분의 자체적인 상업적 활동이나 Azure Marketplace 트랜잭션을 통해 이루어집니다. Fabric은 "대금 결제를 받는" 문제를 해결하는 것이 아니라, "구매자의 도구 내부에서 구매자 앞에 나타나는" 문제를 해결합니다.

문서에는 엔지니어링의 난이도가 과소평가되어 있습니다

Workload Dev Kit 문서는 등록 과정을 단순한 설정 작업처럼 보이게 만듭니다. 실제로 프론트엔드/백엔드 계약 (contract), 아이템 CRUD 라이프사이클 (lifecycle), 그리고 작업 스케줄링 통합 (job scheduling integration)에는 실제 엔지니어링 시간이 소요되며, 샘플 워크로드는 오직 해피 패스 (happy path)만을 다룹니다. 해커톤 수준이 아닌, 제대로 된 빌드를 위한 예산을 책정하십시오. 이는 단순히 측정된 추정치가 아니라 계약 내용을 면밀히 검토한 결과에 따른 판단입니다. 여러분 팀의 수치는 달라질 수 있습니다.

핵심 요점: 이것은 플랫폼 네이티브 (platform-native) 소프트웨어입니다. 단순히 최신 상태를 유지해야 할 또 다른 리스팅 (listing)이 아니라, 플랫폼에 대한 베팅으로서 플랫폼 베팅에 걸맞은 실사 (due diligence)를 통해 평가하십시오.

Microsoft Fabric 앱 뒤에 숨겨진 유통 수학 (distribution math)

엔터프라이즈 SaaS 계약은 두 곳에서 무산됩니다: 조달 (procurement)과 보안 검토 (security review)입니다. 엔터프라이즈 시장에 판매하는 모든 데이터 벤더는 이 의례를 알고 있습니다. 벤더 보안 설문지, 데이터 레지던시 (data residency) 검토, 새로운 DPA (데이터 처리 합의서), 고객의 데이터가 머물게 될 네트워크 아키텍처 다이어그램 등이 그것입니다.

이제 Fabric 네이티브 워크로드 (Fabric-native workload)가 구조적으로 무엇을 변화시키는지 살펴보겠습니다. 고객의 데이터는 그들의 테넌트 (tenant)를 떠나지 않습니다. 여러분의 워크로드는 고객의 기존 워크스페이스 역할 (workspace roles) 및 민감도 레이블 (sensitivity labels) 하에 있는 OneLake 데이터 위에서 작동합니다. ID (Identity)는 그들의 Entra ID입니다. 플랫폼 관계는 이미 그들의 Microsoft 계약 하에 존재합니다. 이것이 마찰을 얼마나 줄여주는지에 대해 수치를 붙이지는 않겠습니다. 왜냐하면 아무도 이를 발표한 적이 없으며, 저는 임의로 지어내는 것을 거부하기 때문입니다. 하지만 논리는 반박하기 어렵습니다. 고객이 이미 신뢰하고 있는 모든 제어 수단은 여러분이 처음부터 다시 시작하지 않아도 되는 검토 항목 하나를 의미합니다. 여러분의 백엔드 (backend)는 여전히 여러분의 백엔드이기 때문에 일부 검토는 남아있겠지만, 노출 면적 (surface area)은 줄어듭니다.

다음은 혼잡도 문제입니다. Microsoft는 Build 2024에서 11,000개 이상의 조직이 Fabric을 사용하고 있다고 밝혔으며, 그 숫자는 이후 더 증가했습니다. 반면 워크로드 허브 (Workload Hub)는 빈약합니다. Microsoft의 자체 Ignite 2024 발표에서는 Esri, SAS, Informatica, Teradata를 포함한 소수의 출시 파트너만을 언급했습니다. 해당 고객 기반을 가진 플랫폼치고는 짧은 목록입니다. 출시 첫날의 AppSource와 오늘날의 AppSource를 비교해 보십시오.

저는 강한 입장을 취하겠습니다. 데이터 인접 ISV (data-adjacent ISVs)들에게 이것은 AppSource가 출시된 이후 Microsoft가 제공한 가장 저렴한 엔터프라이즈 유통 채널입니다. 허브에 수천 개의 타일 대신 수십 개의 타일만 있을 때, 초기 진입자들은 카테고리 포지셔닝 (category positioning)을 선점할 수 있습니다. 이 기회의 창은 언제나 그렇듯, 조용히 시작되어 어느 순간 한꺼번에 닫힐 것입니다.

OneLake의 트레이드오프 (trade): 상호 운용성 이야기, 용량 모델 (capacity-model)의 현실

여기서부터는 응원이 멈춥니다. 왜냐하면 이 트레이드오프 (trade)에는 실질적인 대가가 따르기 때문입니다.

먼저 긍정적인 측면부터 살펴보겠습니다. Fabric-native(Fabric 네이티브)로 구축한다는 것은 데이터 모델이 OneLake의 Delta Lake 테이블에 존재함을 의미하며, 이는 내부적으로 오픈 포맷인 Parquet를 사용합니다. 이는 진정으로 강력한 OneLake ISV(독립 소프트웨어 벤더) 통합 사례입니다. 고객은 데이터의 사본을 하나만 유지하면서도, 오픈 포맷을 통해 자신의 환경에 있는 모든 엔진과 귀사의 엔진 모두에서 읽을 수 있습니다. 독점적인 스토리지 계층도, 내보내기(export) 파이프라인도, "이제 귀하의 데이터는 우리 클라우드에 있습니다"라는 식의 대화도 필요 없습니다. 데이터 사일로(data silo)로 고통받는 고객들에게 이것은 Fabric 워크로드가 가질 수 있는 최고의 판매 논거(sales argument)입니다. 저는 이전에도 OneLake가 어떻게 데이터 아키텍처를 단축시키는지에 대해 쓴 적이 있으며, 동일한 제로 카피(zero-copy) 로직이 ISV에게도 유리하게 작용합니다.

이제 제약 사항(the cage)입니다. 귀사의 매출원가(cost of goods)가 Microsoft의 용량 단위(capacity unit) 모델과 얽히게 됩니다. Fabric 컴퓨팅은 F SKU 전반에 걸쳐 CU(Capacity Unit) 단위로 과금됩니다. Azure Fabric 가격 페이지에 따르면, 공개된 리스트 가격 기준으로 F64는 지역에 따라 다르지만 종량제(pay-as-you-go) 기준 시간당 약 $11.52이며, 예약(reservation)을 이용하면 훨씬 저렴해집니다. 이러한 가격은 Microsoft가 변경할 수 있으며, 스무딩(smoothing) 및 스로틀링(throttling) 동작 또한 Microsoft가 정의합니다. 만약 귀사의 마진 모델이 직접 튜닝할 수 있는 인프라 상에서 제어 가능한 컴퓨팅 비용을 가정했다면, 귀사는 방금 하나의 통제 수단(lever)을 포기한 셈입니다.

두 번째 리스크는 더 날카롭습니다. Microsoft는 퍼스트 파티(first-party) 워크로드를 공격적으로 출시합니다. 만약 귀사의 기능이 Fabric 로드맵에 있는 무언가와 인접해 있다면, 단 한 번의 릴리스 웨이브(release wave)만으로도 귀사의 서비스가 범용화(commoditized)될 수 있습니다. 데이터 수집(ingestion), 변환(transformation), 그리고 기본적인 BI는 이미 Microsoft의 영역입니다. 귀사의 지식 재산(IP)이 생존할 수 있는 유일한 방법은 스토리지 기질(storage substrate) 상단에 존재하는 것입니다. 즉, 도메인 로직(domain logic), 수직적 데이터 모델(vertical data models), 독점적인 ML(Machine Learning), 또는 Microsoft가 구축하지 않을 규제 준수 워크플로우(regulated workflows) 등이 되어야 합니다.

가격을 책정하기 전에 CU 동작 방식을 프로토타이핑하세요

실제 고객 부하(load) 하에서의 CU 소비량은 문서만으로는 예측하기 어렵습니다. 백그라운드 작업(Background jobs), 스무딩 윈도우(smoothing windows), 그리고 대화형 스파이크(interactive spikes)는 가격표가 시사하는 것과는 다르게 동작합니다. 가격 모델을 확정하기 전에, 체험용 용량(trial capacity)을 대상으로 대표적인 워크로드(workload)를 실행하고 측정하십시오. 그 이전에 수행하는 모든 모델링은 예시일 뿐입니다. 실제 수치를 바탕으로 보정(calibrate)하십시오.

핵심 요점: 이 '케이지 리스크(cage risk, 종속성 위험)'를 이사회 보고서(board deck)의 유통 측면의 이점(distribution upside)과 동일한 슬라이드에 명시하십시오. 고객 계약을 체결한 이후가 아니라 그전에 해야 합니다.

누가 Microsoft Fabric 커스텀 워크로드를 구축해야 하는가

적합성(Fit)은 귀하의 팀이 개발 키트(dev kit)를 사용하여 기술적으로 구축할 수 있는지 여부에 관한 것이 아닙니다. 역량 있는 플랫폼 팀이라면 거의 무엇이든 할 수 있습니다. 적합성은 귀하의 제품의 중력(gravity)이 어디에 위치하느냐에 관한 것입니다. 만약 귀하의 가치가 고객의 OneLake 데이터 옆에 위치함으로써 복리로 증가한다면, 이 채널은 귀하에게 유효합니다. 그렇지 않다면, 귀하는 타인의 쇼핑몰에서 비싼 부동산을 임대하고 있는 셈입니다.

강력한 적합성을 가진 카테고리는 출시 파트너 목록이 이미 암시하고 있는 것들입니다: 데이터 자산(data estate)에 대한 관측성, 데이터 품질 및 마스터 데이터 관리(MDM), 지리 공간 및 산업별 분석입니다.

여기에 저의 주관적인 휴리스틱(heuristic), 즉 측정된 임계값이 아닌 명백한 경험칙(rule of thumb)을 제시합니다: 만약 귀하의 영업 파이프라인 중 약 3분의 1 미만이 Microsoft 데이터 스택(data stack) 위에서 운영된다면, 당분간 Fabric-native 방식은 건너뛰고 1년 후에 다시 검토하십시오. 그 선 아래로 내려가면, 해당 워크로드(workload)는 귀하의 로드맵이 보조하는 부수적인 도박(side bet)이 되며, 플랫폼 채널에 대한 부수적인 도박은 빠르게 부패합니다.

이 결정은 귀하의 제품의 중력(gravity)이 어디에 위치하느냐에 따라 결정됩니다. 엔지니어가 무엇을 구축할 수 있느냐가 아닙.

Microsoft가 과소평가하고 있는 AI 관점

위의 모든 내용은 구매자를 브라우저에서 워크로드를 여는 인간으로 취급합니다. 그러한 프레임워크는 이미 구식이 되어가고 있습니다.

Fabric 워크로드는 OneLake 내의 관리되는 Delta 테이블(Delta tables)에서 작동하기 때문에, Microsoft가 테넌트(tenant) 자산 전반에 걸쳐 구축하고 있는 AI 경험(AI experiences)을 통해 접근할 수 있습니다. Fabric의 Copilot과 Fabric 데이터 에이전트(Fabric data agents)는 네이티브 워크로드가 연결되는 바로 그 데이터 레이어(data layer)를 기반으로 추론하며, 별도의 커스텀 커넥터(custom connectors)나 별도의 시맨틱 내보내기(semantic export)가 필요하지 않습니다. 특정 에이전트 기능의 미리 보기(preview) 대 정식 출시(GA) 상태를 확인한 후 이를 기반으로 구축하십시오. 이 기능들은 분기마다 변화합니다.

여기에 미래 지향적인 논거를 제시합니다. 아무도 미래를 인용할 수 없기에 저는 이를 그렇게 명명합니다: 장기적인 보상은 인간이 여는 대시보드(dashboard)가 아니라, 에이전트가 호출하는 워크로드가 되는 것입니다. 앱 스토어(app-store)의 역학 관계는 새로운 사용자와 함께 반복됩니다. 테넌트의 데이터 자산(data estate)을 오케스트레이션(orchestrating)하는 에이전트가 데이터 품질 점수, 엔티티 해상(entity resolution), 또는 수직적 리스크 모델(vertical risk model)이 필요할 때, 에이전트는 등록되어 있고 관리되며 데이터와 인접한 모든 기능을 호출할 것입니다. 자산 외부의 워크로드는 호출되지 않습니다.

오늘 특정 에이전트 API를 대상으로 구축하지 마십시오. 그것들을 불안정한 것으로 취급하십시오. 대신 지속 가능한 위치를 구축하십시오: 즉, 오픈 Delta 형식의 데이터, 관리되는 항목(governed items)으로 노출된 운영, 그리고 다음에 자산을 오케스트레이션할 무엇인가에게 읽힐 수 있는 가치를 구축하는 것입니다.

귀하의 워크로드를 '에이전트 준비가 된 데이터 및 액션(agent-ready data plus actions)'으로 포지셔닝한다면, 귀하는 다음 유통 변화(distribution shift)에 반응하는 대신 그 변화에 앞서 나가게 될 것입니다.

90일 평가 프레임워크

엔지니어 1인당 1분기(one engineer-quarter)의 투입은 근거에 기반한 의사결정을 가능하게 합니다. 플랫폼 채널에 뒤처지는 것은 시장 지위를 잃는 것을 의미합니다. 이것이 비용 대비 편익(cost-benefit)의 전부입니다.

첫날이 되기 전에 중단 기준(kill criteria)을 서면으로 정의하십시오. CU(Capacity Unit) 경제성이 귀하의 마진 모델을 깨뜨리거나, 구매자가 Fabric에 없다는 것이 입증된다면 그 베팅은 종료됩니다. 그 외의 모든 것은 소음일 뿐입니다.

1. 1일 차부터 30일 차까지: 개발 키트(dev kit)를 활용한 프로토타입 제작 Fabric Workload Dev Kit을 사용하여 얇은 수직적 슬라이스(thin vertical slice)를 구축하십시오. 하나의 아이템 유형, 실제 Entra on-behalf-of 인증, 샘플 워크로드에 대한 실제 OneLake 읽기 및 쓰기를 포함해야 합니다. 목표는 데모를 보여주는 것이 아닙니다. 목표는 문서에서 간과하는 프론트엔드/백엔드 계약(contract) 작업과 라이프사이클 처리 과정을 드러내는 것입니다. 이를 통해 귀하의 공수 산정(effort estimate)이 Microsoft의 샘플이 아닌, 귀하의 코드베이스에 기반하도록 해야 합니다.
2. 31일 차부터 60일 차까지: 현재 지출 대비 CU 경제성 모델링 시험용 용량(trial capacity)에서 대표적인 부하를 실행하여 CU 소비량을 측정하고, 공개된 Fabric 리스트 가격을 사용하여 고객 규모에서의 비용을 모델링하십시오. 실제 수치를 확보하기 전까지는 모든 숫자를 예시로 취급하십시오. 업계 표준 입력값은 시작점일 뿐이며, 귀하의 워크로드 형태에 따라 결과는 달라질 것입니다. 결과를 현재의 클라우드 매출원가(COGS) 및 귀하의 최저 가격선(pricing floor)과 비교하십시오.
3. 61일 차부터 90일 차까지: 세 곳의 디자인 파트너와 함께 압박 테스트 수행 현재 Fabric을 운영 중인 세 곳의 고객 또는 잠재 고객에게 프로토타입을 가져가십시오. 두 가지 질문을 던지십시오. 귀하의 SaaS 대신 그들의 테넌트(tenant) 내부에 귀하의 워크로드를 배포할 의사가 있는지, 그리고 상속된 거버넌스(inherited governance)가 귀하와 같은 벤더에 대한 검토 프로세스를 실제로 단축시키는지 여부입니다. 그들의 답변은 Fabric 네이티브(Fabric-native)가 귀하의 제품에 있어 유통 채널(channel)인지, 아니면 감옥(cage)인지를 알려줄 것입니다.

비용 모델링 단계와 관련하여, 저는 평활화(smoothing) 및 백그라운드 작업이 단순한 시간당 계산을 어떻게 왜곡하는지를 포함하여 Fabric 용량 비용 모델링을 더 심도 있게 다룬 바 있습니다.

90일이라는 타임박스(timebox)는 저렴한 보험입니다. 결정이 어느 방향으로 나아가든, 타임박스를 건너뛰는 것은 비싼 선택이 될 것입니다.

이번 분기에 Microsoft Fabric 앱 도입 여부를 결정하십시오