욕망의 절제

역사상 가장 복잡한 소프트웨어가 무엇인지는 기준에 따라 달라질 수 있습니다. 소프트웨어 복잡도를 평가하기에 소스코드 라인 수는 썩 훌륭한 지표는 아닐 겁니다. 작성한 언어, 소프트웨어 플랫폼 등에 따라 크게 달라질 수 있을 뿐 아니라 소스코드 라인 수 자체가 복잡도의 선형 증가를 의미하지는 않을 가능성이 있기 때문입니다. 하지만 복잡도의 증가와 라인 수 증가 사이에는 양의 상관관계가 있을 거라고 예상합니다. 세계적으로 소스코드가 가장 긴 것으로 알려진 소프트웨어에는 구글 서비스, 페이스북 서비스, 윈도우 운영체제, 리눅스 운영체제, 매킨토시 운영체제 등이 있다고 알려져 있습니다. 여기까지는 워낙 유명한 소프트웨어들인데 그 다음에는 LHC 제어 및 데이터 처리 시스템, 안드로이드 운영체제, 보잉 787 항공기 소프트웨어, 쉐보레 볼트 자동차 소프트웨어 등이 있습니다. 이들의 소스코드는 수 백만 라인에서 수 천만 라인에 달합니다. 구글 서비스는 약 20억 라인 이상으로 알려져 있지만 이들은 전체 서비스를 포함한 값이므로 이 목록의 맨 위에 두기는 하겠지만 나머지 소프트웨어들과 함께 비교하기에 적절하지 않을 수 있습니다. 이 목록에는 잘 알려진 운영체제, 복잡한 장치의 제어 및 데이터 처리 소프트웨어들이 주로 포함되어 있습니다. 그런데 이런 목록에는 잘 나타나지 않지만 이만큼 소스코드가 길면서도 운영체제도 아니고 복잡한 기계의 제어 소프트웨어도 아닌 서비스가 있는데 바로 미국 healthcare.gov 입니다.

미국 헬스케어 웹 서비스의 개발과 런칭 과정은 소프트웨어 업계에 여러 가지 교훈을 줄 정도로 순탄하지 않았다고 알려져 있습니다. 지나치게 낙관적인 일정 추산, 검증되지 않았을 뿐 아니라 개발자들에 익숙하지 않은 데이터베이스 도입, 성능을 거의 고려하지 않은 데이터베이스 사용, 전체 시스템에 대한 인증 서비스의 중요성에 대한 과소 평가, 부족한 테스트와 보안 평가 등 온갖 문제가 겹쳐 예상 대로 런칭과 동시에 아무도 정상적으로 사용할 수 없었습니다. 실은 ‘아무도’라는 표현은 잘못되었는데 런칭 첫 날 이 서비스를 통해 정상적으로 의료보험에 가입한 사용자가 여섯 명 있었다고 알려져 있기 때문입니다. ‘아무도’ 정상적으로 사용할 수 없지는 않았고 여섯 명이 정상적으로 사용했고 나머지 사용자들은 로그인에 실패하거나 서비스 검색이 영원히 끝나지 않거나 개인정보를 입력하는 과정에서 폼을 제출하고 서비스가 영원히 응답하지 않는 상황을 겪었다고 알려졌습니다. 사실 이런 상황은 이미 서비스 런칭 수 개월 전부터 예견되었습니다. 개발의 각 마일스톤 종료 시점마다 수행한 시연은 항상 실패했는데 나중에는 어차피 시연에 실패할 것을 고려해 실제 시연 대신 스토리보드를 가지고 프리젠테이션을 하는 것으로 보고를 마무리하기도 했습니다. 개발자들에 익숙하지 않은 데이터베이스를 선택했고 각 요청마다 과도학게 데이터베이스에 요청을 보내는 코드가 아무런 검증 없이 사용되어 이들은 오직 테스트 환경에서만 정상 동작했습니다. 런칭이 얼마 남지 않은 시점에 수행한 스트레스 테스트에서 최초에 예상한 규모의 인프라로는 서비스를 수행할 정상적인 성능을 낼 수 없음을 알게 된 다음에는 급하게 인프라를 증설했지만 결국 인증 서비스가 서비스 전체에 영향을 미치는 가장 인프라 집중적인 모듈이라는 사실을 간과하면서 런칭 시점에 서비스를 사용할 수 없게 만드는 근본적인 원인으로 지목되었습니다.

