PDF를 수집하는 파이프라인을 구축해 본 적이 있다면, 이 데모가 오해를 불러일으킨다는 것을 이미 알고 있을 겁니다.

깨끗하고 잘 포맷된 인보이스 10개를 가지고 테스트합니다. 추출은 완벽하게 작동합니다. 그리고 배포합니다. 그러다가 지난 분기에 템플릿을 업데이트한 공급업체로부터 #47번 인보이스가 도착하고, 갑자기 '작동하던' 파이프라인이 조용히 쓰레기를 반환하거나, 더 나쁜 경우 아무도 알아차리지 못하다가 실제 문제(downstream)를 일으킬 때까지는 틀렸지만 그럴듯해 보이는 데이터를 반환합니다.

이것은 거의 모든 PDF 추출 접근 방식의 기본 실패 모드이며, 왜 그런지 이해할 가치가 있습니다.

거의 모든 것이 하는 핵심 가정

PyPDF, pdfplumber, Camelot를 사용하든, 심지어 많은 'AI 기반' 추출 도구를 사용하든 관계없이, 대부분의 PDF 파싱 도구는 문서 구조가 안정적이라고 조용히 가정합니다. 이들은 대략 같은 위치에서 테이블을 찾고, 비슷한 레이아웃으로 된 필드 라벨 뒤에 값을 찾으며, 헤더와 푸터를 대략 같은 위치에서 찾습니다.

이것은 작동하다가 작동하지 않을 때까지는 좋습니다. 그리고 '작동하지 않는' 경우는 실제 세계에서는 끊임없이 일어납니다:

• 공급업체가 인보이스 템플릿을 업데이트하는 경우
• 스캔된 문서의 여백(margin)이 이전 배치와 약간 다른 경우
• 다중 컬럼 레이아웃이 섹션에 포함된 텍스트 양에 따라 다르게 리플로우되는 경우
• 테이블이 하나가 아닌 두 페이지에 걸쳐 있는 경우
• 완전히 다른 소프트웨어에서 동일한 '종류'의 문서를 내보내는 사람

만약 실제 볼륨으로 문서를 처리하고 있다면, 이들 중 어느 것도 엣지 케이스(edge case)가 아닙니다. 이것은 화요일 같은 일상입니다.

이것이 보이는 것보다 더 나쁜 이유

좌절스러운 부분은 추출 자체가 실패하는 것이 아니라, 그것이 어떻게 실패하느냐는 것입니다. 위치 기반 또는 템플릿 가정을 기반으로 구축된 파서는 레이아웃이 이동할 때 일반적으로 오류를 발생시키지 않습니다. 단지 자신감 있게 잘못된 것을 추출할 뿐입니다. 필드가 잘못된 위치에서 끌려오거나, 테이블이 잘리거나(truncated), 헤더의 텍스트가 본문에 연결되어 붙어버리는 일이 발생합니다.

이는 크래시(crash)보다 훨씬 더 심각한 실패 모드입니다. 왜냐하면 오류가 발생했다는 사실을 아무도 알려주지 않기 때문입니다. 만약 이 데이터를 RAG (Retrieval-Augmented Generation) 파이프라인이나 다운스트림 자동화 (downstream automation)에 입력하고 있다면, 숫자가 맞지 않거나 쿼리에 대한 답변이 미묘하게 틀렸다는 것을 누군가 알아차릴 때까지는 문제를 알 수 없습니다.

실질적인 해결책

노력 수준이 낮은 것부터 높은 순서대로 몇 가지 실용적인 패턴을 소개합니다:

1. 구조 탐지 (structure detection)와 콘텐츠 추출 (content extraction)을 분리하세요. "X, Y 위치의 값"을 추출하는 대신, 콘텐츠가 실제로 어떻게 보이는지, 즉 레이블이 지정된 필드(labeled field), 헤더 행이 있는 테이블(table), 또는 산문 블록(block of prose)인지에 기반하여 추출하세요. 좌표를 하드코딩하지 않기 때문에 레이아웃 변화 (layout shifts)에 더 견고합니다.

2. 스키마 (schema)뿐만 아니라 원본과 대조하여 검증하세요. 출력된 JSON이 형식에 맞는지 확인하는 것만으로는 부족합니다. 추출된 샘플을 실제 원본 문서와 대조하여 점검(spot-check)하세요. 필드가 완벽하게 유효한 JSON이라 할지라도 잘못된 위치에서 추출될 수 있습니다.

3. 도구를 선택할 때 형식 드리프트 (format drift)를 예외가 아닌 상수로 취급하세요. 추출 도구를 평가하고 있다면, 가장 깨끗한 문서로만 테스트하지 마세요. 스캔된 사본, 방식이 다른 공급업체의 문서, 테이블이 여러 페이지에 걸쳐 있는 문서 등 가장 지저분한 문서들로 테스트하세요. 도구 간의 진짜 차이는 바로 그 지점에서 나타나며, 깨끗한 데모 환경에서는 보이지 않습니다.

4. "AI 기반 (AI-powered)"이라는 말이 형식에 구애받지 않는다 (format-agnostic)고 가정하지 마세요. 많은 도구가 AI 기반 추출이라고 마케팅하지만, 내부적으로는 여전히 템플릿 매칭 (template matching)이나 고정 스키마 추출 (fixed-schema extraction)을 수행하고 있습니다. 라벨이 문제를 해결해 줄 것이라고 가정하기보다 실제로 테스트해 볼 가치가 있습니다.

이것이 바로 Corvic에서 우리가 진정으로 해결하고자 노력해 온 문제입니다. 우리는 고정된 레이아웃을 가정하는 대신, 일관되지 않은 실제 세계의 문서 구조를 중심으로 설계된 추출 방식을 구축하고 있습니다. 덕분에 공급업체가 올해 들어 세 번째로 인보이스 템플릿을 변경하더라도 견고하게 작동합니다.

시사점 (The takeaway)

만약 여러분의 PDF 파이프라인 (pipeline)이 테스트 단계에서는 훌륭하게 작동하다가 운영 (production) 환경에서 무너진다면, 문제는 대개 여러분의 코드가 아닙니다. 그것은 여러분이 사용 중인 추출 (extraction) 방식에 내재된 가정 (assumption) 때문입니다. 현실 세계의 문서들은 가만히 멈춰 있지 않습니다. 여러분이 무엇을 구축하든 (혹은 구매하든), 이를 나중에 패치해야 할 예외 사례 (edge case)로 취급할 것이 아니라, 첫날부터 당연한 것으로 예상해야 합니다.

다른 분들은 이 문제와 관련하여 어떤 경험을 했는지, 특히 스캔된 문서 (scanned documents)나 여러 페이지에 걸쳐 있는 표 (tables)와 관련하여 궁금합니다. 여러분에게 가장 빈번하게 문제를 일으키는 것은 무엇인가요?