오픈소스 RAG 문서 파서 5종 비교 (2026) — 폐쇄망·온프레미스 환경 실전 가이드

 

핵심 요약

2026년 현재 폐쇄망·온프레미스 환경에서 RAG 문서 전처리를 위한 오픈소스 파서는 사실상 다섯 가지로 압축됩니다. Docling·MinerU·Marker·Unstructured·PyMuPDF4LLM 각각의 강약점과 V100 GPU 환경 호환성, 그리고 실무에서 자주 채택되는 하이브리드 조합 패턴까지 정리했습니다.

왜 지금 RAG 파서를 따로 이야기해야 하는가

RAG(Retrieval Augmented Generation) 시스템을 구축할 때 가장 과소평가되는 단계가 바로 문서 파싱과 전처리입니다. 임베딩 모델이 아무리 좋아도, 표가 깨지고 페이지 헤더가 본문에 섞이고 다단 레이아웃이 한 줄로 뭉개진 텍스트가 입력되면 검색 품질은 회복이 어렵습니다. 결국 답변 품질의 천장은 파서 단계에서 결정된다고 봐도 과언이 아니에요.

특히 IT 직무에 일하는 사람 입장에서 사내 인프라가 폐쇄망(에어갭) 환경이면 선택지가 급격히 좁아집니다. LlamaParse, Mistral OCR API, Reducto, Firecrawl처럼 클라우드 API에 의존하는 도구는 처음부터 제외해야 하니까요. 이번 글에서는 완전 로컬 실행이 가능한 오픈소스 파서 5종을 실무 관점에서 비교해보겠습니다.

선정 기준 — 폐쇄망 RAG에서 정말 중요한 다섯 가지

💡 평가 기준

• 로컬 실행 가능 여부: 에어갭 환경에서 외부 호출 없이 동작
• CJK(한·중·일) 지원: 한글 PDF 레이아웃·폰트 처리
• 표 구조 보존: 병합 셀, 다중 헤더, 중첩 표 인식
• GPU 가속: 대량 문서 처리 시 V100·L40S 활용 가능
• RAG 친화 출력: Markdown/JSON, 메타데이터(헤딩·페이지·바운딩박스)

2026년 현재 살아남은 오픈소스 파서 5종

1. Docling — IBM Research의 엔터프라이즈 픽

RAG 친화 1순위

출신: IBM Research, 2024년 공개. 2026년 1월 Granite-Docling-258M VLM 추가 공개(Apache 2.0).

지원 포맷: PDF, DOCX, PPTX, XLSX, HTML, 이미지, 오디오(WAV/MP3), 비디오(MP4), LaTeX

강점: 의미 계층 구조를 보존하는 DoclingDocument 출력. TableFormer 모델이 병합 셀까지 정확히 인식하고, 헤딩·섹션·페이지번호·바운딩박스가 메타데이터로 따라옵니다. RAG 답변에 "3.1절 7페이지 출처" 같은 인용을 붙이기 쉬워요. LlamaIndex·LangChain·MCP 통합 기본 제공.

약점: 표가 많은 문서는 페이지당 4~5초로 느린 편이고, 멀티컬럼 처리 시 메모리가 2GB까지 튀는 경우가 있습니다.

언제 쓰나: 사내 규정집, 금융 리포트, 기술 매뉴얼처럼 구조가 살아있어야 하는 문서. 출처 추적이 중요한 컴플라이언스 영역.

2. MinerU — CJK 문서의 최강자

한글 특화

출신: 상하이 AI 연구소(OpenDataLab) 오픈소스 프로젝트.

강점: 중국어·일본어·한국어 레이아웃 감지에서 따라올 도구가 거의 없습니다. 한자가 섞인 학술 논문, 세로쓰기, 복잡한 표, 스캔 PDF의 OCR까지 단일 파이프라인에서 처리해요. 한국 정부 보고서, 금융권 한글 PDF처럼 폰트와 레이아웃이 까다로운 문서에 강합니다.

약점: 영문 학술 논문에서는 Marker나 Docling보다 살짝 떨어질 때가 있고, 의존성이 무거워 초기 셋업이 번거롭습니다.

