게임 소프트웨어 개발 수명주기에서 기획서의 역할

이번에는 약간 논쟁적일 수 있는 주제를 이야기해볼 작정입니다. 게임 소프트웨어를 개발하는 프로젝트에서 기획서가 어떤 역할을 하며 그 수명은 어디까지인지 제 의견을 말해 볼 작정인데 이 의견은 글을 읽으시는 분들의 생각과 상당히 다를 수 있습니다. 지금까지 몇몇 프로젝트를 경험해 보며 서로 다른 문서 작성 요구를 받곤 했는데 이들마다 요구사항은 상당히 달랐습니다. 어느 프로젝트에서는 규모가 꽤 큰 단위 기능에 대한 요구사항을 문서 하나에 모두 서술하도록 했는데 마이크로소프트 워드에서 A4 용지에 인쇄될 것을 고려한 모양으로 작성한 문서는 아주 쉽게 세 자리 수 페이지를 넘기곤 했습니다. 또 다른 프로젝트에서는 단위 기능의 규모를 줄여 이 범위에만 해당하는 문서를 작성하기도 했습니다. 이 경우 게임 전체를 구성하는 수많은 단위 기능을 지탱하는 서로 다른 아주 많은 기획서가 돌아다녔는데 각각의 길이는 그리 길지 않았지만 그 수가 많았기 때문에 어쩌면 한 덩어리로 된 아주 긴 기획서와 크게 다르지 않았을른지도 모릅니다. 또 다른 프로젝트에서는 단위 기능 기반으로 기획서를 작성하되 마일스톤 목표에 해당하는 단위 기능에 집중해 문서를 작성할 것을 요구 받기도 했는데 이는 바로 위에 단위 기능의 규모를 줄인 기획서와 어느 정도 비슷하지만 이 구분이 마일스톤에 의해 강력하게 통제되어 문서가 단위 기능의 맥락이 아니라 마일스톤 자원의 맥락에 따라 작성되는 점이 다릅니다.

기획서를 작성한 다음 유지 보수에 대한 요구사항도 프로젝트에 따라 꽤 달랐습니다. 어떤 프로젝트는 처음에 규모가 큰 단위 기능에 대한 아주 긴 문서를 작성한 다음 이에 따라 개발하되 개발 진행에 따라 변경되는 내역마다 별도의 문서를 만들게 했습니다. 이는 주로 회의록 형태였는데 기획서의 내용을 알고 있다는 가정 하에 회의록에만 집중하면 가장 최신의 개발 의사결정을 쉽게 따라 잡을 수 있고 또 세 자리 수 페이지를 우습게 넘기는 거대한 마이크로소프트 워드 파일을 중간에 수정하기는 굉장히 어려우므로 회의록 작성에만 집중하면 되는 정책은 그리 나쁘지 않았습니다. 또 다른 프로젝트에서는 기획서를 작성해 개발을 시작한 다음 일어나는 여러 가지 변경사항을 기획서에 직접 반영하기를 요구하기도 합니다. 물론 회의록은 회의록 대로 있어야 하지만 이 문서에 의한 수정사항이 기획서에도 반영 되어야 했는데 다행히도 이 때는 이전에 비해 마이크로소프트 워드 문서 하나하나의 길이가 상대적으로 짧은 수 십 페이지 수준이어서 협의에 따라 문서를 수정하기가 그렇게까지 힘들지는 않았습니다. 이 규칙이 잘 지켜지는 동안에 기획서는 언제나 가장 최신의 협의가 반영되어 있었기 때문에 문서에 나열된 요구사항이 실제 빌드와 꽤 가까웠고 이는 이 문서들을 QA 부서에 전달해 테스트케이스를 준비하게 만들거나 신규 인원이 온보딩 할 때 스트레스를 크게 줄여주었습니다. 다른 사례는 단위 기능의 기획서를 작성하고 개발을 진행하며 변경되는 내역을 이전과 같이 회의록에만 기록하지만 기획서가 더 작은 단위 기능에 대한 요구사항만을 서술하고 있어 굳이 회의록에 의한 변경사항을 기획서에 반영하지 않아도 될 수준으로 개발이 마무리되어 문서를 작성하고 관리해야 하는 입장에서는 이 모양이 가장 편했습니다. 하지만 이 문서는 실제 빌드와 꽤 큰 차이가 있었으므로 이 문서를 프로젝트 바깥의 협업 부서에 전달할 수가 없었습니다.