폭포수(waterfall) 모형의 이러한 문제들 때문에, High Moon Studios에는 반복적이고 점증적인 방법론(iterative and incremental methodology)으로 돌아가려는 강렬한 욕구가 있었다. 이에 대한 가장 큰 장애물은 팀의 규모였다. 우리는 보다 공식적인-규모가 10명 이하였을 때의 분위기로 돌아갈 수 있는 일련의 실천 사항들로 이루어진-방법론이 필요했다.

우리는 Scrum을 발견했고, 채택한지 한 달 이내에, 팀의 생산성과 사기에 커다란 향상이 있었다. 우리 팀은 이내에 또 다른 이점을 깨달았다: 우리가 개발하던 게임이 형태를 갖추기 시작했고, 단기간에 얼마나 할만하고 재미있는가를 확인할 수 있었다. 나중에 우리 프로그래밍 팀은 Extreme Programming (XP)를 채택했고, 또 한 번의 중요한 발전이 있었다.

CHALLENGES

난관들

Agile을 채택했을 때, 우리는 모든 사항들을 준수하는 것을 목표로 했다. 우리는 그 원칙을 완전히 이해했을 경우에만 그것을 변형해서 적용하기로 했다. 사실 고위 관리자들이 Agile의 원칙들을 충분히 이해하고, 폭포수(waterfall) 모형에서는 옳지만 Agile에서는 그렇지 않은 잘못된 결정을 내리는 것을 중단하기까지 정말 오래 시간이 걸렸다.

Agile을 적용한지 수개월이 지나고 그 실천 사항들(pratices)에 숨겨진 이유들을 이해하게 되었을 때, 우리는 부딪힌 난관들을 해결하기 위해서 Agile에 변형을 가하기 시작했다.

HARD DEADLINES

빡빡한 마감

비디오 게임 개발은 빡빡한 마감 날짜들에 맞춰서 돌아간다. 대부분의 마감 날짜들은 매해의 특정 시기에 맞추어져 있으며, 마케팅상의 이유로 결정된다. 마케팅상의 마감은 게임의 성공에 매우 중요하다. 많은 주류 게임들이 대목인 연말(a holiday release)[1]에 맞춰 출시된다. 영화를 원작으로 하는 게임은 영화와 게임이 동시에 출시되어야 한다.

정해진 일정이 있기 때문에 개발에서 선택 가능한 사항은 오직 개발 범위(scope)뿐이다. 예산이 유동적일 수는 있지만, 프로젝트 후반에 인력을 더 투입하는 것은 오히려 상황을 악화시킬 뿐이다[2]. 개발 범위를 조절하는 데에는 반복적이고 “가치를 우선(value first)”하는 접근법이 빛을 발한다. Agile을 사용하면, 매주기마다 최우선 항목들(the most important features)을 반복적으로 먼저 개발하게 된다. 팀이 시간에 쫓기게 되면, 아직 적용하지 않은 기능들이 이미 적용된 기능들보다 덜 중요하다고 확신하고, 쓸데없는 기능을 추가하지 않게 된다.

폭포수(waterfall) 모형을 사용하여 개발할 경우, 기능의 구현이 반드시 중요한 것부터 순서대로 진행되지는 않는다. 예를 들어서, 기술 팀은 인공 지능(이하 AI)이 완성되기 전에 복잡한 애니메이션 시스템에 집중하고 싶어할 수도 있다. 만약 애니메이션이 예상보다 오래 걸린다면, 원래는 AI 개발에 할당되었던 시간을 사용할 것이고, 이렇게 개발된 AI는 사용자들에게 그다지 매력적이지 않을 수도 있다. 반복적인 접근법에서는, 다른 부가적인 기능을 추가하기에 앞서, 게임의 가장 중요한 기능들을 완성하는데 요구되는, 적절한 수준의 애니메이션과 AI를 개발하는 것을 목표로 하게 된다. 다시 말해서 반복적인 접근법의 목표는, 예정된 계획을 따르는 것이 아니라, 필요한 수준의 기능을 개발하는 것이다.

CONTRACTS

계약

개발사들은 배급사와 계약을 체결하여 비디오 게임을 만든다. 배급사의 역할은 개발에 대한 대가를 지불하고, 게임을 홍보하며, 그 게임이 담긴 DVD나 카트리지를 대량 생산해서 배포하는 것이다.

폭포수(waterfall) 모형에서, 많은 배급사들은 게임이 어떻게 개발될 것인가에 대해 사전에 구체적인 계획(an up-front, well-fleshed-out plan)과 언제 어떤 기능이 완성될 것인지에 대한 일정을 요구한다. 이 결과물들, 즉 “마일스톤(milestones)”은 개발사에 대한 자금 지급과 결부된다. 마일스톤에 따른 지급은 개발사에게는 생명줄이며, 생존에 필수적이다. 계약, 즉 마일스톤 식의 일정은 (해당 기능들의 가치와 상관없이) 개발사들이 사전에 정의된 모든 기능들이 구현하도록 유도한다. 그러나 동시에 마일스톤 식의 일정은 어떤 변경 사항이 생겼을 때, 배급사와 개발사 사이에 장애물을 만들기도 한다.