헬스케어 웹 서비스의 런칭 실패 사례는 여러 모로 배울 점이 많습니다. 가령 검증되지 않은 데이터베이스 시스템을 선택해 새로운 데이터베이스 시스템에 기반해 요구사항을 처리할 수 있을지 여부가 데이터베이스를 사용할 여러 개발자들에 걸쳐 검증되지 않았을 뿐 아니라 새로운 데이터베이스는 이들에게 익숙하지 않았습니다. 프로젝트 관리 관점에서는 어떤 팀이 어느 기능을 개발하고 있는지 잘 파악되지 않은 상태에서 각 마일스톤마다 완료될 기능과 이로 인해 시연 가능한 기능과 그렇지 않은 기능을 구분할 수도 없었습니다. 그런데 이 사례를 살펴보다가 가장 제 흥미를 끄는 부분은 바로 여러 팀이 스프린트 방식으로 개발하는 과정에서 스프린트 막바지에 요구사항이 추가되어 스프린트가 엉망으로 변해 버린 사례를 실패 원인 중 하나로 언급한 것입니다. 스프린트는 정확한 목표에 기반해 제한 시간 동안 개발해 작동 가능한 결과물을 만드는 소프트웨어 개발 방법론 중 하나입니다. 이 핵심을 조금 더 설명하면 먼저 정확한 목표와 제한 시간이 필요합니다. 구성원들이 정확한 목표를 인식하고 제한 시간 안에 이를 작동 가능한 결과로 만들어내야 합니다. 만약 목표가 정확하지 않거나 구성원들이 목표를 충분히 인식하지 못했다면 스프린트는 실행 가능하지 않습니다. 그저 시간을 보내며 그때그때 주어진 개발을 수행할 뿐입니다. 결과적으로 구성원들은 제한 시간 안에 개발했지만 정작 제한 시간이 끝날 때 목표에 따른 작동하는 소프트웨어를 개발하는데 실패할 수 있습니다. 이제 헬스케어 시스템의 런칭 실패 원인 중 하나로 지목된 스프린트 막바지에 요구사항이 추가되었다는 말이 뭔가 이상하다는 점을 느끼실 수 있을 겁니다. 스프린트는 시작하기 전에 명확한 목표가 설정된 다음 스프린트가 끝날 때까지 목표가 변경되지 않아야 합니다. 부득이하게 목표가 변경된다면 그 스프린트를 중단하고 새로 추가된 요구사항을 포함해 목표를 재검토하고 구성원들이 다시 숙지한 다음 다시 시작해야 합니다.

스프린트의 핵심은 제한 시간 또는 일정 기간 동안 단위 기능 개발팀이 정확한 목표를 숙지한 상태로 이 목표가 온전히 동작하는 상태를 만들기 위해 개발에 집중하는 것입니다. 새로운 목표가 추가되지 않기 때문에 처음 이해한 목표를 깊이 이해하고 이를 달성하기 위해 다양한 방법을 동원합니다. 구성원 각자의 역할은 스프린트 목표를 달성하는 범위 안에서 오직 동작하는 결과를 도출하기 위한 관점에서 분배됩니다. 문제가 발생하면 모든 구성원이 관심을 가지고 빨리 해결하는데 이 모든 과정은 오직 스프린트를 시작할 때 수립한 목표를 달성하기 위함입니다. 스프린트에 기반한 개발은 어쨌든 결과를 도출하는데 집중하고 이를 실현하는 장점이 있지만 반대로 이런 특징 때문에 중장기적으로 문제를 일으킬 수 있는 의사결정이 제한 시간 안에 동작하는 결과를 만드는데 집중하기 위해 쉽게 일어날 수 있다는 점 때문에 배척되기도 합니다. 그래서 보다 규모가 크고 상대적으로 개발기간이 긴 소프트웨어는 특별한 이유가 없다면 스프린트에 기반해 개발하지 않곤 합니다. 그런데 스프린트에 기반해 개발할 때 스프린트 기간 동안 요구사항이 추가된다는 말은 사실상 스프린트가 이름만 스프린트였을 뿐 실제 스프린트에 기반해 진행되지 않았음을 의미합니다. 만약 스프린트가 온전히 진행되었다면 스프린트 기간 동안에는 요구사항이 추가될 수 없습니다. 구성원들은 이미 초기 목표를 숙지하고 이를 제한 시간 안에 달성하기 위해 ‘달리고’ 있기 때문입니다. 이들에게 새로운 요구사항을 부여하기 위해서는 스프린트를 중단하고 목표를 재설정해야 합니다. 하지만 스프린트 후반에 요구사항이 추가되어 구성원들을 곤란하게 만들었다는 말로 미루어 스프린트가 정상적으로 수행되지 않았음을 짐작할 수 있습니다.

