왜 존은 실패할 수밖에 없었나

이전 존에게 진 빚에서 둠의 창조자들이라는 책을 읽은 이야기를 했습니다. 저는 실시간으로 둠을 플레이 한 세대는 아닙니다. 그보다 훨씬 나중에 퀘이크를 플레이 하며 비로소 일인칭 슈터 장르에 매력을 알게 됐고 이드소프트의 여러 게임 중 머리 속에 가장 강렬한 인상을 남긴 게임은 둠이 아니라 퀘이크였습니다. 또 이드소프트의 게임 중 가장 오랜 시간을 들여 플레이 한 게임은 퀘이크 3이었습니다. 이전까지는 이 모든 게임들이 그저 이드소프트에서 개발한 게임이라고, 존 카맥이 크게 관여한 게임이라고 생각해 왔는데 이번에 책을 읽으며 각각의 게임을 내놓을 때 어떤 일이 있었는지, 또 어떤 사람들이 더 많이 관여했는지 조금은 알게 됩니다. 가령 두 명의 존 중 존 로메로는 울펜슈타인과 둠에 더 많이 관여했고 퀘이크에는 전혀 관여하지 않았다는 사실을 알게 됐는데 이전까지는 그가 이드에서 레벨디자인에 관여했다고 알고 있었기 때문에 별 생각 없이 깊은 인상을 받은 첫 일인칭 슈터 장르인 퀘이크 역시 이 사람이 관여했을 거라고 생각했습니다. 하지만 제가 경험한 게임 중 이 사람이 관여한 레벨디자인은 헤러틱을 통해 처음 접했는데 의미 있었지만 딱 그 정도가 아니었을까 싶습니다.

한편 존 로메로가 존과 여러 모로 의견이 달라지고 또 개발에 집중하지 않으면서도 개발에 대한 권한은 유지하려고 하며 일어난 여러 가지 문제로 인해 결국 회사를 떠나게 되는데 이 다음의 이야기는 흥미로우면서도 슬프고 또 아주 먼 옛날의 이야기이며 이제는 흑역사로 치부되어 거의 이야기되지 않는 것 같지만 책에 묘사된 사건의 진행은 게임 만드는 일을 시작한 다음 경험했던 일과 여러 모로 닮아 있어 한번 쯤 생각해 보고 지나갈 가치가 있다고 생각합니다. 존 로메로는 이드소프트에서 개발팀이 아주 작을 때부터 울펜슈타인 3D의 레벨디자인 도구를 직접 만들고 그 도구를 사용해 초창기 일인칭 슈터 장르의 레벨을 만들었다고 알려졌습니다. 이전에 해본 적 없는 업무를 정의하고 이에 적합한 도구를 개발하고 직접 레벨디자인을 해 냈으며 그 결과가 울펜슈타인, 헤러틱, 둠에서 경험한 바로 그 레벨디자인이라고 생각하면 완전히 없던 것을 창조해냈다는 관점에서 엄청나다고 말하지 않을 수 없습니다. 존에게 진 빚에서 이야기한 대로 울펜슈타인은 그 기술적 한계 때문에 레벨디자인이 그리 인상적이라고 느끼지는 못했습니다. 여느 문과 벽이 모두 똑같이 생겼고 특히 모든 장소에서 바닥과 천장이 똑같이 생긴 이상 이 공간을 가상의 삼차원 공간이라고 인식하기는 너무나 어려웠습니다. 하지만 헤러틱에서 본격적인 고저차와 복층 공간을 경험하며 깊은 인상을 받았는데 적어도 이 때 까지는 존 로메로가 제가 한 경험을 만들어내고 있습니다.

