1분 동안 설명한 시스템기획서 쓰기

작년에 인턴십 면접을 보면서 면접을 끝내기 전에 들은 질문 중 기억에 남는 것이 하나 있습니다. “시스템기획서는 어떻게 쓰는가” 였는데 기획서를 쓰는 방법에 대한 질문이라기보다는 회사에서 일하는 당신은 시스템기획서를 어떻게 쓰느냐는 질문에 더 가까웠습니다. 이미 면접을 통해 이 분이 학교에서 게임 개발 관련 커리큘럼을 이수하며 겪은 답답한 장면들을 대략 머릿속에 그리고 있었습니다. 게임 개발을 교육한다고 해서 갔는데 거기에는 게임 개발을 가르칠만한 사람이 없었습니다. 학생들도 그걸 알았고 학교에서 제시하는 커리큘럼으로는 경쟁력이 부족하리라는 사실을 짐작한 끝에 나온 질문이었을 겁니다. 연달아 면접 일정이 잡혀 있어 짧게 설명해봤습니다.

먼저 요구사항을 분석합니다. 이 단계의 목표는 요구사항을 제시한 사람과 시스템기획서를 작성할 내가 머릿속에 같은 그림을 그리는 것입니다. 요구사항을 제시하는 사람은 PD나 디렉터일 수도 있고 나 자신일 수도 있습니다. 심지어 나 자신의 요구사항을 내 스스로가 잘 이해하지 못하기도 합니다. 요구사항을 제시한 대상을 반복해서 인터뷰하고 각 인터뷰 시도마다 지난 시도로부터 비슷한 사례를 조사하고 다양한 미디어로부터 설명을 대신할만한 방법을 찾아봅니다. 글을 쓰거나 그림을 그릴 수도 있습니다. 그림은 드로잉일 수도 있고 다이어그램일 수도 있습니다. 요구사항을 제시한 사람과 시스템기획서를 작성할 나 사이에 - 그게 같은 사람이라고 할지라도 - 최대한 같은 생각을 가지고 있다고 판단할 수 있을 때 다음으로 넘어갑니다.

이제 이 요구사항이 실제 게임에 반영된 결과를 시각적으로 설계합니다. 요구사항은 완결된 컨텐트 하나일 수도 있고 인터페이스일 수도 있고 새로운 기능을 가진 NPC일 수도 있습니다. 현대의 모바일 게임은 게임 메커닉의 상당 부분을 인터페이스로 표현하므로 요구사항이 게임에 적용된 모습을 화면 단위로 설계한다고 생각하면 이해하기 편합니다. 장비강화 기능이라면 이 기능에 처음 진입하는 방법, 강화할 장비를 선택하는 과정, 강화 재료를 넣는 방법, 강화 시도, 결과 표시, 연속 강화 같은 각 단계를 화면으로 그려봅니다. 이 과정을 통해 요구사항이 실제 게임에 반영하며 일어나는 ‘예상하지 못한 동작’을 추가로 생각하고 정의할 수 있습니다.

앞에서 작성한 화면을 기준으로 동작과 데이터구조를 정의합니다. 사실 동작은 화면을 설계하는 과정에서 어느 정도 규명되었을 겁니다. 데이터구조는 화면 각각과 일치하지는 않지만 화면 각각을 만들어내기 위해 필요한 정보를 우선 화면 단위로 정의한 다음 중복을 제거하고 이들 사이에 관계를 정의하고 나면 더 빨리 의미있는 데이터구조를 설계할 수 있습니다. 이미 진행 중인 프로젝트라면 이 과정을 건너뛰고 이미 사용 중일 데이터구조를 가져와 각 화면을 구성하는데 필요한 정보를 나열하고 각 정보를 가져올 방법을 정의합니다. 이제 화면과 데이터를 가져올 방법에 의해 대부분의 동작이 정의되었고 여기 사용할 데이터구조 역시 정의되어 있을 겁니다.

이 다음은 문서를 정리해 개발을 진행할 단계인데 여기부터는 처음 설명하려고 한 시스템기획서 작성 요령의 범위를 넘어서기도 하고 더 설명할 시간도 없어 대강 마무리했습니다. 갑작스런 질문이었는데 답변이 됐을지 좀 걱정스럽기도 하고 또 게임 전문 교육기관에서 이런 요령을 설명해주지 않는다면 그들은 대체 무엇을 가르치고 있는지 조금 걱정스럽기도 했지만 이내 생각을 멈추고 다음 면접으로 넘어갔습니다.