프로젝트와 QA의 관계

iT업계에서 쓰이는 프로젝트의 의미는 사업과 일맥상통한다.
즉, 소프트웨어를 개발하는 회사인 경우 해당 소프트웨어의 타이틀이 프로젝트가 되는것이고 게임회사인 경우에는 게임 자체가 프로젝트라고 볼 수 있다.

그렇다면 그 프로젝트에서 QA는 어떤일을 맡아 직무를 수행하게 되는것일까? 품질 보증을 담당하는 QA가 할 수 있는 역할은 어디까지인걸까?
 
답은 회사에서 요구하는 업무방식에 따라 차이를 드러낸다.
어떤 회사에서는 단순 테스팅을 요구할때가 있는 반면, 또 어느 회사에서는 테스팅의 영역을 넘어 소비자의 시선으로 바라보았을 때 불편사항이 생길만한 요소 즉, 컨플레인이 발생할만한 지점을 짚어달라는 요구도 있다.

전자의 경우에는 프로젝트를 담당하는 기획자가 설계한 내용과 프로그래머가 구현한 기능들이 올바르게 동작하는지에 대한 검수과정, 또 특이사항이나 버그등 결함을 찾아내는데에만 집중을 하는 케이스이다. 해당 검수과정을 통해 발견되는 버그들을 수정하고 적용하는 과정에 있어서는 큰 절차없이 진행이 되기 때문에 일정에 큰 무리가 가지 않는다.

후자의 경우는 조금 다른 케이스이다. 단순 테스팅을 넘어 프로젝트의 품질쪽까지 생각해야하는 QA는, 이미 완성되어있거나 완성과정을 밟아나가는 프로젝트의 개선사항을 찾아 고객의 불편함을 미연에 방지해야하는 역할을 하기도 한다. 미처 고려되지 않은 부분이나 설계되지 못한 것, 변수에 따른 예외사항, 사용자의 연령층을 고려한 컨텐츠나 불친절한 UI등 개선사항 관련 의견을 내놓게 된다.

그 이후엔 PM(프로젝트 매니저)이 짜놓은 스케쥴외에 추가적인 업무증가가 발생하고(계획에 없던 일이 새롭게 생긴다) 이는 계획에 차질이 발생하는 부분이므로 시간을 넉넉히 잡고 운용되는 프로젝트가 아니라면 보통은 전자의 과정을 밟는 회사가 많다.

*이는 회사의 재정문제 혹은 개발인력 문제와 연관이 있을 가능성이 높다.
https://youtu.be/MH19NNrEHiU
[개발인력난 관련 뉴스]

https://www.jobplanet.co.kr/contents/news-3903
[타 직군 대비 높은 개발자 연봉]

간혹, 예외사항과 기획내용이 프로젝트에 반영되었을 때 사용자에게 전달 될 피드백을 미리 받기 위해, 기획회의단에서 QA를 참석시키는 경우도 있다. (이를 경험해본 나로써는 좋은 결과들을 내놓는 경우가 많았기에 긍정적으로 판단하고 있다)

다른 케이스로는 'QA의 역량이 뛰어날 때'이다.
굳이 QA에게 요청하지 않더라도 연차가 어느정도 쌓이거나 프로젝트 이해도가 높은 QA의 의견은 곧 사용자의 의견으로 받아들여지는 경우가 있다. 물론 모든 케이스를 말하는 것은 아니다. 의견만 있다고 QA의 의견이 받아들여진다면 프로젝트는 산으로 가버리는것이 불보듯 뻔한 일이기 때문이다. QA의견은 단지 의견으로만 끝나는 케이스가 다반사이지만 앞서 말했듯 QA의 역량이 뛰어나다는것은 고객의 니즈를 정확히 캐치하고 프로젝트의 이해도가 높은 경우의 이야기이다.
적용 사례의 예를 들어보자.

