배치 추출에서 파일의 절반이
누락된 이유는? 일반적인 실패 유형

1단계: 파일이 업로드 단계를 통과하지 못함

이것은 파일 누락의 가장 흔한 원인이며, 업로드 진행 표시줄이 매끄럽게 움직이기 때문에 간과하기 쉽습니다. 문제가 있는 파일이 대기열에 들어가기 전에 카운트가 멈출 뿐입니다. 도구는 이러한 파일을 "업로드됨"이 아닌 "시도됨"으로 등록하며, 파일별 오류 로그가 없으면 이 간격은 조용히 지나갑니다.

지원되지 않는 파일 형식

모든 이미지 및 문서 형식이 동일하게 취급되지는 않습니다. 대부분의 AI 추출 도구 — ImageToTable.ai 포함 — 는 PDF, JPG, PNG, WebP 및 AVIF를 지원합니다. 하지만 배치에 TIFF 파일, iPhone의 HEIC 사진 또는 이전 시스템의 BMP 스크린샷이 포함된 경우 업로드 처리기가 단순히 건너뛸 수 있습니다. 특히 TIFF는 흔한 문제입니다. 많은 스캐너가 여전히 다중 페이지 TIFF를 기본값으로 사용하며, TIFF는 유효한 이미지 컨테이너이지만 대부분의 추출 도구 입력 목록에는 없습니다. 파일이 업로드되는 것처럼 보이지만 처리 파이프라인은 이를 포착하지 않습니다.

확인 방법: 업로드 전에 소스 폴더를 파일 확장자별로 정렬하세요. .tiff, .heic, .bmp 또는 .svg가 보이면 먼저 JPG 또는 PNG로 변환하세요. 대부분의 운영 체제는 파일 탐색기 또는 Finder에서 일괄 변환할 수 있습니다. 30초의 변환 단계로 나중에 몇 시간의 고민을 절약할 수 있습니다.

손상되었거나 불완전한 파일

내 컴퓨터에서는 정상적으로 열리는 파일도 업로드 무결성 검사를 통과하지 못할 수 있습니다. 클라우드 다운로드가 중단되어 PDF의 마지막 페이지가 잘렸을 수 있고, 카메라 저장 실패로 이미지의 EXIF 헤더가 손상되었을 수 있습니다. 미리보기에서 "정상으로 보이는" 파일도 — OS가 캐시된 썸네일을 표시하기 때문에 — 추출 도구가 바이트를 읽으려 할 때 실패할 수 있습니다.

이 문제는 이메일 첨부 파일이나 클라우드 저장소 링크에서 다운로드한 파일에서 특히 흔합니다. 파일이 열리고 내용이 정상적으로 보여도 바이너리가 완전하지 않은 것입니다. 추출 도구는 미리보기를 읽는 사람과 달리 바이트를 읽으며, 손상된 바이트는 빈 결과를 만듭니다.

확인 방법: 의심되는 각 파일을 열어 다시 저장해 보세요. Adobe Acrobat에서는 "파일 → 다른 이름으로 저장 → 최적화된 PDF"를 사용하여 잠재적 손상을 제거할 수 있습니다. 이미지의 경우 사진 편집기에서 빠르게 다시 저장하면 일반적으로 헤더 문제가 해결됩니다.

파일 크기 제한

대부분의 추출 도구는 개별 파일 크기를 제한합니다. ImageToTable.ai의 표준 업로드 한도는 일반적인 사무 문서를 수용하지만, 200페이지 분량의 스캔 PDF나 48메가픽셀로 촬영한 고해상도 인보이스 사진은 이 한도를 초과할 수 있습니다. 도구가 항상 업로드를 눈에 띄게 거부하지는 않습니다 — 파일 메타데이터는 수락하지만 크기 임계값을 초과했음을 감지하면 실제 콘텐츠를 건너뛸 수 있습니다.

확인 방법: 업로드 전에 파일을 검토하세요. 단일 파일이 30-50MB를 초과하면 PDF 분할기를 사용하여 다중 페이지 PDF를 더 작은 문서로 나누거나, 업로드 전에 이미지 해상도를 줄이는 것을 고려하세요. PDFsam이나 Adobe Acrobat의 "문서 분할" 기능이 몇 초 안에 처리합니다.

