목차
- Google Cloud Fraud Defense, 정확히 어디까지 묶인 묶음인가
- 후보 셋, 묶음의 범위가 다르다
- 가격과 단가, 같은 줄에 놓이지 않는다
- 통합 비용은 위젯이 아니라 백엔드 평가에서 발생한다
- 실전 봇 방어력 — false positive와의 줄다리기
- 어떤 케이스에 어느 도구가 맞는가
Google Cloud Fraud Defense, 정확히 어디까지 묶인 묶음인가
반면, Google Cloud Fraud Defense는 reCAPTCHA Enterprise를 코어로 두고 그 위에 Account Defender(계정 탈취 탐지), Password Defender(유출 자격증명 차단), Fraud Prevention(결제 부정거래 점수)을 얹은 보호 묶음이다. 단순한 캡차 위젯이 아니라 가입·로그인·결제 단계 각각에 점수를 매기고 그 점수를 같은 평가 ID로 추적할 수 있도록 묶어 놓은 게 핵심이다.
특히, reCAPTCHA v3까지는 페이지 단위 점수만 줬다. v3 점수가 0.7 이상이어도 봇이 통과하는 케이스가 늘었고, 그 다음에 나온 게 Enterprise였다. Enterprise는 점수와 함께 reasons 필드를 같이 던져줘서 차단 사유로 분기할 수 있다는 게 컸다. Fraud Defense는 거기에 더해 동일 사용자의 행동을 가입에서 결제까지 한 시퀀스로 묶어 보는 게 추가된 형태로 보인다.
업데이트된 가격표(2026-04 시점, 출처: Google Cloud reCAPTCHA pricing 페이지)를 기준으로 보면, reCAPTCHA Enterprise는 월 1만 평가까지 무료고, 그 위로는 평가 1,000건당 1달러 정도다. Account Defender나 Fraud Prevention 같은 상위 기능은 별도 단가가 붙는다. 묶음으로 부르고 있지만 실제로는 모듈별로 켜고 끄는 SaaS 라인업에 가깝다.
후보 셋, 묶음의 범위가 다르다
같은 자리에 놓고 비교 가능한 후보는 결국 셋으로 정리된다. Cloudflare Turnstile, AWS WAF Bot Control, 그리고 Google Cloud Fraud Defense다. 이름은 비슷한 카테고리지만 보호하려는 범위가 다르다.
Turnstile은 캡차 대체에 충실하다. 사용자에게 퍼즐을 풀게 하지 않고 백그라운드 신호로만 봇 여부를 판단한다. 무료 한도가 매우 넓고, Cloudflare 인프라를 쓰지 않아도 된다. 그 대신 계정 탈취 같은 후속 분석 기능은 없다.
반면, AWS WAF Bot Control은 WAF 규칙 안에 봇 탐지 카테고리를 박아 넣은 구조다. 검색엔진, 크롤러, 스크래퍼 같은 카테고리별로 차단할 수 있고, Targeted Bots 옵션을 켜면 자바스크립트 챌린지와 디바이스 핑거프린팅까지 들어간다. WAF에 익숙한 팀이 보기엔 새로 도입할 게 거의 없다.
Google Cloud Fraud Defense는 위 둘과 비교하면 가장 무겁다. 캡차 점수만 받는 게 아니라 동일 사용자의 가입~로그인~결제 흐름을 같은 평가 ID로 묶어 본다. 그래서 ‘로그인은 통과시켰지만 결제는 막아야 하는’ 케이스에 강하다. 반대로 단순히 댓글 폼 봇만 막을 거면 과한 도구다.
가격과 단가, 같은 줄에 놓이지 않는다
가격은 평가 1건당 단가로 비교하지만 묶음 범위가 다르므로 단가 자체가 동일선상에 놓이지 않는다. 작성 시점(2026-04 기준) 단가만 정리하면 아래와 같다.
| 항목 | reCAPTCHA Enterprise (Fraud Defense 코어) | Cloudflare Turnstile | AWS WAF Bot Control |
|---|---|---|---|
| 무료 한도 | 월 10,000 평가 | 사실상 무제한(공식: 무료) | 없음(WAF 요금 별도) |
| 기본 단가 | 평가 1,000건당 약 $1.0 | 무료 | 월 $10 + 1M 요청당 $1 |
| 상위 기능 | Account Defender 등 별도 단가 | 없음 | Targeted Bots는 1M당 $10 추가 |
| 통합 부담 | JS SDK + 백엔드 평가 호출 | JS 스니펫만 | WAF 규칙에서 토글 |
한편, 표만 보면 Cloudflare가 압도적이지만 정확히 같은 일을 하지는 않는다. Turnstile은 ‘이 요청이 봇인지 아닌지’만 답한다. Fraud Defense는 ‘이 사용자가 동일인이고 지금 결제하려는 카드 패턴이 위험한지’까지 답한다. 같은 가격대로 단순 비교할 수 없는 이유가 여기 있다.
월 100만 평가 기준으로 환산해 보면 차이가 더 분명해진다. Turnstile은 0달러, Bot Control(Common Bots만)은 약 1,010달러, reCAPTCHA Enterprise 코어는 무료 한도를 빼면 약 990달러 수준이다. Account Defender나 Fraud Prevention을 같이 켜면 그 위로 단가가 더 붙는다. 가격만 놓고 보면 Bot Control과 Fraud Defense가 비슷한 자리에 들어온다.
통합 비용은 위젯이 아니라 백엔드 평가에서 발생한다
Cloudflare Turnstile은 위젯 한 줄로 끝난다. HTML에 div 하나 넣고 토큰을 백엔드에서 검증하면 된다. 추가 SDK가 없고 의존성이 거의 들어오지 않는다. 도입 자체는 반나절도 안 걸린다는 평가가 많다.
반면, AWS WAF Bot Control은 WAF가 이미 깔려 있어야 의미가 있다. WAF 룰셋 하나 추가하는 작업이라 인프라 변경이 적은 편이다. Targeted Bots를 켜면 클라이언트 측 자바스크립트가 자동으로 주입되는데, SPA에서는 해당 스크립트가 의도대로 로드되는지 별도 확인이 필요하다(공식 문서 ‘JavaScript SDK integration’ 항목, 2025-10 업데이트).
반면, Google Cloud Fraud Defense는 결이 조금 다른 작업이 들어간다. 클라이언트에서 reCAPTCHA Enterprise 토큰을 발급받는 것까지는 같지만, 백엔드에서 createAssessment API를 호출해 점수와 reasons를 받고, 그 결과를 자체 차단 정책에 매핑하는 단계가 추가된다. Account Defender를 같이 쓰면 accountId(또는 hashedAccountId)를 함께 넘겨야 사용자 단위 추적이 동작한다.
# Fraud Defense 코어인 reCAPTCHA Enterprise 평가 호출 예시
# 점수만 받지 말고 reasons까지 분기에 같이 쓰는 게 핵심
from google.cloud import recaptchaenterprise_v1
def assess(token: str, action: str, account_id: str):
client = recaptchaenterprise_v1.RecaptchaEnterpriseServiceClient()
event = recaptchaenterprise_v1.Event(
token=token,
site_key="6Lxxx",
expected_action=action,
user_info=recaptchaenterprise_v1.UserInfo(
account_id=account_id, # Account Defender 활성화 시 필요
),
)
assessment = recaptchaenterprise_v1.Assessment(event=event)
response = client.create_assessment(
parent="projects/your-project",
assessment=assessment,
)
# 점수만 보지 말고 reasons까지 같이 본다
return response.risk_analysis.score, list(response.risk_analysis.reasons)
한편, 이 코드 자체는 어렵지 않다. 운영에서 부담이 생기는 건 점수와 reasons를 어떤 임계값에서 어떤 액션으로 매핑할지 정책을 정하는 단계다. 가입은 0.5에서 막을 건지, 결제는 0.3에서 추가 인증을 띄울 건지, 같은 사용자에 대한 과거 평가는 며칠치를 합쳐 볼 건지. 이 결정이 false positive 양을 좌우한다.
실전 봇 방어력 — false positive와의 줄다리기
세 도구 모두 ‘봇만 100% 차단하고 사람만 100% 통과시키는’ 모드는 없다. 어디서 자르느냐의 문제로 보인다. 일반 가입 폼에 셋을 동시에 붙여 비교한 사례가 종종 공개되는데(Cloudflare 블로그 2025-11 게시글, AWS Security Blog 2025-09 게시글에서 비슷한 비교가 나온다), 패턴은 대체로 비슷하다.
반면, Turnstile은 정상 사용자 차단률이 가장 낮은 편으로 알려져 있다. 무료에 도입 부담이 작은 이유가 여기 있다. 다만 정교한 헤드리스 브라우저 봇에는 비교적 약하다는 보고가 반복된다. 광고 클릭 봇이나 단순 스크래퍼 차단에는 충분하지만, 크리덴셜 스터핑까지 노리는 공격자는 통과시키는 경우가 있다.
따라서, AWS WAF Bot Control의 Common Bots(기본 카테고리)는 거의 카테고리 매칭에 가깝다. User-Agent와 IP 평판에 의존하는 비중이 크다. Targeted Bots를 켜야 자바스크립트 챌린지와 행동 분석이 들어가고, 이때 비로소 reCAPTCHA류와 비교 가능한 강도가 나온다. 가격도 그만큼 오른다.
그러나, Google Cloud Fraud Defense는 점수 자체의 정밀도보다 ‘여러 단계에 걸친 동일 행위 묶기’가 강점으로 보인다. 가입 직후 동일 디바이스에서 비정상 속도로 결제 시도가 들어오는 패턴을 잡아낸다. Account Defender의 SUSPECTED_CARDING이나 SUSPECTED_CHARGEBACK 같은 reasons가 그래서 의미를 가진다.
점수만 보면 놓치는 것
점수만 임계값으로 자르면 reasons에 들어 있는 정보를 통째로 버리게 된다. 같은 0.4 점수라도 AUTOMATION 사유는 봇 의심에 가깝고, LOW_CONFIDENCE_SCORE는 신호 부족에 가깝다. 정책에서 두 케이스를 분리해야 false positive가 줄어든다.
임계값을 어디서 시작할까
운영 시작 단계에서는 점수 단일 컷으로 차단까지 가지 않는 게 일반적이다. 0.3 이하만 즉시 차단, 0.3~0.7은 추가 인증(SMS, OTP)으로 라우팅, 0.7 이상만 그대로 통과시키는 식의 3단계 분기가 흔히 권고된다(출처: Google Cloud reCAPTCHA Enterprise best practices 문서, 2025-12 업데이트). 이 구조면 false positive를 점진적으로 좁힐 여지가 생긴다.
같은 점수, 다른 액션
같은 0.5 점수가 가입 폼에서는 통과여도 결제 폼에서는 차단이 합리적인 경우가 있다. Fraud Defense의 평가 ID는 단계별로 달라도 같은 사용자로 묶이므로, 한 번의 점수에 한 번의 액션을 거는 사고를 버리는 게 낫다. 단계별로 임계값을 다르게 두는 게 운영에서 실제로 의미 있게 작동한다.
어떤 케이스에 어느 도구가 맞는가
그러나, 같은 ‘봇 방어’라는 라벨을 달고 있어도 도구별로 잘 맞는 자리가 다르다. 비교한 내용을 케이스 단위로 정리하면 선택이 단순해진다.
따라서, 댓글 폼, 단순 스팸 가입, 콘텐츠 스크래핑처럼 ‘봇 여부’만 판단하면 되는 자리에는 Turnstile이 맞다. 무료고 도입이 빠르며 사용자 마찰이 가장 적다. 굳이 Fraud Defense를 끌어다 쓰는 건 과하다.
예를 들어, 이미 AWS 위에서 운영 중이고 WAF가 깔려 있다면 Bot Control Common Bots부터 시작하는 게 합리적이다. 추가 SDK 없이 룰 토글만으로 끝난다. 봇 트래픽 비중이 크고 Common Bots만으로 부족하다고 판단되면 Targeted Bots로 한 단계 올리면 된다. WAF 외부에 또 다른 봇 방어 레이어를 쌓는 것보다 운영 부담이 작다.
게다가, 가입~로그인~결제로 이어지는 흐름을 가진 서비스, 특히 결제 부정거래(카딩, 크리덴셜 스터핑)까지 신경 써야 한다면 Google Cloud Fraud Defense가 제 자리를 찾는다. 단가는 위 둘보다 비싸지만 동일 평가 ID로 단계 간 행동을 묶어 보는 기능을 다른 도구에서 비슷한 수준으로 재현하려면 자체 구축 비용이 들어간다.
당장 실행할 수 있는 액션은 셋이다. 첫째, 보호하려는 단계가 ‘봇 차단’인지 ‘부정 결제 차단’인지 한 줄로 정리한다. 둘째, 그 단계에 단일 도구만 붙일지 다단계로 나눌지 결정한다. 셋째, 점수 단일 컷이 아니라 reasons까지 분기에 들어가는 정책을 초안으로 작성한다. 이 셋이 정해지면 위 비교표에서 도구 하나가 자연스럽게 좁혀진다.
마지막 함정 하나만 짚으면, 단가만 보고 묶음을 비교하지 않는 게 좋다. Turnstile 무료가 매력적이라고 해서 결제 단계에 그대로 가져다 쓰면 카딩 패턴은 못 잡고, Fraud Defense를 댓글 폼에 붙이면 평가 비용만 새어나간다. 도구는 보호하려는 행위와 단계에 맞춰 골라야 단가도 의미가 생긴다.
관련 글
- 캐시 TTL jitter 설정으로 Cache Stampede 막는 실전 패턴 – TTL 만료 직후 DB에 요청이 몰리는 Thundering Herd를 막는 제일 싼 방법은 jitter 한 줄이다. Redis와 CDN 양…
- Redis 캐시 전략 비교 — LRU·LFU·allkeys로 maxmemory 다루기 – 프론트엔드에서 백엔드로 넘어온 지 2년. Redis OOM 에러를 만나고서야 maxmemory-policy를 제대로 본다. LRU와 LFU…
- Redis 캐싱 전략 실무 — Cache-Aside, Write-Through, TTL 설계까지 – Redis를 캐시로 도입할 때 흔히 저지르는 실수와 Cache-Aside, Write-Through, TTL 설계 기준을 실무 관점에서 정…