PyMuPDF와 Docling 비교: PDF 추출 품질·속도·실행 조건을 함께 보기

배경과 문제

RAG(검색 증강 생성)나 멀티모달 LLM 파이프라인을 구축할 때 가장 먼저 마주치는 고민 중 하나는 비정형 PDF 문서를 어떻게 빠르고 정확하게 파싱할 것인가이다. 문서 AI 파서들이 많이 등장하면서 리더보드도 늘었지만, 벤치마크를 제작한 주체가 상위권을 독점하는 경우가 많아 실제 프로덕션 환경에서 믿을 수 있는 객관적 지표가 무엇인지 의문이 남는다.

이런 배경에서 이파피루스와 Artifex는 자체 벤치마크 툴 대신 경쟁사인 LlamaIndex가 만든 ParseBench를 활용해 로컬 파서들의 성능을 측정한 결과를 공개했다. ParseBench는 문서 파싱 도구가 PDF를 AI 에이전트가 신뢰하고 행동할 수 있는 구조화된 출력으로 변환하는 능력을 평가하는 벤치마크로, 실제 기업 문서(보험, 금융, 정부)에서 가져온 약 2,000페이지를 다섯 가지 능력 차원으로 나누어 평가한다.

기존 접근의 한계

문서 AI 리더보드는 벤치마크를 주관하거나 후원한 조직이 참여한 경우 해당 모델이 상위권을 차지하는 경향이 있다. 이파피루스의 분석에 따르면 13개의 문서 AI 리더보드 중 벤치마크 제작사나 스폰서와 연관된 모델이 참가한 10건 모두에서 해당 모델이 1~3위를 차지했다. 이는 업체가 제시한 관찰이며 순위만으로 평가 조작이나 편향의 원인을 입증한 것은 아니다.

또한 기존 벤치마크는 추출 품질 점수만 강조하는 경우가 많다. 하지만 실제 서빙 인프라에 배포하려면 처리 속도, 설치 용량, 로컬 구동 여부도 중요하다. 문서 추출 품질이 아무리 높아도 처리 속도가 10초 이상 걸리거나 의존성 패키지 용량이 기가바이트 단위라면 배포하기 부담스럽다. 따라서 품질과 운영 비용을 함께 평가하는 접근이 필요하다.

연구방법을 단계별로

게시 업체는 ParseBench의 평가 방법과 공식 점수 산출 방식을 바꾸지 않았다고 설명한다. 실행을 위한 호환성 수정 이력은 공개 저장소에 남겼다고 밝혔다. ParseBench는 표, 차트, 내용 충실도, 의미적 서식, 시각적 그라운딩의 다섯 가지 범주로 문서를 평가하며, 각 범주는 에이전트 워크플로우를 망가뜨리는 실패 모드를 겨냥한다. 예를 들어 표 범주는 병합된 셀과 계층적 헤더의 구조적 충실도를, 내용 충실도는 누락·환각·읽기 순서 위반을 측정한다.

측정 환경은 고정된 AWS 인스턴스(c7i.2xlarge, Intel Xeon Platinum 8488C)에서 자동화 파이프라인을 통해 동일 세션 내에서 진행되었다. 벤더 페이지는 2,078개 documents를 2회 반복 측정했다고 쓰지만, 공개 README는 중복 제거 기준 2,078페이지·1,211문서로 구분한다. 따라서 2,078을 독립 문서 수로 확정할 수 없다. ParseBench 리비전은 a65ca16, 최대 동시 실행 수는 1로 고정했다. PyMuPDF 1.28.2는 PyMuPDF4LLM과 Layout 라이브러리를 포함하며, Docling 2.124.0은 로컬 docling-serve 인터페이스를 통해 측정되어 localhost HTTP 경유 비용이 포함된다.

측정 결과의 투명성을 위해 테스트 스크립트와 개별 문서별 결과 데이터를 GitHub 포크 저장소에 공개했다. 또한 소프트웨어 버전에 따라 결과 차이가 크다는 점을 강조했는데, 실제로 Docling은 2.122.0 버전과 2.124.0 버전 사이에서 표 추출 점수가 거의 9점 가까이 차이 났다. 따라서 벤치마크를 확인할 때 정확한 버전 확인이 필수적이다.

결과와 숫자의 의미

종합 품질 점수는 ParseBench의 공식 점수를 다섯 범주에 걸쳐 평균한 값이다. PyMuPDF는 53.57, Docling은 50.72를 기록했다. 표 추출에서는 PyMuPDF가 72.00으로 Docling의 69.07보다 높았고, 시각적 그라운딩에서는 Docling이 65.60으로 PyMuPDF의 61.89보다 높았다. 차트, 내용 충실도, 의미적 서식 점수도 각각 차이가 있다.

속도 표의 열 이름은 페이지당 중간 시간(p50)이다. PyMuPDF는 0.474초, Docling은 11.008초로 약 23배 차이가 났다. 다만 이 수치는 문서별 공식 타이밍을 풀링한 중간값이며, Docling은 docling-serve API를 통한 localhost HTTP 홉을 포함한다. 설치 용량은 PyMuPDF 278MB, Docling 1.6GB였다. 모델 캐시를 제외한 깨끗한 가상환경의 크기이며 실행 중 메모리나 전체 컨테이너 크기는 아니다.

