Power BI 쿼리 폴딩 완벽 이해하기: 작업을 데이터 원본으로 넘기세요
By Mirko Peters ·
Power BI를 사용할 때 데이터 새로 고침이 끝도 없이 이어지거나, 더 나쁘게는 리소스가 부족해 중간에 실패하는 상황만큼 답답한 일도 많지 않습니다. 원격 SQL 데이터베이스, 기업용 데이터 웨어하우스, 클라우드 서비스에서 수백만 행을 가져오는 경우라면 변환을 어떻게 처리하느냐가 매우 중요합니다. Power Query에서 수행하는 모든 단계는 데이터를 호스팅하는 강력한 서버가 효율적으로 처리할 수도 있고, 로컬 컴퓨터나 Power BI 서비스의 메모리 엔진이 느리게 처리할 수도 있습니다. 바로 여기서 쿼리 폴딩의 효과가 드러납니다.
Automatically translated with AI from the original post. Read the English original
Power BI를 사용할 때 데이터 새로 고침이 끝도 없이 이어지거나, 더 나쁘게는 리소스가 부족해 중간에 실패하는 상황만큼 답답한 일도 많지 않습니다. 원격 SQL 데이터베이스, 기업용 데이터 웨어하우스, 클라우드 서비스에서 수백만 행을 가져온다면 변환을 어떻게 처리하느냐가 매우 중요합니다. Power Query에서 수행하는 모든 단계는 데이터를 호스팅하는 강력한 서버가 효율적으로 처리할 수도 있고, 로컬 컴퓨터나 Power BI 서비스의 메모리 엔진이 느리게 처리할 수도 있습니다. 바로 여기서 쿼리 폴딩의 효과가 드러납니다.
이 글에서는 쿼리 폴딩을 깊이 있게 살펴보겠습니다. 쿼리 폴딩이 데이터 변환을 어떻게 최적화하는지, 단계가 올바르게 폴딩되도록 하는 실용적인 기법, 폴딩 체인을 끊는 흔한 함정, 그리고 보고서 새로 고침 효율을 크게 높이는 방법을 다룹니다. 작업을 원래 있어야 할 곳, 즉 데이터 원본으로 되돌려 보내겠습니다.
쿼리 폴딩 소개
쿼리 폴딩의 핵심은 Power Query가 사용자 인터페이스에서 만든 데이터 변환 단계를 기본 쿼리 언어(주로 SQL)로 변환하고, 그 쿼리를 원본 데이터베이스로 보내 실행하게 하는 메커니즘입니다. Power BI는 모든 행, 테이블, 열을 내려받아 Power BI 메모리에 올린 뒤 로컬에서 필터링, 그룹화, 조인하는 대신 원본 데이터베이스에 무거운 작업을 맡깁니다.
식료품 주문에 비유해 보겠습니다. 대형 창고형 매장에 가서 매장 안의 상품을 모두 집어 주방 식탁에 올려놓은 뒤, 유통기한이 지났거나 필요하지 않은 것의 90%를 버린다고 생각해 보세요. 엄청난 시간과 에너지가 낭비됩니다. 쿼리 폴딩이 없을 때 벌어지는 일이 바로 이것입니다. 쿼리 폴딩이 활성화되어 있으면 창고 직원에게 구체적인 목록을 전달하는 셈입니다. "1파운드 이상 나가는 사과만 색깔별로 묶어서 주세요." 직원은 창고에서 분류 작업을 마치고 요청한 물건만 담긴 작은 상자를 건넵니다. 주방은 깔끔하게 유지되고, 요리도 훨씬 빨리 끝납니다.
쿼리 폴딩이 데이터 변환을 최적화하는 방식
쿼리 폴딩은 확장 가능한 Power BI 아키텍처의 핵심입니다. 제대로 실행되면 네트워크 간 데이터 전송량을 최소화하고, 새로 고침 단계의 메모리 사용량을 크게 줄이며, 개발 작업 흐름도 빨라집니다.
Power Query 적용 단계의 앞부분에서 행 필터링, 열 제거, 정렬, 기본 집계 같은 변환을 적용하면, 기본 커넥터는 데이터 원본이 그 작업을 네이티브로 처리할 수 있는지 평가합니다. 처리할 수 있다면 해당 단계들이 하나의 고도로 최적화된 쿼리로 묶여 원본으로 전송됩니다. 데이터베이스 엔진은 기존 인덱스를 활용해 이를 실행하므로 수백만 행도 순식간에 걸러낼 수 있습니다.
반대로 쿼리 폴딩이 깨지면 Power BI는 압축되지 않은 필터링 전 전체 데이터 세트를 네트워크를 통해 Power Query 평가 엔진(매시업 엔진)으로 가져와야 합니다. 데이터가 로컬에 들어오면 Power BI는 로컬 CPU와 RAM을 사용해 필터와 변환을 적용합니다. 대규모 기업 데이터 세트에서는 이것이 게이트웨이 시간 초과, 메모리 부족 오류, 보고서 업데이트 지연으로 이어지는 전형적인 원인입니다.
단계가 올바르게 폴딩되도록 하는 실용적인 기법
모든 Power Query 단계가 같은 것은 아니며, 모든 데이터 원본이 쿼리 폴딩을 지원하는 것도 아닙니다. SQL Server, Oracle, PostgreSQL 같은 관계형 데이터베이스는 탄탄한 폴딩 기능을 갖추고 있습니다. 반면 CSV나 Excel 통합 문서 같은 플랫 파일은 네이티브 쿼리 프로세서가 없어서 같은 방식으로 폴딩되지 않습니다.
단계가 성공적으로 폴딩되도록 하려면 적용 단계를 특정 순서로 구성하고, 사용하는 함수에 주의해야 합니다. 쿼리 폴딩을 유지하기 위한 실용적인 기법은 다음과 같습니다.
- 필터를 앞에서 적용하세요: 행 필터(예: 최근 3년 데이터만 유지하거나 활성 상태로 필터링)는 가능한 한 적용 단계의 앞부분에서 항상 적용하세요. 데이터 세트를 일찍 줄일수록 이후 SQL 변환이 더 효율적입니다.
- 불필요한 열은 즉시 제거합니다: 처리 과정 초기에 사용하지 않는 열을 제거하면 데이터 원본이 필요 없는 데이터를 직렬화하고 전송하느라 리소스를 낭비하지 않습니다.
- 지원되는 변환을 이해합니다: 열 제거, 열 이름 바꾸기, 특정 조건에서의 테이블 병합, 추가(Append), 기본 조건부 열 같은 작업은 일반적으로 쿼리 폴딩이 잘 적용됩니다. 반면 복잡한 사용자 지정 수식, 인덱스 조회를 포함한 텍스트 조작, 프로그래밍 방식의 사용자 지정 열은 대개 쿼리 폴딩 체인을 끊습니다.
- "네이티브 쿼리 보기" 옵션을 확인합니다: Power Query 편집기에서 적용된 단계를 마우스 오른쪽 버튼으로 클릭합니다. "네이티브 쿼리 보기" 옵션이 활성화되어 클릭할 수 있다면, 해당 단계까지 쿼리가 성공적으로 폴딩되고 있는 것입니다. 옵션이 회색으로 비활성화되어 있다면 해당 단계 또는 그 이전 단계에서 폴딩이 끊어진 것입니다.
쿼리 폴딩을 깨뜨리는 일반적인 함정
쿼리 폴딩의 까다로운 점 중 하나는 취약하다는 것입니다. 변환 단계 하나라도 잘못된 순서에 놓이면 데이터베이스가 충분히 처리할 수 있는 작업이라도 폴딩 체인 전체가 끊어지고, 그 이후의 모든 단계가 로컬에서 실행될 수 있습니다.
쿼리 폴딩을 깨뜨리는 가장 흔한 실수를 몇 가지 살펴보겠습니다.
- 네이티브 SQL을 삽입한 뒤 변환하기: 데이터 원본 단계의 맨 앞에 네이티브 SQL 쿼리를 작성하면 Power Query는 그 결과 집합을 블랙박스로 취급합니다. 이후 Power Query UI에서 추가한 변환은 대개 폴딩되지 않습니다. Power Query가 사용자 지정 SQL 블록에 UI 단계를 안정적으로 삽입할 수 없기 때문입니다.
- 형식 변환을 너무 이르게 하거나 순서를 잘못 지정하기: 데이터 형식 변경은 필수적이지만, 필터링이나 데이터베이스의 형식 규칙과 충돌하는 작업을 수행하기 전에 변경하면 폴딩이 깨질 수 있습니다. 예를 들어 숫자 열을 텍스트로 바꾼 뒤 그 열에 숫자 범위 필터를 적용하려고 하면 데이터베이스가 쿼리를 최적화하지 못할 수 있습니다.
- 인덱스 열을 추가하거나 행 번호를 사용하기: "인덱스 열 추가"처럼 행 위치에 의존하는 함수나, 절대 인덱스로 주변 행을 참조하는 작업은 위치를 결정하기 위해 전체 데이터 집합을 메모리에 로드해야 합니다. 이는 즉시 쿼리 폴딩을 중단시킵니다.
- 데이터 원본 혼합하기: SQL 데이터베이스의 테이블을 Excel 파일의 테이블과 병합하면, 두 원본이 상호 작용하는 경계에서 쿼리 폴딩이 중단됩니다. Excel은 SQL 쿼리를 네이티브로 처리할 수 없기 때문입니다.
Power BI 새로 고침 효율 개선하기
쿼리 폴딩을 제대로 익히면 그 효과는 전체 데이터 아키텍처에 걸쳐 나타납니다. 예전에는 몇 시간 걸리던 보고서 새로 고침이 몇 분, 심지어 몇 초로 줄어들 수 있습니다. 이러한 효율성은 클라우드 게이트웨이나 서버의 컴퓨팅 리소스를 절약할 뿐 아니라, 개발자가 더 빠르게 반복 작업할 수 있도록 해 줍니다.
새로 고침 효율을 극대화하려면 쿼리 폴딩을 다른 기본 모델링 모범 사례와 함께 적용해야 합니다. 예를 들어 자주 필터링하거나 조인하는 열에는 데이터베이스 테이블에 적절한 인덱스를 적용해야 합니다. SQL 테이블에 인덱스가 없다면, 폴딩된 쿼리라도 데이터베이스 엔진이 비용이 많이 드는 테이블 검색을 수행하게 됩니다. 또한 쿼리 폴딩과 함께 깔끔한 스타 스키마 데이터 모델을 적용하고, 중복 열을 제거하며, 대규모 과거 데이터셋에는 증분 새로 고침 정책을 구현하는 것이 좋습니다.
Power BI 쿼리 모니터링 및 문제 해결
측정하지 않으면 개선할 수 없습니다. 새로 고침이 느리거나 예기치 않게 쿼리가 실패할 때는 병목이 어디에 있는지 진단하는 체계적인 접근이 필요합니다. 먼저 Power BI Desktop의 Power Query Diagnostics 도구를 활용하십시오. 이 기능을 사용하면 단계별 실행 시간을 추적하여 개별 변환 작업에 정확히 얼마나 걸리는지, 그리고 데이터가 원격으로 가져와지는지 로컬에서 처리되는지를 확인할 수 있습니다.
또한 게이트웨이 로그와 데이터베이스 프로파일러(SQL Server Profiler나 Extended Events 등)를 모니터링하여 Power BI에서 데이터 원본으로 전송되는 실제 쿼리를 확인하십시오. WHERE와 GROUP BY 절이 포함된 대상화된 쿼리가 아니라 원본 데이터를 필터링 없이 그대로 가져오는 대규모 SELECT 문이 보인다면, 적용된 단계 어딘가에서 쿼리 폴딩이 실패했음을 즉시 알 수 있습니다.
실행 순서, 운영 시 주의할 점, 고급 최적화 워크플로에 대해 종합적으로 알고 싶다면 관련 팟캐스트 에피소드를 들어보고 Power Query Folding and Execution Order in Power BI 노트도 함께 읽어 보시기 바랍니다. 연산 순서의 기본 원리를 이해하면 언제나 견고하고 매우 빠른 모델을 자신 있게 구축할 수 있습니다.
결론
쿼리 폴딩을 익히는 것은 Power BI 개발자가 습득할 수 있는 가장 영향력 있는 기술 중 하나입니다. 계산 부담을 로컬 머신이나 Power BI 서비스에서 데이터 원본의 강력하고 고도로 최적화된 엔진으로 넘기면 성능 병목을 없애고, 네트워크 혼잡을 줄이며, 보고서 새로 고침이 원활하고 안정적으로 이루어지도록 할 수 있습니다. 단계 순서를 의도적으로 설계하고, 기본 쿼리를 정기적으로 확인하며, 너무 이른 인덱싱이나 호환되지 않는 원본 혼합 같은 흔한 함정을 피하면 비즈니스 인텔리전스 환경의 잠재력을 온전히 끌어낼 수 있습니다.
이러한 개념을 더 자세히 살펴보고 쿼리 실행 순서가 작업 영역 성능에 어떤 영향을 미치는지 자세한 설명을 듣고 싶다면 팟캐스트 에피소드 Power Query Folding and Execution Order in Power BI 전체 내용을 들어 보시기 바랍니다. 오늘부터 이 전략들을 적용해 보시고, 보고서 성능이 눈에 띄게 개선되는 것을 확인해 보십시오!