시작하는 기획자의 실수

출처 : KGDC 2003 문서강연 참가 글 / 작성자 김의민님 (Nickname : 아리랑피바람 )

시작하는 기획자의 실수, 시작하는 게임 개발에서 중요한 점
- 아마추어 게임개발에서 기획자의 존재 이유 -

작성자: 김의민

청강문화산업대학 게임과 재학 중

mal_min99@hotmail.com

도입:

시작하는~ 이라는 제목은 흔히 ‘게임 개발자 지망생’, ‘초보’ 이런 말을 보다는 좀 더 어감이 친근하고 듣기에도 좋지 않을까 해서 사용하게 되었습니다. 또 아마추어 개발자, 아마추어 게임 과 같은 경우도 모두 똑같이 아마추어 라고 불리우지만, 그 중에서 상대적으로 경험이 풍부한 아마추어도 있고, 이제 막 시도하는 아마추어도 있기 때문에, 그리고 저의 글의 타깃이 되는 대상은 아마추어 개발자 중에서도 '시작하는~' 등급이 적절하다고 판단 되었기 때문 입니다.


1. 시작하는 기획자

- 기획자는 무엇을 하는 걸까?

필자가 접해본 대다수의 개발자 지망생 중 게임 기획 & 디자인 을 지망하는 사람들은 대다수가 게임 기획이란 것이 추상적이고, 어떤 형식이 없고, 문서 위주의 작업, 그리고 심지어는 시나리오 작성이 기획자가 해야 할 일의 전부로 착각하는 사람도 아주 많았다.

개인적으로 생각하기로는 우리나라의 기존 게임 기획자들이 잘못된 선례를 남겼고 이 잔재를 후배들이 받은 것 같아서 언짢다. 필자가 생각하는 올바른 기획자 또는 게임 디자이너는 관념 속에서 멋지게 포장되어있는 ‘리더’, ’설정자’ 같은 것이 아니다. 이들이 분명 멋져 보이긴 하지만 아무런 기반 없이 그 위치에 오른 것이 분명 아닐 것이다.

특히 현실적인 기획자라면 역시 개발의 일선에서 툴을 만지면서 레벨디자인을 하고 스크립트 작업과 같은 힘든 일을 하면서 항상 자신들이 만드는 게임에 대해서 생각하고 더 좋은 게임으로 만들기 위해서 고민해야 하는 사람이 아닐까?. 물론 흔히들 잘 알고 있는 기획서 작성 및 시나리오, 설정 같은 것도 해야 한다. 필자는 우선 기획자가 되려면 게임 기획에 관해서 멋지게 포장되어있는 기존의 관념, 거짓 환상을 버리고, 무엇을 할지 분명히 알아야 한다고 생각한다. 게임 기획도 프로그래밍, 그래픽 과 같이 똑같이 진흙탕을 구르는 것이고, 똑같이 힘든 일이다.

- 문서작성에 대한 잘못된 생각.

옛날 유명한 수학자이자 철학자 파스칼은 언젠가 친구에게 한정 없이 긴 편지를 한 통 쓰고 난 후 추신에 짧은 편지를 쓸 만한 시간이 없었노라고 사과하는 글을 덧붙인 적이 있다. 하물며 편지를 길게 쓰고도 사과를 해야 할 정도이니, 그것이 게임 기획서 라면 어떻겠는가?

정말 무진장 지루하게 읽기만 하고 이해조차 할 수 없는 기획서를 쓰는 기획자라면 깊이 반성을 해야 할 것이다.

시작하는 기획자들은 종이에 한이 맺혔는지는 몰라도, 무한정 기획서를 길게 쓰려고 하는 경향이 있다. 특히 기획서를 써본 경험이 별로 없는 사람의 경우는 ‘양이 많은 기획서 = 잘 쓴 기획서’로 착각을 하는 경우가 많다. 그들이 쓰는 기획서들을 살펴보면 앞부분에 커버가 있고, 목차, 게임에 대한 기획의도 랄지, 게임의 핵심 같은걸 쓰고... (여기까지는 나무랄 수는 없다) 꼭 그 다음에는 한 페이지의 도표에 일정표가 들어간다. 그 이후에 친절한(?) 유저 인터페이스 설명이 나오는데, 이것들에 시시콜콜히 표나 그림 같은걸 집어넣어서 그 분량이 장난이 아니다. 이후에는 다닥다닥 아이템 표, 캐릭터 설정, 그리고 줄기찬...시나리오...시나리오...시나리오.

