월간 PDF 보고서에서 Power Query가
깨지는 이유

매달 실패하는 새로 고침

반복 보고서는 좀처럼 고정된 파일이 아닙니다. 은행 거래 내역서에 새 달의 열이 추가됩니다. 공급업체의 월말 내보내기에서 시스템 업데이트 후 "Amount"가 "Amount (USD)"로 이름이 바뀝니다. 단종된 필드는 레이아웃에서 완전히 빠집니다. 여러분이 만든 쿼리는 지난달 출력을 기준으로 정확했지만, 출력이 바뀌었다는 사실을 알려줄 사람은 아무도 없었습니다.

Microsoft 공식 문서는 이 실패를 정확히 설명합니다. 쿼리 생성 후 데이터 원본의 열 머리글이 변경되면 Power Query가 "예상한 열 이름을 더 이상 찾지 못할 수 있으며" The column '<column name>' of the table wasn't found. 오류를 반환합니다. 일반적인 복구 방법은 Go To Error를 선택하고 문제가 있는 단계를 연 다음 수식을 고치거나 해당 단계를 삭제하고 편집기가 다시 작성하도록 하는 것입니다.

반복 보고서에 대한 쿼리를 유지 관리하는 사람이라면 누구나 익숙한 패턴입니다. 이번 주에는 쿼리가 정상 작동하고, 다른 머리글이 포함된 새 파일이 도착하면 다음 새로 고침에서 누락된 열이 보고됩니다. 보고서에는 변경 사항을 알리는 내용이 없었고, 쿼리에도 이를 대비한 준비가 없었습니다.

모든 복구는 쿼리를 보고서의 한 버전에 맞춰 다시 작동하게 만들 뿐입니다. 다음 버전은 이미 생성되고 있습니다.

쿼리가 실제로 수행하는 작업

중단이 계속 발생하는 이유를 확인하려면 Power Query가 실제로 저장하는 내용을 살펴보세요. Applied Steps 창은 레시피와 같으며, 각 단계는 열을 이름으로 참조하는 M 코드 한 줄입니다. Rename Column, Changed Type, Remove Columns, Reorder Columns는 모두 열을 이름이나 위치로 명시적으로 참조합니다.

