Docling이란? PDF에서 글자를 뽑는 것과 문서 구조를 읽는 것의 차이

문단 블록과 빈 표가 있는 종이 위에 든 반투명 시트. 이해를 돕기 위한 AI 생성 개념 이미지입니다.

PDF를 텍스트로 바꿨는데 두 단의 문장이 번갈아 섞이면, 글자는 읽었어도 문서를 제대로 읽은 것은 아닙니다. 표의 수량과 품명이 서로 다른 행에 붙는 문제도 문자 인식만으로 설명하기 어렵습니다.

PDF 변환 도구는 글자 수보다 읽기 순서와 표의 행·열 대응으로 비교하세요.

OCR 뒤에도 문서 해석이 남습니다

Docling 공식 소개는 PDF를 포함한 여러 문서 형식을 처리하고 생성형 AI 도구와 연결하는 기능을 설명합니다. 스캔에서 문자를 인식하는 OCR뿐 아니라 페이지 배치와 문서 구조를 다루는 점을 함께 봐야 합니다.

스캔 PDF는 이미지에서 글자를 읽어야 하고, 텍스트가 들어 있는 PDF도 읽기 순서와 표 구조를 해석해야 할 수 있습니다. Docling은 OCR과 PDF 레이아웃·표 이해를 별도 기능으로 제공하므로, 어떤 입력에 어떤 파이프라인을 켰는지 기록해야 합니다. 문자가 추출됐다는 결과와 사람이 읽는 순서대로 내용이 보존됐다는 결과는 다릅니다.

최소 변환 경로부터 결과를 확인합니다

공식 Python 예시는 DocumentConverter로 변환한 뒤 DoclingDocument를 Markdown으로 내보내는 흐름입니다.

from docling.document_converter import DocumentConverter

converter = DocumentConverter()
result = converter.convert("report.pdf")
doc = result.document
markdown = doc.export_to_markdown()
structured = doc.export_to_dict()

markdown은 사람이 읽거나 RAG 입력으로 다루기 편한 전달 형식이고, structured는 표·계층·위치·provenance를 후속 검수에 활용할 수 있는 구조 표현입니다. 실제 파일이 스캔됐거나 복잡한 표라면 변환 성공 객체가 나왔다는 것만으로 품질을 보장하지 않으므로, 페이지별 상태와 원문 대조를 함께 확인합니다.

같은 숫자가 다른 의미가 되는 경우

가상의 제품 표를 보겠습니다.

제품	수량	단위
유리컵	12	개
받침	3	묶음

변환 결과에 “유리컵 받침 12 3 개 묶음”이라는 문자열이 모두 남아 있어도, 프로그램이 제품과 수량을 안정적으로 연결하기 어렵습니다. 문자 누락이 없다는 검사는 통과하지만 표 추출로는 부족합니다.

병합 셀이 있는 표에서는 빈 칸이 위 행과 같은 범주를 의미할 수 있습니다. 이를 모두 빈 문자열로 보관할지, 의미를 보존해 별도 필드로 풀지 정해야 합니다. 숫자를 보정해서 그럴듯한 표를 만드는 것과 원문 구조를 보존하는 것은 다른 작업입니다.

DoclingDocument에는 텍스트 이상의 구조가 들어갑니다

DoclingDocument 설명은 텍스트, 표, 그림과 문서 계층, 위치에 관한 정보를 통합하는 문서 표현을 소개합니다. 변환 결과를 Markdown만 저장하면 이런 정보 일부를 후속 단계에서 사용하기 어려울 수 있습니다.

검색용이라면 사람이 읽는 Markdown과 함께 구조화된 원본 변환 결과를 남기는 방식을 검토할 수 있습니다. 이후 잘못 검색된 문단이 어느 페이지의 어느 블록이었는지 돌아가 확인할 수 있기 때문입니다. 출력 형식은 최종 목적에 맞춰 선택해야 하며, 모든 형식을 중복 보관하라는 뜻은 아닙니다.

비교 샘플은 서로 다르게 고릅니다

일반 문단 한 페이지만 넣으면 차이를 보기 어렵습니다. 두 단 문서, 병합 셀 표, 각주가 있는 페이지, 흐린 스캔을 각각 준비합니다. 공개 자료나 직접 만든 예시로 다음을 확인할 수 있습니다.

• 본문 읽기 순서가 시각적 순서와 같은가.
• 표의 행·열·단위가 원문과 대응하는가.
• 반복 머리글이 본문 중간에 섞이지 않는가.
• 원문 위치로 되돌아갈 단서가 남는가.

문제 있는 부분은 후처리로 숨기기 전에 원문과 나란히 보세요. 추출 오류를 요약 모델이 자연스럽게 이어 쓰면 오히려 발견하기 어려워질 수 있습니다.

변환 결과를 세 층으로 보관할 수 있습니다

