2026 AI PDF OCR 도구 순위: pdf-inspector, MinerU, Marker 중 무엇이 최선일까?

RAG, 계약 검토, 논문 지식베이스를 만들 때 팀은 자주 「MinerU와 Marker 중 누가 더 강한가?」를 묻습니다. 그러나 파이프라인을 실제로 느리게 만드는 것은 텍스트 레이어가 있는 PDF까지 GPU OCR에 넣는 습관입니다——배치가 초 단위에서 분 단위로 늘어나고 Agent는 문서 준비를 기다립니다. Firecrawl 오픈소스 pdf-inspector가 말하는 해법은 분명합니다. 먼저 분류하고, 추출하고, 글자가 빠진 페이지만 OCR합니다.

본문은 PDF를 벡터 DB나 Agent에 넣으려는 iOS / Flutter / 백엔드 개발자, 그리고 로컬 파싱용 Cloud Mac 노드를 검토하는 팀을 대상으로 합니다. 최종 업데이트 2026년 8월 6일. 도구 버전과 라이선스는 각 프로젝트 GitHub를 기준으로 하세요.

왜 「전부 OCR」이 문서 파이프라인을 망가뜨리는가

기업 PDF 코퍼스에는 보고서, 논문, 송장, 투자설명서처럼 추출 가능한 텍스트 레이어를 가진 파일이 많습니다. 페이지마다 비전 모델로 인식할 필요가 없습니다. 전통적으로 MinerU / Marker / 클라우드 OCR API를 일괄 호출하면 세 가지 숨은 비용이 생깁니다.

1. 지연 비용——순수 텍스트 PDF는 수백 ms에 Markdown이 나올 수 있는데 GPU 대기열에 걸립니다.
2. 구조 비용——OCR이 읽기 순서를 깨뜨리면 표와 각주 후처리가 더 어려워집니다.
3. 라이선스 비용——Marker 등은 모델 가중치에 상업 조항이 있어, 전량 OCR은 컴플라이언스 면적을 넓힙니다.

2026년 합리적인 프레임은 진입 분류 → 로컬 텍스트 추출 → 페이지 단위 OCR 폴백입니다. pdf-inspector는 opendataloader-bench 200건 PDF에서 OCR 없이 전체 점수 약 0.875, 라이브러리 전체 처리 약 2.8초——수 분 걸리는 ML 파이프라인과 대조됩니다.

AI PDF 도구 분류(세 가지 진입점)

세 도구를 같은 순위표의 1·2·3위로 보지 마세요. 파이프라인의 서로 다른 층을 담당합니다.

유형	대표	핵심 동작	전형적 지연
A. 라우팅 / 텍스트 레이어 추출	pdf-inspector	TextBased / Scanned / Mixed 판별, 네이티브 텍스트 → Markdown	분류 ~20ms + 추출 ~150ms/건
B. 고정밀 OCR 파이프라인	MinerU	레이아웃 분석, 표 HTML, 수식 LaTeX, 84개 언어 OCR	초~분/건(GPU 의존)
C. 고처리량 OCR 파이프라인	Marker	Surya 스택, 다형식 입력, 선택적 LLM 후처리	배치 시 페이지/초급(GPU)

비대칭 결론: 진짜 분수령은 모델 파라미터 수가 아니라 파이프라인 진입에서 「텍스트 레이어 vs 스캔본」 분류를 제대로 했는지입니다. 이 층이 없으면 아무리 강한 OCR도 OCR이 필요 없는 문서에 돈을 쓰는 셈입니다.

핵심 비교: pdf-inspector vs MinerU vs Marker

아래 표는 기술 선정 문서에 그대로 넣을 수 있는 통일 축입니다. 실행 능력은 배치·파이프라인 임베딩과 출력 제어, 컨텍스트는 레이아웃·표·수식·다국어 보존도를 뜻합니다.

