--- title: "Crawl4AI, 사용자들은 실제로 뭐라고 말할까 — 칭찬과 불만을 2년치 글에서 종합했다" date: 2026-10-10 model: qwen3.6-plus author_type: human category: reviews summary: "무료·오픈소스·자체호스팅이라는 문구에 끌려 설치한 뒤 운영 비용을 치르는 사람들이 지적하는 것들. Reddit·Hacker News·독립 벤치마크·GitHub 보안 권고까지 읽고 낸 결론은 하나로 좁혀진다. Crawl4AI는 '무료 대체재의 최상위'이면서 동시에 'DevOps를 그대로 떠안는 도구'다." tags: Crawl4AI, 웹 크롤링, 웹 스크래핑, 오픈소스, Firecrawl 비교, RAG, AI 에이전트, 자체호스팅, 보안, 실사용자 리뷰 --- ## Crawl4AI, 사용자들은 실제로 뭐라고 말할까 — 칭찬과 불만을 2년치 글에서 종합했다 Crawl4AI를 검색하면 대부분의 글은 한 문장으로 압축된다. "Firecrawl 대체, 무료, Apache 2.0, GitHub 수만 스타." 그 문장이 틀렸다고 말하는 사람은 없다. 문제는 그 문장이 전부라는 착각이다. 이 글은 Crawl4AI를 처음 써 본 사람의 첫인상이 아니라, 이미 수개월에서 6개월을 운영한 사용자들이 Reddit과 Hacker News, 기술 블로그, GitHub 보안 권고에 남긴 평가를 모아 읽은 결과다. 결론부터 말하면 **"무료라는 사실은 맞고, 그 무료의 대가가 무엇인지도 사용자들은 정확히 알고 있다"**는 것이다. --- ### 1. 이 글의 자료 범위와 한계 | 자료 | 성격 | | --- | --- | | Reddit r/AgentsOfAI, r/LocalLLaMA, r/webscraping, r/n8n, r/hermesagent | 실제 사용 후기, Firecrawl 대비 비교 체험기 | | Hacker News, 기술 블로그(6개월 운영 후기, 독립 리뷰어 실측) | 장기 운영 경험, 직접 측정 수치 | | Spider.cloud 벤치마크(1,000 URL), Datacelix·flybyapis 비교 | 성공률·비용 비교 (단, 비교 주체가 경쟁사인 자료 포함) | | GitHub Security Advisories, 공식 셀프호스팅 문서 | 취약점 이력과 0.9.0 이후 보안 기본값 | 한계도 분명하다. 대부분의 자료가 영어권 개발자 커뮤니티 기반이고, 성공률 비교는 공급사가 직접 돌린 벤치마크가 섞여 있다. 아래 수치는 전부 출처를 밝힌 채로만 인용했으며, 필자가 새로 측정한 값은 없다. --- ### 2. 사용자들이 실제로 칭찬하는 것 **첫 번째, "가격이 0원이라는 말이 반박이 안 된다."** r/AgentsOfAI에 올라온 Firecrawl·Crawl4AI 동시 사용기([원문](https://www.reddit.com/r/AgentsOfAI/comments/1t3pe4e/firecrawl_vs_crawl4ai_i_tried_both_and_heres_what/))는 Docker 설치에 "대략 1시간"이 들었고 "출력은 괜찮으며, 공짜라는 사실은 반박하기 어렵다"고 요약한다. 예산이 없는 1인 프로젝트에는 여기서 논쟁이 끝난다. **두 번째, "Firecrawl 토큰이 떨어져서 갈아탔다."** r/n8n에서는 "문서 크롤링에 Firecrawl 쓰고 있다면 Crawl4AI로 바꾸라. 더 좋다"는 글이, r/hermesagent에는 "어젯밤 Firecrawl 토큰이 떨어져서 짜증이 나서 로컬에 Crawl4AI를 띄웠다"는 글이 올라왔다. 즉 상당수 이사는 **유료 티어에 찔린 경험이 출발점**이다. **세 번째, "리터럴한 마크다운이 나온다."** SearchTools.ai의 리뷰 집계에서 사용자가 가장 자주 언급한 항목은 출력 품질(17회 언급)이었고, 칭찬 표현은 "LLM에 최적화된 깔끔한 마크다운"이었다. 독립 리뷰어가 실측한 수치도 같은 방향이다. thunderbit 리뷰에서는 문서 사이트에서 한 번의 호출로 마크다운 13,476자를 뽑았고, ToolRiot의 실측에서는 Hacker News 목록에서 검증 가능한 레코드 30건을 받아냈다. **네 번째, "설정하면 끝이 아니라, 문서와 튜토리얼이 촘촘하다."** 사용자 리뷰 집계에서 가장 많이 언급된 항목은 사용 편의성(20회 언급)이었고, "공식 문서와 튜토리얼이 방대하다"는 표현이 반복해 나왔다. 에이전트 플러그인으로 붙여 쓰는 사례도 보인다. Crawl4AI 서버는 MCP를 직접 지원해 Claude Code 같은 MCP 클라이언트에 바로 물릴 수 있다(공식 셀프호스팅 문서). **다섯 번째, 토큰 절감 효과.** 장기 운영 후기를 쓴 한 사용자는 `fit_markdown` 필터를 쓰지 않을 때와 쓸 때를 비교해 페이지당 평균 토큰이 4,500에서 1,200으로 줄었다고 기록했다(ITNotes, 6개월 운영 후기). 다른 리뷰어는 로컬 테스트 페이지에서 원시 HTML 2,190자 → `raw_markdown` 1,268자 → `fit_markdown` 805자로 줄어드는 과정을 표로 남겼다. **핵심은 "무료"가 아니라 "필터를 켜면 입력비가 눈에 띄게 준다"는 점**이다. --- ### 3. 사용자들이 실제로 불만을 표하는 것 **"설치가 절대 가볍지 않다."** 첫 사용기는 Docker 설치 1시간, 최소 4GB RAM 요구, 기계에 따라 Docker가 까다롭다는 점을 지적한다. 독립 리뷰어는 1회 설치 시 브라우저 스택 두 종과 FFmpeg, 헤드리스 셸이 디스크에 깔린다고 기록했다. SearchTools 집계에서도 "비개발자에게는 복잡한 설치", "Docker 배포 난이도"가 반복 불만으로 잡혔다. **"몇 주는 멀쩡하다가 조용히 무너진다."** 네 달간 두 도구를 병행한 사용자의 체험이나 정리되는데, "Crawl4AI Docker 배포는 3주 뒤부터 요청을 무작위로 떨어뜨리기 시작했고 깔끔한 해결책을 찾지 못했다"는 증언이 남아 있다(중개 글: Datacelix). 원인은 Crawl4AI의 버그라기보다 헤드리스 브라우저를 직접 관리하는 일 자체의 무게다. Chromium 좀비 프로세스와 메모리 압박이라는 표현이 함께 등장한다. **"복잡한 상호작용에는 오히려 방해가 된다."** 한 개발자는 IMDB 평점 탭을 넘기며 3만 편을 수집하는 작업에서 3일을 망한 끝에 Crawl4AI를 버리고 Playwright를 직접 썼다고 썼다. JavaScript를 Python 문자열 안에 넣어 굴리는 구조 때문에 오류가 "브라우저 안, 그 안의 JavaScript 블롭 안"에서 검은 상자로 죽는다는 것이다. 그의 요약은 이렇다. **"추상화는 80%에는 훌륭하다. 나머지 20%에서는 장애물이 된다."** **"버전이 빠르게 움직인다."** 한 리뷰어는 "프로젝트가 빠르게 움직여 API 이름이 버전마다 바뀌고, 문서의 클래스 이름이 저장소 코드와 일치하지 않는 곳이 있다. 버전을 고정하라"고 경고했다. 빠른 발전은 장점의 이면이다. **"기본값이 깨끗하지 않다."** `raw_markdown`을 그대로 받으면 내비게이션·사이드바·쿠키 배너·푸터까지 함께 들어온다. 정제는 사용자가 필터를 명시해야 하는 **선택 동작**이지 기본값이 아니다. --- ### 4. 놓치기 쉬운 함정 세 가지 이 대목에서 독립 리뷰어 thunderbit의 실측은 특히 유용하다. 그는 "동적 페이지를 다룬다"는 문구가 실제로 뜻하는 바를 실험으로 갈랐다. | 상황 | 결과 | | --- | --- | | 정적 페이지 추출 | 기대한 6개 항목 모두 확인 | | JS 페이지 + `wait_for` 명시 | 기대한 8개 항목 모두 확인 | | JS 페이지, `wait_for` 없이 | 절반만 그려진 페이지를 긁어옴 | | BFS 딥 크롤 (5페이지 발견) | 3개 성공, 2개 실패 — **`wait_for`가 상속되지 않음** | 즉 "Crawl4AI는 동적 페이지를 지원한다"는 문구와 "딥 크롤이 자동으로 동적 페이지를 기다려 준다"는 문구는 서로 다른 약속이다. 전자는 맞고 후자는 그렇지 않다. 두 번째 함정은 **오해를 부르는 에러 메시지**다. 의도적으로 깨진 500 페이지를 집어넣자 요청은 정상적으로 실패(500)를 보고했지만 메시지는 "anti-bot protection 차단: 작은 페이지의 최소 텍스트"였다. 차단하는 장치는 없었고, 텍스트가 적다는 구조 판정이 메시지를 오도한 것이다. **대규모 수집에서 이 문구를 그대로 신뢰하면 정상 페이지를 적대적으로 오판해 작업 전체를 그르칠 수 있다.** 세 번째는 **셀프힐링 선택자의 착각**이다. Crawl4AI의 CSS/XPath 스키마는 정적이다. 사이트가 클래스명을 바꾸면 사용자가 고쳐야 한다. 적응형 셀렉터는 다른 도구의 기능이다. --- ### 5. 보안: Docker API 서버의 이력과 0.9.0의 변화 실사용자 리뷰보다 먼저 알아야 할 것이 공식 보안 권고의 이력이다. GitHub Advisory Database를 보면 2026년 6~8월에 걸쳐 Crawl4AI Docker API 서버에 대한 권고가 연이어 등장했다. | 시기 | 주요 항목 | 심각도 | | --- | --- | --- | | 2026-06-02 (GHSA-365w-hqf6-vxfg) | 하드코딩 JWT 시크릿, `/screenshot`·`/pdf` 임의 파일 쓰기(CVSS 9.1), 웹훅 SSRF, 모니터 인증 우회, `/execute_js` 임의 JS 실행 | 최고 9.8 | | 2026-06-04 (GHSA-f989-c77f-r2cq) | 요청의 `base_url`로 LLM 호출을 빼돌려 서버 보유 API 키 탈취, `env:`로 임의 환경변수 읽기 → **CVE-2026-56259** | 높음 | | 2026-06-18 (GHSA-r253-r9jw-qg44) | Chromium 실행 인자 주입 기반 **미인증 원격 코드 실행** (영향 버전 ≤ 0.8.9) | 치명적 CVSS 10.0 | | 2026-08-31 | PDF 파이프라인 파일 쓰기·SSRF, 플레이그라운드 DOM XSS로 토큰 탈취, `/crawl/stream` 미인증 SSRF | 높음~중간 | 이 권고들이 한 방향으로 가리키는 것은 하나다. **문제의 대부분은 Docker API 서버에 있다.** 즉 "자체호스팅하면 데이터가 내부에 안전하다"는 문장은, 동시에 "그 서버를 내가 지켜야 한다"는 뜻이다. 좋은 소식은 0.9.0에서 기본값이 바뀌었다는 점이다. 공식 셀프호스팅 문서는 0.9.0 이상을 "secure-by-default"로 규정한다. 토큰이 없으면 서버가 컨테이너 안 루프백에만 바인딩되어 외부 포트가 연결을 거부하고, 요청 본문은 신뢰 경계로 검증되며, `extra_args` 같은 위험 필드는 아예 거부된다. 예전에 Python 코드 문자열을 받던 훅 API는 "미인증 원격 코드 실행 표면"이었다는 이유로 제거되고 선언형 훅으로 대체됐다. 권고도 분명하다. 포트 11235를 인터넷에 열지 말 것, 인증을 켜고, 뒤에 리버스 프록시를 둘 것. **즉 "0.9.0 이상 + 토큰 설정 + 포트 폐쇄" 세 가지를 지키느냐가 이 도구의 보안 실체를 가른다.** --- ### 6. Firecrawl과의 갈림길 — 사용자 판정 | 구분 | Crawl4AI | Firecrawl | | --- | --- | --- | | 라이선스 | Apache 2.0 | 코어 AGPL-3.0 (SDK는 MIT) | | 월 10만 페이지 비용 | 인프라 약 70~80달러 수준 | 스탠다드 기준 83달러(연간 선불) / 99달러(월 결제) | | 성공률(독립 벤치마크, 1,000 URL) | 전체 89.7%, 보호 페이지 72.0% | 전체 95.3%, 보호 페이지 88.4% | | 노이즈 비율 | 11.3% | 6.8% | | 데이터 경로 | 전부 내 서버 | Firecrawl 인프라를 경유 | | 난이도 | 당신이 인프라를 운영 | 당신은 URL만 준다 | 주석이 필요하다. 성공률 수치는 비교 주체인 Spider.cloud가 돌린 벤치마크라 유리하게 설계됐을 가능성이 있고, 반대로 Crawl4AI의 기본 설정은 프록시를 끼우지 않은 순수 상태다. 그래서 이 수치는 절대값이 아니라 **"기본값 그대로의 간극"**으로 읽어야 한다. 사용자들의 실제 판단은 두 문장으로 수렴한다. 첫째, **라이선스가 갈린다.** 자기 제품 안에 담아 배포해야 하는 팀에게 AGPL은 법적 협의가 필요한 문제고, Apache 2.0은 그 대화 자체가 없다. 둘째, **규제 데이터가 갈린다.** 데이터가 네트워크 밖으로 나가면 안 되는 환경에서는 Firecrawl은 구조적으로 탈락이다. 그리고 많은 사용자가 택하는 것은 이 둘 중 선택이 아니라 **병행**이다. "쉬운 80%는 자체호스팅으로 돌리고, 적대적인 20%만 유료 API에 태운다"는 전략이 반복해 제안된다. 무료 옵션이 실패했을 지점에서만 페이지 단위로 지불하면 블렌드 비용이 어느 한쪽만 쓰는 것보다 싸진다. 비용 감각에 대해서는 한층 냉정한 지적이 있다. 월 10만 페이지에서 Firecrawl 83달러와 자체호스팅 인프라 70~80달러는 사실상 같다. **"유료가 더 비싸다"는 문장은 엔지니어링 시간을 빼고 쓴 계산이며, 시간에도 가격이 있다는 것이다."** --- ### 7. 누가 써야 하고, 누가 피해야 하는가 **추천하는 사람** - Python 파이프라인 안에서 RAG·에이전트용 텍스트를 뽑는 개발자 - 페이지당 비용을 0으로 만들고 대신 서버를 감당할 인력이 있는 팀 - 데이터가 사무실 밖으로 나가면 안 되는 환경 - 사이트별로 다른 추출 규칙을 직접 짜야 하는 고부가가치 수집 **피해야 할 사람** - 코드를 쓰지 않고 URL만 넣어 쓰려는 사람 — 그러면 유료 API가 답이다 - 한두 개 정적 페이지를 가끔 뽑는 사람 — 설치 비용에 못 이긴다 - 클릭·탭 전환이 반복되는 상호작용 수집 — 오히려 Playwright를 직접 쓰는 편이 빠르다 - Docker 포트를 외부에 열어 둔 채 업데이트를 미루는 서버 운영자 — 이 조건만으로 자격이 없다 --- ### 8. 사용자들이 남긴 팁 다섯 가지 1. **`fit_markdown`을 명시하라.** 기본은 원시 마크다운이다. 토큰 절감은 선택해야 생긴다. 2. **동적 페이지는 `wait_for`를 페이지 단위로 물려라.** 딥 크롤은 자동으로 상속하지 않는다. 3. **버전을 고정하고 0.9.0 이상으로 올려라.** API 이름이 자주 바뀐다. 인증 토큰을 켜고 포트는 외부에 열지 말 것. 4. **동시성을 5~10으로 제한하라.** 한 사이트에 50개를 동시에 때리는 것은 차단을 부르는 행위다. 5. **"anti-bot" 메시지를 그대로 믿지 말라.** 상태코드와 실제 페이지를 확인하라. 얇은 오류 페이지도 같은 메시지를 쓴다. --- ### 9. 결론 — "무료"가 아니라 "내가 운영하는 것" Crawl4AI에 대한 사용자 평가는 이미 오래전에 갈렸다. 갈린 지점은 성능이 아니라 **정산 방식**이다. Firecrawl이 릴리어블함을 렌트하는 방식이라면, Crawl4AI는 통제권을 사들이는 방식이다. 한 비교 글이 남긴 문장이 이 도구를 가장 정확히 요약한다. > "Crawl4AI는 인프라 규율이 있는 팀에게 보상하고, 그렇지 않은 팀에게 벌을 준다." 무료라서 설치한 사람 대부분이 3주 뒤 요청 드롭과 싸우는 이유도, 결국 6개월을 버틴 사람들이 "캐시·필터·동시성 세팅"을 팁으로 공유하는 이유도 같은 문장 안에 있다. **무료는 맞다. 다만 운영은 남는다.** 같은 계열의 실전 자료: [웹 크롤링 완벽 가이드](/knowhow/2026-09-24-web-crawling-complete-guide/) · [대형 테크 크롤러의 방문, 그 의미](/knowhow/2026-10-10-bigtech-crawlers-visit/) · [Crawl4AI 에이전트 허브 항목](/agents/crawl4ai/) · [웹 검색 API 솔직 후기](/reviews/2026-10-09-web-search-api-honest-review/) --- ### 출처 - Reddit: [Firecrawl vs Crawl4AI, I tried both (r/AgentsOfAI)](https://www.reddit.com/r/AgentsOfAI/comments/1t3pe4e/firecrawl_vs_crawl4ai_i_tried_both_and_heres_what/) · [문서 크롤링은 Crawl4AI가 낫다 (r/n8n)](https://www.reddit.com/r/n8n/comments/1l624u2/if_youre_doing_scraping_with_fire_crawl_to_get/) · [Firecrawl 토큰 소진 후기 (r/hermesagent)](https://www.reddit.com/r/hermesagent/comments/1viebzr/crawl4ai_webextract_plugin_easy_install/) · [최고의 스크래퍼 도구 논의 (r/LocalLLaMA)](https://www.reddit.com/r/LocalLLaMA/comments/1jw4yqv/what_is_the_best_scraper_tool_right_now_firecrawl/) - 독립 실측: [thunderbit Crawl4AI Review (2026)](https://thunderbit.com/blog/crawl4ai-review) · [Halit Yeşil: Crawl4AI field notes](https://halityesil.com/en/crawl4ai-llm-web-crawler-review/) · [ToolRiot: HN을 JSON으로 (0.9.1 실측)](https://toolriot.com/posts/we-used-crawl4ai-to-turn-hacker-news-into-json) · [ITNotes: 6개월 운영 후기](https://itnotes.dev/building-a-smart-web-scraper-with-crawl4ai-and-python-a-6-month-production-review/) - 비교·비용: [Spider.cloud 1,000 URL 벤치마크(경쟁사 자료)](https://spider.cloud/blog/firecrawl-vs-crawl4ai-vs-spider-honest-benchmark/) · [Datacelix 비교](https://datacelix.com/crawl4ai-vs-firecrawl/) · [flybyapis: Managed SaaS vs Free Open Source](https://flybyapis.com/blog/firecrawl-vs-crawl4ai/) · [Doolpa 리뷰 집계](https://doolpa.com/article/crawl4ai) · [SearchTools.ai 리뷰 집계](https://searchtools.ai/t/crawl4ai) - 복잡한 상호작용 실패기: [Medium: 3일간 잘못된 도구를 쓴 이유](https://medium.com/@mustaphaliaichi/happy-new-year-from-a-guy-who-just-spent-three-days-learning-he-was-using-the-wrong-tool-20bf0450e58c) - 보안: [GitHub Security Advisories (unclecode/crawl4ai)](https://github.com/unclecode/crawl4ai/security) · [GHSA-r253-r9jw-qg44 미인증 RCE](https://github.com/unclecode/crawl4ai/security/advisories/GHSA-r253-r9jw-qg44) · [GHSA-f989-c77f-r2cq 자격증명 탈취](https://github.com/advisories/GHSA-f989-c77f-r2cq) · [GHSA-365w-hqf6-vxfg Docker API 다중 취약점](https://github.com/unclecode/crawl4ai/security/advisories/GHSA-365w-hqf6-vxfg) - 공식: [셀프호스팅 문서 (v0.9.x)](https://docs.crawl4ai.com/core/self-hosting/) · [GitHub 저장소](https://github.com/unclecode/crawl4ai)