PTW 몬트리올에서 QA를 담당하는 디엔 커티스(Deanne Curtis)는 수많은 게임을 세계에 알리는 데 도움을 주었습니다. 디엔은 직장 생활을 해오면서 여러 파트너의 워크 플로에 대해 파악하고 공통점을 발견했습니다. 그것은 바로, 일반적으로 QA는 프로세스 전반에 걸친 필수 요소가 아니라 프로세스의 가장 마지막 단계로 취급된다는 것입니다. 다음은 2022년 10월 19일, 캐나다 몬트리올에서 열린 MEGAMIGS에서 디엔이 발표한 내용을 발췌한 것입니다.

이따금 인증 과정 중에 QA는 필요악 취급을 받아, 제작 파이프라인의 계획 단계에서 의도적으로 회피되는 경우가 많습니다. 관리자들 또한 QA가 필수라는 것을 알고 있지만, 대개 출시 전 마지막 단계에서 진행됩니다. 하지만 디엔은 계획 초기 단계부터 QA를 적극적으로 포함하여 더욱 효율적인 개발 사이클을 도출하고 더 높은 품질의 게임을 출시해야 한다고 주장했습니다.

디엔은 조사를 통해, QA 담당자는 프로젝트 전반을 다루기 때문에 일반적인 관점에서 전문가보다는 제너럴리스트로 간주되므로 이러한 현상이 발생한다는 사실을 발견했습니다. 누구나 할 수 있는 작업이라고 여겨지므로 실제 전문 지식을 발전시킬 때까지 아주 오랜 시간이 걸리는 신입 직원이 배치되는 것입니다. 심지어는 더 나아가서 생산적인 작업이라기보다는 개발 업무를 비평하는 존재로 여겨져서 무시당하는 경우도 많습니다.

시작부터 QA를 제작 계획에서 배제하게 된 데는 이러한 부정적인 인식이 한 몫 합니다. 적절한 준비가 뒷받침된다면 QA는 진행 중인 프로젝트에 대한 지침이 되어 주므로 조기에 오류를 발견하여 수정할 수 있게 됩니다. 이는 결과적으로 시간 절약으로 이어지며, 예정된 출시일 바로 직전에 납기일을 놓치는 일을 피할 수 있습니다.

대부분의 게임 개발자와 퍼블리셔의 경우, 인증을 목표로 합니다. 어떤 게임도 인증받지 않고는 출시될 수 없기 때문이죠. 인증은 목표 플랫폼의 모범 사례를 준수해야 하며, 인증을 획득하려면 완수해야 하는 필요 요건 체크리스트가 있습니다. 하지만 적절한 계획 없이는 모든 체크 박스를 완료했는지 확인하기 위해 개발의 끝자락에서 정신없이 서둘러 달려들어야 하는 일이 생기기도 합니다. 이 때문에 절차는 엉성해지고, 팀원들은 스트레스에 시달리며, 결국 최종 게임의 품질은 떨어지는 것이죠.

인증을 후순위로 처리하면 불필요한 위험과 불안정을 초래하고, QA 팀의 활용도를 떨어뜨려 시간 낭비와 비용 증가를 야기하며, 부서 간 지식 공유를 저하시킬 뿐 아니라 전체 게임을 샅샅이 파악하고 있는 QA 팀 직원이 LiveOps 팀으로 배치될 기회를 놓치게 될 수도 있습니다. 이는 결국 플레이어 지원 부서가 바빠지는 결과를 낳게 될 것입니다.

디엔은 조기에 QA를 적극적으로 수행한다면 더 나은 인증 결과를 얻을 수 있다고 주장합니다. 왜 그럴까요? 올바른 QA를 포함한다면 다음과 같이 다양한 가치를 얻을 수 있습니다.

그렇다면 QA를 포함하여 진행하는 최선의 방법은 무엇일까요? 먼저 계획의 초기 단계부터 핵심 팀의 일부로서 QA가 수반되어야 합니다. 전체 프로세스 전반에 걸쳐 QA를 확인할 수 있다면 큰 문제가 되기 전에 작은 문제를 식별하고, 진행하는 동안 생길 수 있는 장애물을 미연에 방지하는 데 도움을 줍니다.

QA 팀 구조를 이해하는 것이 중요합니다. 프로젝트가 시작되면 디엔은 고객과 만나서 함께 전략을 수립합니다. 고객의 니즈에 따른 최선의 QA 모델을 제안하고, 고객에게 가장 적합한 각 분야의 전문 지식을 가진 테스터를 선택합니다.

