Introducing /parse: Turn any document into LLM-ready data

🖼️ 인포그래픽

Introducing /parse: Turn any document into LLM-ready data 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Firecrawl은 로컬 문서를 업로드해 웹 페이지처럼 정리된 마크다운, 요약, 구조화 JSON을 받을 수 있는 새 API /parse를 출시했다.

📌 핵심 요약

Firecrawl /parse는 계약서, 보고서, 송장, 사용자 업로드 파일처럼 웹이 아니라 디스크에 있는 문서를 직접 업로드해 처리하는 API다.
/parse는 /scrape와 같은 파싱 엔진을 사용해 PDF의 읽기 순서와 표를 보존하고, 워드 문서의 불필요한 XML 노이즈를 제거하며, 스프레드시트를 표 형태의 깨끗한 마크다운으로 바꾼다.
지원 형식은 PDF, DOCX, DOC, ODT, RTF, XLSX, XLS, HTML이며 파일 크기는 최대 50MB까지다.
내부 엔진은 러스트 기반으로 페이지당 평균 400ms 미만을 목표로 하며, 모든 문서를 OCR로 보내지 않고 먼저 페이지를 분류해 필요한 경우에만 GPU 처리를 사용한다.
주요 활용처는 웹과 파일을 함께 처리하는 단일 파이프라인, 내부 문서의 구조화 필드 추출, 사용자 업로드 문서의 RAG용 마크다운 변환이다.

🧩 주요 포인트

Firecrawl /parse는 계약서, 보고서, 송장, 사용자 업로드 파일처럼 웹이 아니라 디스크에 있는 문서를 직접 업로드해 처리하는 API다.
/parse는 /scrape와 같은 파싱 엔진을 사용해 PDF의 읽기 순서와 표를 보존하고, 워드 문서의 불필요한 XML 노이즈를 제거하며, 스프레드시트를 표 형태의 깨끗한 마크다운으로 바꾼다.
지원 형식은 PDF, DOCX, DOC, ODT, RTF, XLSX, XLS, HTML이며 파일 크기는 최대 50MB까지다.
내부 엔진은 러스트 기반으로 페이지당 평균 400ms 미만을 목표로 하며, 모든 문서를 OCR로 보내지 않고 먼저 페이지를 분류해 필요한 경우에만 GPU 처리를 사용한다.
주요 활용처는 웹과 파일을 함께 처리하는 단일 파이프라인, 내부 문서의 구조화 필드 추출, 사용자 업로드 문서의 RAG용 마크다운 변환이다.

🧠 상세 정리

1. 출시 배경과 문제의식

글은 Firecrawl이 이미 웹 URL과 웹에 올라온 PDF에서 깨끗한 마크다운을 가져올 수 있다는 점에서 출발한다. 그러나 실제로 처리해야 하는 많은 문서는 웹이 아니라 로컬 디스크나 사용자의 업로드 공간에 존재한다고 설명한다. 예시로 계약서, 보고서, 송장, 업로드된 파일이 제시된다. /parse는 이 간극을 메우기 위해 출시된 기능으로, 파일을 직접 업로드하면 Firecrawl이 웹 페이지에 제공하던 것과 같은 정리된 구조화 출력을 돌려주는 것을 목표로 한다.

2. /parse의 기본 기능

/parse는 로컬 파일을 /scrape에 쓰이는 것과 같은 파싱 엔진에 통과시킨다. PDF는 읽기 순서를 보존하고 표를 유지한 결과로 반환되며, 워드 문서는 내부 XML에서 생기는 잡음을 제거한다. 스프레드시트는 사람이 읽기 쉬운 표 형태의 마크다운으로 변환된다. 같은 호출에서 요약이나 구조화 JSON 추출도 요청할 수 있어, 별도의 후처리 없이 문서를 LLM이 사용할 수 있는 형태로 바꾸는 흐름을 강조한다.

3. 지원 형식과 처리 범위

지원되는 파일 형식은 PDF, DOCX, DOC, ODT, RTF, XLSX, XLS, HTML로 제한된다. 파일 크기는 최대 50MB까지 가능하다고 명시되어 있다. 글은 이 기능이 웹 페이지뿐 아니라 이메일 첨부파일, 다운로드한 보고서, 사용자가 애플리케이션에 업로드한 문서를 같은 파이프라인에서 다룰 수 있게 한다고 설명한다. 즉 Firecrawl을 이미 웹 리서치용으로 쓰는 사용자는 별도 문서 처리 스택을 추가하지 않고 파일 처리까지 확장할 수 있다.

