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

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

이번 제3편에는 애자일 게임 개발을 위해서 조직을 어떻게 구성할 것인가에 대해서 다룹니다. 동시에 가장 논란이 될만한 '야근'에 대한 언급도 있습니다.

아마도 이 글을 읽으시는 분들 중에는 "이건 불가능하다."라고 회의적인 분들 있을 겁니다. 가능하다면 김창준 님의 "극과 극" "평범한 직원들로 천재 조직 만들기"를 읽어보시길 권해드립니다.

그리고 즐거운 실험에 동참해보십시요!

..

..

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

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

3/3

 

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

작성: Clinton Keith

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

SUPPORTING THE DISCIPLINES

서로 다른 분야들에 대한 지원

 

Agile을 적용하기 전에, 우리 프로젝트 팀들은 각각 일단의 프로그래머들, 기획자들, 아티스트들로 분리되어 있었다. 이것은 공통된 분야의 기술(shared disciplinary skills)을 갖고 있을 경우에는 훌륭한 방식이었으나, 게임이 정상적으로 돌아가도록 하는 간접 비용(the overhead)을 증가시켰다. 우리가 Agile을 적용했을 때, 이 점이 명확해졌고, 변화가 필요했다. 초반에 저항이 있었고, 이것이 결과적으로는 우리를 요소 제작팀들(feature teams)로 변화시켰다.

 

처음에 우리는 한 개의 특정 분야가 주도하는 여러 개의 “기능 제작팀들(functional teams)”을 구성했다. (예를 들어, AI 팀은 대부분 프로그래머로 이루어진다.) 몇 달 후, 문제들이 발생했다. AI 팀은 ‘진공 상태’[1]에서 자신들의 작업물을 만들었다. AI의 요구사항(requirements)이 실제 게임 내에서 개발되고 시험되기 보다는, AI를 사용하는 모든 팀들이 필요로 하는 아키텍처를 제공하는데 초점을 둔 프로그래머 위주의 팀에 의해 개발되었던 것이다. 따라서 매 주기가 끝날 때마다, 아키텍처는 진보했으나, 실제 게임에서의 활용도는 별로 증가하지는 않았다.

 

그 다음, 우리는 기능 제작팀들(functional teams)에서 “요소 제작팀들(feature teams)”로 변화해갔다. 요소 제작팀들(feature teams)은 사격이나 주행 메카닉과 같은 서로 다른 분야의 연계가 필요한 게임 플레이의 독립적인 한 부분(a vertical slice of game play)을 만드는데 초점을 맞추었다. 목표는, 게임 플레이의 독립적인 한 부분을 반복적으로 개발하는데 필요한, 개발의 모든 분야를 취급하는 자급자족적인 팀이다.

 

“요소 제작팀들(feature teams)”로 전환한 결과, 핵심 기술의 개발 노력이 분산되었다. 예를 들어, 우리는 하나의 기능별 조직이 전체 프로젝트를 위한 하나의 AI를 만드는 대신, 각 요소 제작팀들(feature team)의 한두 명이 각각 AI를 만들도록 했다. 이 조치는 여러가지 문제들을 일으켰는데, 우선적으로는 기술 개발이 분열되는 양상을 초래했다. 이런 방식은 다양한 가능성을 탐색하는 초기(early exploration)에는 좋을지 몰라도, 전적으로 문제가 많았다. 우리는 마치 별개의 게임을 만드는 것처럼 행동하고 있었지만, 결과적으로 우리가 전체 게임을 위한 단 하나의 AI 시스템이 필요하게 될 것이라는 것을 알았다. 또한 우리는 요소 제작팀들(feature teams)이 자원을 놓고 서로 경쟁하는 것을 목격했다. 이 방식은 모든 팀들이 전체 프로젝트의 일부분이라는 인식을 심어주지 못했다.

 

해결책은 추가로 각 전문 분야마다 가상의 팀들(virtual teams)을 조직하는 것이었다. 프로그래머들은 자신들의 Scrum Master[2] 한 명과 팀을 이루고, 그들은 일주일에 최소 한 번 이상 만나서, 팀의 기술적인 발전 방향을 논의했다. 프로그래밍 분야의 Scrum Master는 다른 분야(아트 및 기획)의 Scrum Master들과 만나서 게임의 비전을 창출한다. 이것은 각각의 분리된 팀들이 보다 효과적으로 의사 소통하도록 해줄 뿐만 아니라, 그들 모두가 최종 제품의 한 부분이라는 점을 인식시켰다.

 

 

 

DEVELOPMENT PHASES

개발 단계

