reCAPTCHA v3 점수 작동 방식: 2026년 보이지 않는 위험 엔진 분석

reCAPTCHA v3 점수 작동 방식: 보이지 않는 위험 엔진의 내부

reCAPTCHA v3는 2018년 출시 이후 구글의 핵심 봇 방어 계층으로 자리 잡았으며, 2026년 현재까지도 가장 널리 배포된 보이지 않는 챌린지 시스템이다. reCAPTCHA v3 점수 작동 방식을 이해하려면, 이 시스템이 단순한 “인간/봇 이진 분류”가 아니라는 점부터 출발해야 한다. 대신, 사용자가 특정 행동(action)을 수행할 때마다 grecaptcha.execute() 호출을 통해 0.0에서 1.0 사이의 연속형 위험 점수를 반환한다. 점수가 높을수록 “합법적인 인간 트래픽”일 가능성이 높다고 판단한다.

이 점수는 단일 신호가 아니라 수십 개의 신호를 융합한 결과다. 마우스 이동 궤적, 스크롤 패턴, 키스트로크 타이밍, 페이지 체류 시간, Google 쿠키 그래프, 브라우저 지문(TLS 지문 포함), 그리고 IP 평판이 모두 점수 계산에 들어간다. 합법적인 QA 자동화나 접근성 테스트를 수행하는 엔지니어에게 이 점수를 통과하는 것은 단순한 기술적 호기심이 아니라 실무적 요구사항이다. 이 글에서는 reCAPTCHA v3가 점수를 어떻게 계산하는지, 왜 데이터센터 IP가 점수를 붕괴시키는지, 그리고 레지던셜 프록시와 실제 브라우저를 결합해 합법적으로 통과 점수를 유지하는 방법을 다룬다.

reCAPTCHA v3 score: 연속형 점수와 11개 버킷

구글은 reCAPTCHA v3의 점수를 0.1 단위로 11개 버킷(0.0, 0.1, 0.2, … 1.0)으로 양자화하여 반환한다. 실제 내부 모델은 연속형 확률값을 생성하지만, API 응답에서는 소수점 첫째 자리로 반올림된 값이 전달된다. 대부분의 웹사이트는 다음과 같은 임계값을 사용한다:

• 0.3 미만: 차단(block) — 봇으로 간주하여 요청 거부
• 0.3–0.6: 챌린지(challenge) — 추가 검증(이메일 인증, 2FA, 이미지 챌린지) 요구
• 0.6 초과: 허용(allow) — 정상 트래픽으로 통과

이 임계값은 사이트마다 다르며, 일부 금융 사이트는 0.7 이상을 요구하기도 한다. recaptcha score 0.3은 실무에서 가장 중요한 분기점이다. 0.3 미만으로 떨어지면 대부분의 사이트에서 즉시 차단되기 때문이다. 구글의 공식 문서에 따르면 점수는 “사이트 전체 트래픽의 통계적 분포”를 기반으로 조정되며, 사이트가 충분한 트래픽을 확보하면 자동으로 임계값 튜닝이 이루어진다. 자세한 내용은 Google reCAPTCHA v3 개발자 문서에서 확인할 수 있다.

기술적 배경: 왜 이 문제가 존재하는가

reCAPTCHA v2는 “나는 로봇이 아닙니다” 체크박스와 이미지 선택 챌린지를 통해 인간과 봇을 구분했다. 하지만 이 방식은 사용자 경험을 저해하고, 접근성 장벽을 만들었으며, 봇 팜이 머신러닝으로 이미지 챌린지를 자동 해결하면서 효율성이 떨어졌다. reCAPTCHA v3는 이 문제를 “보이지 않는 점수”로 해결하려 했다. 사용자는 아무것도 클릭하지 않아도 되지만, 백엔드에서는 복잡한 신호 융합이 일어난다.

핵심 문제는 이 점수가 행동 신호만으로 결정되지 않는다는 것이다. 아무리 인간적인 마우스 움직임을 시뮬레이션해도, IP 평판이 나쁘면 점수는 0.1–0.2 수준으로 붕괴한다. 이는 합법적인 자동화를 수행하는 QA 엔지니어와 보안 연구자에게 큰 장애물이 된다. 예를 들어, 자사 웹사이트의 reCAPTCHA 통합을 테스트하는 QA 팀이 AWS/GCP IP에서 접근하면, 실제 사용자와 동일한 행동을 해도 점수가 낮게 나와 테스트가 실패한다.

