스크래핑 시 Cloudflare 우회하는 방법 (2026년에도 여전히 통하는 것들)

지난주에는 멀쩡히 잘 돌던 Python 스크립트 하나를 디버깅하느라 40분을 잡아먹었습니다. 테스트용 사이트 3곳에서는 아무 문제 없었는데, 4번째 사이트가 Cloudflare 뒤에 숨어 있다는 걸 뒤늦게 알아챘죠. 스크래퍼는 계속 "Checking your browser…" 페이지만 맴돌았고, 결국 챌린지 HTML만 받아오는 상황이었습니다. 너무 익숙한 장면 아닌가요?

비슷한 경험이 있다면 혼자가 아닙니다. 지금 가 Cloudflare를 쓰고 있고, 이는 에 해당합니다. 다시 말해 리드 생성, 가격 모니터링, 부동산 리서치, 경쟁사 분석 등 어떤 목적이든 웹 데이터를 모으려는 사람에게 Cloudflare는 가장 흔한 걸림돌이라는 뜻입니다.

문제는 대부분의 가이드가 우회 방법을 한꺼번에 쭉 나열만 하고, 내 상황에서는 무엇부터 해봐야 하는지를 잘 안 알려준다는 점입니다. 이 글은 조금 다르게 접근합니다. 우선순위가 있는 의사결정 트리, 솔직한 신뢰도 추정치, 그리고 많은 글에서 아예 빼놓는 노코드 경로까지 함께 소개합니다.

• 난이도: 초급~중급(선택한 방법에 따라 다름)
• 소요 시간: 노코드 방식은 약 10~30분, 코드 방식은 상황에 따라 다름
• 준비물: Chrome 브라우저(노코드 방식용), 선택적으로 Python 3.9+(코드 방식용), 그리고 대상 URL

Cloudflare 보호란 무엇이며, 왜 내 스크래퍼를 막을까?

Cloudflare는 방문자와 웹사이트 원본 서버 사이에 들어가는 리버스 프록시입니다. 모든 요청은 먼저 Cloudflare 엣지를 거치고, Cloudflare가 페이지를 보여줄지, 방문자에게 챌린지를 줄지, 아니면 그냥 차단할지를 결정합니다. 여기서 중요한 건, Cloudflare가 내 스크래퍼가 악성인지 정확히 알 필요는 없다는 겁니다. 요청이 충분히 자동화됐거나 수상해 보이기만 해도 막을 수 있습니다.

Cloudflare의 시스템은 하나의 단일 장치가 아니라 여러 보안 검문소를 겹겹이 쌓아둔 구조입니다. 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 헤더 분석: Cloudflare는 User-Agent, Accept-Language, 헤더 순서, HTTP 버전을 비교합니다. 예를 들어 Chrome 136이라고 주장하면서 TLS 핸드셰이크는 "Python" 냄새가 나면 바로 티가 납니다.
• TLS 핑거프린팅(JA3/JA4): TLS 핸드셰이크 과정에서 클라이언트는 지원하는 암호화 스위트, 확장, 프로토콜 선호 패턴을 드러냅니다. 는 이를 하나의 식별자로 압축합니다. 실제 Chrome과 Python requests 스크립트는 완전히 다른 "모양"을 남깁니다.
• HTTP/2 핑거프린팅: 브라우저와 HTTP 라이브러리는 HTTP/2 SETTINGS 프레임, pseudo-header 순서, 우선순위 처리 방식이 서로 다릅니다. Cloudflare의 작업은 단일 요청의 정체성만 보는 게 아니라 요청 간 패턴까지 시간 흐름에 따라 추적합니다.
• AI Labyrinth: Cloudflare의 최신 함정입니다. 수상한 크롤러를 그냥 막는 대신, 해 크롤러 자원을 낭비하게 만듭니다. 스크래퍼는 자신이 잡혔는지도 모를 수 있습니다.

액티브 탐지: 브라우저 안에서 실행되는 챌린지

패시브 검사만으로는 확실하지 않으면 Cloudflare는 액티브 챌린지로 넘어갑니다.

