게임을 플레이하며 버그를 직접 겪었던 유저들의 불만은 상당했다. 그리고 그만큼, 게임을 개발하고 서비스하는 이들의 속도 타들어 갔으리라. 과연 게임을 서비스하는 입장에서 본 버그는 어땠을까. 로드컴플릿 김재원 QA는 연단에 올라 그동안 QA의 입장에서 접했던 다양한 버그와 사건 사고들을 소개했다. 그리고 초보 QA였던 자신의 대응과, 같은 상황에서 QA가 어떻게 대처하면 좋을지에 대한 내용을 하나씩 풀어나갔다.
개발이 진행되는 도중, 보통 QA는 기획, 개발, 기능 확인, 재미검증, 서비스 등의 작업에 관여하게 된다. 하지만 나는 초보 QA였기에 단순히 기능 확인밖에 하지 못했다. 그러다 보니 여기저기 구멍이 뚫리면서 큼직큼직한 사건 사고를 만나게 된다. 튜토리얼 진행 불가부터 '크퀘가 폭발한다' 사건, 그리고 무한 로딩 등 각각의 이슈들을 발생했던 시간 순서대로 되짚어보려 한다.
가장 먼저 만났던 이슈는 튜토리얼 진행 불가다. 크루세이더퀘스트의 CBT 당시 발생했던 버그로, CBT가 시작된 지 얼마 되지 않아 일부 유저들이 튜토리얼에서 막혔다는 제보를 보내왔다. 상당히 치명적인 버그로 긴급점검이 걸리기도 했다.
튜토리얼 진행 중 용사 승급 부분에서 생긴 버그였다. 진행을 위해서는 용사 승급 버튼을 눌러야 하는데, 막상 획득한 재화가 없어 버튼을 누르면 재화가 부족하다는 팝업이 뜨며 진행이 불가능했다. 크루세이더퀘스트의 튜토리얼은 강제적으로 진행해야만 하는 방식이기에 유저들은 이도 저도 못하고 해당 구간에서 막혀버린 것이다. 최악의 경우, 유저들이 그대로 게임을 접어버릴 수도 있는 상황이었다.
초보 QA였던 나는 해결을 위해 재현 시도를 했다. 재현 시도란 이슈를 다시 발생시켜, 이슈가 발생하는 경로나 조건을 좁혀나가는 작업이다. 하지만 초보 QA가 제반 지식도 없는 상황에서 무작정 반복 시도만 해서 될 문제가 아니었다. 그래서 우선 개발자가 코드를 점검해 의심되는 부분을 QA와 의논했고, 이를 해결하는 업데이트를 진행해 일단락 지었다.
버그의 원인은 바로 서버에서 재화를 지급하고, 그 재화를 튜토리얼에서 쓰게끔 했던 방식이었다. 모바일의 경우 통신환경이 좋지 않을 때가 있어, 서버에서 재화를 보내다가 유실된 것이 아닐까 하고 추론했다. 그래서 그 당시에 게임에서 로딩이 걸리기 시작하면 통신환경이 불안정한 비상계단으로 뛰쳐나가 상황을 재현해보려 했다. 그렇게 시도한 끝에 결국 이슈가 재현되어 '이 문제는 통신 환경의 문제다'라고 입증할 수 있었다.
그렇다면, 여기서 QA로써는 직접 뛰어다니는 것 이외에 어떤 일을 할 수 있을까 생각해봤다. 먼저 튜토리얼처럼 중요한 기능은 불안정한 요소를 거치지 않도록, 무료로 진행할 수 있게끔 하는 방법을 제시할 수 있을 것이다. 그렇지 않다면 불안정한 요소를 미리 테스트하는 것도 좋은 방법이다. 불안정한 통신망까지 구현해서 미리 테스트를 해보고, 안정성을 입증하는 것이 좋을 것이다.
두 번째 이슈는 버그 부활이다. 보통 테스트 과정은 개발 서버에서 시작해 외부의 침입 없이 테스트를 할 수 있는 테스트 서버, 라이브 서버와 거의 동일한 환경으로 구축한 알파 서버를 거치며 진행된다. 버그 부활 이슈는 데이터들이 단계적으로 서버를 거칠 때마다, 이전에 수정했던 버그들이 부활하는 이슈였다.
그 당시 수정한 버그들이 부활하는 이슈가 빈번하게 일어나자, 담당자에게 "수정한거 맞아요? 왜 버그가 부활했죠?" 라고 물었다. 그러면 담당자들에게서 "수정한 게 맞다. 잘 되는 것까지 확인했다. 진짜다."라는 대답이 돌아왔다. 한동안 이렇다 할 원인을 찾지 못해 "시트 귀신이 살고 있다"는 말까지 나올 정도였다. 물론 범인은 개발자 중 하나였을 것이다.
하지만 버그는 해결해야 했다. 그래서 각 개발 담당자들이 작업을 마칠 때와 적용할 때, 변경 사항이 있을 때면 반드시 다시 한번 확인하도록 요청했다. 또한, QA인 나는 고질적으로 버그가 부활하는 구간을 기억했다가 서버가 한 단계씩 진행될 때마다 해당 구간을 다시 테스트했다. 서버의 종류가 늘어나고 부활하는 버그의 수가 많아지게 되면서, 작업량이 기하급수적으로 늘어나 체력 소모가 심했었다.
해당 이슈의 원인은 바로 온라인 협업 도구로 같이 작업하는 방식 때문이었다. 여러 명이 작업 도구에 데이터를 넣고 잘못 넣었을 때 삭제를 해버리거나 위치를 옮기는 경우가 빈번했는데, 이때 서로가 서로의 작업물을 공격해버린 것이다. 그러다 보니 작업 수정 내역도 상당히 늘어나 범인 색출도 어려웠다. 여기서 초보 QA였던 내가 했던 일은 많은 작업 수정 내역을 전부 뒤져서 범인을 찾아, 그에게 조심해 달라고 부탁한 것이 전부였다.
만일 이 상황에서 QA는 어떤 일들을 할 수 있을까. 여기서는 크루세이더퀘스트를 새롭게 맡은 팀장님이 도입한 프로세스를 소개하려 한다. 우선 온라인 협업 도구를 쓰지 말고 오프라인으로 각자 작업해 안정성을 높인다. 이후 작업 툴을 이용해 서로의 작업을 합친다. 개발 담당자들은 합치는 과정에서도 서로의 작업물이 잘 적용되었는지 서로 체크하는 과정도 거쳤다. 그 결과 '시트 귀신'이 완전히 사라지진 않았지만, 그 빈도를 많이 줄일 수 있었다.
다음 소개할 이슈는 바로 '끝판왕 버그'다. 게임을 멀쩡히 하다가 갑자기 "다른 기기에서 접속하셨습니다"라는 팝업이 뜨며 게임이 튕겨버리는, 서비스 사상 최악의 버그였다. 모든 유저에게 이러한 현상이 발생해 게임을 제대로 플레이할 수 없게 된 것은 물론, 팝업 메시지의 내용 때문에 자신의 계정이 해킹당하지 않았나 하는 불안감까지 조성되는 최악의 상황이 벌어진 것이다.
그래서 가장 먼저 팝업 메시지의 내용을 "세션이 만료되었습니다"로 수정했다. 해킹을 당하지 않았다는 내용임을 알리려는 의도였다. 이후 버그에 조치를 위해 작업에 들어갔다. 시급한 해결이 필요했던 이슈였지만, 나는 경험이 많지 않은 초보 QA였기에 마땅한 도움이 되지 않았다. 기술팀에서는 의심되는 부분을 수정해도 해결되지 않았고, 방어 코드를 넣어도 해결되지 않았다. 결국에는 라이브러리 교체와 코드 교체로 해결할 수 있었으나, 명확한 원인은 아직도 밝혀지지 않았다.
별달리 할 수 있는 것이 없었던 상황에서 초보 QA인 내가 한 일은, 의심되는 소스가 있으면 사소한 것이라도 제보하는 것이었다. 하지만 지금 생각해보면, 소스를 하나씩 하나씩 따로 제보하는 것보다 나 이외에 다른 여러 사람들이 주는 제보와 정보를 QA가 취합하고, 담당자가 알기 쉽게 일목요연하게 정리해 전달하는 것이 더 도움이 되지 않았을까 싶다.
물론 개발 지식을 쌓으면 도움이 될지도 모르지만, 만약 관련된 지식이 없어 대처할 수 없는 일이 닥친다면 계속 그것에 얽매여서 '어떻게 할까?' 하고 고민하는 것은 그다지 추천하고 싶지 않다. 그 대신 지금 당장 할 수 있는 일에 집중해 제보를 모은다거나, 정리하거나, 전달하는 것이 좋지 않을까.
네 번째 이슈는 스킬 버그와 밸런스 붕괴다. 시간 순서대로 네 번째 발생한 이슈라기보단 크루세이더퀘스트의 대표적인 이슈이며, 출시 때부터 지금까지 계속 발생하는 이슈이기도 하다. 강력한 특정 용사가 있는 반면 '까빈스'처럼 약했던 용사들이 있는 등 밸런스 이슈가 있었고, 부술 수 없게끔 설정된 대미지 미터기를 용사가 부숴버리거나, 용사의 스킬이 망가져 최악의 경우 게임 진행이 불가능했던 이슈도 있었다.
용사의 스킬을 건드린다는 것은 크루세이더퀘스트 근간을 흔들 수 있는 부분이라 거대한 작업이 될 수밖에 없었다. 다행히도 게임 QA 분야의 신입 사원 중 크루세이더퀘스트를 많이 플레이했던 사람이 있어, 그 사원을 통해 모든 용사의 스킬을 테스트했다. 이후 그 사원이 스킬 및 밸런스 담당 QA가 되어 개발자와 많은 피드백을 주고받았다.
잦은 스킬 버그의 원인는 바로 한 땀 한 땀 쌓아 올린 듯한 데이터 구조였다. 기획자가 코딩하듯이 타겟, 시간, 해제, 중첩, 반응, 아이콘, 연출 등의 스킬 데이터를 하나씩 쌓아 올린 형식 때문이었다. 마치 위태위태하게 서있는 젠가와 같은 느낌이다. 문제가 있는 조각을 발견해 그 조각을 제거하게 되면, 젠가가 무너져 버그가 생긴다. 그렇기 때문에 담당자는 물론 QA 역시 고도의 집중력과 지식이 필요하다.
용사를 하나만 테스트하는 것도 상당히 어려운 작업인데, 크루세이더퀘스트는 하나의 파티에 3명의 용사와 여신, 챔피언까지 데려가는 구조다. 경우의 수가 상당히 많으며 그만큼 버그가 발생하게 된다. 거기다 그들의 밸런스까지 생각하려고 하면 문제는 더욱 어려워진다. 만화 '몬타나존스'에 등장하는 니트로 박사의 입버릇처럼 충분한 시간과 예산이 주어진다 하더라도 쉬운 작업이 아닐 것이다.
여기서 초보 QA인 내가 한 일은 위험한 상황을 미리 깨닫고, 이를 예방하기 위해 데이터 구조를 공부하는 것이었다. 보통은 테스트를 진행하며 게임의 생태계를 파악하고, 게시판 동향을 하나하나 읽어가며 어떤 용사가 좋은지 의견을 모으는 행동들을 했어야 했다. 하지만 직접 테스트를 하기엔 시간이 부족했고, 게시판 동향을 읽다가 부정적인 피드백을 보고 '멘탈이 박살 나' 다른 방법을 찾았다. 그 결과 데이터 구조를 파악해 미리 무너지는 사태를 막아보자는 식으로 접근했다.
그렇다면 QA는 이런 상황에 어떤 작업을 해야 할까. 우선 스스로가 게임 밸런스 전문 인력이 되는 것이 먼저다. 그렇지 못하다면 게시판 동향에 항상 귀를 기울여 어떤 캐릭터가 좋은지, 나쁜지 항상 숙지해야 할 것이다. 만약 크루세이더퀘스트처럼 스킬 구조가 복잡한 경우, 작은 수정 작업에서 발생할 수 있는 관련 스킬에 대한 경우의 수를 최대한 테스트해 위험을 줄여야 한다.
다섯 번째는 이미지 깨짐 버그다. 게임 내 이미지가 보라색으로 깨지거나 용사나 여신의 아이콘이 들어갈 자리에 몬스터 중 하나인 엔트 아이콘이 나오는 현상이다. 유저들에게 '게임이 없어 보인다'는 인상을 심어줄 수 있었고, 심각한 경우는 아예 게임 플레이가 불가능하게 되는 일도 있었다. 물론 용사의 표정이 무기 근처에 여럿 나타나 유저들이 재미있어했던 버그도 있었지만, 그래도 버그는 버그였기에 빠르게 고쳐야 했다.
버그의 해결을 위해 개발엔진 Unity4를 Unity5로 업그레이드하기로 결정했다. 큰 작업이다 보니 TF팀에 QA도 참여해 프로젝트 밖에서부터 함께 작업했다. 여담으로 이때 기억에 남는 일화가 있다. 작업 중 담당자와 함께 이야기를 나눴는데, 그 담당자가 업그레이드를 하고 나면 문제가 해결되거나, 변화가 없거나, 박살 나거나 셋 중 하나라고 했다. 사실 업그레이드를 하는 것도 모험인데, 박살이 나면 다시 다운 그레이드를 해야 한다. 다운 그레이드는 다른 회사에서도 경험해본 적이 없어, 그 역시 모험이라는 무서운 말을 듣고서 떨었던 기억이 난다.
원인을 진단해보니 Unity4의 기술적인 한계였는지 이미지 번들이 굉장히 불안정했다. 또한, 이미지의 개별 수정과 개별 업데이트 작업이 불가능했고, 때문에 업데이트 코스트가 이미지 수정 작업의 배로 걸렸다. Unity5로 업그레이드된 후에는 안정화 된 모습을 보여 큰 문제 없이 이미지 관리를 하고 있다.
여기서 초보 QA인 내가 할 수 있었던 일은 거의 없었다. 대부분 기술적인 영역이었기에 단순히 빨리 업그레이드 해달라고 요청한 것이 다였다. 여기서 QA는 어떤 방법을 사용해야 할까. 우선 기술적인 문제라면 빠른 업그레이드가 가능하도록 푸시를 해야 한다. 또한, 거대한 규모의 작업이 진행될 때면 담당 QA 인력이 붙어서 미리 위험성을 확인해야 할 것이다. 그리고 엔진 업데이트 작업이 완료되었다면, 원래 잘되던 기본적인 것들도 세밀한 테스트를 거쳐 발생할 수 있는 위협을 미리 방지해야 한다.
마지막은 무한 로딩 버그로, 크루세이더퀘스트의 경우 주로 이벤트가 열리는 날에 발생했던 버그다. 버튼을 누를 때마다 로딩이 걸리거나, 용사 뽑기를 한 번만 눌렀는데 그 배의 용사 뽑기가 진행되던 이슈였다. 어떤 때는 1회의 비용으로 여러 명의 용사가 뽑혔지만, 어떤 때는 여러 명의 용사가 뽑힌 만큼의 비용이 소모되었던 경우도 있었다.
해결을 위해 업데이트가 되는 날 미리 서버를 예열시키는 프로세스를 도입했다. 자동차 엔진을 예열하듯 서버를 미리 예열하는 것이다. 또한, 부하가 걸렸을 때를 대비해 스트레스가 와도 정상적으로 동작하게끔 여러 겹의 안전장치를 추가했다. 그리고 기획 단계에서 부하가 걸릴 것 같은 로직이 발견되면 사전에 변경하는 식으로 진행했다.
버그의 원인은 동시 접속자의 몰림 현상 때문이었다. 개발자나 QA 모두 유저들이 많이 몰리는 상황에 대한 상정이 없어서, 그 부분을 미리 체험하지 못해 놓치게 된 것이 원인이었다. 놓친 부분인 만큼 무언가를 시도하지도 못했다. 그렇다면 이런 상황에서 QA는 어떻게 해야 할까.
먼저 빌드와 서버가 데이터를 주고받는 구조를 파악해, 기획 회의 때 부하가 예상되는 부분을 발견했다면 우회 경로를 건의해야 한다. 또한, 스트레스 테스트가 가능한 인프라를 요청하는 것도 좋을 것이다. 만약 그런 환경을 구축할 수 없다면 유료 결제 등 중요한 부분을 더욱 세밀히 테스트해보는 수밖에 없지 않을까. 안전장치를 미리 마련했다면 사소한 부분이라도 테스트를 세밀하게 진행해야 할 것이다.
보통 QA들은 시간이나 예산이 여유로운 상황에서 테스트하는 경우가 거의 없다. 항상 허덕이며 테스트를 하는 와중에도 최대의 효율을 내야 할 것이다. 하지만 주어진 환경 안에서만 발버둥 쳐서는 안 된다. 작업 환경이나 프로세스에 문제가 있다고 느껴진다면 이를 지적할 수 있는 눈을 가져야 한다. 물론 프로세스의 개선이 쉬운 일은 아니지만, 좋은 게임을 위해서라면 당당히 건의할 수 있는 마음가짐이 필요하다.
지금까지 초보 QA인 내가 뭔가 한 것처럼 이야기하긴 했지만, 사실 내가 뭔가를 해온 건 딱히 없다고 생각되기도 한다. 나는 도움을 요청했고, 환경에 변화가 있었고, 그러다 보니 험난한 업계에서 어떻게 살아남아 발표도 하게 되었다. 다른 QA분들이나 QA를 지망하시는 분들도 혼자 발버둥 치는 것이 아니라 개발자, 기획자분들과 함께 QA를 해나갈 수 있는 환경이 되었으면 한다. 항상 고군분투하는 모든 QA분들에게 존경을 표한다.
desk@inven.co.kr