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

<게임으로 오세요: 게임 개발자들에게 배워야 할 점들> 제2편입니다.

이번 제2편에는 High Moon Studios에서 <GDC 2007 - Agile Game Development>에 이르기까지 어떤 과정을 겪었는지를 보여줍니다.

한편 제1편도 주석을 달아서 보강했습니다.

 

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

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

2/3

 

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

작성: Clinton Keith

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

MOVING TO AGILE
Agile로의 이행

폭포수(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 팀들이 대부분의 장애물을 내부적으로 즉시 해결할 수 있도록 자급자족적이어야 한다는 사실을 깨달았을 때, 아티스트들과 기획자들이 팀에 합류했다.

                               

[1] [역자주] 성탄절(Christmas)을 전후로, 추수감사절(Thanksgiving day, 11월 마지막 목요일) 즈음부터 연초(New Year’s Day)에 이르는 기간. 북미 시장의 경우, 한 해 매출의 절반 가까이가 이때 발생한다.

 

[2] [역자주] Kurt Bittner는 “유스 케이스를 이용한 반복 개발(Driving Iterative Development With Use Cases”에서 다음과 같이 설명하고 있다;

“프로젝트 후반에 사람들을 투입하면 프로젝트는 더 지연된다. 아키텍처가 안정되지 않고 작업이 독립적인 단위로 효과적으로 나뉠 수 없을 경우에는 더욱 그렇다. 이 경우 서로 충돌을 방지하기 위해 지속적으로 통신해야 하기 때문에 작업이 느려지고 더 많은 사람들이 하나의 프로젝트에 작업하더라도 실제 작업은 줄어들게 된다.”

[3] [역자주] 4명 = 2조 * 2명. XP의 짝 프로그래밍(Pair programming)-두 명의 프로그래머가 한 조를 이루어 함께 프로그래밍 하는 것-을 말한다.

[4] [역자주] 예를 들면, 프로그래밍이 중요한 팀에는 6명을, 보통은 4명을, 별로 필요하지 않은 곳에는 2명을 배치하는 것을 말한다. 이 경우, 각 팀이 일정 크기를 유지하기 위해서, 그만큼 각 팀의 아티스트나 기획자의 수가 줄거나 늘어난다.

<< 이전: 비디오 게임 개발의 역사 <<           >> 다음: 서로 다른 분야들에 대한 지원 >>

.