문서 파서를 리더보드로 고르면 실패한다
공모전 요강은 대부분 PDF나 HWP로 온다. 요약 공고만 보고 착수했다가 첨부 원문에만 있던 배점표를 놓친 적이 있어서, 첨부를 무조건 파싱해서 읽는 파이프라인이 필요했다.
그래서 "가장 좋은 PDF 파서"를 찾기 시작했다. 리더보드를 봤다. OmniDocBench 1위를 확인하고 그걸 쓰면 되겠다고 생각했다.
그게 틀렸다. 도구 137개를 훑고 나서 남은 결론은 어떤 모델이 1등이냐가 아니라, 내 검색 방식이 필요한 답을 구조적으로 못 보고 있었다는 것이다.
결론부터
| 용도 | 픽 | 출신 / 라이선스 |
|---|---|---|
| born-digital 한글, 로컬 + 오픈 | Hancom OpenDataLoader | 한컴 / Apache-2.0 |
| 스캔·손글씨 한글, 오픈 | PaddleOCR PP-OCRv5 또는 MinerU(-l korean) |
Baidu / Apache |
| 스캔·손글씨 한글, 최고 정확도 | Naver CLOVA OCR | 네이버 / 상업 API |
| 대규모 RAG 인제스천 | PaddleOCR-VL | Baidu / Apache |
핵심은 표 안이 아니라 표의 첫 열에 있다. born-digital과 스캔은 다른 문제다. 하나의 최강 도구로 둘 다 처리하려던 게 처음의 잘못된 전제였다.
텍스트 레이어가 살아 있는 PDF는 OCR이 필요 없다. 룰 기반으로 구조를 읽으면 CPU에서 페이지당 0.015초에 끝난다. 여기에 무거운 비전 모델을 태우면 느리고 비싸고 오히려 부정확하다. 반대로 스캔본에 룰 기반 파서를 태우면 아무것도 안 나온다.
그래서 최종 구조는 하나의 진입점 안에서 라우팅이다. 텍스트 레이어를 먼저 검사하고, 있으면 룰 기반, 없으면 한국어 OCR로 보낸다. 호출하는 쪽은 파일만 던지고 어디로 갔는지 신경 쓰지 않는다.
리더보드가 못 보여주는 세 가지
여기가 이 글의 본론이다. 왜 리더보드만 보면 위 표에 못 도달하는가.
1. 출신 편향
리더보드 상위는 거의 전부 중국발이다. Baidu, OpenDataLab, DeepSeek, Tencent, Alibaba. 그리고 OmniDocBench 자체가 중국 OpenDataLab이 만든 벤치마크다.
측정 언어가 중국어와 영어 중심이고 한국어는 다국어 항목 안에 부분적으로 묻힌다. 즉 종합 점수 1위가 한국어 성능 1위라는 보장이 없다. 벤치마크는 자기가 재기로 한 것만 잰다.
한컴이 만든 파서는 이 리더보드에 아예 안 올라온다. 내가 찾던 답이 내가 보던 표에 없었다.
2. 라이브러리 대 모델 편향
리더보드는 엔드투엔드 모델만 줄 세운다. 그런데 실무에서 바로 설치해 쓰는 건 대부분 라이브러리와 프레임워크다. Hancom, Marker, Docling, Unstructured 같은 것들.
이것들은 리더보드에 없다. 카테고리가 달라서 안 올라오는 것이지 나빠서가 아니다. 그런데 리더보드만 보면 존재 자체를 모른다.
여기에 한 겹 더 있다. 자체 벤치마크 함정이다.
opendataloader-bench에서 1위 = 한컴 (한컴이 만든 벤치)ParseBench에서 1위 = LlamaParse (LlamaParse가 만든 벤치)SCORE-Bench에서 1위 = Unstructured (Unstructured가 만든 벤치)
전부 사실이고 전부 자기 벤치다. "best overall"이라는 문구를 보면 점수보다 측정 주체를 먼저 봐야 한다.
3. 최신성 편향
이 분야는 몇 주 단위로 1위가 바뀐다. 버전 하나 올라갈 때마다 순위가 재배열된다.
그래서 최신만 쫓으면 반대쪽을 놓친다. CPU 결정론, 한국어 손글씨, 허용적 라이선스, 온프렘 배포 같은 안정성 요구는 오히려 성숙한 도구가 더 잘 만족한다. 최신 SOTA는 대개 그 축에서 검증이 덜 됐다.
내가 필요했던 건 매주 바뀌는 1위가 아니라 몇 달 뒤에도 같은 입력에 같은 출력을 내는 도구였다.
그래서 검색 방식을 바꿨다
"best PDF parser" 한 프레임으로는 이 세 편향을 통과할 수 없다. 그래서 축을 나눠서 쓸었다.
- 언어 축 — 한국어 전용 도구, 한국어 벤치마크
- 출신 축 — 한국, 중국, 미국, 유럽을 각각
- 카테고리 축 — 모델 / 라이브러리 / 상업 API / 온프렘 솔루션
- 최신성 축 — 최신 SOTA와 성숙한 표준을 따로
- 완전성 축 — "목록", "전체 비교", "대안" 류 쿼리
이렇게 137개가 모였다. 한 프레임으로 검색했다면 아마 스무 개쯤 봤을 것이고, 그 스무 개 안에 정답이 없었을 것이다.
이건 문서 파서에만 해당하는 얘기가 아니다. "가장 좋은 X"를 물을 때마다 같은 함정이 있다. 검색 결과 상위에 오르는 건 실력 순이 아니라 측정된 순이고, 측정하지 않은 것은 순위에 없는 게 아니라 목록에 없다.
남은 정직한 한계
- 한컴 파서는 born-digital 한글에서 로컬 실측으로 검증했다. 스캔본에서는 시험하지 않았다. 애초에 그 용도가 아니다.
- 상업 API의 정확도 수치는 제공사 발표를 인용한 것이고 내가 재현하지 않았다. 손글씨 정확도 같은 숫자는 그 상태로 표기해두고 결정 근거로는 약하게 썼다.
- 137개 중 실제로 돌려본 건 소수다. 나머지는 라이선스·언어 지원·입력 형식으로 필터링만 했다. "조사했다"와 "검증했다"는 다른 말이고, 섞어 쓰면 나중에 내가 속는다.
남은 질문
이 리서치를 하면서 제일 오래 걸린 건 도구를 비교하는 시간이 아니라 비교표에 뭘 올릴지 정하는 시간이었다. 후보를 잘못 모으면 그 뒤의 비교가 아무리 정교해도 소용이 없다.
그리고 후보를 모으는 단계는 대개 검토를 안 받는다. 비교표는 남에게 보여주지만 "이 스무 개를 어떻게 골랐나"는 아무도 안 묻는다.
다음에 도구를 고를 때 먼저 물어야 할 건 이거다. 내 후보 목록을 만든 검색어가, 내가 찾는 답을 구조적으로 배제하고 있지는 않은가?