다음 마일스톤 기획서를 미리 쓰는 계획은 왜 항상 실패할까

여느 흔한, 하지만 훌륭하지는 않은 프로젝트가 마일스톤 계획을 수립하는 광경을 상상해 봅시다. 운이 좋다면 현재 빌드의 상태와 마일스톤이 끝날 때 기대하는 빌드의 상태를 비교해 이들 사이의 차이를 기능으로 정의하고 동시에 마일스톤이 끝날 때 기대하는 빌드의 상태를 런칭과 서비스에 이르는 긴 맥락 속에서 설명하는 계획을 수립할 수도 있습니다.

하지만 운이 좋지 않거나 평범한 운을 가지고 있다면 마일스톤 계획은 그저 맥락 없이 언젠가는 런칭과 서비스 단계에 도달하기는 하겠지만 그 과정 중 어디 쯤에 우리가 위치하고 있는지에 관계 없이, 또한 우리 팀의 퍼포먼스에 관계 없이 그저 기간 안에 개발해야 하는 기능의 나열일 뿐일 가능성이 더 높습니다. 어떤 과정을 거치든 마일스톤 계획은 제한된 기간 안에 개발해야 하는 여러 기능의 목록의 집합에 가까운 모양이고 계획이 수립된 다음에는 이 계획에 동의하든 동의하지 않든 회사에 소속된 이상 이 계획에 따라 행동할 수밖에 없는 상태가 될 겁니다.

한편 프로젝트를 구성하는 각 팀은 그 팀에 붙여진 이름과 원래 그 팀에 의도한 역할 외에도 상황에 따라 다양한 역할을 하기도 하는데 가령 마일스톤 계획에 따라 기능을 정의하는 문서를 쓰던 사람들은 시간이 지나면 개발된 기능과 에셋을 조립해 실제 동작하는 빌드를 만드는데 기여하고 나아가 개발된 기능을 테스트하며 기능이 게임 안에서 올바르게 동작하는 상태로 튜닝하는 역할을 담당하기도 합니다. 또 주로 코드를 작성해 기능을 만드는 역할을 하는 사람들은 종종 개발 인프라를 정의하고 유지보수하는 역할을 겸하기도 하며 종종 중요한 일정이 있을 때 즉시 해결하거나 우회해야 하는 기술적인 문제에 대응하기 위해 대기하고 있기도 하고요.

마일스톤 계획은 이런 각 부서에 명시적으로 정의된 역할에 집중해 퍼포먼스를 예상하기 때문에 꽤 자주 실제 팀이 낼 수 있는 퍼포먼스보다 더 많은 목표를 포함하게 됩니다. 가장 큰 이유는 방금 말한 명시적인 역할이 그 부서의 전체 역할이라고 쉽게 생각하기 때문입니다.

지금까지는 약간 추상적인 표현을 사용해 말하려는 주제 주변을 빙빙 돌고 있었는데 이제부터는 추상적인 단어를 줄이고 실제 사례를 가지고 표면적인 역할에 집중해 수립한 마일스톤 계획이 항상 실패하는 이유를 ‘다음 마일스톤 기획서를 미리 쓰려는 계획이 항상 실패하는 이유’를 설명하겠습니다.

전통적인 폭포수 모델에서 한 가지 기능을 개발하기 위해 각 팀은 이전 작업자로부터 전달 받은 작업물에 이어 내가 담당한 작업을 수행하고 다음 사람에게 넘기기를 반복하기만 하면 됩니다. 가령 게임에 ‘한계돌파’라는 성장 규칙을 새로 설정해 구현해야 하는 상황이라고 합시다. 이전 까지는 캐릭터 레벨을 30 까지만 올릴 수 있었는데 레벨 30에 도달한 캐릭터가 정해진 자원과 시간을 투입하면 캐릭터 레벨을 50까지 올릴 수 있는 상태가 되고 이를 한계돌파라고 부르기로 했습니다. 전체 개발 맥락 상 고객들이 캐릭터를 성장 시켜 일정 기간이 지나면 만렙에 도달할 예정이기 때문에 그 이후에도 고객들이 지속적으로 게임에 돌아오게 만들기 위해서는 기존 성장 규칙의 한계를 넘는 메커닉이 필요했고 그저 만렙을 확장하기 보다는 만렙 확장에 의미 있고 또 명시적인 단계를 두는 편이 더 좋겠다고 판단했기 때문에 한계돌파를 추가하기로 했습니다.

