92주차 프로젝트 주간 생존일지

회사에서는 한 달에 한 번 정도 일종의 개발일지를 작성해 공개하고 있습니다. 전통적인 프로젝트 관점에서 아직 개발하고 있는 프로젝트가 외부에 개발일지를 공개하는 행동은 그리 흔하지 않은 것 같지만 지금 일하는 분야에서는 개발 중인 프로젝트라도 NFT를 통해 이미 고객들이 있는 상태입니다. 이 고객들은 전통적인 게임 고객과는 속성이 약간 다를 수도 있지만 회사와 프로젝트 입장에서 고객은 고객이고 우리들을 신뢰해 우리들이 판매한 NFT를 소유해 주시는 분들께 매 달 우리들이 해 온 일, 그리고 이어서 할 일 등에 대한 정보를 공개하는 건 익숙하지는 않지만 다른 한 편으로는 꽤 재미있는 일입니다.

전통적인 프로젝트에서 실무를 담당하다 보면 종종 개발이 진행되는 전체 맥락과 상황을 놓칠 때가 있습니다. 프로젝트를 시작할 때는 프로젝트 구성원 전체를 대상으로 목표를 설명하곤 하지만 슬슬 마일스톤이 몰아치고 마감의 압박을 받으며 일하다 보면 시야가 좁아져 지금 당장 해결해야 할 일에 집중할 뿐 이 일의 결과가 전체 프로젝트에 어떤 결과를 미치는지, 또 왜 이 일을 하기로 했었는지 잊을 때가 있고 이는 종종 팀의 사기와 퍼포먼스에 영향을 끼치기도 합니다. 부끄럽지만 제 스스로도 그런 상태에 빠질 때가 있었는데 그럴 때 당장 눈앞에 닥친 일에 대한 짜증과 불만을 잠깐 접어 두고 이 짓거리를 왜 하기 시작했고 이 짓거리를 마치면 빌드에 어떤 변경이 일어나는지 그 맥락을 곰곰이 생각해 보면 시야가 다시 조금은 넓어지고 짜증과 불만이 줄어드는 효과가 있습니다. 그런데 외부 고객들을 위한 문서이기는 하지만 이렇게 일정 기간마다 지금 우리가 뭘 하고 있는지, 왜 이 일을 하고 있는지 정리한 글이 있어 잠깐 방금 소개한 짜증 나는 상태로 빠지려다가도 글을 읽어보고 ‘아 맞다….’ 하는 상태가 되어 다시 일에 집중할 수 있게 됩니다.

사실 저런 일종의 개발일지를 외부 고객용으로 작성해 공개하는 이유는 이전에 이 업계에서 NFT를 판매해 돈을 만든 다음 실제 개발을 진행하지 않고 그냥 잠적하는 경우가 꽤 자주 있었기 때문입니다. 프로젝트를 시작하면서 같은 업계에서 이미 개발하고 있다는 다른 프로젝트를 수없이 조사했는데 개발 전체에 대한 시야가 부족한 중간 관리자의 눈으로 봐도 이상해 보이는 프로젝트가 많았습니다. 이들이 NFT 판매를 통해 돈을 조금 모을 수는 있었겠지만 이 돈 만으로는 그들이 만들겠다고 주장하는 빌드 비슷한 것 조차도 만들 수 없어 보였습니다. 또 이들이 만들겠다는 게임의 규모에 비해 인원이 너무 적어 보였고 팀에 조인할 때 이런 상황에 주의해야 한다고 기획자 두 명이 만들 수 있는 MMO 게임은 없어요에 소개한 적도 있습니다. 생성형 인공지능에 의해 사람이 더 잘 한다고 생각했던 여러 가지 일들이 대체되어 가는 이 와중에도 여전히 게임 소프트웨어 개발은 노동 집약적인 일이며 이 거대한 노동력을 유지하는데는 엄청난 비용이 필요합니다. 또 우리들이 늘상 게임 웹진에서 만나는 별 것 아닌 것처럼 보이는 게임들도 그 정도 퀄리티와 그 정도 볼륨으로 개발해 런칭 단계에 도달하는데는 예상보다 훨씬 많은 사람들, 훨씬 큰 비용, 그리고 훨씬 긴 기간이 필요합니다.

