Docling 리뷰: IBM의 문서-마크다운 변환기가 PDF에 실제로 하는 일

Docling은 자꾸 웹 스크래퍼랑 같은 선에 놓이곤 하지만, 사실은 완전히 다른 도구입니다. IBM Research에서 시작해 지금은 LF AI & Data Foundation 프로젝트가 된 문서 변환 툴킷으로, 이미 가지고 있는 파일(PDF, DOCX, PPTX, XLSX, HTML, 이미지)을 Markdown이나 JSON으로 바꿔 줍니다. 공식 슬로건도 아주 직설적입니다. “문서를 생성형 AI에 맞게 준비하세요.”

즉, 이 글은 크롤러가 아니라 변환기를 직접 써본 리뷰입니다. 아래 내용은 전부 CPU 전용 머신 1대(macOS arm64, Python 3.14.2, Docling 2.111.0)에서 측정했고, 스크립트로 점수를 매겼으며, 실패는 실패대로 기록했습니다. 저장소 규모도 엄청 크고 매일 바뀝니다 — 63,069 stars, 4,449 forks, 그리고 메타데이터를 가져온 당일에도 커밋이 있었을 정도입니다. 그래서 여기 적힌 이슈 수나 버전은 고정값이 아니라 스냅샷으로 봐야 합니다.

Docling이 실제로 하는 일과 하지 않는 일

Docling의 모든 작업 단위는 DoclingDocument입니다. 파일을 그 구조로 파싱한 뒤 Markdown, HTML, DocTags, 또는 무손실 JSON으로 내보냅니다. 코드는 MIT 라이선스를 따르며(개별 모델 라이선스는 다를 수 있음), 출발점은 IBM Research Zurich입니다. 작성 시점의 최신 릴리스는 v2.112.0으로, 제가 테스트를 돌리기 이틀 전에 공개됐습니다.

가장 핵심적인 기능은 PDF와 이미지 처리입니다. 다만 이건 단순 문자열 파싱이 아니라, RT-DETR 레이아웃 모델, TableFormer 표 구조 모델, 선택형 비전-언어 모델, 스캔 문서를 위한 RapidOCR로 구성된 머신러닝 스택입니다. 이 모델들이 페이지 레이아웃, 읽기 순서, 표 구조를 복원합니다. 바로 이 부분이 리뷰할 가치가 있는 대목이고, HTML만 던져서는 절대 볼 수 없는 영역이기도 합니다.

한 가지는 확실히 구분해야 합니다. Docling은 아무것도 가져오지 않습니다. JavaScript를 렌더링하지도 않고, 안티봇 장벽을 뚫지도 않으며, 크롤링도 하지 않습니다. 사용자가 파일을 넣으면 Docling이 그 내용을 이해합니다. 크롤링은 다른 도구의 몫입니다. 나중에 Docling이 Firecrawl을 대체하느냐는 질문이 나오는 이유도 여기 있습니다. 답은 ‘아니오’입니다. 둘은 서로를 보완하는 관계이며, 그 이유는 뒤에서 설명하겠습니다.

아무도 경고해 주지 않은 첫 실행

Python 3.14.2에서 pip install docling은 문제 없이 끝납니다. 그런데 가상환경을 열어 보면 1.3 GB입니다. HTML 파일만 변환할 예정이어도 Docling은 전체 ML 스택을 강제 의존성으로 끌고 옵니다.

의존성	디스크 사용량(MiB, du)
torch (2.13.0)	536
opencv (cv2)	119
transformers (5.8.1)	101
scipy	99
sympy	76
pandas	72
rapidocr(+ 번들 모델)	75.6
docling_parse	30

이건 PDF 한 장을 변환하기도 전의 수치입니다. 진짜 불편함은 첫 PDF 변환에서 시작됩니다. 그때 모델 다운로드가 일어나기 때문입니다. 새 HuggingFace 캐시 환경에서 첫 PDF 변환은 약 224초가 걸렸고, 그 대부분은 계산이 아니라 다운로드였습니다. 레이아웃 + TableFormer 모델은 디스크 기준 약 506 MiB(TableFormer 342 MiB + 레이아웃 164 MiB, du로 검증)이고, RapidOCR는 site-packages 아래에 PP-OCRv4 가중치 약 40 MB를 받습니다. 같은 파일을 두 번째로 변환하면요? 0.55초입니다. 모델은 캐시되기 때문에 한 번만 비용을 치르면 됩니다.