이번 마일스톤에 한계돌파 기능을 추가하기로 결정하고 마일스톤이 시작되면 먼저 기획팀의 누군가가 이 일을 담당해 한계돌파 기획서를 작성하기 시작합니다. 미리 한계돌파 기능의 맥락과 대략적인 의도, 형태를 컨셉의 형태로 전달 받았을 가능성이 높으니 여기에 기반해 기획서를 작성하며 한계돌파 기능이 현재 빌드에 투입되었을 때 필요한 기능을 정의하는데 집중해 기획서를 작성합니다. 기획서는 팀 내 리뷰 및 협업 부서 리뷰를 거친 다음 다른 부서 담당자들에게 전달되어 개발되기 시작하는데 이론적으로 이 기능의 담당 기획자는 기획서를 작성해 협업 부서에 전달했으므로 이 마일스톤 안에 더 이상 한계돌파 관련 업무를 담당하지 않게 됩니다.

이런 관점에서 마일스톤 계획을 수립할 때 기획서 작성이 끝나면 이 담당자는 유휴 상태가 되니 마일스톤 계획에 포함된 기능 중 다른 기능을 담당하게 할 수 있을 것 같아 보입니다. 그러면 이 담당자는 이번 마일스톤에서 한계돌파 기능과 또 다른 기능, 그리고 평소에 이 정도 규모 기획서를 작성하는 퍼포먼스를 고려할 때 다른 기능 한 가지를 더 담당할 여유가 있을 것으로 예상할 수 있습니다. 그런데 곰곰이 생각해보니 다음 마일스톤에는 규모가 더 큰 기능을 개발해야 할 것 같은데 이 기능은 당장 기획서 작성에도 시간이 꽤 걸릴 것 같아 다음 마일스톤을 시작한 다음에 기획서를 쓰기 시작하면 다음 마일스톤 기간 안에 개발을 마무리하기 어려울 것 같습니다. 그래서 한계돌파 기획서를 작성한 다음 이 인력이 유휴 상태가 될 때 다음 마일스톤에 필요한 기능의 기획서를 미리 작성하도록 하기로 결정합니다.

제목에서 이미 내용을 스포일링 했지만 이런 계획은 대부분 실패하거나 가끔 성공하더라도 정상적인 방법 보다는 개개인의 초과근무를 통해 성공했을 겁니다. 성공했더라도 지속 가능한 성공이 아니며 이를 성공이라고 평가할 수 있는지도 의문입니다.

일단 기획서가 협업 부서에 전달되어 개발이 시작된 다음에도 기획서를 작성한 담당자의 한계돌파 기능에 대한 업무 부하는 완전히 사라지지 않습니다. 우리들이 완전한 명세에 기반해 작업한다고 알려진 SI 업계처럼 일한다면 기획서 작성 완료 후 관련 업무 부하가 완전히 사라질 거라고 예상할 수도 있겠지만 게임 업계에서는 그들처럼 완전한 명세에 기반해 개발을 시작하지 않습니다.

기획서는 마일스톤 계획을 수립할 시점에 작성한 컨셉과 비교해서는 좀 더 실제 빌드에 가까운 동작을 포함하고 있겠지만 여전히 불완전하며 실제로 기능을 개발해 감에 따라 예상하지 못한 추가 요구사항, 기존 기능과 통합하며 발생하는 문제, 기능이 동작하기 시작한 다음에는 기존 게임의 다른 기능과 상호작용하며 발생하는 문제가 다양하게 발생해 흔히 기획서라고 부르는 요구사항 명세가 지속적으로 변경되어야 합니다. 그리고 요구사항의 지속적인 변경은 달리 말해 기획서를 수정하고 수정된 요구사항을 다시 협업 부서에 전달하며 때에 따라서는 기획서를 처음 작성해 협업 부서가 모두 모여 진행했던 것과 비슷한 규모의 리뷰 단계를 마일스톤 진행 도중에 반복해야 할 수도 있습니다.

