리뷰 스팸을 AI로 감시할 때 가장 먼저 정해야 할 것은 어떤 모델을 사용할지가 아니다. 더 중요한 질문은 이것이다.

AI가 의심스럽다고 판단한 리뷰를 바로 삭제할 것인가, 아니면 사람이 검토할 수 있도록 큐에 넣을 것인가?

내 기록과 현재 리뷰 관리 흐름을 돌아보면 답은 분명하다. AI는 감시자와 분류자로는 유용하지만, 최종 처분자로 두기에는 아직 위험하다. 특히 리뷰는 단순한 텍스트가 아니라 구매 경험, 판매자 평판, 고객 신뢰, 분쟁 가능성이 함께 담긴 운영 데이터이기 때문이다.

그래서 리뷰 스팸 감시의 기본 원칙은 다음과 같아야 한다.

AI는 먼저 분류하고, 시스템은 기록하며, 사람은 최종 판단한다.

리뷰 스팸 판정은 이진값이 아니다

처음에는 리뷰 스팸 판정을 정상 또는 스팸이라는 두 가지 값으로만 생각하기 쉽다. 하지만 실제 운영에서는 최소한 다음 상태가 필요하다.

  • 미검사

  • 정상으로 판정됨

  • 검토 필요로 분류됨

  • 사람이 검토한 결과 문제가 없음

  • 운영자가 최종 조치함

현재 리뷰 흐름도 ReviewModerationStatus enum을 기반으로 판정 상태를 분리하고 있다. AI가 정상으로 본 리뷰는 Clean으로 기록되고, 의심 리뷰는 Flagged 상태로 관리자 화면에 표시된다. 운영자가 확인한 뒤에는 해당 플래그를 해제할 수 있다.

이 구조의 핵심은 AI의 판정과 사람의 최종 판단을 같은 것으로 취급하지 않는 데 있다.

AI가 “스팸 같다”고 말한 것과 실제로 삭제해야 한다는 것은 서로 다른 판단이다.

자동 삭제가 위험한 세 가지 이유

1. 오탐은 고객 신뢰를 직접 훼손한다

정상적인 리뷰가 스팸으로 분류될 수 있다.

예를 들어 다음과 같은 리뷰를 생각해 보자.

  • 같은 책을 여러 권 구매한 고객의 반복적인 리뷰

  • 짧지만 실제 경험을 담은 리뷰

  • 특정 표현을 여러 번 사용한 어린이 또는 보호자의 리뷰

  • 외부 링크처럼 보이지만 실제로는 책 제목이나 작가명을 언급한 내용

AI는 문맥과 운영 정책을 완벽하게 이해하지 못한다. 정상 리뷰를 삭제하면 작성자는 자신의 의견이 사라졌다고 느낄 수 있고, 다른 고객은 리뷰 시스템을 신뢰하지 않게 된다.

스팸을 하나 놓치는 비용보다 정상 고객의 리뷰를 잘못 지우는 비용이 더 클 수 있는 이유다.

2. 리뷰 삭제는 되돌리기 어려운 운영 결정이다

자동 삭제는 단순한 데이터 정리가 아니다.

리뷰에는 다음 정보가 함께 들어 있다.

  • 고객의 실제 사용 경험

  • 상품에 대한 품질 피드백

  • CS나 환불 분쟁의 참고 자료

  • 향후 스팸 판정 규칙을 개선하기 위한 학습 데이터

  • 운영자가 판단한 근거와 처리 이력

삭제해 버리면 이후에 “왜 삭제되었는가”를 재검토하기 어렵다. 반면 검토 큐에 보관하면 운영자는 원문과 AI의 사유를 확인하고, 판단을 수정하거나 정책을 개선할 수 있다.

따라서 리뷰 스팸 감시에서는 삭제보다 보류가 안전한 기본값이다.

3. AI 자체의 실패도 반드시 고려해야 한다

AI 서비스가 항상 정상적으로 응답한다는 보장은 없다.

  • API 키가 잘못 설정될 수 있다.

  • 네트워크 요청이 실패할 수 있다.

  • 응답이 JSON 형식이 아닐 수 있다.

  • 모델이 예상하지 못한 문장을 반환할 수 있다.

  • 응답 형식은 맞지만 내용이 모호할 수 있다.

