마일스톤 목표의 우선순위 설정과 실행여부

목표로 하는 소프트웨어의 규모가 크고 이를 개발하기 위해 참여하는 사람들의 수가 늘어날수록 마일스톤 계획을 수립하기는 점점 더 어려워집니다. 여기에 프로젝트 팀이 만들어진지 얼마 지나지 않아 우리들이 낼 수 있는 퍼포먼스를 잘 모르거나 마일스톤 기간이 길어 전체 기간에 걸친 결과를 정의하고 또 예측하기 어려운 상황이라면 더더욱 마일스톤 계획을 수립하기는 쉽지 않습니다. 이상적인 해결 방법은 이런 상황에서 마일스톤 계획을 수입하기는 어렵거나 사실상 불가능하다는 사실을 인정하고 마일스톤 계획 수립을 어렵게 만드는 여러 가지 요소를 제거해 나가거나 마일스톤 계획 단계에 개입하지 않도록 통제하는 것입니다. 가령 프로젝트를 시작한지 얼마 지나지 않아 우리들의 퍼포먼스를 잘 모른다면 본격적인 마일스톤을 시작하기 위해 계획을 수립하는 대신 조금 더 작은 일종의 파일럿 마일스톤을 실행해본 다음 우리들의 퍼포먼스를 예측하는 자료로 사용할 수 있습니다. 또 마일스톤의 전체 기간을 줄여 기간이 증가함에 따라 기하급수적으로 증가하는 예측 난이도를 현격하게 낮추는 방법도 있습니다. 12주 후의 미래를 예측하기는 대단히 어렵지만 8주 뒤의 미래를 예측하는 것은 여전히 어렵지만 12주 뒤를 예측하는 것 보다는 쉬울 겁니다. 또한 마일스톤이 끝날 때 목표를 구체적으로 정의해 중요도가 낮거나 마일스톤 목표에 거의 영향을 끼치지 못하는 요구사항이 함부로 끼어들어 단위 기간 동안의 개발력에 악영향을 끼칠 위험성을 통제할 수도 있습니다. 구체적인 정의라고 하면 쉽게 오해를 불러일으킬 수 있을 것 같으니 비디오 게임 관점에서 ‘마일스톤이 끝난 시점의 플레이시나리오’라고 해 두겠습니다.

마일스톤 계획을 수립할 때 이 가칭 ‘플레이시나리오’는 대단히 중요합니다. 프로젝트의 고위의사결정자가 매 마일스톤을 시작하기 전에 반드시 마일스톤이 끝날 때 우리가 가지고 있어야 하는 빌드의 플레이시나리오를 정의한 다음 이를 정확히 공표하는 것과 그렇지 않은 것 사이에는 마일스톤 결과 뿐 아니라 마일스톤 도중 일어나는 의사결정 과정을 완전히 달리 진행되도록 만들 수도 있습니다. 이전에 경험한 어떤 프로젝트에서 그 프로젝트의 디렉터님은 3개월 뒤 미래에는 게임을 시작한 다음 플레이어들이 세 팀으로 나뉘어 게임을 시작한 다음 각자의 마을에서 자원을 획득해 기술을 발전시킨 다음 마을 주변의 다른 거점을 점령하고 주변의 다른 자원을 수집하며 이 사이에 다른 팀의 공격으로부터 자원을 채집하는 플레이어들을 보호하는플레이럴 계속한 끝에 다른 플레이어들의 거점과 마을을파괴하고 한 팀이 살아남으면 한 세션의 게임이 끝나는 플레이 시나리오를 제시했습니다. 여기서 가장 중요한 것은 한 세션에 걸친 플레이가 수행되는 것입니다. 여기에는 보다 구체적인 여러 가지 목표가 있지만 핵심은 한 세션의 플레이가 이전에 수행한 프로토타입 단계와 같이 수행되도록 하는 것입니다. 이 플레이시나리오를 알고 있는 구성원들은 앞으로 한 마일스톤 안에 이를 실현해야 하는데 플레이시나리오 모양의 목표를 모두가 공유하고 있는 이상 이제 이들의 의사결정에는 큰 차이가 생깁니다. 가령 이 플레이시나리오에 당장 영향을 끼치지 않는 보조 기능이나 이 플레이시나리오에 영향을 끼치지 않는 코너 케이스를 해결하기 위한 요구사항 정의 요청 같은 소모적인 일이 발생하지 않을 겁니다.

