기획자를 철저히 망가뜨리는 방법 (2)

지난 기획자를 철저히 망가뜨리는 방법 (1)에서 현대에 그리 쓸모 있어 보이지도 않고 또 다른 소프트웨어 개발 업계에서는 프로젝트 조직 내에 수직 계열화 한 사례를 찾아보기도 어려운 이런 직군이 여전히 프로젝트에 속해 딱히 프로덕션에 직접 관여하는 것처럼 보이지도 않는 문서와 엑셀 파일 작성을 하며 돈을 받고 있기 때문에 장기적으로 이들을 프로젝트로부터 제거해 효율을 올릴 수 있으며 이를 위해 기획자들을 파괴하는 열 가지 방법을 살펴봤습니다. 원래 계획은 글 하나로 끝내는 것이었지만 미리 준비한 방법의 절반도 채 다루지 못한 상태로 거의 1만 5천글자에 도달해 버렸기 때문에 글을 나누기로 결정했습니다. 이 글은 ‘기획자를 철저히 망가뜨리는 방법’의 두 번째 글입니다.

열 한 번째. 기획자가 제안한 데이터구조와 동작 방식을 곧이곧대로 구현하세요. 논리적으로 더 올바른 방법, 체계적인 접근 방법, 기 구현된 비슷한 기능의 존재를 절대 말하지 말고 문서에 표현된 그대로 개발하세요. 바보같은 기획자는 오히려 기뻐할 겁니다. 엔지니어들이 여러 경로를 통해 자료구조나 데이터베이스 이론을 공부하고 이 지식에 기반해 데이터구조를 설계하는 것에 비해 기획자들은 이런 이론적 기반 없이 그저 다른 사람들이 과거에 작성한 기획서를 보고 이를 흉내내는 방식으로 데이터구조를 제안하는 것처럼 보입니다. 가령 처음으로 아이템 데이터를 제안하는 기획서에는 과거나 지금이나 Item[id].Usable = true 같은 구조가 등장하곤 하는데 사실 이 데이터는 아무런 의미도 없습니다. 아이템이 어떤 역할을 수행하기 위해서는 아이템을 사용할 때 일어나야 할 어떤 로직에 대한 연결이 필요하기 때문입니다. 가령 여러 가지 상호작용을 스킬과 스킬 효과의 관계로 정의하곤 하는 여러 MMO 게임에서 사용하면 체력을 회복하는 포션 아이템을 만들어내려면 단지 아이템 데이터에 이 아이템의 사용 가능 여부만을 기입해서는 안됩니다. 당연히 이에 뒤따르는 상황에 따라 사용자의 체력을 올려 주는 데이터가 포함되어야 합니다. 하지만 이를 함께 설계하는 사례를 찾아보기는 어렵습니다. 하지만 이런 문제를 지적하고 또 논리적으로 모호함을 제거한 구조를 제안하더라도 기획자로부터 좋은 피드백을 받기는 쉽지 않습니다. 이들은 데이터구조에 대한 얕은 기반으로 인해 자신이 제안한 방식 대로 데이터를 정의할 때 일어날 온갖 문제를 제대로 내다보지도 못하고 있습니다. 이들과 협의하며 시간을 낭비하기 보다는 이들이 제안한 모양 그대로 만들어야 합니다.

