숨겨진 서사를 찾는 과정
"내 주인공이 어젯밤에 살해당했어. 아니 글쎄 내 주인공이 술집엘 갔는데, 어디선가 느닷없이 멕시코 출신의 한 남자가 등장해서 그의 머리를 쏴버렸지 뭔가. 이제 어쩌면 좋을지 모르겠어. 이제 겨우 130쪽인데 주인공이 죽어버리다니."
위 말은 미국 범죄소설의 대부이자 하드보일드의 거장 엘모어 레너드가 했던 말이다. [미스터리 추리 백과사전]을 집필한 펜즐러에게 전했던 이야기로, 펜즐러가 그 장면을 다시 쓰면 되지 않느냐고 하자 레너드는 그를 미친 사람 취급했다고 한다. 주인공은 이미 죽었다고. (지루하면 죽는다. p165. 조나 레러 지음.)
QA를 하다 보면 수많은 재현 요청을 받는다. 수많은 개발자로부터, 기획자로부터. IT 관련 종사자나 연관된 공부를 하지 않은 사용자 입장에서는 잘 이해하지 못하는 부분이지만, 버그란 본래 재현이 가능해야만 수정할 수 있다. 이게 무슨 말이냐면 많은 게임을 하는 고객은 문제가 있던 상황만 설명하면 문제가 해결될 수 있을 것이라고 믿는다. 그러나 간헐적이라도 재현되는 방법이 있어야 문제를 고칠 수 있다.
예를 들어 가슴에 통증이 있다고 해보자. 이는 심장 문제일 수도, 폐 문제일 수도 있고 식도에 문제가 있을 수도 있다. 의사를 만나 증상을 설명하고 우린 바로 가슴을 여는 수술을 하지는 않는다. 정확한 검사를 하고 필요하다면 다른 과와 협진도 이루어진다. 이때 대다수 환자는 왜 의사에게 고치지 않느냐고 묻지 않는다. 노력하는 것이 보이기 때문이다.
불행하게도 게임에서 문제가 발생했을 때 해결되는 상황도 이와 비슷하다. 특히 게임에 자유도가 높은 형태일수록 그러하다. 여기서 자유도란 사용자 행동을 기준으로 한다. RPG 장르가 두드러지는데 많은 사람들이 하는 MMORPG가 더욱 그렇다. 수많은 사람과 상호 작용이 동시에 가능하고 여러 변수가 있다면 문제를 빠르게 진단하기가 어렵다. 앞서 1화에서 이야기한 로그를 보면 되지 않느냐 하지만, 정말 안타깝게도 로그가 만능은 아니다. 인생의 기억도 내가 어제 먹은 점심에서 몇 번의 젓가락질을 음식마다 했는지 남지 않는다.
때문에 게임 회사 안에서 보편적으로 가장 많이 게임을 플레이하고 다양한 테스트 상황을 겪는 QA에 의뢰가 들어온다. 이 시점부터 QA는 한 명의 탐정으로 변한다. 서두에서 이야기한 다음 서사를 어떻게 풀어가야 할지 고민하는 것처럼 QA도 이 버그의 원인과 재현방법, 기대 결과 등을 치열하게 고민해야 한다. 나는 재현 과정을 찾는 것이 숨겨진 서사를 발견하고 만들어가는 것과 일맥상통한다고 생각한다. 그리고 그 과정이 정말 재밌다.
다음은 일종의 재현 방법을 찾는 노하우다. 다만, 당연한 것 아닌가?라고 생각이 들 수 있는데 그런 것들도 스스로 생각해 내는 것이 중요하다. 남의 생각을 보고 알고 있었다고 하는 것과 스스로 생각해 내는 것은 천지차이다. 해답지를 보고 수학 문제를 푸는 것처럼.
1. 의뢰 자체가 잘못된 것은 아닌지 알아본다. 사건의 제보자가 잘못 보거나 다르게 이해한 점이 있을 수 있다. 만약 UX (사용자 행동)적으로 개선이 가능하다면 이 또한 QA로써 품질과 연관되어 생각해 봄직하다. 다수가 아니다고 하면 그에 따를 줄도 알아야 한다. 다른 한 편으로는 여러 가지 현상이 섞여 진실이 오염될 수도 있다는 가능성을 열어둬야 한다.
2. 이미 어디선가 해결 중인 문제일 수도 있다. 메신저로, 메일로, CS로, 커뮤니티 동향 등으로 버그 소식을 접하고 재현을 시도해 보는 경우 나(혹은 QA팀)뿐만 아니라 이미 다른 누군가가 작업을 시작할 때도 있다. 이럴 때는 어딘가 작업 흔적이 없는지 찾아봐야 한다.
3. 여러 팀과 공유하면서 히스토리를 누적한다. 특히 메일에서 중요한 부분인데, 단순히 다른 팀 '제보자'와 '나'뿐만 이걸 알면 안 된다. PM팀이나 관련 개발팀, 기획팀 등 참조에 넣어 이런 업무가 진행되고 있음을 넌 지시라도 알려야 한다. 그래야 시급한 문제라면 리소스를 더 투입할 수도 있고 빌드 추가 대응도 있을 수 있다.
4. 버그가 발생하는 노출도를 잘 고민해봐야 한다. 일례로 전 회사에서 심각한 버그를 찾았지만 노출도가 높지 않아 그냥 넘어간 경우가 있다. 켜져 있는 화면에서 다음 단계로 진행이 안 되는 것인데 문제는 이 버그의 조건이 문제 화면에서 한 달간 아무 행동도 하지 않는 것이다. 심각하지만 현실적으로 이런 경우가 있을지 판단이 필요하다.
5. 심적인 마감 시간을 둔다. 대략적으로라도 데드 라인이 있어야 한다. 언제까지고 하나의 문제만 붙들고 있을 수 없다. 이미 다른 업무들도 있기 때문에 짧은 시간이라도 집중해서 재현 시도를 하고 그것이 안되면 여러 형태로 확인한 항목을 남겨두면 된다. 내가 아니더라고 다른 팀원이나 다른 팀에서 문제를 해결해 줄 수 있다.
버그에는 상상도 못 한 이유들로 발생한다. (이건 추후 다른 곳에서 다룰 예정이다.) 때문에 나는 수많은 가정을 위해 말도 안 되는 이야기를 만들 필요가 있다고 본다. 무엇보다 그것이 가끔 발견하는 업무의 재미다. 다음은 몇 년 전에 김영하 작가가 회사에서 특강을 할 때 해준 이야기다. 정확한 워딩은 기억나지 않지만 그 맥락을 남겨본다.
"할리우드 작가들은 뻔한 이야기의 진행을 제거하기 위해서 예전에는 리스트를 많이 만든다고 한다. 남자가 여자에게 차였을 때 할 수 있는 일을 100가지 써봤다고 한다. 쭉 쓰다 보면 뒤로 갈수록 참신한 것이 나온다. 아예 거꾸로 접근하는 방법도 있다. 이런 일은 하지 않을 것 같은 상황을 상상해 보는 것이다. '실연을 겪은 남자가 볼링장에 가서 볼링 30게임을 친다. 그러다 팔이 빠진다.' 말도 안 되는 것을 써보는 것이다. 오히려 한 번도 생각해보지 않은 것들을 할 필요가 있다. 이런 것들이 나중에 보면 꽤 참신한 것들이 있다."
재현 요청이 온다는 것은 누군가 참신한 행동을 게임 안에서 한 것이고, 예측 불가능 한 이야기가 더 매력 있는 것처럼 이런 버그들이 나에게 매력으로 다가온다. 서비스되기 전 업무 중 발견하면 더할 나위 없다.