로그인

회원가입 | ID/PW 찾기

취재

[KGC] 바이오웨어에서는 QA와 개발자가 평등하다

튜레이 테이커 QA 디렉터가 말하는 ‘QA 인식전환의 필요성’

안정빈(한낮) 2013-09-27 18:26:25
QA와 개발자가 같은 대우를 받는다. 중견 개발자보다 경력이 긴 QA가 더 많은 임금을 받고, QA 분야에서만 10년 넘게 근무하며 경력을 쌓아 나갈 수도 있다. 의미 없는 테스트를 거부하고, 개발회의에 참가해서 의견을 말하고, 초기부터 적극적으로 개발에 참가한다. <매스 이펙트> <드래곤 에이지> 등 최상급 RPG를 만들어온 개발사 바이오웨어의 이야기다.

게임산업이 발전하고 게임이 복잡해지면서 QA(Quality Assurance, 품질관리)는 개발에서 필수적인 존재가 됐다. 하지만 QA가 개발에서 얼마나 중요하고 얼마나 전문성이 필요한지 확실히 아는 개발사는 많지 않다. 단순한 게이머 수준의 인식에서 벗어나 개발사부터 QA를 존중하고, QA 역시 그에 합당한 능력을 갖춰야 한다는 바이오웨어 튜레이 테이커 QA 디렉터의 KGC 2013 강연을 정리했다. /디스이즈게임 안정빈 기자



바이오웨어의 튜레이 테이커 QA 디렉터


■ 높아진 QA의 중요도. 여전히 낮은 인식과 이해

게임 개발 초기에 디버그(QA)는 개발자들의 몫이었다. 아트부터 디자인, 테스트까지 개발자가 모두 해야 하던 시대다. 지금도 능력 있는 개발자들은 그렇게 게임을 만들고 있다. 하지만 어느 순간 유저들을 고용해서 테스트하는 개발사들이 생겨났고, 게임이 점점 더 복잡해지면서 많은 개발사가 전문적인 테스트를 위한 별도의 팀을 필요로 하게 됐다. QA팀이 생긴 이유다.

그런데 QA 태동기에 엔드유저들을 데려다 놓고 플레이를 시키다 보니 ‘QA = 하루종일 게임 하면서 돈을 받는 사람이라는 인식이 생겼다. 특별한 능력이 없어도 할 수 있는 일, 고양이에게 시켜도 되는 일. QA에 대한 나쁜 인식은 숱하게 많다. 튜레이 테이커 디렉터는 QA에 대한 그런 인식을 바꾸고 싶었다.

여전히 게임만 하고 돈 받는 사람이라는 인식이 많다.


■ 퀄리티를 위해서는 QA가 필요하고, QA에게는 권한이 필요하다

QA의 역할은 게임의 퀄리티를 목표에 맞추는 것, 게임을 테스트하며 얻은 지식을 개발자와 임원에게 제공하는 것, 그리고 개발조직 내에서 게임의 퀄리티를 가장 중요하게 여기는 문화를 만드는 것이다.

QA는 게임 내의 모든 부분에 관여한다. 시스템의 내부구조에 접근해서 코드를 분석하고 서로 다른 특징들과 게임엔진이 어떻게 상호작용하는지 확인하는 화이트박스 테스트, 일반 유저처럼 게임에 대한 정보가 없는 상태로 플레이하는 블랙박스 테스트, 의도했던 대로 작업이 진행되는지 확인하는 QC, 전체적인 플레이 과정에서 장애가 있는지 최종 소비자가 과연 재미를 느낄지 점검하는 QA까지 모두가 넓게 봤을 때 QA의 영역이다.

단순한 테스트 이외의 면에서도 중요하다. 개발자들은 개발 후반부에 조금의 리뷰 점수라도 더 받을 수 있도록 게임을 근사하게 보이려 많은 공을 들인다. 그때 개발속도를 올리도록 돕는 게 QA의 역할이다. 가상의 상황을 시뮬레이션하고, 비교하고, 눈에 띄지 않는 부분을 찾고, 게임에 관련된 정보를 수집한다. 그리고 개발자가 올바른 판단을 내릴 수 있는 정보를 제공한다. 마치 군대의 전투정보실과 비슷한 역할이다.

