EN
CASE 04Fruition / PDF 문서 변환, 데이터 파이프라인

PDF → Markdown 변환 - 복원율 약 90% 달성

주로 PDF로 제공되는 논문을 지식으로 활용하려면, Markdown으로 변환할 때 표의 수치와 수식이 먼저 보존돼야 했습니다. 이를 위해 변환 결과를 AI로 고치는 과정에서 생기는 누락을 추적하고, 원본 배치와 내용 유형에 맞춰 처리 경로를 나눴습니다.

45.17%기존 Docling
89.89%개선 파이프라인

2026.07 — 2026.09

PDF 변환 오픈 소스 : AnyDoc, DoclingLLM APIsLLM (Qwen2.5 7B)PythonLLM-as-a-Judge

01 배경

핵심 타겟층인 대학원생들이 주로 활용하는 논문은 PDF로 제공됐습니다. PDF를 지식으로 활용하기 위해 Markdown으로 변환하는 오픈소스를 사용해 봤으나, 표의 행 및 열 관계와 수식이 손상됐습니다.

해결하면 얻는 것

PDF의 복원률이 떨어져 핵심 수치가 누락되면 문서가 Wiki에 온전히 편입되지 못하고, 사용자는 질이 낮은 서비스를 받게 됩니다. 이로 인해 사용자가 이탈할 수 있다고 생각했습니다.

02 실험과 개선 과정

  1. 손상 영역 선택 복원과 탐지 누락 확인

    문제 상황 오픈소스를 통한 변환으로는 표의 행 및 열 관계와 수식이 깨져, PDF 논문의 핵심 수치를 Wiki에 편입하기 어렵게 추출됐습니다. 손상된 부분들을 복원할 방법이 필요했습니다.

    시도와 결과 Docling으로 구조를 뽑고 손상된 표와 수식만 로컬 Qwen sLLM으로 복원했습니다. 표는 비전 모델, 수식은 텍스트 모델로 나눠 두 모델을 모두 쓸 때보다 복원율을 높이고 sLLM 처리 시간을 약 42% 줄였습니다. sLLM이 고친 96개 중 85개는 통과했지만, 손대지 않은 쪽에 오류와 누락이 107개 남아 있었습니다. OCR 대조를 더하면 통과율을 80.00%에서 97.53%로 높일 수 있었지만, 멀쩡한 내용 50개까지 고칠 대상으로 골랐고 처리 시간은 약 12분 35초였습니다.

    판단 고칠 곳을 고르는 단계부터 오류를 놓쳤고, 이를 메우는 검사에도 비용이 들었습니다. 그래서 원본 페이지 전체를 비전 sLLM이 읽게 하는 방식을 다음으로 검토했습니다.

  2. 전체 페이지 sLLM 변환의 표 및 수식 오류와 비용 확인

    문제 상황 고칠 곳을 ai가 판단하는 방식은 오류를 놓쳤고, OCR 대조를 더하면 정상적인 내용까지 고르면서 검사 시간과 비용이 늘었습니다. 손상된 부분만을 적절히 골라 처리하도록 하는 방법을 모색해야 했습니다.

    시도와 결과 논문 PDF 25개(415쪽)를 비전 sLLM으로 통째로 처리했습니다. 내용 보존 통과율은 91.92%였지만 표 및 수식의 값과 구조가 모두 맞은 비율은 58.84%에 그쳤고, 모든 페이지를 처리하는 부담도 컸습니다.

    판단 모든 내용을 같은 방식으로 모델에 맡긴 게 문제라고 판단했습니다. 본문은 필요한 곳에만 AI를 쓰고, 표와 수식은 각자의 구조를 살릴 수 있는 입력을 줘야겠다고 생각했습니다. 그래서 본문, 표, 수식의 경로를 나누고, 본문은 빠르게 뽑으면서 필요한 곳만 AI로 고칠 방법을 모색했습니다.

  3. 본문 추출 비교, AnyDoc 적용과 상용 API 전환

    문제 상황 페이지 전체를 sLLM으로 돌려도 표와 수식 오류가 남았고, 본문까지 전부 모델에 보내는 부담이 컸습니다. 이 부담을 줄여 처리 시간과 정확도를 향상시키고자, 주로 손상되는 표와 수식은 따로 복원하고, 본문은 빠르게 뽑을 방법이 필요했습니다.

    시도와 결과 Threads에서 알게 된 PDF 변환 도구 AnyDoc을, GitHub의 Docling 대비 평가 결과를 보고 기존 실험의 PDF 4개(30쪽)로 비교했습니다. AnyDoc의 텍스트 추출은 1.68초로, OCR과 표 분석까지 포함한 Docling 기록 134.19초보다 약 80배 짧았습니다. 다만 한 문서는 PDF 안에 글자 코드를 실제 문자로 잇는 정보가 없어 글자가 깨졌습니다.

    판단 처리 범위가 달라 전체 변환이 80배 빨라졌다고 볼 수는 없지만, 본문 추출이 빠르다는 점 때문에 AnyDoc을 본문에만 쓰기로 했습니다. 표와 수식 복원은 유지하고, 글자가 깨지거나 읽는 순서가 섞인 페이지는 AI로 보완했으며, 그림은 원본을 살렸습니다. 또 초기 사용자가 없는 단계에서는 GPU 서버로 sLLM을 운영하는 비용이 더 커, 복원 모델을 상용 LLM API로 바꿨습니다.

03 개선한 처리 흐름

ARCHITECTUREMermaid diagram
flowchart TD
 A[원본 PDF] --> B[본문, 표, 수식, 그림 구분]
 B --> C[본문 문맥과 위치 보존]
 B --> D[표와 수식 원본 영역을 AI로 판독]
 B --> E[그림 원본 보존]
 C --> F[원래 순서로 조립]
 D --> F
 E --> F
 F --> G{위치 표시와 누락 검사}
 G -->|정상| H[변환 문서]
 G -->|불일치| I[해당 부분 원문 유지]

정보 유형에 따라 처리하고 원래 위치에 합치는 개념도입니다. 이는 현재 개념도이며, 모든 실험이 동일한 경로를 사용한 것은 아닙니다.

Mermaid 원문 보기
flowchart TD
 A[원본 PDF] --> B[본문, 표, 수식, 그림 구분]
 B --> C[본문 문맥과 위치 보존]
 B --> D[표와 수식 원본 영역을 AI로 판독]
 B --> E[그림 원본 보존]
 C --> F[원래 순서로 조립]
 D --> F
 E --> F
 F --> G{위치 표시와 누락 검사}
 G -->|정상| H[변환 문서]
 G -->|불일치| I[해당 부분 원문 유지]

04 결과와 배운 점

30페이지 원문 대조에서 실사용 기준 통과율 45.17% → 89.89%

기존 Docling과 개선한 파이프라인을 같은 논문의 본문, 표, 수식 등을 445개 평가 단위로 나눠 원문과 대조하는 방식으로 평가했습니다. 실사용 기준 통과율을 201개(45.17%)에서 400개(89.89%)로, 값과 기호까지 똑같아야 하는 엄격 기준을 193개(43.37%)에서 393개(88.31%)로 높였습니다.

기존 Docling45.17%총 30페이지
개선 파이프라인89.89%총 30페이지
결과의 범위와 트레이드오프

PDF 4개(30쪽)에 대한 내부 LLM 평가입니다. 본문, 제목, 그림은 경미한 차이를 허용했고, 표와 수식은 값, 기호, 구조가 일치해야 통과시켰습니다.

PDF -> Markdown에 SLLM 사용해보기 ↗PDF 변환 오픈소스 AnyDoc을 사용해보자 ↗