멀쩡히 돌아가던 Python 스크립트 하나 때문에 40분을 날린 적이 있어요. 테스트한 사이트 세 곳은 멀쩡했는데, 네 번째가 Cloudflare 뒤에 있다는 걸 한참 뒤에야 알았죠. 스크래퍼는 "Checking your browser…" 화면만 빙빙 돌고, 손에 잡히는 건 챌린지 HTML뿐이었어요. 어디서 본 듯한 장면 아닌가요?
이런 경험이 있다면 결코 혼자가 아니에요. 지금 2,400만 개가 넘는 활성 웹사이트가 Cloudflare를 쓰고, 이게 전체 웹사이트의 약 22%에 해당해요. 리드 수집이든, 가격 추적이든, 부동산 리서치든, 경쟁사 분석이든, 웹에서 데이터를 모으려는 사람이라면 Cloudflare는 거의 반드시 만나는 벽이라는 뜻이에요.
문제는 대부분의 가이드가 우회법을 죽 늘어놓기만 한다는 거예요. 내 경우엔 뭐부터 해봐야 하는지는 알려주지 않죠. 이 글은 결이 좀 달라요. 우선순위가 매겨진 의사결정 트리, 솔직한 신뢰도 추정치, 그리고 다들 빼먹는 노코드 경로까지 같이 다뤄요.
- 난이도: 초급~중급(고른 방법에 따라 달라요)
- 소요 시간: 노코드는 10~30분, 코드 방식은 상황마다 제각각
- 준비물: Chrome 브라우저(노코드용), 필요하면 Python 3.9+(코드용), 그리고 대상 URL
Cloudflare 보호란 무엇이며, 왜 내 스크래퍼를 막을까?
Cloudflare는 방문자와 원본 서버 사이에 끼어드는 리버스 프록시예요. 모든 요청이 일단 Cloudflare 엣지를 통과하고, 거기서 페이지를 보여줄지, 챌린지를 띄울지, 그냥 막을지를 정해요. 여기서 중요한 포인트. Cloudflare는 내 스크래퍼가 진짜 악성인지까지 알 필요가 없어요. 충분히 자동화된 것처럼 보이거나 수상하기만 해도 차단할 수 있죠.
Cloudflare의 Bot Management는 단일 장치가 아니라 검문소를 겹겹이 쌓아둔 구조예요. IP 평판, HTTP 헤더, TLS 지문, JavaScript 실행, 브라우저 핑거프린팅, 행동 패턴까지 한꺼번에 봐요. Python requests로 Cloudflare 보호 페이지에 GET 요청을 던지면 여러 단계에서 동시에 걸려요. TLS 핸드셰이크가 다르고, JavaScript를 못 돌리고, 쿠키도 없고, 브라우저 지문도 없으니까요. 헤더 몇 개 속여서 넘어가던 시절은 이미 끝났어요.
가장 자주 보는 증상은 이래요. 403 Forbidden, 503과 함께 뜨는 "Checking your browser…", 1020 Access Denied, 끝없이 도는 챌린지 루프, 안 풀리는 Turnstile 위젯, 그리고 JSON 자리에 내려오는 챌린지 HTML이에요.
패시브 탐지: 페이지가 뜨기도 전에 Cloudflare가 확인하는 것들
페이지를 보기도 전에, Cloudflare의 패시브 레이어는 벌써 요청을 평가하고 있어요.
- IP 평판: 데이터센터 IP, 클라우드 호스팅 대역, 알려진 프록시 출구는 바로 의심받아요. 반대로 주거용 IP와 모바일 통신사 IP는 훨씬 더 신뢰받죠. 2026년 커뮤니티 사례를 봐도, 로컬 주거용 브라우징은 통과하는데 Docker나 VPS는 막힌다는 보고가 끊이지 않아요.
- HTTP 헤더 분석: User-Agent, Accept-Language, 헤더 순서, HTTP 버전을 대조해요. Chrome 136이라고 우기는데 TLS 핸드셰이크에서 "Python" 냄새가 나면 바로 들통나요.
- TLS 핑거프린팅(JA3/JA4): TLS 핸드셰이크 과정에서 클라이언트는 지원 암호화 스위트, 확장, 프로토콜 선호 패턴을 드러내요. JA3/JA4는 이걸 하나의 식별자로 압축하죠. 진짜 Chrome과 Python
requests는 남기는 "모양"이 완전히 달라요. - HTTP/2 핑거프린팅: 브라우저와 HTTP 라이브러리는 HTTP/2 SETTINGS 프레임, pseudo-header 순서, 우선순위 처리가 서로 달라요. Cloudflare의 JA4 Signals는 단일 요청의 정체뿐 아니라 요청 간 패턴까지 시간 흐름으로 추적해요.
- AI Labyrinth: Cloudflare의 최신 함정이에요. 수상한 크롤러를 그냥 막는 대신, 그럴듯한 AI 생성 허니팟 페이지로 유인해 자원을 낭비시켜요. 스크래퍼는 자기가 잡힌 줄도 모를 수 있죠.
액티브 탐지: 브라우저 안에서 실행되는 챌린지
패시브 검사로 확신이 안 서면, Cloudflare는 액티브 챌린지로 넘어가요.
- JavaScript 챌린지: 흔히 보는 "Checking your browser…" 중간 페이지예요. Cloudflare의 JavaScript Detections는 보이지 않는 스크립트를 돌려 자동화 요청을 가려내요.
- Turnstile: Cloudflare의 CAPTCHA 대체품이에요. Turnstile 위젯 모드는 Managed, Non-Interactive, Invisible로 나뉘어요. 눈에 보이는 퍼즐이 없어도 마우스 움직임, 브라우저 환경, TLS 지문을 분석하죠.
- Canvas 및 WebGL 핑거프린팅: 헤드리스 브라우저가 실제 브라우저와 다르게 렌더링되는지 확인해요.
- 행동 신호: 요청 타이밍, 스크롤 패턴, 클릭 순서까지 봐요. 3초에 50페이지를 긁는데 마우스가 멈춰 있다면 사람처럼 보일 리 없죠.
실무로 보면, Cloudflare가 액티브 챌린지까지 올렸다면 requests, httpx, 심지어 curl_cffi 같은 일반 HTTP 클라이언트로는 뚫기 어려워요. 진짜 브라우저 환경을 돌릴 수 있는 도구가 필요해요.
Cloudflare 보호 티어: 왜 같은 스크립트가 어떤 사이트에서는 되고, 어떤 곳에서는 막힐까?
대부분의 우회 가이드가 여기서 핵심을 놓쳐요. Cloudflare 보호는 다 똑같지 않아요. 무료 플랜에 보안 낮은 사이트와, Enterprise에서 Bot Management와 Turnstile를 켠 사이트는 난이도가 천지차이예요. 한쪽에서 술술 통하던 스크립트가 다른 쪽에선 바로 막혀요.
| Cloudflare 티어 | 대표적인 방어 수단 | 우회 난이도 | 보통 잘 통하는 방법 |
|---|---|---|---|
| 무료 플랜(보안 낮음) | Bot Fight Mode, 기본 WAF 규칙, IP 평판 | ⭐ 낮음 | 내부 API 탐색, 적절한 헤더를 넣은 curl_cffi, 실제 브라우저 세션 |
| Pro 플랜(중간) | Super Bot Fight Mode, Managed Challenge, JavaScript 탐지 | ⭐⭐ 중간 | 실제 브라우저 세션, 스텔스 브라우저 자동화, 주거용 프록시 |
| Business | 더 강한 WAF, Bot Analytics, 주요 경로에 대한 더 엄격한 챌린지 | ⭐⭐⭐ 중간~높음 | 브라우저 세션 추출, 세션 유지, 주거용/모바일 프록시, 유료 스크래핑 API |
| Enterprise / Bot Management | Bot score, JA3/JA4 필드, 엔드포인트별 규칙, Turnstile, AI Labyrinth | ⭐⭐⭐⭐ 높음 | 내부 API(접근 가능할 때), 실제 사용자 세션 도구, 엔터프라이즈급 스크래핑 API |
Cloudflare 요금 페이지를 보면 Free는 $0(무료), Pro는 월 $20(약 2만 8천 원), Business는 월 $200(약 28만 원), Enterprise는 맞춤 요금이에요. Bot Fight Mode는 Free 플랜의 단순 토글이고, Super Bot Fight Mode는 Pro/Business에서 더 세밀한 제어를 줘요. Enterprise의 Bot Management는 봇 점수를 더 잘게 쪼개고 엔드포인트별 규칙도 추가하죠.
대략 티어를 가늠하는 방법. Cloudflare 로고가 박힌 차단 페이지는 뜨는데 챌린지 스크립트가 없으면, 보통 WAF나 핑거프린트 거부예요. cf-turnstile div나 challenges.cloudflare.com/turnstile/v0/api.js 스크립트가 보이면 Turnstile이고요. "Checking your browser" 중간 페이지는 Managed Challenge예요. 메인은 잘 열리는데 특정 경로에서만 실패하면, 경로별 WAF나 Bot Management 규칙일 가능성이 커요.
방법을 고르기 전에 보호 수준부터 파악하세요. 디버깅 시간이 확 줄어요.
Cloudflare 우회, 무엇부터 시도해야 할까? 의사결정 트리
닥치는 대로 찔러보지 말고, 우선순위대로 가세요. 가장 쉽고 신뢰도 높은 방법부터 시작해서, 막힐 때만 다음 단계로 올라가면 돼요.
| 단계 | 먼저 시도할 것 | 이유 | 실패하면 → |
|---|---|---|---|
| 1 | 내부/비공개 API가 있는지 확인 | Cloudflare를 완전히 건너뜀; 가장 빠르고 신뢰도 높음 | 2단계 |
| 2 | 브라우저 렌더링이 내장된 노코드 도구 사용(예: Thunderbit) | 설정이 거의 필요 없고 JS 챌린지를 자동 처리 | 3단계 |
| 3 | TLS 지문 모방(curl_cffi) | 빠르고 가벼우며 브라우저가 필요 없음 | 4단계 |
| 4 | 스텔스 브라우저 자동화(SeleniumBase UC / Puppeteer stealth) | JS 챌린지와 지문 탐지를 처리 | 5단계 |
| 5 | FlareSolverr + Docker | 오픈소스이며 서버 환경에 적합 | 6단계 |
| 6 | 유료 스크래핑 API(ScrapingBee, ZenRows, Scrapfly 등) | 이 경쟁 자체를 외부에 맡김 | — |
논리는 간단해요. 공짜에 부담 없는 방법부터, 코드 무겁고 돈 드는 방법은 맨 끝으로. 내 상황에 맞는 단계로 바로 들어가면 돼요.
2026년 3월 커뮤니티 벤치마크에 따르면 curl_cffi가 테스트 도메인 20개 중 16개(80%)를 통과했고, FlareSolverr는 대략 55~70%, 유료 프록시 집계 서비스는 평균 약 97% 성공률을 기록했다고 해요. 다만 같은 스레드에서도 Cloudflare 업데이트마다 수치가 계속 바뀐다고 못 박았어요. 성공률은 어디까지나 참고로만 보세요.
1단계: 싸우지 말고, Cloudflare 뒤의 내부 API를 찾아라
제가 본 포럼 스레드 네 개가 하나같이 Cloudflare와 정면승부하지 말고 사이트 내부 API를 찾으라고 해요. 솔직히 이게 가장 영리한 첫수예요. 내부 API가 있으면 Cloudflare를 통째로 건너뛸 수 있어요. 꼼수도, 지문 스푸핑도, 스텔스 플러그인도 필요 없죠.
이렇게 체계적으로 접근하세요.
- Chrome DevTools 열기 → Network 탭 → XHR/Fetch로 필터링.
- 페이지를 만져보기: 검색, 필터, 페이지 넘김, 스크롤을 해보세요. Network 탭에 JSON 응답이 뜨는지 확인합니다.
- 요청 URL과 헤더를 확인합니다. 종종 API 엔드포인트는 프런트엔드 페이지보다 Cloudflare 보호가 약하거나 아예 없어요.
- 요청 우클릭 → Copy → Copy as cURL. 터미널이나 Postman에 붙여넣어 테스트합니다.
- 같은 헤더, 쿠키, 쿼리 파라미터로 Python에 재현합니다(
requests또는curl_cffi사용).
API가 구조화된 JSON을 돌려준다면 전통적인 스크래퍼 자체가 필요 없을 수도 있어요. 2026년 1월 Reddit 스레드에도 비슷한 사례가 있었어요. Cloudflare에 막힌 사용자가 curl_cffi로도 안 되자, 결국 API 응답을 직접 가로채는 방법만 통했다고 했죠.
실전 팁: cURL 복사가 성공하면 불필요한 헤더를 하나씩 빼보세요. sec-ch-ua, 쿠키, CSRF 토큰, referer는 필요할 수 있지만 브라우저 캐시 제어 헤더는 보통 없어도 돼요. 브라우저 cURL을 코드로 옮길 땐 User-Agent와 TLS 지문을 서로 맞춰두세요.
한계: 모든 사이트에 접근 가능한 API가 있는 건 아니에요. 어떤 API는 인증, CSRF 토큰, 서명된 요청 파라미터, 세션에 묶인 쿠키를 요구하죠. 그래도 통할 때는 유지보수 거의 없이 약 99% 성공률에 가까워요.
2단계: 노코드 경로 — 브라우저 확장 프로그램으로 Cloudflare 우회하기(Thunderbit)
대부분의 경쟁 가이드는 독자가 Python이나 JavaScript를 쓴다고 가정해요. 하지만 이 키워드를 검색하는 사람 중엔 영업팀이 리드 리스트를 만들고, 이커머스 운영팀이 경쟁사 가격을 보고, 부동산 분석가가 매물 데이터를 가져오는 경우가 많아요. 이런 분들은 Docker 컨테이너 같은 건 띄우고 싶지 않죠.
브라우저 확장 프로그램으로 Cloudflare 우회하기 Get Started Free
Thunderbit 같은 Chrome 확장 프로그램은 실제 브라우저 세션 안에서 돌아가니까 Cloudflare 검사를 자연스럽게 넘어가는 경우가 많아요. Chrome의 진짜 TLS 지문, 내 쿠키, 로그인 상태, 행동 신호를 그대로 쓰거든요. Cloudflare가 신뢰하는 바로 그 환경이죠. 스텔스 플러그인도, xvfb-run도, 터미널 명령도 필요 없어요.
단계별 사용법
- Chrome 웹 스토어에서 **Thunderbit Chrome Extension**을 설치합니다.
- Cloudflare로 보호된 페이지를 Chrome에서 엽니다. 챌린지가 뜨면 일반 사용자처럼 통과하세요. Turnstile 체크박스를 누르거나, "Checking your browser" 페이지가 사라질 때까지 기다리면 됩니다. 지금 여러분은 진짜 사람이고 진짜 브라우저를 쓰니까 Cloudflare가 통과시켜요.
- Thunderbit 사이드바에서 **"AI Suggest Fields"**를 클릭합니다. AI가 페이지를 읽고 "Product Name", "Price", "Rating" 같은 데이터 열을 제안해요.
- 제안 필드를 검토합니다. 필요 없는 건 빼고, 원하는 내용은 평범한 말로 설명해 직접 필드를 추가합니다.
- **"Scrape"**를 클릭합니다. 보이는 페이지에서 데이터를 추출해요.
- Google Sheets, Excel, Airtable, Notion, CSV, JSON으로 내보내기합니다.
페이지네이션이 있는 사이트에서도 클릭 기반 페이지 넘김과 무한 스크롤을 다 처리해요. 상세 페이지용이라면(상품 링크 목록에서 각 상품 스펙을 가져오고 싶은 경우) 서브페이지 스크래핑을 쓰세요. 연결된 상세 페이지를 하나씩 방문해 표를 풍성하게 채워줘요.
제 경험으로는, 설치부터 내보내기까지 50100행짜리 데이터셋 기준 510분이면 끝나요.
브라우저 기반 스크래핑이 특히 잘 맞는 경우와 그렇지 않은 경우
하나는 솔직히 짚고 가야 해요. 브라우저 기반 스크래핑은 세션 속도에 묶여요. 수백~수천 페이지 정도의 중간 규모에 잘 맞아요. 수백만 페이지를 정기적으로 크롤링해야 한다면 코드 방식이나 API 방식이 낫죠.
Thunderbit의 Cloud Scraping은 공개 접근 가능한 사이트에서 한 번에 최대 50페이지까지 긁어 속도를 올려줘요. 개발자 워크플로나 더 큰 규모라면 Thunderbit의 Web Scraper API가 JavaScript 렌더링, 봇 차단, 프록시 로테이션을 처리하고 요청당 최대 50~100개 URL을 배치로 돌려요.
하지만 리드, 가격 데이터, 부동산 목록을 적당한 규모로 긁는 비즈니스 사용자라면? 이 방법 하나로 충분한 경우가 많아요. 코드도, 프록시도, 유지보수도 없이요.
3단계: curl_cffi로 TLS 지문 스푸핑하기(가벼운 코드 방식)
Python에 익숙하고 노코드가 워크플로에 안 맞는다면, curl_cffi가 가장 가벼운 코드 옵션이에요. 실제 브라우저의 TLS 지문을 흉내 내는 libcurl 기반 Python 바인딩이죠. requests나 httpx와 달리, TLS 핸드셰이크를 Chrome이나 Safari에서 온 것처럼 꾸밀 수 있어요.
2026년 기준 지원 임퍼서네이션 대상에는 chrome136, safari184 같은 프로필이 있고, 과거 버전도 많이 받쳐줘요. PyPI 릴리스도 2026년 4월까지 계속 나와서 유지보수가 활발한 편이에요.
언제 쓰면 좋나: Free나 Pro 수준의 Cloudflare 보호를 쓰는 사이트 중, 주로 패시브 핑거프린팅에 기대는 경우. 즉 액티브 JavaScript 챌린지나 Turnstile가 없을 때예요.
기본 예시:
from curl_cffi import requests
url = "https://example.com/products"
resp = requests.get(
url,
impersonate="chrome136",
headers={
"accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"accept-language": "en-US,en;q=0.9",
},
timeout=30,
)
print(resp.status_code)
print(resp.text[:500])
헷갈리기 쉬운 점: User-Agent는 반드시 임퍼서네이션 대상과 맞춰야 해요. Chrome 136을 흉내 내면서 User-Agent는 Chrome 120으로 보내면, 그 불일치 자체가 신호가 돼요.
한계: curl_cffi는 JavaScript를 실행하지 않아요. 사이트가 "Checking your browser" 챌린지나 Turnstile 위젯을 띄우면 이 방법은 실패해요. 브라우저 챌린지에서 얻는 쿠키 기반 세션 상태가 필요한 사이트에도 안 통하죠. 패시브 전용 보호에 대한 빠르고 저렴한 1차 시도라고 보면 돼요.
같은 계열의 대안: tls-client, curl-impersonate도 비슷한 TLS 임퍼서네이션을 제공해요.
4단계: 스텔스 브라우저 자동화(Puppeteer Stealth, SeleniumBase UC)
사이트가 JavaScript 실행, 액티브 챌린지, Turnstile를 요구한다면 TLS 스푸핑만으론 부족해요. 이때는 완전한 브라우저가 필요하죠. 대표 선택지는 둘이에요.
- SeleniumBase UC Mode(Python): 문서에서 UC Mode를 자동화를 더 사람처럼 보이게 하고 봇 방지 서비스의 탐지를 피하는 방법으로 설명해요. Cloudflare Turnstile 처리 예시도 들어 있죠.
puppeteer-extra-plugin-stealth를 쓰는 Puppeteer(Node.js): 지금도 널리 쓰이지만, 2026년엔 점점 약해지고 있어요. 커뮤니티에선 CDP(Chrome DevTools Protocol) 탐지 플래그와 브라우저 프로필 불일치로 실패한다는 보고가 많아요.
두 도구 모두 실제 Chromium을 띄우되, navigator.webdriver, WebGL 메타데이터, 플러그인 목록 같은 탐지 가능한 자동화 신호를 손봐요.
실제로 중요한 설정 팁:
- 헤드리스가 아니라 헤드드 모드를 쓰세요. SeleniumBase 문서도 UC Mode는 헤드리스에서 탐지될 수 있다고 경고해요. Linux 서버에선 가상 디스플레이를 쓰세요.
- 뷰포트 크기와 User-Agent를 랜덤화하되, 서로 그리고 프록시의 지리 정보와도 일관되게 맞추세요.
- 페이지 동작 사이에 자연스러운 지연을 넣으세요. 페이지 이동 사이 200ms 간격은 "저 봇입니다" 광고나 다름없어요.
- 초기 챌린지를 넘긴 뒤엔 쿠키와 브라우저 프로필을 유지하세요. 매 요청마다 다시 풀지 마세요.
- 주거용 프록시와 같이 쓰면 IP 평판이 좋아져요.
이 방식의 골칫거리는 유지보수예요. Chrome이 업데이트되거나, Cloudflare가 새 신호를 더하거나, 스텔스 플러그인이 뒤처지거나, 대상 사이트가 경로별 Turnstile를 붙이면 자동화 스택이 깨질 수 있어요. ScrapeOps 벤치마크에서는 시간대/언어/프록시 지리 정보가 서로 안 맞는 "프랑켄 핑거프린트" 조합 탓에 많은 스텔스 구성이 핑거프린트 테스트를 통과 못 했다고 보고했어요.
강력하지만 운영 비용이 커요. 계속 손볼 시간이 든다는 걸 예산에 넣어두세요.
프록시 로테이션: 지문만큼 중요한 IP 문제
브라우저를 완벽하게 스텔스 처리해도, 한 IP에서 너무 많은 요청을 쏘면 속도 제한에 걸려요. Cloudflare는 데이터센터 IP보다 주거용·모바일 IP를 훨씬 더 믿어요.
- 주거용 프록시: 2026년 기준 진입 볼륨에서 GB당 약 $1.50~$8+(약 2천~1만 1천 원+) 수준이에요. 더 신뢰받지만 더 비싸죠.
- 데이터센터 프록시: 더 싸지만, 빡센 Cloudflare 대상에선 금방 실패해요.
- 로테이션 전략: 요청마다 바꾸지 말고 세션 단위로 바꾸세요. 요청마다 바꾸면 세션 쿠키와
cf_clearance가 깨져요. 세션 안에선 IP, 쿠키, 지문을 일관되게 유지해야 해요.
"최소 프록시 풀 크기" 같은 마법의 숫자는 없어요. 소량 리드 스크래핑은 고정형 주거용 세션 몇 개로 되기도 하고, 대량 가격 모니터링은 수백 개 출구와 재시도 로직이 필요할 수도 있죠.
5단계: FlareSolverr — 오픈소스 Cloudflare 우회 서버
FlareSolverr는 Docker 컨테이너 안에서 Chromium과 undetected-chromedriver로 Cloudflare 챌린지를 풀고, 재사용 가능한 쿠키/헤더를 돌려주는 오픈소스 프록시 서버예요. 2026년 5월 v3.5.0 릴리스도 나왔으니 아직 활발히 유지되고 있죠.
언제 쓰면 좋나: 매일 밤 돌아가는 자동 작업처럼, 챌린지 해결 서비스가 계속 필요한 서버 측 스크래핑 파이프라인. 예를 들어 새 cf_clearance 쿠키가 필요할 때예요.
동작 방식: 스크래퍼가 URL을 FlareSolverr API로 보내요. FlareSolverr가 브라우저에서 페이지를 열고, 챌린지를 풀려 시도한 뒤, HTML과 쿠키를 돌려줘요. 그 쿠키를 이후 일반 HTTP 클라이언트에서 다시 쓸 수 있죠.
설정 개요: Docker Compose로 컨테이너를 띄우고, 로컬 API 엔드포인트에 POST 요청을 보내요. ScrapeOps에 괜찮은 튜토리얼이 있어요.
미리 솔직히 말해둘 한계:
- 인터랙티브 Turnstile 챌린지나 Enterprise Bot Management를 안정적으로 풀지 못해요.
- GitHub 이슈와 Reddit 스레드에 챌린지 감지 실패, Turnstile 타임아웃, 페이지 크래시 등 들쭉날쭉한 동작이 보고돼요.
- Docker 인프라와 끊임없는 유지보수가 필요해요.
- 자원을 많이 먹어요. 챌린지를 풀 때마다 브라우저 컨텍스트를 새로 띄우거든요.
예상 신뢰도는 중간 수준 보호에서 60~80% 정도예요. Enterprise에선 더 낮고, 단순한 챌린지 페이지에선 더 높죠. FlareSolverr로도 안 되면 유료 API를 볼 때예요.
6단계: Cloudflare를 대신 처리해 주는 유료 스크래핑 API
때로는 아주 단순한 계산으로 답이 나와요. 자체 스텔스 인프라를 굴리는 비용이 구독료보다 더 들 수도 있으니까요. 유료 스크래핑 API는 이 경쟁 전체를 전문 업체에 넘겨요. URL만 보내면 지문 처리, 프록시, 챌린지 해결, 재시도를 다 대신해주죠.
비교할 때 보는 포인트:
| 서비스 | Cloudflare 지원 | JS 렌더링 | 주거용 프록시 | 구조화된 출력 | 요금 모델 |
|---|---|---|---|---|---|
| ScrapingBee | 예 | 예 | 예 | HTML만 | 요청당 크레딧 |
| ZenRows | 예(99% 이상 성공률 주장) | 예 | 예(프리미엄) | HTML, 일부 파싱 | 배수 적용 CPM |
| Scrapfly | 예(CF, Akamai, DataDome 포함) | 예 | 예 | HTML, 일부 파싱 | 크레딧 기반 |
| Browserless | 예 | 예(헤드리스 Chrome) | 예(내장) | HTML, 스크린샷 | 단위 기반 |
| Thunderbit API | 예 | 예 | 예 | AI 스키마 기반 구조화 JSON/CSV | 무료 티어 + 유료 플랜 |
이럴 때 특히 적합해요: 대량 스크래핑, 엔터프라이즈급 안정성이 필요할 때, 혹은 팀이 스크래핑 인프라를 직접 굴리기 싫을 때. 비용은 소중간 규모로 월 약 $30$500+(약 4만 2천~70만 원+)이고, 엔터프라이즈 볼륨으로 갈수록 더 올라가요.
Thunderbit API는 원시 HTML이 아니라 구조화된 데이터를 뱉는다는 점에서 따로 볼 만해요. Extract 엔드포인트는 요청당 최대 50개 URL을 배치 처리하고, AI 기반 스키마로 JSON/CSV를 돌려줄 수 있어요. HTML 파싱을 직접 하기 싫고 바로 분석 가능한 깔끔한 데이터를 원한다면 꽤 쓸 만하죠.
솔직한 신뢰도 표: 실제로 통하는 것과 깨지는 것
2025~2026년 내내 커뮤니티 보고, GitHub 이슈, 벤더 주장을 추적했어요. 아래는 그걸 바탕으로 정리한 솔직한 비교예요. 실험실 벤치마크가 아니라 방향성 추정치로 봐주세요.
| 방법 | 추정 성공률 | 유지보수 부담 | 언제 깨지나… | 비용 범위 |
|---|---|---|---|---|
| 내부 API(있을 경우) | 약 90~99% | 낮음 | API가 바뀌거나 인증이 추가되거나 토큰에 서명이 붙을 때 | 무료 |
| 브라우저 확장 프로그램(Thunderbit) | 약 85~95%(실제 세션 기준) | 낮음(AI가 레이아웃 변경에 적응) | 특수 인증 흐름이 필요하거나, 액션마다 강한 Turnstile가 붙을 때 | 무료 티어 있음 |
curl_cffi / TLS 스푸핑 | 약 70~85% | 중간(지문 업데이트 필요) | Cloudflare가 JA3 검사 방식을 바꾸거나, 활성 JS 챌린지가 필요할 때 | 무료 |
| Puppeteer + stealth 플러그인 | 약 70~90% | 높음(플러그인 업데이트가 늦음) | CDP 탐지, 새로운 지문 신호, 헤드리스 탐지 | 무료 + 프록시 비용 |
| FlareSolverr | 약 60~80% | 높음(Docker, 의존성 드리프트) | Enterprise급 보호, Turnstile 상호작용 | 무료 + 인프라 비용 |
| 유료 스크래핑 API | 약 85~95% | 낮음(제공사가 유지) | 제공사가 업데이트를 못 했거나 예산을 초과할 때 | 월 약 $30~500+ |
가장 중요한 열은 성공률이 아니라 "언제 깨지는가"예요. 모든 방법엔 실패 지점이 있어요. 제일 좋은 전략은 대상에 통하는, 가장 품이 적게 드는 방법을 고르고, 대체 계획을 같이 챙기는 거예요.
영구적인 해결책은 없어요. Cloudflare는 계속 업데이트돼요. 이 줄다리기는 사실상 끝나지 않아요.
Cloudflare의 눈을 피하는 습관(어떤 방법을 쓰든 중요)
어떤 방법을 고르든, 다음 습관을 지키면 Cloudflare의 탐지망에 덜 걸려요.
- 속도 제한을 존중하세요. 사람처럼 보이도록 요청 사이에 현실적인 지연을 넣으세요. 최소 2~5초는 두는 게 좋아요. 기계 속도로 사이트를 두드리는 건 가장 빨리 차단되는 길이에요.
- 지문 일관성을 유지하세요. User-Agent, TLS 지문, 브라우저 버전, 시간대, 로케일, IP 지리 정보가 다 같은 이야기를 해야 해요. 독일 IP에서
en-US로케일에 Python TLS 핸드셰이크를 쓰면서 Chrome 136이라고 우기면 서로 안 맞아요. - 챌린지를 넘긴 뒤엔 쿠키와 세션을 재사용하세요. 매 요청마다 다시 풀지 마세요.
- 세션 도중 IP를 바꾸지 마세요. Cloudflare는 세션 연속성을 추적해요.
- 예산과 용도가 허락하면 주거용 또는 모바일 IP를 쓰세요.
- 소프트 블록을 모니터링하세요: JSON 대신 챌린지 HTML이 오거나, 테이블이 비거나, 로그인 리다이렉트가 생기거나, AI Labyrinth 허니팟처럼 수상한 페이지가 뜨는 경우예요.
- 트래픽이 몰리는 시간대는 피하세요. 사이트 운영자가 WAF 규칙을 더 빡빡하게 걸 수 있어요.
- 대체 경로를 설계하세요: API 우선 → 브라우저 세션 → 유료 제공사 순서로.
Thunderbit 사용자라면 특히 AI가 페이지 레이아웃 변경에 자동으로 적응하니까, CSS 셀렉터를 계속 고치는 데 쓰던 시간을 줄이고 실제 데이터 활용에 더 쓸 수 있어요.
법적·윤리적 고려 사항에 대한 짧은 메모
이 글의 핵심은 아니지만, 그냥 넘기기엔 너무 중요해요.
공개적으로 이용 가능한 데이터를 스크래핑하는 행위는 일부 상황에서 미국 판례상 유리한 해석을 받기도 했어요. hiQ 대 LinkedIn 사건의 CFAA 논리는 대법원 환송 후에도 살아남았지만, 당사자들은 2022년에 합의했고 전체 맥락은 꽤 복잡해요. 최근에는 Reddit이 Anthropic을 상대로 2025년에 사용자 댓글 스크래핑 의혹으로 소송을 냈고, 그해 말에는 Reddit이 Perplexity와 데이터 스크래핑 업체들까지 상대로 소송했어요.
EU에서는 개인정보가 포함되면 개인정보보호법(한국의 PIPA에 해당하는 EU GDPR)이 적용되고, EU AI Act는 AI 학습을 위한 무차별 스크래핑에 관한 구체적 의무도 더해요.
실무에서 기억할 규칙은 이래요.
- 사이트의 이용약관을 항상 확인하세요.
- Cloudflare 보호는 사이트 운영자가 자동화된 접근을 통제하고 싶다는 신호예요. 그 의도를 존중하세요.
- 정당한 근거 없이 개인정보를 수집하지 마세요.
- 상업적이거나 대량 워크플로라면, 가능할 때 공식 API, 라이선스 데이터, 서면 허가를 우선하세요.
- 확실하지 않다면, 자신의 용도와 관할권에 맞는 법률 자문을 받으세요.
Thunderbit는 공개 접근 가능한 데이터를 쓰는 합법적인 비즈니스 용도, 예를 들어 리드 생성, 가격 모니터링, 시장 조사에 맞춰 설계됐어요.
마무리: 무엇부터 시도하고, 그다음엔 뭘 할까?
이 글에서 가장 큰 시간 절약 포인트는 도구나 코드 조각이 아니라, 시작하기 전에 보호 티어를 먼저 파악하는 거예요. 그것만으로도 애초에 통하지 않을 방법을 붙잡고 몇 시간씩 디버깅하는 일을 막을 수 있어요.
여기서 시작하세요:
- 내부 API가 있는지 확인하세요(무료에 빠르고, 자주 놓쳐요).
- 코드를 안 쓰는 비즈니스 사용자라면 Thunderbit Chrome Extension을 써보세요. 실제 브라우저 세션이 Cloudflare를 상대로 가장 큰 자산이에요.
- 개발자이고 대상 사이트가 패시브 핑거프린팅만 쓴다면
curl_cffi를 시도하세요. - 스텔스 브라우저, FlareSolverr, 유료 API는 더 단순한 방법이 실패했을 때만 올리면 돼요.
어떤 방법도 영구적이지 않아요. 규모에 맞는 도구와 대체 계획을 같이 쓰면, 403 페이지만 멍하니 보는 시간은 훨씬 줄어들어요.
더 깊이 알고 싶다면 Thunderbit 블로그에서 코딩 없이 웹 스크래핑하는 방법, AI 웹 스크래핑, 최고의 AI 웹 스크래퍼 관련 글도 확인해 보세요. 확장 프로그램이 실제로 어떻게 도는지 보고 싶다면 Thunderbit YouTube 채널의 튜토리얼 영상을 보시면 돼요.
Cloudflare로 보호된 사이트에서 Thunderbit 체험하기
Thunderbit AI Web Scraper 체험하기 Get Started Free
자주 묻는 질문(FAQ)
1. Cloudflare 보호를 완전히 우회할 수 있나요?
아니요. 특히 Turnstile, JA4 핑거프린팅, AI Labyrinth가 있는 Enterprise급 Bot Management에서는 어떤 방법도 100% 성공을 보장하지 않아요. 가장 신뢰도 높은 접근은 실제 브라우저 지문과 좋은 IP 평판을 함께 쓰는 거예요. 내부 API를 찾는 것이 사실상 가장 "완전한" 우회에 가까워요. Cloudflare를 아예 거치지 않으니까요. 다만 모든 사이트에 그런 API가 있는 건 아니에요.
2. 스크래핑할 때 Cloudflare를 우회하는 것이 합법인가요?
관할 지역, 사이트의 이용약관, 수집하는 데이터에 따라 달라요. 공개 데이터 스크래핑은 일부 상황에서 미국 판례상 유리한 해석(hiQ 대 LinkedIn)을 받기도 했지만, 기술적 접근 통제를 우회하거나 ToS를 위반하거나 정당한 근거 없이 개인정보를 수집하면 법적 리스크가 생길 수 있어요. 상업적 워크플로라면 가능할 때 공식 API나 라이선스 데이터부터 검토하고, 확실치 않으면 법률 자문을 받으세요.
3. 코딩 없이 Cloudflare를 우회하는 가장 쉬운 방법은 무엇인가요?
Thunderbit처럼 실제 Chrome 세션 안에서 도는 브라우저 확장 프로그램이 Cloudflare 챌린지를 자동으로 처리해줘요. 사용자는 일반 사용자처럼 사이트와 상호작용한 뒤, 확장 프로그램이 데이터 추출과 내보내기를 맡아요. Python도, Docker도, 프록시 설정도 필요 없어요.
4. 왜 어떤 Cloudflare 사이트에서는 제 스크래퍼가 되고, 다른 곳에서는 안 되나요?
Cloudflare의 보호 수준은 플랜(Free, Pro, Business, Enterprise)과 설정에 따라 크게 달라요. Free 플랜 사이트의 기본 JavaScript 챌린지를 통과하는 방법이, Enterprise 사이트의 Turnstile나 완전한 Bot Management에서는 실패할 수 있어요. 우회 방식을 고르기 전에 항상 보호 티어부터 확인하세요. 단순한 JS 체크인지, Managed Challenge인지, Turnstile 위젯인지 먼저 봐야 해요.
5. Cloudflare 우회 방법은 얼마나 자주 깨지나요?
스텔스 플러그인이나 TLS 스푸핑 같은 코드 기반 방법은 Cloudflare가 탐지 방식을 바꾸면 몇 주에서 몇 달 단위로 성능이 떨어질 수 있어요. 유료 API와 실제 브라우저 세션 도구는 인프라나 사용자 세션 레벨에서 적응하니까 더 견고한 편이에요. 내부 API는 사이트가 백엔드를 다시 짜거나 인증 모델을 바꾸지 않는 한 잘 안 깨져요. 장기적으로 가장 안전한 전략은 한 방법만 믿지 않고 여러 대체 수단을 준비하는 거예요.
더 읽어보기
