여섯 번째 마일스톤은 왜 실패했을까

비록 지난 여름의 첫 번째 비공개 테스트에 이은 두 번째 테스트를 준비하던 여섯 번째 마일스톤은 권고사직, 아무도 돕지 않고 돌아서다에 소개한 대로 저 자신은 해고되어 더 이상 참여할 수 없게 되었습니다. 프로젝트가 중단된 것은 아니고 법인 계좌에 남은 돈으로 버티며 투자를 성사 시키기 위한 선택으로 오직 런웨이를 유지하는데 집중하기 위해 사람들을 한 줄로 세워 놓고 돈을 더 받는 사람부터 차례로 해고해 전체의 절반이 조금 넘는 사람들이 계속해서 마일스톤에 기여하게 됩니다. 사실 이런 식으로 사람들을 제거하면 앞으로 새 마일스톤 시작 및 진행이 쉽지 않으리라는 현실을 쉽게 짐작할 수 있는데 사실 새 마일스톤 시작을 목표로 삼기조차 쉽지 않은 상황입니다. 때문에 이번 감원을 통한 목표는 진행 중이던 여섯 번째 마일스톤을 마무리 할 수 있는 물리적인 최소 인원을 남기는 선에서 진행했다고 봐야 합니다.

지난 권고사직을 발표하던 날은 마일스톤 마감 날짜가 지난 다음 다음 근무일이었습니다. 12월에 서둘러 인원을 해고하기로 결정한 이유는 내년으로 넘어갈 경우 내년도 휴가가 발생하기 때문에 해고 비용이 증가하기 때문이었고 저 날 권고사직 발표를 한 이유는 이제 마감 날짜가 지나 어쨌든 빌드의 핵심 기능이 개발되었을 거라고 예상하고 남은 작업은 주니어들의 피똥을 댓가로 어떻게든 마무리할 수 있으리라는 생각 때문이었을 겁니다. 사실 경영 입장에서 어느 정도 근거 있고 또 비용을 최소화한 해고 전략이라고 볼 수 있는데 이론 상 가능할 것 같기는 하지만 실상은 마감 날짜에도 아직 핵심 기능이 온전히 통합되어 구동 되지 않는 상태였고 또 미래를 대비해 준비한 보상 시스템 디자인 (2023년 겨울 버전)은 현 시점에 필요 이상으로 복잡해 이들을 모두 추스리기는 결코 쉽지 않을 겁니다. 어쨌든 권고사직을 발표한 당일 오후에 면담을 마치고 억까짓을 할까 말까 한참 고민하다가 그냥 빨리 다음 직장을 구하는 편이 개인에게 이익이겠다는 생각이 들어 나가라는 서류에 사인하고는 빌드와 정을 떼기 위해 진행하던 작업을 모두 중단해 버렸습니다.

기획은 크게 전투 담당, 시스템 담당, 레벨디자인 담당이 있었는데 이들 중 맨 마지막을 제외한 나머지 전체가 사라져 버려 난데없이 개발된 빌드 조립을 1년차 한 분과 나름 짧지 않은 경험을 가진 한 분이 전부 다 담당해야 하게 됐는데 적절한 시간과 요구사항이 비용을 고려하지 않고 함부로 변경되는 경영진의 게임디자인 관여만 아니면 개발을 마무리 해 두 번째 비공개 테스트를 수행하기에 불가능하지 않아 보입니다. 하지만 지금까지 결과를 놓고 생각해 보면 우리들은 마일스톤 기간 안에 기능 개발을 마무리 하지 못했고 기획에서 기능을 조립할 시간을 벌지 못했으며 왜 새 PvE게임모드 개발은 실패할 수밖에 없었나에 설명한 대로 마일스톤 마감까지 아직 의미가 있을지 알 수 없는 새 게임모드를 단 한번도 끝까지 플레이 해본 적이 없는 상태입니다.

일단 물리적으로 처음 계획했던 두 번째 테스트 일정을 맞추기는 불가능하기 때문에 새로운 일정과 계획을 수립해 무사히 두 번째 테스트를 마치고 이 사실과 빌드를 기반으로 투자를 받는다면 그 금액이 전통의 비디오 게임 업계 기준에서 터무니 없이 적다 하더라도 남겨진 인원을 고려할 때 다음을 도모할 만한 런웨이를 확보할 수는 있을 겁니다. 하지만 제 개인적인 관점에서 이런 상황은 미래에는 어떻게 될 지 몰라도 여섯 번째 마일스톤 만을 놓고 평가하면 실패했다고 보는데 일단 목표로 삼은 기간까지 개발을 완료하지 못했으며 그 시점까지 위험성이 높은 기능의 일부라도 통합해 테스트 하지도 못했고 결과적으로 서비스 일정을 맞추지 못했기 때문입니다. 오늘은 이전 마일스톤 기간과 이번 마일스톤을 계획하던 시점으로 돌아가 여섯 번째 마일스톤이 왜 실패할 수밖에 없었는지, 이를 피하려면 어떻게 해야 했을 지를 생각해 보겠습니다.