Agile 게임 개발법은 폭포수(waterfall) 모형에서 제시된 프로젝트 단계들을 인정한다. 예를 들어서, 컨셉 발전 단계(the concept-development phase)에서는 고객이 창조적인 목표들을 전반적으로 그려볼(visualize) 수 있도록, 게임의 창조적인 가능성들과 한계들을 실험해본다. 개발 도중에는 게임 프로젝트의 가능성을 충분히 탐색하기가 불가능하다. 고객은 게임을 위한 라이센스와 함께 마케팅적인 척도나 요구사항들을 갖고 있을 것이며, 이것은 사전-시각화(pre-visualization)[3]와 원화(concept art)를 필요로 한다.

 

제작 단계(the production phase)는 프로젝트의 후반부, 즉 상당수의 게임 리소스-캐릭터와 레벨들-가 자리 잡아가는 시기를 말한다. 제작 단계 이전에는 별다른 제약 없이 게임 플레이를 실험해볼 수 있다. 우리는 그 시기 동안, 몇 개의 대표적인 레벨들과 캐릭터들을 만들었다. 어떤 자원을 생산할지를 결정하는 재미의 요소들을 발견하자, 우리는 [손상되거나 변하지 않도록] 재미의 요소들을 고정시켰다.

 

 

 

CRUNCH TIME

야근

 

게임 산업은 야근으로 악명이 높다.[4] 최근에는 게임 개발사 직원들을 위한 본보기적인 소송들(high-profile lawsuits)이 발생하고 있으며, 종종 집에 들어오지 못하며 고생하는 직원들의 가족들이 때때로 원고가 되기도 한다.[5] 다행히도 우리는 그런 문제를 겪지 않았다. 우리는 Scrum 기법의 일환으로 과거 경험에서 누적된 자료(the empirical data)를 사용하였기 때문에, 야근을 근본적으로 제거했다. Scum에서는, 한 주기(a sprint) 동안 하루 단위로 남아 있는 업무를 추정한다. 한 주기에서 남아 있는 시간의 일일 변동량을 속도(velocity)라고 하며, 도표로 표시된다. 기술적 장애물, 휴가, 좌석 배치 등과 같이 속도에 영향을 미치는 많은 요소들이 이 도표에 나타난다. 또한 팀의 업무 효율(effectiveness) 역시 이 도표에 드러난다.[6]

 

우리는 심지어 Scum에서도 해당 주기의 다가오는 마감에 맞추어 야근을 하도록 강요당한 적이 있었다. 그러나 이것은 경영진이 Scrum의 규칙들을 무시하고 팀으로 하여금, 업무(work)에 헌신하도록 하기보다, 하루에 10시간씩, 1주일에 6일이라는 일정(schedule)에 헌신하도록 고집했기 때문이었다. 초반에는 속도가 증가했으나, 수주가 지나자 속도는 야근 이전 수준(the pre-crunch-time level)으로 떨어져 버렸다. 사람들이 야근을 하게 되면 지칠뿐만 아니라, 프로그래밍상의 오류(game bugs)나 잘못된 그래픽 소스(art mistakes)와 같은 많은 실수들을 범하게 된다. 이것들은 수정하는데 별도의 시간이 필요하기 때문에, 결과적으로 속도를 감소시킨다.

 

 

이것은 우리에게 중요한 교훈이었다. 팀들은 해당 주기의 목표를 달성하기 위해서 추가 근무를 할 수도 있다. 그러나 경영진은 더 이상 그것을 강요하지 않는다.

 

 

 

SUMMARY

요약

 

우리는 Agile을 어떻게 비디오 게임 개발에 응용할 것인지를 계속해서 탐색해 보고자 한다. 대가는 크다. 진보된 방법론은 게임 가격이 합리적이 되도록, 개발비를 줄여준다. 또한 극소수만이 창조적인 도전을 기꺼이 받아들이고, 나머지 대부분은 위험을 무릅쓰려 하지 않는 추세(the increasing risk-averse trend)에 편승하지 않도록 도와준다. 현재 영화나 스포츠 라이센스를 기반으로 한 게임들과 성공적인 전작의 후속작들이 시장의 많은 부분을 차지하고 있다. 새로운 지적 재산이나 참신한 아이디어를 이용한 타이틀들을 개발하는 데, 막대한 돈을 투자하는 것은 너무 무모해 보일지도 모른다. 그러나 엔터테인먼트 산업에서 소비자의 돈과 관객의 관심은 더없이 소중하다. 비디오 게임의 전반적인 가치와 재미를 감소시키는 추세는 시장을 축소시켜서, 게임 산업의 모두에게 피해를 줄 것이다. Agile은 새로운 경험을 실험하고, 참신한 아이디어를 반복적으로 개발하여, 게임 속에서 재미를 빨리 그리고 자주 찾을 수 있도록 해주며, 우리의 고객을 즐겁게 하는 동시에 증가시키는, 보다 나은 길을 열어주는 체계(framework)를 제공할 것이다. {끝}

 

