
기획서는 길게 쓴다고 좋은 문서가 아닙니다. 프로그래머가 읽고 질문 없이 구현할 수 있고, 그래픽 팀이 필요한 리소스 목록을 바로 뽑을 수 있어야 합니다. 수…
막혔다는 신호부터 확인하기
독학 중인 시스템 기획 지망생이 흔히 겪는 막힘에는 공통된 신호가 있습니다. 아래 항목 중 여러 개가 해당된다면, 공부를 더 하기보다 방법을 바꿔야 할 때입니다.
- 기획서를 몇 편 썼는데 어디가 부족한지 스스로 설명하지 못한다
- 기존 게임 시스템을 분석하면 기능 나열로 끝나고 '왜'가 빠진다
- 문서를 읽은 사람이 '그래서 이 경우엔 어떻게 되느냐'고 물으면 답이 막힌다
- 엑셀이나 스프레드시트로 데이터를 정리하는 단계에서 손이 멈춘다
- 포트폴리오에 넣을 문서를 고르지 못하고 계속 새로 쓰고만 있다
이런 신호는 실력이 부족해서라기보다 시스템 기획 문서가 실무에서 어떻게 쓰이는지 감이 덜 잡혔을 때 나타납니다. 시스템 기획서는 읽는 사람이 프로그래머와 다른 기획자라는 점을 기억하면 점검 방향이 보입니다.
점검 1: 규칙의 구조를 쓰고 있는가
시스템 기획은 게임 안의 규칙을 설계하는 일입니다. 강화, 인벤토리, 퀘스트, 전투 공식, 보상 지급처럼 플레이어가 반복해서 만나는 구조를 정합니다. 그런데 독학 문서에서는 '강화하면 아이템이 강해진다'처럼 결과만 적힌 경우가 많습니다.
실무 문서에는 조건, 처리, 결과가 순서대로 있어야 합니다. 어떤 조건에서 강화 버튼이 활성화되는지, 재료는 언제 차감되는지, 실패하면 무엇이 남는지, 화면에는 무엇이 표시되는지까지 적혀 있어야 프로그래머가 구현할 수 있습니다. 내 문서를 다시 읽고 이 흐름이 빠진 곳에 표시해 보세요.
흐름을 글로만 쓰기 어렵다면 순서도로 먼저 그려 보는 것도 좋습니다. 상자와 화살표로 단계를 나누다 보면 빠진 분기가 눈에 들어옵니다. 그림을 문서 앞에 붙여 두면 읽는 사람도 전체 흐름을 빨리 파악합니다.
점검 2: 예외 상황을 다루고 있는가
시스템 기획서의 수준은 예외 처리에서 갈립니다. 인벤토리가 가득 찬 상태에서 보상을 받으면 어떻게 되는지, 강화 중에 접속이 끊기면 재료는 어떻게 되는지, 같은 버튼을 빠르게 두 번 누르면 어떻게 처리하는지 같은 질문입니다.
독학 문서는 정상적인 흐름만 다루는 경우가 많습니다. 하지만 실제 개발에서 가장 많은 질문이 나오는 곳은 예외 상황입니다. 문서마다 '이 시스템에서 일어날 수 있는 이상한 상황'을 따로 목록으로 만들어 처리 방식을 적어 보세요. 이것만 추가해도 문서의 완성도가 크게 달라집니다.
예외를 찾는 요령은 플레이어 입장에서 '일부러 이상하게 해 보기'입니다. 순서를 바꿔 누르기, 조건을 겨우 채운 상태에서 시도하기, 다른 시스템과 동시에 쓰기를 머릿속으로 시뮬레이션해 보세요. QA가 버그를 찾는 방식과 비슷해서, 이 습관이 붙으면 문서를 쓰는 단계에서 문제를 미리 막는 기획자가 됩니다.
점검 3: 데이터 테이블로 옮길 수 있는가
시스템 기획자는 문서와 함께 데이터 테이블을 다룹니다. 아이템 목록, 강화 단계별 확률과 비용, 몬스터 능력치처럼 게임에 들어갈 숫자를 표 형태로 정리합니다. 개발팀은 이 테이블을 읽어 게임에 반영합니다.
내 문서에 적힌 규칙을 테이블로 옮겨 보면 문서의 빈틈이 드러납니다. 열 이름을 정하다 보면 '이 값은 어디서 정해지지?'라는 질문이 생기고, 그 답이 문서에 없다면 보완할 부분입니다. 스프레드시트 함수 몇 가지(합계, 조건, 찾기)만 익혀도 테이블 작업이 한결 수월해집니다.
테이블을 만들 때는 키 값을 정하는 것부터 시작하세요. 아이템마다 고유 번호를 붙이고, 다른 테이블에서 그 번호로 참조하게 만드는 구조를 이해하면 실무 문서에 한 걸음 가까워집니다.
다시 짜는 독학 계획
- 이미 쓴 문서 중 하나를 골라 조건·처리·결과 흐름이 빠진 부분을 채웁니다.
- 같은 문서에 예외 상황 목록과 처리 방식을 추가합니다.
- 문서의 규칙을 데이터 테이블로 옮기고, 문서와 테이블이 서로 맞는지 확인합니다.
- 기존 게임 시스템 하나를 골라 같은 방식(흐름, 예외, 테이블)으로 역기획 문서를 씁니다.
- 완성한 문서들을 묶어 포트폴리오 초안을 만들고 다른 사람에게 읽혀 질문을 받아 봅니다.
새 문서를 계속 쓰는 것보다, 한 문서를 끝까지 다듬는 경험이 훨씬 큰 성장을 가져옵니다. 독학이 막혔다는 느낌은 사실 '고쳐 쓰는 단계'로 넘어갈 때가 되었다는 신호인 경우가 많습니다.
공부 시간도 다시 나눠 보세요. 그동안 강의나 책 읽기에 대부분의 시간을 썼다면, 이제는 절반 이상을 문서 수정과 테이블 작업에 쓰는 편이 좋습니다. 수정 전후 문서를 함께 보관해 두면 나중에 포트폴리오에서 개선 과정을 보여 주는 자료로도 쓸 수 있습니다.
혼자서 넘기 어려운 지점
위 점검을 해도 남는 문제가 있습니다. 내 문서가 실무 기준에서 어느 정도인지, 어떤 질문이 나올지는 실제 개발 경험이 있는 사람의 눈으로 봐야 알 수 있습니다. 혼자서는 '충분히 썼다'고 느끼는 부분이 다른 사람에게는 가장 모호한 부분일 수 있습니다.
그래서 독학을 이어 가더라도 문서를 읽어 줄 사람을 정기적으로 만드는 것이 좋습니다. 스터디나 커뮤니티도 방법이고, 짧은 피드백이라도 꾸준히 받는 구조를 만드는 것이 핵심입니다. 지금까지 쓴 기획서를 기준으로 어디부터 고쳐야 할지 판단이 어렵다면, SBS아카데미게임학원 게임기획 과정 상담에서 문서를 함께 보며 보완 순서를 정리해 드립니다.
자주 묻는 질문
시스템 기획자도 프로그래밍을 알아야 하나요?
코드를 직접 짤 필요는 없지만, 기본적인 로직 개념을 알면 프로그래머와 소통이 쉬워집니다. 조건문과 반복 같은 개념 정도는 이해해 두는 것이 좋습니다.
역기획서는 몇 편 정도 있어야 하나요?
편수보다 깊이가 중요합니다. 흐름, 예외, 데이터까지 갖춘 문서 몇 편이 기능만 나열한 여러 편보다 평가에 유리합니다.
기획서는 어떤 툴로 써야 하나요?
문서 도구와 스프레드시트, 순서도 도구 정도면 충분합니다. 툴보다 읽는 사람이 이해하기 쉬운 구조로 쓰는 것이 더 중요합니다.
가까운 캠퍼스에서 게임기획 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.