최저 가치 단계의 모니터링

하이 아웃풋 매니지먼트는 무척 오래 된 이야기이지만 현대에도 여러 관리 관점을 가질 수 있게 해 줍니다. 문제 상황을 마주할 때 이 책에서 말하는 여러 관점을 하나 씩 적용해 볼 만 하지만 그 중 개인적인 경험과 연결되어 기억에 더 잘 남은 것은 최저 가치 단계의 모니터링이라는 개념이었습니다. 이전의 몇몇 개발 경험이 왜 그토록 고통스러웠으며 같은 결과를 내기 위해 왜 그렇게 많은 비용이 필요했는지 어렴풋이나마 추측할 수 있었습니다. 사실 이 개념이 완성된 제품의 형태를 상상하기 쉽지 않은 엔터테인먼트 개발에 동일하게 적용할 수 있을지 의심스러운 면도 없지는 않습니다. 하지만 업무의 여러 영역에서 이 개념을 염두해 두면 의미가 있을 겁니다.

온라인에서 쉽게 찾을 수 있는 작은 팀이 메커닉을 개선하는 이터레이션을 상상해 봅시다. 게임을 테스트해 어떤 문제를 발견했습니다. 문제를 정의했지만 원인과 해결 방법은 다양해서 어떻게 접근해야 할 지 잘 모르겠습니다. 또 각 접근 방법이 문제를 해결할지, 또 어떤 부작용을 일으킬지 알 수 없는 상황입니다. 일단 한 가지 방법을 선택해 시도해 봅시다. 선택하는 방법에는 메커닉에 큰 변화를 일으키는 것을 우선 선택하거나 그 반대로 선택할 수도 있는데 업계의 전설들이 작성한 글을 찾아보면 이 상황에 유리한 접근 방법을 배울 수 있을 겁니다. 이 글의 주제는 아니니 넘어갑니다.

선택을 평가하려면 선택이 게임 상에 온전히 구현되어 있어야 합니다. 구현 비용을 줄일 수는 있겠지만 구현하지 않고 평가할 수는 없습니다. 경험이 쌓이면 머릿속 시뮬레이션을 조금 더 잘 할 수 있기는 합니다. 하지만 이 역시 비용을 줄일 수 있을 뿐 시뮬레이션이 올바른지 평가하기는 어렵습니다. 구현 결과가 문제를 해결하지 못하면 다른 방법을 선택하고 이 과정을 반복합니다.

이는 일종의 최대 가치 단계의 모니터링이라고 할 수 있습니다. 이미 개발되어 게임에 반영된 상태에서는 평가 비용이 낮습니다. 또한 실제 결과가 눈앞에 있으므로 프로젝트 구성원들을 설득해 다음 단계로 진행하기도 쉽습니다. 하지만 이 방법은 비용이 높으며 상황에 따라 팀에 상처를 남깁니다. 게임을 개발하며 재작업을 두려워하지 말라고 가르치곤 하지만 모두에게 이를 요구하기는 쉽지 않습니다. 솔직히 재작업은 괴롭습니다. 충분히 감정을 지불하지 않으면 상처가 깊어집니다.

최저 가치 단계의 모니터링은 이 사례에서 잠깐 언급한 머릿속 시뮬레이션에 더 의존하는방법입니다. 사실 어느 정도 경험이 쌓이면 기획서의 글자만 보고서 이 결과가 지금까지 개발한 게임에 어떻게 섞여 들어갈지 아예 예상할 수 없는 것은 아닙니다. 기획서 단계에서 시뮬레이션을 반복해 사전에 문제를 찾아내 기획을 수정하거나 실행 여부나 실행 시점을 조정할 수 있습니다. 이 단계에서도 여전히 재작업 비용과 이로 인한 감정을 지불해야 하지만 최대 비용 단계의 모니터링에 비해 비용이 낮습니다. 다만 시뮬레이션의 올바름을 검증할 방법은 필요합니다. 만약 최저 가치 단계에서 모니터링이 어렵다면 비용을 조금씩 더 지불해 가며 모니터링이 가능한 단계를 찾아야 합니다. 이럴 수 있음에도 굳이 최대 비용을 지불하기를 반복하는 것은 팀을 낭비하는 일입니다.

이전의 몇몇 개발 경험은 왜 그렇게 고통스러웠을까요. 충분히 가치가 낮은 단계에서 모니터링 할 수 있었지만 결국 습관적으로 마지막 단계까지 가고 맙니다. 흔히 바쁘고 큰 개발팀에서 당연히 있어야 할 것 같은 기능을 추가하는 상황을 상상해 봅시다. 마일스톤 초기에 목표가 수립되지만 이 목표 각각이 실제 게임에 어울리게 동작할지 평가하지는 않습니다. 일단 개발을 시작해 마일스톤이 끝날 무렵까지 최대 비용을 지불하도록 방치합니다. 마일스톤이 끝나면 최대 비용을 지불한 게임 전체를 평가해 다음 계획을 수립하고 이를 반복합니다. 때에 따라서는 마일스톤 마감 기간에 갑작스레 문제를 수습해 보기 위한 온갖 요구사항이 쏟아져 팀을 과로 상태에 빠뜨리기도 합니다. 이미 최대 비용을 지불한 상태에서는 이로 인해 발생하는 문제를 단기간 안에 해결하기 아주 어렵습니다. 서비스 단계에서는 이런 문제해결 방법이 강제 되지만 개발 단계에 이럴 필요는 적습니다.

이전의 몇몇 개발 경험은 왜 그렇게 고통스러웠을까요. 일상적으로 최대 비용 단계에서 모니터링을 반복했기 때문입니다. 여기서 발생하는 높은 비용과 이로 인해 발생하는 상처에 대한 감정적 지불 없이 같은 방식을 유지했기 때문입니다. 이 과정을 반복하면 결국 서서히 구성원이 바뀌어 가며 이 과정에서 노하우와 사기가 유실되고 이는 다시 개발 경험을 고통스럽게 만듭니다. 이러지 않기 위해 노력해야 합니다.