그런데 이런 성공적이지 않은 스프린트는 굳이 헬스케어 시스템까지 가지 않더라도 상용 게임 소프트웨어를 개발하는 우리들 주변에서도 쉽게 사례를 발견할 수 있습니다. 첫 회사의 첫 프로젝트를 제외한 나머지 모든 프로젝트에서 ‘마일스톤’ 단위로 개발해 왔습니다. 이게 너무 당연했기에 소프트웨어를 개발하는 누구라도 마일스톤 단위로 개발할 거라고 생각했지만 이는 개발기간이 길고 또 복잡도가 높은 이 분야에서 흔히 그렇게 할 뿐 나머지 업계에서는 그렇지 않다는 점을 우연히 알게 되었습니다. 상용 게임 소프트웨어는 개발 기간이 1년 이상일 때가 많고 종종 수 년에 걸쳐 개발하기도 하며 요즘 세상에는 100명 정도 되는 인원이 동시에 참여하는 정도는 큰 프로젝트로 인식하지 않는 수준이 되었습니다. 때문에 전체 개발 기간을 적당한 기간으로 나눠 각 기간 별로 목표를 정한 다음 프로젝트에 속한 서로 다른 직군이 각자의 업무를 수행하고 마일스톤 후반에는 각자가 만들어낸 빌드, 에셋, 데이터를 조립해 동작하는 플레이와 기능을 만들어내 마일스톤이 끝날 때는 목표로 한 기능들이 동작하는 상태로 만듭니다. 이 설명을 위에 있는 스프린트와 비교해 보면 거의 대부분이 일치한다고 생각할 수도 있습니다. 그런데 스프린트와 마일스톤의 가장 큰 차이점은 제한 시간의 길이입니다. 스프린트는 보통 짧게는 2주에서 길게는 8주 정도의 기간 도안 수행하는 반면 마일스톤은 8주에서 길게는 12주 이상의 기간에 걸쳐 진행되기도 합니다. 최근에 경험한 어떤 프로젝트에서는 한 마일스톤의 길이를 무려 6개월로 설정했는데 스프린트 수준의 목표를 수립하기도 쉽지 않아 스프린트 중간에 요구사항이 변경되는 일이 발생하는 세계에서 6개월에 달하는 마일스톤을 지탱할 목표를 설정하기는 사실상 불가능했습니다. 어쨌든 마일스톤과 스프린트의 가장 큰 차이는 바로 기간입니다.

스프린트를 실행할 때 기간을 최대한 짧게 만들기 위해 노력하는 이유는 기간이 길어질수록 목표를 설정하기 어렵고 또 목표에 따른 스프린트 구성원들의 퍼포먼스 예측이 급격하게 어려워지기 때문입니다. 개인적으로 프로젝트 극초반 마일스톤 계획을 수립할 때 일부러 목표를 정확하게 설정하지 않고 약간 느슨하게, 열린 결말에 가까운 목표를 수립하곤 했습니다. 이는 종종 관리자로부터 문제로 지적되기도 했지만 처음 모인 사람들이 처음 일하는 상황에서 이들의 퍼포먼스를 예측할 근거가 전혀 없는 상황에서 목표를 너무 구체적으로 설정하면 예측은 아주 쉽게 실패하고 마일스톤 목표 달성에 시작부터 당연히 실패할 수 있었기 때문에 보통 제가 의도한 대로 약간은 느슨하고 또 열려 있는 목표를 수립했습니다. 하지만 시간이 지나며 이 목표는 점점 더 구체적으로 변하고 우리들이 이 목표를 달성할 수 있음을 확신할 수 있게 됩니다. 하지만 이 역시 마일스톤 기간이 8주에서 12주 사이일 때만 가능합니다. 만약 마일스톤이 이보다 길어지면 목표를 통제할 수 없게 되는데 여기에는 두 가지 이유가 있습니다. 첫째. 기간이 길어지는 만큼 마일스톤의 목표 역시 더 크고 구체적인 모양으로 변합니다. 이는 마일스톤 초기에 구성원들이 목표를 명확하게 인지하기 더 어렵게 만들어 목표를 인지하는데 마일스톤 초기 기간을 소모하게 만듭니다. 둘째. 목표를 인식하기 어렵고 또 기간 자체가 길기 때문에 중간에 요구사항이 추가될 여지를 줍니다. ‘건물을 왼쪽으로 1cm만 옮겨 주세요' 같은 요구사항이 더 짧은 마일스톤에는 끼어들 여지가 거의 없지만 더 긴 마일스톤에는 더 쉽게 끼어들 수 있습니다. 그래서 가장 긴 스프린트 기간과 비슷한 8주 짜리 마일스톤은 그나마 통제할 여지가 있지만 12주보다 더 긴 마일스톤은 사실상 마일스톤으로써 통제 가능한 범위를 벗어납니다.

