1.
프로그래머에게 사랑 받는
게임 기획서 작성법
㈜블루홀 이상균

2.
이 프레젠테이션은 ㈜블루홀 내부
주니어 개발자용 교육 자료를 기반으로 작성되었습니다.
Ⓒ 임신형 Ⓒ 이상균

3.
시작하기 전에

4.
ⒸCasper Cruz
먼저 조사를 해보겠습니다
손을 들어주세요

5.
이 세션은 게임 기획 경력자 대상 강연으로,
업계 실무 경력이 없으면 이해나 공감이
좀 어려울 수도 있습니다
그래도 끝까지 들어 주세요 마지막에 재밌게 해드릴께요

6.
발표자 소개 - 이상균
1985 초등학교 5학년 때 MSX 컴퓨터로 프로그래밍 시작
2001 서강대학교 컴퓨터 공학과 졸업
2003 서강대학교 컴퓨터 공학 대학원 졸업
2001 – 2003 매크로임팩트㈜ 분산 DB 네트워크 모듈 개발 (파트타임)
2003 – 2005 삼성전자 DVS 사업부 선임 프로그래머
DVD 레코더용 펌웨어, 양산 공정 제어 프로그램 개발

7.
발표자 소개 - 이상균
7
2005-2011 넥슨, <마비노기 영웅전> 크리에이티브 디렉터
2012-2015(현재) 블루홀, 미공개 프로젝트 디렉터
누적 경력 11년차의 게임 기획자/디렉터

8.
• 발표자의 특징
– 절반은 프로그래머, 절반은 게임 기획자(Game Designer)
– 학창 시절을 프로그래머로 살았으나,
– 밥벌이는 게임 기획자로 하고 있음
• 오늘 할 얘기
– 프로그래머와 게임 디자이너를 모두 이해하는 입장에서,
– 프로그래머와 잘 소통하기 위해
– 게임 기획자가 알면 좋은 것들
• 실무 기획자들은 한번 쯤 생각해봤던 내용일겁니다…

9.
기획서는 왜 잘 쓰기 어려울까

10.
• 기획서 잘 쓰는 방법에 대한 자료는 정말 많다
– 웹서핑 몇 분만으로도 방대한 자료 획득이 가능
• 하지만,
– 대부분의 개발팀은 신입 기획자를 뽑으면,
– 문서 쓰는 방법 부터 가르쳐야 한다 생각한다
기획서는 왜 잘 쓰기 어려울까?

11.
상품 개발 프로세스
• 기획은 개발의 선행 작업
– 제조업, 보험업, 교육업 등등 기존 산업에선,
– 기획이 확정된 후 개발을 시작한다
• 게임은 어떤가?
Ⓒ 메리츠 생명

12.
얼마전에 발표된 블리자드 신작 게임입니다.
<워크래프트 레전드>,
워크래프트의 영웅이 되어 아제로스를 떠도는 게임
Ⓒ Derak Sakamoto,
Blizzard Entertainment

13.
• 스톰윈드에서 게임을 시작합니다
• 월드엔 수 많은 적들이 준비되어 있군요
이 게임 아시는 분?
Ⓒ Derak Sakamoto,
Blizzard Entertainment

14.
지금까지 본 스크린샷은
하스스톤의 UI 디자이너 데릭 사카모토의
GDC 2015 세션에서 발췌한 것입니다
Ⓒ Derak Sakamoto
Ⓒ GDC Vault

15.
게임은 기획대로 만들기 어렵다
• 워크래프트 레전드 VS 하스스톤
– 블리자드 조차 초기의 기획과 최종 상품이 다름
• 게임 개발
– 확정된 기획으로 상품을 만들어 내는 다른 산업과 달리,
– 반복적인(Iterative) 통합(Integration)을 통해
공학적 예술품을 만들어 내는 것이 게임 개발

