anydoc 심층 리뷰: Firecrawl이 Rust로 만든 만능 문서 Markdown 변환 도구

TL;DR: 대규모 언어 모델에 문서를 공급할 때, 형식 변환 품질이 RAG 효과를 직접 결정합니다 — 테이블이 손실되거나, 제목이 엉망이 되거나, 수식이 사라지면 정보도 손실됩니다. Firecrawl 팀은 Rust로 anydoc을 처음부터 만들었습니다. 14가지 오피스 형식(Word/PPT/Excel/PDF/EPUB/RTF/CSV/OpenDocument)을 커버하는 하나의 라이브러리로, 중앙값 변환 속도는 불과 4.4밀리초이며, Pandoc, Markitdown, Docling 등 경쟁사를 품질에서 완전히 압도합니다. GitHub에 올라온 지 3주도 안 되어 17,000개 이상의 Star를 획득했습니다. 이 글에서는 아키텍처 원리부터 배포 실전까지, 2026년 가장 뜨거운 문서 전처리 도구를 완전히 이해하도록 안내합니다.

1. anydoc이란? Firecrawl 팀의 "문서 전처리 엔진"

anydoc은 Firecrawl 팀이 2026년 8월 초에 오픈소스로 공개한 Rust 라이브러리로, 하나의 문제를 해결합니다: 다양한 오피스 문서 형식을 깔끔한 GitHub-Flavored Markdown으로 통일하여 변환.

Firecrawl은 잘 알려진 웹 스크래핑 및 파싱 API 서비스(Y Combinator 지원 프로젝트)입니다. 문서 파싱을 수행하면서 보편적인 문제를 발견했습니다: 시중의 어떤 라이브러리도 모든 일반적인 문서 형식을 안정적으로 처리할 수 없었습니다. 개발자들은 네다섯 개의 도구를 조합해야 했습니다 — 각 도구마다 자체 의존성, 출력 형식, 실패 모드가 있었습니다. 그래서 그들은 직접 만들기로 결정했고, 하나도 아닌 두 개를 만들었습니다:

• pdf-inspector: PDF 전문, 13k Star, 각 페이지가 텍스트인지 스캔인지 판단하여 OCR 필요 여부 결정
• anydoc: 다른 모든 형식(Word/PPT/Excel/EPUB/RTF/CSV/OpenDocument) 처리, 텍스트 기반 PDF 처리를 위해 pdf-inspector 내장

두 라이브러리, 동일한 설계 철학: 순수 Rust, 로컬 실행, API 키 없음, 시스템 의존성 없음, Markdown 출력.

문서 바이트
  │
  ├─► 형식 감지          → 콘텐츠 마커 기반, 확장자에 의존하지 않음
  │
  ├─► 형식 파서         → 각 형식당 하나의 파서(doc/docx/ppt/pptx/xls/
  │                        xlsx/odt/ods/odp/rtf/epub/csv)
  │         │
  │         └─► Document → 공유 문서 모델: 블록, 인라인, 테이블, 각주, 리소스
  │               │
  │               └─► GFM 직렬화기 → Markdown
  │
  └─► PDF → pdf-inspector → 직접 Markdown 출력

핵심 설계: 모든 형식이 동일한 문서 모델과 직렬화기로 수렴. 이는 한 형식의 버그(예: 테이블 이스케이프)를 수정하면 다른 모든 형식이 자동으로 혜택을 받음을 의미합니다.

2026년 8월 21일 기준, anydoc의 GitHub 데이터:

2. 왜 문서 변환이 RAG에 중요한가?

RAG(Retrieval-Augmented Generation) 아키텍처에서 대규모 언어 모델의 지식 출처는 학습 데이터뿐만 아니라 사용자가 제공하는 비공개 문서도 포함됩니다. 이러한 문서는 다음과 같을 수 있습니다:

• 고객이 업로드한 Word 계약서
• 재무 부서에서 내보낸 Excel 보고서
• 제품 매니저가 만든 PPT 프레젠테이션
• 기술 팀이 작성한 PDF 백서
• 오래된 .doc 파일(2003년 이전 형식)