콜드 스타트 시간(모델이 이미 다운로드된 상태에서 새 프로세스의 임포트 및 첫 문서 처리 시간)은 PyMuPDF가 1.20초, Docling이 12.11초였다. 각 값은 모델 다운로드가 끝난 상태에서 새 프로세스로 3번 측정한 중간값이다. 이는 모델 로딩 오버헤드가 실제 서비스의 첫 응답 지연에 영향을 줄 수 있음을 보여준다. 참고로 LiteParse(no OCR)는 0.05초, MarkItDown은 0.69초로 더 빨랐지만 종합 품질 점수는 각각 32.56, 18.74로 낮았다.

구체적인 예시

ParseBench의 다섯 가지 범주는 각각 실제 에이전트 실패 시나리오를 반영한다. 예를 들어 표 범주에서 병합된 셀과 계층적 헤더의 구조가 잘못 추출되면, 에이전트가 값을 조회할 때 잘못된 열을 읽게 된다. 차트 범주에서는 막대·선·파이·복합 차트에서 정확한 데이터 포인트와 계열·축 레이블을 추출해야 하는데, 대부분의 파서는 구조화된 데이터 대신 원시 텍스트를 반환해 에이전트가 정확한 값을 얻지 못한다.

내용 충실도 범주는 누락, 환각, 읽기 순서 위반을 측정한다. 에이전트의 컨텍스트가 불완전하거나 조작된 내용을 포함하면 모든 하위 결정이 손상된다. 의미적 서식 범주는 취소선(대체된 내용 표시), 위첨자/아래첨자(각주, 수식), 굵은 글씨(정의된 용어, 핵심 값), 제목 계층 등 의미를 전달하는 서식의 보존을 평가한다. 취소선이 있는 가격은 현재 가격이 아니라는 점을 파서가 인식해야 한다.

시각적 그라운딩 범주는 추출된 모든 요소를 페이지의 원본 위치로 추적할 수 있는지 평가한다. 규제 대상 워크플로우에서 모든 값이 추적 가능해야 하는 감사 가능성에 필요하다. 이번 측정에서 Docling이 이 범주에서 더 높은 점수를 받은 것은 레이아웃 내 시각적 위치를 찾는 능력이 상대적으로 우수함을 시사한다.

한계와 오해하기 쉬운 점

이 벤치마크는 PyMuPDF/Artifex 및 관련 업체 측이 주도했다. 경쟁사 LlamaIndex의 ParseBench를 사용했다는 사실만으로 독립적·중립적인 검증이 보장되지는 않는다. 파서 선정, 버전, 설정값에 따라 결과가 달라질 수 있기 때문에, 공개된 환경 조건을 꼼꼼히 확인해야 한다.

공식 표의 처리 시간 0.474/11.008은 페이지당(p50)으로 표기되어 있지만, 방법 설명에는 pooled official per-document timings라고 적혀 있다. 문서 수와 페이지 수, 시간 정의를 혼동하지 말아야 한다. 이 해설은 개별 원시 결과를 재실행하지 않고 게시문·벤치마크 페이지·README를 대조했다. 벤더의 2,078문서 표기와 README의 2,078페이지 표기도 서로 다르다.

Docling의 처리 시간에는 localhost HTTP 홉이 포함되어 있어 순수 파서 성능과 직접 비교하기 어렵다. 또한 이번 측정은 GPU를 필수로 요구하지 않는 Non-VLM 순수 로컬 파서에 초점을 맞췄다. VLM 파이프라인은 높은 인식률을 보일 수 있지만 GPU 인프라 비용과 서빙 복잡도가 완전히 다르므로, 향후 동일한 투명성 원칙 아래 비교 범위를 넓힐 계획이다.

실제로 어떻게 활용할까

실무 엔지니어는 단순히 정확도 수치만 보기보다 시스템 요구사항에 맞는 처리 속도(Latency)와 설치 용량과 실행 리소스를 함께 저울질해야 한다. 예를 들어 대규모 배치 파이프라인이나 경량 컨테이너 배포가 필요하다면 PyMuPDF의 빠른 속도와 작은 설치 용량이 유리할 수 있다. 반면 시각적 그라운딩이 중요한 규제 워크플로우라면 Docling의 강점을 고려할 수 있다.

리더보드를 볼 때는 테스트 주체가 누구인지, 어떤 버전과 파라미터로 측정되었는지 확인하는 것이 안전하다. 가장 확실한 방법은 어떤 공개 벤치마크보다도 자신이 운영 중인 서비스의 실제 비즈니스 문서 샘플로 직접 PoC를 진행하는 것이다. 이번에 공개된 벤치마크 페이지는 누구나 검증하고 재현할 수 있는 프로세스를 제공하지만, 제품 도입의 최종 잣대는 실제 데이터여야 한다.