파일 이름의 특수 문자

간과하기 쉬운 실패 모드입니다. INV-2026-03-15_återbetalning.pdf 또는 收据-001.jpg 또는 Invoice (final - DO NOT EDIT).pdf와 같은 파일 — 비ASCII 문자, 특수 기호 또는 매우 긴 경로 이름이 포함된 파일 — 은 서버 측 쓰기 단계에서 실패할 수 있습니다. 업로드 요청은 성공하고 서버는 파일 스트림을 수락하지만, 원래 파일 이름을 사용하여 임시 저장소에 파일을 쓰려고 할 때 파일 시스템이 문자 인코딩을 거부합니다. 파일은 HTTP 계층에서 "수신됨"으로 계산되지만 처리용 디스크에는 저장되지 않습니다.

확인 방법: 표준 영숫자 문자, 하이픈, 밑줄 외의 항목이 파일 이름에 있는지 확인하세요. 빠른 일괄 이름 변경 — 원래 이름 대신 INV-2026-03-15-refund.pdf — 으로 이 변수를 완전히 제거할 수 있습니다.

2단계: 업로드는 되었지만 처리 중 조용히 누락된 경우

이 단계는 업로드가 성공적으로 확인되었기 때문에 진단이 더 까다롭습니다. 도구에 30개 파일 업로드, 30개 녹색 표시가 나타납니다. 하지만 처리 단계 — AI가 각 문서를 실제로 읽고 데이터를 추출하는 동안 — 파일이 오류 상태를 트리거하지 않고 컨베이어 벨트에서 떨어질 수 있습니다. 처리 UI는 핵심 엔진이 작업을 완료했기 때문에 "완료"라고 표시하지만, 업로드된 문서보다 더 적은 수의 문서를 처리한 것입니다.

동시성 제한 및 큐 한도

AI 추출은 계산 비용이 많이 듭니다. 각 문서에는 비전 모델 추론이 필요하며, 이는 GPU 메모리와 API 처리량을 소비합니다. 안정성을 유지하기 위해 추출 도구는 사용자당 일반적으로 4~8개의 동시 처리 슬롯이라는 동시성 제한을 적용합니다. 50개 파일을 업로드하면 큐에 들어가고 도구는 4개씩, 그 다음 4개씩 웨이브로 처리합니다.

큐에 하드 캡이 있을 때 문제가 발생합니다. 일부 시스템은 큐 깊이를 초과하는 파일을 조용히 삭제합니다. 플랜에서 배치당 50개 파일을 허용하지만 동시 슬롯이 4개뿐이고, 처리 엔진이 처음 4개 파일 중 하나에서 지속적인 오류를 만나면 전체 웨이브가 지연되어 큐에 남은 파일이 시간 초과되어 폐기될 수 있습니다. UI에는 여전히 "50개 업로드, 46개 처리"로 표시되지만 누락된 4개는 실제로 시도되지 않은 것입니다.

확인 방법: 업로드를 10~15개 파일의 더 작은 배치로 나누어 순차적으로 처리하세요. 특정 배치가 지속적으로 파일을 잃는 반면 더 작은 배치는 그렇지 않다면 동시성 제한이 원인입니다. 이 동작은 Google Document AI부터 자체 호스팅 OCR 파이프라인에 이르기까지 여러 배치 처리 시스템에서 문서화되어 있으며, "업로드됨"과 "처리됨" 수치 사이의 차이는 거의 항상 큐잉 아티팩트입니다.

크거나 복잡한 PDF의 무음 타임아웃

100페이지가 넘는 PDF 또는 복잡한 임베디드 그래픽이 포함된 PDF는 추출 엔진의 문서당 처리 타임아웃을 초과할 수 있습니다. 파일이 실패했음을 알려주는 명시적 타임아웃 오류와 달리, 일부 시스템은 파일을 조용히 건너뛰고 다음 파일로 계속 진행하는 방식으로 처리합니다. 타임아웃 핸들러가 스레드를 정상적으로 종료했기 때문에 처리 작업 로그에는 파일이 "완료"로 기록되지만, 추출 결과는 생성되지 않습니다.

