게임 QA가 게임성에 관여해야 하는가?

1편에서 게임 QA에 대해 자세하진 않지만 어떤 일들을 하는 것인지 수박 겉핥기 식으로 확인해 보았습니다.

 

이번에 할 얘기는 많은 게임 QA에 종사하는 분들이 고민할 수 있는 혹은 이미 고민하고 있는 문제입니다.

“게임 QA가 제작 중인 게임의 게임성에 관여해야 하는가?”

잠시 옛날이야기로 돌아가 보겠습니다.

최초로 컴퓨터가 만들어지고 소프트웨어가 만들어졌을 때 그 녀석의 탄생 목적은 하나였습니다.
그건 바로 미사일의 궤도 계산이었습니다.

어떻게 해야 가열차게 저 녹색 돼지 잔당을 몰살시킬 수 있는가?

그 뒤로 컴퓨터와 SW는 누군가의 혹은 어떤 조직의 필요성에 의해 발전해왔습니다. 정말 엄청난 발전을 했죠.

HAL이 정말 손아귀 안에 들어왔습니다.

그런데 이런 누군가의 필요성에 의해 만들어져 나간 컴퓨터와 SW의 역사에 게임은 매우 다른 방향에서 튀어나왔습니다.

흔히 최초의 컴퓨터 게임이라고 알려진 퐁 보다도 이전에 만들어진 오실로스코프로 만들어진 게임 Tennis for two입니다. 만든 이유가 박물관에 오는 손님들이 지루해하길래 지루함을 달래기 위해 만들었다고 합니다. 누군가의 요청이나 필요함에 대한 언급 없이 개발자 스스로 만들어 냈습니다. 더군다나 목적이 여흥을 위해서입니다.

게임은 창의력에서 발전해 왔다. 저는 이것이 게임 SW의 핵심이라고 생각합니다. 고객 혹은 Client의 요구가 정의되어 있지 않고 제작자의 의도가 우선하여 반영되기 때문에 게임은 IT 산업 중 예술에 가까운 산업이 되었다고 생각합니다.

한편 SW가 발전하면서 같은 요구목적을 가진 프로그램이더라도 품질에 차이가 나타나기 시작했습니다. 사람이 기획하고 사람이 만들어낸 코드에서 실행되는 것이니 어쩔 수 없는 일이었겠지요. 하지만 초기엔 이게 잘 만들어진 것인지 못 만들어진 것인지 판단하기도 어려웠습니다.

그래서 사람들은 SW의 품질 평가를 할 수 있는 모델을 만들자고 생각했습니다.

그래서 나온 것이 ISO 9126 입니다. 실은 이런 연구가 몇 가지 더 있는데 그중에서 유명한 게 ISO 9126입니다. 그리고 국제 표준화 기구에서 심사 단계의 최종에 다다른 모양입니다.

어쨌든 ISO 9126에서 다루는 SW의 품질 모델은 다음과 같습니다.

	주특성	주특성 내용	부특성
품질 특성	기능성	소프트웨어가 특정 조건에서 사용될 때, 명시된 요구와 내재된 요구를 만족하는 기능을 만족하는 기능을 제공하는 소프트웨어 제품의 능력	적절성
			적밀성
			상호 운용성
			준수성
			보안성
	신뢰성	소프트웨어가 규정된 조건에서 사용될 때 규정된 성능수준을 유지하거나 사용자로 하여금 오류를 방지할 수 있도록 하는 소프트웨어 제품의 능력	성숙성
			결함허용성
			회복성
			유용성
	사용성	소프트웨어가 규정된 조건에서 사용될 때, 사용자에 의해 이해되고, 학습되며 선호될 수 있게 하는 소프트웨어 제품의 능력	이해성
			학습성
			운용성
	효율성	규정된 조건에서 사용되는 자원의 양에 따라 요구된 성능을 제공하는 소프트웨어 제품의 능력	시간행동
			자원이용
	유지보수성	소프트웨어 제품을 변경할 수 잇는 능력, 변경에는 운영환경과 요구사항 및 기능적 사양에 따름 소프트웨어의 수정, 개선, 혹은 개작 등이 포함된다.	분석성
			변경성
			안정성
			시험성
	이식성	다양한 환경에서 운영될 수 있는 소프트웨어 제품의 능력	적응성
			설치성
			병행 존재성
			적합성
			대체성

