잊지 못할 CS의 추억들
프로젝트 매니저에게 CS의 의미
서비스 담당자의
안일함이 반영된 것이 아닌가
생각 들었습니다.
추석 연휴에 받은 CS 문구 중 하나다. 이 CS(문의하기)를 보면서 변명이 아니라, 개인적으로 프로젝트 매니저에게 CS는 어떤 의미인가를 되새기는 개인적인 회고를 좀 해보고자 한다.
카카오모빌리티에서 처음 내비게이션 서비스를 맡았을 때 매일 하던 일 중 하나는 CS를 살펴보는 일이었다. CS를 전문으로 운영하는 팀이 있고, 대부분 모범 답안이 적힌 CS 매뉴얼과 이미 이슈 담당자가 지정되어 있기 때문에 내가 직접 답변을 다는 경우는 많지 않다.
굳이 개발자에게 지정된 이슈들을 PM인 나를 통해 답변이 끝나도록 프로세스를 다시 만든 이유는, 서비스를 가장 쉽게 이해할 수 있는 도구가 CS라고 생각했기 때문이다. 서비스 정책과 구조를 알아야 누가 답변을 하든 최종 이슈를 클로즈할 수 있고, 각 부문의 담당자들도 쉽게 파악할 수 있었다. 무엇보다 사용자들의 기상천외한 서비스 이용법을 가장 쉽게 아는 길이기도 했다.
사용자들의 CS 대부분은 불만이지만, 아이디어를 주기도 한다. 물론 톤&매너가 다정하지는 않지만. (화를 내고 있다...) 사용자들이 보기에는 쉬운 일들도 실제로는 구현이 엄청 어려운 경우도 있다. (가령 고가와 아래 도로가 겹치는 경우, 위치는 파악되지만 고도를 구분할 수 없어서 때로 내비게이션은 차가 경로 이탈한 것으로, 반대로 제대로 간다고 해석하기도 한다.)
CS를 통해 알게 된 어떤 이슈때문에 위험을 미리 방지할 때도 있다. 언젠가 한 경찰의 CS로 사고 지점을 지도 데이터로 파악한 적이 있다. 길안내 상 문제는 없어 보였으나, 차를 몰고 개발자와 함께 해당 지점에 직접 가보니 왕복 2차선으로 표기되어 있지만 도로 폭이 넓지 않아 유턴할 경우, 자칫 야간에는 차량 전복이 일어날 수 있는 길이었다. (이런 경찰 정말 칭찬한다.) 유턴 신호의 지점을 미세하게 조정하여 길안내를 변경했다.
이런 건 데이터로는 알 수 없다.
직접 가보지 않으면…
내비게이션은 수많은 다층의 데이터로 이루어져 있고, 도로규정과 법에 따라 길을 안내하지만, 운전자의 휴면 팩터도 고려해야 한다. 내비팀이 주기적으로 주행 테스트를 나가는 이유이기도 하다. 회식을 가면서, 워크샵을 가면서, 동료 집에 데려다 주면서도 내비팀은 내비게이션과 도로를 살핀다.
언젠가는 가까운 동료의 집에 다녀오는 길이었다. 2차선 골목은 왕복 8차선과 만나는데, 우리집으로 돌아가려면 80미터 앞 횡단보도에서 유턴을 해야 했다. 세 개의 차선을 거의 대각선에 가깝게 가로질러야만 유턴 지점에 도달한다. 도로에 차가 많다면 도저히 뚫고 갈 수 없기 때문에 경로를 이탈하여 3-400미터 이후에 있는 다음 횡단 보도에서 유턴하게 된다.
하지만 심야 시간에 차가 없다면? 오히려 빠르게 속도를 내고 달려오는 직진 차량과 부딪쳐 큰 사고로도 이어질 수 있다. 이런 도로와 길안내를 겪고 나면 사무실에 돌아와 우리는 전국에 유사 케이스들을 찾아본다. 소요 시간이 늘더라도 안전한 경로를 설계한다. 내비게이션의 길안내는 실시간 교통량 뿐 아니라 이런 다양한 예외 케이스들에도 영향을 받는다.
구글 안드로이드 오토를 독점 런칭하고 애플 카플레이를 선 런칭했을 때는 관련 CS가 쏟아졌다. 걔중에는 우리가 이미 아는 이슈도 있었지만 같은 차량임에도 도저히 재현이 되지 않는 이슈도 있었다. 이 경우에는 별 수 없다. 직접 사용자에게 전화를 드리고, 퇴근 시간에 맞춰 댁으로 찾아갈 수밖에. 개발자와 기념품을 챙겨 용인의 한 아파트 단지 주차장에서 기다렸다. 양해를 구하고 개발자와 해당 차량으로 20분을 주행 테스트를 했다. 원인을 파악했다. (난 정말 카카오모빌리티의 내비팀 개발자들을 리스펙트한다. )
서비스를 만드는 사람들은 나름 치밀하게 다양한 환경에서 지겹게 테스트를 한다. 하지만 사용자들의 불가사의한(?) 모든 환경과 닿는 것은 아니다. 이 빈틈이 사용자들의 피드백과 CS로 채워진다. 물론 지금까지의 예시처럼 훈훈한 마무리도 있지만 대개는 알 수 없는 경우가 더 잦다. 언젠가는 트럭 기사님과 1시간 넘게 통화를 나눈 적도 있다. 당연히 기사님의 의견이 반영되지는 못했다.... 그래도 당시 나는 3장의 녹취록을 남기고, 여러 피처들을 검토했었다.
어쨌든 대개의 서비스를 만드는 사람들은 사용자 피드백을 포기하지 않는다. 카카오모빌리티에서 팀 회의마다 내비팀의 개발자들은 항상 나보다 자주 미해결 이슈들을 거론했다.
1년 전 모빌리티를 떠나 카카오에서 카카오프로젝트100이라는 서비스를 런칭했다. 베타로 1년 째 운영 중이다. 여전히 점심 후에는 루틴처럼 CS를 본다. 대부분의 CS는 아는 이슈, 우리도 고민한 이슈일 때가 많다. 사용자의 요구를 모르지 않는다. 때때로 한탄스럽고, '우리도 바꾸고 싶다!'고 외치고 싶을 때가 있다.
모든 일이 그렇듯, 시간과 리소스 사이에서 저울질 하고, 어떤 것이 가장 효율적인가, 효과적인가를 고민할 수밖에 없기 때문이다. CS 때문에 주요한 정책에 변화를 주기도 하지만 이건 베타 서비스이기 때문에 그나마 가능한 것일지도 모른다. *여기서 말하는 CS란 모든 사용자의 피드백을 포함한다. 나와 접점에 있는, 제휴로 맺어진 사용자들은 늘 디테일한 서비스 의견을 넘치게 주신다.
다시 맨 위의 CS로 돌아가서, 변명을 하자면…
“안일하지는 않고요. 꽤 많은 생각과 논의를 거쳐 신중하게 답변을 드리고 있습니다.”
그리고 하고 싶은 이야기는, 불만이어도 좋다. 서비스는 사용자의 피드백이 필요하다. CS는 어쨌든 현재 있는 문제를 서비스가 인식하게 하는 가장 좋은 수단이고(이미 아는 이슈라도 우리는 다시 한번 더 머리를 싸맬 수 있다), 솔직히 CS까지 주는 사용자들의 열정과 분노를 나는 어느 정도 사랑하는 거 같다.
+덧붙인다
사용자의 피드백이 혁신을 만든다고 생각하지는 않는다. 대부분 서비스의 품질향상에 관한 이야기다. 피드백에 깔린 본질을 파악하고 근본적인 변화를 만드는 건 서비스의 몫이다. 원하는대로 해주는 게 답이 아니라, 새로운 원츠를 만드는 것이 답이다.
