기획 문서와 개발 계획 만들기

기획 문서는 두꺼운 책이 아니라 작업 기준이다

게임 기획 문서는 멋진 설명서가 아니다. 개발자가 오늘 무엇을 만들지, 무엇을 만들지 않을지 판단하게 해주는 기준표다. 특히 인디게임에서는 문서가 길어질수록 관리 비용이 커진다. 혼자 개발한다면 읽지 않는 문서는 바로 버려진다. 작은 팀이라면 서로 다르게 이해한 내용을 나중에 수정하느라 시간이 사라진다.

좋은 문서는 짧지만 결정이 들어 있다. "어두운 분위기의 퍼즐 게임"이라고 쓰는 것보다 "플레이어는 한 화면 안에서 상자를 밀어 출구를 열고, 3번 안에 탈출하지 못하면 실패한다"라고 쓰는 편이 낫다. 후자는 바로 구현할 수 있고 테스트할 수 있다.

기획 문서의 목적은 세 가지다.

• 게임의 핵심 재미를 같은 문장으로 설명하게 한다.

• 기능 추가와 삭제를 판단하는 기준이 된다.

• 일정표와 작업 목록으로 바꿀 수 있어야 한다.

문서를 쓰는 이유는 기억하기 위해서가 아니다. 결정을 미루지 않기 위해서다.

AI 생성 이미지

한 장짜리 게임 디자인 문서 만들기

첫 게임이라면 거대한 게임 디자인 문서보다 한 장짜리 문서가 더 효과적이다. 이 문서는 이전에 정리한 콘셉트를 개발 작업으로 바꾸는 중간 단계다. 다음 항목만 먼저 채워도 충분하다.

예를 들어 짧은 생존 슈팅 게임이라면 이렇게 정리할 수 있다.

• 한 문장 설명: 플레이어는 좁은 방에서 몰려오는 적을 피하며 5분 동안 생존한다.

• 핵심 루프: 이동한다 → 적을 피한다 → 탄약을 아낀다 → 아이템을 줍는다 → 더 오래 버틴다.

• 조작: 이동, 조준, 발사, 대시.

• 목표: 제한 시간까지 생존한다.

• 실패 조건: 체력이 0이 된다.

• 보상 구조: 생존 시간 기록, 클리어 화면, 짧은 점수 평가.

• 제외할 것: 온라인 랭킹, 캐릭터 성장, 무기 20종, 스토리 컷신.

여기서 중요한 부분은 '제외할 것'이다. 초보 개발자는 무엇을 만들지 정하는 데 시간을 많이 쓰지만, 실제 완성은 무엇을 만들지 않을지 정할 때 가까워진다. 제외 목록은 아이디어를 버리는 쓰레기통이 아니다. 첫 출시를 지키는 울타리다.

핵심 루프를 작업 가능한 단위로 쪼개기

핵심 루프는 문장으로 끝나면 안 된다. 실제 작업 목록으로 바뀌어야 한다. "적을 피한다"라는 문장은 구현하기 어렵다. 이것을 더 작은 기능으로 나누면 다음과 같다.

• 플레이어가 방향키나 스틱 입력으로 움직인다.

• 적이 플레이어 위치를 향해 이동한다.

• 적과 플레이어가 닿으면 체력이 줄어든다.

• 체력이 0이 되면 실패 화면이 나온다.

• 실패 화면에서 다시 시작할 수 있다.

이렇게 나누면 무엇부터 만들어야 하는지 보인다. 먼저 플레이어 이동을 만들고, 그다음 적 이동을 만들고, 충돌과 실패 처리를 붙이면 된다. 아직 효과음, 애니메이션, 배경 연출은 필요 없다. 핵심 루프가 손으로 만져지는 상태가 먼저다.

기획 문서의 각 문장은 작업으로 바꿀 수 있어야 한다. 작업으로 바꿀 수 없는 문장은 너무 추상적일 가능성이 높다. "타격감이 좋다"라고 쓰지 말고 "공격 시 화면이 0.1초 흔들리고, 적이 뒤로 밀리며, 짧은 효과음이 재생된다"처럼 확인 가능한 표현으로 바꿔야 한다.

기능 목록은 우선순위로 나눈다

기획 문서가 방향을 정한다면 기능 목록은 실제 개발 순서를 정한다. 이때 모든 기능을 같은 중요도로 두면 일정이 무너진다. 기능은 최소한 세 단계로 나눈다.

