왜 reCAPTCHA는 봇을 막지 못하게 되었는가

폼을 전송하기 전에 "신호등을 모두 선택해 주세요"라는 요청을 받는다. 그 메커니즘이 reCAPTCHA(리캡차)다.

오랫동안 Web 서비스의 bot protection(보트 방어)의 정석으로 사용되어 왔다. 그런데 현재, reCAPTCHA는 봇을 확실하게 막는 수단으로서 기능하지 못하고 있다. 왜 그렇게 되었는지, 기술적인 배경을 정리한다.

먼저 메커니즘 확인부터 시작한다.

reCAPTCHA v2는 "인간다운 행동 패턴인가"를 스코어링(scoring)한다. 마우스의 움직임, 클릭 타이밍, IP 주소, Cookie 상태 등을 조합하여 리스크 스코어(risk score)를 산출하고, 의심스러운 경우 이미지 선택 챌린지(challenge)를 내보낸다.

reCAPTCHA v3는 UI 챌린지를 없애고, 사이트 전체의 행동을 상시 감시하여 0.0~1.0의 스코어를 반환하는 설계다. 스코어가 낮으면 추가 확인을 요구한다.

둘 다 공통적인 점은, "인간다운 행동을 하고 있는가"를 확률적으로 판정한다는 설계다. "이 주체가 생물학적인 인간인가"를 확인하고 있는 것이 아니다.

이 구분이 AI 시대에 치명적인 문제가 되고 있다.

bot protection으로서 reCAPTCHA가 기능하지 않게 된 이유는 크게 3가지가 있다.

"버스가 포함된 이미지를 선택해라", "신호등을 클릭해라"라는 챌린지는 인간에게는 직관적이고 기계에게는 어려운 태스크(task)로 설계되어 있었다. 다만, 현재의 이미지 인식 AI는 이러한 종류의 태스크에서 인간과 동등하거나 그 이상의 정밀도를 가진다.

Imperva의 조사에 따르면, 고도화된 봇의 reCAPTCHA 돌파율은 83%에 달한다. 이미지 챌린지는 bot protection의 수단으로서 거의 기능하지 않게 되었다.

reCAPTCHA v3가 의존하는 "인간다운 마우스 움직임"이나 "자연스러운 클릭 타이밍"은 현재의 AI 에이전트(agent)가 고정밀도로 모방할 수 있다. 의도적으로 랜덤성을 가미한 시뮬레이터는 행동 분석형 스코어링을 통과할 수 있다.

알고리즘에 의한 돌파뿐만 아니라, 인력으로 CAPTCHA를 푸는 서비스(CAPTCHA Farm)나 자동 돌파 툴이 상업적으로 유통되고 있다. 기술적인 문제라기보다 경제적인 아비트라지(arbitrage)로서 기능하고 있다.

자주 나오는 의문이므로 정리해 둔다.

v3는 UI 챌린지를 없애 사용자 경험을 개선했지만, 행동 분석이라는 근본적인 접근 방식은 v2와 같다. AI에 의한 시뮬레이션에 대한 내성이라는 의미에서는 v2와 v3의 차이는 크지 않다.

오히려 v3의 문제는 스코어 판정 기준이 불투명하기 때문에 오검출(false positive)이 일어나기 쉽다는 점에 있다. 정상 사용자가 차단되거나, 반대로 고정밀 봇이 통과하는 케이스가 보고되고 있다.

bot protection으로서의 한계와는 별개로, 비용 문제도 있다.

Google Cloud 공식 요금 페이지에 따르면, reCAPTCHA Enterprise는 API 호출 수에 따른 종량제 모델로 이행하고 있다. 월간 100만 리퀘스트(request)를 초과하는 규모가 되면 무시할 수 없는 비용이 발생한다.