이전까지 알고 있던 어렴풋한 이야기는 두 명의 존 중 한 명은 게임의 기술적인 면과 순간의 경험에 집중한 반면 다른 한 명은 게임의 스토리와 내러티브에 집중했기 때문에 서로 의견 차이가 생겨 다른 회사로 갈라 서게 되었다는 것이었습니다. 하지만 그렇게 개발된 게임은 형편 없는 수준이었고 그가 관심을 가지고 있는 것처럼 보이던 스토리와 내러티브, 게임디자인이 리드하는 개발 결과로 해석하기에 부끄러웠는데 어쩌면 이 시대의 이 결과가 지금까지도 여러 조직에서 게임디자인이 기술 조직에 대체로 끌려 다니는 처지에 놓이게 만들었는지도 모릅니다. 그런데 책에 언급된 이야기는 꽤 달랐습니다. 존 로메로는 그 시점까지의 성공에 고무되어 차기작 개발에 집중하지 않은 모양입니다. 대외 업무에 집중했다고 하면 크게 틀리지는 않아 보입니다. 회사 바깥과 직접 이야기하고 개발 계획을 설명하고 현재 진행 상황을 고객들에게 알리고 개인적인 비전을 공유하는 행동들은 업계의 전설로써 할 수 있는 일이고 또 어느 정도는 해야 하는 일이라고도 생각합니다. 하지만 이런 대외 업무에 집중하기 시작하면 자연스럽게 개발 업무에 집중하기는 어려운데 이 사실을 인정하고 자신이 집중해야 하는 일과 그렇지 않은 일을 구분해 각각이 온전히 수행되도록 다른 사람들에게 일을 넘기는 것 역시 중요합니다. 하지만 행간에서 존은 대외 업무에 집중하면서도 여전히 개발에 권한을 잃을 생각이 없었고 이는 일정에 문제를 일으킵니다.

결국 제가 처음으로 의미 있는 일인칭 슈터 장르에서 삼차원 공간 레벨디자인이라고 생각한 퀘이크는 존이 떠난 다음에 만들어진 것이었고 그 즈음에 회사를 떠난 존은 자기 회사를 만들어 이번에는 스스로 하고 싶은 대로 하는 환경에서 개발하려고 한 것 같습니다. 이 시대의 전설들은 각자 자기 회사에서 게임을 만들었습니다. 가령 로드 브리티시 - 삼평동에서는 이 사람의 이름을 함부로 말하면 안됨 - 는 오리진, 시드마이어는 파이락시스, 윌 라이트는 맥시스 같은 식이었는데 존이라고 해서 이 대열에 합류하지 말란 법은 없었습니다. 게다가 대외 활동을 통해 그는 이전 이드소프트의 얼굴이며 이드소프트 그 자체나 다름 없었고 다른 존이 방 안에서 코딩에 집중하며 외부와 거리를 두며 존재감을 낮추는 상황에서 모든 조명은 또 다른 존이 받을 수밖에 없었습니다. 이런 스타 개발자가 이드를 떠나 회사를 만들겠다고 할 때 투자할 생각을 하지 않기 쉽지 않았을 겁니다. 돈이 있다면 말입니다. 이 존은 더 이상 기술적인 제한과 한계를 인정하고 싶지 않았고 게임디자이너로써 비전을 실현할 방법으로 게임디자인에 의해 핵심 의사결정이 일어나는 방식으로 개발하고 싶었던 것 같습니다. 비디오 게임 업계는 처음부터 스스로 동작하는 빌드를 만들 수 있는 사람들로부터 시작되었고 이 시대에는 게임디자인이라는 직군 자체가 없었습니다. 이드소프트에서는 게임 엔진을 개발하는 존과 레벨디자인을 담당한 존으로 업무가 구분되었는데 후자가 현대적인 게임디자인에 가까운 업무라고 생각합니다.

현대에도 기술 조직이 핵심 의사결정을 수행할지, 아니면 기획 조직이 핵심 의사결정을 수행할지에는 논란이 있습니다. 대부분의 프로젝트가 기술 조직이 핵심 의사결정을 수행하게 만드는데 이들이 실제 동작하는 빌드를 개발할 능력이 있기 때문입니다. 이 능력은 권한으로 연결되는데 비용이 너무 높거나 지금까지 개발해 오며 세운 어떤 가정과 너무 동떨어진 요구사항은 거절될 수 있습니다. 요구사항이 아무리 게임에 의미 있는 영향을 끼칠 수 있다 하더라도 이를 증명하려면 실제로 개발해 봐야 하고 기획 조직은 스스로 개발할 수 없기 때문에 요구사항이 기술 조직의 입맛에 맞지 않으면 손이 발이 되도록 빌거나 예쁘게 설득하려고 노력하거나 아니면 포기할 수밖에 없습니다. 이런 환경에서 일하다 보면 핵심 의사결정은 요구사항을 거절하는 방법으로 기술 조직이 수행하고 있으면서도 여전히 프로젝트에는 기획 조직이 있기 때문에 개발 계획, 요구사항의 집합 등에 대한 의견은 그 의사결정을 기획 조직에서 수행하지 않았더라도 기획 조직이 떠안게 되는데 이 상황은 기술 조직이 더더욱 책임지지 않는 의사결정을 반복하게 만듭니다. 종종 분명 올바르게 동작하지만 직접 플레이 해 보면 동작할 뿐 경험을 주지는 못하는 이상한 결과가 시장에 나타날 때가 있는데 이런 결과의 상당수는 기획 조직에서 핵심 의사결정을 하는데 실패했기 때문일 가능성이 있다고 생각합니다. 한편 기술 조직은 스스로 빌드를 만들어낼 수 있기에 어떻게든 결과를 만들어 내는데 이 기술 조직이 핵심 의사결정을 기획 조직에 맡기고 요구사항의 기술적 한계, 비용의 한계 등을 합의해 대안을 만들기를 반복한 결과 잘 동작하면서도 의미 있는 경험을 주는 결과를 만들어낼 수도 있습니다.