가령 던전 입장권을 매 두 시간에 한 번 받는다고 해 봅시다. 이를 표현하기 위한 적당한 데이터는 ‘매 두 시간 마다’를 정의한 부분과 이 조건에 일치할 때 부여할 던전 입장권을 서로 연결하거나 서로 같은 줄에 나타나는 모양일 겁니다. 그런데 기획자에 따라 이런 요구사항의 논리 구성과 데이터구조 사이의 관계를 잘 이해하지 못하고 엉뚱하게도 아이템을 획득하는 동작을 하니 이 동작을 아이템에 표현하려고 할 수 있습니다. 가령 던전 입장권 데이터에 이 아이템을 획득할 인터벌을 기입하도록 하는 식으로요. 이 방법이 틀렸다고 하기는 쉽지 않습니다. 하지만 대충만 생각해봐도 매 두 시간 마다 획득하는 입장권과 그렇지 않은 입장권을 구분하려면 똑같이 생긴 던전 입장권 아이템을 두 개 만들어야 합니다. 이를 확이냏 입장 여부를 결정해야 하는 던전 입장 절차에 아이템 두 종류 이상을 기입할 수 있도록 준비해야 하는 일이 발생하는 것은 덤입니다. 하지만 이를 기획자에게, 특히 이전에 설명한 대로 스스로 의사결정을 할 권한이 거의 없는 기획자라면 명백히 이상한 데이터구조를 조정하고 싶어도 이를 실행하기는 어렵습니다. 그냥 기획자가 제안한 그대로 구현하면 이런 여러 고민을 없앨 수 있습니다. 어차피 데이터는 기획자가 입력하니 그 과정에서 일어날 여러 가지 문제에 대해 깊이 고민하지 않아도 됩니다. 특히 기획자는 자신의 권한을 넘어설 가능성이 높은 의사결정 상황에 내몰리지 않아도 되고 또 자신이 제안한 모양 그대로 개발된 상태를 보고 오히려 기뻐할 겁니다.

열 두 번째. 미들웨어의 데이터를 절대 직접 컨버팅하게 만들지 마세요. 반드시 기획자가 미들웨어에 표시된 숫자를 엑셀에 받아 적은 다음 이를 컨버팅하게 하세요. 이는 바로 위 ‘열 한 번째’ 항목과 관련이 있습니다. 아주 오래 전 제대로 된 미들웨어 없이 직접 바닥부터 엔진을 개발하는 팀에서 일한 적 있는 사람들은 처음부터 인하우스툴이 아주 부실한 상태에서도 문제 없이 게임을 개발해 왔습니다. 가령 개발환경이 불친절하기로 악명이 높은 퀘이크 엔진으로도 퀘이크 자기 자신 뿐 아니라 여러 게임들이 멀쩡하게 개발되었습니다. 이런 시대를 지나온 기획자들은 현대적인 개발 환경에 대해 딱히 고민하지 않는 것처럼 보입니다. 울지 않는 아이에게 밥을 줄 필요가 없듯 요구하지 않는 편의를 미리 제공할 필요가 없습니다. 가령 기획자가 엑셀 데이터에 정의한 어떤 게임 상 물체의 충돌 영역을 엑셀 데이터 상에 정의하게 해 달라고 제안할 수 있습니다. 두 칼럼에 걸쳐 첫 번째 칼럼에는 충돌 영역의 형태인 정육면체, 실린더, 콘, 스피어 따위를 선택하게 합니다. 이어지는 두 번째 칼럼에는 앞서 선택한 충돌 영역의 형태에 따라 영역을 결정하는 숫자를 입력하게 합니다. 정육면체는 한 변의 길이를, 실린더는 반지름과 높이를, 콘은 반지름과 각도를, 스피어는 반지름을 입력하도록 할 수 있을 겁니다. 분명 잘 동작할 것이기에 기획자는 딱히 불평하지 않을 가능성이 높습니다.

하지만 현대적인 개발 환경 관점에서 이 방법은 어이없습니다. 분명 이 데이터를 입력하고 테스트 할 기획자는 엑셀에서 이 값들을 입력한 다음 텍스트 포멧으로 컨버팅 하고 서버와 클라이언트를 실행하고 이 물체가 배치된 레벨로 이동한 다음 물체에 직접 상호작용 해 충돌 영역이 올바르게 설정되었는지를 확인해야 합니다. 만약 충돌 영역이 의도와 달리 설정되었다면 다시 클라이언트와 서버를 종료하고 엑셀을 실행해 값을 고친 다음 앞서와 똑같은 절차를 반복합니다. 각 이터레이션에는 몇 분이 필요한데 이 과정은 현대적인 개발 환경에서 그냥 미들웨어가 제공하는 화면에서 프리뷰 하고 여기에 사용한 값을 바로 저장하면 될 일입니다. 하지만 여전히 과거에서 일하는 기획자들에게 그런 환경을 제안한들 그 가치를 알아보는 사람은 없거나 거의 없을 겁니다. 오히려 그런 프리뷰 환경과 값을 텍스트 모양으로 변환하는 체계를 구축할 필요가 없으니 개발은 훨씬 단순해지고 출시일은 훨씬 가까워집니다. 그러니 미들웨어에서 데이터를 프리뷰하고 이 근거가 되는 숫자를 직접 컨버팅 하게 만들지 마세요.

