데이터 제공업체를 위한 PDF 추출
레이아웃에서 실패합니다

데이터 제공자의 받은 편지함은 실제로 어떤 모습인가

데이터 제공자의 입력은 그 다양성에 의해 정의되며, 그 다양성이 파이프라인이 견뎌야 할 대상입니다. 데이터 제공자를 위한 PDF 추출은 반복되는 하나의 읽기 문제가 아니라, 보낸 사람마다 다른 읽기 문제입니다. 문서는 다양한 출처에서 도착하며, 어떤 두 출처도 같은 방식으로 파일을 만들지 않습니다. 유통업체는 표에 가격이 있는 제품 카탈로그를 보냅니다. 정부 기관은 스캔된 PDF로 규제 서류를 게시합니다. 파트너는 독자가 원하는 숫자가 다단 레이아웃의 3페이지에 묻혀 있는 분기 보고서를 보냅니다. 고객은 마지막 개정에서 필드 라벨이 이동한 작성 가능한 양식을 보냅니다.

형식의 혼합은 출처의 혼합만큼 중요합니다. 일부 파일은 디지털로 생성되어 페이지 아래에 선택 가능한 텍스트 레이어가 여전히 있습니다. 일부는 스캔본으로, 모든 문자가 문자의 그림이며 선택할 텍스트가 없습니다. 많은 실제 파일은 동시에 둘 다입니다. 1페이지는 디지털이고, 2~5페이지는 PDF에 스테이플로 고정된 종이 양식의 스캔입니다. 독자는 그 페이지들 사이를 알아차리지 못하고 넘길 수 있습니다. 1페이지에 대해 작성된 규칙은 3페이지에서 깨집니다.

동일한 필드가 모든 출처에서 다른 위치에 있으며, 스캔된 출처에서는 위치가 전혀 없고 픽셀만 있습니다.

그것이 아래 모든 내용의 배경입니다. 문제는 특정 PDF 하나가 읽기 어려운지 여부가 아닙니다. 문제는 다음 출처와 그 다음 출처가 한 번도 본 적 없는 레이아웃으로 도착할 때 파이프라인에 어떤 일이 일어나는지입니다.

출처별 파서 하나가 깨지는 이유

레이아웃에 의존하는 파서는 레이아웃이 변경되지 않을 것이라는 약속을 암시하며, 통제할 수 없는 출처는 그 약속을 할 수 없습니다. 영역 기반 및 템플릿 기반 파서는 위치를 가리키는 방식으로 작동합니다. 송장 합계 주위에 사각형을 그리거나 "Total"이라는 단어를 찾아 오른쪽 숫자를 읽는 규칙을 작성합니다. 규칙은 정확하며, 그 정확성이 정확히 실패하는 지점입니다. 보낸 사람이 열 제목을 바꾸거나, 두 필드의 순서를 바꾸거나, 업데이트된 시스템에서 동일한 데이터를 다시 내보내면 규칙은 잘못된 값을 읽거나 아무것도 읽지 못합니다. 도구 시장도 같은 차이를 반영합니다. 영역 및 템플릿 파서, AWS Textract와 같은 일반 OCR 서비스, LlamaParse와 같은 레이아웃 우선 파서는 각각 구조화된 출력으로 가는 다른 길을 택하며, 실질적인 질문은 각각이 얼마나 많은 레이아웃 변형을 기대하는지와 피드 중 얼마나 많은 부분을 직접 조립해야 하는지입니다.

실패는 예외로 처리할 만큼 드물지 않습니다. 이는 소스가 많은 피드의 정상적인 수명 주기이며, 해당 파이프라인을 운영하는 사람들은 이를 있는 그대로 표현합니다. 다양한 소스의 데이터를 처리하는 방법에 대한 r/dataengineering 스레드에서 한 엔지니어는 이렇게 썼습니다: "클라이언트가 데이터를 내보내는 방식이 보통 달라서 스크립트가 더 이상 작동하지 않게 됩니다. 그래서 다시 작성해야 합니다. 여기에 서로 다른 추출 형식을 가진 수백 개의 클라이언트가 결합되면 이것이 얼마나 큰 골칫거리인지 알 수 있습니다." 해당 스레드는 실제 비용이 첫 번째 스크립트가 아니라 끊임없는 재작성이라는 점을 지적합니다.

