회사에서 다루는 문서의 90%는 웹에 없다. 계약서, 분기 리포트, 송장, 사용자 업로드 PDF — 전부 디스크에 있고, 그 처리는 항상 별도 파이프라인이었다.
Firecrawl이 4월 14일 Fire-PDF를 깔고, 14일 뒤인 4월 28일 /parse 엔드포인트를 추가하면서 그 분리가 끝났다. 웹 스크레이프와 로컬 파일이 처음으로 같은 엔진을 쓴다.
왜 같이 묶어 봐야 하는데?
Firecrawl이 4월 한 달에 푼 두 릴리스를 따로 보면 의미가 반쪽이다.
4월 14일 — Fire-PDF. Rust 기반 PDF 파서. 이전 파이프라인 대비 평균 페이지당 400ms 이하, 3.5~5.7배 빠른 처리. 핵심 트릭은 모든 페이지를 GPU에 던지지 않는 것. 오픈소스 pdf-inspector가 페이지를 텍스트 기반/스캔 기반으로 millisecond 단위로 분류한 뒤, 텍스트 페이지는 native 추출로 빠지고 스캔/이미지 페이지만 GPU 레이아웃 모델 + OCR로 보낸다.
4월 28일 — /parse 엔드포인트. 같은 엔진을 로컬 파일에 그대로 쓸 수 있게 만든 입구. multipart/form-data로 파일 바이트를 올리면 Markdown, JSON, 요약, 구조화 추출까지 한 번에 돌아온다. 지원 포맷은 PDF, DOCX, DOC, ODT, RTF, XLSX, XLS, HTML — 파일당 50MB까지.
둘이 합쳐졌다는 뜻은 단순하다. 웹 페이지와 회사 안 파일이 처음으로 같은 RAG 파이프라인에 들어간다. 이전에는 웹은 Firecrawl, PDF는 PyMuPDF/Unstructured, 스캔본은 Tesseract/Textract — 세 갈래로 갈라져 있었다. 출력 포맷이 달랐고, 표/수식 처리 품질이 달랐고, 비용 구조도 달랐다.
이전 PDF 파이프라인은 뭐가 그렇게 비쌌나?
Fire-PDF가 자랑하는 5배 속도가 마케팅이 아닌 이유는 두 가지다.
- Native 추출 우선 — 텍스트 기반 페이지는 GPU를 아예 안 거친다. PDF 내부 구조(폰트, 텍스트 operator, 이미지 coverage)를
pdf-inspector가 렌더링 없이 millisecond 단위로 읽어 그대로 텍스트를 뽑는다. - Lane-based GPU routing — GPU가 필요한 페이지만 보내되, 문서 크기별로 lane을 분리한다. 200페이지 리포트가 들어와도 1페이지 송장 처리 latency가 영향받지 않는다.
- Region-tuned OCR — 표·수식·텍스트 블록을 별도 region으로 감지해 각각 다른 토큰 budget과 prompt를 쓴다. 표는 25초까지 양보, 수식은 LaTeX로 보존, 텍스트는 12초·256토큰으로 잘라 효율 우선.
금융 리포트 같은 mixed 문서를 떠올리면 차이가 분명하다. 150페이지가 텍스트 기반이고 60페이지만 스캔이라면, 이전에는 210페이지 전부 OCR을 돌렸다. Fire-PDF는 60페이지만 GPU로 보낸다. 속도와 비용이 거의 비례 절감되는 구조.
그래서 뭐가 달라지는 건데?
비용보다 더 큰 건 파이프라인 단순화다. 회사가 RAG/에이전트를 운영하면 보통 이런 그림이었다.
| 처리 대상 | 이전 — 갈라진 스택 | 이후 — Firecrawl 통합 |
|---|---|---|
| 웹 페이지 | Firecrawl /scrape |
/scrape + Lockdown 옵션 |
| 웹에 있는 PDF/DOCX | 다운로드 → 별도 파서 | /scrape URL만 던지면 자동 감지 → Fire-PDF로 처리 |
| 로컬 파일/사용자 업로드 | PyMuPDF + Unstructured + Tesseract 조합 | /parse에 파일 업로드 한 번 |
| 구조화 추출 (계약 당사자, 송장 합계) | 파싱 → LLM 호출 → JSON 정규화 (3단계) | /parse 호출에 schema 함께 전달 (1단계) |
| 출력 포맷 | 도구마다 다름 — 후처리 필수 | 전부 Markdown / JSON 통일 |
| 민감 문서 (계약·의료) | 자체 인프라 + 별도 보안 검토 | Enterprise ZDR — 응답 후 즉시 폐기 |
RAG 파이프라인 운영해본 입장에서 보면, 표 마지막 두 줄이 진짜 가치다. "파싱 → LLM 호출 → JSON 정규화"가 한 줄로 줄어드는 건 단순한 라인 수 문제가 아니라, 에러 표면이 1/3로 줄어든다는 뜻이다. 중간 단계마다 retry/fallback/검증 로직이 사라진다.
/parse는 매 호출마다 재파싱한다 — 캐시가 없다. 같은 파일을 여러 번 올리면 매번 과금된다. 사용자 업로드를 받는 서비스라면 파일 hash 기반 자체 캐시 레이어를 앞에 두는 게 합리적이다.
핵심만 정리: 시작하는 법
- 1단계 — 분기점부터 결정
웹에 공개된 URL이면/scrape, 로컬 파일이거나 인증 뒤 파일이면/parse. Firecrawl 가이드도 이 분기로 시작한다. - 2단계 — PDF 모드 명시
스캔본이 많으면parsers: [{type:"pdf", mode:"ocr"}]. 텍스트 PDF면mode:"fast". mixed면 기본auto로 두면 된다. - 3단계 — schema 함께 던지기
계약서·송장처럼 정해진 필드를 뽑을 거면formats에{type:"json", schema:{...}}를 같이 넣는다. 후속 LLM 호출 한 단계가 사라진다. - 4단계 — 큰 PDF는 maxPages로 제한
200페이지 리포트 전체가 필요한 경우는 드물다.maxPages: 50같은 cap을 둬서 비용·latency를 묶는다. timeout도 함께 늘려준다 (기본 30초 → 최대 5분). - 5단계 — 민감 문서는 ZDR 플랜으로 분리
계약·의료·내부 리포트는 ZDR이 켜진 Enterprise 키로 호출하고, 일반 RAG는 standard 키로 분리. 키 단위로 데이터 잔존 정책이 갈린다.
자주 묻는 질문
이미 Unstructured.io나 LlamaParse 쓰고 있는데 갈아탈 가치가 있나?
속도와 비용 면에서 Fire-PDF가 우위지만, "기존 스택이 안 깨졌으면 그냥 두라"가 솔직한 답이다. 갈아타는 진짜 가치는 웹 스크레이프와 파일 파싱이 같은 엔진이라는 점에서 나온다. 웹 데이터를 같이 쓰는 RAG/에이전트라면 출력 포맷·과금·SDK가 통일되는 운영 단순화가 크다. 파일만 처리하는 워크플로우라면 즉시 마이그레이션 우선순위는 낮다.
Fire-PDF로 표/수식 처리 품질이 실제로 얼마나 올라가나?
Firecrawl이 공식적으로 정확도 벤치를 공개하진 않았지만, 구조 자체가 다르다 — 표는 토큰 budget을 25초까지 양보하고, 수식은 LaTeX 보존 prompt가 별도, multi-column reading order는 neural 모델이 예측하고 XY-cut을 fallback으로 둔다. 학술 논문, 금융 리포트, 법률 문서처럼 "기존 OCR이 표를 헝클어뜨려서 못 쓰던" 문서가 1차 수혜 영역이라고 보면 된다.
50MB 제한이 걸리는데, 큰 PDF는 어떻게 처리하나?
두 가지 패턴이 있다. (1) 클라이언트에서 PDF를 페이지 단위로 분할(예: PyPDF2 split) 후 /parse 병렬 호출 — 한 번에 한 파일이 원칙이라 batch upload는 없다. (2) maxPages 옵션으로 처음 N페이지만 추출 — 보고서 요약·meta 추출 용도면 충분하다. 수백 MB 단일 PDF는 사실상 (1)이 유일한 답이다.
Lockdown Mode와 같이 쓸 수 있나?
현재 Lockdown은 /scrape 전용이다. /parse는 outbound 요청 자체가 없는 엔드포인트(파일 바이트를 직접 받음)라 Lockdown 같은 cache-only 보호가 의미가 없다. 다만 ZDR 옵션으로 응답 후 데이터를 즉시 폐기할 수 있어 보안 워크플로우의 또 다른 층이 된다. 두 기능은 다른 위협 모델을 막는다 — Lockdown은 "outbound가 새는 정보", ZDR은 "공급자에 남는 정보".