언제 쓰나: 한글 비중이 60% 이상인 문서 코퍼스, 스캔본이 다수 섞인 환경.

3. Marker — 속도와 균형의 만능 칼

출신: Datalab(VikParuchuri) 오픈소스. Surya OCR 엔진 기반.

지원 포맷: PDF, 이미지, DOCX, PPTX, XLSX, HTML, EPUB

강점: GPU 가속이 강력합니다. V100·L40S에서 처리량이 다른 파서 대비 눈에 띄게 빠르고, --use_llm 플래그를 켜면 정확도가 한 단계 더 올라갑니다. 학술 논문의 수식, 참고문헌, 다단 레이아웃 처리가 깔끔해요.

약점: 표 병합 셀을 분리된 항목으로 쪼개는 경향이 있어서, 표 구조가 핵심인 재무 문서엔 Docling이 더 적합합니다.

언제 쓰나: 대량 문서 일괄 처리, 영문·학술 비중 높은 코퍼스, 속도가 정확도보다 중요한 파이프라인.

4. Unstructured (오픈소스) — 포맷 다양성의 챔피언

출신: Unstructured.io 오픈소스 라이브러리(상용 API 별도). GitHub 약 14.6k stars.

지원 포맷: 30개 이상(PDF, DOCX, PPTX, XLSX, HTML, 이메일, 이미지 등)

강점: 다른 파서가 Markdown으로 평탄화할 때, Unstructured는 Title, NarrativeText, Table, ListItem, Header 같은 의미 단위로 라벨링된 요소를 반환합니다. 이 라벨이 청킹 로직의 자연스러운 경계가 되기 때문에 RAG 청킹 품질이 안정적이에요. 룰 기반 + AI 하이브리드 파싱.

약점: 표·복잡 레이아웃 정확도는 Docling보다 낮고, 의미 라벨링에 의존하다 보니 출력이 다소 무거운 편입니다.

언제 쓰나: 이메일·HTML·오피스·PDF가 잡탕으로 섞인 코퍼스. 단일 파이프라인에서 다 받아야 할 때.

5. PyMuPDF4LLM — 가볍고 빠른 단순 PDF 추출

출신: PyMuPDF(fitz)의 LLM 친화 래퍼.

강점: 디지털 텍스트 PDF에서는 가장 빠르고 가볍습니다. 의존성이 거의 없고 설치도 단순해서 폐쇄망 도입 장벽이 가장 낮아요. 결과는 깔끔한 Markdown.

약점: 스캔본·복잡한 멀티컬럼·표가 많은 문서는 사실상 못 씁니다. 비전 모델이 없으니까요.

언제 쓰나: 사내 결재 시스템에서 뽑아낸 깔끔한 디지털 PDF, 가벼운 프로토타입, 라우터에서 "단순 텍스트" 분류된 문서의 빠른 경로(fast path).

한눈에 보는 비교 매트릭스

 

도구	표 구조	한글	속도	GPU 가속	RAG 출력	폐쇄망
Docling	★★★★★	★★★★	★★★	지원	DoclingDocument + 메타	완전 로컬
MinerU	★★★★	★★★★★	★★★	지원	Markdown + JSON	완전 로컬
Marker	★★★	★★★	★★★★★	강력 지원	Markdown / JSON / chunks	완전 로컬
Unstructured	★★★	★★★	★★★★	일부 지원	의미 라벨 요소	완전 로컬
PyMuPDF4LLM	★★	★★★	★★★★★	불필요	플랫 Markdown	완전 로컬

V100·sm_70 환경에서 알아둬야 할 점

V100(sm_70) GPU 클러스터를 운영 중이라면 최신 비전 파서가 점점 사양에서 잘라내는 추세를 의식해야 합니다. 특히 다음 세 가지에서 막힐 수 있어요.

• bfloat16 미지원: sm_70은 fp16/fp32만 지원합니다. 모델 로드 시 torch_dtype=torch.float16 명시 필요.
• FlashAttention 2/3 제한: 일부 VLM 기반 파서(Granite-Docling 등)는 FA를 가정합니다. CPU fallback이나 표준 attention으로 우회.
• 최신 vLLM 호환성: vLLM은 0.7.x 이후 sm_70 지원이 사실상 멈춥니다. 파서가 vLLM을 의존성으로 가지면 핀(pin) 관리가 추가로 필요해요.

