---
title: "구글 클라우드 사기 방어, 사실상 폐기됐던 웹 환경 무결성의 재포장이라는 비판"
published: 2026-05-08T13:56:10.000Z
canonical: https://jeff.news/article/2528
---
# 구글 클라우드 사기 방어, 사실상 폐기됐던 웹 환경 무결성의 재포장이라는 비판

Private Captcha는 Google Cloud Fraud Defense가 2023년 반발로 철회된 웹 환경 무결성(WEI)의 핵심 메커니즘을 상용 제품으로 되살린 것이라고 비판한다. QR 코드 챌린지는 봇을 막기보다 기기 인증을 웹 접근 조건으로 만들고, 프라이버시 브라우저와 커스텀 안드로이드 사용자를 배제할 수 있다는 주장이다.

## 이 글의 주장은 간단함. “QR CAPTCHA가 아니라 웹용 기기 인증이다”

- Google은 2026년 5월 Google Cloud Fraud Defense를 발표함
  - reCAPTCHA의 다음 진화라고 소개됨
  - 사용자가 웹사이트에서 QR 코드를 보고, 휴대폰으로 스캔해 인간 존재를 증명하는 방식

- 글쓴이는 이걸 2023년에 폐기된 Web Environment Integrity, 줄여서 WEI의 재포장이라고 봄
  - WEI는 브라우저가 기기 하드웨어에 암호학적 증명을 요청해 “변조되지 않은 브라우저와 인증된 하드웨어에서 실행 중”임을 웹사이트에 알려주는 제안이었음
  - 웹사이트는 이 서명을 보고 콘텐츠를 그냥 보여줄지, 추가 챌린지를 걸지 결정할 수 있었음

- 당시 반발은 꽤 강했음
  - Mozilla는 이 제안이 사용자 이익에 반하고, 운영체제와 기기 벤더가 통제하는 게이트형 인터넷을 만든다고 비판함
  - EFF는 이를 “웹을 DRM화하려는 Chrome의 계획”이라고 불렀음
  - Google은 제안 공개 3주 뒤 WEI를 철회함

> [!IMPORTANT]
> 글쓴이가 문제 삼는 건 QR 코드 자체가 아님. 핵심은 웹 접근 권한을 Google Play Services와 인증된 기기 생태계가 사실상 판정하게 되는 구조임.

## Fraud Defense의 요구 조건에서 중요한 단어는 ‘Google Play Services’임

- Google Cloud Fraud Defense 요구사항에는 최신 Android 기기와 Google Play Services, 또는 최신 iPhone/iPad가 언급됨
  - 여기서 Google Play Services는 단순 앱 번들이 아니라 Google의 폐쇄형 소프트웨어 계층
  - Play Integrity API를 통해 기기가 변조되지 않았고 Google이 승인한 환경인지 증명하는 역할을 함

- 글쓴이는 이게 기술적 우회가 가능한 빈칸이 아니라, 제품의 핵심 메커니즘이라고 지적함
  - Google Play Services가 없는 기기는 Fraud Defense가 요구하는 수준의 Play Integrity 검사를 통과할 수 없음
  - 즉 “사람인가?”를 묻는 척하지만 실제로는 “Google이 인증한 기기인가?”를 묻게 된다는 주장

- WEI 때는 공개 표준 논의라도 있었지만, 이번에는 상용 제품으로 바로 나왔다는 점도 비판 포인트임
  - Chromium 제안은 공개 반박과 철회 과정을 거쳤음
  - Fraud Defense는 Google Cloud 과금 계정이 있는 조직이 쓸 수 있는 제품으로 출시됨

## 봇 방어 효과도 생각보다 약하다는 주장

- QR 챌린지는 기계적으로 우회 가능하다고 봄
  - 봇 운영자가 화면에 뜬 QR 코드를 카메라로 찍게 만들면 됨
  - 오프더셸프 하드웨어로 자동화 가능한 영역이라는 설명

- Play Integrity 증명이 꼭 필요해도 비용 장벽이 높지 않다고 주장함
  - 글에서는 호환 안드로이드 기기 하나가 약 30달러, 정확히는 Walmart 기준 29.88달러라고 제시함
  - 전문 봇팜이 대량 구매하는 고정비로 보면 큰 방해가 아니라는 논리

- 보안 UX 측면의 부작용도 있음
  - 사용자가 웹사이트 접근을 위해 QR 코드를 스캔하는 습관을 학습하게 됨
  - 글에 인용된 사고 대응 전문가는 “HR의 Susan에게 진짜 Google CAPTCHA QR과 피싱 QR을 구분하라고 가르치는 건 현실적으로 불가능하다”고 지적함

> [!WARNING]
> 웹 로그인이나 접근 과정에서 QR 스캔을 정상 행동으로 학습시키면 피싱 캠페인이 바로 그 습관을 노릴 수 있음. 보안 기능이 사용자의 위험 행동을 훈련시키는 꼴이 될 수 있다는 얘기임.

## 앱 생태계의 기기 증명과 오픈 웹의 기기 증명은 다르다는 얘기

- Apple의 App Attestation 같은 기기·앱 증명은 이미 존재함
  - iOS 앱이 App Store를 통해 설치됐고 변조되지 않았는지 확인하는 식
  - 하지만 이건 사용자가 iPhone이라는 폐쇄형 생태계를 선택한 앱 영역의 이야기

