Power BI 계산 열이 리포트 성능을 해치고 모델 메모리를 부풀리는 이유

By Mirko Peters · 2026-10-29

Power BI 계산 열을 과도하게 사용하면 모델 메모리가 불어나고 리포트 성능이 떨어지는 이유를 알아보고, 데이터 모델 아키텍처를 최적화하는 방법을 살펴봅니다.

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

Power BI에서 계산 열을 잘못 사용하면 데이터 모델의 메모리가 눈에 띄지 않게 불어나고 리포트 렌더링 시간이 느려질 수 있습니다. 동적인 측정값과 달리 계산 열은 데이터 새로 고침 중에 모든 행을 계산하고 저장하므로, 귀중한 RAM을 소비하고 작업 공간 아키텍처 전반의 처리 오버헤드를 높입니다.

핵심 요약

• 계산 열은 데이터 새로 고침 중에 행 단위로 값을 계산하고, 그 값을 메모리에 영구적으로 저장합니다.
• 계산 열을 과도하게 사용하면 VertiPaq 압축률이 크게 떨어져 파일 크기가 급격히 늘어납니다.
• 행 컨텍스트 때문에 계산이 정적으로 실행되며, visual 요소에 적용된 사용자 필터 선택을 완전히 무시합니다.
• 열이 많은 데이터 모델은 확장성에 문제가 생기기 쉬우며, 특히 대규모 기업용 Microsoft Fabric 환경에 통합될 때 그렇습니다.
• 저장 공간을 많이 차지하는 열에서 쿼리 시점에 계산되는 측정값으로 로직을 옮기면 시스템 RAM을 아끼고 리포트 성능을 최적화할 수 있습니다.

행 수준 평가에 숨은 메모리 비용

Power BI에서 새 리포트를 만들 때는 표시할 데이터 항목마다 계산 열을 사용하는 습관에 빠지기 쉽습니다. 수익률, 성과 전체 이름, 또는 매출 수치를 범주로 나눈 구간이 필요하면 테이블에 열을 추가하는 것이 직관적으로 느껴집니다. Excel 스프레드시트와 마찬가지로 데이터 보기에서 결과를 바로 확인할 수 있기 때문입니다.

하지만 Power BI는 스프레드시트가 아니라 분석 엔진입니다. 계산 열을 만들 때마다 VertiPaq 데이터베이스 엔진은 데이터 새로 고침 과정에서 테이블의 모든 행에 대해 그 값을 계산하도록 지시받습니다. 매출 테이블에 행이 500만 개 있다면, 새 계산 열은 의미 체계 모델에 500만 개의 개별 항목을 추가하게 됩니다.

더 큰 문제는 계산 열이 엔진의 압축 알고리즘을 방해한다는 점입니다. VertiPaq는 카디널리티가 낮은 열, 즉 반복되는 중복 값이 많은 열을 기반으로 데이터를 효율적으로 압축합니다. 고유한 값을 갖는 계산 열은 이 압축 효율을 크게 떨어뜨려, 모델을 메모리에 상주시키는 데 필요한 RAM을 몇 배로 늘립니다. 모델이 커지면 이 메모리 부풀림은 Microsoft 클라우드에서 작업 공간의 용량 한도를 빠르게 넘어설 수 있습니다.

정적 컨텍스트가 리포팅의 유연성을 제한하는 방식

메모리 소비 외에도, 계산 열은 평가 컨텍스트를 처리하는 방식 때문에 기능상의 중요한 제약을 안고 있습니다. 계산 열은 엄격하게 행 컨텍스트 안에서 동작합니다. 리포트 캔버스에서 이루어지는 사용자 상호 작용, 슬라이서, 교차 필터링 선택과 무관하게 현재 행의 값만 평가합니다.

정적 기준값을 바탕으로 고가 고객을 표시하는 계산 열을 만들면, 그 분류는 저장 계층에 고정됩니다. 나중에 사용자가 슬라이서를 바꿔 지역별로 데이터를 보거나 날짜 범위를 변경하더라도 계산 열은 이러한 필터를 인식하지 못합니다. 값이 이미 마지막 새로 고침 때 몇 시간 전에 계산되어 저장되었기 때문에, 바뀌는 집계 상태에 동적으로 적응할 수 없습니다.

