지난주, 나는 고객이 보내온 스펙서류를 에이전트에게 던져봤다. .docx 파일 하나. 두꺼운 계약 조항과 표가 섞인 문서였다. 에이전트는 돌려받은 답이 없었다 — 아니, 읽을 수가 없었다. 그래서 결국 내가 직접 문서를 열어 내용을 복사하고, Markdown으로 옮겨 적고, 다시 던졌다. 30분이 날아갔다.

이건 내 개인적인 불편이 아니다. 에이전트 워크플로의 가장 큰 병목은 결국 ‘문서 입력’이다. 코드는 에이전트가 그냥 읽는다. 웹도 크롤러가 읽는다. 그런데 .docx, .pdf, .xlsx — 우리가 실제 비즈니스에서 주고받는 문서는 여전히 에이전트의 접시에서 벗어나 있다.

모든 문서가 Markdown이 되고 있다

이번 주 트렌드 리뷰에서 눈에 띈 흐름이 하나 있었다. 문서·오피스 레이어가 AI 네이티브로 재구성되고 있다는 것. 워드 파일을 받아 AI 파이프라인에 넣는 작업, PPT를 에이전트가 생성하는 작업, 엑셀 표를 RAG에 태우는 작업 — 이 모든 게 하나의 공통 분모로 수렴한다. Markdown.

그 중심에 있는 것이 firecrawl이 만든 anydoc이다. 트렌드 리포트가 9,310★로 기록한지 닷새 만에 14.4k★까지 치솟았다. 전부 문서를 깨끗한 Markdown으로 바꿔주는 라이브러리 하나가.

내가 벤치마크를 검토한 이유

솔직히 처음엔 ‘또 컨버터 하나지’ 싶었다. 하지만 트렌드 분석을 하면서 Drewgent의 실무 관점에서 이 도구가 정확히 어디에 붙는지 계산하게 됐다.

우리는 지금까지 WordPress 게시를 위해 docx/xlsx 변환을 간헐적으로 필요로 했고, 기본적으로 Markdown을 원본으로 써왔다. 그런데 이 추세는 방향이 다르다. 모든 문서를 Markdown으로 수집·생성·편집하는 레이어를 표준으로 만든다. 우리의 doc7/pdf → Markdown 처리에 anydoc이 직접 교체 후보가 될 수 있다는 판단이 섰다. 기록으로 남겼다.

특히 문장 하나가 남아있었다 — 트렌드 리뷰의 결론이었다:

기존 문서(.docx 스펙서류, 고객 양식)를 받아 AI 파이프라인에 넣는 작업이 있으면 anydoc 벤치마크가 정답.

그리고 그 다음 주, 고객의 스펙서류가 실제로 도착했다. 검토 결론이 그대로 현실이 된 순간이다.

숫자로 보는 문서 인제스트 레이어

anydoc이 왜 인제스트 레이어의 표준이 됐는지는 벤치마크가 말해준다. firecrawl의 공식 측정에 따르면, 6개 컨버터를 14개 포맷, 100개의 실제 문서로 겨뤘을 때 결과가 갈렸다.

  • 커버리지: anydoc은 14/14 포맷을 지원. libreoffice 12, unstructured 8, markitdown 6, pandoc 5, docling 4.
  • 속도: 중앙값 4.4ms. libreoffice 1,129.5ms, unstructured 572.9ms, markitdown 134.8ms.
  • 품질 점수: anydoc 94점. judge가 보는 순위에서도 14개 포맷 전부에서 가장 높은 점수.

문서 하나를 변환하는 데 걸리는 시간이 사람이 복붙하는 시간과 비교 자체가 안 된다. 그리고 이건 Rust 코어에 ML 모델도, 외부 서비스도 없는 순수 로컬 처리다.

여기서 재미있는 건 구현 방식이다. 포맷을 파일 확장자가 아니라 바이너리 콘텐츠에서 읽는다 (PDF 헤더, OLE 스트림, ZIP 패키지 타입). 확장자를 잘못 붙여 보낸 파일도 내용만 보면 올바르게 변환된다. 병합된 셀의 표, 각주, 스피커 노트, 내부 크로스레퍼런스까지 구조가 살아난다. 이것이 ‘단순 변환’이 아니라 ‘문서 이해’인 이유다.

에이전트의 입장에서 다시 보면

에이전트 워크플로 관점에서 이 도구의 진짜 가치는 다른 곳에 있다. anydoc은 Agent Skill로 배포된다. 즉, 컨버터를 쓰는 코드를 짜는 게 아니라 에이전트에게 “문서를 읽어”라고 말하는 것만으로 끝난다.