프로젝트에 따라 아트 조직이 핵심 의사결정을 독점하는 경우도 많은데 아트 조직에 유명한 일러스트레이터가 있다면 여러 의사결정이 이들의 요구사항을 맞추는데 집중됩니다. 가령 캐릭터의 외형에 영향을 주는 의상 아이템을 상의와 하의로 구분하고 모자, 장갑, 신발을 별도로 장착할 수 있게 만들자는 요구사항은 실제 세계의 규칙과 거의 같아 딱히 이상하지 않을 수 있습니다. 또 이렇게 개발하면 상대적으로 적은 에셋만 제작해도 꽤 다양한 배리에이션을 만들 수 있다는 장점도 있습니다. 그런데 만약 아트 조직에서 시각적 결과에 집중한 의사결정을 해 캐릭터의 전체 외형을 한 번에 바꾸도록 할 수도 있는데 이는 시각적으로 엄청나게 훌륭하기 때문에 의사결정자들의 이목을 집중시키기에 충분합니다. 기술적인 난이도 역시 실제 세계와 같이 각기 분리된 의상을 착용하는데 비해 한 번에 외형 전체를 변경하는 것은 훨씬 단순해 기술 조직의 동의를 얻기에도 나쁘지 않습니다. 하지만 게임 상에 배리에이션을 만들기 위해서는 이전에 비해 훨씬 많은 에셋을 만들어야 할 뿐 아니라 외형에 영향을 주는 아이템을 사용하는 보상 집행 계획을 크게 망가뜨립니다. 그저 의상을 조각조각 만들지, 아니면 한 덩어리로 만들지에 따라 MMO 게임에서 캐릭터 성장 메커닉 자체가 영향을 받는 결과로 이어지는데 보통 이런 핵심 의사결정에 관여하는 사람들은 이런 결과를 끝까지 인식하지 못한 채 의사결정을 하곤 하는 것 같습니다.

좀 더 강하게 분업화된 현대에도 여전히 기획 조직이 핵심 의사결정을 수행하기 어려운데 애초에 기획 조직이 막 생겨난 시대에 이들이 프로젝트의 핵심 의사결정을 수행하기는 어려웠을 겁니다. 이런 상황에서 존이 회사를 떠나 기획 조직이 핵심 의사결정을 할 수 있는 프로젝트를 하고 싶어 하는 것은 전혀 이상하지 않습니다. 어쩌면 적어도 방금 예를 든 외형 아이템을 각각 만들지 아니면 한 덩어리로 만들지 같은 지극히 시각적인 의사결정조차도 게임의 성장 메커닉을 완전히 달리 설계해야 하도록 만들 수 있다는 사실을 이해하는 사람들과 의사결정을 수행하고 싶었을른지도 모릅니다. 하지만 이런 의도를 예상할 수 있음에도 불구하고 둠의 창조자들에 언급된 존 로메로의 회사에서 일어난 여러 가지 일들은 결국 실패에 다다르는 전형적인 모습으로 흘러간 것 같아 보입니다. 이미 존의 새 회사는 프로젝트를 시작하는 순간부터 여러 가지 문제를 가진 채로 시작했는데 여기에 허리가 없는 개발팀, 너무 포괄적이고 또 희미한 비전, 기술의 완전한 부재, 대규모 개발팀이 작동하게 만드는 체계 부재 등 잘못될 수 있는 거의 모든 문제를 떠안고 퍼블리셔가 엄청난 손실을 떠안게 만들었습니다. 그 즈음 윙커맨더 4를 개발하는데 약 1천2백만 달러를 사용했다고 알려져 화재가 됐는데 에이도스가 존의 회사에 투자한 금액이 3천만 달러였다고 하니 당시로써도 엄청난 개발금액이라고 말할 수밖에 없습니다.