비용이 발생하는 곳은 재작성입니다. 깨진 소스 하나하나가 엔지니어의 시간이며, 엔지니어의 시간에는 가격이 있습니다. 미국 노동통계국(U.S. Bureau of Labor Statistics)에 따르면 2025년 5월 기준 소프트웨어 개발자의 연봉 중앙값은 $135,980이고 평균은 $148,100입니다. 이는 전 산업에 걸친 국가 통계이지만 문제의 규모를 가늠하기에는 충분합니다. 몇 주마다 새 규칙이 필요한 피드는 일회성 통합이 아닙니다. 이는 시니어 개발자의 시간으로 지불하는 구독입니다. 동일한 논리가 제대로 스캔되지 않은 단일 페이지에도 적용됩니다. 고정할 좌표가 없는 규칙은 사각형을 옮기는 방식으로는 수리할 수 없기 때문입니다.

스캔 문서는 문제의 두 번째 측면을 드러냅니다. 영역 기반 파서는 고정된 위치가 필요한데 스캔은 신뢰할 수 있는 위치를 제공하지 않습니다. 기울어짐, 잘림, 압축은 모두 가져오기 사이에 픽셀을 몇 단위씩 이동시킵니다. 이것이 템플릿 기반 도구에 대한 유지보수 논의가 항상 같은 결론에 도달하는 이유입니다. 해당 모델이 공급업체별로 어떻게 작동하는지 더 자세히 비교하려면 PDF 파서의 템플릿 유지보수 분석을 참조하세요.

계약을 페이지에서 출력으로 옮기기

지속 가능한 해결책은 추출 계약을 전달하려는 필드로 정의하고, 문서가 해당 필드의 위치를 결정하지 못하게 하는 것입니다. 이것이 위치 기반 추출과 의미 기반 추출의 차이입니다. 상자를 그리고 숫자가 그 안에 유지되기를 바라는 대신, 원하는 값을 지정하면 모델이 페이지를 읽어 해당 값을 의미하는 콘텐츠가 어디에 있든, 어떤 레이아웃으로 둘러싸여 있든 찾아냅니다.

ImageToTable.ai는 전체 제품을 이 아이디어를 중심으로 구축합니다. 이를 Custom Column Extraction이라고 하며, 말 그대로 작동합니다: Product SKU, Product Name, Unit Price, Currency, Effective Date와 같은 열 이름을 입력하면 AI가 각 값의 의미를 이해하여 찾아냅니다. 입력한 열 이름은 출력의 헤더가 되므로, 페이지를 설명하는 규칙이 아닌 일반 언어로 피드의 스키마를 정의하게 됩니다. 3열 가격표가 있는 공급업체 카탈로그와 동일한 수치가 산문으로 적힌 스캔된 정부 문서 모두 동일한 행을 채웁니다.

이 전환의 두 번째 부분은 작업이 배치로 이루어진다는 것입니다. 데이터 제공업체는 한 번에 하나의 문서를 처리하지 않으며, 그렇게 가정하는 설계는 실제 소스와의 접촉을 견디지 못합니다. ImageToTable.ai는 일괄 우선 처리 방식입니다: 한 소스 또는 여러 소스에서 많은 파일을 업로드하면 함께 처리되어 하나의 테이블로 통합됩니다. 새 발신자를 추가한다고 해서 파서가 추가되는 것은 아닙니다. 이미 작동하는 동일한 열 세트에 파일이 추가될 뿐이며, 이것이 바로 이 접근 방식이 소스별 규칙보다 우수한 이유입니다.

두 가지 열 유형이 피드에 일반적으로 필요한 형태를 다룹니다. 직접 열은 단가와 같이 문서에 기록된 값을 가져옵니다. 추론 열은 문서에 인쇄되지 않은 값을 생성합니다. 예를 들어 Category (options: Hardware/Electrical/Plumbing/Other)로 정의된 정규화된 범주가 있으며, 모델이 제품을 읽고 분류합니다. 계산 열은 추출 중에 계산합니다. 예를 들어 피드가 전달하는 두 필드에서 파생된 마진이 있습니다. 그렇지 않으면 웨어하우스에서 두 번째 작업이 될 분류와 산술 연산이 동일한 패스에서 수행됩니다.

API를 통한 피드 전달

전달은 다운스트림 클라이언트가 실제로 보는 절반이며, 데이터 제공자에게는 추출 자체만큼이나 중요한 부분입니다. 배치의 출력은 깔끔하고 구조화된 JSON입니다. 지정한 필드가 키가 되고, 날짜와 금액은 추출 중에 표준화되어 다운스트림 스크립트에서 직접 수정할 필요가 없습니다. 동일한 배치를 Excel 또는 CSV로 내보낼 수도 있지만, 피드는 일반적으로 코드로 소비되며 코드는 JSON을 원합니다.

