Power Query 초기 필터 전후 새로 고침 시간을 비교하는 A/B 기록표

초기 필터를 추가한 쿼리가 빨라져도, 필요한 행을 덜 읽어서 빨라진 것이라면 같은 작업의 개선이라고 말할 수 없습니다. A/B 비교에서는 두 쿼리가 같은 최종 결과를 내는지부터 맞춰야 합니다. 이 글은 기존 가상 기록값 39초와 16초를 그대로 사용하면서, 출력과 조건 검증 없이 단축이 나오는 단순 판정을 고칩니다.

첨부에는 AB기록, 경계검산, M입력 시트와 완전한 Power Query M 예제 파일이 있습니다. 50,000행·10,000행 및 시간·자원 수치는 계산을 익히는 가상 입력입니다. M 예제는 별도의 여덟 행으로 동등한 결과를 확인하는 연습이며, 그 여덟 행이 39초 걸렸다는 측정 주장이 아닙니다. Microsoft Excel 및 Power Query 엔진을 실제 실행하지 않았습니다. 통합문서 계산은 LibreOffice, 행 필터와 정렬의 참조 결과는 Python에서 각각 검산했습니다.

1. 원본은 보존하고 비교 사본 두 개 만들기

업무 파일을 닫고 읽기 전용으로 보관할 원본 사본을 먼저 만듭니다. 원본 쿼리는 Source_Original로 남기고, 비교용 쿼리를 Source_LateFilter와 Source_EarlyFilter로 나눕니다. 원본의 다른 변환을 삭제하거나 데이터 원본을 바꾸지 않습니다. 비교 두 쿼리는 같은 원본, 같은 열 형식, 같은 필터 경계, 같은 최종 정렬을 사용해야 합니다.

Microsoft Power Query 모범 사례는 필요한 데이터를 가능한 이른 단계에서 필터링하도록 권장합니다. 그러나 이 원칙은 모든 쿼리에서 동일한 시간 단축을 보장하지 않습니다. 이미 원본 시스템에서 필터를 수행하거나 데이터 양이 작으면 차이가 작을 수 있습니다. 성능 효과는 실제로 같은 작업을 수행한 기록으로 판단합니다.

2. 완전한 M 예제로 두 쿼리의 최종 결과를 먼저 맞추기

다음 코드를 빈 쿼리의 고급 편집기에 넣고 이름을 Source_Original로 정하면 가상 여덟 행 입력이 됩니다. 외부 파일이나 웹 서버를 읽는 코드가 없습니다. 기준일은 처음부터 date 형식이므로 날짜 형식을 정하기 전에 텍스트 날짜를 무작정 비교하는 예제도 아닙니다.

