마일스톤 시작할 때 기획서가 완성되어 있으면 좋겠어요

지금까지 여러 프로젝트에 기획팀 입장으로 참여하면서 자주 들었던 주문 중 하나입니다. 마일스톤을 2개월 단위로 운영하는 프로젝트가 있다고 하겠습니다. 지난 마일스톤이 끝나고 이제 이번 마일스톤을 시작하는 첫 날이 되었습니다. 다행히도 이번 마일스톤은 마일스톤 시작 첫날 전에 이번 마일스톤의 목표가 합의되어 공유된 상태입니다. 마일스톤을 시작하자마자 일어날 일은 기획팀에서 이번 마일스톤 목표의 요구사항을 기획서에 작성하기 시작하는 겁니다. 이런 마일스톤 운영은 바쁜 팀에서 다른 팀이 불만을 가지게 만듭니다. 마일스톤 기간은 두 달이지만 실제로 기획서가 넘어가 일할 수 있게 되는 시점은 마일스톤 시작 시점으로부터 시일이 훨씬 지난 다음이고 두 달 중 실제 개발이나 에셋 제작에 사용할 수 있는 기간은 훨씬 짧기 때문입니다. 심지어 우선순위가 높고 규모가 큰 기능들은 마일스톤 시작과 함께 기획서 작성에 착수하지만 온갖 사람들의 피드백과 불확실한 요구사항 사이를 허우적거리다 보면 첫 달을 모두 소모한 다음에야 간신히 기획서가 넘어가는 일도 자주 일어납니다. 불만이 없을 수가 없어요.

기적적으로 기획서가 첫 두어 주 안에 작성되어 협업 부서에 전달되어 본격적인 개발을 시작하게 됐다고 가정하겠습니다. 여전히 마일스톤 기간 전차를 오롯이 개발에 사용할 수가 없는데 이유는 마일스톤 끝에는 마감이 기다리고 있기 때문입니다. 마감 이전에 개발을 마쳐 기능을 조립하고 테스트하고 컨텐츠를 입력해 실제 동작하게 할 시간이 필요하기 때문입니다. 프로젝트 관리를 꽤 오래 하셨다고 말씀하시는 분들도 이 기간을 과소평가하는 경우를 자주 겪었습니다. 심지어는 이 기간은 기본적인 기능 개발 단계까지 도달하는데 필요한 기간일 뿐이고 본격적인 컨텐츠 입력을 통한 게임화 과정은 다음 마일스톤으로 넘어갈 만한 규모일 때가 많은데 보통 이를 잘 고려하지 않습니다.

마감은 약 2주 정도 잡습니다. 마감 첫주에는 실제로 기능 개발을 마쳐 기능을 발주한 주체 - 보통 기획팀의 누군가 - 에게 돌아가 기능과 에셋을 조립해 이제 겨우 테스트할 수 있는 상태로 만듭니다. 마감 둘째 주에는 이 상태로 QA에 넘어가 본격적으로 통합 테스트를 합니다. 아직 제대로 된 게임화 작업이 일어나지도 않았지만 문제는 수두룩하고 아무리 초과근무를 해도 마일스톤 마지막날까지 만족할만한 빌드를 만들어내기 어렵습니다. 마일스톤 마지막 날은 항상 월 최대근무시간에 걸려 출근하지 못한 사람들과 이 사람들에게 가야 할 이슈를 대신 처리하는 사람들의 허둥댐으로 가득합니다. 이제 토요일과 일요일이 지나고 월요일이 찾아오면 다시 다음 두 달 짜리 마일스톤의 첫날이 시작됩니다.

다시 원래 하려던 이야기로 돌아가 보겠습니다. 마일스톤 시작할 때 기획서가 완성되어 있으면 좋겠습니다. 기획자인 제가 생각해도 그러면 참 좋겠습니다. 마일스톤 시작하자마자 기획서를 협업부서에 리뷰하고 바로 개발을 시작하면 기획자 입장에서도 너무 좋습니다. 마일스톤 시작하자마자 바로 개발대응으로 넘어갈 수 있고 이전보다 훨씬 더 이른 시점에 개발이 진행되어 기능을 조립해볼 수 있을 뿐 아니라 더 이른 시점에 QA를 진행해 시간에 쫓기지 않아 기본 기능 뿐 아니라 이게 실제로 재미있긴 한지 의견을 들어볼 수 있을 뿐 아니라 운이 좋다면 실제 컨텐츠로 구성해 게임화하는 단계에까지 도달할 수 있을지도 모릅니다. 그러면 게임화 과정이 다음 마일스톤으로 넘어갈 필요도 적어지고 프로젝트 매니저의 ‘아니 이건 지난 마일스톤에 개발 끝난 거 아닌가요? 왜 이번 마일스톤에 또 진행하나요?’ 같은 질문에 답하거나 다음 마일스톤 계획에 ‘길드 2차’, ‘길드 3차’, ‘길드 4차’, ‘길드 추가개발’ 같은 멍청한 목표 이름을 넣지 않아도 될 겁니다.