열 세 번째. 데이터 사용 방법을 절대 문서화 하지 마세요. 어쩔 수 없이 문서화 해야 한다면 늘 참고하는 잘 정리된 API 문서와 최대한 다른 모양으로 작성하세요. 가령 API 스펙 문서에서 함수 모양과 각 인자를 설명하는 방법에 도움을 받는다면 이 방법을 사용하지 마세요. 기획자들은 그저 엑셀 파일에 데이터를 기입할 줄 아는 사람들일 뿐입니다. 이들은 자신들이 데이터를 입력할 방법이 문서화 되어 있지 않아 어려움을 겪으면 그저 엑셀 파일마다 워크시트를 추가해 각 칼럼의 사용 방법을 그 시점의 동작에 맞춰 기입하는 식으로 문제를 해결하는데 익숙합니다. 사실 이 행동은 API 도큐먼트를 작성하는 행동과 비슷하지만 이 과정은 자동화 되어 있지도 않고 또 엑셀 워크시트 상에 기입된 각 칼럼의 사용 방법은 시인성이 극도로 나쁘기까지 합니다. 하지만 이들은 필요하면 자신들이 문서를 작성하고 또 그 문서가 얼마나 보기 어렵고 유지보수 하기 어려운지에는 별 관심이 없습니다. 그저 끝없는 초과근무로 문제를 돌파하려고 할 겁니다. 그러니 이들을 위한 문서는 필요하지 않습니다.

가령 위 ‘열 두 번째’에 예를 든 엑셀 파일에 물체의 충돌 영역을 직접 입력하게 만드는 사례를 생각해 봅시다. 일단 현대적인 프리뷰가 안 되는 근본적인 문제가 있지만 이는 기획자들이 문제로 여기지도 않을 테니 넘어가고 첫 번째 값인 충돌 영역의 형태에 따라 두 번째 값인 충돌 영역을 정의하는 값의 종류와 개수가 달라집니다. 직육면체나 구는 숫자 하나만 필요한데 전자는 한 변의 길이, 후자는 반지름의 길이입니다. 실린더와 콘은 값 두 개가 필요하지만 두 값의 용도는 서로 다릅니다. 만약 이들을 인터넷에서 흔히 접할 수 있는 여느 API 도큐먼트 모양으로 만들어 두고 또 이를 자동화 하는 단순한 방법을 사용할 수도 있지만 애초에 이런 방법이 존재한다는 사실을 알지도 못하고 또 자신들의 방식에 딱히 의문을 가지지도 않는 사람들에게 이런 방식을 제공할 이유가 없습니다. 그저 그들이 그들 스스로 워크시트를 추가하고 각 칼럼의 사용 방법을 직접 문서화 하도록 그냥 방치하세요.

열 네 번째. 빌드가 끝나기 전에 개발이 ‘완료되었다’고 말하세요. 기능을 개발하며 내 자리에서 컴파일 해 미들웨어 상에서 동작을 확인하면 사실 이미 개발이 완료된 것이나 다름없습니다. 코드를 커밋하고 CI에 의해 바이너리가 배포될 때 까지 기다린 다음 다시 이를 테스트하는 것은 불필요할 뿐 아니라 시간 소모적인 일입니다. 앞서 프로젝트에서 비용이 가장 낮은 사람들이 기획자라는 사실을 이야기한 바 있는데 이 관점에서 효율적으로 행동하려면 바이너리가 배포되기 전에 이미 테스트는 끝났으므로 이 시점에 바로 기획자에게 개발이 완료되었다고 선언함으로써 시간을 크게 절약할 수 있습니다. 기획자는 아마도 새 바이너리가 배포되기 전에 형상관리도구 상의 버전을 업데이트 하고 기능을 테스트 하려 하겠지만 분명 동작하지 않을 겁니다. 아직바이너리가 배포되기 전이니까요. 이에 대한 질문을 받으면 CI 상태를 보여주고 앞으로는 테스트 하기 전에 CI로부터 빌드 상태를 확인한 다음 테스트 하라고 안내하면 됩니다. 그러면 빌드 하는 동안, 바이너리가 배포되는 동안, 기획자가 이를 받아 테스트 하는 동안의 시간을 절약하고 이 시간 동안 다른 더 생산적인 일을 할 수 있게 됩니다.

