왜 사양서라는 별도 문서가 필요했을까?

게임 프로젝트에 참여해 게임디자이너 직군으로 여러 문서를 작성해 봤지만 여전히 기획서라는 문서는 어떻게 작성해야 할 지 잘 모르겠습니다. 어느 정도로 어떻게 작성해야 할 지 잘 모르겠느냐 하면 완전히 새로운 주제에 대한 기획서를 작성하기 시작하려면 일단 이전에 작성했던 기획서를 하나 열어 이전에 대략 어떤 식으로 작성했었는지 파악한 다음 이를 바탕으로 새 기획서를 작성하기 시작할 지경입니다. 그렇게 매번 새로운 기획서를 작성하기 시작할 때마다 이전에 작성했던 기획서를 참고하는 제 모습이 하도 한심스러워서 뭔가 이런 한심스런 행동을 피할 방법이 없을지 고민하다가 기획서에 스토리텔링을 시도해 보기로 합니다. 그러니까 기획서라는 문서에 제가 이 문서를 읽는 사람에게 이야기하는 것처럼 어쩌다 이런 기능이 게임에 들어가야 하게 됐는지 전후 사정을 짧게 설명하고 이런 상황 때문에 이 기능에 대해 이 문서를 통해 정의하게 됐다는 말을 하고 이어서 기능을 정의하는 식으로 작성하는 것입니다. 이런 작성 방법이 성공적이었을른지는 잘 모르겠지만 적어도 제 개인 선에서는 새 문서를 작성할 때 쪽팔리게 이전에 작성했던 문서를 열어 이전에는 어떻게 썼었는지 살펴보고 이에 맞춰 새 문서를 작성하는 일을 할 일이 꽤 줄어들었습니다. 또 다른 장점으로는 문서를 마치 제가 이 주제를 독자에게 이야기하는 느낌으로 작성했기 때문에 문서를 앞에 띄워 놓고 브리핑 할 때 훨씬 더 진행하기가 쉬웠습니다.

기획서 말고도 게임디자이너가 프로젝트에 기여하기 위해 작성해야 할 문서는 훨씬 다양합니다. 다들 여러 가지 이름으로 부르고 있는 것을 알고 있지만 여기서는 제 기준에서 알고 있는 여러 가지 목적에 따른 문서들을 나열해 보겠습니다. 일단 기획서 그 자체가 있습니다. 주로 기획서는 단위 기능의 사양과 요구사항을 정의한 문서로 기획 부서 내에서는 사양과 요구사항이 올바른지 판단하는 용도로 사용되지만 협업 부서로 넘어가면 이 문서의 요구사항에 맞춰 에셋을 제작하고 코드를 작성하는데 사용됩니다. 이름은 기획서이지만 실은 기획 뿐 아니라 협업 부서의 여러 가지 요구사항에 맞춘 부분들을 포함하고 있습니다. 다음으로는 제안서가 있습니다. 제안서는 규모에 따라 좀 나뉘는데 프로젝트 수준으로 규모가 큰 문서는 제안서라고 부르기도 하지만 피칭 문서라고 부르기도 합니다. 주로 회사나 경영진을 대상으로 프로젝트의 비전을 설명하고 이를 개발해 돈을 벌 수 있을 가능성이 높음을 설득해 돈을 받아 와 프로젝트를 시작하는 의사결정을 만들어내기 위한 문서입니다. 규모가 더 작은 제안서는 기획서를 작성하기 이전에 게임의 단위 기능의 게임디자인 계획을 설명하는 문서에 가까운데 여기에는 문제 인식, 문제를 해결하기 위한 대략적인 방법, 시장의 다른 플레이어들이 비슷한 문제를 해결하기 위해 하고 있는 행동, 이를 바탕으로 게임디자이너 자신의 의견을 포함하는데 특히 마지막 게임디자이너 자신의 의견이 바로 제안이며 이 제안을 포함했기 때문에 이 문서를 제안서라고 부릅니다. 제안서가 게임디자인 부서 내에서 승인되면 다음으로 기획서를 작성하곤 합니다.