- 글쓴이는 이를 오픈 웹에 적용하는 건 완전히 다른 문제라고 봄
  - URL 접근을 민간 기업이 인증한 하드웨어 조건에 묶는 구조가 되기 때문
  - 웹은 원래 특정 하드웨어 약관을 전제로 설계된 공간이 아니었다는 주장

- QR 인증도 자체로 새로운 건 아님
  - 에스토니아의 Smart ID처럼 은행, 정부 서비스, 건강 기록 같은 한정된 리소스에서 QR 인증을 쓰는 사례가 있음
  - 하지만 그런 경우는 사용자가 인증을 선택하고, 보호 대상 리소스와 목적이 명확함
  - Fraud Defense는 웹 운영자가 원하는 어떤 URL에도 기기 증명을 걸 수 있다는 점에서 범위가 훨씬 넓음

## 프라이버시를 중시하는 사용자가 오히려 막힐 수 있음

- Google Play Integrity는 Google Play Services를 요구함
  - GrapheneOS는 기본적으로 Play Services를 포함하지 않음
  - 샌드박스 호환 계층을 지원하긴 하지만, Fraud Defense가 요구하는 MEETS_DEVICE_INTEGRITY 수준을 만족하지 못한다고 설명함
  - LineageOS for microG 같은 프라이버시 지향 배포판도 같은 이유로 실패함

- Firefox for Android도 Google의 지원 브라우저 목록에 보이지 않는다고 지적함
  - Mozilla는 2023년 기기 증명에 반대 입장을 냈고, Firefox는 설계상 Google Play Integrity에 통합되지 않음
  - 결과적으로 프라이버시를 위해 다른 브라우저나 커스텀 운영체제를 쓰는 사용자가 봇이 아닌데도 검증 접근에서 배제될 수 있음

## 추적 문제는 더 조용하지만 더 크다

- 성공한 Fraud Defense 챌린지는 Google에 신호를 남김
  - 인증된 이 기기가, 이 사이트에, 이 시각에 접근했다는 정보가 생김
  - 기기 증명은 단순히 접근을 막거나 허용하는 게 아니라, 기기 기반 귀속 정보를 만든다는 주장

- 안정적인 하드웨어 정체성은 세션, 브라우저, 시크릿 모드를 넘어서는 식별자가 될 수 있음
  - 어떤 하드웨어가 ‘정상’인지 정하는 회사가 그 하드웨어의 웹 이동 기록까지 축적할 수 있다는 우려
  - 글쓴이는 이것을 사기 방지의 부작용이 아니라, 인증된 기기 정체성에 검증을 묶은 구조적 결과라고 봄

- 대안으로는 Proof of Work 방식 CAPTCHA를 제시함
  - 사람 한 명이 한 번 푸는 비용은 작게 유지
  - 봇팜처럼 동시 세션을 대량으로 돌리면 계산 비용이 급격히 커지는 구조
  - 하드웨어 식별자나 인증 계층 없이도 남용 비용을 올릴 수 있다는 설명

---

## 기술 맥락

- 이 논쟁의 핵심은 CAPTCHA가 불편하다는 얘기가 아니에요. 웹사이트가 사용자를 검증할 때 브라우저 행동이 아니라 기기의 인증 상태를 요구하기 시작하면, 웹 접근 권한의 기준이 바뀌기 때문이에요.

- Device attestation은 앱 보안에서는 꽤 자연스러운 도구예요. 금융 앱이 루팅된 기기나 변조된 앱을 막는 건 이해할 수 있거든요. 그런데 같은 방식을 임의의 웹 URL에 붙이면, 사용자가 어떤 운영체제와 브라우저를 쓸 수 있는지까지 간접적으로 제한하게 돼요.

- Play Integrity API가 중요한 이유도 여기에 있어요. 이 API를 통과하려면 Google Play Services와 인증된 안드로이드 환경이 사실상 필요하니, GrapheneOS나 Firefox for Android 같은 선택지가 정상 사용자임에도 불리해질 수 있어요.

- 글에서 제시한 Proof of Work 대안은 완벽한 해법이라기보다 다른 설계 철학을 보여줘요. 사용자의 기기 정체성을 묻지 않고, 요청량이 커질수록 비용을 높이는 방식이라 프라이버시와 남용 방어의 균형을 다르게 잡는 거예요.

- 한국 서비스 개발자에게도 남의 일이 아니에요. 봇 방어 솔루션을 붙일 때 통과율만 보면 안 되고, 어떤 사용자 환경을 배제하는지와 어떤 식별 신호가 외부 사업자에게 넘어가는지도 같이 봐야 해요.

## 핵심 포인트

- Google Cloud Fraud Defense는 QR 코드를 휴대폰으로 스캔해 인간 존재를 확인하는 방식으로 소개됐다
- 비판의 핵심은 QR 코드가 아니라 Google Play Services와 Play Integrity API 기반의 기기 증명이다
- GrapheneOS, LineageOS for microG, Firefox for Android 같은 프라이버시 지향 환경은 기본적으로 불리해질 수 있다
- 글은 봇 우회 비용이 약 30달러짜리 안드로이드 기기 수준이라 실효성도 낮다고 주장한다
- 성공한 챌린지는 특정 인증 기기가 특정 사이트에 접속했다는 신호를 Google에 남길 수 있다는 추적 우려도 제기된다

## 인사이트

이 글의 포인트는 CAPTCHA UX 불평이 아니라, ‘웹 접속 권한을 누가 정하느냐’의 문제다. 기기 증명이 보안 제품으로 들어오면 봇 방어와 브라우저·운영체제 통제 사이의 경계가 꽤 위험하게 흐려진다.