[공모전 등지에서 소개된 기획서들의 양식 영향인지 몰라도, 기획서들을 살펴보면 거의 형식은 비슷비슷하고, 전부 몇 십 페이지의 방대한 분량을 자랑한다. 필자는 이런 기존의 방식 보다 좀더 효율적이고 새로운 방법을 강구 해야 된다고 주장한다.]

필자가 본 많은 기획서가 이렇다. 물론 무조건 나쁘다는 것은 아니다. 하지만 그들 기획서에서 기획서가 가져야 할 실질적으로 중요한 내용이 무시되기 일쑤이다. 특히 지금 설명하려는 부분은 지금까지의 전반적인 기획서 작성법에 관한 내용인데, 기존의 거의 모든 게임 기획서 들은 나열식 수직 구조이다.

워드프로세서의 구조 자체가 원래 그렇지만, 이런 구조일 경우 10 page 가 넘어가면 보는 사람은 지루해지고 집중력을 잃는다. 팀원들에게 그걸 던져주면... "어! 기획자 수고했어, 잘 읽어보겠어~ (하지만 내일...)" 그리고 이 기획서는 그냥 문서더미 속에 던져진다.

현업의 기획자들도 팀원들이 기획서를 안 읽는다고 불평이 많은데, 그것이 지망생 개발팀이나 아마추어게임 팀이면 더 심할 것이라고 생각한다. 이 부분은 팀원을 탓하기 이전에 기획자가 기획서를 좀더 보기 편하게 만들어 놓아야 하는 문제이다.

필자가 제시하는 대안은 이렇다.

우선 나열식의 기획서는 되도록 10장 이내로 제한 하자. 멋들어진 커버는 생략 하고, 일단 간단한 목차와 게임의 핵심적인 요소, 기승전결의 간단 시놉시스, 필요한 기술적인 능력 등을 구체적이고 명확하게 명시하는 것이 본 기획서의 목적이다.

그리고 파생되는 캐릭터, 아이템, 시나리오는 차라리 다른 문서로 준비를 하자. 일정표도 마찬가지이다. 기획서에 한 페이지에 쓰인 도표는 일정관리에 별로 쓸모가 없다는 것이 필자의 생각이다. 일정관리를 문서화 할 필요가 있다면 역시 외부의 다른 문서로 만들어주자.

정리 하자면 핵심이 되는 기본 문서와 그것에서 파생되는 간략하지만, 잘게 나뉘어진 문서로 기획서를 구성하자.

이보다 좀 더 발전적인 기획 문서를 만든다면 '하이퍼텍스트’ 를 이용하자.

간단히 활용을 할 수 있는 것은 ‘인트라넷’ 을 하나 구축하고 위에 쪼개진 각각의 다른 문서들의 제목을 하이퍼텍스트 화 해서 필요할 때 쉽게 찾아볼 수 있도록 하는 방법이 있을 것이다.

‘나열식 기획서’와 ‘목차 지향형’ 기획서
좀더 발전시키자면 애초부터 모든 기획 문서의 하이퍼텍스트 화를 하는 방법이 있다.

‘WikiWiki’와 같은 발전적인 기술을 써도 좋고, 모든 문서를 Html파일로 만들고, 서로를 이어줘도 좋을 것이다. 물론 이때 가장 중요한 것은 한번에 그들 문서를 찾아볼 수 있는 '목차' 라고 생각한다. 메인 페이지 의 목차를 보고 빨리 이해하고, 개발진이 필요한 정보를 목차를 따라 이동해서 볼 수 있고, 다시 메인 페이지로 돌아갈 수 있어야 한다.

하이퍼텍스트 화 된 기획서의 예시

[세부적인 예시가 될 수 있는 예제를 차후 필자의 홈페이지에서 공개할 예정이다.]
흔히 간결한 문서를 쓴다는 것을 문서를 짧게 작성하라는 걸로 착각하는 사람이 있다.

