OpenDataLoader PDF 완전 해부: AI 시대, PDF 파싱의 새로운 표준

PDF, 30년간 풀리지 않은 문제

1993년, Adobe는 세상에 PDF(Portable Document Format)를 내놓았다. 목표는 간단했다. "어떤 기기에서든 동일하게 보이는 문서." 30년이 지난 지금, PDF는 그 약속을 완벽하게 지켰다. 전 세계에서 매일 수십억 개의 PDF가 생성되고, 법률 문서부터 학술 논문, 금융 보고서까지 — PDF는 디지털 문서의 사실상 표준이 되었다.

그런데 문제가 있다.

PDF는 "보여주기 위한" 포맷이지, "읽히기 위한" 포맷이 아니다.

PDF 파일의 내부를 열어보면, 거기에는 문단도 없고, 표도 없고, 제목 계층도 없다. 있는 것은 오직 "좌표 (x, y)에 글자 'ㅎ'을 그려라" 같은 드로잉 명령어뿐이다. 마치 캔버스에 페인트를 뿌린 것과 같다 — 사람 눈에는 아름다운 그림이지만, 컴퓨터에게는 의미 없는 점들의 나열이다.

이것이 왜 문제가 되는가?

2026년, AI의 시대가 왔기 때문이다.

왜 지금 PDF 파싱이 중요한가

RAG(Retrieval-Augmented Generation)가 엔터프라이즈 AI의 핵심 아키텍처로 자리잡았다. 기업의 내부 문서를 LLM에게 먹여서 정확한 답변을 얻겠다는 것이다. 그런데 기업 문서의 대부분은 무엇인가? PDF다.

문제는 여기서 시작된다. PDF에서 텍스트를 단순히 추출하면 이런 일이 벌어진다:

2단 칼럼으로 인쇄된 학술 논문에서 텍스트를 왼쪽에서 오른쪽으로 한 줄씩 읽으면, 두 칼럼의 내용이 뒤죽박죽 섞인다. 사람은 칼럼을 구분하지만, 단순 PDF 파서는 y좌표가 같은 텍스트를 한 줄로 이어붙인다.

이것은 빙산의 일각이다. PDF 파싱이 어려운 이유를 정리하면:

이런 문제들을 해결하기 위해 등장한 것이 바로 OpenDataLoader PDF다.

OpenDataLoader PDF란 무엇인가

OpenDataLoader PDF는 한컴(Hancom)이 주도하는 Apache 2.0 라이선스의 오픈소스 PDF 파서로, GitHub에서 11,000개 이상의 스타를 받으며 빠르게 성장하고 있다.

핵심 미션은 두 가지다:

기존 PDF 파서들과 비교해서 OpenDataLoader가 특별한 점은 무엇일까?

1. 로컬 우선(Local-first): GPU 없이, 네트워크 없이, 페이지당 0.05초. 민감한 문서도 안심하고 처리할 수 있다.
2. 바운딩 박스 제공: 모든 요소에 좌표([left, bottom, right, top])를 포함. RAG에서 "이 답변의 출처는 3페이지 두 번째 단락입니다"라고 정확히 인용할 수 있다.
3. AI 안전 필터: PDF에 숨겨진 프롬프트 인젝션 공격을 기본적으로 차단한다.
4. 하이브리드 모드: 단순한 페이지는 빠르게, 복잡한 표와 수식은 AI로 — 속도와 정확도를 모두 잡는다.

PDF의 역사: "보여주기"에서 "이해하기"로

OpenDataLoader의 아키텍처를 이해하려면, 먼저 PDF가 왜 이렇게 설계되었는지 알아야 한다.

1993-2000: PostScript의 후손

PDF는 Adobe의 페이지 기술 언어 PostScript에서 태어났다. PostScript는 프린터에게 "여기에 이 글자를 그려라"고 명령하는 언어였고, PDF는 이것을 화면용으로 최적화한 것이다. 핵심 설계 원칙은 "What You See Is What You Get (WYSIWYG)" — 어디서 열든 똑같이 보여야 한다.

이 원칙 때문에 PDF는 시각적 충실도(visual fidelity)에 모든 것을 걸었다. 문서의 의미(semantic)는 중요하지 않았다. "제목"이라는 개념은 없고, 단지 "24pt Bold 글씨"가 있을 뿐이다.