신호 융합: 구글이 무엇을 보는가

reCAPTCHA v3가 융합하는 주요 신호 카테고리는 다음과 같다:

TLS 지문에 대해 조금 더 설명하자면, reCAPTCHA v3는 직접 TLS 핸드셰이크를 수집하지는 않지만, reCAPTCHA 스크립트가 로드되는 Google 도메인 연결에서 JA3/JA4 지문이 수집될 수 있다. 예를 들어, Python requests 라이브러리의 기본 TLS 설정은 Chrome의 TLS 핸드셰이크와 확장 순서가 다르다. requests는 일반적으로 TLS_AES_256_GCM_SHA384를 최우선으로 제안하지만, Chrome 120+는 TLS_AES_128_GCM_SHA256을 먼저 제안하고 확장 순서도 다르다. 이런 차이가 점수에 영향을 줄 수 있다.

캔버스 핑거프린트는 브라우저가 <canvas> 요소에 텍스트와 도형을 렌더링한 후 픽셀 데이터를 해시한 값이다. Headless Chrome은 GPU 가속이 비활성화되어 있거나 가상 디스플레이에서 실행되므로, 일반 Chrome과 캔버스 해시가 다르다. 이 값이 reCAPTCHA의 신호 융합에 직접 들어가는지는 공개되어 있지 않지만, Google의 위험 모델은 브라우저 일관성을 평가하므로, 비정상적인 캔버스 해시는 의심 신호로 작용할 수 있다.

데이터센터 IP가 점수를 붕괴시키는 이유

reCAPTCHA v3의 IP 평판 신호는 행동 신호를 압도할 수 있다. 이는 실무에서 가장 자주 마주하는 장벽이다. AWS, GCP, Azure, DigitalOcean, Hetzner 등의 ASN은 “데이터센터”로 분류되며, 구글은 이 IP 대역에서 오는 트래픽에 기본적으로 낮은 신뢰도를 부여한다.

구체적으로, 데이터센터 IP에서 reCAPTCHA v3 점수는 일반적으로 0.1–0.3 범위에 머문다. 반면, 레지던셜 IP(가정용 ISP)에서 동일한 행동을 수행하면 0.7–0.9 점수가 나오는 경우가 많다. 이 차이는 행동 신호가 아니라 IP ASN 분류가 결정한다. 모바일 IP(4G/5G)도 레지던셜과 유사한 높은 신뢰도를 받는다.

이것이 합법적인 자동화에 레지던셜 프록시가 필요한 이유다. 자사 웹사이트의 reCAPTCHA 통합을 QA 테스트하거나, 접근성 자동화 도구를 실행하거나, 허가받은 보안 테스트를 수행할 때, 데이터센터 IP를 사용하면 테스트 자체가 실패한다. 행동을 완벽하게 시뮬레이션해도 IP 평판이 점수를 끌어내린다.

핵심 인사이트: reCAPTCHA v3 점수에서 IP 평판은 행동 신호보다 우선순위가 높을 수 있다. 데이터센터 IP에서 0.8 이상의 점수를 얻는 것은 사실상 불가능에 가깝다. 레지던셜 또는 모바일 IP가 필수다.

서버 측 토큰 검증: siteverify 작동 원리

클라이언트에서 grecaptcha.execute(siteKey, {action: 'submit'})를 호출하면 토큰이 반환된다. 이 토큰을 백엔드로 전송하면, 백엔드는 Google의 siteverify 엔드포인트에 토큰과 시크릿 키를 POST하여 검증한다:

POST https://www.google.com/recaptcha/api/siteverify
Content-Type: application/x-www-form-urlencoded

secret=YOUR_SECRET_KEY&token=TOKEN_FROM_CLIENT

응답은 다음 필드를 포함한다:

• success: true/false
• score: 0.0–1.0
• action: 클라이언트에서 지정한 action 문자열
• hostname: 토큰이 생성된 사이트의 호스트명
• error-codes: 오류 코드 배열

여기서 두 가지 검증이 중요하다:

1. action 일치: 클라이언트에서 {action: 'login'}으로 토큰을 생성했으면, 서버에서 반환된 action도 'login'이어야 한다. 공격자가 다른 action으로 생성한 토큰을 재사용하는 것을 방지한다.
2. hostname 일치: 반환된 hostname이 예상 도메인과 일치해야 한다. 공격자가 다른 사이트의 사이트 키를 도용해 토큰을 생성하는 것을 방지한다.

