프롤로그 — 2026년에도 OCR이 어려운 이유

2026년에도 우리는 PDF로 고통받는다. 청구서, 계약서, 보험 약관, 의료 기록, 학술 논문, 정부 문서 — 인류가 만든 비즈니스 문서의 대부분은 여전히 PDF다. 그리고 그중 상당수는 스캔된 이미지 PDF이거나, 텍스트가 들어있어도 표·이미지·수식·여러 단 레이아웃이 섞여 있어 "그냥 텍스트 추출"이 안 된다.

LLM이 충분히 똑똑해졌으니 문서 파싱은 풀린 문제일까. 아니다. 2025년 한 해 동안 Mistral OCR, OlmoOCR, Reducto, LlamaParse 새 버전, Docling 1.0, Marker 1.0, Surya 0.6 등이 잇따라 나왔다는 사실 자체가 "아직 정답이 없다"는 증거다. 누구도 한 방에 풀지 못했다.

이 글은 2026년 5월 현재 문서 AI 생태계의 지도를 13개 후보로 그린다. 각각이 어디에 강하고 어디에 약한지, 그리고 우리 팀이 청구서·계약서·논문·RAG ingestion 중 어떤 일을 한다면 무엇을 골라야 할지까지.

1장 · 2026년 문서 AI 지도 — 4단계 파이프라인으로 정리한다

문서 AI를 한 덩어리로 보면 도구를 못 고른다. 단계로 쪼개야 한다. 우리는 4단계 모델을 쓴다.

| 단계 | 하는 일 | 입력 | 출력 |

| --- | --- | --- | --- |

| 1. OCR | 픽셀 → 텍스트 | 이미지/PDF | 글자 + 좌표 |

| 2. Layout | 텍스트 + 좌표 → 구조 | OCR 결과 | 블록·표·헤딩·읽기 순서 |

| 3. Extraction | 구조 → 의미 필드 | 레이아웃 결과 | JSON(invoice_number, total, ...) |

| 4. RAG ingestion | 의미 → 검색 인덱스 | 추출 결과 | chunked markdown + 메타데이터 |

각 단계는 별개의 도구로 풀거나, 한 도구가 여러 단계를 흡수한다. 2026년의 트렌드는 명확하다 — **단계가 통합되는 쪽**이다.

- Mistral OCR, OlmoOCR, Marker, Docling — OCR + Layout을 한 번에

- LlamaParse, Unstract, Reducto — 거기에 Extraction까지

- 멀티모달 LLM(Pixtral, Florence-2, Claude, GPT-4o) — 네 단계를 통째로 흡수 시도

이 통합이 좋기만 한 건 아니다. 한 단계가 망가지면 어디서 망가졌는지 보기 어렵다. 그래서 우리는 **단계별로 도구를 골라서 조합하는 파이프라인**과, **end-to-end LLM 호출**을 둘 다 쓴다. 어느 쪽이 더 나은지는 도메인이 정한다.

핵심 통찰 — **OCR은 2026년에도 단일 모델이 다 풀지 못한다.** 청구서에서 좋은 게 학술 논문에서 망가지고, 한국어에서 좋은 게 일본어에서 망가진다. 도메인별 베스트가 따로 있다.

2장 · Mistral OCR (2025년 3월) — 새로운 표준 API

2025년 3월, Mistral이 "OCR API"라는 이름으로 별도 제품을 냈을 때 업계가 놀랐다. LLM 회사가 왜 OCR API를 따로? 답은 "Mistral 7B 같은 자사 모델로 RAG 하려면 좋은 PDF 파서가 필수인데, 시장에 만족스러운 게 없었다"였다.

Mistral OCR이 가져온 변화 세 가지.

- **속도 우선** — 한 페이지 약 2,000 페이지/분(배치 기준). Marker 같은 오픈소스 대비 한 자릿수 빠르다.

- **레이아웃 + 수식 + 표 + 이미지 위치 모두 마크다운으로 반환** — 텍스트만 주는 게 아니라 구조를 준다.

- **per-page 가격** — 1,000페이지에 약 1달러. 클라우드 OCR(Document AI, Textract) 대비 절반에서 1/3 수준.

API는 단순하다.

from mistralai import Mistral

client = Mistral(api_key="...")

response = client.ocr.process(

model="mistral-ocr-latest",

document={"type": "document_url", "document_url": "https://example.com/contract.pdf"},

include_image_base64=True,

)