이 문제는 본질적으로 100개의 개별 JPEG 이미지를 하나의 파일로 묶은 스캔 PDF에서 특히 흔합니다. 각 페이지마다 전체 OCR 패스를 수행해야 하며, 누적 시간이 70번째 페이지에서 타임아웃 임계값을 초과할 수 있습니다. 이후 프로세서는 누적된 작업을 폐기하고 다음으로 넘어갑니다.

확인 방법: 문제가 있는 파일을 개별적으로 업로드하세요. 단독 업로드로는 성공적으로 처리되지만 배치 모드에서 건너뛰는 경우, 배치 큐 중 타임아웃이 원인입니다. 30페이지를 초과하는 다중 페이지 PDF는 배치 업로드 전에 더 작은 문서로 분할하는 것을 고려하세요.

혼합 파일 유형의 상이한 동작

모든 파일 유형이 동일한 속도로 처리되지는 않습니다. 단일 페이지 JPG 스크린샷과 50페이지 스캔 PDF를 혼합한 배치는 불균등한 처리 리듬을 만듭니다. 가벼운 JPG는 빠르게 완료되는 반면, 무거운 PDF는 불균형적으로 많은 처리 시간을 소비합니다. 배치 타임아웃이 모든 파일의 총 처리 시간을 기준으로 계산되는 경우, 느린 PDF로 인해 큐에서 나중에 도착한 JPG가 폐기될 수 있습니다. JPG는 단독으로는 정상적으로 처리되었을 텐데도 말입니다.

이는 특정 제품의 결함이 아니라 모든 배치 추출 도구에 영향을 미치는 시스템 수준의 문제입니다. 근본 원인은 처리 파이프라인이 일반적으로 파일을 이질적으로 배치하지만 타임아웃은 동질적으로 측정하기 때문입니다.

확인 방법: 업로드 전에 파일을 유형과 크기별로 그룹화하세요. 모든 작은 JPG 파일을 하나의 배치로 처리한 다음, 큰 PDF를 별도로 처리하세요. 이렇게 하면 느린 파일과 빠른 파일이 분리되어 타임아웃 로직의 교차 오염이 제거됩니다.

3단계: 처리되었지만 병합 과정에서 유실됨

가장 드물지만 가장 교묘한 실패 모드입니다. 30개 파일 모두 업로드에 성공했고, 30개 모두 AI가 처리했으며, 30개 모두 추출 결과를 반환했습니다. 하지만 최종 병합 출력물 — 다운로드한 단일 스프레드시트 — 에는 22개 행만 포함되어 있습니다. 나머지 8개는 개별 문서로 처리되었지만 통합 내보내기에 포함되지 않았습니다.

서로 다른 파일 구조로 인해 정렬이 어긋난 행 발생

문서 세트에 대해 배치 추출을 실행하면 도구의 배치 처리 엔진이 일관된 열 헤더를 가진 단일 테이블로 결과를 병합하려고 시도합니다. 이는 모든 파일이 동일한 유형일 때 완벽하게 작동합니다. 그러나 배치에 인보이스 25개와 대변 메모 5개가 포함된 경우, 대변 메모에는 "인보이스 번호" 대신 "대변 메모 번호"와 같은 다른 필드가 있을 수 있어 병합 알고리즘이 중복 열을 만들거나 — 일부 구현에서는 — 대다수 스키마와 일치하지 않는 구조의 행을 건너뛰게 됩니다.

엄밀한 의미에서 이는 데이터 손실이 아닙니다. 추출은 성공했기 때문입니다. 그러나 내보내기 로직은 이 8개 파일을 구조적 이상치로 간주하고 열 일관성을 유지하기 위해 통합 테이블에서 제외했습니다. 도구는 이를 알려주지 않았습니다. 도구의 관점에서는 가능한 가장 깔끔한 병합을 제공했기 때문입니다.