잘못될 수 있는 거의 모든 것이 잘못 됐고 또 전형적으로 기획 조직이 주도권을 가지고 핵심 의사결정을 수행하는 개발 조직을 만들려다가 실패한 사례임에도 몇 가지 특징에 대해서는 현대에도 비슷한 일이 반복되고 있어 좀 더 설명할 수 있을 것 같습니다. 먼저 존의 비전은 너무 포괄적이고 희미했는데 이를 인식할 수 있는 대표적인 신호는 개발팀의 고위 의사결정자로부터 나온 높은 레벨의 요구사항이 게임의 핵심 메커닉이 아니라 게임을 둘러싼 배경에 머물러 있는 것입니다. 가령 프로젝트를 완수할 수 있을 가능성이 높은 고위 의사결정자의 요구사항은 캐릭터가 던전에서 자신을 둘러싼 강력한 괴물들을 통쾌하게 쓸어버리고 보상을 획득하는 즐거움을 주는 아이소메트릭 뷰 게임이라는 식입니다. 이 요구사항에는 게임의 장르, 핵심 플레이 경험 따위가 모두 드러나기 때문에 일단 개발을 시작할 수 있을 뿐 아니라 하위 의사결정을 할 때도 길을 잃지 않을 수 있습니다. 가령 이 게임을 개발하다가 마을에 자기 집을 짓고 집 안에 가구를 들여놓아 방을 꾸밀 수 있는 기능을 넣어야 한다는 주장을 맞닥뜨릴 때 첫 요구사항으로 돌아가 강력한 괴물을 통쾌하게 쓸어 버리는 게임이라는 정의에 기반해 요구사항을 평가해 요구사항을 받아들일지 말지 결정할 수 있습니다. 어느 쪽으로 결정되더라도 초기 요구사항에 근거를 둔 의미 있는 결정일 겁니다.

반면 문제를 일으킬 가능성이 높은 고위 의사결정자의 요구사항은 훨씬 포괄적이고 게임의 핵심을 상상하기 어려운 모양일 수 있습니다. 가령 책에 나온 존의 비전은 강력한 무기를 휘두르고 여러 시대의 배경이 나와 고객이 여러 시대의 다양한 배경을 기반으로 한 경험을 할 수 있는 게임이라는 높은 레벨의 요구사항은 그래서 플레이어가 게임 상에서 어떤 플레이어를 하는지, 고객이 이를 통해 어떤 경험을 해야 하는지를 전혀 표현하지 못하고 있습니다. 일단 이전에 이드에서 일인칭 슈터 장르를 만들어 왔으니 같은 형식의 게임을 만들기로 서로 간의 합의가 이미 되어 있는 상태라 하더라도 이런 모호한 요구사항은 중요한 의사결정을 해야 할 때 아무 도움도 되지 못합니다. 똑같이 마을에 플레이어가 자기 집을 가질 수 있고 그 안을 꾸밀 수 있으며 꾸미는데 필요한 아이템을 제작할 수 있어야 한다는 요구사항이 나타날 때 이를 받아들일지 말지 판단할 수가 없습니다. 강력한 무기를 휘두르고 여러 시대의 배경이 나오는 스케일이 큰 게임에 자기 집이 나와도 될지 요구사항에 근거해 판단하기는 불가능합니다. 이럴 때 일어나는 끔찍하고 또 전형적인 상황은 ‘어 그거 좋은 아이디어인걸? 한번 구체화 해 보자’는 식으로 핵심 의사결정이 뒤로 미뤄지는 것입니다. 이는 개발할 수도 있고 개발하지 않을 수도 있는 요구사항에 팀이 자원을 투입하게 만들어 소프트웨어의 기능 상에 아무 영향을 주지 않았으면서도 출시 시점을 뒤로 미루는 효과가 있습니다.

