WoW 수석개발자, 퀘스트 디자인의 실수와 교훈

제프리 카플란(Jeffrey Kaplan)은 월드오브워크래프트(이하 WOW)의 퀘스트 디자인을 하면서 몇 가지 실수를 했으며, 거기에서 교훈을 배웠다고 한다.

WOW의 전 수석 디자이너였던 그는 현재 블리자드의 미공개 차기작을 맡아 일하고 있다. 그는 2009년 게임 개발자 회의(GDC;Game Developer Conference)에 참석해, 'WOW에서의 의도된 게임 플레이(Directed Gameplay Within World of Warcraft)'라는 세션에서 토론 시간을 가졌다. 이 세션에서 그는 주로 퀘스트 디자인과 관련해 저질렀던 실수와, 여기에서 배운 교훈에 대해 이야기했다.

아래는 게임 개발 전문 매체 Gamasutra에 보도된 토론 내용 일부를 발췌한 것이다.


크리스마스 트리 효과

크리스마스 트리 효과에 대해 카플란은 이렇게 말하고 있다. "이는 퀘스트가 많은 지역에서 퀘스트를 승인하고 나면, 미니맵이 퀘스트 표시 때문에 크리스마트 트리처럼 빛나는 것을 의미합니다. 이 때 생기는 문제점은 디자이너들이 플레이어들로 하여금 재미있는 경험을 하도록 유도하지 못하게 된다는 것입니다. 이는 경험들이 일직선 혹은 기차 선로와 같은 구조로 되어 있거나 선택의 여지가 없어야 한다는 의미가 아닙니다. 플레이어들이 좀더 좋은 선택을 하게 해주고 싶을 뿐입니다."


문제는 플레이어들이 지금 무슨 내용을 진행하고 있는지 알지 못한 채, 닥치는 대로 퀘스트를 쓸어담는다는 것이다. 이 때문에 게임은 더 어려워지고, "만들어진"것 처럼 보이게 된다.


너무 길어서 읽지 않음

이는 퀘스트 디자인에 대한 문제인데, 블리자드에서는 퀘스트 내용을 약 한글 255자(영문 511자)로 제한하고 있다. 카플란은 게임 디자이너들이 글을 쓰고자 하는 열정을 이렇게 묘사한다. "우리들 중 비디오 게임 텍스트를 쓰는 누구라도 겪는 실수입니다. 겉으로 표현하자 마자, 사람들은 모두 우리가 너무 자기 세계에 빠져 있다는 사실을 깨닫게 될 것입니다.." 자신의 글에 너무 집착하지 말고, 실제로 게임을 플레이 하는 유저들의 입장에서 생각하라는 것이다.


"때때로 우리 게임도 그렇지만, 너무나 많은 게임들이 자신이 아닌 모습이 되려고 하는 모습은 안타깝습니다. 예술, 문학, 드라마, 영화, 노래는 모두 일정한 맥락 안에 있고 자신만의 방식으로 이야기합니다. 우리는 게임 속에 빌어먹을 책 쓰는 일을 그만해야 하는데, 왜냐하면 아무도 그것을 읽고 싶어하지 않기 때문입니다. "

미스테리

카플란은 좀더 복잡한 문제에 대해 이야기했다. 퀘스트 디자인에 있어 "미스테리"같은 막연한 개념을 집어넣는 것 말이다. 이는 대단히 구체적인 결과를 낼 수가 있다.


"때때로 제가 이것을 망쳐버리곤 합니다." 카플란이 고백했다. "이는 미스테리가 들어 있는 이야기가 나쁘다는 말이 아닙니다. 미스테리가 문제되는 이유는, 미스테리는 절대 플레이어들이 해야 하는 행동에 들어가 있어서는 안되기 때문입니다. 우리의 퀘스트 철학은 심지어 미스테리가 들어있다 해도, [숲 속에] 뭔가 나쁜 것이 있다. 가서 밝혀내가.' 라는 식으로 만들어서는 안 된다는 것입니다. 마지막에 가서는 '이놈을 죽이고, 아이템을 가져와라'라는 식으로 되어야 합니다. 심지어 유저가 [따로 웹사이트나 자료를 사용]하는 성격이 아니더라도, 내키지 않지만 퀘스트 설명에서 [해답]을 찾아낼 수 있어야 합니다."


연계 퀘스트의 배열이 좋지 않음

카플란은 그런 퀘스트 디자인이 명백히 끔찍하다고 느낀다. "우리는 플레이어들에게 신뢰를 잃습니다. 게임 개발자로서 우리가 해야 하는 일은, 신뢰를 쌓아 유저들을 재미있는 경험으로 이끄는 것입니다. 유저가 레벨이 낮아 당장 수행할 수 없는 퀘스트나 잡을 수 없는 몹을 만나자 마자, 우리는 신뢰를 잃습니다.


좋지 않은 흐름

