2023년 직업생활 회고

사실 지난 2022년 직업생활 회고에 이어 2023년도에도 직업생활 회고를 해야 할 지 고민했습니다. 이미 권고사직, 아무도 돕지 않고 돌아서다, 소코로프의 생애를 통해 연말에 2023년도의 직업생활이 파국으로 치달았음을 충분히 설명했기 때문입니다.

회사 생활 측면에서는 마감 일정을 통한 학대 전략을 통해 항상 마감을 달성하는데 성공할 수 없음을 알면서도 이를 그냥 밀어 붙여 일시적인 생산성 향상을 달성하는 전략에 대한 의문, 아는 대로 다 불면 안돼를 통해 작은 조직에서 개인이 기술적으로는 할 수 있더라도 이를 그대로 밝히면 온갖 일을 떠맡아 팀이 돌아가도록 지지하고 있으면서도 아무런 존경도 받지 못한다는 사실을 설명했습니다. 개인적으로는 미움 받을 용기 없음을 통해 팀과 프로젝트에 시행착오로 인한 약간의 낭비를 견딜 체력이 있다면 예상되는 시행착오를 막지 않고 문제가 일어나도록 두는 편이 팀 관리 측면에서 더 나을 수 있다는 교훈을 설명하기도 했고 또 고위 의사결정자 이상의 의사소통 방식을 통해 우리가 개발하는 제품 자체에 별 관심이 없는 고위 의사결정자나 투자사에게 우리의 업무를 설명하는 방식을 배운 사례를 설명하기도 했습니다.

그렇다 보니 이미 제 개인적인 관점에서는 파국으로 치달은 2023년도 직업생활을 별도로 회고할 필요가 있을지 고민했습니다. 어차피 저는 회사에서 잘려 더 이상 기여할 수 없고 빌드는 이 해고와 관계 없이 어쨌든 개발되고 있으며 이를 결정했을 경영진, 그리고 투자사의 판단이 옳았음을 증명할 예정이며 이 상황을 바꿀 별다른 요소는 없어 보이기 때문입니다. 다만 여전히 PvP는 정말 저렴한가? 의사결정 따라잡기를 시도해볼 만한 결정이 일어난 미래를 알고 있는 사람 입장에서 이전 마일스톤 끄트머리로 돌아가 제 입장에서 마지막 마일스톤 개발 계획을 수립할 때 좀 도 올바른 의사결정을 할 여지가 있지 않았을지, 좀 더 올바른 의사결정을 수행했다고 가정하면 마지막 마일스톤은 어떤 모습이었을지를 생각해보는 것 정도는 나쁘지 않을 거라고 생각합니다. 그래서 이번에는 게임 경제를 외부에 공개할 이유가 무엇인가처럼 이 프로젝트가 뿌리를 두고 있는 블록체인 관련 언급은 이제 그만 두고 상업용 게임을 만들어 가는 관점에서 마지막 마일스톤 계획을 달리 수립할 수는 없었을지를 생각해 보려고 합니다.

이전 마일스톤을 통해 고객들에게 우리가 여느 러그풀 프로젝트와 비교해 실제 빌드를 개발할 능력이 있고 더 먼 미래까지 이어지는 현실적인 로드맵을 가지고 있다는 사실을 실제 서비스를 통해 증명했습니다. NFT에 관심을 보이는 고객들은 그 이전까지 구입한 NFT가 실제로 움직이는 세계를 구경조차 하지 못하거나 NFT와 비슷한 아바타가 가상 세계에 움직이기는 하지만 기껏해야 전후좌우 이동과 점프만 하며 에셋 스토어에서 갓 구입한 것이 확실한 따끈따끈한 레벨을 돌아다니는 것 이상의 결과를 본 적이 거의 없었을 겁니다. 그래서 실제로 일정 수준 이상의 게임 플레이를 할 수 있으며 그 안에서 NFT가 잘 동작하고 또 미래에 전통적인 크립토 게임의 문법에 따른 랜드 판매 및 메타버스 단계로 진입 같은 계획에 관심과 호응을 보였습니다. 이런 상황에서 다음 마일스톤은 우리가 고객들과 잠재 투자자들에게 밝힌 로드맵에 따라 개발을 계속해 나갈 계획이어야만 했고 또 잠재 고객들의 피드백을 일정 수준에서 수용하는 모습을 보여야 했으며 마일스톤이 끝날 때 이전과 마찬가지로 짧은 서비스를 통해 우리들이 개발을 지속하고 있다는 사실을 실제 동작하는 빌드를 통해 증명해야만 했습니다.