for page in response.pages:

print(page.markdown)

반환은 페이지별 마크다운이다. 표는 GFM 표로, 수식은 LaTeX로, 이미지는 base64로 함께 온다. 즉 한 번 호출하면 마크다운 + 임베디드 이미지 + 페이지 메타데이터가 한 번에 나온다.

약점도 있다. 한국어/일본어 같은 비라틴 스크립트는 영어/프랑스어만큼 안정적이지 않다(2025년 말 한국어 추가 학습이 들어왔지만 여전히 네이버 CLOVA OCR 대비 미세하게 떨어진다는 보고가 많다). 그리고 클로즈드 API다 — 자체 호스팅 못 한다.

언제 고르나 — **영어 위주 PDF를 빠르게 마크다운으로 바꿔야 하고, API 비용을 감당할 수 있을 때.** 특히 RAG ingestion 파이프라인을 1주 안에 만들어야 하면 거의 항상 첫 시도가 된다.

3장 · Marker (Vik Paruchuri) — PDF → Markdown 오픈소스 챔피언

Marker는 Datalab을 만든 Vik Paruchuri의 오픈소스 프로젝트다. "PDF를 마크다운으로 바꾸는" 가장 잘 알려진 오픈소스이고, GitHub 스타 3만 개를 넘었다(2026년 5월 기준). Mistral OCR이 나오기 전까지는 "오픈소스에서 PDF 마크다운화하는 거의 유일한 답"이었다.

Marker의 구성.

- **Surya** — 같은 저자가 만든 멀티링구얼 OCR + 레이아웃 모델 (다음 장)

- **레이아웃 모델** — DocLayoutYOLO 계열로 블록 분류

- **마크다운 변환기** — 표·수식·코드 블록을 인식해서 GFM/LaTeX로 변환

- **선택적 LLM 리파인** — 모호한 영역을 LLM에 다시 물어 정제

사용은 한 줄이다.

pip install marker-pdf

marker_single contract.pdf output/ --output_format markdown

배치 처리, 워커 수 지정, GPU/CPU 선택, LLM 리파인 켜기 모두 CLI 옵션으로 된다.

Marker의 강점은 **수식과 표**다. 학술 논문 같이 LaTeX 수식이 잔뜩 들어간 PDF에서는 Mistral OCR보다 자주 더 깨끗한 결과를 낸다. 그리고 자체 호스팅이 된다 — GPU 한 장 있는 머신에서 분당 30~100페이지가 나온다. 데이터를 외부로 보낼 수 없는 기업에 잘 맞는다.

약점은 속도다. CPU만 있으면 페이지당 5~30초가 걸린다. GPU에서도 Mistral OCR보다 느리다.

언제 고르나 — **PDF 데이터를 외부로 보내고 싶지 않거나(보안), 수식·표가 중요한 학술/금융 문서가 많거나, GPU 자원이 충분할 때.**

4장 · Surya — 멀티링구얼 OCR + 레이아웃 + 읽기 순서

Surya는 Marker 안에서 OCR을 담당하는 모듈이지만, 독립적으로도 강력하다. 같은 저자(Vik Paruchuri)가 만들었고, "오픈소스에서 가장 다국어 잘하는 OCR" 자리를 차지하고 있다.

Surya가 한 번에 푸는 4가지.

- **텍스트 검출** — 페이지에서 글자 영역 찾기

- **텍스트 인식(OCR)** — 90개 언어 지원, 한국어·일본어·중국어 포함

- **레이아웃 분석** — 헤딩·본문·표·이미지·캡션 분류

- **읽기 순서** — 다단 컬럼·삽화 캡션·각주를 사람이 읽는 순서로 재정렬

특히 마지막 "읽기 순서"가 중요하다. 신문이나 학술 논문은 컬럼이 여러 개고, 사이드바·각주·캡션이 본문과 섞인다. 단순 좌상단 → 우하단 스캔으로는 텍스트가 엉킨다. Surya는 트랜스포머로 사람이 읽는 순서를 예측한다.

from surya.recognition import RecognitionPredictor

from surya.detection import DetectionPredictor

from PIL import Image

image = Image.open("page.png")

det = DetectionPredictor()

rec = RecognitionPredictor()

predictions = rec([image], det_predictor=det)

for line in predictions[0].text_lines:

print(line.bbox, line.text)

