---
title: "구글 reCAPTCHA, 탈구글 안드로이드 사용자에게 사실상 문 걸어 잠갔다"
published: 2026-05-08T18:45:58.000Z
canonical: https://jeff.news/article/2455
---
# 구글 reCAPTCHA, 탈구글 안드로이드 사용자에게 사실상 문 걸어 잠갔다

구글의 차세대 reCAPTCHA가 안드로이드에서 Google Play Services 25.41.30 이상을 요구하면서 GrapheneOS 같은 탈구글 기기 사용자가 인증에 실패하는 문제가 나왔어. iOS 16.4 이상에서는 추가 앱 설치 없이 같은 검증을 통과한다는 점 때문에, 보안보다 생태계 통제라는 비판이 커지고 있어.

- 구글의 차세대 reCAPTCHA가 탈구글 안드로이드 사용자에게 사실상 장벽이 됐다는 비판이 나옴
  - 안드로이드에서 검증을 통과하려면 Google Play Services 25.41.30 이상이 필요함
  - GrapheneOS처럼 구글 소프트웨어를 제거한 커스텀 롬에서는 챌린지가 뜨는 순간 인증이 실패할 수 있음

- 문제의 흐름은 이렇음
  - reCAPTCHA가 사용자를 수상하다고 판단하면 예전처럼 이미지 퍼즐을 던지는 대신 QR 코드 스캔을 요구함
  - 이 QR 검증은 백그라운드에서 Google Play Services가 돌고, 구글 서버와 통신해야 통과됨
  - Play Services가 없는 안드로이드 기기는 여기서 막힘

```mermaid
sequenceDiagram
    participant 사용자 as 탈구글 안드로이드 사용자
    participant 웹사이트 as 웹사이트
    participant 리캡차 as 리캡차
    participant 플레이 as 구글 플레이 서비스
    participant 구글 as 구글 서버
    사용자->>웹사이트: 로그인 또는 접근 시도
    웹사이트->>리캡차: 사람 여부 검증 요청
    리캡차->>사용자: QR 코드 검증 요구
    사용자->>플레이: 백그라운드 검증 시도
    플레이->>구글: 기기 및 검증 데이터 전송
    구글-->>리캡차: 검증 결과 반환
    리캡차-->>웹사이트: 통과 또는 실패 처리
```

- 구글은 이 시스템을 4월 23일 Cloud Next에서 Google Cloud Fraud Defense의 일부로 소개했음
  - 자율 AI 에이전트와 전통적인 봇을 모두 다루는 신뢰 플랫폼이라는 식의 포지셔닝임
  - 그런데 실제 사용자 입장에서는 “사람임을 증명하려면 구글의 독점 프레임워크를 켜라”에 가까운 요구가 생긴 셈임

> [!IMPORTANT]
> reCAPTCHA는 수백만 개 웹사이트 앞단에 붙어 있음. 여기에 Play Services 의존성이 생기면, 특정 안드로이드 환경에서는 웹의 기본 콘텐츠 접근 자체가 막힐 수 있음.

- 이 변화가 갑자기 튀어나온 것도 아님
  - 2025년 10월 Internet Archive 스냅샷에도 지원 페이지가 이미 Play Services 25.39.30 요구사항을 적고 있었음
  - 최소 7개월 전부터 의존성이 조용히 들어가 있었고, 이후 degoogle 서브레딧 사용자가 문제를 제기하면서 PiunikaWeb과 Android Authority 보도로 더 알려짐

- iOS와 비교하면 더 묘함
  - iOS 16.4 이상 기기는 같은 검증을 추가 앱 설치 없이 통과함
  - 구글은 아이폰 사용자에게 Google 소프트웨어 설치를 요구하지 않음
  - 결국 Play Services를 거부한 안드로이드 사용자만 “수상한 사용자”처럼 취급되는 비대칭 구조가 됨

> [!WARNING]
> 웹 개발자가 이 reCAPTCHA를 도입하면 보안 기능 하나 붙이는 데서 끝나지 않음. 탈구글 안드로이드 사용자를 서비스 밖으로 밀어내는 선택이 될 수 있음.

- 탈구글 폰 사용자는 그냥 특이한 취향의 사용자가 아님
  - 이들은 Play Services가 어떤 데이터를 구글로 보내는지 보고 동의하지 않아서 다른 환경을 고른 사람들임
  - 새 reCAPTCHA는 그 결정을 기본적으로 의심스럽게 보고, 구글 소프트웨어 부재를 검증 실패 조건처럼 다룸

- 사이트 운영자와 개발자에게 남는 질문은 꽤 현실적임
  - 봇 방어를 위해 reCAPTCHA를 붙였는데, 개인정보에 민감한 사용자를 배제해도 괜찮은가
  - 인증 통과 조건이 특정 벤더의 독점 런타임에 묶이는 걸 웹의 기본값으로 받아들일 수 있는가
  - “보안 솔루션 선택”이 곧 “접근 가능한 사용자 범위 선택”이 되는 순간임

---

## 기술 맥락

- reCAPTCHA 같은 봇 방어 시스템은 원래 웹사이트와 사용자 사이에서 위험도를 판단하는 보조 장치였어요. 그런데 이번 변경처럼 검증 통과가 Google Play Services에 묶이면, 웹 표준 기능이라기보다 특정 플랫폼 런타임에 의존하는 인증 흐름이 돼요.

- 안드로이드에서 Play Services는 단순 앱 하나가 아니라 백그라운드 프레임워크에 가까워요. 앱 인증, 푸시, 위치, 계정 같은 기능을 구글 서버와 연결하거든요. 탈구글 사용자가 이걸 제거하는 이유도 바로 그 데이터 흐름을 줄이려는 거예요.

- 개발자 입장에서는 reCAPTCHA를 붙이는 순간 사용자 검증 로직 일부를 구글 정책에 위임하게 돼요. 이게 편하긴 하지만, 어떤 기기와 브라우저를 정상 사용자로 볼지도 같이 위임하는 셈이라 리스크가 있어요.

- 특히 이번 사례는 iOS에서는 추가 구글 앱 없이 통과되는데 안드로이드에서는 Play Services를 요구한다는 점이 커요. 같은 사람 검증인데 플랫폼별 조건이 다르면, 보안 설계인지 생태계 통제인지 따져볼 수밖에 없어요.

## 핵심 포인트

- 차세대 reCAPTCHA가 의심스러운 사용자를 검증할 때 QR 코드 스캔을 요구하고, 안드로이드에서는 Google Play Services가 필요함
- GrapheneOS 등 Google 소프트웨어를 제거한 커스텀 롬 사용자는 검증에 실패할 수 있음
- iOS 16.4 이상은 추가 Google 앱 없이 통과해 안드로이드에만 비대칭 요구가 걸린 셈
- 웹 개발자가 이 reCAPTCHA를 도입하면 탈구글 안드로이드 사용자를 사실상 배제할 수 있음

## 인사이트

웹 보안 도구가 특정 벤더 런타임을 사실상 필수 조건으로 만들면, 그건 단순한 봇 방어를 넘어 접근성 정책이 돼버려. 개발자가 “그냥 reCAPTCHA 붙이자”라고 넘길 문제가 아니게 됐어.