카플란은 퀘스트의 흐름도를 보여주었는데, 한번에 몹을 4마리 잡은 다음 다시 한번에 아이템을 4개 수집하는 퀘스트였다. 그가 말하기를 이는 좋지 않은 디자인인데, 다음 번 패치에서 다시 설계될 거라고 했다. 목표를 이루기 위해서는 다양한 방식을 사용할 수 있어야 하고 만약 가능하다면, 일반적이지 않은 (그러면서도 만들다 만 쭉정이가 아닌)요소도 포함할 수 있어야 한다. "이는 유연성을 지니면서도 언제나 되돌아갈 수 있도록 유도하는 것입니다."


수집 퀘스트에서의 실수

"저는 수집 퀘스트들이 망했다고 생각하지는 않지만, 종종 수집 퀘스트를 엉망으로 디자인하긴 했습니다." 예를 들면 다음과 같다.


- 좋지 않은 흐름
- 퀘스트 몹 밀도와 관련된 이슈
- 한 가지 아이템을 너무 많이 모아야 함
- 다양한 아이템을 모아야 함


"WOW같은 게임을 플레이 하는 플레이어들이 겪어야 하는 세금 같은 것 중 하나는, 인벤토리 관리입니다. 기본적으로 모든 플레이어들은 가방 안에 무엇을 넣을 지 결정을 해야 합니다."


내가 왜 이따위 것들을 수집하고 있나?

"당신은 결코 플레이어들이 게임을 만든 누군가를 떠올리는 것을 원하지 않을 것입니다. 당신은 플레이어들이 자기 자신만을 생각했으면 하고 바랄 것입니다." 아이템을 수집하는 것은 때때로 극도로 강압적이고 무의미해 보일 수 있습니다. 하지만 만약 수집하는 행위가 스토리에 영향을 끼친다면, 더 좋은 효과를 불러올 것입니다. 환호할 만한 순간이 있기만 하다면, 당신이 [플레이어들을] 어떤 과정에 몰아넣어도 좀더 순응하게 될 것입니다.


"짜증나는 노가다"는 아이템 수집 퀘스트에서도 문제가 됩니다. 리치 킹에서 WOW는 향상된 확률 시스템을 도입했습니다. "수집퀘스트의 대상이 되는 몹은 모두 퀘스트 아이템을 100% 가지고 있습니다. 하지만 우리는 플레이어가 그 몹을 몇 마리나 죽여야 아이템을 얻는지에 대한 향상된 시스템을 사용하며, 계속 추적합니다."


비록 숫자들이 정확하지는 않지만 시스템을 수치화하면 다음과 같다. : 몬스터를 처음 잡을 때에는, 아이템을 얻을 확률이 16%이다. 두번 째는 32%, 세번 째는 48%, 그리고 결국에 100%가 된다. 하지만 이렇게 경고하고 있다. "이 때문에 좋은 노가다 까지 묻혀버릴 수 있습니다. 기본 드랍율을 더 높혀야 합니다."


질문과 답변

퀘스트 테스트에 대해 묻자 카플란은 모든 스튜디오가 그런 것은 아니지만, 특히 블리자드에서는 모든 디자이너들이 반드시 게임을 해 보아야 한다고 답했다.


"플레이 테스트는 누군가 게임 내에 추가할 때마다 시작됩니다."


어떤 질문자는 왜 그가 WOW에 접속할 때마다 10분 동안 세계를 날아다니냐고 물었다.


카플란은 이것이 초보 디자이너 시절의 흔적이라고 설명한다. "진짜 발전한 모습을 볼 수 있을 것입니다. 만약 당신이 오리지널 컨텐츠를 보고 불타는 성전과 비교한 다음, 다시 리치 왕의 분노 컨텐츠와 비교한다면, 리치 왕의 분노는 우리가 가고싶어 하는 방향이라는 사실을 알 수 있을 겁니다.


오래된 퀘스트들이 개선될 계획이고, 여행 시간은 점점 단축될 것입니다. 게임이 발표되기 전에, 우리의 철학은 플레이어들이 이 크고 아름다운 세상을 좀 더 여행하도록 만드는 것이었습니다.... 우리는 여러분을 너무 멀리 보내는 우스꽝스러운 퀘스트를 많이 만들었습니다. 우리는 후에 이것들을 "경로 유도" 지침에 따라 재설계했습니다."


누군가 카플란에게 출시일에 대한 공식 지침이라던가 플레이어의 지루함 척도가 있냐고 묻자, 카플란은 이렇게 답했다 "전투만큼은 확실히 지침이 있습니다. -- 우리는 전투가 1분 정도 지속되길 바라며, 그리고.... 지금은 조금 빠릅니다. 다른 것들에 대해서는, 그때그때 다릅니다."

------------------------------------------------------------------------------------------

