7,000페이지 PDF의 OCR:
하나의 거대한 파일이 잘못된 작업 단위인 이유

7,000페이지 파일의 실체

수천 페이지가 있는 파일을 백업 아카이브로 취급하면 접근 방식이 완전히 달라집니다. 문서에는 독자가 따라가는 구조, 즉 장, 절, 목차가 있습니다. 아카이브는 컨테이너이며, 아카이브에 물을 수 있는 유일한 유용한 질문은 특정 페이지나 필드가 어디에 있는지입니다. "1000+ pages pdf files with text and tabular data, but some idiot exported it as image"라는 글로 시작하는 r/DataHoarder 스레드는 바로 이런 종류의 객체를 설명하고 있습니다.

OCR을 실행하기 전에 2분 테스트를 먼저 해보세요. PDF를 열고 커서로 텍스트를 선택해 보십시오. 텍스트가 강조 표시되면 파일에 이미 텍스트 레이어가 있는 것이므로, 해당 텍스트에서 필요한 필드를 거의 완벽한 정확도로 바로 추출할 수 있습니다. 커서가 빈 상자를 그리고 아무것도 강조되지 않으면 페이지가 이미지이며 OCR이 정말로 필요합니다. 이 테스트는 서로 매우 다른 두 작업을 구분하며, 대부분의 가이드가 건너뛰는 단계입니다. 이미 텍스트 레이어가 있는 파일에 OCR을 실행하는 것은 필요 없는 작업에 하루를 소비하는 가장 흔한 방법입니다. 페이지가 실제로 이미지인 경우 어떻게 처리하는지는 AI가 스캔된 PDF에서 데이터를 추출하는 방법을 참조하세요.

거대한 단일 파일이 모든 단계에서 실패하는 이유

거대한 PDF의 실패는 구조적인 문제입니다. 더 나은 앱이 페이지 트리나 단일 페이지에 필요한 메모리를 바꾸지는 않습니다.

파일 내부에서 페이지는 읽는 순서대로 저장되지 않습니다. 페이지는 문서를 조립하기 위해 리더가 탐색하는 분기 구조인 페이지 트리에 매달려 있으며, 사용자가 탐색하는 사람이 읽을 수 있는 목차는 PDF 사양에서 책갈피라고 부르는 개요 트리입니다(ISO 32000-1:2008, 섹션 7.7.3 및 12.3.3). 7,000페이지 파일은 매우 큰 트리를 가지며, 전체 문서를 다루는 모든 작업은 이 트리를 탐색해야 합니다.

PDF 1.5에 추가된 두 가지 기능은 실제 사용 환경을 더 악화시킵니다. 페이지 사전, 주석, 책갈피와 같은 작은 객체는 압축된 객체 스트림에 패킹될 수 있고, 문서의 교차 참조 테이블은 교차 참조 스트림으로 대체될 수 있습니다. 둘 다 표준(ISO 32000-1, 섹션 7.5.7 및 7.5.8)의 정당한 부분이며, 둘 다 리더가 바이트 오프셋으로 객체 번호 5,000으로 점프할 수 없음을 의미합니다. 무엇이든 찾으려면 전체 블록을 압축 해제해야 합니다. 이것이 600MB 파일이 느리게 열리고, 느리게 검색되며, 도구가 파일 내부를 점프하려고 할 때 멈추는 이유입니다.

그 다음은 래스터화 단계입니다. 도구가 한 페이지를 이미지로 렌더링하여 읽을 수 있게 만드는 단계입니다. 페이지당 메모리 비용은 과소평가하기 쉽습니다. 300 DPI로 렌더링된 A4 페이지는 약 2,480 x 3,508픽셀, 즉 원시 색상 약 26MB를 차지합니다. 600 DPI에서는 단일 페이지에 대해 약 104MB까지 올라갑니다. 여러 페이지를 동시에 처리하거나 문서 전체의 단일 모델을 구축하려는 데스크톱 애플리케이션은 로직이 아니라 메모리 부족으로 실패합니다.

인식이 시작되기 전에 600 DPI의 한 페이지가 약 104MB의 메모리를 차지할 수 있습니다. 이 숫자가 거대한 파일이 데스크톱 작업인지 파이프라인 작업인지를 결정합니다.