열 다섯 번째. 사용자가 3천만명일 때 발생할 상황을 미리 질문하세요. 또 변조된 클라이언트에 의해 발생할 수 있는 문제에 대한 기획적 해법을 요구하세요. 실무 기획자는 근본적으로 미래를 보는 시각이 부족합니다. 또한 자신의 업무에 매몰되어 있을 때가 많아 시야가 좁기도 합니다. 때문에 이들은 짧게는 자신이 요구하는 기능이 필요로 하는 개발 비용을 잘 모르기도 하고 또 미래에 무슨 일이 일어날 수 있는지도 잘 모릅니다. 가령 현대에 가까워질수록 MMO 게임에서 한 장소에 모일 수 있는 플레이어 수는 점점 더 줄어드는 추세입니다. 네트워크 기술이 발달하고 또 클라이언트가 서버의 승인에 기반해 행동하지 않더라도 서버와 비슷한 로직으로 일단 서버의 행동을 예측할 수 있을 만큼 클라이언트 측 처리속도 역시 발전했지만 이 기반에서 요구되는 플레이어 각각의 행동과 서로의 상호작용은 이 발전을 뛰어넘을 만큼 복잡하고 정교해졌기 때문입니다. 가령 이전에는 칼을 휘두를 때 내가 타겟팅 한 대상 한 명에게 대미지를 주면 됐기 때문에 동작은 훨씬 단순했고 이런 규칙에 기반해 한 장소에 더 많은 플레이어들이 모일 수 있었습니다. 하지만 현대에는 칼을 휘두른 궤적에 따라 이 안에 있던 다양한 대상이 대미지를 입을 수 있어 문제가 훨씬 더 복잡하고 이를 수용하기 위해서는 한 공간에 모일 수 있는 플레이어 수를 제약해야 합니다. 게임에 따라 종종 마을에서는 전투 행동을 할 수 없도록 제한할 때가 있는데 이는 마을에 모일 수 있는 플레이어 수를 늘리기 위한 목적도 있습니다.

이런 어려움은 기획자가 자신의 요구사항에 대한 긴 안목과 넓은 시야를 가지고 있으면 훨씬 줄어들 겁니다. 현대적인 복잡한 스킬 시스템에 의한 상호작용 요소를 가지고 있으면서도 전장의 한 장소에 200명이 한 번에 모일 수 있어야 한다고 기획자가 주장할 수 있는 이유는 이런 고찰이 부족하기 때문입니다. 그렇다고 이들에게 현대 게임의 변화를 설명하는 것은 적절하지 않아 보입니다. 그렇다면 종종 이들에게 같은 요구사항에 대해 아직 일어나지 않았지만 근미래에 일어날 수도 있는 질문을 해 이들의 안목과 시야를 개선할 수 있을지도 모릅니다. 가령 너무 오래된 ‘서버 단위’의 서버 구조에 익숙해진 나머지 오직 이 구조에서만 성립하는 요구사항을 포함한 기획서를 작성한 기획자가 있을 겁니다. 그렇다면 이렇게 질문하세요. 만약 이 서버에 동시접속자가 3천만명이면 어떻게 동작해야 하느냐고요. 같은 지역에 있는 다른 플레이어들의 목록을 보여주고 이들 중 상호작용 할 대상을 선택하는 인터페이스가 있다면 만약 이 지역에 2백만명이 접속 중이라면 어떻게 동작해야 하는지, 리스트뷰에 2백만 라인을 표시하면 되는지, 이 때 메모리 몇 기가가 필요한지를 말하며 질문을 이어가면 기획자의 시야를 넓히는데 큰 도움이 됩니다. 같은 맥락으로 클라이언트 - 서버 환경에서 클라이언트가 변조된 상황에서 일어날 수 있는 문제를 게임디자인 수준에서 해결하기를 요구하세요. 가령 흔한 스피드핵, 거리를 무시한 상호작용, 서버의 승인에 기반하지 않는 동작의 변조 같은 문제가 발생하지 않도록 이런 상황이 근본적으로 일어날 수 없는 기획적 방법을 고민하게 만드세요. 누구도 게임이 실행될 때 잉카인터넷 제품이 메모리에 떠 있게 하고 싶지 않잖아요?

