게임 개발자와 게임 개발자가 아닌 모두가 스크럼, 익스트림 프로그래밍(XP, eXtreme Programming), 칸반(kanban)과 생산성, 직장(작업 공간), 제품 품질을 크게 향상시킬 수 있는 기타 애자일 실천방안을 적용하는 데 도움을 주는 프리랜서 애자일 코치이자 공인 스크럼 트레이너다.
25년 동안 첨단 전투기 및 수중 로봇을 위한 전자기기 프로그래밍과 <미드타운 매드니스(Midtown Madness)>, <미드나잇 클럽(Midnight Club)> 등의 인기 비디오 게임 프로그래밍을 경험했다. 여러 스튜디오를 거치며 프로그래머, 프로젝트 디렉터, CTO, 제품 개발 디렉터로 활동했고, 프레젠테이션과 자신의 인기 블로그를 통해 2005년 비디오 게임 산업에 스크럼을 도입했다. CTO로서 하이 문 스튜디오를 2005년, 2006년 IT 매거진이 선정한 기술 혁신 '톱 50' 리스트에 올렸고, 2005년, 2006년, 2007년에는 샌디에고에서 최고의 인사관리 기업 대상을 차지하는데 크게 기여했다. www.ClintonKeith.com에서 더 자세한 내용을 볼 수 있다.
이 책은 애자일 방법론을 사용하고 있거나 그 의미에 대해 호기심을 갖고 있는 게임 개발자를 위해 저술되었다. 또한 애자일 제품 개발의 다양한 영역으로부터 얻은 많은 정보를 제공하며, 게임 산업 고유의 생태계에 적용하는 것에 대해 언 급한다. 이 책은 지난 6년간 애자일을 사용해 게임을 출시했던 수많은 스튜디오들의 경험을 바탕으로 한다.
게임 업계에 몸담고 있지 않은 사람이라도 게임 산업이나 애자일에 호기심을 갖고 있다면 이 책을 즐길 수 있을 것이다. 이 책은 모든 분야와 의사소통해야 하기 때문에 그중 어떤 한 분야의 세부적인 부분에 얽매이지 않는다. 예를 들어, 다분야통합 팀에서 일을 잘하기 위해 아티스트는 같은 팀의 프로그래머가 직면한 어려움과 해결책을 이해해야 한다.
제목에서 알 수 있듯이 이 책은 애자일의 다른 영역보다 스크럼에 더욱 초점을 맞춘다. 스크럼은 애자일 게임 개발 프로세스를 구축하기 위한, 분야에 구애받지 않는 프레임워크다. 스크럼에는 미리 정의된 아트, 설계, 프로그래밍 프로세스가 없다. 스크럼은 게임을 만들고 가장 적합한 실천방안을 적용하는 방법에 대한 모든 면을 검사해볼 수 있게 해주는 토대다.
애자일과 게임 개발은 어떻게 만났을까? 내 경우 2002년 새미 스튜디오에서 시작했다. 많은 스튜디오와 마찬가지로 우리는 '재앙'을 피하기 위해 애자일을 선택했다. 새미 스튜디오는 2002년 일본 파친코 제조회사에 의해 설립되었다. 그들의 목표는 서양 게임 업계에서 최대한 빨리 입지를 구축하는 것이었다. 이를 위해 그들은 새미 스튜디오가 이 목표를 달성하는 데 필요한 것은 뭐든지 재정적으로 지원하고 권한을 부여해주었다. 경험이 많은 프로젝트 관리자였던 우리는 <다크워치(Darkwatch)>라는 주력 게임 프로젝트에 필요한 모든 세부사항 관리를 돕기 위해 마이크로소프트 프로젝트 서버의 라이선스를 포함한 프로젝트 관리 체계를 수립했다.
<다크워치>의 계획은 야심 찼다. 이 게임은 걸출한 1인칭 콘솔 슈팅 게임으로, <헤일로>의 경쟁 게임이었다. 당시 우리에게는 자원이 있었고 계획 관리 소프트웨어를 사용하는 한 우리가 관리할 수 없는 문제가 발생해 일을 그르칠 가능성은 거의 없다고 생각했다. 하지만 그리 오래지 않아 많은 것에 문제가 생기기 시작했다. 1년 만에 예정보다 6개월 뒤처졌고 상황은 매일매일 악화되어 갔다. 왜 이렇게 된 걸까?
■ 각 분야가 별도의 계획으로 작업했다
각 분야는 많은 시간 동안 독립적으로 작업하는 목표를 갖고 있었다. 예를 들어, 애니메이션 기술은 어떤 것이 입증되기도 전에 그들만의 많은 피처를 개발하는 계획에 따라 프로젝트를 진행했다. 애니메이션 제작자는 간단한 전환 작업을 만들면서 애니메이션 프로그래머가 잘라낼지도 모르는 팔, 다리에 관한 작업도 수행했다. 이런 문제를 수정하기 위해서는 정기적으로 주요 일정을 점검해야 했다.
■ 빌드가 항상 깨져 있었다
동작하는 게임의 최신 버전을 얻는 데에는 별도의 노력이 필요했다. 전자 게임 전시회E3 데모에 필요한 빌드를 제작하기 위해 디버깅 및 해킹에 한 달 이상 노력을 기울였다. 그럼에도 불구하고 개발자는 데모 컴퓨터를 자주 재부팅해야만 게임을 실행해볼 수 있었다.
■ 추정과 일정이 언제나 너무 낙관적이었다
작은 작업부터 주요 마일스톤에 이르는 모든 일정이 너무 늦는 것처럼 느껴졌다. 예상치 못한 작업은 개인적인 시간에 수행하거나 이후로 미뤄두었다. 이는 결국 수많은 야근과 주말 초과근무로 이어졌다.
■ 관리자는 지속적으로 '불을 꺼야만 했고', 큰 그림을 해결할 시간을 가진 적이 없었다
관리자는 매주 해결해야 할 문제 중 하나를 선택했고 이를 해결하기 위해 하루 종일 진행되는 대규모 회의를 했다. 문제들의 목록은 해결할 수 있는 능력을 넘어서 빠르게 증가했다. 우리에게는 미래를 내다보고 프로젝트를 이끌 시간이 없었다.
이와 같은 문제는 계속 적어내려갈 수 있을 정도로 많았고 점점 늘어났다. 대부분의 문제는 한 달 이상의 포괄적인 계획에 대한 추정을 정당화할 수 있는, 많은 프로젝트 세부사항을 예측하지 못했기 때문에 발생했다. 결론적으로 우리의 계획 방법론이 잘못된 것이었다.
결국 우리의 일본 모기업은 핵심 구성원을 바꿔 달라고 우리에게 요청했다. 메시지는 명확했다. 우리가 원하는 모든 가용 리소스는 관리자에게 주어져 있었기 때문에 모든 문제는 우리의 잘못이었고, 이를 수정하라는 짧은 통지를 받았다. 일뿐만 아니라 스튜디오의 생존이 위기에 처해 있었다.
내가 상황을 바꾸기 위한 프로젝트 관리 방법을 찾기 시작했던 것은 이 절망적인 시기였다. 우리는 그때까지 스크럼, 익스트림 프로그래밍XP과 같은 애자일 실천방안을 알지 못했다. 새미 스튜디오의 기존 CTO는 우리에게 XP를 시도하게 했고, 프로젝트 리더는 몇 가지 스크럼 실천방안을 실험했다.
스크럼(슈와버와 비들, 2002)에 대한 책을 읽고 난 후, 나는 스크럼을 우리 환경에 사용할 수 있을 것이라고 확신했다. 스크럼을 처음 알게 되었을 때, 게임 개발팀의 재능과 열정을 활용할 수 있는 프레임워크를 찾았다고 직감했다. 물론 쉽지만은 않았다. 스크럼 규칙들은 IT 프로젝트를 수행하는 프로그래머 팀 쪽으로 편향되었고 몇몇 규칙은 제대로 적용되지 않았다.
이는 애자일이 가진 의미와 게임 개발자들이 이를 적용하는 것에 대한 일련의 끝없는 발견의 시작이었다. 나는 2005년에 애자일 게임 개발에 대해 이야기하기 시작했다. 이때는 스튜디오가 Xbox 360과 플레이스테이션3 게임 타이틀을 개발하고 있을 무렵이었다. 100명 이상의 팀이 일반적이었고 프로젝트 실패에 대한 비용은 수백억 원에 이르렀다.
안타깝게도 많은 사람들이 애자일의 메시지를 너무 과장되게 받아들였고, 몇몇은 이를 모든 것을 해결할 수 있는 만병통치약으로 여겼다. 2008년 수십 개의 스튜디오에서 수백 명의 개발자와 이야기를 나눠본 후, 나는 게임 개발자의 애자일 도입을 돕는 풀타임 코치가 되기로 결심했다. 나는 현재 여러 스튜디오를 코치하며 공개 강의를 통해 개발자에게 스크럼마스터가 되는 방법을 가르치고 있다. 이 개발자들과 함께 작업하며 배운 경험으로 이 책을 쓸 수 있었다.