• JavaScript 챌린지: 흔히 보는 "Checking your browser…" 중간 페이지입니다. Cloudflare의 는 보이지 않는 스크립트를 실행해 자동화 요청을 가려냅니다.
• Turnstile: Cloudflare의 CAPTCHA 대체 기능입니다. 에는 Managed, Non-Interactive, Invisible이 있습니다. 보이는 퍼즐이 없어도 마우스 움직임, 브라우저 환경, TLS 지문 등을 분석합니다.
• Canvas 및 WebGL 핑거프린팅: 헤드리스 브라우저가 실제 브라우저와 다르게 렌더링되는지 확인합니다.
• 행동 신호: 요청 타이밍, 스크롤 패턴, 클릭 순서까지 봅니다. 3초 만에 50페이지를 가져오는데 마우스 움직임이 전혀 없다면 사람처럼 보일 리가 없죠.

실무적으로 보면, Cloudflare가 액티브 챌린지까지 올렸다면 requests, httpx, 심지어 curl_cffi 같은 일반 HTTP 클라이언트로는 통과하기 어렵습니다. 실제 브라우저 환경을 실행할 수 있는 도구가 필요합니다.

Cloudflare 보호 티어: 왜 같은 스크립트가 어떤 사이트에서는 되고, 어떤 곳에서는 막힐까?

대부분의 우회 가이드는 여기서 핵심을 놓칩니다. Cloudflare 보호는 균일하지 않습니다. 무료 플랜에 보안 수준이 낮은 사이트와, Enterprise에서 Bot Management와 Turnstile가 켜진 사이트는 완전히 다른 난이도입니다. 한 곳은 쉽게 통과하던 스크립트도 다른 곳에서는 바로 막힙니다.

에는 Free는 $0, Pro는 월 $20, Business는 월 $200, Enterprise는 맞춤 요금으로 안내되어 있습니다. 는 Free 플랜의 간단한 토글이고, 는 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 우회, 무엇부터 시도해야 할까? 의사결정 트리

아무 방법이나 닥치는 대로 시도하지 말고, 우선순위대로 접근하세요. 가장 쉽고 신뢰도 높은 방법부터 시작해서, 필요할 때만 다음 단계로 올라가면 됩니다.

논리는 단순합니다. 무료이고 부담 적은 방법부터, 코드가 무겁고 비용이 드는 방법은 마지막에. 내 상황에 맞는 단계로 바로 들어가면 됩니다.

에서는 curl_cffi가 테스트 도메인 20개 중 16개(80%)를 통과했고, FlareSolverr는 대략 55~70%를 커버했으며, 유료 프록시 집계 서비스는 평균 약 97% 성공률을 기록했다고 주장했습니다. 다만 같은 스레드에서도 Cloudflare 업데이트에 따라 수치는 계속 바뀐다고 경고합니다. 성공률은 어디까지나 참고용으로 보세요.

1단계: 싸우지 말고, Cloudflare 뒤의 내부 API를 찾아라

제가 본 포럼 스레드 4개는 모두 Cloudflare와 정면승부하기보다 사이트의 내부 API를 찾으라고 권합니다. 솔직히 말해 이것이 가장 똑똑한 첫 번째 선택입니다. 사이트에 내부 API가 있으면 Cloudflare를 아예 건너뛸 수 있습니다. 꼼수도, 지문 스푸핑도, 스텔스 플러그인도 필요 없습니다.

아래처럼 체계적으로 접근하세요.

1. Chrome DevTools 열기 → Network 탭으로 이동 → XHR/Fetch로 필터링.
2. 페이지와 상호작용하기: 검색, 필터, 페이지 넘김, 스크롤을 해보세요. Network 탭에 JSON 응답이 나타나는지 확인합니다.
3. 요청 URL과 헤더를 확인합니다. 종종 API 엔드포인트는 프런트엔드 페이지보다 Cloudflare 보호가 약하거나 아예 없기도 합니다.
4. 요청을 우클릭 → Copy → Copy as cURL. 터미널이나 Postman에 붙여 넣어 테스트합니다.
5. 같은 헤더, 쿠키, 쿼리 파라미터로 Python에 재현합니다(requests 또는 curl_cffi 사용).

