게임 회사 업무의 공유, 공동의 목표를 위해
개발과 QA의 협력과 업무 효율 높이기
최근 회사에서 개발자와 QA(Quality assuarance; 품질보증; 버그를 찾거나 피드백을 제공해서 게임의 리스크를 줄이는 업무) 간 테스트 케이스를 비공식적으로 하나의 공간에서 공유하는 시스템을 만들었다. 이전에는 각자의 공간에서 각자의 업무를 했다. 해당 페이지에 '찾아가서'봐야 하는 수고를 덜게 됐다. 또한 기존엔 각 집단에 따라 같은 개념도 다른 용어로 정리가 되면서 서로 직관적으로 내용을 이해하기 어려웠다. 이번 시스템은 그런 문제까지 해결해줬다.
사실 타사에서는 여러 직군이 개발 초반부터 내용을 공유하는 경우도 이미 있었다. 필자의 회사에서는 한 분의 아이디어로 이번에 추진하게 되었다. 본격적인 시도 전이지만 분명 효율적으로 보인다.
소프트웨어 엔지니어(개발자; 이하 SE)의 경우 <기획서 읽기 - 구현하기 - 스펙(계획)에 맞게 구현 확인 - QA요청 - QA가 요구한 이슈 수정>의 프로세스로 업무에 임한다.
QA의 경우 <기획서 읽기 - 테스트 시나리오 만들기 (테스트 케이스) - 스펙에 맞게 구현 확인 - 테스트 성공 or 실패 - 버그 등록>의 프로세스를 거친다.
SE와 QA가 주로 협업이나 커뮤니케이션을 거치는 과정은 QA가 테스트 시 결함을 발견할 때다. 즉, 이미 QA는 테스트 케이스를 작성했고 구현된 게임을 테스트한 뒤다. 위의 프로세스를 살짝 바꿔서 SE와 QA가 유저에 기반한 테스트 케이스를 작성하는 과정에 SE가 참여한다면? 서로가 사전에 숨겨진 리스크를 찾아내고 누락된 개발이 없도록 체크할 수 있다면? 분명 좋은 게임 개발이라는 공동의 목표에 다가설 수 있다.
같은 문제라도 늦게 발견되면 전체 일정에 큰 타격을 줄 수 있다. 그 예는 워크래프트 리포지드가 잘 보여주고 있다. 이미 알고 있는 버그를 수정할 시간조차 없기 때문에 공지사항에 해당 내용을 알릴 수밖에 없는 것이다.
게임을 방해하는 버그들이 많을수록 유저의 즐거움은 줄어들기 마련이다.
개발 단계부터 SE와 QA가 서로 체크하면서 디버깅 기간(QA가 본격적으로 개발된 새 빌드의 버그를 찾는 기간)에 불필요한 버그를 줄이기 위해서도 이런 방식은 유효하다. 디버깅 기간에 시간을 벌 수 있다면, QA팀은 다른 리스크들을 처리할 수 있다. 일반적으로 게임의 론칭 시점은 정해져 있기 때문에 '시간'이야말로 가장 중요한 가치다. 게임 회사가 야근이 많다는 이야기는 모두 시간 때문이다.
해당 프로젝트와 관련된 항목들을 작성하고 공유하면서 기획, QA, ART, SE가 개발을 확인하려는 의도에서도 이 방법은 옳다. 기획자의 의도와 다르게 SE에 의해 게임이 구현될 경우를 최소화할 수 있다. 다른 팀의 시선에서 필요한 목록을 추가하여 개발에 반영할 수도 있다. QA가 피드백을 제공하는 것이 의무인 이유는, 기획이나 SE에서 못 보는 내용이 있을 수 있기 때문이다. 타 직군도 마찬가지다. 이는 예술가들이 자신의 작품을 보면서 결함을 찾기 위해 노력하는 것과 같다. 창조주가 창조된 것을 부수기는 어렵다.
여러 직군이 개발 초반부터 회의로 끝나지 않고 위처럼 업무에 임하는 건 여러 직군의 개발 방향과 범주, 목표를 일치시킨다. 해당 내용처럼 일한다면 게임사 내 모든 직군이 개발하려는 기능이 모두 올바르게 구현되는 거다.
업무의 개발 정도, 항목, 구현 유무 등 하나하나 공유하려는 건 귀찮은 일처럼 보인다. 수시로 본인 업무의 진행 정도를 업데이트해야 한다. 그러나 잠재적인 리스크를 줄인다는 것에서 오히려 효율적이다. 또한 '좋은 게임을 만들어 유저에게 행복을 주자'라는 공동의 취지에 맞게 게임사 내부터 다양한 구성원이 협력해나간다면 분명 더 좋은 게임이 세상에 나올 거라 믿는다.