4. 러스트 기반 엔진과 성능 구조

/parse의 내부는 러스트 기반 엔진으로 구동되며, 글은 페이지당 평균 400ms 미만의 처리 속도를 제시한다. 중요한 점은 모든 문서를 무조건 OCR로 보내지 않고, 먼저 페이지를 분류한 뒤 실제로 필요한 부분만 GPU로 보낸다는 것이다. 텍스트 기반 PDF는 오픈소스 러스트 라이브러리인 pdf-inspector가 폰트, 텍스트 연산자, 이미지 비중 같은 PDF 내부 정보를 읽어 빠르게 텍스트를 추출한다. 이 구조는 불필요한 렌더링과 OCR 처리를 줄여 속도와 효율을 높이는 방향으로 설명된다.

5. 스캔 문서와 레이아웃 처리

스캔되었거나 이미지가 많은 페이지는 GPU 플릿으로 라우팅되며, 글은 lane 기반 격리를 통해 큰 문서가 작은 문서 처리를 지연시키지 않도록 한다고 설명한다. 예를 들어 200쪽짜리 보고서가 한 장짜리 송장을 느리게 만들지 않는 구조를 강조한다. 또한 신경망 기반 레이아웃 모델이 표, 수식, 텍스트 블록, 헤더를 개별적으로 감지한다. 각 영역별로 파라미터를 조정해 표에는 더 높은 토큰 예산을 주고, 수식은 LaTeX로 보존하며, 다단 문서의 읽기 순서도 예측한다.

6. 활용 사례와 제한 사항

글은 구조화 추출과 RAG 수집을 주요 사용 사례로 제시한다. 파일과 함께 JSON 스키마를 전달하면 항목, 날짜, 당사자, 총액 같은 타입이 있는 필드를 한 번의 호출로 받을 수 있으며, Zero Data Retention이 활성화된 엔터프라이즈 플랜에서는 파싱 결과를 저장하지 않는다고 설명한다. 사용자가 PDF나 DOCX를 업로드하는 애플리케이션에서는 /parse가 이를 임베딩 준비가 된 마크다운으로 바꾸고 요약까지 같은 응답에 포함할 수 있다. 다만 결과는 캐시되지 않아 같은 파일을 반복 업로드해도 매번 다시 파싱되고 과금되며, 지원하지 않는 형식은 UNSUPPORTED_FILE_TYPE 오류를 반환한다. 이미지 전용 PDF는 OCR에 의존하므로 깨끗한 스캔은 잘 처리되지만 저해상도나 손글씨 스캔은 품질이 낮아질 수 있다.

🧾 핵심 주장 / 시사점

/parse의 핵심 가치는 웹 문서 수집과 로컬 파일 처리를 하나의 API 흐름으로 합쳐, 에이전트나 RAG 시스템의 입력 파이프라인을 단순화하는 데 있다.
성능 설명의 중심은 무조건 OCR을 적용하지 않는 분류 기반 처리다. 텍스트 기반 문서는 직접 추출하고, 스캔 문서에만 GPU를 쓰는 방식으로 속도와 자원 사용을 함께 관리한다.
운영 관점에서는 지원 형식, 50MB 제한, 반복 업로드 과금, 스캔 품질 의존성을 명확히 고려해야 한다. 특히 대량 문서 처리나 사용자 업로드 기능에서는 재파싱 비용과 입력 품질 관리가 중요하다.

✅ 액션 아이템

로컬 업로드 API인 /parse의 적용 범위를 계약서·보고서·송장 등 처리 문서군으로 제한하고 웹 데이터 처리 흐름과 분리한다.
PDF·DOC·DOCX·ODT·RTF 처리에서 읽기 순서 보존, 표 정렬, XML 노이즈 제거 결과를 샘플 비교해 마크다운 정합성과 구조화 JSON 품질을 점검한다.
지원 형식(PDF, DOCX, DOC, ODT, RTF, XLSX, XLS, HTML)과 50MB 상한을 기준으로 업로드 허용 규칙을 정하고 초과 파일의 처리 분기 규칙을 확정한다.