API가 구조화된 JSON을 반환한다면, 전통적인 스크래퍼가 필요 없을 수도 있습니다. 에서도 비슷한 사례가 있었는데, Cloudflare에 막힌 사용자가 curl_cffi로도 해결하지 못하자 결국 API 응답을 직접 가로채는 방법만이 통했다고 설명했습니다.

실전 팁: cURL 복사가 성공한 뒤에는 불필요한 헤더를 하나씩 빼보세요. sec-ch-ua, 쿠키, CSRF 토큰, referer는 필요할 수 있지만, 브라우저 캐시 제어 헤더는 보통 없어도 됩니다. 브라우저 cURL에서 코드로 옮길 때는 User-Agent와 TLS 지문을 서로 맞춰 두세요.

한계: 모든 사이트에 접근 가능한 API가 있는 건 아닙니다. 어떤 API는 인증, CSRF 토큰, 서명된 요청 파라미터, 세션에 묶인 쿠키를 요구합니다. 그래도 통할 때는 유지보수 거의 없이 약 99% 성공률에 가까운 방법이 됩니다.

2단계: 노코드 경로 — 브라우저 확장 프로그램으로 Cloudflare 우회하기(Thunderbit)

대부분의 경쟁 가이드는 독자가 Python이나 JavaScript를 쓴다고 가정합니다. 하지만 이 키워드를 찾는 사람 중에는 영업팀이 리드 리스트를 만들고, 이커머스 운영팀이 경쟁사 가격을 모니터링하고, 부동산 분석가가 매물 데이터를 가져오는 경우도 많습니다. 이런 분들은 Docker 컨테이너를 띄우고 싶지 않죠.

같은 Chrome 확장 프로그램은 실제 브라우저 세션 안에서 동작하므로 Cloudflare 검사를 자연스럽게 통과하는 경우가 많습니다. Chrome의 진짜 TLS 지문, 내 쿠키, 로그인 상태, 행동 신호를 그대로 쓰기 때문입니다. Cloudflare가 신뢰하는 바로 그 환경이죠. 스텔스 플러그인도, xvfb-run도, 터미널 명령도 필요 없습니다.

단계별 사용법

1. Chrome 웹 스토어에서 ****을 설치합니다.
2. Cloudflare로 보호된 페이지를 Chrome에서 엽니다. Cloudflare가 챌린지를 띄우면 일반 사용자처럼 통과하세요. Turnstile 체크박스를 클릭하거나, "Checking your browser" 페이지가 사라질 때까지 기다리면 됩니다. 지금 당신은 실제 사람이고 실제 브라우저를 쓰고 있으니 Cloudflare는 통과시킵니다.
3. Thunderbit 사이드바에서 **"AI Suggest Fields"**를 클릭합니다. AI가 페이지를 읽고 "Product Name", "Price", "Rating"처럼 적절한 데이터 열을 제안합니다.
4. 제안된 필드를 검토합니다. 필요 없는 것은 빼고, 원하는 내용은 평범한 영어로 설명해 사용자 지정 필드를 추가합니다.
5. **"Scrape"**를 클릭합니다. Thunderbit가 보이는 페이지에서 데이터를 추출합니다.
6. Google Sheets, Excel, Airtable, Notion, CSV, JSON으로 내보내기합니다.

페이지네이션이 있는 사이트에서도 Thunderbit은 클릭 기반 페이지 넘김과 무한 스크롤을 모두 처리합니다. 상세 페이지용이라면(예: 상품 링크 목록이 있고 각 상품 상세 스펙을 가져오고 싶은 경우) 을 사용하세요. Thunderbit이 연결된 각 상세 페이지를 방문해 표를 풍성하게 만들어 줍니다.

제 경험상, 이 작업은 보통 설치부터 내보내기까지 50~100행짜리 데이터셋 기준으로 5~10분 정도 걸립니다.

브라우저 기반 스크래핑이 특히 잘 맞는 경우와 그렇지 않은 경우

