"RAG 핵심 학습 (2/26) — 문서 전처리와 PDF → Markdown 파이프라인"

1편에서 RAG의 5요소를 정리했다. 그 중 Knowledge Base를 실제로 만들 때, 가장 먼저 답해야 할 질문이 있다 — "원본 문서를 어떤 형태로 저장할 것인가?"

조직의 문서는 거의 모든 경우 PDF·HWP·DOCX·HTML·CSV의 혼합이다. 사람은 시각으로 읽을 수 있지만, LLM과 임베딩 모델은 텍스트와 구조가 보존된 단일 포맷이 필요하다. 그 단일 포맷이 Markdown이다. 본 편은 PDF → Markdown 변환을 책임지는 네 가지 라이브러리 — MarkItDown · Unstructured · Docling · LlamaParse — 를 동일 기준으로 비교한다. 마지막에 "어떤 코퍼스에 어떤 도구를 쓸 것인가"의 결정 매트릭스를 남긴다.


0. Prerequisites

본 편을 편하게 읽으려면 다음 두 가지면 충분하다.

  • Python 기본: 가상환경·pip·간단한 함수 정의.
  • 마크다운: #, ##, |...|...|, ``` 정도의 표준 문법.

PDF의 내부 구조(객체·스트림·텍스트 박스)는 알 필요 없다. 본 편은 결과물(마크다운)의 품질을 기준으로 도구를 평가한다.


1. 학습 목표

이 글이 끝나면 세 가지를 자신의 말로 설명할 수 있어야 한다.

  1. 왜 마크다운인가 — RAG의 Knowledge Base 형식 결정이 임베딩 품질청킹 가능성에 직접 영향을 준다.
  2. 네 도구의 강점 1줄 차이 — MarkItDown(MS) / Unstructured(범용) / Docling(IBM, 구조 보존) / LlamaParse(LLM 기반).
  3. 결정 매트릭스 5축 — 구조 보존, 표 추출, 이미지 처리, 라이선스, 운영 비용.

본 편의 결정은 Knowledge Base 한 번에 한 번 일어난다. 한번 잘못 정하면 코퍼스를 다시 만들어야 한다. 작은 결정이지만 비용이 크다.


2. 핵심 요약 — 한 단락 요약

PDF → Markdown 변환은 "텍스트만 뽑으면 끝"이 아니다. 제목 계층·표 구조·이미지 위치·코드 블록·각주가 보존되어야 청킹이 의미 단위로 잘리고, 임베딩이 좋은 신호를 받는다. MarkItDown은 Microsoft가 만든 경량 변환기로 빠르고 단순하나 표·복잡 레이아웃에는 약하다. Unstructured는 범용 파서로 여러 포맷을 일관된 element 트리로 정규화한다. Docling은 IBM이 만든 구조 보존 강화형으로 표·읽기 순서·수식까지 잡는다. LlamaParse는 LLM이 직접 PDF를 읽어 마크다운을 만든다 — 품질은 최고급이지만 비용·지연이 가장 크다. 선택은 코퍼스의 특성과 운영 예산이 좌우한다.


3. 직관 — 같은 PDF, 네 가지 결과

한 페이지의 PDF가 있다고 하자. 상단에 제목, 본문 두 단, 가운데에 표 하나, 하단에 그림과 캡션. 네 도구가 만들어 내는 마크다운의 형태는 이렇게 다르다.

  • MarkItDown: 텍스트가 상단부터 하단으로 직선으로 추출된다. 두 단 레이아웃이 섞이고, 표는 본문 사이에 들어간 한 줄 글이 된다. 빠르다.
  • Unstructured: 텍스트를 element(Title / NarrativeText / Table / Image)로 분리한다. 두 단 레이아웃이 각각 잡힌다. 표는 별도 element로 보존된다.
  • Docling: 읽기 순서가 두 단 사이를 왔다 갔다 하지 않게 정렬한다. 표는 마크다운 표로 변환된다. 수식·코드도 별도 블록.
  • LlamaParse: LLM이 시각으로 본 것처럼 페이지를 묘사해 마크다운을 만든다. 표는 거의 원본 그대로 재구성된다. 그러나 한 페이지당 LLM 호출 1회의 비용·지연이 붙는다.

같은 PDF가 다른 코퍼스가 되는 것이다. 임베딩이 본 신호가 도구마다 다르고, 그 차이는 retrieval 정확도에 직접 반영된다.

