[reinvent 2025] AWS WAF SDK로 모바일 앱의 봇 방어 수준을 한 단계 높이세요

들어가며

모바일 앱을 대상으로 한 봇 공격은 갈수록 정교해지고 있으며, 단순한 IP 차단이나 Rate Limiting만으로는 효과적인 방어가 어려워지고 있습니다. 이번 강연에서는 AWS WAF SDK를 활용한 토큰 기반 인증, 라벨 평가를 통한 세밀한 트래픽 제어, 그리고 False Positive를 최소화하는 실전 전략에 주목했습니다. 모바일 환경에서 웹과는 다른 접근이 필요한 이유와 함께, 실무에 바로 적용할 수 있는 아키텍처와 구현 패턴을 살펴보겠습니다.

세션은 200만 사용자를 보유한 스니커즈 회사의 실제 사례로 시작됩니다. 이 회사는 세 가지 심각한 봇 위협에 직면했습니다. 스크래핑(Scraping)으로 경쟁사가 가격과 재고 정보를 실시간 수집하고, 대량 계정 생성 사기로 봇이 한정판 출시 시 재고를 독점하며, 계정 탈취 공격으로 로열티 포인트를 탈취당하는 문제가 발생했습니다.

봇 방어를 설계할 때는 세 가지 Trade-offs를 고려해야 합니다.

첫째, 비용 vs 효과입니다. User-Agent만 확인하는 것은 저렴하지만 효과가 낮고, 머신러닝 모델은 효과적이지만 비용이 높습니다

둘째, 보안 vs 사용자 경험입니다. 정당한 사용자를 봇으로 오인하여 차단하는 False Positive는 직접적인 매출 손실로 이어집니다.

셋째, 사용자 여정의 각 단계(검색, 장바구니, 결제)마다 다른 수준의 정책을 적용해야 합니다.

기본 아키텍처는 모바일 클라이언트 → CloudFront(AWS WAF 적용)  → ALB → Backend 구조입니다. 여기에 AWS WAF Mobile SDK를 추가하면 클라이언트의 정당성을 검증하고 세션 개념을 만들 수 있습니다.

AWS WAF Bot Control에는 두 가지 레벨이 있습니다. Common Bot Control은 Googlebot처럼 스스로 신원을 밝히는 봇을 검증하고 올바르게 식별합니다. 단순히 User-Agent만 보는 것이 아니라 실제로 Google 소유 ASN에서 왔는지 확인합니다. Targeted Bot Control은 브라우저 자동화 도구를 사용하거나 정상 사용자처럼 위장한 정교한 봇을 탐지합니다.

토큰 메커니즘은 봇 방어의 핵심입니다. SDK가 앱 시작 시 AWS WAF에 토큰을 요청하면, WAF는 암호학적 Challenge를 반환합니다. SDK는 이를 백그라운드에서 해결하고 디바이스 지문을 생성하여 제출하면, 서명된 토큰을 받습니다. 이후 모든 API 요청에 이 토큰이 자동으로 첨부됩니다. 정당한 사용자에게는 100~200ms 정도만 소요되어 거의 느끼지 못하지만, 수천 개의 봇을 운영하는 공격자에게는 큰 리소스 부담이 됩니다.

강연자는 모바일과 웹의 근본적인 차이를 강조했습니다. 웹 브라우저는 DOM, 쿠키, JavaScript 이벤트 등 “noisy”한 환경이지만, 모바일 API는 “quiet”합니다. SDK는 가속도계, 터치 패턴, 화면 전환 같은 센서 데이터를 수집하여 실제 사람이 디바이스를 사용하는지 판단합니다. 데이터센터의 봇이 이러한 자연스러운 인간 행동을 재현하기는 극도로 어렵습니다.

라벨은 AWS WAF Bot Control의 가장 강력한 기능입니다. 단순히 “차단/허용”이 아니라 요청의 특성을 분류하여 메타데이터로 추가합니다. 주요 라벨로는 token:absent(토큰 없음), token:accepted(유효), token:rejected(변조), signal:automated_browser(자동화 브라우저), volumetric:session(비정상적 요청량) 등이 있습니다.

