Apply
home

유저들의 의견을 데이터화하다 (ft. 스프레드시트 짱!)

시작하며

지난번 티켓 자동 번역 시스템 여행기에 이어서, 이번에는 수많은 티켓 데이터를 보기 좋게 스프레드시트로 옮긴 사례를 들려드리려 합니다. 지난 글에서 말씀드린 내용과 연결되는 부분이 있으니 이전 글 읽고 오시는 걸 추천드려요!
아마 티켓 자동 번역만큼, 어쩌면 그보다 훨씬 오랫동안 다듬어온 과정이기에 할 이야기가 많을 거예요. 차근차근 목적부터 진행 과정, 결과까지 말씀드려볼게요.

이게 최선의 방법일까

티켓을 젠데스크 뷰에서 모니터링하고 처리하던 당시, 저희 그룹은 몇 가지 불편함을 느꼈어요.
iOS의 버그, 문의 티켓만 모아둔 필터 뷰입니다. 한 눈에 어떤 내용인지 보이시나요?
우선 전체적인 조망이 어려웠어요. 여러 개의 티켓 간 공통점 분석, 그룹화 등을 하려면 임시 태그를 만들어서 관련 모든 티켓을 업데이트하는 등 불편한 과정을 거쳐야 했습니다. (오래 걸리겠지요..?) 설령 이렇게 해서 유사한 티켓들을 묶는다고 해도, 한 화면 내에서 볼 수 있는 칼럼이 10개로 제한되고 본문은 앞부분만 보여서 결국 티켓 하나하나 다시 봐야 하는 번거로움이 있었어요.
두 번째로, 위 문제로 인해 정량화가 어려웠습니다. 딜라이트룸에서는 유저의 불편 정도를 파악할 때 티켓 데이터를 자주 참고합니다. 문제는, 처음에 모니터링할 때는 이슈인지 모르고 넘어갔는데 나중에 비슷한 티켓을 보다가 문제라는 걸 인식하는 경우였어요. 이전 내역을 정확히 찾아내는 것도 어렵다 보니, 초반의 티켓은 그룹화하지 못하게 되죠. 결국 특정 이슈에 대해 정확한 데이터보다는 감으로 인식하게 되었고, 어떠한 문제가 얼마나 큰 불편을 낳고 있는지 전달이 어려웠어요.
세 번째, 젠데스크의 검색 시스템이 (다소) 불편했습니다. 특정한 필드 값의 검색은 편했지만 본문 내 특정 단어를 언급한 경우를 찾기 아주 어려웠어요. 티켓 번역 글에서 하루만에 수백 개의 피드백이 들어왔을 때 트렌드 파악이 어렵다고 했지요? 번역을 함으로써 경향 파악을 위한 초석은 다졌지만, 그 안에서 단어를 검색해서 원하는 결과를 얻으려면 아주 불편했답니다.
“battery” 단어를 검색한 결과입니다.
예를 들어서 “battery”라는 단어가 들어간 티켓을 검색한다고 해볼게요. 이 경우 power, batteries 등 다른 단어로도 검색할 수 있어야 하는데 합집합 검색이 불가능했어요. 정확히 “battery”가 들어간 티켓의 목록이 나온다고 해도, 저희가 원한 결과인지 알려면 또다시 티켓을 하나하나 클릭해서 들어가 확인해야 했답니다.
이런 상황에서, 평소 엑셀로 자료 정리를 하는 걸 좋아하던 저는 “엑셀 시트에서 티켓 내용을 쭈루룩 한 번에 볼 수 있다면 참 좋을 것 같다”는 해결 방법을 생각하게 되었어요. 과연 가능할까 싶었지만, 번역 시스템을 만들던 때처럼 일단 작은 단위부터 시도해보았습니다.

Google Sheet API와의 만남

엑셀 프로그램은 타인과의 공유가 어렵다 보니, 여러 사람이 공유하여 실시간으로 변경내역을 볼 수 있는 구글 스프레드시트를 활용해보기로 마음 먹었습니다. Python 스크립트로 스프레드시트를 이리저리 조정하고 내용을 붙여넣을 수 있을까? 하며 검색해보니, Python 스크립트를 사용할 수 있는 Google Sheet API를 제공되고 있었어요. 두근두근하는 마음으로, 특정 셀에 제가 원하는 값을 넣는 아주 간단한 API request를 보내보았습니다.
최초 Sheet API 활성화, 사용자 인증 등의 단계를 거치고 나니, 저는 화면을 바라보고만 있었는데 스크립트가 뿅!하고 셀을 채워주었어요. 이미 자동 번역을 시도하면서 젠데스크 API를 조금 써본 상태였던 저는 “우리가 보고 싶은 티켓 내용을 스프레드시트에 자동으로 옮길 수 있겠는걸?” 하는 생각에 신이 났습니다.
Sheet API를 활용하여 Python 스크립트로 스프레드시트에 값을 넣어본 결과입니다.

스크립트에 살 붙이기

01 어떤 값을 가져와야할까?

