시각에 집중한 개발

지난 권고사직 끝부분에 구직 중 시간이 될 때마다 프로젝트에서 겪은 일, 아쉬운 점, 개선할 수 있을 것 같은 부분들을 생각해 보고 글로 남길 작정이라는 이야기를 했습니다. 어떤 목록을 작성해 놓고 목록에 따라 일종이 포스트모템을 진행할 예정은 아니지만 대략 지금 이 글의 제목인 ‘시각에 집중한 개발’, ‘왜 새 PvE 모드는 기한에 맞출 수 없었나’, 또 ‘왜 채집, 상점, 제작 같은 기초 기능을 기한에 맞출 수 없었나’ 같은 주제들이 생각나는데 머지 않은 시점에 하나 씩 짚어 볼 수 있지 않을까 싶습니다. 오늘은 먼저 ‘시각에 집중한 개발’이라는 주제로 개발에 있어 시각적인 측면에 집중할 때 생기는 장점, 그리고 단점에 대해서 생각해 보려고 합니다. 개인 블로그의 모든 글에 그렇지만 이 글 역시 저 자신의 생각을 말하고 있을 뿐 이 생각은 함께 일했던 팀이나 이 글을 읽으시는 분들의 생각이나 관점과 다를 수 있음을 미리 양해 부탁 드립니다.

이번, 아니 지난 개발에서 개인적으로 가장 흥미롭게 생각한 점은 오픈월드 게임 개발에 지레 겁먹음, MMO만 만드는 세계에서 다른 경험을 할 기회, 플랫포머에 약한 사람은 플랫포머를 퍼즐로 만들었다에서 이야기한 적 있는 다른 곳에서는 경험하기 어려운 개발을 해볼 수 있다는 것입니다. 이미 그 이전에 다른 프로젝트를 경험하며 표면적으로는 MMO 게임을 몇 차례 개발했지만 이 경험들을 놓고 냉정하게 생각해 보면 결국 이것저것 만들다가 아무것도 똑바로 못 만든다에 소개한 상태에 가깝습니다. MMO는 여러 장르를 한 월드에 모아 놓은 다양한 게임처럼 보이지만 실상은 그 다양한 게임은 어느 것 하나 온전하지 않은 상태의 MMO 환경의 제약 속에서 만들어진 그리 인상적이지 못한 결과물일 때가 많았습니다. MMO 안에서는 다양한 PvP 모드와 PvE 모드, 여러 스타일의 퀘스트를 만들곤 했지만 이 경험을 가지고 어디 가서 각 분야를 전문적으로 개발하는 곳에 가서 ‘이런 경험이 있어요’ 하고 떳떳하게 말하기는 어려울 겁니다.

특히 국내에서 MMO, 그 중에서도 모바일 MMO를 만들다 보면 상당히 제한적인 개발 경험을 하기 쉽습니다. 가령 개발 도중 미래의 다국어화에 대비한 준비를 하게 되는데 이미 미들웨어로 사용하는 언리얼 엔진에서 다국어 환경을 제공하지만 여러 언리얼 프로젝트에 걸쳐 이 기능을 사용하지 않곤 했습니다. 그냥 오래 전부터 하던 대로 다국어 환경을 수동으로 구축하고 엑셀 파일에 텍스트 키와 언어 별 값을 입력하는 방식으로 개발했는데 이는 이전부터 이렇게 해 왔고 이 방식으로 여러 프로젝트에 걸쳐 아무 문제 없이 사용해 왔기 때문에 이전에 시도해본 적 없는 방법을 시도하는 대신 더 안전한 방법을 선택하는 약간 보수적인 의사결정의 결과입니다. 이 의사결정은 프로젝트 전체 관점에서 결코 문제를 일으키지 않고 또 올바른 의사결정이기도 합니다. 이미 이전 여러 프로젝트에 걸쳐 검증된 방법을 계속해서 사용하기 때문에 문제가 일어나더라도 이전에 해결해본 문제여서 익숙하게 해결할 수 있고 또 우리들이 직접 개발했으니 문제가 생기더라도 우리 스스로 해결할 수 있습니다. 개인적으로 언리얼 엔진에 ‘사용할 만한’ 다국어 대응 환경이 갖춰진 다음에는 이를 사용하지 않는데 작은 불만을 가지고 있었는데 이번에는, 아니 바로 직전에는 이런 의사결정을 할 수 있게 됩니다.

