한 주에서 10개 이상의 신작이 쏟아지는 모바일게임 시장. 게임을 출시해도 대박은커녕 어떻게 하면 게임이 잊혀지지 않을까 고민하는 개발사가 부지기수다. “최소한 내가 만든 게임만은 유저에게 버림받지 않아야 할텐데….” 하지만 급변하는 시장 속에서 게임의 생존 가능성을 확신하기란 쉽지 않다.
확인하는 방법은 두 가지. 직접 출시해 보거나, 아니면 적은 유저들에게라도 먼저 의견을 듣거나. 모바일게임의 개발비가 늘어난 만큼 이제는 모바일게임 테스트도 희귀한 일이 아니다. 하지만 성공적인 테스트의 예는 많지 않다. 어떤 테스트는 설계를 잘못해 헛돈을 날리기도 하고, 어떤 테스트는 그 결과를 개발자가 귀담아 듣지 않아 테스트 자체가 무용지물이 되기도 한다.
그렇다면 성공적인 모바일게임 테스트를 위해서는 어떻게 해야 할까? 올해 들어 10여 건의 모바일게임 테스트를 주관한 디스이즈게임의 국순신 차장은 27일 KGC 2013에서 그동안 자신이 얻은 노하우를 공유했다. ‘모바일게임, 어떻게 테스트 해야 하나?’ 강연을 들어 보자. /디스이즈게임 김승현 기자
디스이즈게임 국순신 차장
어설프면 시간 낭비, 돈 낭비. 개발자의 마음을 읽어라
“테스트를 의뢰받으면 가장 공을 들이는 것이 무엇일까요? 테스트 과정 설계? 테스트할 게임 플레이? 개인적으로는 무엇보다도 개발자와의 인터뷰에 공을 들입니다.”
어떤 행동을 하는 데 있어 가장 중요한 것은, 그 행동의 목적이 무엇인지 확실히 하는 것이다. 아무리 테스트에 공을 들여도 기획부터 잘못되었다면 그 테스트는 무용지물이다. 지급된 참가보상비와 섭외비용, 그리고 테스터와 관계자들의 금쪽같은 시간도 모조리 날아간다.
문제는 이를 막기 위해 테스트 목적을 확실히 하는 것이 생각보다 쉽지 않다는 것이다. 개발사가 아무리 꼼꼼히 게임 소개서와 테스트 의뢰서를 작성했다고 하더라도 테스트를 주관할 사람이 보기엔 무언가 이상한 점이 한두 개가 아니다.
“많은 게임을 테스트하고 또 그만큼 많은 개발자를 만나왔지만, 개발자에게 들은 게임과 내가 한 게임이 같다고 생각된 적은 거의 없습니다. 심한 경우엔 개발자에게 들은 캐릭터 모습이 실제 게임에선 완전히 달랐던 경우도 있었죠.(웃음) 여러 가지 이유가 있을 거예요. 하지만 분명한 것은 ‘말’이라는 것은 우리가 생각하는 것 이상으로 정확하지 않다는 것입니다. 그리고 이것을 줄이고 줄인 ‘글’은 더욱 그렇죠. 의뢰서만 보고 게임을 이해하고 테스트했다가는 헛다리만 짚기 십상입니다.”
결국 정답은 지겨울 정도로 게임을 플레이하고 개발자와 만나며 기획 의도와 테스트 목적을 파악하는 것이다. 국 차장이 게임 파악과 테스트 기획에만 매달리는 시간은 약 2주. 최소 개발자와 2번은 만나야 게임과 테스트에 대한 감이 잡힌다는 게 그의 설명이다.
게임 스타트! 영상 녹화를 잊지 마세요
테스트 기획이 끝나면 본격적인 FGT가 시작된다. 대부분의 FGT는 게임 플레이를 기본으로 설문이나 인터뷰가 추가되는 방식으로 진행된다. 캐릭터 원화만 갖고 유저들의 반응을 체크하는 식의 독특한 테스트도 없지 않으나, 대부분의 테스트는 플레이를 기본으로 한다.
PC온라인게임이라면 PC방을 빌리겠지만, 모바일게임 FGT는 조금 양상이 다르다. 대부분은 테스터가 모일 공간을 마련한 후, 테스트 주관업체가 마련한 기기를 배치해 놓는 식이다. 테스터들의 스마트폰을 사용하는 경우도 있지만, 최근 같이 초고속 통신이 가능해진 시기에는 보안 문제 때문이라도 권장하지 않는 방식이다.
테스터가 모이면 간단한 성향 파악 후 본격적인 플레이에 들어간다. 테스트의 목적이나 게임의 성격에 따라 플레이 시간은 유동적이다. 하지만 명심해야 할 것은 아무리 코어 타이틀을 지향한다고 하더라도 휴식 없는 테스트는 지양해야 한다.
“개발자 중에는 의외로 유저가 자신의 게임을 재미없어 할지도 모른다는 것을 아는 이가 적어요. 특히 미드코어 이상을 노리는 개발사라면 콘텐츠 자랑도 할 겸 많은 플레이 타임을 테스터들에게 요구하죠. 하지만 분명한 것은 게임을 즐기는 것과 게임을 테스트하는 것의 스트레스 강도는 천지차이라는 겁니다. 실제로 이 스트레스 때문에 응급실에 실려갔던 사람이 생길 정도로요.”
일반적으로 FGT를 진행하는 게임 대부분은 개발 일정 상의 문제로 테스트에 참고할 DB나 로그를 확보하기 어렵다. 때문에 정확한 테스트를 위해서라면 테스터들이 게임을 플레이하는 모습을 영상으로 남기는 것이 좋다.
녹화할 수 있는 것은 다양하다. 테스터의 표정을 녹화하면 게임이 플레이하며 그가 느끼고 있는 감정을 보다 확실히 알 수 있다. 전용 프로그램으로 플레이 영상을 녹화해 두면 나중에 테스터의 플레이 패턴을 파악하기 쉬워진다. 캠코더 등의 외부 기기로 플레이하는 모습을 찍는다면 손가락 때문에 화면은 가려지겠지만, 대신 조작 상의 문제를 보다 잘 파악할 수 있다.
목소리 큰 사람을 조심해라, 설문과 인터뷰
플레이가 끝나면 테스터들이 느낀 점을 알아보기 위해 설문조사나 개별∙단체 인터뷰 등이 진행된다. 테스트 종류에 따라 둘 중 하나만 하는 경우도 있지만, 보다 꼼꼼히 의견을 듣고 싶다면 두 과정 모두 진행하는 것이 좋다. 포괄적인 것을 묻는 설문과 세부적인 것을 묻는 인터뷰는 서로를 보완하는 관계에 있기 때문이다.
예를 들어 설문조사는 특정 사안에 대한 구체적인 답변을 듣기 힘든 조사 모델이다. 설문조사를 객관식으로 하면 나중에 통계를 구하긴 쉽지만, 테스터가 느낀 세세한 감정을 놓치기 쉽다. 그렇다고 설문조사에 주관식 문항을 넣으면 귀찮음 때문인지 성실히 답변하는 경우가 별로 없다. 그렇다면 답하기 쉬운 객관식으로 세세한 항목 모두를 물어본다면 어떻게 될까?
“그러면 설문조사가 뒤로 갈수록 1, 3, 5번으로 답변이 쏠리게 되죠.(웃음) 아무리 객관식이라고 하더라도 질문 문항이 많아지면 테스터들이 귀찮아합니다. 더군다나 이 모델의 문제점은 처음에는 제대로 답을 하다가 점점 불성실하게 답을 하다 보니 어디서부터 값이 왜곡됐는지 파악할 수 없다는 것이죠. 설문조사는 어디까지나 테스터들의 큰 의견을 듣기 위한 도구입니다. 자세한 의견을 듣고 싶다면 인터뷰를 하는 게 좋죠.”
인터뷰의 강점은 테스터 개개인의 의견을 심도 있게 들을 수 있는 것이다. 이러한 장점을 살리기 위해선 참여 인원 전부를 한꺼번에 인터뷰하는 것보다, 그룹으로 나눠서 이야기하는 것이 좋다. 보다 자세한 의견을 듣기 위해 인터뷰를 진행하는 만큼, 전체를 아우르는 질문보다는 설문을 바탕으로 핵심적인 내용을 집중적으로 파고드는 편이 효과적이다.
주의해야 할 것은 ‘의견의 오염’이다. 그룹 인터뷰를 하면 간혹 자기 주장을 강하게 어필하는 사람이 있다. 자신의 주관이 강한 것이 나쁘다는 것은 아니나, 문제는 주관이 강한 만큼 다른 테스터들의 의견을 자신과 유사하게 변화시킬 확률이 높다는 것이다. 이는 다양한 테스터의 의견을 심도 깊게 듣고자 하는 인터뷰의 목적과는 어긋나는 경우다. 때문에 이럴 경우는 의도적으로라도 해당 유저의 발언권을 줄여 다른 유저들의 의견이 오염되지 않게 막는 것이 중요하다.
개발자가 수긍할 수 있는 언어로 이야기해라
테스트의 목적은 그 결과를 바탕으로 게임이 보다 나은 방향으로 나아갈 수 있게 돕는 것이다. 그런 만큼 테스트 결과를 보고할 때는 테스트의 내용 못지않게, 어떻게 효과적으로 개발자에게 전달할지도 중시된다.
예를 들어 ‘던전 플레이가 재미없다’는 의견이 있어 이를 그대로 전달했다면 테스트의 목적을 달성하기 힘들다. 개발자로선 어떤 요소 때문에 재미가 없는지 파악할 수도 없을뿐더러, 원색적인 피드백 때문에 개발자가 방어적인 태도를 취할 확률도 높다.
때문에 결과를 보고할 때는 항상 개발자가 받아들일 수 있는 언어와 납득할 수 있는 근거가 마련돼야 한다. 만약 ‘던전 플레이가 재미없다’면 이를 그대로 전달하는 것보다는, ‘몬스터 사냥 시간보다 이동 시간이 길다’, ‘동일한 던전을 10번 이상 반복해야 한다’ 같은 상세한 데이터를 전달하는 것이 더 좋다. 보통 테스트 대상이 되는 게임은 플레이 분석 툴을 갖추지 않은 경우가 대부분이기 때문에, 이러한 데이터를 마련할 때는 테스터들의 플레이 장면을 찍은 영상이 큰 힘을 발휘한다.
“영상은 플레이 분석 외에도 다양한 방면에서 강력한 도구로 활용될 수 있습니다. 단순히 게임이 재미없다고 이야기하는 것보다, 실제 유저가 그 게임을 하면서 어떤 표정을 지었는지 보여주면 훨씬 강렬한 메시지를 전달할 수 있죠.”
개발자가 소화할 수 있는 데이터라는 측면에서, 보고서의 길이도 무시하지 못할 요소다. 더 많은 데이터를 거부하는 이는 많지 않지만, 필요 이상으로 정보가 많다면 도리어 중요한 데이터를 놓치는 경우도 많다. 보고서의 양이 지나치게 많으면 그 양에 질려 보고서 자체를 대충 보는 경우도 적지 않다. 때문에 결과를 보고하는 입장에서는 항상 정보의 배치와 양에 신경을 써야 한다.
“결국은 소통입니다. 테스트 준비 단계에서는 개발자의 니즈를 알아야 하고, 테스트 후에는 유저의 요구를 전달해야 합니다. 하지만 소통에 실패해 둘 중 어떤 것이라도 놓친다면 테스트는 의미를 잃게 됩니다. 끊임없는 소통으로 성공적인 모바일게임 테스트를 할 수 있기를 바랍니다.”
디스이즈게임 댓글 ()
디스이즈게임
