고객 문의 게시판에 광고가 올라오면 문제는 화면이 지저분해지는 데서 끝나지 않는다. 정상 문의가 묻히고, 담당자가 매번 삭제 작업을 하며, 고객은 이곳에 내용을 남겨도 되는지 망설이게 된다. 그렇다고 의심스러운 글을 전부 즉시 거부하면 실제 고객의 첫 문의까지 막을 수 있다. 목표는 ‘봇을 모두 없애기’가 아니라 공개 노출을 통제하면서 정상 문의가 접수되는 경로를 유지하는 것이다.
OWASP의 봇 관리·자동화 방어 가이드는 한 가지 장치에 의존하지 않고 엣지, 애플리케이션, 업무 처리 계층을 나눠 방어하도록 권한다. 고객 문의 폼에도 같은 원칙이 맞는다. 봇이 어떤 경로로 제출하는지, 담당자가 어떤 상태의 글을 보는지, 고객에게 어떤 접수 안내를 보여 줄지를 한 흐름으로 설계해야 한다.
첫 질문: 무엇을 막고 무엇을 보류할 것인가
모든 의심 신호를 즉시 삭제 기준으로 쓰지 않는다. 자동 광고에서 반복되는 문구나 대량 제출처럼 확실한 신호는 접수 단계에서 차단할 수 있다. 반면 낯선 이메일 도메인, 짧은 본문, 해외 접속 같은 약한 신호는 정상 고객에게도 나타난다. 이런 경우 공개를 보류하고 검토 대상으로 보내는 편이 안전하다. 위험 판단을 ‘허용/차단’ 두 칸으로만 만들면 오탐을 회복할 공간이 없다.
공개 게시판과 비공개 문의 접수도 구분한다. 정상 고객의 글은 접수되었음을 확인할 수 있어야 하지만, 검토 전 내용을 모두에게 즉시 보일 필요는 없다. 접수, 검토, 공개, 답변이라는 상태를 분리하면 광고가 검색엔진과 방문자에게 노출되는 일을 줄이면서도 담당자는 정상 문의를 처리할 수 있다.
요청 경로에 얇은 방어층을 여러 개 둔다
먼저 입력 길이, 필수 항목, 허용 문자와 파일 유형처럼 기본 검증을 서버에서 수행한다. 숨겨진 허니팟 필드는 단순한 자동 제출을 걸러내는 값싼 신호지만, 이를 피하는 봇에게는 약하다. 다음으로 제출 횟수를 제한한다. IP 한 개만 기준으로 하면 여러 사람이 공유하는 사무실이나 이동통신망에 불리하고, 분산된 봇에는 쉽게 우회된다. 세션, 계정, 엔드포인트, 짧은 시간의 제출 패턴을 함께 검토하되 수치는 실제 정상 문의량을 보고 정해야 한다.
추가 확인이 필요한 경우에만 사람 확인 절차를 제시할 수도 있다. 이때 화면에 위젯을 그리는 것과 서버가 제출 토큰을 검증하는 것은 다르다. 예를 들어 Cloudflare Turnstile 공식 문서는 서버 측 Siteverify 검증이 필수이고 토큰이 일회성이라고 설명한다. 다른 제품을 사용해도 핵심은 같다. 브라우저가 보내 준 ‘검증 완료’ 표시를 서버가 그대로 신뢰하지 않는다. 검증 서비스가 일시적으로 느리거나 장애일 때 정상 문의를 어떻게 안내할지도 설계한다.
본문 위험 신호를 볼 때는 대소문자, 전각 문자, 공백·기호 삽입처럼 표현이 바뀌어도 같은 의미가 되는 경우를 고려한다. 그렇다고 전화번호나 특정 단어 하나만으로 자동 삭제하면 정상적인 영업 문의까지 걸릴 수 있다. 확실한 광고 문구와 반복된 연락처, 매우 짧은 시간의 다량 제출처럼 여러 신호를 함께 보고, 약한 신호는 검토 대기열로 보낸다. 본문을 공개할 때의 HTML 이스케이프·링크 정책은 스팸 판정과 별개로 유지해야 한다. 광고가 아니더라도 악성 스크립트가 섞인 입력은 안전하게 렌더링해야 하기 때문이다.
관리자 승인 대기열은 마지막 안전망이다
자동 규칙은 새 광고 문구와 우회 표기를 영원히 따라잡지 못한다. 검토 대기열에는 접수 시각, 위험 신호, 중복 여부, 고객이 남긴 원문과 이전 처리 이력을 한눈에 볼 수 있게 한다. 담당자는 공개, 비공개 답변, 거부를 구분할 수 있어야 한다. 이력은 ‘왜 차단했는가’와 ‘오탐이었는가’를 나중에 되짚는 자료가 된다. 단, 원문과 연락처를 필요 이상 오래 저장하거나 넓게 노출하지 않도록 접근 권한과 보관 정책을 둔다.
작성자 경험도 잊지 말자. 제출이 성공했다면 ‘접수되었고 검토 후 공개될 수 있다’고 명확히 알려 준다. 모든 글이 즉시 보일 것처럼 안내하면 정상 고객이 중복 제출을 하고, 그 중복이 다시 스팸 신호로 잡힌다. 차단된 정상 문의를 찾을 수 있는 관리자 검색과 고객의 재문의 경로도 함께 마련한다.
운영자에게 오는 알림도 공개 여부와 분리한다. 접수 즉시 관리자에게 원문을 이메일로 복사하면 스팸이 메일함으로 이동할 뿐이다. 알림에는 새 검토 건수나 관리 페이지 링크를 넣고, 위험도가 높은 입력은 별도 대기열에서 다룬다. 이렇게 하면 사이트 화면뿐 아니라 담당자의 실제 업무 흐름까지 지킬 수 있다. 사용자가 삭제를 요청했을 때 게시글뿐 아니라 알림·검토 기록에 남은 개인정보를 어떻게 처리할지도 보관 정책에 포함한다.
효과는 차단 건수만으로 판단하지 않는다
스팸 차단량만 높아져도 정상 문의가 줄었다면 성공이 아니다. 공개된 광고 건수, 검토 대기 시간, 정상 문의의 접수·답변 완료율, 오탐 복구 건수를 같이 본다. 규칙을 새로 넣을 때는 일정 기간 검토 대기열에서 신호만 기록해 정상 글에 얼마나 맞는지 살피고, 확신이 높은 규칙부터 차단으로 올린다. 보안과 영업 경험을 동시에 측정해야 한다.
점검 체크리스트
- 공개 글과 접수 글의 상태를 분리했는가?
- 서버에서 필수 입력과 길이·형식을 검증하는가?
- 허니팟과 제출량 제한을 독립적인 신호로 쓰는가?
- 사람 확인 도구를 쓴다면 서버에서 토큰을 검증하는가?
- 애매한 글은 삭제 대신 검토할 수 있는가?
- 고객에게 접수 상태와 공개 시점을 설명하는가?
- 차단량과 함께 정상 문의 손실을 측정하는가?
스팸 방어는 버튼 하나를 더 붙이는 일이 아니다. 접수는 안전하게, 공개는 신중하게, 오탐은 되돌릴 수 있게 만드는 운영 설계다. 방어층을 나누면 새로운 스팸 패턴이 나타나도 게시판 전체를 잠그지 않고 대응할 수 있다.