하지만 NFT를 구입하는 고객들은 그저 개발팀이 주장하는 로드맵을 신뢰할 수밖에 없었을 테고 자신들이 NFT를 구입해 만든 돈으로는 게임 비슷한 것도 만들 수 없으리라는 사실을 알기는 어려웠을 겁니다. 그래서 온갖 프로젝트에서 러그풀 - 일종의 사기 행태를 표현하는 이 쪽 업계 용어 - 이 수없이 일어났고 이제 고객들은 자신들이 구입하는 데이터가 얼마나 멋져 보이는지, 또 미래에 어떤 혜택을 받을 수 있는지에 대한 관심과 동시에 이들이 제시한 로드맵이 현실적인지, 또 실제로 개발을 하고 있기는 한 것인지에 관심과 의심을 가지기 시작했습니다. 뭔가 대단한 결과를 만들어 내겠다고 말했지만 이에 비해 터무니 없이 작은 자원 만으로 볼품 없는 결과를 내놓는 프로젝트의 최고 책임자가 영상에 나와 오랜 시간에 걸쳐 자신의 행동을 정당화 하는 모습을 지켜보다가 고작 이런 걸로 사람들을 속일 수 있다면 이 세상에 가난한 사람이 없어져야 하는 게 맞지 않나 싶은 생각도 들었습니다.

안타깝게도 우리는 그런 필드에 있고 이런 필드에서 이전의 여러 사건들로 인해 의심이 깊어진 고객들을 대상으로 사업을 지속하려면 고객에게 진실에 기반해 설득하는 방법 밖에 없습니다. 우리들은 실제 개발 경험이 많은 사람들로 구성되어 있고 다들 실제 동작하는 게임을 만들어내기가 얼마나 어려운지, 얼마나 큰 비용이 필요하고 또 볼륨을 만들어내는데 얼마나 큰 규모가 필요한지, 또 그런 규모를 통제하기가 얼마나 어려운지 깊이 이해하고 이런 시도를 만만하게 보지 않는 사람들입니다. 또 우리들은 지금까지 러그풀로 끝난 크립토 게임 프로젝트들이 동작하는 빌드 대신 프리렌더 된 영상을 빠른 시점마다 공유하며 개발이 아주 빠르게 진행되는 것처럼 보이곤 했던 것에 비해 실제 동작하는 빌드를 제공하고 또 이 과정이 생각보다 만만하지 않으며 영상만 제공하는 프로젝트에 비해 개발이 더뎌 보이지만 이게 실제 개발 속도임을 설명하고 있습니다. 고객들이 이를 신뢰할지는 잘 모르겠지만 실제로 상황을 공유하고 우리가 개발을 계속하고 있음을 말하고 있습니다.

서론이 너무 길었는데 외부 고객들께 공유하는 개발일지를 살펴보다가 문득 프로젝트 안에 있는 사람 관점에서, 회사와 체결한 보안 관련 계약을 깨지 않는 범위를 조심스럽게 유지하며 내부 고객들, 그리고 프로젝트에 별 관심은 없지만 뉴스레터를 구독해 주시는 분들을 대상으로 한 개발일지, 혹은 생존일지를 작성해 보면 재미있겠다는 생각을 해봤습니다. 마치 영화 마션에서 하루를 마친 와트니가 카메라 앞에 앉아 그 날 일어났던 일을 담담하게 말하며 영상으로 일지를 남기는 것과 비슷할 수 있을 것 같습니다. 사실 매일 일기를 쓰기도 어려운데 매일 그런 영상을 남기는 건 생각보다 훨씬 어려운 일이거나 아니면 영상에 엄청나게 익숙해서 여느 관광지에서 쉽게 볼 수 있는 브이로그를 찍는 수많은 영상에 엄청나게 익숙한 사람이어야만 할 수 있을 것 같은데 저는 영상 문법에 익숙하지는 않아서 영상보다는 보기 불편한 글 모양으로 일지를 만들 수 있습니다. 오늘은 그 첫 번째 시간으로 프로젝트에 참여하고 나서 92주째 살아 남으며 겪은 일을 소개해 보겠습니다.

