[심층분석] PDF 지옥에서 벗어나기: 71만 줄 문서를 LLM이 읽을 수 있게 만드는 MinerU 뜯어보기

PDF는 왜 이렇게 다루기 힘들까요?

혹시 RAG 시스템을 만들어 보신 적 있나요? 회사 내부 문서나 논문 수백 개를 AI한테 먹여서 "이 자료들 기반으로 질문에 답해줘" 하는 그 시스템 말이에요. 막상 해보면 가장 짜증나는 단계가 바로 문서를 텍스트로 바꾸는 일이거든요.

PDF가 특히 악명 높아요. 사람 눈에는 깔끔한 표와 수식, 2단 편집의 논문이 보이지만, 컴퓨터한테 PDF는 그냥 "이 좌표에 이 글자를 찍어라"는 그림 명령어 덩어리예요. 그래서 단순하게 텍스트만 뽑으면 표가 와르르 무너지고, 2단 칼럼이 뒤섞이고, 수식은 깨진 기호가 되고, 페이지 머리말·꼬리말까지 본문에 섞여 들어와요. 이걸 그대로 AI한테 주면 "쓰레기를 넣으면 쓰레기가 나온다(garbage in, garbage out)"는 말 그대로가 돼버려요.

오늘 소개할 MinerU는 바로 이 문제를 정면으로 푸는 도구예요. 상하이 AI랩 산하 OpenDataLab가 만든 오픈소스 프로젝트인데, 한 줄로 요약하면 이래요.

> 복잡한 PDF·워드·PPT·엑셀·이미지·웹페이지를, LLM이 바로 읽을 수 있는 깔끔한 Markdown / JSON으로 변환해주는 엔진

최근 3.4 버전까지 올라오면서 OCR 정확도와 모델 다운로드 경험이 크게 좋아졌고, 109개 언어를 지원해요. 왜 이게 중요한지, 안에서 무슨 일이 벌어지는지 천천히 풀어볼게요.

핵심 아이디어: "사람이 읽는 순서"로 복원한다

MinerU의 출력물을 보면 한 가지 철학이 분명하게 보여요. 바로 human reading order(사람이 읽는 순서)를 따른다는 거예요.

이게 뭐냐면요. 학술 논문 한 페이지를 떠올려 보세요. 왼쪽 칼럼을 위에서 아래로 읽고, 그다음 오른쪽 칼럼으로 넘어가죠. 중간에 표가 있으면 표를 읽고, 수식이 나오면 수식을 이해하고. 사람한테는 너무 당연한 이 순서를, 기계는 그냥 "위에서 아래로, 왼쪽에서 오른쪽으로" 좌표만 보고 긁어버려요. 그러면 왼쪽 칼럼 첫 줄, 오른쪽 칼럼 첫 줄, 다시 왼쪽 둘째 줄... 이렇게 문장이 누더기가 돼요.

MinerU는 먼저 페이지의 레이아웃(배치)을 분석해요. "여기는 제목, 여기는 본문 칼럼, 이건 표, 저건 그림, 이건 페이지 번호" 하고 영역을 구분한 다음, 사람이 읽을 순서대로 다시 엮어줘요. 그러면서 자동으로 머리말·꼬리말을 떼어내요. 결과적으로 나오는 Markdown이 진짜 사람이 정리한 것처럼 자연스러워지는 거죠.

구체적으로 어떤 걸 처리해주냐면요.

• 수식 → LaTeX: 깨진 기호 대신 \frac{a}{b} 같은 정식 수학 표기로 변환해줘요. AI가 수식의 의미를 이해할 수 있게 되는 거예요.
• 표 → HTML: 셀 구조를 그대로 살린 HTML 표로 만들어줘요. 심지어 페이지를 넘어가며 잘린 표도 하나로 합쳐줘요(cross-page table merging). 긴 표가 다음 페이지로 이어질 때 보통 두 조각으로 깨지는데, 이걸 알아서 이어붙이는 거죠.
• 스캔 문서·손글씨·다단 편집: 도장 찍히고 손으로 쓴 옛날 문서도, 신문처럼 칼럼이 여러 개인 레이아웃도 처리해요.

듀얼 엔진: 상황에 맞게 골라 쓰는 두 개의 머리

