문의 폼을 열어 두면 며칠 안에 알 수 없는 영문 광고와 링크 뭉치가 쌓이기 시작합니다. 진짜 문의 한 건을 찾으려고 수십 건을 지우다 보면 결국 알림을 꺼 버리고, 그때부터 고객 문의도 같이 묻힙니다. 막는 장치는 여러 가지지만 아무거나 하나 켠다고 끝나지 않습니다.
이 글에서 확인할 것
- 스팸이 들어오는 경로가 왜 세 갈래로 나뉘는지
- 장치마다 막는 대상과 사람에게 주는 불편이 어떻게 다른지
- 폼 화면과 접수 처리 쪽에서 각각 손볼 순서
들어오는 경로는 세 갈래다
첫째는 자동 제출 프로그램입니다. 폼의 입력 칸 이름을 읽어 값을 채우고 제출 버튼을 누르는 일을 수천 개 사이트에 반복합니다. 사람이 아니기 때문에 화면에 보이지 않는 칸도 채우고, 페이지를 연 지 1초 만에 제출합니다. 가장 양이 많지만 막기도 가장 쉬운 쪽입니다.
둘째는 사람이 직접 붙여넣는 광고입니다. 대행 인력이 사이트를 돌며 준비된 문구를 복사해 넣습니다. 보안문자를 통과하고 제출 시간도 자연스러워서 자동 제출을 막는 장치로는 걸러지지 않습니다. 대신 본문에 링크가 여러 개 들어가고 연락처가 문의 내용과 맞지 않는 특징이 있습니다.
셋째는 주소를 모으는 수집기입니다. 폼을 제출하지는 않지만 페이지에 적힌 메일 주소와 전화번호를 긁어가고, 그 목록이 다시 첫째와 둘째의 재료가 됩니다. 폼만 지키고 연락처를 본문에 그대로 써 두면 이 경로가 계속 열려 있는 셈입니다.
장치는 하나가 아니라 겹쳐 쓴다
보안문자 하나로 해결하려는 경우가 많은데, 그러면 진짜 손님이 가장 먼저 불편을 겪습니다. 순서는 사람에게 보이지 않는 장치부터입니다. 화면에 표시되지 않는 빈 칸을 하나 두고 그 칸이 채워져 오면 버리는 방식, 페이지를 연 시각과 제출 시각의 차이가 몇 초 안이면 버리는 방식은 손님이 존재조차 모릅니다.
그다음이 같은 주소에서 짧은 시간에 여러 번 제출하는 것을 제한하는 장치, 본문 안의 링크 개수와 특정 문구를 세는 필터입니다. 여기까지 걸러지지 않는 것만 보안문자로 넘기면 대부분의 손님은 보안문자를 만나지 않습니다. 마지막 단계로 접수 뒤 메일 인증을 요구하는 방법이 있는데, 이는 손님 쪽 절차가 하나 늘어나므로 예약이나 견적처럼 손님도 확인을 원하는 폼에만 어울립니다.
장치별로 막는 대상과 불편을 비교하기
어떤 장치를 켤지 정할 때는 무엇을 막는지와 함께 손님이 무엇을 더 해야 하는지를 같이 봐야 합니다. 아래 표는 그 두 가지를 나란히 둔 것입니다.
| 장치 | 막는 대상 | 손님이 겪는 불편 | 먼저 켤 조건 |
|---|---|---|---|
| 숨긴 입력 칸 | 자동 제출 | 없음 | 모든 폼 |
| 제출 시간 측정 | 자동 제출 | 없음 | 모든 폼 |
| 횟수 제한 | 반복 제출 | 거의 없음 | 공용 회선 손님이 적을 때 |
| 링크·문구 필터 | 사람 광고 | 정상 문의 오탐 가능 | 거른 것을 따로 보관할 때 |
| 보안문자 | 자동 제출·일부 사람 | 클릭 한 번 이상 | 앞 장치로 부족할 때 |
| 메일 인증 | 거짓 연락처 | 메일 확인 절차 | 예약·견적 폼 |
표에서 불편이 없음으로 적힌 두 줄은 조건 없이 켭니다. 필터는 오탐이 생기므로 거른 접수를 바로 지우지 말고 따로 모아 두었다가 일주일에 한 번 훑는 편이 안전합니다.
폼 화면에서 손볼 것
입력 칸이 많을수록 자동 제출에는 유리하고 사람에게는 불리합니다. 이름, 연락처, 내용 세 칸으로 줄이고 나머지는 담당자가 회신하면서 묻는 편이 접수율도 올라갑니다. 연락처 칸은 형식을 정해 두면 아무 문자열이나 넣는 자동 제출이 상당 부분 걸러집니다.
제출 버튼을 누른 뒤 무엇이 일어나는지도 화면에 보여야 합니다. 접수되었다는 문구와 회신 예상 시점이 없으면 손님이 같은 내용을 두 번, 세 번 보내고 그것이 다시 횟수 제한에 걸립니다. 이런 흐름은 장치를 켜기 전에 폼 화면을 다시 그리는 작업에서 함께 정리하는 것이 뒤에 붙이는 것보다 간단합니다.
메일 주소와 전화번호를 본문에 글자 그대로 적어 두었다면 수집기가 계속 긁어갑니다. 이미지로 바꾸거나 클릭했을 때만 드러나게 하는 방법이 있는데, 어느 쪽이든 손님이 복사할 수 있어야 하므로 UI UX 디자인 단계에서 동선을 같이 봐야 합니다. 앱 안에 문의 화면을 두는 경우도 원칙은 같아서, 앱을 만들 때 숨긴 칸과 제출 시간 측정을 처음부터 넣어 두면 나중에 서버 쪽만 손보면 됩니다.
접수 뒤 처리 기준
걸러진 접수와 통과한 접수는 서로 다른 곳에 남겨야 합니다. 통과한 것만 담당자에게 알림이 가고, 걸러진 것은 목록으로만 보관합니다. 알림이 하루 수십 건을 넘으면 사람이 안 보게 되므로, 알림 개수 자체가 장치가 잘 작동하는지 보는 지표가 됩니다.
접수 기록에는 제출 시각, 접속 주소, 어떤 장치에 걸렸는지를 함께 남깁니다. 나중에 정상 문의가 잘못 걸러졌다는 연락이 오면 이 기록으로 원인을 찾고 필터를 고칩니다. 기록이 없으면 필터를 끄는 것 말고 할 수 있는 일이 없습니다.
점검 목록과 정리
- 숨긴 입력 칸과 제출 시간 측정이 모든 폼에 켜져 있는가
- 입력 칸이 세 개 안팎으로 줄어 있는가
- 걸러진 접수를 따로 보관하고 주 1회 확인하는가
- 접수 완료 화면에 회신 시점이 적혀 있는가
- 본문에 메일 주소가 글자 그대로 노출되어 있지 않은가
- 알림 건수를 월 단위로 기록하는가
- 보안문자는 앞 장치로 부족할 때만 켜져 있는가
스팸 대응의 목표는 스팸을 0으로 만드는 것이 아니라 담당자가 알림을 끄지 않게 하는 것입니다. 손님이 모르는 장치부터 켜고, 걸러진 것을 버리지 않고 보관하며, 알림 건수를 지표로 삼으면 그 목표는 유지됩니다.
손님에게 보이지 않는 장치부터 켜고, 보안문자는 마지막에 둔다.
