웹 페이지의 내용을 LLM에 전달하고 싶어 하는 상황이 늘어나고 있습니다.

예를 들어, 기술 문서를 요약하고 싶다거나, 경쟁 사이트를 비교하고 싶다거나, 사내 지식 베이스(Knowledge Base)에 외부 기사를 도입하고 싶을 때, 혹은 RAG용 데이터를 수집하거나 Agent에게 조사를 맡기고 싶을 때 등이 있습니다.

하지만 실제로 웹 페이지를 가져와 보면, LLM에 전달하기 쉬운 '본문'이 아니라 거대한 HTML이 반환됩니다.

중첩된 태그, 광고, 네비게이션, CSS, JavaScript, 쿠키(Cookie) 배너, 관련 기사 링크, 푸터(Footer). 인간이 브라우저로 볼 때는 자연스럽게 읽히는 페이지라도, LLM에 그대로 전달하기에는 노이즈가 너무 많습니다.

이 문제는 상당히 단순하게 말할 수 있습니다.

웹을 크롤링(Crawl)하는 것과, LLM이 읽을 수 있는 데이터로 변환하는 것은 별개의 문제입니다.

이번에 살펴볼 Crawl4AI는 이 후자의 문제에 상당히 정면으로 대응하고 있는 OSS(Open Source Software)입니다.

Crawl4AI란

Crawl4AI는 LLM을 위한 Web crawler / scraper입니다.

공식 문서에서는 open-source LLM-friendly Web Crawler & Scraper라고 설명되어 있습니다. 기본적으로 URL을 전달하면 웹 페이지를 가져와서, LLM이나 RAG 파이프라인에서 다루기 쉬운 Markdown 등으로 변환해 줍니다.

공식 Quick Start에서도 기본적인 크롤링, Markdown 생성, 추출 전략, JavaScript로 업데이트되는 동적 페이지의 취득 방법이 소개되어 있습니다.

일반적인 스크레이핑(Scraping) 도구와 다른 점은, 단순히 HTML을 가져오는 것이 아니라 **LLM에 전달하기 위한 전처리(Pre-processing)**를 주 목적으로 한다는 점입니다.

왜 HTML 그대로는 안 되는가

LLM에게 웹 페이지를 읽게 할 때, HTML을 그대로 전달하면 몇 가지 문제가 발생합니다.

• 본문 이외의 노이즈가 많음
• DOM 구조와 의미 구조가 일치하지 않음
• 네비게이션이나 관련 기사가 본문에 섞임
• 테이블이나 코드 블록의 구조가 무너짐
• JavaScript로 나중에 로드되는 본문이 누락됨
• 토큰(Token)을 낭비함

LLM은 어느 정도 노이즈에 강하지만, 그렇다고 해서 대량의 노이즈를 전달해도 된다는 뜻은 아닙니다. 특히 RAG에서는 입력 데이터의 품질이 검색 결과와 답변 품질에 직결됩니다.

즉, 웹 페이지를 LLM에 사용하기 위해서는 다음과 같은 변환이 필요합니다.

웹 페이지
↓
HTML / DOM / 동적 콘텐츠
...

Crawl4AI는 이 중간 계층을 담당하는 도구입니다.

기본적인 사용법

설치는 Python 패키지로 수행할 수 있습니다.

pip install -U crawl4ai
crawl4ai-setup
crawl4ai-doctor

브라우저 의존성으로 문제가 발생하는 경우에는 Playwright 측의 Chromium을 설치합니다.

python -m playwright install --with-deps chromium

최소 코드는 매우 짧습니다.

import asyncio
from crawl4ai import AsyncWebCrawler
async def main():
...

result.markdown에 HTML이 아닌 Markdown으로 변환된 내용이 들어갑니다.

LLM에 전달하는 것을 전제로 한다면, 이는 큰 차이입니다. HTML 구문을 읽게 하는 것이 아니라 제목, 단락, 리스트, 링크 등을 자연스러운 텍스트 구조로서 전달할 수 있습니다.

CSS / XPath / LLM 추출

Crawl4AI는 단순히 페이지 전체를 Markdown화하는 것에 그치지 않습니다.

CLI 문서에서는 CSS, XPath, LLM을 사용한 추출 전략 및 출력 형식 지정 방법이 소개되어 있습니다.