이때 AI 응답을 해석하지 못했다고 해서 해당 리뷰를 정상으로 통과시키는 것도 위험하고, 반대로 자동 삭제하는 것도 위험하다.

현재 ReviewSpamScreener는 이 상황을 보수적으로 처리한다. AI 응답을 해석할 수 없으면 정상으로 넘기지 않고 Flagged 상태로 올리며, “AI 판정 결과를 해석하지 못했습니다 — 직접 확인이 필요합니다.”라는 사유를 남긴다.

이것은 중요한 운영 원칙이다.

판단할 수 없는 상태를 정상으로 간주하지 않되, 삭제로 확대하지도 않는다.

검토 큐가 먼저인 운영 흐름

안전한 리뷰 스팸 감시는 다음과 같은 순서로 동작해야 한다.

리뷰 작성
  ↓
미검사 상태로 저장
  ↓
AI가 내용과 평점을 분류
  ↓
판정 결과와 사유 기록
  ↓
의심 리뷰만 관리자 검토 큐에 표시
  ↓
사람이 원문·평점·문맥 확인
  ↓
플래그 해제 또는 운영 조치

여기서 중요한 점은 AI가 리뷰 원문을 삭제하지 않는다는 것이다. AI는 리뷰의 상태와 검토 사유를 기록할 뿐이다.

관리자는 다음을 함께 확인할 수 있어야 한다.

  • 리뷰 원문

  • 별점

  • 작성자와 구매 맥락

  • AI가 제시한 사유

  • 판정 시각

  • 이전 검토 및 조치 이력

이렇게 해야 운영자는 모델의 결론을 그대로 받아들이는 것이 아니라, 판단의 근거를 검토할 수 있다.

AI 응답이 이상하면 검토 큐로 보낸다

AI 응답 형식도 운영 규칙에 포함해야 한다.

현재 흐름에서는 AI에게 JSON 형태로 응답하도록 요청하지만, 코드 펜스가 붙거나 주변에 다른 문장이 포함되는 상황까지 고려해 응답을 파싱한다. 그래도 다음 조건을 만족하지 못하면 검토 대상으로 분류한다.

  • JSON 객체를 찾을 수 없음

  • spam 필드가 없음

  • spam 값이 boolean이 아님

  • 사유를 신뢰할 수 있는 형태로 추출할 수 없음

이 원칙은 AI를 신뢰하지 말자는 뜻이 아니다. AI를 시스템 안에서 통제 가능한 구성요소로 사용하자는 뜻이다.

모델이 정해진 형식을 지키지 않았을 때 시스템이 조용히 정상 처리하면, 운영자는 실제로 무슨 일이 있었는지 알 수 없다. 반대로 검토 큐에 올리면 실패 자체가 운영자가 확인할 수 있는 신호가 된다.

배치 처리도 멈출 줄 알아야 한다

리뷰를 한 건씩 처리하지 않고 배치로 검사할 때는 실패 이후의 동작도 중요하다.

현재 배치 처리 방식은 다음과 같다.

  • 오래된 미검사 리뷰부터 처리한다.

  • 한 건씩 AI 판정을 수행하고 즉시 결과를 기록한다.

  • API 오류가 발생하면 그 지점에서 중단한다.

  • 아직 처리하지 않은 리뷰는 미검사 상태로 남긴다.

  • 다음 실행에서 남은 리뷰를 다시 처리한다.

이 방식은 일부 리뷰만 처리된 상태를 명확하게 남긴다. API 오류가 났는데도 나머지 리뷰를 억지로 정상 처리하거나, 오류가 난 리뷰를 삭제 대상으로 취급하지 않는다.

운영 자동화에서 중요한 것은 “끝까지 실행하는 것”이 아니다.

실패했을 때 어디까지 처리되었고, 무엇이 남았는지 알 수 있는 것이 더 중요하다.

검토 큐는 AI의 약점을 보완하는 장치다

검토 큐는 단순히 사람이 귀찮은 일을 대신하는 장소가 아니다. AI와 운영 정책 사이의 안전장치다.