또 여러 번에 걸쳐 비슷한 주제로 투덜거린 적 있는 엑셀을 통한 데이터 입력 방식도 마찬가지입니다. 왜 엑셀 데이터를 컨버팅 할 때 유효성 검사가 필요했을까, 엑셀 수식 복잡도 통제, 왜 하필 엑셀이죠, 엑셀을 치우고 싶을 때, 엑셀을 위한 기형적 데이터 정의리 등 엑셀이 썩 어울리지 않는 상황에서 이전에 해 온 대로 엑셀을 계속해서 사용하거나 엑셀을 사용하다 보니 문제가 생기는 상황에서도 어떻게든 엑셀을 사용하기 위해 온갖 문제를 감수하면서도 결코 이 수 십 년에 걸친 익숙한 환경을 벗어날 생각조차 하지 않곤 했습니다. 그래서 늘 하던 대로 형상관리도구로부터 엑셀 파일을 체크아웃 하고 수정한 다음 저장하고 컨버팅 프로그램을 실행해 게임 클라이언트와 서버가 구동될 때 읽어들이기 편한 XML 형식으로 변환한 다음 이들을 모두 함께 커밋하고 별도로 밸리데이션 과정을 거친 다음 데이터가 적용된 결과를 테스트 하는 과정을 반복했는데 개인적으로 이 과정이 이터레이션을 느리게 만들어 게임디자인 관점에서 도전적인 시도를 하기 어렵게 만든다고 생각해 왔습니다.

어떤 팀에서는 관계형 데이터를 입력하는데 엑셀을 사용한 뇌에서 김 나기 딱 좋은 입력 방식 대신 관계형 데이터를 시각적으로 표시하고 빠뜨리지 않도록 도와주는 웹 폼을 통해 데이터를 입력하고 밸리데이션도 입력 즉시 처리하고 또 적용도 웹 폼을 서브밋 할 때 다로 일어나는 환경을 사용하기도 했는데 데이터를 대량으로 입력할 때는 귀찮았지만 데이터 수정에 일어나는 실수를 효과적으로 줄이고 또 관계형 데이터를 잘 이해하지 못하는 스탭들에게도 이를 어렵지 않게 이해 시킬 수 있어 좋았습니다. 또 다른 팀에서는 다국어화 준비가 되어 있었지만 접근 방식이 완전히 달랐는데 일단 다국어화를 구려한 프로젝트에서는 텍스트를 입력할 때 반드시 미리 정해진 방식으로 입력해야 합니다. 언리얼 엔진 기준 UI 위젯에 텍스트가 포함되어 있다면 텍스트를 일단 직접 입력하지만 나중에 이를 로케일 데이터로 옮기고 로케일 데이터와 연결된 아이디를 사용하는 방식으로 입력하거나 앞에서 소개한 엑셀을 사용한다면 엑셀에 새로 추가한 텍스트 아이디를 입력해야 했습니다.

여기서 종종 엑셀에 새로 추가한 텍스트 아이디를 언리얼 에디터에서 바로 인식할 수 없어 별도의 새로고침 과정을 거치거나 에디터를 재시작하는 불편을 겪곤 했습니다. 이런 상황에 비해 그 프로젝트에서는 다국어화 준비가 되어 있지만 이를 전혀 신경 쓸 필요가 없었는데 별도의 프로그램이 데이터, 소스코드를 스캔해 텍스트 사용을 검사한 다음 이를 별도의 데이터로 만들어 이 파일을 다국어화 한 다음 이를 다시 읽어들여 데이터, 소스코드에 적용하는 방식으로 동작했습니다. 덕분에 이전과 달리 다국어화에 아무 신경 쓰지 않고 소스코드 안에 텍스트를 직접 사용하기도 하고 UI 위젯에 스위처를 사용하거나 하는 대신 직접 텍스트를 쓴 다음 신경 써도 되기도 했습니다.

