[▲ 넥슨코리아 이나은 개발자]

  • 주제: 시스템 기획서 잘 쓰는 법
  • 강연자 : 이나은 - 넥슨코리아 / NEXON KOREA
  • 발표분야 : 게임기획, 커리어
  • 권장 대상 : 지망생, 주니어 시스템 기획자, 다른 사람은 어떻게 기획서를 쓰는지 궁금한 분
  • 난이도 : 사전지식 불필요 : 튜토리얼이나 개요 수준에서의 설명


  • [강연 주제] 이 세션은 지망생, 신입 게임 디자이너 및 다른 사람은 시스템 기획을 어떻게 하는지, 궁금한 분들을 위한 세션으로, 시스템 기획서를 쓸 때 어떤 것을 신경 써야 하는지, 실제 프로젝트에서 시스템 기획서는 어떤 식으로 쓰는지에 대해서 이야기 드리려고 합니다. 사실 기획서를 쓰는 것에 대한 정해진 양식은 없지만 시스템 기획서를 작성할 때 도움이 되면 좋겠습니다.

    '시스템 기획'은 게임의 규칙을 정의하는 일이며, 게임의 뼈대를 만드는 일이라고 할 수 있다. 그리고 콘텐츠 기획은 이렇게 시스템 기획으로 잡혀진 규칙과 룰, 그리고 다양한 기능을 활용해 게임에 살을 붙이는 일이라고 표현할 수 있다.

    하지만 현업 실무에서 시스템 기획자는 단순히 뼈대를 잡는 일에 그치지 않는다. 뼈대를 잡는 형태의 기획은 게임 개발 초창기의 신규 프로젝트에 많이 투입되는 일이다. 게임에 살을 붙여나가는 과정이나 라이브 서비스에서 시스템 기획자는 '시스템 기반'의 콘텐츠를 추가하는 업무를 더욱 많이 맡게 된다. 일반적으로 이런 형태의 시스템 기획은 주로 프로그래머와 협업해 새로운 기능을 만드는 경우도 많다.


    '시스템 기획서'는 이렇게 게임에 새로운 기능이나 기존 기능이 추가될 때 쓰게 되는 문서라고 할 수 있다. 시스템 기획자나 콘텐츠 기획자 모두 시스템 기획서를 쓰기도 하며, 콘텐츠 기획자가 제작을 하면서 필요한 기능은 직접 기획하기도 한다. 결국 시스템 기획서는 개발자들에게 작업을 위해 시스템 프로세스를 도식화나 차트 등으로 흐름을 파악할 수 있도록 하는 문서다. 그만큼 '전달력'이 중요하다고 할 수 있다.

    그렇다면 이런 '시스템 기획서'를 잘 쓰기 위해서는 어떻게 해야 할까. 이번 NDC 강연에서 넥슨의 이나은 개발자는 시스템 기획서를 잘 쓰는 방법에 대해서 세 가지 팁을 제시했다. 생각하고, 쓰고, 그리고 고치는 것. 조금 더 설명을 덧붙이자면, 기획의도와 개발 방향 및 목표를 '생각하고', 읽는 대상에 따라 다르게 형태를 고려하면서 범주를 정해 '쓰고', 공유하기 전에 다시 기획서를 읽어보고 수정 내용을 반영하며 최신 버전을 유지하도록 '고치는 것'이라고 할 수 있다.



    ■ 팁 I. "생각하기" - '기획 의도'를 반드시 생각하자

    기획서에서 가장 중요한 건 바로 '기획 의도'다. 어째서 이 시스템을 개발할지, 그리고 왜 이렇게 할지를 작업자들에게 설명해서 더 이해도를 높여 의도한 시스템이 개발될 수 있도록 유도한다. 기획 의도를 모른 채 개발을 진행하다 보면 의도와는 정 반대가 되는 형태의 시스템이 나올 수도 있다.

    만약 의도를 말해주지 않는 시스템 기획을 맡게 된다면, '어떤 의도를 가지고 있는지 생각'을 해보자. 그리고 확인하는 과정도 중요하다. 기획 의도에 따라서 개발 목표가 달라지기 때문에 이렇게 '기획 의도'를 파악하는 일은 매우 중요하다. 그리고 기획서에도 이런 의도를 추가하는 게 작업자들이 이해하기도 쉽다.

    기획서에 '기획 의도'가 있으면 설득의 근거가 될 수 있고, 방법을 바꿔야 할 때 방법에 얽매이지 않고 다른 방법을 찾아도 기획의 방향을 잃지 않는다. 또한 개발, 구현 과정에서 기획 의도에 맞는 더 좋은 방법을 찾아낼 수도 있다. 여기서 멈추지 말고, 개발 방향을 생각하면서 "왜 하는지", "무엇을 신경 쓸 것인지", "어떻게 개발할 것인지"를 고민하는 게 좋다.




    ■ 팁 II. "쓰기" - 대상에게 '필요한 내용'을 담자

    충분한 생각을 마쳤으면 이제 기획서를 '쓸' 단계다. 기획서는 여러 직군에게 공유되는 문서다. 내용이 많지 않다면 한 문서에 쓰는 것도 괜찮을 수 있다. 하지만 내용이 많아지게 되면 작업자 입장에서는 자신과 관련이 없는 내용이 많아질 수 있다. 작업 시간이 부족하게 될 경우 문서를 읽은 시간도 부족하기에 구두로 질문하고 개발하게 되는 경우도 있다.

    그렇기 때문에 내용이 많아질 경우, 작업자에게 맞춰서 기획서를 작성하는 게 좋다. 기획서를 보는 대상에서 필요한 내용을 쓰는 것이다. 예를 들어 프로그래머에게 전달되는 기획서는, 실제 구현에 필요한 내용(UI 동작 및 조작 프로세스, 각종 예외 처리, 테이블 구조 등등)을 담는다.

    프로그래머에게 전달되는 기획서의 예시

    처음부터 완벽하게 쓸 순 없으니 지속적으로 다듬는 것도 좋지만 너무 오래 걸리지 않아야 한다. 시간이 부족하다면 쪼개서 전달하는 방식도 나쁘지 않다. 로직이나 알고리즘 같은 내용은 적지 않아도 된다. '기능'에 대해서는 어떤 식으로 흘러갈 것인지에 대한 '흐름'을 공유하는 게 좋다. UI 디자이너에게 전달되는 기획서라면 '디자인'에 필요한 내용을 적는다. 컨셉이나 구성 요소, 필요한 연출 등이라고 할 수 있다. 더 잘 보여야 하는 부분을 설명하거나 강조가 필요한 부분, 기능에 대한 설명도 첨가하면 더 좋은 기획서가 된다.

    이렇듯 기획서를 보는 대상에 '필요한 내용'을 담는 게 중요하다. 여기서도 앞서 언급했던 것처럼, '기획 의도' 및 제공 방향을 꼭 기록하자. 순서도의 경우는 내용이 복잡하다면 추가하는 게 좋긴 하지만, 순서도도 '흐름을 파악하기 위한 것'이라는 걸 명심하자. 물론 흐름을 정리하는 용도의 플로우는 필요하다. 프로그래머에게 전달하는 기획서에는 많이 발생할 수 있는 예외 처리는 반드시 언급하는게 좋다.


    포맷은 큰 상관이 없지만, 가장 효과적으로 전달할 수 있는 포맷을 선택하는게 좋다.


    ■ 팁 III. "고치기" - 공유전에 검토하고, 최신 버전 유지에 힘쓰자.

    작성까지 완료했다면, 이제는 검토를 해봐야 할 단계다. 기획서를 공유하기 전에는 기획 의도와 방향이 맞는지 잘 살펴봐야 한다. 또한 개발이 진행되면서 수정 사항이 생길 수밖에 없다. 기획서는 그만큼 작성 후 충분히 변경될 수가 있으며, 변경이 되더라도 기획 의도는 만족시켜야 한다.

    이렇게 변경 사항이 생기게 되면, 기획서는 여러 가지 버전이 생기게 된다. 이럴 경우 항상 최신 버전을 유지를 위해 힘써야한다. 막상 업데이트 이후 정리할 시간이 부족한 경우가 많지만, 최신 버전이 유지되지 않으면 혼란이 발생할 수 있다. 또한 최신 버전을 유지하면 개발의 히스토리를 파악하기 쉽고, 인수인계가 용이하다.

    기획서는 기획 의도를 만족시키고, 방향에 맞는 결과물을 만들 수 있게 하는 도구다. 기획 의도를 생각하면서 작성하고, 대상에게 필요한 내용을 쓰고, 작성 후 내용을 검토하고 최신 버전을 유지하는 것. 이 세 가지가 강연에서 전달한 기획서를 잘 쓰기 위한 팁이라고 할 수 있다. 이나은 개발자는 기획서의 정답은 없지만, 가장 전달을 잘 할 수 있는 형태로 쓰는 게 중요하다고 전하며 강연을 마무리했다.