Surya의 한국어/일본어 품질은 2026년 기준 오픈소스 중 최상위권이다. 네이버 CLOVA OCR이나 Google Document AI 한국어/일본어 모델보다 약간 떨어지지만, 자체 호스팅 가능한 오픈소스라는 점이 결정적이다.

언제 고르나 — **다국어(특히 CJK) PDF를 자체 호스팅으로 처리해야 할 때.** Marker 안에 들어가 있어서 따로 호출할 일은 많지 않지만, OCR만 따로 떼어 쓰고 싶으면 Surya를 직접 부른다.

5장 · LlamaParse (LlamaIndex) — RAG에 최적화된 파서

LlamaParse는 LlamaIndex가 만든 PDF 파서다. 출발점이 다르다 — "RAG에 쓸 좋은 입력을 만든다"가 목표다. 그래서 마크다운 출력이 LlamaIndex의 청크 분할기와 곱하기 좋게 설계됐다.

LlamaParse의 특징.

- **세 가지 모드** — fast(빠름·저렴), balanced(기본), premium(LLM 리파인, 표 정확도 ↑)

- **표를 마크다운 GFM으로 정확히** — premium 모드에서 표 인식이 가장 강하다는 평가가 많다

- **이미지 위치 보존** — 마크다운 안에 이미지 자리표시자

- **per-page 가격** — fast 모드 1,000페이지 무료, premium은 1,000페이지에 3달러 정도

API는 단순하다.

from llama_parse import LlamaParse

parser = LlamaParse(

api_key="...",

result_type="markdown",

parsing_mode="premium",

)

docs = parser.load_data("contract.pdf")

for doc in docs:

print(doc.text)

특이한 기능은 **parsing instructions** — 자연어로 "이 문서는 보험 약관이니까 조항 번호를 헤딩으로 잡아줘" 같은 힌트를 줄 수 있다. 내부적으로 LLM이 그 힌트를 받아 파싱 결과를 조정한다.

약점은 비용과 클로즈드 API다. premium 모드에서 1,000페이지에 3달러는 Mistral OCR의 3배다. 그리고 자체 호스팅 못 한다.

언제 고르나 — **LlamaIndex 기반 RAG를 이미 쓰고 있고, 표가 중요한 문서가 많을 때.** LlamaParse → SemanticSplitterNodeParser → 벡터 인덱스 흐름이 매끄럽다.

6장 · Docling (IBM, 오픈소스) — 기업용 종합 파서

Docling은 IBM Research가 2024년 말 공개한 오픈소스 문서 파서다. IBM 내부에서 "watsonx Discovery"라는 RAG 제품을 만들면서 쌓은 파싱 노하우를 떼어내 공개한 것이다.

Docling이 가져온 차별점 세 가지.

- **풍부한 출력 포맷** — 마크다운뿐 아니라 자체 JSON 포맷("DoclingDocument")으로 좌표·블록 ID·문단·표 셀까지 보존

- **표 인식 모델 TableFormer** — IBM이 별도로 학습시킨 표 구조 인식 모델. ICDAR 벤치에서 SOTA

- **로컬 + GPU 옵션** — 자체 호스팅 가능, CPU에서도 돌아감

Docling 사용.

from docling.document_converter import DocumentConverter

converter = DocumentConverter()

result = converter.convert("contract.pdf")

print(result.document.export_to_markdown())

또는 JSON 구조로

print(json.dumps(result.document.export_to_dict(), indent=2))

DoclingDocument JSON은 트리 구조다. body 아래에 sections, sections 아래에 paragraphs/tables/figures가 들어가고, 각 노드는 페이지 번호와 bbox를 가진다. 이게 중요하다 — 단순 마크다운으로는 "이 문장이 PDF의 어디에서 왔는지" 거꾸로 못 찾는데, Docling JSON으로는 페이지·좌표까지 역추적된다. RAG의 출처 표시(citation)에 직접 쓸 수 있다.

약점은 속도다. Marker보다 살짝 느리고, GPU가 없으면 페이지당 10초가 넘는 경우도 있다. 그리고 한국어/일본어는 영어만큼 성숙하지 않다.

언제 고르나 — **자체 호스팅이 필요하고, RAG에서 "이 답변의 근거가 PDF의 어디인지" 정확한 출처가 필요할 때.** 기업 컴플라이언스 환경에 잘 맞는다.

7장 · DocLayoutYOLO — 빠른 레이아웃 검출 전문