자. 그러면 과거로 돌아가 어떻게 여섯 번째 마일스톤 계획이 수립되었는지 그 즈음에 일어났던 일과 주변 상황을 생각해 봐야 합니다. 프로젝트 개발을 시작한 우리들은 처음 세 마일스톤 기간이 지나는 동안 방향을 설정하고 이 업계의 전통에 따라 캐릭터 NFT 세일을 준비하며 이들을 뒷받침할 기술적 배경을 결정하는데 시간을 보냈습니다. 사실 이 단계를 좀 더 빨리 결정할 수 있었지만 여러 가지 정치적인 문제, 사람들마다 생각이 너무 달랐지만 이들이 평소에는 잘 노출되지 않았던 문제, 지금은 러그풀로 끝난 다른 프로젝트를 리퍼런스 삼아 이들의 방식을 어느 정도 복제하려다가 암만 생각해도 뭔가 이상해 머뭇거리기를 반복하던 문제 등이 계속해서 일어나며 처음 세 마일스톤 동안 제대로 된 빌드, 제대로 된 아트 스타일, 제대로 된 미래 계획을 수립하는데 애를 먹었고 이 상태로 몇 달을 보냅니다. 이때도 별로 넉넉한 생활을 하지는 못해 완전 관리되는 유명한 공유 오피스에 입주해 있으면서 열악한 환경과 주변 오피스의 소음에 그대로 노출되는 작업 환경, 오피스 이외에는 아무런 공간이 없어 물건을 쌓아둘 공간조차 없어 어수선한 업무 공간 속에서 초기에 겪은 문제들을 해결해 나갔습니다.

먼저 당시에는 웹에서 동작하는 제품, 이에 기반해 동작하는 아바타 NFT를 판매하는 제품들이 많았는데 사실 이들의 품질은 형편 없었습니다. 전통의 비디오 게임 업계에서 온 우리들 입장에서 이들은 마인크래프트의 스티브와 별로 다르지 않았고 이들로 데모 정도를 만들 수는 있겠지만 몇 년 뒤에도 통할 의미 있는 제품이 기반으로 삼기에는 품질이 너무 낮고 발전 가능성도 너무 부족하다고 판단합니다. 하지만 우리들의 눈높이에 맞는 외형을 만들기 위해서는 웹 기반에서는 방법을 찾기 어려웠는데 초기 우리들의 스폰서가 브라우저 껍데기에서 돌아가는 리모트 VM에서 동작하는 높은 품질의 프로젝트를 들고와서 이런 것도 있다며 무슨 불이라도 발견한 마냥 난리를 쳐 댔고 우리들 중 누군가가 이건 테크데모 이상으로 동작할 수 없음을 설명해 그 사람을 진정 시키는데 상당한 시간을 사용해야만 했습니다. 결국 전통의 비디오 게임 업계에서 거의 표준에 가깝게 사용하는 언리얼 엔진을 미들웨어로 사용하기로 결정하고 웹 기반의 동작을 포기하는 의사결정을 하는데 상당한 시간을 사용해야만 했고 이 의사결정을 한 다음에는 이전까지 유니티로 개발할 작정이었기 때문에 모인 사람들 상당수가 언리얼 개발 경험이 전혀 없다는 사실을 깨닫고 잠시 당황했습니다. 하지만 이 결정을 통해 어쨌든 기술적 기반, 아트 스타일, 개발 계획을 어느 정도 수립할 수 있었고 이제 뭐라도 만들어 볼 수 있는 상태가 됐습니다.

이 다음은 난데없이 커스터마이징을 개발하는 일이 나타났습니다. 프로젝트를 시작하자마자 캐릭터 커스터마이징을 개발하자는 의사결정은 사실 이전부터 여러 차례에 걸쳐 겪어 왔는데 여기에는 프로젝트 후반에 가서 커스터마이징을 개발하려면 기존 에셋을 크게 고쳐야 하기 때문에 미리 커스터마이징을 개발해 여기 맞춰 에셋을 개발하면 나중에 가서 손이 덜 간다는 논리가 있었습니다. 또 크립토 게임 업계에서는 아직 제품이 없는 시점에 캐릭터 NFT를 판매하는 무슨 전통 비슷한 전통이 있었기 때문에 이를 위해 초반에 커스터마이징 기능이 필요합니다. 보통 이 시점에 소위 전투라고 퉁 쳐서 부르는 코어 메커닉을 당장 만들기 시작하기는 어렵고 그 담당자들은 이를 어떻게 만들어야 할 지 여러 게임을 살펴보며 연구하고 있을 시점이라 아직 아무 것도 없는 상태에서 커스터마이징 기능을 만들기 시작했는데 이전에 MMO 게임 만들 때도 비슷한 요구를 받은 적이 있어 당황하지는 않았습니다. 하지만 항상 이 결정은 이상하다고 생각했는데 커스터마이징 기능을 총 세 번 개발해 보면서 세 번 모두 아트 요구사항이 없었습니다. 그도 그럴 것이 아직 바닐라 상태인 언리얼 엔진만 덜렁 가지고 있는 상태에서 제대로 된 설정도 없고 제대로 된 원화 한 장 없는 상태에서 갑자기 NFT를 팔아재낄 캐릭터 생성 시스템, 그리고 생성된 상태가 인게임에 걸어다닐 수 있는 체계를 만들어야 하는 마당에 아트에서 무슨 커스터마이징에 대한 요구사항을 가지고 있기는 어렵습니다.