주석 : 이 가르침들은 기본적으로 큰 뜻을 품은 게임 디자이너들을 위한 것이지만, 여기에서 다루고 있는 많은 개념들은 게임 산업에서 다른 형태로 종사하는 사람들에게도 적용될 수 있다. 이 가르침들은 변경되고 개선될 수 있으며, 독자들의 의견은 환영하는 바이다. 특히, 나는 내가 게임 산업에서 쌓은 20년이 넘는 경력 때문에 다소 “지긋지긋한” 사람으로 인식되는 경향을 극복하기 위해 아직도 노력중이다. 어떤 부분이 너무 부정적인지를 내게 알려준다면, 내가 그 부분을 완화시키겠다. 이 얘기는 이번 과 뿐만 아니라, 앞선 과들에게도 적용되는 말이다.

게임 업계에서 일을 시작하려면 테스터라는 일이 좋다는 말을 분명히 들어보셨을 것입니다. 부정적인 의견도 함께 들으셨을 것입니다. 하지만, 말씀 드리건대 그런 부정적인 말들은 죄다 틀린 것입니다. 물론 테스트는 하위 보조 업무이고, 밑바닥 일입니다만, 매우 중요한 일입니다. 또한 게이머들에게 즐거운 경험을 선사하며, 게임을 빛나게 하는 생명 같은 일입니다.

테스터는 훌륭한 취직의 길이기도 합니다. 이번 글에서 그 이유를 많이 찾을 수 있을 것입니다.

용어 해설 : 테스트팀은 "품질보증(Quailty Assurance)"부서로 불리기도 합니다. QA라는 약어로서 테스트과 관련된 업무나 처리를 나타냅니다. 본문에서 "테스트"와 "QA"가 같이 쓰이고 있습니다.

주석 : 본문의 테스터는 상근직을 지칭합니다(즉 생업으로서 회사에 테스트 결과를 보고하는 고용인). 자원봉사자, 즉 "베타 테스터"(집에서 게임을 해보고 이메일로 보고하는 무급 테스터)는 이 글과 무관합니다. 테스터로 취직하는 것은 게임 업계에 종사하는 좋은 방법이지만, 베타 테스터는 일반인이나 다름없습니다.

최종 단계로서의 테스트

액티비젼(Activision)같은 대형 개발사에서 QA는 프로젝트의 최종 과정입니다. 이런 곳에서 테스터는 게임의 대부분이 완료될 때까지 투입되지 않습니다. 이는 테스터들이 기획 과정에 참여할 수 없고, 관련 사항을 알려주지도 않기 때문에 불행한 일입니다. 하지만, 소규모 회사에서는 개발에 참여하는 팀원이 테스터 역할도 겸합니다. 따라서 그들은 관련 사항에 대해 잘 알고 있으며 프로젝트에 관련된 결정에도 참여합니다.

일반적으로 테스터는 프로젝트의 최종 단계에 투입되므로, 게임의 주요 기획에 영향을 미치지 못합니다. 그러나 게임을 망칠 수는 있습니다. 군사적으로 보자면, 테스터는 병사입니다. 기획/개발팀은 장교입니다. 좀 과장되었지만, 그렇게도 볼 수 있습니다. 그러나 테스터를 하게 될 여러분이 게임 개발 현실에 적용하기에는 무리가 있군요.

전장에서 장군은 모든 병사를 바라보지 않습니다. 병사는 지시 받은 대로 행동해야 합니다. 모든 병사에게 전략을 설명할 시간이 없기 때문이죠. 가능한 저는 게임 제작 과정에서 테스터들과 함께 전략을 공유하려고 합니다. 그러나 모든 기획자나 개발자가 그렇게 하지는 않습니다. 자신의 아이디어를 게임에 반영할 수 없다는 사실을 납득하지 못하는 테스터도 있습니다. 유감스러운 일입니다.


테스트는 정말 중요합니다

기획자 겸 개발자로서, 자기가 만든 게임이 쉽고, 친숙하고, 재미 있다는 점은 중요한 일입니다. 그만큼 단점을 찾는 것도 어렵습니다. 저 또한 테스트 중에 많은 버그를 찾지만, 테스터들이 발견한 버그를 "그건 버그가 아닙니다" 또는 "원래 기획에 있던 것입니다"라고 거절하기도 합니다. 몇 번 거절 당한 테스터는 반감을 갖기도 합니다. 그러나 편을 가르면 안됩니다. QA팀과 저는 같은 목표를 공유하니까요. 즐거운 게임을 만드는 겁니다.

확실하게 재미있는 게임을 만드는 방법은 오로지 꼼꼼한 테스트 뿐입니다. 여러 사람의 눈으로 보고, 여러 사람의 손으로 해보세요. 저의 플레이 방식은 하나 뿐입니다. 하지만 다른 사람은 그 사람만의 방식이 있습니다. 어쩌면 제가 상상도 하지 못했던 방식일 수도 있습니다. 그런 식으로 게임이 출시되기 전에 모든 문제점을 찾아내야 합니다.


테스트는 쉽지 않습니다