형식 손실 = 정보 손실. 변환 도구가 테이블을 순수 텍스트로 평평하게 만들거나, 제목 계층을 엉망으로 만들거나, 수식을 알아볼 수 없는 문자로 바꾸면, 대규모 언어 모델은 불완전한 정보를 받게 됩니다. RAG 효과가 직접적으로 감소합니다.

구체적인 예를 들어보겠습니다: Word 문서에 지역, 분기, 매출액의 세 열이 포함된 판매 데이터 테이블이 있습니다. 저품질 변환 도구는 다음과 같이 출력할 수 있습니다:

지역 분기 매출액
동북 Q1 100만
동북 Q2 150만

테이블 구조가 손실되어 대규모 언어 모델은 "지역"과 "분기"가 열 이름이고, "100만"이 "동북 Q1"의 매출액임을 이해할 수 없습니다. 반면 anydoc은 표준 Markdown 테이블을 출력합니다:

| 지역 | 분기 | 매출액 |
|------|------|--------|
| 동북 | Q1   | 100만  |
| 동북 | Q2   | 150만  |

구조가 완전하여 대규모 언어 모델이 각 필드의 의미를 정확하게 이해할 수 있습니다.

이것이 문서 변환 품질이 RAG 효과에 직접적인 영향을 미치는 이유입니다. anydoc의 설계 목표는: 어떤 형식이 입력되든 구조적으로 완전하고 의미가 명확한 Markdown을 출력.

3. 지원되는 14가지 형식 상세

anydoc은 14가지 일반적인 오피스 형식을 커버하며, 현재 "전체 형식 커버리지"를 달성한 유일한 오픈소스 라이브러리입니다:

3.1 형식 감지: 확장자에 의존하지 않음

anydoc의 형식 감지는 파일 콘텐츠 마커를 기반으로 하며 확장자에 의존하지 않습니다. 이는 파일이 잘못 이름 지정된 경우(예: report.pdf가 실제로는 Word 문서인 경우)에도 anydoc이 올바르게 식별하고 변환할 수 있음을 의미합니다.

// Rust
Format::from_bytes(&bytes); // Some(Format::Docx), 또는 일치하는 것이 없으면 None
Format::from_extension("pptm"); // Some(Format::Pptx)
Format::from_path(Path::new("report.odt")); // Some(Format::Odt)

# Python
import anydoc
anydoc.format_from_bytes(data)  # <Format.DOCX: ...>
anydoc.format_from_extension("pptm")  # <Format.PPTX: ...>

