운영 자동화와 스팸 차단 정책을 문서로 정리
목차
특정 사이트의 k2 버전 운영 정책을 한군데 정리했다. 스팸 방지부터 자동 처리까지, 장기간 운영하면서 축적된 규칙들을 docs 에 명문화한 작업이다.
왜 이런 정책 문서화가 필요했나
서비스가 커지면서 요청 폼은 피할 수 없는 골칫거리가 된다. 사용자 의견은 듣고 싶은데, 자동 제출 봇의 노이즈는 줄여야 한다. 내가 맡은 사이트도 마찬가지였다. 처음엔 기본 제약만 있었는데, 시간이 지나면서 여러 겹의 방어 계층이 생겼다. IP 기반 요청 제한, 허니팟 필드, 쿨다운 정책 등등. 문제는 이 규칙들이 코드 곳곳에 산재해 있었다는 것이다. 팀원이 와서 "요청이 안 들어와"라고 하면 어느 정책이 걸렸는지 추적하기가 난감했다.
그래서 이번엔 운영 정책을 한 문서에 정리하기로 했다. "단일 진실 공급원"이라는 아키텍처 원칙을 운영 정책에도 적용해야 한다고 생각했다.
정리한 정책들
요청 폼 스팸 차단은 다층방어다. 먼저 honeypot — 사용자에겐 보이지 않는 필드를 폼에 심어놓는다. 실제 사람은 채우지 않지만, 자동 봇은 모든 필드를 채워 제출한다. 그 필드가 채워지면 즉시 폐기한다. 저비용의 효율적인 필터다.
그 다음은 IP 제한이다. 같은 IP에서 시간당 3회, 하루 10회까지만 요청을 받는다. 짧은 시간에 대량 제출하는 패턴을 원천 차단하는 것이다. 여기에 쿨다운 로직을 더했다. 제한에 걸린 IP는 일정 시간 요청을 받지 않는다. 사람이 실수로 여러 번 클릭한 경우를 고려해서, 너무 길지는 않게 설정했다.
자동화 영역으로 넘어가면, cron 작업으로 매일 상위 35개 항목(약 8,500개 데이터)을 처리한다. 이건 자동으로 갱신되어야 하는 콘텐츠가 있다는 뜻이다. 수동으로 하면 놓치기 쉬운데, 자동화하면 일관성을 보장할 수 있다. 다만 8,500개라는 숫자 자체가 일일 배치의 한계를 보여준다. 더 큰 범위를 처리하려면 다른 아키텍처가 필요할 텐데, 현재로선 비용과 속도의 균형을 맞춘 선택이다.
클라이언트 사이드 처리로 검색과 즐겨찾기를 옮겼다. 서버 부하를 줄이는 동시에, 사용자 경험도 개선한다. 정렬이나 필터링 같은 작업은 브라우저에서 즉시 실행되므로 더 반응성 있다. 물론 큰 데이터셋에서는 메모리 관리가 중요해진다. 이 부분도 앞으로 모니터링이 필요하다.
마지막으로 "EU 쿠키 동의 미설치"라는 메모를 달았다. GDPR 때문에 필수인데, 아직 구현되지 않았다는 뜻이다. 기술 부채로 등록해두는 것만으로도 다음 우선순위 선정할 때 도움이 된다.
회고
이 작업의 본질은 "정책을 코드에서 분리해서 명문화하기"다. 문서화라고 하면 당연히 해야 할 일처럼 들리지만, 실제로는 중요한 의사결정이다.
특히 운영 정책처럼 자주 바뀌거나 팀원마다 인식이 다를 수 있는 영역에선 더욱 그렇다. 작년에는 스팸 제한을 시간당 5회로 했었나, 3회로 했었나? 이런 질문에 공식 문서가 있으면 대답이 명확해진다. 그리고 팀이 커질수록, 이런 명확함이 온보딩 시간을 크게 줄인다.
다음 번엔 이 정책들이 실제로 얼마나 효과적인지 메트릭을 추가할 생각이다. "honeypot 으로 몇 개를 필터했나", "IP 제한 때문에 정상 사용자가 차단된 경우가 몇 건인가" 같은 수치들이 있으면, 정책을 개선할 때 데이터 기반 의사결정을 할 수 있을 것 같다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.