Microsoft의 데이터 형식 문서에서 그 구조를 직접 확인할 수 있습니다. 자동으로 생성된 Changed Type 단계는 열 이름을 수식에 기록합니다: Table.TransformColumnTypes(#"Promoted Headers",{{"OrderID", type number}, {"CustomerID", type text}, ...}). That example is fine for a fixed source. Point it at a monthly report that renames a field and the step is now looking for something that no longer exists. The same is true of the rename function: if a referenced column is missing, the operation raises an error unless you explicitly tell it to ignore or null the miss.

The second half of the problem sits in how Power Query reads a PDF in the first place. A PDF is not a spreadsheet. It is a set of glyphs placed at coordinates, with no built-in notion of rows, columns, or field names. The connector infers a table by reading the spatial layout, so a small change in margins, spacing, or a moved signature block can be interpreted as a different column structure. That is the "position" in position-based parsing: the parser builds the table from where things sit, then the transformation steps describe that built table by name. Merged headers, spanning cells, and multi-page tables each add their own structural distortion, the kind collected in this guide to 병합된 셀 추출 수정.

하나의 의존성은 위치에서, 다른 하나는 이름에서 발생합니다. 둘 중 하나라도 변경되는 반복 보고서는 정상 작동하던 쿼리를 매달 수리해야 하는 작업으로 바꿔 놓습니다.

중단이 잘못된 쿼리가 아닌 구조적 문제인 이유

이 실패에는 두 가지 유형이 있으며, 각각 비용이 다릅니다.

명시적 중단은 새로 고침을 중지합니다. 하드코딩된 열 이름이 더 이상 존재하지 않으면 Power Query가 "wasn't found" 오류를 발생시키고, 누군가 수정할 때까지 보고서가 로드되지 않습니다. 고통스럽지만 눈에 보입니다. 데이터가 잘못되었거나 없거나 둘 중 하나이며, 어떤 상태인지 알 수 있습니다.

암시적 중단은 새로 고침을 성공시키고 잘못된 열을 채웁니다. 이는 보고서가 필드 이름은 유지하지만 필드를 재정렬하거나 구조를 변경하거나, 커넥터가 이동된 레이아웃을 새 열로 읽을 때 발생합니다. 오류는 없습니다. 값이 단순히 잘못된 위치에 들어가고, 오류는 하류에서 잘못된 합계나 불일치 필드로 표면화됩니다. 이것이 일관되지 않은 추출 결과의 배후에 있는 실패 모드이며, 필드 위치만큼 필드 설계가 중요한 이유이기도 합니다. 이 내용은 일반적인 필드 설계 실수에서 다룹니다.

그리고 새로 고침이 남기는 잔여물이 있습니다. 쿼리가 이전 로드보다 적은 수의 열을 반환할 때, 쿼리가 공급하는 Excel Table이 항상 그에 맞게 줄어들지는 않습니다. Microsoft Tech Community의 한 사용자는 이 결과를 "유령" 열, 즉 이전 로드 구조에서 상속되어 실제 데이터 옆에 계속 표시되는 빈 열로 설명했습니다. 쿼리 출력은 깨끗하지만 대상은 그렇지 않습니다.

이것이 널리 알려진 해결 방법이 절반만 효과가 있는 이유입니다. 열을 이름으로 참조하는 대신 위치로 참조할 수 있으며, Table.ColumnNames를 사용하여 이름이 무엇이든 "세 번째 열"을 가져올 수 있습니다. 이는 이름 변경에는 견딥니다. 그러나 어떤 열이 세 번째인지 변경하는 재정렬에는 견디지 못합니다. 이름 의존성을 위치 의존성으로 바꾼 셈이며, 보고서는 둘 중 하나를 변경할 수 있습니다. 이름이 바뀌거나 삭제된 열을 가리키는 하류 수식은 그 위에 자체적인 깨진 참조를 표시합니다.

큰 소리로 나는 고장은 싼 고장입니다. 비싼 실패는 새로고침이 성공한 후 조용히 잘못된 열을 채우는 경우입니다.

비용 청구서에 한 번도 올리지 않는 수리 비용

15분짜리 쿼리 수정에 대해 비용 보고서를 제출하는 사람은 없으며, 그래서 비용이 눈에 보이지 않는 것입니다. 그래도 계산은 해보세요. 한 달에 한 번 수정, 각 15분이면 단일 보고서 기준 연간 3시간입니다. 반복 보고서 5개를 유지한다면 대략 15시간, 즉 근무일 기준 거의 이틀을 자동으로 실행되어야 했던 설정을 수리하는 데 쓰는 셈입니다.

그 숫자는 훨씬 더 큰 스프레드시트 유지보수 패턴 안에 있습니다. 분석 전 데이터 정리 및 준비는 분석가 시간에 대한 익숙한 비용입니다. 취약한 파싱은 그 예산에서 한 줄을 차지하며, 줄어들지 않고 반복되는 바로 그 줄입니다.

반복 보고서 시나리오는 패턴을 더 선명하게 만듭니다. 동일한 12개월치 월간 명세서를 하나의 워크플로우로 처리하는 팀은 쿼리를 한 번만 구축하면 되지만, 1년에 12번은 계속 유지해야 합니다. 또한 지식 리스크가 내재되어 있습니다. Applied Steps를 이해하는 사람이 종종 그것을 고칠 수 있는 유일한 사람입니다. 그 사람이 휴가 중이면 보고서는 기다려야 합니다.

매달 수정이 필요한 일회성 설정은 일회성 설정이 아닙니다. 변동 비용이 드는 구독입니다.

해결책: 열을 위치가 아닌 의미에 바인딩하기

수리 주기는 파싱 계층이 계속해서 두 가지 버전별 질문을 하기 때문에 지속됩니다. 이 값이 어떤 위치에 있는지, 이번 달 이 열의 이름은 무엇인지. 질문을 "이 값의 의미는 무엇인가"로 바꾸면 보고서 레이아웃은 더 이상 쿼리 계약의 일부가 아닙니다.

그것이 바로 맞춤 열 추출이 하는 일입니다. 영역을 그리거나 위치에 대한 규칙을 작성하는 대신 "Statement Date", "Total Amount", "Account Number"와 같은 원하는 열 이름을 입력합니다. AI는 문서를 읽고 열 이름의 의미를 이해하여 각 값을 찾습니다. 값이 어디에 있든, 소스 레이블이 무엇이든 상관없습니다. "Amount"에서 "Amount (USD)"로 이름이 바뀌어도 정확한 텍스트나 좌표가 아닌 의미 기반 매핑이므로 여전히 "Total Amount" 열에 매핑됩니다.

현재 유지 관리하는 단계에 매핑하면 변경 사항은 간단합니다. 내장된 테이블의 헤더에 고정되는 것이 없으므로 월 이름을 하드코딩하는 Changed Type 단계가 없습니다. 보고서가 스스로 순서를 바꿔도 깨질 Reorder 단계도 없습니다. 출력 열을 한 번 정의하면 동일한 정의가 모든 버전의 보고서에 대해 실행됩니다.

추출 후에 보통 이어지는 정리 작업을 처리하는 두 가지 관련 기능이 있습니다. 이 도구의 데이터 후처리는 같은 패스에서 날짜, 금액, 참조 번호를 여러분이 지정한 형식으로 정규화할 수 있으므로, "Statement Date (YYYY-MM-DD)"라는 열이 별도의 형식 지정 단계 없이 이미 일관된 상태로 반환됩니다. 이는 여러 형식의 공급업체 데이터 표준화에 대한 가이드에서 설명한 것과 같은 원칙입니다. 또한 배치 처리가 처음부터 내장되어 있어 월간 보고서 폴더를 한 번에 업로드하고 파일별 출력 대신 병합된 스프레드시트 하나를 얻을 수 있습니다.

중요한 경계는 이것이 대체하는 대상입니다. 의미론적 추출은 문서 읽기 레이어, 즉 보고서의 위치와 이름에 버전이 고정되어 있던 부분을 담당합니다. 이 기능이 여러분의 워크플로우에서 Power Query를 삭제하지는 않습니다. 이 도구는 깔끔하고 이미 구조화된 스프레드시트를 반환하며, Power Query는 이후의 모든 다운스트림 작업, 즉 비즈니스 로직 변환, 병합, 이미 표 형식으로 된 데이터의 계산 열에 여전히 훌륭한 도구입니다. 파싱 측면을 단독으로 확인하려는 팀을 위해 PDF에서 깔끔한 표 추출하기 및 일반적인 PDF를 스프레드시트로 경로에 대한 안내가 관련 메커니즘을 다룹니다.

이 도구가 해결하지 못하는 것

여기서는 그럴듯한 설명보다 정직함이 더 중요합니다. 과장된 주장에 기반한 워크플로우 결정은 쿼리가 실패한 것과 같은 방식으로 실패할 것이기 때문입니다.

기존 쿼리에는 영향을 주지 않습니다. 이 도구는 문서를 읽고 스프레드시트를 반환합니다. Power Query에 다시 쓰거나, Applied Steps를 재생성하거나, 쿼리를 자동으로 업데이트하지 않습니다. 파싱 단계를 대체하는 것이지, 기존 단계의 유지 관리를 자동화하는 것이 아닙니다.

문서 간 필드 매칭을 수행하지 않습니다. 각 문서 내의 필드를 여러분이 지정한 열에 매핑합니다. 한 문서의 값을 다른 문서의 값과 비교하고 자동으로 결정하는 것은 다른 작업이며, 이 단계가 아닌 다운스트림 로직에 속합니다.

보고서에 없는 값을 만들어낼 수 없습니다. 1월 열이 있으면 찾아낼 수 있습니다. 보고서에서 필드가 완전히 빠지면 어떤 방법으로도 그 자리에 무엇이 있어야 했는지 알 수 없습니다. 빈 값이 표시되면 검토를 위해 표시하게 됩니다. 의미론적 읽기도 여전히 읽기입니다.

인식 기능은 품질이 낮은 입력에 한계가 있습니다. 깨끗한 스캔과 디지털 원본 PDF가 가장 강력한 결과를 제공합니다. 심하게 퇴색되었거나 저해상도 스캔은 정확도를 떨어뜨리며, 이러한 출력은 검토 과정을 거쳐야 합니다. 목표는 인간의 판단을 제거하는 것이 아닙니다. 쿼리를 재구축하는 데서 두 번째 확인이 필요한 값을 검토하는 데로 그 판단을 옮기는 것입니다.

자주 묻는 질문

열 이름이 변경되면 Power Query가 왜 중단되나요?

변환 단계가 작동 대상이 되는 열 이름을 저장하기 때문입니다. Changed Type, Rename, 또는 Remove Columns 단계는 특정 이름을 찾으며, 소스 헤더가 변경되면 Power Query가 더 이상 해당 이름을 찾을 수 없어 "The column of the table wasn't found."를 반환합니다. 해결 방법은 이번 달 파일에 맞게 해당 단계를 수정하는 것이며, 그래서 같은 문제가 다음 버전에서 다시 발생하는 것입니다.

Power Query에서 고스트 열이란 무엇인가요?

고스트 열은 새로고침 후 Excel Table에 남아 있는 빈 열로, 일반적으로 쿼리가 이전 로드보다 적은 수의 열을 반환할 때 발생합니다. 쿼리 출력은 정확하지만 대상 Table은 이전 구조의 열을 유지합니다. 커뮤니티 보고에 따르면 예측할 수 없이 나타나며, 신뢰할 수 있는 해결 방법은 이전 구조 위에서 새로고침하는 대신 Table을 다시 구축하는 것입니다.

Power Query에서 이름 대신 위치로 열을 참조할 수 있나요?

네, Table.ColumnNames를 사용하여 인덱스로 열을 선택할 수 있습니다. 쿼리가 더 이상 열 이름에 의존하지 않으므로 이름 변경 문제를 해결합니다. 그러나 열 위치가 변경되므로 순서 변경 문제는 해결하지 못합니다. 취약성을 제거한 것이 아니라 이동시킨 것이며, 열 이름이 변경되거나 삭제되면 다운스트림 참조는 여전히 깨집니다.

ImageToTable.ai가 Power Query를 업데이트하거나 다시 작성하나요?

아니요. 문서 읽기 단계를 대체하고 구조화된 스프레드시트를 반환합니다. 쿼리를 편집하거나 Applied Steps를 수정하거나 Power Query 내에서 실행되지 않습니다. 많은 팀이 다운스트림 비즈니스 로직에는 Power Query를 유지하고, 이전에 문제가 되던 구문 분석에는 추출 기능을 사용합니다.

전체 열이 사라진 보고서도 처리할 수 있나요?

누락된 필드에 대해 값을 만들어내는 대신 빈 값을 반환합니다. 이것이 올바른 동작입니다. 필수 필드가 소스에서 사라진 경우, 합성된 숫자를 수용하는 것이 아니라 빈 값을 확인하고 소스 보고서를 점검하는 것이 올바른 대응입니다.

한 번 구축한 설정은 계속 유지되어야 합니다. 월간 수리 티켓은 구문 분석이 값의 위치와 이번 달 헤더 이름을 계속 묻기 때문에 자동으로 발생합니다. 값의 의미를 묻는 방식으로 바뀌면 보고서는 레이아웃을 변경해도 쿼리를 중단시키지 않습니다.