감지 원리: - PDF: PDF 헤더 마커 %PDF- 읽기 - RTF: RTF 오픈 그룹 {\rtf 읽기 - OLE 형식(.doc/.ppt/.xls): OLE 스트림 이름 읽기 - ZIP 패키지 형식(.docx/.pptx/.xlsx/.odt 등): ZIP 패키지의 mimetype 및 콘텐츠 유형 읽기 - CSV: 콘텐츠 마커 없음, 확장자에 의존하거나 명시적으로 지정

3.2 변환 품질: 완전한 문서 구조 보존

anydoc은 텍스트만 추출하는 것이 아니라 완전한 문서 구조를 보존합니다:

• 제목 계층: 앵커가 포함된 H1-H6
• 텍스트 스타일: 굵게, 기울임꼴, 취소선, 인라인 코드
• 코드 블록: 구문 강조 표시 포함
• 목록: 순서 있는, 순서 없는, 중첩, 작업 목록(원래 번호 보존)
• 테이블: 병합된 셀, 헤더 행
• 인용 블록: blockquote
• 각주 및 미주
• 수식: Word/PowerPoint의 OMML, OpenDocument/EPUB의 MathML, RTF 수식이 모두 GitHub 스타일의 LaTeX 수학 표기법으로 변환($...$ 인라인, $$...$$ 블록)
• 포함된 리소스: 이미지와 포함된 객체는 Markdown에서 alt 텍스트로 렌더링되며, 원본 바이트는 문서 모델에 보존됨(미디어 유형 마커 포함)

4. 기술 아키텍처: Rust 구현, 4.4ms 속도의 비밀

anydoc의 성능은 세 가지 핵심 설계 결정에서 비롯됩니다:

4.1 순수 Rust 구현, 외부 의존성 없음

anydoc은 처음부터 Rust로 작성되었으며, LibreOffice, Python 라이브러리 또는 기타 외부 서비스에 의존하지 않습니다. Rust의 제로 비용 추상화와 메모리 안전성 특성 덕분에 anydoc은 밀리초 단위로 변환을 완료할 수 있으면서도 메모리 누수와 세그먼트 오류를 방지합니다.

4.2 공유 문서 모델 + 단일 직렬화기

모든 형식의 파서는 동일한 Document 구조를 출력합니다:

pub struct Document {
    pub blocks: Vec<Block>,      // 단락, 제목, 목록, 테이블 등
    pub inlines: Vec<Inline>,    // 굵게, 기울임꼴, 링크 등
    pub tables: Vec<Table>,      // 테이블
    pub footnotes: Vec<Footnote>, // 각주
    pub assets: Vec<Asset>,      // 이미지, 포함된 객체
}

그런 다음 단일 GFM(GitHub-Flavored Markdown) 직렬화기가 통합 렌더링을 수행합니다. 이는 다음을 의미합니다: - 일관성: 입력이 .docx이든 .rtf이든, 출력 Markdown 형식은 완전히 동일 - 유지보수성: 버그 하나를 수정하면 모든 형식이 혜택을 받음 - 확장성: 새 형식을 추가하려면 파서만 구현하면 되며, 직렬화 로직은 재사용

4.3 ML 모델 없음, 순수 규칙 기반 파싱

anydoc은 기계 학습 모델을 사용하지 않고 형식 사양 기반의 규칙 파싱을 사용합니다. 이로 인해: - 빠른 속도: 중앙값 변환 시간 4.4ms(Ryzen 9 9950X3D에서 테스트) - 예측 가능성: 모델 추론의 불확실성 없음 - 낮은 리소스 사용: GPU가 필요 없으며, CPU만으로 실행 가능

스캔된 PDF의 경우, anydoc은 "OCR 필요"로 표시하고 외부 비전 파이프라인(예: Firecrawl의 Fire-PDF 서비스)에 전달합니다.

4.4 바인딩 설계: 메인 스레드를 블로킹하지 않음

• Node.js: 변환이 libuv 스레드 풀에서 실행되어 이벤트 루프를 블로킹하지 않음
• Python: GIL을 해제하여 다른 스레드가 계속 실행됨
• TypeScript 타입 및 Python 스텁: 패키지와 함께 제공되어 IDE 자동 완성 친화적

5. Pandoc / Markitdown / Docling과의 비교

anydoc이 유일한 문서 변환 도구는 아닙니다. 주요 경쟁사와의 비교를 살펴보겠습니다:

5.1 기능 커버리지 비교

주요 차이점: - Pandoc은 가장 많은 형식을 지원하지만(40+), 출력 품질이 anydoc보다 낮음(아래 벤치마크 참조), Haskell 의존성으로 통합이 복잡 - Markitdown은 Python 라이브러리로, 6가지 형식만 지원, 속도가 느림(134.8ms vs 4.4ms) - Docling은 PDF 및 이미지 문서에 특화, PyTorch 필요, 4가지 형식만 지원 - LibreOffice는 완전한 오피스 스위트, 용량이 큼(수백 MB), 변환 속도가 느림(1129.5ms) - Mammoth는 docx만 지원하지만 품질은 좋음(70점)

5.2 공식 벤치마크

Firecrawl 팀은 100개의 실제 문서에서 각 도구의 성능과 품질을 테스트했습니다(Claude Sonnet 5를 LLM 심사위원으로 사용):

주요 발견: - 속도: anydoc은 가장 빠른 경쟁사(mammoth)보다 12배, 가장 느린 경쟁사(libreoffice)보다 256배 빠름 - 품질: anydoc은 테스트된 모든 형식에서 최고 점수를 획득 - 커버리지: anydoc은 14가지 형식을 모두 지원하는 유일한 도구

5.3 형식별 품질 비교

참고: mammoth의 70점은 docx 한 가지 형식만을 기반으로 하며, anydoc의 81점은 14가지 형식 전체에 걸쳐 있습니다. 형식별 비교가 더 공정합니다.

5.4 선택 권장사항

• anydoc 선택: 다양한 형식을 처리해야 하고, 속도와 품질을 추구하며, 제로 의존성을 원할 때
• Pandoc 선택: 형식 변환(예: Markdown → PDF)이 필요하고, Haskell 의존성을 신경 쓰지 않을 때
• Markitdown 선택: 기존 Python 생태계가 있고, 기본 형식 지원만 필요할 때
• Docling 선택: PDF 및 이미지 문서에 특화되어 있고, GPU 리소스가 있을 때
• LibreOffice 선택: 완전한 오피스 스위트 기능이 필요하고, 용량과 속도를 신경 쓰지 않을 때

6. 로컬 배포 실전: 세 가지 방식 선택

anydoc은 다양한 시나리오에 적응할 수 있도록 세 가지 배포 방식을 제공합니다:

6.1 CLI 도구: 가장 빠른 시작

# npx를 사용한 임시 실행(첫 실행 시 사전 컴파일된 바이너리 다운로드)
npx @firecrawl/anydoc report.docx               # stdout으로 출력
npx @firecrawl/anydoc slides.pptx -o slides.md  # 파일로 출력
npx @firecrawl/anydoc - --format csv < data.csv # stdin에서 읽기

# 전역 설치
npm install -g @firecrawl/anydoc
anydoc report.docx -o report.md

사용 시나리오: 빠른 테스트, 스크립트 통합, CI/CD 파이프라인.

6.2 Python SDK: RAG 파이프라인에 최적

pip install firecrawl-anydoc

import anydoc

# 파일 경로에서 변환
markdown = anydoc.to_markdown("contract.docx")
print(markdown)

# 바이트에서 변환(형식 자동 감지)
with open("report.pdf", "rb") as f:
    data = f.read()
markdown = anydoc.to_markdown_bytes(data)

# 명시적으로 형식 지정(CSV에 필요)
markdown = anydoc.to_markdown_bytes(csv_data, "csv")

# 완전한 문서 모델 가져오기(포함된 리소스 포함)
document = anydoc.to_document("presentation.pptx")
print(document.blocks)  # 문서 구조 접근
print(document.assets)  # 포함된 이미지 접근

사용 시나리오: Python RAG 파이프라인, 일괄 처리, LangChain/LlamaIndex와 통합.

6.3 Node.js SDK: 웹 애플리케이션 통합

npm install @firecrawl/anydoc

import { toMarkdown, toDocument } from '@firecrawl/anydoc';

// 파일 경로에서 변환
const markdown = await toMarkdown('contract.docx');

// 바이트에서 변환
const buffer = fs.readFileSync('report.pdf');
const markdown = await toMarkdownBytes(buffer);

// 완전한 문서 모델 가져오기
const document = await toDocument(buffer);
console.log(document.blocks);

사용 시나리오: Node.js 웹 애플리케이션, Express/Fastify 백엔드, 실시간 문서 미리보기.

6.4 WebAssembly: 브라우저에서 실행

anydoc은 WebAssembly로 컴파일되어 브라우저에서 로컬로 실행될 수 있으며, 파일이 서버로 업로드되지 않습니다:

npm install @firecrawl/anydoc-wasm

import init, { toMarkdownBytes } from '@firecrawl/anydoc-wasm';

await init();

const file = document.getElementById('file-input').files[0];
const buffer = await file.arrayBuffer();
const markdown = toMarkdownBytes(new Uint8Array(buffer));

사용 시나리오: 개인 정보 보호가 중요한 시나리오, 오프라인 애플리케이션, 서버 부하 감소.

6.5 Docker 배포

anydoc에는 공식 Docker 이미지가 없지만 직접 구축할 수 있습니다:

FROM node:20-alpine

RUN npm install -g @firecrawl/anydoc

WORKDIR /app
CMD ["anydoc"]

docker build -t anydoc .
docker run -v $(pwd):/app anydoc report.docx -o report.md

사용 시나리오: 컨테이너화된 배포, Kubernetes 클러스터, 마이크로서비스 아키텍처.

7. 실전: 문서 전처리 파이프라인 구축(anydoc + RAG)

사용자가 업로드한 다양한 문서를 처리하는 완전한 RAG 파이프라인을 구축해 보겠습니다:

7.1 아키텍처 설계

사용자 문서 업로드 → anydoc 변환 → 텍스트 청크 → 임베딩 → 벡터 데이터베이스 → 검색 → LLM 생성

7.2 Python 구현

import anydoc
import os
from pathlib import Path
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma

# 1. 문서 변환
def convert_document(file_path: str) -> str:
    """임의 형식의 문서를 Markdown으로 변환"""
    try:
        markdown = anydoc.to_markdown(file_path)
        return markdown
    except anydoc.ConvertError as e:
        print(f"변환 실패: {e}")
        return None

# 2. 텍스트 청킹
def chunk_text(text: str, chunk_size: int = 1000, overlap: int = 200):
    """긴 텍스트를 작은 청크로 분할"""
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=chunk_size,
        chunk_overlap=overlap,
        separators=["\n## ", "\n### ", "\n\n", "\n", " ", ""]
    )
    return splitter.split_text(text)

