최근 Microsoft Fabric 업데이트의 물결은 나에게 강한 인상을 남겼습니다. 로드맵에 추가된 또 다른 기능 체크박스 때문이 아니라, Fabric이 더 이상 데이터 웨어하우스(warehouses), 파이프라인(pipelines), 노트북(notebooks)만을 위한 "단순한" 플랫폼이 아니라는 점이 명확해졌기 때문입니다.

Fabric은 단순히 보고서(reports)를 넘어, 마치 하나의 제품처럼 느껴지는 **실제 분석 애플리케이션(real analytical applications)**을 출시할 수 있는 공간이 되어가고 있습니다.
이러한 깨달음이 제가 이 글을 쓰기로 결심한 이유이며, 저의 첫 번째 Fabric App을 만들기 시작한 이유입니다.

이 작업은 아직 초기 단계입니다. 저는 진행하면서 Fabric Apps의 영역을 배워나가고 있으며, 더 깊이 탐구한다면 훨씬 더 강력한 솔루션을 구축할 수 있을 것이라 확신합니다. 하지만 이 단계에서도 이미 이 패턴은 공유할 만큼 충분히 강력하게 느껴집니다.

Fabric Apps가 우리에게 주는 것

오랫동안 맞춤형 분석 경험(단순한 Power BI 페이지뿐만 아니라 자체 UI, 내비게이션, 워크플로 및 AI 코파일럿(AI copilots) 포함)을 원했다면, 여러분은 종종 다음과 같은 풀스택 제품을 설계해야 했습니다:

• 프론트엔드 (frontend)
• 백엔드 (backend)
• 인증 (authentication)
• API
• 호스팅 (hosting)
• 권한 관리 (permission plumbing)

그 방식은 여전히 유효합니다. 하지만 매우 무겁습니다.

Fabric Apps는 트레이드오프(trade-off)를 변화시킵니다.
경험이 Fabric 상에서 실행되고 플랫폼을 통해 여러분의 시맨틱 모델 (semantic model)(및 기타 Fabric 기능)과 통신할 수 있기 때문에, 여러분은 사용자가 실제로 접하는 제품의 표면인 **프론트엔드 레이어 (frontend layer)**에 훨씬 더 집중할 수 있습니다. 비즈니스 질문에 답하기 위해 전체 백엔드를 새로 만들 필요가 없습니다.

실제로 이는 다음과 같은 의미를 갖습니다:

• 단일 진실 공급원(source of truth)으로서의 하나의 공유된 시맨틱 모델 (semantic model)
• **네이티브 Power BI 시각화 요소 (native Power BI visuals)**와 **커스텀 React 인터페이스 (custom React interfaces)**를 결합할 수 있는 능력
• 클래식한 보고서 페이지가 잘 표현하지 못하는 UX 패턴을 위한 공간: 가이드형 내비게이션, AI 채팅, 스토리텔링, 인터랙티브 쇼케이스

이것은 "보고서를 게시하는 것"이라기보다 제품을 전달하는 것에 가깝게 느껴집니다. 즉, 단일 진실 공급원을 기반으로 구축되고 비즈니스 케이스에 맞춤화된 하나의 연결된 경험입니다.

이것이 보고(reporting)에 중요한 이유

이를 구체화하기 위해, 제가 생각하는 구분 방식은 다음과 같습니다:

흥미로운 점은 이들의 조합입니다:

• Power BI가 이미 뛰어난 성능을 보이는 곳 → 네이티브 보고서 (native report)를 임베드
• 경험이 제품(product)처럼 느껴져야 하는 곳 → 커스텀 페이지 (custom page) 구축
• 그리고 모든 곳에서 → 양쪽 모두를 **동일한 시맨틱 모델 (semantic model)**에 연결된 상태로 유지

비즈니스 케이스에 따라, 여러 개의 단절된 시스템으로 진실(truth)을 분산시키지 않고도 적절한 인터페이스를 선택할 수 있습니다.
이 점이 저를 가장 설레게 했습니다. Fabric Apps는 이러한 하이브리드 모델을 자연스럽게 만들어 줍니다.

내가 만든 것 (첫 번째 버전)

저는 판매 및 물류 (Sales & Logistics) 시맨틱 모델 (semantic model)을 중심으로 한 다중 페이지 Fabric App을 구축했습니다.
아래는 각 모듈에 대한 설명입니다. 우선은 개괄적인 수준으로 설명하겠습니다. 유용하다면 후속 포스트에서 특정 기능에 대해 더 자세히 다룰 수 있습니다.

1) 홈 (Home): 진입점

경험을 소개하고 사용자를 각 모듈로 안내하는 런치패드 (launchpad)입니다.

2) 커스텀 대시보드 (Custom Dashboard): 실시간 시맨틱 모델 분석

Fabric 시맨틱 모델 (semantic model)을 직접 쿼리하는 커스텀 React 대시보드입니다:

• KPI 카드
• 월간 트렌드
• 교차 필터링 (cross-filtering) 기능이 포함된 고객 순위
• 물류 뷰 (logistics views)
• CSV 내보내기
• 자동 생성된 "퀵 인사이트 (quick insights)"

이것은 Fabric Apps의 수제 제품 UI 측면입니다. Fabric REST API를 통해 시맨틱 모델 (semantic model)에 직접 쿼리하는 커스텀 React 레이어이지만, 네이티브 보고서와 동일한 비즈니스 로직을 공유합니다. 중복된 측정값 (measures)도 없고, 별도의 데이터 소스도 없습니다.

구현 참고 사항: 시맨틱 모델 (semantic model) 쿼리

const result = await getFabricClient()
  .semanticModel("model")
  .query(dax, { bypassCache: true });