보안상의 한계와 경제적인 비용이 겹치면서, 대체 수단을 검토하는 엔지니어가 늘어나고 있다. 대체 수단의 비교에 대해서는 'reCAPTCHA가 유료화: 일본 개발자가 알아두어야 할 대체 수단'에서 정리하고 있다.

여기에 설계상의 핵심이 있다.

reCAPTCHA가 확인하고 있는 것은 "인간다운 행동 패턴"이지 "이 주체가 인간인가"가 아니다. AI가 인간의 행동을 정밀하게 모방할 수 있는 시대에, 행동 기반의 판정은 "인간임을 증명하는 것"으로서 기능하지 않는다.

이 한계로 인해, 보안 설계 영역에서는 "proof of human(인간 증명)"이라는 다른 접근 방식이 주목받고 있다. 행동을 분석하는 것이 아니라, 생체 정보를 기점으로 한 암호학적인 증명으로 "이 주체가 실재하는 고유한 인간인가"를 확인하려는 설계다.

World ID는 그 접근 방식을 실용화한 사례 중 하나다. 전용 디바이스 Orb가 얼굴과 눈의 이미지를 취득하고, 홍채 패턴으로부터 생성한 해시값(IrisCode)과 영지식 증명(ZKP)을 조합함으로써, 개인 정보를 공개하지 않고도 "실재하는 고유한 인간"임을 증명할 수 있는 구조로 되어 있다. reCAPTCHA와의 설계상 차이에 대해서는 'reCAPTCHA는 이제 한계? AI가 봇 검증을 돌파하는 시대의 새로운 인간 증명'에서 자세히 정리하고 있다.

reCAPTCHA가 "쓸 수 없다"는 이야기는 아니다. 경량 스팸 대책으로서 일정 역할은 아직 있다.

문제는 "reCAPTCHA를 두어 놓으면 bot protection이 되고 있다"라는 전제로 설계를 진행하는 것이다.

높은 신뢰성이 필요한 상황, 예를 들어 이벤트 추첨, 포인트 프로그램, AI 에이전트가 대량으로 유입될 가능성이 있는 API 엔드포인트에서는 확률적인 행동 판정만으로는 불충분하다. 용도를 명확히 한 뒤, reCAPTCHA를 사용하는 상황과 다른 수단을 사용하는 상황을 구분하는 것이 현실적인 설계다.

• reCAPTCHA는 행동 패턴의 확률적 판정에 의한 bot protection(봇 보호)이며, "인간인지 아닌지"를 직접 확인하는 메커니즘이 아니다
• 이미지 인식 AI의 정밀도 향상과 행동 시뮬레이션의 정교화로 인해, 고도화된 봇의 83%가 reCAPTCHA를 돌파할 수 있다
• v3는 UI를 없앴지만, 행동 분석이라는 근본적인 접근 방식은 v2와 동일하여 내성의 차이가 작다
• 2025년 이후 Enterprise 버전의 유료화 전환도 대체 수단을 검토하는 움직임을 가속화하고 있다
• 신뢰성 높은 bot protection이 필요한 상황에서는 행동 분석형이 아닌 증명 기반 (proof-based) 접근 방식을 검토할 가치가 있다

경량 스팸 방지책으로서는 아직 유효한 상황이 있다. 다만 "reCAPTCHA를 두면 bot protection이 되고 있다"라는 전제로 높은 신뢰성이 필요한 설계를 진행하는 것은 재고할 필요가 있다.

행동 분석이라는 설계는 동일하며, AI 시뮬레이션에 대한 내성의 차이는 크지 않다. v3는 UI를 제거함으로써 사용자 경험(UX)은 개선되었지만, 보안의 근본적인 구조는 변하지 않았다.

직접적인 대체재가 아니라 용도가 다르다. reCAPTCHA는 스팸 필터링에 적합하다. proof of human은 "한 명의 실재하는 인간이 참여하고 있다"라는 보증이 필요한 상황에 적합하며, 설계의 전제가 다르다.

관련 링크