2001-2012: 태그드 PDF의 등장

2001년, PDF 1.4에서 Tagged PDF 스펙이 추가되었다. HTML의 <h1>, <table>, <p> 같은 의미론적 태그를 PDF에도 넣을 수 있게 된 것이다. 목표는 접근성(accessibility) — 시각 장애인이 스크린 리더로 PDF를 읽을 수 있도록 하는 것이었다.

하지만 현실은? 대부분의 PDF 제작 도구가 태그를 생성하지 않았다. 2026년 현재도 전 세계 PDF의 약 95%는 태그가 없는 "비접근성" 문서다.

2012-2020: OCR과 규칙 기반 파서

Tesseract OCR, PDFMiner, pdftotext 같은 도구들이 PDF에서 텍스트를 추출했지만, 구조(표, 제목, 읽기 순서)는 제대로 복원하지 못했다. 연구자들은 XY-Cut, Voronoi 다이어그램, 프로젝션 프로파일 같은 문서 레이아웃 분석(Document Layout Analysis) 알고리즘을 개발했지만, 실용적인 통합 도구는 부족했다.

2020-2026: AI와 문서 이해의 시대

LayoutLM(Microsoft, 2020), DocTR, Donut 같은 딥러닝 모델이 문서 이해 분야에 혁명을 일으켰다. 동시에 RAG의 폭발적 성장으로 "PDF → 구조화된 데이터" 파이프라인의 수요가 폭증했다.

그리고 2025년, 유럽 접근성법(European Accessibility Act, EAA)이 시행되면서, 모든 디지털 문서의 접근성이 법적 의무가 되었다. PDF 접근성은 더 이상 "하면 좋은 것"이 아니라 법적 요구사항이 되었다.

바로 이 시점에 OpenDataLoader PDF가 등장한다 — AI 데이터 추출과 접근성 자동화, 두 마리 토끼를 동시에 잡겠다는 야심찬 목표를 들고.

아키텍처 완전 해부

이제 OpenDataLoader PDF의 핵심 — 아키텍처를 깊이 파고들어 보자.

전체 아키텍처 개요

OpenDataLoader PDF의 아키텍처는 크게 세 층(layer)으로 나뉜다:

Java Core Engine이 핵심이다. 110만 줄의 Java 코드로 이루어진 이 엔진은 GPU 없이, 네트워크 없이, 순수하게 규칙과 휴리스틱만으로 PDF를 분석한다. Python과 Node.js SDK는 이 Java JAR를 서브프로세스로 실행하는 래퍼(wrapper) 패턴이다.

코드 구조 맵

opendataloader-pdf/
├── java/
│   └── opendataloader-pdf-core/          # 핵심 엔진
│       └── src/main/java/org/opendataloader/pdf/
│           ├── api/                       # 공개 API
│           ├── processors/               # 19개 프로세서 (파이프라인)
│           │   └── readingorder/         # XY-Cut++ 구현
│           ├── hybrid/                   # 하이브리드 AI 처리
│           ├── entities/                 # 수식, 이미지 등 엔티티
│           ├── json/                     # JSON 출력
│           ├── markdown/                 # Markdown 출력
│           ├── html/                     # HTML 출력
│           └── pdf/                      # 주석 PDF 출력
├── python/
│   ├── opendataloader-pdf/               # Python SDK (pip)
│   └── opendataloader-pdf-mcp/           # MCP 서버
├── node/opendataloader-pdf/              # Node.js SDK (npm)
└── content/docs/                         # 문서 사이트

프로세싱 파이프라인: 19개 프로세서의 오케스트라

PDF가 입력되면, 19개의 프로세서가 순서대로 실행되며 문서의 의미를 복원한다. 이것은 마치 고고학자가 깨진 도자기 조각들을 원래의 형태로 맞추는 과정과 같다.

이 파이프라인에서 가장 핵심적인 부분은 읽기 순서 복원과 표 구조 추출이다. 각각을 깊이 들여다보자.

핵심 알고리즘 #1: XY-Cut++ 읽기 순서 복원

