게임 프로그래머는 기획서의 규칙을 실제로 돌아가는 코드로 바꾸는 사람입니다. 수업은 C 언어와 C++로 변수, 함수, 포인터, 객체지향 같은 기본기를 단단히 …
일정표가 없는 프로젝트에서 벌어지는 일
개인 프로젝트든 팀 프로젝트든 일정표 없이 시작하면 처음에는 빠르게 진행되는 것처럼 느껴집니다. 하고 싶은 기능부터 손대고, 재미있는 부분을 먼저 만들기 때문입니다. 그런데 마감이 가까워지면 메뉴 화면, 사운드 연결, 버그 수정처럼 미뤄 둔 일이 한꺼번에 몰려옵니다. 결국 마지막 몇 주를 밤새우며 보내거나, 핵심 기능을 빼고 제출하게 됩니다.
팀 프로젝트에서는 문제가 더 커집니다. 프로그래머는 캐릭터 그래픽이 나와야 애니메이션을 연결할 수 있고, 아티스트는 화면 크기가 정해져야 UI를 그릴 수 있습니다. 누가 무엇을 언제까지 해야 하는지 보이지 않으면 서로를 기다리느라 시간이 흘러갑니다. 일정표는 이런 기다림을 미리 드러내 주는 지도 역할을 합니다.
먼저 마일스톤을 세운다
마일스톤은 프로젝트 중간중간의 확인 지점입니다. 날짜만 정하는 것이 아니라, 그 지점에 무엇이 되어 있어야 하는지 완료 기준을 함께 적는 것이 중요합니다. 기준이 모호하면 '거의 다 됐다'는 말만 반복하게 됩니다.
| 마일스톤 | 완료 기준 예시 |
|---|---|
| 프로토타입 | 임시 그래픽으로 핵심 놀이를 처음부터 끝까지 한 판 플레이할 수 있음 |
| 알파 | 계획한 주요 기능이 모두 들어가 있고, 큰 흐름이 끊기지 않음 |
| 베타 | 실제 그래픽과 사운드가 들어가고, 새 기능 추가를 멈추고 수정에 집중함 |
| 최종 빌드 | 알려진 큰 버그가 해결되고, 제출이나 공개용 빌드가 만들어짐 |
학교 과제나 공모전처럼 마감일이 정해져 있다면, 마감일에서 거꾸로 날짜를 배치합니다. 최종 빌드 이전에 베타 기간을 충분히 두고, 그 앞에 알파와 프로토타입을 놓는 식입니다. 전체 기간이 짧다면 알파와 베타를 하나로 합쳐도 되지만, 프로토타입 지점은 꼭 따로 두는 것이 좋습니다.
작업을 며칠 단위로 쪼개는 순서
- 마일스톤마다 필요한 기능과 리소스를 모두 적습니다.
- 각 항목을 하루에서 며칠 안에 끝낼 수 있는 크기로 나눕니다. '전투 시스템'이 아니라 '근접 공격 판정', '피격 애니메이션 연결'처럼 씁니다.
- 작업마다 담당자와 예상 기간을 적습니다.
- 다른 작업이 끝나야 시작할 수 있는 작업에는 선행 작업을 표시합니다.
- 모든 작업을 날짜 위에 배치하고, 한 사람에게 일이 몰린 구간이 없는지 확인합니다.
작업을 잘게 쪼개는 이유는 추정의 정확도 때문입니다. '전투 시스템 만들기'에 몇 주가 걸릴지는 누구도 정확히 알기 어렵습니다. 하지만 '근접 공격 판정'이 며칠 걸릴지는 비교적 쉽게 감이 옵니다. 작은 작업의 추정치를 더해 큰 기능의 기간을 계산하면 훨씬 현실적인 일정이 나옵니다. 작업 크기가 일주일을 넘는다면 한 번 더 쪼갤 수 있는지 살펴보세요.
여유 기간과 선행 작업을 꼭 반영하기
처음 일정표를 만들면 모든 작업이 계획대로 끝난다는 가정으로 빈틈없이 채우기 쉽습니다. 하지만 게임개발에서는 예상하지 못한 버그, 엔진 버전 문제, 아파서 쉬는 날, 다른 과제와 겹치는 주가 반드시 생깁니다. 그래서 마일스톤 사이마다 아무 작업도 배정하지 않은 여유 기간을 두는 것이 좋습니다. 이 기간은 늦어진 작업을 흡수하고, 문제가 없다면 품질을 다듬는 데 씁니다.
선행 작업 표시는 기다림을 줄여 줍니다. 아트 리소스가 늦게 나올 것 같다면, 그동안 프로그래머는 임시 도형으로 기능을 먼저 만들고 나중에 교체하는 방식으로 순서를 바꿀 수 있습니다. 일정표에 선행 관계가 보이면 이런 조정을 미리 계획할 수 있습니다. 선행 관계가 길게 이어진 작업 줄은 하나만 늦어져도 뒤가 전부 밀리므로, 그 줄에 있는 작업부터 먼저 시작하고 진행 상황을 더 자주 확인하는 것이 좋습니다.
일정이 크게 밀렸을 때 고르는 세 가지 길
여유 기간을 다 써도 일정이 크게 밀리는 경우가 있습니다. 이때 할 수 있는 선택은 대개 세 가지입니다. 기능을 줄이는 것, 마감을 늦추는 것, 사람이나 시간을 더 쓰는 것입니다. 학교 과제나 공모전처럼 마감을 늦출 수 없다면 사실상 기능을 줄이는 쪽이 현실적입니다.
기능을 줄일 때는 무엇을 뺄지 감으로 고르지 말고, 핵심 재미와의 거리를 기준으로 고릅니다. 핵심 놀이와 멀리 떨어진 부가 기능부터 빼고, 콘텐츠 양을 줄이는 쪽을 먼저 검토합니다. 스테이지를 다섯 개 만들 계획이었다면 세 개를 완성도 높게 만드는 편이 다섯 개를 어설프게 만드는 것보다 낫습니다. 결정한 내용은 일정표에 바로 반영하고, 빠진 기능은 '다음 버전' 목록으로 옮겨 두면 팀원들이 아쉬움 대신 다음 목표를 보게 됩니다.
도구는 단순하게, 점검은 매주
일정표 도구는 스프레드시트, 칸반 보드, 협업용 노트 서비스 등 무엇이든 괜찮습니다. 중요한 것은 팀원 모두가 같은 문서를 보고, 작업 상태를 쉽게 바꿀 수 있어야 한다는 점입니다. 처음부터 복잡한 프로젝트 관리 툴을 쓰기보다 '할 일, 진행 중, 완료' 세 칸짜리 보드와 날짜가 들어간 표 한 장으로 시작해도 충분합니다.
가장 중요한 것은 매주 정해진 시간에 일정표를 점검하는 것입니다. 지난주에 끝내기로 한 작업 중 무엇이 끝났고 무엇이 남았는지, 남은 이유가 무엇인지 짧게 이야기합니다. 늦어진 작업이 있다면 여유 기간에서 시간을 가져오거나, 다른 작업의 우선순위를 낮추거나, 기능 범위를 줄이는 결정을 바로 내립니다. 문제를 일찍 발견할수록 고를 수 있는 선택지가 많아집니다.
일정표를 짜고 지켜 나가는 능력은 프로그래머와 기획자 모두에게 실무에서 크게 평가받는 역량입니다. 팀 프로젝트를 앞두고 일정 관리 방법이 막막하다면, SBS아카데미게임학원 PROJECT MANAGEMENT 과정 상담에서 프로젝트 기간과 팀 구성을 알려 주시고 마일스톤 초안부터 같이 그려 보세요.
자주 묻는 질문
혼자 만드는 게임에도 일정표가 필요한가요?
필요합니다. 혼자일수록 하고 싶은 작업만 하다 마감을 놓치기 쉽습니다. 마일스톤과 주간 점검만 있어도 진행 상황을 객관적으로 볼 수 있습니다.
예상 기간을 자꾸 틀리는데 어떻게 하면 좋을까요?
작업이 끝날 때마다 예상과 실제 기간을 함께 기록해 보세요. 몇 번만 쌓여도 내가 어떤 종류의 작업을 얼마나 짧게 잡는 경향이 있는지 알 수 있습니다.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.