확인 방법: 원본 파일 간의 차이점을 찾아보세요. 하위 집합에 페이지 방향, 언어 또는 문서 유형이 근본적으로 다른 경우 해당 파일을 별도 배치로 처리하세요. "배치"의 정의가 중요합니다 — 워크플로는 폴더 편의가 아닌 구조적 유사성에 따라 파일을 그룹화해야 합니다.

이 문제는 유사하지만 동일하지 않은 문서(예: 병합된 셀이나 중첩 구조가 있는 문서에서 테이블 추출)를 배치 처리할 때 특히 흔하며, 문서별 행 수가 예측 불가능하게 달라질 수 있습니다.

업로드 전 체크리스트 — 배치당 30초

위에서 언급한 대부분의 오류 유형은 공통된 특징을 공유합니다. 바로 업로드 전에 소스 폴더를 빠르게 시각적으로 스캔하면 감지할 수 있다는 점입니다. 이 체크리스트를 "처리 준비 완료"와 "배치 시작" 사이의 관문으로 간주하십시오. 이후에 누락된 파일 8개를 문제 해결하는 것보다 시간이 훨씬 적게 걸립니다.

1. 파일 형식 감사 — 모든 파일이 JPG, PNG 또는 PDF인지 확인하십시오. TIFF, HEIC, BMP 또는 WebP 파일은 변환하십시오. 파일 탐색기에서 확장자별로 빠르게 정렬하면 이상한 파일을 즉시 찾을 수 있습니다.
2. 파일 크기 검사 — 30MB가 넘는 파일이 있는지 확인하십시오. 있으면 분할하거나 압축하십시오.
3. 파일명 정리 — 특수 문자 또는 비ASCII 문자(é, ü, å, 中)가 포함된 파일의 이름을 바꾸십시오. A-Z, 0-9, 하이픈, 밑줄만 사용하십시오.
4. 유형 동질성 확인 — 모든 파일이 동일한 문서 유형입니까? 송장과 대변 메모, 구매 주문서와 배송 영수증을 혼합하는 경우 전용 배치로 분리하십시오.
5. 대용량 파일 테스트 — 가장 큰 PDF를 개별적으로 업로드하여 올바르게 처리되는지 확인하십시오. 단독으로 시간 초과되면 배치에서도 반드시 실패합니다.
6. 배치 크기 적정성 — 파일이 30개를 초과하는 경우 10-15개씩 더 작은 배치로 분할하십시오. 더 작은 배치는 문제를 격리하고 종단 간 완료 속도를 높입니다.

에스컬레이션 시점 — 이 도구가 귀하의 파일에 적합한가요?

도구의 한계를 솔직하게 인정하면 반복되는 불만을 방지할 수 있습니다. 여러 배치에 걸쳐 지속적으로 파일이 손실되고 업로드 전 체크리스트로 원인을 찾을 수 없는 경우, 문서 세트에 대부분의 추출 도구 설계 가정을 벗어나는 특성이 있는지 고려하십시오.

배치 추출 도구(ImageToTable.ai 포함)는 일반적인 경우를 위해 제작되었습니다. 다음 용도로는 설계되지 않았습니다:

• 매우 큰 단일 문서 — 500페이지가 넘는 PDF는 배치 추출 대기열이 아닌 전용 문서 관리 파이프라인에 속합니다.
• 매우 이질적인 컬렉션 — 한 폴더에 15가지의 다른 문서 유형이 있으면 모든 병합 엔진이 한계에 도달합니다. 분리하십시오.
• 암호화 또는 권한 관리 PDF — 비밀번호로 보호된 파일은 거의 모든 추출 도구에서 건너뜁니다. 업로드 전에 보호를 제거하십시오.
• 픽셀 단위의 정확한 위치 지정이 필요한 문서 — 모든 필드의 정확한 X,Y 좌표를 알아야 하는 사용 사례의 경우 의미론적 추출 엔진보다 템플릿 기반 영역 OCR 도구가 더 적합할 수 있습니다.

파일이 이러한 범주 중 하나에 해당하는 경우, 해결책은 더 나은 문제 해결이 아니라 도구의 설계에 맞게 워크플로를 조정하는 것입니다. 이는 도구나 프로세스의 실패가 아닙니다. 특정 문서 특성에 추출 파이프라인에 대한 다른 접근 방식이 필요하다는 신호입니다.