Clinton Keith는 최신 전투기의 항공 전자 장비용(avionics) 소프트웨어 개발을 그만두고, 비디오 게임 프로그래머가 되었다. 그는 현재 미국 캘리포니아 칼스버드(Carlsbad) 소재의 게임 개발사, High Moon Studios[7]의 기술 이사(the chief technology officer)로 재직중이다. 그가 개발하거나 개발을 진두 지휘한 것들을 몇 개 들자면, Midtown Madness, Midnight Club, Smuggler's Run과 Darkwatch가 있다. 게임을 개발하기 전에는 소프트웨어 엔지니어로서, Raytheon에서는 해저 관련 기술에, TRW에서는 YF-23과 YF-22에 관련된 일을 했었다.

 

해당 주제에 대한 보다 자세한 정보를 원한다면, www.StickyMinds.com/bettersoftware에 들러볼 것.

l  사전 제작: 재미의 요소들(Pre-production: elements of fun)

                             

[1] [역자주] 다른 팀들과 완전히 동떨어진 상태에서 개발을 했다는 것에 대한 은유적 표현이다.

[2] [역자주] “Scrum Master는 팀과 제품주(Product owner) 사이의 촉진자(facilitator)이다. Scrum Master는, 팀을 관리하는 것이 아니라, 다음과 같이 팀과 제품주를 지원한다;

l  제품주가 직접적 개발을 주도할 수 있도록, 개발팀과 제품주 사이의 장벽을 제거한다.

l  제품주에게 어떻게 투자 수익(ROI: return on investment)을 극대화시킬지 알리고, Scrum을 통해서 제품주의 목표를 만족시키도록 한다.

l  창조력과 위임을 촉진시켜서, 개발팀의 삶[의 질]을 향상시킨다.

l  가능한 모든 수단을 동원하여, 개발팀의 생산성을 향상시킨다.

l  각 주기마다 추가된 기능들이 언제든지 배포될 수 있도록, 기술과 도구를 향상시킨다.

l  진행 상황에 대한 정보를 최신으로 유지하고, 모든 관련자가 접근가능하게 한다.”

Agile Project Management with Scrum(Ken Schwaber, Microsoft Press, 2004)에서 인용.

[3] [역자주] 사전 시각화(pre-visualization)란, 개발하려는 게임(의 컨셉)을 문서가 아닌 시각적인 매체들(예: 그림, 동영상, 도표 혹은 모형 등)을 통해서 표현하는 것을 말한다. 대표적인 예로는 ICO의 Pilot movie를 들 수 있다. 자세한 것은 http://kwanny.ntreev.net/tt/index.php?pl=133를 참조.

[4] [역자주] 한 사후분석(Postmortem)에서는 다음과 같이 묘사한다; “막바지가 되면 가족들과 친구들은 우리를 잊어버리고, 우리는 피자 배달부와 친해진다.”

 

[5] [역자주] 이에 대한 좋은 예로, Electronic Arts(이하 EA) 소속 개발자의 배우자가 익명으로 쓴 “EA: The Human Story”가 있다. 2004년말에 쓰여진 이 글은 최고 주당 80시간(오전 9시~오후 10시. 주 7일 근무. 열심히 일한 경우, 토요일 저녁에는 오후 6:30에 퇴근 가능.)의 일을 시키면서도 야근 수당을 지급하지 않는 EA의 관행에 대해서 강력히 비판했다. 이로 인해, EA 내외에서 격렬한 논쟁이 벌어졌고, 소송이 줄을 이었다. 2006년 4월, 결국 EA는 200명에 달하는 전현직 프로그래머들에게 1,449만 달러를 지불하기로 합의했다. 보다 자세한 사항은 Wikipedia의 EA Spouse 및 EA의 Employment policy를 참고할 것.

[6] [역자주] 남기룡 님의 “우리팀 3개월 동안의 일일소멸차트”를 참조할 것.

[7] [역자주] 원래는 Sammy Studios, Inc였으나, 2005년 03월 07일 Sammy로부터 독립하고, High Moon Studios가 되었다. 2006년 01월 05일, Vivendi Universal Games에 합병되어, 현재는 Sierra Entertainment의 일부가 되었다.


<< 이전: Agile로의 이행 <<
..

..