크라이텍 키예프 스튜디오 출장기 - QA 서밋에서 느낀 것들

 

 

지난 4월 첫 주 1주일 동안 키예프 스튜디오로 출장을 다녀왔습니다.

 

크라이텍의 각 지사에서 일하고 있는 QA 리드와 테크니컬 시니어들이 모여서 각자의 QA 프로세스와 경험을 공유하는 자리인 QA 서밋에 참가하는 것이 목적이었습니다. 제게는 우크라이나의 이국적인 풍광(물론 왜 장모님의 나라라고 불리는지도 확인할 수 있었고)도 인상 깊었지만, QA 업무와 관련된 좋은 팁과 사례들을 직접 보고 배울 기회여서 더욱 좋았던 것 같습니다.

 

QA 서밋 동안 다양한 주제의 발표가 진행되었고, 이 중 인상 깊었던 멘트들과 길지는 않았지만 스튜디오에 머물면서 느꼈던 QA에 관한 시각과 위상에 대해 정리해 보고자 합니다. 

PS> 이 글은 크라이텍의 공식적인 의견을 전달하는 글이 아닙니다. 어디까지나 제 개인적인 생각과 의견을 반영하고 있으니 오해 없으시기 바랍니다.

 

QA as a key player, not a substitution

키예프 스튜디오에 처음 출근해 QA 매니저의 안내를 받으며 스튜디오를 둘러볼 기회를 가지게 되었습니다. 여느 게임 개발 스튜디오답게 개방적이고 활발한 분위기가 곳곳에서 느껴졌습니다. 제일 처음 눈에 띈 것은 QA 그룹에 속해있는 인원들의 숫자가 상당하다는 것입니다. 매일 아침 다양한 그룹에 소속된 QA가 한 자리에 모여 스탠드 미팅을 가지는데, 리드들만 모이는 이 회의에 참가하는 인원이 10명이 넘습니다. 물론 각 파트별 인원 구성은 아주 다양하지만, 전체 스튜디오 인원 중 QA 인원들이 상당한 부분을 차지하고 있다는 사실은 주목할 만한 합니다.

QA가 차지하는 이런 양적인 비중 외에도, 프로세스 상에서 QA가 차지하고 있는 비중 역시 적지 않았습니다. 기획자 혹은 개발자들이 만들어낸 1차 산출물이 QA에게 전달되기까지의 시간이 제가 접했던 어떤 게임 개발 프로세스보다도 짧습니다. 각 QA들이 RnD, 서버, UI 등의 다양한 개발 그룹에 속해서 QA 업무를 진행하는 이유이기도 합니다. 실제로 업무 시간에도 항상 개발자들과 QA들이 수시로 복도에서, 자리에서, 혹은 회의실에서 머리를 맞대고 의견을 나누는 모습을 자주 볼 수 있었습니다. 거의 대부분 칸막이가 둘러쳐 진 자기 자리에서만 업무를 보고, 팀장이나 리드와 같은 고정된 채널을 통해서만 정보와 의사를 교환하는 국내의 일반적인 업무 환경과는 사뭇 다른 풍경이었습니다. 개발 프로세스 안에 QA가 임베디드 되어 있는 것을 당연한 것으로 받아들이고 마치 왼팔과 오른팔처럼 상당히 밀접하고 유기적으로 QA와 개발 업무가 관계를 맺고 있는 것이 인상 깊었습니다. 국내에서 하면 좋고 안 해도 회사 굴리는 데는 무방한 것으로 인식되고 있는 QA와는 근본적인 지위와 역할이 달라 보였습니다.

 

 

No way to crunch

