[심층분석] OCR 비용 절반을 아끼는 교통정리 담당: Firecrawl의 Rust PDF 분류기 pdf-inspector

들어가며: PDF는 왜 이렇게 다루기 어려울까요?

RAG(검색 증강 생성) 파이프라인이나 문서 자동화를 만들어본 분이라면 다들 공감하실 텐데요. 웹 페이지나 마크다운 문서는 그럭저럭 파싱이 되는데, PDF만 만나면 갑자기 난이도가 확 올라가거든요. PDF라는 포맷 자체가 '사람 눈에 예쁘게 보이는 것'만을 목표로 설계됐기 때문이에요. 내부적으로는 '이 글자를 이 좌표에 이 폰트로 찍어라'라는 그리기 명령의 나열일 뿐, 문단이나 표 같은 구조 정보는 거의 없거든요.

그래서 많은 팀이 PDF를 만나면 그냥 전부 OCR(광학 문자 인식, 이미지에서 글자를 읽어내는 기술) 서비스로 던져버려요. AWS Textract나 Google Document AI 같은 서비스 말이죠. 그런데 이게 페이지당 과금이라 문서량이 조금만 늘어도 청구서가 무서워지고, 처리 속도도 페이지당 몇 초씩 걸려요.

여기서 재미있는 사실이 하나 있는데요. Firecrawl 팀의 분석에 따르면 실제 세상의 PDF 중 약 54%는 OCR이 전혀 필요 없는, 텍스트가 이미 들어있는 PDF라고 해요. 워드에서 '내보내기'로 만든 PDF들이 대표적이죠. 이런 PDF에 OCR을 돌리는 건, 이미 텍스트 파일이 있는데 굳이 그걸 프린트해서 다시 스캔하는 것과 똑같은 낭비거든요.

오늘 소개할 pdf-inspector는 바로 이 낭비를 잡아주는 도구예요. 웹 크롤링 API로 유명한 Firecrawl이 만든 Rust 라이브러리인데, PDF를 열어보고 '이건 텍스트 PDF니까 로컬에서 바로 뽑자', '이건 스캔본이니까 OCR로 보내자'를 똑똑하게 판단해주는 '문서 교통정리 담당'이라고 보시면 돼요.

기술 분석: 10~50ms 만에 PDF의 정체를 알아내는 법

1. 스마트 분류 — 겉만 슬쩍 보고 판단하기

pdf-inspector의 핵심은 분류(classification)예요. PDF를 TextBased(텍스트 기반), Scanned(스캔본), ImageBased(이미지 기반), Mixed(혼합형) 네 가지로 나누는데, 이걸 10~50ms 만에 해내요.

비결은 '전체를 다 읽지 않는 것'이에요. PDF 내부에는 콘텐츠 스트림(content stream)이라는, 페이지에 뭘 그릴지 적어둔 명령 목록이 있는데요. pdf-inspector는 이 스트림을 샘플링해서 — 그러니까 일부만 골라 슬쩍 들여다보고 — 텍스트 그리기 명령이 많은지, 이미지 붙이기 명령만 있는지 통계를 내요. 책 전체를 읽지 않고 목차와 몇 페이지만 훑어보고 장르를 맞히는 것과 비슷하죠.

그리고 결과를 그냥 예/아니오로 주지 않고 0.0~1.0 사이의 신뢰도 점수(confidence score)로 줘요. 게다가 페이지 단위 OCR 라우팅 정보까지 주는데, 이게 실무에서 진짜 유용해요. 예를 들어 100페이지짜리 계약서에서 본문 95페이지는 텍스트고 마지막 5페이지만 스캔한 도장 페이지라면, 그 5페이지만 OCR로 보내면 되거든요. OCR 비용이 1/20로 줄어드는 거죠.

2. 위치 인식 텍스트 추출과 마크다운 변환

텍스트 PDF로 판정되면 그 자리에서 바로 추출까지 해줘요. 참고로 문서는 한 번만 파싱해서 분류와 추출이 공유하는 구조라, 판별 따로 추출 따로 두 번 읽는 낭비가 없어요. 그리고 단순히 글자만 긁는 게 아니라 폰트 정보와 X/Y 좌표를 함께 뽑는데요. 이 좌표 정보가 있어야 신문처럼 여러 단으로 나뉜 문서(멀티컬럼)에서 읽는 순서를 제대로 복원할 수 있어요. 좌표 없이 글자를 순서대로 뽑으면 왼쪽 단 첫 줄과 오른쪽 단 첫 줄이 뒤섞여서 문장이 엉망이 되거든요.

마크다운 변환 로직도 꽤 영리해요:

• 제목 감지: 폰트 크기 비율을 보고 H1~H4 헤딩을 판단해요. 본문보다 두 배 큰 글자면 아마 제목이겠죠.
• 코드 블록: 고정폭(monospace) 폰트를 쓴 영역을 코드 블록으로 변환해요.
• 표 감지: 두 가지 방식을 병행해요. PDF의 사각형 그리기 명령(선이 그려진 표)을 보는 방식과, 텍스트 정렬 패턴(선 없는 표)을 보는 휴리스틱 방식이죠. 재무제표처럼 페이지를 넘어가며 이어지는 표도 처리한다고 해요.
• 리스트, 볼드/이탤릭, URL 링크, 페이지 구분까지 지원해요.

결과물이 마크다운이라는 게 포인트인데요. LLM에 문서를 넣을 때 마크다운이 사실상 표준 포맷이 됐기 때문이에요. 제목 구조가 살아있는 마크다운은 청킹(문서를 의미 단위로 조각내는 작업)할 때도 훨씬 유리하고요.

