얼마 전에 팀 내부 회의에서 좀 민망한 상황이 있었습니다.
추천 모델 정확도를 12%나 개선했다고 보고했는데, 정작 사용자 만족도 조사 결과는 거의 그대로였거든요.
데이터 사이언티스트는 "지표상으로는 확실히 좋아졌는데 왜 반응이 없냐"고 물었고, 저도 딱히 명쾌한 답을 못 했습니다.
그날 이후로 몇 주간 이 문제를 계속 붙잡고 있었는데, 결국 "모델 성능"과 "사용자 경험"이 같은 방향을 보고 있지 않을 수도 있다는 결론에 도달하게 되었어요.
저희가 개선한 건 추천 알고리즘의 클릭률 예측 정확도였습니다.
숫자로는 분명히 좋아졌어요.
그런데 사용자 입장에서는 "이전보다 더 마음에 드는 추천이 나온다"고 느끼려면, 정확도뿐 아니라 다양성, 신선함, 그리고 무엇보다 응답 속도까지 같이 좋아져야 했습니다.
저희 모델은 정확도를 높이는 대신 연산량이 늘어서 응답 시간이 200ms 정도 더 걸리게 됐는데, 그 지연이 사용자에게는 "느려졌다"는 인상을 준 거였어요.
정확도 그래프만 보고 있으면 이런 부작용이 전혀 안 보입니다.
그래서 그 이후로는 모델을 배포하기 전에 반드시 "체감 응답 속도"를 별도 지표로 같이 리포트하도록 요청하게 됐습니다.
머신러닝 팀과 일하면서 배운 게 하나 있는데, 벤치마크 데이터셋에서의 성능과 실제 서비스 환경에서의 성능은 꽤 다르다는 점이었어요.
저희가 쓰던 벤치마크는 사용자 행동이 비교적 일정한 상황을 가정하고 있었는데, 실제 서비스에서는 신규 가입자, 오랜만에 돌아온 사용자, 특정 이벤트 기간의 사용자처럼 패턴이 훨씬 다양했습니다.
벤치마크에서 1위를 했던 모델 버전이 실제 A/B 테스트에서는 오히려 이전 버전보다 이탈률이 높게 나온 적도 있었어요.
그 이후로 저희 팀은 "벤치마크 성능"과 "실서비스 A/B 테스트 결과"를 반드시 같이 보고, 둘 중 하나만 좋으면 배포를 보류하는 규칙을 만들었습니다.
번거롭긴 한데, 이 규칙 덕분에 사고를 몇 번 막을 수 있었어요.
완벽한 모델을 기다리다가 아무것도 못 내놓는 경우를 여러 번 봤습니다.
저는 요즘 "이 모델이 틀렸을 때 사용자가 어떤 경험을 하는가"를 먼저 설계하고, 그 다음에 모델 성능 목표를 정하는 순서로 접근하고 있어요.
예를 들어 추천이 틀렸을 때 사용자가 쉽게 "이건 별로예요"라고 피드백을 줄 수 있는 버튼이 있으면, 모델 정확도가 완벽하지 않아도 전체 경험은 나쁘지 않게 유지됩니다.
저희는 실제로 이 버튼을 추가한 뒤로, 모델 자체는 손대지 않았는데도 사용자 만족도가 소폭 올라간 걸 확인했어요.
모델을 개선하는 것보다, 모델이 틀렸을 때의 회복 경로를 만드는 게 때로는 더 효율적인 투자라는 걸 그때 배웠습니다.
이 질문에 정답은 없지만, 저희 팀이 정한 기준은 있습니다.
사용자가 결과를 기다리는 맥락(검색, 챗봇 응답)에서는 속도를 우선하고, 사용자가 결과를 나중에 확인하는 맥락(추천 피드, 배치성 알림)에서는 정확도를 우선하기로 했어요.
이 기준을 세우고 나니 매번 "이번엔 어느 쪽을 우선할까"를 새로 논의하지 않아도 됐습니다.
물론 예외는 계속 생기지만, 기준이 있으니 예외를 다룰 때도 논의가 훨씬 빨라졌어요.
가장 크게 느낀 건, 모델 성능 지표와 사용자 경험 지표를 같은 회의에서 같이 보고하는 문화 자체가 없었다는 점이었습니다.
데이터 사이언티스트는 정확도, 재현율, F1 스코어를 이야기하고, 저는 만족도, 이탈률, 재방문율을 이야기하는데, 이 둘이 한 슬라이드에 같이 놓인 적이 거의 없었어요.
그래서 저희는 격주 리뷰 때 "모델 지표 + UX 지표"를 한 표에 나란히 놓고 보는 걸로 포맷을 바꿨습니다.
이렇게 하고 나서야 "정확도는 올랐는데 만족도는 그대로다"라는 사실을 그 자리에서 바로 확인할 수 있게 됐고, 다음 개선 방향도 훨씬 구체적으로 잡을 수 있었어요.
AI 모델을 다루는 기획자에게 가장 중요한 역량은 모델을 직접 튜닝하는 능력이 아니라, 모델 성능 숫자와 사용자 체감 사이의 간극을 계속 의심하는 태도라고 생각합니다.
숫자가 좋아졌다는 보고를 받으면 일단 반갑긴 한데, 그 다음엔 항상 "그래서 사용자는 뭘 다르게 느끼는가"를 한 번 더 물어보는 습관이 생겼어요.
이 균형을 잡는 일에 완벽한 답은 아직 못 찾았지만, 적어도 이제는 어떤 질문을 던져야 하는지는 조금 더 명확해진 것 같습니다.
'AI > AI Technology' 카테고리의 다른 글
| 챗봇 NLU 엔진 선택 기준 (오픈소스 vs 상용) (0) | 2021.05.01 |
|---|