왜 읽기 순서가 그토록 어려운가

당신이 2단 칼럼 논문을 읽을 때, 무의식적으로 하는 일을 생각해 보자:

1. 제목을 읽는다 (전체 폭)
2. 왼쪽 칼럼을 위에서 아래로 읽는다
3. 오른쪽 칼럼을 위에서 아래로 읽는다
4. 아래의 전체 폭 표를 읽는다

사람에게는 자연스러운 이 과정이, 컴퓨터에게는 풀리지 않는 퍼즐이다. PDF에는 "이것은 왼쪽 칼럼이고 저것은 오른쪽 칼럼이다"라는 정보가 없기 때문이다.

고전적 XY-Cut 알고리즘

XY-Cut은 1990년대에 제안된 문서 레이아웃 분석 알고리즘이다. 원리는 간단하다:

1. 모든 텍스트를 X축(가로)과 Y축(세로)에 투영한다
2. 투영 프로파일에서 가장 큰 빈 공간(gap)을 찾는다
3. 그 공간을 기준으로 페이지를 자른다 (X축 gap이면 세로 커팅, Y축 gap이면 가로 커팅)
4. 잘린 영역 각각에 대해 재귀적으로 반복한다

하지만 고전적 XY-Cut에는 치명적인 약점이 있다:

• 전체 폭 요소(제목, 캡션) 처리 불가: 2단 칼럼 사이에 전체 폭 제목이 있으면 칼럼 분리가 깨진다
• 밀도 적응 부재: 빽빽한 텍스트와 듬성듬성한 텍스트에 같은 전략을 적용

XY-Cut++: OpenDataLoader의 개선

OpenDataLoader의 XYCutPlusPlusSorter.java는 고전 XY-Cut에 두 가지 핵심 개선을 추가한다:

Phase 1: 크로스 레이아웃 감지 (Cross-Layout Detection)

먼저 전체 폭을 차지하는 요소를 식별한다. 제목, 전체 폭 캡션, 페이지 상단 헤더 등이 여기에 해당한다. 이 요소들은 칼럼 분리 전에 미리 추출되어 별도로 보관된다.

Phase 2: 밀도 적응 분석 (Density-Adaptive Analysis)

모든 문서가 같은 밀도를 가지지 않는다. 교과서의 빽빽한 본문과 프레젠테이션의 넓은 여백은 완전히 다른 전략이 필요하다.

Phase 3-4: 재귀 분할 + 병합

Phase 3에서 재귀 분할이 실행되고, Phase 4에서 Phase 1에서 분리해둔 크로스 레이아웃 요소가 원래 Y좌표 위치에 재삽입된다.

핵심 파라미터들:

이 알고리즘의 결과로, OpenDataLoader는 200개 벤치마크 PDF에서 NID 0.94라는 최고 읽기 순서 정확도를 달성했다.

핵심 알고리즘 #2: 표 구조 추출

PDF에서 표를 추출하는 것은 또 다른 난제다. PDF의 표는 사실 선(line)과 좌표에 배치된 텍스트의 조합이다. "이것은 3행 4열의 표이며, 첫 번째 행은 헤더입니다"라는 정보는 어디에도 없다.

OpenDataLoader는 세 가지 전략을 사용한다:

전략 1: 테두리 기반 분석 (Border-based)

PDF에 그려진 선(stroke)을 분석하여 표의 격자를 재구성한다. 가장 빠르고 정확하지만, 테두리 없는 표에서는 무력하다.

전략 2: 클러스터 기반 분석 (Cluster-based)

테두리가 없는 표를 위해, 텍스트의 위치 패턴을 분석한다. 같은 X좌표에 반복적으로 텍스트가 나타나면 → 칼럼이다. 같은 Y좌표에 반복적으로 텍스트가 나타나면 → 행이다.

전략 3: AI 하이브리드 분석

로컬 전략으로 처리가 어려운 복잡한 표(병합 셀이 많은 표, 불규칙한 레이아웃의 표)는 AI 백엔드로 전달한다.

TEDS(Tree Edit Distance Similarity)는 Zhong et al. (arXiv 1911.10683)이 제안한 표 구조 정확도 평가 지표로, 표의 DOM 트리 구조를 비교한다. 1.0이 완벽한 일치이다.