열 여섯 번째. 이건 클라이언트(서버)의 일이라고 말하세요. 클라이언트(서버) 프로그래머와 절대 직접 이야기하지 마세요. 기획자에게 문제를 제기하고 기획자가 메신저 역할을 하게 하세요. 앞서 여러 항목들로 미루어 기획자들이 자기들 스스로도 잘 이야기하지 않는다는 사실을 잘 알고 있습니다. 그렇다면 다른 부서가 비슷하게 행동하며 좀 더 편안하게 일한다 하더라도 이 행동이 문제가 될 일은 전혀 없습니다. 이 관점에서 클라이언트 - 서버 환경에서 동작하는 로직을 개발하며 클라이언트(서버) 담당자와 직접 이야기하며 시간을 낭비할 필요가 없습니다. 대체로 프로젝트가 커질 수록 이들 사이의 물리적인 거리가 멀어져 이야기하기는 점점 더 어려워집니다. 복도를 가로질러 한참을 걸어갔지만 상대가 자리를 비웠다면 시간을 쉽게 낭비하게 됩니다. 앞서 기획자가 프로젝트 전체에서 가장 가격이 싼 사람들이라는 사실을 여러 번 이야기했습니다. 이번에도 이들을 활용하면 됩니다. 엔지니어들 사이에서 직접 이야기하는 대신 반드시 기획자를 중간에 끼워 기획자가 메신저 역할을 하게 만드세요. 가령 개발 중에 패킷에 정보를 추가해야 하는 상황을 가정해 봅시다. 원래는 2차원 좌표 정보만으로 문제를 해결할 수 있을 거라고 예상했지만 실제로는 3차원 좌표 정보가 필요했습니다. 하지만 이를 협의하기 위해 많은 시간을 쓸 필요가 없습니다. 이 문제를 기획자에게 말한 다음 상대에게 전달해 달라고 요청하면 됩니다. 기획자는 이야기가 필요한 사람들 사이를 오가며 마치 그리 멀리 떨어져 있지도 않은 마을 사람 NPC들이 서로에게 메시지를 전달해 달라며 퀘스트를 부여하는 것처럼 이야기가 필요한 여러 사람들 사이를 오가며 메신저 역할을 할 겁니다. 기억하세요. 이들의 가격이 가장 싸기 때문에 시간 대비 비용 효용을 생각하면 이 방법이 가장 효율적인 방법입니다. 또한 기획자는 개발 진행 상황을 따라잡을 수도 있으니 장점 뿐입니다.

열 일곱 번째. 기획자가 절대 미들웨어 에셋을 직접 수정하게 하지 마세요. 인터페이스, 텍스트, 애니메이션 등 모든 데이터는 ‘요청’만 하게 하고 절대 그들이 편집하게 하지 마세요. 관리 복잡성이 증가하기 때문이라고 설명하세요. 종종 기획자들이 현대적인 미들웨어를 직접 사용하려고 시도할 때가 있습니다. 이는 각 직군 별로 나뉘어 있는 역할을 침해하는 행위이기 때문에 문제 삼아 같은 일이 다시 일어나지 않도록 해야 합니다. 가령 프로젝트에는 분명 인터페이스를 제작하는 일을 하는 사람이 있을 겁니다. 언리얼 엔진을 예로 들면 인터페이스를 제작하는데 사용하는 위젯 블루프린트를 제작하는 업무만을 담당한 사람들이 있습니다. 이들은 위젯 블루프린트 에셋을 바닥부터 제작하고 엔지니어와 협의해 코드에 바인딩 된 부분과 그렇지 않은 부분을 구분해 인터페이스를 수정하며 나아가 다국어화에도 대응하는 역할을 합니다. 그런데 종종 기획자들이 이 업무 영역을 침범해 인터페이스를 수정하거나 다국어화 과정에 개입하려고 할 때가 있습니다. 이는 직군 별 업무 영역을 모호하게 만들어 관리 비용을 올리고 책임 소재를 모호하게 만듭니다. 때문에 기획자가 인터페이스를 수정하고 싶다면 반드시 담당자에게 서면으로 요청하게 하고 또 다국어화 역시 오직 문서를 통해 요청하게 해야 합니다. 이를 통해 모든 작업의 기록을 문서 모양으로 남기고 또 기획자들이 함부로 현대적인 미들웨어의 기능을 잘못 해석해 직군 별 업무 영역을 침범하려는 시도를 원천 차단할 수 있습니다.