한 가지는 솔직히 말해야 합니다. 브라우저 기반 스크래핑은 세션 속도에 묶입니다. 수백 페이지에서 수천 페이지 정도의 중간 규모 작업에 적합합니다. 수백만 페이지를 정기적으로 크롤링해야 한다면 코드 방식이나 API 방식이 더 맞습니다.

Thunderbit의 Cloud Scraping 옵션은 공개 접근 가능한 사이트에서 한 번에 최대 50페이지까지 스크래핑해 속도를 높여줄 수 있습니다. 개발자 워크플로나 더 큰 규모에서는 Thunderbit의 가 JavaScript 렌더링, 봇 차단, 프록시 로테이션을 처리하며 요청당 최대 을 배치 처리합니다.

하지만 리드, 가격 데이터, 부동산 목록을 적당한 규모로 스크래핑하는 비즈니스 사용자라면? 이 방법 하나면 충분한 경우가 많습니다. 코드도 없고, 프록시도 없고, 유지보수도 없습니다.

3단계: curl_cffi로 TLS 지문 스푸핑하기(가벼운 코드 방식)

Python에 익숙하고 노코드 방식이 워크플로우에 맞지 않는다면, 가 가장 가벼운 코드 옵션입니다. 실제 브라우저의 TLS 지문을 흉내 낼 수 있는 libcurl 기반 Python 바인딩입니다. requests나 httpx와 달리, TLS 핸드셰이크가 Chrome이나 Safari에서 온 것처럼 보이게 할 수 있습니다.

2026년 기준 에는 chrome136, safari184 같은 프로필이 포함되어 있고, 과거 버전도 많이 지원합니다. 계속 나왔기 때문에 유지보수가 활발한 편입니다.

언제 쓰면 좋나: Free 또는 Pro 수준의 Cloudflare 보호를 쓰는 사이트 중, 주로 패시브 핑거프린팅에 의존하는 경우. 즉, 활성 JavaScript 챌린지나 Turnstile가 없는 경우입니다.

기본 예시:

1from curl_cffi import requests
2url = "https://example.com/products"
3resp = requests.get(
4    url,
5    impersonate="chrome136",
6    headers={
7        "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
8        "accept-language": "en-US,en;q=0.9",
9    },
10    timeout=30,
11)
12print(resp.status_code)
13print(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): 자동화가 더 사람처럼 보이게 하고 봇 방지 서비스의 탐지를 피하는 방법으로 설명합니다. Cloudflare Turnstile 처리 예시도 포함되어 있습니다.
• puppeteer-extra-plugin-stealth를 사용하는 Puppeteer(Node.js): 지금도 널리 쓰이지만, . 커뮤니티에서는 CDP(Chrome DevTools Protocol) 탐지 플래그와 브라우저 프로필 불일치 때문에 실패한다는 보고가 많습니다.

두 도구 모두 실제 Chromium 브라우저를 띄우되, navigator.webdriver, WebGL 메타데이터, 플러그인 목록 등 탐지 가능한 자동화 신호를 수정합니다.

실제로 중요한 설정 팁:

• 헤드리스가 아니라 헤드드 모드를 사용하세요. SeleniumBase 문서도 UC Mode는 헤드리스에서 탐지될 수 있다고 경고합니다. Linux 서버에서는 가상 디스플레이를 쓰세요.
• 뷰포트 크기와 User-Agent를 랜덤화하되, 서로 그리고 프록시의 지리 정보와도 일관되게 맞추세요.
• 페이지 동작 사이에 자연스러운 지연을 넣으세요. 페이지 이동 사이 200ms 간격은 "봇입니다"라고 광고하는 것과 같습니다.
• 초기 챌린지를 통과한 뒤에는 쿠키와 브라우저 프로필을 유지하세요. 매 요청마다 다시 풀지 마세요.
• 주거용 프록시와 함께 쓰면 IP 평판이 더 좋아집니다.

이 방식의 문제는 유지보수입니다. Chrome이 업데이트되거나, Cloudflare가 새로운 신호를 추가하거나, 스텔스 플러그인이 뒤처지거나, 대상 사이트가 경로별 Turnstile를 붙이면 브라우저 자동화 스택이 깨질 수 있습니다. 에서는 많은 스텔스 브라우저 구성이 시간대/언어/프록시 지리 정보가 서로 맞지 않는 "프랑켄 핑거프린트" 조합 때문에 핑거프린트 테스트에 실패했다고 보고했습니다.