반면 마일스톤 목표를 지정하지 않거나 잘못 지정하거나 기능의 나열과 같이 근본적으로 마일스톤 기간이 끝난 다음의 미래를 상상하기 불가능하게 만드는 잘못된 목표 제시 방법들도 있습니다. 먼저 마일스톤 목표를 지정하지 않는 사례가 있습니다. 가령 ‘이번 마일스톤이 끝나면 사장님께 보고를 해야 한다’는 사실이 마일스톤 목표와 같은 의미로 통용될 때가 있습니다. 이미 예상하셨겠지만 이 말은 아무 의미도 없습니다. 사장님은 항상 매 달 거대한 돈을 쓰고 있는 우리들이 뭘 어떻게 만들어 가고 있는지 항상 굼금해합니다. 때문에 사장님이 빌드를 보고 싶어 하는 건 별로 대수로운 일이 아닙니다. 가장 큰 문제는 이 사실은 빌드 목표로 삼을 수 없다는 점인데 이유는 이 말을 듣고 마일스톤이 끝날 무렵의 빌드 모양을 예측하는데 아무런 도움도 주지 않기 때문입니다. 물론 다른 마일스톤 목표와 같이 마일스톤 진행 중 일어날 의사결정에 영향을 줄 수는 있습니다. 가령 이번 마일스톤이 끝날 때 사장님께 빌드를 보여드려야 하니 이른바 코스메틱 이슈의 우선순위를 높여 다듬어지지 않은 모양의 에셋이 보고 시나리오에 등장하지 않도록 하는 일들이 더 중요하게 처리될 겁니다. 또 다른 그리 바람직하지 않은 마일스톤 목표 정의에는 ‘첫 번째 대륙 완성’이나 ‘레벨 15까지 플레이’와 같이 이를 접하는 사람들마다 의미를 달리 해석할 여지가 있는 표현도 있습니다. 이전에 경험한 어떤 프로젝트에서는 게임을 크게 세계를 구성하는 대륙 단위로 개발했는데 각각의 대륙은 대륙 전체를 아우르는 커다한 시나리오가 있었습니다. 첫 대륙은 게임을 처음 시작해 퀘스트를 따라가며 게임 전체의 목표를 인식하고 여러 가지 일을 겪은 끝에 결국 다른 대륙으로 진출하기 위해 바다로 나서게 된다는 이야기로 마무리됩니다. 그래서 첫 번째 대륙의 개발을 마쳐야 한다는 말의 의미는 여러 가지로 해석될 수 있었는데 첫 번째 대륙의 퀘스트 전체를 플레이 할 수 있어야 하고 이에 따른 모든 던전과 컷씬이 완성되어야 한다는 의미로 해석할 수 있습니다. 또 이 대륙의 플레이에 따라 등장하는 서브 컨텐츠가 모두 완성되어야 한다는 의미일 수도 있었습니다.

이 마일스톤이 끝날 때 우리들은 첫 번째 대륙의 퀘스트를 시작해 몇 시간에 걸쳐 퀘스트를 따라가며 대륙 곳곳을 누비고 여러 몬스터를 사냥하고 여러 던전을 플레이 하며 던전마다 조금씩 다른 메커닉을 접하고 여러 아름다운 컷씬을 보며 대륙 전체에 걸친 퀘스트를 마무리할 수 있었습니다. 여기에는 개발비용이 아주 높은 대규모 전투와 커다란 보스 몬스터들이 포함되어 여러 사람들이 월말에 주 52시간 상한 제한에 걸려 더 이상 출근하지 못하는 상태가 프로젝트 전체에 걸쳐 나타나게 만들었지만 어쨌든 첫 대륙의 퀘스트는 조금 삐걱거리는 구석이 없지 않았지만 어쨌든 동작했습니다. 퀘스트가 대륙 처음부터 끝까지 끊기지 않고 플레이 되는 것은 굉장히 중요해서 퀘스트 자동 테스트 기능을 만들었습니다. 매일 새벽 네 시에 퀘스트 테스트를 담당한 컴퓨터 몇 대는 각자 클라이언트 여러 개를 실행해 퀘스트를 맨 처음부터 플레이 하기 시작했습니다. 당시 우리는 퀘스트 인터페이스를 조작하면 퀘스트를 자동으로 수행하는 메커닉이 있어 퀘스트 자동 테스트를 준비하기 훨씬 쉬웠습니다. 각 클라이언트가 여러 클래스로 퀘스트를 따라가며 플레이 하다가 뭔가 문제가 생겨 일정 시간 동안 같은 퀘스트에 머물며 진행하지 못하면 이를 문제 상황으로 정의해 기록하고 보고하는 방식으로 동작했습니다. 출근하면 메일로 새벽에 일어난 퀘스트 테스트 결과가 와 있었고 우리들은 문제를 살펴보고 각자 문제를 재현해본 다음 이를 직접 수정하거나 지라 태스크를 만들어 협업 부서로 전달하는 과정을 몇 주 동안 반복해 퀘스트 라인이 깔끔한 모양으로 동작하게 만들었습니다. 하지만 불명확한 마일스톤 목표는 오직 퀘스트가 멀쩡하게 동작한다고 해서 목표를 완수했는지 여부를 판단하기 어렵게 만들었습니다.