v1 API는 해당 작업을 위한 공개 REST 인터페이스이며, 사실상 이 도구를 자체 코드에서 호출할 수 있는 PDF-to-structured-data API로 전환합니다. 문서를 업로드하고, 배치 처리를 실행하고, 웹 앱을 건드리지 않고 상태와 결과를 조회할 수 있어 일회성 내보내기가 아닌 파이프라인에 적합합니다. 처리는 비동기식입니다. 작업을 제출하면 작업이 반환되고, 작업은 성공하거나 실패할 때까지 몇 가지 상태를 거칩니다. 작업 완료 여부를 API에 반복적으로 묻는 대신 webhook을 등록하면 결과가 준비되었을 때 서비스가 사용자의 엔드포인트를 호출합니다. 이렇게 하면 폴링 트래픽이 제거되고, 더 중요하게는 파이프라인이 완료된 배치에 반응할 수 있어 언제 확인할지 추측할 필요가 없습니다.

이 교환의 출력 측면에는 업계 표준이 있습니다. JSON Schema는 JSON 문서가 따라야 하는 구조를 설명하기 위한 표준화된 어휘로, json-schema.org에서 유지 관리됩니다. ImageToTable.ai는 별도의 스키마 파일이 아닌 열 이름으로 동일한 계약을 정의하며, API는 해당 이름으로 필드를 반환합니다. 실용적인 요점은 데이터 제공자가 관심을 두는 부분입니다. 피드의 형태는 소스 문서의 형태와 무관하게 사용자가 지정하고 안정적으로 유지하는 것입니다.

공급업체 카탈로그 배치는 요청한 대로 보이는 레코드로 반환됩니다.

[
  {
    "Product SKU": "AC-1180",
    "Product Name": "Stainless Steel Clamp",
    "Unit Price": 4.75,
    "Currency": "USD",
    "Effective Date": "2026-09-01",
    "Category": "Hardware"
  },
  {
    "Product SKU": "EL-2044",
    "Product Name": "12AWG Copper Wire, 100m",
    "Unit Price": 89.9,
    "Currency": "USD",
    "Effective Date": "2026-09-01",
    "Category": "Electrical"
  }
]

값은 예시일 뿐이지만 구조는 그렇지 않습니다. 각 문서는 하나의 레코드가 되고, 키는 사용자가 지정한 열이며, Category는 제품 설명에서 자동으로 채워지는 추론 열입니다. 다운스트림 클라이언트가 다른 필드 이름을 필요로 하는 경우 열 이름을 변경하면 키도 함께 변경됩니다.

견고한 설정

구성은 소스별이 아니라 피드별로 한 번만 내리는 짧은 결정 목록입니다. 고객이 소비하는 결과물을 기준으로 거꾸로 작업하세요.

제공하지 않는 기능

제공된 문서에서 추출하며, 문서를 직접 가져오지 않습니다. 이 도구는 웹 스크래퍼나 크롤러가 아닙니다. 소스 사이트를 방문하여 PDF를 자체적으로 다운로드하는 구성 요소는 없습니다. 앱 또는 API를 통해 파일을 제공하면 서비스가 이를 읽습니다. 예약된 가져오기, 소스 모니터링 및 다운로드 로직은 사용자가 직접 실행해야 합니다.

완성된 데이터 소스 파이프라인이 아닙니다. v1 API는 배치를 구조화된 JSON으로 변환하고 완료 시 알려줍니다. 해당 JSON이 저장되는 위치, 버전 관리 방법, 다른 테이블과의 조인 방법, 작업 실패를 감시할 주체를 결정하는 것은 여전히 사용자 시스템의 몫입니다. API를 파이프라인 자체가 아닌 파이프라인 내부의 추출 단계로 취급하십시오.

소스별 파서를 구축하지 않으며, 이는 양날의 검입니다. 매우 특이한 발신자 한 곳을 위해 규칙을 수동으로 조정할 수 있는 이론적 옵션은 잃게 됩니다. 대신 모든 발신자에 걸쳐 수정 없이 작동하는 열 집합을 얻을 수 있으며, 이는 다양한 형식의 피드를 원하는 경우 선택할 만한 절충안입니다.

문서를 읽을 뿐, 문서 간의 대조는 수행하지 않습니다. 페이지의 필드를 채우고 문서 내에서 값을 계산합니다. 레코드를 외부 데이터베이스와 일치시키거나, 가격을 검증하거나, 한 소스의 수치를 다른 소스의 수치와 교차 확인하지는 않습니다. 이러한 판단은 사용자 코드와 검토자의 몫입니다.