한 가지 수치는 무시해도 됩니다. 콜드스타트 스크립트가 model_download_mb를 1060.2로 찍는데, 이건 footprint로 인용하면 안 됩니다. os.walk가 심볼릭 링크를 따라가면서 생긴 수치라, HuggingFace 캐시가 각 모델 파일을 blobs/에 한 번 저장한 뒤 snapshots/ 심볼릭 링크로 다시 노출하는 구조를 두 번 세게 됩니다. 즉, 14개 모델 파일을 중복 카운트한 셈입니다. du와 맞아떨어지는 중복 제거 기준 수치는 약 506 MiB입니다(블롭만 보면 505.4 MiB). Docling을 벤치마크할 때는 다운로드 바이트와 디스크 점유 바이트를 따로 봐야 한다는 뜻입니다. 둘은 서로 다르니까요.

Docker 이미지를 만들거나 오프라인 환경에 넣는 사람에게는 또 다른 함정이 있습니다. 가중치가 두 위치에, 두 타이밍으로 나뉘어 내려옵니다. 레이아웃과 TableFormer 모델은 HF_HOME을 따르고 첫 PDF 변환 때 다운로드됩니다. 반면 RapidOCR 모델은 그렇지 않습니다. …/site-packages/rapidocr/models/에 저장되며, 캐시 설정을 아예 무시합니다. 이미지를 사전 빌드하거나 에어갭으로 운영하려면 두 캐시를 모두 처리해야 하고, HF_HOME만 설정해선 두 번째 캐시를 막지 못합니다.