이렇게 퀘스트를 자동으로 테스트 하며 퀘스트 라인이 정상적으로 동작하는지 자동화된 모양으로 테스트 하기 위해서는 몇 가지 조건을 설정해야만 합니다. 가령 기계는 보상을 획득해 무기를 교체하거나 무기를 성장 시키지 않았습니다. 때문에 특정 시점마다, 주로 레벨이 오르면 그 시점에 고객이 수행해야 하는 성장 행동을 명령어를 사용해 수행하게 했습니다. 이 테스트는 오직 모든 퀘스트를 끊기지 않고 플레이 할 수 있는지를 확인하는데 초점을 맞추고 있었기에 이어지는 퀘스트들의 난이도가 얼마나 올라가는지는 관심사가 아니었습니다. 어떤 고객은 무기 성장 메커닉을 전혀 이해하지 못할 수 있습니다. 매 퀘스트마다 무기 성장에 사용할 재료를 계속해서 보상으로 주고 있지만 이 아이템의 용도 자체를 이해하지 못할 수 있습니다. 그렇다면 어느 순간 눈앞에 나타난 보스 몬스터 뿐 아니라 그저 던전을 지나가는데 아무렇게나 뿌려져 있는 일반 몬스터를 상대하기도 버거운 순간이 찾아오고 어쩌면 게임을 그만 둘는지도 모릅니다. 만약 마일스톤 목표가 ‘첫 번째 대륙 완성’이 아니라 ‘첫 번째 대륙 퀘스트 라인 완성’과 같이 아주 조금 더 구체적인 모양이었다면 우리들이 어디에 자원을 집중해야 할 지 쉽게 판단할 수 있었을 겁니다. 하지만 마일스톤 목표는 여러 가지 의미로 해석될 수 있었기에 요구사항은 아주 쉽게 확장되었습니다. 가령 어느 날 부터는 드디어 아침에 출근해 확인한 퀘스트 테스트 메일에 모든 퀘스트를 수행하는데 성공했다는 내용이 나타났습니다. 하지만 우리들은 이 상태가 마일스톤 목표를 달성한 상태인지 판정할 수가 없었습니다. 첫 번째 대륙에는 다양한 컨텐츠가 별도로 동작해야 했고 앞서 잠깐 설명한 대로 퀘스트 라인 그 자체에 포함된 성장과 밸런스 요소가 개발되어야 했습니다. 심지어 프로젝트 팀에 소속된 사람들 조차도 종종 변경되는 파밍 위치와 파밍 목표 아이템, 필요한 성장 수준을 그때그때 따라가지 못해 의도하지 않은 시점에 죽곤 했습니다.

