DAX와 Power Query로 끌어올린 Power BI 속도

 

Power BI 성능 튜닝은 개별 DAX 공식만 손보는 문제가 아니라, “원본 DB → Power Query → 모델(VertiPaq) → DAX → 시각화/필터” 전체 파이프라인을 한 번에 보는 게 핵심입니다. 특히 동적 필터링(슬라이서, RLS)과 새로고침 성능을 같이 잡으려면, 스타 스키마와 쿼리 폴딩, 증분 새로고침, DAX 최적화가 하나의 설계 원칙으로 엮여야 합니다. 

반응형

---

성능을 결정하는 전체 구조

Power BI의 VertiPaq 엔진은 열 기반 컬럼 스토리지와 고압축 인덱스를 사용하기 때문에, 스키마 설계를 잘하면 수천만 행도 빠르게 집계할 수 있습니다. 하지만 관계가 꼬인 스노우플레이크 구조나 원-투-원 복잡 조인, 높은 카디널리티 열이 많으면 압축 효율이 떨어지고 조인 비용이 폭발하면서 시각화 렌더링이 확 느려집니다. 

각 보고서 시각화는 Power BI 의미 체계 모델에 쿼리를 날리고, 이 쿼리는 필터 → 그룹핑 → 집계 순으로 실행됩니다. 따라서 “필터와 그룹핑은 얇은 차원 테이블, 집계는 일관된 그레인의 팩트 테이블”로 명확히 나뉘어 있어야 동적 필터링이 들어와도 상태를 빠르게 계산할 수 있습니다. 

---

데이터 모델링 튜닝 전략

마이크로소프트 공식 가이드는 Power BI에서 스타 스키마를 기본 모델로 쓸 것을 강하게 권장합니다. 하나의 중앙 Fact 테이블과, 날짜·고객·제품·조직 등 얇은 Dimension 테이블들이 방사형으로 연결된 구조가 성능과 사용성을 동시에 최적화합니다. 

튜닝 관점에서 특히 중요한 포인트는 다음입니다.

• 팩트 테이블 그레인 고정
  트랜잭션 수준이든 일별 집계든, 같은 팩트 테이블 안에서 그레인을 섞지 않아야 조인과 집계가 단순해집니다. 혼합 그레인을 쓰면 CALCULATE, SUMX 같은 DAX에서 불필요한 중복 집계가 생기고 성능이 떨어집니다.
• 고카디널리티 열 관리
  GUID, 개별 트랜잭션 ID, 긴 문자열 키는 모델 사이즈와 압축률에 악영향을 줍니다. 비즈니스 분석에 필요 없으면 제거하거나 상위 카테고리 열만 남기고, 관계 키는 정수 surrogate key로 정규화하는 것이 좋습니다.
• 관계 방향 최소화
  양방향 관계(Bi-directional)를 남발하면 필터 전파 경로가 복잡해져서 쿼리 플랜이 무거워집니다. 기본은 단방향(차원 → 팩트)로 두고, 필요한 경우에만 CROSSFILTER, TREATAS 등으로 DAX에서 명시적으로 제어하는 패턴이 권장됩니다.
• Aggregation 테이블 활용
  대용량 팩트에 대해 집계 테이블을 별도로 두고, Aggregations 기능이나 DirectQuery+Import 혼합 모델을 사용하면 자주 쓰는 집계는 작은 테이블에서 처리하여 응답속도를 크게 줄일 수 있습니다.

---

Power Query와 새로고침 성능

Power Query 단계에서의 설계는 새로고침 시간과 게이트웨이 부담에 직결됩니다. 핵심 개념은 “가능한 한 많은 변환을 원본 DB로 폴딩해서 보내는 것(query folding)”입니다. 

• 쿼리 폴딩(Query Folding) 유지
  필터, 조인, 집계 같은 변환을 Power Query에서 정의했을 때, 이를 SQL 등 원본 쿼리로 변환해 소스에서 실행하도록 만드는 것이 폴딩입니다. 폴딩이 잘 되면 Power BI는 필요한 데이터만 가져오고 대부분의 계산을 DB에서 처리하므로 새로고침 속도와 메모리 사용량이 크게 줄어듭니다.