허리가 없는 개발팀을 자기 스스로 만들고서도 거기에 어떤 문제가 있는지 전혀 알지 못한 점 역시 그 시대에도 심각하게 실패한 프로젝트를 만들었지만 현대에도 마찬가지입니다. 허리가 없다는 의미는 팀에 고위 의사결정자와 주니어 사이에 의사소통을 담당하는 시니어들이 없는 상황을 표현한 것입니다. 팀의 허리는 고위 의사결정자가 모호한 비전을 말하거나 잘못된 의사결정을 수행하더라도 프로젝트에 이 효과로 인한 문제를 최소화하고 이런 상황에도 불구하고 개발이 지속되도록 하는 역할을 합니다. 특히 고위 의사결정자의 언어와 주니어들의 언어가 크게 달라 같은 말이 서로 간에 완전히 잘못 전달되어 엉뚱한 결과에 도달하는 상황을 극적으로 줄여 줍니다. 가령 개발에 별로 관여하지 않는 고위 의사결정자가 MMO 게임의 마을 레벨을 보고 ‘마을에 생활감이 없다’는 말을 한 상황을 가정해 봅시다. 고위 의사결정자는 아마도 캐릭터 한 명이 뛰어다니는 커다란 마을을 보고 있을 가능성이 높은데 여러 사람이 상시 드나들고 머무르게 만들 목적으로 넓은 공간을 설계했지만 그 공간을 혼자 돌아다닐 때는 완전히 느낌이 다를 겁니다. 만약 팀에 온전히 동작하는 허리가 있다면 이 상황을 잘 설명하고 주니어들에게 아무런 요구사항도 내려보내지 않음으로써 서로 다른 언어가 잘못 해석되어 이상한 일을 일으키지 않을 겁니다. 하지만 그런 사람들이 없다면 갑자기 텅 빈 마을 레벨에 생활감을 줄 방법을 찾기 시작하고 여러 플레이어들이 이 공간에 있을 상황을 생각하지 않은 채 여러 NPC가 돌아다니는 싱글플레이 마을을 만들려고 시도하며 개발비용을 낭비하고 팀을 혼란에 빠뜨릴 수 있습니다.

허리가 없는 팀은 처음부터 그렇게 시작하기 보다는 프로젝트가 지속되며 만들어집니다. 팀의 허리를 담당하는 사람들은 고위 의사결정에 관여하기에는 권한이 부족하지만 적어도 이 프로젝트가 올바르게 진행되고 있는지, 그리고 자신들이 개발에 기여하고 문제에 개입할 수 있는지를 판단할 수 있습니다. 만약 여러 가지 이유로 명백한 문제를 그들이 해결할 수 없고 이 상황이 계속되면 프로젝트가 실패하거나 자신이 신체적으로, 정신적으로 파괴될 가능성이 높다고 판단하면 허리들은 조용히 팀을 떠납니다. 이 상황이 반복되면 어느새 프로젝트에는 고위 의사결정자 소수와 다수의 주니어들만 남아 서로 완전히 다른 언어로 말하며 서로의 의도를 완전히 잘못 해석해 매번 엉뚱한 결과를 만들기를 반복하는 이상한 팀이 완성됩니다. 때문에 팀을 구성할 때 고위 의사결정자 그룹, 시니어들로 구성된 팀의 허리, 그리고 주니어들을 적당히 배치해야 너무 큰 개발비용을 사용하지 않으면서도 정상적으로 동작하는 팀을 만들 수 있습니다. 물론 허리가 없다는 사실이 바로 프로젝트 실패로 이어지지는 않습니다. 여러 프로젝트가 허리 없이 고위 의사결정자와 주니어들의 끝없는 크런치 끝에 완수된 사례가 있으며 중간에 더 이상 상황을 개선할 여지가 없다고 판단한 팀의 허리들이 대규모로 이탈한 상황에서 회사에서 돈을 받으며 마치 게임을 처음 개발해 보는 사람들처럼 지독한 시행착오를 거친 끝에 의미 있는 결과를 만들어낸 사례도 있습니다. 하지만 굳이 그럴 필요는 없지 않았을까 싶습니다.