젠데스크의 뷰에는 엄~청나게 많은 정보가 있다고 했지요. 처음 스크립트를 짤 당시에는 티켓들의 전반적인 현황을 조망하자는 넓은 목표만 가지고 있었기에, 일단 다 때려넣고(?) 불필요한 것은 나중에 빼자고 마음먹었습니다. 시간이 지나면서 팀 내에서 이 값이 필요할지 아닐지 논의하며 자연스럽게 정리가 되었습니다.
앱 버전, 마이너 버전, OS 버전, 제조사 값을 가공하여 넣은 모습입니다.
추가로 시트 상에서 알아보기 편하게 정보 형태를 가공하기도 했습니다. 예를 들면 기기 제조사 값의 다양한 대소문자 형식을 통일했습니다. 안드로이드 OS 버전이 API level로 표기된 것을 일상적으로 많이 사용하는 SDK 버전으로 변환하기도 했고요. 구글 플레이스토어 콘솔이나 젠데스크 상에서는 구분하기 어려웠던 앱의 마이너 버전도 새로운 열로 만들어서, 이제 마이너 업데이트 별로 구분해서 피드백을 나눠볼 수 있게 되었답니다.

02 시트에 중복된 행이 있으면 안 되는데!

이제 가져올 정보값은 각이 잡혔는데, 매일 티켓을 모니터링하다 보니 중복된 행이 있으면 안 되겠더라고요. 즉 마지막 업데이트 이후로 생성된 티켓만 가져오도록 해야 했습니다. 여기에는 티켓의 고유 값인 ID 값을 기준으로 가져오기로 했어요.
처음에는 티켓 정보를 시트로 가져오기 전에 ID 역순으로 정렬한 뒤, 가장 위쪽 셀에 마지막 티켓 ID가 위치하도록 했습니다. 그리고 해당 셀 값을 읽어서 그 이후의 티켓만 시트에 업데이트하도록 했지요. 하지만 예상하실 수 있듯이, 티켓 정렬을 미리 해두지 않으면 잘못 업데이트될 수 있었어요. 그러면 시트 파일의 Show History에서 이전 상태로 돌린 뒤 다시 스크립트를 돌리는 삽질을 해야 했습니다.
스프레드시트의 ID 열을 읽어 최댓값을 가져오는 코드 부분입니다.
그리하여 개선책으로 ID가 적힌 열 정보를 쭉 읽어서 그 중 최댓값을 자동으로 가져오게 했어요. 이제는 제가 스크립트를 돌리기 전에 매번 시트를 정렬하지 않고도 똑똑한 스크립트가 알아서 최신 티켓만 업데이트하게 되었답니다.

03 번역된 내용 가져오기

다음으로 중요한 것은 다국어 티켓에서 번역된 부분을 정확히 가져오는 것이었습니다. 이전 글에서 말씀드렸듯이, 티켓 종류 별로 번역된 내용이 위치한 곳이 조금씩 달랐어요. 자동 번역 스크립트를 통해 번역한 내용은 내부 노트에 있었기 때문에 기존에 쓰던 것과는 또다른 API를 사용해야 했고요.
다행히 티켓 번역 스크립트를 짜면서 티켓의 언어 정보 파악에는 나름대로 빠싹?해졌기 때문에, 티켓 인입 채널 별로 언어 정보값을 가져와서 정확히 번역된 내용을 가져오게 했어요. 영어, 한국어는 원문을 그대로, 그 외의 언어는 번역된 값을 가져오도록 했어요. 혹시 모르니 원문도 볼 수 있도록 본문 원문번역된 본문 칼럼을 따로 만들었답니다.
좌: 번역 전 원문 | 우: 번역 후 영어/한국어 버전!
그 결과 번역된 본문 칼럼만 쭈루룩 훑어도 내용 파악이 빠르게 가능하고, 꽤나 정확히 번역된 본문 덕에 특정 키워드 별로 검색하는 것도 아주 수월해졌답니다. (스프레드시트의 필터 기능 만세! )

04 데이터는 역시 시각화지! 대시보드

젠데스크에서 모니터링하는 과정의 단점으로, 티켓 데이터의 정량화가 어렵다고 했었죠. 스프레드시트는 피봇 테이블, 차트 생성 등의 기능을 젠데스크에서보다 자유롭게 활용할 수 있었기에 드.디.어. 정량화의 길이 열렸습니다.
타입 별로 Stack 차트, Column/Line 차트 등을 활용하고 있습니다.
티켓 종류, OS, 앱 버전, 내용 등 여러 기준 별로 피봇 테이블을 만들고 그걸 바탕으로 차트를 그리도록 했어요. 차트를 제공하는 소프트웨어만큼 멋지구리하지는 않아도, 나름대로 날짜, 버전 등을 변경하여 원하는 기준의 차트로 데이터를 한 눈에 볼 수 있게 했습니다. 그 결과 “어 요즘 버그 티켓이 평소보다 증가했네?”, “이 기능에 대해 불만이 늘고 있어” 등을 최근 경향에 대해 시각적으로 빠르게 감 잡을 수 있었어요.
이제는 누군가 “이 내용에 대한 티켓이 얼마나 들어오나요?”라고 물으면 정확한 평균치, 최근 경향까지! 더 확신을 가지고 대답하게 되었답니다. 이제는 유저들의 생각에 대한 POM 그룹의 감을 딜라이터들과 보다 쉽게 일치시킬 수 있었어요.