92주차 생존일지: 지난주에는 하루 휴가를 내고 궁극적으로 무엇을 성취하고 싶은가요?의 그트머리에 말씀 드린 대로 집에서 멀리 떨어진 곳에 가서 첫눈을 맞으며 걷고 또 맛있는 커피를 마셨습니다. 그렇게 주말을 보낸 다음 돌아와 출근하니 휴가 후 업무 파악은 고통스럽습니다에 소개한 마치 이 회사에 처음 출근한 것처럼 이전까지 제가 해 왔던 일들이 모두 생소하게 느껴지는 상태를 잠시 겪었지만 이내 익숙해질 수 있었습니다. 이 날은 이번 마일스톤의 기능 개발을 마치기로 한 시점으로부터 2주 전, 혹은 10근무일 전이었는데 지난 빌드에서 오직 게임 플레이만을 제시했다면 이번 빌드에서는 여기에 순환구조를 제시해야 하는 상황입니다. 여기에는 아이템 개념, 보상 시스템, 채집, 상점, 제작 같은 기초적인 개념과 이들을 지탱하는 기능이 필요한데 아직까지 이 모든 기능들이 시각적으로는 어떨지 몰라도 기능 상으로는 깔끔하게 한 사이클을 동작한 적이 없는 상태입니다.

여러 기능이 동시에 개발 되며 빌드는 온갖 오동작으로 가득해 각 기능의 담당자들이 개발을 마쳤더라도 이 기능에 도달하는 나머지 기능의 오동작으로 조립과 테스트가 거의 불가능합니다. 상황이 썩 좋지는 않지만 이 상황이 생소한 것도 아닙니다. 마일스톤 마감이 가까워지면 서로 다른 기능을 별로 의식하지 않고 개발하던 기능들이 한 브랜치에 통합되며 이전 까지는 멀쩡했던 기능이 오동작 하기 시작해 빌드는 아주 개판이 되어 이전까지는 최소한 플레이가 됐던 상황에서 이제는 레벨에 진입하려고만 해도 크래시가 일어나는 상황이 되곤 하는데 비슷한 시점에 온갖 기능이 한 브랜치에 통합되며 일어나는 흔한 상황입니다. 한동안은 모든 사람들이 고통 받겠지만 서로 다른 사람들이 개발한 기능을 의식하며 통합을 계속해 나가며 빌드 상태는 급격히 좋아지게 됩니다. 다만 이 과정이 꽤 고통스러운 것은 사실이며 매 마일스톤마다 이런 상황을 겪고 있습니다. 저 유명한 래스트 오브 어스로 발매 몇 주 전에는 게임이 엉망이었다고 하는데 우리는 그보다는 나은 상황이 아닐까 하며 스스로를 위로해 봅니다.

이 시점이 되면 사람들은 자신이 개발한 기능에 집중해 개발 환경에서 오직 그 기능이 동작하는 테스트 환경을 만들어 테스트 하곤 하는데 이는 테스트 시간을 단축하기 위한 자연스러운 행동입니다. 그런데 한 브랜치에 여러 코드가 머지되면서 이상한 일이 벌어지듯 게임디자인에서도 자신이 맡은 기능의 조립과 테스트에만 집중하다 보면 게임 전체는 동작하지 않고 있다는 사실을 놓치기 쉽습니다. 가령 상점 기능을 테스트 한다면 상점 NPC를 테스트 레벨에 배치해 놓고 그 레벨만 플레이 해서 상점을 테스트하면 아무런 문제가 없을 겁니다. 그런데 게임을 처음부터 실행해 보면 상점 NPC가 배치된 레벨에 아예 진입조차 할 수 없거나 아예 캐릭터를 생성할 수 없어 인게임에 진입할 수 없는 상황일 수 있습니다. 그래서 누군가는 계속해서 테스트 환경이 아니라 실제 게임이 실행되는 환경과 절차를 통해 게임의 상태를 파악하고 있어야 하는데 이번에는 제가 그 역할을 하고 있습니다. 제 스스로도 웬만큼 바쁘거나 급하지 않으면 테스트 환경만으로 테스트 하기 보다는 게임을 처음부터 시작해 테스트 환경까지 이동한 다음 테스트 하곤 하며 시간이 허락하는 한 이 방식을 추천하기도 합니다.

개발 브랜치에 다양한 코드와 에셋이 통합되면서 기획서에 언급하지 않은 온갖 상황이 일어나고 이 상황을 새로 정의해야 하는 일이 더 자주 일어납니다. 개인적으로 이를 ‘교통정리’라고 불렀는데 나중에 이게 업계에서 흔히 사용되는 용어라는 사실을 알고 웃겼습니다. 다른 사람들도 이 행동이 교통정리와 비슷하다고 생각했다는 점이 특히 웃겼습니다. 교통정리의 핵심은 크게 두 가지인데 하나는 질문을 가지고 있는 사람과 질문에 답할 수 있는 사람을 직접, 그리고 빠르게 연결하는 것, 다른 하나는 이렇게 이루어진 질문과 답변이 함께 일하는 최대한 많은 사람들에게 모호하지 않은 모양으로 선언되도록 하는 것입니다. 엔지니어가 기획서에 정의되지 않은 상황과 마주쳤을 때 이 기능의 기획서를 작성한 사람에게 맨 먼저 질문하기 마련이지만 종종 정의되지 않은 상황은 여러 사람의 의사결정에 의한 결과일 수 있습니다.