이 두 검증을 생략하면, reCAPTCHA v3의 보안 가치가 크게 훼손된다. 자체 QA 환경에서도 이 검증을 그대로 구현해야 실제 프로덕션 동작을 정확히 테스트할 수 있다.

합법적 접근: ProxyHat 레지던셜 프록시 + 실제 브라우저

이제 실제 구현을 살펴보자. 목표는 합법적인 QA 자동화 또는 허가받은 보안 테스트에서 reCAPTCHA v3 점수를 0.6 이상으로 유지하는 것이다. 이를 위해서는 세 가지가 필요하다:

1. 레지던셜 IP — 데이터센터 IP는 점수를 붕괴시킨다.
2. 실제 브라우저 — Headless Chrome이 아닌, 실제 Chrome/Chromium 인스턴스. TLS 지문, 캔버스 핑거프린트, JavaScript 엔진 동작이 일반 사용자와 일치해야 한다.
3. 인간적 행동 — 마우스 이동, 스크롤, 적절한 타이밍. 즉시 폼을 채우는 것은 의심 신호다.

ProxyHat 레지던셜 프록시 설정

ProxyHat 레지던셜 프록시는 gate.proxyhat.com:8080 게이트웨이를 통해 접근한다. 사용자 이름에 국가 코드를 지정해 미국 레지던셜 IP를 할당받을 수 있다:

# HTTP 프록시 (기본 포트 8080)
http://user-country-US:PASSWORD@gate.proxyhat.com:8080

# SOCKS5 프록시 (포트 1080)
socks5://user-country-US:PASSWORD@gate.proxyhat.com:1080

도시 단위 타겟팅도 가능하다: user-country-US-city-newyork:PASSWORD@gate.proxyhat.com:8080. 세션 고정이 필요하면 user-session-abc123:PASSWORD 형식을 사용해 동일한 IP를 유지할 수 있다. 자세한 연결 가이드는 ProxyHat 공식 문서를 참조하라.

Python 예제: Playwright + ProxyHat 레지던셜

아래는 Playwright를 사용해 실제 Chromium을 구동하고, ProxyHat 레지던셜 프록시를 통해 접속하며, 인간적 행동을 시뮬레이션하는 예제다. 이 예제는 자사 웹사이트의 reCAPTCHA v3 통합을 테스트하는 QA 시나리오를 가정한다:

from playwright.sync_api import sync_playwright
import time
import random

PROXY = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-country-US",
    "password": "YOUR_PASSWORD"
}

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,  # 실제 브라우저 — headless는 감지 위험
        proxy=PROXY
    )
    context = browser.new_context(
        viewport={"width": 1920, "height": 1080},
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) "
                  "Chrome/131.0.0.0 Safari/537.36"
    )
    page = context.new_page()

    # 1. 페이지 로드 후 대기 (인간적 체류 시간)
    page.goto("https://your-site.example.com/login")
    time.sleep(random.uniform(2.0, 4.0))

    # 2. 마우스 이동 시뮬레이션 (선형이 아닌 곡선 궤적)
    page.mouse.move(100, 200)
    time.sleep(0.3)
    page.mouse.move(300, 250)
    time.sleep(0.5)

    # 3. 스크롤 (자연스러운 속도)
    page.mouse.wheel(0, 150)
    time.sleep(random.uniform(0.5, 1.0))

    # 4. reCAPTCHA 토큰 실행
    token = page.evaluate("""
        async () => {
            await new Promise(r => grecaptcha.ready(r));
            return grecaptcha.execute(
                'YOUR_SITE_KEY',
                {action: 'login'}
            );
        }
    """)
    print(f"reCAPTCHA token: {token[:40]}...")

    # 5. 백엔드 siteverify 호출 (별도 스크립트)
    # 토큰을 서버로 전송하여 score 확인

    browser.close()

이 예제에서 주의할 점은 headless=False다. Headless Chrome은 navigator.webdriver가 true이고, GPU 컨텍스트가 다르며, 캔버스 렌더링이 가상 디스플레이에서 이루어진다. 이 모든 것이 reCAPTCHA 점수를 낮추는 요인이다. 가능하면 실제 디스플레이 환경에서 실행하라. 서버 환경에서는 Xvfb 가상 디스플레이를 사용할 수 있지만, 이 경우 캔버스 핑거프린트가 여전히 비정상적일 수 있다.

