Google Cloud Fraud Defense, reCAPTCHA 다음 전장은 AI 에이전트 신원 검증이다

나는 보안 쪽 일을 하다 보면 로그인 페이지보다 먼저 자동화가 어디까지 사람처럼 행동할 수 있느냐를 본다. 요즘 그 질문은 더 까다로워졌다. 예전엔 사람과 봇만 나누면 됐는데, 이제는 실제 업무를 대신 수행하는 AI 에이전트가 웹에 들어온다. 그래서 Google Cloud가 Fraud Defense를 reCAPTCHA 연장선이 아니라 에이전틱 웹용 신뢰 플랫폼처럼 설명한 건, 꽤 중요한 신호다.

핵심은 간단하다. 앞으로 웹 보안은 “이 요청이 봇이냐 아니냐”만 묻지 않는다. 대신 누가, 어떤 자동화 권한으로, 어떤 단계의 사용자 여정을 건드리려 하느냐를 먼저 묻게 된다. 이 변화는 로그인, 회원가입, 결제, 쿠폰, 예약, 상담 신청 같은 모든 운영 흐름을 바꾼다.

사람·봇·AI 에이전트를 함께 분류하는 새 보안 경계

왜 reCAPTCHA만으로는 이제 부족한가

reCAPTCHA가 풀던 시대 문제는 명확했다. 대량 자동화 요청을 잡고, 폼 남용이나 단순 스팸을 줄이는 것. 그런데 AI 에이전트가 웹을 쓰기 시작하면 문제가 달라진다. 이들은 무식하게 요청을 쏘는 봇이 아니라, 실제 사람처럼 페이지를 읽고, 흐름을 따라가고, 때로는 결제나 신청까지 시도한다.

즉 지금부터는 이런 질문이 더 중요하다.

이 자동화는 단순 스크래퍼인가, 업무 대행 에이전트인가
이 주체는 로그인만 시도하는가, 결제 직전까지 들어오는가
이 요청은 사용자를 대신한 것인가, 아니면 계정 탈취/남용 흐름인가
인간 확인이 필요한 순간을 어디에 넣을 것인가

내가 보기엔 여기서부터 보안 모델이 바뀐다. 탐지의 단위가 IP나 브라우저 흔적만이 아니라, 자동화 주체의 정체성과 행동 맥락으로 이동한다. Fraud Defense가 중요한 이유도 그 지점이다.

Google Cloud Fraud Defense가 던지는 진짜 메시지

이 발표를 그냥 “reCAPTCHA 업그레이드” 정도로 읽으면 반만 본 거다. 더 중요한 건 Google이 방어 대상을 사람 vs 봇에서 사람 vs 봇 vs AI 에이전트로 넓혀 설명했다는 점이다. 이건 제품 이름보다 철학 변화가 더 크다.

실무적으로 해석하면 세 가지다.

첫째, 보안팀과 운영팀은 앞으로 트래픽 양보다 주체 분류를 먼저 보게 된다. 누가 들어왔는지, 그 주체가 어떤 자동화 성격을 갖는지, 과거 행동과 얼마나 일치하는지가 첫 화면으로 올라온다.

둘째, 정책 엔진이 중요해진다. 위험 점수 하나만 보고 차단하는 게 아니라, 자동화 유형·행동 단계·리소스 민감도에 따라 다른 규칙을 써야 한다.

셋째, 인간 개입은 사라지지 않는다. 오히려 더 전략적으로 들어간다. Google이 QR 기반 human-in-the-loop 같은 마찰 장치를 강조한 것도 같은 맥락이다. 단순 퍼즐보다 AI 자동화가 대신 통과하기 어려운 인간 개입 지점을 설계하겠다는 뜻이기 때문이다.

이건 꽤 현실적이다. 실제 서비스 운영에서는 모든 자동화를 막을 수도 없고, 그래도 안 된다. 고객 지원 에이전트, 장바구니 보조, 예약 대행, 내부 운영 봇, 브라우저 에이전트 같은 합법적 자동화도 늘어나기 때문이다. 그래서 필요한 건 blanket ban이 아니라 신뢰 등급별 허용 모델이다.

이제 웹 방어는 정책 문제다

여기서부터 운영팀이 해야 할 일은 기술 도입보다 정책 설계다. Fraud Defense 류 플랫폼이 의미가 있으려면, 서비스는 먼저 자기 여정을 위험 단계별로 쪼개야 한다.

예를 들어 이런 식이다.

signup:
  allow: human, low-risk agent-assist
  block: scripted bulk creation
  challenge: suspicious device + repeated attempts

checkout:
  allow: authenticated human
  review: agent-assisted purchase with unusual velocity
  challenge: QR human confirmation for high-risk flow

coupon-claim:
  allow: known account + normal session history
  block: multi-account automation swarm
  challenge: behavior anomaly + new device

이런 규칙이 없으면 탐지 결과가 좋아도 운영은 헷갈린다. 점수는 나오는데, 어디를 막고 어디를 통과시켜야 할지 모르는 상태가 된다. 보안 제품이 아니라 보안 운영 설계가 병목이 되는 순간이다.

나는 이 지점이 제일 중요하다고 본다. 많은 팀이 보안 도구를 사면 문제가 해결된다고 믿지만, 실제로는 서비스가 먼저 답해야 한다.

어떤 자동화는 허용할 것인가
어떤 행위는 사람 확인 없이 절대 통과시키지 않을 것인가
어떤 API/화면은 agent-assisted 사용을 지원할 것인가
신원과 권한을 어디서 분리할 것인가

