러스트로 만든 의존성 없는 문서 추출기 udoc 공개

• udoc은 러스트(Rust)로 만든 문서 추출 도구임. 핵심 메시지는 꽤 선명함. “외부 의존성 없이 문서에서 텍스트, 표, JSON, 렌더링 페이지를 뽑겠다”는 것

  • CLI, 파이썬 바인딩, 순수 러스트 API를 제공함
  • 라이선스는 MIT / Apache-2.0 듀얼 라이선스라 상업 프로젝트에도 붙이기 부담이 적은 편

• 지원 포맷이 꽤 넓음. 단순 PDF 추출기라기보다는 오피스 문서까지 커버하려는 쪽임

  • PDF, DOC, DOCX, XLS, XLSX, PPT, PPTX 지원
  • ODT, ODS, ODP, RTF, Markdown도 포함
  • 특히 레거시 바이너리 오피스 포맷인 .doc, .xls, .ppt에 네이티브 파서를 제공한다고 강조함

• 제일 중요한 차별점은 dependency-free임. 외부 파서, 라이브러리, 시스템 패키지를 요구하지 않는다고 함

  • 운영 환경에서 문서 추출기는 보통 poppler, libreoffice, tesseract 같은 외부 도구 조합으로 엮이다가 배포가 지저분해지는 경우가 많음
  • udoc은 이 지점을 줄여서 단일 도구처럼 쓰게 만드는 걸 목표로 잡은 듯함

• 내부 구조는 포맷별 결과를 하나의 Document 모델로 맞추는 방식임

  • 본문은 Block과 Inline 노드로 구성된 content spine으로 표현함
  • 발표 자료의 표현 정보, 문서 간 관계, 인터랙션 같은 정보는 optional overlay로 붙음
  • Config에서 필요 없는 overlay는 끌 수 있음. 파싱 결과를 가볍게 만들 수 있다는 얘기

• 큰 파일 처리도 신경 쓴 흔적이 있음. 10GB PDF를 통째로 메모리에 올리지 않아도 된다고 설명함

  • Extractor가 페이지별 작업을 지연시키는 구조
  • 대용량 계약서 묶음, 스캔 문서 저장소, 내부 지식베이스 인덱싱 같은 배치 작업에서 의미가 있음

• 진단 정보는 문자열 로그가 아니라 typed diagnostics로 제공됨

  • 폰트 fallback, malformed xref, stream length mismatch 같은 문제를 종류별로 필터링 가능
  • 운영에서 특정 문서만 이상하게 깨질 때 “그냥 실패”가 아니라 원인별 집계가 가능해지는 쪽임

• OCR, 레이아웃 감지, 엔티티 추출은 훅으로 빼뒀음. 이 선택이 꽤 현실적임

  • Tesseract, 클라우드 OCR API, DocLayout-YOLO, GLM-OCR, 비전 언어 모델, NER 같은 외부 도구를 붙일 수 있음
  • 프로토콜은 JSONL 기반이라 subprocess가 한 줄씩 JSON을 읽고 쓰는 형태
  • 모든 걸 내장하려다 무거워지는 대신, 코어는 문서 구조화에 두고 인식 계층은 교체 가능하게 만든 셈

• PDF 표 감지와 읽기 순서는 휴리스틱이라고 솔직히 적혀 있음

  • born-digital 문서처럼 선이 깔끔하고 컬럼 흐름이 표준적인 경우는 기본 추출이 잘 된다고 함
  • 반대로 복잡한 레이아웃이나 스캔 문서는 레이아웃 감지나 OCR 훅을 붙여야 하는 케이스로 안내함

• LLM tool use를 위한 안내 페이지도 제공함. 요즘 문서 추출기의 사용처를 정확히 보고 있는 느낌임

  • 에이전트에게 udoc CLI 사용법을 붙여 넣을 수 있는 instructions 페이지가 있음
  • 문서 → 청크 → 검색/요약/질의응답으로 이어지는 워크플로를 의식한 설계로 보임

---

기술 맥락

• udoc의 핵심 선택은 “문서 포맷마다 따로 처리하지 말고, 공통 Document model로 먼저 모으자”예요. PDF, DOCX, PPTX는 내부 구조가 완전히 다르기 때문에, 후속 파이프라인이 포맷별 예외를 계속 알게 되면 유지보수가 금방 지옥이 되거든요.

• dependency-free를 내세운 이유도 운영 관점에서는 꽤 커요. 문서 추출 파이프라인은 로컬에서는 잘 되는데 서버 이미지, 샌드박스, 서버리스 환경에서 외부 바이너리 때문에 터지는 일이 많아요. 러스트 단일 도구에 가깝게 가져가면 배포와 재현성이 훨씬 단순해져요.

• OCR과 레이아웃 감지를 내장하지 않고 JSONL 훅으로 뺀 것도 현실적인 타협이에요. OCR 모델은 계속 바뀌고, 문서 종류마다 잘 맞는 도구도 다르니까요. 코어 추출기는 안정적으로 두고, 인식 모델만 교체할 수 있으면 RAG나 사내 문서 검색 파이프라인에 붙이기 좋아요.

• 10GB PDF를 페이지 단위로 처리한다는 점은 단순 최적화가 아니에요. 대규모 문서 배치에서는 메모리 사용량이 비용과 실패율로 바로 이어지거든요. 스트리밍 추출은 “한 번에 다 읽고 실패”가 아니라 “처리 가능한 단위로 나눠 진행”하게 해주는 설계예요.