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

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

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

이런 사례들을 살펴보며 게임 소프트웨어 개발 프로젝트의 생애주기에 따라 우리들이 작성한 기획서가 어떤 모습이어야 하는지, 또 어떻게 유지보수 되어야 하는지 제 의견을 설명하겠습니다. 결론부터 말하면 기획서는 개발을 시작하기 위해 필요한데 기획서의 역할은 딱 거기까지라고 생각합니다. 이 말은 기획서가 처음 작성되어 요구사항이 빌드에 가져올 구체적인 변화와 이 변화의 목적을 협업 부서들 간에 온전히 이해하는데 기여하고 개발이 시작되었다면 기획서는 이 시점에서 그 역할을 다했고 이 다음부터는 개발 진행에 따라 나타날 변경 사항을 그때그때 협업 부서들이 모두 간단히 인식할 수 있도록 기획서와 구분된 짧은 문서로 그때그때 공유하는 수준이면 충분합니다. 물론 한참 개발을 진행하다 보면 여러 가지 이유로 애초에 이 업무의 근본적인 목표가 무엇이었는지 잊어버리고 눈 앞의 아주 작은 문제에만 시야를 유지할 때가 있습니다. 이럴 때 다시 처음 일을 시작할 때 사용한 기획서를 끄집어내 분명 그 문서에 포함되어 있을 이 일의 목표, 게임에 구현되었을 때의 모습 따위를 다시 확인하는데 사용할 여지는 있지만 이 목적에 대응하기 위해 그때그때 변경사항을 기획서에 반영할 필요는 적거나 없습니다. 게임 소프트웨어 개발 상애주기에서 기획서는 협업 부서들이 목표를 이해하고 각자의 일을 시작하는 그 순간 까지 유효하며 이 시점에 기획서는 그 역할을 다했으므로 이 문서를 지속적으로 업데이트 하며 자원을 낭비할 필요가 없습니다.

이 관점에서 종종 일어나는 ‘기획서가 빌드 상태와 다르다'거나 ‘최신 상태를 파악하기 위해 여러 문서를 봐야만 한다’는 불평은 애초에 각자의 목적을 이미 그 역할과 수명이 끝난 잘못된 문서를 보고 있기 때문이며 이 불평 또는 문제에 대응하기 위해 기획서를 업데이트 하는 행동은 잘못되었다고 생각합니다. 우리들이 하고 있는 일의 근본적인 목적은 동작하는 소프트웨어를 개발해 고객에게 전달해 고객들이 우리가 의도한, 혹은 의도하지 않은 경험을 하도록 만드는 것입니다. 이 과정에서 회사가 이익을 얻을 수 있으며 이를 통해 우리들이 매 월 같은 날 급여를 받아 생계를 유지합니다. 이 상황에서 가장 중요한 부분은 우리들이 하는 일은 동작하는 소프트웨어를 개발하는 일이라는 것입니다. 우리들이 하는 모든 일은 그게 무엇이든 결국 동작하는 소프트웨어를 만드는 것입니다. 문서를 만드는 일, 회의를 하고 나서 회의록을 작성하고 액션 플랜을 도출해 이들의 수행 여부를 관리하는 일, 아트 에셋을 제작하는 일, 클라이언트 및 서버 코드를 작성하는 일, 인하우스 툴 코드를 작성하는 일, 데브옵스 코드를 작성하고 관리하는 일 모두는 좁은 시야로 보면 각자의 목적을 달성하기 위한 것이지만 시야를 조금 넓혀 보면 결국 동작하는 소프트웨어를 만들어 고객에게 전달하기 위함입니다. 그래서 각자의 작업이 올바르게 수행되고 있는지, 그리고 각자의 작업이 효율적이고 또 의미 있는 작업인지를 평가하기 위해서는 모두가 소프트웨어를 개발하고 있다는 사실에 기반해 생각해보면 됩니다.