어떤 사람은 "테스트"가 온종일 게임만 하는 일이라고 생각합니다. 재미있고 쉬워보이죠.
그렇지 않습니다. 오랫동안 재미 있을 수도 있습니다(재미 있는 일이 될 수도 있습니다). 하지만 업무라고 느끼면 절대 그렇지 않습니다.
게임을 하는 것은 즐겁습니다. 그러나 어렵죠. 게이머에게 물어보세요. 쉬운 게임은 재미가 없습니다.
게임이 재미없다면(균형 잡힌 게임이 아니라면), 계속 반복해서 하기란 정말 고역입니다. 당신의 업무가 테스트라면, 설령 재미없다 해도 계속 해야 합니다. 그래서 정말 어렵죠!

테스트를 반복하다 보면 똑같은 부분을 수십 번 해야 할 때도 있습니다. 게임의 재미는 점점 사라져갑니다.

테스터는 컴퓨터에 능숙해야 합니다. PC 게임을 테스트한다면, 각종 카드(역주: 그래픽/사운드 지원 카드)와 조이스틱, 드라이버를 설치해야 합니다. 설치/제거하는 것이 가능해야 하고, OS를 다시 설치할 수도 있어야 합니다. 플레이스테이션 2, 게임보이 어드밴스 게임이라고 해도, PC로 보고서를 써야 합니다.

테스터는 의사소통에 능통해야 합니다. 회사 내에서 놀라운 능력으로 버그를 찾아낸다 해도 팀원들에게 버그를 어떻게 찾았고, 버그가 무엇이고, 무엇이 발생했고 할 것인지, 코드에서 잘못 돌아가고 있는 것이 생각한 바를 표현할 수 없다면, 전혀 소용이 없습니다.

"녹색 검을 집고 파란 물약을 마시니까 게임이 깨짐" 훌륭한 테스터는 버그를 찾아 보고하는 것으로 끝내지 않습니다. 좋은 테스터는 깊게 파고 들어 갑니다. 게임이 어떻게 돌아가는지는 알고 있고, 이를 바탕으로 버그가 어떻게 발생했는지 고심해봅니다. 그리고 무엇이 정말 잘못되었는지 생각합니다. 다시 "녹색 검을 집고 파란 물약을 마신다"를 하면 버그가 안 나올 수도 있습니다. 다른 요인이 있을 수도 있습니다. 좋은 테스터는 불독과도 같습니다. 끈질기게 버그를 찾아 이빨을 쑤셔 넣으세요. 그 이유를 찾을 때까지 절대 놓치면 안됩니다.

테스트는 재미를 쫓아다니는 미숙련자가 할만한 일은 절대 아닙니다.


현장 학습
테스트 업무는 게임 산업을 배우는 좋은 방법입니다. 여러 가지를 접할 수 있습니다 (직접 그 일에 관여하지 않아도 상관없습니다). 여러 게임에서 테스트를 하면서, 산업 전반에 대해 많이 배울 수 있습니다.


개발 측면
(여기서 쓰는 '개발'은 프로젝트에서 '제작 전 단계'를 지칭합니다. 즉 기획을 언급합니다. '제작'은 프로그래밍, 미술, 음향 등을 만드는 것을 지칭합니다) 테스트를 하는 동안, "왜 이렇게 기획했지?"라는 의문이 떠오를지도 모릅니다. 세부 사항을 구현하는 방법은 여러 가지가 있으며 또한 테스터는 게임을 가장 빨리 접합니다. 테스터는 시시각각 변하는(또는 변하지 않는) 기획의 측면에 노출됩니다.


제작 측면
테스터는 버그를 찾아 보고합니다. 대부분은 수정하고 끝나는 간단한 문제입니다. 그러나 어떤 경우 QA와 제작팀 사이에 토론이 필요한 복잡한 문제일 수도 있습니다. 그 동안, 테스터는 제작팀이 무슨 일을 하는지 파악할 수 있습니다. 그러면서 전체적인 제작 과정에 대한 넓은 시야를 가질 수 있습니다.


마케팅 / 판매 측면
테스터에게 테스트가 전부는 아닙니다. 패키지와 매뉴얼 문구를 살피기 위해서도 불려집니다. 하드웨어 사양은 정확해야 하고, 요구 사항 또한 표기되어야 합니다(특히 게임의 특징이 묘사되어야 합니다). 이런 사항들을 파악하여 실제로 제품을 살 사람들이 어떻게 제품을 보게 될지 식견을 가질 수 있습니다.

선적 기일 같은 끔찍한 최종일자는 버그 수정을 불가능하게 합니다(버그의 우선순위가 낮을 수록). 몇 번의 게임 프로젝트를 거치는 동안, 테스터는 버그의 우선 순위를 정하는 것이 매우 중요함을 알게 됩니다. 회사는 테스터의 월급을 주기 위해서라도 게임을 출시해야 합니다. 언제까지 테스트만 할 수는 없겠죠. 제작 과정에 몇 차례 참여하면서, 이익을 내야 하는 현실을 깨닫습니다. 또한 버그의 우선 순위를 정하는 중요성에 대해서도요.