KPI 및 차트는 Fabric 시맨틱 모델 (semantic model)에 대한 라이브 쿼리에 의해 구동됩니다.

3) 네이티브 Power BI 보고서: 앱 내부의 크롬리스 (chromeless) Power BI

사용자에게 보여주고 싶은 페이지에 대한 페이지 선택 기능과 함께, 앱 내부에 임베드된 (일반적인 크롬(chrome) 요소가 없는) 네이티브 Power BI 보고서입니다.

이것은 상호 보완적인 패턴을 보여줍니다. 이미 빛을 발하고 있는 강력한 Power BI 작업물은 그대로 유지하면서, 이를 동일한 앱 셸 (app shell) 내부에서 제공하는 방식입니다.

4) AI 어시스턴트: 실제 수치를 바탕으로 한 질문

시맨틱 모델 (semantic model)에서 계산된 결과를 사용하여 KPI 및 트렌드에 관한 질문에 답하는 AI 분석가입니다.
또한 질문의 언어(영어 또는 폴란드어)에 맞춰 적응합니다.

어시스턴트 전체의 형태를 결정지은 한 가지 설계 선택은, AI가 모든 질문에 대해 자유롭게 DAX를 생성하지 않도록 한 것입니다.

대신 제가 사용한 패턴은 다음과 같습니다:

• 미리 정의된 안전한 쿼리 세트가 핵심 KPI 및 트렌드를 커버합니다.
• 언어 모델 (language model)은 (원시 데이터가 아닌) 계산된 결과를 전달받아 이를 자연어로 해석합니다.
• 해당 범위를 벗어나는 질문에 대해서만 어시스턴트는 템플릿 기반의 응답으로 대체됩니다.

이것이 왜 중요할까요? LLM이 임의의 DAX를 생성하도록 허용하는 것은 데모에서는 인상적으로 보일 수 있지만, 실제 운영 환경(production)에서는 무너집니다. 계산된 지표(Computed metrics)를 우선시하고, 언어(language)를 마지막에 배치하십시오. 이 순서가 어시스턴트를 통제된 환경 밖에서도 실제로 사용 가능하게 만듭니다.

구현 참고 사항: AI를 실제 수치에 기반하도록 유지하기 (keeping AI grounded in real numbers)

const metrics = await fetchCoreMetrics();
return generateGeminiText({
  userPrompt: buildPrompt(question, metrics),
...

안전한 쿼리를 우선적으로 수행하고, 언어 모델(language model)은 오직 답변을 위해서만 사용하십시오.

5) 제품 쇼케이스 및 비주얼 랩(Visual Lab): 커스텀 UX의 모습

상호작용과 시각화에 초점을 맞춘 두 개의 쇼케이스 페이지입니다 (의도적으로 모의 데이터(mock data)를 사용함):

• 제품 드릴다운(drill-down) 패널
• 애니메이션 차트
• KPI 링(rings)
• 히트맵(heatmaps)
• 기타 커스텀 비주얼(custom visuals)

이 페이지들은 하나의 아이디어에 대한 개념 증명(proof of concept)입니다: Fabric Apps의 UI 한계치는 클래식 Power BI보다 훨씬 높다는 것입니다. 애니메이션 차트, KPI 링, 드릴다운 패널 등 이 모든 것은 표준 React를 사용하므로, Power BI 비주얼 마켓플레이스(visual marketplace)가 제공하는 것에 국한되지 않습니다.

도구(및 Cursor)에 관한 참고 사항

React 경험이 있더라도, 이러한 종류의 앱을 구축하는 데는 여전히 많은 구성 요소가 포함됩니다:

• 레이아웃 및 네비게이션(navigation)
• 임베딩(embedding) 및 토큰(tokens)
• 시맨틱 모델(semantic-model) 쿼리
• UX 다듬기(polish)
• 반복 속도(iteration speed)

Cursor가 큰 차이를 만들었습니다.
리포트 레이아웃과 페이지 구조를 잡는 것부터 기능을 구현하고 에지 케이스(edge cases)를 디버깅하는 것까지, Cursor는 작업 속도를 크게 가속화했습니다.
가장 도움이 되었던 영역은 React 컴포넌트 구조의 스캐폴딩(scaffolding), 토큰 및 임베딩 오류 디버깅, 그리고 파일 간의 컨텍스트를 잃지 않으면서 레이아웃을 반복 수정하는 것이었습니다.
저에게 있어 Cursor는 스택(stack)에 대한 이해를 대체하는 것이 아니라, 특히 플랫폼 자체가 여전히 빠르게 진화하고 있는 상황에서 힘을 배가시켜주는 증폭기(force multiplier)입니다.

이것은 시작일 뿐입니다

위의 모든 내용은 첫 번째 버전 (first version) 입니다. Fabric Apps를 더 깊이 파고들수록, 이것이 더 풍부한 솔루션을 위한 토대라는 점이 더욱 명확해집니다. 여전히 동일한 핵심 아이디어, 즉 Fabric 기반의 프론트엔드 우선 제공 (frontend-first delivery on top of Fabric) 을 유지하면서 말이죠.

이것은 아직 초기 빌드 단계입니다. 다음 포스트에서는 하나의 특정 기능에 대해 더 깊이 다룰 예정이며, 아마도 React 측에서의 시맨틱 모델 (semantic model) 쿼리 패턴이 될 가능성이 높습니다.

만약 여러분이 Fabric Apps, Power BI 임베딩 (embedding), 또는 시맨틱 모델 기반의 AI 코파일럿 (AI copilots)을 탐색하고 있다면 댓글을 남겨주세요. 여러분이 무엇을 만들고 있는지 정말 듣고 싶습니다.