let
    Source = #table(type table [ID = Int64.Type, 기준일 = date, 금액 = number], {
        {1, #date(2026, 8, 31), 10},
        {2, #date(2026, 9, 1), 20},
        {3, #date(2026, 9, 10), 30},
        {4, #date(2026, 9, 30), 40},
        {5, #date(2026, 10, 1), 50},
        {6, #date(2026, 9, 15), 60},
        {7, #date(2026, 9, 20), 70},
        {8, #date(2026, 8, 1), 80}
    })
in
    Source

Source_LateFilter는 먼저 ID로 정렬하고 9월 행을 남깁니다. 아래 전체 코드를 별도 쿼리에 입력합니다.

let
    Source = Source_Original,
    Sorted = Table.Sort(Source, {{"ID", Order.Ascending}}),
    Filtered = Table.SelectRows(Sorted, each [기준일] >= #date(2026, 9, 1) and [기준일] < #date(2026, 10, 1))
in
    Filtered

Source_EarlyFilter는 같은 필터를 정렬보다 먼저 적용합니다. 다른 조건은 바꾸지 않습니다.

let
    Source = Source_Original,
    Filtered = Table.SelectRows(Source, each [기준일] >= #date(2026, 9, 1) and [기준일] < #date(2026, 10, 1)),
    Sorted = Table.Sort(Filtered, {{"ID", Order.Ascending}})
in
    Sorted

Table.SelectRows는 선택 조건에 맞는 행의 표를 반환합니다. Table.Sort는 지정한 열과 비교 기준으로 표를 정렬합니다. 여기서는 ID가 중복되지 않으므로 ID 오름차순의 기대 순서를 명확히 정할 수 있습니다. 실제 자료에 ID 중복이 있으면 동률의 순서를 이 예제처럼 단정하지 말고 추가 키를 정합니다.

기대 결과는 두 쿼리 모두 아래 다섯 행입니다. 첨부 M입력의 원본 여덟 행과 M기대값의 다섯 행도 이 표와 같아야 합니다.

행 수 5, ID 순서 2·3·4·6·7, 금액 합계 220을 대조합니다. 10월 1일인 ID 5를 포함하거나 9월 1일인 ID 2를 빼면 실패입니다. 행 수만 같아도 다른 ID가 들어갔다면 같은 출력이 아닙니다. Python 참조 검산은 이 행·값·순서를 검사하지만 M 엔진을 실행한 결과라는 뜻은 아닙니다.

3. 가상 A1:J3의 열 위치와 단위를 확인하기

AB기록 시트의 숫자는 기존 예제와 같은 위치에 둡니다. B열은 단계에서 처리하는 가상 입력 행 수이고, 최종 출력 행 수가 아닙니다. 초기 필터로 처리 중간 행 수가 달라도 최종 출력은 별도로 같아야 합니다. C열의 사본 크기도 기록 위치를 연습하는 값이며 동등성의 증거가 아닙니다.

E2·E3의 39와 16을 시간으로 읽습니다. F2·F3의 72와 58을 빼면 14가 나오지만 그것은 시간 차이가 아닙니다. 실제 기록에서는 자원 표시의 단위와 측정 시점을 별도 메모로 남기고, 이 가상 표시값으로 CPU나 메모리 구매 기준을 정하지 않습니다. C열의 크기를 시간에 포함하거나 완료 순간의 사용률 하나로 병목을 확정해서도 안 됩니다.

4. 시간과 출력 확인이 모두 있어야 판정하기

I2는 시간 두 칸이 숫자인 경우에만 차이를 계산합니다. 숫자 입력이 빠지면 의도적으로 오류를 남겨, 빈칸을 0초로 취급한 단축 수치가 나오지 않게 합니다.

=IF(COUNT(E2:E3)=2,E2-E3,NA())

J2에는 다음 전체 수식을 둡니다. B6:B9는 각각 최종 키·값 일치, 같은 데이터·필터, 같은 실행·측정 조건, 초기 필터 위치만 변경 여부입니다. 첨부의 TRUE는 가상 검산을 위한 입력입니다. 실제 업무 파일에 붙여 넣었다고 네 조건이 자동 검증되는 것이 아닙니다.

=IF(COUNT(E2:E3)<>2,"시간 입력 확인",IF(OR(E2<=0,E3<=0),"시간 입력 확인",IF(NOT(AND(B6=TRUE,B7=TRUE,B8=TRUE,B9=TRUE)),"출력·조건 확인",IF(I2>0,"초기 필터 후 단축","재측정"))))

초기 가상값의 I2는 23, J2는 초기 필터 후 단축입니다. B6을 FALSE로 바꾸면 시간 차이가 여전히 23이어도 J2는 출력·조건 확인이어야 합니다. E3을 비우면 시간 입력 확인, E3을 39로 바꾸면 재측정입니다. E3을 0·음수·텍스트로 입력해도 정상 단축으로 승인하지 않습니다. 경계검산의 아홉 행에서 각 계산 결과 G열과 고정 기대값 F열을 대조할 수 있습니다.

5. 실제 측정에서는 같은 최종 작업을 반복하기

실제 성능을 확인할 때만 자신의 Excel 사본에서 측정합니다. 같은 파일 위치와 원본 스냅샷, 같은 연결 및 로드 대상, 같은 전원·백그라운드 조건을 유지합니다. 이 연습 절차는 각 쿼리를 두 번 실행하고 두 번째 완료 시간을 기록하는 방식입니다. 첫 실행을 기록하지 않는 선택만으로 캐시나 네트워크 영향을 완전히 제거했다고 주장하지 않습니다.

시작과 완료의 기준도 같아야 합니다. 미리보기 완료를 한쪽 시간으로 쓰고 워크시트 로드 완료를 다른 쪽 시간으로 쓰면 비교하지 않습니다. 반복해서 결과가 뒤집히면 좋은 값만 고르지 말고 두 기록을 보존한 뒤 실행 조건을 다시 확인합니다. 결과표의 ID·열·값이 맞지 않으면 시간 차이가 양수라도 B6을 TRUE로 두지 않습니다.

측정이 유효하려면 실험용 두 쿼리가 똑같은 최종 기간을 반환해야 합니다. 필터 없는 전체 이력과 필터한 일부 기간의 시간을 비교해 전체 작업이 빨라졌다고 결론 내리지 않습니다. 대규모 실제 자료에 이 실습을 옮길 때는 M 예제의 ID 검증 대신 그 업무에서 합의한 키·행·열·합계 검증을 먼저 정합니다.

6. 실패한 비교는 원본으로 돌아가 다시 만들기

ID 5가 들어왔다면 종료 경계를 < #date(2026,10,1)로 썼는지 확인합니다. ID 2가 빠졌다면 시작 경계의 >=를 확인합니다. 조건을 고친 뒤 다섯 행과 합계 220이 다시 맞는지 검산하고 이전 잘못된 시간은 개선 근거로 사용하지 않습니다. 형식 오류나 null 날짜를 포함한 업무 자료는 이 여덟 행과 다른 입력 계약이므로, 빠르게 보이도록 오류 행을 임의 삭제하지 않습니다.

실험 사본의 쿼리가 손상되면 Source_Original을 수정해 맞추지 말고 손상 사본을 별도 이름으로 보존합니다. 백업에서 새 사본을 만들고 비교 두 쿼리에 같은 조건을 적용하세요. 복구 완료는 원본 내용이 바뀌지 않고, 두 결과의 키·값·순서와 측정 기준이 다시 일치하는 상태입니다. 실제 새로 고침, 자격 증명, 서버 지연, Excel 응답 없음 문제는 이 오프라인 첨부로 해결됐다고 판단할 수 없습니다.

7. 이 비교의 적용 범위와 한계

첨부 XLSX에는 자동 새로 고침이나 연결 자격 증명이 없습니다. M 코드는 ZIP의 텍스트 파일로 제공하며 실행 여부는 독자의 Excel에서 확인해야 합니다. 가상 시간과 Python 검산을 실제 성능 실험으로 바꾸어 인용하지 마세요. 기록표가 주는 것은 구매 추천이나 처리시간 보장이 아니라, 같은 출력이라는 전제를 확인한 뒤 두 시간을 비교하는 절차입니다.

본문과 같은 입력으로 연습하기

실습 XLSX에는 본문에서 지정한 셀과 수식이 들어 있습니다. 검산 자료 ZIP에는 같은 XLSX와 입력·수식 CSV, 실습 설명, README 및 오프라인 Python 검산 코드가 있습니다. 원본 업무 파일을 덮어쓰지 말고 사본으로 연습하세요. Microsoft Excel 앱의 실제 실행 결과로 제공하는 파일은 아닙니다.

공식 자료

Best Practices When Working with Power Query – Power Query

Table.SelectRows – PowerQuery M

Table.Sort – PowerQuery M

출처 원문 수집일: S1 2026-09-24; S2 2026-09-24; S3 2026-09-24.

작성자 소개

최지원

엑셀·VBA·파이썬·AI 업무 자동화의 사용 절차와 실습 자료를 정리합니다.

WP 게시물 작성자의 글 보기