간결함과 짧음은 같지가 않다. 개발자가 문서를 읽어보고 그것에 대한 모호함이 없이 정확히 기획자의 의도를 파악할 수 있다는 것이 간결함 이라고 할 수 있다.

간결성을 강조한다고 그냥 막무가내로 짧은 문서를 쓴다면 그 모호함은 가중될 것이다.

또한 정형화된 방법으로 기획서를 만들려고 하지 마라. 여기서 말하는 것과 ‘포맷’은 다른 것이다. 틀이 잡힌 문서의 ‘포맷’은 효율적이다. 하지만 ‘배경 시나리오를 쓰고, 세계관을 설정하고, 그 다음에는 일정표 차트를 하나 넣어주고...' 바로 이런 것이 ‘정형화’ 혹은 ‘악습화’ 된 형식으로 그대로 따라 하는 것들이다. 이것은 게임을 만드는 것과 전혀 무관하다. 기획서에 시시콜콜히 ‘세계관’, ‘배경스토리’ 이런 것은 넣을 필요는 없다고 생각한다. 그런 것은 시간 날 때 하고 당장은 게임을 만들 때 실질적으로 필요한 작업을 하라. 단순히 기획서 몇 페이지 늘린다고 바뀌는 것은 아무것도 없다. 문서를 늘리기 보다는 줄일 수 있는 기획자가 되자.

아마추어 개발팀 중에서 열심히 하는 개발자들이 많다. 필자가 겪어본 팀들도 다 자신만의 기술과 능력이 있고 근면하다. 하지만 그 중에서 기획자가 가장 쓸데없는 작업을 하고 있고, 가장 많이 논다. (필자도 기획자이다.)

그래픽 팀원이 도트 찍고, 프로그래머가 힘들게 코딩 할 때, 기획자라면 위에 명시한 정도의 노력은 해야 하지 않겠는가? 이 정도를 기획이 못해준다면 아마추어 개발에서 기획자가 하는 일은 무엇인가? 있기라도 할까?
　

2 시작하는 게임개발

- 분명한 목표를 세우자

나는 시작하는 게임 개발에서 가장 중요하게 생각하는 것이 분명한 목표를 세우는 것 이라고 자신 있게 말할 수 있다. 가장 흔히 들 수 있는 잘못된(?) 목표가 바로 ‘게임을 같이 만들어 가면서 실력향상을 도모하자’ 라는 목표 이다. 일단 얼핏 듣기에 전혀 문제가 없는 말이지만, 이 목표는 우선적으로 게임 보다는 개인의 실력향상에 주안점을 둔 것 이기 때문이다. 처음의 목표부터 ‘게임의 완성’ 이라는 목표를 분명히 설정해두지 않았기 때문에 이런 막연한 목표에서는 게임이 나오기 힘들 것이다.

어떤 종류와 어느 정도의 기술력이 요구되는 게임을 만들지도 중요하다. 게임을 만들면서 실력이 좋아지기는 하지만, 그렇다고 처음부터 완성될 게임의 목표를 개개인의 잠재적 성장도 까지 생각해서 잡는 건 문제가 있다. 자신들의 실력이 10이라고 할 때 첫 번째 만들 게임 이라면 8 정도 되는 수준의 게임을 만드는 것을 권장한다. 우선은 완성이 관건이기 때문이다. 아마추어 게임 개발에서 완성은 무엇보다 중요한 목표 라고 생각한다.

한가지 게임을 처음부터 끝까지 만드는 경우가 아마추어 게임 개발에서는 희귀할 정도이다. 한 개의 게임을 끝까지 완성을 할 수 있는 팀은 그걸로 대단하다고 판단할 수 있을 것이다. 완성은 성공이고 성공은 자신감이다. 이 성공이 아마추어 개발팀을 존속시킬 수 있는 이유가 될 것이다.

- 가능하면 빨리 만들자

아마추어 게임 개발은 비영리적인 일이다. 아무도 그들에게 돈을 주지 않는다. 그렇다고 게임을 완성하면 돈을 벌기도 힘들다. 또한 게임을 만든다는 것이 그렇듯, 완성하기 이전에는 명확히 눈에 보이는 것도 없고, 결과물을 예측하기 힘드니 마치 맨땅에 헤딩하는 기분일 것이다. 그래서 위에서 말했든 달성 가능한 목표를 세우는 것이 중요한 것이다.

