한 SaaS 개발자가 계정 내 모든 도메인에 Cloudflare의 Bot Fight Mode를 활성화했다가 한 달 동안 API 트래픽이 중단되는 것을 발견했습니다. 이로 인해 유료 고객들이 제품의 핵심 기능을 사용할 수 없게 되었습니다.

문제는 개발자가 사용량 지표가 갑자기 평탄해지는 것을 발견했을 때 나타났습니다. 신규 가입은 계속되었지만, 활성 세션은 늘어나지 않았습니다. 몇 주간의 코드 재작성과 디버깅 끝에, 단 하나의 보안 토글이 원인임이 밝혀졌습니다. Cloudflare의 Bot Fight Mode가 SaaS 자체의 AWS Lambda 엔드포인트를 악성 봇으로 분류하여 차단하고 있었던 것입니다.

단 하나의 설정이 전체 서비스를 망가뜨린 방법

개발자의 스택은 서버 간 호출(server-to-server calls)에 의존했습니다. 내부 Lambda 함수가 정기적으로 SaaS의 공개 도메인으로 데이터를 전송했는데, 이는 현대적인 마이크로서비스 아키텍처에서 흔히 볼 수 있는 패턴입니다. Bot Fight Mode는 자동화된 스크래퍼처럼 보이는 요청에 챌린지를 부여하거나 차단하여, 콘텐츠 중심 사이트를 데이터 수집으로부터 보호합니다.

모든 존(zone)에서 이 모드를 활성화했을 때, Cloudflare는 Lambda의 아웃바운드 요청을 또 다른 자동화된 클라이언트로 취급했습니다. 요청은 애플리케이션에 도달하지 못했고, 차단이 에지(edge)에서 발생했기 때문에 SaaS의 모니터링 도구에는 아무런 오류도 나타나지 않았습니다. 트래픽이 그냥 사라져 버린 것입니다. 개발자는 Cloudflare Workers의 CPU 사용량이 급증하는 것을 보고, 자신의 백엔드가 아닌 외부 스크래퍼를 의심했습니다.

Cloudflare 로그를 자세히 살펴본 후에야 Lambda의 IP 범위를 포함하는 "Bot Fight Mode" 차단 항목을 확인할 수 있었습니다. 영향을 받은 존의 기능을 끄자 API 트래픽이 재개되었고, 사용량 지표도 정상으로 돌아왔습니다.

이 실수가 SaaS 운영자에게 중요한 이유

  • API 중심 제품에는 개방된 서버 간 채널이 필요합니다. Bot Fight Mode는 주요 트래픽이 HTML, 이미지 또는 정적 자산을 요청하는 사람(브라우저)의 요청이라고 가정합니다. API, 웹훅(webhook) 또는 내부 콜백을 노출하는 SaaS 플랫폼은 애플리케이션 계층에 가시적인 오류 코드가 전달되지 않은 채 트래픽이 제한되거나 차단될 수 있습니다.
  • 글로벌 보안 설정이 모든 워크로드에 적합한 경우는 드뭅니다. 모든 도메인에 단일 Cloudflare 설정을 적용하는 것은 모든 사이트가 동일한 위협 모델을 공유한다고 간주하는 것입니다. 콘텐츠 사이트, 포럼, SaaS 백엔드는 보안 요구 사항이 매우 다릅니다.
  • 조용한 실패(Silent failures)는 매출을 갉아먹습니다. 차단된 요청이 애플리케이션에 도달하지 않았기 때문에 개발자의 알림 시스템은 작동하지 않았습니다. 사용자 참여 지표의 하락만이 문제의 징후를 보여주었습니다. 선제적인 에지 레벨 로그 검토가 없다면 유사한 문제가 인지되지 않은 채 지속될 수 있습니다.

개발자가 같은 운명을 피하기 위해 할 수 있는 일

  1. 각 존의 트래픽 프로필을 감사하십시오. Bot Fight Mode를 활성화하기 전에 도메인이 예상하는 요청 유형(사람의 브라우저, API 호출, 웹훅 콜백 또는 내부 서비스 호출)을 목록화하십시오. 핵심 기능에 필수적인 요청이 있다면 해당 존을 "API 우선(API-first)"으로 취급하고 봇 완화 설정을 최소화하십시오.
  2. 스테이징 환경에서 변경 사항을 테스트하십시오. Cloudflare를 사용하면 단일 서브도메인이나 스테이징 존에 설정을 적용할 수 있습니다. 변경 사항을 전역으로 배포하기 전에 정당한 자동화가 여전히 작동하는지 확인하십시오.
  3. 관측성 스택(observability stack)의 일부로 에지 레벨 로그를 모니터링하십시오. Cloudflare의 방화벽 및 봇 완화 로그를 SIEM, Loki 또는 기타 집계 서비스로 스트리밍하십시오. 차단된 요청의 급증과 애플리케이션 지표의 하락을 연관 분석하여 조용한 실패를 조기에 포착하십시오.
  4. 보안 설정을 되돌릴 수 있게 만드십시오. 문서화된 롤백 계획을 유지하십시오. 새로운 규칙이 예기치 않은 동작을 유발하면, 코드 수정을 위해 시간을 투자하기 전에 먼저 해당 규칙을 비활성화하고 변경 사항을 확인하십시오.
  5. 올바른 질문을 던지십시오. "스크래퍼를 어떻게 막을 수 있을까?"라고 묻는 대신 "이 도구가 내가 직면한 특정 문제를 해결해 주는가?"라고 물으십시오. 스크래퍼를 차단하는 보안 기능이 개방형 API 액세스가 필요한 SaaS에는 적절한 답이 아닐 수 있습니다.

더 넓은 관점

Bot Fight Mode는 공격적인 크롤러로부터 정적 콘텐츠를 보호해야 하는 사이트에는 여전히 유용합니다. 단점은 적대적인 스크래퍼와 동일한 HTTP 패턴을 따르는 정당한 자동화 클라이언트를 구분하지 못한다는 점입니다.

요점

단일 Cloudflare 계정에서 여러 도메인을 관리할 때는 각 도메인을 별개의 보안 존으로 취급하십시오. 트래픽이 순수하게 사람에 의해 유도되는 경우에만 Bot Fight Mode를 활성화하십시오. API 중심의 SaaS 워크로드의 경우 설정을 꺼두거나 사용자 정의 방화벽 규칙으로 미세 조정하십시오. 클릭 한 번으로 스크래퍼를 막는 것만큼이나 효과적으로 정당한 트래픽을 차단할 수 있습니다.