16.
• 게임 기획서를 쓰기 어려운 이유
– 다른 산업에서 기획이란 개발(혹은 실행) 이전의 작업
– 게임 산업에서는 개발과 동시 진행되는 작업
• 기획서가 아니라 변경 가능한 설계도를 쓴다고 생각해야 함
Ⓒ 메리츠 생명

17.
• 오늘 할 얘기
– 게임 기획서 작성의 특수성을 인지한 상태에서,
– 쉽게 읽히는 기획서 작성 법에 대해 얘기합니다 (시스템 기획서 특화)
– 프로그래머와 잘 소통하는 법에 대해 얘기합니다
• 이런 얘기는 나오지 않습니다
– 컨텐츠 디자인 잘 하는 법
– 시나리오 잘 쓰는 법
– 게임 기획 잘 하는 법 (알면 저 좀…)
※ 개발/라이브, 회사와 팀 문화에 따라 이 강연 내용은 실천 가능하지 않을 수 있습니다

18.
완전성에 대한
환상을 버리자

19.
• 혹시 이 PT를 보신적 있는 분?

20.
이 시절엔, 규칙 뿐만이 아니라 기획서도 완전함이 목표여야한다 생각
어렸었습니다… ( -_-)y~3

21.
완전성에 대한 환상
• 게임 기획서는 완전할 수 없다
– 실 제작 이후 방향 수정이 당연하다는 것을,
디렉터, 기획자, 프로그래머 등등이 받아 들여야 함
– 절대 변하지 않을 기획서(X)
– 변동 범위를 예측 가능한 기획서(O)
• 팀 문화
– 완전성에 대한 환상을 버리고,
변동 가능성을 받아들이려면
– 유연한 팀 문화의 빌드업이 선행되어야 함

22.
조직 문화 빌드업에 대해 다룬 강연은 많으니,
이 강연에서는 다루지 않습니다.
Ⓒ Reed Hastings, NetflixⒸ 안미루, 넥슨

23.
• 가끔 이렇게 말하는 프로그래머를 봅니다
• 라이브  개발로 이동한 프로그래머에게 보이는 경향
• 다시 말하지만 완전한 사양서는 존재하기 어렵다
– 최초의 상품 기획과 설계 대로 완성되는 공산품이 아님
– 게임이 완성되고,
라이브를 시작한 후에는 비로소 정확도 높게 예측 가능
25
완전한 사양서를 가져다 주세요
프로그래머가 상상하지 않게 해주세요

24.
• 목표가 선명해졌다
– 완전성이 환상이라면,
– 목표는 완전한 기획서를 쓰는 것이 아니라
– 이후 변동 범위를 예측하기 쉬운 기획서를 쓰는 것
• 어떻게 하면 그런 기획서를 쓸 수 있을까?

25.
의도를 전달하자

26.
• 모든 부대에는 “전시 행동 강령”이라는게 있다
– 전시에 특별한 지시 없이도 군대가 일사분란하게 움직이도록
– 군대 다녀온 분들은 다 알 것
• 발표자는 미8군 한국군지원단(카투사) 신병계
– 모든 문서를 파기하고, 하드디스크를 뽑아 들고,
– 용산 고등학교 운동장에서 헬기를 타는 것이 전시 행동 강령
28

27.
• 그런데 만약,
• 폭격으로 용산 고등학교가 사라졌다면?
29

28.
• 지휘관의 의도(Commander’s Intent)
– 1980년대 미 육군사관학교 톰 콜티츠 대령이 만든 개념
– 대부분의 전시 행동 강령과 작전 계획이,
전투가 시작됨과 동시에 무용지물이 된다는 걸 깨닫고
대안으로서 제시한 개념
• 동작 원리
– 모든 명령서의 최 상단에 의도를 짧게 서술
– 강령보다 의도 중심
– “하드디스크를 들고 용산 고등학교로 가라”(X)
– “최신 카투사 신병 자료를 캠프 헨리의 작전 본부까지 옮겨라”(O)
30