이런 상황에서 다음 마일스톤 개발 계획은 크게 미래에 게임의 핵심이 될 신규 PvE 모드와 이로부터 보상으로 획득한 아이템을 사용해 단기적으로 성장하고 웨어러블 아이템을 구입해 스스로를 차별화 할 수 있는 방법을 제공하는 크게 두 가지 덩어리로 구분했습니다. 사실 이전 마일스톤에 PvE 모드 한 종류와 PvP 모드 한 종류를 만들어 서비스 해 보니 고객들은 압도적으로 PvP 모드를 더 많이 플레이 했는데 이는 보상 없이 똑같은 PvE를 반복하면 순식간에 지루해질 수밖에 없기 때문에 나타난 현상이기도 하고 또 몬스터를 때리는 것 보다 실제 사람을 때리는 쪽이 훨씬 더 재미있는 당연한 속성 때문이기도 합니다. 그런데 우리는 애초에 사람과 사람이 싸우는 상황을 만들 생각이 별로 없었습니다. 우리가 스테이지를 제공하고 고객들이 이를 다양한 방법으로 플레이하며 재화를 획득해 게임 상에서 성장해 나가기를 반복하며 미래의 메타버스 단계에 도달하는 시간을 버는 정도로만 생각했습니다. 하지만 우연한 생각 끝에 낮은 비용으로 투입한 PvP 모드가 큰 인기를 끌면서 다음 마일스톤의 주 목표가 핵심 PvE 모드를 개발하는 것이면서도 또 다른 PvP 모드도 추가해야 하는 상황이 됩니다.

PvP는 정말 저렴한가? 의사결정 따라잡기에 설명한 대로 꼼수를 써서 PvP 제작 비용을 극도로 낮췄는데 이번에도 같은 방법을 사용한다면 PvP 제작 비용을 낮출 수 있을 것을 예상했습니다. 대신 개인적으로 감히 우리가 걸작에 손 댈 수 있을까? 같은 양심의 가책 같은 느낌을 받긴 했지만 어쨌든 신규 PvP 레벨 역시 낮은 비용으로 만들어냈고 이를 위한 최소한의 레벨 트윅과 규칙 트윅 만으로 동작하는 새 PvP 모드를 만들 수 있었습니다. 여기 까지는 괜찮았습니다.

하지만 게임의 핵심이 될 PvE 모드는 시작하기 전부터 상당한 난관에 봉착해 있었습니다. TPS 게임에서 PvE 모드는 애초에 우리들에게 제작 경험이 거의 없었고 보상을 고려하지 않은 반복 플레이 가능성을 처음부터 계획하기는 쉽지 않았습니다. 이전에 플레이 하던 협동 멀티플레이 게임인 Deep Rock Galactic의 호위 미션으로부터 영감을 얻어 게임 설정에 맞춰 호위 대상이 일정 속도로 이동할 때 플레이어들이 이를 호위해 레벨 끝까지 이동하며 다양한 몬스터를 상대하고 다양한 메커닉을 사용해 게임을 유리하게 만들기로 했습니다. 이 계획에는 경영진 뿐 아니라 다른 부서에서도 호의적인 반응을 보냈는데 적어도 이 PvE 모드는 기획서 상으로는 꽤 괜찮아 보였기 때문입니다. 게다가 게임의 목적을 제대로 파악하지 못한 누군가가 ‘이런 요소는 없음?’ 이라며 헛소리를 하더라도 중간에 여러 메커닉을 추가할 수 있었기 때문에 이런 바퀴벌레 같은 질문에도 상당한 내성이 있었습니다. 하지만 그런 다양한 메커닉을 한 번에 계획하고 한 번에 개발한 다음 한 번에 전체 게임 모드를 개발하는 계획은 그 자체가 이미 난관 그 자체였습니다.

