02. 게임 기획 매니지먼트 스크럼(Scrum)의 시작

■. 목표 설정

스크럼은 오직 정해진 기간 내 목표를 달성하는 것에 그 목적이 있다. 그리고 게임 개발에 있어 목표 달성이란 대부분의 문제를 해결하고 정상적으로 동작 가능한 시스템 또는 콘텐츠(Viable Product)를 완성하는 것이다

 

스크럼에서의 최종 목표가 프로젝트의 완성이며, 이 과정에서 중간 목표지점을 설정하는 것을 스프린트(Sprint)라 부른다. 스프린트는 달성 목표를 보다 단계적으로 분할하고 최종 목적지에 도달하는 동안 발생할 수 있는 다양한 문제를 수정하고 대응할 수 있는 중간 기착지 역할을 한다. 하지만 당신이 스프린트를 설정할 때 꿈(목표)은 크게 와 같은 말을 믿는다면 시작하기도 전에 모든 것을 망쳐버릴 완벽한 준비를 마친 것이다. 스프린트 설정에서 중요한 부분은 하고 싶은 것을 하는 것이 아니라 가능한 할 수 있는 것들을 목표로 설정해야 한다는 점이다. 즉 불가능한 것들에 매달리지 말고 가능한 것부터 하나씩 해결해 나가는 법과 실현 가능한 목표를 설정하는 방법을 먼저 고민해야 한다.

<스프린트는 최종 목표를 위해 중간 기착지를 만드는 것과 같다.>

 

■. 스프린트의 필요성

스크럼을 이용하던 다른 업무적 프로세스를 활용하던 최종 결과물에 대한 목표는 모두 동일하다. 그렇다면 꼭 스크럼이어야 하는가? 결론부터 말하자면 꼭 스크럼이어야 할 필요는 없다. 하지만 스크럼은 일반적인 스케줄 관리 프로세스보다 뛰어난 부분이 많으며 당신의 목표설정에 가장 적극적인 도움을 줄 수 있는 수단임은 분명하다.

 

스크럼의 가장 큰 장점은 스프린트(Sprint)와 이를 달성하기 위한 업무인 개발 항목(Backlog Task)으로부터 현재 개발 상황을 시각적으로 확인하고 발생할 수 있는 다양한 이슈에 매우 빠르게 대응할 수 있다는 점이다. 이러한 장점은 기존 일반적은 스케줄 관리 프로세스와는 다른 새로운 경험을 할 수 있다. 일반적인 스케줄 프로세스의 경우 프로젝트 오더로(Project Order : 할당된 업무)의 시작과 완료 일정을 기준으로 관리한다. 이 과정에서 발생하는 추가 이슈에 대응하기 위해 일정 변경이 진행되는데 이미 시작과 끝을 기준으로 잘 짜인 스케줄의 일부 변동 사항이 발생하여 이어진 다른 스케줄이 변경되어야 하는 것은 불가피하다. 그렇다고 모든 프로젝트 오더에 대한 여유 일정을 할당한다면 지나치게 일정이 늘어지거나 불특정 한 일정 변경이 불가피하다. 이렇듯 단순 업무 처리에 소요되는 시간을 기준으로 작성되는 스케줄은 시각적으로 보기는 좋을 수 있으나 현실적으로 그 기능을 다하기에 어렵다.

<대표적인 일정 관리 프로세스인 지라(Jira))와 레드마인(Redmine)은 전형적인 스케줄 관리 형태를 보여준다.>

 