그렇다고 이 시점에 게임디자인이나 시스템디자인이라고 해서 커스터마이징에 대한 요구사항을 가지고 있지도 않았는데 이 상태에서 매력적인 캐릭터 NFT를 만들어낼 수 있는 커스터마이징 시스템을 요구 받았고 당시 갑자기 공개된 에픽 메타휴먼을 살펴보며 그래도 이 정도는 만들어야 하지 않느냐는 이야기를 들으며 ㅈ됐다는 생각이 들었습니다. 사람들은 처음에 욕심에 가득 차 에픽에서 공개한 테크데모에 나오는 기능 대부분을 소화해야 한다고 생각했고 기획에도 이를 계속해서 푸시 했지만 그냥 그건 불가능했습니다. 또 테크데모에서 가능하다고 해서 그걸 인게임에 그대로 가져와 사용하는 것 만큼 멍청한 짓도 없었기도 하고요. 오직 시각적인 측면에만 집중해 리모트 VM에서 동작하는 테크데모의 웹 버전을 가져온 사람들은 여전히 우리가 에픽 테크데모를 탐탁찮게 생각하는 이유를 이해할 수 없어 했지만 우리는 제품을 끝까지 책임 져야 했습니다. 그저 시각적으로 그럴듯해 보이는 데모를 띡 던져 놓고 아님 말고 식으로 접근하는 사람들을 설득하기보다는 이제 그들을 무시하기 시작합니다. 하지만 이전 두 번에 걸쳐 게임이 아직 있지도 않은 상태에서 커스터마이징부터 만드는 이상한 일을 겪어 보니 대강 해쳐 나갈 수 있겠다는 생각이 들었습니다. 결국 캐릭터 NFT와 인게임 캐릭터를 일치 시키는 거의 최초의 제품을 만들 목표로 커스터마이징을 설계했고 이는 메타휴먼에서 얼굴을 구성한 다양한 본과 머테리얼을 수정해 그럴듯한 외형을 만드는데 집중하는 대신 다양한 웨어러블에 따라 캐릭터 사이에 차이가 드러나게 만드는데 집중하기 시작했습니다.

한편 그렇게 서서히 인게임에 처음으로 커스터마이징 된 캐릭터가 기본 애니메이션 시스템에 의해 걸어 다니기 시작하고 이에 맞춰 이들이 총을 쏘고 몬스터와 싸우는 전투 시스템을 개발하기 시작합니다. 이미 커스터마이징은 웨어러블 탈착에 기반해 어느 정도 동작했고 여기에 설정에 기반한 다른 게임과 차별점으로 사람의 피부를 포함한 신체 외형에 해당하는 부분을 템플릿처럼 한 번에 교체할 수 있게 만들어 굉장히 도전적인 외형을 가진 캐릭터를 만들 수 있게 했는데 처음에는 우리들 스스로도 약간 거부감을 느낄 때도 있었지만 장차 다양한 외부 에셋이 게임에 들어올 때 이들과 쉽게 어우러지게 만들려는 목표를 생각하면 그리 이상한 것도 아니라고 우리들 스스로도 납득하게 됩니다.

이들이 인게임의 평평한 테스트 레벨 위를 뛰어 다니며 어떤 폐업하는 회사로부터 구입해 온 게임 에셋에서 꺼낸 몬스터와 총을 쏘며 싸우게 만드는데는 그리 오랜 시간이 걸리지 않았는데 이 정도 요구사항 까지는 바닐라 언리얼 엔진으로 그리 어렵지 않게 대응할 수 있었습니다. 게임 바깥에 NFT 모양으로 보이는 캐릭터가 거의 그대로 인게임에 나타나 총을 쏘고 몬스터와 전투하는 상태가 되자 이 상태만으로도 지금까지 러그풀을 일삼던 업계의 다른 플레이에들과 비교해 상당히 앞서 있었다고 판단해 크립토 게임 업계의 전통에 따라 당장 돈이 필요한 상황은 아니었지만 NFT 세일을 하고 세일 일정에 맞춰 비공개 테스트를 실시하기로 결정합니다.