행동 시뮬레이션의 핵심 원칙

행동 신호를 자연스럽게 만드는 것은 단순히 time.sleep()을 추가하는 것이 아니다. reCAPTCHA v3는 다음을 검사한다:

• 마우스 궤적의 곡률: 직선 이동은 로봇 신호다. 베지어 곡선 기반 이동이 자연스럽다.
• 이벤트 간격의 변동성: 정확히 1.0초마다 클릭하는 것은 의심스럽다. random.uniform(0.3, 1.2) 같은 변동이 필요하다.
• 포커스 전환: 탭 전환, 클릭 후 포커스 이동 등 실제 사용자의 행동 패턴.
• 페이지 체류 시간: 페이지 로드 후 0.1초 만에 폼 제출하는 것은 비정상이다. 최소 2–5초 대기.

프록시 유형 비교: reCAPTCHA v3 통과 관점

공용 레지던셜 프록시 풀은 비용이 저렴하지만, 동일한 IP가 많은 사용자에 의해 사용되면 IP 평판이 저하될 수 있다. ProxyHat의 프라이빗 레지던셜 풀은 이 문제를 완화한다. 가격 정보는 ProxyHat 가격 페이지에서 확인할 수 있다.

흔한 실수와 엣지 케이스

1. Headless 브라우저 사용

Headless Chrome은 여전히 navigator.webdriver === true를 반환하며, Chrome 131 기준으로 --headless=new 모드에서도 일부 JavaScript API 동작이 다르다. reCAPTCHA v3가 이를 직접 검사하는지는 불분명하지만, 행동 신호와 결합되면 의심 신호로 작용할 수 있다. 가능하면 headless=False를 사용하라.

2. 세션 고정 없이 매 요청마다 IP 변경

reCAPTCHA v3는 Google 쿠키 그래프를 사용한다. 쿠키가 없는 상태에서 매 요청마다 다른 IP로 접속하면, “새로운 방문자” 상태가 되어 초기 점수가 보수적으로 낮게 책정될 수 있다. 세션 고정(user-session-abc123)을 사용해 동일한 IP와 쿠키를 유지하면 점수가 안정화된다.

3. action 불일치

클라이언트에서 {action: 'submit'}으로 토큰을 생성했는데, 서버에서 action === 'login'을 기대하면 검증이 실패한다. QA 환경에서 이 실수는 테스트 실패의 흔한 원인이다. 항상 action 문자열을 클라이언트와 서버 간에 일치시켜라.

4. 토큰 만료

reCAPTCHA v3 토큰은 약 2분 후 만료된다. 토큰을 생성한 후 지연 없이 siteverify를 호출해야 한다. 자동화 파이프라인에서 토큰을 큐에 저장해 두었다가 나중에 사용하면 검증이 실패한다.

적용 범위와 윤리적 경계

이 글에서 설명한 기법은 합법적인 용도에만 적용해야 한다:

• 자사 QA 자동화: 자체 웹사이트의 reCAPTCHA 통합을 테스트하는 경우.
• 접근성 테스트: 스크린 리더, 키보드 내비게이션 등 접근성 도구가 reCAPTCHA와 호환되는지 검증.
• 허가받은 보안 테스트: 사이트 소유자의 서면 허가를 받은 침투 테스트.

반면, 다음 용도는 명백히 부적법이다:

• 타사 사이트의 reCAPTCHA를 우회해 대량 계정 생성.
• 티켓팅/스니커즈 봇으로 경쟁 사용자를 밀어내는 행위.
• 사기, 자격 증명 스터핑, 또는 서비스 악용.

미국에서는 컴퓨터 사기 및 남용법(CFAA, 18 U.S.C. § 1030)이 “허가 없는 접근”을 금지하며, reCAPTCHA를 우회해 타사 사이트에 접근하는 것은 CFAA 위반으로 해석될 수 있다. 유럽 연합에서는 GDPR 제6조가 합법적 근거를 요구하며, 타사 사이트의 reCAPTCHA 신호를 무단으로 우회하는 것은 데이터 처리의 합법적 근거가 부족할 수 있다. 자세한 법적 맥락은 FTC 사법 사례 라이브러리에서 관련 사례를 확인할 수 있다.

ProxyHat은 웹 스크래핑 및 SERP 추적 같은 합법적 자동화 사용 사례를 지원한다. 관련 사용 사례는 웹 스크래핑 사용 사례와 SERP 추적 사용 사례에서 확인할 수 있으며, 사용 가능한 위치 목록은 프록시 위치 페이지에 있다.