MinerU가 똑똑한 또 하나의 지점은 변환 방식을 골라 쓸 수 있다는 거예요. 크게 세 가지 백엔드(처리 엔진)를 제공해요.

1. pipeline 엔진 — 빠르고 안정적인 기본기

전통적인 방식이에요. 레이아웃을 분석하고, 글자가 그림으로 박힌 부분은 OCR(광학 문자 인식, 이미지 속 글자를 텍스트로 읽어내는 기술)로 읽어내요. 가장 큰 장점은 환각(hallucination)이 없다는 점이에요.

환각이라는 건, 쉽게 말해 AI가 없는 내용을 그럴듯하게 지어내는 현상이에요. pipeline 엔진은 AI가 추론으로 글자를 "상상"하는 게 아니라 실제로 인식하는 방식이라, 원문에 없는 말을 만들어낼 위험이 적어요. 게다가 CPU에서도 돌아가요. 비싼 GPU가 없어도 쓸 수 있다는 거죠. 이번 3.4 버전이 바로 이 pipeline 엔진의 OCR 정확도를 집중적으로 끌어올렸어요.

2. vlm-engine — 똑똑하지만 무거운 정예

VLM(Vision-Language Model, 그림과 글자를 함께 이해하는 AI 모델)을 쓰는 방식이에요. 이미지를 보고 문맥까지 파악해서 변환하니까 정확도가 높아요. 복잡한 레이아웃일수록 빛을 발하죠. 대신 vLLM, LMDeploy, 애플 실리콘용 mlx 같은 추론 프레임워크 위에서 돌리기 때문에 자원을 더 많이 먹어요.

3. hybrid-engine — 두 마리 토끼를 잡는 절충안

이름 그대로 둘을 섞었어요. PDF에 이미 글자 정보가 들어 있으면(native text) 그걸 그대로 뽑아 정확도를 챙기고, 필요한 부분만 VLM으로 보강해요. 정확도는 높이면서 환각은 낮추는, 균형 잡힌 선택지예요.

비유하자면 이래요. pipeline은 꼼꼼한 타이피스트예요. 보이는 대로 정확히 받아치지만 융통성은 없어요. vlm-engine은 베테랑 편집자예요. 문맥을 이해하고 알아서 정리하지만 품삯(자원)이 비싸요. hybrid는 둘이 짝지어 일하는 팀이고요. 내 문서 성격과 가진 장비에 맞춰 고르면 돼요.

어디에 갖다 붙일 수 있나요?

MinerU가 인기 있는 진짜 이유는 변환 품질만이 아니라 생태계 연결이에요. 만든 결과물을 어디에 흘려보낼지가 이미 다 준비돼 있거든요.

• MCP 서버 지원: MCP(Model Context Protocol)는 AI 도구들이 외부 기능을 표준 방식으로 가져다 쓰게 해주는 규약이에요. 쉽게 말해 "AI를 위한 USB 포트" 같은 거죠. 덕분에 Cursor, Claude Desktop, Windsurf 같은 AI 코딩 도구가 MinerU를 직접 호출해서 문서를 읽을 수 있어요.
• RAG 프레임워크 네이티브 연동: LangChain, LlamaIndex, RAGFlow, Dify, FastGPT 등 요즘 쓰는 RAG 도구 대부분과 바로 붙어요.
• 여러 방식의 사용 경로: Python·Go·TypeScript SDK, CLI(명령줄), REST API, Docker까지. 코드를 못 짜는 분을 위한 웹 UI와 데스크톱 클라이언트도 있어요.

경쟁 도구들과 비교하면

문서 파싱 도구는 사실 여럿 있어요. 대표 선수들과 비교해볼게요.

| 도구 | 강점 | 약점 |
|------|------|------|
| PyMuPDF / pdfplumber | 가볍고 빠름, 무료 | 표·수식·복잡 레이아웃에 약함 |
| unstructured | 다양한 포맷, 생태계 넓음 | 복잡한 표·수식 정확도 아쉬움 |
| LlamaParse | 품질 좋고 손쉬움 | 클라우드 유료 API, 데이터 외부 전송 |
| Docling (IBM) | 오픈소스, 구조화 잘함 | 언어·아키텍처 지원 범위 |
| MinerU | 수식/표/다국어 강함, 완전 오프라인 가능 | 고정확 모드는 GPU 필요 |

