마일스톤 중간 점검. 제한시간 안에 서비스 할 수 있을까?

얼마 전에 다른 프로젝트에서 일하시는 지인 분들을 만나 회사 카드로 먹을 수 있는 소고기를 먹다가 지금 저희는 마일스톤을 4개월 단위로 하고 있다는 이야기를 했습니다. 4개월 단위 마일스톤은 사실 처음 경험해 보는데 분기 단위의 보고에 맞춰 3개월로 하거나 모바일에서는 2개월 단위로 개발했습니다. 2개월 단위 마일스톤은 상당히 고통스러웠는데 그럼에도 여러 가지 필요로 1개월 짜리 마일스톤을 진지하게 고민한 적이 있지만 아무래도 그건 팀이 버틸 수 없을 것 같아 실행하지는 않았습니다. 사실 2개월 짜리 마일스톤에 익숙해진 채로 4개월 짜리 마일스톤을 마주하니 처음엔 좀 무서웠습니다. 기간이 긴 만큼 평화로운 상황에서 종종 일어나는 악의적이지는 않은 비효율 방치가 일어날 수 있을 거라고 예상했기 때문입니다.

서로 4개월 짜리 마일스톤은 처음 본다며 신기해 하다가 우리가 한 마일스톤을 4개월로 잡게 된 이유를 설명하다 보니 4개월이 아니면 이전에 다른 모바일 프로젝트에서 검토한 적 있는 1개월 마일스톤처럼 팀이 버틸 수 없을 지도 모른다는 생각이 들었습니다. 우리가 다른 프로젝트와 크게 다르지 않지만 이전에 참여했던 다른 프로젝트와 비교할 만한 점은 마일스톤이 끝날 때마다 짧게 나마 NFT 홀더들, 그리고 커뮤니티 구성원들을 대상으로 짧게라도 서비스를 해야 한다는 점입니다. 지난 첫 홀더 테스트를 마쳤습니다 (1), 첫 홀더 테스트를 마쳤습니다 (2)에서 했던 그런 이름은 테스트이고 실제 속성은 짧은 라이브 서비스에 가까운 행동을 마일스톤 마다 해야 하는 상황인데 만약 마일스톤을 3개월로 진행한다면 서비스를 준비할 시간이 부족할 가능성이 높습니다. 한참 전에 이런 마일스톤 단위를 협의할 때 이전에 다른 팀을 경험하지 않지는 않았을 누군가가 ‘마일스톤 끝날 때 그냥 그 상태를 공개하면 되는 것 아닌가?’ 라고 말하는 것을 듣고 흡연을 하지 않아 다행이라고 생각한 적이 있는데 만약 흡연을 했다면 가까이 있던 재떨이를 집어 던졌을 것 같았기 때문입니다.

개발과 서비스에 필요한 여러 기능을 인하우스에 수직 계열화 한 조직이라면 이런 계획이 효율적으로 잘 동작할 가능성이 상대적으로 높습니다. 가령 현대에 여러 프로젝트에서 인하우스에 잘 두지 않으려고 하는 사운드 조직을 수직 계열화 했다면 마일스톤 중후반에 가서야 외부 업체에 사운드 제작을 요청하고 막판에 이를 정신 없이 그저 게임에 붙이는데 집중하지 않아도 되고 테스트 조직을 수직 계열화 하고 있다면 이 조직이 마일스톤 목표에 대한 이해를 높여 기계가 해도 되는 기계적인 테스트에 시간을 덜 들이고 의미 있는 목표에 대한 테스트에 집중할 수도 있습니다. 프로젝트 관리 조직이 수직 계열화 되어 있다면 이들이 주요 기능의 개발 진척을 모니터링하고 각 기능 별 위험성, 각 기능 중 하나 이상이 제한시간 안에 개발에 실패하는 상황에 대처할 계획을 미리 수립해 실패 상황에 허둥대지 않을 수 있습니다. 그런데 자원이 적은 조직은 표면적으로 여러 기능을 인하우스에 수직 계열화 한 것처럼 행동하지만 실제로는 그냥 같은 사람이 여러 기능으로 동작하기를 ‘기도’하는 경우가 많은데 현재 저희가 그런 상황에 가깝습니다.