diagram-1

4. 정의 — 네 도구의 위치

도구 만든 곳 핵심 발상 라이선스
MarkItDown Microsoft 빠른 경량 변환기. 30+ 포맷을 마크다운으로 직선 추출 MIT
Unstructured unstructured.io 범용 element 트리 파서. 일관된 NarrativeText·Title·Table 구조 Apache 2.0 (오픈), 상용 API 별도
Docling IBM Research 구조 보존 강화. 읽기 순서·표·수식 재구성 MIT
LlamaParse LlamaIndex LLM 기반 시각 이해. PDF를 페이지 이미지로 읽음 상용 API, 무료 1000 페이지/일

네 도구는 같은 PDF에 대해 다른 결과물을 만든다. 같은 코퍼스라도 retrieval 정확도가 도구에 따라 5~20%p 차이 날 수 있다는 보고가 모인다(Docling 2024 기술 보고, LlamaParse 공개 벤치).

본 편이 답하는 핵심 질문은 "내 코퍼스에 맞는 도구는 어느 쪽인가"다. 그 답은 다섯 가지 축의 가중치로 결정된다.

  1. 구조 보존: 제목 계층·읽기 순서·문단 구분이 잘 살아 있는가.
  2. 표 추출: 표가 마크다운 표(또는 HTML)로 재구성되는가.
  3. 이미지 처리: 이미지 캡션·alt-text가 보존되는가, OCR이 함께 되는가.
  4. 라이선스: 오픈인가 상용인가, 데이터가 외부로 나가는가.
  5. 운영 비용: 페이지당 시간·비용. 정기 재색인 비용까지.

5. 표준 호출 형식

코드는 일부러 각 도구의 한 줄 호출만 둔다. 깊은 파이프라인은 라이브러리 공식 docs에 일관된 형태로 정리되어 있다.

from markitdown import MarkItDown
md_text = MarkItDown().convert("doc.pdf").text_content

from unstructured.partition.pdf import partition_pdf
elements = partition_pdf("doc.pdf")  # element 트리 반환

from docling.document_converter import DocumentConverter
doc = DocumentConverter().convert("doc.pdf").document
md_text = doc.export_to_markdown()

from llama_cloud_services import LlamaParse
documents = LlamaParse(result_type="markdown").load_data("doc.pdf")

네 호출 모두 입력은 PDF 경로 하나, 출력은 텍스트 또는 element 트리다. 동일 입력에 대한 출력의 형태와 품질이 본 편의 비교 대상이다.


6. 원리 워크스루 — 페이지 한 장이 마크다운이 되기까지

PDF 한 페이지에서 마크다운이 만들어지기까지의 일반 흐름은 여섯 단계다.

  1. 레이아웃 분석(Layout Analysis): 페이지의 블록(텍스트 박스·표·이미지)을 좌표와 함께 식별. 두 단·세 단 같은 컬럼 구조를 잡는다.
  2. 읽기 순서 결정(Reading Order): 사람이 읽는 순서로 블록을 정렬. 두 단 레이아웃에서 좌우를 섞지 않게 한다.
  3. 텍스트 추출(Text Extraction): 각 텍스트 블록의 문자를 원본 좌표 정렬로 뽑는다. 폰트·기울임·굵게는 마크다운 표기로 매핑.
  4. 표 추출(Table Detection): 표 블록을 행·열 구조로 복원. 단순 cell merge·다단 헤더가 잘 잡혀야 한다.
  5. 이미지 처리(Image Handling): 이미지에 캡션을 연결하고, 필요 시 OCR 또는 시각 모델로 alt-text를 생성.
  6. 마크다운 직렬화(Markdown Serialization): 위 정보를 제목·문단·표·이미지 링크의 마크다운 형식으로 출력.

네 도구는 어느 단계를 얼마나 깊이 처리하는가가 다르다.

  • MarkItDown은 1~3단계를 얇게 한다. 4·5단계는 거의 처리하지 않는다.
  • Unstructured는 1~5단계를 element 트리로 분리해 둔다. 마크다운 직렬화는 사용자 측 책임.
  • Docling은 1~6단계를 모두 한다. 표·읽기 순서·수식·코드 블록 보존이 강점.
  • LlamaParse는 1~6단계를 통째로 LLM에 맡긴다. 페이지를 이미지로 보고 마크다운을 합성한다. 비용·지연이 크지만 복잡 레이아웃에서 가장 잘 버틴다.