• 폴딩을 깨는 연산 피하기
  Row-by-row 커스텀 함수, Table.Buffer 남용, 정렬-인덱스 조합 등은 폴딩을 깨서 전체 데이터를 Power BI로 끌어온 뒤 메모리에서 처리하게 만듭니다. 가능하면 이런 연산은 MSSQL 뷰나 스토어드 프로시저, SAP CDS View 등 상위 레이어로 올리는 편이 좋습니다.
• 필터를 최대한 앞단에 적용
  날짜 범위, 활성 플래그, 특정 회사코드 등 기본 필터는 Source 직후 단계에서 걸어야 DB가 읽는 데이터 양 자체를 줄일 수 있습니다. 폴딩이 유지된다면, 이 필터들이 그대로 WHERE 조건으로 내려가게 됩니다.

---

증분 새로고침과 동적 데이터

증분 새로고침(Incremental Refresh)은 “최근 N년/월만 새로고침하고, 과거 파티션은 그대로 두는” 방식으로 대용량 모델의 필수 기능입니다. 마이크로소프트 문서에서도 증분 새로고침과 실시간(DirectQuery) 조합이 빠른 새로고침과 최신 데이터 확보를 동시에 달성하는 전략으로 소개됩니다. 

• RangeStart/RangeEnd 기반 설계
  증분 새로고침은 RangeStart, RangeEnd 매개변수를 사용하여 날짜 필터를 소스까지 폴딩시키는 것이 핵심입니다. 이 필터가 폴딩되지 않으면, Power BI가 전체 데이터를 받아서 날짜를 나누기 때문에 일반 풀 새로고침과 다를 바 없어집니다.
• 파티션 전략
  Fact 테이블을 연도/월 단위로 파티셔닝하고, 최근 몇 개 파티션만 새로고침하도록 설정하면 새로고침 시간이 크게 줄고 실패 위험도 작아집니다. 특히 Databricks나 클라우드 DW처럼 대규모 분산 환경에서는 파티션 프루닝이 가능한 구조를 맞추는 것이 중요합니다.
• DirectQuery/Import 혼합
  최신 소량 데이터는 DirectQuery 파티션에서 라이브로 가져오고, 과거 대용량은 Import+증분 파티션으로 두는 하이브리드 구조를 쓰면 동적 필터링에도 빠르게 반응하면서 전체 모델 새로고침 부담을 최소화할 수 있습니다.

---

DAX와 Measure 최적화

DAX 튜닝은 “엔진이 대량 집계를 한 번에 하게 두느냐, 행 단위 반복을 시키느냐” 싸움입니다. 최근 베스트 프랙티스 문서와 DAX 최적화 글들을 정리해보면 공통된 핵심은 아래와 같습니다. 

• Measure > 계산 열
  실시간 집계가 가능한 로직은 계산 열(Calculated Column) 대신 Measure로 구현하는 것이 좋습니다. Measure는 쿼리 시점에 필요할 때만 계산되지만, 계산 열은 결과가 모두 메모리에 저장되어 모델 사이즈와 새로고침 시간이 증가합니다.
• VAR 적극 사용
  동일한 계산을 여러 번 반복하지 말고 VAR로 한 번만 계산해 재사용하면, 엔진이 중복 계산을 줄이고 캐시를 활용할 수 있습니다. Microsoft 기반 베스트 프랙티스에서도 “변수를 통해 성능, 가독성, 디버깅이 모두 개선된다”고 명시합니다.
• 단순 집계 우선, Iterator 남용 금지
  SUM, AVERAGE 같은 집계 함수로 해결될 일을 SUMX, FILTER 조합으로 과도하게 풀면 불필요한 행 컨텍스트 반복이 생깁니다. 예를 들어 단순 매출 합계를 SUMX로 다시 계산하는 대신 SUM(Sales[Amount])를 사용해야 합니다.
