“유저의 목소리에 귀 기울여라”
100명에게 이야기하면 모두 고개를 끄덕일 이야기지만, 개발자가 실제로 이를 수행하기란 쉽지 않다. 개발과 퍼블리싱이 분리된 게임사가 많아 개발자가 직접 유저들의 피드백을 확인하기도 어렵고, 개발자 스스로도 라이브 서비스 이슈에 쫓기느라 따로 유저의 반응을 파악하기도 어렵다.
물론 그중에는 직접 커뮤니티를 찾아다니며 유저들의 반응을 체크하는 이도 있지만, 하루에도 수천수만 개의 글이 생성되는 인기작이라면 이마저도 난관이다. 네오플의 송창규 테크니컬 디렉터(이하 TD)도 상황은 다르지 않았다. 하지만 어느 날 사정이 달라졌다.
개발팀에서 원인조차 잡지 못하던 버그의 원인을 한 유저의 게시물을 통해 알게 되었다. 이후 바쁜 와중에도 유저 게시물을 체크하기 시작했다. 그 덕에 많은 버그를 고칠 수 있었지만 다른 이들에게 이를 권하긴 너무 고된 방식이었다. “어떻게 하면 효과적으로 유저들의 반응을 체크할 수 있을까?” 그가 1년간 고민했던 문제의 답을 들어봤다. /디스이즈게임 김승현 기자
네오플 송창규 TD
유저는 왕이자 현자, 유저 말에 귀 기울여라!
“<던전앤파이터>는 대형 커뮤니티가 4곳 존재합니다. 하루에 새로 올라오는 글만 수만 개. 4개 커뮤니티를 돌아다니며 특정 키워드 하나만 검색하는 것도 만만치 않은 일이었죠”
네오플의 송창규 TD는 처음 유저 게시글을 탐색했을 때의 어려움을 이야기했다. 서비스가 오래된 게임일수록, 그리고 많은 유저들의 사랑을 받는 게임일수록 유저들의 반응을 체크하기 더 힘들다. 체크할 커뮤니티도 많은 데다가, 하루에 생산되는 이슈도 많아 이를 온전히 쫓을 수 없기 때문이다. 기껏 유저 게시글을 좇아봤자 전체적인 분위기만 파악할 뿐이다.
물론 분위기 파악이 의미 없다는 것은 아니다. 하지만 게임의 실행문제나 안정성 같이 소수의 유저들에게만 화제가 돼도 게임에 치명적인 악영향을 주는 이슈도 존재한다. 이를 체크하기 위해서는 각 커뮤니티의 게시판마다 돌아다니며 특정 키워드를 검색해야 하는데, 유저들이 사용하는 용어나 오타, 그리고 이슈의 종류 등을 감안하면 손이 열 개라도 모자랄 지경이다.
이 때문에 그도 게시글을 탐색하는 것을 대수롭지 않게 생각했었다. 그러던 중 2013년 <던전앤파이터>에 범상치 않은 버그가이 연이어 등장했다. 시작은 원거리 직업군 ‘스핏파이어’의 버스터샷이었다. 밸런스 패치 후 버스터샷의 피해가 온전히 들어가지 않는 일이 발생했다.
내부에는 버그의 현상조차 재현하지 못해 해결에 골머리를 앓고 있었다. 그러던 중 한 유저가 커뮤니티에 스킬의 문제점을 분석해서 올렸다. 개발팀은 실마리조차 잡지 못하던 버그의 원인을 단숨에 짚었다. 버스터샷 문제가 해결되니 얼마 뒤 게임이 실행되지 않는 문제가 발생했다.
피해자들 모두 윈도우 XP를 사용하고 있었지만, 정작 네오플이 보유한 XP PC에서는 잘만 플레이가 됐다. 버그 재현이 되지 않아 원인도 온전히 파악 못 했다. 그러던 중 송 TD는 한 커뮤니티에서 XP 패치 후 게임이 다시 실행됐다는 팁을 보게 되었다. 알고 보니 XP SP2 팩에서 메모리를 많이 잡아먹는 프로그램을 차단해서 생긴 일이었다. 최신(?) PC를 가진 덕에 파악하지 못한 원인을 유저들의 게시물에서 찾게 된 셈이었다.
송 TD는 이러한 경험을 이야기하며 “아무리 게임사가 크고 프로세스가 정교해도 잡지 못하는 문제가 있습니다. <던전앤파이터>같이 오래 서비스된 게임은 프로그램이 복잡해 더더욱 그렇죠. 많은 이들이 유저를 왕(고객)이라 말합니다. 여기에 한마디 더 덧붙이자면 게임을 사랑하는 유저는 현자가 되기도 합니다. 고객을 지키기 위해선 고객의 말에 귀 기울여야 합니다”라며 유저들의 동향 파악을 게을리하지 말 것을 주문했다.
반복작업보다 더 무서운 것, 인간의 관성을 넘어라
물론 이를 아는 것과 실행하는 것은 별개의 문제다. 송창규 TD 또한 이러한 내용을 알고 있었지만, 쏟아지는 피드백에 질려 동향 파악을 포기했던 사람이었다.
송 TD가 이를 해결하기 위해 고안한 것은 일종의 검색 자동화 프로그램이었다. 마이크로소프트의 ‘아웃룩’처럼 커뮤니티의 게시물을 한곳에서 모아볼 수 있고, 커뮤니티나 게시판에 상관없이 모든 글에 검색이 가능한 프로그램이었다. 검색의 용이성을 위해 검색어도 ‘밸런스 패치, 밸패, 패치’ 등으로 그룹화했다. ‘렉’과 ‘랙’같은 오타까지 고려한 꼼꼼한 구성이었다.
효과는 놀라웠다. 그리고 주변의 반응은 다른 의미로 놀라웠다. 그가 만든 프로그램은 이전까지의 방식보다 효과적으로 유저들의 동향을 파악했다. 동료들도 모두 기뻐하고 칭찬했다. 하지만 정작 그 프로그램을 사용하는 이는 적었다. 이유는 단순했다. 귀찮아서. 혹은 이전까지 자신이 쓰던 방식을 버릴 이유가 없어서. 꼭 해야 하는 것은 아니니까 등등. 그의 프로그램은 ‘관성’이라는 벽을 넘지 못했다.
고생해서 프로그램을 만들었던 것도 아쉬웠고, 이 좋은 수단이 묻히는 것도 아쉬웠다. 그때부터 송 TD의 진정한 고생이 시작되었다. 사내 메일로 프로그램을 소개하기도 하고, 어떤 때는 직접 사내 회의실에서 프로그램을 시연하기도 했다.
효과적인 홍보(?)를 위해 메일을 보낼 때는 텍스트보다 시청각 자료의 비중을 높였고, 이슈가 발생하면 프로그램으로 뽑은 데이터를 샘플(?)로 보내기도 하였다. 동료들이 프로그램에 익숙해지게끔 하기 위해 사람들의 이동이 많은 곳에는 모니터를 설치해 주요 이슈를 실시간으로 보여주기도 했다.
그렇게 몇 번을 반복하니 동료들 사이에서도 조금씩 긍정적인 반응이 나타나기 시작했다. 어떤 개발자는 패치가 끝나면 그가 만든 툴로 유저들의 반응을 체크하기 시작했고, <던전앤파이터>팀 메일에서도 툴을 이용한 정성적∙정량적 근거가 활용되기 시작했다. 외부접속이나 통계 등 프로그램의 기능을 확장하는 요구도 생겨났다.
베일 속의 개발자들, 유저 앞에 나서다
그리고 개발팀의 이러한 변화는 네오플 내부뿐만 아니라, <던전앤파이터>를 즐기는 유저들에게도 영향을 끼치기 시작했다. 게시글 분석으로 좋은 결과를 얻은 개발팀은 이를 적극적으로 활용하기로 했다. 개발팀 내부에 유저들과 직접 소통하는 별도의 TF를 신설한 것이 대표적인 사례였다.
최초 콘셉트는 ‘고객의 이야기를 들어주는 정의의 개발자 원이’. 2013년 10월 ‘원이의 불편 사항 개선’이라는 이름으로 시작된 이 코너는 실제 개발자가 공지와 댓글, 게임 커뮤니티의 게시글 등으로 유저에게 개발 방향과 목적을 설명하고, 게임에 대한 유저들의 의문과 요구를 들어주는 콘셉트였다. 이러한 코너는 좋은 반응을 얻어 이후 밸런스 팀이나 개발팀, 유료화 모델팀 등에서도 유사한 모델의 코너를 만드는 계기가 되었다.
이렇게 개발자가 전면에 나서자 유저들의 반응도 달라졌다. 특정 파트를 담당하는 개발자가 전면에 나섬으로써 유저들도 알지도 못하는 개발자에게 불만을 쏟아내는 대신, 특정 ‘창구’에게 자신들의 의견을 말하고 설득하기 시작한 것이다.
대표적인 예가 2013년 11월 논란이 된 ‘싸우자!’였다. ‘싸우자!’는 도시에 돌아다니는 아무 유저에게나 PK를 시도할 수 있는 <던전앤파이터>의 콘텐츠다. 싸우자!에서 패배한 유저는 5분간 게임 속에서 아무것도 할 수 없었기 때문에 많은 논란 끝에 2012년 패치로 사라지게 된 콘텐츠였다.
이것이 지난해 11월 <던전앤파이터> 테스트 서버인 ‘퍼스트서버’에 다시 업데이트되었다. 논란의 콘텐츠가 다시 부활한다는 소식이 들리자 관련 커뮤니티에서는 부정적인 피드백이 쌓이기 시작했다. 하지만 이전처럼 유저들이 ‘폭발’하지는 않았다.
담당 개발자가 직접 커뮤니티에 출몰하며 유저들의 의견을 듣고 답한 덕분이었다. 그리고 이렇게 모아진 의견들은 다시 개발팀으로 전달돼 결국 퍼스트서버 업데이트 번복으로 이어지게 되었다.
물론 이러한 과정이 쉬웠던 것은 아니다. 개발자가 유저와 직접 소통한다는 것은 생각보다 많은 위험을 내포한다. 혹시라도 개발자와 유저가 싸우기라도 하면 돌이킬 수 없는 일이 벌어질 수도 있다. 네오플에서는 이러한 일을 방지하기 위해 소통에 나선 개발자가 커뮤니케이션 교육까지 받았다.
하지만 모든 실수를 막을 수는 없었다. 커뮤니케이션 채널의 다양화도 문제가 될 수 있다. 일반적으로 유저들이 대화하는 상대는 개발자보다는 고객서비스팀이다. 둘 사이의 소통이 원활하지 않다면 서로 맞지 않는 내용 때문에 유저들이 불신할 수도 있다.
하지만 이러한 장애물에도 불구하고, 유저들과 소통한다는 것은 많은 장점을 가지고 있다. 단순히 게시물만 파악하더라도 통계로는 알 수 없는 유저들의 감정이나 개발자가 놓친 버그 등을 알 수 있으며, 개발자가 유저들 앞에 나섬으로 인해 소통과 합의의 과정에서 서로에 대한 신뢰와 게임에 대한 주인 의식을 얻을 수 있다.