표면적으로 인하우스에 수직 계열화된 다양한 기능이 함께 동작하며 개발이 진행되는 것처럼 보이지만 이제는 사람이 수행하는 멀티태스킹이 허상이라는 과학적인 사실이 널리 알려진 마당에 실제로는 그저 각자가 맡은 여러 가지 일이 프로젝트 진행 시점에 따라 선형으로 수행될 뿐입니다. 그래서 마일스톤이 시작되면 그제서야 게임디자인이 이번 마일스톤의 목표에 따라 플레이 시나리오를 설계하고 시나리오에 따라 기능을 분리해 마일스톤의 세부 목표를 설정하며 각각을 설계한 기획서를 작성하고 이를 협업 부서에 브리핑 하는 과정을 거친 다음에야 본격적으로 협업 부서들에 의한 개발을 시작할 수 있습니다. 마일스톤 시작부터 마일스톤에 해당하는 모든 목표에 대한 브리핑을 마칠 때 까지는 보통 한 달 이상이 소요되는데 그 안에도 먼저 준비되는 기능은 먼저 브리핑을 하고 먼저 개발을 시작하기 때문에 마일스톤 앞부분의 기간을 게임디자인에서 완전히 블로킹 하는 상태는 아닙니다. 하지만 나머지 부서들이 지속 가능한 최대 출력으로 개발을 수행하기에는 계획이 부족하고 또 모든 목표가 우선순위에 따라, 또 작업 분량에 따른 순서에 맞춰 나오지 않으므로 나중에 수행한 브리핑 결과에 따라 이전에 수립한 계획을 수정할 일이 자주 일어납니다.

이런 상황은 규모가 큰 조직이 아닌 이상 종종 겪을 수밖에 없기 때문에 다들 게임디자인에서 마일스톤 목표를 개발 가능한 목표로 재해석 하는 동안 아무 것도 안 하고 있지는 않습니다. 가령 엔지니어 조직에서는 이전 마일스톤 막바지에 급하게 개발한 기능을 개발을 지속 가능한 모양으로 수정하기도 하고 이전 마일스톤에 완전히 해결하지 못한 잔여 결함을 수정하기도 합니다. 또 아트 조직에서는 마일스톤 진행과 별개로 제작 기간이 긴 에셋을 미리 제작하고 엔지니어 조직과 비슷하게 이전 마일스톤 후반에 급하게 제작한 에셋의 최적화 작업을 수행하기도 하고요. 그러는 사이에 게임디자인에서 마일스톤 목표를 개발 가능한 단위로 나눠 기획서를 작성해 브리핑 할 준비를 마치면 그때서야 이번 마일스톤 개발이 시작된다고 볼 수 있습니다. 이 과정이 모두 완료되는데 앞에서 말한 대로 한 달 이상이 걸리고 뒤쪽에 진행한 브리핑에 의해 이전 계획이 수정되며 어느 정도 비효율이 일어납니다.

