PDF와 스캔 문서를 AI가 읽을 수 있게 바꾸는 오픈소스 MinerU

1. 개요: 먼저 문서를 읽을 수 있게 만들어야 합니다

MinerU는 챗봇이 아닙니다. 더 정확히 말하면 문서 준비 도구에 가깝습니다. 공식 저장소는 MinerU를 LLM, RAG, 에이전트 워크플로를 위한 문서 파싱 엔진이라고 설명합니다. 쉽게 말하면 복잡한 파일을 AI가 검색하고 인용하고 다음 업무로 넘길 수 있는 자료로 정리해주는 도구입니다.

공식 설명 기준으로 MinerU는 PDF, 이미지, DOCX, PPTX, XLSX 파일을 구조화된 Markdown과 JSON으로 변환할 수 있습니다. Markdown은 사람과 AI 도구가 읽기 쉬운 정리된 글 형식입니다. JSON은 시스템이 항목을 구분해서 주고받을 수 있는 데이터 형식입니다.

이 단계가 중요한 이유는 단순합니다. 원본 파일이 스캔본이거나, 표가 많거나, 여러 단으로 나뉘어 있거나, 인쇄용 PDF로만 남아 있으면 AI가 내용을 제대로 찾기 어렵습니다. 입력이 흐리면 어떤 모델을 붙여도 결과 품질은 흔들립니다.

2. MinerU가 제공하는 기능

기능은 꽤 실무적입니다. MinerU는 OCR을 지원합니다. OCR은 이미지나 스캔 문서에 찍힌 글자를 텍스트로 바꾸는 기술입니다. 또 사람이 읽는 순서를 보존하려고 하고, 머리말과 꼬리말을 제거하며, 표와 이미지를 추출하고, 수식은 LaTeX 형식으로, 표는 HTML 형식으로 내보낼 수 있다고 설명합니다. 공식 저장소에는 OCR이 109개 언어를 지원한다는 설명도 있습니다.

개발자 입장에서는 CLI, API, Docker, SDK, LangChain, LlamaIndex, Dify, FastGPT, MCP 연동 같은 방식으로 붙일 수 있습니다. 비개발자에게 필요한 번역은 이렇습니다. 한 번 환경을 잡아두면 문서 변환을 사람이 복사해서 붙여넣는 일이 아니라 반복 업무의 한 단계로 만들 수 있습니다.

RAG는 retrieval-augmented generation의 줄임말입니다. AI가 답하기 전에 저장된 문서를 먼저 검색하는 방식입니다. MinerU는 RAG가 문서를 검색하기 전에 원본 문서를 정리해주는 준비 단계에서 가치가 있습니다.

• OCR: 스캔된 글자를 텍스트로 바꾸는 기술입니다.
• Markdown: 사람과 AI 도구가 읽기 쉬운 정리된 글 형식입니다.
• JSON: 시스템이 항목을 구분해 주고받는 데이터 형식입니다.
• RAG: AI가 답하기 전에 준비된 문서를 먼저 검색하는 방식입니다.
• MCP와 연동 도구: 에이전트나 업무 자동화 시스템이 MinerU를 호출하게 해주는 연결 방식입니다.

3. 실제 업무 적용 아이디어

처음부터 회사의 모든 문서를 대상으로 삼는 방식은 좋지 않습니다. 정기적으로 접수되는 문서 한 종류를 선택하고, 검수 책임자를 정하는 편이 좋습니다. 실제 문서 20개에서 50개 정도를 MinerU로 처리한 뒤, 다음 업무에 쓸 만큼 결과가 맞는지 확인하는 방식이 안전합니다.

계약서라면 당사자, 날짜, 갱신 조건, 지급 조건, 특이 조항을 사람 검토 전에 뽑아볼 수 있습니다. 세금계산서와 견적서라면 거래처명, 금액, 날짜, 품목, 세금 항목을 정리하는 데 쓸 수 있습니다. 보고서와 매뉴얼은 제목, 표, 그림, 원문 문단을 뽑아 사내 검색 자료로 넘길 수 있습니다.