7. 변형과 사례 — 네 도구의 5블록

각 도구를 무엇이 바뀌나 → 왜 등장했나 → 무엇이 가능해졌나 → 어디에 적합한가 → 한계와 다음 단계로 본다.

7.1 MarkItDown — Microsoft 경량 변환기

  • 무엇이 바뀌나: 30+ 포맷을 한 줄로 마크다운으로. PDF·DOCX·PPTX·XLSX·이미지·오디오까지 일관 인터페이스.
  • 왜 등장했나: Microsoft가 내부 도구 통합용으로 경량 어댑터가 필요했다(2024-12 공개).
  • 무엇이 가능해졌나: POC·소규모 코퍼스를 몇 분 만에 마크다운으로 변환. CLI도 제공.
  • 어디에 적합한가: 단순 레이아웃의 사내 문서, 워드/파워포인트 위주, 검색 정확도보다 속도가 우선.
  • 한계와 다음 단계: 복잡 표·다단 레이아웃에서 텍스트가 섞인다. 이미지 caption 안 잡힘. → 표·읽기 순서가 중요하면 Docling 또는 LlamaParse.

7.2 Unstructured — 범용 element 트리

  • 무엇이 바뀌나: 변환의 출력 형식이 element 트리(Title, NarrativeText, Table, Image, ...). 마크다운은 사용자가 선택해서 직렬화.
  • 왜 등장했나: 청킹·임베딩 파이프라인이 일관된 의미 단위를 요구. element 트리가 그 단위.
  • 무엇이 가능해졌나: 단일 인터페이스로 PDF·HTML·DOCX·EML·CSV를 동일 element 트리로 통합. LangChain UnstructuredLoader로 표준 통합.
  • 어디에 적합한가: 포맷이 섞인 대규모 코퍼스. element 기반 청킹을 쓰고 싶을 때.
  • 한계와 다음 단계: 표 보존이 오픈소스 빌드에서는 약하다. 고품질 표 추출에는 상용 Unstructured API가 필요. → Docling 또는 LlamaParse 대체 가능.

7.3 Docling — IBM 구조 보존 강화

  • 무엇이 바뀌나: 표·수식·코드·읽기 순서를 깊이 처리한다. 표는 마크다운 또는 HTML로 셀 단위 재구성. 수식은 LaTeX 보존.
  • 왜 등장했나: IBM Research가 기업 문서(연구 보고서·재무 자료·정책)의 retrieval 품질을 끌어올리려고 만들었다(2024-08 v1 공개, 2024-11 v2).
  • 무엇이 가능해졌나: 복잡 표·수식·다단 레이아웃에서 원본 구조에 가까운 마크다운. 모델 가중치 포함 단일 패키지(docling-models).
  • 어디에 적합한가: 학술 논문, 재무 표, 다단 보고서, 기술 매뉴얼.
  • 한계와 다음 단계: 로컬 모델 호출로 페이지당 1~3초 정도. 100K 페이지 코퍼스 변환 시 수십 시간. → 배치 처리 + GPU 가속 필요. 또는 핵심 문서만 Docling, 나머지는 MarkItDown으로 분할 사용.

7.4 LlamaParse — LLM 기반 시각 이해

  • 무엇이 바뀌나: 페이지를 이미지로 만들어 LLM에 직접 보낸다. 마크다운은 LLM이 생성한다.
  • 왜 등장했나: 규칙 기반 파서가 복잡 차트·손그림·다국어 표에서 한계. LlamaIndex가 API 서비스로 출시(2024 초).
  • 무엇이 가능해졌나: 차트·다이어그램·필기 노트의 의미 보존. 표가 시각적으로 복잡해도 거의 그대로 재구성.
  • 어디에 적합한가: 고품질 retrieval이 필수이고, 비용을 감수할 수 있는 코퍼스. 법령, 의료 차트, 학술 도서.
  • 한계와 다음 단계: 페이지당 비용(현재 Premium은 페이지당 $0.045 + 부가, Balanced는 $0.003). 데이터가 외부 API로 나간다 — 사내 보안 요건과 충돌 가능. → 보안 요건이 강하면 Docling 자체 호스팅으로 대체. 비용이 부담이면 중요 문서만 LlamaParse.