비유로 풀면, PyMuPDF는 연필 한 자루예요. 어디서나 쓸 수 있지만 정교한 작업은 무리예요. LlamaParse는 고급 외주 업체고요. 결과는 좋지만 내 민감한 문서를 밖으로 보내야 하고 비용이 나가요. MinerU는 우리 사무실에 들여놓은 전문 장비예요. 처음 세팅은 좀 해야 하지만, 한번 갖추면 외부에 데이터 한 톨 안 흘리고 무제한으로 돌릴 수 있어요.

특히 MinerU가 차별화되는 지점은 완전 오프라인·온프레미스(사내 자체 서버) 운영이 가능하다는 점, 그리고 수식과 다국어예요. 한중일 혼용 문서, 수식 가득한 논문처럼 까다로운 자료에서 강점이 분명해요. 중국산 AI 칩(Ascend, Cambricon 등) 10여 종까지 지원하는 건, 외부 클라우드에 의존하지 않으려는 시장 흐름을 정확히 노린 포지셔닝이에요.

한국 개발자에게 주는 시사점

구체적인 시나리오로 풀어볼게요.

시나리오 1 — 사내 문서 RAG. 보안 때문에 외부 API를 못 쓰는 회사가 많죠. 규정집·기술 매뉴얼이 전부 PDF인데 LlamaParse 같은 클라우드는 데이터 유출 우려로 막혀 있어요. 이럴 때 MinerU를 사내 서버에 올리면, 문서를 밖으로 한 번도 안 내보내고 RAG 파이프라인을 완성할 수 있어요.

시나리오 2 — 논문·기술 자료 분석 봇. 수식과 표가 핵심인 자료는 일반 파서로는 다 깨져요. MinerU의 LaTeX·HTML 변환을 쓰면 수식의 의미까지 살아남아서, AI가 "이 수식이 뭘 뜻하는지"까지 답할 수 있게 돼요.

시나리오 3 — 비용 절감. 지금 외부 파싱 API에 문서 건당 요금을 내고 있다면, pipeline 엔진은 CPU만으로도 돌아가니 일단 작은 서버에서 시험해볼 수 있어요. 양이 많아질수록 자체 운영이 훨씬 싸져요.

학습 로드맵은 이렇게 권해요. 먼저 ① Zero-Install 웹 버전이나 데스크톱 클라이언트로 내 PDF가 얼마나 잘 변환되는지 눈으로 확인하고 → ② 마음에 들면 CLI나 Python SDK로 pipeline 엔진을 로컬에서 돌려보고 → ③ GPU가 있다면 vlm/hybrid 엔진으로 정확도를 올린 뒤 → ④ LangChain이나 Dify에 연결해 RAG로 확장하는 순서예요. 1단계는 설치도 필요 없으니 오늘 당장 10분이면 감을 잡을 수 있어요.

마무리: 문서 파싱이 "기본기"가 되는 시대

MinerU가 보여주는 큰 그림은, 문서 전처리가 더 이상 귀찮은 잡일이 아니라 AI 시스템의 핵심 기본기가 되고 있다는 거예요. 아무리 똑똑한 LLM도 깨진 입력을 주면 헛소리를 하니까요. 좋은 답의 절반은 좋은 입력에서 나온다는 걸 다들 깨닫기 시작한 거죠.

동시에 "내 데이터는 내 인프라 안에서"라는 온프레미스·오프라인 흐름도 분명해지고 있어요. MinerU의 완전 오프라인 지원과 국산 칩 대응은 그 신호예요. 앞으로 RAG·에이전트 워크플로우를 짤 때, 파서를 클라우드에 맡길지 직접 들고 갈지가 중요한 설계 결정이 될 거예요.

여러분은 어떠세요? 지금 PDF나 사내 문서를 AI에 먹일 때 어떤 도구를 쓰고 계신가요? 표나 수식이 깨져서 고생한 경험, 아니면 "이건 진짜 잘 되더라" 했던 도구가 있다면 댓글로 나눠주세요. 오프라인 파싱 vs 클라우드 API, 여러분의 선택은 어느 쪽인가요?