작성 계기: 공공데이터를 다루다 보면 API가 준비되어 있지 않은 경우가 있다. 나는 그런 구간에서 Firecrawl을 써보고 있고, 비슷하게 정책 추천 페이지를 운영하는 사이트도 보면서 “결국 이런 곳은 API만으로는 어렵고 크롤링 계층이 필요하겠구나”라는 생각을 했다.
연관 글
요약
Firecrawl·Crawl4AI·WaterCrawl 비교라고 제목을 바꾼 만큼, 이번 글도 세 도구를 같은 기준에서 보려 한다. 다만 아직 동일 URL 묶음으로 직접 벤치마크를 돌린 글은 아니고, 내가 공공데이터 API가 없는 페이지에 Firecrawl을 써본 경험에 공식 수치와 self-hosted 여부를 더한 후기다. 지금은 Firecrawl이 가장 손에 익지만, 사용량이 늘면 Crawl4AI나 WaterCrawl처럼 직접 운영할 수 있는 도구가 더 중요해질 수 있다.
목차
이 글에서 다루는 내용
왜 Firecrawl을 보게 됐나
공공데이터 쪽 글을 쓰면서 제일 자주 느끼는 건 “데이터는 공개되어 있는데 개발자가 바로 쓰기 좋은 API는 아닐 때가 많다”는 점이다. 어떤 자료는 검색 페이지 안에 묶여 있고, 어떤 자료는 기관 페이지에만 있고, 어떤 자료는 API가 있어도 인증·쿼리·응답 구조가 기대와 다르다.
이럴 때 원래는 공식 API를 먼저 보는 게 맞다. 다만 API가 없거나, 내가 필요한 항목이 API에 빠져 있는 구간에서는 결국 HTML을 읽어서 정리하는 방법을 고민하게 된다. 그때 Firecrawl 같은 도구가 꽤 현실적인 선택지로 보였다.
Firecrawl·Crawl4AI·WaterCrawl의 체감 차이
| 구분 | Firecrawl | Crawl4AI | WaterCrawl |
|---|---|---|---|
| 사용감 | 가입 후 API로 바로 쓰는 느낌이 강하다. | 오픈소스 라이브러리/서버를 직접 다루는 느낌이 강하다. | self-hosted 크롤링 서비스나 내부 수집기로 키우는 느낌이 강하다. |
| 장점 | 프록시, JS 렌더링, Markdown 변환 같은 귀찮은 부분을 많이 감춰준다. | 브라우저 설정, 세션, 쿠키, 추출 전략을 더 직접 제어할 수 있다. | 반복 크롤링, 큐, 저장, 모니터링처럼 운영형 수집 흐름을 생각하기 좋다. |
| 성능 체감 | 한두 페이지를 빠르게 확인하고 LLM에 넣을 텍스트를 얻는 데 편하다. | 여러 페이지를 반복 처리하거나 자체 파이프라인에 붙일 때 유리해 보인다. | 사용량이 많아져 self-hosted 운영을 전제로 보면 다시 눈이 가는 후보가 된다. |
| 비용/운영 | 무료 플랜이 있어 작게 써보기 좋지만, 많이 쓰면 과금과 한도를 봐야 한다. | 도구 자체는 무료·오픈소스지만 실행 환경, 브라우저, 서버 운영은 직접 책임져야 한다. | 무료 credits로 시작할 수 있고 self-hosted 방향성이 있지만, 운영 책임은 내가 가져가야 한다. |
후기들을 대략 종합하면 Firecrawl은 “웹을 API처럼 쓰게 해준다”는 쪽에 반응이 좋고, Crawl4AI는 “내가 직접 통제하는 LLM용 크롤러”에 가깝다. WaterCrawl은 그 중간에서 self-hosted 운영과 반복 크롤링을 더 전면에 내세우는 도구로 보인다. 그래서 순수 성능 비교라기보다, 관리형 편의성 vs 직접 제어권 vs 반복 수집 운영성의 비교로 보는 편이 더 정확했다.
숫자로 보면 어느 쪽이 커 보이나
속도와 성능은 같은 URL 묶음으로 직접 벤치마크해야 정확하다. 이번 글에서는 아직 그런 동일 조건 테스트까지는 하지 않았기 때문에, 공식 페이지와 GitHub에서 확인 가능한 숫자만 따로 놓고 봤다. 이 표는 “절대 성능 순위”라기보다 도구를 고를 때 참고할 수 있는 외형 지표에 가깝다.
| 항목 | Firecrawl | Crawl4AI | WaterCrawl |
|---|---|---|---|
| GitHub stars | 약 140.9k | 약 70.1k | 약 1.9k |
| GitHub forks | 약 8.1k | 약 7.2k | 약 235 |
| 공개 이슈 수 | 약 367개 | 약 115개 | 약 6개 |
| Self-hosted 가능 여부 | 가능. 다만 공식 안내상 hosted service와 open-source/self-host 구성이 나뉘며, 직접 운영 난이도와 AGPL 조건을 같이 봐야 한다. | 가능. 로컬/서버/Docker API 형태로 직접 돌리는 쪽이 핵심 장점이다. | 가능. README와 공식 페이지 모두 self-hosted & open source 방향을 강조한다. |
| 라이선스 | AGPL-3.0 | Apache-2.0 | GitHub API 기준 NOASSERTION/Other |
| 무료 시작 조건 | 공식 가격표 기준 월 1,000 credits / 1,000 pages, 동시 요청 2개 | 라이브러리 자체는 오픈소스. 비용은 내 실행 환경에 좌우됨 | 공식 페이지 기준 월 1,000 page credits, 동시 crawl 1개 |
| 공식 성능 주장 | README 기준 96% web coverage, P95 latency 3.4s 주장 | async browser pool, caching, 최소 hop 등을 강조하지만 대상 환경 의존 | 실시간 모니터링과 crawl speed/depth 제어를 강조하지만 공개 벤치마크 수치는 제한적 |
이 숫자만 보면 Firecrawl은 사용층과 관리형 서비스 완성도가 커 보이고, Crawl4AI는 오픈소스 크롤러로서 커뮤니티 규모가 꽤 크다. WaterCrawl은 별 수만 보면 아직 작지만, 무료 credits와 self-hosted 운영 방향 때문에 “사용량이 많아졌을 때 다시 볼 후보”로 남는다.
내 기준에서 이 행이 꽤 중요하다. 사용량이 커지면 API 과금보다 self-hosted로 돌릴 수 있는지가 더 크게 느껴진다. 그래서 Firecrawl을 더 써보되, 장기적으로는 Crawl4AI나 WaterCrawl처럼 직접 운영 가능한 선택지를 계속 같이 봐야 한다.
공공데이터 API가 없을 때의 현실적인 선택
내가 Firecrawl을 좋게 본 지점은 여기다. 공공데이터포털이나 기관 사이트에서 API가 제공되지 않는 자료를 볼 때, 일단 페이지를 읽고 Markdown이나 구조화된 텍스트로 바꿔서 확인할 수 있다. 이 과정이 생각보다 편했다. 무료 플랜도 있어서, 처음부터 인프라를 만들지 않고 작은 실험을 해보기 좋았다.
물론 이게 공식 API를 대체한다는 뜻은 아니다. 주기적으로 대량 수집해야 하거나, 약관·robots.txt·저작권 검토가 필요한 경우에는 조심해야 한다. 하지만 “이 페이지의 정책 공고를 LLM이 읽을 수 있는 형태로 바꿔보고 싶다” 정도의 실험에서는 Firecrawl이 진입 장벽을 많이 낮춰준다.
비슷한 사이트를 보며 든 생각
예를 들어 LifeReference의 2026 국가 지원 사업 추천 페이지를 보면, 사용자가 조건을 넣고 정책·지원 사업을 추천받는 구조다. 페이지 안에는 자체 REST endpoint가 있고, 겉으로 보기에는 내부에서 정리된 데이터를 바탕으로 추천 결과를 만드는 형태다.
다만 외부에서 그 사이트의 내부 구현을 볼 수는 없으니 “반드시 크롤링했다”고 단정할 수는 없다. 다만 이런 류의 서비스는 공식 API, 자체 DB, 수동 정리, 크롤링이 섞일 가능성이 높고, API가 지원되지 않는 자료는 결국 크롤링이나 수집 파이프라인이 필요해진다.
나도 비슷한 문제를 겪고 있어서 이 부분이 눈에 들어왔다. API가 깔끔하게 있으면 제일 좋지만, 현실에서는 “공개 페이지는 있는데 API는 부족한” 경우가 많다. 그래서 Firecrawl 같은 도구는 개발자가 빠르게 가설을 확인하는 데 꽤 유용하다.
주의할 점
성능 숫자만 보고 고르면 안 된다
Firecrawl 공식 자료에는 빠른 응답과 높은 커버리지 이야기가 나오고, Crawl4AI는 async browser pool, caching, 세밀한 브라우저 제어를 강조한다. 하지만 내 사이트·내 대상 페이지에서의 성능은 페이지 구조, 차단 정책, JS 렌더링, 요청량에 따라 달라진다.
크롤링은 항상 운영 책임이 따라온다
무료라서 좋다고 무작정 많이 긁으면 안 된다. 서비스 약관, robots.txt, 요청 빈도, 개인정보 포함 여부를 확인해야 한다. 특히 정책·지원금·공공데이터처럼 사람이 실제 의사결정에 참고할 수 있는 정보라면, 마지막에는 반드시 원문 링크와 최신 공고를 확인하게 해야 한다.
Crawl4AI는 “공짜”지만 완전히 공짜는 아니다
Crawl4AI는 Apache 2.0 라이선스의 오픈소스라 매력적이다. 대신 브라우저 실행, 서버 배포, 메모리, 프록시, 세션 관리는 내가 책임져야 한다. 반대로 Firecrawl은 무료 플랜이 있어 시작은 쉽지만, 규모가 커지면 플랜과 크레딧 구조를 봐야 한다.
결론
내 기준에서는 Firecrawl이 먼저 손이 간다. 공공데이터 API가 없는 기관 페이지를 빠르게 읽어 LLM용 텍스트로 바꿔야 할 때 부담이 적었다. “무료로 시작해보고, 결과가 괜찮으면 파이프라인을 고민한다”는 흐름에 잘 맞는다.
반면 장기적으로 많은 페이지를 안정적으로 돌리고, 세션·쿠키·브라우저 동작까지 직접 제어해야 한다면 Crawl4AI도 충분히 볼 만하다. 사용량이 많아지면 이전에 살펴본 WaterCrawl 쪽으로 다시 눈이 돌아가긴 한다. 그래도 아직까지 Firecrawl을 쓰면서 큰 문제를 겪지는 않았고, 무료로 시작해서 결과를 확인하는 흐름이 편해서 당분간은 Firecrawl을 조금 더 써보기로 했다.
그래서 이번 비교의 결론은 단순하다. 빠른 실험과 관리형 편의성은 Firecrawl, 직접 운영과 세밀한 제어는 Crawl4AI 쪽에 더 가깝다. 다만 내 현재 사용량과 목적에서는 아직 Firecrawl을 더 써보는 쪽이 자연스럽다.