기획서 이전에 게임디자인 부서에서는 고위 의사결정자의 요구사항에 기반한 제안서를 작성하곤 합니다. 고위 의사결정자의 스타일에 따라 누군가는 자신의 요구사항을 제대로 된 문서를 통해 전달하기도 하고 또 다른 누군가는 지라 에픽 모양으로 제시하기도 합니다. 반면 누군가는 그저 말로만 요구사항을 전달하기도 하며 심지어 또 다른 고위 의사결정자는 아예 요구사항을 말하지 않아 우리들이 제안을 만들어 오히려 고위 의사결정자의 승인을 받아야 하는 이상한 상황 속에 일하기도 합니다. 어느 쪽이든 우리들이 작성한 제안서는 최소한 프로젝트 전체의 고위 의사결정자들과 게임디자인 부서 내의 동의를 획득하는데 사용되며 이후 기획서를 작성하는데 근거 자료로 사용됩니다. 즉 제안서는 요구사항이 처음 발생해 게임디자인 부서 내에서 동의를 이끌어내는 핵심 동작을 수행하는데 사용되며 그 수명은 이후 기획서가 작성되고 나면 끝납니다. 특정 단위 기능에 대한 기획서가 작성되었다면 이 시점에 제안서는 사실상 쓸모가 없습니다. 이미 게임디자인 구성원들의 합의를 이끌어냈고 고위 의사결정자도 명시적 또는 묵시적으로 동의했으며 이에 기반해 요구사항을 기입한 기획서가 완성되었기 때문입니다. 제안서는 이제 미래의 누군가에 의해 전체 히스토리를 따라잡는데 사용되거나 그저 개발 과정의 히스토리 그 자체로 남을 뿐 제안서가 직접적으로 어떤 역할을 수행할 일은 없습니다.

이 과정에서 작성된 기획서는 이제 본격적으로 그 목표와 요구사항을 포함하고 있습니다. 기획서를 통해 이 단위 기능의 목적이 무엇인지 인식하고 또 이 단위 기능이 빌드에 포함되고 나면 빌드가 현재 모습과 비교할 때 어떻게 변화할지 예상할 수 있습니다. 또 그런 변화를 위해 구체적인 기능의 동작 방법, 이들이 기초할 데이터, 여기에 필요한 에셋 등 요구사항을 달성하는데 필요한 여러 항목 중 게임디자이너가 생각해낼 수 있는 범위헤 국한된 내용을 포함합니다. 이상적인 기획서는 마치 자동차나 항공기의 설계도처럼 그대로 만들기만 하면 완제품에 도달할 수 있는 문서여야 할 것 같지만 실제로는 전혀 그렇지 않습니다. 가장 큰 이유는 이 문서를 작성하는 역할을 맡은 소위 게임디자이너들 상당수가 각자가 담당한 좁은 분야에는 전문성을 가지고 있을 수 있지만 근본적으로 이들이 종사하는 소프트웨어 개발에는 충분한 전문성을 가지고 있지 못할 가능성이 높기 때문입니다. 기획서에 이 기능이 동작할 때 근거로 삼을 데이터구조를 포함하겠지만 이는 컴퓨터과학 분야에서 지난 수 십 년에 걸친 연구와 개발의 결과로 도출된 데이터구조를 흉내낼 뿐 그런 구조와 표현 방법이 왜 필요한지 이해하지 못할 겁니다. 또한 기획서에는 기능에 필요한 다양한 에셋을 나열하고 또 프로젝트의 정책에 따라 각각의 에셋을 발주할 문서를 별도로 작성하겠지만 게임디자이너는 높은 확률로 각각의 에셋이 프로젝트 전체 관점에서 통과할 파이프라인을 이해하지 못하고 있을 겁니다. 그래서 기획서는 게임디자이너 관점에서 단위 기능을 개발하는데 필요하다고 예상되는 정보를 포함하고 있을 뿐 이 문서에 따라 개발한다 해서 목표에 도달할 수 있는 상태가 전혀 아닙니다.