로컬 X 북마크 조사에서도 MinerU를 무료 오픈소스 문서 변환 도구로 보는 관심이 확인됐습니다. 다만 이런 반응은 시장 신호로만 봐야 합니다. 정확도 판단은 각 회사의 문서로 해야 합니다. 회사마다 양식, 언어, 스캔 품질, 표 모양이 다르기 때문입니다.

• 계약서 접수: 핵심 날짜, 당사자, 갱신 조건, 조항을 검토 전에 뽑습니다.
• 회계 보조: 세금계산서, 견적서, 영수증, 거래명세서 표를 확인 가능한 자료로 바꿉니다.
• 사내 지식화: 오래된 매뉴얼, 정책 PDF, 온보딩 자료를 검색 가능한 출처로 정리합니다.
• 리서치와 보고서: 긴 보고서에서 제목, 표, 수식, 그림, 인용할 문단을 모읍니다.
• 고객 운영: 반복 양식과 첨부 파일을 접수 분류에 쓸 수 있는 항목으로 바꿉니다.

4. 설계 도면과 print-to-PDF 문서에도 쓸 수 있을까요?

시험해볼 가치는 있습니다. 다만 기대 범위를 좁게 잡아야 합니다. 설계 업무에서는 제출, 공유, 보관 전에 도면을 PDF로 저장하는 경우가 많습니다. 이때 MinerU는 제목란, 개정표, 일반 주석, 범례, 실명, 시트 번호, 날짜, 표처럼 눈에 보이는 글과 표를 뽑는 데 후보가 될 수 있습니다.

이 정도만 되어도 검색과 관리에는 도움이 됩니다. 예를 들어 "이 방 이름이 들어간 도면은 무엇인가", "B 개정에서 바뀐 시트는 무엇인가", "이 장비 태그가 들어간 파일은 어디인가" 같은 질문을 문서 검색으로 연결할 수 있습니다.

하지만 이것은 도면을 CAD나 BIM처럼 이해하는 것과 다릅니다. MinerU가 레이어, 축척, 기호 의미, 법규 적합성, 구조 의도, 물량 산출, 설계 책임을 판단한다고 보면 안 됩니다. 도면 PDF는 먼저 눈에 보이는 글과 표가 들어 있는 문서로 다루고, 설계 판단은 기존 전문 검토 절차를 유지해야 합니다.

5. 적용 전 Checklist: 샘플 테스트와 사람 검수

MinerU는 유망하지만, 공식 Quick Start 문서도 문서 파싱이 어렵다는 점을 분명히 말합니다. 복잡한 레이아웃, 스캔 페이지, 손글씨 내용에서는 결과가 부족할 수 있습니다. 그래서 안전한 도입 순서는 샘플 테스트를 먼저 하고, 그다음 업무 연결을 검토하는 것입니다.

운영 관점의 질문도 있습니다. 로컬 배포에는 하드웨어, 저장공간, 모델 파일, 유지보수가 필요합니다. 민감한 문서는 개인정보와 접근 권한 규칙이 필요합니다. 현재 라이선스는 Apache 2.0 기반에 추가 조건이 붙은 형태이므로 상업적으로 쓰려는 팀은 라이선스를 먼저 확인해야 합니다. 표 추출과 낮은 추출 품질에 관한 공개 GitHub 이슈도 실제 파일에서는 데모와 다른 문제가 생길 수 있다는 신호로 봐야 합니다.

작게 시작하면 충분합니다. 문서 한 종류를 고릅니다. 샘플을 준비합니다. 무엇을 맞으면 성공으로 볼지 정합니다. 사람 검수 결과와 비교합니다. 추출 결과 옆에 원본 파일 링크를 남깁니다. 이 절차를 통과한 뒤 검색, 자동화, 에이전트 업무에 연결하는 편이 좋습니다.

• 공개 예제가 아니라 우리 회사의 실제 문서로 테스트합니다.
• 이름, 날짜, 금액, 표, 조항, 페이지 위치처럼 중요한 항목을 기준으로 봅니다.
• 계약, 돈, 법무, 안전, 설계 판단에는 사람 검수 단계를 남깁니다.
• 실패 사례를 기록하고 다음 테스트 세트에 넣습니다.
• 실서비스 전에 배포 방식, 개인정보, 접근 권한, 라이선스를 확인합니다.