이전에 아쉬워 하던 이런 점들을 이번에는 좀 더 자유롭게 시도할 수 있었습니다. 이전이라면 실제 개발에서 검증되지 않은 관계로 말도 붙여 볼 수 없었을 언리얼 엔진의 다국어화 지원이나 대규모 레벨을 스트리밍 하기 위한 월드 파티션, 또 엑셀을 대신한 언리얼 데이터에셋 등 다양한 기능을 사용하기 시작합니다. 이런 선택은 사실 이렇게 할 수 밖에 없는 이유에 기반한 것이었는데 우리들은 아주 작은 팀이었고 검증된 안전한 방법이라 하더라도 이를 바닥부터 개발할 여유는 없었습니다. 가령 전통적인 다국어화 방식은 사실 난이도가 높지는 않지만 이를 개발하려면 분명히 비용이 필요했고 큰 레벨을 스트리밍 하고 여기에 맞춰 동기화 하는 기능 역시 이를 바닥부터 개발할 여유는 없었습니다. 또 엑셀 기반의 데이터 파이프라인 역시 마찬가지입니다. 그래서 언리얼 엔진에서 제공하는 우리들 스스로 검증해본 적 없는 기능을 적극적으로 사용할 수밖에 없기도 했습니다. 하지만 어느 정도는 이런 기능들이 온전히 돌아간다면 이 비싼 미들웨어를 활용해 개발 비용을 줄일 사례와 경험을 만들어 미래에 우리들의 의사결정에 힘을 실어줄 수 있어 보였습니다.

이런 검증되지 않은 시도들은 이런 개발 측면에만 국한되지 않았습니다. 게임의 다양한 부분에서 이전에는 잘 시도하지 않았을 행동을 시도하기도 했는데 특히 시각적인 측면에서 그랬습니다. 게임의 시각적 측면은 고객 관점에서 극초반 게임에 매력을 느끼고 후킹 되게 만드는 역할을 합니다. 일단 게임 플레이 영상을 60프레임으로 찍어 커다란 스크린에 재생하기만 해도 그 자체로 게임 광고 역할을 할 정도입니다. 또 그런 대단한 시각 효과로 가득한 게임을 플레이 하는 고객들의 고양감을 높이는 역할도 합니다. 하지만 개발 측면에서는 시각 효과가 늘어날 수록 개발 비용을 크게 높이는데 일단 퀄리티 높은 시각 효과는 에셋 제작 비용 자체도 높고 이를 실시간으로 처리해야 하는 게임에 큰 부담을 줍니다. 유튜브에서 종종 보이는 리얼리즘 모드를 적용해 초 고해상도 텍스처, 프레임 레이트를 신경 쓰지 않는 엄청난 파티클 연산, 이들 모두와 상호작용을 마친 엄청난 레이트레이싱을 포함한 영상은 아무 프레임에서나 멈춰도 그 자체가 포토리얼리즘을 넘어 하이퍼리얼리즘의 결과 그 자체입니다. 하지만 기술적으로 이렇게 할 수 있다 하더라도 이렇게 만들지 않는 이유는 최대한 광범위한 기계에서 원활하게 구동할 수 있어야 하기 때문입니다.

여느 MMO 개발 프로세스와 마찬가지로 여느 MMO 개발의 ‘첫 번째 마을’에 해당하는 부분을 개발하기 시작했는데 일단 여기서부터 마치 리얼리즘 모드를 적용한 것 마냥 화려한 시각 효과로 단장하기 시작합니다. 구조물 바닥은 금속 재질로 주변의 여러 빛을 반사해 반짝였고 레이트레이싱을 적용할 때 효과가 큰 빛을 내는 요소가 여기 저기 배치되어 있었으며 이들은 언뜻 보면 잘 눈에 띄지 않는 아름다운 파티클 효과를 포함했습니다. 또 인터페이스 역시 이전에 비해 훨씬 다양한 시도를 했습니다. 가령 모바일 기계에서는 프레임을 크게 저하 시켜 잘 사용하지 않곤 하는 블러 패널을 원하는 만큼 사용했고 전통적인 방식 대로 인터페이스를 씬으로 만들어 2D로 띄우는 대신 3D 공간에 띄운 다음 화각에 따른 곡률에 맞춰 자연스럽게 휘어지는 모양으로 만들었습니다. 사실 당장 배경부터 사양이 낮지는 않은 우리들의 개발 환경에서도 충분히 원활한 프레임이 잘 나오지 않기 시작했고 또 2D로 띄울 때는 마우스 커서가 끊기지 않고 부드럽게 조작할 수 있었지만 같은 UI에 큰 비용을 들여 3D로 띄우자 포스트프로세스와 함께 마우스 커서가 미세하게 좌표 사이를 뛰어넘게 됩니다. 근본적으로 3D 공간 상에는 주로 ‘직접 조작하지 않는’ 인터페이스를 표시하곤 하는데 이는 이런 인터페이스가 보기에는 아름답지만 실제로 이를 조작하기는 상당히 불편하기 때문입니다. 하지만 일단 보기에 멋져 보이는 온갖 시각 효과 속에 이런 사소한 문제는 쉽게 묻혔습니다.

