pdfplumber·Camelot·tabula-java 테스트 PDF 143개로 PDF-to-Excel 도구를 검증했습니다

AI 요약

PDF를 Excel로 변환하는 도구를 만든 작성자가 pdfplumber, Camelot, tabula-java 테스트 스위트에 포함된 PDF 143개로 검증했습니다. 변환한 파일 수보다 잘못된 결과를 경고 없이 내보내는 경우를 중요하게 봤습니다.

경고 없이 나온 오류

첫 검사에서 경고 없이 잘못 변환한 결과가 7개였습니다. 날짜 열이 둘로 쪼개지거나, 텍스트가 중복돼 ‘AAAANNNN’처럼 출력되거나, 180도 돌아간 페이지에서 ‘Dummy PDF file’을 거꾸로 읽은 사례가 있었습니다. 이후 셀을 수정하지 않고 경고만 추가하는 검사를 만들었습니다.

직접 확인에서 발견한 결함

도구가 ‘정상’으로 분류한 결과 82개 가운데 21개를 직접 살펴봤고, 그중 3개에서 검사기가 잡지 못한 결함을 발견했습니다. 작성자는 이 결과를 정확도 수치로 포장하지 않고 공개했습니다. 테스트 PDF는 일부러 어려운 사례를 담고 있지만, 실제 카탈로그·견적서·가격표에서 어떻게 작동하는지는 아직 확인하지 못했다고 밝혔습니다.

파일 간 구조 비교 제안

댓글에서는 경고를 설계할 때 이미 확인한 오류 7개와, 검사기에 맞춰 사용하지 않은 21개를 구분해야 한다는 의견이 나왔습니다. 21개에서 발견한 3건은 검사기의 놓침을 살피는 자료지만, 표본이 적어 추정 범위가 넓다는 설명입니다. 또 파일 하나 안에서 이상을 찾는 검사만으로는 공급업체가 서식 자체를 조용히 바꾼 경우를 잡기 어렵다는 지적도 나왔습니다. 이전 실행 결과와 열 개수·헤더를 비교하면 이런 변화를 감지할 수 있습니다.

검사 결과를 설명하는 방식

구조를 직접 읽는 처리 경로에서는 셀마다 PDF 페이지와 경계 상자 정보를 붙여 경고가 위치를 가리킬 수 있습니다. 반면 기존 대체 경로에서는 반복 문자가 있는 셀의 수나 헤더가 없는 열처럼 파일 단위로만 알립니다. 작성자는 다음 테스트부터 오류를 ‘한눈에 알아보기’, ‘PDF를 열어 확인하기’, ‘PDF를 열고 숫자까지 확인하기’처럼 찾는 데 드는 노력으로 나누겠다고 답했습니다.

Indie Hackers 반응