결국 Fraud Defense는 기술 스택이면서 동시에 제품 정책 문서다.

위험 점수보다 중요한 것은 사용자 여정별 정책 설계

한국 서비스 운영자에게 바로 닿는 이유

한국 서비스는 보통 공격 이론보다 운영 현실이 더 먼저 온다. 회원가입 어뷰징, 쿠폰 남용, 로그인 시도, 상담 폼 스팸, 티켓팅 자동화, 재고 선점, 커머스 체크아웃 비정상 흐름 같은 문제는 이미 익숙하다. 여기에 AI 에이전트까지 붙으면 기존 룰은 더 빨리 낡는다.

예전 룰은 대략 이랬다.

headless 브라우저면 의심
요청 수가 많으면 차단
CAPTCHA 못 풀면 차단

하지만 이제는 정교한 자동화가 이 세 가지를 꽤 많이 우회한다. 그러면 운영팀은 단순 차단보다 권한을 어떻게 분절할지를 고민해야 한다.

예를 들어 상담 신청 폼이라면:

AI 에이전트가 작성 보조를 하는 것 자체는 허용할 수 있다.
하지만 실제 최종 제출 직전에는 인간 확인을 요구할 수 있다.
동일 주체가 짧은 시간에 여러 브랜드/계정으로 반복 제출하면 위험 점수를 올릴 수 있다.

전자상거래라면:

상품 탐색이나 가격 비교 자동화는 허용할 수 있다.
장바구니 점유나 결제 시도는 더 강한 신뢰 조건이 필요하다.
계정 생성, 쿠폰 적용, 결제 수단 변경은 같은 세션이라도 별도 검증 레벨로 봐야 한다.

이렇게 보면 Fraud Defense의 진짜 질문은 “AI를 막을까?”가 아니다. **어떤 자동화를 어느 권한까지 인정할까?**다.

reCAPTCHA의 다음 단계는 신원 검증 + 인간 개입 설계다

Google이 QR 기반 human-in-the-loop를 강조한 건 꽤 영리하다. 퍼즐 풀기나 이미지 선택은 이미 너무 오래된 마찰 장치다. 반면 QR 기반 확인은 인간이 직접 개입해야 하는 순간을 더 명확하게 만들 수 있다.

중요한 건 이걸 남발하면 안 된다는 점이다. 모든 요청마다 사람 개입을 요구하면 UX는 바로 죽는다. 그래서 설계는 이런 식으로 가야 한다.

평소에는 조용히 분류하고 점수를 쌓는다.
중간 위험 구간에서는 review 또는 제한 모드로 전환한다.
높은 위험 구간에서만 인간 개입을 요구한다.
인간 개입 이후에도 같은 주체의 행동 이력을 다시 학습한다.

이 흐름을 잘 짜면 사용자는 덜 귀찮고, 운영팀은 더 선명한 기준을 얻는다. 이건 AI 시대에 꽤 중요한 균형이다. 마찰을 없애는 게 목표가 아니라, 필요한 곳에만 정밀하게 넣는 것이 목표다.

AI 자동화 시대의 human-in-the-loop 보안 흐름

지금 팀이 바로 바꿔야 할 체크리스트

이 주제를 읽고 실제로 할 일은 생각보다 단순하다.

1) 사람/봇/AI 에이전트 구분을 로그 스키마에 넣기

지금 로그가 IP, UA, path, status 정도만 남기고 있으면 곧 부족해진다. 최소한 자동화 힌트, 세션 일관성, 반복 속도, 권한 단계 같은 분류 필드를 붙여야 한다.

2) 고위험 여정을 따로 분리하기

회원가입, 계정 복구, 결제, 쿠폰, 포인트, 상담 제출, 예약 확정은 다 같은 보호 수준으로 보면 안 된다. 여정별 정책 분리가 먼저다.

3) agent-assisted 사용을 허용할 범위를 결정하기

AI가 대신 읽고 추천하는 것까지는 허용할지, 실제 submit이나 purchase까지 허용할지 팀 안에서 먼저 정해야 한다. 이게 없으면 정책 엔진도 헛돈다.

4) 인간 개입 포인트를 최소하지만 확실하게 설계하기

무조건 CAPTCHA를 많이 다는 건 답이 아니다. 정말 비싼 행위 직전에만 사람 개입을 넣는 게 맞다.

5) 보안과 제품팀이 같은 문서를 봐야 한다

이건 순수 보안팀 일만도, 순수 프론트엔드 일만도 아니다. 정책은 결국 제품 흐름 위에서 동작한다. 운영, 보안, 결제, 성장팀이 같은 여정 지도를 공유해야 한다.

김덕환 운영자가 봤을 때

log8.kr 운영자 김덕환 입장에서 이 주제가 중요한 이유도 뚜렷하다. 앞으로 웹 서비스는 단순 방문자 수보다 어떤 자동화 주체가 어떤 행동까지 시도했는지를 먼저 봐야 한다. OpenClaw나 에이전트 워크플로우를 오래 만지다 보면 더 선명해진다. 자동화는 막아야 할 대상이 아니라, 식별하고 권한을 쪼개서 다뤄야 할 실행 주체가 된다. reCAPTCHA 다음 전장은 그래서 퍼즐이 아니라 신원, 정책, 그리고 인간 개입 설계다.

결론은 이거다. AI 에이전트 시대의 웹 보안은 봇 차단 기술 경쟁이 아니라, 자동화 신뢰 계약을 어떻게 쓰느냐의 경쟁이다. Google Cloud Fraud Defense가 던진 메시지는 제품 이름보다 거기에 있다.