Safety와 UX 충돌: 욕설은 막아도, 버그 제보는 놓치면 안 됩니다

[AI 품질 개선 시리즈 1/3] 
Safety와 UX 충돌: 욕설은 막아도, 버그 제보는 놓치면 안 됩니다

AI 챗봇에서 Safety는 중요합니다. 다만 실무에서는 다른 문제가 생기기도 합니다. 욕설이나 강한 표현을 막는 데 집중하다 보면, 그 문장 안에 있던 실제 사용자 의도까지 함께 잘려나가는 경우가 있기 때문입니다.

예를 들어 감정이 섞인 버그 제보나 문의 접수 요청이 단순한 위험 발화로 처리되면, 사용자는 도움을 요청했는데 서비스는 표현만 본 셈이 됩니다. 실제 운영 사례에서도 욕설 필터가 먼저 작동하면서, 버그 신고나 문의 접수 같은 실질적 니즈가 초동 대응 경로로 연결되지 않는 문제가 있었습니다.

이럴 때 필요한 것은 필터를 더 세게 거는 일이 아니라, 표현과 의도를 분리해서 처리하는 구조입니다. 저는 이 사례를 통해 Safety를 단순 차단 장치가 아니라, 사용자 의도를 놓치지 않도록 경로를 다시 설계하는 문제로 보게 됐습니다. 핵심은 하나입니다. 욕설은 막아도, 버그 제보는 놓치면 안 됩니다.

1. 문제 제기 | 욕설을 막았더니, 버그 제보까지 막히는 상황

겉으로 보면 문제는 단순해 보입니다. 욕설이 있으면 필터가 작동하고, 챗봇은 더 이상 진행하지 않습니다.
그런데 실제 사용자 발화는 그렇게 단순하지 않습니다.

불만이 큰 사용자는 문제 상황을 감정적으로 표현하는 경우가 많습니다. 이때 문장 안에는 욕설이나 강한 표현이 들어가기도 하지만, 동시에 버그 제보, 문의 접수, 도움 요청 같은 실제 니즈도 함께 들어 있습니다. 문제는 기존 구조에서 Safety가 먼저 작동하면, 그 뒤에 있는 의도는 충분히 보지 못한다는 점입니다. 결과적으로 사용자는 “문제가 있으니 접수하고 싶다”고 말했는데, 서비스는 “부적절한 표현이 있으니 차단한다”로 끝나버립니다.

이 순간 Safety는 사용자를 보호하는 장치가 아니라, 사용자의 문제 해결을 막는 장치처럼 느껴질 수 있습니다.

2. 왜 생기나 | Safety가 의도 분류보다 먼저 작동할 때

이 문제는 필터 성능이 부족해서라기보다, 처리 순서 때문에 생깁니다.

기존 구조에서는 욕설이나 비속어가 포함된 입력이 들어오면 Safety가 먼저 반응했습니다. 그러면 그 안에 버그 신고나 문의 접수 의도가 있더라도, 실제 경로 분기는 충분히 이루어지지 못했습니다. 반대로 순수 욕설이나 장난처럼 접수 의도가 없는 경우는 여전히 차단해야 했습니다. 결국 핵심은 “욕설이 있느냐”가 아니라, 그 발화가 실제로 무엇을 하려는 말이냐 였습니다.

실무적으로 보면 이 차이는 꽤 중요합니다.
Safety는 표현의 위험을 다루는 장치이고, 의도 분류는 사용자의 목적을 이해하는 장치입니다. 이 둘이 한 단계에서 한 번에 처리되면, 표현의 문제와 목적의 문제가 섞여버립니다. 그리고 그 순간 챗봇은 사용자 의도를 놓치기 쉬워집니다.

3. 어떻게 풀었나 | 경고 후 정제하고, 다시 의도를 분류하는 구조

해결 방향은 생각보다 명확했습니다. Safety를 없애는 것이 아니라, 역할을 바꾸는 것입니다.
핵심은 이렇습니다.

기존 구조

  • 사용자 입력
  • Safety 차단
  • 종료

개선 구조

  • 사용자 입력
  • Safety 경고
  • 텍스트 정제
  • 의도 재분류
  • 문의/버그 제보면 초동 대응 경로로 연결

즉, 부적절한 표현에는 먼저 경고를 주되, 동시에 정제된 텍스트를 기준으로 다시 의도를 분류하는 방식입니다. 이렇게 하면 욕설은 제어하면서도, 그 안에 있던 버그 제보나 문의 접수 의도는 놓치지 않을 수 있습니다. 실제 개선안도 같은 방향이었습니다. Safety를 기존의 최종 차단 역할이 아니라 경고와 정제 단계로 두고, 이후 단계에서 정화된 텍스트 기준으로 FAQ인지 초동 대응인지 다시 분류하도록 정리했습니다. 욕설이 있어도 본질적 의도가 버그 신고나 문의 접수라면 초동 대응 경로로 진입하게 바꾼 것입니다.

여기서 중요한 점은, 해결 방식이 더 복잡한 모델을 붙이는 것이 아니라 의도 분류 기준을 현실적으로 다시 정리하는 것이었다는 점입니다. 직접적인 접수 요청뿐 아니라, 도움 요청형 표현이나 문제 상황형 표현도 실제 접수 니즈의 신호로 볼 수 있게 정리하되, 순수 욕설·장난·맥락 불명확 발화는 기존처럼 차단하는 구조가 더 적절했습니다. 모든 걸 한 번에 더 똑똑하게 만들기보다, 지금 확실히 처리할 수 있는 의도를 안정적으로 살리는 쪽이 실무적으로 더 낫다고 봤습니다.

4. 실무적 교훈 | Safety는 차단이 아니라 경로 설계의 문제다

이 사례에서 얻은 교훈은 분명했습니다.
Safety와 UX는 서로 반대편에 있는 개념이 아니라, 같은 서비스 경험 안에서 함께 설계되어야 하는 요소라는 점입니다.

Safety를 무조건 앞세우면 서비스는 안전해질 수 있습니다. 하지만 동시에 사용자의 실제 니즈를 놓칠 위험도 커집니다. 반대로 사용자 의도만 살리려 하면, 위험한 표현이나 운영 리스크를 제대로 제어하지 못할 수 있습니다. 결국 중요한 것은 둘 중 하나를 선택하는 일이 아니라, 어디서 멈추고 어디서 다시 살릴지 설계하는 일입니다.

그래서 저는 AI 챗봇의 Safety를 단순히 “위험한 표현을 막는 기술”로 보지 않습니다. 오히려 사용자의 목적을 놓치지 않도록 처리 경로를 조정하는 운영 설계 문제에 더 가깝다고 생각합니다.
좋은 챗봇은 잘 답하는 챗봇이기도 하지만, 그보다 먼저 사용자의 실제 니즈를 놓치지 않는 챗봇이어야 합니다. Safety도 그 목표 안에서 설계될 때 비로소 제대로 작동합니다.

Similar Posts

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다