물론 이러한 스케줄 프로세스가 나쁘다는 것은 아니다. 이미 상용화되었고 프로젝트의 성공적인 완수를 위해 충분히 검증된 매우 훌륭한 툴임은 분명하다. 하지만 이러한 절차 기반의 스케줄 관리 프로세스는 별도의 숙련된 관리자와 회사 내부의 기존 프로세스가 일치했을 경우에 그 역할을 충분히 다할 수 있다. 또한 개별로 할당된 개발 항목(Task)으로만 스케줄이 관리될 경우 담당자는 자신의 역할에만 몰두하여 프로젝트 오더 달성을 위해 필요한 다른 이슈에 대응하지 못하거나 이를 파악하지 못하는 경우가 많다. 이것은 개발 항목 중심으로 스케줄이 설정되어 있기 때문에 담당자는 다음 개발 항목을 준비하게 되고 이전 프로젝트 오더가 완료되기까지 필요한 전반적인 개발 과정에 기획이 행사할 수 있는 영향력이 매우 약해질 수밖에 없다. 이러한 스케줄 관리는 최종적으로 밀려드는 이슈와 연관 작업자의 업무 지연으로 통한 전체 개발 스케줄에 악영향을 준다. 그렇다고 이슈 관리 및 개발에 관련되는 사항들을 개발 항목 스케줄에 반영하는 것 또한 정확한 일정 산출이 어렵기 때문에 현실적으로 어렵다. 이렇듯 병렬적으로 대부분의 업무가 진행되어야 하는 게임 개발에 있어서 절차적인 진행 형태를 가진 스케줄 프로세스는 지나치게 복잡 해지거나 심하게 간소해지기 마련이다.

<스크럼의 스프린트와 태스크를 통해 목표 달성을 위한 업무 진행 현황을 시각적으로 파악할 수 있다.>

 

그렇다면 스크럼을 통한 스프린트 관리는 어떠한 이점이 있을까? 스프린트는 프로젝트 오더(Project Order)를 달성하기 위해 여러 개로 목표로 나눠진다. 이후 각 스프린트는(목표)를 달성하기 위한 개발 항목(Task)으로 세분화되어 분리된다. 이러한 과정은 생각보다 많은 시간과 노력이 들어가고 고통스럽지만 성공적인 목표 달성을 위해서는 꼭 필요한 과정이다. 이렇게 분리된 각 항목들은 개발 항목별 담당자가 지정되어 업무 진행하도록 한다. 이후 개발 항목을 중심으로 진행 사항을 공유하여 각 업무의 진척도를 파악할 수 있으며, 다른 개발 항목과 연계되어야 하는 업무 이슈에 대한 협의 사항들을 수시로 체크하여 이슈를 정리할 수 있다. 세분화되어 분리된 개발 항목은 업무 진행 상태에 따라 진행율을 기입하여 개발 항목과 스프린트의 진행 달성율을 시각적으로 확인할 수 있다. 스프린트는 최종 목적지까지 중간 기착지 역할을 하기 때문에 각 스프린트가 종료(완료)되는 시점에 진행 사항에 대한 방향을 다시 체크하고 수정할 수 있는 기회를 얻을 수 있다. 물론 이러한 과정은 매우 길고 지루하며 스크럼을 주도하는 담당자의 헌신적인 노력과 조율 역량이 필요하다. 하지만 이는 극히 초반에 발생하는 업무 부하일 뿐 반복되는 스크럼을 통해 프로젝트에 참가하는 스크러머(Scrummer : 스크럼참가자)의 업무가 서로 유연하게 맞물려 진행되기 시작하면 전체 개발 속도가 무섭게 가속화된다.

<스크럼은 고무줄과 같이 천천히 당겨지지만 충분히 당겨진 다음에는 엄청난 속도로 진행된다.>

 

■. 스프린트 설정

스크럼과 스프린트는 당신은 프로젝트 오더(Project Order : 할당된 업무)로부터 시작된다. 여기서 중요한 것은 프로젝트 오더를 스프린트로 설정하는 것이 아니라 보다 구체적인 동작 가능한 제품(동작 가능한 제품이란 구동된다는 뜻이 아니다. 정상적인 기능을 포함한 제품이라는 뜻으로 예를 들어 몬스터 추가의 경우 기획, 외형, 애니메이션, 이펙트 등 몬스터 스펙에 포함된 모든 기능이 완성된 상태를 말한다.)을 위한 목표를 설정해야 하는 것이다. 그렇다면 스프린트는 어떻게 결정해야 할까? 개념적으로 이야기하자면 동작 가능한 제품 완성을 위해 필요한 절차적 단계 또는 필요한 업무를 목록으로 분리하고 개발의 우선순위에 따라 스프린트 진행 순서를 배열하면 된다.