각 QA가 하는 역할. 콘텐츠 점검부터 엔지니어링까지 다양하다. 

다만 이를 위해서는 적절한 권한과 개발팀 및 경영진의 신뢰와 지지가 있어야 한다.

다행히 바이오웨어는 그것을 갖췄다. 바이오웨어에서는 현재 15~20명 정도의 QA가 게임 타이틀마다 배치돼 일하고 있다. 동시에 많은 타이틀을 개발할 때는 인원을 추가하기도 한다. 방식도 개발 단계부터 QA가 개발팀과 함께하는 ‘임베디드 QA’ 방식을 사용하고 있다.

바이오웨어에서 처음부터 QA가 존중받았던 건 아니다. 17년에 이르는 기간 중에는 블랙박스 테스트를 하던 시기도 있었고, 그때의 QA는 지극히 수동적이었다. 하지만 어느 순간 애니메이션의 아트 애셋을 통제하는 상황에서 테스트할 기회가 생겼고 그 이후로 QA에 대한 개발자들의 신뢰가 생겼다.

이후에는 바이오웨어의 개발문화가 변했다. QA가 개발과 기획회의에 참가하고 능동적으로 개발 중인 신작의 정보를 얻기 시작했다. 단순히 지시만 기다리는 게 아니라 테스트를 직접 계획하는 등 적극적인 활동도 하게 됐다.

QA 분야도 보다 세분됐다. 크게 프로그래머를 돕는 테크니컬 QA와 기획자(디자이너)를 돕는 디자인 QA로 나누고, QA의 기술이나 개인적인 선호도에 따라 분야를 고를 수 있도록 했다. <제이드 엠파이어>의 개발시기부터는 회사 내 모든 부서에서 적극적으로 QA가 활동했다.

바이오웨어의 QA가 13~14년에 걸쳐 결과를 만들어내며 얻은 개발문화다. 지금은 프로젝트 초기에 프로젝트팀을 컨설팅하고 프로젝트의 타당성을 따져보는 일도 맡고 있다. 알파 단계의 테스트가 아니면 바꿀 수 없는 일도 있기 때문이다. 그만큼 게임의 퀄리티도 높아졌다.


바이오웨어의 QA팀이 참여하는 일정. 붉은색은 테크 QA, 노란색은 디자인 QA, 보라색은 QA 매니저다. 개발 초기부터 테크 QA가 참가하는 걸 볼 수 있다.


■ 개발자에 비해 부족함이 없는 임금. QA의 가치 인정이 필요

QA는 전통적으로 이직률이 높은 직종이다. 게임 개발에서 선망하는 직업은 아닌 만큼 중간에 개발로 빠지거나 이직을 결정하는 경우도 많다. 그러다 보니 QA의 노하우가 계속 이어지지 못하고 회사 내에서 영향력을 유지하기도 어렵다. QA가 단순한 테스터로 전락하는 상황이다.

이게 반복되면 결국 게임을 재미있게 만들겠다는 열정은 사라지고 그냥 돈을 벌기 위해 묵묵히 시키는 일만 하는 경우가 많다.

튜레이 테이커 디렉터는 QA를 ‘닌자’에 비유했다. 최선의 제품을 만들기 위해 보이지 않는 곳에서 도움을 주는 사람들이라는 의미다. 모든 부분에서 역할을 맡고 있고 1개라도 놓치는 부분이 있어서는 안 된다. 예를 들어 스토리 내러티브가 나쁘다는 걸 QA에서 눈치채지 못하면 그 게임이 성공하기는 쉽지 않다.

이를 위해서는 많은 노하우와 지식이 필요한데 이직이 잦아서는 답이 없다. 결국 QA의 대우를 좋게 만들 수밖에 없다.



바이오웨어에서 스튜디오의 사람들은 모두 평등하다. 중간 경력을 가진 기획자가 경력이 많은 QA보다 더 많은 임금을 받지 않는다. 당연하다. 그가 게임을 만드는 데 더 많이 기여했다고 할 수 없으니까.