가령 어떤 레벨에서는 월드맵을 볼 수 없게 하기로 했다고 해 봅시다. 그럼 그 레벨에서 월드맵에 접근하려고 하면 쿨하게 입력을 씹거나 메시지를 보여주거나 메뉴를 비활성 상태로 표시하면 됩니다. 그런데 곤란하게도 누군가가 아무 레벨에서나 사용해야 하는 어떤 기능 버튼을 월드맵 인터페이스 안에 배치해 버려서 월드맵을 안 보여주기로 한 레벨에서 이 기능에 접근할 방법이 없어질 수도 있습니다. 그러면 이 상황을 ‘교통정리’하려면 월드맵 담당자와 월드맵 안에 특정 기능을 배치한 담당자가 모두 모여야 하는데 엔지니어가 이들을 모두 찾아다니기는 어렵습니다. 그러니 기획팀의 누군가가 라우터 역할을 해야 하는데 그 역할을 주로 제가 담당하고 있습니다.

이렇게 결정이 이루어지면 이상적인 형태는 기획서에 결정사항이 반영되는 것이지만 마일스톤 마감 상황에서 인력이 충분하지 않은 조직은 이를 실천하기 어렵습니다. 그렇다고 이를 방치하면 나중에는 기획서와 빌드 사이에 서로 너무 큰 차이가 생겨 기획서를 참고해 업무를 수행하려던 사업이나 QA 부서를 아주 곤란하게 할 수도 있습니다. 그래서 이들이 모두 포함된 슬랙 채널에 빠르게 일어나는 정의되지 않은 동작에 대한 의사결정 결과를 정리해서 올려 최대한 모든 사람들에게 전파 되도록 해야 합니다. 그런데 이를 실천하려고 보니 사람들은 여전히 많은 사람들이 모인 채널에 결정사항을 선언하는 행동을 그리 달가워하지 않곤 했는데 이런 선언은 종종 이 메시지를 입력한 사람에게 선언에 대한 책임이 돌아가기 때문인 것 같습니다. 하지만 기획팀은 요구사항을 정의하는 부서이고 또 이렇게 여러 의사결정이 일어날 때 의사결정을 수행하며 이 결정에 대한 수습 책임을 지고 있는 것도 맞습니다. 우리들이 경제적으로 실패한다면 경영진이 실패에 대한 책임을 지겠지만 빌드에 일어난 의사결정에 의하 문제가 일어난다면 우리들이 책임을 져야 합니다. 하지만 이런 책임을 주니어님들께 요구하는 건 또 너무 가혹하므로 교통정리가 일어날 때 옆에서 가만 듣고 있다가 이를 빠르게 정리해서 제 이름으로 슬랙 채널에 선언하고 앞에서 라우터 역할을 하는 것과 같이 이 결정에 의문을 가진 분들이 먼저 저에게 찾아오도록 하고 있습니다.

우리들과 협업하기를 원하는 외부 협력업체들로부터 에셋이 도착해 에셋을 게임에 넣고 테스트 해 보니 일부 에셋은 잘 동작했지만 나머지 에셋은 여러 가지 문제를 일으켰습니다. 이제 와서 협력업체에 이를 수정해 달라고 하기에는 시간이 부족할 것 같아 우리가 직접 수정하고 수정 사실을 전달하기로 합니다. 그런데 우리는 성별형 체형에 따라 다른 에셋을 필요로 하기 때문에 최소한 두 가지 성별형 체형에 따른 의상 에셋이 필요했는데 협력업체에서는 한 쪽 성별형 체형에 맞춘 에셋만을 전달해 준 상태여서 나머지 한 쪽 성별형 체형에 맞춘 에셋을 전달해 달라고 요청한 상태이지만 우리들의 제한시간 안에 에셋을 받을 수 있을지는 불확실한 상태입니다. 최악의 경우 두 번째 빌드 공개에서는 어느 한 쪽 성별형 체형에 맞는 의상만이 인게임에 나타나게 될 수 있는데 그러면 다른 성별형 체형 캐릭터가 상점에서 의상을 구입한 다음 이를 입을 수 없게 되어 이에 대한 처리가 필요해질 수 있습니다. 규칙 자체는 단순하겠지만 경험이 좋지 않고 또 이 규칙을 급하게 개발하게 될 테니 위험 부담이 있어 걱정입니다.