하지만 인하우스에서 캐릭터를 만들고 이들이 몬스터를 향해 총을 쏘며 플레이 하는 것과 이 상태를 아무리 적은 인원을 대상으로 하더라도 서비스 수준으로 만드는 것 사이에는 큰 차이가 있었습니다. 그래서 네 번째 마일스톤 까지 기초 전투를 만들고 또 NFT 시장에서 널리 알려진 아티스트의 몬스터를 가져와 보스로 출연 시킨 PvE 모드를 만들어 구색을 갖추고 또 게임에 덜렁 이 모드 하나만 넣긴 좀 그러니 설정에 따라 이 모드에 진입할 일종의 광장 레벨을 만들었습니다. 그럴싸한 게임 메인 메뉴를 만들고 NFT를 보유하지 않은 사람들이 초대 코드를 통해 접근할 때 인게임 캐릭터를 만들어볼 수 있도록 인터페이스를 준비하고 광장에 들어와 아무 것도 할 일이 없을 때를 대비해 광장에 장난감을 준비하기도 합니다. 게임 외적으로는 NFT를 판매해야 했으므로 수많은 웨어러블 에셋을 제작해야 했고 이들이 조합되어 다양한 캐릭터가 만들어질 때 웨어러블이 서로 간섭해 문제를 일으키는 경우를 찾아 이들을 해결하는데도 집중합니다. 어지간한 온라인 게임에서 밖으로 튀어나온 장식이 많은 상의와 이를 덮는 긴 머리카락이나 마스크 같은 웨어러블은 애니메이션에 따라 서로 충돌해 씹히는 모습을 보이기도 하는데 전통의 게임이라면 이를 대강 넘어갈 수도 있었지만 우리는 이런 상태라도 NFT로 팔아야 했으므로 시각적으로 완벽해야 했고 이런 문제를 케이스 별로 해결해야 했습니다.

이렇게 좌충우돌하며 어떻게 다섯 번째 마일스톤을 진행해 투자자들에게 보여줄 만한 빌드를 만들어냈고 이를 통해 어느 정도 시장의 관심을 이끌어냅니다. 그저 화려하게 만든 웹사이트와 화려한 에셋으로 가득한 피칭 프리젠테이션 뿐 아니라 우리는 여기에 빌드를 직접 보여줄 수 있었습니다. 아직 NFT 세일 전이어서 투자자들이 게임에 진입해 직접 웨어러블을 선택하게 만드는 것은 좋지 않다고 판단해 커스터마이징 기능을 숨기고 미리 만든 여러 캐릭터 중 하나를 선택하도록 아웃게임 인터페이스를 조정하고 PvE 모드 외에 PvP 모드 하나를 추가해 캐릭터 선택, 광장 레벨, PvP 모드 하나, PvE 모드 하나를 플레이 할 수 있는 모드를 포함한 빌드를 투자자들이 원하는 아무 시간대에나 기획팀이 머릿수를 채워 함께 플레이 했는데 투자자의 위치에 따라 이 시간은 한국 시간으로 한밤중이거나 새벽이기도 했습니다. 물론 투자자들은 관심을 보일 뿐 선뜻 나서지는 않았고 이어서 우리들은 NFT 세일과 홀더 테스트를 진행하기 위한 다음 마일스톤 계획을 수립합니다.

지난 투자자들에게 시연하기 위한 마일스톤이 다섯 번째 마일스톤이었는데 여기서 잠시 숨겼던 커스터마이징을 도로 꺼내 여러 웨어러블을 탈착해볼 수 있게 하고 캐릭터 NFT가 연동될 경우 처리를 아웃게임에 추가하며 이와 함께 인게임이 멀쩡하게 동작하도록 만드는데는 분명 비용이 필요했지만 이전의 다른 마일스톤만큼 큰 비용이 필요하지는 않을 것 같아 보였습니다. 그래서 마일스톤 번호를 이전의 5에 1을 더하는 대신 0.5만 더해 5.5로 만들어 이전에 비해 짧은 기간 안에 작은 서비스를 감당할 수 있는 수준으로 만들어 비공개 테스트를 수행하기로 결정합니다. 하지만 항상 그렇듯 인하우스 수준에서 그럭저럭 동작하는 빌드와 달리 불특정 다수에 대한 서비스로 수준을 올리려고 보면 그 동안은 아무렇지도 않게 넘어갔던 작은 문제들이 전부 다 튀어나오고 이들을 수정함에 따라 다른 구성요소가 영향을 받으며 예상보다 더 많은 비용이 들기 마련입니다. 또 새로 추가된 웨어러블 에셋이 기존 커스터마이징 시스템을 고려하지 않고 만들어져 이를 처리하기 위한 규칙을 만들어야 했는데 가령 장화와 긴바지를 입으면 장화가 위로 올라와야 할 지, 아니면 바지가 위로 올라와야 할 지를 자동으로 결정해 이에 맞는 에셋을 표시하도록 만드는 일이 생기기도 했습니다. 그렇게 5.5번째 마일스톤 개발을 마치고 테스트를 수행한 다음 여섯 번째 마일스톤 계획을 수립해야 하는 시점이 됐습니다.

여섯 번째 마일스톤에 대한 경영진의 의견은 이전에 우리가 NFT를 포함한 게임을 만들어낼 수 있음을 증명했으니 이어서 순환구조를 포함한 게임 플레이를 만들어야 한다는 것이었습니다. The 순환구조. 고객이 게임을 계속해서 플레이 할 이유를 만드는 한 가지 방법으로 플레이를 통해 인게임 자원을 만들어 더 강해지고 이에 따라 게임은 점점 더 다양한 컨텐츠를 고객에게 제시해 가며 고객이 게임을 반복해서 플레이 할 이유를 만드는 것을 말합니다. 이전 빌드에서 몬스터는 그저 총에 맞아 죽을 뿐이었지만 이제 아이템을 드랍해야 했고 아이템은 어딘가 쓸모가 있어야 했으며 무기에는 공격력이 필요했고 공격력이 서로 다른 무기를 게임 어디선가 구할 수 있어야 했으며 이런 반복 플레이에 어울리는 또 다른 게임모드나 이를 뒷받침할 환경이 필요했습니다. 여기에 몬스터로부터 획득한 아이템을 게임 내 다른 재화나 자원으로 바꾸기 위한 상점, 제작, 그리고 고객이 인게임에서 획득한 아이템을 보유하기 위한 인벤토리 같은 기본적인 시스템 역시 필요합니다. 이들을 대략 정리하면 전투에서는 반복 플레이를 만들어내기 위한 새로운 PvE 게임모드를 개발하기로 했고 비전투에서는 아이템 개념, 인벤토리, 아이템 드랍, 채집, 제작, 상점, 인게임 커스터마이징을 개발하기로 했습니다.