정확도는 높지만 완벽하지는 않습니다. 당사가 인용하는 인쇄 테이블 수치는 특정 입력 유형에 대한 당사 자체 수치인 최대 99% 인식률입니다. 밀집된 손글씨, 흐린 스캔 및 비정형 레이아웃은 이보다 낮으며, 이것이 바로 Review Mode와 Bbox verification이 존재하고 불확실한 필드가 여전히 사람의 검토를 거쳐야 하는 이유입니다. 처리는 비동기식이므로 동일한 호출에서 답변 대신 작업을 반환합니다. 입력에는 PDF, JPG, PNG, WebP, AVIF 및 웹페이지 스크린샷이 포함되며, 출력에는 JSON, Excel, CSV 및 Word가 포함됩니다.

관련 맥락이 필요하다면 PDF 데이터 추출 소프트웨어에서 일반적인 도구 비교를 다루고, 문서 파서 개요에서 파싱과 추출의 관계를 설명합니다. 특정 방식으로 피드를 표준화하기 전에 두 문서를 모두 읽어 보시기 바랍니다.

자주 묻는 질문

스캔된 PDF와 스캔 및 디지털 페이지가 혼합된 파일에서도 작동하나요?

예. 스캔된 페이지와 디지털 원본 페이지는 동일한 추출 과정을 거치며 동일한 필드를 반환합니다. 1페이지는 디지털이고 2페이지는 스캔인 파일도 하나의 문서로 처리되므로 별도의 OCR 경로나 별도 업로드가 필요하지 않습니다.

API가 제 필드 이름을 사용하는 JSON을 반환할 수 있나요?

예. 입력한 열 이름이 출력의 키가 됩니다. 다운스트림 클라이언트가 Unit Price 대신 Price를 기대하는 경우 열 이름을 바꾸면 키도 함께 변경됩니다. 출력은 문서당 레코드 하나이며, 날짜와 금액은 추출 중에 표준화됩니다.

배치가 완료되었는지 어떻게 알 수 있나요?

처리는 비동기 방식이므로 제출된 배치는 조회 가능한 작업을 반환합니다. 파이프라인의 경우 webhook을 등록하면 결과가 준비되었을 때 서비스가 사용자의 엔드포인트를 호출하므로 폴링이 필요 없습니다. 인바운드 호출을 받을 수 없는 환경이라면 폴링을 대체 수단으로 사용할 수 있습니다.

레이아웃이 완전히 다른 소스에서도 동일한 필드를 추출할 수 있나요?

영역을 그리는 대신 열 이름을 지정하는 것이 바로 그 목적입니다. 모델은 의미를 기준으로 각 값을 찾으므로 카탈로그 표와 산문 형식의 서류 모두 동일한 열 세트를 채웁니다. 새 소스에 대해 새 템플릿이나 새 스크립트가 필요하지 않습니다.

모델이 확신하지 못하는 필드는 어떻게 되나요?

해당 필드도 표시되지만 검토가 필요합니다. Bbox verification이 포함된 Review Mode를 사용하면 사용자가 셀을 클릭하여 원본 페이지에서 해당 값이 추출된 정확한 영역을 확인한 후 수정할 수 있습니다. 금액 및 신원 관련 필드의 경우 이러한 검토가 예외가 아니라 기본값이어야 합니다.

무료 체험판이 있나요?

가입은 무료이며 자체 문서로 테스트할 수 있는 크레딧이 포함됩니다. 결정하기 전에 서로 다른 두 소스에서 배치를 실행하여 동일한 열 세트가 둘 다 채워지는지 확인하세요. 이 페이지의 데모는 계정 없이 실행됩니다.

유지 관리 대상은 가정(Assumption)입니다

소스의 레이아웃이 변경될 때 깨지는 피드는 실제로 PDF를 유지 관리하는 것이 아닙니다. 각 값이 마지막으로 발견된 위치에 계속 있을 것이라는 가정을 유지 관리하는 것입니다. 보낸 사람이 내보내기를 업데이트하거나 스캔이 약간 비뚤어져 돌아올 때마다 조용히 실패하는 것은 바로 그 가정입니다. 전달할 필드의 이름을 지정하고, 의미별로 추출하고, 문서를 배치 처리하고, 결과를 JSON으로 전달하면 레이아웃을 더 이상 방어할 필요가 없습니다. 피드가 유지되는 이유는 계약이 다른 사람의 페이지가 아닌 출력물에 있기 때문입니다.