퀘스트 라인은 온전히 개발되었지만 개발팀은 여전히 소위 성장 밸런스를 맞추는데 시간을 보냈습니다. 메인 퀘스트 사이에 의도적으로 허들을 만들어 성장을 필요로 하게 만들고 이 부분을 지탱하기 위한 이른바 서브퀘스트, 반복 파밍 던전 따위를 만들어 시간을 보내며 성장 요구사항을 달성하게 만들어야 했습니다. 하지만 메인 퀘스트 라인이 자동화된 테스트의 도움을 받아 매일 새벽마다 반복해서 기계에 의해 테스트 되고 있는 것에 비해 나머지 기능들은 그런 현대적인 개발 환경의 도움을 받기 어려웠습니다. 각 던전은 시도 때도 없이 오동작을 일으켰고 서브퀘스트는 여러 퀘스트를 동시에 수행하는 상황, 여러 지역을 계속해서 이동하는 상황 등에 의한 영향을 계속해서 받아 예상한 모양으로 동작하지 않았습니다. 마일스톤 마감은 점점 더 가까워 오고 누군가 마일스톤 목표에 맞출 수 있는 목표 조정이 필요하다고 느꼈습니다. 하지만 여전히 목표는 ‘첫 번째 대륙 완성’으로 고정되어 있었고 이 목표는 실질적인 문제에 맞닥뜨린 우리들의 관점에서는 지나치게 느슨했습니다. 어느 날 테스트 부서로부터 날아온 보조 기능의 오동작에 대한 지라를 보고 이걸 받아들여 수정하도록 할 지 아니면 중간에서 제가 지라를 먹고 아무 대응도 하지 않을지 고민했습니다. 테스트 부서에서 결함을 발견하면 한동안은 이 결함을 직접 수정할 담당자에게 바로 지라를 보내곤 했지만 이러다 보니 각 실무자들의 업무 부하를 모니터링하는데 어려움을 겪었습니다. 그래서 팀마다 컨텍 포인트를 지정해 한 사람이 지라를 몽땅 받은 다음 이들 중 수행할 것과 그렇지 않은 것을 분류하고 또 각 실무자들의 부하를 고려해 담당자를 설정했는데 이 때 제가 하는 일 중 하나는 결함을 받아 내용을 검토했지만 아무것도 하지 않고 그냥 제가 들고 있는 것입니다. 이걸 돌려보내자니 결함은 여전히 존재하고 수정하라고 다음 사람을 지정하기에는 마일스톤 목표에 그리 가깝지 않아 보였습니다. 그래서 항상 저는 해결되지 않은 결함을 수 백 개 단위로 들고 있었고 테스트 부서로부터 결코 좋은 평가를 받지 못했을 겁니다.

이윽고 우리들의 모가지를 걸고 사장님께 발표하는 자리에서 게임은 적어도 겉으로는 별 문제를 일으키지 않는 범위 내에서 시연되었습니다. 시연 시나리오에는 여러 가지 문제를 일으키던 서브퀘스트는 처다보지도 앟았고 높은 비용을 들여 제작되었음에도 문제가 많던 특정 보스 몬스터의 마지막 페이즈는 아예 수행되지 않도록 수정했습니다. 그래서 첫 대륙의 메인 퀘스트는 처음부터 끝까지 깔끔하게 수행되었을 뿐 아니라 이 상태를 만들기 위해 자동 퀘스트 기능에 기반해 아주 높지는 않은 비용으로 제작한 퀘스트 자동 테스트 파이프라인은 상당한 호평을 받았습니다. 개발 중인 기능은 완전히 숨겨졌고 그 동안 코스메틱 이슈에 아주 민감하게 반응한 덕분에 게임은 마치 이번 주에 출시해도 될 것 같아 보였습니다. 사장님이 농담으로 ‘이제 출시 날짜를 정하면 되나요?’라고 물었고 프로젝트 쪽 고위 의사결정자님은 그렇지 않다고 웃으며 말했지만 그 자리에 있던 우리들의 표정은 결코 밝지 않았습니다. 우리들은 모가지를 보전하는데 성공했고 또 앞으로 얼마 동안에 걸쳐 생계를 유지할 수 있게 되었습니다. 하지만 여전히 우리는 이 보고를 위한 지난 마일스톤의 목표는 과연 무엇이었고 과연 무엇인지 알 수 없는 목표를 달성했는지 여부를 평가할 수 없었습니다. 어느새 기획팀의 여러 부서에서 두 번째 대륙을 개발하는데 필요한 요구사항을 한창 작성하고 있었고 여기에 필요한 엄청난 양의 아트 에셋 제작을 위한 수많은 문서가 준비되고 있었습니다. 아마도 이 시점에 다음 마일스톤의 목표는 ‘두 번째 대륙 개발’이 될 것 같습니다. 그런데 우린 아직 첫 번째 대륙의 개발을 마무리했는지, 이를 요구하는 마일스톤 목표가 있었는지 평가하기 어려웠습니다. 결국 우리들은 이전 마일스톤에 수행해야 했는지 그렇지 않아도 됐는지 평가하기 어려운 주제들을 두 번째 마일스톤의 기다란 목표 목록 어딘가에 적당히 쑤셔 넣은 모양으로 마일스톤 계획을 수립해야만 했습니다.

