[게임 디자인] 좋은 게임 기획서의 조건 | 신입과 주니어 기획자를 위한 메모

좋은 게임 기획서의 공통점 7가지

게임 기획자 취업 준비생과 주니어 기획자를 위한 정리

게임 기획자를 준비하다 보면 가장 자주 듣는 말 중 하나가 있다.

바로 "기획서를 잘 써야 한다”는 말이다.

 

하지만 "잘" 써야 하는 것을 누가 모르겠는가.

<쉽죠? 좋은 기획자는 기획서를 잘 쓰면 돼요>

 

 

막상 준비를 시작하면 이런 생각이 들기 쉽다.

 

<대하드라마급의 기획서>

 

“기획서는 많이 써봤는데 왜 부족하다고 할까?”
“분량도 길고 열심히 썼는데 왜 정리가 안 됐다는 피드백을 받을까?”
“좋은 기획서는 대체 뭐가 다른 걸까?”

 

특히 취업 준비생이나 주니어 기획자일수록
기획서를 쓸 때 아이디어를 많이 넣는 것에 집중하는 경우가 많다.
하지만 실제로 좋은 평가를 받는 기획서는 아이디어가 화려한 문서라기보다,
읽는 사람이 바로 이해하고 사용할 수 있는 문서인 경우가 많다.

(그래서 신입들에게는 보통 역기획서를 쓰라고한다)

 

게임 기획서는 단순한 글쓰기가 아니다.
내 생각을 정리하는 데서 끝나는 문서가 아니라,
다른 사람이 읽고 개발하고, 검토하고, 피드백할 수 있어야 하는 문서다.

 

그래서 좋은 기획서는 공통점이 있다.
이번 글에서는 게임 기획자 취업 준비생과 주니어 기획자 관점에서
좋은 게임 기획서의 공통점 7가지를 정리해보려고 한다.

 

 

---

1. 이 문서를 왜 쓰는지 목적이 분명하다

좋은 기획서는 처음부터 목적이 분명하다.

생각보다 많은 초안 문서가
“무엇을 만들고 싶은지”는 적혀 있지만, 왜 필요한 기능인지가 빠져 있는 경우가 많다.

 

예를 들어 출석 보상 시스템을 기획한다고 해보자.
그럴 때 단순히 “7일 보상을 준다”, “보상은 재화와 아이템이다”로 시작하면 기능 설명은 되지만 의도는 잘 보이지 않는다.

 

좋은 기획서는 먼저 이런 질문에 답할 수 있어야 한다.

• 이 기능은 어떤 문제를 해결하려는가?
• 유저에게 어떤 행동을 유도하려는가?
• 게임 전체 흐름에서 어떤 역할을 하는가?

예를 들면 이렇게 쓸 수 있다.

 

출석 보상 시스템의 목적은 초반 유저의 일일 접속 습관을 형성하고,
일정 기간 동안 반복 접속 동기를 제공하는 데 있다.

 

이 한 줄이 있으면 뒤의 규칙도 더 설득력 있게 읽힌다.
반대로 목적이 없으면 문서가 점점 기능 나열처럼 보이기 쉽다.

취업 준비생이나 주니어 기획자가 기획서를 쓸 때
가장 먼저 확인해야 할 건

“내가 이 기능을 왜 넣는지 설명할 수 있는가”다.

(누누히 말하는 기획서의 "의도")

 

 

---

2. 한 번 읽었을 때 구조가 바로 보인다

좋은 기획서는 읽는 사람을 헤매게 하지 않는다.

기획서를 처음 쓰는 단계에서는 머릿속에 있는 걸 최대한 많이 적으려다 보니 문서 구조가 뒤섞이기 쉽다.
배경 설명, 시스템 규칙, UI, 예외 처리, 수치가 한 문단 안에 섞여 있으면 읽는 사람은 이해하는 데 에너지를 많이 써야 한다.

 

좋은 기획서는 보통 구조가 명확하다.

 

예를 들면 이런 흐름이다.

