기획 탐색 단계와 개발 반복 단계를 구분하는 편이 게임 팀에는 더 현실적일 때가 많다
게임 팀이 애자일을 도입했다고 해서 모든 것이 짧은 스프린트 안에서 자연스럽게 풀리지는 않는다. 특히 게임 개발은 무엇을 만들 것인가를 찾는 과정과 정한 것을 어떻게 구현하고 다듬을 것인가의 성격이 꽤 다르다. 이 둘을 섞어 버리면 기획은 계속 흔들리고, 개발은 계속 되돌아가게 된다.
그래서 제품 조직에서는 종종 발견(discovery)과 전달(delivery)을 구분해 다루자고 말한다. 게임 개발에서도 이 구분은 꽤 유용하다.
기획 탐색은 질문을 줄이는 과정이다
초기 단계의 핵심 질문은 보통 이렇다. 이 게임의 핵심 루프가 재미있는가, 어떤 장르 문법을 따를 것인가, 어떤 규모가 가능한가, 어떤 기술 리스크가 있는가. 이 단계에서는 정답보다 가설과 실험이 중요하다.
라미 이스마일이 프로토타입을 질문에 답하기 위한 도구라고 말한 것도 같은 이유다. 프로토타입 단계에서는 정확한 일정과 완성도보다, 무엇이 아직 결정되지 않았는지를 빨리 줄여 가는 편이 중요하다.
개발 반복은 속도보다 안정성을 위해 범위를 고정하는 과정이다
반대로 본격 제작 단계에 들어가면 질문의 종류가 바뀐다. 이제는 무엇을 만들까보다 언제 어떤 순서로 만들까, 어떻게 버그를 줄일까, 어떤 피드백을 다음 빌드에 넣을까가 중요해진다. 여기서는 잦은 큰 방향 전환이 팀을 더 지치게 만들 수 있다.
그래서 발견 단계에서 정리된 방향을 바탕으로, 제작 단계에서는 범위를 일정 수준 고정하고 짧은 반복으로 다듬는 편이 더 현실적일 때가 많다.
둘을 구분한다고 해서 폭포수 모델로 돌아가자는 뜻은 아니다
이 구분은 처음에 다 정하고 끝까지 안 바꾼다는 뜻이 아니다. 오히려 큰 질문과 작은 개선을 서로 다른 리듬으로 다루자는 뜻에 가깝다. 발견 단계에서는 과감하게 버리고 바꾸되, 전달 단계에서는 변경 비용을 고려하며 움직이는 것이다.
실무적으로는 보통 이런 식으로 작동한다.
- 발견: 프로토타입, 플레이 루프 검증, 아트 방향 탐색, 기술 리스크 확인
- 전달: 일정 관리, 기능 구현, 버그 수정, 플레이테스트 반영, 품질 개선
이 두 리듬이 섞이면 팀은 매주 회의에서 세계관과 조작계를 다시 논의하면서도 동시에 안정적인 빌드를 내야 하는 상태가 된다.
마치며
게임 개발에서 중요한 것은 애자일이라는 이름 자체가 아니라, 서로 다른 종류의 일을 같은 방식으로 다루지 않는 것이다. 기획 탐색과 개발 반복은 둘 다 필요하지만, 리듬과 기준이 다르다.
그래서 팀이 계속 흔들린다면 애자일을 더 잘하자보다 지금 우리는 발견 단계의 문제를 전달 단계에서 풀려고 하고 있지 않은가를 먼저 물어보는 편이 낫다. 많은 혼란은 그 지점에서 줄어든다.