DocLayoutYOLO는 OCR이 아니다. **레이아웃만** 한다. PDF 페이지 이미지를 받아 "이 영역은 제목, 이 영역은 본문, 이 영역은 표, 이 영역은 그림" 식의 바운딩 박스를 뱉는다.

왜 별도 모델이 필요할까. 다른 모든 도구가 레이아웃을 내장하니까. 답은 **속도와 조합 자유**다. DocLayoutYOLO는 YOLOv10 기반으로 한 페이지를 GPU에서 10밀리초에 처리한다. Marker나 Docling 내장 레이아웃 모델보다 한 자릿수 빠르다.

DocLayoutYOLO + 좋아하는 OCR(Tesseract, Surya, PaddleOCR)을 조합하면 자기만의 파이프라인이 만들어진다.

from doclayout_yolo import YOLOv10

model = YOLOv10("doclayout_yolo_docstructbench_imgsz1024.pt")

results = model.predict("page.png", imgsz=1024, conf=0.2)

for box in results[0].boxes:

print(box.cls, box.xyxy)

언제 고르나 — **레이아웃 검출만 필요하거나, OCR을 다른 모델로 따로 돌리면서 레이아웃은 별도로 빠르게 잡고 싶을 때.** 대용량 문서를 처리하면서 단계마다 GPU 활용을 극대화해야 하는 파이프라인에 잘 맞는다.

8장 · Nougat (Meta) — 학술 논문 전용

Nougat은 Meta가 2023년 공개한 학술 논문 전용 OCR 모델이다. 이름이 의외인데 "Neural Optical Understanding for Academic Texts"의 약자다. arXiv 논문 800만 편 위에서 학습됐고, **수식과 표가 많은 학술 PDF**에서 압도적이다.

Nougat의 출력은 마크다운 + LaTeX 수식이다. 다른 OCR이 수식 영역을 이미지로 남기거나 깨진 텍스트로 변환할 때, Nougat은 LaTeX 코드로 정확히 복원한다. 행렬·적분·합 기호 다 된다.

pip install nougat-ocr

nougat path/to/paper.pdf -o out --model 0.1.0-base

약점은 **학술 논문 이외에서는 자주 망가진다**는 것이다. 청구서, 계약서, 일반 PDF에서는 형편없는 결과가 자주 나온다. 학습 데이터 도메인이 학술이라 그렇다.

그리고 환각(hallucination)이 있다. Nougat은 encoder-decoder 트랜스포머라 "그럴듯한 LaTeX"를 만들어내는데, 원본에 없는 식을 만들거나 식을 잘못 풀어 쓰는 경우가 보고된다. 학술 도메인에서도 검수가 필요하다.

언제 고르나 — **arXiv 같은 학술 PDF를 대량으로 마크다운/LaTeX화할 때.** 그 외의 도메인이라면 다른 도구가 거의 항상 낫다.

9장 · OlmoOCR (Allen AI, 2025년 2월) — 오픈 웨이트, 클라우드 수준

OlmoOCR은 Allen Institute for AI(AI2)가 2025년 2월 공개한 오픈 웨이트 OCR 모델이다. 이름이 OlmoOCR인 이유는 AI2가 만든 오픈 LLM 시리즈 "Olmo"에 OCR 능력을 학습시킨 것이기 때문이다.

OlmoOCR이 가져온 충격 — **오픈 웨이트인데 GPT-4o 수준의 OCR 품질을 보인다.** AI2가 자체 벤치(olmOCR-Bench)에서 측정한 결과 GPT-4o, Mistral OCR과 비등하거나 일부 도메인에서 앞선다.

특이점은 학습 방식이다. AI2는 7B Vision-Language 모델 Qwen2-VL-7B를 베이스로 잡고, "PDF에서 추출한 정답 텍스트" 25만 페이지를 SFT로 학습시켰다. 정답은 GPT-4o로 생성하고 사람이 검수한 데이터셋이다.

from transformers import AutoProcessor, Qwen2VLForConditionalGeneration

model = Qwen2VLForConditionalGeneration.from_pretrained(

"allenai/olmOCR-7B-0225-preview", torch_dtype=torch.bfloat16

)

processor = AutoProcessor.from_pretrained("allenai/olmOCR-7B-0225-preview")

... 이미지 + 프롬프트로 추론

