전통적인 기획자의 낮은 직급 문제

다른 프로젝트에서는 마일스톤을 어떻게 시작하는지 잘 모르겠지만 지금 제가 참여하는 프로젝트에서는 마일스톤을 시작하기 전에 높은 분들 사이에 마일스톤 결과에 대한 공감이 어느 정도 이루어진 상태에서 이에 기반한 계획을 설계하는 것으로 새 마일스톤이 시작됩니다. 마일스톤이 시작될 때는 마일스톤이 끝날 때 만들어져 있어야 하는 빌드에 대한 대략적인 플레이 시나리오가 있는 상태인데 이 시나리오는 우리가 처한 상황, 시장 상황, 또 높은 분들이 회사 밖에서 듣고 온 이야기, 스폰서의 취향 등에 기반하고 있습니다. 플레이 시나리오라고 정의할 수밖에 없지만 별로 내용 집약적이지 않은 프리젠테이션 문서 하나를 두고 여러 이익집단 사이에 나름 첨예한 대립이 일어난 결과는 그걸 실제로 만들어야 하는 사람들 입장에서 어찌나 엉성한지 모르겠습니다.

우리들이 내부에서 실제 어떤 상황에 처해 있는지 감안하지 않고 주로 팀과 회사 기준으로 바깥을 바라보고 만든 계획이 우리들의 실제 상황을 잘 반영하지 못하는 이유는 서로가 하는 일이 다르기 때문인 것 같습니다. 저 자신은 주로 프로젝트나 팀 기준에서 프로젝트와 팀 안쪽을 보고 계획의 실현 가능성을 평가하고 실현하는 일을 주로 하는 사람인데 비해 더 높은 분들은 주로 회사 바깥쪽을 보고 상황을 파악하며 프로젝트를 둘러싼 여러 이익 집단의 의견을 조율한 결과를 프로젝트 목표로 설정할 수밖에 없고 이 목표가 우리들의 실제 상황을 반영하지 못한다고 해도 이상하지 않습니다. 어떻게 보면 여러 이익집단의 욕망을 반영한 이 마일스톤 목표가 실제 우리들이 처한 상황과 거리가 있다는 사실 자체가 저 자신이 아직 잘리지 않고 밥값을 벌 수 있는 기회로써 작동하고 있지 않은가 싶습니다.

그렇게 약간 붕 뜬 것 같은 프리젠테이션 문서는 지라에 실현 가능한 조금 더 구체적인 단위의 에픽으로 만들어지고 에픽 각각에 담당자가 설정됩니다. 에픽 담당자들은 주로 게임디자이너들인데 게임디자이너들은 자신들이 해야 할 원래 일 이외에도 여러 협업 부서를 거쳐 빌드에서 기능이 실제 사용 가능하게 되는데까지 책임을 추가로 지고 있습니다. 단순히 말하면 기능에 대한 오너십을 함께 가지고 있다고 볼 수 있는데 이전에는 별도 관리자를 고용하지 않고 관리 부담을 게임디자이너들에게 전가하는데 불만을 가지고 있었지만 시간이 지나며 다른 소프트웨어 개발 업계에서 일하는 방법을 배우며 한 기능을 개발하는데 참여하는 여러 사람들 중 누군가는 다른 사람들에 비해 더 큰 오너십을 가져야 하고 여기에 항상 별도 관리자를 설정할 수는 없다는 사실을 배우게 됩니다. 이상적으로는 프로젝트 매니저들을 고용하고 별도 부서를 만들어 이 분들이 각 기능의 진행을 관리하면 일하기는 편하겠지만 이런 이상적인 형태를 바라기는 현실적으로 어려워 보입니다. 그래서 어느 순간 부터는 게임디자이너들이 기능에 대한 오너십을 가지는데 대해 불만을 가지지 않게 되었습니다.

다시 마일스톤 시작 시점으로 돌아가 게임디자이너들 각각에게 에픽이 할당되면 킥오프 준비를 하는데 킥오프는 완성된 기획서에 기반해 협업 부서 담당자들을 모아 놓고 브리핑 하고 질의응답을 하는 회의 자리입니다. 회의 전에 각 담당자들께 문서를 배포해 놓지만 대부분은 문서를 전혀 파악하지 않은 상태로 회의에 들어오시기 때문에 개인적으로 ‘문서를 띄워 놓고 읽어 드린다’고 말하는 모양으로 진행되기도 합니다. 처음에는 우리 모두 한국어를 잘 구사할 수 있고 기획서는 한국어로 작성되어 있는데 이걸 굳이 다들 모아 놓고 읽어 드려야 하는 이유를 잘 이해하지 못했고 또 이걸 읽지 않고 들어오는 상황에선 함께 개발할 수 없다고 좀 더 강하게 생각한 적도 있습니다. 하지만 이 역시 시간이 지나고 보니 아무도 기획서를 읽지 않고 킥오프 회의에 들어올 때마다 그 사람들과 일할 수 없다고 선언하면 업계에 아무도 남아 있지 않으리라는 사실을 인정할 수밖에 없었습니다.