이러한 경직성은 사용자가 그 순간 적용한 필터 컨텍스트를 기준으로 결과를 즉석에서 계산하는 메저와 뚜렷이 대비됩니다. 사용자가 비주얼과 상호 작용하면 메저가 다시 계산되어 정밀하고 컨텍스트에 맞는 인사이트를 제공하는 반면, 계산 열은 RAM에 저장된 정적 데이터를 그대로 되풀이할 뿐입니다.

Microsoft Fabric과 Azure를 위한 더 가벼운 모델 설계

엔터프라이즈 클라우드 리포팅에서는 특히 Microsoft Fabric, Azure, 그리고 복잡한 Microsoft 365 데이터 환경 전반으로 확장할 때 높은 효율성이 요구됩니다. 비대해진 시맨틱 모델은 인프라 리소스를 소모하고, 쿼리 응답 시간을 늦추며, 대시보드 로딩을 기다리는 비즈니스 사용자에게 불편을 줍니다.

리포트 성능을 최고 속도로 유지하려면 계산 열은 행 수준 값이 정말로 필요한 경우에만 엄격하게 제한하십시오. 예를 들어, 여러 매개 변수를 기준으로 테이블 간 관계 키를 만들어야 하거나, 메저를 사용할 수 없는 슬라이서나 행 수준 보안(RLS) 규칙에서 값을 사용해야 하는 경우에는 계산 열이 적합할 수 있습니다.

합계, 평균, 비율, 조건부 집계와 같은 그 밖의 모든 분석 계산은 메저로 옮기십시오. 메저는 모델에 값을 저장하지 않으므로 저장 공간을 전혀 차지하지 않습니다. 대신 코드 형태로 메모리에만 상주하며, 비주얼이 데이터를 요청할 때만 실행됩니다. 이 방식은 RAM을 절약하고, 압축 효율을 극대화하며, 클라우드 인프라가 원활하게 운영되도록 유지해 줍니다.

결론

행 수준 저장과 동적 쿼리 실행의 근본적인 차이를 이해하는 것은 확장 가능한 분석 솔루션을 구축하는 모든 사람에게 필수적입니다. 불필요한 계산 열을 줄이고 동적 메저의 장점을 적극 활용하면 리포트 속도를 크게 개선하고 메모리 사용량을 줄일 수 있습니다.

이 주제를 더 깊이 알아보고, 수식을 엔진이 어떻게 처리하는지 전문 용어 없이 자세히 설명하는 전체 에피소드를 듣고 싶다면 전체 에피소드 듣기를 이용해 보십시오. M365 FM 팟캐스트에서 클라우드 분석 전략에 도움이 되는 전문가 인사이트를 계속 확인하며 한발 앞서 나가시기 바랍니다.

자주 묻는 질문

Power BI에서 계산 열이 메모리를 많이 사용하는 이유는 무엇입니까?

계산 열은 데이터 새로 고침 중 모든 행을 평가하고, 그 값을 모델의 RAM에 영구적으로 저장합니다. 이로 인해 VertiPaq 엔진이 데이터를 효과적으로 압축하지 못하고, 모델이 빠르게 비대해집니다.

메저도 Power BI 시맨틱 모델에서 저장 공간을 차지합니까?

아니요, 메저는 저장 공간을 차지하지 않습니다. 메저는 메타데이터에 수식 정의로만 저장되며, 비주얼이나 사용자 상호 작용이 계산을 요청할 때만 동적으로 계산됩니다.

계산 열은 언제 사용하는 것이 적절합니까?

계산 열은 복합 키를 만들어 관계를 설정하거나, 행 수준 보안(RLS) 규칙을 적용하거나, 정적 슬라이서 값으로 표시해야 하는 항목을 제공하는 등 행 컨텍스트가 반드시 필요한 특정 상황에만 사용해야 합니다.

계산 열은 리포트 렌더링 성능에 어떤 영향을 줍니까?

계산 열이 과도하게 많으면 시맨틱 모델의 전체 크기가 커지고 데이터 압축 효율이 떨어집니다. 모델이 커질수록 더 많은 메모리와 처리 능력이 필요하며, 결과적으로 워크스페이스 전반에서 쿼리 실행과 리포트 로딩 시간이 느려집니다.