현실적인 기획서

기획서를 쓰는 일을 직업을 가지고 살고 있으면서도 아직 까지 기획서를 잘 쓰는 방법, 잘 유지하는 방법을 잘 모르겠습니다. 여러 조직에서 기획서에 서로 다른 여러 가지 의미를 부여하는 모습을 본 적이 있습니다. 어떤 조직에서는 기획서야말로 게임 전체의 설계도와 같기 때문에 심혈을 기울여 작성해야 하고 또 한 번 작성한 기획서는 개발을 진행해 가면서 어지간히 큰 이유가 없다면 함부로 수정하지 않아야 한다고도 배웠습니다. 이 조직에서 작성한 기획서는 항상 대단한 분량을 자랑했는데 이런 문서를 작성하기 쉽지 않기도 하지만 한편 수정하기는 더더욱 쉽지 않았는데 기획서를 함부로 수정하지 않아야 하는 이유는 그저 문서 자체를 수정하기가 엄청나게 어렵기 때문이 아닐까 싶기도 했습니다.

한편 다른 조직에서는 기획서를 작성하는데 긴 시간을 사용하지 말라는 주문을 들었습니다. 기획서는 개발을 시작할 아이디어를 정리하는데 목적이 있으며 일단 실제 개발을 시작하면 다양한 사람들이 관여하고 이들로부터 다양한 의견이 나오며 상황 자체도 계속해서 변할 수 있기 때문에 기획서를 작성하는데 시간을 사용하기 보다는 일단 최소한의 내용으로 개발을 시작하고 그때그때 상황에 맞는 의사결정에 따르자는 관점입니다. 여기서는 개발 후반에 접어 들어 개발팀 바깥의 협업 부서들이 나타났을 때 이들과 협업을 시작하기 상당히 어려웠는데 이유는 이들이 다른 개발팀에 있을 법한 기획서를 받을 수 있기를 기대하고 있었기 때문입니다.

이들이 예상한 기획서는 위에 설명한 전통적인 개발팀의 두툼한 기획서와 거의 그대로 개발된 게임이었는데 우리가 가지고 있던 것은 개발을 시작하기 위한 최소한의 아이디어를 기술한 짧은 문서와 그때 그때 의사결정에 사용한 자료, 그리고 의사결정을 기록한 회의록에 가까운 문서들 뿐이었습니다. 아무래도 이런 문서들을 그대로 전달할 수는 없겠다는 생각이 들어 이 문서들을 정리하려고 시도하다가 제한시간 안에 문서를 정리해 팀 밖에서 예상한 ‘기획서’에 가까운 문서를 전달할 수는 없겠다는 판단을 하고 양해를 구한 다음 팀에 돌아다니는 문서를 그냥 있는 그대로 전달하고 일을 시작했는데 그 다음에 이 분들을 다시 만날 때 그 분들의 흔들리는 눈빛을 잊을 수가 없습니다.

 이런 서로 어느 정도는 반대쪽 끝에 있을 것 같은 두 조직의 두 가지 기획서 쓰는 스타일에 따라 일을 하면서 기획서라고 납작하게 눌러 부르는 이 문서는 어느 정도 수준으로 시작해야 하고 또 어느 정도 수준까지 개발 상황을 따라가야 할 지에 대해 생각해 보곤 했는데 여전히 적절한 답을 모르겠습니다. 이 글은 이 질문에 대해 고민해 본 최근의 경험에 대해 설명하고 이 경험에 따라 2023년 봄 현재 가지고 있는 의견을 설명하기 위한 것입니다.

먼저 시간이 흐를 수록 기획서를 작성하는데 물리적으로 필요한 시간을 점점 더 확보하기 어려워지고 있습니다. 팀에 따라 기간은 다르지만 일정 기간을 마일스톤이라고 선언한 다음 그 기간 안에 모든 팀이 목표로 삼은 기능을 개발하며 개발 진행 상황이나 속도를 관리하곤 하는데 마일스톤이 시작됨과 동시에 주요 목표의 기획서를 작성하기 시작합니다. 그런데 기획서를 작성하는데는 물리적으로 시간이 필요한데 이 시간 동안 기획서를 보고 작업을 시작해야 하는 다른 부서들은 기획서들이 근거로 삼은 마일스톤 계획을 보고 미리 예상되는 준비를 하고 있거나 마일스톤 목표와 관계 없는 다른 작업을 하며 기획서를 기다려야 하는 상황이 일어납니다. 만약 기획서를 작성하는 부서 안에서 의견 차이가 생겨 이를 해결하는데 시간을 사용할 수록 이 결과에 의한 기획서를 바탕으로 개발을 시작하는시점은 마일스톤 뒤쪽으로 점점 더 밀리게 되는데 보통 이런 의견 차이가 생기는 기능은 마일스톤에 중요한 기능인 경우가 많아 마일스톤에 중요한 기능인데도 개발 시간을 충분히 확보하지 못하는 이상한 현상이 일어납니다.