• @kevinbai — 직접 확인한 21개는 이미 별도 검증 집합입니다. 앞서 발견한 7개 오류를 기준으로 경고를 설계했으니 그 7개만으로는 검사기가 놓치는 오류를 알기 어렵지만, 21개는 경고를 조정하는 데 쓰지 않았으므로 3건은 검사기의 미탐률을 추정하는 실제 자료입니다. 21개뿐이라 범위가 넓어도, 솔직하게 넓은 범위를 말하는 편이 숫자를 아예 내놓지 않는 것보다 낫습니다. 교차 실행 구조 비교는 경고가 아니라 통과 조건으로 삼아야 한다고 봅니다. 공급업체가 서식을 바꾸면 모든 셀이 내부적으로는 그럴듯하게 나와 파일 내부 검사만으로는 경고가 울리지 않을 수 있습니다. 이전 실행과 열 개수·헤더를 비교하면 월간 가격표처럼 반복되는 문서에서 이런 변화를 잡을 수 있습니다. 셀을 수정하지 않고 경고만 하는 것도 옳습니다. 검사기가 검사 대상까지 편집하면 스스로 정답을 맞춘 것처럼 만들 수 있어 더는 검사 성능을 측정할 수 없습니다.
• @tsutsu — 경고 없이 나온 오류 7건을 공개하고 정확도 수치를 내세우는 대신 경고를 추가한 점이 솔직해서 좋습니다. 정상 결과 21개를 직접 확인해 3건을 놓쳤다는 내용도 신뢰를 쌓습니다. 도구가 잘 되길 바랍니다.
• @josuarc1307 — 검사가 셀을 건드리지 않고 경고만 한다는 점에서 오류 양상을 더 믿을 수 있습니다. 다음 과제가 실제 PDF라면 전체 파일을 보내지 않아도 사례를 공유하도록 페이지, 기대값과 실제값, 경고 발생 여부를 적는 간단한 보고 양식을 만들면 좋겠습니다. 각 보고를 회귀 테스트 사례로도 쓸 수 있습니다. 현재 페이지와 경계 상자 메타데이터로 가능할까요?
• @Youssef_Bezza — ‘잘못된 결과를 알리지 않는 경우’가 추적할 수치라는 말에 동의합니다. 아무도 알아채지 못한 잘못된 셀은 변환을 거부하는 것보다 더 나쁩니다. 정상 결과 82개 중 21개를 직접 확인했고 3개를 놓쳤다고 밝혀서 다른 수치도 더 믿게 됩니다. ‘검토 필요’ 표시가 확인할 셀을 가리키나요, 아니면 파일 전체를 가리키나요?
• @innokentyB — 직접 고른 데모보다 기존 파서의 테스트 스위트를 쓴 점이 더 나은 출발입니다. 다만 문서 종류별 비중, 추출된 셀의 정답을 판정하는 기준, 테스트 스위트가 실제로 잡아낼 수 있는 결함을 따로 구분해야 합니다. 표를 잘 복원해도 단위, 부호, 병합 헤더, 각주를 조용히 바꿀 수 있습니다. 평가기가 올바른 이유로 실패하는지 확인하려고 의도적으로 오류를 넣어봤나요?
• @ryanshrott — 직접 확인한 정상 결과에서 나온 3건이 유용한 발견입니다. 검사기가 셀을 조용히 고치지 않고 경고만 하기 때문입니다. 음성 입력도 비슷합니다. 결과가 매끄러워 보여도 이름이나 숫자 하나가 틀리면 일이 늘어납니다. 다음 테스트에서는 변환 완료 여부뿐 아니라 오류를 찾는 데 드는 노력도 분류해 보세요. 경고가 정확한 셀과 PDF 원문 영역을 가리킬 수 있나요?
  • @Liu — 유용한 관점입니다. 솔직히 말하면 일부 경로에서만 가능합니다. 태그가 있는 표, 선으로 구분된 표, OCR처럼 구조를 직접 읽는 경로에서는 셀마다 페이지와 경계 상자가 있어 경고가 정확한 셀과 PDF 영역을 가리킵니다. 대부분의 경고 파일을 만든 기존 대체 경로에서는 ‘반복 문자가 있는 셀이 N개’ 또는 ‘이 열에 헤더가 없음’처럼 파일 단위로만 알립니다. 셀 위치까지는 아직 가리키지 못합니다. 직접 찾은 결함 3개는 경고가 없었으므로 위치를 알려줄 수도 없습니다. 다음 테스트에서 오류를 ‘한눈에 알아보기’, ‘PDF를 열어 확인하기’, ‘PDF를 열고 숫자까지 확인하기’로 나눠 보겠습니다. 마지막 유형이 위험합니다.
• @dataox — 중요한 수치는 변환한 파일 수가 아니라 조용히 빠져나간 오류 수라는 데 전적으로 동의합니다. 운영 파이프라인에서 그게 주된 문제입니다. 정상 결과 21개 중 3개에서 결함을 찾고 그 사실을 정확도라고 포장하지 않은 점도 좋습니다. 파일별 검사뿐 아니라 이전 실행과 열 개수·헤더 같은 출력 구조를 비교하는 검사도 유용합니다. 저희는 자체 스크래퍼를 모니터링할 때 그렇게 합니다. Python으로 PDF 파일을 대량 수집할 때 생기는 문제를 정리한 글도 있습니다.
  • @Liu — 좋은 지적입니다. 아직 추가하지 않은 검사입니다. 지금까지 만든 기능은 모두 파일별로 작동해 PDF 하나 안의 내용을 보고 결과에 경고를 붙입니다. 이전 실행과 열 개수나 헤더를 비교하면 공급업체가 서식을 조용히 바꿔 결과가 달라지는 문제를 잡을 수 있습니다. 월간 가격표처럼 반복되는 파일에서 특히 유용해 보여 추가를 검토하겠습니다. 어떤 PDF를 파이프라인에서 다루고, 어떤 종류가 먼저 깨지는지도 궁금합니다. 익명화한 실패 사례를 보내주시면 도구가 어떻게 처리하는지, 어디서 실패하는지 알려드리겠습니다.

원문: Indie Hackers / 번역·요약: Trawling