게임 기획서 작성법: ‘빈 페이지에서 시작하는 게임의 탄생’

게임 기획서 작성법: '빈 페이지에서 시작하는 게임의 탄생'

나는 신입 시절 처음으로 상업용 게임을 기획하려다 3개월간 기획서만 작성하다가 중도 포기한 경험이 있다. 당시에는 “게임 기획서란”이라는 것의 기준조차 알 수 없었다. 프로그래밍 도구는 정해져 있고 그래픽도 튜토리얼이 산더미처럼 있지만, 기획은 어디에든 도움도 없으며 표준도 없었다. 창피하긴 하지만, 지금 생각하면 그 자체만으로도 게임 개발자의 첫걸음이었다.

원론적으로 게임 기획서란, 게임의 ‘본질적 구성요소’를 어떻게 구조화할지 결정하고 이를 문서로 남기는 과정이다. 그러나 실전에서는 “정확히 어떤 요소를 정의하면 좋을까?”라는 질문에 답하기가 어렵다. 이 글에서는 실질적인 접근법부터 표준화된 프레임워크 구축 방법까지, 20년 동안 현장에서 부딪히며 정리한 구체적인 단계를 설명하겠다.

”빈 페이지에 게임을 만들 수 있나?”

과거에는 예제 코드나 튜토리얼 없이 게임을 만드는 게 불가능해 보였다. 그러나 실은 기존 게임을 ‘수정’하여 시작하는 것이 가장 효율적인 방법이다. 이는 마치 ‘레고 블록을 조립해 본 뒤, 새 블록을 만든다’는 개념과 같다.

내가 2016년 게임 기획을 처음 배울 때, 쯔꾸르(RPG Maker) 시리즈나 스팀의 ‘Mod 지원 게임’(스타크래프트, 도타2 등)을 통해 이런 과정을 거쳤다. 예를 들어, 스타크래프트를 열고 ‘오버마인드’를 없애고 ‘자유 도시를 만들기’ 시작한 것이다. 이때 가장 중요한 세 가지 원칙이 있었다:

플레이 가능한 예제를 충분히 분석한다. (예: ‘도타2의 NPC는 어떤 트리거로 공격할까?’)
소규모 변형을 통해 규칙을 발견한다. (예: ‘적 유닛의 HP가 100으로 고정되면 어떻게 변할까?’)
기획서의 ‘표준’을 자신의 게임에 맞게 정의한다. (예: ‘우리의 게임에서는 AI 유닛 대신 플레이어에게 임무를 내릴 것’)

실제 사례: ‘포항의 마물사냥대’ 기획시도 2017년, 친구와 함께 ‘한국전통마물사냥’을 테마로 게임을 기획했다. 당시 기존 게임의 ‘틀’은 물론 없었다. 그래서 다음과 같이 진행했다:

첫 번째 단계: ‘마물사냥 게임의 예시’를 찾았다. → 인디게임 ‘The Forest’와 ‘Slay the Spire’를 참작했다.
두 번째 단계: ‘오브젝트 시스템’을 정의했다. → “마물”은 공격력/방어력+추가 스킬을 갖도록 했다.
세 번째 단계: ‘공통적 패턴’을 발견했다. → 대부분의 게임에서 ‘스킬 사용’은 “트리거(조건) → 이벤트(행동)을 정의”하는 방식을 사용했다.

이 과정에서 중요한 시사점은 기획서를 작성하되, ‘완벽한 문서’를 만들려는 것이 아니라 ‘개발 가능성’을 높이는 것이다. 나의 첫 기획서는 ‘캐릭터 대사’보다 ‘스탯 시트’와 ‘플레이버 텍스트’라는 개념을 먼저 정의했다.

‘게임의 공통 구조’: 4가지 핵심 요소와 어떻게 적용하느냐

기존 게임을 분석하다 보면, ‘공통적으로 등장하는 요소’가 있다. 그러나 이 요소를 ‘표준화된 프레임워크’로 만들지 않으면 기획서가 혼돈에 빠진다. 내가 2020년 개발한 ‘신비한 동굴 탐험’ 프로젝트에서 시도했던 4가지 구성요소를 소개한다:

