게임 개발자를 위한 프로젝트 관리: 당신의 게임이 계속 마감일을 놓치는 이유

게임 개발자에게 마지막 프로젝트를 망친 것이 무엇인지 물어보면 "코드가 너무 어려웠다"는 말을 거의 듣지 못할 것입니다. 거의 항상 스코프 크립, 번아웃, 잃어버린 동기, 또는 그냥 다음에 무엇을 해야 하는지 파악을 잃는 것의 어떤 버전입니다. 게임 개발의 기술적 측면은 모든 주목을 받지만, 게임이 실제로 출시되는지를 결정하는 것은 조직적 측면입니다. 이것은 여가 시간에 열정 프로젝트를 진행하는 솔로 개발자에게만 특유한 문제가 아닙니다. 실제 예산과 실제 팀이 있는 스튜디오도 관리 측면이 무너지기 때문에 늦게 출시하거나, 기능을 삭제하거나, 프로젝트를 완전히 취소합니다. 출시되는 게임과 영원히 40% 완성된 채로 있는 게임의 차이는 거의 항상 기술적이 아닌 구조적입니다. 게임 개발은 동시에 너무 많은 분야를 다루기 때문에 관리하기 유난히 어렵습니다. 단순히 소프트웨어를 작성하는 것이 아닙니다. 같은 프로젝트 안에서 아트, 디자인, 오디오, 내러티브, 프로그래밍, QA, 때로는 마케팅까지 조율하고 있습니다. 각각은 자체 워크플로우, 의존성, "완료"의 정의를 가집니다. 이 모든 것을 유지할 시스템이 없으면 무너집니다.

일반적인 소프트웨어 프로젝트는 비교적 예측 가능한 구조를 가집니다. 요구 사항을 수집하고, 기능을 만들고, 테스트하고, 배포합니다. 게임 개발은 그렇게 작동하지 않습니다. 자체 일정으로 에셋을 생산하는 아트 파이프라인이 있습니다. 플레이테스트를 해보기 전까지 재미있는지 알 수 없기 때문에 본질적으로 반복적인 게임 디자인이 있습니다. 완성된 비주얼에 의존하는 오디오가 있습니다. 그리고 이 모든 것을 묶는 코드가 있습니다. 게임 개발의 의존성 체인은 잔인합니다. 프로그래머는 디자이너가 전투 시스템을 확정하기 전까지 적 AI 행동을 구현할 수 없습니다. 애니메이터는 캐릭터 모델이 완성되기 전까지 공격 애니메이션을 만들 수 없습니다. 사운드 디자이너는 애니메이션 타이밍이 정해지기 전까지 충격 효과를 만들 수 없습니다. 하나의 병목이 전체 프로젝트에 걸쳐 연쇄됩니다. 이것이 일반적인 프로젝트 관리 조언이 게임 개발자에게 부족한 이유입니다. 복잡한 상호 의존성을 가진 5개 분야에 걸쳐 200개의 태스크가 있을 때 "그냥 할 일 목록 사용해"는 충분하지 않습니다. 시각적, 기술적, 조직적 모든 것을 동시에 처리할 수 있는 것이 필요합니다.

게임 프로젝트를 위해 할 수 있는 단 하나의 가장 중요한 것은 마일스톤으로 분해하는 것입니다. "게임 완성" 같은 모호한 마일스톤이 아닙니다. 명확한 납품물과 날짜가 있는 실제적이고 구체적인 마일스톤. 일반적인 인디 게임의 마일스톤은 이런 것들일 수 있습니다. 프로토타입(핵심 메커니즘 작동, 플레이스홀더 아트), 버티컬 슬라이스(최종 품질 아트와 오디오가 있는 하나의 완전한 레벨), 알파(모든 기능 구현, 콘텐츠 대략 완성), 베타(콘텐츠 완성, 버그 수정), 골드(출시). 각 마일스톤은 끝없는 백로그를 바라보는 것이 아닌 모멘텀을 얻을 수 있도록 미니 결승선처럼 느껴져야 합니다. 각 마일스톤 안에서 분야별로 태스크를 분해하세요. 아트 태스크, 프로그래밍 태스크, 디자인 태스크, 오디오 태스크. 팀과 함께 작업한다면 각각에 우선순위와 담당자를 지정하세요. 완료 퍼센트를 추적해서 프로그래밍이 뒤처지는 동안 아트가 일정보다 앞서가고 있는지 한눈에 볼 수 있게 하세요. 이런 종류의 가시성이 프로젝트를 망치는 "거의 다 됐다고 생각했는데" 서프라이즈를 예방합니다.