# 3. 벡터 데이터베이스 구축
def build_vector_store(chunks: list, collection_name: str = "documents"):
    """텍스트 청크를 벡터로 변환하여 저장"""
    embeddings = OpenAIEmbeddings()
    vectorstore = Chroma.from_texts(
        texts=chunks,
        embedding=embeddings,
        collection_name=collection_name
    )
    return vectorstore

# 4. 완전한 파이프라인
def process_document_pipeline(file_path: str):
    """완전한 문서 처리 파이프라인"""
    # 변환
    print(f"변환 중: {file_path}")
    markdown = convert_document(file_path)
    if not markdown:
        return None

    # Markdown 저장(선택 사항)
    output_path = Path(file_path).with_suffix('.md')
    output_path.write_text(markdown, encoding='utf-8')
    print(f"Markdown 저장됨: {output_path}")

    # 청킹
    chunks = chunk_text(markdown)
    print(f"{len(chunks)}개 청크로 분할")

    # 벡터 DB 구축
    vectorstore = build_vector_store(chunks)
    print("벡터 데이터베이스 구축 완료")

    return vectorstore

# 5. 일괄 처리
def batch_process(directory: str):
    """디렉터리의 모든 문서 일괄 처리"""
    supported_extensions = {
        '.doc', '.docx', '.docm',
        '.ppt', '.pptx', '.pptm',
        '.xls', '.xlsx', '.xlsm',
        '.odt', '.ods', '.odp',
        '.rtf', '.epub', '.csv', '.pdf'
    }

    for file_path in Path(directory).rglob('*'):
        if file_path.suffix.lower() in supported_extensions:
            print(f"\n처리 중: {file_path}")
            process_document_pipeline(str(file_path))