개인적으로도 개발 초반의 고양된 분위기 속에 이런 사소한 문제를 지적하며 찬물을 끼얹고 싶지 않았고 어차피 최적화는 미래에 나올 수밖에 없는 이슈이니 굳이 지금 이야기할 이유도 없었습니다. 미래에 광범위한 기계에서 일정 수준 이상의 성능을 내도록 만들기 위해 온갖 조치를 취할 테고 그러면 지금 보이는 사용하기 불편하고 또 프레임이 떨어져 좀 불편한 느낌을 주는 이 모든 시각효과들은 크게 수정될 뿐 아니라 우리가 그 단계까지 가면 지금 기쁘게 온갖 시각효과를 밀어 넣는 사람들은 다시 한 번 기쁘게 시각효과를 줄이고 있을 겁니다. 그래서 지금 당장은 이 모든 불편한 경험에도 불구하고 아무 것도 하지 않았습니다.

위에서 설명한 언리얼 데이터에셋 역시 언리얼 에디터 상에서 즉시 편집하고 저장 후 즉시 월드에 반영되며 입력하는 순간 밸리데이션이 일어나는 경험은 분명 훌륭했지만 초반에 여러 데이터를 추가하면서 데이터 하나를 추가할 때마다 데이터 에셋을 새로 만들고 여러 데이터를 한 번에 고치려면 프로퍼티 매트릭스를 열어야만 하는 점은 마냥 훌륭하지는 않았습니다. 하지만 이 역시 초반에 여러 데이터를 한 번에 추가하는 상황에서는 분명 불편하지만 미래에 여러 사람이 동시에 데이터를 수정하고 테스트하는 상황에서는 도움이 될 거라고 생각해 지금 당장은 조금 불편하더라도 딱히 이를 개선하려고 하지 않았습니다.

이런 접근은 여러 특징들이 얽혀 어떤 특징은 개발 비용을 줄이기도 하고 같은 기능의 또 다른 특징은 개발 비용을 늘리기도 해서 언리얼 엔진이 제공하는 기능을 더 적극적으로 사용한다고 해서 비용이 감소한다고 평가하기는 어려운 상태를 만들었습니다. 사실 이 자체는 딱히 신경 쓸 만한 문제는 아니었는데 도리어 문제는 이렇게 개발을 진행하는 빌드가 우리를 바라보는 잠재 고객, 커뮤니티, NFT 홀더, 투자자들, 그리고 우리들 스스로에게 계속해서 시각에 집중한 개발을 하도록 부추기는 효과를 일으킵니다. 전통적인 비디오 게임 업계에서는 개발 도중에 게임을 공개하지 않는데 이유는 게임은 영상이 아니라 실시간으로 동작하는 소프트웨어이기 때문에 개발 도중 이를 공개하기 아주 어렵고 비용이 많이 들기 때문입니다. 만약 중간에 공개해야 한다면 개발 브랜치의 현재 상태를 그대로 패키징 해서 공개할 수 없습니다. 이 안에는 아직 완성되지 않은 기능이 일시적으로 개발 브랜치에 포함되어 있을 수도 있고 인증 기능이 아직 연동되지 않았을 수도 있으며 동작은 하겠지만 공개된 상태가 그나마 게임처럼 보이는 경험을 만드는 여러 설정이 아직 제대로 통합되지 않았기 때문입니다. 그래서 어떤 행사에 게임을 공개하려면 오직 이 공개 버전을 위한 별도 브랜치에서 게임 공개가 끝나면 버려질 작업들을 포함한 추가 비용을 들여 빌드를 별도 제작해야 합니다.