그런데 존은 처음 팀을 구성할 때부터 구성원의 경험이나 실력 보다는 열정에 근거해 충원했습니다. 이들은 열심히 하려고 할지도 모르지만 개발은 단지 열심히 한다고 진행되지 않습니다. 업무 방법을 알아야 하고 요구사항을 결과로 만드는 과정을 파악하고 있어야 하며 고위 의사결정자의 언어로 설명된 요구사항과 실제 빌드의 상태가 서로 어떤 모양이어야 하는지를 파악할 수도 있어야 합니다. 또 이전 개발 경험을 통해 해도 되는 것과 해서는 안되는 일을 구분해 팀에서 후자의 상황이 일어나지 않도록 하는 역할도 해야 합니다. 그런데 존은 이런 역할의 존재와 필요를 무시했거나 필요를 느끼지 못한 것 같습니다. 존은 자기 스스로 소수의 고위 의사결정자와 이들과 같은 언어를 사용하지만 결코 같은 언어로 말하지 않는 다수의 주니어들로 구성된 허리가 없는 조직을 만들었습니다. 게다가 당시 기준으로는 거대한 100명이 넘는 팀을 운영하고 있었는데 이후 처음 세 자리 수가 넘는 인원으로 구성된 개발팀을 운영하면서 이전에는 그리 복잡하지 않았던 일이 그저 사람 수가 늘어났다는 이유 만으로 훨씬 복잡해지는 상황을 겪었습니다. 이런 마당에 그 시대에 경험이 없는 주니어들로 구성된 세 자리 수 인원으로 구성된 팀을 오직 고위 의사결정자 그룹 만으로 운영해 프로젝트를 성공적으로 수행한다는 것은 그냥 불가능합니다. 존이 아무리 능력이 뛰어나도 혼자서는 도저히 달성할 수 없는 상태를 스스로 만들었습니다.

게임 소프트웨어는 결국 소프트웨어입니다. 비디오 게임 개발은 소프트웨어 개발과 별로 다르지 않습니다. 다만 도메인이 다르고 요구사항의 성격이 다를 뿐입니다. 비디오 게임 소프트웨어는 결국 기술 조직의 손에서 완성됩니다. 존은 이드에서 그 사실을 강한 체험을 통해 이미 알고 있었지만 기술적인 제한과 한계에 의해 게임디자인을 변경해야 한다는 소프트웨어를 개발하는 관점에서는 당연한 행동에 불만을 가졌던 것 같고 자신이 권한을 행사할 수 있는 개발팀을 만들면 이런 행동을 할 필요가 없으리라 생각한 것 같습니다. 하지만 게임 소프트웨어 역시 근본적으로 소프트웨어이기에 충분한 기술 조직을 갖추지 않으면 게임을 기획할 수는 있겠지만 소프트웨어를 개발하고 이를 발매할 수는 없습니다. 그래서 기술 조직의 의견을 귀 기울여 듣고 수용할 수 있는 요구사항을 수용하되 앞서 설명한 가장 중요한 요구사항을 망가뜨리지 않는 범위 안에서 타협을 통해 실현 가능한 요구사항을 도출해 내며 개발해야 합니다. 하지만 존은 그 스스로 허리가 없는 팀을 구성하며 스스로 개발에 필요한 핵심 기술을 보유하지 못한 팀을 만들고 말았습니다. 이드와 계약을 맺고 퀘이크 엔진 기반으로 개발했지만 대대로 퀘이크 엔진은 엔진으로써 동작할 뿐 원활한 개발환경을 제공하지 않는 것으로 악명 높았습니다. 그렇다면 존이 이전에 이드에서 했던 것처럼 그 스스로 저작도구를 개발하거나 적어도 저작도구를 개발하는 조직을 운영했어야만 합니다. 하지만 존은 그 어느 쪽도 하지 않았고 그 스스로 저작도구를 개발하는 선택 역시 이미 이 시점에 게임 프로젝트는 그가 처음 울펜슈타인 3D의 레벨 저작도구를 만들 때와 비교해 너무나 복잡해졌습니다.