29.
• 지휘관의 의도를 몰랐다면,
– 파괴된 용산 고등학교 주변을 배회했을 지도
• 지휘관의 의도를 알았다면,
– 자동차를 타든, 버스를 타든, 걸어서든,
– 캠프 헨리까지 가려고 했을 것이다.
31
ⓒGde-Fon.com

30.
• 기획서에 자주 누락되는 “의도”
– 대개 최초의 의도는 디렉터에게 있다
– 게임 디자이너가 의도를 스펙으로 바꾸는 동안,
– 의도는 문서 안에서 희석되거나 사라지기 쉽다
– 혹은 처음부터 의도가 전달되지 않았을 수도 있다
32

31.
고기 시스템 기획서
• 플레이어는 고기를 소비해 영웅을 던전에 보낼 수 있습니다
• 던전 난이도와 관련 없이 한 번에 고기 1개를 소비합니다
• 고기는 오전 9시, 오후 12시, 오후 6시, 오후 9시에 채워집니다
• 고기는 한 번에 8개가 충전됩니다
• 충전 시간까지 소비되지 않은 고기는 버려집니다
우리 게임은 글로벌 원빌드 인데,
북미에서도 한국 서버 시간을 기준으로 하나요?
프로그래머 A

32.
기획서 첫 줄에 의도를 명시한다
고기 시스템 기획서
• 출근(등교), 점심 시간, 퇴근(하교),자기 직전 시간에
게임 플레이를 유도하고 싶습니다.
• 플레이어는 고기를 소비해 영웅을 던전에 보낼 수 있습니다
• 던전 난이도와 관련 없이 한 번에 고기 1개를 소비합니다
• 고기는 오전 9시, 오후 12시, 오후 6시, 오후 9시에 채워집니다
• 고기는 한 번에 8개가 충전됩니다
• 충전 시간까지 소비되지 않은 고기는 버려집니다
프로그래머 A
그렇다면 고기 지급은
클라이언트 로컬타임을 기준으로 해야겠구나.

33.
• 의도를 전달하면,
– 프로그래머가 더 좋은 구현 방법을 생각해낼 수 있게 된다
– 앞으로 기획의 확장 방향을 예측할 수 있게 된다
– 무엇보다 안돼요를 줄일 수 있게 된다 (뒤에 설명합니다)
• 만약 의도 칸에 쓸 말이 없다면?
– 디렉터가 의도를 전달하지 않은 경우입니다
– 디렉터를 찾아가서 이 시스템의 의도를 물어봅시다
35

34.
단계별로 작성하자

35.
37
몬스터 AI 기획서
• 몬스터는 각자 고유의 AI를 가지고 있습니다
• AI의 종류
• 평화 상태 – 플레이어를 인식하지 못한 상태
• 경계 상태 – 플레이어를 인지하고 공격 거리까지 접근하는 상태
• 공격 상태 – 플레이어와 전투 공방을 하는 상태
• 도주 상태 – 체력이 낮아져 스폰 포인트를 향해 도주하는 상태
• 동료를 부름 – 어떤 종류의 몬스터는 울음 소리를 내 동료를 부릅니다
• 광폭화 – 체력이 낮아져도 도망치지 않습니다
• 몬스터는 보스와 자코 AI를 갖습니다
• 보스 AI가 공격할 때는 자코 AI들은 뒤로 물러섭니다
• 보스의 체력이 낮아지면 자코들이 보스를 보호합니다
• 여러 그룹으로 나뉘어진 AI입니다.
• 상호 정보를 교환하며 메타 AI인 종족 AI의 통제를 받습니다