만약 프로젝트에 필요한 여러 기능들이 다양한 인력에 의해 수직 계열화 된 조직이라면 이제부터 게임디자인은 개발 진행에 대응하며 문제를 해결하고 이번 마일스톤에 해당하는 플레이를 조립할 준비, 다음 마일스톤 목표 준비, 리서치 따위를 수행할 시간을 확보해 다음 마일스톤 때 비슷한 일을 수행할 시간을 조금이라도 줄이고 잘못된 의사결정 가능성 역시 조금이라도 줄일 수 있습니다. 그런데 표면적으로는 프로젝트 안에 다양한 기능을 수직 계열화 한 것 같지만 실제로는 그저 같은 사람에게 여러 가지 일을 맡긴 조직에서는 모든 일이 선형으로 진행되므로 게임디자인에서 이런 시간을 확보할 수 없습니다. 같은 사람이 규모가 큰 태스크 여러 개를 담당해 하루에도 여러 협업자 그룹과 서로 다른 주제에 대한 개발 대응을 해야 하고 개발 진행상황을 관리해야 하며 서로 의사소통 하지 않아 작업이 완료되었음에도 지연되는 작업을 찾아내 사람들을 연결 시키고 그러는 중간중간에 근미래에 일어날 기능 조립, 테스트, 그리고 실제 플레이를 의도에 맞춰 만들어낼 준비, 서비스 대응 준비 따위를 수행해야 합니다.

이런 상황에서 마일스톤 중반에 가장 중요한 일은 마일스톤 목표를 달성하는데 필요한 여러 기능 각각이 빠짐 없이 진행 되고 있는지 파악하는 것입니다. 분명 잘 갖춰진 조직에서는 이런 일을 전담하는 사람들이 있을 겁니다. 그렇지 않은 조직에서는 이 일을 각 기능의 게임디자인 담당자가 ‘동시에’ 수행하는데 여러 협업 부서 대신 게임디자인에서 이를 수행하게 되는 이유는 ‘그나마’ 다른 부서들에 비해 시야가 좁지는 않은 편일 가능성이 있기 때문입니다. 가령 엔지니어 조직에서 간신히 테스트 데이터에 의한 한 가지 시나리오를 만족하는 상태를 전달 받으면 실제 사용할 데이터와 아트 에셋을 포함해 조립하며 일어나는 온갖 문제를 겪으며 이를 협업 부서와 함께 해결해야 하는데 이 과정을 반복할수록 프로젝트 전체를 보는 시야가 넓어지는 것은 사실입니다. 하지만 다양한 경험을 가진 사람들이 모인 조직에서 모두에게 이 같은 기능을 요구하기도 쉽지 않아 결국 이런 일이 필요함을 이해하는 사람이 여러 기능에 걸친 개발 관리를 함께 맡을 수밖에 없습니다.

지난 주에는 마일스톤 기간의 절반이 지난 상태에서 전체 진행상황을 점검했습니다. 모든 일이 올바르게 진행되고 있는지 파악하는데는 여러 가지 방법이 있을 겁니다. 이전에 경험한 관리 부서는 거대한 간트 차트를 만들어 높은 분들의 답변이 불가능한 질문에 술술 답하기도 하고 또 어떤 관리 부서는 모든 작업에 정확한 완료 일정을 예측해 지라에 기입하기를 요구하기도 해서 개발팀과 상당한 신경전을 일으키기도 했습니다. 개인적으로 선호하는 점검 방식은 먼저 이번 마일스톤의 목표와 목표가 모두 달성 되었을 때 고객이 실제로 겪을 플레이를 머릿속에 온전히 그리는 것입니다. 플레이 시나리오가 문서 모양으로 존재한다 하더라도 이를 글자로 읽는 것과 실제 동작하는 이미지를 떠올릴 수 있는 상태는 서로 완전히 다르다고 생각하는데 글자로 전달된 목표를 달성하는데 비해 실제 동작하는 이미지에 기반한 목표 달성은 달성 수준이 훨씬 높기 때문입니다.