마일스톤 길이가 길어지면 초기에 마일스톤 목표를 수립하기 거의 불가능해지고 또 목표의 범위가 크고 구체적으로 변하기 때문에 구성원들이 이를 목표로써 명확히 인식하기 어려워진다고 앞서 이야기했습니다. 그런데 각 구성원들이 목표를 인식하기 어려워지면 중간에 끼어드는 요구사항에 대한 통제가 어려워집니다. 이상적으로는 요구사항은 항상 한 곳에서 받고 이 요구사항을 받아들여 스프린트를 중단하고 다시 시작할지 검토해야 합니다. 마일스톤 기반으로 개발할 때도 마찬가지로 변경, 또는 추가된 요구사항을 검토해 잉여 자원에 목표를 부여할지 아니면 다음 마일스톤 계획에 추가하고 이번 마일스톤에서는 수행하지 않을지 여부를 결정해야 합니다. 하지만 이렇게 컨텍 포인트를 한 곳으로 설정하면 외부에서 요구사항을 밀어 넣기 어렵게 되므로 주로 요구사항은 단일 컨텍 포인트나 주요 관리자를 거치지 않고 의도적으로 실무자 수준에 직접 전달되곤 합니다. 실무자들은 일반적으로 변경된 요구사항에 저항할 권한이 없으므로 이를 받아들이는 편입니다. 이미 마일스톤 초반에 예상했던 목표는 흐릿해지고 그때그때 변경되는 요구사항에 반사적으로 대응하며 아주 짧은 시야의 의사결정을 반복하게 되는 썩 바람직하지 않은 상태가 됩니다. 이런 일이 프로젝트 곳곳에서 일어나기 시작하면 애초에 마일스톤 목표가 무엇이었는지, 어떤 상태로 동작해야 하는지 따위에 대한 인식이 흐릿해집니다. 통합된 빌드는 시간 단위로 오동작을 반복하지만 이것이 오동작인지 아니면 새로 추가된 요구사항에 의한 의도된 동작인지 판단하기도 어렵습니다.