예를 들어 당신에게 전달된 프로젝트 오더가 4주 안에인 파티의 신규 던전 콘텐츠 제작(여기서 가정하는 부분은 던전 콘텐츠에 대한 시스템은 이미 개발이 완료된 상황을 가정한다.)이라고 한다면 스프린트를 설정하기 위해 신규 던전 콘텐츠 제작에 필요한 항목을 정리하고 우선순위에 따라 이를 분류하는 작업이다. 그리고 이 작업은 몇 단계에 걸쳐 진행되어야 하기 때문에 처음부터 너무 세분화된 정밀한 계획은 아직은 필요하지 않다.

 

▶. 던전 개발에 필요한 항목

Index	Task Category	Description
1	플레이 할 수 있는 던전	입장 가능한 던전과 외형
	던전 시나리오	던전에서 사용되는 시나리오 및 퀘스트
2	몬스터	던전에 배치되는 몬스터
3	전투 밸런스	전투 밸런스와 패턴 디자인
4	던전 클리어 보상	던전 클리어 이후 지급되는 보상

<던전을 하나 만들어서 콘텐츠로 구성하기까지 대략적으로 필요한 항목은 생각보다 별로 없다.>

 

콘텐츠 개발에 필요한 항목은 일단 정리가 되었다. 이제 당신이 해야 할 업무는 프로젝트 오더에 대한 구체화된 스펙 범위를 설정하는 것이다. 콘텐츠를 개발하기 위해서는 시간과 인력이 소비된다. 그리고 당신이 어떠한 스펙을 산정하고 개발을 진행해야 하는지에 대한 초기 가이드가 없다면 분명 일정이 부족하거나 구성원들로 하여금 어떠한 것을 만들어야 하는지 그 목적을 잃어버리기 쉽다.

 

▶. 프로젝트 오더 스펙 구체화

Index	Task Category	Description
1	플레이 할 수 있는 던전	던전은 1종으로 구성되며, 플레이 타임은 약 15 ~ 20분 내외 -. 주요 전투가 벌어지는 6개의 방형태로 구성되어 있으며, 각 방은 복도 형태로 연결되어 있다. -. 던전의 규모와 개발 기간을 고려하여 지나치게 복잡하거나 오픈 된 공간이 아닌 폐쇄된 형태로 제작
	던전 시나리오	던전에 사용되는 주요 컨셉 시나리오 -. 던전 플레이를 유도하기 위한 메인과 서브 퀘스트 -. 반복 플레이를 유도하기 위한 반복 퀘스트
2	몬스터	일반 전투 구역에 배치되는 몬스터 -. 기존 몬스터를 활용한다. -. 새로운 전투 경험을 제공하기 위해 일부 몬스터에 엑티브 스킬 추가   신규 몬스터 -. 보스 몬스터 1종과 중간 보스 몬스터 2종 추가 -. 중간 보스의 경우 공략 패턴은 특정 사용자 스팩(스텟)을 기준으로 생성 -. 보스 몬스터의 경우 다양한 패턴을 학습하고 공략할 수 있도록 구성 -. 전투 메타성을 고려하여 직업 조합이 고려되어야 함
3	전투 밸런스	일반 몬스터 -. 배치된 일반 몬스터는 그룹화 되어 순차적으로 공략되어 갈 수 있다. -. 다수의 몬스터와 전투가 벌어질 경우 전멸할 수 있을 정도의 레벨디자인 필요. -. 순찰형 몬스터를 통해 설계된 시간 내 일반 몬스터 그룹 처치가 주요 공략 패턴   보스 몬스터 -. 단순 공략 패턴이 아닌 기믹 요소를 추가 -. 기믹에 대한 사용자 대응이 주요 공략 패턴 요소
4	던전 클리어 보상	던전 클리어에 따른 기본 보상 -. 퀘스트 보상을 제외한 던전 클리어 보상 설계 던전 클리어 전용 보상 -. 반복 플레이를 위해 해당 던전에서만 획득 가능한 고유 아이템 제공

<프로젝트 오더 스펙을 설정할 때는 보다 구체적인 기획 의도를 포함하는 것이 좋다.>

 