하지만 이미 이 계획을 수립할 때 이 정도 분량은 팀 크기를 고려할 때 달성할 수 없으리라는 의견이 지배적이었습니다. 하지만 적어도 경영진 수준에서는 적어도 이 정도 까지는 만들어야 다음 번 투자자들에게 면이 설 거라는 이야기를 반복했고 이는 우리들이 잘 모르는 분야여서 더 이상 설득하기 어려웠습니다. 이 계획을 프로젝트 전체에 발표할 때 엔지니어들이 제게 찾아와 이걸 전부 12월까지 하는 거냐고 물었을 때 당당하게 그렇다고 대답할 수가 없었습니다. 계획 자체가 틀렸다고 말하기는 어려웠지만 계획을 우리들이 수행해낼 수 있는지는 다른 문제입니다. 이 주제로 여러 번 문제를 제기했지만 그 때마다 투자가 진행되면 비용에 여유가 생겨 충원할 수 있을 테니 그렇게 까지 불가능한 상황은 아닐 거라는 설명을 들었습니다.

하지만 대충 생각해도 신규 인력이 순식간에 한 사람 몫을 수행할 가능성은 없었고 만약 그들을 지금 당장 충원해 내일 아침부터 책상에 앉혀 놓고 교육한다 하더라도 이번 마일스톤에 도움이 될지 안될 지 알기 어려운 상황이었습니다. 그럼에도 여전히 마일스톤 계획을 초반에 조절하기는 거의 불가능했습니다. 결국 기존 구현을 많이 바꿔야 하는 큼직한 것들부터 요구사항을 전달해 이전에 하던 대로 개발을 시작합니다. 이 시점에 경영진을 제외한 우리 모두는 현재 인력으로 이 요구사항을 마일스톤 마감 전까지 개발해 낼 수 없으리라는 사실을 미리 알고 있었습니다.

개발은 크게 새로운 반복 가능한 PvE 모드, 그리고 이를 포함한 순환구조, 그리고 인게임에 아이템 개념이 생김에 따라 이전에는 아웃게임에 있던 웨어러블 탈착 기능을 인게임으로 가져오는 플로우 변경의 세 가지 부분으로 구분해 진행합니다. 전투를 포함한 요구사항이 항상 그렇듯 PvE는 전투 담당자들이 성당에 들고 들어가 개발을 시작했고 성당에 들어가지 않는 사람들은 그 진행을 파악하기는 쉽지 않았습니다. 그저 같은 오피스 안에서 담당자들이 서로 이야기하는 것을 주워 듣고 이들의 상황, 해결해야 하는 문제 등을 어렴풋이 파악하는 수밖에 없었습니다.

한편 아웃게임에 있던 웨어러블 탈착을 인게임으로 들고 들어가기 위해서는 인게임에 아이템과 인벤토리 개념이 필요했는데 블록체인에 연동된 지갑을 통해 로그인 하면 그 안에 있는 캐릭터 NFT를 인식해 캐릭터 목록에 표시해 주는 로그인 특성 상 캐릭터마다 독립된 인벤토리 개념을 만들기는 쉽지 않았고 또 그럴 필요가 클 것 같지도 않았습니다. 그래서 지갑 하나에 대응하는 계정 공용 인벤토리 하나가 있다는 개념으로 시작해 아이템을 만들고 지난 마일스톤에서는 아웃게임 메뉴를 통해 자유롭게 탈착할 수 있었던 웨어러블을 이제는 몬스터를 사냥해 얻은 아이템을 팔아 인게임 재화를 만들어 상점에서 구입한 다음에야 장착할 수 있는 모양으로 바꿨고 이 과정에는 보상 시스템, 인벤토리, 새 웨어러블 탈착 인터페이스, 제작, 상점 같은 비슷하지만 조금씩 다른 자잘한 기능을 제각기 만들어야 했습니다.