기획팀에 소속된 사람들은 종종 게임의 여러 부분이 자동으로 만들어지거나 내가 아닌 다른 사람이 작업 해야 한다고 생각할 때가 있습니다. 기획팀은 기획서를 내고 브리핑을 마친 다음 기다리면 작동되는 빌드가 쨘! 하고 나타날 것을 기대하기도 하는 것 같습니다. 하지만 그 사이에는 최소한 조립과 테스트 과정이 기다리고 있으며 특히 조립 과정을 수행하지 않으면 엉뚱한 사람이 조립하고 있을 수 있는데 이 사실이 기획자 본인에게 전달되지 않으면 이 분 입장에서는 기획서를 내고 기다리면 동작하는 빌드를 받을 수 있다고 착각할 수 있습니다.

지난 빌드에서 마을에 배치된 대화 가능한 NPC와 상호작용을 통해 여러 동작을 하는 물체들이 배치되어 있었는데 실은 이들 모두를 제가 배치하고 기능을 연결해 놓았습니다. 그래서 앞에 설명한 교통정리 상황에서 이런 NPC나 상호작용 가능한 물체의 배치 및 수정 방법을 기획팀에서 아무도 모르는 상황이 일어나기도 했는데 개인적으로는 시간은 없고 다른 사람에게 전달할 시간도 없으니 일단 개발 과정을 따라오며 구조를 이미 이해하고 있는 제가 모두 일을 끝내 버렸지만 이를 전파하지 않은 것은 큰 실수입니다. 이미 이번에도 다른 사람들은 모두 각자의 일이 바빠 새로운 기능을 수행할 NPC를 배치 조차 못 하고 있어 이번에도 NPC들을 배치하고 기능을 연결해 놓았는데 몇 달 전에 했던 실수를 반복하고 있는 것 같아 마음이 좋지는 않습니다.

개발 자원이 부족해 실시간으로 인게임에 이벤트를 진행하지는 못하지만 인게임 로그를 집계해 다양한 조건을 달성한 고객들께 보상하는 이벤트를 할 수는 있습니다. 실시간으로 달성 여부를 알 수 있으면 이벤트 참여율이 높아지지만 거기까지 이번 마일스톤에 개발할 수는 없습니다. 그런데 이 로그 역시 지난번에 로그를 설계해 전달하고 그 집계를 담당했는데 이는 순전히 마지막 아르바이트의 유산으로부터 비롯된 기초적인 지식을 갖추고 있어서 였을 뿐입니다. 만약 아무 것도 안 하고 있었으면 비즈니스 부서와 서버 엔지니어 사이의 업무가 됐을텐데 괜히 중간에서 인게임 로그 요구사항을 작성한 입장이 되어 관여하다 보니 집계 업무 역시 수행하게 되어 버렸습니다.

이번에는 여러 새로운 기능이 추가되기도 하고 또 지난번에 인게임 로그를 쌓아 집계해 보니 여러 아쉬운 점이 있어 이를 좀 해결하고 또 새로 추가되는 기능에도 인게임 로그를 남기는 요구사항을 작성하다 보니 비즈니스의 새로운 이벤트 요구사항을 검토하기도 해야 했습니다. 이를 한 사람이 하다가는 시간을 낭비할 것 같고 또 누군가에게 이를 넘길 수 있을 것 같지도 않아 비즈니스 담당자님께 로그 요구사항 완성과 엔지니어의 검토 후 실행되는 것과 그렇지 않은 것이 정리되는 상황을 기다리는 대신 이 논의를 슬랙에서 진행할 동안 실시간으로 대화에 따라오며 내용을 파악해 이벤트를 준비해 달라고 했습니다. 솔직히 좀 미안했는데 어쩔 도리가 없었습니다.

