PDF 변환에 AnyDoc 적용해보기

SW 마에스트로 프로젝트를 하며 작성하는 회고입니다.

기존에는 Docling과 AI를 함께 사용해 PDF를 Markdown으로 변환하고 있었다. Docling으로 문서를 읽고, 표나 수식처럼 손상되는 부분은 원본을 잘라 AI로 복원하는 방식이었다. PDF에서 내용이 빠지면 이후 Wiki를 만들거나 질문에 답할 때도 문제가 생기기 때문에, 이 부분을 계속 실험하고 있었다.

그러던 중 Threads에서 AnyDoc을 알게되었고, AnyDoc의 github를 보니 Docling보다 평가결과가 좋아 한 번 써봐야겠다고 생각했다. 이미 Docling으로 비교하던 문서와 결과가 있었기 때문에, 같은 문서를 넣어보면 어떤 차이가 있는지 알 수 있으니, A/B 테스트를 해보고 싶었다.

(변환 자체는 8월 10일에 했지만...글을 이제쓴다...)

내 생각보다 더 빠른데?

일단 기존에 사용하던 PDF 4개, 총 30페이지로 비교해봤다. AnyDoc 0.1.7로 변환한 시간은 CLI 실행 비용까지 포함해 합계 1.68초였다. 같은 문서를 기존 Docling으로 처리했을 때 남겨둔 기록은 134.19초, 약 2분 14초였다. 시간만 보면 약 80배 차이였다. 물론... Docling은 OCR과 정밀 표 분석까지 수행했고, AnyDoc은 PDF에 있는 텍스트를 추출했다. 하지만 솔직히 이 정도로 빠를 줄은 몰랐다.

처리하는 일이 달라 전체 파이프라인이 80배 빨라졌다고 볼 수는 없지만, 본문을 먼저 뽑아보는 용도로는 활용할 만했다. 그런데 결과를 열어보니 빠르다는 것만으로 교체하기는 어려웠다. 표와 수식의 손상뿐 아니라, 한 문서에서는 본문 글자 대부분이 깨져 있었다. 화면에서는 정상적으로 보이는 PDF였는데 추출한 텍스트는 읽을 수 없었다.

원인을 확인해보니 PDF 안에 글자 코드와 Unicode를 연결하는 정보가 빠져 있었다. 기존 Docling은 OCR로 글자 모양을 다시 읽어서 처리했지만, AnyDoc의 텍스트 추출에서는 그대로 깨진 것이다. 이런 이슈로 인해, 속도는 마음에 들었지만, 바로 Docling을 교체해 사용하기엔 애매했다. 표와 수식뿐 아니라 본문도 정상적으로 추출됐는지 확인해야 했기 때문이다. 변환 명령이 성공했다고 해서 내용을 제대로 변환했다는 보장이 없었다.

그래도 본문을 빠르게 추출할 수 있다는 점은 활용하고 싶었다. 기존 파이프라인에서는 표와 수식을 원본 crop으로 복원하고 있었으니, 이 과정은 유지하면서 본문 추출에 AnyDoc을 적용해볼 수 있겠다고 생각했다. 다만 그러려면 앞에서 발견한 것처럼 본문이 깨지는 경우도 확인하고 복원할 수 있어야 했다.

깨진 본문은 어떻게 처리하지?

AnyDoc이 추출한 본문을 그대로 사용하는 대신, 먼저 명확하게 문제가 생긴 페이지를 걸러냈다. 변환 자체가 실패했는지, 사용 중인 글꼴에 ToUnicode 정보가 빠져 있는지, 추출 결과에 � 같은 대체 문자가 들어 있는지 등을 확인했다. 앞에서 본 글꼴 인코딩 문제도 이 검사에 포함됐다. 이렇게 문제가 확인된 본문 페이지는 gpt-5.6-Luna 모델로 보내 복원했다. AnyDoc의 빠른 추출 결과를 활용하되, 읽지 못한 페이지에는 별도의 AI 처리를 붙인 것이다.

글자는 정상이어도 다단 문서의 읽는 순서가 섞이는 경우가 있어, 글자 깨짐을 검사하는 것만으로는 만족할만한 결과를 얻지 못했다.. 그래서 원본의 단어 순서와 추출 결과가 다른 페이지도 AI 처리 대상에 포함했다. 기존 30페이지 평가 표본에서 추가로 처리한 8페이지는 모두 같은 다단 문서에 있었고, 해당 문서의 블록 정확도는 LLM 평가 기준 59.62%에서 95.19%로 올라갔다.

이렇게 왼쪽을 먼저 다 읽고 넘어가야하는걸 다단 문서라고함!
┌─────────────┬─────────────┐
│ 왼쪽 본문 ①   │ 오른쪽 본문 ③ │
│ 왼쪽 본문 ②   │ 오른쪽 본문 ④ │
└─────────────┴─────────────┘

모든 오류가 사라진 것은 아니지만, 본문이 깨지거나 순서가 섞이는 문제를 별도 처리로 보완할 수 있었다. 이렇게 본문을 처리하고, 표와 수식은 기존처럼 원본 이미지를 이용해 복원했다.

표와 수식은 AI의 힘을 빌려보자

PDF에서 표를 텍스트로 추출하면 행과 열이 섞이기도 하고, 수식에서는 기호나 위첨자 등이 빠질 수 있다. 이때, 이렇게 깨진 텍스트만 AI에게 주면 원래 어떤 모양이었는지 추측해야 한다. 즉, 비교를 할 원본을 제공해줄 필요가 있다고 생각했다.