사실 마일스톤 목표를 그리 길지 않은 플레이시나리오 모양으로 정의하고 이를 당당히 프로젝트 팀에 제시하고 도 이를 당당히 사장님께도 제시할 수 있는 강을 가진 고위 의사결정자는 시장에 그리 많지 않습니다. 널리 알려진 네임드들 중 일부가 그렇게 일하거나 그렇게 일해도 모가지가 날아가지 않는 지위를 획득했다고 알려져 있지만 이렇게 일하기 위해서는 아래로부터, 그리고 위로부터 들어오는 온갖 압력에 태연하게 반응할 수 있는 엄청난 수준의 깡이 필요합니다. 가령 플레이사나리오를 정의했다 칩시다. 만약 이 계획이 잘 수행된다면 마일스톤을 수행하는 우리들은 플레이시나리오를 달성하기 위해 이에 직접적으로 관여하지 않는 여러 가지 기능에 대한 소모적인 의사결정을 전적으로 거부해 버릴 수도 있습니다. 가령 ‘시나리오에 따른 한 세션 전체의 플레이’나 ‘첫 번째 대륙의 퀘스트 라인 완성’ 같은 목표를 수행하기 위해 당장 여기에 끼치는 영향이 현격하게 적은 ‘길드 기능의 오동작’을 해결하기 위한 근본적인 기획 변경이나 ‘거래소 기능의 기술적 한계를 정의하기 위한 의사결정’ 같은 주제를 무시할 수 있습니다. 하지만 이런 일이 일어나는 상태를 무시하고 마일스톤 목표에 집중할 수 있는 환경을 만들다 보면 이런 집중에 의해 일시적으로 소외되는 부서들로부터 나오는 불만을 처리해야만 합니다. 대체로 이런 상황을 중간관리자들에게 처리하도록 위임하기는 쉽지 않기 때문에 애초에 이런 상황을 만들지 않도록 모호한 마일스톤 목표를 정의해 프로젝트 팀이 집중할 목표를 중간관리자들이 ‘알아서’ 판단하도록 위임보다는 회피에 가까운 행동을 하더라도 이 문제가 고위 의사결정자의 문제로 판단되지 않는 모양으로 만들 수 있습니다. 사실 깡의 문제라기보다는 어느 정도는 그 부작용을 알면서도 자기 자신도 그저 한 명의 월급쟁이에 불과한 고위 의사결정자 역시 자기 자신을 보호하기 위해 어쩔 수 없이 이런 모호한 목표를 설정하며 일어나는 온갖 상황을 방관하는 측면도 없지 않습니다.

하지만 마일스톤 목표가 모호한 상태가 되면 마일스톤 목표는 근거로 삼을 아무런 플레이시나리오의 지원 없이 그저 기능의 나열 모양으로 바뀌기 쉽습니다. 플레이시나리오는 만들기도 어렵고 이를 지탱하려면 깡이 필요하지만 기능의 목록은 시나리오 모양의 정의를 필요로 하지도 않습니다. 그저 마일스톤이 끝날 무렵 테스트 부서로부터 각각의 기능이 정상적으로 동작하는지 여부를 판단 받아 각각의 결함을 수정하기만 하면 됩니다. 마일스톤의 완수 여부를 판단 기준으로 삼을 날짜의 스냅샷 기준으로 발행된 전체 결함 목록과 이들 중 해결된 결함, 그리고 남은 결함 수에 근거해 숫자로 제시할 수도 있어 보고할 때 편안한 의사소통을 할 수 있게 만듭니다. 또 실무자들 입장에서도 플레이시나리오에 근거한 어려운 의사결정을 할 필요 없이 그저 자신이 수행해야 할 일을 하고 나중에 자신에게 날아온 지라를 해결하다 보면 마일스톤이 끝나고 다음 마일스톤에 이번 마일스톤에서 해결하지 못한 결함과 구현하지 않은 기능을 이어서 개발하기만 하면 되니 이해하기도 쉽습니다. 이런 장점 때문인지 규모가 작다고는 말하기 어려운 여러 프로젝트에서 마일스톤 목표를 플레이시나리오 모양 보다는 기나긴 기능의 목록으로 표현하곤 했습니다. 각각의 기능이 전체 제품을 완성하는데 얼마나 도움이 될 지, 그리고 마일스톤이 끝날 때 어떤 수준의 플레이가 가능해야 하는지 직관적으로 인식하기는 어렵지만 그저 각 마일스톤에 따른 개발을 수행하기만 하는 입장에서 이런 마일스톤 목표는 직관적입니다. 개인적으로는 장기적으로 여러 모로 바람직하지 않은 마일스톤 디자인이라고 생각하는 입장이지만 이 모양이 직관적이며 여러 사람들을 어려운 의사결정으로부터 해방 시켜 준다는 점을 인정합니다.