Acrobat 지원 포럼은 이 문제가 어디서 끝나는지 가장 명확하게 보여주는 공개 기록입니다. 한 사용자는 "약 1,500페이지를 넘어가면 충돌한다"고 보고합니다. 또 다른 사용자는 "매년 10,000페이지가 넘는 PDF 몇 개를 OCR해야 한다"며 Acrobat이 "파일을 OCR하려고 할 때도, 분할하려고 할 때도 충돌한다"고 말합니다. 세 번째 사용자는 24,595페이지 문서에 대해 질문합니다. 커뮤니티 전문가는 이렇게 요약합니다: "Acrobat은 낮은 볼륨의 OCR을 위한 도구입니다" (Adobe 커뮤니티 스레드). 이 앱은 설계된 대로 작동하며, 600MB 단일 파일 작업을 위해 설계된 적이 없습니다. 동일한 한계는 Acrobat의 OCR이 비전 모델과 어떻게 비교되는지에서도 그 크기를 넘어선 문서에서 나타납니다.

7,000페이지 처리량 계산

7,000페이지에서 유용한 질문은 작업에 몇 시간과 몇 달러가 소요될지입니다.

Tesseract는 기준 CPU 성능입니다. 깨끗한 인쇄 텍스트에서 최신 CPU 기준 분당 약 25페이지를 처리하며, 독립적인 벤치마크는 PaddleOCR(RTX 3090에서 분당 약 120페이지) 및 EasyOCR(CPU에서 분당 약 8페이지)과 같은 더 무거운 엔진과 비교해 그 수준에 있다고 평가합니다. 7,000페이지를 단일 스레드 Tesseract에 입력하면 약 280분, 즉 5시간 미만이 소요됩니다. EasyOCR의 CPU 경로에서는 같은 작업이 14시간 이상으로 늘어납니다.

이러한 수치를 바꾸는 지렛대는 병렬 처리입니다. OCRmyPDF는 작업 수를 받는 명령줄 도구로 Tesseract 엔진을 감싸므로, 8코어는 5시간 실행을 40분에 가깝게 줄일 수 있습니다. 이전 섹션의 주의 사항은 여전히 적용됩니다: 작업자가 많을수록 페이지당 상주 메모리도 많아지므로, 메모리가 적은 머신은 많은 페이지를 병렬로 처리하는 것보다 적은 수의 페이지를 더 빨리 완료합니다.

클라우드 OCR은 제어를 병렬 처리로 맞바꾸고 페이지당 비용을 청구합니다. Google Document AI와 AWS Textract는 모두 페이지 1,000장당 약 1달러 수준이며, 재시도 전에 7,000페이지 문서는 10달러 미만입니다. 더 높은 품질이나 더 구조화된 서비스는 더 비싸며, Reducto의 공개 요금은 1,000페이지당 10달러입니다. 예산이 여기서 제약이 되는 경우는 거의 없습니다. 제약은 7,000페이지 전체를 OCR할 필요가 거의 없고, 하나의 거대한 파일을 둘러싼 도구가 작업을 고통스럽게 만든다는 점입니다.

실용적인 절차는 투자 전에 샘플링하는 것입니다. 아카이브의 범위를 대표하는 5~10페이지(깨끗한 페이지, 희미한 페이지, 밀집된 표, 다른 양식 레이아웃의 페이지)를 뽑아 후보 경로로 실행하고 실제 분당 페이지 수와 실제 오류율을 측정하세요. 직접 측정한 샘플에서 외삽하는 것이 위의 수치를 포함한 어떤 벤치마크 표를 신뢰하는 것보다 낫습니다.

구조에 따라 분할, 수작업이 아닌

대용량 PDF에 대한 해답은 이미 보유한 도구에 맞는 단위로, 문서가 이미 선언한 경계를 따라 자르는 것입니다.

가장 좋은 경계는 개요 트리입니다. PDF에 책갈피가 있으면 그것이 곧 목차이며, 각 최상위 책갈피는 자연스러운 단위(장, 명세서 기간, 서류)를 나타냅니다. 이러한 경계를 기준으로 분할하면 관련 페이지가 함께 유지되어 이후 추출 정확도에 중요하며, 각 결과 파일에 나중에 이해할 수 있는 이름을 부여할 수 있습니다.

로컬에서 실행할 작업과 서비스에 보낼 작업

합리적인 분담은 로컬 머신이 절단과 인덱싱을 맡고, 서비스가 실제로 판독이 필요한 페이지를 맡는 것입니다.

