Agile/Scrum으로 게임 개발 스프린트 주기 관리하는 법

게임 개발의 스프린트 관리는 ‘2주마다 기능을 끝낸다’는 일정표가 아닙니다. 제품 백로그(Product Backlog)를 플레이 가능한 가치 단위로 쪼개고 팀의 실제 처리량(Velocity)에 맞춰 범위를 약속한 뒤 리뷰와 회고로 다음 주기를 보정하는 운영 방식입니다. 핵심은 작업량을 밀어 넣는 것이 아니라 스프린트 목표를 지킬 수 있도록 스코프와 협업 방식을 관리하는 데 있습니다.

게임 개발에 Agile/Scrum이 필요한 이유는 무엇인가?

게임은 클라이언트 코드, 서버, 기획, 아트, 사운드, QA가 동시에 맞물립니다. 전투 시스템 하나를 추가해도 입력 처리, 애니메이션, VFX, 밸런스 데이터, UI, 적 AI, 튜토리얼, 테스트 시나리오가 연쇄적으로 영향을 받습니다. 일정이 흔들리는 이유는 대개 각 직군의 작업량보다 완료 기준과 의존성이 불명확하기 때문입니다.

Scrum은 다음 질문에 짧은 주기로 답하도록 만듭니다.

• 이번 스프린트가 끝났을 때 플레이어가 확인할 수 있는 결과는 무엇인가?
• 그 결과를 막는 의존성과 위험은 무엇인가?
• 새 요청이 들어왔을 때 무엇을 미루거나 제거할 것인가?

Scrum 역할과 산출물을 게임 팀에 맞게 정의하기

Scrum 용어를 그대로 도입하기보다 책임 경계를 먼저 합의해야 합니다.

Scrum 요소	게임 개발에서의 적용	주의할 점
Product Owner	게임 디렉터, 프로듀서 또는 권한을 위임받은 기획 리드	여러 사람이 우선순위를 동시에 바꾸지 않도록 최종 결정권을 명확히 한다.
Scrum Master	PM, 프로듀서 또는 순환 진행자	팀원 대신 일정 약속을 하거나 업무를 배분하는 역할이 아니다. 장애물을 제거하고 회의를 개선한다.
Developers	클라이언트, 서버, 기획, 아트, QA 등 스프린트 목표 달성에 필요한 구성원	Scrum Team 안에서 하나의 Sprint Goal을 공유하고 Increment를 만든다.
Product Backlog	기능, 콘텐츠, 기술 부채, 버그, 검증 과제의 우선순위 목록	‘캐릭터 제작’처럼 직군 중심으로 적지 말고 플레이어 가치 중심으로 쓴다.
Definition of Done	완료로 인정하는 조건	코드 작성 완료와 배포 가능한 완료를 구분하지 않으면 처리량이 왜곡된다.

예를 들어 보스 전투 구현은 너무 넓습니다. 반면 플레이어가 1페이즈 보스의 패턴 3개를 회피하고 처치할 수 있다는 검증 가능한 스프린트 목표가 됩니다. 그 아래에 클라이언트, AI, 애니메이션, VFX, 사운드, QA 작업을 연결합니다.

Definition of Done은 어떻게 작성할까?

게임 기능의 완료 조건에는 최소한 다음 항목을 포함하는 편이 좋습니다.

[전투 패턴 01 완료 조건]
- 빌드에서 입력, 피격 판정, 애니메이션 전환이 정상 동작한다.
- 난이도 데이터가 ScriptableObject 또는 DataTable에서 조정 가능하다.
- 60 FPS 목표 플랫폼에서 프로파일링 기준을 통과한다.
- 재현 절차가 있는 치명적 버그가 없다.
- QA 테스트 케이스와 알려진 제한 사항이 티켓에 기록돼 있다.
- 스프린트 리뷰에서 플레이 가능한 빌드로 시연했다.

Unity를 사용한다면 Profiler, Frame Debugger, Addressables 검증 여부처럼 프로젝트의 실제 품질 기준을 명시합니다. Unreal Engine이라면 Unreal Insights, 패키징 빌드, 네트워크 플레이 테스트 같은 기준이 될 수 있습니다. 중요한 것은 엔진 이름이 아니라 팀이 완료를 같은 방식으로 판정하는 것입니다.