고객 지원 측면
게임을 면밀히 테스트하는 일은 당연합니다. 그러나 게임이 시장에 출시되었을 때부터 문제가 발생합니다. 고객은 잔인합니다! 게임에서 할 수 있는 방법을 모두 시도해보고 제작이나 QA에서 결코 생각하지 못한 것들도 있습니다. 고객 지원팀으로 전화가 옵니다. 보통 첫번째 고객 지원 전화는 QA쪽으로 연결됩니다. QA팀과 고객 지원팀 간의 관계는 그래서 중요합니다. 할 일을 다했다고 생각한 테스터에게 이제 "이 하드웨어 사양으로 게임을 해보세요. 그리고 무슨 일이 일어나는지 살펴보세요" 하고 서비스 업무 지원 지시가 내려집니다. "어떻게 이걸 놓칠 수가 있습니까?"라며 시비를 걸 수도 있겠죠. 이 방면으로 테스터의 실제 업무는 별로 없지만, 고객 지원 측면의 주요 이슈에 대해 배울 수 있습니다.


생산 측면
생산 또한 게임 제작에 참여함으로써 배울 수 있는 것 중의 하나입니다.

- 프로젝트를 끝마치기 전에 최종 확인을 위해 테스터에게 패키지와 매뉴얼을 줍니다. 명심하세요. CD를 꺼내 실행하는 것보다 박스와 매뉴얼을 찍어내는데 더 시간이 걸린다는 점을요.

- 게임기용 CD라면(PC 용보다 낫습니다), 테스터는 플랫폼을 확인해야 합니다. 그리고 패치가 불가능하다는 점도 잊어선 안되겠죠. 게임기용 CD는 첫 출시 때 잘 작동해야 합니다. 가끔 드물게 생산 과정에서 문제가 발생하기도 합니다. 그러면 테스트를 다시 하는 것은 당연하고 재출시까지 경험할 수 있습니다. 설령 이런 일이 없다 해도 매일매일 겪는 일상을 통해, 게임을 출시하기 위해 겪어야 하는 일들이 얼마나 고통스러운지 느낄 수 있을 겁니다(플레이가 지긋지긋하게 느껴지겠죠).

- 프레스 되는 CD와 골드 CD(CD-R로 만들어지는 CD)는 제작 방법이 다릅니다. 제가 만든 게임 중 하나는, "레드북 스탠다드(redbook standard)"에 따른 자체 음악 트랙이 있었습니다. 테스트할 때는 물론 잘 돌아갔습니다. 공장으로 게임을 보낼 때까지 몰랐지만, 그 CD 제작기는 음악 트랙 사이에 매우 짧은 공백을 넣는다는 것이었습니다. 이런 CD로 게임을 했다면, 아마 모든 음악이 하나의 트랙으로 플레이 되었을 겁니다. CD 헤드가 트랙을 인식하려 할 때마다, 시작 부분을 찾지 못하니까요(다른 곡 시작을 할 때 눈깜짝할 사이에 실패가 발생합니다). 결국 우리는 마스터 작업을 다시 했습니다. 각각의 트랙 사이에 공백을 넣어서 말이죠. 저는 여기서 뭔가 배울 수 있었습니다. 여러분 역시 그럴 거라고 생각합니다.


게임 산업을 배우는 방법에 대해 살펴보셨는지요? 그러나 여러분이 생각하는 테스터는 매일 게임만 하는 사람입니다.


테스트는 디딤돌입니다 ...더 큰일을 얻어내려는 사람들을 위한


좋습니다. 제목에 충분히 설명이 되었습니다. 그렇다고 테스터보다 더 중요한 일을 하기 위해 그만둘 필요는 없습니다. 열심히 일하고 성과가 좋고, 그리고 훌륭한 애사심을 보여주면, 의사를 효율적으로 잘 전달한다면 더 높은 위치로 발전할 수 있을 것입니다.

여러 프로젝트에서 훌륭한 테스트 성과를 올리면, 수석 테스터로서 올라갈 수 있습니다.

여러 프로젝트에서 수석 테스터로서 실적을 올리면, 테스터 팀장이 될 수 있습니다. 또는 개발 스튜디오의 일원으로 참여하길 요청 받을 수도 있습니다. 개발 진행 책임자나 부 프로듀서, 초보 기획자로 말이죠.

그냥 보여주세요. 승진 기준이 될 만큼만 일하지 마세요. 당신은 빛나야 합니다. 다른 사람보다 더욱 활활 불타야 합니다. 거둔 대로 뿌립니다(영원히 승진에서 누락되는 사람들에게 불평을 듣는다 해도).

어디서 들은 지 기억은 나지 않지만 적당한 문구가 있습니다.

"영리한 자는 능력을 발휘하는 방법을 배운다. 행복한 자는 결점을 이해하는 방법을 배운다"

당신에게 재능이 있다면, 게임 산업에서 중요한 역할을 하게 될 테스트 업무를 기꺼이 맡을 것입니다.