대략적인 구체화 작업이 완료되었다면 이제는 보다 구체적인 콘텐츠 완성을 위해 필요한 우선순위를 스프린트로 설정해야 한다. 단 스프린트를 설정하기 앞서 중요한 점은 당신은 최종 완성을 위한 설계도를 가지고 있어야 한다는 점과 모든 공정이 완료되어 하나로 조립되었을 때 최종 결과물이 될 수 있어야 한다는 점이다. 즉 쉽게 이야기해서 당신에게는 충분한 계획이 수립되어 있어야 한다.

<누구든 쳐 맞기 전에는 그럴싸한 계획이 있다. 하지만 잊지 말자 우리는 맞지 않으려고 계획을 짜는 것이다.>

 

구체화된 프로젝트 오더가 있다면 이를 일정에 맞춰 스프린트로 구성한다. 이는 프로젝트 오더의 구체화 과정과 크게 다르지 않다. 단 스프린트 설정에 있어서 중요한 점은 최종 완성된 콘텐츠(또는 시스템)를 위해 단계적으로 필요한 사항들로 설정해야 한다는 점을 잊지 말아야 한다.

 

앞서 구체화된 프로젝트 오더를 통해 스프린트를 설정한다면 가장 먼저 진행되어야 하는 업무는 어떠한 것이 있을까? 당신이 아직 그것을 판단하기 어렵다면 던전을 최종적으로 완성하기 위해 가장 필수적인 업무가 무엇인지 생각해 보자. 현재 프로젝트 상황에 따라 다르겠지만 개인 적인 경험으로 조언하자면 가장 먼저 필요한 것은 몬스터와 던전(지형)이다. 이 두 가지 항목이 완료되지 않는다면 연결된 다른 업무 또한 진행이 순조롭지 않다. 단 몬스터의 경우 임시로 사용 가능한 대상이지만 던전(지형)의 경우 그렇지 못하기 때문에 가장 높은 우선순위는 던전 그 자체의 리소스이다.

<던전 그 자체가 먼저 완성되어야 연관된 모든 작업들을 이어서 진행할 수 있다.>

 

하지만 아쉽게도 던전을 완성한다는 것은 던전 콘텐츠에서 가장 오랜 시간(일정)을 필요로 하는 업무이다. 이것이 완료되기를 기다린 뒤에 다른 업무를 진행한다는 것은 목표 일정 내 최종 콘텐츠(또는 시스템)를 완성하기란 불가능하며, 지나치게 비 효율적인 프로세스이다. 그렇기 때문에 우리는 스프린트를 통해 우선순위에 따라 작업을 진행하고 각 단계별 진행 사항을 효율적으로 관리하고자 한다.

 

하나의 스프린트(Sprint)는 주어진 목표 일정(Deadline) 내 동작 가능한 시스템(Viable Product)으로 구성되며 내부에는 이를 위해 필요한 다수의 스프린트 항목(Sprint Backlog)으로 관리된다.

<하나의 스프린트는 목표 일정에 맞춰 다수의 스프린트 백로그로 구성되어 있다.>

 

여기서 목표 일정은 최종 결과물에 대한 일정이 아닌 스프린트 하나에 대한 일정을 이야기한다. 즉 스프린트는 최종 목표 일정 내 중간 기착지까지 도달하기 위해 일정을 새로 구성한 것이다. 그리고 중간 기착지 도달을 위해 필요한 항목이 스프린트 항목(Sprint Backlog)이다.

 