• DISTINCT vs VALUES
  DISTINCT와 VALUES 모두 고유값을 반환하지만, referential integrity 위반으로 추가된 blank 처리 방식이 다르므로 모델 전체에서 일관되게 사용할 것을 권장합니다. Blank 처리 차이로 인한 예상치 못한 필터 결과 차이는 debug 비용과 성능 문제를 동시에 유발합니다.
• 복잡한 필터는 미리 테이블로
  매우 복잡한 조건의 필터가 반복해서 등장한다면, 이를 별도 계산 테이블이나 Dimension 속성으로 미리 만들어 두고, DAX에서는 간단한 조건만 사용하도록 설계하는 편이 좋습니다.

---

계산 열과 계산 테이블의 사용 기준

계산 열과 계산 테이블은 남용하면 모델을 불필요하게 비대하게 만듭니다. 베스트 프랙티스에서는 “가능한 한 많은 계산을 Power Query 또는 소스 DB에서 처리하고, 모델 내 계산 열은 최소화하라”고 조언합니다. 

• 계산 열은 정적 특성일 때만
  제품 카테고리, 고객 등급처럼 행 단위지만 자주 바뀌지 않는 속성은 소스 또는 Power Query에서 미리 만들어 두는 것이 이상적입니다. 어쩔 수 없이 계산 열을 쓴다면, 행 수가 적은 Dimension 테이블에만 제한하는 것이 좋습니다.
• 계산 테이블의 역할
  Role-playing Date, 마케팅 캠페인 기간 매핑 등 모델링 목적의 계산 테이블은 오히려 DAX를 단순화해 성능에 도움을 줄 수 있습니다. 다만, 순수 분석용 가상 테이블은 가능한 한 SUMMARIZE, GROUPBY 같은 가상 테이블 함수로 쿼리 시점에 생성하는 방식이 VertiPaq에 부담을 덜 줍니다.

---

필터링, 슬라이서, 시각적 요소 튜닝

보고서가 느려지는 가장 흔한 원인은 “과도한 시각적 요소와 슬라이서”입니다. B EYE의 Power BI 성능 체크리스트와 DAX 성능 글들에서 다음과 같은 공통 조언을 제시합니다. 

• 페이지별 시각화 개수 제한
  하나의 페이지에 너무 많은 차트와 카드, 테이블을 올리면 각 요소마다 쿼리가 발생합니다. 핵심 KPI와 요약 뷰만 두고, 상세 테이블은 별도 페이지로 분리하는 것이 좋습니다.
• 슬라이서와 교차 필터 최적화
  고카디널리티 컬럼(예: 고객 ID, 주문번호)을 슬라이서에 직접 쓰면 필터 갱신 비용이 큽니다. 대신 상위 카테고리나 계층형 슬라이서를 사용하고, 필요하면 검색 박스나 드릴스루로 상세 탐색을 분리합니다.
• Visual Interaction 제어
  모든 시각화가 서로 영향을 주도록 두면, 사용자가 슬라이서를 조작할 때마다 수많은 쿼리가 연쇄적으로 실행됩니다. “시각적 개체 간 상호 작용 편집”으로 꼭 필요한 관계만 남기는 것이 중요합니다.

---

SAP·MSSQL 환경에서의 특이점

SAP S/4HANA와 Power BI를 연계한 연구에서는, 적절한 데이터 모델링과 Power Query 변환, DAX Measure 설계가 복잡한 ERP 데이터를 빠르게 시각화하는 데 결정적이라고 강조합니다. 특히 SAP 쪽에서는 CDS View나 Calculation View에서 먼저 비즈니스 로직과 집계를 정리하고, Power BI에서는 스타 스키마와 KPI 계산에 집중할 때 전체 성능과 거버넌스가 좋아진다고 보고합니다. 