QA 용어 해설
'A' 버그 A 버그는 최악의 버그입니다. 이 종류의 버그는 "고치지 않고 출시하면 잊지 못할 끔찍한 화를 불러올 버그"로 설명됩니다. 예를 들어 :
  - 게임 파손
  - 바이러스 감염
  - 명백한 오자
  - 명백한 그래픽 / 오디오 문제
  - 기능(메뉴나 버튼를 사용하여 작동할 수 있는)이 작동하지 않음
  - 저작권 표시가 없을 경우
  - 게임이 재미없을 때
이런 결점을 안고 출시를 한다면, 형편없는 대중의 반응, 언론의 혹평을 얻거나, 심지어 회사가 당신을 고소할 수도 있습니다.


'B' 버그 B 버그는 A 버그보다는 낫습니다. 이러한 버그는 " 게임은 그럭저럭 괜찮지만, 출시하면 안 좋을 평판을 얻게 될" 버그로 요약될 수 있습니다. 재정난 등에 시달려서 게임을 출시해야만 할 때, 고객 지원팀, 판매팀, 마케팅팀, QA팀과 경영진이 모두 동의하면 테스트과 버그 수정을 중지한 채 게임은 작은 오류를 갖고 출시될 수 있습니다. 예를 들면:

  - 게임 플레이를 망치지않는 버그
  - 명백한 그래픽 / 오디오 문제(눈/귀에 띄일만큼)
  - 독창적인 기능 제거(그리고 그에 대해 게임 내에서 언급하지 않음)

B 버그는 잡지 기사에서 언급될 것입니다. 이것들을 고치는 것은 어려운 일입니다 (많은 대가를 치루게 합니다). 게임을 하는 사람들은 이런 문제가 달갑지 않을 테지만 전체적인 게임 진행이 이런 문제로 망쳐지지는 않을 것입니다.


'C' 버그 C버그는 "고치면 게임이 더 나아질" 버그로 요약됩니다. 테스터는 자신이 발견한 문제를 심각히 생각하는 경향이 있습니다. 그러나 회사가 출시의 필요성을 더 강하게 느끼고 저울질한다면, 그 버그는 의사 결정자에게는 중요하게 생각되지 않습니다. 출시하기 위해, C 버그는 포기될 수도 있습니다.(고치기 어려운 문제라면, 그렇게 되겠죠 -- 중요도가 낮은 C버그는 간단히 고쳐질 것 같지만 생각대로 진행되는 일은 없습니다)


'D' 버그 "이것까지 고치면 금상첨화입니다." 테스터 과정에서 늦게 발견되면, D 버그는 수정되지 않을 수도 있습니다.

"모든 버그를 고칠 것" 이상적으로는 옳은 이야기지만 어떤 게임은 너무 크고 복잡해서 수정하는 것이 결코 끝나지 않을 수도 있습니다. 가능한 회사에 있을 때 출시되기 전에 모든 사항을 체크하고 균형을 맞춰야 합니다.


"알파" "알파"와 "베타"라는 용어는 회사마다 달리 쓰입니다. 개발사에서 유통사까지 정의가 다릅니다. 어떤 개발자는 "게임을 할 수 있는 단계"를 알파라고 부릅니다. 그러나 대부분의 유통사(특히 유통사의 QA 부서에서)는 이렇게 정의합니다. "모든 기능이 구현되어 있지만 버그도 있고 균형도 잡아야 하는 상태"

"베타" 어떤 개발자는 베타를 이렇게 생각합니다. "기획한 모든 것이 구현되어있습니다. 그러나 버그가 있고 게임플레이는 주의할 필요가 있습니다" 하지만 대부분의 유통사(혹은 QA 부서)는 베타를 이렇게 언급합니다. "모든 것이 다 되고 개발사가 아는 것과는 달리 버그가 없고 게임 플레이도 완벽히 돌아간다."


"재현 불가" 테스터는 분명 발견했지만, 다시 보여줄 수 없는 버그가 발견될 때도 있습니다. 프로그래머가 디버거를 갖고 코드를 면밀하게 탐색해도 그 문제를 다시 밝혀낼 수 없다면, 수정하는 작업은 불가능할 것입니다. 재능 있는 테스터라면 더욱 끈질기게 노력해보고, 왜 발생했는지 추리해 내야겠죠.

"골드 마스터" CD 또는 DVD로 QA팀을 거쳐 생산되는 제품입니다. 이 디스크는 실행 확인 및 바이러스 검사를 해야 합니다. 더불어 출시하기 전에 상세한 검사 목록을 통과해야 합니다.

"어색함" 테스터에게 최대의 칭찬은 "버그 없음"과 "기획한대로 작업됨"입니다. 때때로 테스터는 게임에 자신이 원하는 바를 삽입하려고 보고서를 임의로 쓸 때도 있습니다. 보고서를 받아본 기획자는 이렇게 답하겠죠. "버그가 아닙니다. 기획한대로 작업된 겁니다. 이게 여기 있는 이유를 말씀 드려보자면..." 라고요. 만일 테스터가 발견한 것이 어색하다는 점을 확신 있게 설득한다면, 바꿔질 수도 있습니다.