36.
39
몬스터 AI 기획서
1단계 - 10월 빌드
• 몬스터는 각자 고유의 AI를 가지고 있습니다
• AI의 상태는 다음과 같습니다
• 평화 상태 – 플레이어를 인식하지 못한 상태
• 경계 상태 – 플레이어를 인지하고 공격 거리까지 접근하는 상태
• 공격 상태 – 플레이어와 전투 공방을 하는 상태
• 도주 상태 – 체력이 낮아져 스폰 포인트를 향해 도주하는 상태
2단계 - 11월 빌드
• 특수 AI
• 동료를 부름 – 어떤 종류의 몬스터는 울음 소리를 내 동료를 부릅니다
• 광폭화 – 체력이 낮아져도 도망치지 않습니다
• 그룹 AI
• 몬스터는 보스와 자코 AI를 갖습니다
• 보스 AI가 공격할 때는 자코 AI들은 뒤로 물러섭니다
• 보스의 체력이 낮아지면 자코들이 보스를 보호합니다
3단계 – 미정
• 군대 AI
• 여러 그룹으로 나뉘어진 AI입니다.
• 상호 정보를 교환하며 메타 AI인 종족 AI의 통제를 받습니다
이번 구간에 만들기로 확정된 부분
확정되지않았고,방향만있는부분
※ 개발 프로젝트를 기준으로 한 얘기이며, 라이브는 좀 다를 수 있습니다

37.
기획의 구성
• 완성된 사양
– 이미 시스템으로 제작된 것
– 완성된 부분의 스펙이 변경되는 건 가능하면 피해야
• 눈 앞의 사양
– 이번 구간에 만들기로 한 것
– 구간 안에서는 확정된 사양
• 미래의 비전
– (아마도) 디렉터의 머릿 속에만 있는 것
– 눈 앞의 사양의 성과에 따라 모습이 달라질 수 밖에 없다
40
눈앞의
사양
+
미래의
비전
완성된
사양
+

38.
• 단계별 사양서
– 이 세 모습을 한 눈에 알아볼 수 있게 함
– 변경 가능성 있는 것과 그렇지 않은 것을 알 수 있음
– 확정되지는 않았지만 미래를 예측할 수 있음
• 단계별 사양서를 작성하면,
프로그래머가 변동 범위를 예측 가능
41
눈앞의
사양
+
미래의
비전
완성된
사양
+

39.
프로그래머 분들께
• 특히 툴 같은 것을 개발할 때 많이 나오는 말
• 무리하게 완전한 사양서를 요구한 경우
• 이럴 땐 단계별 사양서를 요청하자
모든게 다 되는 시스템을
만들어 주세요
기획자 A

40.
• 게임 기획자가 단계별 사양서를 못 주면?
– 이 게임이 어떻게 생겼는지 비전이 불명확 한 경우
– 기획자 자신도 이 시스템이 어떻게 변할지 예측을 못하는 경우
• 디렉터가 비전을 전달하지 않은 탓
디렉터를 찾아갑시다
43

41.
기획서를
소모품으로 쓰자
이 파트는 디렉터/PD도
대상으로 하고 있습니다

42.
• 마일스톤이 완료되면
– 두개의 결과물을 가지게 된다
• 문서(사양서등)와, 빌드(코드+데이터)
– 이 두개가 일치할 확률은?
기획서
사양서
회의록
QA 목록…
문서
데이터코드
빌드

43.
• 많은 개발팀이 문서화에 많은 시간을 쓰고 있다
– 잘못된 것 아님
– 긴 라이브 기간 동안 멤버가 바뀔 수도 있고,
– 이후 업데이트 때 이전의 결정에 대한 맥락도 파악해야 하고,
– 회의 자리에 없었던 멤버들도 내용을 공유 받아야 하고,
– 기타 등등…
• 그럼에도 불구하고 문서와 빌드의 불일치는 피하기 어려움

44.
• 문서/빌드가 불일치 하면,
– 프로그래머는 어느 문서가 최신인지 항상 묻게 되고,
– 누군가 문서를 통제해야 하며,
– 때로는 지난 문서 업데이트 때문에 우선 순위가 변경되기도 하고,
– 심지어 프로그래머가 문서를 기다리느라 코딩을 멈추기도 한다
– 문서의 유지 보수 때문에 기획자를 더 뽑아야 하는 상황도
• 그럼에도 불구하고,
– 문서화 그 자체는 여전히 가치있다
– 여러분의 팀이 대형 MMORPG를 개발/유지 보수 하는 팀이라면