자주 묻는 질문

파일이 실패할 때 내 추출 도구가 오류를 표시하지 않는 이유는 무엇인가요?

대부분의 추출 도구는 파일 단위가 아닌 배치 단위로 보고합니다. 업로드 중 파일이 처리 대기열에 등록되지 않고 실패하면, 도구에는 해당 파일이 처리 대상이었다는 기록이 없습니다. 사용자의 예상 개수와 도구의 개수 사이의 차이는 책임이 사용자에서 시스템으로 넘어가는 경계 지점에서 발생합니다. 파일별 상태 추적을 제공하는 도구는 예외적이며 일반적이지 않습니다. 파일별 상태를 추적하는 배치 OCR 실행은 그러한 예외 중 하나로, 모든 문서에 대해 대기 중, 처리 중, 완료 또는 실패를 표시합니다.

배치 처리 중 건너뛴 파일에서 데이터를 복구할 수 있나요?

네, 대부분의 경우 가능합니다. 업로드 또는 처리 중 실패한 파일은 일반적으로 로컬 컴퓨터에서 변경되지 않은 상태입니다. 업로드 전 체크리스트를 통해 해당 파일을 실행하고, 확인된 문제를 해결한 후 개별적으로 또는 더 작은 배치로 처리하십시오.

업로드 대화상자의 파일 순서가 건너뛰는 파일에 영향을 미치나요?

대부분의 시스템에서는 그렇지 않지만 그렇게 보일 수 있습니다. 30개의 파일을 업로드하고 처리 대기열이 수신된 순서대로 처리하는 경우, 대기열에서 나중에 배치되는 파일이 누적 시간 초과의 영향을 받을 가능성이 더 높습니다. 해결책은 파일 순서를 재배열하는 것이 아니라 배치 크기를 줄이는 것입니다.

업로드 전에 파일이 손상되었는지 어떻게 알 수 있나요?

기본 응용 프로그램에서 열어 보십시오 — PDF는 Adobe Acrobat, 이미지는 사진 뷰어에서. 경고 없이 열리면 손상되지 않았을 가능성이 높습니다. 배치 검증을 위해 pdfinfo(Linux) 또는 Adobe Acrobat의 "Preflight" 도구와 같은 도구로 여러 PDF의 구조적 무결성을 검사할 수 있습니다. 의심스러운 파일을 빠르게 다시 저장하면 잠재적 손상이 대개 해결됩니다.

단일 배치에 포함해야 하는 최대 파일 수는 얼마인가요?

대부분의 도구는 배치당 30-50개 파일을 지원하지만, 안정성은 10-15개에서 가장 높은 경우가 많습니다. 더 작은 배치는 완료 속도가 빠르고, 문제 파일을 격리하기 쉬우며, 동시성 제한과 누적 시간 초과의 영향을 줄입니다. 배치 크기는 기능 제한이 아니라 안정성과의 절충입니다.

추측하지 마세요 — 진단하세요

배치 추출에서 파일이 누락되는 경우, 어디를 봐야 하는지 알면 거의 미스터리가 아닙니다. 업로드 실패가 약 60%를 차지합니다 — 지원되지 않는 형식, 손상, 파일 이름 문제가 원인입니다. 처리 실패 — 동시성 저하, 시간 초과, 혼합 유형 충돌 — 는 또 다른 30%를 차지합니다. 가장 조용한 실패 모드인 병합 누락은 나머지 10%를 차지합니다. 각각 해결 방법이 있으며, 대부분의 해결 방법은 적용하는 데 1분 미만이 걸립니다.

지난 배치에서 잃어버린 8개 파일은 거의 확실히 여전히 컴퓨터에 있으며, 통과하지 못한 특정 게이트를 식별하면 바로 처리할 준비가 되어 있습니다. "배치 추출이 파일을 누락한다"와 "배치 추출이 안정적으로 작동한다"의 차이는 어떤 게이트가 실패했고 그 이유를 아는 것입니다.

다음 배치에서 체크리스트를 실행하세요. 여전히 30개 파일이 들어가겠지만, 30개 행이 나올 것입니다.