그렇지만 그저 여러 기능의 나열 모양의 마일스톤 목표가 실제 세계에서 이렇게 직관적인 모양으로 실행되지는 않습니다. 크게 두 가지 문제가 있습니다. 하나는 이 프로젝트 팀이 함께 개발해 온 지 시간이 제법 지났음에도 여전히 서로의 퍼포먼스를 잘 모른다는데 있습니다. 기능의 규모와 그간의 퍼포먼스를 고려해 실현 가능한 범위를 예측할 수 있어야 한다고 생각합니다. 예측은 틀릴 수 있지만 시간이 갈수록 예측은 아주 조금씩 발전하기 마련인데 이 전제 조건은 퍼포먼스에 기반해 예측을 반복해서 연습하는데 있습니다. 하지만 이런 시도를 하지 않으면 그저 나열된 기능의 수나 기능에 나타난 주요 키워드들을 보고 비용을 과대평가하거나 과소평가해 여러 사람들을 초과근무의 늪에 몰아넣거나 마일스톤 목표 달성에 실패하게 만들 수 있습니다. 또 다른 문제는 앞서 직관적이기는 하지만 명확하지는 않은 마일스톤 목표로 인해 이전 마일스톤에서 완료하지 못한 기능과 결함들이 다음 마일스톤으로 넘어와 다음 마일스톤 계획에 영향을 끼치는 것입니다. 새 마일스톤에는 새로운 기능, 두 번째 대륙, 새로운 레벨 구간, 멀티플레이 엔드 컨텐츠 따위를 개발하려고 요구사항을 준비해 놓았지만 이미 이전 마일스톤들로부터 완성되지 않고 넘어온 기능들로 인해 이미 마일스톤 전체 목표의 절반 이상이 점유 되어 버렸습니다. 사실 이전 마일스톤으로부터 넘어온 일감들이 새 마일스톤의 얼마만큼을 점유했는지 판단할 수도 없습니다. 이전의 경험에 기반한 퍼포먼스 예측을 수행하지 않으므로 그저 마일스톤 목표에 해당하는 기나긴 기능들의 나열에 아무래도 지난 마일스톤부터 봐 왔기 때문에 낯익은 일감들이 여럿 보이고 이들의 수가 많으면 많을수록 이번 마일스톤의 목표를 보수적으로 설정하게 만들 뿐입니다. 새 마일스톤에 새로 시작할 멋진 요구사항들 소수와 이전 마일스톤으로부터 완결되지 않고 넘어온 일감 다수로 구성된 새 마일스톤 목표가 수립되고 이제 슬슬 마일스톤을 시작할 차례입니다.

물론 마일스톤 목표를 덜렁 이렇게 기나긴 여러 기능들의 나열 모양으로 만든 다음 바로 시작하지는 않습니다. 지금까지 ‘우선순위 설정과 실행여부’라는 제목으로 시작한 글이라고 하기에는 아직 제목에 가까운 이야기를 단 하나도 하지 않았다는 사실을 눈치 채셨을 수 있습니다. 맞습니다. 단순히 기능이 나열된 모양으로는 마일스톤을 시작할 수 없습니다. 이제 이들에 우선순위를 설정해 어떤 일을 먼저 시작할지, 또 어떤 일에 더 많은 인원과 자원을 할당할지 판단하려 할 때 근거로 삼도록 해야 합니다. ‘우선순위'의 정의는 ‘어떤 것을 먼저 차지하거나 사용할 수 있는 차례나 위치’라고 합니다. 여기서 먼저 차지하거나 사용할 어떤 것은 적어도 비디오 게임 소프트웨어 개발 분야에서는 이를 개발할 사람을 말합니다. 우선순위가 높은 일이라면 이번 마일스톤에 반드시 끝마쳐야 할 가능성이 높고 또 이 마일스톤 목표를 보고 받은 사장님이 마일스톤이 끝난 다음 보고 때 이 기능이 동작하는 모습을 보고 싶어 할 가능성이 높습니다. 때문에 우선순위가 높은 기능은 기능을 여러 조각으로 나눠 서로 다른 사람들에게 분배하고 이들이 병렬로 진행되는 파이프라인에 의해 더 빠른 시점에 기능이 동작하는 수준에 도달하게 만들 수 있습니다. 반면 우선순위가 낮은 목표는 심지어 마일스톤이 시작한 다음이라도 당장 아무 것도 하지 않아도 될 수 있습니다. 다른 더 중요한 일을 수행하고 나서 만약 시간이 남는다면 이 일들을 검토할 수는 있을 겁니다. 하지만 우선순위가 높은 일을 처리하느라 이들에 집중하던 여러 사람들은 덜 중요하거나 별로 중요하지 않은 다른 일로 태스크 스위칭이 잘 일어나지 않을 뿐 아니라 물리적으로도 덜 중요한 일로 전환하기 쉽지 않은 상황에 놓입니다. 가령 가장 중요한 기능의 개발을 마쳐 조립한 다음 테스트 부서에 전달하고 그 사이에 덜 중요한 일을 수행하려 했지만 테스트 부서로부터 결함 보고가 도착하기 시작하면 덜 중요한 업무 수행을 중단하고 다시 더 중요한 업무로 돌아와야만 합니다.