그런데 메타버스 및 크립토 게임 업계에서는 개발 중간에 빌드를 공개하는 행동이 흔했습니다. 아마도 가장 큰 이유는 지난 권고사직에서 설명한 NFT만 팔고 먹튀하는 플레이어들이 너무 많아서일 겁니다. 자신들이 사기 당한 것은 아닌지 계속해서 확인하는 방법은 개발팀에 현재 진행 상황을 계속해서 브리핑 하도록 요구하고 최대한 자주 동작하는 빌드를 공개하게 만드는 것입니다. 이 이유 뿐만은 아니겠지만 이 업계에는 빌드를 더 자주 공개하고 진행 상황과 다양한 정보를 더 자주 공개해야 하는 압력을 받았습니다. 이런 압력은 팀이 개발에 집중하기 어렵게 만들었는데 일단 빌드를 공개하고 진행 상황과 정보를 공개하는 행동 하나하나가 비용을 발생 시켰기 때문입니다. 가령 잠재적인 투자자들에게 원격에서 빌드를 시연하며 실제 게임을 설치해 실행한 다음 함께 플레이 하곤 했는데 처음 몇 번은 그럴 수 있을 지도 몰랐지만 이 횟수가 수 십 회에 이르면 아무리 기획팀에서 - 다른 팀에는 차마 이 일을 시킬 수 없으니 - 잠깐 시간을 내 이를 반복한다 하더라도 상당한 비용을 소모할 수밖에 없었습니다. 또 아직 확정되지 않은 정보를 미리 공개해야 하기도 했는데 이는 아주 짧은 시간이 지난 미래에 올바른 의사결정을 하기 어렵게 만들기도 했습니다.

이런 여러 복잡한 상황에도 불구하고 개발 중인 게임의 동작 일부를 영상으로 촬영하거나 스크린샷을 찍어 커뮤니티와 트위터 등지에 공유하는 일은 거의 습관적으로 계속됩니다. 덕분에 여느 먹튀가 확실해 보이는 다른 프로젝트에 비해 우리는 버그로 인해 웃기게 동작하는 영상이라도 이게 개발 중인 빌드의 일부라는 사실 때문에 잠재 고객들로부터, 그리고 NFT 홀더들로부터 나쁜 평가를 받지는 않았습니다. 그런데 이런 상황이 계속 되다 보니 빌드를 공유하는 소규모 테스트 때가 아니더라도 훨씬 자주 게임의 개발 중인 모습을 공개하게 됐는데 이 때문에 특히 아트에서는 게임 스크린샷이 공개될 때마다 상당히 예민하게 반응했습니다. 가령 아직 이펙트 작업이 모두 끝나지 않은 결과물의 스크린샷이 공개되는 것을 꺼려 했고 앞에서 설명한 다양한 광원 효과를 필요 이상으로 배치하곤 했습니다. 그래서 내부에서 테스트 할 때 레벨 상에서 시각 유도가 잘 되지 않거나 프레임이 떨어져 인터페이스를 조작하기 힘든 상태가 되기도 했지만 이는 스크린샷을 통해서는 드러나지 않기 때문에 적어도 스크린샷을 기준으로는 최대한 아름다운 모습을 만들었습니다. 이를 보는 사람들이 몹시 기뻐했고 우리들 역시 이런 반응에 고무됩니다.

이런 긍정적인 반응은 심지어 개발을 계속해 각각의 마일스톤 목표를 달성하고 예상대로 동작하는 소프트웨어를 개발해야 하는 우리들 자신마저 속였습니다. 가령 주 단위로 각 부서의 진행 상황을 보고하고 공유하는 자리에서 각 부서는 서로 할 수 있는 범위 안에서 가장 그럴듯한 시각 자료를 준비하기 시작합니다. 배경에서는 요청하지도 않은 멋진 구조물을 만들어내 기획에서 이 구조물의 배치와 쓸모를 고민하는데 시간을 사용하게 만들었고 어제까지 동작하던 포탈은 오늘 더 화려하고 멋진 오브젝트로 대체되어 기능이 고장 나 고쳐야 하기도 했습니다. 매주 하루 정도는 게임의 여러 화려하게 동작하는 부분들을 짧은 영상으로 만들고 또 아직 구현되지 않았지만 미래에 구현된 상태를 보여주기 위해 영상으로 동작하는 아름다운 시안을 만드는데 사용하곤 했습니다. 누군가는 매주 이런 보고를 준비하는데 시간이 너무 많이 들어 힘들다는 불만을 제기했지만 우리들 스스로가 시각적인 환상에 빠진 이상 부서 간에 진행 상황을 공유하는 회의를 불필요하다고 말하는 것처럼 몰아붙여 의견을 묵살했습니다. 물론 이 자리를 위해 준비한 여러 시각 자료는 앞에 나열한 여러 대상들에게 공개됐고 모두가 기뻐했습니다.