오브젝트(Unit) 분류
- 플레이어: 동굴 탐험가 (조작 가능, HP/체력 시스템)
- 적(NPC): ‘구슬광대’, ‘수수께끼의 늑대’ (공격 패턴이 고정되지 않음)
- 아이템: ‘불꽃의 조개’, ‘고스트 랜턴’ (사용 시 효과가 스크립트화)
- 환경 오브젝트: ‘부서진 문’, ‘미로의 기둥’ (플레이어 상호작용 가능)
예시: ‘도타2의 아이템 시스템’에서 영감을 받아, ‘고스트 랜턴’은 “적에게 3회 공격 후 사라지는 버프”를 제공하도록 했다. 이때 중요한 점은 ‘오브젝트의 속성은 게임의 ‘목표’에 맞게 정의돼야 한다는 사실이다.
속성치(Attribute)의 정의
- 각 오브젝트는 ‘기본 속성’과 ‘추가 효과’를 가진다.
  - 기본: HP(100), 공격력(15) → 모든 게임에 통용됨.
  - 추가: ‘정신력’, ‘운’ (내 게임에만 적용될 수 있음)
- 문제발생: 처음엔 ‘수수께끼의 늑대’에게 ‘공격력 30’을 주었지만, 플레이어에게 너무 강하다는 피드백을 받아 ‘공격력 20 + 숨은 약점’으로 조절했다.
이벤트 트리거의 스크립트화
- 게임에서 일어나는 모든 일은 ‘조건 → 행동’의 형태로 정의된다.
  - 예: “플레이어가 ‘미로의 기둥’에 도착하면 → 이벤트 발생 (고스트 랜턴의 등불이 켜짐)”
- 실패한 사례: 처음엔 ‘수수께끼의 늑대가 등장했을 때 10초 후에 공격’으로 설정했지만, 플레이어에게 공격적인 기분이 들기에 ‘호기심 유발’을 위해 5초로 단축했다.
게임의 ‘룰 시스템’
- 모든 게임에는 ‘플레이어에게 어떤 선택지가 주어진다’는 것이 핵심이다.
  - 내 게임에서는 ‘동굴의 문’에서 다음 두 가지 선택지를 주었다:
    1. ‘문을 강제로 열기’ (10% 확률로 함정 발생)
    2. ‘고스트 랜턴을 사용’ (함정을 회피할 수 있음)
- 조언: 이 선택지는 ‘게임의 ‘핵심 conflict’를 반영해야 한다. 예를 들어, ‘수수께끼의 늑대’와의 대결에서는 “공격 vs 회피”라는 선택지가 필수적이다.

주의점: 이 요소들은 ‘공통적’일 뿐, ‘표준’은 없다. 따라서 기획서를 작성할 때는 ‘내 게임에 가장 중요한 요소’를 먼저 정의해야 한다. 예를 들어, ‘포션 RPG’라면 아이템의 속성이 중요하지만, ‘내러티브 어드벤처’라면 대사 트리거가 중요하다.

‘기획서의 표준’을 만드는 법: 공략본 분석에서 시작하다

게임 개발자들에게 가장 유용한 자료는 공략본이다. 그러나 대부분의 개발자가 공략본을 단순히 ‘스포일러’로 여긴다. 하지만 공략본은 ‘기획자의 생각과 유저의 상호작용’을 분석할 수 있는 최적의 자료다.

1 공략본의 ‘오브젝트 분석’ 방법

공략본을 읽다 보면, ‘게임의 모든 요소’를 체계적으로 분류한 것이 드러난다. 예를 들어, ‘파이널 판타지’ 시리즈의 공략본(Ultimania 시리즈)은 다음과 같이 구성되어 있다:

카테고리	구성요소	예시 (FF14)
기본 정보	이름, 아이템 레벨	’드래곤 슬레이어’ (공격력 +15%)
속성치	공격, 방어, HP	’스피드 80 / 마나 60’
스킬 효과	조건 & 이벤트	’파이어 3’ → 3초 후 불꽃 범위 공격
보스 패턴	이벤트 시퀀스	’드래곤의 날개 공격 → 회피 가능’

내 게임에 적용한 예시: 2021년, ‘신비한 동굴 탐험’ 기획서 작성 때 유명 게임들의 공략본을 분석했다. 이때 ‘공격력/방어력’ 외에도 위치 감지 스킬(예: 적이 플레이어의 위치를 감지하여 추적하는 패턴)을 추가하기도 했다.

2 공략본에서 ‘시나리오’를 분석하는 법

게임의 ‘목표’는 ‘플레이어가 무엇과 대결해야 하는가’를 정의한다. 공략본은 이 대결의 ‘흐름’을 상세히 설명한다.

분석 예시: ‘파이널 판타지 14’의 레이드 보스 ‘바하무트’