성당 안에서 진행되는 PvE 모드 개발은 몰라도 그 이외의 기능 각각은 그 갸념이 미래에 큰 역할을 할 거라는 사실에 비해 그리 대단하지는 않았습니다. 사실 몬스터의 아이템 드랍, 채집은 형태가 다를 뿐 같은 보상 시스템을 서로 다른 시점에 서로 다른 대상이 불러오는 차이가 있을 뿐이었고 상점, 제작은 재료와 결과가 서로 다를 뿐 똑같은 시스템입니다. 가령 몬스터가 죽을 때도 보상 시스템을 부르고 채집을 할 때도 같은 보상 시스템을 부르도록 만들었습니다. 상점은 재료가 항상 인게임 재화로 고정된 채 결과 아이템이 달라지는 제작이었고 제작은 재료가 서로 다르지만 결과는 제작과 동일한 형태의 제작이라고 할 수 있었으며 이들 각각도 보상 시스템을 부르도록 만들어 인터페이스는 다들 조금씩 다르지만 내부 구조, 게임디자인에서 입력할 데이터 모양은 모두 똑같은 모양이 되도록 만들어 비용을 줄이도록 설계합니다.

하지만 인터페이스와 데이터구조가 대부분은 인벤토리, 제작, 상점, 아이템 드랍 같은 기능에 비해 레벨 상의 실제 대상에 상호작용을 해야 하는 전투에 의한 보상, 그리고 채집은 개발이 더뎠는데 이 부분을 개발할 인력이 모두 성당 안에 들어가 PvE 개발에 집중하고 있었기 때문입니다. 이런 형태는 큰 팀에서 한 가지 기능의 서로 다른 부분을 담당하는 여러 스탭에 의해 잘 제어된 일정에 따라 개발될 때 시너지를 일으키지만 작은 팀에서는 이렇게 개발하면 각 부분을 전담하는 스탭이 다른 작업에 할당될 경우 개발 일정이 쉽게 지연될 수 있습니다. 가령 채집의 상호작용 부분은 관련 담당자에 의해 빠른 시점에 개발되었지만 이 기능이 실제 인벤토리와 보상 시스템에 연결되기 까지는 상당히 오래 기다려야 해서 결국 마일스톤 마감 직후 권고사직이 일어나기 전에 조립을 마쳐 실제 동작하게 만들 수가 없었습니다. 상호작용 개발과 나머지 기능에 연결 사이에는 4주 이상의 대기 기간이 있었는데 이 일에 관련된 모든 사람들은 이 사이에 서로 다른 일을 하고 있었을 뿐 아무도 이 기능이 늦게 개발되기를 원하지는 않았다고 생각합니다. 하지만 우리들처럼 작은 팀에서는 큰 팀처럼 각자가 전문 분야를 담당해 여러 기능에 걸쳐 같은 부분을 개발하기 보다는 각자가 한 가지 기능을 처음부터 끝까지 개발하는 형태가 더 시간을 단축할 수 있는데 사실 이를 제어할 사람이 없어 그냥 익숙한 대로 개발했기 때문이라고 보는 편이 적절할 겁니다.

마감이 가까워지자 여러 세부 기능이 개발 중이라는 사실을 알고 있었지만 그때까지 단 한 번도 처음부터 끝까지 통합되어 플레이 해 본 적이 없는 신규 PvE 모드에 관심을 안 가질 수가 없었습니다. 언리얼 엔진이 기본적으로 슈터 장르에 필요한 여러 기능과 개념을 제공하는 것은 분명하지만 슈터 장르에 당연하게 생각되는 자잘한 기능에 관심을 가지기 시작하면 언리얼 엔진은 그야말로 기초 중의 기초에 대응할 뿐 거기서 한 발자국이라도 더 나아가려면 우리가 직접 개발하는 수밖에 없습니다. PvE 쪽에서는 이전 마일스톤에서 슈터의 기초적인 기능조차 없이 그냥 서비스를 해 버렸다는 사실을 크게 부끄러워 하고 있었고 고객들이 우리가 그런 기초적인 개념조차 모르는 팀이라고 생각해 버릴 거라고 걱정하고 있었습니다.

그래서 이번에는 지난 수 십 년에 걸쳐 쌓인 슈터 장르의 기초적인 기능들을 모두 보강해 이들을 통합한 제대로 된 슈터 PvE 모드를 개발하고자 했습니다. 때문에 중간에 어떤 기능은 정말 지금 시점에 미션 크리티컬 하지 않은 어떤 비싼 기능이 필요한지 게임디자이너 한 명을 둘러싼 다른 협업 부서 스탭 열 명 이상이 게임디자이너 자리에서 한창 언쟁을 벌이는 상황이 벌어지기도 합니다. 이 작은 사건에 대해 두 가지 감정이 있는데 하나는 이 시점에 미션 크리티컬 하지 않은 기능은 버리는 편이 옳다는 것, 그리고 다른 하나는 이 논쟁의 맨 앞에 나머지 모든 사람들과 마주 선 전투 담당자가 한 명의 시니어로 올라서기 위해서는 저 논쟁을 적절한 방향으로 마무리 지어 원하는 바를 달성해야 하는 것입니다. 결국 이 미션 크리티컬 하지 않은 기능을 개발하기로 했는데 이를 통해 전투 담당자는 분명 성장했겠지만 프로젝트 전체 관점으로 보면 마일스톤에 실패하는데 조금 더 이바지했다고 생각합니다.

