- 다음 글은 제가 활동하는 GAMEDESIGNERZ.NET 기획 스터디 소모임의 발표 자료입니다.
- 내용은 논란의 소지가 좀 있는 것들인데, 경험과 이상이 반씩 섞여 있음을 미리 밝힙니다. 학부 수준의 리
포트 정도로 봐 주시면 감사하겠습니다.
- 관심이 있으신 분들은 한번 읽어보시고 많은 의견과 피드백을 부탁드립니다.
1. 문서화의 필요성
먼저 다음의 2가지를 생각해 보자.
- 게임 기획서는 프로그래머(작업자)들이 읽을 수 있도록 준비되어야 한다.
- 프로그래머(작업자)들은 게임 기획서를 읽지 않는다.(주1)
모순이면서 모순이 아닌, 게임 개발을 경험해 본 사람이라면 누구나 공감할 만한 말이다. 기획서 없이
개발을 진행했다는 예를 이따금 볼 수 있는데(레인보우 식스, R2) 그것은 개발하려는 컨텐츠의 속성과
구성 요소를 개발팀원 모두가 완전히 파악하고 있거나, 애초에 기획이 특별히 필요하지 않는 검증된 피
쳐일 가능성이 높다. 다시말해 2번 항목을 가정하더라도 기획서는 작성되어야 한다.
피쳐 개발에 관련된 기획서는 물론, 그 피쳐가 갖는 목적과 의미 역시 문서화되어야 한다. 게임 개발
을 진행하다 보면 여러가지 의사 결정에 직면하게 되고, 그 과정에서 마찰을 빚는 경우가 적지 않기 때
문이다. 대부분의 마찰은 다음의 2가지 경우에 발생한다.
- 피쳐에 대한 가치가 서로 다른 경우(주로 미적 가치 혹은 게임 완성도에 대한 가치)
- 기획 내용의 요구사항과 구현 비용(혹은 복잡성) 사이에서의 의사결정
이런 의사결정 과정에 직면했을 때 (보통은 말하지 않고 숨겨왔던) 개개인의 비전과 가치들이 갑자기
빛을 발하기 시작한다. 원만한 협의가 이루어지면 좋겠지만, 그렇게 되지 않을 경우도 많다. 문서는 이런
경우 의사결정의 기준으로 사용될 수 있다. 인류에게 기록이 가지는 가치만큼이나, 게임 개발에서 문서화
가 갖는 가치는 크다.
2. 혼자서 만들기 vs 여럿이 만들기
게임 개발 프로세스를 근본적으로 돌아보기 위해서, 혼자서 게임을 만드는 경우를 생각해 보자. 이는
하나의 게임개발 과정 전체에 해당되지만, 게임을 구성하는 개별 컨텐츠에도 똑같이 적용할 수 있다.
물론 이것은 지극히 절차 위주로, 누구나 게임을 만들 때 이러한 사고 과정을 거치지는 않는다. 모든
사고과정이 한 번에 이루어질 수도 있고 일단 만들어 본 후 목적을 다시 생각해 볼 수도 있다. 그러나
각각의 과정마다 생각의 중점이 구별되는 것은 분명하다. 컨셉 기획을 할 때 구현 비용을 가장 중시하
거나, 시스템 기획을 할 때 마음껏 상상의 나래를 펴는 사람은 그다지 많지 않을 것이다.
이번에는 혼자가 아닌, 팀 단위로 게임을 만드는 상황을 가정해 보자. 위에서 본 사고 과정을 개발팀
의 프로세스로 대치해 보면 다음과 같다.
혼자서 만들 때와 달리, 팀 단위의 게임 개발에서는 각 단계가 뚜렷하게 구분되고, 단계마다의 개발 목
표가 분명해진다. 혼자서 게임을 만들 때에는 항상 머릿속에 비전을 그리고 있기 때문에, 구현 단계에서
시스템부터 세부 피쳐까지 한꺼번에 만들어지지만 팀 단위의 개발에서는 각 단계마다 실제로 개발이 진
행되기 때문이다.
3. 기획문서 체계의 필요성
게임 개발에 필요한 기획문서는 쓰는 사람과 목적에 따라 그 형식이 다르고 전달하는 방식도 각기 다
르다. 개발 과정에서 어떤 컨텐츠가 기획되고 구체화되는 과정은 대부분 앞서 살펴본 프로세스를 거치
게 된다. 각 단계마다 기획서가 필요함은 두말할 나위가 없으므로, 개발 프로세스를 각 단계에서 작성되
는 기획서로 대치해 보자.
개발 단계에 따라 작성되는 기획서는 추상적이고 간단한 개념에서 시작해서 점점 구체적이고 복잡한 세
부 사항으로 이어진다. 때문에 문서의 선후 관계에 따라 상위 수준 문서와 하위 수준 문서로 나눌 수 있다.
상위 수준 문서는 언제나 하위 수준 문서의 목적을 포괄하는 내용이 기술되어 있어야 한다. 시스템 기획이
컨셉을 무시하고 있거나, 세부사항은 시스템의 구조를 벗어나는 요소를 가질 수 없다.
여기서 잠깐, 자신의 팀에 1년 이상 쌓여져 온 기획서들을 돌아보자. 과연 수많은 문서들이 이런 간단한
모델로 분류될 수 있을까? 실제 개발에서는 훨씬 많은 문서가 복잡하게 얽혀있기 때문에 결코 쉽지는 않을
것이다.
개발이 진행될수록 기획서의 수가 늘어나기 때문에, 기획문서들은 복잡하게 얽히기 시작하고, 문제를 발생
시킨다. 다음의 몇 가지 예를 살펴보자
A. 새로운 피쳐에 대해 가능성과 비전을 완벽하게 공유한 팀원들은 컨셉 문서를 작성하지 않은 상태로 시스
템을 기획하고 구현한 후 다양한 기능을 추가하였다. 그런데 어느 날부터인가 주요 기능 중 한 가지를 가
지고 이견이 생겨나기 시작했다. 회의는 연일 계속되었지만 의견차는 좁혀지지 않았고, 회의를 하던 모두
는 문득 깨닫게 된다.
‘우리 이거 왜 만들었었지?’
그러나 정확한 목적은 아무도 기억하지 못하고 있다. 누군가 강제로 재단할 때까지 회의(정확히는 싸움)
는 계속된다.
B. 새로운 피쳐의 시스템 기획문서를 작성할 때 목적을 분명하게 하기 위해 각 챕터마다 기획의도를 명시했
다. 이 시스템은 많은 변수와 예외처리를 동반하기 때문에 적용 예도 추가했다. 어쩔 수 없이 분량은 늘어
났지만, 최대한 줄여 10페이지 정도로 했다. 빈틈없는 완벽한 기획서였다. 기획서를 만드는 데 많은 시간
을 들였기 때문에, 문서를 쓴 기획자는 내용을 완벽하게 파악하고 있었다. 각 챕터의 앞부분에 의도가 기
술되어 있으므로 누구나 이 문서를 보면 이 피쳐를 만들 수 있다고 생각하였다.
몇 달 후, 들어온 지 얼마 되지 않은 프로그래머가 이 시스템을 구현하게 되었다. 작업을 위해 프로그래머
에게 이전에 작성된 완벽한(?) 기획 문서를 던져주었다. 그러나 대부분의 내용은 너무 구체적이어서 문서를
전부 읽어보고 이해하는 데에도 긴 시간이 요구되었고, 끝까지 읽기 전까지는 전체적인 아키텍처를 구상할
수 있었다. 구현하는 도중 프로그래머가 기획서를 들고 찾아와 질문을 하면, 기획서를 쓴 사람도 다시 내용
을 찾느라 한참을 헤매곤 한다.
C. 세부 기획서를 작성할 때 여기저기 흩어진 내용을 정리하기 위해서 기획서에 공통으로 추출되는 규칙을 기
술하였다. 이미 구현된 시스템 문서를 볼 필요는 거의 없어졌고, 세부 기획서에 추가된 몇몇 규칙이 포함되
었다. 그런데 어느날 QA파트에서 전투결과 통계에 이상이 있다는 보고가 들어왔다. 시스템을 손보기 위해
가장 최근에 작업한 세부 기획서의 규칙을 찾아보았지만, 원하는 내용을 찾을 수 없었다. 한참이 지나 찾아
낸 원래의 시스템 기획서는 현재 구현된 것과 다른 것이 많았고, 올바른 규칙이 어떤 것인지 다시금 결정해
야 했다.
문서가 일정 이상 늘어나면 위와 같은 상황들이 발생할 빈도가 높아진다. 그러나 문서의 수는 복잡성을
가중시키는 직접적인 이유가 아니다. 보다 정확한 원인은 문서간의 관계가 불분명하거나, 없다는 데에 있다.
문서간의 상/하위 관계, 곧 문서 체계를 미리 준비하여, 그에 맞춰 문서를 작성하면 문서 수가 많아져도
모든 문서를 앞서 설명한 개발단계 모델에 맞추어 정리할 수 있다.
기획문서 체계의 가장 큰 장점은 세부 기획의 변경이나 문제 발생시 그에 대한 의사결정 시간을 단축시켜
준다는 것이다. 상위 문서에는 모두가 동의한 당초의 목적이나 규칙이 명시되어 있으므로, 하위 문서의 변
경 시 기억에 의존한 사견이나 탁상공론을 불식시킨다. 이견은 곧 모두가 동의했던 상위 기획의 변경을 의
미하기 때문이다.
세부 기획서의 수가 늘어나도 상위 문서를 참조하고 있으면 목표를 잃지 않을 수 있으며, 세부 기획서들의
내용이 부득이하게 커졌을 경우에는 세부 기획문서에 1단계 정도를 추가하면 된다. 개발이 일정 이상 진척
되어 있거나, 팀
의 규모가 클수록 문서 체계의 필요성은 더욱 커진다.
4. 체계별 문서의 작성과 활용
A. 비전 문서(주2) – 정책 문서 / 컨셉 문서
정보이용자: 팀원 모두
비전 문서는 가장 상위 수준에 있는 문서를 말한다. 비전 문서는 반드시 해당 피쳐의 기획의도 및 목적을 포
함하여, 비전 문서만 살펴보면 게임의 주요 구성요소가 무엇인지 알 수 있어야 하며, 왜 하는지에 대한 궁금증
을 해소시켜 주어야 한다. 게임의 세계관을 설정한 컨셉 문서, 게임을 구성하는 컨텐츠에 대한 정책 문서가 비전
문서에 해당된다.
정책 문서에는 해당 피쳐에 대한 기본정보와 구현 방향이 있어야 하며, 필요하다면 예상되는 결과까지 기술되
어 있어야 한다. 비전 문서는 해당 피쳐를 구현하는 모든 사항에 대한 기준이 된다. 파일네임 등 아트 리소스를
만드는 데에 공통적인 가이드라인이 발생한다면, 그 역시 하나의 정책으로서 문서화될 수 있다.
컨셉 문서는 게임을 아우르는 세계관이 있을 때 요구된다. 배경 컨셉, 캐릭터 컨셉 등은 이후 만들어질 모든
트 리소스의 미적 기준이 된다.
B. 시스템 기획문서
정보이용자: 해당 피쳐를 담당하는 프로그래머
시스템 기획문서는 어떤 컨텐츠가 만들어지는 데에 관한 규칙들을 담은 문서다. 시스템 기획 하면 수많은 공식이
들어있는 방대한 분량의 문서라고 생각하기 쉽지만, 그것은 시스템이 복잡할 것이라는 가정 때문이다. 문서의 복
잡성이나 분량과 관계없이 시스템 기획문서는 다음의 2가지 요건을 충족하면 된다.
1. 비전 문서의 의도를 반영하고 있어야 한다.
2. 컨텐츠 범주 내의 모든 규칙이 정리되어 있어야 한다.
많다. 혼자서 만들 때 그렇듯이 누구나 큰 그림을 그리고 그를 실행에 옮기는 과정을 그대로 거치지는
않기 때문이다.
하지만 시스템 기획문서는 비전 문서와 분리되는 것이 효율적이다. 비전 문서의 내용이 시스템 기획서
와 섞이면 가독성이 떨어지기 때문이다. 앞서 제시한 예와 같이, 기획서 작성 후 긴 시간이 지난 뒤에 어
떤 정책을 확인하기 위해 문서를 찾을 때 시스템 기획 사이에서 그 의도를 찾아야 한다면 얼마나 불편할
지 상상해 보자. 길드 컨텐츠를 만든다면, 길드 컨텐츠의 기조와 길드 컨텐츠를 만들기 위한 시스템은
분리되어야 한다.
C. 세부 기획문서 – 세부 기획서 / 기능 명세서
정보이용자: 해당 피쳐에 연관된 작업자 모두
시스템 기획은 많은 예측을 동반하지만, 실제로 그 예측이 구체화되는 내용을 모두 담을 수는 없다. 그래서
실제 구현단계에서는 시스템을 이루는 하위 요소나 해당 피쳐에 부속되는 기능을 구체적으로 명시한 세부
기획문서가 요구된다. 큰 구조를 설계하는 과정에서 작은 것들은 무시되기 쉽기 때문에 세부 기획서는 최대
한 구체적으로 기술해야 한다.
세부 기획문서는 특성에 따라 쪼개지거나 합쳐질 수 있다. 단, 시스템 기획문서와는 구별되어야 한다.
D. 작업 명세서 – 리소스 목록, 테이블, 대본 등
정보이용자: 해당 기능(리소스)의 작업자
작업 명세서는 세부 기획서에서 작업에 필요한 내용을 추려낸 것이다. 리소스 목록, 세부기획에 포함되는
테이블, 구조화된 대본 등이 이에 해당된다.
실제로 마지막 마무리를 담당하는 사람에게 정말로 필요한 것은 기능의 구체적인 설명보다는 전환하기 용이
한 포맷이다. 기능의 구구절한 설명을 보고 작업자가 일일히 필요한 것을 결정하는 것보다는, 작업할 리소스
목록이나 바로 붙여넣기 좋은 테이블이 따로 분리되어 있는 것이 훨씬 효율적이다. 시나리오 역시 내용이 확정
된 이상 구현 단위에 맞추어 분리되어 있는 것이 가장 좋다.
세부 기획에서 작업 명세서를 분리해 내는 수고는 작업자의 편의성을 생각하면 충분히 감내할 수 있는 작업이
다. 수십 개의 리소스를 제작해야 하는 작업자의 경우 파일명을 명시한 리스트가 있다면 훨씬 편하게 작업을 할
수 있고, 작업 후의 확인을 위한 체크리스트로도 사용할 수가 있다.
5. 문서 체계의 역전과 확장
문서작성과 그에 따른 개발 단계는 상위에서 시작하여 하위로 진행되지만, 종종 그 순서가 역전되는 경
우가 있다. 어떤 세부기획에서 수정 사항이 발생했을 때, 그 수준에서 끝나는 것이 아니라 시스템 기획에
까지 영향을 미칠 수 있다.
게임플레이를 보완하기 위해 구현 중 기획서를 작성해서 이를 반영한 경우를 상정해 보자. 반영된 요소
는 규칙의 하나가 되므로 시스템 기획문서에 업데이트되어야 하고, 그 요소에 의해 게임플레이의 흐름이
조금이라도 변했다면 비전 문서에 명시된 게임플레이의 흐름에도 변경이 가해져야 한다.
있다. 다음의 예를 생각해 보자
마을에서 길드원들이 모이는 곳에서 의사소통을 위해 이모션 기능을 삽입하였는데, 그것이 열띤 반응을
얻어 유저들에게서 던전을 도는 도중에도 사용할 수 있게 해달라는 요청이 들어왔다.
던전에서의 이모션 기능을 수행하기 위해 추가 작업이 필요함은 물론, 다른 곳에서도 쓰일 경우를 대비
하여 이모션 기능 자체가 범용적 시스템으로 제작하는 추가 작업이 발생할 가능성이 높다. 이모션 기능
자체가 단순한 기능이 아닌 게임 전체를 아우르는 피쳐가 되어 이모션 정책 역시 필요하게 된다.
하위 수준의 피쳐는 언제든지 상위 수준으로 확장이 가능하도록 준비되어 있어야 한다. 아직은 존재하
지 않는 상위 개념을 문서화하여 게임 내의 역할을 규정하고 목표를 설정하는 것은 개발자들이 좀 더 멀
리 보고 일을 진행할 수 있게 도와준다.
기획문서 체계는 2가지 상황에 좀 더 기민하게 대응할 수 있게 해 준다. 문서의 상/하위 체계에
익숙해 있기 때문에, 상위 개념의 변동 가능성이나 새로운 상위개념 설정의 필요성을 보다 빠르게 인식하
게 된다. 앞서 예를 든 이모션 시스템의 경우, 동작을 만들고 구현하는 과정에서 다음과 같은 느낌이 들도
록 해야 한다.
‘어, 이런 거라면 다른 곳에서도 자주 쓰일 것 같은데, 왜 시스템 기획서가 아니라 세부 기획서밖에 없지?’
유저의 아우성이 시작되기 전에, 이모션 기능은 하나의 게임 내 컨텐츠로서 범용적으로 준비될 수 있을 것이다.
6. 마치며..
발표를 준비하면서 큰 회사의 경우에는 문서 체계가 존재하는지 몇몇 분들에게 여쭈어 보았는데, 처음부터 그런
체계가 있었다는 경우는 없었고, 개발이 진행되면서 체계 비슷한 것이 생겨나는 정도였다고 한다.
필자의 개발팀에서도 위에 설명한 요소를 전부 반영하지는 못하고 있다. 어떤 문서들은 기획문서 체계에 맞추어
분류할 수 있지만 그러기에 모호한 문서들이 많고, 무엇보다도 이슈가 발생할 쓸 때마다 상위 개념을 도출해서 문
서화하거나, 시스템 기획문서에 규칙만을 정의하는 것 역시 쉽지는 않은 일이었다.
그러나 체계화된 문서는 분명 힘을 발휘했다. 시스템을 파헤치다가 기조가 궁금해지면 비전 문서를 보고, 비전 문
서를 읽다가 세부 구성 요소가 어떤 것이 있었는지 궁금해지면 비전 문서가 포괄하는 폴더를 찾아 들어가기만 해도
되었다. (비전 문서에 해당되는 하위 문서들을 묶어서 관리하는 방법은 추후에 살펴보기로 한다.)
물론 팀마다 고유의 개발 프로세스와 문서작성 방식이 있기 때문에 여기서 설명한 기획문서 체계를 바로 적용하기
는 힘들 것이라고 생각한다. 매번 체계에 맞추어 문서를 분리 작성하는 것 역시 상당한 수고를 필요로 한다. 하지만
상위 수준과 하위 수준 문서의 관계 설정이 갖는 이점을 생각하면 한번쯤 팀 내 문서들에 대해 체계를 도입해 보는
것도 좋을 것이다.
또한, 위의 내용은 기획문서 폴더정책과 버전 관리라는 또다른 원흉(?)을 고려하지 않은 가정으로, 이 쪽은 추후
현재의 모델에 하나씩 올려놓으면서 생각해 보기로 하자.
'게임 > 게임 이야기' 카테고리의 다른 글
| [ETC] 헬게이트:런던 런칭파티 후기 (0) | 2008.01.12 |
|---|---|
| [ETC] SFC형님의 바깥나들이 (0) | 2007.12.09 |
| [XBOX360] 오렌지 박스 - 포탈 (0) | 2007.11.02 |
| [XBOX360] 기타 히어로 3 데모버전 (0) | 2007.10.28 |
| [XBOX360] 버추어 파이터5 데모버전 (0) | 2007.10.15 |