빨리 만들어야 하는 이유도 이것의 연장선에 있는 내용이다. 개발 프로젝트의 시간이 길어질수록 점점 프로젝트의 목적에 회의감이 들고, 이탈하는 인원이 생길 수 있을 것이다. 마치 둑에 균열이 생기는 것처럼 일단 이런 일이 시작하면 팀 자체의 존속은 어려워질 것이다. 특히 오랜 시간 동안 진행해야 할 프로젝트일수록 위험도는 크다. 필자가 생각하는 가장 적정선은 6개월 이내 라고 생각한다. 학교라면 한 학기 동안 정도일 것이고, 이정도 라도 충분히 게임 하나 만들 시간은 될 것이다. 이 이상 길어지면 상당히 어려워진다.

게임을 만든다는 것은 집중을 한다면 그리 큰 시간을 잡아먹지는 않는다. 시간의 손실은 주로 쓸모 없는 잡업이나 개으름이 대부분이다. 특히 강조하고 싶은 것은 아마추어 수준 (첫 경험이라면 더더욱) 에서 년 단위로 진행되는 프로젝트를 성공시킨다는 것은 팀원들이 준 프로나 현업 경험자가 아닌 이상 절대적으로 어렵다. 팀의 리더라면 적절한 수준의 일정 관리와 팀원 관리로 목표한 시간 안에 완성시키도록 노력하자. 시간이 길어질수록 위험도 커진다.

- 팀 작업과 대인관계

팀 작업은 근본적으로 어려운 일이다.

어쩌면 혼자서 게임을 만드는 것이 더 쉬울 수 있다. 팀으로 작업을 한다는 것은 사람 (팀원) 의 관리에 신경을 써야 한다는 의미 이기도 하다. 경험이 없는 개발자 지망생들은 이 점에 있어서 매우 큰 약점을 가지고 있다. 팀이라는 것은 사람의 모임인데, 대다수의 지망생들은 팀 작업 경험이 전무하고, 팀원의 관리를 잘 할 수 있는 사람이 드물기 때문이다.

아래는 필자가 생각하는 팀 작업의 몇 가지 기본적인 조건사항 이다.

1. 소규모의 팀이어야 한다.
2. 그들에게 믿음을 주라!
3. 노는 작업자가 없어야 한다.
4. 서로간의 신뢰는 기본이다.
5. 군대를 앞두고 있는 팀원, 커플이 될 가능성이 있는 팀원은 피한다.
6. 원격 작업은 가능하면 피하자.
7. 자주 만나서 예기를 해야 한다.

기술력이 된다면, 팀은 작을수록 좋다. 한 사람의 개발력이 1이라고 봤을 때 7명이 작업한다고 7의 개발력이 발휘되는 것은 아니다. 팀 작업의 여러 가지 어려운 점은 관리가 안 되는 많은 팀원 숫자에도 있다고 생각한다.

아마추어 개발팀에서 대인관계의 핵심은 팀원들에게 믿음을 주라는 것이다. 자신이 팀장의 위치라면 게임을 완성할 수 있다는 확신을 주어야 하고, 솔선수범을 해서 작업을 열심히 하는 모습을 보여주어야 한다. 특히 대다수가 팀의 리더인 기획파트가 모범을 보여야 한다고 생각한다. 상대적으로 기획 쪽이 가장 일을 안 하는 것으로(!) 보이기 때문이다. 아까도 말했듯, 기획 쪽도 실질적으로 작업을 해야 하고 그 밖의 업무를 할 때도 모범을 보여야 한다.

팀원 중 노는 사람이 생긴다는 것은 팀 작업에 문제가 생기고 있다는 것을 반증한다.

우선 먼저 작업 분배를 잘해서 노는 인원의 발생을 최소화 시켜야 한다. 초기 팀원 모집부터 분명히 프로젝트에 필요한 사람을 모집하는 것도 중요하다. 너무나 뜻이 다르고 작업에 저해가 되는 사람이 생기면 빨리 프로젝트에서 제외를 시켜라. 한 사람과의 우정을 생각하다가 모든 것을 잃을 수도 있다.