마일스톤 후반으로 가서 중요한 기능이 충분히 개발되지 않은 상황을 모면하기 위해 기획서가 작성되는 시간 동안 기다린 시간을 감안해 손쉽게 기획서를 작성하는 부서를 문제의 원인으로 지목할 수 있고 이런 지목은 보통 쉽게 용인되어 기획서를 작성하는데 걸리는 시간을 단축하라는 주문으로 돌아오곤 합니다. 이런 상황 속에서는 전통적인 바이블 스타일 기획서를 작성하기는 불가능합니다. 오히려 처음에 설명한 두 가지 사례 중 두 번째 사례인 기획서는 이 기획서의 목표와 첫 번재 방법을 제안하는 수준의 최소한으로 작성하고 이 문서에 기반해 바로 개발을 시작하며 이후에 일어나는 문제와 의사결정은 그때그때 상황에 따르는 방법으로 개발하는 편이 낫습니다.

이런 개발 방법에서 기획서는 개발을 시작하는 순간까지는 유효하지만 개발이 진행되어 감에 따라 순식간에 실제 개발 상황을 반영하지 못하게 됩니다. 개발 현황을 기록하고 개발을 진행하는 과정에 수행한 의사결정을 별도로 기록한 낱낱의 문서들은 이들을 모두 읽고 머릿속에서 내용을 종합하면 현재 개발 상황을 따라가는데 도움이 될 것이 분명하지만 각각의 문서를 따로 떼 놓고 보거나 전통적인 기획서를 읽는 느낌으로 문서를 읽으면 기획서의 상태와 개발된 상태가 서로 전혀 일치하지 않는 상태를 볼 수 있을 뿐입니다.

이런 상황에서 기획서는 개발을 처음 시작할 때 목표를 공유하는데 사용되는 문서일 뿐이며 그 이후에 기획서는 개발 상황을 따라가지 않고 그저 개발에 참여한 사람들의 의사소통 보조 수단으로만 사용됩니다. 맨 처음 시작한 문서를 제외한 나머지를 기획서라고 부르기는 어려울 겁니다. 만약 개발 후반에 개발에 참여하지 않은 부서의 협업을 요청할 경우에는 이때까지 도출한 문서들을 어느 정도 합쳐 기획서와 비슷한 모양으로 만들어 한 번에 현재 개발 상황을 따라가는 문서로 만든 다음 외부에 공유하는 정도가 기획서라고 부를 수 있는 문서의 전부에 가깝다고 생각합니다.

 기획서는 개발 상황을 어디까지 따라가야 할까요. 전통적인 바이블 스타일의 기획서는 분명 문서 자체만 놓고 보면 그럴싸한 모양이지만 작성하는데도 유지보수하는데도 엄청난 비용이 듭니다. 이 방법은 이상적이지만 이 이상을 달성하기 위해 필요한 자원을 지불할 준비가 되어 있지 않다면 애초에 꿈 꾸지 않는 편이 낫습니다. 깨끗하고 멋진 문서는 보는 사람 기분을 좋게 하지만 그런 문서를 관리하는데는 몇 명을 예상했든 그 인원의 두 배가 필요하니 함부로 시도할 생각을 하지 않는 편이 좋습니다.

게임 개발은 요구사항이 불분명한 상태로 진행되며 진행 과정에서 요구사항이 점점 더 정확해지는 경우가 많으므로 처음부터 온전한 기획서에 기반해 개발을 시작하는 건 불가능하다고 인정하고 기획서는 개발을 시작할 때 참여하는 인원들에게 목표를 공유하는 용도 정도로 활용할 문서 수준에 마무르는 편이 좋다고 생각합니다. 이 관점에서는 첫 기획서 이후에는 개발 진행에 따른 의사결정을 기록한 문서들이 나타나며 다른 팀과 협업 시점이 오면 이들을 대강 갈무리한 문서가 추가로 생산되는 수준으로 기획서가 개발 진행상황을 따라가는 것이 현실적인 기획서 작성 수준입니다.