이런 상황은 프로젝트에 큰 이벤트를 앞두고 더 자주 발생합니다. 앞서 C레벨 패닉에서 고위 의사결정자들이 자신의 상상 속 빌드와 요구사항이 마구 변경되어 예측 불가능한 모양으로 바뀐 빌드 사이의 차이를 보고 이 간극을 줄이기 위해 여러 요구사항을 가장 높은 우선순위로 남발하게 되는 상황을 소개했습니다. 또 어떤 프로젝트에서 이런 의사결정 결과로 실컷 개발한 커스터마이징 기능을 제거한 사례를 중요 보고와 게임 커스터마이징에 소개하기도 했습니다. 여기서 큰 이벤트란 프로젝트가 처한 상황에 따라 조금씩 달라집니다. 어떤 프로젝트는 3개월 마다 닥쳐 오는 회사의 허들일 수 있습니다. 허들을 통과하지 못하면 프로젝트가 취소되고 쫓겨나는 신세가 됩니다. 이런 일이 일어날 수 있는 이유는 게임 업계의 고용 형태는 프로젝트 단위 계약직에 가깝습니다에 설명한 적 있습니다. 또 다른 프로젝트는 그저 회사의 경영진과 고위 임원들에게 프로젝트의 진행 상황을 브리핑 하고 프로젝트 일부를 시연하는 보고 형식일 수도 있습니다. 이 경우 보고 직전에는 프로젝트의 외형적인 측면에 아주 큰 자원을 투입합니다. 게임 전체에 임시 에셋이 존재해서는 안되며 개발 중인 어설픈 기능, 덜 만들어진 인터페이스 에셋 따위가 절대로 나타나서는 안됩니다. 종종 이런 일들을 ‘코스메틱 이슈’라고 불렀는데 보고 직전이 되면 코스메틱 이슈의 우선순위가 최상으로 올라가 아직 입력되지 않은 L10N 데이터 키가 그대로 표시되어 고장 난 것처럼 보이거나 실험적으로 몬스터가 동기화 영역 언저리에서 아이들 동작을 취하게 하려던 기능을 제거하기도 합니다. 또 이 문단 앞쪽에서 소개한 대로 다 만들어 놓은 기능이 충분히 그럴싸해 보이지 않으면 아예 존재하지 않는 것처럼 제거해 버리기도 합니다.

근본적으로 프로젝트의 고위 의사결정자는 회사의 이런 중요 이벤트를 미리 예상할 수 있어야 합니다. 프로젝트에 소속되어 일하는 실무자들은 경영진과 직접적인 접점이 없으므로 정보를 얻기 어렵지만 프로젝트의 고위 의사결정자들은 경영진들과 접점이 있으므로 이들로부터 중요 이벤트의 존재와 실행 시점에 대한 정보를 미리 획득할 수 있습니다. 가령 이번 마일스톤이 종료되는 5월 말에는 이번 마일스톤의 산출물을 기준으로 경영진 보고를 할 예정이라든지 같은 시점에 보안 서약을 한 잠재 고객들을 회사로 모셔 포커스 그룹 테스트를 할 계획이라는 회사의 상황을 미리 파악하고 있어야 합니다. 이 정보에 기반해 마일스톤 계획을 수립하고 이번 마일스톤의 목표들 사이의 우선순위를 설정할 수 있습니다. 마일스톤이 끝날 때 중요한 경영진 보고 또는 허들을 수행해야 한다면 이번에는 이 이벤트를 무사히 넘기는데 집중하는 기능 위주로 개발하도록 목표를 설정하고 마일스톤을 시작할 때 이 목표를 프로젝트 구성원들에게 공유해 각자의 작은 의사결정을 할 때 이 목표를 달성하는 관점에서 의사결정이 이루어지도록 유도할 수도 있습니다. 그런데 정말 이상하고 또 신기하게도 지금까지 경험한 프로젝트 내 고위 의사결정자들 중 그 누구도 이런 회사의 중요 이벤트를 미리 파악하고 전제 대응하지 않았습니다. 늘 프로젝트가 끝날 때까지 몇 주 남지 않은 시점에 갑자기 회사의 중요 이벤트의 존재를 밝히며 지금부터 이를 대비하기 위해 지금까지 수행해 온 모든 개발보다 더 높은 우선순위로 보고 시나리오에 맞춘 코스메틱 이슈에 집중한 개발을 하기를 요구했습니다. 저는 이들이 회사와 원만한 관계를 유지하지 못해 나중에서야 중요 이벤트에 대한 정보를 얻었기 때문이라고 생각하지 않습니다. 이들은 회사와 충분히 원만한 관계를 유지하고 있기에 그 자리에 있을 수 있습니다. 그렇다면 이유는 하나 뿐입니다. 굳이 텍스트로 타이핑 하지는 않겠지만요.