💡 실무 팁

L40S 같은 sm_89 카드로 업그레이드 계획이 있다면, Marker의 --use_llm 모드와 Granite-Docling이 본격적으로 빛을 봅니다. 그 전까지는 Docling 기본 모델 + MinerU 조합이 V100에서 가장 안정적이에요.

실전 추천 — 시나리오별 선택 가이드

시나리오	1순위	대안
한글 PDF 위주 (정부 문서, 사내 규정)	MinerU	Docling
금융 리포트·재무 자료 (표 핵심)	Docling	Unstructured
영문 학술 논문·기술 문서	Marker	Docling
이메일·HTML·오피스 잡탕 코퍼스	Unstructured	Docling
깔끔한 디지털 PDF만, 빠르게	PyMuPDF4LLM	Marker
스캔본·이미지 PDF 다수	MinerU	Marker (LLM 모드)

현실적인 답 — 하이브리드 파이프라인

2026년 RAG 커뮤니티의 컨센서스는 명확합니다. 어떤 오픈소스 파서도 모든 문서를 혼자 잘 처리하지 못한다는 것. 스켈레톤용 파서, OCR용 파서, 표·수식용 파서를 따로 두고 라우터가 분기하는 구조가 자리잡는 추세예요.

제가 사내 환경에서 검토했던 구조는 대략 이런 모습입니다.

┌─────────────────────────────────────────────┐
│  1차 라우터 (문서 유형 감지)                │
│  - 디지털 텍스트 PDF? → fast path           │
│  - 스캔본·이미지? → OCR path                │
│  - CJK 비중 높음? → CJK path                │
│  - 잡탕 포맷? → 범용 path                   │
└──────────────────┬──────────────────────────┘
                   ↓
   ┌───────────────┼────────────────┐
   ↓               ↓                ↓
fast path     OCR path         CJK path
PyMuPDF4LLM   MinerU           MinerU
              + Tesseract      
                   ↓
   범용 path: Docling (기본) / Unstructured (다포맷)
                   ↓
            Markdown + 메타데이터로 표준화
                   ↓
            청킹 (semantic, 200~500 토큰)
                   ↓
            임베딩 + 벡터 DB

출력은 전부 Markdown + JSON 메타데이터로 통일하면 다운스트림 청킹·임베딩 코드를 파서별로 분기하지 않아도 됩니다. 청크 사이즈는 일반적으로 200~500 토큰이 RAG에서 안정적이에요.

마무리 — 어디서부터 시작할까

폐쇄망 RAG를 처음 시작한다면

Docling 단일 도구로 PoC를 띄우고, 한글 비중이 높거나 스캔본이 섞이는 순간 MinerU를 라우터에 추가하는 순서를 추천드려요. Marker는 처리량 병목이 보이는 시점에 GPU 가속용으로 합류시키면 됩니다. Unstructured는 포맷이 다양해질 때, PyMuPDF4LLM은 fast path 옵션으로.

결국 파서 선택은 "어떤 도구가 최고냐"의 문제가 아니라 "내 문서 분포에 어떤 조합이 맞느냐"의 문제입니다. 처음부터 거창한 파이프라인을 짜기보다 단일 파서로 시작해서 실패 케이스를 모은 다음, 그 케이스만 처리할 두 번째 파서를 붙이는 점진적 접근이 가장 현실적이에요.

혹시 비슷한 환경에서 RAG 구축 중이시라면, 어떤 파서로 시작하셨는지 그리고 어디서 막히셨는지 댓글로 공유해주세요. 케이스가 쌓일수록 다음 글을 더 알찬 내용으로 쓸 수 있을 것 같아요.

※ 본 글은 2026년 5월 시점 공개된 정보와 개인 검토 경험을 바탕으로 작성되었습니다. 각 도구의 라이선스·버전·기능은 빠르게 변하므로 도입 전 공식 저장소 확인을 권장드립니다. 특정 도구를 추천하거나 후원하지 않습니다.