# 사용 예시
if __name__ == "__main__":
    # 단일 파일 처리
    vectorstore = process_document_pipeline("contract.docx")

    # 일괄 처리
    # batch_process("./documents")

7.3 LangChain과 통합

from langchain.document_loaders import BaseLoader
from langchain.schema import Document
import anydoc

class AnyDocLoader(BaseLoader):
    """anydoc 문서 로더"""

    def __init__(self, file_path: str):
        self.file_path = file_path

    def load(self) -> list[Document]:
        """문서 로드 및 변환"""
        markdown = anydoc.to_markdown(self.file_path)
        metadata = {"source": self.file_path}
        return [Document(page_content=markdown, metadata=metadata)]

# 사용
loader = AnyDocLoader("report.pdf")
docs = loader.load()

# LangChain 파이프라인과 통합
from langchain.chains import RetrievalQA
from langchain.llms import OpenAI

qa = RetrievalQA.from_chain_type(
    llm=OpenAI(),
    chain_type="stuff",
    retriever=vectorstore.as_retriever()
)

result = qa.run("이 보고서의 주요 발견은 무엇입니까?")
print(result)

7.4 오류 처리

anydoc의 오류 유형:

import anydoc

try:
    markdown = anydoc.to_markdown("document.pdf")
except anydoc.ConvertError as e:
    if isinstance(e, anydoc.EncryptedError):
        print("문서가 암호화됨")
    elif isinstance(e, anydoc.UnsupportedError):
        print("지원되지 않는 형식")
    elif isinstance(e, anydoc.MalformedError):
        print("문서 구조 손상")
    elif isinstance(e, anydoc.ResourceLimitError):
        print("리소스 제한 초과")
    else:
        print(f"변환 오류: {e}")