여기서 기준은 "좋아 보이는가"가 아니라 "없으면 게임이 성립하지 않는가"다. 배경 음악이 없어도 게임은 플레이될 수 있다. 하지만 재시작 버튼이 없으면 테스트가 불편해지고 완성도도 떨어진다. 화려한 타이틀 화면보다 실패 후 다시 시작하는 흐름이 먼저다.

기능 목록을 만들 때는 각 항목에 예상 시간을 붙인다. 정확할 필요는 없다. 대신 너무 낙관적으로 적지 않는다.

• 플레이어 이동: 3시간

• 적 추적 이동: 4시간

• 체력과 피격 처리: 3시간

• 실패 화면과 재시작: 2시간

• 기본 사운드 적용: 3시간

• 첫 빌드 테스트: 4시간

처음에는 예상이 자주 틀린다. 괜찮다. 중요한 것은 기록을 남겨 다음 예상을 조금 더 정확하게 만드는 것이다.

마일스톤은 날짜가 아니라 검증 결과물이다

마일스톤은 "이번 주 열심히 개발" 같은 문장이 아니다. 특정 시점에 확인할 수 있는 결과물이다. 작은 첫 게임이라면 다음 정도로 충분하다.

마일스톤을 정할 때는 결과물이 반드시 실행 가능한 형태여야 한다. 문서만 완성된 상태, 코드만 많이 작성된 상태, 에셋만 모인 상태는 위험하다. 게임은 실행해서 플레이할 수 있을 때만 진척을 판단할 수 있다.

또한 마일스톤마다 검증할 질문을 하나씩 둔다. 프로토타입 단계에서는 재미를 본다. 첫 플레이 가능 버전에서는 흐름을 본다. 테스트 빌드에서는 버그와 이해도를 본다. 출시 후보에서는 안정성을 본다. 모든 단계에서 모든 것을 보려고 하면 아무것도 제대로 고치지 못한다.

작은 팀에 맞는 관리 도구 선택하기

도구는 프로젝트를 대신 완성해주지 않는다. 관리 도구를 고를 때는 기능 수보다 계속 쓸 수 있는지가 중요하다. 혼자 또는 2~5명의 작은 팀이라면 단순한 도구가 더 낫다.

가장 기본적인 선택지는 세 가지다.

• 칸반 보드: 작업을 카드로 만들고 상태를 옮기는 방식이다. "할 일", "진행 중", "검토", "완료"처럼 나눈다.

• 이슈 트래커: 버그, 개선 요청, 작업 항목을 번호로 관리한다. 버그가 많아지는 테스트 단계에 유용하다.

• 스프레드시트: 기능 목록, 일정, 예상 시간, 담당자를 표로 관리한다. 처음 시작할 때 가장 진입 장벽이 낮다.

혼자 개발한다면 스프레드시트와 간단한 칸반만으로 충분하다. 팀이 있다면 이슈 트래커를 함께 쓰는 편이 좋다. 말로만 "나중에 고치자"라고 하면 대부분 잊힌다. 버그와 수정 요청은 반드시 기록해야 한다.

칸반 보드를 쓴다면 열을 너무 많이 만들지 않는다.

• 백로그: 언젠가 할 수 있는 작업

• 이번 주 할 일: 이번 마일스톤에 필요한 작업

• 진행 중: 지금 실제로 작업 중인 항목

• 확인 필요: 구현은 했지만 테스트가 필요한 항목

• 완료: 실행해서 확인한 항목

중요한 규칙은 진행 중 항목을 제한하는 것이다. 혼자 개발한다면 동시에 1~2개만 진행한다. 작은 팀도 사람 수보다 많은 작업을 동시에 벌리지 않는다. 진행 중인 카드가 많다는 것은 바쁘다는 뜻이지, 완성에 가까워졌다는 뜻이 아니다.

일정에는 반드시 버퍼를 넣는다

개발 일정은 거의 항상 예상보다 길어진다. 이유는 단순하다. 처음에는 모르는 문제가 보이지 않기 때문이다. 엔진 오류, 빌드 실패, 저장 버그, 해상도 문제, 컨트롤 감도, 난이도 조절, 스토어 이미지 제작 같은 일은 계획표 밖에서 튀어나온다.

그래서 일정에는 버퍼를 넣어야 한다. 버퍼는 게으름을 위한 시간이 아니다. 예상하지 못한 문제를 처리하기 위한 안전 공간이다. 첫 프로젝트라면 전체 일정의 30% 정도를 버퍼로 잡는 편이 현실적이다. 개발 경험이 적거나 새로운 기술을 쓴다면 더 늘려야 한다.