그래서 해당 부분의 원본을 이미지로 crop하여 제공했다. 표라면 표 전체를, 수식이라면 식이 있는 부분만을 잘라서 AI의 입력으로 함께 넣었다.

또한, 영역에 따라 처리 방법을 나누고, 각 결과를 마지막에 Markdown으로 조립했다.

본문은 AnyDoc, 표·수식은 원본 crop 기반 복원, 그림은 원본 이미지 보존으로 나눴다. 화살표는 처리 역할을 나타낸다.

본문은 앞에서 설명한 별도 복원 결과까지 반영해 조립했다. 따라서 최종 Markdown에는 AnyDoc의 추출 결과와 본문·표·수식의 AI 복원 결과가 함께 들어갔다. 이렇게 적용하고 보니 AnyDoc으로 전체를 교체했다기보다는, 기존에 만들던 파이프라인의 본문 추출 부분을 바꾼 것에 가까웠다.

이제 같은 기준으로 비교해보자

파이프라인을 수정했으니 같은 문서로 블라인드 테스트를 진행했다. 어떤 도구의 결과인지 숨기고, 원본 페이지와 잘라낸 영역을 함께 보여준 뒤 LLM이 판정하도록 했다. 본문과 제목은 내용을 활용할 수 있는 수준까지 인정했고, 표와 수식은 값과 기호, 구조가 정확해야 통과하도록 했다. 블라인드를 한 이유는 변환에 GPT모델을 사용했는데, 평가자또한 GPT라면 편향될 가능성이 존재했기 때문이다.

4개 PDF, 30페이지의 445개 블록을 비교한 결과는 다음과 같았다.

445개 블록 중 Docling 기준선은 201개, AnyDoc과 crop 복원을 결합한 경로는 400개가 통과했다.

여기서는 본문과 표·수식의 AI 복원까지 반영한 결과를 비교했다. 이번에는 기술 논문 PDF 4개를 LLM으로 평가했기 때문에, 다른 종류의 문서도 확인해봐야 한다. 그래도 기존 문서에서 어느 부분이 개선됐고 무엇이 여전히 남아 있는지는 볼 수 있었다.

그래서 처음부터 끝까지 얼마나 걸렸을까?

추출 시간이나 단계별 예상치만으로는 실제로 얼마나 빨라졌는지 알기 어려웠다. 그래서 같은 PDF 4개, 총 30페이지를 두 방식으로 다시 처리했다. 이번에는 이전 본문이나 표·수식 복원 결과를 재사용하지 않고 새로 생성했다. 명령을 실행한 시점부터 최종 Markdown을 저장하고 프로세스가 종료될 때까지 측정해, 준비·추출·복원·조립 시간을 모두 포함했다. (이게 현재 파이프라인 기준!)

문서	페이지	Docling	AnyDoc + AI 복원
serial	4	10.24초	22.45초
designing	6	24.75초	24.20초
multi	8	26.13초	21.92초
iet	12	76.32초	25.24초
합계	30	137.44초	93.81초

여기서 serial,designing,multi,iet는 모두 논문의 제목이다.

문서 네 개를 순서대로 처리한 시간은 약 2분 17초에서 1분 34초로, 43.63초(약 31.7%) 줄었다. 처음 AnyDoc만 실행했을 때의 1.68초와 달리, 이번에는 AI 복원까지 포함하고도 전체 처리 시간이 줄어든 것을 확인했다.

모든 문서가 빨라진 것은 아니었다. 4페이지인 serial은 오히려 더 오래 걸렸고, 가장 큰 차이는 12페이지인 iet에서 났다. 같은 Mac에서 각 경로를 한 번씩 실행한 결과이며, Docling은 OCR·정밀 표 분석을 사용했고 AnyDoc 경로는 Luna API를 최대 8개 병렬로 호출했다. 모델 파일의 디스크 캐시는 사용했지만 이전 변환·복원 결과는 공정성을 위해 사용하지 않도록 했다.

느낀점

새로운 오픈소스 성능이 궁금해 시작한 테스트였지만, 오픈소스만을 사용해서는 만족할만한 결과를 얻지 못했다... 하지만 속도가 굉장히 맘에 들었고, 실제로 현재 본문 추출에 활용하고, 표와 수식 복원은 기존의 crop 방식을 이어서 사용하고있다.

처음부터 모든 것을 해결하는 도구를 찾으려고 했다면 표와 수식이 깨지는 것을 보고 사용하지 않았을 수도 있을 것 같다. 하지만 우리가 이미 가지고 있던 복원 과정과 결합하니 사용할 수 있는 부분이 있었다.

하지만 여전히 실패가 남아 있다. 테스트해보지 못한 유형의 PDF들도 존재한다. 그래도 초기 타겟 사용자인 대학원생들을 위한 논문은 어느정도 테스트를 잘 해본 것 같다. 그래도 아직 아쉬운 수준으로 복구가 된다... 최근에 스캔문서나 손글씨도 OCR을 잘하는 모델이 생겨나고 있다고하니, 심심할 때, 사용해서 테스트해보아야겠다!

(https://paperswithcode.co/benchmark/omnidocbench-v1-6 OCR 벤치마크 사이트!)