심지어 잠깐 언급했던 자동차나 항공기 같은 제조 분야에서도 설계도에 따라 개발한다고 해서 항상 예상한 결과에 도달할 수 있지도 않습니다. 가령 설계 대로 제작했더니 강성이 부족해 휘지 말아야 할 곳이 휘어지거나 새지 말아야 할 것이 새거나 움직이지 말아야 할 것이 움직이는 등 다양한 문제가 일어날 수 있습니다. 또한 제작 과정에서도 현재 공장이 보유한 장비로는 설계도가 요구하는 크기의 부품을 생산할 수 없거나 지금 시장에서 설계가 요구하는 재료를 입수할 수 없을 수 있습니다. 이런 다양한 상황에 따라 실제 개발되는 제품은 처음 작성한 설계도와는 상당히 다른 모양이 될 가능성이 높으며 이는 소프트웨어 개발 뿐 아니라 제조업 전반에 당연하게 나타나는 현상입니다. 소프트웨어 역시 마찬가지입니다. 기획서를 작성할 때 까지만 해도 엔진 제조사에서 홍보한 새로운 기능이 잘 동작할 거라고 예상해 비용을 낮게 예측했지만 실제 개발을 시작해 보니 제조사는 아직 홍보한 기능을 온전히 마무리 하지 못해 우리들이 이 기능을 사용해 우리 게임을 개발하고 있는 것인지 아니면 테스트를 수행해 엔진 제조사에 버그 리포팅을 하고 있는 것인지 헛갈릴 때도 있습니다. 또 이미 완전히 굳어진 클라이언트 - 서버 아키텍처 상 요구사항을 달성할 수 없다는 사실을 늦게서야 발견해 요구사항 달성을 위해 새로운 기반 개발이 필요하다는 사실을 마주할 수도 있습니다. 이런 온갖 이유 때문에 제조에서도 설계에 따라 변화 없이 완제품에 도달할 수 없으며 게임 소프트웨어 개발에서도 기획서에 따라 동작하는 빌드에 도달할 수 없습니다.

소프트웨어 개발 과정은 문제 해결의 연속입니다. 게임디자이너가 자신의 부족한 지식과 좁은 시야에 기반해 제안한 요구사항은 그대로 만들면 동작하기는 하겠지만 엔지니어 관점에서 완전히 다른 접근을 통해 같은 동작을 하지만 더 나은 설계를 제안할 수 있습니다. 또 게임 업계의 특성 상 기능 개발에 참여하는 협업 부서의 구성원 각각이 다른 게임의 고객일 가능성이 있으므로 이들의 의견을 평가해 요구사항을 더 나은 방향으로 수정할 수도 있는데 이 역시 기획서는 일을 시작하는 역할을 할 뿐 이후 진행 과정에서 일어나는 변경에 관여하지 않습니다. 물론 마일스톤이 끝나갈 때 기능이 준비된다면 아마도 이 기능은 기획서를 통해 예측할 수 있는 모양과 아주 다르지는 않을 겁니다. 하지만 그 과정, 그리고 그 기능이 동작하는 내부 구조나 요구하는 에셋, 데이터 모양 따위는 처음 기획서에 언급된 모양과는 상당히 다를 수 있습니다. 하지만 빌드를 통해 기능이 처음 의도한 목적을 달성하기만 한다면 이 기능의 내부가 어떻게 동작하든 별로 중요하지 않습니다. 이 시점에 기획서에 중요한 부분은 이 단위 기능이 동작할 때 게임에 미치는 영향, 그러니까 소위 ‘목적’ 뿐입니다.

그래서 개인적으로는 처음 기획서를 작성해 단위 기능의 개발을 시작하면 기획서는 그 시점에 수명을 다하고 더 이상 업데이트 될 필요가 없다고 생각합니다. 일단 개발을 시작하면 제조와 마찬가지로 온갖 시행착오를 겪으며 개발될 것이 거의 확실하며 이 과정에서 목표와 목적을 제외한 나머지 모든 것이 변할 수 있습니다. 이 과정에서 문서 작성에만 매달리는 별도 스탭이나 조직이 있지 않다면 개발 과정의 하위 의사결정을 담당하고 협업 부서들 사이를 조율하는 역할을 함께 담당하는 이전에 기획서를 작성했던 게임디자이너가 협의를 기록한 소위 회의록을 작성하고 액션 플랜을 도출하고 이들을 추적하는 일 뿐 아니라 처음 작성했던 기획서마저 업데이트 하기를 기대하는 것은 올바르지 않습니다. 이는 한 사람이 할 수 있는 일의 범위를 아득히 초월하기 때문이며 애초에 그런 일을 할 필요가 없기 때문이기도 합니다. 시행착오가 확실히 예상되는 업계에서 기획서가 개발 주기의 어느 시점에나 항상 빌드의 현재 상태를 반영하는 모양으로 수정되어 있기를 바라는 것은 기획서의 의미를 지나치게 확대 해석했기 때문이며 이런 요구사항은 달성할 수 없습니다. 차라리 소프트웨어 개발업의 속성 중 일부가 제조업의 그것과 비슷하다는 사실을 인정하고 기획서의 역할이 끝나면 미련 없이 버리도록 해 담당자들의 부하를 낮춰야 합니다.