또한 이 PvE 게임모드는 그렇게 개발해서는 안되는 방법으로 개발되기 시작합니다. 바로 모든 요소를 하나하나 전부 다 만든 다음 이들을 배치해 한 번에 동작하도록 만드는 것입니다. 이 방식은 주로 아주 큰 팀에서 복잡한 신규 컨텐츠를 빨리 만들기 위해 게임의 각 구성요소를 분리해 서로 다른 사람들에게 분산한 다음 먼저 완성되는 것부터 조립해 테스트를 시작하는 방식과 비슷합니다. 이렇게 하려면 일단 플레이시나리오에 각 부서가 합의한 다음 이를 기능 조각으로 분해해 각각을 서로 다른 게임디자이너가 설계하게 하고 이를 서로 다른 파이프라인을 통해 테크 및 아트 부서로 전달해 서로 다른 사람이 개발을 진행해야 합니다. 그리고 이 기능 전체를 총괄하는 누군가가 개발 진행에 따라 그때그때 준비된 각 부분을 조립해 테스트하고 수정사항을 각 부분의 담당 게임디자이너에게 요청해 서로 다른 파이프라인을 통해 수정하게 만들어 복잡한 게임 경험을 상대적으로 짧은 기간 안에 개발할 수 있습니다. 다만 이 방법은 여러 파이프라인을 서로 다른 사람들에게 분산 시킬 수 있는 큰 팀에서만 할 수 있습니다. 그런데 우리는 아주 작은 조직에서 이 방식을 사용합니다.

이 진행 과정에서 일어난 여러 문제와 결과에 대해서는 왜 새 PvE게임모드 개발은 실패할 수밖에 없었나에서 설명했는데 핵심은 총 4개월 짜리 마일스톤의 마감일 당일에도 새 PvE 모드는 한 사이클 전체가 동작한 적이 단 한번도 없었고 여기에 포함될 메커닉 일부가 제각각 동작하기는 하는 상태가 됩니다. 위 글에서 이 게임모드를 작은 팀에서 개발하려면 여러 파이프라인이 실제 서로 다른 사람들에 분산 되어 동작할 방법을 사용하는 대신 가장 중요한 기능부터 단일 파이프라인을 통해 개발하며 각 기능이 준비될 때마다 전체 경험의 버티컬슬라이스를 점차 보강해 나가는 방식으로 개발했어야 한다고 생각합니다. 하지만 이렇게 하지 않았고 큰 팀에서 개발하는 방식으로 여러 파이프라인을 통해 개발했지만 실제로는 인원이 부족해 같은 사람이 여러 파이프라인을 한꺼번에 담당하는 상황이 아주 흔하게 일어납니다. 그나마 이 상황에서 각 기능에 우선순위를 설정하고 이에 따라 기능 개발 순서를 조율했다면 마감날이 지남에도 단 한번도 전체 게임 사이클을 돌려본 적이 없는 상태를 마주하지는 않았을 겁니다.

결국 권고사직이 일어난 다음 남은 인원이 개발을 계속해 현재는 뭔가 돌아는 가는 상태를 만든 것 같습니다. 다만 이 PvE 모드를 처음 설계한 당사자조차 권고사직 목록에 포함되어 이제 이 모드의 경험이 초기에 의도한 경험에 부합하는지 확인할 사람이 없어졌습니다. 하지만 소코로프의 생애에 예상한 대로 이 계획은 결국 성공해 훨씬 적은 비용으로 마일스톤을 마무리 하고 두 번째 서비스를 성공시킬 수 있을 겁니다.

이제 이런 미래를 알고 있는 미래 사람 입장에서 PvE 모드를 단일 파이프라인 환경에 맞춰 단계별로 개발해 나가며 각 단계마다 전체 사이클을 수행할 수 있는 상태로 만드는데 집중해서 개발하는 것 외에 아예 다른 계획을 수립할 수는 없었을지도 생각해 봐야 합니다. 이 신규 PvE 모드는 게임 설정에 따라 장차 실행할 랜드 NFT 세일에 내러티브를 부여하는 장치임과 동시에 고객들이 반복 플레이를 통해 재화를 획득하는 핵심 장치이기도 합니다. 그래서 이 장치는 반복 플레이에 강하도록 다양한 메커닉을 포함에 이를 추가, 삭제하거나 배치 순서를 변경하거나 레벨디자인을 수정해 배리에이션을 만들기 쉬운 모양이어야 했습니다.

