🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Firecrawl은 PDF를 페이지별로 판별·추출하는 pdf-inspector와 14개 문서 형식을 마크다운으로 변환하는 AnyDoc을 공개해, 여러 변환 도구를 조합해야 했던 문서 처리 파이프라인을 두 개의 오픈소스 Rust 라이브러리로 단순화했다.

📌 핵심 요약

• Firecrawl은 공통 문서 형식을 하나의 라이브러리로 안정적으로 처리하기 어렵다는 문제를 해결하기 위해 PDF 전용 pdf-inspector와 기타 문서용 AnyDoc을 별도 오픈소스 저장소로 공개했다.
• pdf-inspector는 PDF를 렌더링하지 않고 글꼴 인코딩, 텍스트 연산자, 이미지 점유율 같은 내부 구조를 분석해 각 페이지가 기본 텍스트 추출 대상인지 OCR 대상인지 밀리초 단위로 판별한다.
• 텍스트 기반 페이지는 읽기 순서를 유지한 채 직접 추출하고, 스캔 또는 이미지 중심 페이지는 판별 사유와 함께 OCR 파이프라인으로 넘겨 필요한 페이지만 GPU로 처리한다.
• AnyDoc은 API 키와 시스템 의존성 없이 14개 문서 형식을 마크다운으로 변환하며, 내부적으로 pdf-inspector를 사용해 텍스트 기반 PDF도 단일 호출로 처리한다.
• Firecrawl이 100개 실제 문서로 수행한 벤치마크에서 AnyDoc은 14개 형식을 모두 처리했고, 문서당 중앙값 4.4밀리초와 전체 품질 점수 81을 기록했지만 평가 말뭉치가 Firecrawl 자체 자료라는 한계도 명시됐다.

🧩 주요 포인트

1. PDF 내부 구조의 페이지별 판별 → OCR이 필요한 페이지만 선별해 네이티브 텍스트의 정확성을 활용하고 GPU 처리량을 줄인다.
2. 개 형식을 하나의 무의존성 변환기로 통합 → 형식마다 다른 도구, 출력 구조, 장애 유형을 관리하던 문서 처리 작업을 축소한다.
3. PDF 전문 엔진과 범용 문서 변환기를 분리하되 마크다운 출력과 로컬 실행 원칙을 공유 → 전문성과 일관된 통합 방식을 동시에 유지한다.

🧠 상세 정리

1. 여러 문서 변환기를 조합해야 했던 문제

Firecrawl은 공통 문서 형식을 모두 깨끗한 마크다운으로 안정적으로 변환하는 단일 라이브러리가 없다는 문제에서 출발했다. 기존에는 팀이 네다섯 개의 도구를 이어 붙여야 했고, 각 도구가 서로 다른 의존성, 출력 구조, 지원 범위와 실패 방식을 갖고 있었다. 특히 사용자가 오래된 스프레드시트, DOCX 계약서, 프레젠테이션, EPUB처럼 임의의 파일을 업로드하는 서비스에서는 텍스트 추출 자체가 별도의 배관 작업이 됐다. Firecrawl은 이를 PDF 전용 pdf-inspector와 나머지 문서 형식을 담당하는 AnyDoc이라는 두 개의 오픈소스 Rust 라이브러리로 나눠 해결했다. 두 프로젝트는 같은 계보와 설계 원칙을 공유하지만 전문 영역을 유지하기 위해 의도적으로 별도 저장소와 별도 제품으로 운영되며, 이미 Firecrawl의 /parse 및 /scrape 엔드포인트에서 문서 처리에 사용되고 있다.

2. pdf-inspector의 페이지별 PDF 판별과 추출

pdf-inspector는 처음부터 Rust로 개발된 PDF 전용 라이브러리이며, 글 작성 시점에 해당 저장소는 GitHub 스타 1만 3천 개를 기록하고 있었다. 이 도구는 PDF를 이미지로 렌더링하지 않고 글꼴 인코딩, 텍스트 연산자, 이미지 점유율 같은 내부 구조를 밀리초 단위로 조사한다. 그 결과 각 페이지를 네이티브 텍스트로 처리할 수 있는지, 아니면 OCR이 필요한 스캔·이미지 중심 페이지인지 개별적으로 분류한다. 텍스트 기반 페이지에서는 원래 PDF에 들어 있는 텍스트를 읽기 순서를 보존해 직접 추출하며, 완전히 텍스트 기반인 PDF라면 pdf-inspector만으로 전체 처리가 끝난다. OCR이 필요한 페이지에는 해당 페이지 참조와 판별 사유를 함께 반환하므로, 후속 비전 파이프라인은 어떤 페이지를 무거운 처리 과정으로 넘겨야 하는지 명확히 알 수 있다.

3. OCR 중심 방식에서 선택적 GPU 처리로의 전환

Firecrawl은 모든 PDF 페이지가 스캔됐을 가능성을 전제로 전체 문서를 OCR에 보내는 방식을 일반적인 PDF 파이프라인의 잘못된 가정으로 지적한다. 이런 방식은 원래 PDF 안에 정확한 네이티브 텍스트가 존재해도 렌더링과 GPU 처리를 수행하므로 느리고 비싸며, 직접 추출보다 정확도가 낮아질 수도 있다. pdf-inspector는 내부 구조만으로 페이지를 먼저 분류해 텍스트 페이지는 즉시 추출하고, 스캔 페이지에만 OCR 자원을 배정하는 라우팅 계층으로 작동한다. 이 계층을 사용하는 Firecrawl의 호스팅 PDF 엔진 Fire-PDF는 이전 파이프라인보다 3.5배에서 5배 빠르다고 소개됐다. 기사에 제시된 200페이지 보고서 사례에서는 순수 텍스트인 150페이지가 GPU 처리를 완전히 건너뛰고, 나머지 페이지만 무거운 처리 단계로 전달된다.