물론 프로덕션 진행의 어느 시점에는 현재 빌드의 상태와 의도를 대응 시켜 기술하는 어떤 문서가 필요한 것은 사실입니다. 가령 수직계열화 되어 있지 않은 QA 부서와 협업하려면 이들이 참고할 빌드와 빌드를 설명하는 문서가 필요합니다. 이들 각각에 기반해 테스트 케이스를 작성하고 문서를 살펴보며 개발팀의 의도를 이해하고 이 의도에 따라 빌드를 테스트 해야 하기 때문입니다. 이 과정에서 쉽게 ‘기획서’를 전달하기 위해 이미 오래 전에 수명이 끝난 기획서를 끄집어내 현재 동작하는 빌드를 살펴본 다음 실제 빌드에 변경된 동작을 반대로 기획서에 반영하는 행동을 요구 받기도 하고 실제로 이런 일이 일어나기도 하지만 이는 기획서의 역할을 너무 광범위하게 보고 내린 잘못된 지시라고 생각합니다. 기획서는 이미 개발을 시작하는 시점에 그 수명을 다했고 이미 동작하는 빌드가 존재한다면 이를 수직계열화 되지 않은 협업 부서에 전달하기 위해 작성해야 하는 문서는 기획서가 아닙니다. 또한 기존 기획서를 수정하려는 우리 모두를 불행하게 만드는 시도를 하는 대신 현재 빌드의 상태와 의도를 설명하는 이 시점의 목적에 정확히 맞는 문서를 다시 작성하는 편이 문서 작성 난이도를 훨씬 낮출 겁니다. 이 때 필요한 것은 기획서가 아니며 기획서의 수명은 이미 오래 전에 끝났다는 사실을 생각하면 새로운 문서를 만들어야 한다는 당연한 사실을 쉽게 납득할 수 있을 겁니다.

기획서는 종종 제조업의 설계도에 비유되며 이 대로 개발 또는 제작할 때 예상할 수 있는 결과에 도달할 수 있다고 알려져 있지만 소프트웨어 개발업에서도, 제조업에서도 실제로는 그렇지 않습니다. 개발 진행에 따라 온갖 시행 착오를 겪으며 목표에 도달하게 되며 이 과정에 다양한 문서가 생산될 수 있습니다. 하지만 이 문서들은 각각의 시점에 의사결정을 뒷받침해 동작하는 빌드를 만들어내는데 기여하면 충분하며 이들이 다시 ‘이미 시작된 개발에 기여한’ 기획서에 다시 반영될 필요가 없습니다. 빌드의 최신 상태를 반영한 문서가 프로젝트 바깥의 협업 부서에 전달될 필요가 있을 겁니다. 하지만 이 때 전달 되어야 하는 것은 개발을 시작하는데 사용하는 기획서가 아니라 빌드의 동작을 설명하고 동작의 의도를 대응 시키는 또 다른 종류의 문서이며 결코 기획서가 아닙니다. 게임 소프트웨어 개발 생애주기 상 기획서는 협업 부서 간에 개발을 시작하게 만드는 역할을 합니다. 그 이외의 역할을 기획서가 담당하게 만들려는 시도들은 이 문서를 작성하고 수정하는 사람들이 사실상 혼자 수행하기 거의 불가능한 상태로 만들 수 있습니다.