어떤 기능은 개발하는데 한 마일스톤보다 더 긴 기간을 필요로 합니다. 우리들은 이미 완성하는데 1년 이상이 필요한 복잡한 소프트웨어를 개발하고 있기에 단위 기능의 개발에 한 마일스톤보다 더 긴 기간이 필요할 경우 이를 통제된 상태로 유지하고 개발을 진행해 나가기는 상당히 어렵습니다. 가령 어떤 게임에 길드 기능이 굉장히 중요해서 ‘길드’ 키워드 하위에 여러 가지 기능이 개발되어야 하며 이 기능 각각은 한 마일스톤 단위 계획에 포함할 수 있겠지만 길드의 전체 기능이 완성되는데 까지는 여러 마일스톤이 필요할 수 있습니다. 이 상황에서 종종 게임디자이너는 여러 마일스톤에 걸쳐 ‘길드 기획서’, ‘길드 기획서 (2)’, ‘길드 개선 기획서’, ‘길드 추가 기능 기획서’와 같이 같은 기능을 여러 마일스톤에 걸쳐 개발하는 것처럼 보이는 요구사항을 작성해 개발을 진행해 나가는데 큰 어려움을 겪곤 합니다. 이는 새로운 마일스톤을 시작하기 위해 요구사항을 검토할 때 ‘아니 길드를 언제까지 개발하는 거야?’ 같은 질문에 의해 쉽게 대미지를 입을 수 있습니다. 온전한 해법은 아니지만 이런 상황은 ‘길드 가입과 탈퇴', ‘길드마스터 기능’, ‘길드 출석 기능’, ‘길드전’과 같이 이들이 길드 기능의 하위에 속하기는 하지만 이들이 각기 다른 기능이라는 사실을 전달할 수 있는 모양으로 요구사항을 작성해 여러 마일스톤에 걸친 개발의 어려움을 완화할 수 있습니다. 하지만 여전히 여러 마일스톤에 걸친 단위 기능의 개발은 결코 쉽지 않습니다. 오죽하면 이전에 모셨던 한 피디님은 ‘한 달보다 더 오래 만든 기능은 다 망했어’라고 말씀하시며 한 달 안에 개발할 수 없는 기능의 개발 실행을 거절하시기도 했습니다. 이는 다른 문제를 만들기는 했지만 프로젝트에 결코 완성되지 않는 것처럼 보이는 기능이 함부로 통제 불가능한 상태에 노출되지 않도록 해 위험을 더 잘 관리하도록 한 것은 사실입니다.

한 마일스톤보다 더 오래 개발해야 할 것 같은 기능은 종종 ‘일단 돌아가게만’ 만들어 놓고 이어지는 마일스톤에서 외형을 다듬어 고객에 전달할 수 있는 수준에 도달할 수도 있습니다. 복잡한 기능이라면 한 마일스톤 안에 이 기능에 해당하는 동작을 전부 만들면서 동시에 고객에게 전달할 수 있을 만큼 인터페이스를 잘 가다듬고 임시 에셋이 없어야 하며 모든 데이터가 실제 사용 가능한 수준에 도달하기는 어렵습니다. 그래서 첫 마일스톤에는 동작에 필요한 최소한의 인터페이스와 최소한의 임시 에셋에 기반해 기능이 동작하게만 만든 다음 이를 바탕으로 다른 마일스톤에서 에셋을 가다듬고 데이터를 조정하고 의도와 어긋나게 개발된 부분에 대한 요구사항 변경을 거쳐 온전한 기능을 개발하게 됩니다. 이렇게 개발할 때 이 기능 기준의 첫 마일스톤이 끝난 다음의 기능은 동작하기는 하지만 높은 확률로 고위 임원이나 경영진에게 보고할 수 있지는 않을 겁니다. 실무자 출신의 경영진들은 자신들이 실무자 출신이기 때문에 개발 진행의 여러 가지 측면을 잘 이해할 수 있다고 말하곤 하지만 그 중 그 누구도 두 마일스톤에 걸쳐 개발할 기능이 첫 마일스톤이 끝난 다음 온갖 임시 에셋에 기반해 동작하는 모습을 보고 싶어 하지 않았습니다. 그들은 경영진이 된 다음부터는 그런 상태를 이해하지 못했고 우리들은 그런 사실을 잘 알기에 보고 직전에는 이런 기능을 아예 제거하거나 코스메틱 이슈의 우선순위를 최고로 올려 ‘보고 가능한 상태’를 만드는데 집중합니다.