• 기능 개요
• 목적
• 주요 이용 흐름
• 상세 규칙
• 화면 구성
• 예외 처리
• 참고 사항

이렇게 큰 단위부터 나눠주면 읽는 사람은 지금 어떤 정보를 보고 있는지 쉽게 파악할 수 있다.

특히 포트폴리오용 기획서는 현업 문서보다 더더욱 가독성이 중요하다.

면접관이나 실무자는 짧은 시간 안에 문서를 보기 때문에 읽는 데 힘이 많이 드는 문서는 좋은 인상을 주기 어렵다.

좋은 기획서는 “정보가 많은 문서”가 아니라

정보가 잘 정리된 문서다.

 

 

★ 기획서 목차 글 참고

https://okayletsgo.tistory.com/34

[게임 디자인] 게임 기획서 목차

 

 

 

 

---

3. 규칙이 구체적이고 애매하지 않다

취업 준비생이나 주니어 기획자의 문서에서 자주 보이는 아쉬운 점 중 하나는 설명이 추상적이라는 점이다.

예를 들어 이런 문장은 자주 보인다.

<용기있게 기획서 쓰는 법>

• 보상을 지급한다 (어떤 보상?)
• 강화 실패 시 불이익이 있다 (어떤 불이익?)
• 유저가 편하게 사용할 수 있도록 한다 (편하게 어떻게?)
• 특정 조건에서 추가 보상이 열린다 (특정?)

<아이디어는 내가 낼 게, 생각은 네가 해>

 

이런 표현은 방향은 보이지만,
실제로는 구현 기준으로 쓰기 어렵다.

좋은 기획서는 한 단계 더 내려가서 써준다.

예를 들어 강화 시스템이라면 이렇게 구체화해야 한다.

 

• 강화는 장비 레벨 10 이상부터 가능
• 1~5강은 100% 성공
• 6강 이상부터 실패 확률 적용
• 실패 시 강화 수치 1 하락
• 보호 아이템 사용 시 하락 방지
• 최대 강화 수치는 15강

이 정도가 되어야
개발자도 기준을 잡을 수 있고,
QA도 어떤 항목을 확인해야 하는지 알 수 있다.

즉, 좋은 기획서는

“대충 이런 느낌”이 아니라

“실제로 어떻게 동작하는지”까지 보이는 문서다.

 

 

---

4. 정상 흐름뿐 아니라 예외 상황도 챙긴다

처음 기획서를 쓰면 보통 “이상적인 흐름” 위주로 작성하게 된다.
하지만 실무에서는 정상 흐름보다 예외 상황에서 더 많은 질문이 나온다.

예를 들어 출석 보상 하나만 해도 생각할 게 많다.

 

• 인벤토리가 가득 차 있으면 어떻게 되는가?
• 날짜 변경 직전에 수령 버튼을 누르면 어떻게 처리되는가?
• 접속이 끊긴 상태에서 보상 수령을 시도하면 어떻게 되는가?
• 이미 수령한 날에 다시 들어오면 UI는 어떻게 보이는가?

 

이런 내용이 빠져 있으면 문서는 깔끔해 보여도 실제론 빈 곳이 많아진다.

좋은 기획서는 기능이 잘 작동하는 상황만이 아니라 문제가 생길 수 있는 지점까지 미리 생각한 문서다.

(목차에 예외처리를 넣어야하는 이유)

 

주니어 기획자에게 예외 처리는 특히 중요하다.

왜냐하면 예외 처리를 챙기는 습관이 있으면 문서의 완성도도 높아지고,
실무에서 “이 사람은 생각을 꼼꼼하게 한다”는 인상을 주기 쉽기 때문이다.

 

 

---

5. 유저가 어떻게 느낄지를 함께 고민한다

좋은 기획서는 시스템 설명만 잘 되어 있는 문서가 아니다.
유저 경험까지 고려된 문서다.

 

취업 준비생이 쓰는 기획서에서 자주 보이는 실수 중 하나는