또 발주서 계열의 문서가 있습니다. 프로젝트에 따라서는 그냥 발주서라고 부르기도 하지만 또 다른 프로젝트에서는 발주서라는 이름이 마치 외주 업체에 보내는 그 발주서와 이름이 같아 같은 프로젝트 내에서 사용하는 문서로는 이름이 좋지 않다고 생각해 ‘제작 요청서’ 같은 다른 이름을 사용하기도 합니다. 의도를 이해하지 못하는 것은 아니지만 이름과 본질에 대해 한번쯤 생각해볼 만한 주제라고 생각합니다. 발주서를 받는 조직은 일반적으로 프로젝트 전체의 진행이나 게임디자인에 대한 이해가 상대적으로 낮다고 알려져 있고 이 상태를 적극적으로 개선할 의도가 별로 없다고도 알려져 있습니다. 때문에 기획서에 이미 어떤 에셋들이 필요한지 설명 되어 있지만 발주서를 받기 원하는 조직들은 기획서를 살펴보고 에셋이 어디에 어떻게 사용될지 확인하고 직접 에셋 목록을 작성해 제작을 시작하기 보다는 부서 밖의 누군가가 게임의 각 부분에 사용될 에셋의 정확한 형태를 정의한 문서를 작성해 주면 오직 이 문서에만 의존해 에셋을 작성하기를 원하곤 합니다. 그래서 발주서에는 이미 기획서에 언급된 예상 에셋 목록으로부터 실제 에셋 목록을 도출해 에셋 각각에 대한 형태, 특징, 기획 의도 따위를 기획서와는 독립된 문서에 작성하고 심지어 이 에셋의 형상관리도구 상의 경로와 파일 이름까지 온전히 지정한 문서를 작성해 제작 요청을 보내는데 사용합니다. 발주서를 작성하며 얻는 장점은 게임의 에셋 파이프라인을 좀 더 잘 이해할 수 있게 되고 또 경로나 파일이름 관리가 상당히 중요하다는 사실을 배우게 된다는 점입니다. 그리고 단점은 … 이 글의 주제는 아닌 것 같으니 이야기하지 않겠습니다.

또 프로젝트에 따라 기획서와 별개로 사양서라는 문서를 작성하도록 하는 사례도 있습니다. 제안서와 기획서 단계를 거치며 요구사항을 정의한 기획서가 이미 존재하지만 이와 별도로 요구사항 각각을 좀 더 작은 단위로 나눈 문서를 발주서라고 부르곤 하는 것 같았는데 제가 이해한 사양서의 특징은 에셋을 제작하기 위해 발주서를 작성하는 것과 마찬가지로 빌드 상의 단위 기능을 제작하기 위핸 일종의 기능 발주서와 비슷한 역할을 합니다. 기획서는 주로 단위 기능의 전체 동작을 언급하는데 이는 기획서 하나가 단위 기능의 여러 맥락을 설명하면서도 각각의 하위 기능을 모두 설명하고 있기 때문에 종종 그 길이가 길어지고 기술적으로 서로 다른 사람이 개발해야 할 기능이 한 문서에 포함될 수도 있습니다. 만약 기획서를 엔지니어나 엔지니어 집단을 관리하는 기술적 전문성이 있는 관리자가 작성했다면 기획서를 각 담당자에 따른 문서로 구분해 작성할 수 있었을 수 있지만 기획서는 주로 기술적 전문성이 부족한 게임디자이너들이 작성하는 관계로 기능 각각의 완결성에 맞춰 작성되지만 이를 받아 개발할 엔지니어들의 구분에 맞춰 작성되지는 않습니다. 또한 마일스톤 길이와 요구사양의 개발 비용에 따라 한 기획서는 두 마일스톤 이상으로 나뉘어 개발될 수도 있는데 이 경우 기획서 중 특정 부분까지는 이번 마일스톤에 개발해 그 때까지 개발된 기능에 기반해 플레이 시나리오를 구축하고 다음 마일스톤에 나머지 부분을 개발해 이전헤 구축한 플레이시나리오를 수정해 온전한 버전으로 만드는 전략으로 개발할 수도 있습니다. 이는 그 규칙은 말이 됩니다. 그런데 고객에게 어떤 경험을 주나요?에 설명한 다른 기능에 의존성이 있는 기능을 의존성이 없다고 가정하고 일단 개발하는 것과도 비슷한 맥락입니다.