except OSError as e:
    print(f"파일 읽기 오류: {e}")

8. 성능 벤치마크 실측

anydoc의 실제 성능을 검증하기 위해 다양한 시나리오에서 테스트를 수행했습니다:

8.1 테스트 환경

• CPU: AMD Ryzen 9 7950X
• 메모리: 64GB DDR5
• 운영체제: Ubuntu 22.04
• Python: 3.11
• anydoc: 최신 버전

8.2 단일 파일 변환 속도

결론: 대부분의 문서가 10ms 이내에 변환되어 공식 발표된 "한 자리 수 밀리초" 성능을 충족합니다.

8.3 일괄 처리 성능

100개의 혼합 형식 문서 처리:

8.4 경쟁사와의 실측 비교

10개의 전형적인 문서를 선택하여 각 도구의 변환 시간과 품질을 비교했습니다:

anydoc은 속도에서 한 자릿수 앞서고, 품질 점수도 가장 높으며, 메모리 사용량도 가장 낮습니다.

9. 제한사항 및 주의사항

anydoc이 뛰어난 성능을 보여주지만, 주의해야 할 몇 가지 제한사항이 있습니다:

9.1 지원되지 않는 형식

• 이미지 기반 PDF: 스캔된 PDF는 외부 OCR 서비스 필요(Tesseract, Firecrawl Fire-PDF 등)
• 암호화된 문서: 비밀번호로 보호된 문서는 변환할 수 없으며, Encrypted 오류 발생
• 구형 Mac 형식: .pages, .numbers, .key는 지원되지 않음
• 이미지 형식: .jpg, .png 등의 이미지 파일은 직접 지원되지 않음(먼저 OCR 필요)

9.2 알려진 제한사항

• 복잡한 레이아웃: 다단 레이아웃, 텍스트가 이미지를 감싸는 등의 복잡한 레이아웃은 손실될 수 있음
• 포함된 객체: Excel 차트, Word에 포함된 OLE 객체는 alt 텍스트만 보존
• 매크로 및 스크립트: VBA 매크로, JavaScript 스크립트는 변환되지 않음
• 매우 큰 파일: 리소스 제한을 초과하는 문서는 ResourceLimit 오류 발생

9.3 버전 호환성

• 구형 Office: .doc/.ppt/.xls(Office 97-2003)는 지원되지만, .docx/.pptx/.xlsx만큼 품질이 좋지 않음
• WPS 형식: WPS에서 생성된 문서는 일반적으로 호환되지만 공식적으로 테스트되지 않음
• Google Docs: .docx로 내보낸 후 변환하는 것이 가장 효과적

9.4 프로덕션 환경 권장사항

1. 오류 처리: 항상 ConvertError를 캡처하고 실패한 파일을 기록
2. 리소스 제한: 큰 파일에 타임아웃을 설정하여 블로킹 방지
3. 형식 검증: 변환 후 출력 품질을 확인하고 필요시 수동으로 검토
4. 원본 파일 백업: 변환 전 원본 문서 보존
5. 성능 모니터링: 변환 시간을 기록하여 이상 징후를 신속하게 파악

10. 자주 묻는 질문 FAQ

1. anydoc과 pdf-inspector의 차이점은 무엇입니까?

pdf-inspector는 PDF에 특화되어 있으며, 각 페이지가 텍스트인지 스캔인지 판단하고 OCR 필요 여부를 결정합니다. anydoc은 다른 모든 형식(Word/PPT/Excel/EPUB/RTF/CSV/OpenDocument)을 처리하며, 텍스트 기반 PDF 처리를 위해 pdf-inspector를 내장합니다. 두 가지가 함께 작동하여 모든 일반적인 문서 형식을 커버합니다.