그래서 그 첫 번째 버전은 고객들에게 미래 계획을 설명하기 위해 필요 이상으로 다양한 메커닉을 포함한 다음 미래에는 이 메커닉들이 추가, 삭제되는 여러 배리에이션을 통해 다양한 플레이를 유도해 반복 플레이에 강한 형태를 만들 거라고 설명하려고 했습니다. 다만 이 목표는 단일 파이프라인을 가정하고 개발했더라도 한 마일스톤 안에 개발할 수 있는 분량을 초과했습니다. 실은 이를 처음부터 알고 있었고 이 계획을 접한 엔지니어들의 첫 반응은 ‘이걸 12월 까지 만들어야 한다고요?’였으며 이게 무슨 의미인지 바로 이해할 수 있었습니다.

단일 파이프라인을 고려하기 이전에 마일스톤의 핵심인 신규 PvE 모드의 전체 기능이 한 마일스톤 안에 개발이 불가능할 것이 거의 확실한 상황에서 이 계획 자체를 조정했어야 한다고 생각합니다. 아니면 적어도 계획을 처음 엔지니어들에게 전달했을 때 그들의 걱정을 좀 더 심각하게 인식했어야 했습니다. 하지만 이 상황에서 부서들 사이에는 서로 퍼포먼스를 충분히 내지 않는다는 의심이 얕게 깔려 있었고 엔지니어들의 우려는 그저 일종의 엄살로 치부되었는데 이것이 엄살이 결코 아니었음은 나중에 가서야 밝혀집니다. 마일스톤 계획을 수립하는 단계에서 이런 상황을 좀 더 고려했다면 한 마일스톤보다 비용이 큰 신규 PvE는 두 마일스톤에 걸쳐 개발하거나 두 마일스톤 전체를 사용할 때 위험성이 너무 높다는 점이 걱정된다면 신규 PvE 모드를 제외하고 구성한 두 번째 서비스와 이로부터 오래 지나지 않은 시점에 신규 PvE 모드를 포함한 세 번째 서비스로 구분해 계획을 수립했어야 합니다. 그러면 신규 PvE 모드와 게임의 나머지 부분 사이에 개발력을 분산할 수 있었을 테고 신규 PvE 모드 개발에 집중하느라 나머지 모든 부분이 마일스톤 후반에 다다르도록 개발이 끝나지 않아 손가락만 빨고 있는 상황에 빠지지 않았을 겁니다. 핵심은 한 마일스톤 안에 끝낼 수 없는 크기 기능은 두 마일스톤으로 나누거나 한 마일스톤 반으로 나눠 이어지는 마일스톤 기간을 절반으로 줄인 다음 남은 기능에 집중하는 식으로 마일스톤 계획을 수정했어야 합니다.

문제는 신규 PvE 모드에서만 일어나지 않았습니다. 이전에는 단순히 PvE 레벨에서 몬스터를 죽이며 앞으로 나아간 다음 보스 몬스터를 처치하면 스테이지를 클리어 할 뿐이었지만 이제부터는 이런 행동으로부터 보상을 얻어 축적하고 이를 판매하거나 직접 사용해 짧은 시간 범위 안에서 성장을 경험하는 일종의 순환구조를 만들어야 했습니다. 이를 위해 다양한 곳에서 플레이어에게 재화를 부여하기 위해 보상 시스템 디자인 (2023년 겨울 버전)을 고안했습니다. 그런데 이번 마일스톤을 시작할 시점에 우리는 빌드에 아이템, 재화 같은 개념 자체가 없었습니다. 상점에서 뭔가를 판매하려면 판매할 상품이 될 아이템, 판매할 때 받을 재화, 이들을 플레이어에게 지급할 보상 메커닉, 그리고 플레이어가 스스로 보유한 아이템을 살펴보고 사용하거나 장착하거나 판매할 인벤토리 인터페이스 등 다양한 기능이 필요했습니다. 그리고 이 모든 기능을 한 마일스톤 안에, 그리고 앞에서 말했듯 제한된 파이프라인을 사용해 개발해야만 했습니다.