도구	진입점	실행 능력	컨텍스트	적합 대상
pdf-inspector	Node / Python / Rust CLI; Agent 전단에 임베드	ML 불필요; pages_needing_ocr 페이지 라우팅; MIT	네이티브 텍스트 Markdown, 이중 모드 표, 다단 읽기 순서; 스캔 OCR 미지원	하이브리드 파이프라인 백엔드; Firestore / S3 대량 PDF 전처리
MinerU	CLI / Docker / API; CPU·VLM 듀얼 백엔드	OmniDocBench급 정확도; VLM 경로 ≥8GB VRAM; 커스텀 OSS 라이선스	표·수식·CJK 강점; 머리글/바닥글 제거; JSON + MD 출력	학술 논문 DB, 재무 보고, 중국어·한국어 다단 편집, 연구 RAG
Marker	CLI / GUI / API; PDF 외 Office 형식	배치 처리량 높음; 선택 LLM 후처리; GPL 코드 + 가중치 라이선스 제한	90+ 언어 OCR; 이미지 추출 강점; 복잡한 표는 가끔 약함	영어 서적 대량 MD화, 다형식 아카이브, 라이선스 검토 가능한 팀

비용과 연산(두 번째 비교 축)

도구	하드웨어	디스크 / 모델	라이선스 요점
pdf-inspector	CPU만으로 충분; Apple Silicon 친화	모델 다운로드 없음	MIT, 클로즈드 소스 임베드 가능
MinerU	고정밀은 NVIDIA GPU 권장; CPU pipeline으로 강등 가능	최초 실행 시 수십 GB급 의존성	커스텀 조항, 상업 전 확인 필요
Marker	CPU / CUDA / MPS(Mac)	Surya 가중치 다운로드 필요	GPL + RAIL-M, 고수익 법인은 별도 검토

시나리오별 선택: 의사결정 매트릭스

당신이…	우선 볼 것	추천 도구	비고
전자판 리포트 / 계약 중심 코퍼스	지연·비용	pdf-inspector 중심	Mixed 페이지만 OCR
스캔 논문 / 오래된 학술지	OCR·수식	MinerU VLM 경로	GPU 또는 원격 Mac 확보
영어 서적 대량 디지털화	처리량	Marker 배치	라이선스 선검토
Agent가 사용자 PDF 실시간 읽기	P95 지연	pdf-inspector → 조건부 OCR	모델 콜드 스타트 회피
모바일 앱 오프라인 파싱	번들 크기·전력	pdf-inspector 층만 현실적	스캔은 클라우드 OCR
데이터 국외 반출 불가 컴플라이언스	셀프호스트	셋 다 로컬 가능; 기본 클라우드 OCR 지양	도움말 센터 격리 배포 참고

추천 조합(스택 중첩 가능)

조합 A — 저비용 RAG 진입(기본 추천)

• pdf-inspector 분류 + 텍스트 레이어 Markdown
• pages_needing_ocr → MinerU CPU 또는 클라우드 API
• 벡터 DB 통일 청크 전략(제목 + 페이지 메타데이터)
• 적합: 기업 지식베이스, 고객 지원 문서, 스캔 혼합 코퍼스

조합 B — 학술 / 아시아어 금융 고정밀

• MinerU 전량(VLM 백엔드)으로 MD + JSON
• 품질: 레이아웃 시각화로 5% 샘플 스팟 체크
• 연산: 로컬 M4 24GB 시험; 피크 배치는 Cloud Mac M4 노드

조합 C — 대량 영어 아카이브 + CI 자동화

• Marker 야간 배치 → 객체 스토리지
• CI에서 pdf-inspector로 신규 업로드 「OCR 필요 여부」 게이트
• 오케스트레이션은 OpenClaw 클라우드 자동화로 파싱 job과 빌드 노드 분리

Cloud Mac / Apple Silicon과의 연관

MinerU와 Marker는 macOS에서 MPS 통합 메모리를 쓸 수 있지만, 24GB 메모리 M4 노드는 「야간 배치 + 주간 원격 개발」 분업에 적합합니다. 파싱 job이 노드를 점유해 Xcode 빌드와 swap을 두지 않습니다. pdf-inspector는 매우 가벼워 CI Runner나 GitHub Actions 자체 호스트 Mac 업로드 게이트에 올릴 수 있습니다——먼저 판별한 뒤 무거운 OCR을 켤지 결정합니다.