열 여덟 번째. 함부로 테스트 데이터를 작성할 수 없게 하세요. 에셋 조립 절차를 최대한 복잡하게 만드세요. 데이터를 한 번 등록하면 삭제할 수 없게 하세요. 테스트 데이터를 절대 함부로 올리지 못하게 됩니다. 테스트 데이터는 항상 빌드 시연에 문제를 일으킵니다. 이전에 경험한 어떤 프로젝트에서는 아직 작업이 덜 된 아트 에셋이 시연용 레벨에 배치되어 있었는데 이를 사장님에게 보고하다가 퀄리티에 대해 나쁜 평가를 들은 다음부터 개발 중인 에셋이 레벨에 절대로 배치되지 못하도록 했습니다. 그 후로 같은 일이 일어나지 않았음은 물론이고 또 사장님이 개발 진행을 오해해 개발이 진행 중인 상태와 아트 퀄리티가 떨어져 보이는 상태를 구분해야 한다는 사실을 교육할 필요도 없어졌습니다. 어떤 기획자들은 테스트가 중요하다고 말하기도 합니다. 다양한 테스트 환경을 구축하고 우리 빌드 기반으로 테스트를 수행해 특징을 발견하고 이를 게임디자인에 반영할 수 있다고 생각하는 것 같습니다. 하지만 그럴 것 같으면 왜 게임회사에서 게임을 많이 플레이 하는사람들을 요구할까요. 다른 게임 경험으로도 충분할 경험을 왜 테스트 데이터를 만들어 직접 빌드에서 테스트 하려고 하는지 이해하기는 쉽지 않습니다. 테스트 데이터 때문에 개발 중 여러 가지 마이그레이션 작업의 복잡성이 증가하고 또 시연용 빌드를 만들 때 심각한 문제를 일으키기도 합니다. 특히 테스트 데이터가 빌드에 포함되지 않아 오동작을 일으키는 추적하기 어려운 문제를 맞이해 여러 사람들의 초과근무를 필요로 하게 될 수도 있습니다. 때문에 테스트 데이터를 작성하지 못하게 해야 합니다.

먼저 데이터를 작성하는 절차를 최대한 복잡한 모양으로 유지해 함부로 테스트 데이터를 작성할 엄두를 내기 어렵게 만드세요. 가령 테스트 레벨을 새로 만들어 클라이언트 - 서버 환경에서 동작하게 만드는데 절차에 익숙한 사람 기준으로 1시간 이상이 필요하도록 하세요. 데이터들이 서로를 참조하게 만들고 모든 데이터가 한 번에 온전히 입력되지 않은 상태라면 밸리데이션을 절대 통과할 수 없게 만들면 익숙하지 않은 사람들을 쉽게 하루 이상의 트러블 슈팅에 빠지게 만들 수 있습니다. 더 단순한 예를 들면 인게임에서 상호작용 하는 어떤 물체가 있다고 합시다. 나무라고 하면 좋겠네요. 새로운 나무 에셋을 등록하려면 이 에셋이 근거한 엑셀 데이터가 필요합니다. 그리고 엑셀 데이터를 추가하려면 이 데이터가 가리킬 나무 에셋이 필요하고요. 이 두 가지 참조 관계가 온전히 입력되기 전에는 밸리데이션을 통과하지 못하게 해 데이터를 작성조차 할 수 없게 만들면 이 과정에 익숙해져 어느 한 쪽을 먼저 만든 다음 이전에 작성한 임시 데이터를 할당해 밸리데이션을 통과하는 꼼수를 모르는 사람은 이 단계의 트러블슈팅을 위해 많은 시간을 소비하게 됩니다. 나아가 같은 나무 에셋이 둘 이상의 상호작용 데이터에 연결될 일은 없으므로 이를 금지해 익숙하지 않은 작업자가 슬쩍 전해 들은 꼼수로 이미 제작된 다른 에셋을 할당하려 하면 이를 문제 삼아 밸리데이션을 통과하지 못하도록 하는 것도 좋은 방법입니다.