첫 번째 발표에서 가장 인상 깊었던 문구입니다. 크런치 자체를 게임 업계에서는 어느 정도 필수불가결한 것으로 받아들이고 있는 것이 사실입니다. 하지만 QA 입장에서는 게임의 전체 품질을 저하시킬 수 있는 하나의 리스크로 보고 있는 것입니다. 특히나 테스트 업무가 프로세스의 마지막 부분에 과도하게 집중되는 것을 막기 위해, 짧고 반복적으로 빌드를 만들어 변경사항을 검증하고, 이를 통해 상시로 안정된 빌드를 유지하는 것이 중요하다고 생각합니다. 물론 크런치 기간 동안 팀 구성원들의 체력 고갈과 과도한 스트레스로 인해 발생할 수 있는 낮은 퍼포먼스와 이로 인한 품질 저하를 막으려는 의도도 있습니다. 사실 아주 간단하고 쉬워 보이는 원리이지만, 실제로 구현하기는 참 힘든 원리 중의 하나같습니다.

 

Collect bugs from user bulletin

다양한 지역에 동시에 게임을 서비스하는 입장에서 가장 중요한 것 중의 하나가 바로 고객들의 피드백입니다. 물론 국내의 개발사/퍼블리셔에서도 유저 게시판 및 다양한 경로를 통해 고객들의 의견과 사용자 환경에서 발생하는 버그를 수집하고 있습니다만, 대부분 GM으로 대표되는 운영팀에서 이 업무를 관장하고 있습니다. 크라이텍의 경우 버그와 관련된 피드백은 QA팀에서 직접 게시판을 모니터링 하면서 피드백을 모으고 이를 버그로 관리하고 있습니다. 정보가 전달되는 과정을 줄이고 이 과정에서 발생할 수 있는 정보의 누락과 왜곡을 방지하려는 목적입니다.

 

고객과의 직접적인 창구인 게임 퍼블리셔를 통해서도 고객의 불만과 사용자 환경에서의 문제점을 수용하는 것과 함께, 퍼블리셔와 다른 개발사만의 시각에서 좀 더 자세하고 필요한 정보를 얻기 위해 직접 사용자 게시판을 모니터링 하는 것도 중요하리라 생각됩니다. 특히 게임 내 치트와 같이 게임 설계를 악용하는 경우나, 해킹과 같이 시스템 외부에서 발생할 수 있는 보안 이슈들의 정보를 얻기 위해서는 이런 방법이 상당히 효과적일 수 있습니다.  

 

Testing as often as possible

안정성이 보장되고 항시 실행 가능한 빌드를 확보하기 위한 방법은 다름 아닌 ‘최대한 자주 테스트’를 실행하는 것입니다. 테스트의 규모나 성격과 상관없이, 기능이나 빌드 자체의 검증을 목적으로 하는 테스트 행위는 효율이 떨어지지 않는 선 안에서 최대한 자주 수행되어야 합니다. 1차적인 산출물에 대한 개발자 테스트, 기능에 대한 단위 테스트, 빌드에 대한 인수 테스트 등이 변경 사항이 있을 때마다 수행되어야 하며, 관례화된 버그 픽스와 이를 검증하기 위한 테스트 프로세스가 상시적으로 수행되고 있어야 합니다.

 

이 밖에도 다양한 발표와 회의를 통해 좋은 경험을 공유 받을 수 있었습니다. 직접 얼굴을 맞대고 서로의 정보를 교환하는 것이 온라인이나 메일과 같은 경로를 통해 정보를 교환하는 것보다 훨씬 효율적이라는 것도 다시 한 번 확인할 수 있었습니다.

 

몇 가지 인상 깊었던 명제들만 예를 들었지만, 사실 이 모든 것들이 모두 다 잘 수행되기는 힘듭니다. 서밋의 목적 중의 하나가 이런 명제를 공유하고 어떻게 효과적으로 수행할 수 있을지 모여서 머리를 맞대고 고민하는 것이었으니까요.

 

다른 분야의 QA들처럼, 국내외의 게임 개발 QA들이 한데 모여 서로의 베스트 프랙티스를 공유하고 공통된 과제에 대한 해결방법을 논할 수 있는 자리가 확대된다면 더욱 좋지 않을까라는 생각이 들었습니다. 모쪼록 근시일 안에 이런 자리가 마련될 수 있기를 바래봅니다.