"더 많은 정보 필요" 이 문구는 프로그래머에게 버그가 어떻게 반복되는지 충분한 정보를 제공하지 않을 경우 자주 보게 될 겁니다. 또는 테스터가 그걸 버그라고 느낀 이유를 밝히지 않을 때도 마찬가지입니다.

"버그 아님" "어색함" 부분을 보세요.

"비정상 플레이" 이 용어는 합당치 않은 사용자 입력을 이유로 발생되는 문제를 가리킵니다. 예를 들어 "F10, ESC를 한 줄에 30~40번씩 누르면 게임이 깨짐"같은 것입니다 이유 없이 사용자는 이렇게 할 수도 있습니다. 그리고 누구라도 할 수 있습니다. 그리하여 예기치 않은 게임 오류가 발생합니다. 그런 문제가 고치기 어렵고 프로젝트가 막바지에 다다르면, 간단히 논의에서 제외되기도 합니다.


"완성" QA팀은 게임에 사인하고 확인 도장을 찍은 후, 생산하기 위해 게임을 보냅니다.

"선적" 이 말은 테스트 과정의 끝 부분에서 듣습니다. 테스터 팀이 터널의 끝에서 불빛을 보게 될 때이기도 합니다.

  - 테스터: "버그를 찾았어요"
  - 수석 테스터: "어떤 버그인데?"
  - 테스터: "C버그예요. 대단치는 않아요. 비정상 플레이 때 나타나요"
  - 수석 테스터: "무시해!"

완료된 게임(테스트, 품질 확인)은 수송업체(가끔 중요하고 급해서, 직접 나를 수도 있습니다)에 의해 생산 설비로 수송됩니다. 대량으로 생산되어 매장 트럭에 실립니다. "수송"은 게임을 바깥 세상으로 보내고 테스트를 끝마치는 중요함을 보여주는 주문입니다.


"변경(Tweak)" 조정과 같은 뜻

"수정 중지" 시간이 촉박할 때, 작은 버그는 보고되어도, 프로그래머나 기획자, 개발자는 버그 보고서의 이런 모호한 글을 남겨 놓을지도 모릅니다. 하지만, 모든 버그는 게임이 출시 전에 "해결" 되어야 합니다.

"기획대로 작업됨" '어색함'을 보세요(위에 있습니다).


테스터로서 직업을 구하고 싶습니까? 여기 준비하는 방법이 있습니다.

저는 학사 학위를 갖고 테스터에 지원하기를 추천합니다. 그러나 그것 없이도 지원할 수 있죠. 그러나 생각해보세요 -- 당신의 최종 목표는 무엇입니까? 만일 기획자나 프로듀서 혹은 마케팅으로 이동하기를 원한다면, 대학 학위는 명백히 도움을 줍니다. 만일 그냥 테스터가 되고 싶다면(그 이상으로는 아무 목적도 없다면), 그대로 좋습니다. 고등학교 졸업으로 충분합니다. 그러나 테스터가 되기 위해 무엇보다도 먼저 필요한 기술이 무엇인지 추측해보세요.


o 의사소통 능력

* 쓰기. 버그 리포트를 써야 합니다. 그 내용이 분명하고 명료해야만 합니다. 테스터는 충분한 문장력을 갖고 있어야 합니다

* 의사소통 능력. 테스터는 말도 잘 해야 합니다. 그의 말을 다른 사람이 충분히 이해할 수 있어야 합니다. 아래의 두 가지 훈련을 해보면 테스터가 의사소통 능력을 기르는데 도움을 줄 것입니다. 훈련을 통해 어떻게 의사 소통 능력을 향상시킬 수 있을까요? 먼저 아래 연습은 작은 방에서 하는 것이 가장 좋습니다 -- 두 사람이 연습에서 대화하고 쉽게 담화할 수 있는 역할을 맡되 다른 사람이 무엇 하는지 볼 수 없게 해야 합니다.

- 페이퍼클립 훈련 이 훈련에서 테스터는 펜과 종이를 가진 상대에게 임의로 구부러진 페이퍼 클립에 대해 설명해야 합니다. 구부러진 모양대로 듣는 이가 그려내면 성공입니다. 단, 테스터는 "페이퍼클립"이라든가 이 물체가 뭘로 만들어졌고 원래 무슨 용도로 사용되는지 말하면 안됩니다. 다만 페이퍼클립의 지금 상태에 대해 설명하세요. 테스터는 듣는 이가 올바른 페이퍼 클립 모양을 그리도록 설명해야 합니다. 훈련이 끝나면 테스터는 자신의 설명에 대해 생각할 계기가 마련됩니다. 이 훈련은 파이프 청소 도구나 묶인 줄로 가능합니다. 클립은 2차원으로 구부리세요. 2차원인 종이에 그리기 때문에 3차원 모양은 좀 어렵습니다.