8. 한계와 실패 양상

PDF 전처리에서 자주 만나는 다섯 실패. v3 5블록 — 왜 본질적인가 → 진단 → 완화 → 다음 단계.

8.1 두 단/다단 레이아웃 텍스트 섞임

  • 왜 본질적인가: PDF는 읽기 순서를 명시적으로 저장하지 않는다. 텍스트 박스는 좌표만 갖고, 사람이 좌→우→다음 단으로 읽는다는 정보는 추론해야 한다.
  • 진단: 변환 결과의 한 문장이 두 단 사이를 왔다 갔다 하면 본 현상 활성.
  • 완화: 읽기 순서를 잡는 도구로 교체(Docling), 또는 LlamaParse처럼 시각으로 처리.
  • 다음 편으로 연결: 4편 OCR과 레이아웃 분석.

8.2 표가 한 줄 텍스트로 무너짐

  • 왜 본질적인가: 표는 좌표 정렬로만 구성되어 있고, 셀 경계는 시각적 선에 의존한다. 셀 경계가 약한 표(공백 정렬, 색 배경)는 텍스트 추출 시 한 줄이 된다.
  • 진단: 마크다운 결과에 파이프(|)가 거의 없거나, 한 줄에 셀 값들이 공백으로 늘어선 형태가 보이면 표 추출 실패.
  • 완화: Docling/LlamaParse 사용, 또는 표만 따로 OCR 표 인식(AWS Textract Table Extraction, Azure DI). 4편에서 다시.
  • 다음 편으로 연결: 4편 OCR & 레이아웃, 6편 Contextual Chunking.

8.3 이미지 정보 손실

  • 왜 본질적인가: 그림·다이어그램·스크린샷은 텍스트 형태가 아니다. 임베딩은 이미지를 인덱싱하지 못한다(별도 vision embedding 없이는).
  • 진단: 변환 결과에 이미지 캡션이나 alt-text가 거의 없고, 본문이 "그림 3 참조"라고만 적혀 있는데 그림 정보가 없음.
  • 완화: LlamaParse 또는 Vision LLM으로 이미지 caption 자동 생성. Docling은 이미지 영역 추출만 한다.
  • 다음 편으로 연결: 4편 OCR (table·image), 8편 임베딩 (multimodal embedding 일부).

8.4 한국어 / CJK 텍스트 깨짐

  • 왜 본질적인가: PDF의 폰트 매핑이 부정확하면 한국어·중국어·일본어 글자가 유니코드 미할당으로 출력되거나 깨진 글자가 된다. 특히 임베디드 폰트 없이 사용된 PDF에서 자주.
  • 진단: 변환 결과에 물음표 모양(?) 또는 유니코드 사각형()이 보임.
  • 완화: PDF 자체를 OCR로 다시 처리(Tesseract, PaddleOCR). 또는 LlamaParse처럼 이미지에서 다시 읽기.
  • 다음 편으로 연결: 4편 OCR.

8.5 비용·지연 누적

  • 왜 본질적인가: 1만 페이지 코퍼스를 LlamaParse Premium으로 처리하면 약 $450 + LLM 호출 시간. Docling 로컬은 비용 0에 가깝지만 수십 시간. MarkItDown은 분 단위. 도구 선택이 전체 KB 구축 비용을 좌우한다.
  • 진단: KB 재색인 1회 비용·시간을 추정. 6개월에 한 번 재색인할 수 있는지 확인.
  • 완화: 문서 등급화 — 핵심 자료는 LlamaParse, 보조 자료는 MarkItDown. 또는 증분 색인(Δ 변경분만 재처리).
  • 다음 편으로 연결: 25편 권한·재색인 운영.

8.5 Common Pitfalls

  • "파서 하나로 모든 문서 처리" — 비용·시간이 폭주한다. 코퍼스를 등급화해 도구를 섞는다.
  • "OCR은 PDF가 스캔본일 때만 필요하다" — 한국어 PDF는 디지털 PDF도 폰트 매핑 깨짐이 잦다. 의심되면 OCR 백업.
  • "마크다운 변환 후 바로 청킹" — 표가 한 줄로 무너진 상태로 청킹하면 표 의미가 영원히 손실. 변환 결과를 샘플링 검증하고 청킹에 들어간다.
  • "LlamaParse는 무조건 좋다" — 데이터가 외부 API로 나간다. 사내 보안 요건과 충돌. 라이선스·DPA 확인.
  • "한 번 변환한 KB는 영원하다" — 도구가 업데이트되고 임베딩 모델이 바뀌면 재색인이 필요하다. 25편 참고.

