게임기획자는 "이 게임이 왜 재미있는가"를 문서로 증명하는 사람입니다. 아이디어가 아무리 좋아도 프로그래머와 그래픽 팀이 읽고 바로 작업할 수 있는 문서가 아…
문서 맨 앞에 목적과 기대 효과가 없다
초보 기획서는 바로 기능 설명으로 시작하는 경우가 많습니다. '출석 보상 시스템: 매일 접속하면 보상을 준다'처럼요. 그런데 이 시스템이 왜 필요한지, 어떤 유저의 어떤 행동을 바꾸고 싶은지가 빠지면 읽는 사람은 판단 기준을 잃습니다. 개발 중에 세부 사항을 결정해야 할 때 기준이 없으니 매번 기획자에게 물어봐야 합니다.
문서 첫 부분에 목적을 두세 줄로 적으세요. 예를 들어 '접속이 끊기기 쉬운 초반 유저가 일주일 동안 꾸준히 들어오게 만든다'처럼 대상과 바꾸고 싶은 행동을 함께 씁니다. 목적이 분명하면 보상 구성이나 UI 위치를 정할 때 팀원 스스로 판단할 수 있습니다. 포트폴리오용 기획서에서도 목적이 있는 문서는 생각의 깊이가 드러나 평가가 달라집니다.
용어와 규칙이 문서 안에서 흔들린다
같은 대상을 문서 앞에서는 '재화', 중간에서는 '골드', 뒤에서는 '코인'으로 부르는 일이 흔합니다. 쓰는 사람은 같은 뜻이라고 생각하지만, 읽는 사람은 세 가지가 다른 것인지 헷갈립니다. 특히 프로그래머는 이름이 다르면 다른 데이터로 만들 수도 있습니다.
기획서 앞쪽에 용어 정의 표를 넣어 두면 이 문제가 사라집니다. 용어, 뜻, 비슷한 말과의 차이를 짧게 적고, 문서 전체에서 정의한 이름만 씁니다. 다 쓴 뒤에는 문서 검색 기능으로 정의하지 않은 표현이 섞여 있지 않은지 확인합니다. 작은 습관이지만 협업 문서의 신뢰도를 크게 올려 줍니다. 규칙도 마찬가지입니다. '하루'가 자정 기준인지 서버 점검 시각 기준인지처럼 해석이 갈릴 수 있는 말은 처음 나올 때 정확히 정해 둡니다.
정상 흐름만 있고 예외 처리가 없다
가장 많이 빠지는 항목이 예외 처리입니다. 유저가 정상적으로 버튼을 누르고 보상을 받는 흐름만 적어 두면, 실제 개발에서는 질문이 쏟아집니다. 예외 상황을 정하지 않으면 개발자가 임의로 처리하게 되고, 그 결과가 기획 의도와 다를 수 있습니다.
- 보상을 받는 순간 인터넷 연결이 끊기면 어떻게 되는가
- 가방이 가득 찬 상태에서 아이템 보상을 받으면 어디로 가는가
- 날짜가 바뀌는 시각에 접속해 있으면 어느 날로 계산하는가
- 이벤트 기간이 끝난 뒤 남은 재화는 어떻게 처리하는가
- 같은 버튼을 빠르게 여러 번 누르면 중복 지급되지 않는가
이런 질문을 스스로 던지는 습관을 들이면 기획서의 완성도가 눈에 띄게 올라갑니다. 다 정하기 어렵다면 '확인 필요' 항목으로 표시만 해 두어도, 빠뜨린 것과 아직 정하지 않은 것을 구분할 수 있습니다.
숫자와 데이터가 어디서 정해지는지 적혀 있지 않다
'보상을 적당히 준다', '쿨타임은 짧게'처럼 숫자 없이 쓰면 만드는 사람이 대신 결정해야 합니다. 그렇다고 처음부터 모든 수치를 확정할 필요는 없습니다. 중요한 것은 어떤 값이 필요한지, 그 값을 어디서 관리하는지를 적는 것입니다.
예를 들어 보상 개수, 지급 조건, 표시 순서를 데이터 테이블 항목으로 정리하고 '수치는 밸런스 시트에서 관리'라고 연결해 둡니다. 데이터 테이블은 게임이 읽어 들이는 표 형식의 설정 파일이라고 생각하면 쉽습니다. 이렇게 해 두면 수치를 바꿀 때 코드를 고치지 않고 표만 바꿔도 되도록 구조를 잡을 수 있습니다. 기획서와 시트 사이의 연결이 보이면 실무를 이해하는 기획자라는 인상을 줍니다.
화면 흐름과 필요한 리소스 목록이 비어 있다
기능 설명은 충분한데 화면이 어떻게 이어지는지, 어떤 그림과 소리가 필요한지 빠져 있는 경우도 많습니다. 아티스트와 사운드 담당자는 이 목록을 보고 작업량을 계산합니다. 목록이 없으면 개발 막바지에 '이 아이콘은 누가 만들죠?' 같은 질문이 나옵니다. 화면 흐름은 손으로 그린 상자 그림이어도 괜찮습니다. 중요한 것은 모든 화면에서 뒤로 가는 길이 있는지, 막다른 화면이 없는지가 보이는 것입니다. 팝업 문구 초안도 미리 써 두면 화면 크기 안에 글이 들어가는지 일찍 확인할 수 있습니다.
| 빠뜨리기 쉬운 항목 | 넣는 방법 |
|---|---|
| 화면 흐름 | 어느 화면에서 어떤 버튼으로 어디로 가는지 상자와 화살표로 그리기 |
| UI 요소 | 버튼, 팝업, 알림 표시의 위치와 상태(활성, 비활성) 정리 |
| 그래픽 리소스 | 아이콘, 일러스트, 이펙트를 이름과 용도로 목록화 |
| 사운드 | 버튼음, 획득음 등 필요한 소리와 재생 시점 |
| 텍스트 | 팝업 문구, 안내 문구 초안과 글자 수 고려 |
변경 이력과 우선순위가 없어 문서가 낡는다
기획서는 한 번 쓰고 끝나는 문서가 아닙니다. 회의를 거치며 계속 바뀌는데, 무엇이 언제 왜 바뀌었는지 적지 않으면 팀원마다 다른 버전을 기준으로 일하게 됩니다. 문서 맨 위에 날짜, 바뀐 내용, 바꾼 이유를 짧게 남기는 변경 이력 칸을 만드세요.
기능마다 우선순위를 표시하는 것도 중요합니다. 꼭 있어야 하는 기능과 시간이 남으면 넣을 기능을 구분해 두면, 일정이 부족할 때 무엇을 줄일지 빠르게 정할 수 있습니다. 우선순위는 상, 중, 하처럼 간단한 표시로도 충분합니다. 다만 모든 기능을 '상'으로 표시하면 의미가 없으니, 목적과 직접 연결된 기능만 높게 둡니다.처음 쓴 기획서를 이 항목들로 다시 점검해 보면 빈칸이 꽤 보일 것입니다. 내 기획서에서 무엇이 빠졌는지 다른 사람의 눈으로 확인받고 싶다면, SBS아카데미게임학원 게임기획 과정 상담에서 직접 쓴 문서를 가져와 보완할 부분을 함께 짚어 보세요.
자주 묻는 질문
기획서는 워드와 파워포인트 중 무엇으로 써야 하나요?
회사와 팀마다 다릅니다. 시스템 설명은 문서형, 화면 흐름 설명은 슬라이드형이 편한 경우가 많으니 내용에 맞춰 고르고, 지원처 양식이 있으면 그것을 따릅니다.
포트폴리오용 기획서에도 예외 처리를 다 써야 하나요?
모든 경우를 다 쓸 필요는 없지만, 핵심 기능의 주요 예외는 꼭 넣는 편이 좋습니다. 예외 처리가 있는지 여부로 실무 감각을 판단하는 경우가 많습니다.
가까운 캠퍼스에서 게임기획 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.