45.
• 하지만 아니라면?
– 대형 MMORPG를 개발/유지보수하는 팀이 아니라,
– (대략 30명 이하) 소규모 모바일 게임을 만드는 팀이라면?
– 빠른 의사 결정, 기민한 시장 대응이 필요한 팀이라면?
– 반복적인 빌드와 조립으로 완성도를 높이는 것이
목적인 팀이라면?
• 문서에 대해 다르게 접근해볼 필요가 있다

46.
다시 고기 시스템
• 이 시스템을 실제로 만들고 나면,
고기 시스템 기획서
• 출근(등교), 점심 시간, 퇴근(하교),자기 직전 시간에
게임 플레이를 유도하고 싶습니다.
• 플레이어는 고기를 소비해 영웅을 던전에 보낼 수 있습니다
• 던전 난이도와 관련 없이 한 번에 고기 1개를 소비합니다
• 고기는 오전 9시, 오후 12시, 오후 6시, 오후 9시에 채워집니다
• 고기는 한 번에 8개가 충전됩니다
• 충전 시간까지 소비되지 않은 고기는 버려집니다

47.
• 우리 손에는,
• 이런 것 들이 남게 된다
고기 시스템 기획서
• 출근(등교), 점심 시간, 퇴근(하교),자기 직전 시간에
게임 플레이를 유도하고 싶습니다.
• 플레이어는 고기를 소비해 영웅을 던전에 보낼 수 있습니다
• 던전 난이도와 관련 없이 한 번에 고기 1개를 소비합니다
• 고기는 오전 9시, 오후 12시, 오후 6시, 오후 9시에 채워집니다
• 고기는 한 번에 8개가 충전됩니다
• 충전 시간까지 소비되지 않은 고기는 버려집니다
기획서 등
문서
그리고 코드
스크립트, 시트, 리소스 등
데이터
ⓒ도탑전기

48.
• 기획서 내용 중 시스템은 코드로,
• 컨텐츠는 데이터로 정리되는 것
• 즉, 빌드는 이미 온전히 기획서를 포함하고 있다
• 그렇다면 이제 기획서는 버려도 되는 것이 아닐까?
기획서
사양서
회의록
QA 목록…
문서
데이터코드
빌드

49.
이렇게 한 번 해 보세요
• 문서를 크게 세 그룹으로 나눈다
– 예전 빌드 문서 모음 (완성된 사양)
– 현재 빌드 스펙 (눈앞의 사양)
– 기획서/비전서 (미래의 비전)
• 빌드가 끝나면,
– 눈앞의 사양 문서 중 일부를 기획서로 흡수
– 나머지는 예전 빌드 문서로 밀어 넣는다(버린다)
– 예전 빌드 문서는 현재 빌드 상태와 일치하지 않을 수 있음
• 남겨야 하는 문서?
– 시스템의 의도가 담긴 문서
눈앞의
사양
+
미래의
비전
완성된
사양
+

50.
• 정말 될까?

51.
기획서의 형식을
없애자

52.
• 보통 팀에는 기획서 양식이라는 것이 있다
문서 제목
작성자 작성일
리비전 수정 내용
개요

53.
• 이런 기획서 양식이,
– 문서를 유지 보수하는데 도움이 될까?
– 다른 멤버에게 기획 내용을 전달하는데 도움이 될까?
– 프로그래머가 문서를 이해하는 데 도움이 될까?
• 지금까지 우리는,
– 기획서의 완전성과 불변성에 대한 환상 대신,
– 반복적인(Iterative) 통합(Integration)을 통해 개발되는
게임의 특성에 잘 맞는 문서 다루는 법에 대해 얘기했다