추론 비용은 7B 모델이라 한 장 GPU에 올라간다. 한 페이지 약 1초(A100 기준). 추론 코드는 vLLM이나 SGLang으로 배치 처리하면 빠르다.

약점 — 7B 모델이라 메모리 12GB는 있어야 하고, OCR 전용이 아니라 VLM이라 가끔 "지시를 듣고 요약하려는 경향"이 나온다. 시스템 프롬프트 튜닝이 필요하다.

언제 고르나 — **클라우드 API 비용을 못 쓰지만 클라우드 수준 품질이 필요하고, GPU가 있을 때.** 오픈 웨이트라서 자체 호스팅이 자유롭고 라이선스 부담이 없다.

10장 · Tesseract 5 / LayoutLMv3 / Donut — 클래식과 사전학습 모델

새 도구만 보면 안 된다. 클래식들도 여전히 살아있다.

Tesseract 5

Tesseract는 1985년 HP에서 시작해 Google이 인수했다가 오픈소스로 풀린 OCR 엔진이다. 5.x 버전(2021년 이후)은 LSTM 기반으로 재작성되어 정확도가 크게 올라갔다. 100개 이상 언어, CPU에서도 빠르고, 무료다.

tesseract scan.png output -l kor+eng --psm 6

약점은 명확하다 — 레이아웃을 못 본다. 텍스트만 뱉는다. 표를 표로, 헤딩을 헤딩으로 인식하지 못한다. 그래서 2026년에는 "Tesseract + 별도 레이아웃 모델"의 조합으로 쓰인다. 또는 "이미 깨끗한 1단 텍스트 PDF만 처리하는 백업 파이프라인"으로.

언제 — **오프라인·극저비용·간단한 단일 단 문서.**

LayoutLMv3 (Microsoft)

LayoutLMv3는 Microsoft Research가 2022년 공개한 사전학습 문서 이해 모델이다. 텍스트 + 좌표 + 이미지 패치를 한 트랜스포머에 같이 넣어 학습됐다. 그래서 "이 영역은 헤더, 저 영역은 합계 필드" 같은 분류·추출 태스크에 강하다.

직접 OCR을 하지는 않는다. OCR 결과(텍스트 + 좌표)를 입력으로 받아 분류/추출만 한다. 그래서 "Tesseract/Azure OCR + LayoutLMv3 fine-tune"의 조합이 흔하다. FUNSD·CORD·SROIE 같은 IE(Information Extraction) 벤치에서 강하다.

언제 — **청구서·영수증·신청서처럼 필드가 정해진 문서를 대량으로 처리하고, 자체 데이터로 fine-tune할 수 있을 때.**

Donut (NAVER CLOVA AI)

Donut은 NAVER CLOVA AI가 2022년 공개한 "OCR-free" 문서 이해 모델이다. 이름이 "Document Understanding Transformer"의 줄임이다. 다른 모델과 달리 **OCR 단계를 건너뛴다**. 이미지를 직접 트랜스포머에 넣어 곧바로 JSON/마크다운을 뱉는다.

이게 왜 중요한가. 전통적 파이프라인은 OCR → 레이아웃 → 추출 세 단계인데, 각 단계 오류가 누적된다. Donut은 한 모델로 끝낸다. 특히 CORD(영수증), DocVQA, TICKET 같은 도메인에서 강하다.

약점은 도메인 fine-tune이 필요하다는 것이다. 사전학습된 Donut을 그대로 던지면 일반 PDF에서 형편없다. 자기 도메인 데이터 수천 장으로 fine-tune해야 진가가 나온다.

언제 — **반복적인 한 종류의 문서(예: 한국식 영수증, 미국식 W-2)를 수십만 장 처리해야 하고, 학습 데이터를 모을 수 있을 때.**

11장 · 멀티모달 LLM 활용 — Pixtral 12B / Florence-2 / KOSMOS-2.5

2025~2026년의 새 흐름은 **멀티모달 LLM에 그냥 PDF 페이지를 던지는** 방식이다. 별도 OCR도, 별도 레이아웃 모델도, 별도 추출 모델도 없다. VLM이 다 한다.

Pixtral 12B (Mistral, 2024년 9월)

Pixtral 12B는 Mistral의 첫 멀티모달 모델이다. 이미지를 받아 텍스트로 답한다. PDF 페이지 이미지를 던지고 "이 페이지를 마크다운으로 옮겨줘"라고 하면 마크다운이 나온다. Mistral OCR이 나오기 전까지는 Pixtral로 OCR을 하는 사용자가 많았다.