그 후 하루 업무의 시작은…

스크립트가 안정화되고 주기적으로 사용할 수 있게 되면서, 저의 하루는 스크립트 실행으로 시작되었습니다.
우선 번역 스크립트를 돌리고, (아직 설명드리지 않았지만) 특정 어구를 인식하여 키워드 태그를 달아주는 스크립트, 마지막으로 해당 정보를 시트로 옮겨주는 스크립트를 순서대로 실행했습니다. 그러면 하루에 100개든 300개든 들어온 티켓 정보를 한눈에 파악하고 빠르게 모니터링할 수 있었어요. 이전에 수 시간이 걸리던 티켓 모니터링을 빠르게는 20–30분만에 완료할 수 있게 되었습니다. 업무의 효율 향상과 더불어 품질까지 향상할 수 있는 계기가 되었지요.

야심차게 그리는, 더 큰 꿈

티켓 파싱 스크립트는 번역 스크립트보다 더 자주 수정/변경하며 여러 정보를 추가하고 있어요. 더 쉽게 읽을 수 있게, 우선순위를 빠르게 정렬할 수 있게 다양한 시도를 하고 있습니다. 더 나아가서 티켓을 모니터링한 결과가 어떻게 대응할지로도 직결되기 때문에 티켓 모니터링부터 대응까지의 큰 그림을 상상하며 장거리 달리기를 하고 있어요.
현재 시도 중인 것에는 크게 두 가지가 있습니다.우선 모니터링 과정 효율화를 위해 번역된 티켓 내용을 바탕으로 특정 표현(어구, 단어 등)을 인식하여 자동으로 내용을 분류하는 것이에요. 이렇게 되면 여전히 휴먼 리소스가 들어가는, 일일이 읽고 분류하는 과정도 단축할 수 있을 거예요. 그러면 저는 쭉~ 훑으면서 정확히 분류되었는지 더블체크하는 정도만 해도 되겠죠? 긴급한 이슈가 생겼을 때 트렌드를 파악하는 속도도 더 빨라질 것이고요. 현재 아주 간단하고 명확한 주제에 대해서만 샘플 스크립트를 짜두었는데, 이를 더 확장 적용하려 합니다.
대응 관련해서는, 자주 사용하는 설명 내용을 빠르게 가져오는 방법을 만들려 하고 있습니다. 특히 앱 내 기능의 사용 방법은 여러 응답에서 활용해야 할 때가 많은데 이걸 매번 쓰는 것보다는 최대한 잘 설명된 하나의 포맷을 사용하는 게 좋습니다. 유저에게 특별히 맞추어 답장을 하되 그때그때 기억에 의존하지 않도록 탄탄한 내용을 준비해두는 것이죠. 이러한 포맷을 가져오는 속도를 높여 대응 효율을 높이려 하고 있습니다. 그러면 각 유저에게 친절하고 자세히 설명을 빠르게 보낼 수 있겠죠!

끝내며

Customer Support 하면 무엇이 떠오르시나요?
유저에게 대응하는 업무(Customer Support)라고 하면 여러분은 어떤 업무를 떠올리시나요? CS 업무를 단순 업무로 대우하는 경우가 꽤 많은 것으로 알고 있는데요, 딜라이트룸에서는 유저와의 접점에 있는 POM 그룹을 중요하게 생각하고 있습니다. 그만큼 업무를 효율화하고 유저로부터 더 좋은 인사이트를 도출하기 위한 여러 시도를 지속하고 있어요. 단순히 고객 문의에 답장만 하면 된다!는 생각이었다면 이런저런 시도를 생각지도 못했을 것 같습니다.
어떻게 하면 더 창의적으로 고객을 만족시키고 도움을 줄 수 있을까 끊임없이 고민하는 POM 그룹에게 이 과정은 많은 교훈을 주었답니다. 스크립트라는 좋은 수단을 적재적소에 두어 팀의 생산성, 그리고 회사 전체의 생산성을 높이기 위한 시도였어요. 저는 기대했던 만큼의 성과가 나타난 것 같아 과정과 결과 모두에 대해 만족하고 있습니다.
글 두 개를 연달아 자동화에 대해 썼지만, 저희 POM 그룹의 업무에 대해서 들려드릴 이야기는 더더더 많답니다. 들려드릴 흥미로운 소재가 생기면 또 돌아오도록 할게요. 유저와 제품을 연결하는 POM 그룹! 응원하고 지켜봐주세요
POM 그룹이 열일하고 있는 이 회사, 대체 어떤 곳이냐구요?  딜라이트룸 더 알아보기