[출처] ISO9126 품질속성|작성자 인생은쇼

 

QA는 위와 같은 품질모델에 맞게 SW가 제작되었다는 것을 증명하기 위해 테스트를 하는 것입니다.

SW가 품질모델을 준수하여 만들어졌다면 정말 잘 만든 것이라고 볼 수 있을 것입니다. 좋은 프로그램은 팔리기도 잘 팔리겠죠.

하지만 게임은요? 위의 품질모델을 준수하여 만들었다고 게임이 흥행하지는 못합니다.

왜일까요? 묻는 것조차 쑥스러울 정도입니다. 게임 SW의 품질이 좋을지언정 위의 모델이 게임성(재미)을 보장하지는 않거든요.

일반 SW는 고객의 요구가 중시 됩니다.

ATM 소프트웨어는 은행의 요구가 수술기기 혹은 병 진단기는 병원(의사)의 요구 그리고 회계 프로그램은 회계사의 요구가 중시 됩니다. 사용자의 요구가 중요시되는 것이 당연합니다.

게임 SW는 누가 고객인가요?

과거에는 프로그래머가 자신이 기획도 하고 제작도 하고 했습니다. 하지만 현대의 게임을 설계하는 것은 거진 기획자들입니다. 기획자들의 요구가 프로그래머에게 전달되어 구현됩니다. 그런데 그 기획자들이 하려고 게임을 만드는 것은 아닙니다. 기획자는 자신들이 생각한 이용자들이 어떻게 하면 재미있을지 만족할 수 있을지를 생각하여 게임을 설계합니다. 그렇다면 이용자들이 고객인가요?

그런데 게임의 이용자들은 게임이 자신에게 전달되기 전까지는 요구사항을 전달하지 않습니다. 패키지 게임은 물론이거니와 온라인 게임도 CBT를 하기 전까지 제작자들은 이용자의 요구사항을 알기 어렵습니다.

더구나 요구사항을 안다고 하더라도 모든 것을 수용할 수는 없습니다. 게임은 그 고유의 게임성을 유지해야 하는데 이용자들의 요청사항 중에는 고유의 게임성을 벗어나는 요청도 있거든요.

SW는 쓰기 쉽고 이해하기 쉬우며(UI와 UX가 좋아야 하며) 버그가 없으면 좋은 소프트웨어라고 할 수 있습니다.

게임은 쓰기 쉽고 이해하기 쉬운 것도 중요하지만, 재미 혹은 게임성을 갖추고 있어야 좋은 게임이라고 할 수 있습니다.

계속 다른 얘기를 늘어놓은 것 같지만 모두 한가지 화두를 위해 얘기했습니다.

게임 QA는 게임성에 관여해야 하는가?

QA는 품질을 관리하며 이용자들에게 만족감을 줄 수 있다는 보증을 해야 하는 파트입니다.

그렇다면 게임 QA는 게임성과 재미가 있어야만 이용자들에게 만족감을 줄 수 있다는 보증을 할 수 있을 것입니다.

그런데 안타깝게도 재미라는 것은 주관이 개입되기 쉬운 요소입니다.

세계에서 제일 잘 팔렸다는 슈퍼마리오라는 게임도 어떤 성향의 이용자들에게는 재미없는 게임 일 수 있는 것입니다.

으아아아아아아아아아아아악!!!!!!!!!

저는 게임성도 게임 품질의 한 요소지만 게임 QA가 무작정 관여해서는 안 된다고 생각합니다.

2가지의 경우를 예로 들어서 설명해 드리겠습니다.

A. 포스터 와우를 만들고 싶어하는 개발팀의 QA

- 다행히도 게임의 컨셉이 명확합니다. 최대한 WOW의 게임성을 가져오고 싶어합니다.