이런 상황에서 한 가지 요구사항을 온전히 담고 있는 기획서는 구현 비용이 한 마일스톤을 넘길 수도 있는데 이에 따라 기획서 하나를 마일스톤 하나 단위로 맞춰 이번 마일스톤이 끝날 때까지 개발해야 할 부분을 분리하고 이에 기반한 플레이시나리오를 다시 구축한 별도의 문서를 만들어 이 문서를 보고 개발해야 하는 엔지니어들의 편의를 도모하기도 하는데 이것이 사양서라는 별도 문서의 가장 큰 목적이라고 생각합니다. 한 마일스톤 안에 기획서 하나의 모든 요구사항을 달성할 수 없을 것으로 예상되므로 한 기능을 서로 다른 여러 마일스톤 단위로 잘라 각 마일스톤에만 해당하는 요구사항을 별도로 기술하면 일단 이 문서를 받아 본 엔지니어가 기획서 전체를 받아볼 때와 달리 놀라지 않을 수 있고 또 에셋을 제작할 때 이 에셋이 필요한 맥락을 완전히 제거한 채 에셋 자체에 대한 정보 전달에만 집중하게 만드는 것과도 비슷한 효과를 기대해볼 수도 있습니다. 만약 기획서를 통해 이 기능이 사용될 다양한 맥락을 제시한다면 이를 본 엔지니어는 요구사항에 언급된 것 이상의 기능이 필요하다고 판단할 수도 있습니다. 여느 프로젝트에서는 이런 판단에 의해 요구사항을 수정하는 선순환을 일으키지만 마일스톤 계획 달성에 초점을 맞춘 프로젝트의 경우 달성되지 않은 목표에 대한 위기관리 같은 문제를 일으킬 수 있기 때문에 프로젝트에 따라서는 이런 엔지니어와 게임디자이너 사이에 일어나는 인터레이션을 좋은 시선으로 평가하지 않는 사례도 있습니다. 이런 상황에서 사양서는 에셋을 제작하기 위해 작성하는 발주서와 마찬가지로 이 문서를 받아 작업을 수행하는 누군가가 순수하게 이 문서에 언급된 정보에만 기반해 코드를 만들어내고 이 규모가 한 마일스톤의 비용을 초과하지 않도록 통제하는데 기여하기 위한 것입니다.

그렇다면 어떤 프로젝트는 사양서라는 문서를 사용하는 반면 다른 프로젝트는 기획서만으로 개발하기도 하는 차이가 생기는 이유는 무엇일까요? 그리고 나아가 에셋 제작을 요청할 때도 게임디자이너가 직접 에셋을 하나하나 분해한 발주서를 작성하지 않아도 기획서 수준으로 에셋 제작이 일어나는 프로젝트가 존재하는 이유는 무엇일까요? 이론적으로 초기에 제안서를 거친 다음 나온 기획서는 협업 부서들이 수행해야 할 공동의 목표를 언급하고 있으니 이 문서만으로 목적에 도달할 수 있습니다. 그런데 협업 부서에 따라 일할 때 정보에 어느 수준까지 접근하고 싶은지, 프로젝트의 본질적인 측면에 어느 정도 수준까지 접근하고 싶은지가 프로젝트마다 서로 다를 때가 있습니다. 어느 프로젝트에서는 협업 부서들이 게임디자이너가 작성한 기획서에 직접 언급되지 않은 맥락이나 행간에 관심을 가져 기획서를 통해 개발할 수 있습니다. 앞서 설명한 대로 기획서에는 이미 이 기획서에 따라 개발이 이루어질 때 도달할 결과를 언급하고 있기 때문입니다. 만약 기획서에 언급한 요구사항이 기술적인 현실을 반영하지 못하거나 앞서 잠깐 언급한 대로 마일스톤 경계를 초과할 것으로 예상된다면 협업 부서와 함께 요구사항을 조정하거나 마일스톤 계획을 조정해 게임디자이너가 처음 예상한 형태와는 조금 달랐지만 어쨌든 기획서에 기입한 요구사항에 다다를 겁니다.