54.
기획서의 본질은 전달
• 게임 기획은,
– 발상
– 설계
– 전달
• 세 단계로 이루어진다
– 이 중, 설계가 끝난 기획을 전달하기 위해 작성하는 것이 기획서
– 즉 기획서의 본질은 전달에 있다고 할 수 있다
자세히 얘기하면 이 얘기만 두시간짜리
Ⓒ 이상균

55.
• 이런 방법은 어떤가?
사회성 부족한 프로그래머들을 위해
프로그래밍 치어리더를 고용한다는 중국 개발사에 대한 기사
Ⓒ Trending in China Facebook

56.
프로그래머의 취향은 다양하다
• 기획서에 대한 취향도 모두 다름
– 어떤 프로그래머는 천천히 읽을 수 있는 정갈한 문서를 좋아하고,
– 어떤 프로그래머는 PPT로 윤곽을 파악한 후,
체크 리스트 형태로 기능을 클리어하는 걸 좋아하고,
– 어떤 프로그래머는 그런거 필요 없고
게임 디자이너가 문서 들고 찾아와서 하나씩 설명해주는걸 좋아하고,
– 어떤 프로그래머는 기획 회의부터 들어가는 걸 좋아한다
• 기획서의 본질이 전달이라면,
꼭 한가지 방법을 고집해야 할 이유가 없다

57.
실제로 써 본 방법
명함으로 보드게임 만들기 설명 한 줄 없는 슈도 코드 기획서

58.
프로그래머에게 물어보세요
• “이번 기획서, 어떻게 준비할까요?”
• 예상 외로 다양한 대답이 돌아 올 겁니다
– “일단 원하는 걸 불릿 리스트 형식으로 5~6줄 써 오세요”
– “회의실 가서, 원하는 걸 간단하게 먼저 설명해 주세요”
– “비슷하게 동작하는 게임이 있으면 찾아서 알려주세요”
– “문서보다 데이터 시트를 먼저 주세요”

59.
• 우리는 앞서, 빌드후 문서를 버릴 수 있을까에 대한 얘기를 했다
• 버리겠다 마음 먹으면, 그 문서의 형식이 중요하진 않을 것
• 기획서의 본질은 전달에 있다
기획서
사양서
회의록
QA 목록…
문서
데이터코드
빌드

60.
안돼요에 대하여
이 파트는 프로그래머도
대상으로 하고 있습니다

61.
• 안돼요 – 프로그래머의 궁극기
– 게임 기획자를 포함,
타 직군 사람들이 가장 두려워하는 답변 1순위
– 왜 안돼요를 그렇게 두려워할까
64

62.
우리가 보는 프로그래머
강철의 연금술사 아이언맨 창조신(神)
신기함
놀라움
간지(멋있음)
뭔지 모르겠는 걸
할 수 있음 기대
부러움
존경스러움
ⓒ 임신형, 블루홀

63.
실체화 능력
– 기획이 실체화 되려면 코드가 필요
– 아무리 훌륭한 아트와 기획이 있어도,
그것 만으로는 게임이 되지 않음
– 먼저 얘기했듯, 게임은 공학적 예술품
※ 당연히 타직군 업무가 덜 중요하다는 뜻은 아닙니다
강철의 연금술사
ⓒ 임신형, 블루홀

64.
메타 개발
• 메타 개발
– 개발이 가능하도록 하는 개발
– 툴, 프로세스 등의 개발
• 생산성, 생산력의 향상
– 더 큰 게임, 더 높은 퀄리티 게임
아이언맨
ⓒ 임신형, 블루홀

65.
가능성의 오픈
– 이 전에는 할 수 없었던
개발의 가능성을 열어주는 일
– 반대로 말하면 프로그래머가
해 주지 않으면 그 가능성은 없어진다창조신(神)
“나의 권능으로, 리비전 18903부터
본 개수 250개 이상인
몬스터의 제작을 허하노라.”
ⓒ 임신형, 블루홀