Florence-2 (Microsoft, 2024년 6월)

Florence-2는 0.23B/0.77B의 작은 비전 모델이다. OCR, 캡션, 객체 검출, 영역 추출을 한 모델로 한다. "small but strong" 컨셉으로 엣지/온디바이스에 좋다.

KOSMOS-2.5 (Microsoft, 2023년 9월)

KOSMOS-2.5는 텍스트 풍부 이미지 전용 멀티모달 모델이다. 스크린샷, 문서 이미지를 받아 마크다운으로 옮긴다. 학술적 영향력이 크지만 실제 프로덕션에는 OlmoOCR이 점차 자리를 가져갔다.

Claude / GPT-4o / Gemini 1.5/2.0

상용 멀티모달 LLM도 PDF 파싱에 자주 쓰인다. 페이지 이미지를 던지고 "마크다운으로 옮겨줘"로 끝난다. 품질은 좋지만 토큰 비용이 크고(1페이지에 수천 토큰), 페이지 수가 많으면 지치는 구조다.

**한 줄 결론** — 멀티모달 LLM은 적은 페이지수·복잡한 레이아웃·구조화된 추출(JSON)에 유리하다. 대량 OCR에는 Mistral OCR / OlmoOCR / Marker가 비용·속도에서 앞선다.

12장 · 한국 — 네이버 CLOVA OCR과 한국어 도메인

한국어 문서는 글로벌 도구들에 약점이 많다. 한글 형태소, 한자 혼용, 가로/세로 혼용, 한국 특유의 표 양식 때문이다. 네이버 CLOVA OCR이 한국어 도메인에서 가장 강하다는 평가가 굳어진 이유다.

네이버 CLOVA OCR의 특징.

- **한국어 정확도 95퍼센트 이상** (네이버 자체 벤치 기준, 인쇄체)

- **신분증·여권·자동차 등록증 같은 도메인 특화 템플릿**

- **표 인식이 한국식 표(병합 셀, 점선 표) 패턴에 맞춰져 있음**

- **API 호출당 가격** (월 1만 건까지 무료 티어)

headers = {"X-OCR-SECRET": "..."}

files = {"file": open("doc.pdf", "rb")}

payload = {

"message": json.dumps({

"version": "V2",

"requestId": "uuid",

"timestamp": 0,

"images": [{"format": "pdf", "name": "doc"}],

})

}

r = requests.post("https://...apigw.ntruss.com/custom/v1/.../general", headers=headers, files=files, data=payload)

대안 — 한국어에 강한 오픈소스로 **PaddleOCR**(중국어·한국어 강함)과 **EasyOCR**(80개 언어)이 자주 쓰인다. Surya도 한국어가 꽤 좋아졌다(2025년 0.5 이후).

언제 CLOVA를 고르나 — **국내 비즈니스 문서(세금계산서, 사업자등록증, 영수증, 은행 거래 내역)를 대량 처리할 때.** 도메인 템플릿이 직접적으로 들어맞는다.

13장 · 일본 — Yomi-toku, Google Cloud Document AI 日本語

일본어 문서는 한국어와 다른 어려움이 있다. 가로/세로 쓰기 혼재, 후리가나(루비), 한자 + 가나 + 카타카나 혼용, 그리고 손글씨 비중이 크다.

Yomi-toku (요미토쿠)

Yomi-toku는 일본어 특화 오픈소스 OCR이다. 일본어 인쇄체·세로쓰기·후리가나에 강하다. 일본 정부 디지털청(Digital Agency) 일부 프로젝트에서 채택되어 알려졌다.

pip install yomitoku

yomitoku scan.pdf -o output.json

Google Cloud Document AI 일본어 프로세서

Google Cloud의 Document AI는 글로벌 클라우드 OCR 중 일본어 품질이 가장 안정적이다. 일본 청구서(請求書), 견적서(見積書), 영수증(領収書) 전용 프로세서가 별도로 제공된다. 일본 SaaS·핀테크 회사들이 자주 채택한다.

그 외

- **Tegaki(手書き)** — 손글씨 전용 OSS 라이브러리

- **NDL OCR** — 일본 국립국회도서관이 학습시킨 모델, 옛 일본어/세로쓰기에 강함

