재미있는 게임을 만들기 위한 게임 개발 프로세스
리얼리티 리플렉션에서는 효율적인 게임 개발을 위해 ‘스크럼'을 사용하고 있어요.
이 글에서는 리얼리티 리플렉션에서 게임을 개발할 때 사용하는 스크럼 시스템을 스타트업 팁으로 소개해드리고자 해요. 스크럼 시스템은 반복적이고 점진적인 개발 프로세스를 위한 방법론인데요. 스크럼을 사용하면 효율적이면서도 높은 성과의 결과물을 팀 역량과 일정에 맞게 성취할 수 있어요.
개발 방법론 스크럼. 어떤 방법론인지 한 번 알아볼까요?
스크럼은 프로젝트 관리를 위한 개발 프로세스 방법이에요. 스크럼의 가장 큰 특징은 프로젝트의 팀원들 전체가 개발 일정을 계획하는 데에 참여하고 또 점진적이고 반복적으로 프로세스를 만들어나간다는 데에 있어요.
소프트웨어 공학에서는 전통적 방식의 개발 모델을 보통 폭포수 모델이라고 하고, 스크럼을 비롯한 반복적인 피드백 등에 집중하는 개발을 애자일 모델이라고 해요. 전통적 방식의 개발 방법과 스크럼을 비교해 볼게요.
전통적인 방식의 개발은 기획이 전부 완성되면 아트와 모델링을 시작하고 그리고 나서 개발을 시작하는 방식으로 진행돼요. 마치 건물을 지을 때처럼 초석을 다지고 그 위에 뼈대를 올리고 또 그래야지만 살을 발라넣는 것처럼요. 스크럼은 좀 더 반복적이고 점진적인 변화를 통한 개발이라고 생각할 수 있어요. 게임의 큰 기획 방향과 목표가 정해지면 그 내부에 들어갈 요소들을 작은 단위로 나눠 개발하고 그게 우리가 만들고자 하는 게임의 목표에 부합하는지, 재미있는지 검증하고 피드백해가며 게임을 만들어 나가는 거라고 생각할 수 있어요.
1. 프로젝트에 포함해야 하는 백로그 리스트를 작성한다.
백로그: 기능 및 개선점들은 사용자의 시선에서 게임이 갖추어야 할 기능과 요소들을 뜻한다.
사용자의 요구에 맞추어 기획팀이 작성한다.
2. 백로그의 우선순위를 정한다.
3. 우선 순위에 맞춰 한 스프린트에서 구현할 목표를 정한다.
스프린트: 전체 일정을 잘게 쪼갠 30일 가량의 단위. 한 스프린트마다 스프린트의 목표에 부합하는 백로그들을 결정하고 결과물을 낸다. 결과물은 실행 가능한 수준으로 제작해 테스트가 가능해야 한다.
4. 스프린트 시작시마다 스프린트 회의를 한다.
스프린트 회의에서는 한 스프린트에서 구현할 백로그를 만들기 위해 필요한 테스크 리스트를 작성한다.
테스크: 백로그를 완성하기 위한 작업들 리스트. 한 테스크는 2-3시간부터 최대 3일 이내로 해결할 수 있도록 설정한다.
테스크를 배분하고 구현 난이도에 따라 테스크 작업 시간을 할당한다.
테스크명, 작업자, 작업시간을 적어 테스크마다 포스트잇에 옮겨적고 To Do 칸에 넣는다.
5. 매일 15분 정도 데일리 스크럼 회의를 한다.
팀원들 모두 어제 한 일, 오늘 할 일, 장애요소를 공유한다. 끝낸 테스크는 To Do에서 Done 칸으로 옮긴다. 공유를 통해 팀원 전부가 프로젝트의 어디에 위치하는지 알게 되고 일정이 늦어지는 원인(장애요소)도 알게 된다. 6. 번다운 차트를 작성한다.
번다운 차트 위에 매일매일 업무 진척도를 표시한다.
번다운 차트: 한 스프린트에 완료해야 할 테스크를 중심으로 총 작업 시간을 구한 후, 총 예상 시간, 남은 테스크를 각각 X, Y축으로 놓고 그린 그래프.
7. 한 스프린트를 완료하면 완성된 데모 버전을 테스트하고 피드백을 받는다.
테스트 대상은 프로젝트 내 팀원뿐 아니라 다른 팀원들도 포함한다.
8. 스프린트에서 더 나아질 수 있는 방향에 대해 나눈다.
어떤 점이 좋았고 어떤 점을 향상시킬 것인지를 정리한다.
9. 피드백을 통해 다음 스프린트 방향을 설정한다.
10. 다음 스프린트를 반복한다.
팀원들을 동기 부여할 수 있다.
팀원들 모두가 스프린트 및 전체 계획 프로세스에 참여하면서 자기주도적으로 업무를 진행할 수 있어요. 한 스프린트의 주기가 한달 남짓이고 또 스프린트마다 결과물을 내기 때문에 계속해서 작은 성취감을 느끼며 프로젝트를 진행할 수 있어요.
효율적으로 개발할 수 있다.
프로젝트를 중심으로 기획자, 개발자, 디자이너 모두가 동시에 작업을 진행하면서, 서로 무의미하게 선행 작업을 기다리며 보내던 시간을 줄일 수 있어요. 스프린트 리뷰를 통해 장애 요소 및 개선점을 나누면서 효율적인 방식으로 나아갈 뿐 아니라 다른 이들의 상황 공유를 통해 문제를 해결하는 방법을 시행착오 없이 배우기도 하죠. 번아웃차트와 데일리 스크럼 회의를 통해 모두가 프로젝트의 진행상황을 그대로 알 수 있구요.
일정과 팀 역량에 맞게 개발할 수 있다.
초기부터 전체일정을 전부 다 세워 놓으면 중간에 예상치 못한 난관에 막혀 딜레이가 생기기 쉬워요. 팀 역량을 과대평가하거나 과소평가해서 아예 전체 계획과 실제로 만들 수 있는 것들이 달라지기도 하구요. 스크럼을 이용하면 점진적인 결과물 단위로 프로젝트를 완성해 나가기 때문에 첫 스프린트에서부터 팀의 역량과 업무량을 조율해 나갈 수 있고요. 예상과 달랐던 부분을 중간에 손쉽게 바꿀 수 있어요. 예측 가능하게 일을 하면서, 마지막에 몰려 있는 야근이나 일정을 잔뜩 미루는 불상사도 피할 수 있어요.
목표에 가까운 결과물을 낼 수 있다.
스프린트를 통해 작은 단위의 완성된 결과물들을 내고 피드백을 받아요. 스프린트마다 준사용자들(팀원이 아닌 사내 다른 직원들)에게 받는 피드백을 통해 결과물이 프로젝트의 목표, 즉 게임이라면 ‘재밌는 게임'의 요소에 가까운지 평가를 받아요. 평가가 낮으면 새롭게 만들어요. 이 과정을 통해 기획 단계에서는 재밌어 보이는 아이디어가 실제로는 재미가 없다던가, 혹은 중간에 추가하면 정말 재밌을 것 같은 디테일들을 놓치지 않고 수정할 수 있어요.
리얼리티 리플렉션에서 스크럼 방식을 도입한 이후 좋아진 부분도 간단히 공유해 드릴게요.
개인에게 할당된 업무를 수행하면서 적극적으로 ‘우리의' 게임을 만든다는 분위기 조성
각자 맡은 부분의 진행 상황이 항상 공유됨 = 개발의 효율성 상승
서로의 진행 상황을 알고 있어서 게임에 부족한 부분, 필요한 부분들에 대한 아이디어가 다양하게 나옴
매일 모여서 회의를 함으로써 팀원들간의 친밀감이 높아짐. 꾸준하게 업무가 진행됨.
(매일매일의 개발 프로세스 정형화)
혹시 이 글을 읽고 스크럼 프로세스를 도입하려고 하신다면, 한 가지 주의해주세요.
스크럼 프로세스를 항상 다 엄격하게 지켜서 할 필요는 없다는 점이에요. 프로세스의 형식보다는 이 프로세스가 어떤 효과를 주려고 이렇게 만들어졌는지 고민하시는 게 중요해요.유용한 부분은 사용하고 또 굳이 필요없다고 생각하시는 부분은 변형해서 사용해주세요.
무엇보다도 가장 중요한 건 자기 팀에 맞게
잘 응용해서 성과를 내는 것이지, 형식이 아니니까요.
여기까지 리얼리티 리플렉션에서 사용하고 있는 게임 개발 방법 스크럼에 대해서 알아보았습니다.
리얼리티 리플렉션은 스크럼을 활용해 엄청난 게임 만들고 있을게요! 게임을 개발하려고 하는 스타트업이라면 효과적인 게임 개발 방법 스크럼을 이용하시는 것 한 번 고려해 보세요. 이 글이 도움이 되길 바라요! 화이팅!
이 글은 스타트업 Reality Reflection의 깨알 팁을 공유하기 위한 글이에요. 스타트업에서의 팁에 관해 쓰인 이 글이 좋았다면, 다른 글들도 읽어보시고 RR의 퍼블리케이션 꼭 구독해 주세요!