라벨의 진정한 힘은 커스텀 헤더로 애플리케이션에 전달할 수 있다는 점입니다. WAF 규칙에서 특정 라벨을 감지하면 차단 대신 Count 모드로 설정하고 X-WAF-Signal: scraper 같은 헤더를 추가합니다. 애플리케이션은 이 헤더를 보고 실제 $100 대신 $120의 가짜 가격을 반환할 수 있습니다. 스크래퍼는 데이터를 수집했다고 생각하지만 쓸모없는 정보만 얻은 것입니다.

Low/Medium/High Confidence 기반 차등 대응도 핵심 전략입니다. High Confidence Bot은 즉시 차단하거나 Distort 전략을 적용하고, Medium Confidence는 로그인을 강제하여 애플리케이션이 더 많은 컨텍스트(계정 생성일, 구매 이력)로 판단하게 합니다. Low Confidence는 정상 서비스를 제공하되 모니터링을 강화합니다.

로그 분석과 자동화도 소개되었습니다. WAF 로그를 S3에 저장하고, Lambda가 Athena로 의심스러운 패턴(동일 JA4 시그니처 + 다수 IP + Token reuse)을 탐지하면 자동으로 IP Set을 업데이트하거나 신규 WAF 규칙을 추가합니다.

발표자가 가장 강조한 부분은 False Positive의 위험성입니다. 정당한 고객을 차단하는 것은 직접적인 매출 손실이며, 한 번 나쁜 경험을 한 고객은 돌아오지 않습니다. 해결책은 Count 모드로 시작하는 것입니다. Bot Control을 처음 배포할 때 차단하지 말고 라벨만 기록하며 2~4주간 로그를 수집합니다. 정상 트래픽의 패턴을 파악한 후, 가장 명확한 위협(token:rejected 같은 명백한 변조)부터 점진적으로 차단을 확대합니다.

한 참석자가 “Count 모드에서 Block 모드로 전환했더니 고객 불만이 폭증했다”는 경험을 공유했는데, 원인은 공용 Wi-Fi 사용자들이 IP Reputation에 걸린 것이었습니다. 이런 문제를 피하려면 Confidence Level별 차등 대응이 필수입니다.

SDK 통합은 의외로 간단합니다. iOS는 URLSession의 네트워크 요청 처리 단계에서, Android는 OkHttp 인터셉터에서 토큰을 자동으로 헤더에 추가합니다. 대부분 몇 시간 내에 완료되며, 가장 시간이 걸리는 부분은 네트워킹 레이어 파악입니다. 403/405 에러 시 토큰을 갱신하고 자동 재시도하는 Graceful Retry 로직만 추가하면 사용자는 어떤 장애도 느끼지 못합니다.

한정판 스니커즈 출시 같은 고위험 이벤트에는 더 엄격한 정책을 적용할 수 있습니다. 토큰 필수 + 계정 생성일 30일 이상 + 과거 구매 이력 + Human 라벨(실제 터치/스크롤 패턴) 조건을 조합하면 Scalper Bot은 차단하면서도 충성 고객은 원활하게 구매할 수 있습니다.

AWS WAF SDK를 활용한 모바일 봇 방어는 사고방식의 전환을 요구합니다. “모든 봇을 차단한다”에서 “트래픽을 분류하고 신뢰도에 따라 차등 대응한다”로 진화해야 합니다.

이번 세션의 핵심 인사이트는 세 가지입니다. 

• 첫째, 모바일은 웹과 다르며 SDK를 통한 디바이스 레벨 텔레메트리 수집이 필수입니다. 

• 둘째, Silent Challenge와 백그라운드 검증으로 보안과 사용자 경험을 동시에 달성할 수 있습니다. 

• 셋째, 라벨을 활용한 동적 방어(Distort, Deceive)가 단순 차단보다 효과적입니다.

실무 적용 로드맵은 명확합니다. SDK를 통합하여 토큰을 발급하고, Bot Control을 Count 모드로 2~4주간 베이스라인을 수집합니다. 로그를 분석하여 정상 패턴을 이해한 후, 명확한 위협부터 점진적으로 차단을 확대합니다. Lambda와 Athena로 자동화를 구축하면 새로운 공격 패턴에도 신속히 대응할 수 있습니다.

David MacDonald와 Paul Le Page가 진행한 이 세션은 참석자들과의 활발한 질의응답을 통해 실전 경험이 공유된 매우 실용적인 세션이었습니다.