주목할 점: 하이브리드 모드는 로컬 only 대비 표 정확도를 0.49 → 0.93으로 거의 두 배 끌어올린다. 이것이 하이브리드 아키텍처가 존재하는 이유다.

하이브리드 아키텍처: 속도와 정확도의 균형

하이브리드 모드는 OpenDataLoader의 가장 혁신적인 아키텍처 설계다. 핵심 아이디어는 단순하다:

"모든 페이지에 AI를 쓸 필요는 없다. 단순한 페이지는 빠르게, 복잡한 페이지만 AI로."

5단계 하이브리드 파이프라인

Stage 1: 안전 필터링

모든 처리에 앞서, ContentFilterProcessor가 악의적인 콘텐츠를 제거한다. 이 단계는 뒤에서 자세히 다룬다.

Stage 2: 페이지 분류 (Triage)

TriageProcessor.triageAllPages()가 모든 페이지를 분석하여 세 가지로 분류한다:

여기서 주목할 것은 보수적 라우팅 전략(conservative routing strategy)이다. 불확실한 페이지를 로컬이 아닌 AI 백엔드로 보내서, 표를 놓치는 것(false negative)을 최소화한다. 속도보다 정확도를 우선시하는 설계 철학이다.

Stage 3a: Java 고속 경로

단순한 텍스트 페이지는 Java 엔진만으로 처리한다. 특징:

• 0.05초/페이지 (초당 20페이지 이상)
• 외부 의존성 없음 (GPU 없음, 네트워크 없음)
• 결정론적(deterministic) — 같은 입력에 항상 같은 출력
• XY-Cut++ 읽기 순서, 테두리 기반 표 추출, 제목/목록 감지

Stage 3b: AI 백엔드 경로

복잡한 페이지는 AI 백엔드로 전달된다. 현재 사용 가능한 백엔드는 docling-fast(로컬 docling-serve)이며, 다음이 계획되어 있다:

AI 백엔드가 제공하는 보강(enrichment) 기능:

• --force-ocr: 80개 이상 언어의 OCR (한국어, 일본어, 중국어 포함)
• --enrich-formula: 수식을 LaTeX로 변환
• --enrich-picture-description: SmolVLM(256M 파라미터) 모델로 차트/이미지를 자연어로 설명

Stage 4-5: 결과 병합 + 출력 생성

양쪽 경로의 결과가 원래 페이지 순서대로 병합되고, 사용자가 선택한 형식으로 출력된다:

• JSON: 바운딩 박스, 요소 ID, 메타데이터 전체 포함
• Markdown: LLM 입력에 최적
• HTML: 웹 렌더링용
• 주석 PDF: 감지된 구조를 원본 PDF 위에 오버레이
• Plain Text: 단순 텍스트

병렬 처리 아키텍처

성능을 위해 OpenDataLoader는 ForkJoinPool을 사용한 페이지 단위 병렬 처리를 수행한다. 사용 가능한 CPU 코어 수만큼 워커 스레드를 생성하고, 각 페이지를 독립적으로 처리한다.

여기서 흥미로운 기술적 세부사항이 있다: Java의 ThreadLocal 상태를 워커 스레드에 전파하기 위해 StaticLayoutContainers의 propagateState.run() 메커니즘을 사용한다. ThreadLocal은 스레드 간에 공유되지 않기 때문에, ForkJoinPool의 워커 스레드에 명시적으로 상태를 복사해야 하는 것이다.

AI 안전 필터: PDF 프롬프트 인젝션 방어

2026년, AI 보안의 새로운 위협이 주목받고 있다: PDF를 통한 프롬프트 인젝션(prompt injection).

공격 시나리오

당신이 RAG 시스템을 운영하고 있다고 가정하자. 누군가 악의적인 PDF를 업로드한다. 이 PDF에는 사람 눈에 보이지 않는 텍스트가 숨겨져 있다:

사람은 이 투명 텍스트를 볼 수 없지만, 기존 PDF 파서는 그대로 추출한다. 그리고 이 텍스트가 LLM의 컨텍스트에 들어가면... 프롬프트가 하이재킹된다.

8가지 공격 벡터