2. anydoc은 API 키가 필요합니까?

아니요. anydoc은 완전히 로컬에서 실행되는 오픈소스 라이브러리로, API 키, 네트워크 연결, 외부 서비스가 필요 없습니다. 모든 변환은 로컬에서 완료됩니다.

3. anydoc은 중국어 문서를 지원합니까?

예. anydoc은 Unicode를 기반으로 하며 중국어, 일본어, 한국어 등 다국어 문서를 완벽하게 지원합니다. 변환된 Markdown은 원본 언어와 인코딩을 보존합니다.

4. 스캔된 PDF는 어떻게 처리합니까?

anydoc은 텍스트 기반 PDF만 처리할 수 있습니다. 스캔된 PDF의 경우: 1. anydoc을 사용하여 OCR이 필요한 페이지 감지 2. 스캔된 페이지를 OCR 서비스(Tesseract, Firecrawl Fire-PDF 등)에 전달 3. 결과 병합

코드 예시:

import anydoc

try:
    markdown = anydoc.to_markdown("scanned.pdf")
except anydoc.UnsupportedError:
    # OCR 서비스 호출
    ocr_result = call_ocr_service("scanned.pdf")
    markdown = ocr_result.text

5. anydoc을 상업적으로 사용할 수 있습니까?

예. anydoc은 MIT 라이선스를 사용하며, 상업적 사용, 수정, 배포가 가능하며 비용이 들지 않습니다.

11. 종합 평가

장점

✅ 포괄적인 형식 커버리지: 14가지 형식, 전체 커버리지를 달성한 유일한 오픈소스 라이브러리
✅ 탁월한 성능: 중앙값 속도 4.4ms, 경쟁사보다 12-256배 빠름
✅ 최고 품질: LLM 심사위원 점수 81, 모든 지표에서 선도
✅ 제로 의존성: 순수 Rust 구현, 외부 서비스 불필요
✅ 다국어 바인딩: Rust/Node.js/Python/WebAssembly
✅ 오픈소스 무료: MIT 라이선스, 상업적 사용 가능

단점

❌ 스캔된 PDF 미지원: 외부 OCR 서비스 필요
❌ 암호화된 문서 미지원: 비밀번호로 보호된 파일은 변환 불가
❌ 복잡한 레이아웃 손실: 다단 레이아웃, 텍스트가 이미지를 감싸는 등이 손실될 수 있음
❌ 프로젝트가 새로움: 2026년 8월에 출시되어 생태계가 아직 구축 중

권장 사용 시나리오

• ✅ RAG 파이프라인 문서 전처리
• ✅ 지식 베이스 구축
• ✅ 문서 검색 엔진
• ✅ AI 어시스턴트 문서 이해
• ✅ 기업 문서 마이그레이션
• ✅ 콘텐츠 관리 시스템

비권장 사용 시나리오

• ❌ 스캔본 OCR(전문 OCR 도구 필요)
• ❌ 복잡한 레이아웃 보존(전문 레이아웃 도구 필요)
• ❌ 형식 변환(예: Markdown → PDF, Pandoc 필요)

최종 점수

추천 지수: ⭐⭐⭐⭐⭐(강력히 추천)

anydoc은 현재 가장 우수한 오픈소스 문서 Markdown 변환 도구이며, 특히 다양한 형식을 처리해야 하고 속도와 품질을 추구하는 프로덕션 환경에 적합합니다. RAG 파이프라인이나 지식 베이스 시스템을 구축하고 있다면, anydoc이 첫 번째 선택이 되어야 합니다.

참고 링크: - GitHub 저장소: https://github.com/firecrawl/anydoc - Firecrawl 공식 블로그: https://www.firecrawl.dev/blog/anydoc-and-pdf-inspector - 온라인 데모(WebAssembly): https://firecrawl.github.io/anydoc/ - Firecrawl Parse API(호스팅 서비스): https://firecrawl.dev/parse