Docling 리뷰: IBM의 문서→Markdown 변환기는 PDF를 실제로 어떻게 다루나

Docling은 자꾸 웹 스크래퍼랑 같은 선상에 놓이곤 하지만, 사실은 완전히 다른 도구입니다. IBM Research가 만들고 현재는 LF AI & Data Foundation 프로젝트로 운영되는 문서 변환 툴킷으로, 이미 가지고 있는 파일(PDF, DOCX, PPTX, XLSX, HTML, 이미지)을 Markdown이나 JSON으로 바꿔줍니다. 공식 슬로건도 딱 그 말 그대로, “Get your documents ready for gen AI.”입니다.

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

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을 대체하느냐고 물을 때도 이 차이가 중요합니다. 결론부터 말하면, 대체가 아니라 보완 관계입니다. 이유는 뒤에서 설명하겠습니다.

처음 실행할 때 아무도 안 알려주는 것

pip install docling은 Python 3.14.2에서 깔끔하게 성공합니다. 그런데 가상환경을 열어 보면 용량이 1.3 GB입니다. Docling은 HTML만 변환하더라도 전체 ML 스택을 필수 의존성으로 끌고 옵니다.

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

이건 PDF 하나 변환하기 전의 이야기입니다. 진짜 마찰은 첫 PDF 변환에서 생기는데, 그때 모델 다운로드가 시작되기 때문입니다. 새로 만든 HuggingFace 캐시 환경에서는 첫 PDF 변환에 약 224초가 걸렸고, 거의 전부가 연산이 아니라 다운로드 시간이었습니다. 레이아웃 + TableFormer 모델은 디스크 기준 약 506 MiB(TableFormer 342 MiB + 레이아웃 164 MiB, du로 검증)이며, RapidOCR는 PP-OCRv4 가중치 약 40 MB를 site-packages 안으로 가져옵니다. 같은 파일을 두 번째로 변환하면? 0.55초입니다. 모델이 캐시되기 때문에, 비용은 한 번만 내면 됩니다.

하나 헷갈리기 쉬운 숫자가 있습니다. coldstart 스크립트는 model_download_mb를 1060.2로 출력하지만, 이걸 저장공간 사용량으로 그대로 인용하면 안 됩니다. os.walk가 심볼릭 링크를 따라가서 생긴 숫자이기 때문입니다. HuggingFace 캐시는 모델 파일을 blobs/ 아래에 한 번만 저장하고, snapshots/에서는 심볼릭 링크로 다시 보여줍니다. 그래서 순회하면 14개 모델 파일이 두 번 세어집니다. du와 맞는, 심볼릭 링크 중복을 제거한 수치는 약 506 MiB입니다(블롭만 보면 505.4 MiB). Docling을 벤치마킹할 때는 다운로드 바이트와 디스크 바이트를 따로 써야 합니다. 두 값은 다르니까요.

Docling 컨테이너를 만들 때 또 하나 걸리는 점이 있습니다. 가중치가 두 위치에, 두 일정으로 나뉘어 내려갑니다. 레이아웃과 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월부터 issue #3733로 열려 있습니다.

표 정확도: TableFormer가 빛을 발하는 지점

표야말로 사람들이 단순 PDF 텍스트 덤프 대신 Docling을 찾는 이유입니다. 그래서 기계가 읽을 수 있는 정답이 있는 표 PDF 7개를 만들어 셀 단위로 채점했습니다. 여기서 중요한 지표는 둘이고, 둘은 같은 뜻이 아닙니다. cell recall은 감지된 표 안 어딘가에 정답 값이 존재하는 비율이고, in-row rate는 그 값이 올바른 행에 들어간 비율입니다. 이 둘을 섞어서 말하면 도구를 지나치게 좋게 보이게 하니까, 둘 다 보여드리겠습니다.