그렇다면 앞서 가장 우선 작업되어야 하는 던전은 최우선 스프린트 항목으로 설정해야 한다. 하지만 던전을 완성하기에는 많은 시간이 소요되기 때문에 전체 일정에 문제가 있는 것은 아닌지 의심이 들기 시작한다. 그렇지만 안된다고 생각하기보다는 할 수 있다는 생각을 하는 것이 더 행복하기 때문에 우리는 방법을 찾을 것이다. 가장 먼저 당신이 생각해야 할 문제는 “과연 완성된 던전이 필요한 것인가?”에 대한 질문에 답을 생각해 보는 것이다. 던전이 필요한 이유는 몬스터를 배치하고 실제 레벨 테스트를 진행하기 위함이지 멋지게 완성된 던전 리소스를 감상하기 위한 것은 아니다. 그리고 다행스럽게도 던전을 제작하기에 앞서 이 문제를 해결하기 위한 가장 기본적인 레벨 디자인 기획 업무인 테스트 레벨(Mockup) 작업이 필수 적이다.(레벨 디자인에 있어 테스트 레벨 제작은 매우 중요하다. 이는 사용자 동선을 미리 파악하고 주요 공간을 확보하여 완성된 레벨의 수정 이슈를 최소화하고 기획 의도에 따라 활용할 수 있는 공간을 확보하기 위함이기 때문이다. 하지만 레벨 디자인에 대한 놀라운 내용은 여백이 부족하여 여기에 적지 않는다.) 그리고 던전의 테스트 레벨과 콘셉트 작업은 연관 작업자의 업무 진행을 위해서는 필수적으로 진행되어야 하는 선행 업무이기 때문에 우선순위가 높다. 이제 최우선 진행되어야 하는 스프린트와 주요 스프린트 항목 그리고 우선 완성해야 하는 동작 가능한 시스템에 대한 내용을 정리하면 아래와 같다.

 

▶. 스프린트 구성

Sprint	Sprint Backlog	Description	Next Work
1주차	던전 구성 기초 작업	던전 컨셉 기획 -. 던전 외형에 대한 컨셉 기획 -. 던전 내부 구조 및 레벨 디자인 기획 던전 시나리오 -. 메인 퀘스트 및 서브 퀘스트를 위한 시나리오 던전 테스트 레벨 -. 던전 테스트 레벨 제작	테스트 레벨을 통한 던전 골조 구성   테스트 레벨에 임시 몬스터 배치 및 데이터 작업   던전 레벨 테스트   던전 퀘스트 데이터 작업
Viable Product		1. 던전 테스트 레벨 제작 및 입장 테스트 2. 임시 몬스터 배치 3. 메인 시나리오 및 퀘스트 시나리오 테스트

<가장 우선시 작업되어야 하는 던전 구성에 대한 스프린트 구성 예시로 필요한 내용을 정리한다.>

 

스프린트를 구성할 때는 꼭 실행 가능한 시스템과 일정 그리고 스프린트 항목이 포함되고 이 모든 내용은 구체적으로 작성되어 있어야 한다. 최초 스프린트를 설정하기는 했지만 과연 이것 만으로는 조금 부족해 보인다. 스크러머 구성에 따라 다르겠지만 아직은 모든 구성원이 스프린트에서 업무를 할당받기에는 다소 부족하다. 그래서 함께 진행될 수 있는 다른 업무들을 스프린트 내 새로운 항목(Sprint Backlog)에 추가하여 전체 구성원이 스프린트에 참여할 수 있도록 조정이 필요하다. 이때 주요 업무는 던전 구성을 위한 기초 작업에 많은 인력(적어도 기획과 원화, 3D 모델러등의 아트 인력)이 투입되기 때문에 담당자가 독립적으로 진행할 수 있는(선행 업무가 필요 없는 또는 가벼운) 업무를 새로운 항목(Sprint Backlog)에 추가하는 것이 좋다. 그렇지 않다면 특정 스크러머에게 너무 많은 업무가 할당되는 병목 현상으로 스프린트 일정에 지장을 줄 수 있다.
※. 당신이 이 스크럼에 관심이 있다면 구체화된 프로젝트 오더 내에서 필요한 항목을 생각하고 자신이 생각하는 스프린트 항목을 구성해 보자.

 

스프린트와 항목을 구성하는 것 만으로는 기존 스케줄 관리방식과의 차이점을 느끼기 어려울 수 있다. 스프린트가 보다 세부적인 스프린트 항목(Sprint Backlog)으로 구성되어 있는 것과 같이 이를 달성하기 위한 보다 상세한 개발 항목(Backlog Task)로 구성되어 있다. 그리고 스크럼을 통한 일정 관리의 강력한 효용성은 해야 할 일을 분류하고 진행 사항을 체크하는 단계로부터 확인할 수 있다. 그리고 우리는 이제 다음 문서를 통해 보다 구체적인 스크럼의 진행과 관리에 대하여 알아볼 것이다.