“Docker에서 Firecrawl을 실행하고 도메인 목록에 적용하여 RAG용 markdown을 얻었다”는 방식은 첫 번째 천 페이지까지는 잘 작동합니다. 그 이후에는 두 가지 문제가 발생합니다. 첫 번째는 안티봇으로부터의 문제입니다: 일부 도메인이 콘텐츠 대신 403을 반환하기 시작하고, 지식베이스에 구멍이 생기며, 이는 어시스턴트가 “제공된 자료에 정보가 없습니다”라고 응답할 때 알게 됩니다. 두 번째 문제는 트래픽에 대한 것입니다: 크롤러는 최종 markdown에 포함되지 않을 이미지와 글꼴을 정직하게 모두 가져옵니다.
2026년 가장 많이 사용되는 LLM 크롤러인 Firecrawl, Crawl4AI, Crawlee에 프록시를 연결하는 방법과 프록시가 필요한 곳에서만 작동하도록 설정하는 방법을 살펴보겠습니다.
이 가이드는 누구를 위한 것인가
RAG를 위한 문서 코퍼스를 수집하거나 내부 지식베이스를 구축하거나 재학습을 위한 데이터 파이프라인을 구축하거나 정기적으로 수백 개의 도메인을 다운로드하는 경우 이 가이드가 해당됩니다. 아래의 세 가지 도구는 기본 구성에서 서버의 IP로 페이지를 전체적으로 로드합니다. 이 기본값은 변경해야 합니다.
문제의 규모는 인기 숫자로 명확합니다: Firecrawl은 게시 시점에 GitHub에서 약 17만 개의 별을 보유하고 있으며(라이센스 AGPL-3.0), Crawl4AI는 약 7만 9천 개, Apify의 Crawlee는 약 2만 5천 개입니다. 이는 더 이상 틈새 실험이 아니라 표준 도구이며, 안티봇 시스템은 그들의 행동을 당신보다 잘 알고 있습니다.
첫 번째 문제: 콘텐츠 대신 403
코퍼스를 수집할 때의 주요 오류는 크롤러가 실패하지 않았다면 성공적으로 작동했다고 생각하는 것입니다. Firecrawl과 Crawl4AI는 차단된 페이지에서 예외를 반환하는 것이 아니라 안티봇의 스탠드인 페이지, 브라우저 확인 페이지 또는 접근 거부에 대한 짧은 텍스트를 반환합니다. 형식적으로 이는 유효한 markdown이며, 벡터 데이터베이스에 저장되고 사용자 요청이 있을 때까지 그곳에 존재합니다.
따라서 프록시 설정 전에 해야 할 첫 번째 일은 결과 품질을 제어하는 것입니다. 최소한의 옵션은 특정 임계값보다 짧은 문서를 걸러내는 것입니다(일반적인 콘텐츠 페이지의 경우 500-800자의 텍스트가 합리적입니다) 그리고 텍스트에서 특유의 마커를 별도로 포착하는 것입니다 — 연결 확인, JavaScript 활성화, “Access denied” 등의 언급. 이러한 문서는 데이터베이스에 저장되지 않고 재방문 대기열로 보내집니다 — 이미 프록시를 통해.
두 번째 문제: 버리는 기가바이트
여기서는 산술이 도움이 됩니다. 2025년 HTTP Archive의 Web Almanac에 따르면, 중간의 메인 페이지는 데스크탑에서 약 2.86MB, 모바일에서 2.56MB의 크기를 가집니다. 이 중 이미지가 메인 페이지에서 약 1,059KB, 내부 페이지에서 911KB를 차지하고, JavaScript는 각각 697KB와 632KB입니다. 즉, 이미지는 페이지의 약 1/3을 차지하는 가장 무거운 카테고리입니다.
이제 결과로 무엇을 하는지 기억해 보세요. 페이지를 markdown으로 변환하고 임베딩을 위해 청크로 자릅니다. 이미지는 이 파이프라인에 전혀 포함되지 않습니다 — 최선의 경우 alt 텍스트 한 줄만 남습니다. 비디오, 글꼴, 분석 스크립트, 광고 픽셀도 마찬가지입니다.
레지던트 프록시를 통해 기가바이트당 요금을 지불하면서 크롤링을 진행하면, 다음 단계에서 버리는 데이터를 배달하는 데 비용을 지불하는 것입니다. 10만 페이지의 코퍼스에서 “모두 가져오기”와 “HTML과 텍스트만 가져오기”의 차이는 비율이 아니라 배수로 측정됩니다. 정확한 절감액은 사이트의 주제에 따라 다릅니다: 미디어 및 전자상거래는 문서 및 블로그보다 더 무겁습니다.
1단계. “모두 프록시” 대신 에스컬레이션
가장 많은 비용을 절감하는 주요 아키텍처 기법은 모든 트래픽을 프록시를 통해 보내지 않도록 하는 것입니다. 지식베이스를 수집할 때 대부분의 도메인 — 문서, 블로그, 참고 사이트, 정부 포털 — 은 콘텐츠를 직접 제공하며 누구도 차단하지 않습니다. 프록시는 소수에게만 필요합니다.
올바른 방식은 다단계 에스컬레이션입니다: 먼저 직접 요청을 하고, 차단 징후가 보이면 다음 단계로 넘어갑니다. 이는 자작의 임시방편이 아니라, 두 개의 성숙한 프레임워크가 기본적으로 지원합니다.
Crawlee에서는 이를 위해 tieredProxyUrls가 있습니다. 단계는 저렴한 것부터 비싼 것까지 나열되며, 크롤러는 차단 시 자동으로 위로 올라가고, 이후 주기적으로 하위 단계로 돌아가려고 시도합니다:
const proxyConfiguration = new ProxyConfiguration({
tieredProxyUrls: [
[null],
['http://user:pass@datacenter-proxy:8080'],
['http://user:pass@residential-proxy:8000'],
]
});문서에서 중요한 점: tieredProxyUrls는 크롤러 인스턴스를 통해 사용할 때만 작동합니다. 직접 호출하는 newUrl()는 예상치 못한 결과를 초래합니다.
Crawl4AI에서는 비슷한 메커니즘이 0.8.5 버전에서 도입되었으며 현재 버전(게시 시점의 최신 릴리스는 2026년 7월 15일의 v0.9.2)에서 사용되고 있습니다. 이를 proxy escalation이라고 하며 CrawlerRunConfig에서 직접 설정할 수 있습니다: 세 가지 단계의 차단 감지 — 알려진 안티봇 공급업체, 일반적인 차단 지표 및 페이지 구조적 무결성 검사 — 그리고 프록시 체인을 통한 자동 재시도입니다.
from crawl4ai import CrawlerRunConfig
from crawl4ai.async_configs import ProxyConfig
config = CrawlerRunConfig(
proxy_config=[ProxyConfig.DIRECT, ProxyConfig(server="http://my-proxy:8080")],
max_retries=2,
)ProxyConfig.DIRECT가 첫 번째 요소라는 점에 유의하세요 — 이는 “먼저 프록시 없이 시도해보세요”를 의미합니다.
2단계. 각 도구에서 프록시 연결하기
다음은 설정에 대한 구체적인 내용입니다. 작업 순서는 동일합니다: 먼저 프록시, 그 다음 불필요한 트래픽 차단, 마지막으로 확인입니다.
- Firecrawl (자체 호스팅). 프록시는 Playwright에 전달되는 세 개의 환경 변수로 설정됩니다:
PROXY_SERVER,PROXY_USERNAME,PROXY_PASSWORD. 이는.env의apps/api에 작성되며, 개발자는 주석에서 정적 주소 대신 요청마다 IP를 회전하는 프록시 서비스를 지정할 수 있다고 명시합니다. - Crawl4AI. 프록시는
BrowserConfig내의proxy_config에 위치하며, 이는ProxyConfig객체 또는server,username,password필드를 가진 딕셔너리입니다. 하나의 브라우저 구성은 크롤링 세션 전체에 사용되며, 각arun()호출에 대해 별도의CrawlerRunConfig가 전달됩니다. - Crawlee.
ProxyConfiguration클래스는proxyUrls옵션을 가지고 있으며, 이는 라이브러리가 순환하는 주소 목록입니다(라운드 로빈). 목록에서null값은 “프록시 없이”를 의미합니다. 통합은 전방위적입니다:HttpCrawler,CheerioCrawler,JSDOMCrawler,PlaywrightCrawler,PuppeteerCrawler. - 특정 규칙. 어떤 도메인이 차단되고 어떤 도메인이 차단되지 않는지 알고 있다면, Crawlee에는
newUrlFunction이 있습니다 — 요청 URL을 기반으로 프록시를 선택하는 자체 논리입니다. 화이트 도메인에는null을 반환하고, 나머지에는 프록시 주소를 반환합니다. 이는 목표 목록이 안정적일 때 가장 저렴한 옵션입니다. - 확인. 실제 실행 전에 설정된 크롤러를 통해 외부 IP를 반환하는 페이지를 통과시켜 프록시 주소가 서버 주소가 아닌지 확인하세요. 세 줄의 코드로 하루의 문제를 절약할 수 있습니다.
3단계. 텍스트가 되지 않을 모든 것 차단하기
프록시가 연결되면 트래픽 절약을 활성화하세요 — 그렇지 않으면 기가바이트 요금이 코퍼스를 수집하기 전에 더 빨리 도착할 것입니다.
Firecrawl에서는 이를 위해 BLOCK_MEDIA 변수가 있습니다. 공식 구성 예제에는 “프록시 대역폭을 절약하기 위해 미디어 요청을 차단하려면 설정하세요”라는 주석이 있습니다. 이는 주요 비용 항목을 제거하는 가장 빠른 방법입니다.
Crawl4AI에서는 유사한 조정이 BrowserConfig 내에 있습니다: text_mode는 이미지를 비활성화하고 텍스트 크롤링을 가속화하며, light_mode는 브라우저의 일부 백그라운드 기능을 비활성화하고, avoid_css는 CSS 로드를 차단합니다. 이들은 조합할 수 있습니다. RAG를 위한 코퍼스를 수집할 때는 거의 항상 올바른 조합입니다 — 레이아웃은 필요 없고, 텍스트가 필요합니다.
Crawlee에서는 다른 논리가 적용됩니다: 콘텐츠가 HTML로 제공되면 브라우저 기반 크롤러 대신 CheerioCrawler 또는 HttpCrawler를 사용하세요. 일반 HTTP 요청은 완전한 렌더링 대신 트래픽을 절약할 뿐만 아니라 비용 구조를 다르게 만듭니다. 브라우저 크롤러(PlaywrightCrawler, PuppeteerCrawler)는 JavaScript 없이 수집되지 않는 페이지에만 남겨두세요.
주의사항
세션 대 회전. 각 요청마다 IP를 변경하는 것은 의심스럽게 보이며 다단계 시나리오를 깨뜨립니다 — 페이지네이션, 동일 도메인 내 전환. Crawlee에서는 각 newUrl() 호출이 프록시를 Session 객체와 연결하며, 이들은 브라우저의 지문 및 헤더와 함께 회전합니다. 이 연결을 수동으로 끊지 마세요.
미디어는 비활성화되었지만 콘텐츠가 사라졌습니다. 일부 사이트는 지연 로딩을 통해 이미지뿐만 아니라 텍스트도 가져옵니다. text_mode 또는 BLOCK_MEDIA를 활성화한 후에는 반드시 20-30페이지의 샘플을 통과시켜 텍스트 양을 기준과 비교하세요.
제한 없는 재시도. 프록시 레벨의 에스컬레이션은 한 페이지가 세 번 다운로드될 수 있음을 의미하며 — 세 번 모두 비용이 발생합니다. max_retries를 제한하고, N번의 실패 후 크롤링에서 제외할 도메인 목록을 만드세요.
Robots.txt 및 법적 프레임워크. 2026년 데이터 수집 및 RAG는 몇 년 전보다 더 엄격하게 규제됩니다 — 출처 공개 요구 사항부터 text and data mining에 대한 거부 메커니즘까지. 파이프라인이 이러한 신호를 존중하는지 확인하세요, 수십만 페이지에서 작동하기 전에.
RAG 파이프라인에 적합한 프록시 유형
답은 당신이 어떤 에스컬레이션 수준에 있는지에 따라 다릅니다.
- 제로 레벨 — 프록시 없음. 문서, 오픈소스 프로젝트, 정부 사이트, 대부분의 기업 블로그. 여기서는 서버의 IP가 정상적으로 작동하며, 비용이 발생하지 않습니다.
- 미들 레벨 — 데이터센터 프록시. 빠르고 저렴하며, 단순한 속도 제한 및 지역 제한에 적합합니다. 대규모 코퍼스를 수집할 때는 작업용 말입니다: 용량이 수백 기가바이트로 측정될 때, 기가바이트당 가격 차이가 주요 요소가 됩니다.
- 상위 레벨 — 레지던트 프록시. 강력한 안티봇 보호가 있는 도메인에 적합하며, 데이터센터 서브넷은 입구에서 차단됩니다. 그래서 기본값으로 설정할 수 없습니다 — 기가바이트당 요금이 추가적인 이미지를 비용 항목으로 만듭니다.
파이프라인을 구축하기 전에 경제성을 정직하게 계산하는 것이 좋습니다: 우리는 백만 페이지 파싱의 전체 비용을 페이지의 무게, 재시도 및 숨겨진 비용을 고려하여 분석했습니다. 그리고 첫 번째 코드 줄을 작성하기 전에 유용하게 물어볼 질문이 있습니다: 크롤링이 정말 필요한가 — 공식 API 대 준비된 데이터셋 및 파싱의 분석에서 일부 출처의 경우 준비된 데이터가 자체 크롤러보다 저렴하다는 것을 알 수 있습니다.
결론
LLM 크롤러에서 프록시는 단순한 “켜기/끄기” 스위치가 아니라 세 단계의 구조입니다. 기본 레벨로 직접 요청, 중간 레벨로 데이터센터 프록시, 레지던트 프록시는 다른 방법으로는 수집할 수 없는 도메인에만 사용됩니다. 또한 미디어를 엄격히 차단해야 합니다, 왜냐하면 당신은 텍스트를 수집하고 바이트에 대해 비용을 지불하기 때문입니다.
작업 순서는 간단합니다: 먼저 결과 품질을 제어합니다(그렇지 않으면 코퍼스의 절반이 스탠드인 페이지라는 것을 알지 못할 것입니다), 그 다음 프레임워크의 도구를 통해 프록시를 에스컬레이션하고, 마지막으로 트래픽을 절약합니다. 이 순서대로 진행하면 코퍼스는 완전해지고, 비용은 예측 가능해집니다.
```