66.
• 그래서 안돼요는 선고 같은 것
– “이 대화를 종결하노라” 같은 답변
– 쓰면 안된다(X) 안되는 이유를 충분히 설명한다(O)
69

67.
• 안돼요에 대해 좀 더 자세히 살펴봅시다
– 프로그래머는 왜 안된다고 할까요?
– 프로그래머가 왜 안된다고 하는 알아야,
커뮤니케이션을 잘 할 수 있다
70

68.
진짜 불가능한거예요
• 기획자가 정말 불가능한 걸 요구했을 때
• 내가 의도를 제대로 전달했는지 생각해보자
71
ⓒ마우리츠 코르넬리스 에셔

69.
“시간이 너무 많이 걸려요”
• 가장 많은 안돼요의 이유
• 현재 더 우선 순위 높은 업무를 진행중일 때
• 게임 디자이너의 요구와 마감 시한이 모순될 때
72

70.
• 그런데 이렇게 생각해보자
– 시간이 많이 걸리는, 시스템상 중대한 업무 혹은 변화를
갑자기 챙겨야 할 상황이란 어떤 상황인가?
• 대개 이 두 가지 경우
– 디렉터가 변덕을 부렸거나,
– 미리 예측 못한 예외 상황 때문일 때가 많다
• 만약 자주 발생하지 않을 예외 상황 때문이라면?

71.
• 이 시스템의 빈도에 대해 언급하자
– 프로그래머가 항상 하드코딩을 기피하는 것은 아님
– 프로그래머는 앞으로도 계속
이 문제로 추가 하드코딩이 예상될 때 안돼요라고 한다
이번만 예외입니다.
비슷한 경우가 없을거예요
기획자 A

72.
추천 프레젠테이션
• 바로 이 주제를 심도 깊게 다룬 PT
ⓒ하지훈, 넥슨

73.
너무 많은 걸 변경해야 해요
• 실은 “안돼요”가 아닌 “싫어요”
76
<월드오브워크래프트: 대격변>

74.
프로그래머의 코드 오너십
• 코드 오너십
– 프로그래머는 본인이 짠 코드에 큰 애착을 갖고 있다
– 아티스트가 마음에 들든 안들든
본인 작품에 애착을 갖는 것 처럼
• 하지만 앞서 얘기했듯, 게임은
– 반복적인(Iterative) 통합(Integration)을 통해 개발됨
• 완성된 사양 또한 변경될 수 있다
눈앞의
사양
+
미래의
비전
완성된
사양
+

75.
• 어쨌든 괴로운 상황
• 어떻게 하면 좋을까?
– 정답이 없는 상황이지만, 저는 이럴 경우
의도를 전달하고 깊게 토론하는 것을 추천합니다
고기 시스템 기획서
• 출근(등교), 점심 시간, 퇴근(하교),자기 직전 시간에
게임 플레이를 유도하고 싶습니다.

76.
다시 등장한 의도
• ToDo List 보다 맥락을 전달한다
– 왜 이런 변경을 해야 하는지 맥락을 전달한다
– 의도를 만족시키는 다른 방법이 없나 함께 찾아본다
– 디자인을 약간 변경하여
기능 추가 등으로 마무리 할 수 없나 찾아본다
– 이 때 중요한 것이 의도를 전달하는 것
• 시스템 변경의 의도를 모르겠다면
– 물론 디렉터 탓입니다. 디렉터를 찾아갑시다

77.
잘 모르겠어요
• 할 수 있는지 없는지 공부해 봐야 해요
– 프로그래머는 “모르겠다”라는 말을 하기 싫어함
– 기획자가 하고 싶은 것이 될지 안될지
지금 당장은 모르겠는데, 그 모른다는 말이 하기 싫다
– 그래서 답변을 바로 준다면 “안돼요”
– 주니어 프로그래머들에게 가끔 나타나는 경향
하지만 이게 가장 나쁜 “안돼요”
왜 가장 나쁠까?
80

