시스템기획서와 컨텐츠기획서는 어떻게 다른가요?
어떤 인터뷰 자리에서 시스템기획서와 컨텐츠기획서의 차이에 대한 질문을 받았습니다. 적당히 대답했는데 결국 떨어졌습니다.
지난 권고사직 즈음에 진행했던 한 망한 인터뷰에서 궁극적으로 무엇을 성취하고 싶은가요?라는 질문을 들었습니다. 평소에 일에 파묻혀 살 때는 별로 생각해볼 일이 없는 종류의 질문이지만 인터뷰에서는 해 볼만 하고 또 질문을 받는 입장에서도 생각해 볼 만한 질문이라고 생각합니다. 다만 그 직전까지 마감 일정을 통한 학대 전략, 사람들을 야근 시키는 방법 등을 통해 어떻게든 마감에 맞춰 빌드를 만들어내느라 정신이 팔려 있던 입장에서 갑작스레 이런 약간은 형이상학적이고 또 철학적인 질문을 받자 짧은 시간 안에 생각해볼 수밖에 없었고 지금 돌이켜 보면 그리 만족스럽지 않은 답변을 하게 된 것 같습니다. 어차피 망한 인터뷰이지만 지금에 와서 생각해보니 어쩌면 질문하신 분들은 이상적인 개발을 갈구하는 좀 더 열정적인 사람이 할 법한 답변을 기대했을지도 모르겠다고 생각합니다. 그에 비해 제 답변은 지나치게 현실적이었습니다.
한편 그 인터뷰에 나왔던 질문 중 생각이 많아지도록 만들지는 않았지만 이 역시 평소에는 그런 질문에 답할 준비를 하지 않은 채로 그냥 일해 왔을 뿐이어서 막상 질문을 듣고 빠른 시간 안에 의견을 정리해서 말하고 보니 이 역시 지난 궁극적으로 무엇을 성취하고 싶은가요? 처럼 한번 정리해 두면 좋겠다는 생각이 들었습니다. 이 질문은 시스템 기획서와 컨텐츠 기획서는 어떻게 다른가요? 입니다. 제가 질문자 분들의 머릿속에 들어가 볼 수는 없으니 이 질문의 맥락을 예상해 보면 저는 지금 정도 업력을 쌓은 다른 분들에 비해 상대적으로 실무 경력이 더 길고 관리 경력이 더 짧은데 이런 특징으로 미루어 그 동안 쌓은 상대적으로 더 긴 실무 경력을 어떻게 요약할 수 있을지 시험하려는 의도가 아니었을까 싶습니다.
게임 만들 때 게임디자인의 역할을 굳이 시스템디자인과 컨텐츠디자인으로 구분해야만 할지 고민해본 적이 없지 않지만 일단 어지간한 프로젝트에서 게임디자인 인력을 운용하고 있다면 보통 저런 분류를 통해 역할을 구분하고 있습니다. 이 분류에 따르면 저는 시스템디자인에 훨씬 가까운 역할을 더 자주 해 왔지만 그렇다고 다른 업무를 안 할 수는 없습니다. 문제가 생기면 그게 뭐든지간에 문제를 해결할 때까지 그에 필요한 어떤 일이라도 해 왔고 덕분에 다른 역할을 할 기회는 충분했습니다.
시스템기획서는 플레이시나리오를 달성하기 위한 세부 기능 중 일부의 동작을 기술하고 이 동작의 관점에서 서술한 동작 시나리오, 이 동작을 게임디자인에서 제어하기를 원하는 범위와 방법, 이 동작이 미래에 다른 기능과 통합될 가능성, 그리고 통합된다면 그에 따라 예상되는 확장된 동작 따위를 기술한 문서입니다. 이 문서를 작성하는 과정은 사실 기능의 설계에 가까운데 게임디자인에 시스템디자인 역할을 하는 사람이 있다면 이 프로젝트는 한 가지 기능을 두 사람이 설계하도록 하는 것입니다. 일단 게임디자인에서 자신들의 기준에 따라 동작을 설계한 다음 이를 엔지니어에게 넘겨 검토해 엔지니어 관점에서 다시 한 번 동작을 설계한 다음 개발을 시작합니다. 게임 외에 다른 소프트웨어 개발에서도 기능을 이런 식으로 설계하는지는 잘 모르겠습니다. 주로 SI 분야에서 소프트웨어를 개발하는 사례를 종종 전해 듣곤 하는데 그 쪽에서는 정해진 입력과 출력, 완전히 정의된 동작과 예외 처리가 포함된 문서를 기준으로 오직 그에 따라 동작하는 구현을 한다고 합니다. 그런 관점에서 어쩌면 우리들이 하는 설계와 개발은 종종 적대적인 엔지니어 집단으로부터 듣곤 하는 ‘기획이 아무것도 없는데’ 개발하는 것과 비슷하게 느껴질 지도 모릅니다.
하지만 아무리 게임디자인에 센스가 있는 엔지니어라도 고위 의사결정자들로부터 나온 모호한 플레이시나리오 자체를 직접 검토해 기능을 추려내고 각 기능의 범위를 정하고 이들 각각의 구체적인 동작을 상상한 다음 이를 개발하기는 그리 쉽지 않기 때문에 그들 스스로보다 설계에 덜 익숙한 사람들이 한 번 필터링 한 결과를 보는 편이 효율적일 수 있습니다. 개인적으로 이를 위해 시스템기획서에 두 가지 요소를 확실히 포함해야 한다고 생각합니다. 먼저 인터페이스를 기준으로 한 동작 설명입니다. 시스템기획서는 게임의 여러 부분에 대해 설명할 수 있습니다. 보통 이런 문서를 만들고 있다면 상황이 좀 꼬였다고 생각하기는 하지만 원래는 없었던 캐릭터가 이동하다가 정면에 바로 뛰어넘을 수 있는 장애물을 만나면 장애물을 손으로 짚고 이를 뛰어넘는 멋진 애니메이션을 재생해 장애물의 존재에도 불구하고 이동에 영향을 거의 받지 않는 동작을 원하는 시스템기획서를 작성할 수 있습니다. 이 시나리오에는 인터페이스가 전혀 필요하지 않지만 이 기능이 개발되어 동작할 때 시각적으로 어떻게 동작해야 할지 서술할 수 있는데 이런 사례를 포함해 ‘인터페이스를 기준으로 한 동작 설명’이라고 설명하곤 합니다. 정확히는 ‘동작의 시각적 설명’이라고 하는 편이 좋을 것 같습니다.
다른 하나는 데이터구조입니다. 게임디자인에서 요구하는 기능 대부분은 프로덕션 단계에서 어떻게든 게임디자인이 통제하기를 원할 겁니다. 가령 아이템 데이터를 코드에 포함해 매 데이터 변경 마다 코드를 수정할 수 있고 이러는 편이 문제를 더 빨리 발견하고 현대적인 개발환경의 도움을 더 잘 받을 수 있겠지만 이렇게 하지 않는 이유는 엔지니어가 아닌 사람이 이를 통제할 수 있어야 하기 때문입니다. 그래서 아이템 데이터는 코드 상에 위치하지 않고 별도의 데이터 모양으로 게임 코드와 분리된 장소에 위치하게 됩니다. 그런데 구현될 기능 또는 대상을 바라보는 방법, 또 미래에 이를 통제하기를 원하는 방법에 따라 서로 상당히 다른 데이터구조로 기술할 수 있습니다. 가령 몬스터를 죽이면 아이템을 드랍 하기로 할 때 이 기능을 바라보는 관점에 따라 몬스터에 직접 아이템 데이터를 연결해 몬스터가 죽을 때 항상 이 아이템을 드랍하게 할 수도 있고 몬스터에 보상을 관장하는 데이터를 연결해 보상 시스템을 통해 같은 아이템을 드랍하게 할 수도 있습니다. 동작 측면에서는 이들의 차이를 구분하기 어렵지만 이런 차이는 게임디자인에서 이 기능을 바라보는 관점에 따른 차이입니다.
몬스터가 죽을 때 항상 정해진 정확한 아이템을 드랍하기로 하면 몬스터에 아이템을 직접 연결하는 모양이면 충분하고 이보다 복잡해질 필요가 없습니다. 만약 이런 구조가 미래를 고려하지 않았거나 제시된 플레이시나리오 자체에 완전히 매몰되어 정확히 이 동작을 수행하게 하는데 집중한 주니어님의 실수가 아니라면 이 게임에서 몬스터는 시간을 투자하면 항상 정해진 아이템을 돌려주는 완전히 예측 가능한 자판기에 가까운 속성을 가지고 있다고 볼 수 있습니다. 그래서 몬스터로부터 얻는 아이템은 인게임에서 그리 큰 위상을 가지지 않으며 그저 사냥에 따란 예측 가능한 보상을 지급하기 위한 수단에 불과하다고 예측해도 그리 틀리지 않습니다. 반면 고작 고정된 아이템 하나를 드랍하기 위해 몬스터에 본격적인 보상 시스템이 연결되어 있다면 이는 구조 상으로는 당장의 필요 이상으로 복잡할 수 있지만 몬스터를 죽이는 행동이 게임 내 표준 보상 계산 절차를 따르며 몬스터 역시 게임 전체의 보상 시스템과 똑같은 방식으로 동작하기 때문에 지금은 단순히 고정된 아이템을 드랍할 뿐이지만 근미래에 훨씬 다양한 아이템을 다양한 방식으로 드랍하게 될 수 있음을 예상할 수 있습니다. 약간 뻔한 예를 들었는데 게임디자인에서 제시한 데이터구조에 따라 이 기능의 현재 위상, 미래의 발전 방향 등을 간접적으로 파악할 수 있습니다.
그래서 시스템기획서에는 크게 두 가지, 앞에서 인터페이스 또는 동작의 시각적 표현이라고 말한 부분, 그리고 데이터구조를 언급한 부분이 반드시 필요합니다. 분명 그 사이에는 동작을 좀 더 설명하고 이 기능이 게임의 다른 부분과 통합될 때 동작할 규칙이나 동작 자체를 풀어서 설명하는 등 다양한 부분이 필요하겠지만 이 부분은 보통 처음에 읽히지 않을 겁니다. 엔지니어들은 일단 시각적인 설명을 보고 기능을 인식한 다음 문서를 넘겨 데이터구조를 살펴보고 요구사항을 예상한 다음 개발을 시작할 테고 나머지 부분은 개발을 진행하다가 의문이 생길 때 일단 문서를 열어 살펴보고 질문을 해결할 수 있을지 확인하는데 사용될 겁니다.
컨텐츠기획서는 개인적으로 이와는 상당히 다른 접근을 해야 한다고 생각합니다. 지금까지의 설명에는 요구사항, 동작, 데이터 같은 좀 더 딱딱한 말을 주로 사용했지만 컨텐츠는 게임에서 이런 시스템에 기반해 고객이 실제로 게임에서 받게 될 경험을 서술하는데 더 가깝습니다. 가령 새 던전의 컨셉과 세부 목표를 기술한 기획서는 이 던전이 게임의 전체 스토리에서 차지하는 위상, 이 던전에서 일어날 스토리, 이를 표현하기 위한 에셋의 나열 등등이 필요한데 이런 접근은 위에 설명한 시스템기획서와는 근본적으로 다릅니다. 본격적으로 컨텐츠를 만드는 팀에 속해 일하기 보다는 컨텐츠를 만드는 팀 옆에서 이 분들이 만들고 싶은 경험을 지금까지 만들어진 게임 기능으로 대응할 수 있는지 판단하고 대응할 수 있다면 그 방법을 안내하고 대응할 수 없다면 대응 방법을 준비 시키는 역할을 주로 했습니다. 그러다가 손이 부족해지면 컨텐츠를 만드는 역할을 하기도 했는데 이 때 느낀 점에 따라 컨텐츠 기획서를 작성하는 방법을 정립하게 됐습니다.
시스템기획서에 대상에 대한 시각적 설명 또는 인터페이스와 데이터구조가 반드시 필요한데 비해 컨텐츠기획서에는 단 한 가지만 필요합니다. 바로 이 컨텐츠를 플레이 할 때 고객이 겪게 될 클라이맥스를 시각적으로 나타내는 것입니다. 가령 던전이라면 이 던전에 진입하게 될 퀘스트와 기반 스토리는 물론 중요합니다. 그런데 고객이 던전에서 하게 될 가장 인상 깊은 경험이 무엇인지 맨 먼저 설명해야 합니다. 가령 이번 던전에서는 처음으로 보스 거대거미를 만나 처음으로 장판을 피하는 행동을 요구 받게 되는데 이 때 거대거미의 압도적인 등장이 중요하며 이를 강조하기 위한 컷씬이 나오고 그 다음에 플레이를 시작하게 된다는 식입니다. 이 보스는 게임 상에서 처음으로 바닥에 장판을 사용하며 이 경험을 보조하기 위해 장판을 설명하는 튜토리얼이 필요하고 또 이 거미의 등장을 예고하기 위해 던전의 테마는 거미 알과 거미줄, 작은 거미들로 꾸며져야 하고 던전 뒤쪽으로 갈수록 거대한 뭔가가 움직이는 소리와 흔들림 효과가 필요하다는 식으로 경험을 설명해야 합니다. 이 모든 장치들은 결국 던전 끝의 클라이맥스 단계에서 고객이 하게 될 경험을 위해 앞에서부터 차근차근 준비해 나간 결과이며 이 결과를 만들기 위해 다시 앞에서부터 차근차근 준비할 각 에셋과 기능이 필요함을 언급합니다.
이를 다시 정리하면 컨텐츠기획서는 일단 이 컨텐츠를 통해 고객이 클라이맥스에 겪을 경험을 시각적으로 설명한 다음 이 경험에 도달하기 위한 중간 과정과 각 과정이 필요한 에셋 및 기능을 뒤이어 설명하는 식으로 기술해야 한다고 봅니다. 사실 처음부터 이렇게 생각하지는 않았습니다. 이전에 함께했던 몇몇 컨텐츠디자인 팀에서는 어째서인지는 모르겠지만 주로 엑셀 문서에 필요한 에셋을 나열하고 컨텐츠의 시작부터 끝까지 진행할 각 단계를 차례로 서술하며 각 단계를 시각적으로 설명하기 위해 온갖 곳에서 찾아온 이미지를 짜맞춘 시각 자료를 엑셀 파일에 끼워 넣고 이를 유지보수하느라 안간힘을 쓰고 있었습니다. 사실 형식은 그들의 선택이니 제가 의견을 낼 이유가 없지만 컨텐츠의 시작부터 끝까지 시간 순서에 따라 차례로 설명하는 방법은 주로 더 많은 에셋과 더 많은 기능을 필요로 하는 클라이맥스에 대한 설명을 뒤로 미루고 당장은 썩 중요하지 않을 수 있는 앞부분에 대한 설명을 우선하는 결과로 이어집니다.
한편 이전에 참여했던 한 전작이 있는 게임의 신작을 개발하면서 감사하게도 전작 개발팀의 모든 문서를 읽을 권한이 주어졌는데 이 때 그 분들의 컨텐츠기획서 작성 방식이 일단 클라이맥스를 설명한 다음 그에 도달하는 나머지 과정을 설명하는 방식이었습니다. 이 방식은 일단 가장 많은 자원이 필요할 클라이맥스를 언급하면서 컨텐츠가 필요로 하는 에셋과 기능 대부분을 짧은 구간 안에 모두 늘어놓을 수 있고 또 이 부분이 나머지 부분에 비해 충분히 매력적일 가능성이 높기 때문에 협업 부서들의 집중을 유지하는데도 큰 도움이 되었습니다. 그리고 이어서 이 경험에 도달하는 과정에 필요한 에셋과 기능을 설명할 때는 궁극적으로 이들이 왜 필요한지를 이미 설명했으므로 설명하기 훨씬 편해졌습니다.
지난 망한 인터뷰에 나온 질문에 대략 이런 식으로 답했었는데 사실 이 답변은 질문 의도에 얼마나 일치했을지 잘 모르겠습니다. 아마도 실무를 어떤 식으로 파악하고 있고 또 관리자 입장에서 이를 팀에 어떻게 푸시하는지를 묻고 싶었을 것 같은데 그런 관점에서라면 완전히 틀린 답변을 하지는 않았을 것 같지만 컨텐츠를 중시하는 사람 입장에서는 썩 입맛에 맞지 않았을 수 있습니다. 또 제 스스로 이런 결론에 도달한 것이 아니라 다른 팀에서 이미 수행하는 방법이 좋아 보여 재빨리 복제해 왔다는 부연을 한 덕분에 좋은 평가를 받지 못했을 수도 있겠다는 생각이 듭니다. 여튼 지금까지의 생각은 시스템기획서는 동작의 시각적 설명과 데이터구조, 컨텐츠기획서는 경험의 클라이맥스에 대한 시각적 설명이 처음에 들어가야 하고 이 차이가 이들 둘 사이의 차이라고 생각합니다.