이 방법은 강력하지만 운영 비용이 큽니다. 계속 손볼 시간이 든다는 점을 예산에 넣어두세요.

프록시 로테이션: 지문만큼 중요한 IP 문제

브라우저를 완벽하게 스텔스 처리해도, 한 IP에서 너무 많은 요청을 보내면 속도 제한에 걸립니다. Cloudflare는 데이터센터 IP보다 주거용 및 모바일 IP를 훨씬 더 신뢰합니다.

• 주거용 프록시: 2026년 기준 진입 볼륨에서는 수준입니다. 더 신뢰받지만 더 비쌉니다.
• 데이터센터 프록시: 더 저렴하지만, 합니다.
• 로테이션 전략: 요청마다 바꾸지 말고 세션 단위로 바꾸세요. 요청마다 바꾸면 세션 쿠키와 cf_clearance가 깨집니다. 세션 안에서는 IP, 쿠키, 지문을 일관되게 유지해야 합니다.

"최소 프록시 풀 크기" 같은 마법 숫자는 없습니다. 적은 양의 리드 스크래핑은 몇 개의 고정형 주거용 세션만으로도 가능할 수 있고, 대량 가격 모니터링은 수백 개의 출구와 재시도 로직이 필요할 수 있습니다.

5단계: FlareSolverr — 오픈소스 Cloudflare 우회 서버

는 Docker 컨테이너 안에서 Chromium과 undetected-chromedriver를 사용해 Cloudflare 챌린지를 풀고, 재사용 가능한 쿠키/헤더를 돌려주는 오픈소스 프록시 서버입니다. 도 있었으니 아직 활발히 유지되고 있습니다.

언제 쓰면 좋나: 매일 밤 돌아가는 자동 작업처럼, 계속해서 챌린지 해결 서비스가 필요한 서버 측 스크래핑 파이프라인. 예를 들어 새 cf_clearance 쿠키가 필요한 경우입니다.

동작 방식: 스크래퍼가 URL을 FlareSolverr API로 보냅니다. FlareSolverr가 브라우저에서 페이지를 열고, 챌린지를 해결하려 시도한 뒤, HTML과 쿠키를 반환합니다. 이후 그 쿠키를 일반 HTTP 클라이언트에서 다시 사용할 수 있습니다.

설정 개요: Docker Compose로 컨테이너를 띄우고, 로컬 API 엔드포인트에 POST 요청을 보냅니다. 이 있습니다.

미리 솔직히 말해둘 한계:

• 인터랙티브 Turnstile 챌린지나 Enterprise Bot Management를 안정적으로 풀지 못합니다.
• 와 에서 챌린지 감지 실패, Turnstile 타임아웃, 페이지 크래시 등 들쭉날쭉한 동작이 보고됩니다.
• Docker 인프라와 계속되는 유지보수가 필요합니다.
• 자원을 많이 씁니다. 챌린지를 풀 때마다 브라우저 컨텍스트를 새로 띄우기 때문입니다.

예상 신뢰도는 중간 수준 보호 대상에서 60~80% 정도입니다. Enterprise에서는 더 낮고, 단순한 챌린지 페이지에서는 더 높습니다. FlareSolverr로도 안 되면 유료 API를 고려할 때입니다.

6단계: Cloudflare를 대신 처리해 주는 유료 스크래핑 API

때로는 아주 단순한 계산으로 답이 나옵니다. 자체 스텔스 인프라를 유지하는 비용이 구독료보다 더 많이 들 수도 있으니까요. 유료 스크래핑 API는 이 경쟁 전체를 전문 업체에 맡깁니다. URL만 보내면 지문 처리, 프록시, 챌린지 해결, 재시도를 전부 대신 해줍니다.

비교할 때 보는 포인트:

이럴 때 특히 적합합니다: 대량 스크래핑, 엔터프라이즈급 안정성이 필요한 경우, 혹은 팀이 스크래핑 인프라를 직접 유지하고 싶지 않을 때. 비용은 소규모~중간 규모 사용 시 대략 월 $30~$500+ 수준이고, 엔터프라이즈 볼륨으로 갈수록 더 올라갑니다.