직급 문제에서도 벗어났다. 다른 개발팀과 마찬가지로 QA도 관리자와 전문가, 둘 중 하나를 선택할 수 있다. 경력이 많더라도 관리자를 원하는 사람은 관리자로, 전문가로 남고 싶은 사람은 QA 전문가로 남으면 된다. 물론 어느 쪽을 택하더라도 능력에 대한 보상은 평등하다. 수석 아티스트, 수석 디자이너가 있다면 당연히 수석 테스터도 있어야 한다는 게 바이오웨어의 생각이다.

직급과 임금에 대한 처우가 개발자와 평등하게 이뤄지고, 그래서 바이오웨어에서는 다른 직업을 찾아 QA에서 벗어나는 사람은 있어도 ‘돈이나 직급 문제로’ QA에서 벗어나는 사람은 없다. 자신의 가치를 인정받을 수 있기 때문이다. 10년 이상 일한 QA 분야의 직원도 많다.

QA에서 벗어나 다른 팀으로 옮긴 사람들이 QA를 배려하고 인정해주고, 점점 더 좋은 협력구조를 만들어 가는 선순환도 이뤄지고 있다.

가치를 인정받다 보니 자연스레 협력이 되고, 경력이 쌓이면서 자신의 경험을 다른 게임에 녹이는 장점도 생겼다. 예를 들어 튜레이 테이커 디렉터는 <매스 이펙트 3>와 <드래곤 에이지 3>의 QA를 함께 총괄하고 있다. 그리고 <매스 이펙트 3>에서 배운 경험들을 <드래곤 에이지 3> 개발 과정에 반영해 실수를 반복하지 않게 만들 계획이다.


바이오웨어의 듀얼 커리어 프로그램. 시니어 스태프 이후에는 매니저와 스페셜리스트 중 하나의 길을 택해야 한다. QA도 마찬가지.


■ 비판적인 사고와 긍정적인 사고는 필수. 눈에 보이지 않는 스킬도 중요하다

QA 역할을 인정해주는 만큼 QA의 능력도 중요하다. 바이오웨어 역시 QA를 굉장히 까다롭게 뽑고 있다. AAA급 게임을 만들려면 AAA급 인재가 필요한데 단순히 월급을 받고 게임만 하려는 사람을 뽑아서는 헤드헌터 수수료부터 인사부 직원의 시간, 교육에 들인 시간, 평가에 들이는 시간 등 많은 자원을 날리는 셈이 된다.

그래서 튜레이 테이커 디렉터가 중요하게 보는 것은 ‘소프트 스킬’이다. C#, 마야, C++ 사용 능력 등 후천적으로 배울 수 있고 눈에 띄는 하드스킬도 중요하지만 비판적 사고나 긍정적 마인드 같은 소프트 스킬은 따로 가르쳐줄 수가 없다. 태어나서 지속적으로 훈련하고 스스로 깨달은 사람을 뽑는 수밖에 없다.

비판적 사고는 QA의 필수다. 문제에 어떻게 접근할지, 질문과 이슈는 무엇인지를 찾아낸다는 건 QA에게 무엇보다 중요하다. 창의적인 사고를 하는 사람은 언제나 비판적인 사고가 가능하다. QA는 언제나 자신의 인식을 바꿀 수 있어야 하는 만큼 오픈 마인드도 필수다. 사실보다 의견에 더 무게를 싣는 사람도 안 된다.

반면 긍정적인 사고방식은 유지해야 한다. QA는 기본적으로 게임의 가장 안 좋은 부분을 보는 사람들이다. 긍정적인 사고가 아니면 문제를 파악하더라도 해결법을 찾아낼 수 없고 삐딱한 사고에만 갇히게 된다.

튜레이 테이커 디렉터는 좋은 QA, 그리고 빠른 테스트를 위해 아래의 10가지 항목을 주문했다.



1. 지속적인 피드백을 줘야 한다. 리스크 관리와 근본적인 원인분석을 하고 피드백을 주는 게 중요하다.
2. 파트너에게 가치를 제공해야 한다. QA가 좋으면 개발자들은 확신을 갖게 된다.
3. 더 나은 커뮤니케이션을 하도록 노력해야 한다. QA는 항상 다양한 부서와 상호작용을 해야 한다.
4. 용기를 가져야 한다. 자신은 퀄리티를 지키는 담당자다. 목표를 정하고 거기에 맞춰야 한다.
5. 단순하라. 새로운 프로세스를 도입할 때 프로세스를 위한 프로세스를 만들어서는 안 된다.