- 블록 쌓기 훈련 이 훈련은 닌텐도 아메리카의 직원들과 소속 고객 지원 팀원들을 훈련시키는데 이용했습니다. 제 생각에는 테스트에 필요한 의사 소통 기술을 잘 적용될 것 같습니다. 훈련하는 양 팀은 동일한 나무 빌딩 블록 상자를 가집니다(레고 같은 걸로 해도 됩니다). 테스터는 블록을 이용해 구조물을 쌓고 훈련하는 다른 참가자에게 구조물에 대해 설명합니다. 테스터가 잘 설명한다면, 두개의 구조물은 동일해질 것입니다. 두 개의 구조물이 다르다면, 무엇을 잘못했는지 배울 수 있습니다.


o 컴퓨터 상식. 테스터는 컴퓨터를 분리하고 그것들을 원래대로 하는 방법을 알고 있어야 합니다. 인터넷 탐색하는 법이나 이 메일, 인스턴트 메시징, 채팅룸 네티켓에 대해서도 물론입니다. 또한 인스톨 하다가 발생하는 문제도 해결할 수 있어야 합니다. 드라이버를 다운로드 하거나 바이러스 데이터파일을 갱신하거나 컴퓨터를 업그레이드 지식도 필요합니다. 또한 워드 프로세서나, 이미지 프로그램, 스캐너, 모뎀에 관련된 지식도 필요하죠.

o 게임 상식. 할 수 있는 한 많은 게임을 해보세요. 그리고 그것들의 장단점을 비교해보세요. 게임 잡지를 읽어보고, FRP와 RTS가 뭐가 다른지 알아두세요. 온라인게임, 콘솔 게임, 핸드헬드 게임, 보드 게임, CCG 등에 대해서도요.

이미 말했지만 반복하자면, 게임 산업에 종사하기 위한 최선의 방법 중의 하나는 테스터입니다. 다른 비관론자들이 테스트가 밑바닥 업무라고 해도 무시하세요. 대부분 테스트가 얼마나 중요한지 깨닫지 못합니다. 더불어 게임 제작과정에서도 테스트가 얼마나 중요한지를요.


[원문] http://www.sloperama.com/advice.html
저자 : Tom Sloper

번역 : 이웅주
----------------------------------------------------------------------------------------

아주 잘 정리된 글입니다. QA는 물론 PM이나 PD, 기획자도 한번씩 읽어보면 좋을 듯 싶네요.

나중에 시간이 되면 제 생각도 한번 정리해 볼께요.

나의 가치를 높여주는 화술(문고본) 카테고리 자기계발 지은이 안은표 (시아출판사, 2008년) 상세보기

나의 점수 : ★★★

전반적인 화술에 대해서도 나와있지만,
판매원(?)의 입장에서의 화술에 대해 많이 애기하고 있습니다.
솔직히 공감 안되는 부분도 많고 해서 후반부는 날림으로 읽었습니다.

(요약)
1. 대화는 듣는 것으로부터 시작된다. 상대가 어떤 말을 해도 먼저 수용하는 자세를 가진다. 상대의 말을 잘 들어주고 난 다음 자신의 의견을 제시해야 대화가 원활히 진행된다.

2. 자신에 의사를 먼저 밝히지 않는다. 먼저 상대의 말을 듣고 마음을 읽으려고 노력한다면 상대방의 호의를 얻을 수 있고 그렇게 되면 자신이 유리한 방향으로 대화를 이끌어 나갈 수 있다.

3. 말을 할 때는 자신감 있는 태도로 한다. 자신감 있는 태도는 상대로부터 호감을 얻을 수 있다. 반면, 자신감 없는 태도는 자신의 말은 신뢰를 잃어 설득력이 없다.

4. 자신의 생각을 주입하려는 것보다 상대에 입장에서 상대의 감정을 공감하고 같은 입장이라고 생각하는 것이 설득을 위한 기본적인 태도이다.

5. 상대를 설득하기 위해서는 구체적인 실례를 드는 것이 좋다. 이는 상대에 흥미를 이끌어내고 대화에 집중하게 한다.

6. 상대가 우월감을 느끼도록 능력을 인정해 주고, 우월감을 충분히 표현할 수 있도록 한다. 그 다음에 말문을 열면 좋은 결과를 얻을 수 있다(즉, 칭찬해주고 너라면 이 정도는 문제 없지? 와 비슷한 개념)

7. 상대를 지나친 찬사이나 상투적인 칭찬은 피한다. 적절한 찬사나 예외적인 칭찬, 상대가 소중히 여기는 사람을 칭찬하는 것으로 대화를 즐겁게 이끌어 낼 수 있다.


8. 상품판매(sales)을 위한 화술.
1) 진실성과 열정이 담긴 화법을 구사한다.
2) 부담 주는 말을 삼가 한다.
3) 실패는 성공의 어머니. 실패를 두려워하지 말고 발판으로 삼아라.
4) 제품의 새로운 점을 우선적으로 강조해라. 비록 별로 의미 없는 것이라도.
5) 거절은 일단 받아 들이고 반 걸음 물러선다.
6) 열정적인 표현과 시각적인 언어를 사용한다.

9. 대화를 즐겁게 이끄는 사람이 주목 받는다. 유머, 위트, 미소를 잃지 말자.