게임 개발 스프린트 플래닝은 어떻게 진행할까?

2주 스프린트를 기준으로 60~90분의 플래닝을 운영할 수 있습니다. 준비가 부족하면 회의 시간을 늘리지 말고 백로그 정제(Refinement)를 별도 시간으로 확보해야 합니다.

1. 스프린트 목표를 한 문장으로 합의한다

목표는 산출물 목록이 아니라 플레이어 또는 팀이 얻는 결과를 표현합니다.

• 나쁜 예: 전투 UI, 보스 AI, 이펙트 작업
• 좋은 예: 신규 플레이어가 튜토리얼 후 첫 보스 전투를 완주할 수 있다.

목표가 있으면 긴급 요청이 들어와도 판단 기준이 생깁니다. 요청이 목표 달성에 직접 기여하지 않는다면 다음 스프린트 백로그 후보로 옮깁니다.

2. 용량(Capacity)과 실제 처리량으로 범위를 정한다

개인의 근무일을 단순 합산하지 않습니다. 휴가, 고정 회의, 라이브 이슈 대응, 코드 리뷰, QA 리그레션 시간을 빼야 합니다. 스토리 포인트를 쓴다면 최근 3~5개 스프린트의 완료 포인트 중앙값을 기준으로 계획합니다.

$$\text{Sprint Capacity} = \text{가용 인원일} \times \text{집중 가능 비율}$$

예를 들어 5명이 10영업일 동안 일해도, 회의·지원·리뷰로 집중 가능 비율이 0.65라면 계획 가능한 용량은 32.5 인원일입니다. 신규 시스템처럼 불확실성이 큰 작업은 여기에 별도 버퍼를 더하는 대신, 버퍼를 이름 없는 작업으로 숨기지 말고 기술 검증 또는 리스크 대응 항목으로 백로그에 기록합니다.

3. 의존성, 완료 조건, 분할 가능성을 검토한다

티켓을 선택하기 전 다음 세 가지를 확인합니다.

1. 다른 직군이나 외부 팀의 선행 작업이 있는가?
2. 스프린트 안에 검증 가능한 수직 슬라이스로 자를 수 있는가?
3. 완료 조건을 테스트 또는 시연으로 확인할 수 있는가?

보스 1종 완성이 크다면 1페이즈 패턴 3종 + 기본 보상 루프처럼 수직으로 자릅니다. 임시 아트나 간단한 VFX를 사용하더라도 실제 조작부터 판정, 보상까지 연결하면 플레이 테스트에서 더 빨리 위험을 발견할 수 있습니다.

데일리 스크럼과 칸반 보드는 무엇을 관리해야 하는가?

데일리 스크럼은 개인별 업무 보고 시간이 아닙니다. 스프린트 목표를 향한 계획을 조정하는 15분 회의입니다. 보드를 보며 다음만 확인합니다.

• In Progress가 과도하게 쌓였는가?
• Blocked 상태의 작업은 누가 언제 해소할 수 있는가?
• 리뷰 또는 QA 대기열이 병목이 되고 있는가?
• 오늘 목표 달성을 위해 함께 끝내야 할 작업은 무엇인가?

보드 상태	운영 규칙 예시	관리 목적
Ready	완료 조건과 선행 조건이 확인된 티켓만 둔다.	시작 전 불확실성을 줄인다.
In Progress	직군 또는 팀 단위 WIP 제한을 둔다.	시작한 일을 끝내는 흐름을 만든다.
Review	코드, 기획, 아트 검토의 담당자와 응답 기한을 기록한다.	승인 대기를 숨기지 않는다.
QA	테스트 환경과 재현 정보를 티켓에 첨부한다.	통합 단계의 재작업을 줄인다.
Done	Definition of Done을 모두 만족할 때만 이동한다.	허상 처리량을 방지한다.

WIP(Work In Progress) 제한은 특히 효과적입니다. 예를 들어 클라이언트 작업자가 동시에 4개 티켓을 시작하는 대신 최대 2개만 진행하도록 정하면 리뷰 요청과 통합 가능한 작업이 더 빨리 나옵니다. 이는 개인 생산성을 통제하려는 규칙이 아니라 팀 전체의 완료 흐름을 보호하는 장치입니다.

