소규모 제작팀의 문서

파이드 파이퍼스에서 실제 풀 타임으로 작업을 하는 인원을 단 둘일 뿐이긴 하지만, 프로젝트 진행 전반에 대한 문서화는 빼먹지 않고 진행을 하는 편이다. ‘달랑 둘이서 작업하면서 그냥 말로 해결하는게 편하지 않나?’ 같은 생각이 들 수도 있지만, 소규모 팀에서의 문서는 소통 수단으로써의 기능 보다는 프로젝트에 대한 ‘기록’으로써 작동을 한다고 보는 편이 좋을 것이다.

초창기에 게임 아이디어 등을 정리 할 때는 게임 시스템의 매카닉을 자세히 전달 할 필요가 있었기 때문에 MS 워드 등을 통한 세부적인 정리가 필요하였고, 이에 따라서 AnS 프로젝트의 중반까지도 이러한 기능 사양의 정리-그러니깐 여러분이 익히 잘 알고 있는 ‘기획서’ 라는 문서는 계속적으로 갱신이 되고 있었다. 전통적인 대규모 제작 팀에서 사용되는 기획 문서의 정리는 게임 디자이너가 정리하고, 이를 토대로 프로그래머, 아트 디자이너 등이 작업을 하는 형태였고, 이는 파이드 파이퍼스에서도 그대로 유지 되었다.

위키백과 공용 – CC BY-SA-3.0

이러한 전통적인 방식의 한계는 곧 다가왔는데 2013년 2월에 실시한 프로젝트 전면 개정 선언 이후 정신없이 바뀌어가는 게임 디자인을 기존과 같이 문서화하는 것은 몇 가지 이유로 불가능 했었다.

우선 짧은 기간동안에 많은 변경 사항과 실험이 진행되고 있었기 때문에 기존과 같은 형식(이것은 정형화된 문서 양식으로 편집하는 일을 포함하고 있었다)으로 문서를 정리 할 여력이 없었다. 게임 디자이너는 문서 만들 시간에 시스템에 대해서 한 번이라도 더 검증하기 위하여 사고 실험을 행하는 쪽을 우선하였고, 게임 시스템에 대한 디자인이 완료된 이후에는 테스트 및 수정을 반복했었기 때문에 전통적인 방식의 문서화의 의미가 퇴색하고 있었기 때문이었다-어차피 바뀔 문서를 수정한다고?

거기에 더하여 MS 워드 등으로 작성된 문서의 변경점은 작성자 이외의 사람이 ‘변경 추적’을 하는 것이 대단히 까다롭게 되어 있었다는 문제가 가장 컸다. MS 워드의 경우 이전 버전과 비교를 보여주긴 하지만, 대단히 복잡한 인터페이스로 인하여 사람 잡는 화면을 출력하곤 했다.

문서를 보기 전에 ‘뭐, 어쩌라고?’ 싶어지는 화면

물론 그렇긴 하더라도 ‘기록’으로써의 문서의 가치가 없어지는 것은 아니었기 때문에 MS워드보다 빠른 문서화 및 이슈 추적 도구가 필요했고, 프로젝트 전면 개정 때의 생산 문서는 다음과 같이 관리되고 있었다.

  • 모든 기본 제안서, 문서는 구글 드라이브(Google Drive – Google Docs의 클라우드 버전)를 이용하여 빠르게 편집하고 공유했다. 간단한 양식을 적용하여 변경점이나 개선점에 대한 것은 바로바로 수정하고 수정 부분에 대한 내용(바뀐점 위치라던가, 추가 문서 여부 등)을 구두로 전달하거나, 문서의 메모 기능 등을 철저하게 이용했다.
  • 구글 드라이브의 문서를 기준으로 맨티스(Mantis) 같은 이슈 트래커(Issue Tracker) 에 진행해야 할 업무에 대한 기록을 하고 이슈를 관리하였다 – 사실 이것은 팀 초창기부터 진행되어오던 프로세스였다.
  • 작업 완료로 더 이상의 수정이 필요 없는 문서들은 태그를 부여하고 별도의 폴더(구글 드라이브의 폴더)에 보관하였다(이 문서들은 현재 맨티스의 이슈 기록, 게임 결과물 등을 중복체크하여 ‘최종 기획 문서’ 형태로 재가공 중에 있다).

팀의 규모와 상관 없이 문서화는 대단히 귀찮은 일 중에 하나이다. 하지만, 문서화를 등한시 했을 때의 참사(다른 무엇보다 기록이 없어서 프로젝트에 대한 개선이 불가능해진다)를 생각한다면 아무리 소규모 팀이라고 하더라도 프로젝트에 대한 기록을 남기는 것은 대단히 중요한 일이다. 때문에 게임 디자이너는 (소규모 팀이라고 하더라도)어떠한 방법을 강구해서라도 기록을 남기고 정리하는 일을 게을리 해선 안된다고 생각한다.

기록을 남기지 않으면, 미래는 없다. 이는 딱히 역사에만 국한된 이야기는 아니다.