개인적으로 실패할 가능성이 높은 대표적인 마일스톤 계획 형태에는 목표 플레이시나리오를 달성하기 위한 메커닉과 그 메커닉의 기반이 되는 또 다른 메커닉을 한 마일스톤 안에 동시에 개발하는 것이 있습니다. 가령 MMO 게임에서 탈것 경주 모드를 만들 작정인데 아직 게임에 탈것이 없어 탈것과 탈것 경주를 동시에 개발해야 한다면 이 마일스톤 계획은 실패할 가능성이 높습니다. 이 경우 각 기능의 의존성을 서로 다른 마일스톤으로 분리해 먼저 탈것을 개발하는데 집중하고 그 다음에 탈것 경주를 개발해야 합니다. 하지만 실제로는 여러 가지 어른들의 이유로 이번 마일스톤에 당장 탈것도 없는 상태에서 탈것 경주를 만들어야 하는 일이 일어나고 이 때문에 앞에서 설명한 큰 팀에서 여러 파이프라인에 걸친 개발이 일어납니다. 하지만 여러 파이프라인을 실제 서로 다른 사람들에게 분산할 수 있는 상황이 아니라면 이렇게 개발해서는 안됩니다.

신규 PvE 모드 외에도 우리는 아직 게임에 아이템 개념, 이를 표시할 인벤토리, 아이템을 플레이어에게 지급할 보상 체계도 없는 상태에서 이들을 사용할 상점, 제작, 채집, 그리고 이들 전체를 아우르는 순환구조를 한 마일스톤 안에 개발해야 했습니다. 당연히 이 계획은 위험했지만 여전히 여러 상황 상 순환구조를 한 마일스톤 안에 개발할 수밖에 없었습니다. 하지만 모든 가용 파이프라인은 신규 PvE 개발에 집중되어 있었고 아이템을 포함한 인벤토리, 보상, 채집, 상점, 제작은 마일스톤 후반에 이르기까지 계속해서 정체된 상태였습니다.

이런 상황에서 플레이시나리오를 이루는 핵심 기능의 우선순위에 민감하지 않은 사람이 업무를 배분하다 보면 업무의 중요도 보다는 업무의 크기에 다라 업무를 배분할 때가 있는데 큰 팀에서는 문제가 일어나지 않지만 작은 팀에서는 뚜렷한 문제입니다. 가령 개발 중 누군가의 손이 비면 당장 이 비는 구간에 알맞는 업무를 배분해야 하는데 이 때 중요도 대신 빈 구간의 크기에 맞는 업무를 배분하면서 별로 중요하지 않은 기능을 개발하게 됩니다. 가령 이번 마일스톤 목표 중에는 서로 다른 레벨에서 월드맵을 열어 전체 레벨에서 자신이 어디에 있는지 파악하는 기능이 있었는데 이는 필요하기는 했지만 미션 크리티컬 하지는 않았습니다. 월드맵 없이 아주 넓은 레벨에서 고객들이 길을 잃더라도 임시로 바닥에 화살표라도 그려 줄 수 있었고 심지어 이전 서비스 때 그렇게 하기도 했습니다. 하지만 이 기능은 그리 중요하지 않으면서도 업무 크기가 작았기 때문에 손이 빈 사람에게 바로 넘어갔고 나머지 더 중요한 기능보다 앞서 개발됩니다. 하지만 이 기능에 맞춰 실제 데이터를 입력할 사람들은 이미 다른 업무를 진행 중이어서 별로 중요하지 않은 기능이 먼저 개발되었지만 이 기능에 맞춘 데이터는 몇 주 뒤에나 입력되며 이 때가 된 다음에야 기능의 문제점이 드러나 다른 기능 개발로 바쁜 와중에 엔지니어가 이 기능의 문제까지 수정해야 하는 상황에 처합니다.