이런 상황에서는 코스메틱 이슈 뿐 아니라 프로젝트의 진행 상황을 조금이라도 더 그럴싸한 모습으로 보고하기를 원하는 고위 의사결정자들의 예측 불가능한 요구사항이 마일스톤의 마지막 몇 주를 지배합니다. 앞서 두 마일스톤에 걸쳐 개발하기 위해 앞 마일스톤에는 간신히 기능이 동작하는 수준으로 만들어 놓고 이어지는 마일스톤에 에셋을 보강하고 데이터를 작성해 조립된 상태로 만들 계획이던 기능들은 계획에 없이 갑작스레 이번 마일스톤 안에 코스메틱 이슈를 모두 해결하고 데이터를 포함한 조립을 마쳐 보고 가능한 상태로 만들어야 하도록 바뀝니다. 그 누구도 이렇게 갑작스레 런칭 수준의 에셋을 이번 마일스톤 안에 제작해야 할 거라고 예상하지 않았습니다. 갑자기 그런 상황이 되었을 뿐입니다. 원래 다음 마일스톤에 이어서 진행하려던 계획은 완전히 붕괴되고 이번 마일스톤 안에 반드시 달성해야 하는 목표로 변합니다. 여러 부서는 게임디자인에 이를 실행하기 위한 문서를 내놓으라고 아우성 치고 게임디자인 역시 예상하지 못한 갑작스런 요구사항을 문서화하기 바쁩니다. 이런 문서가 잘 작성될 리 없고 적절한 고민이 빠진 채 그저 협업 부서들을 움직이도록 만드는데 집중한 문서들은 문단마다 삐걱거리는 소리로 가득합니다. 종종 문서에 기반해 오직 문서에 언급된 대로 행동하도록 훈련된 협업 부서들은 게임디자인 직군의 슬픈 점은 나머지 부서들과 목표가 다르다는데 있다에 소개한 프로젝트를 수행해 나가거나 이번 이벤트를 무사히 통과하기 위한 목표와는 다른 방향으로 행동하기도 합니다.

이럴 때 필요하다고 생각하는 것은 제목과 같은 ‘욕망의 절제’입니다. 앞서 고위 의사결정자들이 회사의 중요한 이벤트를 예측하지 못해 갑작스레 마일스톤 목표를 대규모로 수정하는 사례가 거의 항상 발생한다는 이야기를 했습니다. 이미 이 순간 마일스톤의 원래 목표와 고위 의사결정자가 생각하는 보고 가능한 빌드의 상태 사이에 커다란 차이가 발생하며 이 차이는 아직 고위 의사결정자의 머리 속에만 있을 뿐 제대로 설명되지 않았고 문서화 되지는 더더욱 않았습니다. 일단 코스메틱 이슈가 가장 높은 우선순위로 처리되는 가운데 고위 의사결정자의 머리 속에만 있던 결코 알 수 없는 보고 시나리오에 따라 마일스톤을 시작할 때 설정한 목표는 효력이 사라지고 그때그때 반사적으로 튀어나오는 요구사항에 아주 좁은 시야에 기반해 반사적으로 행동하는 모양으로 개발 스타일이 바뀝니다. 두 마일스톤에 걸쳐 개발할 작정으로 임시 에셋에 기반해 간신히 동작하는 모양으로 만들어진 기능은 마일스톤 마지막 며칠 사이에 코스메틱 이슈를 해결해 그럭저럭 멀쩡한 모양으로 바뀝니다. 하지만 분명 이번 마일스톤과 보고를 거치고 나면 우리들은 다시 이전에 수립한 계획에 따라 개발을 진행해 나가야 하고 이번 마일스톤 마지막 며칠 사이에 한 여러 반사적인 행동과 의사결정 때문에 이전의 계획과 완전히 틀어진 상태의 빌드를 마주하고 이 사이의 차이를 해결하는데 상당한 시간을 필요로 하게 됩니다. 이런 상황을 ‘똥 치우기’라고 표현하는데 이런 상황을 피하거나 최소화 하기 위한 사고 방식이 바로 ‘욕망의 절제’입니다. 물론 급한 마음을 이해합니다. 이번 보고에 따라 자신의 평가가 달라지고 이에 따라 자신의 목, 나아가 프로젝트의 존망이 위태로워질 수 있는 상황에서 뭐라도 해야 할 것 같은 패닉 상태를 이해합니다. 하지만 항상 이를 ‘패닉’에 기반해 겪어야 할지는 잘 모르겠습니다.