언제 무엇을 — **국내 한정 비즈니스 문서면 CLOVA, 일본 한정이면 Document AI 일본어 프로세서, 둘 다 안 되면 Surya/OlmoOCR로 시작하고 도메인 fine-tune.**

14장 · 누가 무엇을 골라야 하나 — 4가지 시나리오

도구 13개를 외울 필요는 없다. 시나리오별로 압축한다.

시나리오 A — 청구서·영수증 대량 처리(IE)

필드(공급자, 금액, 날짜, 항목)가 정해진 문서를 대량으로 처리하고 JSON으로 뽑는다.

- **추천 조합** — Mistral OCR / Docling으로 마크다운 추출 → LLM(Claude 3.5 / GPT-4o)으로 JSON 추출

- **자체 호스팅 필요 시** — Marker → vLLM 호스팅 LLM

- **수십만 장 이상 대규모** — Donut을 자체 데이터로 fine-tune

시나리오 B — 계약서 분석

100~300페이지 PDF에서 조항을 찾아 비교한다.

- **추천 조합** — LlamaParse premium / Docling으로 구조 보존 추출 → 청크 분할 → RAG

- **출처 표시 중요** — Docling JSON(페이지·좌표)로 citation 정확히

시나리오 C — 학술 논문 (arXiv, 학회지)

수식·표·참고문헌이 많은 PDF를 대량 처리한다.

- **추천** — Marker(수식 강함) 또는 Nougat(arXiv 한정)

- **이후** — LaTeX 보존된 마크다운으로 RAG / 검색 인덱스

시나리오 D — RAG ingestion 파이프라인 (잡식)

다양한 PDF가 매일 수백 개씩 들어와 검색 인덱스로 들어간다.

- **간단·빠르게** — Mistral OCR API + 자동 청크

- **자체 호스팅** — Docling + 자체 청크 정책

- **품질 우선·예산 여유** — LlamaParse premium

핵심 — **하나로 끝나는 도구는 없다.** 도메인이 잡식이면 폴백 체인을 짠다. 우선 Mistral OCR → 실패하면 Marker → 그래도 실패하면 LLM 멀티모달.

15장 · 우리 팀의 첫 파이프라인 만들기 — 구체 레시피

이론은 충분하다. 한 주 안에 PDF 1만 장을 마크다운으로 옮기는 파이프라인을 짠다고 치자. 단계는 다음과 같다.

1단계 — **샘플 100장으로 도메인 분포 파악.** 표가 많은가, 수식이 많은가, 비라틴 문자가 많은가, 손글씨가 있는가. 도메인이 잡식이면 한 도구로 안 풀린다는 사실을 먼저 받아들인다.

2단계 — **도구 2~3개로 같은 샘플 100장 처리.** 후보는 Mistral OCR, Marker, Docling, LlamaParse 중에서 도메인에 맞춰 2~3개. 인하우스 평가 스크립트로 GFM 표 정확도·헤딩 추출·수식 보존을 본다.

3단계 — **승자를 메인, 차점자를 폴백으로.** 메인 도구로 처리하고, 메인이 어떤 페이지에서 실패하면(블록 수 0, 표 깨짐, 신뢰도 낮음) 폴백으로 자동 재처리.

4단계 — **메타데이터를 일관되게 저장.** 마크다운 본문 + (페이지 번호, bbox, 도구 이름, 버전, 신뢰도) 메타데이터. 나중에 어떤 도구가 잘 했는지 비교하려면 이 메타가 있어야 한다.

5단계 — **LLM 추출은 별도 단계로.** OCR/파싱과 IE(필드 추출)는 분리한다. 추출은 Claude/GPT-4o/Gemini로 마크다운을 받아 JSON을 뱉는 구조. 모델 교체가 쉬워진다.

다이어그램으로 보면.

[PDF 1만장]

↓

[샘플링 100장]

↓

[Mistral OCR / Marker / Docling 동시 처리]

↓

[자체 평가 스크립트로 도구 선정]

↓

[메인 도구로 9,900장 처리 + 실패 시 폴백]

↓

[마크다운 + 메타데이터 저장]

↓

[필요 시 LLM으로 JSON 필드 추출]

↓

[벡터 인덱스 / DB]

이 순서를 거치면 일주일 안에 안정적인 파이프라인이 나온다.

에필로그 — 2026년의 문서 AI는 아직 더 갈 길이 있다