예를 들어 8주짜리 프로젝트라면 실제 기능 개발은 5~6주 안에 끝낸다고 생각해야 한다. 남은 2주는 테스트, 버그 수정, 난이도 조절, 빌드, 스토어 자료 준비에 쓴다. 마지막 주까지 새 기능을 만들고 있다면 출시 준비가 늦어진다.

일정을 세울 때는 다음 순서로 계산한다.

1. 한 주에 실제로 개발 가능한 시간을 적는다.

2. 필수 기능의 예상 시간을 합친다.

3. 테스트와 수정 시간을 따로 잡는다.

4. 전체 일정의 20~30% 이상을 버퍼로 둔다.

5. 시간이 부족하면 기능을 추가하지 말고 삭제한다.

여기서 핵심은 마지막 문장이다. 일정이 부족할 때 야근이나 의지로 해결하려고 하면 품질이 무너진다. 첫 게임에서는 기능을 줄이는 판단이 가장 강력한 일정 관리다.

기능 추가보다 기능 삭제를 먼저 검토한다

개발 중에는 반드시 새 아이디어가 생긴다. 더 멋진 적, 더 많은 스테이지, 수집 요소, 성장 시스템, 멀티플레이 같은 것들이다. 아이디어가 생기는 것은 좋은 일이다. 문제는 그것을 즉시 일정 안으로 넣는 것이다.

새 기능을 넣고 싶다면 네 가지 질문을 통과해야 한다.

• 이 기능이 핵심 플레이 루프를 더 명확하게 만드는가?

• 현재 마일스톤의 목표와 직접 관련이 있는가?

• 추가하는 데 필요한 시간을 실제로 확보했는가?

• 이 기능을 넣기 위해 삭제할 기능이 있는가?

네 번째 질문이 중요하다. 일정은 빈 공간이 아니다. 새 기능을 넣으려면 기존 기능, 콘텐츠, 연출 중 하나를 줄여야 한다. 아무것도 줄이지 않고 기능만 추가하면 프로젝트는 조용히 커진다.

좋은 원칙은 "프로토타입 전에는 실험하고, 콘텐츠 잠금 이후에는 추가하지 않는다"이다. 초반에는 핵심 재미를 찾기 위해 바꿀 수 있다. 하지만 게임의 기본 구조가 정해진 뒤에는 새 기능보다 완성도를 높이는 일이 우선이다.

개발 계획 체크리스트

기획 문서와 일정표를 만들었다면 다음 질문으로 점검한다.

• 한 문장 설명만 읽어도 어떤 게임인지 이해되는가?

• 핵심 루프가 실제 조작과 규칙으로 나뉘어 있는가?

• 목표, 실패 조건, 보상 구조가 명확한가?

• 필수 기능과 보류 기능이 구분되어 있는가?

• 각 마일스톤에 실행 가능한 결과물이 있는가?

• 이번 주에 할 작업이 3~7개 정도로 좁혀져 있는가?

• 일정에 테스트와 버그 수정 시간이 따로 있는가?

• 새 기능을 넣을 때 무엇을 삭제할지 정하는 규칙이 있는가?

이 질문에 답하지 못한다면 아직 개발을 시작하지 말라는 뜻이 아니다. 대신 첫 작업을 너무 크게 잡지 말아야 한다는 뜻이다. 가장 작은 핵심 루프부터 만들고, 문서는 그 결과에 맞춰 계속 고치면 된다.

문서는 살아 있어야 하지만 흔들리면 안 된다

기획 문서는 한 번 쓰고 끝나는 계약서가 아니다. 개발하면서 바뀔 수 있다. 프로토타입을 만들어보니 조작이 재미없을 수 있고, 예상한 기능이 너무 어려울 수도 있다. 이때 문서를 수정하는 것은 자연스럽다.

다만 문서가 매일 방향을 바꾸면 개발은 앞으로 나아가지 못한다. 바꿔도 되는 것과 지켜야 하는 것을 구분해야 한다. 수치, 난이도, 스테이지 순서, 효과음 같은 것은 자주 조정할 수 있다. 하지만 핵심 루프, 플레이어 약속, 출시 범위는 쉽게 흔들면 안 된다.

첫 게임의 문서는 짧아도 된다. 대신 실제 작업과 연결되어야 한다. 오늘 만들 기능이 무엇인지 알려주고, 이번 주에 확인할 결과물이 무엇인지 보여주고, 새 아이디어가 들어왔을 때 넣을지 말지 판단하게 해주면 충분하다.

문서의 가치는 분량이 아니라 완성에 가까워지게 만드는 힘에 있다. 두꺼운 문서보다 실행 가능한 한 장, 막연한 일정표보다 삭제 기준이 있는 계획이 첫 출시를 더 가깝게 만든다.