게임업계에서 품질관리(Quality Assurance, 이하 QA)의 중요성을 부정하는 사람은 없다. 좋은 게임, 좋은 경험은 멋진 기획 뿐만 아니라 훌륭한 마감에서도 나오는 것이니까. 하지만 실제로 업계에서 QA가 중히 여겨지냐고 물으면 아리송하다. 기획한 것을 만들기에도 빠듯한 인력과 시간. 현실적으로 QA는 개발 마지막 단계에서나 짬내서 잠깐 하는 통과 과정에 가깝다.
이런 각박한 작업환경 속에서 그나마 효율적으로 제품을 관리하기 위해선 어떻게 수를 짜내야 할까? 넥슨네트웍스 황우람 팀장은 조직 차원에서 예상되는 리스크를 선별하고 이를 집중 관리하라고 조언한다. 그의 '게임QA에 리스크 기반 테스팅 이론은 적용 가능한가? - RPG에 대입한 TMMi의 이상과 현실' 강연을 정리했다. /디스이즈게임 김승현 기자
'리스크 기반 테스팅'을 말하기 전에 짚고 넘어가야 할 것이 있다. 본래 최선의 QA는 특정 요소만 집중하는 것이 아니다. 오히려 프로젝트 시작 전부터 테스트 조직이 세팅돼 있어, 프로젝트 내내 개발팀과 협업하고 프로젝트 후에도 이때 얻은 결과물로 지속적으로 결함을 예방하고 프로세스를 최적화하는 것이 이상적이다.
실제로 이런 QA 관리 단계를 인증하기 위한 TMMi라는 지표도 존재한다. 사실 황우람 팀장도 이 TMMi 5단계를 달성하기 위한 TF에 속해있다. 나름 TF 딴에서 TMMi 5단계를 위한 정책도 수립하고 실무 적용을 위한 연구도 했지만, 곧 현실과 부딪혔다. 지금의 조직은 현실적으로 TMMi 2단계도 만족시키기 힘든 인력과 자원을 가지고 있었다.
■ 사람이 없다면 리스크에 집중하라! 리스크 기반 테스팅
황 팀장은 목표를 조금 틀었다. 일단 TMMi 2단계라도 달성해보자. 그러기 위해서 선택한 것이 '리스크 기반 테스팅'이었다.
리스크 기반 테스팅이란 '예상되는 위험을 사전에 정의하고 분석해, 이에 맞춰 테스트와 회피 전략을 세우는 것'이다. 미리 예상되는 위험 요소를 선별하기 때문에 QA자원이 적을 때 효과적인 방법이다. 단, 이 '위험 선별'은 개발과 운영, 사업 등 다양한 조직이 함께 선별해야 하기 때문에 조직 차원에서의 '공감대 형성'이 중요하다.
TF팀은 먼저 이 이 공감대 형성을 위해 설문조사와 토론 등으로 구성원들의 의견을 듣고 대안을 마련하기 시작했다. 구성원 대부분은 '리스크 기반 테스팅'의 필요성과 효과성은 인정하고 있었지만, 여기에 필요한 자원을 걱정하고 있었다.
이에 TF팀은 각 조직 리더들을 모아 몇 시간짜리 워크숍으로 합을 맞추고, 리스크 기반 테스팅에 대한 오해는 직접 바로잡기도 하면서 공감대를 형성해갔다.
■ 리스크 목록, 게임업계에선 어떻게 짜야할까?
허나 아무리 공감대가 형성됐다고 하더라도, 실제 사례가 없으면 일이 진행되지 않는 법. TF팀은 공감대 형성 후, 리스크 기반 테스팅을 적용할 프로젝트를 찾기 시작한다.
결론부터 말하면 <마비노기 영웅전>이 당첨됐다. 게임이 가진 높은 인지도와 대중성 덕에 범용성 있는 데이터를 얻기 편하고, <마비노기 영웅전>팀 특유의 수평구조 덕에 팀 간 소통이 용이한 것이 선정 이유였다.
적용 프로젝트가 확정되자 리스크 선별 작업에 들어갔다. TF팀은 이 때 '1. 게임 자체의 구성요소인 그래픽/효과 등은 제외하자. 2. 개발뿐만 아니라 프로젝트 조직장 모두가 참여해 리스트업을 한다'라는 규칙을 세웠다.
그래픽 등 게임의 구성요소를 뺀 것은 이것이 너무도 중요한 요소이기 때문이다. 문제가 있으면 너무 눈에 잘 띄기 때문에, 반대로 보이지 않는 전투 디자인이나 스토리 등의 요소가 간과되기 쉽다. 때문에 TF팀은 리스크 요소를 추릴 때 일반전투/레이드전투/제작/보관 등 시스템 딴의 요소에 집중했다.
다양한 조직장이 참여하도록 한 것은 게임의 특수성 때문이다. 대부분의 게임 프로젝트는 조직 별로 분리되어 운영된다.
하지만 게임이 서비스 될 때 발생하는 문제점은 어느 한 조직에 국한된 것이 아니다. 버그 하나가 발생하더라도 개발에 대해 알아야 대응 시간을 알 수 있고, 사업에 대해 알아야 이에 대한 손실액을 계산할 수 있다. 때문에 TF팀은 리스크를 선별할 때 최대한 많은 조직장을 참여시켜 최대한 넓은 시야를 가질 수 있도록 신경 썼다.
■ 위기 관리, 품질 관리는 조직 모두의 일이다.
그 결과는 어땠을까? 먼저 이전보다 훨씬 체계적이고 조직적인 품질 관리가 가능해졌다. 이전의 QA는 서로 교류 없이, 자신만의 기준을 가지고 있었기 때문에 서로 원하는 것도, 이해하는 것도 달랐다. 하지만 조직 차원에서 리스크 목록을 공유하다 보니 관리자도, 실무자도, 심지어 다른 조직도 QA 결과물을 이해할 수 있었다.
또한 리스크 관리의 '허수'도 줄어들었다. 리스크 선별 전에는, 막연히 신규 콘텐츠에 리스크 관리가 집중되기 쉬웠다. 새로운 것이니 당연히 불안정할 것이라는 편견 때문이었다.
하지만 실제로 리스크 목록으로 관리를 해보니 예상 외로 신규 콘텐츠의 불안은 적었다. 간과했던 것은 적지 않은 신규 콘텐츠가 기존 콘텐츠의 강화, 개량형이라는 점이었다. 기존 요소를 활용하다 보니 예상보다 불안정성이 낮았고, 이를 깨달음에 따라 보다 효율적인 자원 투입이 가능해졌다.
물론 장점만 있었던 것은 아니다. 가장 아프게 느꼈던 것은 조직 차원의 QA 참여다. 아무리 각 프로젝트장을 QA에 참여시킨다고 하지만, QA팀은 게임의 매출액, 프로젝트의 개발 시간 등의 구체적인 데이터를 알기 힘들다. 그리고 이것은 위기 크기를 평가하거나, 위기 해결 일정을 짜는데 악영향을 준다.
때문에 황우람 팀장은 청중들에게 어떤 직무, 어떤 조직이더라도 QA에 관심을 가져줄 것을 부탁했다. "QA조직이 게임을 100% 파악하는 것은 불가능합니다. 그리고 이것은 효율적인 품질 관리, 위기 관리는 못한다는 것과 같죠. 모든 이해관계자가 QA에 관심을 가져준다면, TMMi 5단계도 우스울 정도로 멋진 품질 관리 환경을 만들 수 있습니다."