표(스트레스 테스트)	감지 여부	Cell recall	In-row rate	비고
T1 테두리가 있는 단순 그리드(8행 × 5열), 페이지 단독 배치	아니오	0.0	—	<!-- image -->로 분류, 모든 셀 유실
T2 테두리 없음(헤더 구분선만 있음)	예	1.00	1.00	정확히 복원, 완전한 그리드
T3 2단계 colspan 머지가 있는 헤더	예	1.00	0.97	모든 값은 찾았지만, 헤더 값 하나가 행을 벗어남
T4 rowspan이 들어간 행 라벨, 페이지 단독 배치	아니오	0.0	—	<!-- image -->로 분류
T5 colspan 헤더 + 테두리 없음	예	1.00	0.97	모든 값은 찾았고, T3와 같은 헤더 행 이동 발생
T6 재무표, 빈 열, 오른쪽 정렬	예	1.00	1.00	빈 열도 유지, 밀리거나 합쳐지지 않음
T7 12열 와이드 그리드	예	1.00	1.00	넓은 표에서도 열 밀림 없음

Docling이 감지한 5개 표에서는 정답 값이 전부 살아서 나왔습니다. cell recall은 전부 1.00이었습니다. 그중 3개는 값이 모두 올바른 행에도 들어갔습니다. 하지만 다단 헤더가 있는 2개(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은 아주 평범한 테두리 있는 8행 5열 표입니다. 이 정도면 표 파싱의 약점이라고 단정하기가 꺼려져서, 실제로 무엇이 문제를 일으키는지 분리하려고 스크립트로 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"도 3개 행에 걸쳐 정확히 반복됐습니다. 표는 똑같았습니다. 바뀐 변수는 그것이 빈 페이지에 혼자 놓였는지, 아니면 본문에 포함됐는지뿐이었습니다.

즉, 진짜 주의점은 TableFormer가 약하다는 게 아닙니다. Docling의 RT-DETR 레이아웃 모델이 페이지 문맥을 사용하기 때문에, 주변이 거의 비어 있는 페이지에 작은 표 하나만 있으면 Picture로 읽혀 조용히 버려질 수 있다는 점입니다. 인보이스, 사양서, 잘라낸 내보내기 파일처럼 실제 업무 문서가 딱 이런 모습이라서 이 문제가 의외로 자주 나타납니다. 해결책은 단순하고 효과적입니다. 레이아웃 모델에 페이지 문맥을 더 주거나, 변환 후 doc.tables를 다시 확인해 표 개수가 0인 페이지를 표시하면 됩니다. 이건 issue #3495와 인접한 문제입니다(표가 Table과 Picture 둘 다로 감지됨). 하지만 페이지가 너무 비어 있을 때만 같은 표가 사라지고, 문맥이 있으면 잘 들어오는 이 특정 트리거는 공개 문서에서 찾지 못했습니다. 측정해 본 것이고, 이전에 문서화되지 않았던 현상입니다. 아무도 몰랐던 버그라고 단정할 수는 없지만, 적어도 제가 확인한 범위에서는 새롭게 드러난 케이스였습니다.

실제 스캔에서의 OCR: EasyOCR이 아니라 RapidOCR

스캔 PDF는 변환기들이 조용히 무너지는 경우가 많습니다. 그래서 텍스트 레이어가 측정상 0자인 진짜 스캔 2개를 Docling에 넣었습니다. 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는 4페이지 모두에 OCR을 돌려 총 70.1초(페이지당 17.5초)가 걸렸고, 각 페이지마다 테스트 문장이 반복되어 나왔습니다. 기본 OCR은 자동으로 동작했습니다. 별도 플래그도, 설정도 필요 없었습니다.

많은 글이 놓치는 핵심은 이겁니다. 기본 OCR 엔진은 EasyOCR이 아니라 RapidOCR입니다. 첫 실행 때 PP-OCRv4 .pth 가중치가 다운로드되는 것을 확인해 이 점을 검증했습니다. 이미 나온 블로그나 오래된 Docling FAQ는 아직도 EasyOCR이 기본이라고 적는 경우가 많지만, 그건 옛 정보입니다. EasyOCR은 이제 선택적으로 추가하는 옵션입니다. 하지만 변함없이 맞는 경고도 있습니다. OCR은 대규모 처리에서 느린 경로라는 점입니다. 여기 수치는 모두 CPU 전용 상한선이며, GPU를 쓰면 시간은 훨씬 줄어듭니다.

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

가짜 데이터는 특정 동작을 증명하고, 실제 PDF는 도구가 정말로 작동하는지 보여줍니다. 그래서 두 개의 디지털 생성 학술 논문 — 9페이지짜리 Docling 기술 보고서와 15페이지짜리 “Attention Is All You Need” — 를 테스트했습니다. 둘 다 2단 편집에 표와 수식이 들어 있는 문서입니다.

15페이지짜리 Attention 논문에서는 Abstract, Introduction, Background, Conclusion, References라는 5개 섹션 마커가 모두 2단 레이아웃임에도 Markdown 선형화 결과에서 문서 순서대로 나타났습니다. Transformer, encoder, BLEU, multi-head 같은 내용 포인트도 모두 있고, 유명한 다단 결과표는 감지된 표 4개로 잡혔습니다. 이것이 바로 읽기 순서와 열 병합 복원입니다. RAG 청킹에서 가장 중요한 가치죠. 2단 페이지를 엉망으로 뒤섞는 선형화 결과로는 문서를 제대로 청킹할 수 없기 때문입니다.

시간에서는 조금 반직관적인 교훈이 보였습니다. 페이지당 시간은 총 페이지 수보다 페이지마다 들어 있는 구조의 양에 더 크게 좌우됩니다. 더 밀도 높은 9페이지 보고서는 페이지당 14.95초로, 15페이지 논문보다 더 느렸습니다(15페이지 논문은 페이지당 5.99초). 이유는 페이지마다 더 많은 표와 그림이 들어 있어서입니다. 9페이지에 표 3개, 15페이지에 표 4개인데, 각 요소가 추가 레이아웃 및 TableFormer 추론을 유발합니다. 즉, 차이는 작고, 절대적으로 보면 더 밀도 높은 문서가 더 많은 표를 가진 것도 아닙니다. 결론은 이겁니다. CPU에서의 “페이지당 초”는 문서 길이가 아니라 구조 밀도의 함수입니다. 그리고 이것도 단일 CPU 실행 결과일 뿐, 프로덕션 수치는 아닙니다.

멀티 포맷과 무손실 JSON 주장

Docling은 통합 멀티 포맷 파싱을 내세우므로, DOCX, XLSX, PPTX를 각각 하나씩 만들고 정답이 알려진 probe를 심은 뒤 두 가지를 확인했습니다. Markdown에 probe가 나타나는지, 그리고 export_to_dict()를 통해 JSON으로 round-trip해도 살아남는지입니다.

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

모든 probe가 Markdown에 들어왔고, 표도 복원됐습니다(DOCX의 병합된 "Total" 행과 XLSX의 두 시트 모두 포함). 그리고 모든 probe가 export_to_dict() JSON에도 살아남았습니다. 깨끗한 입력이라면, 이게 바로 무손실 DoclingDocument 주장에 대한 증거입니다. 적어도 여기서는 그렇습니다. 이 형식들은 ML 모델이 아니라 포맷별 네이티브 백엔드를 통과하므로, 수십 밀리초 단위로 빠르게 돌고 완전히 오프라인에서도 동작합니다. 범위는 솔직합니다. 포맷별로 깨끗한 파일 하나씩은 폭넓은 지원을 보여줄 뿐, 병적인 Office 파일에 대한 스트레스 테스트는 아닙니다.

HTML: 충실하지만 깔끔하진 않다

이 대목이 RAG 파이프라인에 Docling을 넣을지 말지를 결정하므로, 꼭 주의해서 보셔야 합니다. Docling은 HTML 문서 전체를 변환합니다. Readability 스타일의 본문 추출은 하지 않습니다. 사이트의 상단 메뉴, 목차, 쿠키 배너, 푸터 같은 장식 요소가 얼마나 남는지, Docling 자체 출력에서 관련 마커 라인의 개수로 측정했습니다.

페이지	비어 있지 않은 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%가 내비게이션/목차/푸터 보일러플레이트이고, 실제 본문은 28번째 줄이 돼서야 시작합니다. 출력은 "move to sidebar / Contents / Toggle the table of contents"로 열리고, "CS1 maint… / Search Wikipedia"로 끝납니다. 반면 books, quotes 같은 깔끔한 콘텐츠 페이지에서는 거의 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, 감지된 fixture에서 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

한 줄 요약은 이렇습니다. Firecrawl은 데이터가 라이브 웹에 있고 크롤링, JS 렌더링, 본문 정리가 필요할 때 쓰는 도구입니다. Docling은 이미 문서를 가지고 있을 때, 특히 PDF, 스캔, 표가 많은 Office 파일을 오프라인에서 구조를 보존하며 변환하고 싶을 때 쓰는 도구입니다. 둘은 서로를 대체하지 않고 보완합니다. 현실적인 파이프라인은 하나로 크롤링하고, 다른 하나로 문서를 변환합니다.

여기서 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이 애초에 하지 않는 일(예: 크롤링)에 벌점을 주는 꼴이 되고, 서로 비교 불가능한 항목을 억지로 같은 잣대로 재는 셈이 되기 때문입니다. 제가 테스트한 fixture 기준으로 보면:

• 설치 / 첫 실행: 무거움 — 1.3 GB 가상환경, 모델 약 506 MiB, 첫 PDF 약 224초, warm 상태 약 0.55초 — 하지만 docling-slim으로 무게를 피할 수 있음.
• 표 정확도: 표가 감지되면 강함(cell recall 5/5에서 1.00, in-row 0.97–1.00), 공식 TEDS 이야기와도 맞음.
• 표 감지 안정성: sparse-page 함정이 있음. 표 하나만 덩그러니 있으면 Picture로 빠질 수 있으니 doc.tables를 확인해야 함.
• 스캔 / OCR: 동작함, 기본값은 RapidOCR. 다만 대규모에서는 느림.
• 멀티 포맷: 안정적이며 JSON round-trip도 유지됨.
• HTML: 충실하지만 깔끔하진 않음. 본문만 뽑지 않음.
• 개발자 경험: 3줄짜리 깔끔한 API와 정돈된 DoclingDocument, 다만 __version__ 노출은 빠져 있음.

누구에게 맞나? PDF, 스캔, Office 파일 위에서 오프라인으로 구조를 보존하는 변환과 실제 표/OCR 이해가 필요한 RAG 또는 데이터 파이프라인 팀입니다. 누구에게 맞지 않나? 라이브 웹 크롤링이나 깔끔한 HTML 본문 추출이 필요한 사람입니다. 그건 다른 도구의 일입니다.

그리고 이건 홍보물이 아니라 리뷰이므로, 한계도 그대로 적겠습니다. 이건 타깃 테스트입니다. CPU 전용 머신 1대에서 7개의 합성 표와 2개의 실제 PDF만 봤습니다. TEDS 수준 정확도 벤치마크가 아닙니다. 제가 테스트하지 않았고, 실제로 도입하기 전에 여러분이 꼭 확인해야 할 것들도 있습니다. 선택적 VLM(GraniteDocling) 경로, 실제 docling-slim 용량, GPU 실행, 복잡하고 비정형적인 병합 셀과 다페이지 표, 수식을 LaTeX로 바꾸는 정밀도, 그리고 프로덕션에서 가장 놀라울 수 있는 것 — 배치가 길어질수록 메모리가 늘어나는지, 스레드/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에서 Docling의 OCR은 자동으로 동작했고, 제 테스트에서는 텍스트를 깔끔하게 복구했습니다. 기본 엔진은 오래된 글에서 흔히 말하는 EasyOCR이 아니라 RapidOCR입니다. EasyOCR은 이제 선택 설치 옵션입니다. OCR은 대규모에서 느린 경로이며, 특히 CPU에서는 더 그렇습니다.

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

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