게임 개발 스프린트 운영 가이드: Agile·Scrum으로 일정과 스코프를 지키는 법
Agile·Scrum 기반 게임 개발 스프린트를 실무에 적용하는 방법을 정리합니다. 백로그 우선순위, 스프린트 계획, 데일리 협업, 플레이테스트, 리뷰와 회고까지 일정·스코프·품질을 함께 관리하는 운영 기준을 제공합니다.
게임 개발 스프린트가 흔들리는 핵심 원인은 일이 많아서가 아니라 목표·완료 기준·검증 순서가 분리되어 있기 때문이다. Scrum의 짧은 반복 주기에 게임 플레이 검증을 결합하면 기능 단위가 아니라 플레이 가능한 가치를 기준으로 일정과 스코프를 조절할 수 있다. 이 글은 2주 스프린트를 기준으로 백로그부터 리뷰와 회고까지의 운영 방법을 제시한다.
게임 개발에서 스프린트가 필요한 이유는 무엇인가?
게임 프로젝트는 기획, 클라이언트, 서버, 아트, 사운드, QA가 같은 기능을 서로 다른 형태로 완성해야 한다. 예를 들어 ‘보스 전투 추가’는 몬스터 AI 코드만으로 끝나지 않는다. 패턴 데이터, 애니메이션 이벤트, 이펙트, 사운드, 난이도 조정, HUD, 저장 데이터, 테스트 시나리오까지 연결된다.
이 연결을 긴 마일스톤 하나로만 관리하면 문제는 마지막 통합 단계에서 발견된다. 스프린트는 1~2주 안에 작은 가설을 구현하고 플레이테스트로 확인해 위험을 앞당겨 발견하는 운영 단위다.
| 구분 | 기능 중심 운영 | 플레이 가치 중심 스프린트 |
|---|---|---|
| 완료 판단 | 담당 파트의 작업 종료 | 빌드에서 플레이·검증 가능 |
| 우선순위 | 요청 순서 또는 목소리 큰 요구 | 유저 가치, 위험, 의존성 |
| 문제 발견 시점 | 통합 또는 막바지 QA | 데일리 확인, 리뷰, 플레이테스트 |
| 스코프 변경 | 일정 막판에 충돌 | 다음 스프린트 백로그로 조정 |
게임 개발 스프린트는 어떻게 설계할까?
1. 스프린트 길이와 공통 리듬을 고정한다
처음에는 2주(10영업일) 를 권장한다. 1주는 아트와 외부 의존성의 리드타임을 흡수하기 짧을 수 있고 3주 이상은 피드백이 늦어지기 쉽다. 팀이 이미 빠르게 통합하고 자동 빌드를 운영한다면 1주 스프린트도 가능하다.
일정은 매번 바꾸지 말고 다음 리듬을 고정한다.
| 시점 | 활동 | 산출물 |
|---|---|---|
| 시작일 오전 | Sprint Planning | 스프린트 목표, 선택된 백로그 |
| 매일 10~15분 | Daily Scrum | 장애물, 의존성, 당일 통합 계획 |
| 중간 시점 | 플레이테스트·스코프 점검 | 관찰 결과, 조정 제안 |
| 종료일 | Sprint Review | 실제 빌드, 이해관계자 피드백 |
| 리뷰 직후 | Retrospective | 다음 스프린트의 개선 행동 1~2개 |
2. 스프린트 목표를 기능 목록이 아닌 플레이어 변화로 쓴다
좋지 않은 목표는 ‘인벤토리 UI 구현’처럼 작업 목록을 그대로 옮긴 문장이다. 좋은 목표는 “플레이어가 전투 보상을 확인하고 장비를 교체한 뒤 다음 전투를 선택할 수 있다”처럼 결과를 설명한다.
- 나쁜 예: 상점 UI, 재화 API, 아이템 아이콘 추가
- 좋은 예: 스테이지 클리어 뒤 획득 재화로 소모품을 구매하고 다음 전투에 사용할 수 있다
목표가 정해지면 각 직군의 작업은 그 목표를 만족시키는 최소 단위로 나눈다. 목표에 직접 기여하지 않는 연출 고도화, 희귀 아이템 확장, 관리자 편의 기능은 다음 백로그 후보로 남긴다.
3. 팀의 실제 가용 용량으로 계획한다
개인별 최대 작업 시간의 합을 계획 용량으로 쓰면 안 된다. 회의, 코드 리뷰, 빌드 오류, 버그 수정, 지원 업무를 제외한 집중 시간을 반영해야 한다.
예를 들어 5명이 10일 동안 일하지만 휴가와 공통 업무를 고려한 가용일 합계가 42일이고 집중 가능 시간 비율을 0.7로 잡으면 계획 기준은 약 29.4 인일이다. 처음 몇 차례는 추정치보다 실제 완료량을 기록하고 팀의 평균 완료량인 벨로시티를 기준으로 다음 계획을 보정한다.
게임 백로그 우선순위는 어떤 기준으로 정해야 할까?
게임의 백로그는 단순 기능 요청 목록이 아니다. 플레이 경험, 기술 위험, 사업 일정, 라이브 운영 요구가 섞인 의사결정 목록이다. 각 항목에 우선순위 근거를 붙이면 회의에서 ‘무엇을 먼저 할지’보다 ‘왜 지금 해야 하는지’를 논의할 수 있다.
간단한 점수 방식으로는 RICE를 게임 상황에 맞춰 사용할 수 있다.
- Reach: 이번 테스트 또는 출시 구간에서 영향을 받는 플레이어 수
- Impact: 핵심 루프, 전환율, 유지율, 안정성에 주는 영향
- Confidence: 데이터·플레이테스트·기술 조사로 뒷받침되는 확신도
- Effort: 구현과 검증에 필요한 인일 또는 스토리 포인트
다만 점수만으로 결정하지는 않는다. 빌드를 막는 크래시, 플랫폼 인증 이슈, 저장 데이터 손상 가능성은 점수와 관계없이 최우선으로 처리한다.
게임 백로그 항목에는 완료 기준을 함께 기록한다
사용자 스토리는 다음처럼 작성할 수 있다.
플레이어로서 보스 패턴의 예고 신호를 보고 회피할 시간을 판단하고 싶다. 그래야 실패 원인을 이해하고 다시 도전할 수 있다.
이 문장만으로는 완료를 판정하기 어렵다. 반드시 인수 조건(Acceptance Criteria)을 붙인다.
- 보스의 돌진 공격 전 0.8초 동안 바닥 경고 이펙트와 방향 표시가 나온다.
- 난이도 ‘보통’에서 경고 종료 후 피격 판정까지 0.3초의 회피 가능 시간이 있다.
- 키보드와 게임패드에서 회피 입력이 정상 동작한다.
- 20회 연속 전투에서 경고 이펙트가 누적되거나 사라지지 않는 문제가 없다.
- QA 체크리스트와 플레이테스트 영상으로 동작을 확인한다.
Definition of Ready와 Definition of Done은 왜 필요한가?
작업이 스프린트 중간에 멈추는 흔한 이유는 티켓이 준비되지 않은 상태로 들어오기 때문이다. Definition of Ready(DoR) 는 시작 가능한 조건이고 Definition of Done(DoD) 은 정말 끝난 조건이다.
| 항목 | Definition of Ready | Definition of Done |
|---|---|---|
| 기획 | 플레이어 목표와 예외 흐름이 정의됨 | 인수 조건을 충족함 |
| 의존성 | API, 에셋, 담당자와 일정이 확인됨 | 의존 파트와 통합됨 |
| 기술 | 위험 요소와 구현 방향이 검토됨 | 코드 리뷰와 필요한 테스트 완료 |
| 품질 | 테스트 방법과 대상 플랫폼이 명시됨 | QA 확인 및 알려진 이슈 기록 |
| 빌드 | 브랜치·씬·데이터 위치가 정리됨 | 대상 브랜치에서 빌드 가능 |
DoD는 “개발 완료”를 “리뷰 가능한 빌드에서 검증 완료”로 바꾼다. 아트가 임시 에셋으로 연결되어 있거나 서버 API가 목업 상태라면 그 사실을 티켓과 리뷰에서 명확히 표시해야 한다. 숨긴 미완료 항목은 나중에 부채가 아니라 일정 오류로 돌아온다.
스프린트 플래닝을 90분 안에 끝내는 순서
1. 제품 목표와 이번 스프린트 목표를 먼저 확인한다
Product Owner 또는 의사결정권자는 이번 기간에 검증할 플레이어 가치와 출시 제약을 5분 안에 설명한다. 이때 백로그를 처음부터 끝까지 읽지 않는다. 목표와 무관한 항목은 후보 목록에 남긴다.
2. 상위 백로그의 의존성과 인수 조건을 확인한다
기획, 클라이언트, 서버, 아트, QA가 각 항목에서 막힐 부분을 확인한다. 불확실성이 큰 항목은 구현 대신 스파이크(Spike)로 쪼갠다. 스파이크의 결과물은 코드량이 아니라 결정에 필요한 결과다. 예를 들어 “네트워크 동기화 방식 2개를 프로토타입으로 비교하고 권장안을 문서화한다”처럼 종료 조건을 정한다.
3. 용량 안에서 선택하고 목표 달성에 필요한 최소 범위를 합의한다
작업을 너무 촘촘하게 채우지 말고 전체 용량의 10~20%를 버그, 통합, 예상 밖의 조정에 남긴다. 백로그를 확정한 뒤에는 누가 무엇을 맡을지 정리하되 스프린트 백로그는 개인 소유가 아니라 팀이 목표 달성을 위해 관리하는 목록이라는 원칙을 유지한다.
flowchart TD
A[제품 목표와 지표 확인] --> B[스프린트 목표 작성]
B --> C[상위 백로그의 인수 조건 확인]
C --> D{DoR 충족?}
D -- 아니오 --> E[조사 또는 준비 작업으로 분리]
E --> C
D -- 예 --> F[용량과 의존성 검토]
F --> G[스프린트 백로그 확정]
G --> H[매일 통합·플레이테스트]
H --> I[리뷰에서 실제 빌드 시연]데일리 스크럼은 어떻게 협업 문제를 빨리 드러낼까?
데일리 스크럼은 어제 한 일을 보고하는 자리가 아니라 스프린트 목표까지의 경로를 조정하는 15분 회의다. 보드 앞에서 다음 세 질문을 사용한다.
- 스프린트 목표를 막는 항목은 무엇인가?
- 오늘 통합하거나 검증해야 할 변경은 무엇인가?
- 다른 직군의 결정·에셋·API가 필요한 곳은 어디인가?
문제 해결 토론은 데일리 직후에 필요한 사람만 남아 진행한다. 예를 들어 UI 담당자가 아이콘 규격을 기다리고 있다면 회의에서 해결하려 하지 말고 아트 담당자와 10분 후 규격을 확정할 약속을 만든다.
칸반 보드에는 최소한 To Do, In Progress, Review, QA/Playtest, Done 상태를 둔다. 동시에 진행하는 작업 수(WIP)가 많아지면 통합과 검증이 밀리므로 팀은 In Progress 항목 수를 제한하는 편이 좋다.
게임 스프린트 리뷰에서 무엇을 보여줘야 하는가?
리뷰의 주인공은 발표 자료가 아니라 실제 실행 가능한 빌드다. 각 항목은 스프린트 시작 때 합의한 인수 조건을 따라 시연한다. 실패 사례나 남은 제약도 함께 말해야 다음 우선순위 결정이 정확해진다.
리뷰에서 확인할 내용은 다음과 같다.
- 스프린트 목표가 실제 플레이 흐름에서 달성되는가?
- 어떤 인수 조건이 충족됐고 무엇이 보류됐는가?
- 플레이테스트에서 관찰된 행동은 예상과 어떻게 달랐는가?
- 다음 스프린트 전에 결정해야 할 스코프 또는 방향 전환은 무엇인가?
이해관계자의 새 요청은 회의 중 즉시 투입하지 말고 제품 백로그에 기록한 뒤 우선순위를 다시 평가한다. 진행 중인 스프린트에 새 요구를 넣으면 완료 항목이 줄고 예측 가능성도 사라진다. 단, 서비스 장애나 치명적 보안 이슈처럼 즉시 대응이 필요한 경우는 스프린트를 중단하거나 목표를 다시 협의한다.
회고에서 생산성을 높이는 개선 행동은 어떻게 정할까?
회고는 감상 공유로 끝나면 효과가 없다. 사실을 바탕으로 하나 또는 두 개의 실험 가능한 행동을 정하고 다음 스프린트에서 결과를 확인해야 한다.
좋은 회고 항목의 예시는 다음과 같다.
| 관찰된 문제 | 추측 | 다음 스프린트 실험 | 확인 지표 |
|---|---|---|---|
| QA가 종료일에 몰림 | 기능 통합이 늦음 | 매일 오후 통합 빌드 실행 | 종료 2일 전 QA 완료 항목 비율 |
| 기획 질문이 반복됨 | 예외 흐름이 티켓에 없음 | DoR에 예외 흐름 체크 추가 | 진행 중 질문 수 |
| 코드 리뷰 대기 증가 | 리뷰 요청이 너무 큼 | PR을 400줄 이하로 분리 | 평균 리뷰 대기 시간 |
‘소통을 잘하자’는 행동이 아니다. ‘매일 16시에 통합 빌드를 만들고 실패한 항목은 다음 날 데일리의 첫 안건으로 둔다’처럼 누가 언제 무엇을 할지 정해야 한다.
자주 묻는 질문 (FAQ)
스프린트 중간에 기획이 바뀌면 어떻게 해야 하나?
새 요구를 제품 백로그에 기록하고 영향도와 우선순위를 평가한다. 현재 목표를 깨지 않는 작은 조정은 팀 합의로 반영할 수 있지만 목표 자체를 바꾸는 요구라면 스프린트 취소 또는 목표 재협의가 필요하다.
버그 수정은 별도 스프린트로 빼야 하나?
치명적 버그와 스프린트 목표를 막는 버그는 즉시 처리한다. 그 외 버그는 심각도, 재현율, 영향 범위를 기준으로 백로그에 넣는다. 매 스프린트에 버그 처리 용량을 일부 남겨두면 별도 안정화 기간에 과도하게 의존하지 않아도 된다.
스토리 포인트와 시간 추정 중 무엇을 써야 하나?
계획에는 상대적 복잡도를 표현하는 스토리 포인트가 유용하고 외부 일정 협의에는 가용일 기반의 용량이 유용하다. 둘 중 하나만 절대적으로 믿기보다 완료 기록을 쌓아 팀의 실제 예측 정확도를 높이는 것이 중요하다.
마무리
좋은 게임 개발 스프린트는 더 많은 티켓을 끝내는 장치가 아니다. 팀이 짧은 주기 안에 플레이 가능한 결과를 만들고 불확실한 가정을 검증하며 다음 선택을 더 정확하게 하도록 돕는 운영 방식이다. 스프린트 목표, DoR·DoD, 매일의 통합과 플레이테스트, 실제 빌드 중심의 리뷰를 일관되게 적용하면 일정과 품질을 함께 관리할 수 있다.