공략본의 내용: “바하무트는 5단계 공격 패턴을 갖고 있다. 1단계에서는 ‘필드에 얼음 장판’을 생성한다.”
기획자의 관점에서:
- ‘장판’은 ‘플레이어의 선택을 강제한다 → “얼음 장판을 피할지, 또는 얼어붙은 적을 공격할지?”’
- ‘5단계 공격 패턴’은 ‘조건 분기’를 의미한다 → “적의 HP에 따라 공격 방식이 변화한다.”

내 게임 ‘신비한 동굴 탐험’에서도 ‘수수께끼의 늑대’는 3단계 공격 패턴을 갖도록 정의했다:

순찰 모드: 플레이어를 감지하지 않으면 천천히 이동한다.
감지 모드: 랜턴의 빛을 감지하면 ‘정신력’이 10% 감소한다.
공격 모드: ‘고스트 랜턴’을 사용하지 않으면 10초 후에 공격한다.

중요한 통찰: 공략본은 ‘게임의 너비’를 측정하는 도구다. 예를 들어, ‘도타2’의 공략 위키는 ‘영웅’마다 ‘스킬 조합’, ‘아이템 빌드’, ‘상성 관계’를 상세히 설명하고 있다. 이를 통해 ‘게임의 진입 장벽’과 ‘유저 상호작용’을 분석할 수 있다.

3 ‘국내 공략본’은 어떻게 활용하나?

국내에는 일본보다 늦게 공략본 시장이 발달했지만, ‘품질 높은 분석 자료’가 많이 존재한다. 예를 들어:

‘몬스터 헌터: 월드’의 한국 공략본 → ‘무기의 특성’과 ‘적의 약점’을 상세히 분류했다.
‘오버워치’ 한국 공략본 → ‘영웅의 스킬 조합’을 ‘조건 트리’로 정리했다.

내게 유용한 공략본 활용법:

‘오브젝트 목록’을 추출 → ‘적 이름 / 속성치 / 스킬 효과’를 표로 만든다.
‘플레이 가능성’을 분석 → ‘특정 아이템을 얻기 위해 필요한 조건’은 무엇인가?
‘시나리오의 흐름’을 추적 → ‘보스전’은 어떤 ‘이벤트 체이닝’으로 구성되어 있는가?

실패 사례: 처음엔 ‘전설의 영웅담’ 공략본을 분석했지만, ‘대사 트리’를 생략해서 ‘캐릭터의 의도’를 파악하지 못했다. 이후 ‘대사 시나리오’도 표로 작성하게 되었다.

‘기획서의 표준’을 만드는 5단계 프레임워크

기획서를 작성할 때 ‘표준’이 없음에도, ‘개발 가능성’을 높이는 방법을 소개한다. 이는 나의 개발 프로젝트를 통해 실제로 적용한 프레임워크다.

1 게임의 ‘핵심 conflict’를 정의한다.

모든 게임은 ‘플레이어 vs 무엇인가’의 대결을 기반으로 한다.

예시:
- ‘Overwatch’ → ‘아군 팀 vs 상대 팀’
- ‘The Legend of Zelda’ → ‘링크 vs 보스/환경’
- 내 게임 ‘신비한 동굴 탐험’ → ‘플레이어 vs 수수께끼의 늑대 & 동굴의 함정’

작업 방법:

‘게임의 테마’를 1문장으로 정의 → “한적한 마을에서 마물이 등장하여, ‘마을을 구하려 한다.’”
‘대립하는 요소’를 나열 → “마물(적) / 마을 사람(플레이어의 동맹) / 동굴의 함정(환경)”
‘플레이어가 어떤 선택을 강제받는가’를 명시 → “마물의 공격 패턴에 취약할지, 아니면 동맹을 통해 역공할지?“

2 오브젝트 시트의 표준을 만든다.

게임의 모든 요소는 ‘오브젝트’로 표현된다. 표준화된 시트를 만드는 것이 중요하다.

오브젝트 유형	필수 속성 (예시)	추가 속성 (선택)
플레이어	HP(100), 공격력(15)	‘정신력’, ‘운’
적(NPC)	HP(80), ‘공격 패턴’ (회전 공격)	‘약점 스킬’, ‘대화 트리’
아이템	사용 횟수(3), 효과(HP +20)	‘사용 조건’ (예: ‘수수께끼의 늑대’만)
환경 오브젝트	상호작용 가능 여부 (Yes/No)	‘함정 확률’ (10%)

예시: 내 게임에서 ‘고스트 랜턴’은 다음의 속성을 갖도록 정의했다:

기본: 사용 횟수(2), 효과 (적에게 10의 데미지)
추가: ‘수수께끼의 늑대’만 효과를 받음 → “플레이어에게 ‘특수한 선택’을 강제한다.”