3. 한국 개발자가 주목할 부분: CID 폰트 지원

이 부분이 한국어 사용자에게 특히 중요한데요. 한글, 중국어, 일본어 같은 CJK 문자를 담은 PDF는 대부분 CID 폰트(Type0/Identity-H)라는 방식을 써요. 글자를 유니코드로 직접 저장하는 게 아니라, 폰트 내부의 글리프 번호로 저장하고 ToUnicode CMap이라는 변환표를 따로 두는 구조거든요. 쉽게 말해 암호문과 해독표가 분리돼 있는 셈이에요.

허술한 PDF 라이브러리로 한글 PDF에서 텍스트를 뽑으면 네모 상자나 외계어가 나오는 이유가 바로 이 CMap 해독을 제대로 못 해서예요. pdf-inspector는 ToUnicode CMap 디코딩을 정식 지원하고, UTF-16BE 같은 인코딩도 처리해요. 더 좋은 건, 폰트 인코딩이 깨져서 해독이 불가능한 경우를 자동으로 감지해서 '이 문서는 OCR로 우회하세요'라고 알려준다는 점이에요. 조용히 깨진 텍스트를 뱉는 것보다 훨씬 안전한 설계죠.

4. Rust + 다양한 바인딩 + 브라우저 WASM

코어는 순수 Rust로 작성됐고 ML 모델이 전혀 없어요. 그래서 가볍고 빠르고, 배포할 때 GPU나 무거운 의존성이 필요 없어요. Python과 Node.js 바인딩이 있어서 기존 파이프라인에 바로 끼워 넣을 수 있고요.

특히 눈에 띄는 건 브라우저 WebAssembly(WASM) 지원이에요. WASM이 뭐냐면, Rust 같은 언어로 만든 프로그램을 브라우저 안에서 네이티브에 가까운 속도로 돌리는 기술인데요. CMap까지 내장해서 서버 왕복 없이 브라우저나 웹 워커에서 PDF를 파싱할 수 있어요. 사용자가 올린 PDF를 서버로 보내지 않고 처리할 수 있으니, 민감한 문서를 다루는 서비스에서 개인정보 측면의 이점이 커요.

업계 맥락: 기존 도구들과 뭐가 다른가요?

PDF 텍스트 추출 도구는 이미 많아요. Python 진영의 PyMuPDF나 pdfplumber, JS 진영의 pdf.js가 대표적이죠. 그런데 pdf-inspector의 포지션은 조금 달라요.

• PyMuPDF/pdfplumber: 추출 자체는 잘하지만 '이 PDF가 OCR이 필요한가'를 판단해주는 분류가 핵심 기능이 아니에요. 라우팅 로직은 직접 짜야 하죠.
• marker, unstructured 같은 ML 기반 도구: 레이아웃 분석 품질은 좋지만 모델을 돌려야 해서 무겁고 느려요. GPU가 있으면 좋고요.
• Textract/Document AI 같은 클라우드 OCR: 스캔본에는 최강이지만, 텍스트 PDF에까지 쓰면 돈 낭비예요.

한국 개발자에게 주는 시사점

구체적인 활용 시나리오를 그려볼게요.

시나리오 1: 사내 문서 RAG 챗봇. 회사 규정집, 계약서, 보고서 PDF 수천 건을 벡터 DB에 넣는다고 해봐요. 지금 전부 OCR API로 보내고 있다면, 앞단에 pdf-inspector 분류만 붙여도 비용이 절반 가까이 줄 수 있어요. Python 바인딩이 있으니 기존 파이프라인 수정은 분류 함수 호출 하나 추가하는 수준이에요.

시나리오 2: 공공데이터·논문 수집. 정부 보도자료나 학술 PDF는 대부분 텍스트 기반이에요. 이런 건 OCR 없이 즉시 마크다운으로 바꿔서 LLM에 넣으면 되죠. 다만 한글 PDF는 폰트 임베딩 방식이 제각각이라, 도입 전에 여러분이 실제로 다루는 문서 샘플 100건 정도로 추출 품질을 꼭 검증해보세요. 인코딩 깨짐 감지 기능이 있으니, 실패 케이스는 자동으로 OCR로 넘기는 안전망도 함께 구성하고요.

학습 로드맵으로는, 먼저 PDF 내부 구조(콘텐츠 스트림, 폰트, CMap)를 가볍게 훑어보시길 권해요. 이걸 알면 어떤 추출 도구를 쓰든 결과가 왜 이렇게 나오는지 이해가 되거든요. 그다음 pdf-inspector의 분류 → 추출 → 폴백(실패 시 OCR로 우회) 흐름을 작은 스크립트로 직접 짜보면, 문서 파이프라인 설계 감각이 확 늘어요.

마무리

LLM 시대에 '문서를 얼마나 싸고 빠르게 텍스트로 바꾸느냐'는 순수하게 비용 문제이자 경쟁력 문제가 됐어요. pdf-inspector 같은 스마트 라우팅 도구는 '모든 문서에 가장 비싼 처리를 하지 말고, 필요한 만큼만 하자'는 흐름의 신호탄으로 보여요. 앞으로 이런 '판별 후 라우팅' 패턴은 이미지, 오디오 처리 파이프라인에도 퍼질 가능성이 커요.

여러분의 파이프라인에서는 PDF를 어떻게 처리하고 계신가요? 전부 OCR로 보내고 계셨다면, 그중 몇 %가 사실 텍스트 PDF였을지 한번 측정해보시는 건 어떨까요? 한글 PDF 추출 품질에 대한 경험담도 댓글로 공유해주시면 좋겠어요.