일괄 추출에서 파일의 절반이
누락된 이유: 일반적인 실패 유형

1단계: 업로드조차 되지 않은 파일

파일 누락의 가장 흔한 원인이면서, 업로드 진행 표시줄이 정상적으로 움직이기 때문에 간과하기 쉬운 경우입니다. 문제 파일이 큐에 들어가기 전에 카운트가 멈춥니다. 이 도구는 해당 파일을 '업로드됨'이 아닌 '시도됨'으로 기록하며, 파일별 오류 로그가 없으면 이 간극은 조용히 지나갑니다.

지원되지 않는 파일 형식

모든 이미지와 문서 형식이 동일하게 처리되지는 않습니다. ImageToTable.ai를 포함한 대부분의 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나 4800만 화소로 촬영한 고해상도 인보이스 사진은 이 제한을 초과할 수 있습니다. 도구가 항상 업로드를 명시적으로 거부하지는 않습니다. 파일 메타데이터는 수락하지만, 크기 임계값을 초과했다고 감지하면 실제 콘텐츠는 건너뛸 수 있습니다.

확인 방법: 업로드 전에 파일을 검토하세요. 단일 파일이 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개를 처리한 후 다음 4개를 처리하는 식입니다.

문제는 대기열에 하드 한도가 있을 때 발생합니다. 일부 시스템은 대기열 깊이를 초과하는 파일을 자동으로 삭제합니다. 플랜에서 배치당 50개 파일을 허용하지만 동시 슬롯이 4개뿐이고, 처음 4개 파일 중 하나에서 지속적인 오류가 발생하면(예: 손상된 PDF로 인해 리더가 중단됨) 전체 웨이브가 지연되어 대기열의 나머지 파일이 시간 초과되어 폐기될 수 있습니다. UI에는 여전히 "50개 업로드됨, 46개 처리됨"이라고 표시되지만, 누락된 4개는 실제로 시도되지 않은 것입니다.

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

크거나 복잡한 PDF의 자동 시간 초과

100페이지 이상이거나 복잡한 임베디드 그래픽이 포함된 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개는 개별 문서로 처리되었지만 통합 내보내기에는 병합되지 않았습니다.

서로 다른 파일 구조로 인한 정렬 불일치 행

문서 집합에 대해 배치 추출을 실행하면 도구의 배치 처리 엔진이 결과를 일관된 열 헤더가 있는 단일 테이블로 병합하려고 시도합니다. 이는 모든 파일이 동일한 유형(예: 30개의 인보이스)일 때는 완벽하게 작동합니다. 하지만 배치에 인보이스 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 도구가 더 적합할 수 있습니다.

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

자주 묻는 질문

파일 추출에 실패해도 오류가 표시되지 않는 이유는 무엇인가요?

대부분의 추출 도구는 개별 파일 수준이 아닌 배치 수준("파일 30개 업로드됨")으로 보고합니다. 처리 대기열에 등록되지 않고 업로드 중에 파일이 실패하면 도구는 해당 파일이 처리 대상이었다는 기록을 갖지 않습니다. 사용자의 예상 개수와 도구의 개수 차이는 책임이 사용자에서 시스템으로 넘어가는 경계에서 발생합니다. 개별 파일 상태 추적을 제공하는 도구는 예외이며 일반적이지 않습니다.

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

네, 대부분의 경우 가능합니다. 업로드나 처리 중 실패한 파일은 일반적으로 로컬 컴퓨터에서 그대로 유지됩니다. 업로드 전 체크리스트를 적용하고, 확인된 문제(형식 변환, 이름 변경, 분할)를 해결한 후 개별적으로 또는 더 작은 배치로 처리하세요.

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

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

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

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

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

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

추측하지 말고 진단하세요

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

마지막 배치에서 잃어버린 8개의 파일은 거의 확실히 기기에 그대로 남아 있으며, 통과하지 못한 특정 관문을 식별하기만 하면 처리할 준비가 되어 있습니다. "일괄 추출이 파일을 누락한다"와 "일괄 추출이 안정적으로 작동한다"의 차이는 어떤 관문이 왜 실패했는지를 아는 데 있습니다.

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