npx skills add firecrawl/anydoc 한 줄이면 에이전트가 CLI를 통해 어떤 문서든 Markdown으로 읽고 그 내용을 작업에 넣는다. Rust 코어는 노드/파이썬/브라우저(WASM) 바인딩으로도 나와 있고, 브라우저 데모는 파일을 서버로 보내지도 않고 로컬에서 변환한다. 민감한 스펙서류를 다루는 우리 같은 상황에 어울리는 설계다.

물론 한계도 명확하다. 스캔된 이미지 PDF는 anydoc 혼자 못 읽는다. 텍스트 기반 PDF만 로컬에서 처리된다. 그건 doc7 같은 VLM 기반 도구(565→829★, +46.7%)가 받는 몫이다. “Markdown 변환”이 아니라 “AI-ready 문서 이해”로 넘어가는 두 번째 레이어다. 인제스트 파이프라인은 그래서 컨버터 하나가 아니라, 텍스트 문서 → anydoc, 이미지 문서 → VLM 두 갈래가 될 것 같다.

왜 지금, 그리고 무엇이 바뀌나

이 흐름이 의미심장한 이유는 단순하다. 오피스 스위트가 AI 네이티브로 다시 그려지고 있기 때문이다. genoffice(2,091★)는 ‘AI-native 오피스 스위트’를, open-kimi-ppt-skill(1,566★)은 에이전트가 곧바로 편집할 수 있는 문서를 생성한다. 생산의 방향(에이전트→문서)과 소비의 방향(문서→에이전트)이 모두 Markdown으로 수렴한다.

내가 보기에 이건 단순한 포맷 트렌드가 아니다. 비즈니스 문서가 코드처럼 취급되는 순간이다. 코드는 diff로 비교하고, CI로 검증하고, 에이전트가 리뷰한다. 문서가 Markdown이 되면 똑같은 일이 가능해진다. 스펙서류의 변경 이력을 git으로 추적하고, 계약서 조항을 에이전트가 요약하고, 엑셀 표를 RAG에 그대로 태울 수 있다.

직접 확인해보는 법

모든 주장은 결국 한 번의 실행으로 끝나야 설득력이 있다. 아래 셋 중 아무거나 골라 하면 된다.

  1. 브라우저 데모: firecrawl.github.io/anydoc — .docx나 .pptx를 드래그하면 서버에 안 보내고 로컬에서 Markdown으로 변환된다.
  2. CLI: npx @firecrawl/anydoc report.docx — 아무 문서나 하나 집어들고 터미널에서 실행.
  3. 에이전트: npx skills add firecrawl/anydoc — 에이전트가 문서를 직접 읽도록 스킬 추가.

나도 이번 스펙서류 작업에 anydoc을 실제로 붙여보고 있다. 다음에 .docx가 도착하면 ‘내가 복붙하는 시간’이 아니라 ‘에이전트가 읽는 시간’이 되는지, 벤치마크 결론이 현장에서도 서는지 확인 중이다. 이 글이 같은 문제를 겪는 사람들의 도입 판단에 조금이라도 기준이 되길 바란다.

근거 출처

상호작용 (에이전트-드루 대화·작업)

  • 2026-08-07 트렌드 위크 8 리뷰: “문서/오피스 레이어가 AI-네이티브로 재구성” 분석 및 anydoc 벤치마크 적용 후보 결정
  • 2026-08-09 추세 검증 작업: “우리는 Markdown 네이티브, anydoc은 기존 문서(.docx 스펙서류, 고객 양식) 수신 시 정답” 결론
  • Drewgent 실무 경험: WordPress 게시 docx/xlsx 간헐 변환, doc7/pdf → Markdown 파이프라인 운용

외부 정보 (하베스터 수집·공식 문서)

  • firecrawl/anydoc GitHub README 및 벤치마크 (2026-08 확인): 14/14 포맷, 중앙값 4.4ms, 품질 94점, 콘텐츠 기반 포맷 감지, Agent Skill 배포, WASM 로컬 변환 데모
  • 트렌드 위크 8 하베스터 데이터: anydoc 9,310★ (08-07) → 14.4k★ (08-12), genoffice 2,091★, open-kimi-ppt-skill 1,566★, doc7 565→829★

실무 적용 결과는 아직 검증 단계다. 벤치마크 수치와 에이전트 경험은 별개이므로, 도입 전 반드시 자신의 문서로 직접 확인해보길 권한다.