언리얼 엔진에서는 인터페이스 위에 3D 모델을 올리기가 쉽지 않은데 방법이 없지는 않지만 괜찮은 퀄리티를 만들면서 성능을 유지하려면 주의 깊게 개발해야 합니다. 에픽이 직접 개밥을 먹으며 개발하는 포트나이트를 살펴보면 이들은 절대 인터페이스 위에 모델을 올리지 않는데 이는 스스로도 이 과정이 상당히 비싸다는 사실을 알고 있기 때문일 것 같습니다. 그런데 국내에서 개발하는 게임들은 이상할 정도로 내 캐릭터를 인터페이스 위에 올려 놓는 구조를 선호하곤 하고 우리들 역시 마찬가지인데 다른 미들웨어라면 몰라도 언리얼에서 이를 실행하기는 쉽지 않았습니다. 다행히 인터페이스 위에 캐릭터 모델을 올려놓고 괜찮은 룩을 만들기는 했지만 이번에는 이 캐릭터가 무기를 들도록 만들기 쉽지 않겠다는 상황을 맞이했습니다.

사실 캐릭터가 의상을 입고 서 있는 데 까지는 기본적인 캐릭터 시스템으로 해결할 수 있었지만 이 캐릭터가 무기를 들게 만들려면 독립된 무기 시스템을 사용해야 했고 무기 시스템에 의해 무기를 들면 무기를 든 모습을 인터페이스 위에 올려 놓을 수는 있었지만 지금의 방식으로는 성능에 문제가 일어날 수 있습니다. 그래서 인터페이스 위에 캐릭터를 올려 놓을 때는 실제 무기 시스템이 아닌 오직 룩을 만드는데 사용하는 가벼운 보여주기 전용 무기 시스템을 따로 구축해 사용하곤 하는데 우리는 그럴 준비가 안 되어 있습니다. 그래서 단계를 둘로 나눠 일단 캐릭터를 인터페이스 위에 올려놓는데 집중하고 이 상태를 목표로 개발한 다음 만약 시간이 남는다면 - 안 남을 것을 알지만 - 무기를 들려 보기로 결정했습니다.

서로 다른 부분을 개발하는 사람들 사이에 의사소통이 잘 안되다 보면 웃기는 일이 벌어지곤 하는데 가령 게임의 주요 인터페이스로 이동하는 숏컷키 충돌이 가장 흔하게 일어나는 상황입니다. 인게임에서 C키는 캐릭터가 앉는 키로 사용되고 있습니다. 아직 인게임에서 앉기 동작이 의미 있게 사용되지는 않고 있지만 레벨디자인에서는 이미 이 동작을 의미 있게 사용할 계획을 준비해 놓고 있습니다. 당장 이번 빌드에 들어가지는 않겠지만 미래에는 이 앉기 동작이 의미 있게 동작할 테고 이 키 역시 계속해서 인게임에서 점유된 상태일 겁니다. 그런데 이 사실을 망각한 누군가가 의상 탈착 화면으로 가는 바로가기 키를 Customize의 C로 해 달라는 요구를 한 모양입니다. 담당 엔지니어가 이를 설정하려고 보니 이 키는 이미 앉기에 사용되고 있었습니다. 실은 언리얼 개발환경에서 주요 입력방식 설정은 엔지니어를 통하지 않아도 설정에서 간단히 바꿀 수 있는데 이 사실을 알았다면 이미 같은 키가 다른 기능에 사용 중이라는 사실을 엔지니어까지 가기 전에 알 수 있었을 겁니다. 여튼 엔지니어 선에서 요구사항 충돌을 알게 됐고 이 역시 교통정리를 통해 다른 키를 설정해 해결했습니다.

이런 일을 처리하며 한 주가 흘렀고 이제 마감까지 한 주, 5 근무일 밖에 남지 않은 주가 곧 시작될 예정입니다. 지난 92주에 걸쳐 살아 남았으니 새로 시작되는 한 주도 살아남을 수 있지 않을까 희망적으로 예상해 보지만 또 이번에는 무슨 일이 일어날지 아주 기대됩니다. 또 마감이 지나 엔지니어 선에서 우리들에게 빌드가 본격적으로 넘어오면 우리들 선에서 주요 기능을 조립해 게임처럼 만들어야 하는데 이 과정에서 또 얼마나 많은 문제와 예상하지 않은 문제, 그리고 정의되지 않은 상황들이 일어날지 기대 뿐 아니라 걱정도 됩니다. 상대적으로 게임디자인에서 게임을 조립하며 문제를 해결할 시간이 부족해 보여 걱정이기는 하지만 그건 다음 주가 지난 다음에 일어날 일이니 일단 지금 당장은 걱정하지 않기로 하며 92주차 프로젝트 생존일지를 마칩니다. 다음 생존일지에 뵙겠습니다.