문서 파이프라인을 설계할 때 결과 하나만 남기기보다 목적에 따라 층을 나눌 수 있습니다.

층	담는 것	사용 목적
원본	입력 PDF와 파일 해시	재현과 원문 확인
구조 표현	텍스트·표·그림·계층·위치	검색·검수·다른 형식 변환
전달 형식	Markdown, JSON, HTML 등	사람 읽기 또는 후속 시스템 입력

Markdown이 사람이 읽기 편해도 모든 위치와 표 구조를 보존하지 못할 수 있습니다. Docling 문서는 JSON을 손실 없이 직렬화할 수 있는 구조 표현으로, Markdown과 HTML은 일부 메타데이터를 담지 못하는 전달 형식으로 설명합니다. 반대로 구조화된 JSON만 남기면 일반 검토가 불편할 수 있습니다. 최종 목적이 RAG라면 청크 텍스트와 함께 원본 페이지·블록 식별자를 유지해 검색 결과에서 원문으로 돌아갈 수 있게 하는 편이 좋습니다.

원본 파일을 보관할 수 없는 정책이라면 해시와 문서 버전, 변환 옵션, 검수 기록을 남기는 대안을 설계해야 합니다. 이 표는 Docling의 필수 저장 형식이 아니라 재현 가능한 파이프라인을 위한 운영 예시입니다.

표 추출은 셀 단위 계약으로 검사합니다

가상의 제품 표에서 문자열이 모두 추출됐는지만 세지 않습니다. 다음처럼 셀의 좌표와 의미를 확인합니다.

{
  "table_id": "page-3-table-1",
  "headers": ["제품", "수량", "단위"],
  "rows": [
    ["유리컵", "12", "개"],
    ["받침", "3", "묶음"]
  ],
  "source_page": 3
}

검수에서는 “유리컵=12=개”와 “받침=3=묶음”의 연결이 원문과 같은지 봅니다. Docling의 PDF 표 처리에는 구조 인식 결과를 PDF의 원래 셀에 맞출지 선택하는 옵션이 있고, 어려운 표에서는 빠른 모드와 정확도 중심 모드의 선택도 처리 시간과 품질의 교환이 됩니다. 병합 셀, 여러 줄 머리글, 페이지를 넘긴 표에서는 좌표만으로 의미가 충분하지 않을 수 있으므로 별도 예외를 남깁니다. 확신할 수 없는 셀을 그럴듯하게 채우기보다 원문 확인이 필요한 상태로 표시합니다.

RAG에 넣기 전 청크 경계를 확인합니다

문서 구조를 읽은 뒤 다시 고정 글자 수로만 잘라버리면 제목과 본문, 표와 설명이 분리될 수 있습니다. 구조 기반 청크를 검토할 때는 다음을 봅니다.

• 제목 계층이 하위 문단과 함께 유지되는가.
• 표의 제목·열 이름·단위가 행과 함께 들어가는가.
• 머리글·바닥글이 모든 청크에 반복되지 않는가.
• 각 청크에서 원본 페이지와 블록으로 돌아갈 수 있는가.
• 그림 캡션이 관련 그림 또는 문단과 연결되는가.

검색 답변이 틀렸을 때 추출, 구조화, 청크, 검색, 생성 가운데 어느 단계의 문제인지 구분하려면 중간 산출물을 남겨야 합니다. 최종 Markdown만 보고는 표가 원래 잘못 읽힌 것인지 청크에서 잘린 것인지 판단하기 어렵습니다.

작은 비교 세트와 판정표

샘플	통과 기준	대표 실패
일반 단일 단락	문장 순서 유지	줄 순서 뒤집힘
두 단 페이지	왼쪽 단 뒤 오른쪽 단	단 사이 문장 교차
병합 셀 표	범주와 하위 행 대응	빈 셀로 의미 손실
각주 문서	본문과 각주 구분·연결	각주가 본문 중간에 삽입
흐린 스캔	낮은 확신과 원문 위치 표시	숫자를 임의 보정
반복 머리글	본문 청크에서 제거 또는 표시	모든 페이지에 중복

글자 수나 처리 성공 여부 하나로 도구를 고르지 않습니다. 문서 유형별로 읽기 순서, 표 대응, 원문 추적, 처리 시간과 실패 상태를 기록합니다. OCR 정확도를 말하려면 별도의 정답 전사본과 문자·단어 단위 지표가 필요하며, 이 글은 그런 실측을 하지 않았습니다.

도구 선택의 경계

2026년 9월 7일의 공식 소개와 문서 표현 설명을 바탕으로 작성했습니다. 한국어 OCR 정확도나 다른 도구 대비 우위는 측정하지 않았습니다. 원격 서비스나 외부 모델을 붙인 구성까지 모두 로컬 처리라고 가정하지 말고, 실제 선택한 파이프라인을 확인해야 합니다.