UI를 넘어서: 데이터 파이프라인에 커스텀 API가 필요할 때

By Mirko Peters · 2026-08-11

팟캐스트 컴패니언 블로그에 다시 오신 것을 환영합니다! 최근 에피소드에서는 분석 아키텍처를 자세히 살펴보는 데 많은 시간을 들였는데, 오늘은 그 내용을 한층 깊이 다뤄 보겠습니다. …

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

팟캐스트 보조 블로그에 다시 오신 것을 환영합니다! 최근 에피소드에서는 분석 아키텍처를 깊이 있게 다뤄 왔습니다. 오늘은 성장하는 데이터 팀이 언젠가 반드시 마주치게 되는 전환 단계를 자세히 살펴보겠습니다. 표준 데이터 커넥터의 한계에 갇혀 있다고 느끼거나, 보고서를 수동으로 내려받아 겨우 운영을 유지하고 있다면 이 글이 도움이 될 것입니다. 이 주제에 관한 전체 오디오 논의를 듣고 싶다면 관련 에피소드 Extend Microsoft Fabric with Custom APIs and Power BI Models를 꼭 확인해 보시기 바랍니다.

비즈니스를 시작할 때는 사용자 인터페이스 중심의 데이터 로딩이 매우 편리하게 느껴집니다. 몇 번의 클릭으로 자격 증명을 입력하고 표준 SaaS 커넥터를 설정하면 바로 대시보드가 채워집니다. 하지만 조직이 성장하면서 이러한 편리한 UI 경로는 금세 경직된 병목이 됩니다. 레거시 ERP 시스템, 자체 개발한 웹 앱, 표준 커넥터로는 전혀 연결할 수 없는 IoT 스트림을 다루게 되는 것입니다. UI를 넘어서는 일은 단순한 기술적 야심이 아니라, 데이터 파이프라인이 안정적이고 안전하며 진정한 실시간성을 유지하도록 만드는 아키텍처상의 필수 요건입니다.

TL;DR

• UI 중심 방식은 지원되지 않는 소스, 커스텀 로직, 이벤트 기반 자동화가 필요해지기 전까지는 잘 작동합니다.
• 시스템을 연결하려면 커스텀 API를 사용하고, 로직과 보안을 표준화하려면 Power BI 모델을 사용하십시오.
• 앱 전용 인증, 최소 권한, 관찰 가능성, 거버넌스가 적용된 모델을 기준으로 설계하십시오.
• 사용자가 일하는 곳에서 분석을 활용할 수 있도록 Teams/SharePoint/앱에 인사이트를 내장하십시오.

UI를 넘어서야 할 때 (명확한 신호)

• 보고서를 유지하기 위해 CSV, 이메일, Excel 파일을 반복적으로 주고받는 경우
• 커넥터의 사각지대(레거시 ERP, 맞춤형 앱, IoT 피드)가 있는 경우
• "이 숫자가 왜 2일 전 데이터인가요?"라는 질문이 나오는 경우(배치 새로 고침이 오래되었고 이벤트 훅이 없는 상태)
• Power Query만으로는 맞지 않는, 여러 시스템에 걸친 복잡한 비즈니스 규칙이 있는 경우
• 그림자 프로세스로 인해 규정 준수 및 감사 문제가 우려되는 경우

참조 아키텍처

1) API를 통한 거의 실시간 처리 → Lakehouse → Power BI

• 원본 시스템 → 커스텀 API(앱 전용) → 수집 함수(Azure Functions/Logic Apps) → Lakehouse의 Delta/Parquet → Power BI 모델(증분 새로 고침/하이브리드)
• 용도: 운영 KPI, 시간 단위 새로 고침, 대용량 데이터

2) 이벤트 기반 웹후크

• 원본 웹후크 → API 수신기(토큰 검증, 이벤트 큐 적재) → 스트림 프로세서(보강, 중복 제거) → Delta 테이블 및 KQL 캐시 → Power BI DirectQuery/하이브리드 테이블
• 용도: 알림, 예외 대시보드, 실시간 운영

3) 데이터를 적재하지 않는 페더레이션 쿼리

• API 게이트웨이(속도 제한 적용) → Fabric Dataflows Gen2 / Power BI DirectQuery → 시맨틱 모델(거버넌스가 적용된 측정값)
• 용도: 민감한 시스템, 결과 집합이 작은 경우, 엄격한 규정 준수가 요구되는 경우

보안 및 플랫폼 청사진(가장 먼저 수행)

• ID: Azure AD 앱 전용(서비스 주체) 또는 컴퓨팅용 관리 ID를 사용하고, 공유 사용자 자격 증명은 사용하지 마십시오.
• 권한: 특정 작업 영역, 사이트, API로 범위를 한정하고, 테넌트 전체 범위는 피하십시오.
• 비밀: Key Vault에 저장하고, 클라이언트 비밀보다 인증서 인증을 우선하며, 주기적으로 교체하고 알림을 설정하십시오.
• 네트워크: 프라이빗 엔드포인트 또는 승인된 송신 경로를 사용하고, TLS 1.2 이상만 허용하십시오.
• 속도 제한 및 복원력: 백오프를 적용한 재시도와 멱등성 키를 사용하고, 상위 시스템 장애에 대비해 서킷 브레이커를 적용하십시오.
• 관찰 가능성: 로그를 중앙에서 관리하고(App Insights/Kusto), 상관 관계 ID를 사용하며, 4가지 골든 시그널(지연 시간/트래픽/오류/포화도)을 모니터링하십시오.
• 데이터 거버넌스: 개인 정보(PII) 분류, 민감도 레이블, 모델의 RLS/OLS, 계보 및 영향 분석을 활성화하십시오.

