[번역] 정말 프로젝트를 시작할 때부터 QA가 필요할까

늘 숨죽여 살고있는 QA들 사이에는 오래 전부터 전설처럼 전승되고 있는 주문이 하나 있다. “만약 우리가 프로젝트가 시작할 때부터 일을 시작했다면, <그런 일>은 절대 일어나지 않았을거야.” 캡틴 하인드사이트(Captain hindsight)[1]처럼, 모든 사람들이 QA가 도움이 된다는 것에는 동의하지만 결국 QA 없이 새로운 프로젝트를 시작하고는 한다.

자, 언제 QA가 조인해야 하는지에 대해 한 번 고민해 보자.

정말 QA가 프로젝트 초반부터 필요할까? 개발과 사업 관점에서 한 번 접근해보자. 게임의 컨셉을 잡고 프로토타이핑을 할 때는 사실 거의 테스트할 일이 없다. 그런데도 정규직 QA를 채용해야 하나? 물론 이 과정에서도 QA들이 무언가 공헌하고 아이디어를 제공할 수 있다. 하지만 이런 일들은 게임 기획자들도 할 수 있는 일 아닌가? 만약 다양한 사람들로부터 좀 더 많은 의견을 듣고 싶다면 이와 관련된 회의를 열거나 다양한 방법으로 피드백을 받으면 될 일이다. 프로토타이핑 기간 중에 QA가 필요한가에 대해서는 일부 논쟁이 있을 수 있지만, 만약 어느 정도 필요하다고 해도 개발자들이 스스로 테스트를 진행할 수도 있다. 이는 또한 개발자들에게 테스트를 수행하는 습관을 길러주어 향후의 테스팅에도 도움이 될 것이다. 정 안된다면 QA 리드 한 사람 정도만 커뮤니케이션 라인에 넣어두어도 충분할 것 같다.

팀에 QA가 있다는 것만으로도 품질을 향상시킨다. 

이런 이야기들은 늘 들어왔던 이야기 아닌가? 표면적으로는 이런 내용들이 아주 합리적인 것처럼 들리지만, 이는 QA가 단순히 플레이를 통해 버그를 찾아내는 것을 넘어서서 게임뿐만 아니라 게임 개발 프로세스에 대해서도 품질을 향상시킬 의무가 있다는 것을 무시하는 것처럼 들린다. 우리는 게임을 접하게되는 첫 고객이다. QA는 고객에게 전달되어야 할 게임의 품질이 어느 정도여야 하는지를 조정하고, 개발 조직이라는 기계를 원활하게 동작시키는 윤활유와 같은 역할을 수행한다. 개발 초기 QA는 프로젝트에서 QA를 어떻게 수행할 것인지에 대한 자신만의 전략을 모색하고 수립한다. 이 품질 전략은 프로그래머와 아티스트들이 게임 기획자가 만들어낸 아이디어를 표현하고 구현하는 것과 어우러져 프로젝트를 이끌어 나가는 원동력이 된다. 

프로젝트 초반부터 팀과 어울려 연대감을 형성하는 것도 중요하다. 팀은 서로 믿고 존경해야 한다. QA를 프로세스의 후반에 투입하게 되면 팀의 원동력에 영향을 미칠뿐만 아니라(지켜야할 새로운 원칙을 추가하는 것이 되므로) 이 시점에 QA들이 동료들의 존경을 얻으려면 힘든 전투를 벌여야만 한다. 지금까지 내가 일해왔던 팀을 살펴본 결과 나는 팀에 QA가 존재하는 것 만으로도 품질을 향상시키며 다른 이들이 가진 품질 기준을 높여준다는 믿음을 가지게 되었다. 단순히 QA가 보유한 업무 스킬 때문에 이런 일들이 벌어지는 것은 아니다. QA들이 옆에 있게 되면 개발자들은 그들이 개발한 기능들이 그들 자신의 로컬 버전 외에 다른 버전에서도 잘 동작하기를 자연스럽게 원하게 된다. 또한 정기적으로 이런 작업들이 수행되어 제품의 품질을 보장받고 싶어하기 때문에 자연스럽게 품질 기준이 올라가게 된다. 프로젝트의 초반부터, QA를 통해서 우리는 좀 더 최종 고객이 바라는 수준의 품질에 가깝게 접근할 수 있는 것이다.

창작 활동을 하는 사람들에게 직접 그들이 만든 작품을 직접 살펴보고 일부러 중요한 부분 하나를 빼도록 만든다는 것이 얼마나 우스꽝스러운 일인지 한 번 생각해보라. 

지금까지는 ‘QA가 팀에 필수적인 것은 아니지만 있으면 좋다’라는 말은 충분히 논쟁거리가 되어왔다. 실제 현업에서 QA들은 디버그 명령어를 만드는 작업에 참가하고, 개발을 위해 버그 리포터로서의 역할을 수행하고, 또한 개발의 지원을 받아 게임의 자동화 구조를 함께 설계하는 일을 해오고 있다. 독립적으로 어떤 일을 수행하기 보다는 함께 작업을 수행하고 있는 것이다. 프로젝트 초기에 QA가 참가해야 하는 이유는 단순히 버그를 찾아내기 위해서가 아니라 이슈를 사전에 방지하고 차후 유지보수가 용이하도록 개발 방향을 조정해 갈 수 있기 때문이다. 서비스로서의 게임이 부각되고 있는 최근에는 이를 통해 추후 테스팅에 투입되어야 하는 리소스를 상당히 줄일 수 있다는 장점도 제공한다.  

QA가 단순히 아티스트와 프로그래머의 작업을 체크하는 일만 하는 것이 아니라는 것을 늘 염두에 두어야 한다. 프로젝트의 초반일수록 빌드 시스템이 어떻게 구성되어야 하는지, 또한 지속적 통합 프로세스는 어떠해야 하는지, TDD는 어떻게 구현되어야 하는지 등을 살펴보는 것은 반드시 제대로 역량을 집중해 수행되어야 하는 일들이다. 이런 작업들을 통해 추후 테스팅에 대한 부담이 줄어든다면, QA들은 서비스에 적합한 수준의 커버리지를 확보하기 위한 프레임워크를 제안하고, 이를 통해 유관 부서가 적절한 리스크 수준을 결정하고 관리할 수 있도록 해 줄 것이다. 이런 작업들은 GDD(Game Design Documents)와 기술 문서를 작성하고 열람하는 것과 동일한 수준으로 계획되고 수행되어야 한다.  

이 글을 읽고 얻어야 할 단 하나의 인사이트가 있다면, 그것은 QA가 단순히 버그만 발견하는 사람들이 아니라는 것이다. 품질은 단기간에 만들어지는 것도 아니고 코드의 첫 라인이 작성될 때부터 만들어지는 것도 아니다. 늘 생활화된 임베디드 테스팅을 통해 테스터의 역할을 팀 내부에서 정립해야 한다. 게임 개발의 초반에 아티스트와 프로그래머, 기획자들만 모여 있다고 가정해보자. 이들은 모두 창조적인 예술가와 다름 아니다. 이들에게 그들이 만든 작품을 직접 살펴보고 그들 스스로 공들여 만든 부분을 부수도록 해야 한다면, 이 얼마나 우스꽝스러운 일이 될 것인가.