예를 들어, 기사 본문만 가져오고 싶다면 CSS selector를 사용하는 발상이 됩니다.

from crawl4ai import CrawlerRunConfig
config = CrawlerRunConfig(css_selector=".main-content")
result = await crawler.arun(
...

고정된 구조의 사이트라면 CSS selector나 XPath로 충분합니다. 반면 페이지마다 구조가 변하는 경우에는 LLM 기반의 추출을 조합할 여지가 있습니다.

여기서 중요한 점은 Crawl4AI가 '만능 자동 추출기'가 아니라, 추출 전략을 선택할 수 있는 프레임워크라는 점입니다.

프로덕션(Production)에서 사용한다면, 다음과 같이 용도에 맞춰 구분하여 사용하는 것이 현실적입니다.

• 고정된 사이트: CSS / XPath
• 복잡한 페이지: Markdown 변환 + 후속 단계에서 LLM 추출
• RAG용: 본문 추출 + 청킹 (Chunking) + 메타데이터 (Metadata) 부여
• 모니터링 용도: 구조화된 추출 (Structured extraction) + 차이점 검출

동적 페이지 대응

웹 페이지의 상당수는 초기 HTML만으로는 본문 내용이 모두 갖춰지지 않습니다.

'더 보기' 버튼, 무한 스크롤, 클라이언트 사이드 렌더링 (Client-side rendering), SPA(Single Page Application) 등, JavaScript를 실행한 후에야 필요한 정보를 확인할 수 있는 경우가 있습니다.

Crawl4AI는 헤드리스 브라우저 (Headless browser)를 사용하여 페이지를 처리할 수 있습니다. 공식 SDK 문서에서도 AsyncWebCrawler가 기본적으로 Chromium을 실행하여 페이지를 가져오고 Markdown으로 변환하는 흐름을 설명하고 있습니다.

이 점이 단순한 HTTP 요청 기반의 스크레이퍼 (Scraper)와의 차이점입니다.

물론 Playwright를 직접 사용하면 유사한 작업을 수행할 수 있습니다. 하지만 Playwright로 페이지를 연 후에 본문 추출, Markdown 변환, 구조화, RAG용 정제까지 매번 직접 코드를 작성하는 것은 번거로운 일입니다.

Crawl4AI는 이러한 주변 처리 과정을 LLM에 최적화하여 통합해 주는 레이어 (Layer)라고 이해하면 쉽습니다.

CLI로도 사용 가능

Crawl4AI에는 CLI (Command Line Interface)도 있습니다.

crwl https://example.com

CLI에서는 Markdown 출력, JSON 출력, CSS 추출, LLM 추출, 설정 파일에 의한 제어 등이 가능합니다.

개발 중에 "이 URL을 LLM에 전달할 수 있는 형태로 만들면 어떻게 될까?"를 확인하고 싶을 때는 Python 코드를 작성하는 것보다 CLI를 사용하는 것이 더 빠를 때가 있습니다.

RAG 전처리 파이프라인을 설계할 때도, 먼저 CLI로 대상 사이트의 출력 품질을 확인한 뒤 Python 코드에 통합하는 흐름이 다루기 쉬울 것입니다.

Self-host가 가능하다는 의미

Crawl4AI는 OSS (Open Source Software)이므로 자신의 환경에서 직접 구동할 수 있습니다.

공식 문서에도 Self-Hosting 가이드가 있습니다.

이는 의외로 매우 중요한 요소입니다.

웹 추출 관련 서비스 중에는 Jina Reader나 Firecrawl 같은 편리한 선택지들이 있습니다. API로서 즉시 사용할 수 있다는 점은 큰 장점입니다.

반면, 업무용으로 사용할 때는 다음과 같은 제약 사항이 발생합니다.

• 수집 대상 URL을 외부 서비스에 전달하고 싶지 않음
• 이용량이 늘어날 경우 비용 예측이 어려움
• 추출 로직을 세밀하게 조정하고 싶음
• 사내 네트워크 내부의 페이지를 처리해야 함
• 크롤링 (Crawling) / 추출 (Extraction) / 청킹 (Chunking)을 하나의 파이프라인으로 통합하고 싶음

이러한 경우에는 OSS로서 로컬 또는 자사 환경에 구축할 수 있다는 점이 강력한 강점이 됩니다.

Firecrawl / Jina Reader와의 차이점

대략적으로 정리하면 다음과 같습니다.

Crawl4AI가 "가장 쉬운 선택지"는 아닙니다. Python 환경 구축, 브라우저 의존성, 대상 사이트별 조정이 필요합니다.

하지만 장기적으로 웹 데이터를 LLM용으로 처리하고자 한다면, 비용, 제어성, 확장성 측면에서 매력이 있습니다.

활용 분야

개인적으로 Crawl4AI가 효과적일 것으로 보이는 상황은 다음과 같습니다.

• RAG용 웹 데이터 수집: 문서나 블로그, 사양서(Specification)를 Markdown으로 변환하고, 청킹(Chunking)하여 벡터 DB에 저장.
• AI Agent의 조사 파이프라인: Agent가 웹 페이지를 가져와 Markdown으로 읽고, 요약·분류·비교 수행.
• 경쟁사 및 기술 조사: 여러 사이트의 기사나 릴리스 정보를 수집하여 업데이트된 차이점 추출.
• 사내 지식 정리: 사내 Wiki나 공개 문서를 LLM이 다루기 쉬운 형식으로 변환.
• 데이터셋 생성: 특정 도메인의 페이지를 수집하여 분류·요약·평가용으로 정제.

주의사항

편리한 도구이지만 주의할 점도 있습니다.

robots.txt와 이용 약관

크롤링 대상의 robots.txt, 이용 약관, 법적 제약 사항을 반드시 확인해야 합니다. 특히 로그인 후 접근 가능한 페이지, 유료 콘텐츠, 개인정보를 포함하는 페이지는 매우 신중하게 다뤄야 합니다.

안티 크롤링 (Anti-crawling) 대응과의 관계

브라우저 실행이나 세션 관리(Session Management)가 가능하다고 해서 대상 사이트의 제한을 무시해도 된다는 뜻은 아닙니다. 속도 제한(Rate Limit), 접속 빈도, User-Agent, 캐시(Cache) 설계는 구현 측의 책임입니다.

Markdown화해도 정보 품질은 보장되지 않는다

Markdown이 되었다고 해서 내용이 반드시 정확하다는 뜻은 아닙니다. 본문 추출 실패, 불필요한 요소의 혼입, 표(Table)의 깨짐, 링크 누락 등은 발생할 수 있습니다.

RAG (Retrieval-Augmented Generation)에 넣는 경우에는 추출 결과를 평가하는 메커니즘도 필요합니다.

Playwright 계열의 운영 비용

브라우저를 사용하는 처리는 단순한 HTTP 요청보다 무겁습니다. 대량으로 처리할 경우에는 병렬 수, 타임아웃(Timeout), 메모리, 캐시, 재시도(Retry) 설계가 필요합니다.

요약

HTML을 그대로 LLM에 전달하는 것은 작동할 수는 있지만, 안정적인 설계라고 말하기는 어렵습니다. LLM에게 웹을 읽게 하려면 페이지를 한 번 LLM이 다루기 쉬운 구조로 변환하는 처리가 필요합니다. Crawl4AI는 그 변환 계층을 담당하는 OSS (Open Source Software)입니다. Markdown화, CSS/XPath/LLM 추출 전략, 동적 페이지 대응, 셀프 호스팅 (Self-hosting)까지 하나로 묶어 제공합니다.

모델의 성능만큼이나 모델에 전달하는 데이터의 질이 중요한 것이 RAG나 Agent입니다. 웹 데이터를 LLM에 전달하는 처리를 직접 작성하고 있다면, 한 번 시도해 보시기 바랍니다.

참고

• GitHub: https://github.com/unclecode/crawl4ai
• Quick Start: https://docs.crawl4ai.com/core/quickstart/
• CLI Documentation: https://docs.crawl4ai.com/core/cli/
• SDK Reference: https://docs.crawl4ai.com/complete-sdk-reference/
• Self-Hosting Guide: https://docs.crawl4ai.com/core/self-hosting/

이 기사는 「AI Watch」에도 게재될 예정입니다. 최첨단 AI를 기술적인 내용까지 깊이 있게 분석합니다.

Discussion