여러 사건 끝에 마일스톤 마감 날짜가 지나가고 마감 일정을 통한 학대 전략을 사용해 막판에 능률을 조금 끌어올려 보기도 했지만 이쯤 되니 프로젝트 전체가 이번 마일스톤이 날짜에 맞춘 성공을 거두지 못하리라는 사실을 공공연히 알고 있었고 약간의 부족함을 보강하기 위해 최선을 다하기 보다는 어차피 실패할 계획이니 일단 실패하고 계획의 수정을 바라는 상태가 되어 능률이 충분히 오르지 않습니다. 동시에 경영진은 마일스톤 마감이 지났으니 올해를 넘기기 전에 인력을 정리해 내년 휴가가 발생해 해고 비용이 증가하는 문제를 겪지 않기 위해 빌드 상태를 고려하지 않고 마감이 지나자 마자 해고를 단행했으며 덕분에 남은 사람들이 고통스럽게 빌드를 조립해 나가고 있습니다.

장비를 반납하기 전에 살펴본 빌드는 남은 인원이 자기 담당이 아니던 부분의 조립을 떠맡아 고통스럽게 조립하고 있었는데 미래를 대비해 준비한 보상 시스템은 애초에 모든 데이터를 언리얼 데이터에셋 기반으로 하나하나 입력하려면 엄청나게 고통스러울 거라고 예상해 자동화를 통해 초기 데이터를 입력할 계획이었습니다. 그렇지 않으면 파일 하나하나를 매번 새로 만들어야 하는 굉장한 노가다를 필요로 했기 때문입니다. 일단 초기 데이터를 입력하고 나면 그 다음은 그냥 연결해서 쓰기만 하면 되는 거라 간단해지지만 그 첫 작업을 수동으로 할 계획은 전혀 없었습니다. 하지만 이 기능을 제가 조립하기 전에 인수 받은 불쌍한 주니어님은 이들을 하나하나 수동으로 입력하기 시작했고 제 계획을 설명할까 하다가 그만뒀습니다.

성당 안에서 개발하던 신규 PvE 모드는 마감일로부터 2주가 넘게 지난 시점까지도 여전히 처음부터 끝까지 단 한번도 통합된 상태로 플레이 할 수 없었으며 이제는 게임 플로우에 따라 레벨에 진입해 뭔가 동작하는 모습을 구경할 수는 있지만 동작하는 상태와 플레이 가능한 상태, 그리고 고객들에게 서비스 할 수 있는 상태 사이에는 각각의 사이에 아주 큰 차이가 있기 때문에 여전히 통합이 완료되어 조립 가능한 상태라고 보기는 어렵습니다. 몬스터 드랍, 채집, 제작, 상점 모두 비슷한 상태인데 각 기능의 조립된 상태를 꼼꼼하게 확인하는 테스트 담당자나 마일스톤 계획 단계부터 플레이 시나리오를 완전히 외우고 있는 사람이 빈 곳을 지독하게 찾아다니며 문제를 제기하거나 직접 슬쩍 해결해 나가지 않는 이상 빌드 완성도를 올리는데 예상보다 훨씬 긴 기간이 필요해 보입니다.

자. 지금까지 초안 상으로 1만2천글자가 넘도록 여섯 번째 마일스톤 이전 이야기, 여섯번째 마일스톤의 시작과 진행, 그리고 해고되기 직전의 상황을 설명했습니다. 하지만 아직도 제목의 여섯 번째 마일스톤의 실패 원인을 똑바로 이야기 하지는 않았는데 지금까지 이야기를 따라 오셨다면 원인을 대략 짐작할 수 있겠지만 제가 생각하는 마일스톤 실패 원인을 이제부터 설명하겠습니다. 먼저 마일스톤의 핵심 키워드인 순환구조는 그 방향은 적절했지만 이를 달성하기 위한 세부 목표인 사냥, 채집, 제작, 상점, 인벤토리의 전체 기능을 한번에 도입하려는 계획은 올바르지 않았습니다. 이들은 서로 비슷하기는 하지만 각각이 완전히 동일하지는 않아 사실상 각각의 개발비용을 따로 지불해야 하는 항목입니다. 만약 순환구조에만 집중했다면 모호한 채집을 제거하고 사냥에 의한 아이템 드랍만 남기고 또 서로 비슷한 기능인 제작과 상점 중 상점만 남기고 제작이 필요하지 않도록 몬스터가 아이템 대신 인게임 재화를 직접 드랍하도록 만들었어야 합니다. 그러면 당장은 우리가 원하는 모양과 약간 다르겠지만 몬스터가 직접 재화를 드랍해 상점에서 아이템을 구입한 다음 인벤토리에 보유하고 이를 반복하는 순환구조를 달성할 수 있었을 것입니다.