Thunderbit API는 원시 HTML이 아니라 구조화된 데이터를 출력한다는 점에서 따로 볼 만합니다. 는 요청당 최대 50개 URL을 배치 처리하고, AI 기반 스키마를 통해 JSON/CSV를 반환할 수 있습니다. 직접 HTML 파싱을 하고 싶지 않고, 바로 분석 가능한 깔끔한 데이터를 원한다면 꽤 유용합니다.

솔직한 신뢰도 표: 실제로 통하는 것과 깨지는 것

2025~2026년 내내 커뮤니티 보고, GitHub 이슈, 벤더 주장들을 추적했습니다. 아래는 그걸 바탕으로 정리한 솔직한 비교입니다. 실험실 벤치마크가 아니라 방향성 추정치로 봐주세요.

가장 중요한 열은 성공률이 아니라 "언제 깨지는가"입니다. 모든 방법엔 실패 지점이 있습니다. 가장 좋은 전략은 대상에 통하는 가장 적은 노력의 방법을 고르고, 대체 계획도 같이 준비하는 겁니다.

영구적인 해결책은 없습니다. Cloudflare는 계속 업데이트됩니다. 이 경쟁은 사실상 끝나지 않습니다.

Cloudflare의 눈을 피하는 습관(어떤 방법을 쓰든 중요)

어떤 방법을 선택하든, 다음 습관을 지키면 Cloudflare의 탐지망에 덜 걸릴 수 있습니다.

• 속도 제한을 존중하세요. 사람처럼 보이도록 요청 사이에 현실적인 지연을 넣으세요. 최소 2~5초는 두는 게 좋습니다. 기계 속도로 사이트를 두드리는 건 차단되는 가장 빠른 방법입니다.
• 지문 일관성을 유지하세요. User-Agent, TLS 지문, 브라우저 버전, 시간대, 로케일, IP 지리 정보가 다 같은 이야기를 해야 합니다. 독일 IP에서 en-US 로케일과 Python TLS 핸드셰이크를 쓰면서 Chrome 136이라고 주장하면 서로 안 맞습니다.
• 챌린지를 통과한 뒤에는 쿠키와 세션을 재사용하세요. 매 요청마다 다시 풀지 마세요.
• 세션 도중 IP를 바꾸지 마세요. Cloudflare는 세션 연속성을 추적합니다.
• 예산과 사용 사례가 허용한다면 주거용 또는 모바일 IP를 사용하세요.
• 소프트 블록을 모니터링하세요: JSON 대신 챌린지 HTML이 나오거나, 테이블이 비어 있거나, 로그인 리다이렉트가 발생하거나, 허니팟처럼 수상한 페이지가 뜨는 경우입니다.
• 트래픽이 몰리는 시간대는 피하세요. 사이트 운영자가 WAF 규칙을 더 빡빡하게 걸 수 있습니다.
• 대체 경로를 설계하세요: API 우선 → 브라우저 세션 → 유료 제공사 순서로.

Thunderbit 사용자라면 특히 AI가 페이지 레이아웃 변경에 자동으로 적응하므로, CSS 셀렉터를 계속 고치는 데 쓰는 시간을 줄이고 실제 데이터 활용에 더 많은 시간을 쓸 수 있습니다.

법적·윤리적 고려 사항에 대한 짧은 메모

이 글의 핵심은 아니지만, 그냥 넘기기엔 너무 중요합니다.

공개적으로 이용 가능한 데이터를 스크래핑하는 행위는 을 받기도 했습니다. hiQ 대 LinkedIn 사건의 CFAA 관련 논리는 대법원 환송 후에도 살아남았지만, 당사자들은 2022년에 합의했고 전체 맥락은 꽤 복잡합니다. 최근에는 2025년에 사용자 댓글 스크래핑 의혹으로 소송을 제기했고, 그해 말에는 했습니다.

EU에서는 개인정보가 포함되면 GDPR이 적용되고, 는 AI 학습을 위한 과 관련된 구체적 의무도 추가합니다.