78.
• 타 직군 사람들이 가장 두려워하는 답변 1순위
• 그럼 프로그래머가 가장 싫어하는 말 1순위는?
81

79.
• 프로그래머 A님은 된다던데요?
– 왜 A님을 찾아갔을까?
– 될 것 같은데 안된다는 답변을 들었기 때문
– 정말 안되는 것인지 확인하고 싶었기 때문
– 이미 신뢰를 잃었다
사소한 오해에서 갈등이 시작될 수 있기 때문에,
가장 나쁜 “안돼요”라고 할 수 있다
82

80.
• 이 경우, 기획자가 할 수 있는 것은 없다
• 오직 프로그래머만이 이 문제를 해결할 수 있음
당장은 된다 안된다 말씀 못드리겠군요.
제가 좀 살펴보고 말씀드릴께요.
프로그래머 A

81.
그 밖의 짧은 조언들

82.
피드백을 부탁하자
• 피처의 개발이 끝나면, 프로그래머에게 묻자
• 분명히 유의미한 피드백을 받을 수 있을 것
이번 기획서는 어떠셨나요?
다음 번엔 제가 어떻게 하면 좋을까요?
기획자 A

83.
파라메터를 명확히 하자
고기 시스템 기획서
• 던전 난이도와 관련 없이 한 번에 고기 1개를 소비합니다
• 고기는 오전 9시, 오후 12시, 오후 6시, 오후 9시에 채워집니다
• 고기는 한 번에 8개가 충전됩니다
고기 시스템 기획서
• 던전 난이도와 관련 없이 한 번에 고기 1개를 소비합니다
• 고기가 채워지는 시간은 MeatParam.RegenTime 에 정의되어 있습니다
• 고기는 한 번에 Misc.MeatMax 개가 충전됩니다
프로그래머가 문서로부터 하드코딩할 것과 그렇지 않을 것을 구분할 수 있다

84.
기술을 선택하지 말자
바닥에 뿌려진 피가
좀 입체적으로 보였으면 좋겠습니다
피 데칼에 노말맵을 넣을까요?
혹은 3D 메시를 다이나믹 스폰할까요?
① 퍼포먼스를 생각하면 노말맵이 낫겠습니다
② 퀄리티를 위해선 3D 메시가 좋을 것 같네요
③ 제가 결정할 일이 아닌 것 같네요. TA를 부를께요
⒜

85.
진척 상황을 체크하자
• Deadlock
– 두 작업이 서로의 작업이 끝나기를 기다리고 있는 교착 상태를 나타내는
프로그래밍 언어
• 어떤 작업이 시작된 후 별 진전이 없을 때,
– 기획서, 리소스, 데이터, 코딩이 서로를 기다리고 있는게 아닌지 체크
• 프로그래머의 컨텍스트 스위칭 비용은 비싸다
– 적절함과 휴먼 매니지먼트의 영역

86.
끝으로

87.
이런 얘기들을 했습니다
• 완전성에 대한 환상을 버리자
• 의도를 전달하자
• 단계별로 작성하자
• 기획서를 소모품으로 쓰자
• 기획서의 형식을 없애자
• 안돼요에 대하여
• 피드백을 부탁하자
• 파라메터를 명확히 하자
• 기술을 선택하지 말자
• 진척 상황을 체크하자

88.
• 게임 산업은 계속 변화합니다
– 대형 MMORPG가 주류를 이뤘을 때는,
이런 기획서 관리법이 목소리를 내지 못했을거예요
– 작고 빠른 개발팀이 주류가 된 현재에 와서야 의미가 생긴 방법론
• 따라서 이 발표도 영원한 진리를 담고 있지는 않습니다
– 새로운 방법론들이 계속 시도되고, 발표되고, 토론되길 기대합니다

89.
게임 기획자(Game Designer)
여러분의 건승을 빕니다
우리 같이 힘 냅시다

90.
93
긴 시간 수고 많으셨습니다.
감사합니다
이상균
@iyooha
http://iyooha.com