스프린트 중 우선순위가 바뀌면 어떻게 할까?

라이브 이슈, 플랫폼 심사 대응, 치명적 버그처럼 미룰 수 없는 요청은 생깁니다. 이때 기존 스프린트에 새 일을 무조건 추가하면 목표와 처리량이 모두 무너집니다.

1. 요청의 긴급도와 영향 범위를 Product Owner가 판단합니다.
2. 반드시 처리해야 한다면 동등한 규모의 낮은 우선순위 작업을 스프린트에서 제거합니다.
3. 제거할 작업이 없다면 스프린트 목표를 재협상하고 변경 사유를 기록합니다.

변경 기록은 한 줄이면 충분합니다. 예를 들어 8월 2주차: Android 결제 장애 대응으로 보스 보상 연출 티켓을 다음 스프린트로 이동처럼 남기면 회고에서 예측 실패인지 외부 사건인지 구분할 수 있습니다.

스프린트 리뷰와 회고에서 무엇을 확인해야 하는가?

리뷰는 완료 티켓을 읽는 회의가 아니라 실제 빌드를 보여 주는 자리입니다. 플레이 가능한 데모, 캡처 영상, 성능 측정값, 알려진 제한 사항을 준비하고 이해관계자로부터 피드백을 받습니다. 미완료 작업은 완료로 계산하지 않으며 다음 스프린트에서 다시 우선순위를 판단합니다.

회고에서는 개인 평가 대신 시스템을 개선합니다. 아래처럼 관찰 가능한 사실과 실험을 연결하면 효과적입니다.

관찰한 문제	가능한 원인	다음 스프린트 실험
QA 대기 티켓이 마지막 3일에 집중됐다.	구현 후 통합 테스트가 늦었다.	기능별 테스트 가능한 빌드를 5영업일 차에 만든다.
아트 변경으로 UI 구현이 두 번 되돌아갔다.	승인 시점과 에셋 규격이 불명확했다.	플래닝 전에 화면 규격과 상태 목록을 승인한다.
스토리 포인트 편차가 컸다.	기술 검증이 구현 티켓 안에 섞였다.	불확실한 항목은 스파이크(Spike) 티켓으로 분리한다.

회고 액션은 한두 개만 선택하고 담당자와 확인 시점을 정합니다. 너무 많은 개선 항목은 다음 스프린트에 실행되지 않기 쉽습니다.

자주 묻는 질문 (FAQ)

스프린트는 1주와 2주 중 어느 기간이 적절한가?

팀이 피드백을 받고 통합 빌드를 만들 수 있는 가장 짧은 기간을 선택합니다. 신규 팀이나 변화가 잦은 프로젝트는 1주, 여러 직군의 에셋·통합 의존성이 큰 팀은 2주가 실무적으로 안정적인 경우가 많습니다. 한 번 정한 기간은 최소 3~4회 운영한 뒤 데이터로 조정합니다.

버그 수정도 스프린트 백로그에 넣어야 하는가?

넣어야 합니다. 치명도 높은 라이브 장애는 별도 긴급 경로를 둘 수 있지만 계획 가능한 버그와 기술 부채는 기능 작업과 같은 백로그에서 우선순위를 비교해야 실제 개발 비용을 볼 수 있습니다.

스토리 포인트 없이도 Scrum을 운영할 수 있는가?

가능합니다. 작은 팀은 티켓 크기를 ‘1~2일 이내에 완료 가능한 단위’로 제한하고 처리 완료 건수와 리드 타임을 측정해도 됩니다. 다만 포인트를 쓰든 쓰지 않든, 미완료 작업을 완료로 계산하지 않는 규칙은 유지해야 합니다.

정리

게임 개발에서 Agile/Scrum의 목적은 회의를 늘리는 것이 아니라 불확실성을 빠르게 드러내고 조정하는 것입니다. 플레이 가능한 스프린트 목표, 명확한 Definition of Done, 실제 용량 기반의 범위 선정, WIP 제한, 짧고 실행 가능한 회고를 꾸준히 운영하면 일정 예측과 협업 품질을 함께 개선할 수 있습니다.