그렇게 마일스톤 목표에 해당하는 전체 플레이의 구체적인 플레이 시나리오를 그린 다음 이에 기반해 모든 할일이 지라에 근거해 진행되고 있는지 확인해야 합니다. 사실 이슈트래커를 사용한 지 오랜 세월이 흐르고 또 이런 도구의 도움 없이는 사실상 개발이 불가능함을 없는 생활에 설명한 적이 있는데 그럼에도 여전히 이슈트래커에 기반하지 않은 모양으로 무심코 작업을 진행하는 사례가 있습니다. 예전에는 개인적으로 이런 분들은 업무를 하고는 있지만 팀에 필요 없는 관리 요구를 발생 시켜 장기적으로는 함께 해서는 안된다고 생각했지만 요즘에는 찬 밥 더운 밥 가리다가는 개발을 못 할 거라는 쪽으로 생각을 바꿨습니다. 그래서 이슈트래커에 기반해 진행을 파악할 수 있는 범위에서 먼저 진행상황을 파악한 다음 이슈트래커로 파악되지 않는 범위를 파악한 다음 이를 이슈트래커에 다시 남겨 놓고 이들을 모아 마치 작업 전체가 이슈트래커에 기반해 진행되는 것 같은 모양을 만듭니다. 이제 마지막으로 이슈트래커에 근거해 진행 상황을 파악하고 공유할 수 있는 상태가 됩니다.

물론 이슈트래커에 신경 쓰지 않는 분들은 여전히 자신에게 할당된 태스크가 있든 말든 상급자의 구두 지시 이외에는 신경 쓰지 않겠지만 개발의 어느 시점에는 모두가 공유하는 이슈트래커에 기반해 실제 상태를 업데이트 해야 한다고 생각합니다. 이슈트래커를 사용하지 않는 사람을 강제로 사용하게 만들 수 없다고 해서 이슈트래커를 그저 확실하지 않은 정보의 원천으로 치부해 버리면 이제 프로젝트 전체에 현재 상태를 파악하는 방법은 모든 사람들에게 현재 상태를 물어보고 다니는 방법 밖에 없기 때문입니다.

자. 설명이 길었는데 이번 주에는 이번 마일스톤을 시작하고 여러 번째 지금까지 설명한 작업을 수행했는데 이번에도 같은 작업을 한 다음 마일스톤이 끝날 때 우리가 만들어 내야 하는 플레이와 현재 빌드의 상태, 그리고 사람들을 쫓아다니며 파악한 현재 개발 상황 사이에 간극이 좀 있다는 딱히 새롭지는 않은 상황을 마주하게 되었습니다. 사실 모든 협업 부서의 미래 개발 진척을 온전히 예상할 수는 없지만 지금까지 참여해 온 다른 프로젝트의 상황과 비교할 때 이번 마일스톤 역시 마일스톤 막바지에는 서비스 준비, 결함 수정, 조립, 테스트가 동시에, 그리고 각 사람들 관점에서는 선형으로 일어나며 전체적으로는 아수라장이 될 것 같아 보입니다. 가령 결함이 수정되어 이전에 조립한 컨텐츠가 전부 못쓰게 될 수 있고 이미 테스트가 끝난 컨텐츠의 조립이 다시 일어날 수 있으며 늦게 요청하고 늦게 도착한 사운드를 넣으며 새로운 결함이 발생하고 이 난리 속에서도 경험을 다듬으려는 사람들이 서로 동시에 빌드를 고치며 아주 난도질을 하게 될 겁니다.

이런 상황을 예상하다 보니 어느 프로젝트에서나 이런 상황이 일어나기는 하지만 이번에는 아주 진한 경험을 하게 될 것 같아 미리 부터 마음이 편안하지 않은 상태가 되고 말았습니다. 아직 일어나지 않은 일을 미리부터 걱정하는 행동은 머릿속 자원을 낭비하고 현재에 집중해 최선의 결과를 이끌어내는데 방해가 된다는 말을 들었지만 마치 목성에 충돌하는 결과를 피할 수 없는 것처럼 고개를 돌려 외면할 수는 없어 보입니다. 분명 이번 마일스톤도 막바지에 분명 난리를 겪을 것 같으며 그 난리를 겪고서도 일정을 맞출 수 있을지 잘 모르겠습니다. 난리를 겪을 몇 주 전부터 이미 걱정을 시작해 마음이 아주 불편해졌습니다. :)