반대로 협업 부서가 이런 정보에 큰 관심을 가지지 않을 수 있습니다. 앞서 발주서에 대해 설명할 때 발주서는 대체로 이 에셋이 필요하게 된 여러 가지 맥락을 제거하고 에셋 자체의 사양에 집중해 협업 부서가 발주서에 기입된 정보에만 집중해 결과에 도달하기 위한 것이라고 말했습니다. 사양서 역시 기획서를 기반으로 개발하고 상황에 따라 기획서 자체의 목표를 조정하는 등 협업 부서 및 기획서를 작성한 기획 부서 사이에 이터레이션이 일어나며 기획서를 수정해 가는 과정을 협업부서들이 원하지 않을 수 있습니다. 기획서를 놓고 목표를 조정하는 이터레이션을 수행하는데 시간을 사용하는 대신 협업 부서들의 퍼포먼스를 더 잘 예측하고 요구사항의 예상 비용 역시 더 잘 예측한다면 정확히 이번 마일스톤에 개발해야 할 요구사항을 비용에 맞춰 정확히 언급할 수도 있을 겁니다. 만약 그런 문서를 작성할 수 있을 정도로 게임디자이너들이 비용 예측에 전문성이 있다면 완결된 요구사항의 맥락을 모두 포함한 기획서를 작성해 이를 바탕으로 협업 부서와 실제 수행 가능한 목표를 수립하기 위한 이터레이션을 거치는 대신 직접 사양서라는 이름으로 이번 마일스톤에 협업 부서가 달성할 수 있는 정확한 목표를 한 번에 제시하고 협업 부서는 이 문서에 기반해 이터레이션을 위한 맥락을 습득하는 대신 즉시 사양서에 따라 개발을 수행해 사양서에 언급된 수준과 대략 일치하는 빌드를 개발하는데 집중할 수도 있습니다. 이런 시나리오를 통해 개발하기 위해서는 사양서가 필요합니다.

그렇다면 이 사양서는 어떻게 정의할 수 있을까요? 또 기획서와는 어떻게 다를까요? 먼저 기획서는 단위 기능에 대한 요구사항이 기능의 전체적인 맥락과 단위 기능에 포함되는 대부분의 하위 기능을 포함해 언급 되어 있습니다. 가령 우편 기능을 개발한다면 우편 목록, 내용 보기, 발송, 아이템 첨부, 내용 작성, 읽음 처리, 자동 삭제 같은 여러 동작을 모두 설명하고 각각의 상황마다 어떤 인터페이스가 필요하며 인터페이스에 따라 게임디자인 측면에서 필요한 데이터구조를 모두 언급하고 있습니다. 또한 우편 기능이 전체 개발 시점 중 왜 지금 필요한지에 대한 맥락을 함께 이해할 수 있는 정보를 포함하고 있을 수도 있습니다. 이 기획서는 단위 기능에 대한 요구사항을 완결성 있게 설명하지만 이 요구사항을 실제로 개발하기 위해서는 여러 사람, 여러 마일스톤이 필요할 수 있습니다. 그래서 기획서에 언급한 단위 기능에 대한 완결성 있는 설명들로부터 맥락을 제거하고 단위 기능을 구성하는 세부 기능 각각을 분리해 제한된 기간, 제한된 비용으로 개발할 수 있는 각각의 기능으로 분리한 문서를 작성한 것을 사양서라고 볼 수 있습니다. 우편 기획서에 비교해 우편 관련 사양서는 이 각각의 하위 기능들이 우편을 위한 기능이라는 사실을 언급할 수 있겠지만 굳이 그럴 필요가 있지는 않습니다. 그저 목록 보기, 내용 보기, 발송, 아이템 첨부 등등의 하위 기능을 각각의 사양서에 기입하고 각각의 문서가 서로 다른 담당자에게 전달되어 개발될 수 있는 상황에 대비해야 합니다. 때문에 비용에 맞추기 위한 이터레이션에 필요한 맥락을 제거하기는 하지만 최소한 이 각각의 사양들이 조합될 때 우편이라는 통합된 기능으로 동작할 것임을 언급하기는 해야 할 수도 있습니다.

