복합 PDF, 스캔, 스크린샷을 사용자가 지정한 열의 스프레드시트 하나로 변환하는 AI 문서 파서
문서 파서의 진짜 역할은 텍스트를 읽는 것이 아니라 각 텍스트가 무엇인지 판단하는 것입니다. 즉 레이블인지, 값인지, 테이블 셀인지, 메모인지 결정하는 일이죠. 기존 파서는 이런 결정을 규칙으로 코딩하게 만들지만, 레이아웃이 조금만 바뀌어도 그날부터 오작동합니다. 이 파서는 사람이 구조를 읽는 방식을 그대로 따르며, 문서당 한 행씩 사용자가 선택한 열로 결과물을 만들어냅니다.
Enterprise-grade security · TLS 1.3 encrypted
문서 파서가 파일에서 추출할 수 있는 항목
필요한 열 이름을 입력하면 AI가 위치가 아닌 의미를 이해하여 모든 페이지에서 각 값을 찾습니다. 비즈니스 사용자가 PDF 파서에 혼합 문서 더미에서 추출하도록 가장 자주 요청하는 필드입니다.
이 목록은 제한적이지 않습니다. 열 이름을 직접 지정하므로 문서에 포함된 모든 필드가 동일한 방식으로 작동합니다: 배송 추적 코드, 계약 갱신 날짜, 검사 결과 등. 페이지에 값이 적혀 있다면 열로 지정할 수 있습니다.
문서 파싱의 어려운 부분은 읽기가 아니라 모든 것이 무엇인지 판단하는 것입니다
광학 문자 인식은 수년 전에 읽기 문제를 해결했습니다. 픽셀을 문자로 바꾸는 것은 이미 해결된 기본 단계입니다. 파싱은 그 위의 계층이며, 실제 작업은 인식이 아닌 판단입니다. 어떤 텍스트가 라벨이고 어떤 것이 값인가? 테이블은 어디서 끝나고 본문은 어디서 시작하는가? 페이지의 어떤 합계가 총합인가? 템플릿 도구는 그 판단을 규칙 작성으로 넘깁니다. 개발자도 코드에서 같은 부담을 느낍니다. 최근 r/SaaS 스레드의 최상위 게시물 제목은 "PDF를 파싱하기 위해 정규식을 쓰는 데 지쳐서 타입 안전 JSON을 반환하는 API를 만들었습니다"로, 이 분야의 다른 절반이 어떻게 살아가는지 보여줍니다.
문제점
대부분의 파서는 읽기 순서로 텍스트를 추출합니다. "Invoice Date" 라벨이 헤더에 있고 그 값이 두 시각적 영역 떨어진 곳에 있는 페이지에서, 파서는 두 개의 관련 없는 문자열로 봅니다. 위치 기반 추출은 다중 열 레이아웃도 뒤섞어서, 오른쪽 열의 테이블이 왼쪽 열의 본문과 섞이게 됩니다. 텍스트는 모두 있지만 데이터로 만드는 관계가 사라져, 모든 다운스트림 필드는 수동 수리가 필요하게 됩니다.
전통적인 해결책은 규칙을 작성하는 것입니다: 하나의 레이아웃에 맞춘 키워드 앵커, 고정 좌표, 또는 정규식 패턴. 보낸 사람이 레터헤드를 업데이트하거나, 스캔이 약간 회전하거나, 새 공급업체가 앵커와 일치하지 않는 글꼴을 사용할 때까지는 작동합니다. 그러면 규칙은 조용히 실패하고, 스프레드시트 행이 비어 돌아올 때만 누군가 발견합니다. 다양한 소스의 문서를 파싱하는 팀은 레이아웃별 규칙 세트를 유지하게 되고, 파싱 도구는 조용히 두 번째 직업이 됩니다. 개발자 측에서도 패턴은 반복됩니다: 정규식 파이프라인은 첫 번째 형식 변경까지는 살아남지만, 그 후에는 재작성이 필요합니다.
많은 파싱 도구는 모든 텍스트 또는 페이지의 Markdown 스타일 덤프를 출력하고 작업이 끝났다고 말합니다. 그것은 중간 산출물이지 답이 아닙니다. 목표가 문서당 하나의 Excel 행에 Vendor, Date, Total을 고정 열로 넣는 것이라면, 텍스트 덤프는 수동으로 재구성해야 하는 작업을 남깁니다. 출력 형태가 결과물이며, 대부분의 파서가 완성하지 못하는 부분입니다.
맞춤 열 추출이 이 문제를 해결하는 방법
ImageToTable.ai는 사람처럼 전체 페이지를 보는 비전 모델 기반으로 구축되었습니다. 테두리 있는 그리드와 목록, 문단을 구분하고, 병합된 헤더 셀을 해당 열에 연결하며, 사이드 테이블을 본문 텍스트와 섞지 않습니다. 그래서 의미 기반 읽기가 중요합니다. AI가 텍스트 블록이 표임을 알면 행이 읽기 순서의 문자 스트림이 아닌 행으로 출력되기 때문입니다.
맞춤 열 추출을 사용하면 원하는 필드 이름을 입력하기만 하면 AI가 위치가 아닌 의미를 이해하여 페이지 어디서든 각 값을 찾습니다. 배치할 앵커 키워드도, 그릴 좌표도, 디버깅할 정규식도 없습니다. 다음 분기에 발신자가 문서를 재설계해도 사용자 측에서는 아무것도 변경되지 않습니다. 동일한 열 이름이 계속 작동하는 이유는 AI가 규칙을 재실행하는 대신 새 레이아웃을 다시 읽기 때문입니다.
파싱된 각 문서는 스프레드시트의 한 행이 되며, 요청한 각 필드는 사용자가 이름을 지정한 열에 배치됩니다. Excel에서 검토할 XLSX, 다른 시스템으로 가져올 CSV, 또는 다운스트림 프로그램이 소비자인 경우 JSON으로 내보낼 수 있습니다. 구조화된 테이블 출력과 원시 텍스트 덤프는 서로 다른 용도를 제공하며, 이 도구는 전자를 직접 생성하므로 재구성 단계가 사라집니다. 날짜, 금액, 참조 번호는 추출 중에 정규화되므로 열에 들어가는 값은 정리해야 할 문자열이 아닌 유형화된 데이터입니다.
혼합 문서 폴더 하나가 세 단계로 단일 스프레드시트가 됩니다
다양한 발신자로부터 다양한 형식의 문서를 받고, 핵심 필드를 한곳에 모아야 한다면, 업로드부터 출력까지의 워크플로는 다음과 같습니다.
혼합 형식 그대로, 한 번의 배치로 모두 업로드하세요
PDF, 스캔본, 사진, 스크린샷을 함께 넣으세요. 도구는 PDF, JPG, PNG, WebP, AVIF를 지원하며, 비밀번호를 제공하면 암호로 보호된 PDF도 처리합니다. 파일을 레이아웃이나 발신자별로 미리 분류할 필요도, 파일 유형별로 템플릿을 고를 필요도 없습니다. 배치 처리는 단일 작업으로 여러 파일을 실행하므로, 서로 다른 문서로 가득한 폴더 전체가 하나의 업로드가 됩니다. 고객이나 현장 직원이 보내는 문서의 경우, 수집 링크를 통해 짧은 확인 코드를 입력한 후 계정 없이도 바로 대기열에 업로드할 수 있는 공유 URL을 제공할 수 있습니다.
열을 한 번 정의하면, 동일한 정의로 모든 레이아웃을 읽습니다
예를 들어 "참조 번호", "공급업체 또는 발신자 이름", "문서 날짜", "총 금액", "납기일" 등 원하는 필드를 입력하세요. 그러면 AI가 각 문서를 개별적으로 읽고, 해당 페이지에서 원하는 값을 찾아냅니다. 빽빽한 공급업체 인보이스, 2단 신청서, 촬영된 배송 메모 모두 동일한 열 정의로 파싱됩니다. 추출은 저장된 위치가 아닌 의미를 기준으로 작동하기 때문입니다. 문서에 명시적으로 인쇄되지 않은 값이 필요하다면, 계산 열을 사용하여 동일한 패스에서 파생할 수 있습니다(예: "라인 합계").
바로 사용할 수 있는 통합 스프레드시트를 받으세요
각 문서는 하나의 행으로 반환되며, 요청한 모든 필드는 이름이 지정된 열에 정렬됩니다. 따라서 혼합 문서 60개 배치는 60행 스프레드시트가 됩니다. Excel에서 계속 작업하려면 XLSX로, 가져오기용으로는 CSV로, 프로그램이 소비자라면 JSON으로 내보낼 수 있습니다. Word 내보내기는 편집 가능한 형태로 문서 자체가 필요할 때 원본 레이아웃을 보존합니다. 페이지 한 장을 수동으로 입력하는 데는 평균 약 3분이 걸리지만, 파싱된 페이지는 5~10초가 걸리며, 전체 배치는 수작업으로 처리하던 문서 몇 장과 같은 시간 안에 완료됩니다.
시각 문서 파서가 적합한 경우와 다른 도구가 더 나은 경우
가장 적합한 경우
레이아웃이 수시로 바뀌는 다양한 발신자의 문서. 템플릿 도구가 가장 취약하고 시각적 파싱이 가장 잘 처리하는 경우입니다. 각기 다른 디자인의 수십 개 출처에서 도착하는 인보이스, 명세서, 양식, 메모 등이 있으며, 발신자가 문서를 재설계해도 유지 관리할 규칙이 없습니다.
디지털 PDF뿐 아니라 스캔, 사진, 스크린샷도 포함. 스캔한 종이, 촬영한 양식, 앱 스크린샷이 동일한 시각적 판독으로 파싱되므로, 하나의 워크플로우로 디지털 생성 입력과 이미지 기반 입력을 혼합 배치까지 포함해 함께 처리할 수 있습니다.
스프레드시트와 다운스트림 시스템을 위한 필드 수준 출력. 결과물이 Excel, 데이터베이스 가져오기, API에 공급되는 명명된 열일 때, 문서당 한 행에 날짜와 금액이 정규화된 형태로 바로 도착하며 재구성 단계가 필요 없습니다.
주의가 필요한 경우
기계 생성 텍스트 형식은 기존 데이터 파서에 적합합니다. 입력이 이미 구조화된 텍스트, CSV 파일, 로그 라인, JSON 피드, API 응답이라면 규칙 기반 데이터 파서가 더 가벼운 도구입니다. 해석할 시각적 구조가 없고 결정적 규칙이 더 빠르며 대량 처리 시 무료로 실행되기 때문입니다.
텍스트 없이 그래픽으로만 존재하는 값. 서명, 도장, 차트는 시각적으로 전달되며, 이러한 요소는 페이지에서 위치를 찾을 수 있지만 텍스트 형태가 없는 순수 그래픽으로 그려진 데이터 포인트는 열에 담을 수 없습니다. 값이 중요하다면 문서 어딘가에 텍스트로 존재해야 합니다.
손글씨 품질이 한계를 결정합니다. 인쇄 텍스트는 안정적으로 파싱되지만 손글씨는 가독성에 따라 달라집니다. 또렷하고 간격이 좋은 손글씨는 합리적인 정확도로 추출되지만, 급하게 쓴 필기체, 흐린 연필, 진한 취소선은 정확도를 떨어뜨리므로 새로운 손글씨 출처의 첫 출력물을 반드시 점검하세요.
자주 묻는 질문
문서 파서와 데이터 파서의 차이점은 무엇인가요?
데이터 파서는 CSV 파일, 로그 줄, JSON 피드, 웹 응답처럼 이미 구조화된 텍스트를 읽고 정규식 같은 규칙으로 형태를 바꿉니다. 문서 파서는 구조가 시각적인 문서, 즉 라벨, 값, 테이블, 각주가 페이지 모양으로만 구분되는 PDF, 스캔, 스크린샷을 처리합니다. ImageToTable.ai는 문서 파서입니다. 페이지에서 각 텍스트 조각이 의미하는 바를 읽고, 원시 텍스트 대신 이름이 지정된 스프레드시트 열을 출력합니다. 실제 입력이 PDF와 스캔인데 데이터 파서 도구를 찾고 있다면 필요한 것은 문서 파서이며, 그 반대도 마찬가지입니다.
이 파서는 이미지와 스크린샷에서도 데이터를 추출할 수 있나요?
네. ImageToTable.ai는 PDF 파서인 동시에 이미지 파서이자 이미지 텍스트 파서입니다. JPG, PNG, WebP, AVIF 스크린샷과 사진을 업로드하면 AI가 PDF에서 읽는 것과 동일한 시각적 구조를 읽습니다. 화이트보드에서 촬영한 테이블, 결제 앱 스크린샷, 종이 양식 스캔 모두 동일한 이름의 스프레드시트 열로 파싱됩니다. 이미지 안의 테이블은 테이블로 처리되며, 이는 PDF 테이블 파서 검색에서 보통 원하는 결과입니다. 이미지-텍스트 변환 단계도 별도 내보내기가 아니라 동일한 패스의 일부입니다.
이 문서 파서는 어떤 필드를 추출할 수 있나요?
열 이름을 직접 지정하므로 필드 목록도 직접 정의할 수 있습니다. 일반적인 선택 항목으로는 참조 번호, 문서 날짜, 공급업체 또는 발신자 이름, 총 금액, 세금 금액, 통화, 마감일, 라인 항목, 연락처 이메일, 전화번호, 청구 주소, 계정/PO 번호가 있습니다. AI는 위치가 아니라 의미로 각 값을 찾으므로 완전히 다른 레이아웃의 문서에서도 동일한 열 정의가 작동합니다. 문서에 명시적으로 인쇄되지 않은 필드도 처리됩니다. 계산 열은 "라인 합계" 같은 계산을 출력할 수 있고, 추론 열은 페이지에 카테고리 필드가 없어도 각 문서를 예를 들어 카테고리별로 분류할 수 있습니다.
레이아웃마다 파싱 템플릿을 만들거나 규칙을 작성해야 하나요?
아니요. 배치할 앵커 키워드도, 그릴 영역도, 유지할 정규식도 없습니다. 원하는 열 이름을 입력하면 AI가 저장된 위치를 재생하는 대신 의미를 이해하여 각 값을 찾습니다. 이것이 템플릿 기반 파서와의 구조적 차이입니다. 템플릿 기반 파서는 레이아웃마다 고유한 규칙 세트가 필요하고 발신자가 디자인을 바꿀 때마다 유지보수가 필요합니다. 이것이 r/Rag의 독립 리뷰어가 "PDF에서 구조화된 데이터로 가는 과정에서 사소한 수동 정리가 필요 없게" 하는 것이 기존 스택으로는 어려웠다고 지적한 이유이기도 합니다. 레이아웃 매칭 계층이 계속 문제를 일으키는 부분이며, 이를 제거해야 무인 파싱이 가능해집니다.
파싱된 문서를 어떤 형식으로 내보낼 수 있나요?
Excel (XLSX), CSV, JSON, Word입니다. XLSX는 기본 작업 형식으로, 문서당 한 행씩, 지정한 필드가 열로 구성됩니다. CSV는 다른 시스템으로 가져오기에 적합합니다. JSON은 사람이 아닌 프로그램이 출력을 사용할 때 적합하며, REST API가 반환하는 형식이기도 해서 자체 코드에서 파서를 호출하려는 경우에도 유용합니다. Word 내보내기는 유용한 방식으로 특별합니다. 필드 대신 원본 레이아웃이 유지된 전체 문서를 편집 가능한 형태로 반환하므로, 데이터 포인트가 아닌 문서 자체가 필요한 경우에 적합합니다.