구글 클라우드 사기 방어, 사실상 폐기됐던 웹 환경 무결성의 재포장이라는 비판

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

• Google은 2026년 5월 Google Cloud Fraud Defense를 발표함

  • reCAPTCHA의 다음 진화라고 소개됨
  • 사용자가 웹사이트에서 QR 코드를 보고, 휴대폰으로 스캔해 인간 존재를 증명하는 방식

• 글쓴이는 이걸 2023년에 폐기된 Web Environment Integrity, 줄여서 WEI의 재포장이라고 봄

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

• 당시 반발은 꽤 강했음

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

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을 구분하라고 가르치는 건 현실적으로 불가능하다”고 지적함

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

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

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