9. 정리된 결론

Q1. 네 도구의 강점을 한 줄씩 말해 보라.

정답: - MarkItDown — 빠른 경량 변환기(MS, 30+ 포맷). - Unstructured — 범용 element 트리 파서(일관 의미 단위). - Docling — 구조 보존 강화(표·읽기 순서·수식). - LlamaParse — LLM 시각 이해(복잡 레이아웃 최고 품질, 비용 큼).

근거: 4장 도구 비교 표, 7장 5블록. 본문 챕터: 4장, §7.

Q2. 결정 매트릭스의 5축은 무엇인가.

정답: 구조 보존 / 표 추출 / 이미지 처리 / 라이선스 / 운영 비용. 근거: 같은 코퍼스라도 도구 선택에 따라 retrieval 정확도가 5~20%p 차이 날 수 있다(4장 보고). 본문 챕터: §4.

Q3. 두 단 PDF에서 텍스트가 섞이는 실패의 본질은 무엇인가.

정답: PDF가 읽기 순서를 명시적으로 저장하지 않기 때문. 텍스트 박스는 좌표만 가지며, 좌→우→다음 단의 순서를 추론해야 한다. 근거: 6장 1·2단계, 8.1절. 본문 챕터: 8.1절.

Q4. LlamaParse를 쓰는 게 맞는 경우 2가지는?

정답: ① 데이터가 외부 API로 나가면 안 되는 사내 보안 코퍼스. ② 페이지 수가 매우 많아 비용이 RAG 전체 예산을 깨는 경우. 근거: 7.4절 한계, 8.5절. 본문 챕터: 7.4절, 8.5절.

Q5. 한국어 PDF에서 물음표 모양이 나올 때 가장 먼저 의심해야 할 것은?

정답: PDF의 폰트 매핑 깨짐. 임베디드 폰트가 없거나 잘못 매핑된 디지털 PDF일 가능성. 근거: 8.4절. 완화책은 OCR로 다시 읽기. 본문 챕터: 8.4절.


10. 추가 학습

1차 자료

  • Docling Team. Docling Technical Report. IBM Research, 2024. arXiv:2408.09869
  • Auer, C. et al. DocLayNet: A Large Human-Annotated Dataset for Document-Layout Analysis. KDD 2022.
  • LlamaParse benchmarks (LlamaIndex blog, 2024-04 / 2024-09 업데이트).
  • Unstructured.io technical whitepaper (2024).

공식 docs

  • MarkItDown: https://github.com/microsoft/markitdown
  • Unstructured: https://docs.unstructured.io/
  • Docling: https://github.com/DS4SD/docling
  • LlamaParse: https://docs.cloud.llamaindex.ai/llamaparse/getting_started

보조 자료

  • 사용자 노트 2장·3장·4장 — PDF 전처리 핵심.
  • LangChain Document Loaders: https://python.langchain.com/docs/integrations/document_loaders/

Cheat Sheet

도구 라이선스 강점 약점 적합 코퍼스
MarkItDown MIT 빠름, 30+ 포맷 표·다단 약함 단순 사내 문서
Unstructured Apache 2.0 element 트리 일관 표 정확도(오픈) 포맷 섞인 대규모
Docling MIT 구조 보존, 수식 처리 시간 길음 학술·재무·기술
LlamaParse 상용 API 최고 품질 비용·데이터 외부 복잡 레이아웃 핵심 자료

Bridge — 다음 편

다음 — RAG 핵심 학습 (3/26) Ingestion 설계: 문서 경계·Model-aware Schema·Filter-first Retrieval.

문서를 마크다운으로 바꾼 다음, 어디서 찾을 것인가를 먼저 정해야 한다. 같은 벡터 공간에 정책·교육·회의록을 섞으면 retrieval이 무너진다. 3편은 사용자 노트 35장의 핵심을 한 자리에서 풀어낸다 — Whole-document Retrieval, Model-aware Ingestion, Title-Body Schema, Document Boundary, Filter-first Retrieval의 6단계 워크플로.

시리즈 전체 안내: 시리즈 목차

댓글

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"