게임회사 QA는 게임만 하나요?: ① QA에 대하여

게임 QA를 시작한 지도 곧 3년 차에 접어든다. 그동안 보고 느낀 것들을 이 매거진에 풀어볼 예정이다. QA는 그 존재를 한 마디로 정의하기란 쉽지 않다. 특히 청자가 IT, 게임업계에 종사하는 사람이 아닐 경우 더욱 그렇다. 

내가 지인에게 QA를 설명할 때면 주변 상황에 비유하곤 한다. 예를 들어, 친구들과 단골 식당에서 새로운 메뉴를 식사하는 상황이라고 가정해보자. 눈앞의 음식을 만들기 위한 레시피가 어딘가 있을 것이다. 그 레시피는 누군가 작성한 거일 수도 있고, 요리사 머릿속에만 있을 수 있다. 그다음은 요리사가 레시피에 맞게 음식을 만든다. 완성된 요리는 내부에서 확인 작업을 거칠 것이다. 괜찮다고 생각되면 음식은 정식 메뉴가 되어 손님에게 전달된다.

QA는 손님에게 요리가 전달되기 전 단계에서 일한다. 이때 QA들은 음식이 맛있는지, 보기 좋은지, 영양소가 알맞은지, 레시피의 의도대로 요리가 만들어졌는지, 손님의 반응은 어떨지, 요리사나 레시피를 만든 사람에게 필요한 말들은 없는지 등 확인한다. 이 과정이 끝나면 마침내 요리가 완성된다.

QA, 첫 번째 고객이자 고객의 변호사

개념적으로 접근해보자. QA는 Quality Assurance의 약자다. 품질관리를 하는 역할이다. QA 업무를 간단히 말하자면, 기획자들이 기획한 것을 개발자들이 잘 개발했는가 확인하는 작업이다. 이렇게 보면 게임 개발 프로세스의 가장 마지막에 있는 것처럼 보인다. 반은 맞고, 반은 틀리다. QA는 업무 특성상 프로세스 전반적으로, 게임이 세상에 나가기 직전까지 일하는 부서다. 출시 혹은 업데이트는 날짜가 예정되어있다. 내가 몸담은 기업은 퍼블리셔와 협력하기 때문에 이미 정해진 날짜를 쉽게 바꿀 수 없다. 그래서 게임 회사, 그중 QA는 바쁠 수밖에 없다.

회사 내에서 QA는 제품의 첫 번째 고객이자 고객의 변호사들이다. 이들은 보통 회사 안에서 가장 많은 게임 플레이 인사이트를 가지고 있다. 테스트하면서 쌓이는 경험들이 자연스럽게 이들을 우수한 게이머로 만든다. 이들이 게임 개발 초기부터 참여한다면, 당연히 도움이 될 것이다. QA는 개발 초기부터 결함을 찾는다. 보다 게이머들이 원하고 즐기는 방향으로 기획 방향을 일찍이 잡는다. 이는 개발 막바지에 제품을 개선하는 것보다 더 경제적이다.

그렇지만 기획자나 개발자 관점에서 QA가 마냥 반갑지만은 않다. 내가 애써 만든 예술 작품의 결함을 찾기 위해 눈에 불을 켠 사람들이 과연 얼마나 반가울까. ‘좋은 게임’을 만든다는 대의를 생각해도 쉽지 않은 일이다.

QA는 가치 있는 일일까?

게임을 포함한 모든 소프트웨어 테스트는 소프트웨어 개발 과정에서 그 자체로 가치 있는 일이다. 하지만 '테스트'는 버그라는 불확실성을 가지는 동시에 테스트 방법이나 버그 리포트 작성 등 창조적인 면도 가지고 있다. 그 자체로 업무가 불완전해 보인다. 그렇기 때문에 게임을 비롯한 소프트웨어 개발 프로세스 중 'QA의 가치'라는 것을 생각했을 때, 언제나 높은 평가를 받지 못하는 경우가 대부분이다.

일례로 QA(이하 테스터라고도 호칭)의 작업 산출물은 확실하지 않다. 개발자의 경우 코드가 있겠고, 기획자들은 기획서라는 산출물들이 있다. 그런데 테스터는? 이들의 업무 계획이나 업무 진행 정도, 성과는 쉽사리 알기 힘들다. 같은 회사에서 일하는 개발자나 기획자들도 구체적으로 모르는 경우가 허다하다.

QA의 작업 산출물을 알기 힘들다는 이유로 테스트 케이스나, 버그 리포트 등을 그 기준으로 삼을 수 있다. 그러나 이는 크나큰 결점을 안고 간다. 애초에 테스트 케이스의 양은 같은 내용을 쓰더라도 작성자 성향에 따라 얼마든지 늘이고 줄일 수 있다. 버그 발견의 많은 경우 처음 예상한 것들보단 예외사항에 대한 케이스가 더 많다. 단순한 테스트 케이스로 QA의 역량을 측정할 수 없는 이유다. 등록된 버그 리포트의 수는 개발자나 기획자, 아트 작업자의 역량에 의해 버그의 수가 천차만별로 변화함에 따라 달라진다. 또한 애초에 개발 피처의 크기가 크다면 당연히 버그도 많이 나올 수밖에 없다.

QA는 모든 개발 단계에서 그 가치를 찾아볼 수 있다.

- 기획 단계의 아이디어

- 사용자에 따른 니즈 파악 및 요구사항

- 기획과 시안에 맞는 디자인

- 예외 사항에 대한 건의

- 개발된 제품의 상태에 관해 확인 및 버그 등록

- 전반적인 개발 프로세스 개선

- 제품의 버전 관리

QA, 게임 개발을 퇴고하는 사람들

퇴고의 궁극적인 목적은 글의 완성도를 높이는 것에 있다. 우리가 글을 쓰는 이유 중 하나는 잠재적인 독자들에게 정보, 재미, 감동 등을 주기 위해서임을 잊지 말아야 한다. 필요하다면 썼던 글을 세상에 내놓지 않거나 모두 지워야 할 필요도 있다. 그러기 위해선 독자 입장에서 자신의 글을 바라봐야 한다. QA도 마찬가지다. 유저의 입장에서 게임을 플레이하고 완성도를 높인다. 게임을 만드는 이유는 유저들에게 즐거움을 주기 위함이었음을 곱씹으며 말이다.

이런 퇴고는 온라인 게임과 패키지 게임 모두에 적용된다. 패키지 게임은 모든 개발이 100%에 가깝게 완료된 상태에서 출시되고, 온라인 게임은 개발을 진행하면서 서비스를 하고 지속적으로 업데이트를 하는 구조다. 그렇기에 패키지 게임은 개발 과정에서 모든 가능성을 예상하고 상상하고 대비해야 한다. 온라인 게임은 런칭 이후에도 유저 동향 파악을 통해 더 나은 개발 방향과 미쳐 발견하지 못한 버그를 찾아낼 수도 있기때문에, 유저와 끊임없이 소통해야 한다. 이런 과정을 꼼꼼하게 그리고 반복하면서 게임 완성도를 끌어올린다.

나는 QA 업무가 ‘제품에 존재가치와 의미를 부여하는 일’이라고 정의한다. 제품의 마침표를 찍는 것, 숨을 불어넣어 비로소 제품이 세상과 마주하도록 만드는 일이기 때문이다.