6. 지속적인 개선을 해야 한다. 당연하다.
7. 변화에 대응하라. 역시 당연하다.
8. 자체적으로 정리가 돼야 한다. QA와 상의해서 다른 직원들의 워크플로우를 개선하도록 한다.
9. 사람들의 의견에 집중하라. QA는 어떤 것이 거기에 왜 있어야 하는지를 알아야 한다.
10. 즐겨라. QA는 소프트 개발의 나쁜 점을 주로 보게 되는 만큼 유머러스한 무언가를 가져야 한다. 그게 아니면 부정적인 사람으로 남을 뿐이다.

마지막으로 튜레이 테이커 디렉터는 자신의 좌우명인 ‘흥분하지 말자와 함께 개발자와 지나치게 가까워져서 QA라는 것을 망각하는 일을 주의하고, 단순히 좋은 인상을 남기기 위해 개발자나 프로그래머 등에게 자신의 일이 아닌 것을 받아서 처리하지 말 것을 주문했다.

아래는 강연 후 이어진 튜레이 테이커 디렉터와의 일문일답이다.


바이오웨어에서 개발한 게임들의 메타크립틱(리뷰 점수 집계 사이트) 점수.


커뮤니티 부분의 중요성을 말했는데 여성이 남성에 비해 갖는 장점도 있을 듯하다.

튜레이 테이커: 솔직히 말하면 나는 나를 여자로 보지 않는다. 남자냐 여자냐는 중요하지 않는다고 본다. 어떤 능력이 있느냐 스킬이 있느냐가 중요하지 성별 구별은 무의미하다. 우리 QA팀에도 여성이 있자만 똑같이 대한다. 개인의 역량이 중요하다고 보고 성별이 중요하진 않다.


테크 QA에 대해 좀더 알고 싶다. 역할이나 구성. 인원규모 등.

그렇게 많은 사람이 있진 않다. 정확한 숫자를 말할 수는 없지만 보통 2명 정도가 있다. 기술에 집중해서 일하고 있다. 게임의 상황을 시각으로 보여주거나 통계를 보여주는 등의 일을 한다. 그래서 주로 툴을 만든다. 시각화에 필요한 툴, 히트 맵처럼 개발자에게 박스가 어디 있는지 알려주는 툴 등이다. 이런 것들이 QA 엔지니어들이 하는 일이다. 대부분 프로그래머들로 구성돼 있다.

그리고 이들은 툴을 만들 때 QA 매니저와 함께 작업한다. 어떤 부분이 우선순위인지. 어떤 부분을 만들어야 하는지를 알아야 하니까.


선입견을 갖지 말라는 내용이 있었는데 자세히 설명해줄 수 있나?

선입견을 가진다는 건 이런 뜻이다. 우리가 게임의 퀄리티를 보는 거지. 프로그래머를 비난해서는 안 된다. 반대로 이 프로그래머들의 얼굴을 세워주기 위해 버그가 있는데도 리포트를 안 해도 안 된다. 객관적인 시각을 견지해야 한다.

예를 들어 프로그래머가 와서 “이걸 전부 테스트해 달라고 부탁할 때가 있다. 그럼 테스트를 하면서 묻는다. 왜 전부 테스트해야 하는 거야?” 만약 중요한 내용이라면 받아들이지만 단순히 개발팀이 어떻게 해야 하는지 확신을 갖기 위해 필요하다면 그건 필요하지 않다고 판단하고 거절한다.

근본적인 원인을 찾아서 접근해야 한다. 디자이너나 개발팀이라고 한다면 만들기 싫어하거나 듣기 싫어하는 의견도 있을 텐데 QA는 중립적이니까 그런 부분도 하자고 해야 한다.


자신의 직급에서 어떤 스킬을 갖추고 있어야 하는지 알려주는 표. 부족한 부분이나 발전해 나갈 방향 등을 쉽게 알 수 있다.

최신목록 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10