- WOW 경험이 많은 QA팀의 당신은 QA를 하던 중 자사 게임이 어떤 요소가 WOW와 맞지 않는 성향을 가지고 있는 것을 느낍니다.

- WOW의 해당 요소를 열심히 벤치마킹해 자사 게임과 비교 리뷰를 작성해 건의 합니다.

- 포스트 와우를 만드는 게 목적이기 때문에 당신의 리뷰는 정당한 평가를 받을 수 있을 것 같습니다. (아직까진 QA팀의 게임성 건의는 많은 시련을 겪어야 힘들게 받아들여진다는 걸 기억하세요.)

B. 차세대 MMORPG를 만들고 싶어하는 개발팀의 QA

- 차세대인 만큼 새로운 게임컨셉을 가지고 있습니다. 이때까지 어떤 MMORPG에도 없던 독창성을 가지고 있습니다.

- WOW 경험이 많은 QA팀의 당신은 QA를 하던 중 자사 게임의 어떤 요소가 WOW를 벤치마킹하여 만들면 더 재미있을 텐데 라는 생각을 하게 됩니다.

- 당신은 열심히 WOW의 해당 요소와 자사 게임의 비교 리뷰를 작성하여 건의 합니다.

- 기획자는 우리 게임은 WOW와 다른 게임성을 가지고 있기 때문에 건의 사항과 같이 튜닝하면 다른 요소들을 모두 변경해야 하며 그러면 초기 컨셉과 다른 게임이 된다는 얘기를 합니다.

 

 A와 B의 차이를 아시겠나요? 가장 큰 차이는 초기컨셉의 이해입니다. A는 QA팀이 이미 자사 게임이 WOW의 많은 부분을 따르려 한다는 것을 알고 있습니다. B는 물론 내부적인 초기컨셉이 있었겠지요. 그러나 자신이 생각한 재미요소를 건의했고 해당 내용이 WOW를 따르지 않는 새로운 게임성을 만든다는 점에서 배제된 것입니다.

위에서 계속 게임성(재미)에 관한 이야기를 언급했습니다만 게임성의 품질은 보증하기가 어려운 업무입니다.

왜냐면 그건 창의적인 작업이니까요. 이를테면 이런 겁니다.

화가에게 “제가 앤디 워홀 작품을 봤는데요. 그걸 그렇게 그리면 안 돼요. 앤디 워홀 그림 비싸게 팔리시는거 알죠? 이렇게 작업하셔야 잘 팔려요.”

혹은

박진영에게 “아니 저렇게 볼 빵빵한 애하고 아줌마 같은 애를 걸그룹에 넣어두고 성공하겠다고!? 소녀시대를 봐봐! 다들 이쁘고 귀엽고 다리도 좍 빠졌잖아. 그런 애들을 넣어야지!!” (절대 전 원더걸스 안티는 아닙니다!!)

하는 겁니다.

앤디 워홀을 모작 중인 작가에게는 위와 같은 소리 해도 됩니다. 소녀시대 같은 걸그룹을 가지고 싶어하는 박진영에게도 위와 같은 소리 해도 됩니다.

하지만 그들이 원하는 건 그것이 아니기 때문에 안되는 것입니다.

그런데 위에 예로 써드린 A, B외의 정말 이도 저도 아닌 게임을 제작 중인 스튜디오에서 일할 수도 있습니다.

이건 분명 건의해야 한다! 그래서 고쳐야 한다!

 

그런 분들은 
http://wp.me/p1VNqt-X  글을 참고 해보시면 어떨까요?
마지막으로 3줄 요약해보도록 하겠습니다.

1. QA는 품질보증을 해야 하는 업무이기 때문에 게임성에 대해서도 시장성이 있는지 보증을 해야 한다.

2. 하지만 게임성은 게임 SW가 SW에는 없는 고유의 특성이며 제작자의 창조적인 작업이므로 무작정적인 게임성 건의는 옮지 않다.

3. 될 수 있으면 초기 컨셉 및 리뷰하고자 하는 대상의 컨셉을 이해하고 의견을 전달할 수 있도록 하자.