그렇다고 불공평하게만 볼 수는 없습니다. 이전 릴리스들 이후, 프로젝트는 docling-slim을 제공하기 시작했습니다. 약 50 MB짜리 코어 버전이라 pip install docling-slim[format-html]처럼 설치하면 torch를 끌고 오지 않고 HTML만 처리할 수 있습니다. 즉, 기본 docling 메타패키지는 여전히 1.3 GB 수준이 맞지만, 이제는 선택 해제가 가능합니다. 저는 기본 패키지를 테스트했는데, 어차피 pip install docling이 바로 그걸 설치하기 때문입니다. 다만 무거운 구조가 방치된 결함은 아니고, 모듈화된 해결책이 이미 있습니다(issue #2393).

설정하면서 하나 눈에 띄는 작은 불편도 있습니다. import docling; docling.__version__을 실행하면 AttributeError: module 'docling' has no attribute '__version__'가 뜹니다. 모듈이 버전을 노출하지 않기 때문입니다. 정상 동작하는 방법은 importlib.metadata.version("docling")이며, 이 경우 '2.111.0'을 돌려줍니다. 작은 DX 문제지만, 2026년 7월부터 upstream 이슈 #3733으로 열려 있습니다.

표 정확도: TableFormer가 제값을 하는 지점

표는 Docling을 평범한 PDF-to-text 덤프 대신 선택하는 가장 큰 이유입니다. 그래서 기계 판독 가능한 정답이 있는 표 PDF 7개를 만들어 셀 단위로 점수를 매겼습니다. 여기서 중요한 지표는 두 가지이며, 서로 다릅니다. cell recall은 정답 값이 감지된 표 어딘가에 들어가 있는 비율이고, in-row rate는 그 값이 정확한 행에 들어간 비율입니다. 이 둘을 섞으면 도구를 과대평가하게 되므로, 둘 다 보여드리겠습니다.

표(스트레스 테스트)	감지 여부	셀 재현율	행 내 적중률	비고
T1 일반 테두리 그리드(5×8), 페이지 단독	아니오	0.0	—	<!-- image -->로 분류되어 모든 셀이 누락됨
T2 테두리 없음(헤더 구분선만 있음)	예	1.00	1.00	완벽하게 정확한 그리드
T3 2단 colspan 병합 헤더	예	1.00	0.97	모든 값은 찾았지만 헤더 값 하나가 한 행 밀림
T4 merged rowspan row-label, 페이지 단독	아니오	0.0	—	<!-- image -->로 분류됨
T5 colspan 헤더 + 테두리 없음	예	1.00	0.97	모든 값은 찾았고, T3와 같은 헤더 행 밀림 발생
T6 재무표, 빈 열, 오른쪽 정렬	예	1.00	1.00	빈 열이 유지되고 밀리지 않음
T7 폭이 넓은 12열 그리드	예	1.00	1.00	넓은 표에서도 열 밀림 없음

Docling이 감지한 5개 표에서는 정답 값이 하나도 빠지지 않았습니다. 셀 재현율은 전부 1.00이었습니다. 그중 3개는 값이 정확한 행에도 들어갔습니다. 다단계 헤더가 있는 두 케이스(T3, T5)에서는 헤더 값 하나가 원래 행에서 벗어나며 in-row rate가 0.97로 떨어졌습니다. 즉, 데이터는 다 들어가지만, 중첩 헤더에서는 행 배정이 한 칸 흔들릴 수 있습니다.

구조적으로 까다로운 케이스도 생각보다 잘 버텼습니다. 2단 colspan 헤더는 GitHub-flavored Markdown으로 자연스럽게 평탄화됐고(“Q1 2026” 라벨이 두 칸에 걸쳐 반복됨, colspan을 GFM으로 접는 올바른 방식), 헤더 구분선만 있는 테두리 없는 그리드(T2)도 정확했습니다. 12열의 넓은 표(T7)도 열이 밀리지 않았고, 완전히 빈 재무 열(T6) 역시 삭제되거나 합쳐지지 않고 빈 셀로 보존됐습니다. 이는 공식 TableFormer TEDS 점수와도 맞습니다. simple 95.4, complex 90.1, all-tables 93.6으로, 모델 카드는 Camelot(73.0)이나 EDD(88.3)보다 훨씬 높게 벤치마크합니다.

병합 셀에 대해서는 주의가 필요합니다. 반대되는 내용의 열린 이슈가 있기 때문입니다. issue #3698은 V1과 V2가 병합된 행과 열을 잘못 처리한다고 보고합니다. 제 테스트 파일에서는 단순 colspan(T3/T5)과 rowspan 값이 올바르게 평탄화됐고, 위에서 언급한 다단계 헤더의 행 밀림만 있었습니다. 그러나 #3698에서 실패하는 사례는 불규칙한 다중 행/다중 열 병합과 다페이지 표처럼 훨씬 끝단의 병적인 경우입니다. 제 테스트는 그보다 단순한 케이스였습니다. 따라서 정확한 표현은 이렇습니다. 여기서는 단순 colspan과 rowspan 값이 복원됐고(다단계 헤더는 한 행 밀릴 수 있음), 복잡하고 불규칙한 병합은 여전히 문서화된 미해결 문제입니다. “병합 셀은 잘 된다”도 아니고, “병합 셀은 다 깨진다”도 아닙니다.

함정: 페이지에 표 하나만 있으면 사라질 수 있다

위 표를 다시 보세요. T1과 T4는 아예 감지되지 않았습니다. Docling은 <!-- image -->를 내보내고 모든 셀을 누락했지만 오류는 없었습니다. T1은 아주 평범한 테두리 5×8 그리드입니다. 이 정도면 표 파싱 약점이라고 단정하기엔 불안해서, 실제로 무엇이 트리거인지 분리해 보는 A/B 실험을 만들었습니다.

먼저 가장 흔한 설명부터 배제했습니다. 텍스트 레이어는 살아 있습니다. pypdfium2는 T1에서 327자, T4에서 221자를 읽어옵니다. 즉, 이건 스캔 이미지가 아니라 실제 디지털 PDF입니다. OCR을 꺼도(do_ocr=False) 상황은 달라지지 않았습니다. 표는 여전히 떨어졌습니다. 그리고 DoclingDocument를 직접 확인해 보면 len(doc.tables) == 0이고 len(doc.pictures) == 1입니다. 즉, 레이아웃 모델이 표 전체 영역을 Picture로 분류한 것입니다.

결정적인 테스트는 그다음이었습니다. 동일한 T1과 T4 표를 이번에는 일반 본문 문단 몇 개에 둘러싼 뒤 다시 변환했습니다. 결과는 완전히 달라졌습니다. 둘 다 정확히 인식됐고, len(doc.tables) == 1이었으며, 올바른 GFM 표가 출력됐고, T4b의 rowspan 라벨 “North”도 세 행에 걸쳐 제대로 반복됐습니다. 같은 표입니다. 바뀐 것은 sparse page에 단독으로 있었는지, 아니면 텍스트 안에 포함돼 있었는지뿐이었습니다.

즉, 진짜 주의점은 TableFormer가 약하다는 게 아닙니다. Docling의 RT-DETR 레이아웃 모델이 페이지 문맥을 사용하기 때문에, 주변 콘텐츠가 거의 없는 빈 페이지에 작은 표 하나만 있으면 Picture로 읽히고 조용히 누락될 수 있다는 점입니다. 실제 업무에서 이 상황은 꽤 흔합니다. 인보이스, 스펙 시트, 잘라낸 내보내기 파일이 바로 그런 형태이기 때문입니다. 한 페이지에 표 하나, 주변 서술문은 없음. 해결책은 단순하지만 효과적입니다. 레이아웃 모델에 페이지 문맥을 충분히 주거나, 변환 후 doc.tables를 검사해 표 개수가 0인 페이지를 따로 표시하면 됩니다. 이건 issue #3495(Table과 Picture로 동시에 감지된 표)와 인접한 문제이지만, “페이지가 너무 비어서 생기는 트리거” — 같은 표가 단독일 때는 떨어지고 텍스트에 묻히면 변환되는 현상 — 는 제가 확인한 범위에서 공개 문서로 찾지 못했습니다. 측정한 사실이고, 이전에 문서화된 적은 없습니다. 누구도 몰랐던 버그라는 뜻은 아닙니다.

실제 스캔 문서의 OCR: EasyOCR가 아니라 RapidOCR

스캔 PDF는 변환기가 조용히 실패하기 쉬운 영역입니다. 그래서 실제로 텍스트 레이어가 0자인 스캔 2개를 넣었습니다. pypdfium2가 복구 가능한 문자를 0자로 보고하므로, 어떤 출력이든 숨은 텍스트가 아니라 OCR 결과라는 점이 확인됩니다.

단일 페이지 ocr_test.pdf는 CPU에서 14.3초 만에 깔끔하게 복원됐습니다. “Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package,” 문장이 그대로 나왔습니다. 4페이지짜리 nemotron_multipage.pdf는 총 70.1초(페이지당 17.5초) 동안 4페이지 모두 OCR을 수행했고, 각 페이지에 테스트 문장을 반복 출력했습니다. 기본 OCR은 자동으로 동작했습니다. 별도 플래그도, 설정도 필요 없었습니다.

여기서 많은 글이 틀리게 적는 부분이 있습니다. 기본 OCR 엔진은 EasyOCR가 아니라 RapidOCR입니다. 첫 실행에서 PP-OCRv4 .pth 가중치가 내려오는 걸 보고 확인했습니다. 기존 블로그나 오래된 Docling FAQ는 아직도 EasyOCR가 기본이라고 쓰는 경우가 많은데, 그건 오래된 정보입니다. EasyOCR는 이제 선택적으로 켜는 추가 기능입니다. 여전히 맞는 경고는 하나 있습니다. OCR은 대규모 처리에서 느린 경로라는 점입니다. 여기서 측정한 수치는 전부 CPU 한계치이며, GPU가 있으면 시간은 눈에 띄게 줄어들 겁니다.

실제 PDF, 읽기 순서, 그리고 페이지당 시간

합성 테스트는 특정 동작을 증명하지만, 실제 PDF는 진짜로 작동하는지를 보여줍니다. 2단 구성의 학술 PDF 두 개를 돌렸습니다. 9페이지짜리 Docling 기술 보고서와 15페이지짜리 “Attention Is All You Need”입니다. 둘 다 표와 수식이 포함된 2단 레이아웃입니다.

15페이지짜리 Attention 논문에서는 Abstract, Introduction, Background, Conclusion, References 같은 5개 섹션 마커가 모두 문서 순서대로 선형화된 Markdown에 나타났습니다. 2단 구성임에도 순서가 뒤섞이지 않았습니다. Transformer, encoder, BLEU, multi-head 같은 콘텐츠 포인트도 모두 들어갔고, 유명한 다중 열 결과 표는 4개의 감지된 표로 잡혔습니다. 이것이 바로 읽기 순서와 열 병합 복원의 진짜 가치입니다. RAG 청킹은 문서를 제대로 선형화하지 못하면 쓸 수 없기 때문입니다.

시간 측정은 조금 반직관적인 교훈을 줍니다. 페이지당 시간은 페이지 수가 아니라 각 페이지의 구조 밀도에 좌우됩니다. 더 밀도가 높은 9페이지 보고서는 페이지당 14.95초로, 15페이지 논문보다 더 느렸습니다. 논문은 페이지당 5.99초였습니다. 보고서가 표와 그림을 더 많이 담고 있고, 각 요소가 레이아웃과 TableFormer 추론을 더 많이 유발했기 때문입니다. 즉, CPU에서의 “페이지당 초”는 길이가 아니라 구조 밀도의 함수입니다. 이것은 CPU 단일 실행 결과이며, 실제 운영 수치는 아닙니다.

다중 포맷과 무손실 JSON 주장

Docling은 통합 다중 포맷 파싱을 내세우므로, 알려진 내용과 정답 포인트가 있는 DOCX, XLSX, PPTX를 만들어 두 가지를 확인했습니다. Markdown에서 포인트가 보이는지, 그리고 export_to_dict()를 통한 JSON 라운드트립 후에도 살아남는지입니다.

파일	변환 시간(s)	MD에서 포인트 발견	MD의 표 수	JSON에서 포인트 유지
report.docx(제목 + 병합된 "Total" 표 + 글머리표)	0.137	7/7	1	예
workbook.xlsx(2개 시트, 빈 열 포함)	0.016	6/6	2	예
deck.pptx(3개 슬라이드, 글머리표 + 표)	0.038	6/6	1	예

모든 콘텐츠 포인트가 Markdown에 들어갔고, 표도 복원됐습니다(DOCX의 병합된 “Total” 행과 두 XLSX 시트 포함). 모든 포인트는 export_to_dict() JSON에서도 유지됐습니다. 적어도 깨끗한 입력에 대해서는 이것이 바로 무손실 DoclingDocument 주장에 대한 증거입니다. 이 포맷들은 ML 모델이 아니라 포맷별 네이티브 백엔드를 거치기 때문에 수십 밀리초 안에 끝나고 완전히 오프라인으로 동작합니다. 범위도 정직합니다. 포맷당 깨끗한 파일 1개는 폭넓은 지원을 입증할 뿐, 병적인 오피스 파일에 대한 스트레스 테스트는 아닙니다.

HTML: 충실하지만 깨끗하진 않다

이 부분은 Docling을 RAG 파이프라인에 넣을지 결정하는 핵심이라서, 꼭 읽어야 합니다. Docling은 HTML 문서 전체를 변환합니다. Readability처럼 핵심 본문만 뽑아내지 않습니다. 사이트의 장식 요소가 얼마나 남는지 보기 위해 Docling 출력에 포함된 nav, TOC, cookie, footer 마커 줄 수를 세었습니다.

페이지	빈 줄 제외 MD 라인 수	보일러플레이트 라인 수	보일러플레이트 비율	본문 시작 줄
Wikipedia "Web scraping"	255	34	13.3%	28
scrapethissite/forms	63	1	1.6%	—
books.toscrape	65	0	0.0%	—
quotes.toscrape	35	0	0.0%	—

Wikipedia처럼 장식이 많은 페이지에서는 Markdown 라인의 약 13%가 nav/TOC/footer 보일러플레이트입니다. 실제 본문은 28번째 줄에서야 시작합니다. 출력은 “move to sidebar / Contents / Toggle the table of contents”로 열리고 “CS1 maint… / Search Wikipedia”로 닫힙니다. 책이나 인용 페이지처럼 깔끔한 콘텐츠 페이지에서는 비율이 거의 0%이므로, 이는 페이지당 부담이 아니라 템플릿 장식 문제입니다. Docling은 깨끗한 본문 추출이 아니라 문서 전체를 충실하게 Markdown으로 옮깁니다. 업스트림은 HTML 장식 문제를 issue #1865(종료)와 #1930(진행 중)에서 추적하고 있습니다.

공정성을 위해 두 가지를 덧붙이겠습니다. 첫째, HTML 경로에서는 Docling이 ML 모델을 전혀 쓰지 않습니다. 단순한 파이프라인 위의 BeautifulSoup 백엔드입니다. “비전 모델이 페이지를 읽는다”는 이야기는 PDF와 이미지에만 해당합니다. HTML을 넣으면 레이아웃이나 TableFormer 기계는 아예 동작하지 않습니다. 둘째, PDF 경로는 헤더/푸터 장식 분류를 어느 정도 시도합니다. 따라서 “보일러플레이트 제거를 전혀 안 한다”고 말하면 과장입니다. 보일러플레이트를 그대로 돌려주는 것은 특히 HTML 백엔드입니다.

다른 도구들과의 비교, 그리고 Thunderbit의 위치

웹 데이터 추출용 Thunderbit 사용해 보기

Docling과 가장 자주 비교되는 도구는 Firecrawl입니다. 그래서 포지셔닝 표를 하나 넣었습니다. 다만 한 가지 주의하세요. 이 비교는 문서 수준의 비교이지, 같은 머신에서 돌린 벤치마크는 아닙니다. Firecrawl은 이 테스트 파일들에서 실행하지 않았습니다. 여기서 측정된 것은 Docling 열뿐이고, Firecrawl 열은 공개 문서 기준입니다.

축	Firecrawl(문서 기준)	Docling(이 테스트에서 측정)
핵심 역할	라이브 웹을 크롤링 + 스크래핑 → Markdown	이미 가진 문서를 → Markdown/JSON으로 변환
가져오기 / JS 렌더링 / 안티봇	예(호스티드 브라우저)	아니오 — 파일을 직접 넣어야 함
본문 추출	예	아니오 — 전체 문서 충실 변환(Wikipedia에서 약 13% 장식 포함)
PDF 표 구조(ML)	제한적	예 — TableFormer(공식 TEDS 93.6, 감지된 테스트에서 cell recall 1.00, in-row 0.97–1.00)
스캔 PDF / OCR	제한적	예 — 기본 RapidOCR(텍스트 레이어 0인 스캔 복원)
포맷 범위	웹 페이지	PDF/DOCX/PPTX/XLSX/HTML/EPUB/이미지
배포	호스티드 API(+ 자체 호스팅)	로컬 pip 라이브러리, 오프라인, API 키 불필요
설치 부담	API 키 / 가벼운 클라이언트	기본 설치 1.3 GB + 모델 약 506 MiB(또는 docling-slim)
라이선스	상용 / 소스 공개형	MIT

한 줄로 정리하면 이렇습니다. 데이터가 라이브 웹에 있고, 크롤링·JS 렌더링·본문 정리가 필요하다면 Firecrawl이 맞습니다. 이미 문서를 보유하고 있고, 특히 PDF·스캔·표가 많은 오피스 파일에서 충실하고 오프라인이며 구조를 보존하는 변환이 필요하다면 Docling이 맞습니다. 둘은 서로를 보완합니다. 현실적인 파이프라인은 하나로 크롤링하고 다른 하나로 문서를 변환합니다.

이쯤에서 Thunderbit 이야기를 솔직하게 해야겠습니다. 제가 이곳에서 일하고 있기 때문에, 다르지 않은 척하면 당연히 의심받아야 합니다. Thunderbit과 Docling은 같은 일을 하지 않으며, 저는 억지로 같다고 말하지 않겠습니다. 개발자 기준으로 Thunderbit은 AI 스크래핑 API + MCP 서버 + CLI이고, 다루는 대상은 라이브 웹 페이지입니다. POST /distill은 URL을 깔끔한 LLM-친화 Markdown으로 바꾸며, Docling이 명시적으로 건드리지 않는 JS 렌더링, 안티봇, CAPTCHA도 처리합니다. POST /extract는 직접 정의한 JSON Schema를 바탕으로 스키마에 맞는 구조화 JSON을 반환합니다. 즉, RAG 파이프라인의 가져오기와 정리 단계입니다. Docling은 로컬 문서 단계입니다. 디스크에 이미 있는 PDF, 스캔본, 스프레드시트를 다룹니다. 코퍼스가 웹 페이지라면 Thunderbit의 API, MCP 도구(thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) 또는 CLI(npx @thunderbit/thunderbit-cli)를 쓰면 됩니다. PDF와 스캔본이라면 Docling을 쓰세요. 둘 다 필요하다면, 현실의 대부분 파이프라인처럼 함께 쓰면 됩니다. 둘은 서로를 대체하려는 도구가 아닙니다.

최종 판단: 결론은 유보, 숙제는 남아 있다

여기서는 0~100 점 하나로 매기지 않겠습니다. 가중 총점을 내버리면 Docling이 애초에 하지 않는 일(예: 크롤링)에 대한 페널티를 억지로 섞게 되고, 서로 비교 불가능한 항목을 같은 잣대로 재게 되기 때문입니다. 제가 테스트한 항목별로 보면 다음과 같습니다.

• 설치 / 첫 실행: 무겁습니다 — 1.3 GB 가상환경, 약 506 MiB 모델, 첫 PDF 약 224초, 워밍 이후 약 0.55초 — 하지만 docling-slim으로 무게를 피할 수 있습니다.
• 표 정확도: 표가 감지되면 강합니다(5개 중 5개에서 cell recall 1.00, in-row 0.97–1.00). 이번 테스트에서는 공식 TEDS 이야기와도 잘 맞았습니다.
• 표 감지 견고성: sparse page 함정이 있습니다. 단독 표가 Picture로 떨어질 수 있습니다. doc.tables를 반드시 확인하세요.
• 스캔 / OCR: 잘 동작합니다. 기본은 RapidOCR이며, 대규모에서는 느립니다.
• 다중 포맷: 탄탄합니다. JSON 라운드트립도 유지됩니다.
• HTML: 충실하지만 깨끗하지 않습니다. 본문만 추출하지 않습니다.
• 개발자 경험: 깔끔한 3줄 API와 정돈된 DoclingDocument가 장점이지만, __version__ 노출은 빠져 있습니다.

누구에게 맞나: PDF, 스캔, 오피스 파일 위에서 RAG나 데이터 파이프라인을 만들고, 오프라인 상태에서 구조를 보존하면서 표와 OCR까지 제대로 이해하고 싶은 팀. 누구에게 맞지 않나: 라이브 웹 크롤링이나 깨끗한 본문 HTML 추출이 필요한 사람 — 그건 다른 도구의 영역입니다.

그리고 이건 리뷰이지 보도자료가 아니므로, 한계도 분명히 적어 두겠습니다. 이 테스트는 CPU 전용 머신 1대에서 합성 표 7개와 실제 PDF 2개를 돌린 타깃 프로브일 뿐이며, TEDS 규모의 정확도 벤치마크는 아닙니다. 다음 항목들은 제가 테스트하지 않았고, 파이프라인을 Docling에 걸기 전에 꼭 확인해야 합니다. 선택적 VLM(GraniteDocling) 경로, 실제 docling-slim footprint, GPU 실행, 복잡하고 불규칙한 병합 셀과 다페이지 표, 수식의 LaTeX 변환 정확도, 그리고 운영에서 가장 놀라운 문제가 되기 쉬운 대규모 변환 시 배치 메모리 증가, thread/GIL 확장성, 객체 수명 주기입니다. Docling은 자신이 주장하는 영역에서는 강력하고, 측정 가능한 도구입니다. 하지만 실제 코퍼스에 투입하기 전에는 분명히 확인해야 할 경계도 있습니다. sparse-page 주의점은 기억하고, 첫 실행 다운로드 비용을 예산에 넣고, 대규모 동작은 직접 검증하세요.

웹 데이터 추출용 Thunderbit 사용해 보기 Get Started Free

자주 묻는 질문

Docling은 웹 스크래퍼나 크롤러인가요? 아니요. Docling은 PDF, DOCX, PPTX, XLSX, HTML, 이미지처럼 이미 가지고 있는 문서를 Markdown이나 JSON으로 변환합니다. URL을 가져오거나, JavaScript를 렌더링하거나, 안티봇을 처리하지 않습니다. 라이브 웹 크롤링은 Firecrawl이나 Thunderbit의 웹 API 같은 별도 도구가 맡아야 합니다. Docling은 사용자가 넘긴 파일에서 시작합니다.

Docling 설치 크기와 첫 실행 다운로드는 어느 정도인가요? 기본 docling 메타패키지는 전체 ML 스택을 강제 의존성으로 끌어오기 때문에 가상환경이 약 1.3 GB가 됩니다(torch만 536 MiB). 첫 PDF 변환에서는 레이아웃과 TableFormer 모델 약 506 MiB가 디스크에 내려오고, RapidOCR 가중치 약 40 MB가 추가되며, 전체적으로 약 224초가 걸립니다. 거의 전부 다운로드 시간입니다. 두 번째 변환은 약 0.55초입니다. 가벼운 포맷만 필요하다면 docling-slim(코어 약 50 MB)을 쓰면 무거운 경로를 피할 수 있습니다.

Docling은 OCR을 하나요? 어떤 엔진을 쓰나요? 예, 합니다. 텍스트 레이어가 없는 스캔 PDF에서는 OCR이 자동으로 실행되며, 제 테스트에서는 텍스트를 깔끔하게 복원했습니다. 기본 엔진은 EasyOCR가 아니라 RapidOCR입니다. 오래된 글에서 자주 틀리는 부분입니다. EasyOCR는 이제 선택적으로 켜는 기능입니다. OCR은 대규모 처리에서 느린 경로이며, 특히 CPU에서는 더 그렇습니다.

왜 Docling이 내 표를 이미지로 바꾸거나 아예 놓쳤나요? 대부분 sparse-page 효과 때문일 가능성이 큽니다. Docling의 RT-DETR 레이아웃 모델은 페이지 문맥을 사용하기 때문에, 주변 내용이 거의 없는 빈 페이지에 작은 표 하나만 있으면 Picture로 분류되어 오류 없이 사라질 수 있습니다. 같은 표라도 본문 텍스트에 둘러싸이면 잘 변환됩니다. 해결책은 레이아웃 모델에 페이지 문맥을 더 주거나, 변환 후 doc.tables를 확인해 표 개수가 0인 페이지를 표시하는 것입니다.

Docling과 Firecrawl 중 무엇을 써야 하나요? 역할이 다르기 때문에 보통은 둘 중 하나가 아니라 둘 다일 수 있습니다. Firecrawl은 라이브 웹을 크롤링하고, JavaScript를 렌더링하고, 본문을 추출합니다. Docling은 이미 보유한 문서를 변환하며, PDF 표 구조와 OCR을 오프라인으로 다룹니다. 소스가 웹 페이지라면 웹 도구(Firecrawl 또는 Thunderbit의 API/MCP/CLI)를 쓰세요. PDF, 스캔본, 오피스 파일이라면 Docling을 쓰세요. 현실의 대부분 파이프라인은 두 도구를 함께 사용합니다.