한편 이런 분위기는 마일스톤 목표를 달성하기 위해 목표로 삼은 날짜까지 기능을 준비해야 하는 별도 PM이 없어 각자가 마이크로 PM 역할을 담당하던 기획팀 입장에서는 그리 달갑지 않았습니다. 일단 기획팀은 그들 스스로는 다른 부서에서 공유하는 아름다운 시각 자료를 만들 일이 없었으므로 항상 문서 형식으로 된 진행상황을 보고할 수밖에 없었고 이는 외부에 공개할 만한 모습이 아니어서 쉽게 무시되었습니다. 분명 브리핑 회의 때 말했고 매주 공유 자리에서 이야기했지만 실제 개발을 진행하려고 보면 ‘처음 듣는데?’ 란 반응을 자주 겪었고 이는 기획팀 구성원들을 상당히 피곤하게 만들었습니다. 또한 공유 회의 때마다 기획팀은 대놓고 저평가를 반복해서 받은 나머지 사기 유지에도 어려움을 겪었습니다.

또 당장 이번 마일스톤에 개발을 완료해야 하는 기능을 브리핑 할 때 지금 빌드 공개 안 하면 우리 망하나요? 같은 질문을 받으며 완성도를 높여야 하지 않느냐는 의견을 듣기도 했는데 이는 아주 쉽게 전통적인 기획자의 낮은 직급 문제와 연결되어 이런 상황을 익숙하게 처리하는 방법을 아직 잘 모르는 스탭들에게 강한 스트레스를 주곤 했습니다. 모두가 아름다운 결과물을 만들어 기뻐하는 사이 마이크로 PM 역할을 하는 우리들은 로드맵을 보며 드는 감정을 느끼며 어떻게든 기한 안에 약속한 기능을 만들어내기 위해 윽박지르기도 하고 빌어 보기도 하고 부탁도 하고 사비로 커피도 사고 별 짓을 다 해봅니다.

하지만 이런 상태가 누적되자 전체적인 개발은 확실히 느려지기 시작했는데 이는 각자 자기 부서에서 한 일을 보고하는 회의 자리에서는 잘 드러나지 않았습니다. 각자 자신이 담당한 범위 안에서 동작하는 모습을 공유했지만 근본적으로 이들 각각은 그냥 에셋일 뿐이고 또 동작하는 코드 조각일 뿐입니다. 우리가 개발해야 하는 것은 근본적으로 실시간으로 동작하는 소프트웨어이고 에셋과 코드 조각은 이들이 통합되어 동작하는 소프트웨어의 일부입니다. 여러 사람들이 이들이 통합되어 동작하는 소프트웨어에 집중하는 대신 에셋 조각과 코드 조각에 집중하고 이들이 통합된 다음에도 기획에 넘어와 조립 되어 그저 요구사항에 따라 동작하는 소프트웨어 수준을 넘어 고객에게 우리가 의도하는 어떤 경험을 부여하는 게임을 만들기 위해서는 각자가 만든 여러 요소가 통합된 상태에 집중해야 한다고 생각했지만 이미 팀은 스스로 시각에 집중한 개발 스타일에 집중하고 있었던 것 같습니다.

이제 저는 잘렸기 때문에 이런 경향이 미래에 어떤 결과로 이어질지는 이제 알 수 없게 됐습니다. 지난 여름 비공개 테스트를 통해 빌드를 공개할 수 있었지만 머지 않아 다가올 두 번째 비공개 테스트를 위한 빌드는 기능 각각의 개발이 어느 정도 진행됐지만 이들은 아직 통합되지 않았고 또 조립되지 않아 통합되더라도 그저 동작하는 소프트웨어로써 의미 있을 뿐 의도한 경험을 주는 게임으로써 동작하지는 않을 가능성이 있습니다. 또한 두 번째 비공개 테스트 전에 런웨이가 고갈되어 권고사직이 일어난 상황에서 지금까지 설명한 시각적인 개발은 이 프로젝트가 끝까지 가서 성공하든 실패하든 어느 한 쪽의 결과를 얻기 이전에 이미 어느 정도 실패했다고 판단할 수 있지 않을까 싶습니다.

저 자신은 더 이상 개발에 참여하지 않으므로 미래가 어떻게 될지는 알 수 없습니다. 하지만 여러 가지 이유로 팀 전체가 시각적인 개발에 집중할 때 이로 인한 여러 가지 문제가 일어날 수 있고 그 결과 당장 단기적으로도 목표 달성에 실패하는 결과로 돌아올 수 있음을 배웠습니다.