소셜 리스닝 툴로 부정 버즈와 단순 불만을 구분하는 임계치(threshold) 설정법

같은 부정 문장이라도 성격이 다릅니다. 단순 불만은 "배송이 늦어요"처럼 특정 고객의 개별 문제이고, 해결되면 끝납니다. 부정 버즈는 그 불만이 제3자를 향해 발신되고 다른 사람의 구매 판단에 쓰이기 시작한 상태입니다. 전자는 CS의 일이고 후자는 평판 관리의 일이라, 같은 임계치로 묶으면 어느 쪽도 제때 처리되지 않습니다.

실무에서 쓸 만한 구분 축은 네 가지입니다. 요구 대상이 브랜드인가 다른 소비자인가, 내용이 감정 표현인가 검증 가능한 사실 주장인가, 확산이 한 채널에 머무는가 옮겨붙는가, 그리고 작성자가 서로 다른 사람인가 소수가 반복하는가입니다. 부정 리뷰 대응의 기본이 공감·사실 확인·해결책 제시 3단계라는 원칙은 앞의 두 축을 나눈 뒤에야 적용할 수 있습니다.

"부정 언급 하루 50건 이상이면 경보"처럼 절대값으로 잡은 규칙은 곧 무력해집니다. 커뮤니티와 SNS는 요일별 게시량 차이가 크고, 브랜드 인지도가 오르면 평시 언급량 자체가 올라가며, 자사 캠페인을 집행하면 긍부정과 무관하게 언급이 늘어납니다. 절대값 규칙은 이 세 가지를 전부 위기로 읽습니다.

경보가 상시로 울리면 담당자는 알림을 끄고, 그다음 진짜 신호를 놓칩니다. 임계치의 목적은 많이 잡는 것이 아니라 사람이 확인할 수 있는 양만 남기는 것입니다. 그래서 기준은 "몇 건"이 아니라 "평소 우리 수준에서 얼마나 벗어났는가"로 정의해야 합니다.

품질관리에서 쓰는 관리도의 발상을 빌리면 정리가 쉽습니다. 관리도는 표본 평균을 나타내는 중심선과, 중심선에서 상하로 표준편차의 3배 위치에 그은 관리상한·관리하한으로 구성되며, 점들이 그 안에 무작위로 찍히면 안정된 상태로 봅니다. 소셜 버즈에 옮기면 최소 4주치 데이터로 요일별 중심선과 표준편차를 구하고, 그 밖으로 벗어난 날만 확인 대상으로 올리는 구조가 됩니다.

다만 그대로 옮기면 오탐이 많습니다. 관리도는 안정된 공정과 독립 표본을 전제로 하는데 소셜 데이터는 정규분포를 따르지 않고 한 사건이 여러 게시물을 연쇄로 만듭니다. 실무에서는 요일별로 기준선을 따로 잡고, 편차가 큰 지표는 로그를 취해 안정화하며, 3배가 너무 둔하면 2배로 낮춰 시험 운영한 뒤 오탐 이력을 보고 조정합니다. 처음부터 정답을 맞히려 하지 말고 분기마다 한 항목씩 조정하는 편이 빠릅니다.

상용 툴과 API가 주는 긍부정 분류는 출발점이지 결론이 아닙니다. 구글 클라우드 Natural Language API의 감성 분석은 문서 감성을 score(감정의 방향, 양수는 긍정·음수는 부정)와 magnitude(감정 표현의 강도) 두 수치로 표현합니다. 이 구분이 실무에서 중요한 이유는, 약한 부정이 대량으로 쌓인 상태와 강한 부정이 소수 있는 상태가 전혀 다른 대응을 필요로 하기 때문입니다.

한국어에서는 오분류가 더 잦습니다. 반어("참 친절하시네요"), 업종 은어, 제품명이 형태소로 잘못 쪼개지는 문제가 겹칩니다. 한국어 형태소 분석기를 모아둔 KoNLPy로 자사 제품명·업종어 사전을 따로 만들어 두면 분해 오류를 줄일 수 있습니다. 그래도 남는 오분류를 감안해, 임계치를 감성 점수 단독으로 세우지 말고 언급량 편차와 사실 주장 포함 여부를 함께 조건으로 걸어야 합니다.

자동화해도 안전한 영역은 관측과 보존입니다. 임계치 초과 시 담당자 알림 발송, 해당 시점 게시물의 URL·작성자 표시명·작성일시·본문·댓글 캡처 자동 저장, 채널별 언급량 스냅샷 기록까지는 기계가 하는 편이 정확합니다. 증거는 나중에 삭제될 수 있어 초기 수집이 늦으면 복구가 어렵습니다.

자동화하면 안 되는 영역은 판단과 발신입니다. 자동 답글, 자동 신고, 자동 삭제 요청은 사실 관계가 확인되기 전에 브랜드 입장을 확정해 버리고, 사실에 근거한 부정 리뷰까지 건드리면 별도의 법적 문제로 넘어갑니다. 삭제·신고 대상은 명백한 허위·악성으로 한정하고, 그 판단은 사람이 근거를 남기며 하는 절차로 두는 편이 안전합니다.