최대한 양보해 프로젝트의 고위 의사결정자가 회사와 의사소통을 통해 중요 이벤트의 존재를 예측해 이를 마일스톤 계획에 반영하는데 실패할 수도 있습니다. 사장님이 ‘다음 주에 진행상황을 한번 봅시다’라고 어느 날 갑자기 말할 수도 있으니까요. 또 이에 대응해 최대한 좋은 모습을 보여 자신의 모가지와 프로젝트 전체의 목숨줄을 유지해야 할 책임과 의무가 있음 역시 이해합니다. 하지만 여기에는 절제가 필요합니다. 코스메틱 이슈를 해결하는데 실패해 기능 전체를 제거하기로 결정한 기능에 많은 비용을 투입했다면 분명 투입된 비용에 비해 초라한 빌드를 보이게 될 겁니다. 아직 개발 중인 기능에 예정에 없던 코스메틱 이슈를 해결해 보고에 포함한다면 뭔가 조금이라도 더 많은 진행 상황을 보고할 수는 있겠지만 그 댓가로 개발비용은 극적으로 증가하고 프로젝트 구성원들은 마일스톤 계획을 신뢰하지 못하게 됩니다. 예정에 없는 수많은 코스메틱 이슈를 해결해 만들어진 빌드에 포함된 여러 보고 사항과 여러 가능성은 프로젝트 구성원들에게 그 댓가를 치르게 할만큼 그 하나하나가 중요할까요? 아마도 그만큼 중요할 겁니다. 헌데 그렇다면 우리들은 마일스톤을 시작할 때 이 사실을 알고 이 목표에 따른 개발을 할 수도 있지 않았을까요? 만약 여기에 실패했다면 이제 필요한 것은 욕망의 절제입니다. 빌드의 상태를 보고 뭐라도 그러모아 보고에 포함할 수 있을 것처럼 보이는 그 모든 것들의 멀쩡한 상태를 만들어 조금이라도 더 큰 가능성을 보이는데 집중하는 대신 단단한 계획과 현재 상황, 현재 상황 속에서 경영진들의 개발 중인 빌드에 대한 낮은 이해를 감안한 보고를 만들 수 있습니다. 여기에는 더 많은 코스메틱 이슈가 해결된 여러 가지 기능 대신 제대로 된 계획과 계획에 따라 개발 중인 빌드, 그 안에서 경영진의 낮은 이해도를 감안한 시연 가능한 기능들이면 적절합니다. 욕망을 절제한 그런 상태와 절제하지 못한 상태 사이에는 사실 별 차이가 없습니다. 그저 보고를 주고 받는 사람들의 자세에 차이를 만들 분입니다. 그 댓가로 프로젝트 전체에 큰 피해를 줄 만한 일이 아닙니다.

우리들은 근본적으로 회사를 포함한 스폰서의 지원에 기반해 상용 게임 소프트웨어를 개발합니다. 우리들이 이 일을 하며 생계를 이어 갈 수 있는 이유는 우리들이 만들어낸 소프트웨어가 그들이 기대하는 높은 수익을 만들어낼 수 있는 가능성이 있기 때문입니다. 여기에는 게임이 근본적으로 흥행 산업이라는 점과 소프트웨어 개발의 복잡성이 뒤섞인 상당한 위험을 수반한다는 사실이 포함됩니다. 그런 위험을 감수하고 우리들에게 돈을 내고 소프트웨어를 개발하게 하고 있는 스폰서들에게 우리는 우리들의 진행 상황을 더 그럴듯한 모양으로 보여야 할 책임이 있습니다. 하지만 이 과정이 스폰서들과 원만한 의사소통에 기반하지 않고 갑자기 나타나 결국 그럴싸한 빌드를 만들어내는 결과에 도달하기는 하겠지만 프로젝트에 큰 비용을 치르게 만든다면 눈앞의 예측 가능했을, 하지만 예측하지 못한 중요 이벤트를 무사히 지나더라도 근본적으로 스폰서에게 도 큰 비용을 치르게 만드는 셈입니다. 여기에는 스폰서와 의사소통을 통해 중요 이벤트 시점을 예측해 마일스톤 계획에 미리 반영하는 것이 중요하며 만약 여기에 실패했다면 온전한 계획에 기반한 욕망의 절제가 필요합니다. 그렇지 않으면 우리들은 스폰서에 대한 배임을 저지르는 것과 다름없습니다.