게임으로 오세요: 게임 개발자들에게 배워야 할 점들 1/3

<GDC 2007 - Agile Game Development>에서는 Agile이 무엇인지, <게임 개발에 Scrum을 도입하다>에서는 그것이 게임 개발에 미칠 영향을 볼 수 있었습니다.

그렇다면 이제 Agile을 게임 개발에 적용할 때, 겪게 될 난관들을 확인해보는 것은 어떨까요? :)

"게임으로 오세요: 게임 개발자들에게 배워야 할 점들"은 High Moon Studio가 Agile을 적용하면서 어떤 어려움을 겪었고, 그것을 어떻게 극복했는가를 다루고 있습니다.

마지막으로 이 글은 약 3회에 나누어서 번역할 예정이며, 이번 제1편에서는 Agile이 출현하게 된 배경에 대해서 설명하고 있습니다.

게임으로 오세요: 게임 개발자들에게 배워야 할 점들

(Get in the Game: What others can learn from game developers) 

1/3

 

출처: p. 24, Better Software (November, 2006)

작성: Clinton Keith

번역: 김기웅, Nikopole(교정), Khazad(교정) 

12년도 더 전에, 나는 방위 산업체의 소프트웨어 엔지니어를 그만두고, 비디오 게임 프로그래머가 되었다. 게임들이, 코드의 길이로 볼 때, 규모가 10배나 크고, 더 최신의 기술을 사용하며, 개발 주기(pace of product development)가 훨씬 빠르다는 사실에 충격을 받았다. 게임 산업은 의욕이 넘치는 최고의 프로그래머들을 유혹했고, 사람들은 최신 소프트에어 공학 이론에 대해 열띤 토론을 했다. 그러나 이러한 열광에는 프로젝트 관리 절차가 결여되어 있었으며, 심지어 몹시 경멸당하기도 했다.

 

불과 30년만에 비디오 게임은, '퐁(Pong)'을 만들던 장난감 시장의 작은 틈새에서, 할리우드 영화보다 더 큰 엔터테인먼트 산업의 한 분야로 성장했다. 그 변화는 개발팀과 예산의 규모를 기하급수적으로 증가시켰다.

 

이 두 가지 요인들-급성장한 프로젝트 규모와 미비한 관리-은 게임 산업 전반에 엄청난 문제들을 일으켜 왔다. 그 중 하나는 때때로 개발자들을 혹사시키는 것이다; 야근이 1년 내내 지속되는 것도 드물지 않으며[1], 그로 인해 야근 수당에 대한 소송들이 줄을 이었다. 일정이 지연되고 예산을 초과하는 것 또한 일상사다.

 

이러한 문제들을 해결하기 위해, High Moon Studios는 다른 산업의 경험을 거울 삼아, 정해진 예산 하에서 경쟁력을 유지하면서도 제 시간에 게임을 출시하기 위해 Agile methodology를 사용했다. 우리의 특수한 개발 환경 때문에 일부 내용을 바꾸어야만 했지만, 그게 ‘Agile이란 무엇이어야 하는가?’라는 비전(vision)을 해치지는 않았다. 우리는 시작부터 의사 소통과 반복적인(iterating) 개발에 초점을 맞추었고, 여러 방향으로부터의 다양한 변화에 대응해서, 보다 나은 제품을 만들 수 있었다.

 

 

 

BACKGROUND OF VIDEO GAME DEVELOPMENT

비디오 게임 개발의 역사

 

내가 비디오 게임 산업에 처음 들어왔을 때, 게임 산업의 역사는 20년이 채 되지도 않은 시점이었다. 1970년대 후반과 1980년대 초반, 게임 산업은 중대한 변화를 경험한다. 아케이드 게임기-나중에는 콘솔이 가정에서 동일한 상황을 연출한다-는 어마어마한 돈을 갈퀴로 쓸어 담고 있었다.

 

이 시기에, 1~3명으로 이루어진 팀이 약 3달 동안 게임 한 개를 만들 수 있었다. 하드웨어는 불과 수백 KHz로 돌아가는 8Bit 프로세서, 16K 메모리, 저해상도(256색) 2D 그래픽으로 이루어져 있었다. 자원은 제한된 반면, 소비자는 하드웨어를 극한까지 밀어붙이길 원했기 때문에, 개인적인 영웅주의가 팽배했다. 심지어 프로그래머가 그래픽 소스(the game art)를 만드는 경우도 종종 있었다! 개발의 큰 장애물은 아케이드용 기판-혹은 가정용 콘솔의 카트리지-를 대량 생산하는 비용이 게임을 만드는 것보다 훨씬 비쌌다는 점이었다. 그 결과, 개발은 반복적(iterative)이고 점증적(incremental)이 되었다. 게임들은 일정 시기마다(at frequent intervals or risk cancellation) 평가를 받아 질적으로 향상되었다는 것을 증명해야만 했다. 게임 하나가 출시될 때마다, 열 개의 게임이 취소되기도 했지만, 그 한 개가 성공을 거두면 충분한 수익을 거둘 수 있었다.

 