qpdf나 pdftk를 이용한 분할은 빠르고, 파일을 업로드하지 않고 직접 처리하며, 비용이 들지 않습니다. Tesseract나 OCRmyPDF를 이용한 OCR도 로컬에서 실행할 수 있는데, 익숙하지 않은 웹 업로더에 넘기기 꺼려지는 기록이 보관소에 있을 때 중요합니다. 단점은 처리량입니다. 머신 한 대, CPU 풀 하나, 그리고 처리 중인 페이지당 실질적인 메모리 비용이 발생합니다. 데스크톱 도구는 단일 문서의 추출 단계에서 여전히 올바른 선택이 될 수 있으며, 해당 범주의 장점과 한계는 데스크톱 OCR 소프트웨어 비교에서 다룹니다.

클라우드 OCR 서비스는 하드웨어 제한을 없애고 페이지당 비용을 청구합니다. 또한 600 MB 파일이 즉시 도달하는 업로드 상한이 있어, 서비스는 파일이 분할된 후에야 유용해집니다. 브라우저 기반 분할 도구는 수십 MB로 상한이 정해지는 경향이 있어 원본 파일 자체에는 적합하지 않습니다.

보관소와 절단은 로컬에 유지하세요. 정의된 하위 집합만 판독하는 서비스에 보내세요. 600 MB를 한 번에 업로드하는 것은 제품으로 존재하지 않으며, 워크플로우에도 필요하지 않습니다.

분할 후 추출이 들어가는 위치

거대한 파일이 청크로 분할되면, 남은 작업은 수천 페이지에서 몇 개의 명명된 필드를 추출하여 하나의 스프레드시트로 만드는 것입니다.

이것이 추출이 OCR과 다른 점입니다. OCR은 페이지 이미지를 텍스트 덩어리로 변환합니다. 추출은 더 좁은 질문에 답합니다. 이 페이지의 문서 날짜, 사건 번호, 계좌 번호, 금액은 무엇인가? 비전 기반 추출 도구는 이후에 파싱해야 할 텍스트를 생성하는 대신 그 질문에 직접 답하며, 그 차이는 정확도가 입력에 따라 달라지는 이유에서 다룬 것과 같습니다.

맞춤 열 추출은 원하는 것에서 시작합니다. 문서 날짜, 사건 번호, 계좌 번호 같은 열 이름을 입력하면 도구가 모든 페이지와 레이아웃에서 의미별로 각 값을 찾습니다. 400페이지와 4,000페이지 사이에서 디자인이 바뀌는 양식도 새 템플릿이 필요 없습니다. 문서 유형별로 훈련되거나 구성되는 것이 없기 때문입니다. 출력을 정의하는 것은 사용자이며, 보관소는 아무것도 정의하지 않습니다.

일괄 우선 처리는 볼륨을 처리합니다. 한 번에 하나씩 업로드하는 대신 전체 청크를 파일 세트로 업로드하면 결과가 페이지당 한 행씩 단일 스프레드시트로 병합됩니다. 스캔 문서 배치의 경우 이는 폴더에 대해 배치 OCR 실행의 배후에 있는 것과 같은 아이디어로, 폴더 규모에서 보관소 규모로 확장된 것입니다.

파이프라인은 분할, 배치, 추출 순서가 됩니다. 보관소를 구조별로 챕터 크기 또는 페이지 수 기준 청크로 분할하고, 배치당 하나의 청크를 업로드한 다음, 모든 청크에서 동일한 명명된 열을 추출합니다. 출력은 더 이상 7,000페이지 문서가 아닙니다. 날짜별로 정렬하고, 사건 번호로 필터링하고, 비어서 돌아온 페이지를 스캔할 수 있는 테이블입니다. 마지막 부분은 기능입니다. 빈 셀은 페이지에 읽을 내용이 없었음을 알려주며, 수천 행에 걸쳐 인덱스의 정확성을 유지합니다.

계획 시 고려해야 할 한도

어떤 제품도 600MB, 7,000페이지짜리 PDF를 한 번의 호출로 처리하지 않으며, 그러한 처리를 가정하는 계획은 첫날부터 막히게 됩니다. 중요한 한도는 공개되어 있으므로 시작 전에 확인할 가치가 있습니다:

따라서 7,000페이지 작업은 최소 7,000개 파일이 필요합니다. Max 플랜에서는 300개씩 약 24배치에 해당하며, Standard 티어에서는 7,000크레딧이 필요합니다. 두 숫자 모두 시작 전에 플랜을 확인해야 하는 이유이며, 작업을 완료할 수 없는 이유는 아닙니다.

길이는 정밀도에도 영향을 미칩니다. 전사 오류는 양이 많아질수록 누적되므로, 120페이지 작업 중 87페이지의 오류가 상호 참조되는 필드를 통해 전파될 수 있습니다. 그래서 대부분의 도구가 100페이지 지점에서 논리적 섹션으로 분할을 권장하기 시작하며, 이에 대한 자세한 내용은 다중 페이지 PDF 추출에서 기대할 수 있는 것에서 다룹니다. 7,000페이지에서는 분할의 필요성이 운영상의 이유로 대두되며 동시에 정확성과도 관련됩니다.

가장 많은 시간을 절약해 주는 규칙이 하나 더 있습니다: 이미 텍스트 레이어가 있는 콘텐츠는 OCR을 수행하지 마십시오. 일부 페이지 샘플에서 텍스트 선택 테스트가 성공하면 텍스트를 직접 추출하고 인식 단계를 완전히 건너뛰십시오.

FAQ

7,000페이지 PDF를 한 번에 OCR할 수 있나요?

아니요. 600MB 단일 업로드는 파일당 10MB 제한과 서버 측 50페이지 상한을 초과하며, 데스크톱 도구는 그 이전에 메모리가 부족해집니다. 먼저 파일을 분할한 다음 청크를 처리하세요.

책갈피를 기준으로 대용량 PDF를 수작업 없이 분할하려면 어떻게 해야 하나요?

Acrobat은 최상위 책갈피 기준으로 분할할 수 있으며, Apryse PDF PageMaster, EverMap AutoSplit, DeftPDF 같은 도구는 더 깊은 책갈피 수준을 지원합니다. 일반적인 명령줄 분할 도구인 qpdf는 책갈피 기준 분할이 불가능하며, 페이지 범위나 고정 페이지 수로 분할합니다.

600MB 파일에서 PDF 리더가 충돌하는 이유는 무엇인가요?

단일 페이지를 600 DPI로 렌더링하는 데 약 104MB의 메모리가 필요하며, 여러 페이지를 보유하거나 문서 모델 하나를 구축하는 리더는 데스크톱 앱의 용량을 초과하게 됩니다. 압축된 객체 스트림과 빠른 웹 보기 레이아웃의 부재도 속도 저하에 영향을 줍니다.

수천 페이지의 OCR에는 얼마나 걸리나요?

Tesseract를 사용하는 CPU에서 분당 약 25페이지 기준으로, 7,000페이지는 단일 스레드로 약 4.7시간, 8개 병렬 워커로는 약 40분이 소요됩니다. 클라우드 서비스는 여러 머신에서 실행되며 대신 페이지당 요금을 부과합니다.

필요한 필드가 몇 개뿐인데 모든 페이지를 OCR해야 하나요?

아니요. 원하는 필드를 지정하고 해당 필드가 포함된 페이지에 대해 실행하세요. 날짜, 사건 번호, 금액의 인덱스가 일반적으로 실제 산출물이지, 아카이브 전체를 완전히 텍스트화하는 것이 아닙니다.

수천 페이지를 OCR하는 가장 저렴한 방법은 무엇인가요?

로컬 Tesseract는 사실상 무료이며 CPU 성능에 따라 결정됩니다. 주요 클라우드 OCR API는 1,000페이지당 약 1달러 수준이므로, 7,000페이지 작업은 10달러 미만에서 시작합니다. 더 큰 절감은 이미 텍스트 레이어가 있거나 필요하지 않은 페이지에서는 OCR을 전혀 실행하지 않는 것입니다.

파일의 크기는 그 안에 담긴 작업에 대한 진술입니다. 7,000페이지는 OCR 문제라기보다 훨씬 먼저 검색 문제이며, 구축할 가치가 있는 산출물은 처음부터 끝까지 읽지 않을 아카이브의 충실한 사본이 아니라 필요한 페이지의 인덱스입니다. 이미 나뉘어 있는 지점에서 파일을 자르고, 관심 있는 필드를 지정하고, 배치가 나머지를 처리하도록 하세요.

거대 PDF에서 필요한 필드 추출하기