또한 엔진을 확정하지 않고 퀘이크 엔진으로 개발하다가 이드가 퀘이크 2를 발표한 다음 퀘이크 2 엔진을 받아 지금까지 개발하던 게임을 새 엔진으로 이식하겠다는 개발 계획 역시 어처구니가 없습니다. 현대에 처음부터 이런 행동을 가능하게 만들 목적으로 개발했다고 주장하는 언리얼 엔진조차 마이너 버전 업데이트 때마다 프로젝트에 온갖 문제를 일으킵니다. 그런데 애초에 이런 목적으로 개발되지도 않은, 오직 퀘이크 2를 구동하는데 집중해 개발한 엔진을 받아 출시까지 얼마 안 남은 시점에 기존 퀘이크 기반으로 개발하던 프로젝트를 이식하려는 시도는 그가 게임을 처음 만들기 시작하던 시대와 그 시점 사이에 게임 개발의 복잡성이 극도로 증가했다는 사실을 전혀 인지하지 못하고 있다는 것을 보여줍니다. 개인적으로는 오래 전 언리얼 엔진에 기반해 개발하던 MMO 프로젝트를 중간에 이름 모를 엉뚱한 게임 엔진으로 바꾸는 의사결정을 한 사례를 알고 있는데 - 사실은 엔진 교체 의사결정 직전까지 그 프로젝트에서 일했음 - 이런 의사결정이 성공한 사례는 적어도 제가 아는 범위 안에서는 없습니다. 서로 다른 엔진은 서로 완전히 다른 개발 방식을 요구하며 개발 도중 이런 변화를 감당하려면 커다란 비용과 무시무시한 시행착오가 필요할 겁니다. 최근 ㅁ게임의 엔진변경 사례가 진행되고 있다고 알고 있는데 그나마 이는 현대적인 언리얼 엔진을 타겟으로 하고 있어 그나마 가능할 수 있는 이야기이며 존이 퀘이크 엔진과 퀘이크 2 엔진을 접하고 또 팀 스위니가 에픽을 창업해 간신히 첫 번째 언리얼을 만들고 그 다음 언리얼 토너먼트를 만들던 시대 기준으로는 기술적으로 거의 불가능한 목표입니다.

존이 실패할 수밖에 없었던 이유는 크게 세 가지로 요약할 수 있습니다. 첫째. 스스로 고위 의사결정자임에도 불구하고 의미 있는 요구사항을 제시하지 못했습니다. 이는 높은 확률로 이 시점의 존이 그 시대 기준의 현대적인 게임디자인을 수행할 능력이 없다는 증거로 해석할 수 있습니다. 둘째. 자기 스스로 허리가 없는 팀을 만들었습니다. 허리가 없는 팀은 고위 의사결정자와 주니어 개발자가 서로 같은 영어로 말하지만 서로 완전히 다른 언어로 말하며 서로 올바른 의도를 전달하기 거의 불가능합니다. 만약 이 상황을 감당할 수 있는 개발자가 있다면 이 사람을 허리라고 정의하며 조만간 이 사람은 팀을 이탈할 겁니다. 셋째. 회사가 핵심 기술을 보유하지 않았으며 핵심 기술 전체를 외부에 의존하면서도 그 복잡도와 위험성을 과소평가했습니다. 퀘이크 엔진을 생각하고 이식에 별다른 어려움이 없을 거라고, 고작 몇 주 만에 이식을 완료할 수 있을 거라고 투자자들에게 말하는 모습은 이 시점의 존이 게임디자인을 해 낼 역량이 없을 뿐 아니라 기술적인 판단조차 할 역량이 없는 상태라는 점을 말해줍니다. 존이 퀘이크 2 코드를 받아 열어보고 예상한 것과 완전히 달라 얼어붙는 장면에서 저는 얼어붙은 존에게 이입하기 보다는 독자 관점에서 통쾌함을 느꼈는데 그 정도 역량으로 그 시대에 그런 거대한 팀으로 개발하며 개발이 성공하면 그게 더 이상하다고 생각했기 때문입니다.

결국 존은 이름을 말하고 싶지도 않은 바보 같은 실행 가능한 코드 뭉치를 판매하는데 도달했지만 이전에 둠과 퀘이크 시리즈가 산업에 큰 흔적을 남긴 것에 비해 이 게임은 거의 아무런 흔적도 남기지 못한 채 투자사에 거대한 손실을 남기고 끝납니다. 존은 초창기에 울펜슈타인 수준의 복잡도에서 스스로 레벨 저작도구를 개발하고 이를 바탕으로 의미 있는 레벨디자인을 했으며 헤러틱에서도 역량을 발휘할 수 있었습니다. 하지만 둠, 퀘이크를 지나며 고작 몇 년 사이에 게임 기술, 산업, 게임 자체의 복잡도가 극적으로 증가하는 상황을 ‘대외 활동’에 집중한 나머지 전혀 인지하지 못했고 실패할 수밖에 없는 온갖 의사결정을 남발한 끝에 누구라도 반론을 재기할 수 없을 정도로 실패한 다음 사라집니다. 존은 실패할 수밖에 없었습니다.