이러한 높은 수익과 폭발적인 수요로 문제가 발생했다. 품질 관리가 느슨해지면서 무수히 많은 게임들이 쏟아져 나오게 된 것이다. 1980년대 중반에 일어난 이 사태는 게임 산업에서 처음이자 가장 큰 재앙으로 기록되었다.[1] Atari 같은 회사들은 수억 달러의 손실을 보았고, 아무도 사고 싶어하지 않는 수만 개의 카트리지들이 쓰레기 매립장에 묻혔다.

 

가정용 콘솔의 혁신으로 시장은 빨리 회복되었고, 콘솔 제조업자들의 통제 강화와 함께 매출도 꾸준히 성장했다. Nintendo는 어마어마한 성공을 거둔 가정용 콘솔[2]을 출시했고, 출시되는 소프트웨어를 엄격하게 관리해 게임 업계 부활의 주역이 되었다.

 

곧 게임 개발에 대한 주요한 압력(the major pressure)은 [기판이나 카트리지의 대량 생산이 아닌] 발전하는 하드웨어의 성능으로 바뀌었다. 1980년대의 몰락으로부터 10년 이내에, 콘솔은 20Mhz 이상의 프로세서, 4Mb의 RAM와 3D 그래픽을 갖추었다. 숙련된 아티스트가 정말 사실적인 그래픽 소스(highly realistic art)를 만들어냈고, 프로그래밍 팀은 영상, 음향과 인공지능 같은 전문적인 기술 분야를 다루었다. 이제 게임 하나를 만드는데, 12명 이상의 인력과 1년이라는 시간이 필요해졌다.

 

이 시점에서 암묵적이면서 점증적이고 반복적인 개발 방법은 두 가지 이유로 붕괴되기 시작한다. 첫째, 12명에 달하는 전문가들간의 의사소통은 3명의 프로그래머들 사이에서처럼 순조롭지 않았다. 이러한 틈새로 개발의 세부 사항들이 누락되곤 했고, 그 결과 불필요한 작업들이 늘어났다. 둘째, 개발비가 제조와 마케팅 같은 다른 비용들을 초과하기 시작했다. 자금을 제공했던 회사들은 여전히 돈을 벌고 있었지만 예전처럼 1개의 게임을 출시하기 위해, 열 개의 게임들을 취소할 수는 없었다.

 

"비디오 게임에서 가치란 재미이지만, 재미는 문서로 표현하기가 무척 어렵다.”

 

그에 따라, 보다 구조적이고 전통적인 방법론이 게임 개발에 도입되었으며, 폭포수(waterfall) 모형[3]이 가장 흔한 경우였다. 폭포수(waterfall) 모형은 팀 규모 증가와 프로젝트 개발 주기 변화를 경험했던 다른 산업들에서 인기가 있었다. 이 기법은 규모가 커진 프로젝트를 관리하기 위해서, 몇 개의 단계들로 구분하였다: 계획(planning), 시제품(prototyping), 개발(development), 통합(integration), 시험(testing). 프로젝트 초반에 문서를 통해서 개발하려는 제품과 그 제품의 특성들(attributes)을 정의하고, 12명이 넘는 개발자들은 그 문서대로 최종 제품을 만들었다.

 

폭포수(waterfall) 모형은 반복적인 개발(the ability to iterate)을 희생시켰다. 프로젝트 초반에는 게임과 특징들(attributes)의 가치를 알기 힘들기 때문에, 그것은 매우 중대한 문제였다. 비디오 게임에서 가치란 재미이며, 이 가치를 정의하는 많은 요소들은 게임을 실행해야만 뚜렷이 드러나게 된다. 재미는 문서로 표현하기가 무척 어렵다.

                             

[1] [역자주] 이것이 그 유명한 Atari Shock이다. 자세한 것은 아타리 쇼크는 어쩌다 일어났는가? (상) 및 아타리 쇼크는 어쩌다 일어났을까? (하)를 참조할 것.

[2] Famicom (북미에서는 Nintendo Entertainment System, NES)을 말한다.

[3] [역자주] 폭포수 모형(waterfall model)에 대해서, 초보자를 위한 eXtreme(익스트림) 프로그래밍(리팩토링과 기민한 모델링)은 발췌/편집하여 언급하면 다음과 같다;

“폭포수 모형은, 1960년대 복잡한 군사용 소프트웨어 개발을 위해 미국 해군에서 고안되었다. 폭포수 모형에서 프로젝트는 다음의 정해진 순서를 따르게 된다: 개념, 요구사항 분석, 설계, 코딩, 테스팅. 각 단계의 끝에서 프로젝트 팀은 최종 점검까지 모두 끝낸 후 고객의 승인을 받게 되고, 고객이 만족하지 않는 한 다음 단계로 넘어가지 않는다…(중략)…이 모형의 다른 특징은 계획을 중요시한다는 것이다. 만약 프로젝트에 수정이 필요하게 된다면 이미 끝난 부분의 작업을 다시 하는 것이 어렵고 성가시게 된다…(중략)…결국 폭포수 모형은 군대와 같이 엄격하게 관리 통제되는 환경에 적합하지만, 변화가 많은 일반 사업의 세계에서는 몇 가지 심각한 단점을 지니고 있다.”

                                                                    >> 다음: Agile로의 이행 >>
..