형식적 스크럼
게임 디자인 이야기
* 참고 문헌 <Agile Game Development with Scrum>, <스크럼과 XP> 에서 상당 부분 발췌하여 정리한 글입니다.
형식적 스크럼(Scrum)
개발실 전체적로 보면 여러 사람들의 노력으로 스크럼이나 애자일에 대한 인식이 전반적으로 공유되어 있었지만 기획팀 내부에서는 형식이나 일부 프로세스를 차용하고 있는 모습이었다. 예를 들어 아침마다 일일 스크럼을 진행하는데 이 일일 스크럼은 매일 지정된 시간에 팀원 전체가 참여하여 아래와 같이 딱 세 가지를 보고해야 한다.
1) 지난 일일 스크럼 이후 무엇을 완료하였는가?
2) 다음 회의 때까지 무엇을 마무리할 계획인가?
3) 일하는 데 어떠한 방해나 장애요인들이 있는가?
이 일일 스크럼은 관리자에게 상황을 보고하는 회의가 아니다. 이 회의를 통해 팀원들은 팀이 어떤 상황이며 어떻게 진행되고 있는지를 서로 알게 하고 서로 도움이 되는 시간이 되어야 한다. 하지만 의도와는 다르게 지난 업무에 대한 보고와 앞으로의 업무 보고만 하는 자리가 되어 버린다. 일반적으로 일일 스크럼 회의에 관리자나 기타 권위적인 위치에 있는 사람들이 참석하지 않도록 할 것을 권고하지만 대부분 관리자인 팀장이 주축이 되어 진행하고 오히려 어떤 일을 잘 진행되고 있는지 아니면 어떤 일을 하지 않고 있어서 문제가 있다는 식의 훈계의 시간으로 변질되기 쉬웠다. 관리자가 포함된 회의에서 팀원들은 ‘감시받는다’라고 느끼게 되고 매일 일이 척척 잘 진행되고 있다는 보고를 해야 하는 암묵적인 압박을 받고 실제로 문제가 있어도 알리는 것을 꺼리게 된다.
스크럼 도입 당시의 기획팀이 바로 이러한 모습이었다. 이런 상황 때문에 스크럼은 기획팀 내에서 환영받지 못하는 개발 기법이었다. 일정을 더 타이트하게 관리하여 만들어진 시간을 더 많은 야근으로 메우는 기법이라는 생각도 암묵적으로 퍼지고 있었다.
애자일과 스크럼에 대한 오해
애자일은 너무 복잡해
대부분의 애자일을 경험해보지 못했던 사람들이 가장 많이 하는 잘못된 오해 중에 대표적인 것들이다. 애자일과 스크럼을 설명을 하기 위한 익숙하지 않은 스프린트, 유저 스토리, 백로그 등의 용어들 때문일 수 있다. 무겁게 마음을 먹고 공부해야 하는 어렵고 복잡한 것으로 개발자들에게 받아들여지는 것이다. 하지만 애자일은 사람들의 이런 오해와 정반대이다. 스크럼을 만든 켄 슈와버는 스크럼은 ‘가벼운 프로세스(light weight process)’라고 했을 정도로 단순하여 스크럼 관련 서적의 정의 부분만 보아도 쉽게 배울 수 있다.
애자일은 우리나라에서 너무 이상적이야. 영어부터 다시 배워야 해.
우리가 지금하고 있는 것이 더 현실적이야.
애자일 개발 방법론을 현재의 개발팀에 적용하기에는 너무 이상적이라고 생각하는 경향도 많이 있다. 오랜 기간 동일한 일을 해 왔다면, 변화를 두려워하는 것이 당연하다. 그리고 현재 문제가 없는데 왜 어려운 방법론을 적용해야 하는지 필요성에 대한 의문도 가지게 될 것이다. 하지만 전통적인 소프트웨어 개발 기법인 폭포수 개발 방법론은 치명적인 문제점을 가지고 있다. 이미 개발이 시작된 이후에는 기존에 논의되지 않았던 새로운 기능을 추가하려고 하면, 개발 기간이 지연되거나 시간을 문제로 아무리 좋은 기능을 기획한다고 해도 넣을 수 없는 상황이 반복되게 된다. 그리고 이런 경험을 우리는 계속해 왔다. 그리고 윗선의 요구에 따라 우선순위가 변경되거나 프로젝트가 지연되거나 심지어 프로젝트 자체가 사라지는 경우도 빈번히 발생한다. 반대로 이야기하면 전통적인 폭포수 방법으로 제품이 완성되어 한 번에 성공할 수 있다고 생각하는 것 자체가 더 이상적이다. 애자일과 스크럼의 기법 들은 더 현실적으로 개발 목표에 접근할 수 있는 방법을 제시하는 것이다.
애자일은 야근을 하지 않는다.
“이제 우리 팀도 애자일을 시작했는데 제가 왜 야근을 해야 하나요?”라고 이야기하는 사람도 가끔 있다. 하지만 애자일은 야근을 때려잡는 절대 무기가 아니다. 경영진은 “다들 죽어라 일하는데 왜 항상 일정을 못 지키고 만드는 것 마다 버그냐”고 말한다. 하지만 야근 문제는 개개인들이 열심히 일을 하지 않아서가 아니라 그 일정이 지킬 수 없게 계획되어졌기 때문이다. 일정 안에 계획의 변경이나 테스트, 디버깅 등의 일정이 포함되지 않은 계획은 지킬 수 없으며 팀장 한 명이 자신의 경험만을 바탕으로 계획을 세워 실무자에게 통보한다면 그 일정의 정확히 지켜지기 어려울 것이다. 애자일이 팀에 잘 적용되어 팀의 전체 개발 속도를 이해한 상태에서 스스로 자발적으로 세워진 계획대로 프로젝트가 진행된다면 야근을 하지 않을 수 있게 될 것이다.
왜 게임 개발에 애자일을 사용해야 하나?
우리는 현재 1년, 2년에 게임 하나씩 뚝딱 만들던 시절을 지나 대규모 MMORPG의 경우 보통 5년 정도의 개발 기간과 500억 가까운 개발비를 설정하는 시대를 살고 있다. 이제 게임 개발은 젊은 시절의 모험이나 뽑기의 규모가 아니다. 게임이 재미있는지 없는지 알기 위해 프로젝트가 끝날 때까지 기다릴 수 없다. 엄청난 돈을 써버리고 난 뒤에는 게임에 중요한 변화를 주기에 너무 늦어 버린다. 어떤 사람들은 우리 팀은 최고 경험의 가진 사람들이 모여 있으니 남들이 5년 동안 만들어야 하는 것을 2년이면 충분히 만들 수 있을 거야 하는 자신감을 가지기도 한다. 하지만 기존의 게임을 똑같이 베껴 만들지 않는다면 경력만으로 이 시간을 커버하기는 쉽지 않다.
게임을 만들어 내는 원동력인 창의력은 프로젝트 도중에 발생한다. 예를 들어 몬스터 AI를 만들 때 어떻게 효과적으로 플레이어를 공격해야 하는지 어느 정도로 괴롭혀야 하는지 재미있는지에 대한 많은 창조적 지식들을 축적하게 된다. 그리고 매일 같이 개발을 하면서 만들어 내는 이 같은 지식들이 바로 게임 회사의 최고의 자산이 될 것이다. 왜냐하면 게임 개발에서는 어떻게 만들고 무엇을 만드는지가 가장 중요하고 이런 지식들이 바로 불확실한 시간을 줄여 줄 수 있기 때문이다. 애자일 개발은 이런 창조적 지식을 바탕으로 계속적으로 목표를 수정하고 스케줄을 조정하게 도와준다.
위의 그림은 정통적인 개발 방식의 모습을 잘 보여준다. 초기에 기획서를 바탕으로 설정한 목표를 위해 마일스톤을 설정하고 오랜 시간 동안 관련 아트 리소스들을 만들고 프로그램 개발까지 완료하였다. 그런데 마지막에 합쳐보니 기획서를 쓸 때 생각했던 만큼 재미가 없다. 다시 기획서의 목표를 변경하고 또 다른 것을 만들기 시작한다.
애자일 프로젝트도 목표를 향해 단계를 진행해 가는 것은 전통적인 방법과 동일하다. 그러나 애자일의 중요한 키워드인 ‘시험과 적용(inspect and adapt)’을 통해 각각의 반복 주기마다 결과를 빠르게 적용하므로 더 좋은 목표를 향할 수 있도록 계속해서 계획을 수정할 수 있게 해준다.
재미를 찾아가는 여정
게임에서의 고객은 당연히 우리 게임 혹은 계정을 구매하여 플레이하는 사람들이다. 그리고 플레이어들은 재미있는 게임일수록 더 많이 사줄 것이다. 하지만 이 재미는 기획서에도 프로그램 코드를 보아도 찾아 볼 수 없다. 재미는 직접적인 것이고 실제로 컨트롤러를 가지고 플레이해보아야 알 수 있다. 전통적인 폭포수 기법에서도 이 재미를 찾을 수 있는 순간이 2번에서 3번 정도 있다. 하지만 모든 조각들이 맞춰지고 조율되고 디버깅이 마친 뒤에서야 비로써 재미를 찾을 수 있게 된다. 불행한 경우 모두 마친 뒤에도 찾지 못할 수도 있다.
IT 업계에서는 빠르게 제대로 동작하는 소프트웨어를 릴리스 하여 실제 프로그램을 바탕으로 변형해 나간다. 하지만 게임에서 완전하게 모든 리소스가 포함된 릴리스 버전은 개발 마지막 시점에서나 볼 수 있다. 그래서 짧은 반복 주기 안에서 최소한의 리소스를 이용하여 게임의 재미를 확인하고 개선하는 작업이 계속 필요하다. 위 그림의 언차티드3 프로토타입 영상을 보면 최소한의 캐릭터와 지역 모델링 그리고 게임 요소를 가지고 게임 월드를 이동해 보고 다른 캐릭터와 인터랙션 하는 부분을 테스트해본다. 이렇게 계속적이고 반복적인 실제 테스트하고 적용해 보고 또 기획을 수정하면서 점점 재미있는 게임의 모습이 되는 것이다. 처음 세워진 계획을 무조건 마지막까지 철저히 따르기 보다는 변화에 대응하는 것이 더 중요하다.
