저에게는 게임 개발에 QA라는 직군이 있는 줄도 몰랐던 시절이 있었습니다. 사실 게임은 그냥 코드를 뚝딱하고 짜면 짠! 하고 만들어지는 것이라고 생각을 했다는 것이 더 정확할 겁니다. ‘개발자 = 똑쟁이’ 라서 저절로 양질의 제품이 만들어지겠지... 하는 바보 같은 생각이었죠. 우연한 기회로 QA를 업으로 삼고 나니, 테스트라는 것이 정말 소프트웨어 개발에 있어 상당히 중요하구나라는 것을 소름 돋을 정도로 느끼게 되었습니다. 생각보다 게임에는 고쳐야 할 것들이 엄청나게 많거든요.
우선 QA 활동이 게임 개발에 왜 필요한지는 아래 문장으로 간단하게 요약할 수 있을 것 같습니다.
“QA활동을 통해 게임 내 잠재위험과 문제점을 사전에 찾아내어, 제품의 품질을 보증하고 릴리즈 이후 발생하는 비용을 감소시킬 수 있다.”
위 문장이 전반적인 QA활동에 대해 적절히 잘 표현한 것 같습니다. 그렇지만 이렇게 정리하면 너무 식상합니다. 마치 면접장에서 많이 들을 수 있는 대답 같아 보이지 않나요?
그렇다면 좀 더 깊게 생각해봅시다. 만약 “그래서 너의 업무가 프로젝트 안에서 어떤 가치를 창출하는데?”라는 공격적인 질문을 갑자기 받게 되었다면, 빠르고 정확하게 저희의 가치를 상대방의 뇌리에 각인 시킬 수 있으신가요? 몇 년 전의 저였다면, 아마 흔들리는 동공과 떨고 있는 꽉 쥔 주먹만 보여주었을 것 같습니다.
게임 QA로 오랫동안 일하다 보니 가끔 시간이 날 때 마다 ‘나는 프로젝트에서 어떤 가치를 가질까?’하는 질문을 떠올립니다. 그래서 이번 포스팅은 그것에 대한 나름의 답을 같이 이야기하고자 합니다. 테크니컬한 부분은 없습니다만, 특별히 게임 QA를 직업으로 삼고 애정을 가진 많은 분들이 자부심을 가질 수 있도록 조금이나마 도움이 되었으면 합니다.
#1. 게임에서의 품질 기준
QA가 Quality Assurance 인 것은 모두 잘 알고 계실겁니다. 직역하면 역시나 ‘품질 보증’이구요. 어쨌든 단어풀이는 이해가 되는데, 그에 비해 예전부터 명확치 않았던 것이 있었습니다. 우리의 테스트 활동이 어떻게 품질을 ‘보증’하는 것일까요? 농축산품처럼 품질등급을 도장으로 쾅 찍는 것도 아니고, 공산품처럼 6시그마(σ) 품질관리를 활용해 불량률을 정확하게 평가할 수 있는 것도 아닌데 말이 죠. 소프트웨어 제품이라는 두루뭉술한 대상에 대해서 우리는 어떻게 품질을 평가하고 있는걸까요?
이에 대한 정의는 사람에 따라 조금씩 다르겠지만, Software Testing Help 사이트에서 설명한 내용이 오늘 포스팅의 주제에 부합할 것 같습니다.
소프트웨어 품질보증(Software quality assurance, SQA)은 모든 소프트웨어 공학 프로세스, 방법 및 작업 결과물을 모니터링하여 정의된 표준을 준수하는지 확인하는 수단이자 관행이다.
출처 : https://www.softwaretestinghelp.com/software-quality-assurance/
여기서 말하는 QA는 “정의된 표준을 준수하였는가?”에 초점을 맞추고 있습니다. 그렇다면 우리는 먼저 게임 서비스에서 ‘정의된 표준’이 무엇인지 정리해야 할 것 같습니다.
ISTQB Foundation을 공부하셨다면 ‘요구사항’에 대한 내용을 기억하실 겁니다. 이는 사용자가 제품에 원하는 여러가지 기능/비기능적 사양을 뜻합니다. 이 요구사항이 제대로 충족되었는지 인수 테스트를 거친 다음 비로소 제품이 사용자에게 전달되게 됩니다. 즉, 사용자 요구사항이 명확히 정의되면서 표준(Standards)이 되고, 이 기준선을 통과한 상태를 우린 품질이 보증된 상태라고 볼 수 있을 것 같습니다.
그럼 라이브 서비스되는 게임에서 유저 요구사항은 무엇일까요? 이에 대해 ‘확실하게 정의할 수 없다’는 것이 제 의견입니다. 게임을 이용하는 유저들은 다양한 의견을 표출합니다. 서로 상반되어 충돌이 야기되는 의견도 심심치 않게 나오곤 하죠. 주류의견은 있을 수 있어도 통일된 명확한 요구조건은 나오기 힘든 환경이라고 볼 수 있습니다. 게다가 라이브 서비스라는 특징 때문에 이 요구사항들은 각종 조건에 따라 변경되거나 철회될 수도 있습니다. 이는 게임의 ‘재미’가 주관적인 측면이 강한 평가 요소이기도 하고, 또한 게임 서비스는 특정 기능이 필요한 사용자에게만 제공되는 것이 아닌 불특정 다수에게 배포되기 때문에 발생하는 필연적인 현상이라고 생각합니다.
결국 이런 상황에서 개발진은 선택의 기로에 놓이게 됩니다. 모든 의견은 소중하지만 우리의 시간은 유한하고 일정은 빡빡합니다. 따라서 먼저 VOC들의 우선순위를 설정하여 목록화 하고 분석 해야 할 필요성이 생깁니다. 어쩌면 개발 여건에 따라 약간의 타협이 필요할 수도 있습니다. 이렇게 되면 유저의 요구사항에는 ‘개발진의 의도’가 자연스럽게 반영됩니다. 요구사항을 명확하게 정의할 수 없기 때문에 하릴없이 자체적으로 가치를 부여하게 되기 때문이죠.
그래서 게임 개발진은 유저들과 소통해야 하는 의무를 동시에 지게 됩니다. 이런 의도가 어떤 방식으로 반영되었고 어떤 이점이 있는지, 어떤 문제점을 예상하는지, 앞으로의 계획은 어떤 지에 대한 상세한 소명이 있어야 한다는 뜻 입니다.
#2. QA활동의 가치
그럼 이제 QA활동이 제품에 어떤 기여를 하는가에 대한 내용을 고민해볼 차례입니다.
사실 제 결론은 간단합니다.
“게임 개발진과 유저 간의 원활한 소통을 위해 QA는 다양한 활동을 통하여 제품의 장애(Failure)를 최소화 하고, 소통의 질을 높이는데 기여한다.”
이것을 한번 풀어서 설명해보겠습니다.
유저분들이 보내주시는 피드백 중 가장 기분이 좋은 건 단연 게임이 재밌다는 의견일 겁니다. 또는 ‘유저를 배려한 UI’, ‘게임 그래픽이 너무 귀엽다’ 같은 의견도 입가에 미소를 짓게 합니다. 이런 긍정적인 피드백이 있는 반면 ‘밸런스가 엉망이다’, ‘보상을 얻기 너무 힘들다’ 같은 따끔한 질책의 피드백도 다수 받게 됩니다. 다만 이 두 상반된 피드백들의 공통점이 있다면 적어도 ‘제품(게임)’에 기반한 피드백이라는 것 입니다.
만약 여기에 ‘버그’가 눈치 없이 끼어든다면 어떻게 될까요? 아마도 저희는 제품기반 피드백을 받기 어렵게 될 확률이 높아지게 될 것입니다. 소프트웨어, 특히 게임에서 버그는 사용자 경험을 해치는 가장 명백한 원인입니다. 사소한 버그는 (어쩌면 웃고 넘어갈 수도 있겠지만) 팀의 전문성을 낮게 평가하게 되는 계기가 됩니다. 거기에 이용이 불가능하거나 밸런스를 무너트리는 심각한 버그는 유저의 게임 플레이 의욕을 현저히 저하시킵니다.
이처럼 버그는 경중에 관계없이 유저에게 부정적인 경험을 전달할 수 밖에 없습니다. 이런 상태에서 유저가 제품에 기반한 피드백을 온전히 전달할 수 있을까요? 아마도 버그에 대한 제보와 하소연, 분노를 표출하느라 정작 게임성은 눈에 들어오지도 않을 것 같습니다. 물론 버그가 많아도 제품에 대한 적절한 피드백을 주는 유저분들이 반드시 계실 것 입니다. 하지만 개발진은 이슈에 대한 관리없이, 요행에 가까운 의견을 보고 판단해서는 안됩니다.
앞서 설명했듯이 게임 서비스는 다수의 유저에게서 다양한 피드백을 전달받기 때문에, 확실한 품질 표준을 기대하기 힘든 환 경입니다. 개발진은 유저와 서로 개발 위탁계약을 통해 제품을 제공하고 있는 것이 아니므로, 적어도 유저들에게 선보일 사양들에 대해 내부적으로 명확한 품질 기준을 설정해야 합니다. 여러가지 방법이 있겠지만 가장 쉬운 방법은 ‘기획서 기반 테스트 케이스’를 작성하는 것 입니다. 여튼 이렇게 설정된 기준을 넘었다면, 우선은 최소한의 품질이 보증된 상태라고 할 수 있을 것 같습니다.
품질이 보증된 상태의 제품은 개발진의 의도를 명확히 설명할 수 있는 훌륭한 기반이 됩니다. 상점에서 물건을 사는 상황을 생각해봅시다. 물건의 기능을 상점주인이 열심히 설명하고 있는데 들고 있는 물건을 보니 여기저기 흠집이 보이고, 심지어 손때까지 타서 꼬질한 상태라면, 그 물건이 기능상 아무리 좋아도 사고 싶은 마음이 사그라듭니다. 그러면 그 때부터는 말이 반대쪽 귀로 빠져나가면서 ‘그냥 빨리 집으로 가야겠다…’ 라고 되뇌이며 어색한 웃음과 함께 재빨리 자리를 피할겁니다.
위 예시처럼 제품이 말끔해야 개발진도 유저에게 명확한 개발의도를 전달할 수 있는 기회가 생깁니다. 버그 때문에 여기저기 너덜너덜한 게임을 보여준다면, 제 아무리 멋지고 재미있는 게임을 만들어도 유저들은 너덜너덜한 부분에 대해서만 토로하게 될 것 입니다.
더 나아가 라이브 서비스 게임은 ‘발전 가능성’이라는 특성을 품고 있습니다. 이 가능성은 양질의 피드백으로부터 활기를 부여받기 때문에, 이런 피드백이 없다면 게임은 방향을 잃고 누구도 만족시키지 못하는 쪽으로 흘러갈 가능성이 높아질 것이라 생각합니다. 결론적으로 QA란 ‘소통’의 질을 극대화한다는 가치를 창출하기 위해 범단계적인 종합 품질 보증 활동을 수행하는 것이라고 정리할 수 있겠습니다.
#3. 마치며
이처럼 QA활동이 단순 ‘버그 찾기’에서 쓰임을 다하는 것이 아닌, 개발진과 유저가 제품에 기반하여 건강한 피드백을 주고받을 수 있는 기틀이 되어줄 수 있다는 것을 나름대로 설명해보았습니다. 저는 그래서 QA가 개발 단계에서는 릴리즈 전 ‘마지막 수문장’이지만, 릴리즈 후에는 유저에게 선보이는 ‘첫인상’ 포지션을 지니게 된다는 점을 알리고 싶습니다. 그러므로 테스트 업무가 모두 종료되었을 때 손 털고 끝났다며 휴식하는 것도 좋지만, 버그로 인해 받을 수도 있었던 소중한 의견들을 받지 못하는 사태가 일어나지 않게끔 모니터링과 후속 대응에도 노력을 기울여야 할 것 입니다.
이렇게 되면 포스팅 초반 QA활동의 요약에서 언급한 ‘비용 감소’에 실질적으로 도움이 됩니다. 비용은 단순히 ‘돈’이 아닌 개발진의 시간과 노력을 포함한 개념입니다. 기획 방향성을 초반에 잘 갖출 수 있다면, 남은 리소스는 개발 품질에 더 투자할 수 있게됩니다. 이 때 유저들의 피드백이 좋은 참고자료로서 사용됩니다. 제품에 대한 진솔한 피드백이 많으면 많을수록 기획 방향성 설정에 이점이 되는 것은 당연한 이치가 아닐 수 없겠습니다. 결국 좋은 QA활동의 결과가 좋은 유저 피드백을 생산하고, 이것을 바탕으로 개발진은 좋은 기획을 창출하여 더 품질에 노력을 쏟을 수 있는 선순환 구조를 만들어 냅니다.
그러므로 QA로서 일하는 사람들은 버그를 찾는 것은 물론이거니와, 제품에 대한 깊은 관심 을 가지고 유저관점에서 분석하려는 노력이 필요합니다. 이는 프리-프로덕션 단계부터 포스트-프로덕션까지 전단계에 걸쳐 유저에게 불편함을 줄 수 있는 모든 요소를 점검 해야함을 방증합니다.
물론 이런 활동은 쉽지 않습니다. 생각보다 게임은 크고, 방대하며, 복잡합니다. 고도로 발달한 AI가 아닌 이상 실수하며 놓치는 부분도 분명히 생기기 마련입니다. 그러므로 더더욱 유저들의 의견에 대해 귀 기울일 필요가 있습니다. 실수는 용서해도 방치와 기만은 용서가 되지 않을테니까요.
이 밖에도 세상에는 훌륭한 QA 엔지니어들이 더 좋은 가치를 만들어가고 있습니다. 그저 드리고 싶은 말씀은, QA의 활동이 프로젝트와 유저에게 적지 않은 가치를 창출하고 있다는 점, 그리고 유저 관점에서 생각하는 마음가짐을 가지자는 점입니다. 언제나 좋은 업데이트를 위해 고생하는 모든 QA 직군과 개발진에게 이 글을 바칩니다.