스캔된 비즈니스 문서를 신뢰할 수 있는 구조화된 데이터(structured data)로 변환하는 것은 단일 모델의 문제가 아닙니다. 광학 문자 인식 (OCR)은 이미지 품질, 페이지 기하학 (geometry), 레이아웃 (layout), 표 (tables), 스키마 일관성 (schema consistency), 수치 검증 (numerical validation), 그리고 불확실한 결과들을 처리해야 하는 더 긴 시스템의 한 단계일 뿐입니다. 높은 OCR 점수만으로는 송장 번호, 제품 코드, 수량, 단가 또는 총액이 다운스트림 (downstream) 소프트웨어에서 신뢰될 수 있음을 보장하지 않습니다.

이러한 구분은 문서에 기밀 상업 정보가 포함되어 있어 외부 서비스로 전송할 수 없는 경우 특히 중요해집니다. 로컬 파이프라인 (local pipeline)은 일반적으로 여러 클라우드 서비스에 분산되어 있는 기능들, 즉 이미지 전처리 (image preprocessing), OCR, 레이아웃 해석 (layout interpretation), 구조화된 추출 (structured extraction), 검증 (validation), 관측 가능성 (observability), 그리고 인간의 검토 (human review) 기능을 제공해야 합니다. 그 결과물은 단순히 읽을 수 있는 텍스트여서는 안 됩니다. 문서의 픽셀에서 검증된 비즈니스 기록으로 이어지는, 추적 가능하고 측정 가능한 변환이어야 합니다.

로컬 우선 (Local-first)이란 통제된 로컬 실행이 기본 아키텍처임을 의미합니다. 호스팅된 스키마 매퍼 (schema mappers)나 멀티모달 (multimodal) API는 개인정보 보호, 계약 및 거버넌스 정책이 외부 처리를 명시적으로 허용하는 경우에만 선택적인 대안으로 남습니다.

따라서 효과적인 아키텍처는 OCR 출력을 최종 결과물이 아닌 중간 표현 (intermediate representation)으로 취급합니다.

모델을 선택하기 전에 목표 정의하기

모델 선택은 출력 계약 (output contract)에서 시작해야 합니다. 송장 처리 시스템의 경우, 해당 계약에는 문서 수준의 필드와 가변 길이의 품목 리스트 (line items) 컬렉션이 포함될 수 있습니다:

{
  "invoice_number": "INV-2026-0148",
  "invoice_date": "2026-06-15",
...

이 스키마는 엔지니어링 질문을 변화시킵니다. 목표는 더 이상 "어떤 OCR 엔진이 가장 깨끗한 전사 (transcript)를 생성하는가?"가 아닙니다. 대신 "어떤 파이프라인이 해당 값들을 검증하는 데 필요한 구조를 유지하면서, 모든 필수 필드에 대해 가장 정확한 값을 생성하는가?"가 됩니다.

그 차이가 벤치마크 설계를 결정합니다. 일반적인 리더보드(Leaderboard)에서 선택하기보다는, 동일한 대표 문서 세트에서 여러 OCR 엔진을 테스트해야 합니다. 벤치마크에는 깨끗한 스캔본, 흐릿한 페이지, 기울어진 문서, 압축된 이미지, 다양한 글꼴, 표(Table), 그리고 여러 페이지로 구성된 파일이 포함되어야 합니다. 만약 시스템이 하나 이상의 언어나 문자 집합을 처리해야 한다면, 해당 예시들도 벤치마크에 반드시 포함되어야 합니다.

일반적인 단락(Paragraph)에서 성능이 좋은 모델이 작은 제품 코드나 빽빽하게 채워진 표에서는 실패할 수 있습니다. 반대로 어떤 모델은 숫자, 읽기 순서(Reading order), 레이아웃(Layout)을 더 정확하게 보존하는 대신 산문(Prose)의 품질이 약간 떨어질 수도 있습니다. 올바른 선택은 애플리케이션의 필드(Field), 언어, 페이지 구조, 지연 시간(Latency) 요구 사항 및 하드웨어 제약 조건에 따라 달라집니다.

OCR 이전에 네이티브 문서(Native Documents) 경로 지정하기

모든 PDF에 대해 OCR을 기본 경로로 설정해서는 안 됩니다. 디지털로 생성된(Born-digital) PDF는 이미 문자 위치, 글꼴 정보, 페이지 좌표를 포함한 사용 가능한 텍스트 레이어(Text layer)를 가지고 있을 수 있습니다. 해당 페이지를 이미지로 렌더링하고 OCR을 실행하는 것은 이미 사용 가능한 정확한 텍스트를 버리는 것이며, 지연 시간과 계산 비용을 추가하고 피할 수 있는 인식 오류를 유발합니다.

문서 수집(Document intake) 단계에서는 먼저 콘텐츠가 어떻게 표현되어 있는지 결정해야 합니다:

문서 수집 (Document intake)
→ 파일 검증 (File validation)
→ 네이티브 텍스트 및 이미지 콘텐츠 탐지 (Native-text and image-content detection)
...

텍스트 레이어가 완전하고 가시적인 페이지와 일치하는 경우 네이티브 추출(Native extraction)을 우선시해야 합니다. 파서(Parser)는 파일 형식이 정보를 노출할 경우 문자 또는 스팬(Span) 좌표, 페이지 번호, 읽기 순서, 링크 및 표 구조를 유지해야 합니다. OCR은 스캔된 페이지, 임베디드 이미지(Embedded images), 사진으로 찍은 문서, 그리고 텍스트 레이어가 누락되었거나 사용할 수 없는 페이지에 여전히 적합합니다.

이 결정은 PDF가 기술적으로 텍스트 객체를 포함하고 있는지 여부에만 의존해서는 안 됩니다. 일부 스캔된 PDF에는 비어 있거나, 손상되었거나, 정렬이 잘못되었거나, 렌더링된 페이지와 일치하지 않는 숨겨진 OCR 레이어가 포함되어 있을 수 있습니다. 유용한 품질 신호는 다음과 같습니다:

• 추출 가능한 텍스트로 덮인 페이지의 비율 (Percentage of the page covered by extractable text)
• 제어 문자(control characters) 또는 대체 문자(replacement characters) 대비 읽기 가능한 문자의 비율 (Ratio of readable characters to control or replacement characters)
• 추출된 스팬(spans)과 가시적인 페이지 영역 간의 정렬 (Alignment between extracted spans and visible page regions)
• 하나의 커다란 이미지만 포함된 페이지의 존재 여부 (Presence of pages containing only one large image)
• 비논리적인 읽기 순서 또는 중복된 텍스트 (Implausible reading order or duplicated text)
• 네이티브 추출(native extraction)과 경량 OCR 샘플 간의 차이 (Difference between native extraction and a lightweight OCR sample)

하나의 파일에는 네이티브(native) 콘텐츠와 스캔된(scanned) 콘텐츠가 혼합될 수 있으므로, 라우팅(Routing)은 페이지 단위로 작동해야 합니다. 계약서는 디지털 페이지로 시작하여 스캔된 서명 부록을 포함할 수 있습니다. 송장(invoice) 패키지는 네이티브 송장 뒤에 사진으로 찍은 증빙 페이지가 이어질 수 있습니다. 각 페이지는 가장 저렴하고 신뢰할 수 있는 경로를 따라야 하며, 문서 수준의 순서(ordering)와 출처(provenance)는 안정적으로 유지되어야 합니다.

네이티브 파싱(Native parsing)은 PDF를 넘어 다른 형식에도 적용됩니다. DOCX, PPTX, XLSX는 구조화된 텍스트, 표, 관계(relationships)를 포함하고 있으며, 이는 렌더링 후 OCR로 다시 읽는 대신 소스 형식에서 직접 추출하는 것이 정상입니다. MinerU와 같은 시스템은 PDF, 이미지, Office 형식에 대한 문서 파싱 경로를 제공하며, 이는 왜 모델 라우팅 전에 파일 표현(file representation)을 먼저 감지해야 하는지를 잘 보여줍니다.

모든 경로는 공유된 중간 표현(intermediate representation)으로 정규화되어야 합니다. 증거가 네이티브 파서에서 왔든 OCR에서 왔든 관계없이, 다운스트림(downstream) 구성 요소는 일관된 페이지 ID, 텍스트 스팬(text spans), 표 구조, 가능한 경우 좌표, 소스 유형, 신뢰도(confidence), 그리고 출처(provenance)를 전달받아야 합니다. 이를 통해 스키마 매핑(schema mapping)과 검증(validation)을 원본 파일 형식으로부터 독립적으로 유지할 수 있습니다.

문서 OCR 시스템의 네 가지 계열

문서 추출 시스템은 애플리케이션에 의해 파이프라인의 어느 정도가 명시적으로 조립되는지에 따라 그룹화할 수 있습니다. 이 카테고리들은 영구적인 순위라기보다는 통합 패턴(integration patterns)을 설명합니다. 특정 라이브러리는 하나 이상의 카테고리에 해당하는 구성 요소들을 제공할 수도 있습니다.

아키텍처상의 차이점은 다음과 같이 요약할 수 있습니다:

고전적 OCR (Classical OCR)
Tesseract, EasyOCR, docTR, PP-OCRv5, MMOCR
→ 텍스트를 탐지하고 인식합니다.
...

이 차이점은 책임(Responsibility)에 관한 것입니다. 고전적 OCR은 저수준(Low-level)의 텍스트 증거를 노출하고 문서 구조는 애플리케이션의 몫으로 남겨둡니다. 모듈형 및 하이브리드 파이프라인(Modular and hybrid pipelines)은 구조, 인식, 관계, 표, 읽기 순서 단계를 노출하거나 내부적으로 조정합니다. 문서 특화 VLM(Document-specialized VLM) 또는 VLM 기반 툴킷은 이러한 파싱 경로의 대부분을 내부화하거나 오케스트레이션(Orchestrate)합니다. 범용 멀티모달 LLM(General multimodal LLM)은 더 넓은 추론과 유연한 스키마 생성 능력을 더해주지만, 오직 OCR만을 위해 특화된 것은 아닙니다.

제품 분류(Product Taxonomy) 참고 사항

표에 기재된 이름들이 모두 동일한 유형의 산출물(Artifact)을 지칭하는 것은 아닙니다.

• MonkeyOCR는 하이브리드 문서 파싱 아키텍처 (Hybrid document-parsing architecture)로 이해하는 것이 더 적절합니다. 이 모델의 구조-인식-관계 (Structure-Recognition-Relation) 패러다임은 콘텐츠가 어디에 위치하는지, 콘텐츠가 무엇인지, 그리고 블록들이 어떻게 연결되어 있는지를 분리하여 처리합니다. 따라서 이를 단순히 "전체 페이지를 하나의 거대한 VLM에 전송하는" 예시로 제시해서는 안 됩니다.
• dots.mocr은 dots OCR 제품군의 차세대 모델이며, dots.ocr은 이전 세대 모델로 식별할 수 있습니다. dots.mocr은 문서 파싱 (Document parsing), 웹 파싱 (Web parsing), 장면 탐지 (Scene spotting), SVG 생성 (SVG generation)을 위한 프롬프트 모드 (Prompt modes)를 제공하며 vLLM을 통해 서비스될 수 있습니다. 이러한 기능이 모든 임의의 비즈니스 JSON 스키마 (JSON Schema)를 기본적으로 강제한다는 의미는 아닙니다. "지원되는 경우"라는 조건부 규칙이 여전히 적용됩니다.
• olmOCR은 단순한 단일 모델 이름이라기보다 VLM 기반의 OCR 툴킷 (Toolkit)이자 파이프라인 (Pipeline)입니다. 주요 역할은 PDF 및 이미지 기반 문서를 자연스러운 읽기 순서에 따라 깨끗한 텍스트나 마크다운 (Markdown)으로 변환하는 것입니다. 직접적인 키-값 (Key-value) 비즈니스 JSON 추출이 기본 목적은 아니므로, 별도의 스키마 매핑 (Schema-mapping) 단계가 여전히 필요할 수 있습니다.
• MinerU는 단일 모델이라기보다 더 광범위한 문서 처리 시스템 (Document-processing system)입니다. 여기에는 네이티브 파싱 경로 (Native parsing paths), 클래식 파이프라인 (Classical pipeline) 및 VLM 백엔드 (Backends), API 서비스, 그리고 라우팅 구성 요소 (Routing components)가 포함됩니다. 모델 경로를 구체적으로 지칭할 때는 MinerU를 단일 엔드-투-엔드 (End-to-end) 모델로 취급하기보다 "MinerU2.5-Pro VLM 백엔드" 또는 "MinerU VLM 파이프라인"이라고 부르는 것이 더 정확합니다.
• Chandra OCR 2는 레이아웃을 보존하는 HTML, 마크다운 (Markdown), JSON을 생성할 수 있지만, 그 JSON 출력을 애플리케이션의 송장 (Invoice) 또는 계약서 스키마 (Contract schema)로 자동 간주해서는 안 됩니다. 출력된 계약 정보는 필요할 때 반드시 검증 및 매핑 과정을 거쳐야 합니다.

엄격한 로컬 시스템의 경우, 배포 정책(deployment policy)이 후보군을 좁힙니다. 소스 문서가 통제된 환경을 벗어나는 것이 금지된 경우, 호스팅된 멀티모달 API (multimodal API)를 사용할 수 없습니다. 이 경우 셀프 호스팅이 가능한 OCR 모델, 문서 VLM (document VLM), 또는 멀티모달 모델 (multimodal model)이 로컬에서 필요한 기능을 제공해야 합니다. 아키텍처 카테고리는 여전히 유용하지만, 데이터 정책은 강력한 선택 제약 조건이 됩니다.

제품군(Families)의 선택 및 조합

아키텍처는 하나의 OCR 모델이나 하나의 제품군에 영구적으로 결합되어서는 안 됩니다. 후보 모델들은 애플리케이션 전체에 내장된 가정 사항이 아니라, 안정적인 OCR 인터페이스 뒤에 있는 교체 가능한 구현체로 취급되어야 합니다.

각 제품군이 반드시 동일한 역할을 수행할 필요는 없습니다. 정확한 단어 박스(word boxes)와 효율적인 텍스트 인식(text recognition)이 우선순위일 때는 탐지 및 인식(detection-and-recognition) 파이프라인이 적합할 수 있습니다. 개별 단계가 독립적으로 조정, 검사 또는 교체되어야 하는 경우에는 모듈형 레이아웃(modular layout) 파이프라인이 선호될 수 있습니다. 문서 특화 VLM (document-specialized VLM)은 오케스트레이션(orchestration) 코드를 줄이면서 복잡한 표와 혼합된 레이아웃을 처리할 수 있습니다. 일반적인 멀티모달 LLM (multimodal LLM)은 배포 모델과 검증 리스크가 허용 가능한 범위 내에 있다면 직접적인 스키마 추출 (schema extraction)을 단순화할 수 있습니다.

모델 선택 매트릭스(model-selection matrix)는 최소한 다음 항목들을 비교해야 합니다:

• 필드 수준의 정확도 및 완전 일치 (exact match)
• 표(table) 및 읽기 순서(reading-order) 보존
• 흐릿하거나 기울어지거나 대비가 낮은 페이지에서의 품질
• 언어 및 문자 집합(character-set) 커버리지
• 경계 상자(bounding-box) 또는 레이아웃 출력 품질
• 환각(hallucination) 및 지원되지 않는 텍스트 비율
• 최대 이미지, 페이지 또는 문서 길이
• GPU 메모리, 지연 시간(latency), 처리량(throughput) 및 배치(batching) 동작
• 출력 형식 및 다운스트림 검증(downstream validation)의 용이성
• 로컬 배포, 라이선싱 및 데이터 거버넌스(data-governance) 제약 조건

문서 클래스마다 서로 다른 기본 모델을 사용할 수 있습니다. 텍스트 위주의 단순한 페이지는 전통적인 OCR 파이프라인 (classical OCR pipeline)을 사용할 수 있는 반면, 복잡한 표는 레이아웃 인식 파이프라인 (layout-aware pipeline) 또는 문서 VLM (document VLM)으로 라우팅될 수 있습니다. 신뢰도가 낮은 필드는 정밀 검증을 위해 두 번째 OCR 모델로 전송될 수 있습니다.

폴백 (Fallback)은 선택적으로 유지되어야 합니다. 모든 페이지를 모든 모델에 통과시키는 것은 지연 시간 (latency)을 증가시키고, 출력값이 일치하지 않을 때 중재 문제 (arbitration problem)를 야기합니다. 문서 유형, 레이아웃 복잡도, 필드 신뢰도, 스키마 검증 (schema validation) 및 비즈니스 규칙 실패 여부에 따라 다른 모델의 사용 정당성을 결정해야 합니다.

구조화된 추출 (structured-extraction) 계층은 OCR 구현으로부터 독립적으로 유지되어야 합니다. OCR은 증거를 탐지하고 인식하는 책임을 지며, 스키마 매핑 (schema-mapping) 모델은 데이터 정책에 따라 로컬에서 실행하거나 승인된 호스팅 서비스를 통해 실행할 수 있습니다. PP-OCRv5를 Chandra OCR 2, Unlimited-OCR 또는 모듈형 레이아웃 파이프라인으로 교체하더라도 검증, 검토 또는 비즈니스 로직을 다시 작성할 필요가 없어야 합니다.

구조화된 JSON 생성 경로 (Structured JSON Production Paths)

구조화된 JSON을 생성하는 것은 문서 텍스트를 인식하는 것과는 별개의 책임입니다. 올바른 경로는 어떤 모델 제품군 (model family)을 사용하는지, 그리고 해당 모델이 대상 스키마 (target schema)를 직접 따를 수 있는지에 따라 달라집니다.

경로 1: 전통적인 OCR 또는 레이아웃 파이프라인 후 스키마 매핑 수행

전통적인 OCR 및 모듈형 레이아웃 파이프라인은 일반적으로 최종 비즈니스 객체 (business object)보다는 증거 (evidence)를 생성합니다. 이 증거에는 텍스트, 단어 박스 (word boxes), 신뢰도 값 (confidence values), 표 셀 (table cells), 읽기 순서 (reading order), 영역 레이블 (region labels) 및 소스 좌표 (source coordinates)가 포함될 수 있습니다.