핵심 요약

• reCAPTCHA v3는 0.0–1.0 연속형 점수를 반환하며, 0.3 미만은 차단, 0.3–0.6은 챌린지, 0.6 초과는 허용이 일반적이다.
• 점수는 행동 텔레메트리, Google 쿠키 그래프, 브라우저 지문(TLS/캔버스), IP 평판을 융합하여 계산한다.
• 데이터센터 IP는 행동이 완벽해도 점수를 0.1–0.3으로 붕괴시킨다. 레지던셜 또는 모바일 프록시가 필수다.
• 서버 측에서 action과 hostname 일치를 반드시 검증해야 한다. 토큰은 약 2분 후 만료된다.
• 합법적 자동화에서는 실제 브라우저(headless=False), 레지던셜 프록시, 인간적 행동 시뮬레이션을 결합해야 0.6 이상의 점수를 유지할 수 있다.
• 이 기법은 자사 QA, 접근성 테스트, 허가받은 보안 테스트에만 사용해야 한다. 타사 사이트 무단 접근은 CFAA/GDPR 위반이다.

FAQ

reCAPTCHA v3 점수 작동 방식이란?

reCAPTCHA v3는 사용자가 특정 행동(action)을 수행할 때 grecaptcha.execute()를 통해 0.0에서 1.0 사이의 연속형 위험 점수를 반환하는 보이지 않는 봇 방지 시스템이다. 점수는 행동 텔레메트리, Google 쿠키 그래프, 브라우저 지문, IP 평판 등 수십 개의 신호를 융합하여 계산되며, 0.1 단위로 11개 버킷으로 양자화되어 반환된다. 일반적으로 0.3 미만은 차단, 0.3–0.6은 챌린지, 0.6 초과는 허용으로 처리한다.

왜 reCAPTCHA v3 점수가 프록시 사용자에게 중요한가?

reCAPTCHA v3 점수에서 IP 평판은 행동 신호보다 우선순위가 높을 수 있다. 데이터센터 IP(AWS, GCP, Azure 등)에서는 아무리 인간적인 행동을 시뮬레이션해도 점수가 0.1–0.3 범위에 머물러 대부분의 사이트에서 차단된다. 따라서 합법적인 QA 자동화나 허가받은 보안 테스트를 수행하려면 레지던셜 또는 모바일 프록시를 사용해 IP 평판 신호를 통과해야 한다.

reCAPTCHA v3에 가장 적합한 프록시 유형은?

레지던셜 프록시와 모바일 프록시가 가장 적합하다. 레지던셜 IP는 가정용 ISP에서 할당된 IP로, 일반 사용자 트래픽과 구별되지 않아 높은 신뢰도를 받는다. 모바일 IP(4G/5G)는 통신사 대역으로 가장 높은 신뢰도를 받지만 비용이 더 높다. 데이터센터 프록시는 ASN 분류에서 즉시 데이터센터로 식별되어 점수가 붕괴하므로 부적합하다.

reCAPTCHA v3 차단을 피하려면 어떻게 해야 하나?

합법적 자동화에서 차단을 피하려면 세 가지를 결합해야 한다: (1) 레지던셜 프록시로 IP 평판 통과, (2) 실제 브라우저(headless=False)로 TLS 지문과 캔버스 핑거프린트 일치, (3) 곡선 마우스 이동, 변동 간격, 적절한 체류 시간으로 인간적 행동 시뮬레이션. 또한 세션 고정으로 동일한 IP와 쿠키를 유지하고, 토큰 만료(약 2분) 전에 siteverify를 호출해야 한다. 단, 이 기법은 자사 QA나 허가받은 테스트에만 사용해야 한다.

reCAPTCHA v3 토큰 검증에서 action과 hostname이 왜 중요한가?

서버 측 siteverify 응답에는 토큰이 생성된 action 문자열과 hostname이 포함된다. 백엔드는 이 값이 예상한 action(예: 'login')과 hostname(예: 'example.com')과 일치하는지 반드시 검증해야 한다. 이 검증을 생략하면 공격자가 다른 action으로 생성한 토큰이나 다른 사이트의 사이트 키로 생성한 토큰을 재사용할 수 있다. QA 환경에서도 이 검증을 구현해야 프로덕션 동작을 정확히 시뮬레이션할 수 있다.