프로젝트에 따라서는 마일스톤 별 비용에 민감하게 반응하면서도 사양서 같은 별도 문서 없이 기획서에 기반해 개발하기도 하는데 이 경우 왜 이들은 비용에 민감하게 반응하면서도 별도의 문서를 요구하지는 않을까요? 이 경우 협업 부서는 결국 기획서의 요구사항 모두를 이번 마일스톤 안에 개발하기 어렵다는 사실을 인정하면서도 협업 부서 간의 이터레이션을 통해 마일스톤 단위의 목표를 재정의하고 이를 기존 기획서에 표시해 이번 마일스톤에 진행할 부분과 그렇지 않을 부분을 문서에 표시한 채 이번 마일스톤 목표에만 집중해 개발을 진행하기 때문입니다. 사양서를 필요로 할 때는 이런 요구사항의 범위를 재정의하는데 필요한 이터레이션을 수행하기를 원하지 않거나 이 이터레이션 기간마저도 절약해 개발에 집중하도록 하는 목적이 있는 것 같습니다. 반대로 별도의 사양서를 요구하지 않는 경우 요구사항의 범위를 재정의하는 과정의 불가피함을 서로 인식하고 기획서의 요구사항을 살펴보고 이 기능의 핵심과 부가 기능을 구분해 핵심에 먼저 집중해 마일스톤 목표를 달성하고 부가 기능은 마일스톤 목표 바깥으로 밀어내거나 부가적인 목표로 설정해 상황에 따라서는 아슬아슬하게 전체 목표 달성에 성공할 수도 있습니다. 즉 협업 부서 간에 어떤 목표를 마일스톤 비용에 맞춰 재조정하는 이터레이션의 필요성을 인정하고 이를 수행할 경우 별도의 사양서를 요구하지 않고 이 과정을 수행하지 않거나 이 과정에 필요한 시간 마저도 개발에 집중하기를 원하는 경우에는 별도의 사양서를 요구하곤 한 것 같습니다.

또 다른 이유로는 기획서에 이를 개발하려 할 때 요구하는 충분한 정보가 포함되어 있지 않기 때문일 수 있습니다. 앞서 기획서를 도출하기 위해 먼저 제안서 수준에서 시작해 이 문서가 게임디자인 부서 안의 문턱을 넘고 나면 본격적으로 이를 개발하기 위해 협업 부서에 전달할 요구사항을 포함한 문서를 작성하는데 이를 기획서라고 부릅니다. 그런데 종종 제안서와 기획서가 적당히 뒤섞여 있어 게임디자인 부서 입장에서는 우리들이 필요로 했던 정보를 나열하고 있지만 협업 부서 입장에서는 딱히 궁금하지 않은 정보가 뒤섞여 있고 또 정작 필요로 하는 본격적인 요구사항이 뚜렷하게 포함되어 있지 않기도 합니다. 보통 이를 작성한 낮은 수준의 게임디자이너는 이 문서를 읽는 사람이 이 문서로 어떤 일을 수행할 예정이며 이를 위해 어떤 정보가 필요한지 큰 관심을 기울이지 않는 경향이 있기도 한 것 같습니다. 이런 문서들을 남발하다 보면 협업 부서들로부터 기획서가 부실하다거나 기획서를 읽어도 무슨 일을 하라는 말인지 잘 이해하지 못하겠다는 피드백을 받을 수 있습니다. 또한 기획서를 협업 부서에 브리핑 하다 보면 기획서에 뚜렷하게 언급되지 않은 구체적인 요구사항을 도출하기 위한 온갖 질문을 받게 될 수 있는데 브리핑 때 너무 많은 질문이 쏟아져 나오는 원인 중 하나는 기획서에 요구사항이 충분히 언급되지 않아 협업 부서들이 요구사항을 도출하기 위해 브리핑 자리에서 스무고개를 시도하기 때문입니다. 이런 과정을 거치다 보면 협업 부서들은 어차피 도움이 안 되는 기획서 대신 발주서나 사양서 같은 보다 목적 지향적인 - 원래 기획서가 그랬어야 할 - 문서를 요구하게 될 수 있습니다.

앞서 별도의 사양서를 요구하는 원인 중 하나로 협업 부서가 기획서의 예상 구현 비용과 우리들 모두에게 이번 마일스톤에 남은 비용을 비교해 실질적으로 달성 가능한 목표로 기획서의 목표를 수정해 가는 이터레이션을 서로 직접 수행하기를 원하지 않는 것을 들었는데 이는 사실 게임디자이너 관점에서 해결할 수 없는 문제입니다. 근본적으로 이 문제를 해결하기 위해서는 게임디자이너 각각이 자신이 작성한 기획서에 언급한 요구사항의 구현 비용을 추정 가능해야 하지만 여기에는 게임디자이너의 전문성의 한계를 넘어서는 능력이 필요하며 실질적으로 이를 달성하기는 불가능하다고 생각합니다. 때문에 이 원인 때문에 작성해야 하는 사양서는 피할 수 없습니다. 하지만 또 다른 이유로 기획서에 협업 부서가 실제로 업무를 수행하는데 필요한 정보가 충분히 언급되지 않고 그들이 딱히 필요로 하지 않는 게임디자인 부서 내에서 의사결정에 사용한 정보들이 너무 많이 포함되어 있기 때문에 보다 목적에 집중한 사양서를 작성해야 하는 상황이라면 이는 기획서를 작성하는 스타일을 조정해 회피할 수 있습니다. 근본적으로 앞서 설명한 제안서와 기획서가 서로 어떻게 다른지 이해하면 기획서에 포함해야 할 정보와 제안서 수준에서 마무리하고 기획서에는 포함할 필요가 없는 정보를 구분해 기획서 자체를 훨씬 목적 지향적으로 작성하면 됩니다.