서로를 신뢰한다는 것은 당연한 것이다. 설명할 필요가 없을 듯 하다. 이것에 관한 노하우는 스스로 찾아가는 것이 빠르다고 생각한다.

우스운 소리 같지만, 군대를 앞두고 있는 사람이나 이제 막 연애를 시작한 사람은 피해야 한다. 군대를 가게 된다면 당연히 프로젝트는 할 수가 없다. 연애를 시작하는 사람의 경우도 연애하는 것을 게임개발보다 더 매력적으로 받아들일 것이다. 당연히 프로젝트 도중에 공백이 생길 것이고 다른 팀원들의 사기에도 영향을 미친다.

인터넷이 발전해서 이제 모든 개발을 100% 인터넷으로 하려는 사람도 생겼다. 하지만 해당되는 사람들이 철저한 프로의식이 없는 이상 원격작업은 불가능하다고 생각한다. 우선 얼굴을 마주보고 예기를 하는 것과 인터넷으로 대화를 하는 것은 근본적으로 다르다. 또한 정상적인 오프라인 개발팀도 상당한 문제가 생기는데, 하물며 온라인이라면 어떻겠는가?

팀원간에 서로 자주 만나서 예기하는 것은 중요하다. 대화를 통해서 서로의 신뢰를 쌓을 수 있고, 직접 부대끼면서 토론하는 것은 결과적으로 좋은 영향을 준다. 게임 작업 뿐 아니라 일상에서도 서로간의 친목을 도모하면 여러모로 도움이 될 것 이라고 생각한다.

- 다른 방법은 없는가?

굳이 처음 시작하는 작품을 보통 게임 만들 듯, 코딩하고, 그래픽 리소스 직접 그리고, 기획서 쓰고…이런 보편적인 방식을 고수할 이유는 없다고 생각한다. 그냥 소규모 (3명 이하) 의 규모로 간단한 게임 제작 툴 (예를 들자면 퓨어엔진, V-nap 앤진, 알피지쯔구르) 와 같은 걸로 자신들의 첫 게임을 만들어보는 것은 어떨까? 이들 툴은 공개이긴 하지만 충분히 게임을 만들 수 있고 능력에 따라서 창조적이고 독창적인 작품이 나오기도 한다. 특히 이런 공개 툴로 게임을 만든다고 그 가치가 떨어진다고 생각해본 적은 없다. 게임을 게임으로서 잘 만든다면 뭐가 나쁘겠는가?
　

[공개 게임 개발 툴의 간단한 소개]

비주얼노벨 툴‘Pure’:: 장기현(neoojang) 님이 개발하신 ‘비주얼노벨’ 스크립트 엔진으로 사용이 쉽고 강력한 툴 입니다. 청강대학교 게임과 에서 학습 교제로도 사용되었습니다. 곧 최신 버전이 발표됩니다. http://noeejang.net

비주얼노벨 툴 : P u r e

비주얼노벨 툴 ‘V-nap’ :국내의 많은 동인 게임 팀이 사용하는 공개 비주얼노벨 툴 입니다. 상당히 많이 사용을 해서 그 명성이 높습니다. http://vnap.x-y.net/

이하 쯔구르 시리즈 : RPGMAKER 2000, RPGMAKER 2003, 액션 RPG 만들기, 연애 시뮬레이션 만들기, 격투 게임 만들기 등등 (알피지메이커 시리즈는 개인적으로 추천하는 개발 툴 입니다. 개발자에 따라서 이 툴을 사용해서 무척 멋진 게임들을 탄생하기도 합니다.) http://www.acoc.co.kr/ : 유명한 쯔구르 커뮤니티 사이트 ‘창조도시’)

　
3. 왜 ‘시작하는 개발자’ 들을 지원해야 하는가?

우리나라 게임산업 초창기부터 지금까지 게임업계의 인력은 항상 부족한 편이다.

더군다나 몇 년 전부터 급격한 양적인 팽창으로 더욱 많은 인력이 요구되고 있다. 이제는 우리나라에 게임에 관련된 2년제~4년제 대학의 게임학과도 몇 개 생겼고, 사설 교육기관도 있다. 기반은 옛날보다 많이 발전되었지만, 아직 많이 모자란다. 단지 양적인 인력이 많아지는 것 만이 중요한 것이 아니라, 그 인력의 각각에 역량도 중요한 법이다.