팀 구조에는 기본적으로 2가지가 사용됩니다. 모놀리식 팀은 어떤 분야에도 특정되지 않는 다수의 테스터를 활용합니다. 이 경우, 종종 '폭포' 방법론(프로젝트를 순차적으로 진행하는 것으로 QA가 마지막 단계)을 사용하여 프로젝트를 진행합니다. 이러한 종류의 팀 구조는 품질보다 테스터의 수를 더욱 선호하나 항상 원하는 결과를 얻지는 못합니다.

반면, 적은 수의 전문 테스터는 각 프로젝트의 필요에 따라 효율적으로 배치될 수 있습니다. 예를 들어 일부 테스터는 소프트웨어 QA가, 다른 테스터는 개발 QA가 전문 분야일 수 있습니다. 이때 프로젝트는 '애자일' 방법론을 사용하여 진행되는데, 테스터가 고객의 팀에 완전히 융화될 수 있으므로 최상의 결괏값을 도출하고 각 팀원들의 기술을 최대한 활용할 수 있습니다. 이러한 체제를 통해서 PTW와 고객은 전반적으로 더욱 효과적으로 협업하고 소통할 수 있게 됩니다.

종종 저희의 전문 테스터들은 고객의 개발팀에 융합되어 고객의 제작팀, 개발자, 내부 QA 팀 및 팀장들과 직접 작업하곤 합니다. 이러한 테스터는 주니어부터 중급자까지 구성되어 있으며, 각기 다른 코딩 언어에 익숙한 경우 개발팀처럼 일하기도 합니다.

현재 PTW 몬트리올의 팀에서는 4개의 내부 QA팀을 운용하고 있습니다. 한 고객을 위해 시험적으로 시작되었던 이 내부 팀 모델은 고객이 결과에 아주 만족하면서 더 많은 팀을 출범하게 되었고, 현재 다른 고객에게도 적용되고 있습니다.

한번 팀 구조가 결정되면 프로젝트를 위해 팀을 유지 및 관리해야 합니다. 각 팀은 멘토링을 비롯하여 진행 중인 산업 지식을 쌓는데 언제든지 도움을 받을 수 있습니다. 이전의 개발 캠페인에서 익힌 노하우는 큰 가치가 있으며, 모든 관련 직원을 더욱 효과적인 프로세스로 이끌 수 있습니다.

때로는 외부 협력업체를 고용하는 것이 가장 좋은 해결책이 되기도 합니다. 이러한 파트너들은 상당한 유연성과 전문 지식, 안정성을 제공할 수 있습니다. 제3자가 개발을 맡으면 다른 팀들은 자신들이 가장 잘하는 요소에 집중할 시간을 확보할 수 있게 됩니다. 파트너는 다음과 같은 질문을 통해 올바른 결정을 내려야 합니다.

• 이 프로젝트에 특히 필요한 것은 무엇입니까?
• 우리 팀에게 필요한 지식 정보가 있습니까? 아니면 전문가가 필요합니까?
• 우리는 출시 시 필요한 LiveOps를 지원할 수 있습니까?

일단 이러한 특성이 결정되고 나면, 모든 협력업체가 동일한 서비스를 제공하지 않으므로 최상의 서비스를 찾기 위해 반드시 실사를 해야 합니다. 협력업체를 찾고 나면 잘 숙고하여 외부 팀을 프로세스에 통합시키는 것이 중요합니다. 접촉점이 명확해야 정확한 채널을 통해 의사소통이 흐르듯이 이루어질 수 있습니다. 반드시 지침 문서에 완전히 액세스할 수 있는 권한을 부여하고, 초반부터 프로젝트의 범위를 정의해야 합니다. 프로젝트 관리자는 항상 변동이 있을 경우와 변동을 가정할 경우에 대비해서 작업 방향을 조정해야 합니다.

마지막으로, 전체 프로젝트에서 QA가 다른 팀원들과 어우러지는 것이 중요합니다. 팀장은 어떻게 이러한 조직 문화를 구성할 수 있을까요? QA는 겉도는 것이 아니라 전체 프로세스의 가치 있는 구성 요소라는 것을 증명하는 방식으로 설득해야 합니다. 기꺼이 프로젝트 자체의 구조를 받아들여야 합니다.

누군가에게는 신뢰할 수 있는 프로세스로 급진적인 변경을 하는 것처럼 보일 수도 있지만, 올바르게 구현되고 나면 QA를 조기에 포함해야 하는 가치는 최종 제품의 품질 그 자체로 증명될 수 있습니다. 더 나아가서 개발 파이프라인 전체에 걸쳐 QA를 포함하면 비효율적인 요소를 드러내고 합리화를 촉진하여 일관되고 표준화된 프로세스를 형성하며, 필요한 경우 ad hoc 변경을 허용할 수 있게 됩니다.