기획서의 목적을 잘 이해하지 못한 게임디자이너일수록 자신이 이 기획서의 요구사항을 도출하기 위해 기획팀 내부에서 얼마나 많은 준비를 해 왔는지 기획서에 포함하고 싶어 하는 경우가 있어 보입니다. 사실 이런 정보에 관심을 가지는 협업 부서 구성원들이 있는 것도 사실이지만 모든 사람들이 그렇지는 않습니다. 또한 이런 정보에 관심을 가지는 분들이라면 기획서 외에 이 기획서를 도출하는데 사용한 제안서를 따로 찾아볼 수 있도록 기획서 가까이에 제안서를 두거나 두 문서를 서로 연결해 두면 기획서에 굳이 그런 내용을 포함하지 않을 수 있습니다. 기획서는 그 모호한 이름 때문에 이 문서의 본질적인 역할을 망각하게 만들기도 하는 것 같습니다. 기획서는 근본적으로 프로젝트 전체 관점에서 일종의 명령서라고 볼 수 있습니다. 명령, 과업 같은 조금 거창하고 군대 냄새 나는 용어를 사용할 때 불편해 하시는 분들을 종종 만나곤 했지만 기획서의 본질은 협업 부서가 수행할 일과 이를 통해 달성할 목표를 기술한 명령서입니다. 명령서에는 이 명령을 도출하게 된 맥락을 포함할 필요가 없습니다. 개발팀에서 명령에 해당하는 요구사항을 정확히 기입하고 이 요구사항들이 수행되어 게임에 통합된 다음 동작할 모습을 기술하면 명령서로써 역할을 할 수 있고 이것이야말로 기획서의 본질입니다. 만약 이 명령의 구체적인 맥락이 궁금하면 명령서와는 별도로 작성한 제안서를 살펴보거나 명령서를 작성한 담당 게임디자이너에게 물어볼 수도 있습니다. 핵심은 기획서의 본질이 명령서라는 점을 인식하고 명령, 즉 협업 부서가 우리들이 원하는 목표에 따른 행동을 하도록 만들기 위해 그 행동에 대한 구체적이고 직접적인 언어를 통해 작성해야 합니다.

기획서는 본질적으로 명령서라는 관점에서 이 문서에는 이 행동을 수행해야 하는 이유, 이 행동을 수행하게 만든 상황을 구체적으로 언급할 필요가 없습니다. 대신 단도직입적으로 이 명령서에 따른 명령이 성공적으로 수행되었을 때 이 기능이 통합된 게임이 동작하는 모양을 설명하고 이 목표를 달성하기 위한 요구사항의 구체적 단위 기능을 언급해 각각의 기능이 개발되도록 해야 합니다. 또 에셋이 필요할 경우 이를 언급하되 부서에 따라 에셋 별로 별도의 발주서를 요구할 경우 이 역시 발주서의 본질 역시 에셋을 제작하라는 명령서라는 사실을 이해하고 목적 지향적인 문서를 작성해야 합니다. 여기에는 동일하게 이 에셋이 필요한 이유, 이 에셋이 사용될 장면 따위를 상세히 언급할 필요가 없습니다. 그런 정보는 제안서 수준에서 고려되는 정도면 충분하며 협업 부서들로 나갈 각각의 명령서에는 이를 원한다면 언급하거나 이 정보를 포함한 문서를 연결해 줄 수 있지만 이 정보가 반드시 필요하지 않으며 편안하게 생략해도 아무런 문제가 일어나지 않을 것입니다. 기획서가 부실하다는 평가를 받고 또 뭘 해야 할 지 잘 모르겠다는 평가를 받는 이유는 기획서가 본질적으로 협업 부서를 향하는 명령서라는 본질을 이해하지 않고 작성하고 있기 때문이라고 생각합니다. 만약 이 문서들이 본질적으로 명령을 내리는 문서라는 사실을 이해하고 작성한다면 부실하다는 평가는 여전히 받을 가능성이 있지만 뭘 해야 할 지 잘 모르겠다는 평가는 근본적으로 피할 수 있을 겁니다. 또한 게임디자인의 입장이 본질적으로 명령서를 작성하는 집단이라는 사실을 이해해야 합니다. 실상 우리들은 협업 부서에 우리들의 목적을 이해시키고 작업 수행을 부탁하는 입장이지만 본질적으로 이 계획의 수행 결과에 따른 책임을 지는 역할을 맡고 있습니다. 게임이 고객들에게 전달되어 나쁜 평가를 받을 때 회사에서 잘리는 것은 게임디자이너들이기 때문에 우리들은 우리들이 작성한 명령서와 이를 통한 명령에 더 큰 책임을 가지고 임할 필요도 있습니다.