아마추어 시절에 습작 게임 개발을 겪어보지 못하고 본격적인 현업에 진출한다는 것은 큰 문제라고 생각한다. 기본적으로 몇 번 정도의 습작수준에 게임의 완성 경험이 있어야지, 비교적 그 사람이 현업에서 게임을 개발할 수 있는 능력이 되겠다고 판단할 수준이 되는 것 이라고 생각한다. 지망생 시절, 게임 만든 경험도 없이 달랑 기획서 작성하는 것만 알아서 (사실 그 기획서의 수준도 한심한 경우가 대부분이다.) 게임회사에 온다는 것은 그다지 바람직한 현상은 아니라고 본다.

특히 지금은 VT 통신망을 기반한 동호회들의 몰락으로 인해서, 그 아마추어들을 품고 키워주는 공간이 예전보다 부족하다. 또한 급격한 게임산업의 팽창으로 지망생과 현업 개발자의 중간단계라고 볼 수 있는 아마추어 개발자들이 거의 없다고 알고 있다. 결국 이런 상황이 계속되면, 게임업계는 양질의 개발자를 끌어올 수 있는 베이스를 잃어버리는 셈이 된다.

KGDA 는 이런 상황에서도 지망생들의 좋은 성장의 장이 되어왔다.

필자의 경우에도 KGDA가 있었기 때문에 지금 여기에 투고를 할 정도까지의 능력을 가지게 되었다 (물론 많이 부족하지만) 모든 이들이 마찬가지 라고 생각한다. 그들도 격려를 받고, 관심을 받는다면 무럭무럭 성장할 수 있는 자질이 있다고 생각한다.

하지만 아직 미약한 부분이 너무 많다. 좀 더 발전적인 온라인 및 오프라인 모임, 큰 규모의 한번의 행사보다는 작지만, 내실이 있고 자주 접할 수 있는 행사들이 필요하다고 생각한다. 또한 현업 개발자 들도 지망생들에게 관심을 쏟아야 한다. 개인 대 개인으로 전수되는 게임개발의 지식들, 작업 결과물의 공유와 지망생들의 습작에 관한 평가도 필요하다. 결국 누가 뭐래도 그들이 미래의 한국 게임계를 이끌어나가기 때문이지 않는가?

우리의 장래 기반이라고 할 수 있는 지망생들을 간과하지 말자. 또한 그들이 만들 아마추어 게임 역시 간과하지 말자. 결국 이들이 우리의 미래에 모습이고 우리의 희망이다.
　

마치면서:

저의 글이 누군가에게 도움이 될 수 있을지 의심이 됩니다만, 자신을 가지고 썼습니다. 판단은 역시 읽는 분 들이 하시겠죠. 가장 아쉬운 부분은 제 경험이 정말 미약해서 여러분들에게 크게 도움이 되는 글을 못 썼다는 점 입니다. 1년 후에는 더 노력해서 좋은 모습으로 찾아 뵙겠습니다.

이 글의 핵심적인 기반은 KGDA에서 최주홍(joohong) 님이 쓰신 아마추어 게임제작팀의 미래 -1- , -2- 라는 글에서 얻었습니다.

원문::
아마추어 제작팀의 미래 1
아마추어 제작팀의 미래 2
　

또한 제가 대학시절 친구들과 어설프게 게임을 만들 때의 경험, 그리고 김영환(priling) 님과 아마추어(?) 시절의 체험과 토론에서 나온 내용과 현재 대학에서 청강하고 있는 김광삼(별바람) 교수님에게 배운 내용이 대다수 입니다. 여러모로 저에게 귀감이 되는 안진용(gump)님 을 비롯해서 위에 명시된 모든 분들에게 감사를 표하고 싶습니다. 이로서 저의 첫 번째 KGDC 공개 문서가 끝났습니다. 읽어주셔서 감사합니다.

- 기타 문의 사항 : mal_min99@hotmail.com
- 홈페이지: www.arilab.wo.to

출처 : KGDC 2003 문서강연 참가 글 / 작성자 김의민님 (Nickname : 아리랑피바람 )