제작 관리와 팀 워크플로

완성은 아이디어가 아니라 프로세스에서 나온다

좋은 게임 아이디어는 출발점일 뿐이다. 실제 완성품은 일정, 역할, 문서, 의사결정이 맞물릴 때 나온다. 게임 개발은 기획, 코드, 아트, 사운드, QA가 동시에 움직이는 작업이다. 한 사람이 바꾼 결정이 다른 사람의 작업을 흔든다. 그래서 제작 관리는 창의성을 억누르는 절차가 아니라, 창의적인 선택이 끝까지 살아남게 만드는 구조다.

팀이 먼저 정해야 할 것은 무엇을 만들 것인가보다 어디까지 만들 것인가다. 범위가 흐리면 일정은 늘어나고, 기능은 쌓이며, 핵심 재미는 오히려 약해진다.

문서는 길게 쓰기보다 다르게 써야 한다

게임 디자인 문서, 즉 GDD는 게임의 핵심 경험과 규칙, 시스템의 의도를 설명한다. 모든 세부 수치를 끝없이 적는 문서가 아니라 팀이 같은 게임을 상상하게 만드는 기준점이다. 핵심 루프, 플레이어 목표, 주요 시스템, 승패 조건, 카메라, 조작 방식처럼 방향을 바꾸기 어려운 내용을 담는다.

기능 명세서는 구현을 위한 문서다. 예를 들어 상점 시스템을 만든다면 상품 목록, 구매 조건, 실패 처리, UI 상태, 저장 방식처럼 프로그래머와 기획자가 확인해야 할 작동 조건을 적는다. GDD가 왜 필요한가를 말한다면, 기능 명세서는 어떻게 작동해야 하는가를 말한다.

아트 가이드는 화면의 일관성을 지킨다. 캐릭터 비율, 색상 범위, UI 톤, 이펙트 강도, 참고 이미지의 방향을 정한다. 사운드 리스트는 필요한 효과음과 음악을 빠뜨리지 않게 만든다. 버튼음, 피격음, 환경음, 전투 음악, 결과 화면 음악처럼 발생 조건과 우선순위를 함께 적어야 한다.

좋은 문서는 두껍지 않다. 최신 상태이고, 필요한 사람이 바로 이해할 수 있으며, 결정의 근거를 남긴다.

애자일, 스크럼, 칸반을 현실에 맞게 쓰기

게임 개발에는 변수가 많다. 재미는 문서만으로 증명되지 않고, 플레이해 봐야 안다. 그래서 짧은 주기로 만들고 확인하는 방식이 잘 맞는다. 애자일은 계획을 포기하는 방법이 아니다. 작은 단위로 만들고, 자주 확인하고, 배운 것을 다음 계획에 반영하는 태도다.

스크럼은 일정한 기간을 스프린트로 나누어 목표를 정하고 실행하는 방식이다. 1주나 2주 단위로 이번 기간에 반드시 끝낼 기능을 고른다. 중요한 것은 스프린트 중간에 목표를 계속 바꾸지 않는 것이다. 계속 바뀌면 아무것도 완료되지 않는다.

칸반은 해야 할 일, 진행 중인 일, 완료한 일을 보드로 관리하는 방식이다. 특히 소규모 팀에 유용하다. 진행 중인 일을 제한하면 병목이 보인다. 모든 사람이 바쁜데 결과물이 없다면, 일이 너무 많이 열려 있다는 신호다.

게임 개발에서는 두 방식을 섞어도 된다. 큰 목표는 스프린트로 잡고, 세부 작업은 칸반 보드로 흐름을 관리한다.

단계마다 산출물을 분명히 한다

마일스톤은 일정상의 큰 확인 지점이다. 단순히 날짜가 아니라 확인 가능한 결과물이 있어야 한다. 예를 들어 첫 전투 가능, 첫 스테이지 완성, 저장과 로딩 구현처럼 검증 가능한 상태여야 한다.

버티컬 슬라이스는 게임의 작은 완성본이다. 전체 분량은 짧아도 기획, 아트, 사운드, UI, 기술이 실제 출시 품질에 가깝게 들어간다. 이 단계는 게임이 정말 성립하는지 확인하는 데 중요하다.

알파는 주요 기능이 대부분 들어간 상태다. 아직 거칠고 버그가 많을 수 있지만, 게임의 시작부터 끝까지 큰 흐름을 확인할 수 있어야 한다. 베타는 콘텐츠와 기능을 거의 고정하고 안정성, 밸런스, 사용성 문제를 고치는 단계다. 골드는 출시 가능한 빌드다. 이때는 새로운 아이디어를 넣는 시기가 아니라 위험을 줄이는 시기다.

스코프 크립을 막는 기준

스코프 크립은 개발 중 기능이 조금씩 늘어나 전체 범위가 통제되지 않는 현상이다. 대부분 나쁜 의도에서 생기지 않는다. 좋은 아이디어처럼 보이기 때문에 더 위험하다.

막는 방법은 우선순위다. 기능을 필수, 중요, 있으면 좋음으로 나눈다. 필수는 게임이 성립하기 위해 반드시 필요한 것이다. 중요는 품질을 높이지만 없어도 완성은 가능한 것이다. 있으면 좋음은 일정이 남을 때만 고려한다.

컷 기준도 미리 정해야 한다. 구현 시간이 예상보다 두 배 이상 늘어나는 기능, 핵심 루프를 강화하지 않는 기능, 다른 파트의 작업을 크게 늘리는 기능은 보류하거나 잘라야 한다. 기능을 줄이는 것은 실패가 아니다. 완성도를 지키기 위한 선택이다.

의사소통 오류를 줄이는 법

기획자는 의도를 말하고, 프로그래머는 조건과 예외를 확인하며, 아티스트는 화면에서 보이는 결과를 구체화하고, 사운드 디자이너는 감정과 타이밍을 만든다. 같은 단어도 직군마다 다르게 이해할 수 있다. 그래서 말보다 예시가 강하다.

회의에서는 결정 사항, 담당자, 완료 기준을 남겨야 한다. 작업 요청에는 참고 이미지, 예상 동작, 우선순위, 마감일이 함께 있어야 한다. 피드백은 취향이 아니라 목표와 연결해야 한다. 예를 들어 더 멋지게가 아니라 공격이 명중했다는 느낌이 약하니 이펙트 시작을 더 빠르게 보여 주자고 말해야 한다.

게임은 혼자 상상한 모습 그대로 완성되지 않는다. 팀이 같은 목표를 보고, 작은 결과물을 계속 쌓고, 필요할 때 과감히 줄일 때 완성된다. 좋은 프로세스는 팀을 느리게 만드는 장벽이 아니라, 끝까지 도착하게 만드는 길이다.