게임 개발은 계획대로만 흘러가지 않습니다. 만들어 보니 재미가 없어 방향을 바꾸기도 하고, 테스트 결과에 따라 우선순위가 달라지기도 합니다. 애자일은 이런 변화에 유연하게 대응하기 위한 일하는 방식이고, 스크럼은 애자일을 실천하는 대표적인 틀입니다. 이 글에서는 스크럼의 기본 구조와 게임 개발에 적용하는 방법을 설명합니다.

애자일과 스크럼의 기본 생각

전통적인 방식은 처음에 전체 계획을 세우고 순서대로 진행합니다. 애자일은 큰 계획을 짧은 주기로 나눠 만들고, 결과를 보고, 다음 계획을 고치는 과정을 반복합니다. 완벽한 계획보다 자주 확인하고 빠르게 고치는 것을 중요하게 여깁니다.

스크럼은 이 생각을 구체적인 규칙으로 정리한 틀입니다. 일정한 길이의 작업 주기인 스프린트, 해야 할 일 목록인 백로그, 정해진 회의, 정해진 역할로 구성됩니다.

게임 개발에 애자일이 잘 맞는 이유는 재미를 미리 확신하기 어렵기 때문입니다. 문서로 완벽해 보이는 기능도 직접 해 봐야 재미를 알 수 있습니다. 짧은 주기로 만들어 보고 확인하는 방식은 잘못된 방향으로 오래 달리는 위험을 줄여 줍니다.

스크럼의 구성 요소

게임 회사에서는 제품 책임자 역할을 디렉터나 기획 리드가, 스크럼 마스터 역할을 PM이 맡는 경우가 많습니다. 다만 회사마다 이름과 역할 배분은 다를 수 있습니다.

스프린트 한 번의 흐름

1. 스프린트 계획: 백로그에서 이번 주기에 할 작업을 고르고 목표를 정합니다.
2. 데일리 스크럼: 매일 짧게 모여 어제 한 일, 오늘 할 일, 막힌 점을 공유합니다.
3. 작업 진행: 작업 보드에서 할 일, 진행 중, 완료로 상태를 옮기며 일합니다.
4. 스프린트 리뷰: 완성된 결과물을 시연하고 피드백을 받습니다.
5. 회고: 일하는 방식에서 잘된 점과 고칠 점을 이야기합니다.

데일리 스크럼은 보고 자리가 아니라 서로 도울 일을 찾는 자리입니다. 짧게 끝내고, 깊은 논의가 필요한 문제는 관련된 사람만 따로 모여 이야기합니다.

회고는 가장 소홀해지기 쉬운 회의입니다. 일정이 바쁘면 건너뛰고 싶어지지만, 같은 문제가 스프린트마다 반복된다면 회고가 제대로 이루어지지 않고 있다는 신호입니다. 고칠 점을 한두 개만 골라 다음 스프린트에서 실제로 바꿔 보는 것이 좋습니다.

게임 개발에 맞게 쓰는 법

게임 개발에 스크럼을 쓸 때 특히 좋은 점은 스프린트마다 플레이 가능한 결과물을 만든다는 것입니다. 문서로만 보던 기능을 직접 해 보면 재미 여부를 일찍 알 수 있습니다. 백로그 항목을 '유저가 무엇을 할 수 있게 된다'는 형태로 쓰면 결과물을 확인하기 쉬워집니다.

• 백로그 항목 예: '플레이어는 상점에서 포션을 구매할 수 있다'
• 완료 기준 정하기: 기획 문서, 구현, 테스트, 리소스 적용까지 끝나야 완료로 봅니다.
• 직군 간 의존 관리: 아트 리소스가 늦어지면 임시 리소스로 먼저 기능을 완성합니다.
• 작업 보드 활용: 협업 도구로 작업 상태를 모두가 볼 수 있게 합니다.

주의할 점

스크럼은 만능이 아닙니다. 아트 리소스처럼 제작 기간이 길고 미리 계획해야 하는 작업은 짧은 스프린트에 맞추기 어렵습니다. 그래서 많은 팀이 큰 마일스톤 계획과 스프린트 운영을 함께 씁니다. 또 회의만 늘고 실제 개선이 없다면 형식만 남은 것입니다. 회고에서 나온 개선점을 다음 스프린트에 실제로 반영하는지가 중요합니다.

출시가 가까워지면 새 기능보다 버그 수정이 중심이 되므로 스프린트 목표도 품질 중심으로 바뀝니다. 상황에 맞게 방식을 조정하는 것 자체가 애자일의 핵심입니다. SBS아카데미게임학원 프로젝트관리 과정에서는 Jira·Confluence·Notion 같은 협업 도구로 실제 팀이 일하는 방식을 익힙니다.

자주 묻는 질문