한 RPG 게임에서 새로운 무기 강화 시스템을 내놓게 되었다. 무기를 강화하면 캐릭터가 몬스터에게 타격하게되는 타수에 비례하여 추가 데미지가 들어가는 형태의 시스템이 개발중이다.
- A캐릭터의 스킬셋은 능력치에 비례하여 높은 계수를 가지지만 적은 타격 횟수를 가진 스킬이다.
-B캐릭터의 스킬셋은 능력치에 비례하여 낮은 계수를 가지지만 많은 타격 횟수를 가진 스킬이다.
(*캐릭터가 사용 할 수 있는 스킬의 빈도수나 쿨타임, 딜레이, 시전속도등은 여기서 고려하지는 않겠다)

위 강화 시스템이 각 캐릭터에게 가져올 효과를 대입해본다면 강화수치가 높으면 높을수록 추가데미지의 수치도 올라가게되어, 타수가 많은 캐릭터의 효율이 압도적으로 높아진다. 
즉, 프로젝트에 대한 이해도나 게임플레이 경험이 많은 QA는 강화 시스템이라는 컨텐츠, 로직, 시스템QA만 하는것이 아닌 밸런스적인 측면까지 고려하여 사용자에게 전달될 효과나 조치하지 않은 상태에서의 발현될  결과값을 캐치해낼 수 있다는 것이다. 만약 위 내용을 예측하지 못한 상태에서 사용자에게 배포되었을 경우에는 어떤 결과를 초래할까?

첫째로 A캐릭터의 효율 하락으로 사용자의 니즈가 줄어들게 될것이다. 그렇게되면 A캐릭터와 연관된 장비나 아이템등의 가치가 내려갈것이고 이는 게임 내 시장경제에 영향을 미칠 수 있다. 심각한 상황까지 간다면 A캐릭터를 키운 유저들은 B캐릭터를 다시 키워야 하거나 극단적으로는 게임을 접는 상황까지 발생 할 수 있다.

물론 위와 같은 상황이 일어났더라도 상황을 바로잡을 수 있다. 밸런스적인 측면을 고려하여 시스템의 개편이 이루어지거나 게임의 개발방향성을 책임지는 PD나 기획파트, 운영파트에서 효율적이지 못한 부분에 대해서 인정하고 유저에게 개발방향에 대해서 나아가야할 방향을 제시 할수도 있다.

그러나 사용자는 이미 경험을 했다. 좋은 품질을 바라는 플레이어들에게 낮은 품질을 경험하게 된것이다. 한 번의 경험이 프로젝트의 품질을 저하시키진 않는다. (단, 결함의 정도에 따라서는 그럴 수 있다)
그러나 이러한 품질저하의 경험 횟수가 잦아지고 반복될수록 유저의 평가는 냉정을 넘어 극단적으로 변모하게 된다. 게임은 수많은 대체제가 존재하고 품질이 좋은 다른게임도 얼마든지 있기 때문이다. 단순히 애정으로만 게임을 플레이 할만큼 유니크한 캐릭터 컨셉이나 장르가 아니고 게임에 대한 매몰비용이 낮은 유저로부터는 쉽게 버림받을 수 있다는 이야기이다.

https://m.gamevu.co.kr/news/articleView.html?idxno=27709
[단순 외형적 이슈라 해도 저하된 품질의 경험이 많은 경우 생각보다 큰 파급효과를 불러올 수 있다]

‘로스트아크’ 중국 그래픽 일부가 한국에 적용, 금강선 CCO가 직접 해명

결론적으로 위 내용을 함축해서 짧은 문장으로 표현을 한다면 'QA는 리스크 관리를 항상 염두에 두어야 한다.'라고 말 할 수 있겠다. 프로젝트의 품질은 곧 프로젝트의 생명과도 같다.

이미 레드오션이 되버린 게임업계에서 게임 회사들의 경쟁력과 생존성은, 프로젝트의 품질을 높이기 위한 노력과 비례한다고 보여진다.