마일스톤 후반에 가서야 신규 PvE 레벨과 비슷하게 아이템 개념부터 시작한 모든 기능이 준비되어야만 구축할 수 있는 순환구조를 아주 조금이나마 손대볼 수 있는 환경이 갖춰졌는데 여전히 보상은 잘 동작하지 않았고 채집은 어색했고 상점 데이터 입력은 까다로웠으며 보상 데이터 입력은 극한의 노가다를 요구했습니다. 사실 보상 데이터 입력의 초반 노가다는 예상하고 있어 이를 자동화 할 작정이었지만 그 전에 잘리는 바람에 자동화 하지 못한 채로 다음 사람에게 넘어갔고 자동화 없이는 아마 고생 좀 하게 될 겁니다. 남은 사람들이 어떻게든 해서 신규 PvE 모드는 빠르게 개선되고 있는 것 같지만 이와 함께 이번 마일스톤의 양대 기능인 보상을 통한 단기적 성장 경험을 포함하는 순환구조는 상대적으로 개선사항이 눈에 잘 띄지 않아 개선 속도가 느려 보입니다. 이 역시 신규 PvE 모드 개발과 비슷하게 서로 의존성이 있는 두 가지 기능을 한 마일스톤 안에 개발하려는 계획과 큰 팀에서 주로 사용하는 기능을 각각 분해해 서로 다른 사람에게 분산할 수 있는 여러 파이프라인을 통해 개발하는 방법을 통해 개발하려다가 작은 조직에서 심각한 병목을 일으키며 전체 개발을 지연시킨 결과입니다.

지난 2023년에 수행한 두 마일스톤 중 한 마일스톤은 비교적 성공적으로 마무리 하며 짧은 서비스 역시 무사히 마무리하고 이를 기반으로 정량적 데이터를 탐색하는 단계에 도달할 수 있었습니다. 이 때는 플레이시나리오 자체가 좀 더 단순했지만 동시에 서로 의존성이 있는 기능이 이전 마일스톤으로 분리되어 한 마일스톤 동안은 이전에 개발한 기능에 의존해 신규 기능을 개발했습니다. 가령 고객들이 구입한 NFT에 대응하는 인게임 에셋을 생성하는 체계는 이 마일스톤 이전에 개발되어 이번에는 이들을 인게임 상에 띄워 테스트 해 보고 이들로 할 수 있는 플레이를 개발하는데 집중할 수 있었습니다. 하지만 그 다음 마일스톤은 서로 의존성이 있는 기능을 한 마일스톤 안에 동시에 개발하며 그런 기능 집합이 두 개였고 이들 모두는 마치 큰 팀에서 개발하는 것처럼 여러 파이프라인을 고려한 방식으로 개발을 진행했으나 물리적으로는 한 사람이 여러 파이프라인의 병목이 되며 개발이 지연될 수밖에 없었고 개발이 진행 되더라도 전체 기능을 테스트 할 수 없는 상태에 장기간 머무를 수밖에 없었습니다. 또 업무 분배 역시 기능의 우선순위 보다는 업무의 크기에 기반하면서 중요한 기능 보다는 더 작은 기능이 앞서 개발되어 장기간 방치되었습니다.

2023년 직업생활 회고에서 큰 그림에 해당하는 이야기는 이미 지난 권고사직에서 다 했으니 이번 직업생활 회고에서는 한 해 동안 수행한 두 마일스톤을 비교해 성공적으로 수행한 마일스톤 하나와 적어도 제 관점에서는 실패한 그 다음 마일스톤을 비교하며 한쪽은 왜 성공했는지, 그리고 다른 한쪽은 왜 실패했는지 생각해 보았습니다. 저는 이제 더 이상 개발에 관여할 수 없고 지금까지의 경험과 기억에 기반해 이런 상상을 해 보는 입장입니다. 실제 개발은 남은 사람들이 이어서 성공적으로 진행할 수 있으리라 확신합니다. 개인적으로는 한 해 동안 수행한 두 마일스톤을 비교해 보며 앞으로 새로운 마일스톤 계획을 수립할 때 올해의 경험을 거울 삼아 실패할 가능성이 낮은 마일스톤 계획을 수립하고 또 적어도 이번 보다는 더 효율적으로 운영할 수 있지 않을까 하는 작은 교훈을 얻었습니다.

2023년 직업생활 회고는 회고라고 하기에는 시야가 좁은 느낌이지만 회사에서 잘린 특수한 상황 상 좁은 시야를 통해서만 이야기할 수 있음을 양해 부탁 드리며 다음 번 직업생활 회고에서는 좀 더 밝고 희망찬, 그리고 뭔가 더 잘 된 이야기를 할 수 있으면 좋겠습니다.