절망의 벽

게임을 만들다 보면 어느 시점에 지금까지 만든 결과를 뛰어 넘는 완전히 새로운 결과를 내야 하는 순간이 있습니다. 흔히 GDC 같은 곳에 나와 발표하는 대단한 게임디자이너들을 보면 처음부터 게임의 모든 요소에 의도를 가지고 지독한 탑다운 방식으로 만들어지는 것이야 말로 게임 소프트웨어라고 생각할 수 있고 실제로 어느 정도 그런 속성을 가지고 그런 방식으로 개발되는 사례도 있습니다. 하지만 또 다른 경우에는 그저 회사의 다음 프로젝트를 개발하기 위해 원하지 않았지만 프로젝트를 시작해 필요 이상의 기대를 받아 이를 충족하기는 해야 하지만 탑다운으로 내려 보낼 아무런 목표도 의지도 없는 분이 프로젝트를 총괄할 수 있고 이 역시 그리 드물지 않습니다. 요구사항이 탑다운으로 전달되어 개발할 경우 저와 같이 시스템디자인 역할로 게임의 여러 부분을 요구사항에 맞게 설계하고 설계의 구현에 따라 양산 파이프라인을 구축하며 이 과정에서 일어나는 문제를 해결하고 또 서로 다른 부서들 사이에 인터프리터 역할을 하는 사람은 일하기 훨씬 편합니다. 이미 프로젝트 리더십은 자신이 원하는 바를 뚜렷하게 알고 있으며 이를 잘 표현하든 잘 못 표현하든 저는 그 요구사항을 올바르게 접수할 것이기 때문입니다. 만약 프로젝트 리더십과 저 사이에 의사소통에 실패하더라도 지속적인 진행 상황 보고를 통해 의사소통의 실패를 최대한 빨리 눈치 채고 이를 수정할 수도 있습니다. 이 과정은 제 입장에서 일하기 아주 편한 환경입니다.

반면 그렇지 않은 경우, 그러니까 탑다운이 아닌 바텁업 방식으로 개발해야 하는 상황이 있고 제 개인적인 경험 상 후자의 방식으로 개발한 프로젝트가 더 많았습니다. 리더십은 프로젝트에 대한 비전을 가지고 있지 않을 때가 많았고 회사 역시 우리들에게 뚜렷하게 원하는 것이 없었습니다. 처음에는 프로젝트를 시작해 많은 사람들에게 긴 기간에 걸쳐 큰 돈을 투입하는 회사 입장에서 우리들에게 요구하는 바가 별로 없다는 사실에 충격을 받기도 했지만 회사 입장에서 우리들에게 원하는 것은 출시와 수익일 뿐 이를 실행하는 우리들이 만든 제품이 어떤 모양을 가지고 있든 그것은 그리 중요한 문제가 아니라는 사실을 인정할 수밖에 없었습니다. 이는 프로젝트를 맡은 리더십이나 고위 의사결정자들 역시 마찬가지입니다. 이들 역시 회사 또는 경영진의 결정에 의해 피칭을 준비해 프로젝트를 킥오프 했지만 사실 명확한 요구사항 없이 그저 장르와 장르의 특성에 기반한 주로 ‘뻔한 요구사항’ 수준의 요구사항만을 가지고 프로젝트를 시작할 때가 많고 이 상태는 생각보다 오래 지속되곤 합니다. 이런 상태로 개발하면 뭔가 큰 일이 날 것 같지만 실제로는 오히려 아무 일도 일어나지 않는데 시작 멤버들이 올바른 사람들을 데려와 개발하기 시작했다면 높은 수준의 요구사항이 불분명함에도 불구하고 대강 그럴듯하게 돌아가는 빌드 수준에 도달하고 이를 적극적으로 주의 깊게 들여다보고 빌드를 직접 만져보지 않는 이상 아무 일 없이 순조롭게 개발되고 있다고 판단할 수밖에 없습니다. 그도 그럴 것이 높은 수준의 요구사항이 없다 하더라도 일단 기반 장르가 MMO라면 우리들은 이전에 다른 프로젝트에서 해 왔던 것처럼 이 게임을 만들고 있을 테고 최소한의 설정에 기반한 에셋이 생산되면 이를 기반으로 특색 없는 게임을 만들어내기까지는 어렵지 않게 도달할 수 있기 때문입니다.