실무적으로 기억할 규칙은 다음과 같습니다.

• 사이트의 이용약관을 항상 확인하세요.
• Cloudflare 보호는 사이트 운영자가 자동화된 접근을 통제하고 싶다는 신호입니다. 그 의도를 존중하세요.
• 정당한 근거 없이 개인정보를 수집하지 마세요.
• 상업적이거나 대량의 워크플로우라면, 가능할 때 공식 API, 라이선스가 있는 데이터, 서면 허가를 우선하세요.
• 확실하지 않다면, 자신의 사용 사례와 관할권에 맞는 법률 자문을 받으세요.

Thunderbit는 공개 접근 가능한 데이터를 활용하는 합법적인 비즈니스 용도, 예를 들어 리드 생성, 가격 모니터링, 시장 조사에 맞춰 설계되었습니다.

마무리: 무엇부터 시도하고, 그다음엔 뭘 할까?

이 글에서 가장 큰 시간 절약 포인트는 도구나 코드 조각이 아니라, 시작하기 전에 보호 티어를 먼저 파악하는 겁니다. 그것만으로도 애초에 통하지 않을 방법을 붙잡고 몇 시간씩 디버깅하는 일을 막을 수 있습니다.

여기서 시작하세요:

1. 내부 API가 있는지 확인하세요(무료이고 빠르며 자주 놓칩니다).
2. 코드를 쓰지 않는 비즈니스 사용자라면 을 써보세요. 실제 브라우저 세션이 Cloudflare를 상대로 가장 큰 자산입니다.
3. 개발자이고 대상 사이트가 패시브 핑거프린팅만 쓴다면 curl_cffi를 시도하세요.
4. 스텔스 브라우저, FlareSolverr, 유료 API는 더 단순한 방법이 실패했을 때만 올리면 됩니다.

어떤 방법도 영구적이지 않습니다. 규모에 맞는 도구와 대체 계획을 함께 쓰면, 403 페이지만 멍하니 보는 시간은 훨씬 줄어듭니다.

더 깊이 알고 싶다면 Thunderbit 블로그에서 , , 관련 글도 확인해 보세요. 그리고 확장 프로그램이 실제로 어떻게 동작하는지 보고 싶다면 의 튜토리얼 영상을 보시면 됩니다.

자주 묻는 질문(FAQ)

1. Cloudflare 보호를 완전히 우회할 수 있나요?

아니요. 특히 Turnstile, JA4 핑거프린팅, AI Labyrinth가 있는 Enterprise급 Bot Management에서는 어떤 방법도 100% 성공을 보장하지 않습니다. 가장 신뢰도 높은 접근은 실제 브라우저 지문과 좋은 IP 평판을 함께 쓰는 것입니다. 내부 API를 찾는 것이 사실상 가장 "완전한" 우회에 가깝습니다. Cloudflare를 아예 거치지 않기 때문이죠. 다만 모든 사이트에 그런 API가 있는 건 아닙니다.

2. 스크래핑할 때 Cloudflare를 우회하는 것이 합법인가요?

관할 지역, 사이트의 이용약관, 수집하는 데이터에 따라 다릅니다. 공개 데이터를 스크래핑하는 행위는 일부 상황에서 미국 판례상 유리한 해석(hiQ 대 LinkedIn)을 받기도 했지만, 기술적 접근 통제를 우회하거나 ToS를 위반하거나 정당한 근거 없이 개인정보를 수집하면 법적 리스크가 생길 수 있습니다. 상업적 워크플로우라면 가능할 때 공식 API나 라이선스 데이터부터 검토하고, 확실치 않으면 법률 자문을 받으세요.

3. 코딩 없이 Cloudflare를 우회하는 가장 쉬운 방법은 무엇인가요?

처럼 실제 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는 사이트가 백엔드를 다시 설계하거나 인증 모델을 바꾸지 않는 한 잘 깨지지 않습니다. 장기적으로 가장 안전한 전략은 하나의 방법만 믿는 것이 아니라 여러 대체 수단을 준비하는 것입니다.

더 읽어보기