당직 중이던 엔지니어가 공급업체 웹사이트를 열었더니 reCAPTCHA가 나왔습니다. 이메일과 전화로 긴급 경보가 들어오는 중이었습니다. 챌린지는 계단과 신호등, 오토바이를 찾으라고 요구했습니다. "I'm getting email and phone alerts for an emergency, and you're making me spend five whole minutes clicking pictures???"라고 그는 r/sysadmin에 썼습니다.
그의 타이밍이 나빴습니다. 하지만 이런 경험은 흔합니다. 웹에서 가장 큰 챌린지 네트워크 중 하나를 운영하는 Cloudflare는 평균 CAPTCHA에 사람의 시간이 32초 걸린다고 보고, 사람들이 약 15%의 확률로 이 과제를 포기한다고 추정합니다. 그 비용을 누가 치르는지에 대해 W3C는 더 강한 표현을 씁니다. 상호작용형 과제 자체가 "inherently excludes many people with disabilities, resulting in a denial of service to these users"라는 것입니다 (W3C).
CAPTCHA 챌린지는 서버가 요청을 사람의 것으로 받아들이기 전에 브라우저가 통과해야 하는 관문입니다. 맞물려 돌아가는 요소는 세 가지입니다. 서버가 챌린지를 내보내고, 브라우저가 답하고, 서버가 판단합니다. 흥미로운 쪽은 판단입니다. 요즘 대부분의 사이트는 퍼즐을 채점하지 않습니다. 채점 대상은 세션입니다.
CAPTCHA가 짜증나는 이유는 대부분 이 간극에서 나옵니다. 답을 묻지 않은 시험은 공부할 방법이 없습니다. 아래에서는 이 약어의 뜻, 핸드셰이크가 실제로 돌아가는 방식, 챌린지가 다시 나타나는 이유, 다음에 막혔을 때 할 일을 다룹니다. 마지막 부분에서는 Tabbit Browser를 예로 씁니다. AI 브라우저가 무엇인지는 여기서 생각보다 중요한 문제이기 때문입니다.
핵심 요약
CAPTCHA는 "Completely Automated Public Turing test to tell Computers and Humans Apart"의 약자입니다. 이름 그대로 역방향 튜링 테스트입니다. 기계가 시험을 만들고, 자기가 그 시험을 통과하지 못하기를 바라는 구조입니다.
챌린지-응답 검사는 발급, 응답, 토큰, 검증 네 단계로 이루어집니다. 토큰은 한 번만 쓸 수 있고 수명이 짧습니다. 그래서 페이지를 새로고침하면 처음부터 다시 해야 하는 경우가 많습니다.
요즘 시스템은 퍼즐을 채점하기보다 위험도를 평가합니다. reCAPTCHA v3는 0.0에서 1.0 사이의 점수를 돌려주고, Cloudflare는 체크박스를 클릭하는 행위 자체가 신호가 아니라고 잘라 말합니다.
챌린지가 반복되는 원인은 대개 구체적입니다. 시계나 캐시 문제, 챌린지 스크립트를 막는 확장 프로그램, 가상 사설망 출구, 만료된 클리어런스 쿠키 중 하나입니다.
CAPTCHA는 설계상 일부 장애 사용자에게 장벽입니다. W3C는 이를 서비스 거부라고 부릅니다. Cloudflare 자체 수치를 보면 오디오 대체 수단은 쓸모없는 정도가 아니라 거꾸로 되어 있습니다. 사람보다 봇이 더 안정적으로 풀어내기 때문입니다.
주요 챌린지 유형 한눈에 보기
여러분이 지금까지 요구받았던 과제는 거의 모두 여섯 갈래 중 하나에 들어갑니다. 이들을 가르는 것은 퍼즐이 아닙니다. 작업하는 동안 서버가 실제로 무엇을 재는지입니다.
| 챌린지 유형 | 요구되는 행동 | 실제로 측정하는 것 | 실패하는 지점 |
|---|---|---|---|
| 왜곡된 텍스트(고전형) | 뒤틀린 글자를 입력 | 광학 문자 인식이 실패하는지 | Google은 AI가 가장 어려운 변형도 99.8% 정확도로 풀어내자 이 방식을 폐기했습니다 |
| 이미지 격자(reCAPTCHA v2, hCaptcha) | 버스나 계단, 신호등이 있는 타일을 모두 선택 | 클릭 전과 클릭 중에 모은 행동 및 환경 데이터 | 흐릿한 이미지, 모호한 경계, 무엇이 정답으로 인정됐는지 알려 주지 않음 |
| 체크박스 위젯(reCAPTCHA v2, Turnstile Managed) | 체크박스에 체크 | 브라우저 특성, 네이티브 API, 가벼운 작업 증명 | 스크립트가 차단되거나 캐시가 잘못되거나 시스템 시계가 어긋날 때 무한 반복 |
| 점수형 또는 보이지 않는 방식(reCAPTCHA v3, Turnstile Non-Interactive) | 눈에 보이는 것이 없음 | 요청 컨텍스트로 만든 위험 점수 | 왜 점수가 낮은지 알 수 없고, 어떻게 처리할지는 사이트가 정합니다 |
| 작업 증명 | 몇 초 대기 | 브라우저가 퍼즐에 실제 CPU를 썼는지 | 느린 기기일수록 오래 기다리고, JavaScript가 차단되면 페이지가 아예 멈춥니다 |
| 프라이버시 패스 토큰 | 눈에 보이는 것이 없음 | 발급자가 해당 기기를 보증했는지 | 토큰을 지원하는 플랫폼과 브라우저에서만 작동합니다 |
표를 다시 보면 문제의 모양이 드러납니다. 여섯 중 둘만 뭔가 머리를 쓰라고 요구합니다. 나머지는 지켜보기만 합니다.
CAPTCHA는 무슨 약자일까
CAPTCHA는 억지로 끼워 맞춘 약어입니다. 카네기멜런의 Luis von Ahn, Manuel Blum, Nicholas Hopper와 IBM Watson의 John Langford가 2003년에 낸 논문에서 나온 말이고 EUROCRYPT에서 발표됐습니다 (Springer). 초록은 이 아이디어를 한 문장으로 정리합니다. "any program that has high success over a CAPTCHA can be used to solve an unsolved Artificial Intelligence (AI) problem."
영리한 부분은 역할을 뒤집은 데 있습니다. 튜링 테스트는 기계가 사람 행세를 할 수 있는지 묻습니다. CAPTCHA는 판정을 기계에 맡기고, 기계가 아직 잘 못하는 과제를 고릅니다. 이걸 풀어내는 봇은 정의상 연구자들이 풀지 못한 문제를 푼 셈입니다.
이 설계에는 유통기한이 붙어 있습니다. 퍼즐이 기계에게 더 이상 어렵지 않아지는 순간 그것은 CAPTCHA가 아니게 되고, 여전히 그 퍼즐이 보이는 사람들만 남습니다. Google은 2014년에 이 점을 분명히 인정했습니다. "today's Artificial Intelligence technology can solve even the most difficult variant of distorted text at 99.8% accuracy. Thus distorted text, on its own, is no longer a dependable test" (Google Security Blog).
챌린지-응답 핸드셰이크의 작동 방식
전체 순환 과정을 가장 또렷하게 설명한 자료는 2005년 USENIX 논문입니다. 애플리케이션 계층 서비스 거부 공격 방어를 다룬 이 논문은 오늘날 위젯이 쓰는 것과 같은 교환을 설명합니다 (USENIX NSDI '05). 서버는 퍼즐과 서명된 토큰을 함께 내보냅니다. 답을 보내면 서버는 토큰 해시를 다시 계산하고, 토큰이 4분 안에 만들어진 것인지 확인하고, 답이 맞는지 봅니다. 세 검사를 모두 통과하면 수명 30분짜리 쿠키를 돌려줍니다.
오늘날 시스템은 뼈대를 그대로 두고 부품만 바꿨습니다. Cloudflare의 Turnstile은 cf-turnstile-response라는 토큰을 넣고, 사이트 서버가 자기 백엔드에서 이를 검증합니다. 문서는 "A token can only be validated once, and a token cannot be redeemed twice"라고 못 박습니다 (Cloudflare).
이 순서의 세 검사만 봐도 일상적인 답답함의 상당 부분이 설명됩니다. 답은 맞았는데 토큰이 만료되면 실패입니다. 쿠키가 브라우저에 남지 않아도 실패입니다. 챌린지 스크립트가 아예 실행되지 않았다면 검사할 토큰조차 없습니다. 어느 쪽이었는지 알려 주는 결과는 없습니다. 같은 상자가 다시 보일 뿐입니다.
요즘 챌린지가 풀 문제를 거의 내지 않는 이유
기계가 글자를 읽게 되자 업계는 시험을 공부할 수 없는 곳으로 옮겼습니다. 바로 세션입니다. 대체 화면이 언제 나오는지에 대한 Google의 설명은 이렇습니다. "In cases when the risk analysis engine can't confidently predict whether a user is a human or an abusive agent, it will prompt a CAPTCHA to elicit more cues."
reCAPTCHA v3는 이것을 API로 만들었습니다. 위젯이 없습니다. 서비스가 점수를 돌려주고, Google은 "11 levels for scores with values ranging from 0.0 to 1.0"이라고 문서화합니다. 1.0은 위험이 낮다는 뜻이고 0.0은 높다는 뜻입니다 (Google Cloud Fraud Defense). 점수와 함께 AUTOMATION, UNEXPECTED_ENVIRONMENT, TOO_MUCH_TRAFFIC, UNEXPECTED_USAGE_PATTERNS, LOW_CONFIDENCE_SCORE 같은 사유 코드가 표시됩니다. 공개하지 않는 것은 이 코드 뒤에 있는 신호의 전체 목록입니다.
2026년에 알아 둘 변화가 있습니다. developers.google.com/recaptcha 아래 모든 페이지에 Google Cloud Fraud Defense를 가리키는 지원 종료 안내가 붙었습니다. v3 모델은 다른 제품 영역으로 흡수되는 중이고, Google은 구현 첫 주에 잰 점수가 장기 프로덕션 동작과 다르다고 경고합니다.
Cloudflare의 Turnstile도 체크박스에 대해 같은 말을 합니다. 위젯은 Managed, Non-Interactive, Invisible 세 모드로 동작하고, Managed는 방문자 위험도에 따라 체크박스와 조용한 검사 중 하나를 고릅니다. 이 상자가 무엇을 위한 것인지에 대한 제품 설명은 직설적입니다. "the actual act of checking a box isn't important, it's the background data we're analyzing while the box is checked that matters" (Cloudflare).
그래서 "이미지가 흐릿했다"는 불평은 엉뚱한 층을 향합니다. 흐릿한 이미지는 위험 엔진이 이미 증거가 더 필요하다고 판단했을 때만 나타납니다.
챌린지가 계속 돌아오는 이유
무한 반복은 미스터리가 아니라 문서화된 현상입니다. Cloudflare는 자사 위젯의 실패 코드를 공개합니다. 시계가 틀렸거나 중간 단계에서 챌린지가 캐시된 "Clock or cache problem"에 200100, iframe이 차단됐을 때 200500입니다 (Cloudflare 오류 코드). 같은 페이지는 브라우저 확장 프로그램도 원인으로 꼽습니다. "Some browser extensions, such as ad blockers, may block the scripts Turnstile needs to operate."
클리어런스에는 자체 타이머가 있습니다. cf_clearance 쿠키는 방문자가 검증을 통과했음을 증명하고, "securely tied to the specific visitor and device it was issued to"이며, 기본 30분에 "a few extra minutes to account for clock skew"가 더해집니다. 타이머보다 중요한 경고도 따라붙습니다. "The visitor may be re-challenged, even if the cookie has not expired" (Cloudflare).
같은 목록에 대한 Google의 설명은 브라우저가 아니라 네트워크를 봅니다. 도움말 문서는 "자동화된 쿼리" 차단이 흔히 생기는 조건 세 가지를 듭니다. "a shared network that has been abused; your ISP may have recently assigned you a suspicious IP address; the site you're trying to visit may be under heavy attack right now" (Google FAQ). 셋 다 퍼즐로 해결할 수 있는 문제가 아니고, 여러분 잘못도 아닙니다.
네트워크가 원인이면 VPN이 CAPTCHA 생성기가 됩니다. Cloudflare는 "privacy-focused users often ask their browsers to go beyond standard practices… changing their user-agent… and preventing third-party scripts from executing entirely"라고 관찰했습니다. 통과하도록 설계된 적 없는 시험에서 강화 설정이 실패하는 모습을 정확히 묘사한 문장입니다. 특정 업체 사례를 단계별로 보고 싶다면 Cloudflare 인증 루프 해결 가이드가 그 경우를 차근차근 다루고, 개인정보 보호가 웹사이트를 망가뜨리는 이유가 더 넓은 패턴을 정리합니다.
이 반복에는 보안 비용도 따릅니다. 퍼즐과는 아무 상관이 없는 비용입니다. 2026년 8월, 한 관리자가 소규모 사업체 사이트에 reCAPTCHA를 흉내 낸 페이지를 올렸는데 클릭하면 PowerShell 명령이 클립보드에 복사됐습니다. 그가 말하려던 것은 순진함이 아니라 피로감이었습니다. "we and our staff are being so bombarded by these prove your human bots why wouldn't you click the do what it says" (r/sysadmin). 스레드의 최상위 답글은 이 기법의 이름을 ClickFix라고 밝혔고, 다른 댓글 작성자들은 자기 네트워크에서 하마터면 당할 뻔한 일을 적었습니다. 읽지 않고 따르도록 훈련된 인증 장벽은 피싱 표면이 됩니다.
CAPTCHA가 풀지 못하는 접근성 문제
이 문제에 대한 W3C의 설명은 이례적으로 직설적입니다. "users who are blind, visually impaired or dyslexic to identify textual characters in a distorted graphic is asking them to perform a task they are intrinsically least able to accomplish"라고 지적합니다 (W3C). 같은 문서는 reCAPTCHA v2의 오디오 대안이 아예 사라지고 "Your computer or network may be sending automated queries" 화면으로 대체되는 경우도 기록합니다.
WCAG 2.2는 모든 CAPTCHA에 서로 다른 두 가지 방식을 요구하고, 예외가 CAPTCHA를 둘러싼 폼이 아니라 "applies only to the content of the CAPTCHA"에만 해당한다고 조심스럽게 밝힙니다. 한계도 인정합니다. "Every type of CAPTCHA will be unsolvable by users with certain disabilities" (W3C WCAG 2.2).
오디오 대체 수단은 겉보기만 안전망입니다. Cloudflare가 자사 오디오 챌린지를 재 보니 "only 31.2% of audio challenges resulting in a three-person agreement on what the correct solution actually is"였고, "bots can accurately solve audio CAPTCHAs in over 85% of attempts"였습니다. 사람은 정답에 합의하지 못하는데 기계는 맞히는 방식이라면 거꾸로 되어 있는 것입니다.
커뮤니티 사례도 이 측정과 맞아떨어집니다. r/Blind에서 한 사용자는 화면 읽기 사용자를 예외로 빼 주려고 만든 접근성 쿠키와 씨름한 경험을 적었습니다. "Had a hell of a time getting their service to even allow that cookie to appear in my cookie jar when I checked the box… they have a separate option for a text-base captcha which is supposed to be more accessible but it was like trying to do a Caesar cipher in real time in your head" (r/Blind).
점자 디스플레이를 쓰고 챌린지를 보지도 듣지도 못하는 청각·시각 중복 장애 사용자를 어떻게 대응할지 물은 개발자는 설계 결함을 한 문장으로 정리했습니다. "Traditional captcha fails because it assumes you can either see or hear" (r/webdev). OWASP의 안내도 같은 방향입니다. JavaScript를 요구하면 "will reduce the accessibility of the website, especially to visitors who use screen readers"이므로 접근성이 떨어진다고 짚고, 다중 인증을 먼저 쓰고 CAPTCHA는 의심스럽거나 위험이 높은 로그인에만 남기라고 권합니다 (OWASP).
CAPTCHA가 AI 에이전트에 미치는 영향
이 군비 경쟁에 새 참가자가 생겼습니다. 2025년 벤치마크 Open CaptchaWorld는 멀티모달 모델 에이전트를 20가지 CAPTCHA에 대입해 테스트하고 이렇게 보고했습니다. "humans consistently achieve near-perfect scores, state-of-the-art MLLM agents struggle significantly, with success rates at most 40.0% by Browser-Use Openai-o3, far below human-level performance, 93.3%" (arXiv:2505.24878). 논문은 챌린지 장벽을 "a critical bottleneck for deploying web agents in real-world applications"라고 규정합니다.
사람들은 이미 우회로를 찾고 있습니다. 사람이 할 부분을 다시 모델에 넘기는 방식도 있습니다. 한 사용자는 신호등 격자를 세 번 실패한 뒤 화면을 캡처해 채팅 모델에 붙여넣고 "told it to take over my computer and handle it"이라고 지시했더니 첫 시도에 통과했다고 합니다 (X, @alt_w_v_g, 좋아요 597개). 같은 불만을 다룬 영상에 한 댓글 작성자는 "asking the actual robot to complete captcha instead of you is peak of irony and comedy"라고 이 패턴을 짚었습니다 (YouTube, 좋아요 365개).
인증 업계도 이 상황을 압니다. Cloudflare가 에이전트 트래픽에 내놓은 답은 더 어려운 퍼즐이 아니라 서명 방식입니다. Web Bot Auth는 Ed25519 HTTP Message Signatures와 공개 키 디렉터리를 써서 사이트가 서명된 에이전트와 익명 스크립트를 구분하게 합니다 (Cloudflare). Visa와 Mastercard는 2025년 10월에 이를 기반으로 한 에이전트 커머스 프로토콜을 발표했습니다. 검증된 봇 분류 체계는 이제 "Agent"와 "Training" 크롤러를 구분합니다.
여기까지 읽었다면 이 흐름의 방향이 중요합니다. 에이전트가 암호학으로 자신을 증명할 수 있게 되면, 챌린지 장벽은 기술 시험이 아니라 어떤 서명된 에이전트를 받아들일지 사이트가 정하는 정책 결정이 됩니다. 흐릿한 계단 사진보다 나은 결말이지만, 문제 하나는 그대로 남습니다. 에이전트형 브라우저는 이런 체계를 도입하지 않은 사이트에서 여전히 벽에 부딪힙니다.
챌린지가 막고 있을 때 쓸 수 있는 현실적인 선택: Tabbit Browser
챌린지에 막혔을 때 얼마나 오래 막혀 있을지는 세 가지 질문이 결정합니다. 이것이 어떤 종류의 검사인지, 페이지가 실제로 무엇을 말하는지, 문서에 나온 원인 중 내 환경에 해당하는 것은 무엇인지입니다. 셋 다 뭔가를 풀어야 하는 질문이 아닙니다. 읽고 진단하면 되는 질문이고, 모델을 품은 브라우저가 제 몫을 하는 지점이 여기입니다.
Tabbit Browser는 확장 프로그램으로 덧붙인 게 아니라 셸 자체에 AI 계층을 넣은 Chromium 기반 브라우저입니다. 여기서 쓸모가 있는 부분은 세 가지입니다.
첫째, 장벽을 읽는 일입니다. Tabbit의 Omnibox에서 @를 입력하면 현재 탭, 탭 그룹 전체, 스크린샷, 북마크, 로컬 파일을 컨텍스트로 참조할 수 있습니다. 나를 막고 있는 페이지를 가리키고 이것이 어떤 챌린지인지, 페이지에 뭐라고 적혀 있는지 물으면 됩니다. AI가 이미 열려 있는 페이지를 읽으므로 오류 문구를 다른 창에 복사할 필요가 없습니다. "Performing security verification"처럼 복사할 게 없는 화면이나 콘솔에 묻힌 200100 코드에서 이 차이가 큽니다.
둘째, 막힌 일과 하던 일을 떼어 놓는 것입니다. Tabbit의 Agent Mode는 위임한 작업을 별도 탭 그룹에서 실행합니다. 사이트의 폼이나 대시보드를 훑는 작업이 읽고 있던 페이지를 차지하지 않습니다. 위임 작업 도중 인증 장벽이 나타나면 그 작업의 그룹에 뜹니다. 돌아와서 사람이 할 단계를 직접 처리하면 내 탭은 떠날 때 그대로 있습니다.
셋째, 문제 해결 탭 다섯 개를 오가는 대신 체크리스트를 한자리에서 처리하는 것입니다. 문서에 나온 원인은 한정되어 있고 하나씩 시험할 수 있습니다. 시스템 시계를 확인하고, 그 사이트에서 광고와 스크립트 차단을 끄고, VPN을 끊고, 해당 도메인의 쿠키만 지운 뒤 새로고침합니다. 페이지를 읽는 도우미와 함께라면 이 순서는 오후 내내 추측하는 대신 몇 분이면 끝납니다.
트레이드오프는 분명하고, 솔직하게 말할 가치가 있습니다. Tabbit는 CAPTCHA를 대신 풀지 않고, 브라우저 지문을 위조하지 않으며, 평판이 낮은 IP 주소를 가정용처럼 보이게 만들지도 못합니다. 출구 IP가 차단 목록에 있다면 어떤 브라우저도 해결하지 못합니다. 네트워크를 바꾸거나 사이트에 문의해야 합니다. 인증 장벽은 세션을 판단하려고 존재하고, 그 판단을 조용히 무시하는 브라우저는 기능이 아니라 보안 문제입니다. 사이트의 챌린지가 클릭 한 번으로 통과되는 것이라면 도구가 필요 없다는 게 솔직한 답입니다. Tabbit가 돕는 건 그 주변입니다. 무슨 일이 있었는지 읽고, 하던 작업을 그대로 유지하고, 점검을 실행하는 일입니다.
브라우저 계층 자체가 자꾸 말썽이라면 그건 다른 조사입니다. 브라우저 업데이트가 웹사이트를 망가뜨리는 이유와 확장 프로그램이 작동을 멈췄을 때 할 일이 호환성 쪽을 다루고, 브라우저를 고르는 법은 전체 구성을 다시 생각할 때의 선택 기준을 다룹니다.
다음에 챌린지에 막혔을 때 할 일
설정을 마구 바꾸기 전에 보이는 증상을 원인에 맞춰 보세요.
| 보이는 증상 | 할 일 | 이유 |
|---|---|---|
| 같은 사이트에서 계속 반복됨 | 시스템 시계를 확인하고, 그 사이트의 스크립트 차단을 끄고, 해당 도메인의 쿠키만 지운 뒤 새로고침 | 문서에 나온 원인은 시계나 캐시 어긋남, 챌린지 스크립트 차단, 저장되지 않은 클리어런스 쿠키입니다 |
| 시크릿 창에서는 되는데 평소 프로필에서는 안 됨 | 확장 프로그램이나 프로필에 저장된 사이트 데이터가 차이를 만든 것 | 같은 브라우저, 같은 네트워크이므로 문제는 로컬에 있습니다 |
| VPN을 켜면 모든 사이트에서 발생 | 출구 노드를 바꾸거나 VPN을 끊고 다시 시도 | 데이터센터 주소 대역의 평판은 브라우저 설정으로 고칠 수 없습니다 |
| 체크박스가 초록색이 된 뒤 페이지가 새로고침되며 빈 상자가 됨 | 브라우저가 클리어런스 쿠키를 유지하지 못하고 있음 | 토큰이 발급된 뒤 버려졌거나 만료 전에 사이트가 다시 챌린지를 냈습니다 |
| 어떤 브라우저는 실패하고 다른 브라우저는 통과 | 통과하는 브라우저를 쓰고 실패는 제보 | 브라우저 하나에서만 실패하면 대개 사이트가 아니라 프로필 문제입니다. Cloudflare 루프 해결을 참고하세요 |
| 화면 읽기 프로그램을 쓰는데 오디오 대체 수단이 실패 | 사이트에 비시각적 대안을 요청하고 WCAG를 근거로 제시 | 두 가지 방식이 요구되고, 오디오 방식은 사람에게 측정 가능할 만큼 신뢰할 수 없습니다 |
| 위임한 에이전트 작업이 장벽에 부딪힘 | 그 단계는 직접 처리하고 작업을 다시 진행 | 인증은 사람을 요구하는데, 서명되지 않은 에이전트에게는 다른 방법이 없습니다 |
| 꼭 필요한 사이트가 특정 브라우저에서만 작동 | 정말 브라우저 문제인지 포털 정책인지 확인 | 일부 사이트는 기능이 아니라 브라우저 감지로 접근을 막습니다. 환자 포털이 Chrome에서만 작동하는 이유를 참고하세요 |
짧은 답
CAPTCHA 챌린지는 여러분을 시험하는 장치가 아닙니다. 세션에 대한 위험 판단을 퍼즐처럼 꾸며, 답할 수 있는 문제처럼 보이게 만든 것입니다. 이미지가 자주 알아볼 수 없게 나오는 이유, 무한 반복이 실력이 아니라 환경 때문에 생기는 이유가 여기 있습니다.
그러니 퍼즐이 아니라 환경을 고치세요. 문서에 나온 원인을 시계, 확장 프로그램, 네트워크, 쿠키 순서로 점검합니다. 네 가지를 모두 확인해도 챌린지가 계속 나타난다면 남은 변수는 주소 평판이고, 해결책은 브라우저를 바꾸는 게 아니라 사이트로 가는 경로를 바꾸는 것입니다.
에이전트가 일을 하고 있을 때는 사람이 할 단계를 사람에게 남겨 두세요. 기계적인 부분은 작업에 맡기고, 자신이 사람임을 증명하는 그 한 순간만 직접 맡으면 됩니다. 이 두 차선을 분리해 두는 AI 브라우저가 더 잘 흉내 내겠다고 약속하는 브라우저보다 여기서 유용합니다. 퍼즐은 이미 받아들였고 진짜 문제가 그 주변의 브라우저라면, 중요한 것은 이런 특성들입니다.
Tabbit를 받고 사람이 할 단계는 사람에게 남기기
Tabbit Browser는 macOS와 Windows에서 무료이고, Chrome, Edge, Safari의 북마크, 방문 기록, 확장 프로그램, 저장된 비밀번호를 한 번에 가져옵니다. 시험해 보려고 환경을 다시 만들 필요가 없습니다. 설치 파일은 tabbit.ai/download에서 받으세요.
설치 전에 기대치를 정리해 두겠습니다. Tabbit는 인증을 대신 통과해 주지 않고, 그런 척도 하지 않습니다. 이 문제에서 Tabbit가 주는 것은 눈앞의 페이지가 실제로 무엇을 말하는지 물어볼 자리, 그리고 위임한 작업이 읽고 있던 화면 위가 아니라 자기 탭 그룹에서 실행되는 작업 모델입니다. 체크박스를 누르고 넘어가는 부분을 포함해 나머지는 여러분 몫입니다.
자주 묻는 질문
CAPTCHA 챌린지를 쉽게 말하면 무엇인가요?
CAPTCHA 챌린지는 웹사이트가 사람이 보낸 요청인지 봇이 보낸 요청인지 판단하려고 요청 앞에 세우는 관문입니다. 서버가 챌린지를 내보내면 브라우저가 답하고, 서버는 서명된 토큰을 검증한 뒤에야 요청을 통과시킵니다. 요즘 대부분의 사이트에서는 퍼즐 자체가 아니라 브라우저와 네트워크 신호로 판정합니다.
챌린지-응답 검사는 실제로 저를 어떻게 검증하나요?
서버는 서명된 토큰과 함께 퍼즐이나 보이지 않는 테스트를 보냅니다. 브라우저는 답과 토큰을 돌려보내고, 서버는 토큰 해시를 다시 계산하고 토큰이 최근에 발급됐는지 확인한 다음 답이 맞는지 봅니다. 모두 통과하면 이후 요청에서 검증을 대신할 짧은 수명의 쿠키를 내줍니다. Cloudflare 문서에 따르면 Turnstile 토큰은 한 번만 검증할 수 있습니다.
왜 같은 사이트에서 CAPTCHA 챌린지가 계속 나올까요?
챌린지가 반복되는 데에는 대개 개인적인 이유가 아니라 구체적인 원인이 있습니다. Cloudflare는 시계나 캐시 문제, 챌린지 스크립트를 막는 확장 프로그램, 가상 사설망 출구를 원인으로 문서에 적어 두었고, 클리어런스 쿠키는 기본 30분이며 만료 전에도 다시 챌린지가 나올 수 있습니다. Google은 공유 네트워크, 인터넷 사업자가 배정한 의심스러운 주소, 공격을 받는 중인 사이트를 자체 챌린지가 나타나는 조건으로 꼽습니다.
reCAPTCHA v2와 v3의 차이는 무엇인가요?
버전 2는 체크박스를 보여 주고 이미지 퍼즐로 넘어갈 수 있지만, 버전 3은 위젯이 아예 없고 0.0에서 1.0 사이의 위험 점수를 돌려줍니다. Google은 11단계 점수와 AUTOMATION, TOO_MUCH_TRAFFIC 같은 사유 코드를 문서화했지만, 점수를 만드는 신호의 전체 목록은 공개하지 않습니다. 버전 3은 통과와 거부를 사이트가 결정하므로 같은 점수라도 사이트마다 다르게 처리할 수 있습니다.
CAPTCHA는 화면 읽기 사용자와 청각·시각 중복 장애 사용자에게 왜 문제인가요?
W3C는 상호작용형 CAPTCHA가 시각이나 청각을 전제로 하기 때문에 많은 장애 사용자에게 서비스 거부와 다름없다고 설명합니다. WCAG는 서로 다른 두 가지 방식을 요구하면서도 모든 유형의 CAPTCHA는 일부 사용자에게 풀 수 없다는 한계를 인정합니다. Cloudflare가 직접 측정한 결과에 따르면 오디오 챌린지에서 사람들이 정답에 합의한 비율은 31.2%에 그쳤고, 봇은 85%가 넘는 시도에서 오디오 챌린지를 풀었습니다.
AI 에이전트나 브라우저가 CAPTCHA를 대신 풀어 줄 수 있나요?
에이전트가 통과하는 경우도 있지만 안정적이지 않습니다. 2025년 벤치마크에서는 테스트한 에이전트 중 가장 좋은 성적이 챌린지의 40.0%였고 사람은 93.3%였습니다. 자동화로 챌린지를 푸는 순간 사이트가 원했던 신호 자체가 사라지는데, 봇 트래픽과 정당한 에이전트 트래픽이 뒤섞이는 이유가 여기에 있습니다. 챌린지를 대신 통과해 준다고 주장하는 브라우저는 의심해 볼 만합니다.