모든 게임 프로젝트는 게임이 무엇인지, 어떻게 작동하는지, 계획이 무엇인지 설명하는 중앙 문서가 필요합니다. 게임 디자인 문서, 프로젝트 성경, 뭐라고 불러도 좋습니다. 핵심은 3개월 전에 무슨 생각을 했는지 잊어버릴 미래의 나를 포함한 프로젝트의 모든 사람이 한 곳을 보고 무엇이 만들어지고 있는지 이해할 수 있다는 것입니다. 이 문서는 아무도 읽지 않는 50페이지 스펙이 되면 안 됩니다. 핵심 게임플레이 루프, 주요 메커니즘, 아트 방향, 기술 요구 사항, 범위를 다루는 구조화되고 섹션으로 나뉜 문서여야 합니다. 간결하게 유지하고 업데이트하세요. 6개월 전에는 정확했지만 그 이후로 건드리지 않은 디자인 문서는 적극적으로 오도하기 때문에 문서가 없는 것보다 나쁩니다. 태스크를 이 문서의 섹션과 연결하세요. 누군가 "왜 이 기능을 만드는 거죠?"라고 물으면 답은 관련 섹션의 링크가 되어야 합니다. 이것이 고수준 비전에서 개별 태스크까지 이어지는 추론의 사슬을 만들어 모두를 정렬된 상태로 유지합니다. IndieDevBoard의 디자인 문서는 칸반 보드와 마일스톤 바로 옆에 사는 섹션이 있는 구조화된 문서를 만들 수 있게 합니다. 문서를 업데이트하고, 태스크를 업데이트하면 다섯 개의 다른 앱을 전환하지 않아도 모든 것이 연결된 상태로 유지됩니다.

게임 개발은 본질적으로 시각적입니다. 사람들이 보고 상호 작용할 것을 만들고 있습니다. 프로젝트 관리도 이를 반영해야 합니다. 칸반 보드는 태스크 추적에 잘 맞습니다. 진행 중인 것, 막힌 것, 완료된 것을 한눈에 볼 수 있기 때문입니다. 하지만 게임 개발 특히를 위해 앞으로 몇 주와 몇 달에 걸쳐 마일스톤이 어떻게 줄을 서는지 볼 수 있는 타임라인 뷰도 필요합니다. 아트 파이프라인이 프로그래밍 스프린트와 병렬로 실행되는 것을 보여주는 간트 차트는 무언가가 충돌할지 즉시 알려줍니다. 무드보드는 게임 개발자들이 프로젝트 관리에서 과소 사용하는 또 다른 도구입니다. 아트 스타일, UI 디자인, 환경 컨셉, 캐릭터 미학에 대한 시각적 참고 자료를 한 곳에 수집하면 팀 전체가 같은 시각적 언어로 작업합니다. 이것이 캐릭터 아티스트와 환경 아티스트가 아무도 공유된 참고 자료를 확립하지 않았기 때문에 완전히 다른 아트 스타일로 끝나는 너무나 흔한 문제를 예방합니다.

게임 개발에 대한 불편한 진실이 있습니다. 초기 비전은 너무 큽니다. 항상 그렇습니다. 게임 출시에서 첫 번째 기술은 프로젝트의 영혼을 잘라내지 않으면서 기능을 잘라내는 것입니다. 이것을 하는 방법은 첫날부터 우선순위에 대해 가차 없는 것입니다. 모든 기능, 모든 메커니즘, 모든 에셋은 필수, 있으면 좋은 것, 또는 스트레치 목표로 태그되어야 합니다. 불가피하게 일정이 뒤처질 때(그리고 그렇게 될 것입니다) 아래부터 잘라냅니다. 스트레치 목표가 먼저 갑니다. 그다음 있으면 좋은 것들이. 필수는 최소 실행 가능 게임입니다. 태스크 관리로 이것을 추적하세요. 칸반 보드에서 우선순위 수준과 레이블을 사용해서 필터링하고 중요 경로만 볼 수 있게 하세요. 목표 출시 3주 전이고 뒤처져 있을 때 필수 태스크만 꺼내서 출시와 나 사이에 무엇이 있는지 정확히 볼 수 있어야 합니다. 그 명확성이 게임을 출시하게 합니다. 비용 추적도 대부분의 인디 개발자가 깨닫는 것보다 더 중요합니다. 에셋을 사거나, 계약자에게 비용을 지불하거나, 어떤 종류의 예산을 운영하고 있다면 프로젝트 수준에서 돈이 어디로 가는지 알아야 합니다. 작은 구매들이 빠르게 쌓이고, 지출 파악을 잃는 것도 프로젝트가 조용히 죽는 또 다른 방법입니다.

세상에서 가장 좋은 프로젝트 관리 시스템도 게임을 "언젠가는 완성될" 것으로 대한다면 도움이 되지 않습니다. 날짜를 설정하세요. 임의적이라도. 나중에 옮기더라도. 목표를 갖는 것이 모든 결정에 대해 생각하는 방식을 바꿉니다. 마감일이 있으면 "이 멋진 새 기능을 추가해야 할까?"가 "이것을 추가하고도 제때 출시할 수 있을까?"가 됩니다. 그 재프레이밍은 강력합니다. 모든 기능 요청을 소원 목록 항목이 아닌 트레이드오프 계산으로 바꿉니다. 실제로 출시하는 게임 개발자들이 반드시 더 재능 있거나 더 규율 있는 것이 아닙니다. 그들은 프로젝트를 구조, 가시성, 책임감이 있는 프로젝트로 취급한 사람들입니다. 추적할 수 있는 조각들로 작업을 분해했습니다. 결정 사항을 문서화했습니다. 필요할 때 범위를 잘랐습니다. 더 이상 재미없을 때도 계속 앞으로 나아갔습니다. 꿈을 가진 솔로 개발자든 Steam 출시 창을 노리는 소규모 팀이든 간에, 게임이 세상에 존재하는 것과 하드 드라이브에만 존재하는 것의 차이는 작업을 어떻게 관리하는지로 귀결됩니다. 코드와 아트를 진지하게 취급하는 만큼 그것도 진지하게 취급하면 가능성이 극적으로 높아집니다.