특히 한 번 입력한 데이터를 삭제할 수 없도록 만들면 테스트 데이터 제작을 극적으로 위축시킬 수 있습니다. 앞서 엑셀 데이터를 읽어 더 빠른 접근을 위해 데이터베이스에 기록하는 시나리오를 설명했습니다. 이 상황에서 데이터베이스의 특정 데이터가 근거한 엑셀 데이터가 사라지면 이를 안전하게 처리하도록 만드는데 시간과 노력이 필요합니다. 간단히 엑셀에 한 번 추가한 데이터는 절대 삭제하면 안 된다는 규칙을 만들면 이런 시간과 노력을 쓸 필요가 없어집니다. 또한 한 번 데이터를 작성하면 삭제할 수 없는 환경에서 기획자들은 애초에 데이터를 작성하는 행동 자체에 소극적으로 변합니다. 이를 통해 시연에 문제를 일으키는 잘못된 데이터나 테스트 데이터가 빌드에 포함되어 비용을 증가 시키지 않도록 할 수 있습니다. 프로젝트가 현재 이 원칙을 잘 따르고 있는지 살펴보는 간단한 방법은 테스트 레벨, 테스트 데이터, 테스트 오브젝트 따위가 얼마나 많이 입력되어 있는지를 살펴보면 됩니다. 가령 어느 MMO 프로젝트에 접근 가능한 레벨은 오직 실제 런칭에 포함될 레벨과 극 소수의 테스트 레벨 뿐이라면 그 팀은 이 원칙을 아주 잘 지키고 있다고 평가할 수 있습니다.

열 아홉 번째. 기획자들이 어제 내가 플레이 한 게임을 안 해 봤다면 기획자들이 게임을 하지 않는다며 비난하세요. 다른 소프트웨어 개발 프로젝트와 비교해 상용 게임 소프트웨어 프로젝트에서 기획자가 반드시 해야 할 일 중 하나는 여러 게임을 플레이 해 보는 것입니다. 이들은 에셋을 제작하지도 않고 프로덕션 코드를 작성하지도 않으므로 분명 업무에 여유가 있을 겁니다. 그런 여유는 여러 가지 게임을 플레이 해 보고 경험을 쌓는 것입니다. 여러 게임을 플레이 함에 따라 앞서 설명한 의미 없는 테스트 데이터를 작성하려는 시도를 줄일 수도 있습니다. 이 업계의 여러 구성원들은 종종 자기 자신이 여러 게임의 고객인 경우가 있습니다. 이들은 여가 시간에 게임을 플레이 하며 생계를 위해 다른 게임을 개발하는 일을 합니다. 이런 상황에서 요구사항을 작성하는 기획자는 구성원들이 플레이 해 보는 게임을 모두 빠짐 없이 플레이 해 봤어야 한다고 생각합니다. 가령 내가 어제 플레이 한 어떤 게임에 대해 기획자에게 이야기하고 만약 기획자가 이를 플레이 하지 않았다고 말한다면 이를 강하게 비난해야 합니다. 기획자는 여러 게임을 플레이 해 보고 경험을 넓히고 시장의 다른 플레이어들이 어떻게 행동하는지, 같은 문제를 어떤 방식으로 해결했는지 계속해서 파악하고 학습해야 합니다. 그렇다면 당연히 프로젝트 구성원들이 개인적으로 플레이 한 온갖 게임들을 플레이 해 본 상태여야 합니다. 그렇지 않다면 이는 문제입니다.