3 이벤트 트리거를 스크립트화 한다.

게임의 모든 행동은 ‘조건 → 행동’으로 정의된다.

표준화된 스크립트 예시:

[조건] : 플레이어가 '미로의 기둥'에 접촉하면
[행동 1] : 이벤트 '고스트 랜턴의 빛이 켜짐'
[행동 2] : 수수께끼의 늑대가 '공격 패턴을 변경' (정신력이 20% 감소)

실제 적용 예: 내 게임의 ‘수수께끼의 늑대’는 다음의 트리거를 갖도록 했다:

“플레이어가 ‘고스트 랜턴’ 사용 시 → 공격 패턴이 ‘회피’로 변함”
“플레이어가 ‘미로의 기둥’을 통과하지 못하면 → ‘함정’이 발동”

4 게임의 ‘룰 시스템’을 정의한다.

게임에서 ‘플레이어가 어떤 선택을 할 수 있는가’ 를 명시해야 한다.

예시: 내 게임에서는 다음의 ‘룰 시스템’을 적용했다:

‘동굴 탐험’: 3개의 문이 있는데, 각 문은 다른 보상을 제공한다.
‘약점 시스템’: ‘수수께끼의 늑대’는 ‘고스트 랜턴’으로만 공격할 수 있다.
‘진급 조건’: 플레이어가 ‘3개의 비밀을 찾으면’, 새로운 무기 ‘검은 송곳니’를 획득한다.

5 기획서를 ‘개발 가능성’으로 완성시킨다.

마지막 단계는 ‘기획서가 개발할 수 있는 도구’가 되도록 만든다.

작업 방법:

‘오브젝트 시트’와 ‘이벤트 트리거’를 엑셀/구글 시트에 작성 → 개발자가 쉽게 참조할 수 있게 한다.
‘시나리오 대사’를 ‘분기 트리’로 정리 → 예: “수수께끼의 늑대가 플레이어를 공격할 때, ‘공격’ vs ‘회피’를 선택할 수 있다.”
‘테스트 가능한 프로토타입’을 만든다 → 예를 들어, ‘쯔꾸르’로 ‘미니게임’을 제작하여 ‘오브젝트 시스템’이 작동하는지 확인한다.

내 게임에서 적용한 예:

프로토타입 1: ‘동굴 탐험’ 시스템만 제작 → 플레이어가 ‘미로의 기둥’을 통과하는지 확인.
프로토타입 2: ‘수수께끼의 늑대’와 ‘고스트 랜턴’의 상호작용을 테스트 → ‘공격 패턴’이 제대로 적용되는지 확인.

핵심 정리: 게임 기획서의 ‘표준’은 없다. 그러나 개발 가능성을 만드는 프레임워크는 있다.

기존 게임을 ‘분해’하여 공통 패턴을 발견 → ‘오브젝트’, ‘속성치’, ‘이벤트 트리거’를 분석한다.
공략본은 ‘기획자의 사고방식’을 분석하는 최적의 자료 → ‘오브젝트의 속성’, ‘시나리오의 흐름’을 상세히 연구한다.
‘표준화된 프레임워크’는 ‘개발 가능성’을 높이는 도구 → 오브젝트 시트, 이벤트 트리거, 룰 시스템을 표준화한다.
프로토타입을 통해 ‘기획서의 유효성’을 확인 → ‘짓고, 테스트하고, 수정’하는 과정을 반복한다.
기획서의 목적은 ‘게임 개발’이지, ‘완벽한 문서’가 아니다 → “개발자가 이해할 수 있으면서, 유저에게 재미를 줄 수 있는 구조”로 만든다.

마치며: “게임 기획서는 ‘완벽한 문서’가 아니라 ‘개발자의 길잡이’다”

나는 2017년 첫 기획서를 작성할 때, ‘완벽한 문서’를 만들려다 시간만 낭비했다. 그러나 2021년 ‘신비한 동굴 탐험’ 프로젝트를 통해 ‘프레임워크’를 통해 기획서를 개발 도구로 사용하는 법을 배웠다.

이제 당신도 ‘공략본 분석’과 ‘프로토타입 제작’을 통해 기획서의 ‘표준’을 만들 수 있다. 그러나 중요한 것은, ‘기획서는 게임을 위한 것이지, 게임이 기획서 위한 것이 아님’을 기억해야 한다.

마지막 질문: 당신은 ‘게임 기획서’와 ‘개발 가능한 게임 구조’를 어떻게 연결하는가? 이 문제를 해결하면, 게임 개발의 첫걸음을 확실하게 내딛을 수 있다.