OpenDataLoader가 방어하는 공격 유형은 다음과 같다:

기본 활성화 필터

OpenDataLoader는 WCAG 접근성 휴리스틱에서 영감을 받은 분석으로, "사람이 볼 수 없는 것은 AI도 보지 않아야 한다"는 원칙을 구현한다:

신뢰할 수 있는 문서에서는 --content-safety-off hidden-text,off-page로 특정 필터를 비활성화할 수 있다.

PDF 접근성: 법적 의무가 된 보편적 접근

왜 PDF 접근성이 중요한가

2025년 6월, 유럽 접근성법(EAA)이 시행되었다. 미국의 ADA Section 508, 한국의 디지털 포용법과 함께, 이제 디지털 문서의 접근성은 법적 의무다.

접근성이란 무엇인가? 시각 장애인이 스크린 리더로 PDF를 읽을 수 있게 하는 것이다. 그러려면 PDF에 의미론적 태그(semantic tag)가 있어야 한다 — "이것은 제목이다", "이것은 표의 3행 2열이다", "이 이미지의 대체 텍스트는 이것이다"라고 알려주는 구조 정보.

문제는? 현존하는 PDF의 95%에 이 태그가 없다. 수동으로 태그를 추가하려면 100페이지 문서에 전문가 1명이 며칠이 걸린다.

OpenDataLoader의 접근성 4단계 파이프라인

특히 2단계 자동 태깅 엔진이 2026년 Q2에 Apache 2.0 라이선스로 공개될 예정이라는 점이 주목할 만하다. PDF Association과의 협력으로 Well-Tagged PDF 규격도 함께 개발 중이며, veraPDF와의 통합으로 PDF/A 및 PDF/UA 유효성 검증도 지원할 계획이다.

벤치마크: 숫자로 말한다

OpenDataLoader 팀은 200개 PDF, 7개 경쟁 도구를 대상으로 한 공개 벤치마크(opendataloader-bench)를 운영한다. 평가 지표는 세 가지다:

• NID (Normalized Indel Distance): 읽기 순서 정확도 — Chen et al. (MDEval, arXiv 2501.15000)
• TEDS (Tree Edit Distance Similarity): 표 구조 정확도 — Zhong et al. (arXiv 1911.10683)
• MHS (Heading Hierarchy Score): 제목 계층 정확도 — Pawlik & Augsten (APTED, arXiv 1201.0230)

종합 벤치마크 결과

세부 항목별 비교

이 벤치마크에서 읽어야 할 핵심 인사이트:

RAG 통합: 실전 사용법

OpenDataLoader PDF가 RAG 파이프라인의 첫 단계로 사용되는 구체적인 워크플로우를 살펴보자.

설치

# Python
pip install opendataloader-pdf

# Node.js
npm install @opendataloader/pdf

# LangChain 통합
pip install langchain-opendataloader-pdf

요구사항: Java 11 이상 필수. Python 3.10+, Node.js 20+.

기본 변환 (Python)

from opendataloader_pdf import convert

# PDF → JSON (바운딩 박스 포함)
result = convert("financial-report.pdf", format="json")

# PDF → Markdown (LLM 입력용)
result = convert("research-paper.pdf", format="markdown")

# 하이브리드 모드 (OCR + 표 AI)
result = convert(
    "scanned-document.pdf",
    format="json",
    hybrid_mode="full",
    force_ocr=True,
    ocr_lang=["ko", "en"]
)

청킹 전략

RAG에서 핵심은 PDF를 어떻게 청크(chunk)로 나누느냐이다. OpenDataLoader의 JSON 출력은 요소 단위로 구조화되어 있어, 네 가지 전략을 지원한다:

OpenDataLoader가 제공하는 바운딩 박스 덕분에, RAG 시스템은 답변 생성 시 "3페이지 두 번째 표"처럼 정확한 출처를 인용할 수 있다. 이것은 기업 환경에서 특히 중요하다 — "AI가 이 답변을 어디서 가져왔는지" 추적할 수 있기 때문이다.

JSON 출력 구조

OpenDataLoader의 JSON 출력은 다음과 같은 계층 구조를 가진다:

{
  "file name": "report.pdf",
  "number of pages": 42,
  "kids": [
    {
      "type": "heading",
      "heading level": 1,
      "content": "2025년 4분기 실적 보고",
      "page number": 1,
      "bounding box": [72, 680, 540, 720],
      "id": "h1_001"
    },
    {
      "type": "paragraph",
      "content": "매출은 전년 동기 대비 23% 증가...",
      "page number": 1,
      "bounding box": [72, 620, 540, 670],
      "font": "NanumGothic",
      "font size": 11
    },
    {
      "type": "table",
      "number of rows": 5,
      "number of columns": 4,
      "page number": 2,
      "bounding box": [72, 300, 540, 550],
      "kids": [
        { "type": "table-cell", "row": 0, "column": 0, "content": "분기" },
        { "type": "table-cell", "row": 0, "column": 1, "content": "매출" }
      ]
    }
  ]
}

모든 요소에 바운딩 박스([left, bottom, right, top], PDF 포인트 단위, 72pt = 1인치)와 고유 ID가 부여된다. 표는 previous table id / next table id로 크로스 페이지 표 연결도 지원한다.

MCP 서버로 AI 에이전트에 연결

pip install opendataloader-pdf-mcp

Claude Desktop, Claude Code, Cursor, Windsurf 등 MCP 호환 클라이언트에서 바로 사용할 수 있다. AI 에이전트가 직접 PDF를 파싱하고 구조화된 데이터를 가져올 수 있게 된다.

생태계와 파트너십

OpenDataLoader는 단독 프로젝트가 아니라 생태계를 구축하고 있다:

한컴(Hancom)이 프로젝트의 핵심 후원사이자 엔터프라이즈 솔루션 파트너다. 한컴의 Hancom Data Loader는 OpenDataLoader의 엔터프라이즈 확장으로, VLM(Vision-Language Model) 기반의 30개 이상 문서 요소 인식, HWP/HWPX 지원 등을 제공한다.

2026년, PDF 파싱의 미래

이미 출시된 것

• PDF 데이터 추출 엔진 (로컬 + 하이브리드)
• AI 안전 필터 (기본 활성)
• Tagged PDF 구조 추출
• OCR (80개 이상 언어)
• 수식/이미지 보강
• Apache 2.0 라이선스 (v2.0.0, 2026년 3월)

2026년 Q2 출시 예정

• 자동 태깅 엔진: 태그 없는 PDF에 자동으로 접근성 태그를 생성하는 오픈소스 엔진
• 구조 유효성 검증
• 목차(TOC) 추출
• veraPDF 통합

더 먼 미래

PDF 파싱 기술의 방향은 명확하다: 문서의 시각적 표현에서 의미론적 이해로의 전환. OpenDataLoader는 이 전환의 최전선에 서 있다.

2026년 현재, RAG가 엔터프라이즈 AI의 핵심이 된 시점에서, PDF 파싱의 품질은 곧 AI 답변의 품질을 결정한다. "Garbage in, garbage out" — 아무리 좋은 LLM도 잘못 추출된 데이터 위에서는 엉터리 답변을 내놓는다.

OpenDataLoader PDF는 이 문제에 대한 가장 체계적이고 완성도 높은 오픈소스 답변이다. 규칙 기반의 빠른 로컬 처리와 AI의 정확한 분석을 결합한 하이브리드 아키텍처, 프롬프트 인젝션을 방어하는 AI 안전 필터, 그리고 법적 요구사항이 된 접근성 자동화까지 — PDF라는 30년 된 포맷의 한계를 기술로 극복하고 있다.

참고 자료

• OpenDataLoader PDF GitHub: github.com/opendataloader-project/opendataloader-pdf
• 공식 문서: opendataloader.org
• 벤치마크 저장소: github.com/opendataloader-project/opendataloader-bench
• Chen et al., "MDEval: Evaluating Markdown Conversion", arXiv 2501.15000
• Zhong et al., "Image-based Table Recognition: TEDS", arXiv 1911.10683
• Pawlik & Augsten, "APTED: All Path Tree Edit Distance", arXiv 1201.0230
• PDF Association, "Well-Tagged PDF Specification" (개발 중)
• European Accessibility Act (EAA), Directive (EU) 2019/882