문서 AI는 이제 막 "사용 가능"의 문턱을 넘었다. 2024년만 해도 "PDF에서 표를 깨끗이 뽑는다"가 거의 불가능했는데, 2026년에는 Mistral OCR / Marker / Docling 어느 것을 써도 그럭저럭 된다. 1년 사이에 큰 변화다.

그래도 끝난 문제는 아니다.

- **장기 문서의 문맥** — 100페이지 계약서를 페이지별로 잘라 마크다운으로 옮긴 다음에도, "5조항이 12조항을 어떻게 수정하는가" 같은 cross-page 의미는 별개 문제다.

- **손글씨와 옛 문서** — Yomi-toku, NDL OCR 같은 특화 모델이 있지만, 일반 손글씨는 여전히 어렵다.

- **차트와 도면** — 막대그래프, 회로도, 의료 차트는 OCR이 아닌 다른 문제다. Florence-2, GPT-4o가 도전하지만 아직 미흡하다.

- **검증과 환각** — LLM/VLM 기반 OCR은 환각이 있다. 미션 크리티컬 도메인(법률·의료·금융)에서는 검증 레이어가 필수다.

도구 13개를 다 외울 필요는 없다. **단계로 쪼개고, 시나리오로 묶고, 도메인이 정하는 답을 받아들여라.** Mistral OCR이 청구서에서는 압도적이어도 학술 논문에서는 Marker에 진다. 그게 정상이다. 문서 AI에는 "한 방"이 없다.

참고 / References

- Mistral OCR 공식 발표 (March 2025): [https://mistral.ai/news/mistral-ocr](https://mistral.ai/news/mistral-ocr)

- Marker GitHub (Vik Paruchuri): [https://github.com/VikParuchuri/marker](https://github.com/VikParuchuri/marker)

- Surya GitHub: [https://github.com/VikParuchuri/surya](https://github.com/VikParuchuri/surya)

- LlamaParse (LlamaIndex): [https://docs.llamaindex.ai/en/stable/llama_cloud/llama_parse/](https://docs.llamaindex.ai/en/stable/llama_cloud/llama_parse/)

- Docling (IBM): [https://github.com/DS4SD/docling](https://github.com/DS4SD/docling)

- DocLayoutYOLO: [https://github.com/opendatalab/DocLayout-YOLO](https://github.com/opendatalab/DocLayout-YOLO)

- Nougat (Meta): [https://github.com/facebookresearch/nougat](https://github.com/facebookresearch/nougat)

- OlmoOCR (Allen AI, Feb 2025): [https://github.com/allenai/olmocr](https://github.com/allenai/olmocr)

- olmOCR 페이퍼: [https://arxiv.org/abs/2502.18443](https://arxiv.org/abs/2502.18443)

- Tesseract OCR: [https://github.com/tesseract-ocr/tesseract](https://github.com/tesseract-ocr/tesseract)

- LayoutLMv3 (Microsoft): [https://github.com/microsoft/unilm/tree/master/layoutlmv3](https://github.com/microsoft/unilm/tree/master/layoutlmv3)

- Donut (NAVER CLOVA AI): [https://github.com/clovaai/donut](https://github.com/clovaai/donut)

- Pixtral 12B (Mistral): [https://mistral.ai/news/pixtral-12b](https://mistral.ai/news/pixtral-12b)

- Florence-2 (Microsoft): [https://huggingface.co/microsoft/Florence-2-large](https://huggingface.co/microsoft/Florence-2-large)

- KOSMOS-2.5 (Microsoft): [https://arxiv.org/abs/2309.11419](https://arxiv.org/abs/2309.11419)

- 네이버 CLOVA OCR: [https://www.ncloud.com/product/aiService/ocr](https://www.ncloud.com/product/aiService/ocr)

- Yomi-toku: [https://github.com/kotaro-kinoshita/yomitoku](https://github.com/kotaro-kinoshita/yomitoku)

- Google Cloud Document AI: [https://cloud.google.com/document-ai](https://cloud.google.com/document-ai)

- Reducto: [https://reducto.ai/](https://reducto.ai/)

- Unstract: [https://github.com/Zipstack/unstract](https://github.com/Zipstack/unstract)

- PaddleOCR: [https://github.com/PaddlePaddle/PaddleOCR](https://github.com/PaddlePaddle/PaddleOCR)

- EasyOCR: [https://github.com/JaidedAI/EasyOCR](https://github.com/JaidedAI/EasyOCR)