이런 현실적인 상황 때문에 개인적으로는 마일스톤 목표에 나열된 여러 가지 기능 중 우선순위가 가장 높은 항목을 제외하고는 사실상 개발이 진행되지 않는다고 가정합니다. 이전 마일스톤으로부터 넘어온 결함들을 그 중 규모가 아주 작은 것에 한해서는 이번 마일스톤에 진행할 수 있을지도 모릅니다. 가령 테스트 부서로부터 결함 보고가 왔지만 오늘 하루 정도는 덜 중요하고 또 규모가 작은 일 하나를 처리한 다음 내일 결함을 수정하는 업무로 넘어갈 수 있는 수준이라면 우선순위가 낮고 또 규모가 작은 일을 처리할 수 있습니다. 하지만 규모가 꽤 크면서도 우선순위가 가장 높지 않다면 이 일은 사실상 이번 마일스톤 안에 수행할 수 없다고 판단합니다. 물론 항상 그렇지는 않기에 분위기를 봐 가며 미리 요구사항을 준비할지 여부를 판단하곤 하지만 처음부터 이번 마일스톤에 진행할 가능성이 높지 않은 업무에 게임디자인 자원을 투입해 요구사항을 정의하도록 하지 않으려고 노력합니다. 이 일을 반복하다 보면 우선순위 1로 설정된 요구사항을 정의한 다음 이어서 우선순위 2로 정의된 일 중 요구사항을 준비할 항목과 무시할 항목을 더 잘 예측할 수 있습니다. 물론 미리 우선순위에 관계 없이 모든 기능의 요구사항을 정의해 놓으면 제 관리자들의 마음을 편안하게 하는데 도움을 줄 수 있기는 합니다만, 요구사항을 작성했다가 이번 마일스톤에 실행되지 않거나 오랫동안 방치되었다가 미래의 마일스톤 계획에 포함되려 할 때 그 사이에 일어나느 여러 가지 변경 사항을 반영하는 과정이 거의 요구사항을 완전히 재정의 하는 것과 비슷한 수준의 비용이 들 때 이 업무를 수행한 담당자들의 사기를 크게 떨어뜨릴 수 있습니다. 때문에 제 상위 관리자들의 편안한 마음을 위해 이번 마일스톤에 실행되지 않을 것이 분명한 요구사항들을 굳이 준비하지 않습니다. 그 댓가로 저는 인사평가에서 좀 더 낮은 등급을 받는 대신 실제 요구사항을 정의하는 사람들의 사기를 얻을 수 있습니다. 나쁘지 않은 거래입니다.

