라이브 서비스 게임이 많아지면서 기획자는 출시 이후에도 숫자를 보고 판단하는 일이 늘었습니다. 이용자가 어느 구간에서 이탈하는지, 어떤 아이템이 많이 팔리는지…
문서가 많은 이유는 읽는 사람이 다르기 때문이다
게임 하나를 만들 때 기획자가 전달해야 하는 상대는 다양합니다. 투자자나 경영진은 이 게임이 무엇이고 왜 만들 가치가 있는지 알고 싶어 합니다. 프로그래머는 기능이 어떤 규칙으로 동작하는지, 아티스트는 어떤 화면과 리소스가 필요한지, QA는 무엇을 어떻게 시험해야 하는지 궁금해합니다. 한 문서에 이 모든 내용을 담으면 누구도 원하는 정보를 빨리 찾지 못합니다.
그래서 기획 문서는 읽는 사람과 목적에 따라 나뉩니다. 같은 전투 시스템이라도 경영진에게는 한 장짜리 요약으로, 프로그래머에게는 규칙과 예외 처리가 자세히 적힌 사양서로, 데이터 담당에게는 수치가 정리된 표로 전달됩니다. 문서의 종류를 외우기보다 '이 문서는 누구를 위한 것인가'를 먼저 생각하면 어떤 형식으로 써야 할지도 자연스럽게 정해집니다.
기획 문서의 일곱 가지 묶음
| 묶음 | 주로 읽는 사람 | 담는 내용 |
|---|---|---|
| 컨셉·제안 문서 | 경영진, 팀 전체 | 게임의 핵심 재미, 장르, 목표 유저, 차별점 |
| 시스템 기획서 | 프로그래머, QA | 기능의 목적, 규칙, 화면 흐름, 예외 처리 |
| 콘텐츠 기획서 | 레벨·아트 담당, 시나리오 작가 | 퀘스트, 던전, 몬스터, 세계관과 시나리오 |
| 데이터 테이블 | 프로그래머, 밸런스 담당 | 아이템, 스킬, 보상, 성장 수치를 정리한 표 |
| UI 화면 설계서 | UI 디자이너, 프로그래머 | 화면 배치, 버튼 동작, 화면 간 이동 흐름 |
| 운영 문서 | 운영·사업 담당, 커뮤니티 담당 | 이벤트 기획, 업데이트 내용, 공지 초안 |
| 관리 문서 | 팀 전체 | 회의록, 변경 이력, 작업 목록 |
각 묶음 안에도 여러 문서가 있습니다. 예를 들어 시스템 기획서만 해도 전투, 성장, 인벤토리, 상점, 친구, 우편처럼 기능마다 따로 쓰는 경우가 많습니다. 큰 게임이라면 시스템 기획서만 수십 개가 되기도 합니다. 그래서 '몇 종류냐'보다 '어떤 묶음이 있고 내가 주로 무엇을 쓰게 될까'를 아는 것이 더 실용적입니다. 문서끼리는 서로 연결되어 있다는 점도 기억해 두세요. 컨셉 문서에서 정한 핵심 재미가 시스템 기획서의 목적이 되고, 시스템 기획서에 적힌 규칙이 데이터 테이블의 열이 되며, 데이터 테이블의 값이 운영 문서의 이벤트 보상으로 이어집니다. 한 문서를 고치면 연결된 문서도 함께 확인해야 하는 이유입니다. 그래서 많은 팀이 문서마다 관련 문서의 위치를 맨 위에 적어 두고, 어떤 문서가 기준인지 정해 둡니다.
가장 많이 쓰는 것은 시스템 기획서와 데이터 테이블
실무 기획자가 일상적으로 가장 많은 시간을 쓰는 문서는 시스템 기획서와 데이터 테이블입니다. 시스템 기획서는 기능 하나가 어떻게 동작하는지를 개발자가 그대로 구현할 수 있을 만큼 구체적으로 적은 문서입니다. 기능의 목적, 사용 흐름, 화면 구성, 규칙, 예외 상황, 필요한 데이터가 순서대로 들어갑니다.
데이터 테이블은 주로 엑셀 같은 스프레드시트로 작성합니다. 아이템의 이름과 능력치, 스킬의 피해량과 재사용 시간, 단계별 보상량처럼 게임에 들어갈 수치를 행과 열로 정리합니다. 이 표는 그대로 게임에 불러와 쓰이는 경우가 많아서 작은 오타 하나가 버그로 이어집니다. 그래서 열 이름과 데이터 형식을 정확히 지키고, 수정할 때는 변경 이력을 남기는 습관이 중요합니다. 기획자 채용 공고에 엑셀 활용 능력이 자주 등장하는 이유이기도 합니다.
회사 규모와 직무에 따라 쓰는 문서가 달라진다
작은 팀에서는 기획자 한 명이 컨셉부터 시스템, 콘텐츠, 데이터, UI 문서까지 모두 쓰기도 합니다. 반면 큰 프로젝트에서는 기획 직무가 나뉘어 있어 자기 분야의 문서를 깊게 씁니다. 시스템 기획자는 기능 사양서를, 레벨 디자이너는 맵 구성과 동선 문서를, 밸런스 기획자는 수치 설계 문서와 계산 시트를, 시나리오 기획자는 세계관 설정과 대사 문서를 주로 다룹니다.
출시 후 라이브 서비스 단계에 들어가면 운영 문서의 비중이 커집니다. 이벤트 기획서, 업데이트 내용 정리, 공지 초안, 문제 발생 시 보상 기준 같은 문서가 꾸준히 만들어집니다. 개발 단계에서 쓰는 문서와 성격이 달라서, 지원하는 회사가 신작 개발 중인지 라이브 서비스 중인지에 따라 포트폴리오에 넣을 문서도 조금씩 달라집니다.
포트폴리오에는 어떤 문서를 넣어야 할까
신입 기획자 포트폴리오에 모든 종류의 문서를 넣을 필요는 없습니다. 오히려 지원하는 직무와 맞는 문서를 깊이 있게 보여 주는 편이 좋습니다. 기본적으로는 짧은 컨셉 문서 하나, 직접 설계한 기능의 시스템 기획서 하나, 그 기능에 쓰이는 데이터 테이블을 묶어 보여 주는 구성이 무난합니다. 세 문서가 서로 연결되어 있으면 '아이디어를 실제 개발 문서로 옮길 수 있는 사람'이라는 인상을 줍니다.
- 컨셉 문서는 짧고 분명하게, 핵심 재미와 목표 유저가 한눈에 보이도록
- 시스템 기획서는 예외 처리와 화면 흐름까지 빠짐없이
- 데이터 테이블은 실제 게임에 넣을 수 있는 형식으로
- 지원 직무가 정해져 있다면 그 직무의 문서를 하나 더 추가
어떤 문서를 얼마나 자세히 써야 할지는 직접 써 보고 피드백을 받으며 감을 잡는 수밖에 없습니다. 시스템 기획서를 써 봤는데 이게 개발자가 읽을 수 있는 수준인지 확신이 없다면, SBS아카데미게임학원 SYSTEM DESIGN 과정 상담 때 초안을 보여 주세요. 개발자 입장에서 읽다가 멈추게 될 대목이 어디인지부터 짚어 드립니다.
자주 묻는 질문
기획서는 꼭 정해진 양식으로 써야 하나요?
회사마다 양식이 있지만 내용의 순서는 비슷합니다. 포트폴리오에서는 목적, 흐름, 규칙, 예외, 데이터가 빠짐없이 들어 있다면 자기만의 양식으로 써도 괜찮습니다.
문서 작성에 주로 어떤 툴을 쓰나요?
문서는 워드나 협업용 문서 도구, 데이터는 엑셀 같은 스프레드시트, 화면 설계는 피그마 같은 디자인 툴을 많이 씁니다. 툴보다는 읽는 사람이 이해하기 쉬운 구성이 더 중요합니다.
가까운 캠퍼스에서 게임기획 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.