Agile을 적용할 때 겪는 어려움들 중 하나는, Agile 방법론을 허용하는 계약을 성사시키는 것이다. Agile planning은 유동적이고 오직 짧은 기간(보통 3달)만을 대상으로 한다. 이런 단기 일정이 한때 많은 배급사들을 겁에 질리게 했었지만, 이제 배급사들은 사전에 상세한 계획을 요구하는 것이 부질없는 짓이라는 것을 깨닫기 시작했다. 개발사와 배급사 사이의 신뢰 또한 넘어야 할 장벽들 중에 하나다. 배급사가 개발사의 개발 속도와 품질에 대한 헌신을 인식하게 되고, 개발사가 배급사의 비전과 성실성을 믿게 되는 데에는 오랜 시간이 필요하다. 신뢰는 둘 사이의 유대를 강화시키고, 더 나은 게임이 완성되는 배경이 된다.

신뢰가 구두 계약을 의미하지 않지만, Agile의 반복적이고, 유연한 접근법을 반영할 필요는 있다. 예를 들어서, 만약 어떤 게임을 개발할 것인지 사전에 충분히 정의하지 않는다면, 개발사의 계약위반 여부를 알기가 어렵다. 이러한 문제를 해결하기 위한 한 가지 방법은, Agile에서 “출시(release)”라고 불리는 3~6개월마다, 여러 개의 작은 계약들을 체결하는 것이다. 그리고 각 출시 시점마다 잠재적으로 시장에 배포될 수 있는 버전을 만든다. 이러한 단기 계약들에는 개발사와 배급사간의 굳은 믿음이 필요하다. 그러나 만약 게임이 매 출시 단계마다 점점 더 가치가 증가하거나 재미있어진다는 것을 보여준다면, 배급사가 개발사의 개발 진도를 파악하기 쉬울 것이다.

SPECIALIZED ROLES

전문 영역들

진정한 Agile 팀들을 구성할 때, 겪는 또다른 어려움은 전문 영역들의 존재이다. 전통적으로, Agile 팀들에는 서로 상대방의 업무를 거의 이해하지 못하고, 일정 수준까지만 협력하는 전문화된 프로그래머들이 있다. 게임 개발팀들에서는 아티스트, 게임 기획자와 프로그래머가 완전히 서로 다른 역할을 수행한다. 아티스트가 프로그래머의 작업을 보는 것은(혹은 그 반대의 경우), 흡사 “흑마술(black art)”을 보는 것과 같다. 따라서 진정한 Agile 팀들을 조직하기 위해서는 동료들 사이에 많은 믿음과 신뢰가 필요하다.

게임 개발팀은 특성상 이질적인 전문 분야들이 혼합되어 있기 때문에, Agile의 기본적인 실천 사항들(the basic agile practices)을 실천하는 것이 쉽지 않다. 자율 조직(self-organization)이라는 방식이 더 어려운 이유는, 아티스트들이 프로그래머들과 동일한 기준들(criteria)로 팀 프로그래머들을 선택하지 않기 때문이다. 복수의 전문 분야가 뒤섞인 업무 환경(across-discipline team environment)에서 더욱 이루어지지 힘든 멘토링(mentoring)과 업무 공유도 상황은 마찬가지이다.

팀을 이상적인 규모로 유지하는 것은 더욱 달성하기 힘들다. Agile에 따르면, 한 팀은 8~12명으로 구성된다. 이것을 초과하면, 의사 소통의 경로가 너무 복잡해져서 자율적이기 어렵다. 한 팀에 복수의 분야가 있을 경우, 분야당 필요한 최적의 인원수(critical mass)를 갖추기 어렵다. 예를 들어서, XP에서는 2조를 짜기 위해서 최소 4명의 프로그래머가 필요하다.[3] 6명이면 이상적이지만, 각 분야마다 6명을 배치하면 규모가 너무 커진다. 이에 대한 해결책은 각기 한쪽 분야에 살짝 더 비중을 두는 팀들(teams that are skewed slightly toward one discipline over the others)을 구성하는 것이다.[4] 그것 또한 새로운 난관이 될테지만, 팀의 규모를 작게 유지해준다.

처음에 우리는 프로그래밍 부서에만 Scrum을 적용시켰다. 아티스트와 기획자들은 Scrum 프로그래밍 팀들을 조직하는 프로젝트의 고객들이었다. 우리는 고객의 요구를 전달받지 못했기 때문에(due to lack of customer input), 매 Sprint 마다 수백 번의 진행 장애를 겪고 있다는 점을 재빨리 깨달았다. 우리가 Scrum 팀들이 대부분의 장애물을 내부적으로 즉시 해결할 수 있도록 자급자족적이어야 한다는 사실을 깨달았을 때, 아티스트들과 기획자들이 팀에 합류했다.

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) 평가를 받아 질적으로 향상되었다는 것을 증명해야만 했다. 게임 하나가 출시될 때마다, 열 개의 게임이 취소되기도 했지만, 그 한 개가 성공을 거두면 충분한 수익을 거둘 수 있었다.

곧 게임 개발에 대한 주요한 압력(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)의 가치를 알기 힘들기 때문에, 그것은 매우 중대한 문제였다. 비디오 게임에서 가치란 재미이며, 이 가치를 정의하는 많은 요소들은 게임을 실행해야만 뚜렷이 드러나게 된다. 재미는 문서로 표현하기가 무척 어렵다.