하지만 어떤 관리자들은 이런 접근일 이해하지 못하기도 합니다. 미리 저 높은 곳에서 정의되어 내려온 마일스톤 목표들과 목표 각각에 설정된 우선순위를 살펴본 다음 프로젝트 팀 전체의 퍼포먼스를 대략 생각해본 다음 ‘우선순위 1 빼곤 전부 다 드랍되겠네요?’라고 말하면 이를 격렬하게 부정하는 관리자들도 있었습니다. 결국 미래에 제 말이 맞지만 이를 미리 예측해서 이에 맞게 핼동하는 것은 제 상위 관리자들의 마음에 썩 들지는 않는 모양입니다. 저는 실제 업무를 수행할 사람들의 사기를 얻기도 해야 하지만 또 어느 정도는 이들의 사기와 바꾼 제 상위 관리자들의 마음의 평안을 확보해야만 했고 이들 사이에 적당한 밸런스를 맞추기는 생각보다 어렵다는 사실을 배웠습니다. 하지만 여전히 마일스톤 목표 별로 전체 그림을 예측할 수 있는 플레이시나리오가 프로젝트의 가장 높은 곳으로부터 우리들 모두에게 공표되지 않는 이상 마일스톤 목표는 우리들의 의사결정에 전혀 도움이 되지 않는 단순 기능들의 나열 모양이 되며 여기에 각 기능 옆에 우선순위가 붙으면 이 마일스톤 목표는 사실상 우선순위가 높은 항목들만 수행되고 나머지 항목은 그 다음 마일스톤으로 밀리기를 반복하다가 더 이상 미룰 수 없는 순간이 닥칠 때 모든 마일스톤 목표가 우선순위 1로 바뀌는 기적을 체험하게 됩니다. 이는 충분히 미리, 그러니까 몇 달 또는 몇 년 전에 미리 예측하고 회피할 수 있는 일이었지만 대부분은 그렇지 못했습니다. 팀에 도착한 모든 항목의 우선순위가 1로 표시된 마일스톤 목표를 보고 ‘피식’ 하고 숨이 새어나가지 않기는 어려웠습니다. 그나마 이전에는 우선순위에 따라 일을 진행할 순서라도 알 수 있었지만 이제는 순서에 대한 힌트 조차 얻을 수 없었습니다.

이런 경험을로부터 마일스톤 목표는 근본적으로 기능을 예측할 수 있는 플레시나리오 모양이어야 한다고 생각하지만 이는 회사에서 일어나는 여러 가지 어른들의 사정 상 불가능하거나 이를 가능하게 할 정도의 깡이 있는 함께 일하고 싶은 고위 의사결정자들은 저 같은 사람과 함께 일할 가능성이 없기 때문에 그저 여러 기능의 나열일 뿐인 마일스톤 목표는 필요악으로써 납득할 수밖에 없었습니다. 납득할 수밖에 없었지만 완전히 납득하고 인정합니다. 다만 여전히 그 옆에 부여된 우선순위에 따른 실행 여부는 이를 시니컬하게 입 밖으로 말하지 않지만 마음 속으로는 우선순위 1 외에는 아무것도 실행되지 않을 거라는 개인적인 판단에 따라 행동합니다. 우선순위 1에 해당하는 요구사항은 즉시 착수하거나 이미 이전 마일스톤의 남는 시간에 준비해 놓았습니다. 하지만 우선순위가 이보다 낮아 사실상 이번 마일스톤에 착수할 가능성이 없는 업무들에 대해 미리 요구사항을 준비하게 하지는 않습니다. 아주 높은 확률로 이번 마일스톤에 착수되지 않음에 따라 요구사항을 정의한 소위 기획서는 시간이 지나면 낡거나 상합니다. 그래서 문서가 준비되어 있었다 하더라도 시간이 지나면 그 사이에 변화한 상황에 따라 이를 재정의 해야 하고 이 과정에서 담당자들의 사기를 망가뜨립니다. 개인적으로는 제 모가지의 안위와 인사평가에서 너무 낮지 않은 평점이 안 중요하지는 않지만 그것과 담당자들의 사기를 바꿀 수 있다면 당연히 후자를 선택할 겁니다. 제 상위 관리자들은 결코 요구사항을 작성하지 않기 때문입니다.

마일스톤 목표가 서로의 연관 관계에 따라 빌드의 동작을 상상하기 쉽지 않은 기능들의 나열, 그리고 각각의 우선순위를 기입한 모양이라면 적어도 이상적이지는 않은 모양으로 개발하고 있다고 볼 수 있고 이는 극히 정상입니다. 아주 소수의 프로젝트만이 그런 이상적인 모양으로 개발하고 있어 보이며 적어도 저 자신은 그런 팀에 속하기에는 부족합니다. 그러니 이러고 살고 있는 거라고 생각합니다. 이런 상황에서 중요한 교훈은 우선순위가 낮은 항목들은 그저 이들을 우리가 잊지 않고 있음을 나타내는 역할을 할 뿐 실제 이 일들을 수행할 목적으로 이 목록에 낮은 우선순위로 넣은 것은 아니라는 사실입니다. 이런 관점에 기반해 팀의 사기를 덜 망가뜨리는 선에서 더 중요한 일에 집중하고 이번 마일스톤에 요구사항을 준비했지만 실행되지 않아 미래에 이를 전면적으로 재작성해 담당자의 사기를 망가뜨리는 문제를 최소화합니다.