본문으로 건너뛰기
피드

구글 reCAPTCHA, 탈구글 안드로이드 사용자에게 사실상 문 걸어 잠갔다

security 약 6분
vote
0
댓글
북마크

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

  • 1

    차세대 reCAPTCHA가 의심스러운 사용자를 검증할 때 QR 코드 스캔을 요구하고, 안드로이드에서는 Google Play Services가 필요함

  • 2

    GrapheneOS 등 Google 소프트웨어를 제거한 커스텀 롬 사용자는 검증에 실패할 수 있음

  • 3

    iOS 16.4 이상은 추가 Google 앱 없이 통과해 안드로이드에만 비대칭 요구가 걸린 셈

  • 4

    웹 개발자가 이 reCAPTCHA를 도입하면 탈구글 안드로이드 사용자를 사실상 배제할 수 있음

  • 구글의 차세대 reCAPTCHA가 탈구글 안드로이드 사용자에게 사실상 장벽이 됐다는 비판이 나옴

    • 안드로이드에서 검증을 통과하려면 Google Play Services 25.41.30 이상이 필요함
    • GrapheneOS처럼 구글 소프트웨어를 제거한 커스텀 롬에서는 챌린지가 뜨는 순간 인증이 실패할 수 있음
  • 문제의 흐름은 이렇음

    • reCAPTCHA가 사용자를 수상하다고 판단하면 예전처럼 이미지 퍼즐을 던지는 대신 QR 코드 스캔을 요구함
    • 이 QR 검증은 백그라운드에서 Google Play Services가 돌고, 구글 서버와 통신해야 통과됨
    • Play Services가 없는 안드로이드 기기는 여기서 막힘
sequenceDiagram
    participant 사용자 as 탈구글 안드로이드 사용자
    participant 웹사이트 as 웹사이트
    participant 리캡차 as 리캡차
    participant 플레이 as 구글 플레이 서비스
    participant 구글 as 구글 서버
    사용자->>웹사이트: 로그인 또는 접근 시도
    웹사이트->>리캡차: 사람 여부 검증 요청
    리캡차->>사용자: QR 코드 검증 요구
    사용자->>플레이: 백그라운드 검증 시도
    플레이->>구글: 기기 및 검증 데이터 전송
    구글-->>리캡차: 검증 결과 반환
    리캡차-->>웹사이트: 통과 또는 실패 처리
  • 구글은 이 시스템을 4월 23일 Cloud Next에서 Google Cloud Fraud Defense의 일부로 소개했음
    • 자율 AI 에이전트와 전통적인 봇을 모두 다루는 신뢰 플랫폼이라는 식의 포지셔닝임
    • 그런데 실제 사용자 입장에서는 “사람임을 증명하려면 구글의 독점 프레임워크를 켜라”에 가까운 요구가 생긴 셈임

중요

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

  • 이 변화가 갑자기 튀어나온 것도 아님

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

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

⚠️주의

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

  • 탈구글 폰 사용자는 그냥 특이한 취향의 사용자가 아님

    • 이들은 Play Services가 어떤 데이터를 구글로 보내는지 보고 동의하지 않아서 다른 환경을 고른 사람들임
    • 새 reCAPTCHA는 그 결정을 기본적으로 의심스럽게 보고, 구글 소프트웨어 부재를 검증 실패 조건처럼 다룸
  • 사이트 운영자와 개발자에게 남는 질문은 꽤 현실적임

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

기술 맥락

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

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

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

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

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

댓글

댓글

댓글을 불러오는 중...

security

AI 에이전트 보안, 이제 권한이 아니라 ‘실행 증거’ 싸움으로 간다

오페이크가 AI 에이전트의 ID, 실행 환경, 도구 호출, 정책 적용 여부를 암호학적으로 검증하는 오페이크 3.0을 공개했다. 핵심은 에이전트 매니페스트와 컨피덴셜 MCP라는 두 오픈소스 기술이며, 기밀 컴퓨팅과 서명된 실행 증거를 결합해 감사자나 규제기관도 독립적으로 확인할 수 있게 하는 방향이다. AI 에이전트가 업무 시스템과 데이터를 직접 만지는 시대에는 접근 권한보다 ‘무슨 일을 했는지 증명할 수 있느냐’가 더 중요해지고 있다.

security

취약점 제보가 더 이상 특별하지 않은 시대가 왔다

전 Go 보안팀 리드였던 필리포 발소르다가 LLM 이후 취약점 제보의 의미가 바뀌었다고 주장한다. 예전에는 희소한 통찰과 비공개 제보가 귀했지만, 이제는 잠재 취약점을 찾는 것보다 실제 영향도를 빠르게 가려내는 triage가 병목이라는 얘기다.

security

스패로우, AI가 만든 코드 취약점 잡는 ‘Sparrow MCP’ 출시

스패로우가 AI 코딩 에이전트가 생성한 코드의 보안 취약점과 사용된 오픈소스를 실시간으로 검사하는 보안 어시스턴트 ‘Sparrow MCP’를 출시했다. 핵심 기능은 취약점 분석과 소프트웨어 자재명세서(SBOM) 생성이며, 앤트로픽의 모델 컨텍스트 프로토콜(MCP)을 지원하는 AI와 연결할 수 있다는 점이다. AI 코딩이 빨라질수록 보안 검증과 오픈소스 추적이 개발 파이프라인 안으로 더 깊게 들어오는 흐름이다.

security

오픈AI, 오픈소스 취약점 고치는 ‘패치 더 플래닛’ 시작

오픈AI가 트레일 오브 비츠와 함께 주요 오픈소스 프로젝트의 취약점을 AI로 찾고, 사람 검토를 거쳐 실제 패치까지 연결하는 프로그램을 시작했다. 파이썬, 고, cURL, 시그스토어, NATS 서버 같은 핵심 프로젝트가 초기 대상이고, 지금까지 수백 건의 보안 이슈와 수십 건의 병합된 패치가 나왔다. 핵심은 AI가 보안팀을 대체하는 게 아니라, 탐지·검증·패치·공개 조율을 빠르게 만드는 보조 엔진이라는 점이다.

security

오픈AI, 취약점 찾기부터 패치까지 돕는 ‘코덱스 시큐리티’ 공개

오픈AI가 사이버보안 이니셔티브 데이브레이크를 확대하면서 보안 전용 도구 코덱스 시큐리티와 GPT-5.5-사이버를 공개했다. 목표는 취약점 탐지에서 끝나는 게 아니라 검증, 위험도 평가, 패치 개발, 테스트, 배포까지 AI로 지원하는 것이다. cURL, Go, Python, Sigstore 등 30개 이상 오픈소스 프로젝트도 패치 지원 프로그램에 참여한다.