챗봇 프로젝트 실패 사례 분석

 

작년에 진행했던 사내 챗봇 프로젝트 하나를 결국 접었습니다.
6개월 가까이 투입한 프로젝트라서 팀 내부에서도 아쉬움이 많았어요.
같은 실수를 반복하지 않기 위해, 그리고 비슷한 프로젝트를 준비하는 분들에게 참고가 될까 싶어서 실패 원인을 최대한 솔직하게 정리해보려고 합니다.

 

이 프로젝트는 사내 인사팀 문의를 자동으로 응대하는 챗봇이었습니다.
연차, 급여, 사내 복지 관련 문의가 인사팀 업무의 상당 부분을 차지한다는 걸 알고, 이걸 챗봇으로 자동화하면 인사팀 업무 부담을 크게 줄일 수 있을 거라고 판단했어요.
경영진 보고 때도 반응이 좋았고, "일단 만들어서 파일럿을 돌려보자"는 분위기로 빠르게 프로젝트가 시작됐습니다.
그때는 다들 6개월이면 충분할 거라고 생각했어요.

 

 

첫 번째 원인 - 문의 유형 분류가 처음부터 잘못됐다

 

프로젝트를 시작하면서 인사팀 문의 로그를 분류했는데, 이 분류 작업을 인사팀이 아니라 기획팀이 주도해서 진행했습니다.
겉보기엔 비슷한 질문이라도 실제로는 사내 규정에 따라 답이 완전히 다른 경우가 많았는데, 저희는 이 세부 차이를 모른 채 뭉뚱그려서 분류했어요.
예를 들어 "육아휴직 문의"라고 뭉쳐놨던 질문들이 실제로는 재직 기간, 고용 형태에 따라 답변이 다 달라져야 하는 문의였습니다.
이 문제를 챗봇을 절반쯤 만들고 나서야 발견했고, 시나리오를 다시 쪼개는 데 추가로 두 달이 더 들어갔습니다.
실무를 제일 잘 아는 사람이 처음부터 분류 작업에 깊게 참여했어야 했는데, 이 부분을 초반에 놓친 게 첫 번째 실수였습니다.

 

 

두 번째 원인 - 정확도에 대한 기준을 잘못 잡았다

 

저희는 "챗봇이 정답을 맞히는 비율"을 성공 지표로 잡았는데, 인사 관련 문의는 정답이 상황마다 미묘하게 달라서 "정확도 90%"라는 목표 자체가 애초에 잘못된 기준이었습니다.
개발팀은 정확도를 올리려고 계속 룰을 추가했는데, 룰이 늘어날수록 오히려 다른 케이스에서 오답이 나오는 부작용이 생겼어요.
나중에 돌이켜보면, "정답 여부"보다는 "이 답변에 대해 사용자가 추가 확인 없이 만족했는가"를 지표로 잡았어야 했습니다.
지표를 잘못 잡으니 팀 전체가 잘못된 방향으로 최적화를 반복하고 있었던 거예요.

 

 

세 번째 원인 - 이해관계자 관리가 부족했다

 

인사팀 입장에서는 이 챗봇이 "우리 일을 대신해주는 도구"가 아니라 "우리가 하던 판단을 기계가 대신하려는 시도"로 받아들여지는 지점이 있었습니다.
이 부분을 저희가 초반에 세심하게 다루지 못해서, 프로젝트 중반부터 인사팀의 협조가 눈에 띄게 줄었습니다.
답변 콘텐츠 검토 요청에 대한 회신이 계속 늦어졌고, 저희는 그 이유를 뒤늦게야 알게 됐어요.
기술적인 문제보다 이 이해관계자 관리 실패가 프로젝트 속도를 늦춘 더 큰 원인이었다고 생각합니다.

 

 

결국 저희는 파일럿 결과에서 사용자 만족도가 기대치에 크게 못 미치는 걸 확인하고, 추가 투자를 중단하기로 결정했습니다.
6개월간의 노력이 없어지는 건 아쉬웠지만, 계속 투입했다가 더 늦게 접는 것보다는 지금 멈추는 게 맞는 판단이라고 팀 전체가 동의했어요.
이 프로젝트를 접으면서 가장 크게 배운 건, "자동화할 수 있는 것"과 "자동화해야 하는 것"은 다르다는 사실이었습니다.
문의가 반복적으로 들어온다고 해서 그게 곧 자동화 대상이 되는 건 아니었어요.
답변의 맥락 의존도가 얼마나 높은지, 오답이 났을 때의 리스크가 얼마나 큰지를 먼저 따져봤어야 했습니다.

이 프로젝트가 실패라고 부르는 게 맞는지는 아직도 팀 내에서 의견이 갈립니다.
6개월 뒤에 챗봇 서비스는 못 냈지만, 저희 인사팀 문의 프로세스 자체를 다시 들여다보게 된 계기는 됐으니까요.

다만 이번 경험을 통해 다음 AI 프로젝트를 시작할 때는 반드시 실무 담당자를 초반 분류 작업부터 참여시키고, 정확도가 아닌 사용자 만족 기준으로 지표를 잡겠다는 원칙을 세웠습니다.

비슷한 프로젝트를 고민하는 분들이 있다면, 저희가 겪은 이 세 가지 원인만큼은 미리 점검해보시길 권해드리고 싶어요.