10만 개 PDF OCR 필요 여부 일괄 검출: 자동화 파이프라인 완전 가이드

한 줄 요약: 기업 아카이브, 로펌, 금융기관에는 수만~수십만 개의 PDF가 있으며, Word에서보낸 '진짜 텍스트'와 2005년 스캐너로 만든 '가짜 PDF'(전체 페이지 이미지, 복사 불가)가 섞여 있습니다. 10만 개 파일에 전량 OCR을 돌리면 비용이 낭비되고 이미 검색 가능한 문서까지 재처리합니다. 올바른 접근: 먼저 배치로 OCR이 실제로 필요한 PDF를 검출한 뒤 유형별로 로컬 또는 클라우드 인식 엔진으로 라우팅.

'OCR 필요'의 정의

엔지니어링 맥락에서 'OCR 필요' ≠ '파일에 이미지가 있다':

핵심: 검출 단계의 목표는 내용 인식이 아니라 10만 개 파일을 '건너뛰기 / 부분 처리 / 전량 OCR' 3개 버킷으로 저비용 분류하는 것. 유료 API나 무거운 OCR 엔진 전에 반드시 실행.

3계층 검출 파이프라인

L1: 텍스트 레이어 고속 탐지 (< 50ms/파일)

PyMuPDF 또는 pdftotext로 인쇄 가능 문자 수 집계. avg_chars >= 80 → SKIP; avg_chars < 20 → OCR_REQUIRED; 중간 → L2.

L2: 페이지 이미지 면적 비율

L1 회색 영역에서 이미지 면적 / 페이지 면적 계산. 이미지 비율 > 85% + L1 문자 적음 → OCR_REQUIRED; 이미지 비율 < 30% → SKIP; 나머지 → L3.

L3: 렌더링 샘플 + 경량 OCR

불확실 파일은 1·중간·마지막 페이지 3장만 렌더링, macOS Vision 또는 Tesseract로 확인. L3는 회색 영역의 약 5–8%만 처리.

10만 개 병렬 아키텍처

매니페스트 기반 + 메시지 큐로 수평 확장: S3/MinIO → manifest.jsonl → Redis/RabbitMQ → N × Worker → SQLite/Parquet.

처리량 (Cloud Mac mini M4, 24GB):

검출 결과 3단계 라우팅

SHA-256 중복 제거 필수. 검출 결과 90일 캐시로 연산 20–40% 절약.

도구 선택

순수 PDF: PyMuPDF + pdftotext 이중 검증. 혼합 문서: Apache Tika(JVM 오버헤드 주의).

흔한 함정

1. 암호화 PDF → qpdf --decrypt로 복호화 사본 검출
2. CID 폰트 깨짐 → L3에서 Unicode 인쇄 가능 비율 확인
3. 이중 레이어 PDF → pdffonts로 기존 OCR 레이어 감지
4. 손상 파일 → CORRUPT 버킷 분리
5. NAS 랜덤 I/O → 로컬 NVMe에 rsync 후 실행

Cloud Mac을 쓰는 이유

• tmux 24/7 상시, 노트북 덮개 닫으면 큐 중단
• Apple Silicon 통합 메모리로 PyMuPDF가 x86 VPS 대비 20–40% 빠름
• 검출 → OCR 동일 노드 일괄 처리, 10만 개 전송 대역폭 절약
• 법무·금융 데이터 거주 요건: 검출과 로컬 OCR을 렌탈 노드 내 완결

7단계 구현 체크리스트

1. 객체 스토어에서 manifest.jsonl보내기
2. Cloud Mac에 poppler, qpdf, PyMuPDF 설치
3. L1 전량 검출 → Parquet 출력
4. PARTIAL 버킷 200건 수동 spot-check, 임계값 조정
5. OCR_REQUIRED → ocrmypdf 큐; PARTIAL → 페이지별 OCR
6. 사이드카 JSON을 RAG/ES 인덱싱용으로 기록
7. 일일 증분 검출, 전량 재스캔 금지

결론: 10만 PDF OCR 비용의 절반 이상은 애초에 OCR이 필요 없는 파일에 쓰입니다. 3계층 검출 파이프라인으로 버킷을 먼저 나누고, 로컬 Vision vs 클라우드 Document AI를 결정하세요 — 2026년 문서 디지털화의 정석입니다.