한참 이야기했으니 이제 제목인 ‘왜 사양서라는 별도 문서가 필요했을까?’로 돌아가 이 질문에 다시 답해 봅시다. 사양서는 기획서에 언급된 기능에 대한 맥락, 요구사항을 달성하기 위한 하위 기능들의 집합 등으로 구성되어 있는데 문서 전체에 걸친 요구사항의 비용을 추정해 마일스톤 안에 달성 가능한 목표로 조정할 때 일어나야만 하는 이터레이션을 거치는 조직이라면 별도의 사양서가 필요하지 않지만 이런 이터레이션 기간 조차도 개발에 투입하기를 원하는 조직이라면 별도의 사양서가 필요합니다. 기획서가 부실하고 또 뭘 해야 할 지 이해할 수 없다는 평가를 받는 이유는 근본적으로 기획팀의 역할이 프로젝트 전체에 명령을 내리는 것이고 이를 위한 기획서의 근본적인 속성은 명령서라는 사실을 이해하지 못한 채 문서를 작성하기 때문입니다. 이 문서가 명령을 포함하며 이 문서를 읽은 사람들이 명령을 수행하기를 원한다면 제안서에 어울리는 내용은 기획서에 포함될 필요가 없어집니다. 보다 목적 지향적이어야 하고 단언하는 문구를 사용해야 하며 작성자가 판단하지 못한 요구사항을 어설프게 문서에 포함해서는 안됩니다. 본질적으로 명령서라는 관점에서 기획서는 보다 적나라하고 직설적인 문구를 사용해 작성자의 요구하는 바를 명확하게 표현해야 합니다. 이 설명에 포함한 명령이라는 말이 불편하게 느껴질 수 있다는 점을 이해합니다. 실제로 이런 기획서의 본질을 설명할 때 제 말을 상당히 불편하게 느끼는 분들이 많이 계셨던 것도 사실입니다. 그렇다고 마치 2차대전 일본군이나 프랑스군이 작성하던 명령서처럼 도대체 뭘 하라는 것인지 이해할 수 없는 본질과 동떨어진 미사여구 범벅인 문서에 기반해 전쟁을 수행하는 상황을 좌시해서도 안됩니다.

사양서라는 문서가 왜 별도로 필요했을까요? 이는 기획서가 이 문서를 읽는 협업 부서에게 필요한 정보를 제대로 포함하고 있지 않으며 무엇을 해야 하는지 정확히 표현하고 있지 않을 가능성이 높기 때문입니다. 그래서 기획서에 빠진 보다 정확한 사양을 별도의 문서에 작성하도록 하는 이름부터 딱 무엇을 원하는지 이해할 수 있는 ‘사양서’라는 별도 문서를 요구했을 수 있습니다. 하지만 기획서가 본질적으로 명령서라는 사실을 이해하면 별도의 사양서를 작성할 필요가 없습니다. 이미 기획서가 협업 부서의 고위 의사결정자에게 전달되는 명령서로써 이 문서의 목표를 명확하게 서술하고 있는 이상 이 문서에 기반해 이전에 작성해야 했을 각각의 세부 사양서를 작성하는 일은 명령서를 전달 받은 협업 부서의 고위 의사결정자의 업무로 변합니다. 그러면 게임디자이너가 더 이상 사양서를 작성할 필요가 없습니다.