악순환이 반복되는 원인을 크게 세 가지로 봅니다. 첫째. 폭포수 개발 관점에서 기획서 작성이 끝나면 기획팀이 할일이 끝났다고 보기 때문입니다. 실제로는 그렇지 않습니다. 기획서 리뷰가 끝나면 협업부서들의 피드백을 받아 수정하기 시작하고 협업부서들은 본격적으로 설계에 착수합니다. 여전히 문서를 수정하고 있고 협업부서들의 개발 진행에도 대응해야 합니다. 하루에 여러 차례 질의응답을 하고 테스트데이터를 만들고 그날그날의 개발 진척에 따라 단위테스트를 하는 등 여전히 할 일이 있습니다. 저는 이 단계를 ‘개발대응’이라고 불렀는데 이 개발대응이 실제로 기획팀의 자원을 소모하는 일임을 매니저에게 설득하기 굉장히 어려웠습니다. ‘아니 기획서 넘어가면 바로 다음 기획서 써야 하는 거 아니예요?’ 라는 말을 눈앞에서 육성으로 여러 번 듣고 나면 남은 수명만큼 세상을 살 의지가 꺾이곤 합니다. 이 작업이 실제로 프로그래머가 1근무일을 사용할 때 기획자는 최소한 0.2근무일은 사용한다고 측정, 증명해서 주장해도 잘 먹히지 않을 정도였습니다. 자. 이러는 사이에 일정표에 오늘 리뷰 끝나면 당장 내일부터 작성을 시작하는 걸로 계획된 다음 기획서 작성이 밀리기 시작했습니다.

둘째. 개발 후반 작업을 무시하기 때문입니다. 에셋이 준비되고 개발이 진행되어 테스트 가능하다는 상태로 기획자에게 작업이 넘어왔습니다. 높은 확률로 실제 빌드에서 테스트 가능하지 않은데 담당자가 자기 자리에서는 동작을 확인했겠지만 커밋 할 때마다 통합이 일어나는 환경에서 정상 동작하는지는 테스트하지 않기 때문입니다. 퍼포스 단일 스트림 환경에서는 서브밋 하고 CI에 의해 빌드가 돌고 나면 원하든 원하지 않든 이미 이 기능은 전체 빌드에 통합되어 있습니다. 이 상태에서도 과연 기능이 정상 동작할까요? 높은 확률로 그렇지 않습니다. 기획자에게 넘어온 작업을 테스트하기 위해 업데이트 받은 다음 첫 단위 테스트에서 바로 실패합니다. 안되는데요? 이렇게 일을 주고받는 사이에 반나절이 사라집니다. 자. 어떻게든 해서 간신히 동작하는 빌드가 기획자 손에 도착했지만 이제 마감에 맞춘 최소한으로 말이 되는 상태롤 만드는데 시간을 쓰기 시작합니다. 이 작업 역시 만만치 않은데 기획자에게 넘어온 동작은 하는 수준의 원시 기능은 기획자가 데이터를 입력해 구동해 봄에 따라 기초적인 문제들을 해결해야 하기 때문입니다. 컨텐츠를 조립하고 데이터를 입력해 나가며 차근차근 문제를 해결하는 사이에 며칠이 순식간에 지나갑니다.

셋째. 여러 작업자들이 멀티태스킹 환경에 놓여있다는 점을 무시합니다. 기획서 작성을 마치고 리뷰 대기 중인 기획자 입장으로 잠깐 돌아가 봅시다. 다른 일정, 휴가자 고려, 회의실 섭외 등의 문제를 해결하다 보면 리뷰 일정이 늦어집니다. 그러는 사이에 다음 기획서 작성으로 넘어갑니다. 사람의 주의력과 기억력은 한계가 있어 다른 주제로 넘어간 다음에는 다시 이전 주제로 돌아오는데 어려움이 있습니다. 이번 주 수요일에 작성한 기획서 리뷰가 다음 화요일 오전에 잡혔군요. 그 사이에 다른 기획서를 쓰다가 화요일 아침에 출근해서 리뷰할 문서를 보니 무슨 소린지 모르겠습니다. 오늘 리뷰를 순조롭게 진행하기는 쉽지 않을 것 같습니다. 위에서 이야기한 개발대응 이슈도 있습니다. 기획서를 쓰고, 다음 기획서를 쓰기로 예정된 시간에 개발대응을 합니다. 기획서 일정이 늦어지고 세상 평화로운 매니저는 왜 기획서 작성 일정이 늦어지는지 물어보러 옵니다. 협업부서에도 똑같은 일이 일어나고 있습니다. 통합테스트를 하기 전 상태를 급하게 기획팀에 돌려보낸 프로그래머는 바로 다음 작업을 시작합니다. 몇 시간 뒤 기획자가 아예 기능이 동작하지 않는다고 보고하지만 단일 스트림 환경에서 이미 다른 작업을 시작한 다음이라 수정하기가 까다롭습니다. 내일 고치겠다고 말하고 작업을 계속합니다.

주제와 상관 없어 보이는 이야기를 하며 멀리 돌아왔습니다. 기획팀 입장에서도 마일스톤을 시작할 때 기획서가 준비되어 있으면 좋겠습니다. 그럼 바로 개발대응으로 넘어가거나 이전 마일스톤에서 간신히 기본 기능만 만드는데 성공한 원시 기능들을 게임화하는데 시간을 쓸 수 있게 됩니다. 하지만 현실은 기획팀을 포함한 모든 부서가 소프트웨어 개발과정에 대한 몰이해, 실제 비용이 드는 작업 무시, 멀티태스킹 환경 미 고려 같은 문제로 이전 마일스톤이 끝날 때까지 다음 마일스톤 기획서는 고사하고 다음 마일스톤 목표가 뭔지에도 관심을 두기 어려운 환경에서 이 요구사항을 달성하기는 쉽지 않아 보입니다.