또한 처음에 설명한 한 부서가 명시적인 업무 외에도 묵시적인 업무를 수행해야 하기 때문에 기획팀이 기획서 작성 이외에도 다른 일에 시간을 사용하게 되는데 대표적으로 개발이 진행되고 나면 이들을 조립해 빌드 상에서 동작하는 형태를 만드는 일이 있습니다. 흔히 조립이라고 부르며 여기서는 묵시적이라고 했지만 사실상 기획팀에서 수행해야 하는 명시적인 업무에 가깝습니다. 묵시적이라고 표현한 이유는 이전에 참여했던 어떤 프로젝트에서는 기획팀의 이 조립 과정에 소요되는 비용을 인정하지 않는 관리자와 긴 기간에 걸쳐 대립했었기 때문입니다.

협업 부서로부터 개발되어 다시 기획자에게 돌아온 빌드는 테스트 데이터와 테스트 에셋에 기반해 요구사항 각각을 간신히 만족하는 상태인데 이제부터 실제 데이터와 실제 에셋을 사용해 데이터에 기반해 기능을 조립해 실제 게임 상에서 동작하는 수준으로 동작 수준을 끌어 올려야 합니다. 이 때도 한 번 개발되어 기획자에게 돌아왔다 하더라도 여전히 기능은 오동작 할 수 있으며 테스트데이터에 기반해서는 잘 동작했지만 실제 데이터를 적용하자마자 바로 완전히 오동작하거나 동작하지 않을 수도 있으며 실제 데이터는 엔지니어가 의도하지 않은 모양의 데이터여서 꽤 큰 추가 개발이 필요함을 늦게서야 발견할 수도 있습니다. 그래서 이 조립 및 추가 개발에 대응하는데 뚜렷한 비용이 필요합니다.

이제 제목으로 돌아가 왜 이번 마일스톤 기획서 작성을 마치고 느긋하게 다음 마일스톤 기획서를 준비하는 계획이 ‘항상’ 실패하는지 설명하겠습니다. 프로젝트에 소속된 모든 사람들은 자신의 명시적인 업무 이외에도 개발을 완수하기 위한 묵시적인 업무를 수행하고 있으며 명시적이든 묵시적이든 반드시 시간으로 환산할 수 있는 비용을 필요로 합니다. 또한 각 작업자들은 한 가지 기능을 개발할 때 개발의 각 단계에 여러 번 관여하게 되어 기획서를 작성하면 이 기능에 대한 모든 업무가 끝났다고 가정할 수 없습니다. 기획서를 작성하고 개발을 지원하고 조립하고 조립 과정에서 일어난 문제해결을 하고 문제해결 과정에 추가 개발이나 추가 에셋 제작이 일어나는 등 한 가지 기능 개발은 마일스톤 기간 전체에 걸쳐 조금씩 계속해서 비용을 발생 시킵니다.

이런 상황에서 한 마일스톤에 여러 가지 기능을 담당한 사람들은 각 작업 사이에 빈 공간을 최대한 활용해 작업 전환을 반복해 가며 여러 기능을 담당하게 되는데 다음 마일스톤 기획서는 이런 작업들과 비교해 상대적으로 우선순위가 낮을 뿐 아니라 이번 마일스톤이 종료될 때 평가되지 않고 또 평가할 수도 없는 작업 전환 비용이 가장 높은 업무이기까지 합니다. 그래서 낮은 우선순위로 기획서를 작성할 시간을 확보하기 어려울 뿐 아니라 이번 마일스톤에 해당하는 다른 업무와 함께 진행할 때 높은 작업 전환 비용으로 쉽게 기획서 작성을 시작할 수도 없습니다. 그래서 이번 마일스톤 계획을 세울 때 유휴 인력에게 다음 마일스톤을 준비하게 하는 계획은 ‘항상’ 실패합니다.

결론. 프로젝트에 포함된 여러 작업자들은 자신의 명시적인 업무 뿐 아니라 묵시적인 업무를 함께 수행하고 있습니다. 각 작업자는 한 가지 기능 개발 과정에 서로 다른 시점에 걸쳐 여러 번 개입해야 하며 이 과정에서 작업 전환이 여러 번 일어나게 됩니다. 다음 마일스톤 계획은 항상 이번 마일스톤 계획에 비해 우선순위가 낮으며 특히 다음 마일스톤 기획서 작성 업무는 작업 전환 비용이 높아 이번 마일스톤에 동시 진행하기 아주 어렵습니다.