상시 GPU 서버가 없는 팀은 Marker / MinerU 배치를 Cloud Mac 월 임대로 돌리는 편이 OCR 전용 GPU 구매보다 운영 부담이 적은 경우가 많습니다. 라우팅 층은 앱 쪽이나 경량 컨테이너에 두는 것이 정석입니다.

흔한 오해

1. 벤치마크 총점으로 업무 수용 대체——당신 PDF는 한·중 다단 표 주석일 수 있고, 영어 논문집과 분포가 다릅니다.
2. 「가짜 텍스트 레이어」 무시——GID 인코딩·깨진 글자 레이어는 pdf-inspector가 needsOcr로 표시합니다. 억지 추출 말고 OCR로.
3. MinerU / Marker 이분법 고집——혼합 코퍼스는 「라우팅 + 페이지별 듀얼 엔진」이 현실적입니다.
4. 페이지 단위 메타데이터 미부착——벡터 검색에서 「몇 페이지 표인지」 인용 못 하면 환각 수정이 어렵습니다.
5. 라이선스를 마지막에 확인——Marker GPL·가중치 조항이 SaaS 배포 경로를 막을 수 있습니다.

실행 단계(7단계 Action Plan)

1. 실제 PDF 30–50건 샘플링 후 pdf-inspector로 TextBased / Scanned / Mixed 비율 집계.
2. 수용 지표 정의——읽기 순서, 표 구조, 수식 LaTeX 렌더 성공률에 합격선 설정.
3. 라우팅 레이어 구현——고신뢰 TextBased는 로컬 추출; pages_needing_ocr 목록 출력.
4. OCR 구간 엔진 선택——아시아어 복잡 레이아웃은 MinerU; 영어 대량은 Marker; 모델 버전 기록.
5. 연산 배치——가벼운 라우팅은 CI; GPU 배치는 Cloud Mac 또는 전용 기. Mac mini 대여 참고.
6. 1주일 프로덕션 트래픽——P95 지연, 실패 페이지, 수동 수정 비율 기록 후 임계값 조정.
7. 운영 매뉴얼화——라이선스 경계, 롤백 버전을 도움말 센터 키·데이터 보존 정책과 맞춤.

FAQ

pdf-inspector는 OCR 도구인가요?

전통적 OCR은 아닙니다. 분류 후 네이티브 텍스트를 추출하고, OCR 필요로 표시된 페이지만 MinerU, Marker, 클라우드 API로 보냅니다.

MinerU와 Marker, 표는 어느 쪽이 더 정확한가요?

복잡한 학술 표와 아시아어 다단 편집은 MinerU가 더 안정적인 편입니다. Marker는 영어 대량·이미지 추출에 유리——상업 전 라이선스 확인.

NVIDIA GPU 없이 MinerU를 돌릴 수 있나요?

CPU pipeline으로 가능합니다. 고정밀 VLM은 ≥8GB VRAM 권장. Apple Silicon에서는 Marker를 MPS로 시험하거나 배치를 원격 Mac으로.

RAG는 어디서 시작해야 하나요?

기본은 pdf-inspector 라우팅 → 스캔 페이지만 OCR. 평균 비용과 지연을 크게 줄입니다.

세 도구를 연결할 수 있나요?

가능합니다. 2026년 주류 패턴: inspector 분류 → 텍스트 레이어 로컬 MD → 빠진 페이지 MinerU/Marker → 통일 스키마로 DB 적재.

요약

「pdf-inspector, MinerU, Marker 중 누가 최고?」에 단일 우승자는 없습니다. pdf-inspector는 진입·비용, MinerU는 복잡 구조·CJK, Marker는 영어 대량 처리량에서 이깁니다. 먼저 「OCR 없이 몇 페이지를 처리할 수 있는가」에 답한 뒤 엔진을 고르는 편이 순위 점수를 쫓는 것보다 연산도 안정적입니다.

배포 전 한 가지만 자문하세요: OCR을 끄면 여전히 쓸 만한 Markdown이 나오는 문서 비율은? 그 비율을 아키텍처 리뷰 첫 페이지에 적어 두세요.

더 읽기

• 제미나이 4 vs GPT-5.6: 2026년 개발자 선택법 →
• OpenClaw + Cloud Mac: 자동화 체인 →