4. AnyDoc의 형식 통합과 단일 호출 인터페이스

AnyDoc은 pdf-inspector와 마찬가지로 처음부터 Rust로 작성됐으며, 여러 비-PDF 문서를 하나의 호출로 마크다운으로 변환하는 스택의 다른 절반이다. Firecrawl은 AnyDoc이 벤치마크 대상인 14개 문서 형식을 하나의 라이브러리에서 처리하며 API 키, 외부 서비스, 별도 실행 파일과 시스템 의존성을 요구하지 않는다고 설명한다. 또한 내부에서 pdf-inspector를 호출하므로 텍스트 기반 PDF까지 같은 AnyDoc 호출로 변환할 수 있다. 네이티브 바인딩은 Rust, Node.js, Python에 제공되고, 브라우저용 WebAssembly 빌드와 명령줄 인터페이스도 함께 지원된다. 직접 통합하지 않는 경우에도 Firecrawl의 /parse 또는 /scrape 엔드포인트가 비-PDF 문서를 만나면 AnyDoc을 자동으로 사용하므로 별도 문서 유형별 설정이 필요하지 않다.

5. 100개 실제 문서 벤치마크의 결과와 한계

Firecrawl은 14개 형식에 걸친 실제 문서 100개를 사용해 AnyDoc과 다른 변환기 여섯 개를 비교했다고 밝혔다. 지원 범위에서는 AnyDoc만 14개 형식을 모두 처리했고, 가장 가까운 LibreOffice는 12개를 지원했으며 나머지 도구는 일부 형식만 처리했다. 속도 측정에서 AnyDoc의 문서당 중앙값은 4.4밀리초였고, 비교 대상은 52밀리초에서 1,130밀리초 사이를 기록해 다음으로 빠른 도구와도 한 자릿수 이상의 차이가 났다고 설명됐다. 품질은 Claude Sonnet 5가 정답 자료를 기준으로 완전성, 구조, 서식, 정돈 상태를 블라인드 평가했으며, AnyDoc은 전체 81점으로 차순위의 70점을 앞섰다고 제시됐다. 다만 Firecrawl은 평가 말뭉치가 자사 소유이고 각 도구의 전체 점수가 실제로 지원하는 형식만을 평균한 값이라고 명시했으며, 이 때문에 전체 평균보다 동일 형식별 비교가 더 공정하다고 설명했다.

6. 두 라이브러리의 역할 구분과 실제 사용 경로

pdf-inspector와 AnyDoc은 모두 로컬 실행, Rust 기반 구현, 마크다운 출력, API 키 및 시스템 의존성 제거라는 공통 원칙을 따른다. 그러나 AnyDoc이 pdf-inspector의 확장판인 것은 아니며, pdf-inspector는 PDF 구조 판별과 네이티브 추출에 특화된 전용 엔진으로 남는다. AnyDoc은 다른 14개 형식을 담당하면서 텍스트 기반 PDF 지원을 위해 pdf-inspector를 내부에 포함하는 범용 변환 계층이다. 개발자는 두 라이브러리를 저장소에서 직접 통합하거나, 문서를 Firecrawl의 /parse 또는 /scrape로 보내 호스팅 경로를 사용할 수 있다. API 경로에서는 PDF가 pdf-inspector와 필요한 경우 Fire-PDF를 거치고, 그 밖의 문서는 AnyDoc으로 전달되므로 사용자가 형식별 처리 경로를 직접 구성하지 않아도 된다.

🧾 핵심 주장 / 시사점

• pdf-inspector의 핵심 가치는 OCR 자체가 아니라 OCR 필요 여부를 페이지 단위로 먼저 판단하는 데 있으며, 기사에 제시된 200페이지 사례처럼 텍스트 페이지가 많은 혼합 문서일수록 GPU를 건너뛰는 범위가 커진다.
• 두 프로젝트를 하나로 합치지 않고 분리한 구조는 PDF 내부 구조 분석이라는 전문 기능과 다형식 변환이라는 범용 기능을 구분하면서도, 마크다운 출력과 동일한 실행 원칙으로 통합할 수 있게 한다.
• AnyDoc의 벤치마크 수치는 지원 범위·속도·품질에서 우위를 보여 주지만, 자체 말뭉치와 지원 형식별 평균이라는 조건이 있으므로 기사도 전체 점수보다 같은 형식에서의 직접 비교를 더 공정한 기준으로 제시한다.

✅ 액션 아이템

• pdf-inspector의 글꼴 인코딩·이미지 점유율 기반 페이지별 판별이 OCR 선별과 GPU 절감에 맞는지 점검한다.
• AnyDoc의 14개 문서 형식·무의존성 마크다운 변환 범위를 기존 다중 도구 파이프라인과 비교한다.
• Firecrawl 벤치마크의 문서당 중앙값 4.4밀리초와 품질 점수 81을 자체 말뭉치에서 재측정할지 우선순위를 정한다.

❓ 열린 질문

• pdf-inspector가 스캔·이미지 중심 페이지를 OCR 파이프라인으로 넘기는 판별 임계값은 무엇인가?
• AnyDoc이 내부적으로 pdf-inspector로 텍스트 기반 PDF를 단일 호출 처리할 때 품질 편차는 어떻게 판단할 것인가?
• 평가 말뭉치가 Firecrawl 자체 자료라는 한계 속에서 품질 점수 81을 일반화할 기준은 무엇인가?