스무 번째. 개발은 반드시 문서가 작성된 후 두 달 이상이 경과한 다음 시작하세요. 작성자는 이미 문서의 주요 내용을 잊어버렸을 겁니다. 이제 주도권은 내 겁니다. 기획서를 받은 시점으로부터 실제 작업 착수는 최대한 늦은 시점에 시작하세요. 앞서 마일스톤 단위로 함께 제출된 모든 기획서를 극도로 주의 깊게 살펴보고 이들 사이에 발생할 상호작용을 철저히 검토해야 미래에 일어날 문제를 최소화 할 수 있음을 설명했습니다. 이런 신중한 검토에는 몇 주가 걸릴 수 있습니다. 마일스톤이 시작된 다음 문서를 검토하는데 충분한 시간을 사용할 수 있도록 프로젝트 구성원 전체에 걸쳐 이 작업의 중요성을 인지 시켜야 합니다. 또 검토 중에 나타나는 질문은 이전에 설명한 대로 바로바로 담당 기획자 혹은 그의 상관에게 문의해 해결하고 기획서에 언급되지 않은 동작이 나타나면 동작이 정의되어야 함을 알린 다음 동작이 정의되기 전에는 다음으로 진행해서는 안됩니다. 또 기획자들이 다른 일을 한다는 핑계로 몇 주 전에 전달한 기획서에 대한 질문에 즉시 답하지 못한다면 이는 기획자의 전문성에 심각한 문제가 있는 상황으로 평가할 수 있습니다. 기획자는 어떤 상황에서도, 또 얼마나 시간이 흘렀더라도 이전에 자신이 제출한 요구사항에 대해 정확히 기억하고 있어야 하며 언제든 올바른 답변을 할 준비가 되어 있어야 합니다.

종종 기획자도 인간이기에 단기기억 시스템과 장기기억 시스템으로 구성되어 있고 이들 중 일부는 휘발될 수 있다고 변명할 수도 있습니다. 분명 그래서는 안되며 그런 행동은 기획자의 전문성에 의문을 품을 수 있을 만한 문제라고 이야기했습니다만, 만의 하나 극도로 넓은 아량을 발휘해 이런 상황을 인정해줄 수도 있습니다. 다만 이런 아량은 절대 흔하지 않으며 기획자를 제외한 나머지 프로젝트 구성원들이 극도로 이해심이 깊고 기획자들을 배려하기 때문에 그럴 수 있음을 반드시 주지 시켜야만 합니다. 하지만 시간이 지나 기획자가 정확히 기억하지 못하는 주제에 대한 주도권은 이제 기획자가 가지지 않습니다. 과거에 어떤 문서를 작성했든, 이전에 어떤 회의를 했고 또 어떤 기록을 남겼든 이는 중요하지 않습니다. 이제 그 사이에 요구사항을 신중하게 파악한 기획자를 제외한 다른 직군들이 본격적으로 주도권을 가지고 개발을 수행할 차례입니다.

지금까지 기획자를 철저히 망가뜨리는 방법 (1), 기획자를 철저히 망가뜨리는 방법 (2)를 통해 게임 소프트웨어 개발 프로젝트에 속해 일하는 소위 ‘기획자’들과 함께 일하는 방법을 살펴봤습니다. 정확히는 이들과 함께 일함과 동시에 근본적으로 현대 게임 소프트웨어 개발 프로젝트에 이들이 필요하지 않다는 사실에 근거해 이들의 권한을 줄이고 사기를 떨어뜨리고 스스로 판단할 수 없게 만드는 방법을 살펴봤습니다. 나아가 이 상태를 계속해서 유지해 이들이 프로젝트를 떠나게 만들거나 비가역적인 신체적, 정신적 타격을 입힐 수 있습니다. 이런 행동들은 궁극적으로 현대 소프트웨어 개발에 더 이상 필요해 보이지 않는 기획자들을 프로젝트로부터 제거해 보다 유효한 인원들을 채용해 프로젝트의 효율성을 높여 런칭과 성공에 한 발짝 더 가까이 다가가는데 도움을 줄 겁니다. 기획자들을 망가뜨리기는 그리 어렵지 않습니다. 게임디자인 직군의 슬픈 점은 나머지 부서들과 목표가 다르다는데 있다는 점을 기억하세요.