검토 큐에 쌓인 데이터를 보면 다음을 확인할 수 있다.

  • 어떤 표현에서 오탐이 자주 발생하는가

  • 특정 사용자의 반복 활동이 실제 스팸인지 정상 활동인지

  • 광고성 링크, 욕설, 도배, 경쟁 서비스 홍보 중 어떤 유형이 많은가

  • AI가 어떤 응답 형식 오류를 반복하는가

  • 운영자가 자주 플래그를 해제하는 패턴은 무엇인가

이 기록은 이후 프롬프트 개선, 정책 수정, 별도 차단 규칙 도입, 모델 교체 여부를 판단하는 근거가 된다.

자동 삭제는 결과만 남기지만, 검토 큐는 판단 과정을 남긴다.

운영 규칙은 보수적으로 시작해야 한다

리뷰 스팸 감시를 도입할 때는 다음 규칙을 기본값으로 삼는 것이 좋다.

규칙 1. AI는 삭제 권한을 갖지 않는다

AI의 역할은 Clean 또는 Flagged를 제안하는 것이다. 삭제, 비공개, 이용 제한과 같은 처분은 관리자 또는 별도 승인 흐름이 담당한다.

규칙 2. 해석 실패는 검토 대상으로 처리한다

AI가 응답하지 않았거나 응답을 해석할 수 없다면 정상 처리하지 않는다. 그렇다고 자동 삭제하지도 않는다. 원문을 보존한 채 검토 큐로 보낸다.

규칙 3. 판정 사유를 반드시 기록한다

Flagged만 저장하면 운영자는 왜 검토해야 하는지 알 수 없다. 짧더라도 AI가 제시한 사유를 함께 기록해야 한다.

규칙 4. 원문과 판정 이력을 보존한다

운영자가 잘못된 판정을 되돌릴 수 있어야 한다. 리뷰 원문, 판정 상태, 사유, 시각, 최종 처리 결과를 분리해 기록하는 것이 안전하다.

규칙 5. 배치 실패 시 미처리 상태를 유지한다

실패 이후의 리뷰를 임의로 정상 처리하지 않는다. 미검사 상태로 남겨 재시도할 수 있어야 한다.

규칙 6. 자동화 수준은 운영 데이터가 쌓인 뒤 높인다

처음부터 자동 삭제를 목표로 하지 않는다. 먼저 검토 큐를 운영하며 오탐률, 누락률, 처리 시간, 유형별 분포를 측정해야 한다.

언제 자동 조치를 고려할 수 있을까

자동 삭제를 영원히 금지해야 한다는 뜻은 아니다. 다만 자동 조치는 충분한 근거가 쌓인 뒤, 제한적인 조건에서 고려해야 한다.

예를 들면 다음과 같은 조건이 필요하다.

  • 동일한 패턴의 반복 도배

  • 명백한 악성 링크나 시스템 공격 문자열

  • 이미 운영자가 반복적으로 동일 처리한 유형

  • 원문과 판정 이력을 복구 가능하게 보존

  • 자동 조치 전후의 감사 로그 확보

  • 사용자가 이의를 제기할 수 있는 절차 마련

그 경우에도 “AI가 스팸이라고 판단했으니 삭제”가 아니라, 여러 조건을 조합한 정책 엔진으로 접근하는 편이 안전하다.

AI는 신호를 제공하고, 정책이 조치 조건을 결정하며, 예외 상황은 사람에게 돌아가야 한다.

결론: 먼저 지우지 말고, 먼저 보이게 하라

리뷰 스팸 감시에서 가장 위험한 실수는 AI의 확률적 판단을 확정적인 삭제 명령으로 바꾸는 것이다.

좋은 운영 시스템은 AI를 믿지 않는 시스템이 아니다. AI가 틀릴 수 있다는 사실을 시스템 설계에 반영한 시스템이다.

리뷰가 의심스럽다면 먼저 검토 큐에 올린다. AI 응답을 해석할 수 없다면 검토 큐에 올린다. API가 실패했다면 남은 리뷰를 보존하고 다음 실행을 기다린다. 운영자가 판단한 결과는 다시 기록해 다음 정책 개선의 근거로 삼는다.

결국 리뷰 스팸 감시의 목표는 삭제율을 높이는 것이 아니다.

고객의 정상적인 목소리는 지키면서, 운영자가 위험한 리뷰를 빠르게 발견하고 정확하게 판단하도록 돕는 것.

그래서 자동 삭제보다 검토 큐가 먼저다.