기능이 돌아가는 구조 자체에만 집중하고, 유저가 실제로 이걸 편하게 느낄지까지는 덜 고민하는 경우다.

 

예를 들어 튜토리얼을 기획한다고 해보자.

 

문서에는 단계별 진행 순서가 잘 적혀 있어도 실제로는 이런 부분이 중요하다.

 

• 설명이 너무 길지는 않은가?
• 유저가 직접 해보는 구간이 있는가?
• 실패해도 다시 따라가기 쉬운가?
• 너무 많은 정보를 한 번에 주지는 않는가?

 

게임은 결국 사람이 플레이하는 것이기 때문에 구조가 맞는 것만으로는 충분하지 않다.
유저 입장에서 불편하거나 답답하면 좋은 기획이라고 보기 어렵다.

그래서 좋은 기획서는 기능 규칙과 함께 늘 이런 질문을 한다.

 

• 유저는 이 기능을 쉽게 이해할 수 있을까?
• 어느 지점에서 이탈하거나 헷갈릴 수 있을까?
• 행동을 유도할 만큼 보상이 매력적인가?

좋은 기획서는 시스템 중심 문서이면서 동시에 경험 중심 문서다.

 

 

---

6. 다른 사람이 이 문서를 보고 바로 움직일 수 있다

<일단 기획서를 쓰래요>

기획서는 결국 협업 문서다.
좋은 기획서는 읽는 사람이 “그래서 내가 무엇을 해야 하는지”를 알 수 있어야 한다.

 

개발자는 구현 조건을 알아야 하고,

디자이너는 필요한 화면과 리소스를 파악해야 하며,
QA는 무엇을 검증해야 하는지 감을 잡아야 한다.

 

그런데 주니어 단계에서는 종종 문서를 내 기준으로만 쓰게 된다.
내 머릿속에서는 이해가 되지만, 처음 보는 사람 입장에서는 연결이 안 되는 문서가 되는 것이다.

좋은 기획서는 그래서 친절하다.

 

예를 들어 기능 설명만 있는 게 아니라 아래 같은 정보가 함께 정리되어 있으면 훨씬 좋다.

• 유저 이용 흐름
• 버튼별 동작
• 상태 변화
• 필요한 팝업
• 예외 처리
• 우선순위나 주의 포인트

이런 요소가 있으면 문서가 단순 설명문이 아니라 실제로 작업 가능한 문서에 가까워진다.

 

면접관이 포트폴리오를 볼 때도 이런 부분을 많이 본다.
“이 사람이 생각을 많이 했는가?”도 중요하지만,
그보다 더 중요한 건...

★실제로 팀 안에서 일할 수 있는 방식으로 문서를 쓰는가?★

 

 

---

7. 나중에 수정하고 확장하기 쉬운 문서다

게임은 한 번 만들고 끝나는 경우보다 수정하고 확장되는 경우가 훨씬 많다.
그래서 좋은 기획서는 현재 버전만 설명하는 데서 끝나지 않는다.

예를 들어 이벤트 시스템을 만든다고 했을 때 이번 이벤트 한 번만 적용할 수 있는 구조보다,
다음 이벤트에서도 보상 테이블이나 기간만 바꿔 재활용할 수 있는 구조가 더 좋다.

 

문서도 마찬가지다.

<우리의 마일스톤>

• 항목 구성이 일관적인가?
• 수치 조정 포인트가 명확한가?
• 나중에 조건을 추가하기 쉬운가?
• 다른 시스템과 연결될 때 문제는 없는가?

이런 점까지 고려하면 문서가 훨씬 실무적인 인상을 준다.

취업 준비생이 포트폴리오를 만들 때도 무조건 거대한 기능을 넣는 것보다 구조적으로 탄탄하고 확장 가능성이 보이는 문서가 더 좋은 평가를 받을 수 있다.

좋은 기획서는 지금만 맞는 문서가 아니라 앞으로 바뀌어도 버틸 수 있는 문서다.