AI 프로덕트의 신뢰(Trust) 설계

 

AI 기능을 기획하면서 요즘 가장 자주 떠올리는 단어가 "신뢰"입니다.
정확도나 속도만큼, 혹은 그 이상으로 중요한 게 사용자가 이 AI 결과를 얼마나 믿을 수 있느냐는 문제였어요.
이번 글에서는 저희 팀이 AI 기능을 만들면서 신뢰를 어떻게 설계에 반영했는지, 그리고 그 과정에서 겪은 시행착오를 정리해보려 합니다.

 

처음엔 정확도가 높으면 신뢰도 자연스럽게 따라올 거라고 생각했습니다.
그런데 실제로는 정확도가 90%인 기능인데도 사용자가 안 믿는 경우가 있었고, 정확도가 70%대인 기능인데 사용자들이 잘 활용하는 경우도 있었어요.
차이를 들여다보니, 사용자가 "왜 이런 결과가 나왔는지"를 이해할 수 있느냐가 정확도보다 신뢰에 더 큰 영향을 주고 있었습니다.
근거를 보여줄 수 있는 기능은 정확도가 조금 낮아도 사용자가 스스로 판단해서 걸러 쓸 수 있는데, 근거가 없는 "블랙박스형" 기능은 정확도가 높아도 한 번 틀리면 신뢰가 급격히 무너지더라고요.

 

저희가 사내 문서 검색 챗봇을 만들 때 가장 신경 쓴 부분이 바로 이 근거 표시였습니다.
답변마다 참고한 문서의 제목과 링크를 같이 노출하도록 설계했는데, 이게 단순히 "출처 표기"를 넘어서 사용자가 답변을 검증할 수 있는 최소한의 장치가 됐습니다.
사용자 인터뷰에서 "답이 완벽하지 않아도 원문을 바로 확인할 수 있어서 안심된다"는 피드백을 여러 번 들었어요.
반대로 초기 버전에서 출처 없이 답변만 보여줬을 때는, 답이 맞았는데도 "이거 진짜 맞아요?"라고 되묻는 사용자가 훨씬 많았습니다.

 

모델이 확신이 낮을 때 그걸 사용자에게 그대로 보여주는 게 오히려 신뢰를 높인다는 것도 배운 부분입니다.
저희는 답변의 확신도가 일정 기준 이하일 때 "이 답변은 확실하지 않을 수 있어요, 담당자에게 직접 확인해보세요"라는 문구를 추가했어요.
처음엔 이게 사용자 경험을 해칠까 봐 걱정했는데, 오히려 반응은 긍정적이었습니다.
확신이 없을 때도 자신 있게 답하는 것보다, 모른다고 인정하는 게 장기적으로 훨씬 신뢰를 얻는 방법이라는 걸 확인했어요.

 

AI 기능은 반드시 틀리는 순간이 옵니다.
문제는 틀렸을 때 사용자가 그걸 쉽게 되돌리거나, 쉽게 신고할 수 있느냐예요.
저희는 답변마다 "도움이 안 됐어요" 버튼을 넣고, 이 피드백이 실제로 다음 개선에 반영된다는 걸 사용자에게 보여주려고 애썼습니다.
"지난달 피드백을 반영해서 이 부분을 개선했습니다"라는 식의 공지를 주기적으로 냈는데, 이게 사용자들에게 "내 피드백이 의미가 있구나"라는 인식을 심어주는 데 효과가 있었어요.
신뢰는 한 번의 완벽한 결과보다, 틀렸을 때 회사가 어떻게 반응하는지를 보고 쌓이는 것 같습니다.

 

다만 모든 걸 다 투명하게 보여주는 게 항상 좋은 건 아니었습니다.
저희가 근거 문서를 너무 많이(한 답변에 10개씩) 보여줬을 때는, 오히려 사용자가 압도돼서 아무것도 안 읽는 역효과가 났어요.
결국 근거는 가장 관련도가 높은 2~3개만 보여주고, "더 보기"로 나머지를 확인할 수 있게 바꿨습니다.
투명성도 과하면 사용자에게 부담이 된다는 걸, 이 시행착오를 겪으면서 알게 됐어요.

 

신뢰라는 건 정성적인 개념이라 측정이 어렵다고 생각했는데, 저희는 몇 가지 대리 지표로 이걸 추적하고 있습니다.
근거 링크 클릭률, "도움이 안 됐어요" 버튼 클릭 후 재사용률, 그리고 같은 질문을 반복해서 다시 묻는 비율이었어요.
이 지표들이 개선되는 걸 보면서, 신뢰라는 게 실제로 관리 가능한 대상이라는 걸 확인할 수 있었습니다.

AI 프로덕트를 기획할 때 "얼마나 정확한가"만큼 "사용자가 왜 이 결과를 믿어야 하는가"를 설계 초기부터 같이 고민해야 한다고 생각합니다.

모델 성능은 데이터 사이언티스트의 몫이지만, 신뢰를 어떻게 설계할지는 결국 기획자의 몫이더라고요.
저도 이 영역을 다루면서 아직 배우는 게 많지만, 확실한 건 신뢰는 나중에 덧붙이는 기능이 아니라 처음부터 설계에 포함돼야 하는 요소라는 점입니다.