왜 새 PvE게임모드 개발은 실패할 수밖에 없었나에서 이번 마일스톤에 가장 큰 비용을 들인 PvE 모드가 왜 실패할 수밖에 없었는지 이미 이야기했으니 이를 반복하지는 않겠습니다. 다만 근본적으로 새 PvE 모드가 필요했는지, 만약 필요했다면 이를 한 마일스톤 기간 안에 개발하기 위한 올바른 전략을 사용했는지는 한 번 생각해볼 필요가 있습니다. 먼저 새 PvE 모드는 게임 전체가 미래에 이런 스타일의 플레이를 반복하게 만들 거라는 사실을 고객들에게 설명하기 위해 필요하긴 합니다. 여느 MMO 게임처럼 초반에 PvE 모드를 플레이 하며 성장구간을 지나 신뢰 대상을 만들지 않는데 집중한 이상한 결과에 설명한 인게임 부동산 거래 단계에 도달하게 만들어야 했습니다. 하지만 이 모드를 여섯 번째 마일스톤 기간 안에 개발하려 했다면 팀 크기에 맞게 기능을 조절하거나 한 마일스톤보다 더 긴 기간에 걸쳐 개발할 계획을 세웠어야 합니다. 팀 크기에 맞게 기능을 조절하는 방식은 이전에 왜 새 PvE게임모드 개발은 실패할 수밖에 없었나에서 설명했습니다. 일단 끝까지 돌아는 가게 만들어 놓고 기능을 추가하다가 마일스톤 마감까지 개발된 상태를 서비스 하는 것입니다. 그러면 개발 기간이 한 마일스톤을 초과하더라도 서비스 할 수 있습니다.

다른 방법은 처음부터 기능이 많은 신규 PvE 모드가 한 마일스톤 안에 개발될 수 없음을 선언하고 여섯 번째 마일스톤의 서비스 계획에서 제외하는 것입니다. 사실 이는 비용이 극도로 제한된 상황에서 고위 의사결정자가 함부로 선택하기 어려운 방법이기도 합니다. 이전에 함께 일한 적 있는 한 PD님은 ‘한 마일스톤을 초과해 개발해야 하는 기능은 무조건 망함'이라고 말씀하시며 모든 기능을 한 마일스톤에 맞는 수준으로 축소 개발해 일단 서비스하고 한 마일스톤을 초과할 만한 기능은 마일스톤 단위로 쪼개 개발해 어느 마일스톤에나 마일스톤 종료 시점에는 우리 관점에서는 만들다 만 상태이지만 고객 관점에서는 어쨌든 새로운 기능이 추가되는 방식으로 개발하게 했습니다. 이 방식은 왜 한번에 제대로 만들지 않느냐는 협업 부서들의 불만을 만들어 전통적인 기획자의 낮은 직급 문제를 일으켜 기획팀 주니어님들을 굉장히 고통스럽게 만들었지만 항상 마일스톤에 실패하지 않고 또 개발이 아무리 잘못되더라도 한 마일스톤을 초과한 단위로 실패하지 않아 실패 비용이 낮은 장점이 분명히 있었습니다. 만약 신규 PvE 모드의 전체 기능을 한 번에 공개해야만 의미가 있다면 처음부터 한 마일스톤을 초과한 기간을 사용해 개발하도록 경영진을 설득해 심지어 권고사직에 의해 핵심 게임디자인 인력이 전부 이탈한 다음에도 같은 목표를 고집하는 불상사는 미리 막아야 했다고 생각합니다.

여섯 번째 마일스톤이 실패한 이유를 정리하면 그 목표는 올바른 방향이었지만 이를 실행할 요구사항은 목표와 팀 크기에 비해 지나치게 많고 복잡했습니다. 팀 크기를 고려한 개발 방식을 선택하지도 않았고 미션 크리티컬한 요구사항을 우선 개발하지도 않았습니다. 모든 기능을 개발하려고 했고 이는 일하는 도중에는 잘못되지 않은 것처럼 보이지만 마일스톤 단위의 관점에서는 실패를 부르는 방식입니다. 또 한 마일스톤에 맞추기 어려운 요구사항은 마일스톤에 맞게 요구사항을 조절하거나 한 마일스톤을 초과하도록 설정해 서비스 계획에 반영했어야 합니다. 하지만 그러지도 않았습니다. 결국 지금은 마일스톤을 시작할 때 계획한 모든 기능을 미션 크리티컬 여부에 관계 없이 전부 개발하고 이를 전부 조립해 고객을 대상으로 하는 수준에 맞춰 개발을 마무리 해야 하는 상황에 처했고 이를 남은 인력 만으로 해결해야 합니다.

설명이 너무 길었는데 회사에서 해고 당하기 전 마지막 여섯 번째 마일스톤은 이런 여러 이유로 실패했습니다. 아쉬운 점은 이 실패를 모두가 예견하고 있었지만 이를 함부로 말하지 않았고 이 사실이 경영진에게 충분히 전달되지 않았을 가능성이 높으며 어쩌면 이는 경영진에 대한 팀의 불신에 기인하고 있을지도 모른다는 사실입니다. 이미 해고된 마당에 이런 생각을 더 해도 의미는 없지만 이번에는 마일스톤이 실패한 원인에 대해 생각해 봤으니 다음에는 그렇다면 여섯 번째 마일스톤을 이런 상황에도 불구하고 성공 시킬 방법이 있지 않았을지, 지금이라도 실행할 만한 어떤 방법은 없을지 생각해 보려고 합니다. 구직에 집중해도 모자른 마당에 왜 이런 생각을 하고 있는지 스스로를 잘 이해하기 어려운데, 생각 나는 건 끝까지 생각해 볼 작정입니다.