봇 트래픽이 조용히 늘리는 커머스 인프라 비용

문제

커머스 사이트의 봇 트래픽은 항상 명확한 공격처럼 보이지 않습니다. 사이트가 다운되지 않고, 5xx가 폭증하지 않아도 봇은 조용히 비용을 늘릴 수 있습니다. 가격 수집, 재고 확인, 이미지 크롤링, 검색 색인, 모니터링 요청이 섞이면서 origin 요청이 늘고, 캐시 효율이 떨어지고, 실제 고객 요청과 같은 자원을 사용합니다.

운영자는 보통 장애가 나야 봇을 의심합니다. 하지만 문제는 장애 이전부터 시작됩니다. 프로모션 오픈 전후로 크롤러가 상품 상세를 반복 조회하거나, 이미지 원본을 대량 요청하거나, 캐시를 우회하는 파라미터 요청을 만들면 원본 서버는 사람 고객과 기계 요청을 구분하지 못하고 처리합니다.

봇 트래픽은 보안 문제이면서 성능 문제입니다. 사람 고객의 구매 경험을 지키려면 차단만이 아니라 분류가 필요합니다. 어떤 봇은 허용해야 하고, 어떤 봇은 캐시만 내줘도 되며, 어떤 봇은 원본 접근을 제한해야 합니다.

원인

봇 대응이 어려운 이유는 user-agent만으로 충분히 구분되지 않기 때문입니다. 정상 검색 봇도 있고, user-agent를 위장하는 봇도 있습니다. 요청 속도, 경로 패턴, 쿠키 보유 여부, JavaScript 실행 여부, 캐시 우회 여부, 실패율을 함께 봐야 합니다. 단순 차단은 정상 수집이나 제휴 트래픽까지 막을 수 있습니다.

두 번째 이유는 봇이 캐시 효율을 깨뜨릴 수 있다는 점입니다. 의미 없는 query string을 붙이거나, 다양한 경로를 짧은 시간에 순회하거나, 원본 이미지와 상세 API를 반복 요청하면 엣지 캐시가 잘 맞지 않습니다. 캐시 MISS가 늘면 origin 부하는 사람 트래픽 이상으로 커질 수 있습니다.

흔한 오해는 봇 대응이 보안팀만의 일이라는 것입니다. 실제로는 마케팅, 상품, 인프라, CDN 운영과 연결됩니다. 가격 비교나 검색 유입은 필요하지만, 매출과 무관한 반복 원본 요청은 비용입니다.

해결

내부에서 먼저 할 수 있는 것은 봇 의심 요청을 비용 관점으로 보는 것입니다. 상위 IP, user-agent, 요청 경로, query string 패턴, cache status, origin response time을 함께 봅니다. 단순 방문 수가 아니라 원본까지 도달한 요청 비중을 봐야 합니다. 캐시 HIT로 처리된 봇과 origin을 두드린 봇은 비용이 다릅니다.

정책은 세 단계로 나눌 수 있습니다. 허용해야 하는 봇은 명확히 허용하고, 반복 조회 봇은 캐시된 응답만 받도록 제한하며, 비정상 패턴은 차단합니다. 상품 상세, 이미지 원본, 검색 결과, API처럼 경로별 정책도 달라야 합니다. 모든 봇을 막는 것이 목표가 아니라 사람 고객의 리소스를 보호하는 것이 목표입니다.

M2 Live Cloud의 protectbot 관점은 봇을 전송·보안 계층에서 분류하는 것입니다. 점수와 패턴을 기준으로 원본 접근을 줄이고, 캐시 가능한 응답은 엣지에서 처리하며, 위험 요청은 제한합니다. 이렇게 하면 보안과 성능이 분리되지 않고 같은 목표, 즉 구매 경험 보호로 연결됩니다.

지금 실행

• 직접 확인: 최근 24시간 로그에서 상위 IP, user-agent, 요청 경로, cache status, origin 도달 여부를 함께 뽑으세요. 특히 상품 상세와 이미지 원본을 반복 조회하는 패턴을 확인합니다.
• 내부 조치: 정상 검색 봇, 제휴·가격 비교 트래픽, 비정상 반복 요청을 구분하는 정책 초안을 만드세요. query string으로 캐시를 우회하는 요청은 별도 규칙이 필요할 수 있습니다.
• 구조 검토: 봇 트래픽이 프로모션 피크와 겹치거나, 원본 요청 비용을 크게 만들거나, CDN 설정만으로 분류가 어렵다면 protectbot 같은 앞단 분류 계층을 검토해야 합니다. 기준은 차단 수가 아니라 고객 요청을 얼마나 보호했는가입니다.