최소 인증 패턴(Python + MSAL)

확장성을 갖춘 Power BI 모델 패턴

• 대규모 팩트 테이블(날짜별로 파티션 분할)에는 Import + 증분 새로 고침을 사용합니다.
• 실시간에 가까운 처리를 위해 하이브리드 테이블(실시간 스트리밍 핫 데이터 + 과거 콜드 데이터)을 사용합니다.
• 규제 대상 소스에는 DirectQuery를 사용하고, 작은 차원 테이블은 이중 저장 모드로 캐시합니다.
• 계약으로서의 시맨틱 모델: 비즈니스 로직은 보고서가 아니라 메저에 두고, 계산 그룹(시간 인텔리전스)을 사용하며, KPI 정의는 한 곳에 중앙화합니다.
• 보안을 위해 RLS/OLS를 적용하고, 역할 조합을 테스트하며, 누가 무엇을 볼 수 있는지 문서화합니다.

새로 고침 오케스트레이션: REST API와 서비스 주체를 사용해 데이터 적재가 끝난 뒤 새로 고침을 연쇄 실행하고, 실패 시 알림을 설정하며, 무거운 모델은 실행 시점을 분산합니다.

업무가 이루어지는 곳에 임베드하기

• Teams: Power BI 앱 탭, 알림용 어댑티브 카드, 필터가 적용된 딥링크.
• SharePoint/포털: 행 수준 보안이 그대로 적용된 보안 웹 파트.
• LOB 앱: Power BI Embed(App Owns Data) + 서비스 주체 사용; 토큰은 서버 측에서 캐시하고, RLS를 반드시 적용합니다.

실제 API 활용 사례

• ERP/레거시 연동: API로 사용자 지정 필드를 정규화하고, Lakehouse에 적재한 뒤 CRM 데이터와 병합해 통합 파이프라인 상태를 확인합니다.
• 재무 대사: API 임계값 → Fabric 작업 트리거 → 불일치 테이블 기록 → Teams 알림 및 대시보드 타일.
• IoT/운영 텔레메트리: 웹후크 → 큐 → 스트림을 Delta로 저장; 라이브 타일과 SLA 알림에는 하이브리드 테이블을 사용합니다.

흔히 겪는 문제와 해결 방법

• 오래된 자격 증명 → 인증서 또는 관리 ID로 전환하고 자동 교체를 구성합니다.
• 과도하게 넓은 권한 → 워크스페이스/사이트별로 범위를 지정하고, 도메인별로 앱 등록을 분리합니다.
• 제한(스로틀링) → 서버 측 페이지 매김, 조건부 GET(ETag), 재시도/백오프를 적용하고, 제공되는 경우 일괄 처리 엔드포인트를 사용합니다.
• 조용한 새로 고침 실패 → 상태 확인 핑, 실패 웹후크/Teams 알림, 새로 고침 성공률과 소요 시간에 대한 SLO 대시보드를 구성합니다.
• 보고서 내 로직 → 모델 메저/계산 그룹으로 옮기고, 버전을 관리하며 테스트합니다.

7일 시작 계획

1–2일차: 앱 등록(앱 전용) 보안 설정, Key Vault 비밀/인증서 구성, 최소 권한 범위 지정.
3일차: 간단한 API 클라이언트 구현(엔터티 목록 조회, 워터마크 이후 델타 가져오기).
4일차: Lakehouse(Delta)에 적재하고 기본 스키마와 파티션을 추가합니다.
5일차: 핵심 메저 3~5개로 시맨틱 모델을 만들고 증분 새로 고침을 사용합니다.
6일차: 적재 후 REST로 새로 고침을 오케스트레이션하고, Teams에 실패 알림을 추가합니다.
7일차: Teams 채널에 임베드하고 라이브 데모를 진행하며, 엔드 투 엔드로 로그를 남기고 관찰합니다.

자주 묻는 질문

이를 위해 Fabric + Power BI Premium이 필요한가요?
Pro나 PoC로 작게 시작할 수 있습니다. 하지만 거의 실시간 처리, 대규모 모델, 엔터프라이즈 거버넌스가 필요하다면 Premium/Fabric 용량을 사용하는 것이 보통 유리합니다.

배치 vs. 실시간?
기본값은 배치 + 증분으로 하고, 지연 시간이 중요하고 소스가 감당할 수 있는 경우에만 Hybrid/DirectQuery를 사용하세요.

규정 준수를 위해 데이터 적재를 피할 수 있나요?
승인된 API나 데이터 게이트웨이에 DirectQuery를 사용하세요. 다만 성능과 DAX 복잡성 측면에서 트레이드오프가 있다는 점을 감안해야 합니다.

수동 UI 프로세스와 취약한 커넥터에서 벗어나 아키텍처를 발전시키는 계획을 세울 때는 보안을 먼저 설계하고, 시맨틱 모델을 진정한 엔터프라이즈 계약으로 구축해야 한다는 점을 기억하시기 바랍니다. 이러한 개념, 기술 전략 및 실제 구현에 대해 더 깊이 알고 싶으시다면 팟캐스트에서 전체 논의를 들어보시기 바랍니다: Extend Microsoft Fabric with Custom APIs and Power BI Models. 읽어 주셔서 감사합니다. 즐거운 빌드 되시기를 바랍니다!