MSSQL 기반 중소·중견기업(SME) 환경에서는 제한된 리소스로 확장 가능한 데이터 솔루션을 만드는 것이 중요하며, 적절한 인덱싱과 파티셔닝, 데이터 모델 축소를 통해 Power BI 쿼리 부하를 줄여야 한다는 연구도 있습니다. 실무에서는 특히 날짜·사업부·제품 계층에 맞춘 클러스터드 인덱스, 파티션 테이블, 미리 집계된 뷰를 정의해 두고 Power BI에서 이를 Import+증분 새로고침으로 소비하는 패턴이 많이 쓰입니다. 

---

성능 분석 도구 활용법

튜닝을 제대로 하려면, 체감이 아니라 수치 기반으로 병목을 찾아야 합니다. 이를 위해 추천되는 도구와 기능은 다음과 같습니다. 

• Power BI Performance Analyzer
  각 시각화별 쿼리 시간, DAX 계산 시간, 렌더링 시간을 측정해 어떤 요소가 느린지 바로 알 수 있습니다. 이 로그를 DAX Studio로 내보내면 쿼리 수준에서 추가 분석을 할 수 있습니다.
• DAX Studio, VertiPaq Analyzer
  DAX Studio는 쿼리 플랜과 실행 시간, 서버 타이밍, VertiPaq 메모리 구조를 분석할 수 있는 대표 도구입니다. VertiPaq Analyzer를 통해 각 테이블과 열의 메모리 사용량, 카디널리티, 압축률을 확인하고 어떤 열을 줄이거나 재설계해야 할지 판단할 수 있습니다.

이런 도구를 주기적으로 사용해 “시각화 추가나 요구사항 변경 후에도 성능이 일정 수준 이상인지” 체크하는 것이 장기적인 품질 관리에 도움이 됩니다. 

---

모델 사이즈와 용량 관리

마지막으로, 전체 모델 사이즈와 용량 관리 전략도 성능과 직결됩니다. 마이크로소프트는 증분 새로고침과 파티션, 실시간 DirectQuery를 결합해 새로고침 범위를 줄이고, 모델의 메모리 footprint를 최소화할 것을 권장합니다. 

• 불필요한 열·테이블 제거
  보고서나 DAX에서 쓰이지 않는 열과 테이블을 과감히 제거하면 압축률이 좋아지고, 스캔해야 할 데이터 양도 줄어듭니다.
• 스타 스키마 + 증분 새로고침 기본값
  대부분의 엔터프라이즈 시나리오에서 “스타 스키마 기반 Import 모델 + 증분 새로고침 + 부분 DirectQuery” 조합이 성능과 유지보수성의 균형점으로 제시됩니다.
• 스케일아웃 고려
  매우 큰 사용자 수와 데이터 볼륨이 있는 경우, Power BI Premium/Fabric 용량에서 모델당 메모리 한도와 동시성 제한을 고려해 데이터셋을 기능/도메인 단위로 나누는 것도 하나의 전략입니다.

---

• 모델 설계: Star Schema, 단방향 관계, 고카디널리티 관리 → 동적 필터링이 들어와도 VertiPaq이 가볍게 집계할 수 있는 구조 만들기.
• Power Query: Query Folding 유지, 필터를 앞단에, 증분 새로고침은 RangeStart/RangeEnd 폴딩이 되도록 설계.
• DAX: Measure 우선, VAR 활용, Iterator 최소화, DISTINCT/VALUES 일관 사용, 복잡한 로직은 소스·Power Query·모델링 계층으로 올리기.
• 시각화: 페이지당 시각화 수 줄이고, 슬라이서와 상호작용을 최소한으로 설계.
• 운영: Performance Analyzer, DAX Studio, VertiPaq Analyzer로 주기적으로 병목을 수치로 확인하고, 증분 새로고침/집계 테이블/용량 설계로 새로고침과 동시성을 관리.

이 원칙들을 “모델을 처음 만들 때”부터 반영하면, 나중에 느려진 뒤에 고치는 것보다 훨씬 적은 비용으로 SAP·MSSQL 같은 대형 원천에서도 안정적인 Power BI 성능을 유지할 수 있습니다.