고위 의사결정자 이상의 의사소통 방식

지난달 말일에 겪은 일입니다. 슬슬 퇴근시간이 가까워져 오늘 수행하던 일은 이 정도로 마무리 한 다음 내일 이어서 할 수 있도록 처리한 다음 남는 시간에는 오늘 업데이트 된 노션에 모든 문서를 살펴보고 또 오늘 커밋 된 다음 푸시 된 여러 디스크립션을 살펴보며 잠깐 한가한 시간을 보내고 있었습니다. 그런데 퇴근 시간까지 얼마 안 남았을 때 긴급으로 요청이 들어옵니다. 요청은 투자사로부터 앞으로 짧은 시간 안에 지난 첫 홀더 테스트를 마쳤습니다 (1) 이후 진행된 개발 현황을 정리한 문서를 보내 달라는 것입니다. 만약 전문 PM이 있었다면 이런 일은 분명 PM이 수행했을 것 같지만 우리는 전문 PM 없이 게임디자이너들이 알아서 각자가 담당한 기능에 대한 스몰 PM 역할을 수행하고 각자의 시야에 따라 전체적인 조율과 마일스톤 목표 달성을 위한 위험요소 제거를 수행하고 있었습니다. 그래서 이런 일이 바로 기획팀으로 날아온 겁니다.

다른 프로젝트에서도 주로 이런 질문은 기획팀으로 날아오곤 했는데 일단 다른 팀에 보내면 분명 이런 일은 우리가 할 일이 아니라고 말할 테고 또 실제로도 프로젝트 전체에 걸친 시야로 무슨 일이 일어나고 있는지 전체적인 그림을 가지고 있는 곳은 대체로 기획팀 뿐이었기 때문입니다. 만약 잘 동작하는 PM이 있었다면 어쨌을까 하는 생각이 들기는 했지만 아직까지는 잘 동작하는 PM 조직을 본 적이 없어 어떤 모습으로 동작하는지는 잘 모릅니다. 결국 투자사의 요구사항은 제게 왔고 이 문서를 어떻게 작성해야 할 지 잠깐 고민하기 시작합니다. 이런 일이 생겼음을 알려주신 회사의 운영 부서 담당자님은 혹시 이런 내용을 정리해 관리하는 노션 문서나 구글 스프레드시트 같은 것이 있지 않느냐고 물어 오셨고 저는 머리 위에 물음표를 띄운 다음 지금 우리는 그런 식으로 관리하고 있지 않아 생각하시는 것과 비슷한 문서는 없지만 어쨌든 금방 정리해 드릴 테니 기다리시라고 한 다음 지라를 열었습니다.

우리는 지라를 통해 프로젝트를 관리하고 있습니다. 한때 업계에는 trac, mentis, hansoft 같은 다양한 도구가 사용되었고 또 어떤 회사에서는 ttp라는 전문 BTS 소프트웨어를 사용하기도 했는데 어느새 이 모든 용도를 통틀어 지라가 널리 사용되기 시작했고 지금은 거의 업계 표준이 된 것 같습니다. 지라는 사용 요금이 낮지는 않고 또 단순하고 아름답게 동작하는 소프트웨어와는 거리가 좀 있지만 시스템을 이해한 다음 프로젝트마다 각기 다른 워크플로우를 지라 시스템에 구현하면 아주 다양한 상황에도 잘 대응할 수 있는 커스텀 이슈트래커를 만들 수 있습니다. 또 한때는 프로젝트 구성원들이 이런 도구를 사용해 각자의 업무 현황을 추적 하려는 시도에 불쾌해하거나 저항하는 경우도 있었지만 점차 프로젝트 규모가 커지고 파이프라인이 복잡해짐에 따라 이런 도구 없이 각자의 기억에 의존 하다가는 돌이킬 수 없는 시점에 큰 실수를 저지를 수 있다는 점을 이해하고 이런 시스템 사용에 귀찮아 하더라도 저항하지는 않게 된 것 같아 보입니다.

개인적으로 지라를 사용해 프로젝트를 관리할 때 중요하게 생각하는 점은 적어도 제 선에서는 지라를 특정 시점에는 가장 정확한 정보의 원천으로 만들어 정보의 정확도나 정보의 형태를 바꾸기 위해 다른 도구나 기록의 도움을 받을 필요가 없는 상태로 만들어야 한다는 점입니다. 위에서 저에게 빨리 보고 문서를 만들어야 한다고 말씀해 주신 분 역시 어느 프로젝트에나 있을 법 한 마일스톤 목표를 한 페이지에 목록 모양으로 적어 놓은 페이지나 구글 스프레드시트 하나 정도는 있을 거라고 예상하신 것 같습니다. 이런 문서는 여러 프로젝트에 걸쳐 흔히 사용하는 마일스톤 계획 수립 방법이기는 하지만 일단 마일스톤이 시작되면 이 문서들은 그 역할과 수명을 다 했다고 생각합니다. 우리는 이미 고정된 문서 상의 목록이나 구글 스프레드시트보다 훨씬 접근성이 뛰어나고 여러 사람이 작업하기 훨씬 쉬우며 우리들의 파이프라인을 잘 대변하는 도구를 가지고 있는데 마일스톤이 실행 중일 때 그런 도구에 절대적으로 의존하지 않으면 우리는 그냥 한 명당 한 달에 7달러씩 아틀라시안에 기부하는 거나 다름 없습니다.

그래서 마일스톤 계획을 수립하는 단계에서는 각자에게 편한 여러 문서 형식을 허용하되 일단 마일스톤 계획이 확정되고 이를 실행하기 시작하면 지금까지 사용했던 문서의 요구사항은 모두 지라에 에픽 모양으로 옮기고 이 시점부터는 지라를 단 하나 뿐인 신뢰할 수 있는 현황의 원천으로 만들기 위해 최선을 다합니다. 먼저 일정을 제어하는 다른 문서의 존재를 최소화 해야 합니다. 사람에 따라 지라가 보여주는 일정 형식에 익숙해지기 어려워 하는 분들이 있는데 이런 분들의 생산성이 이 정도의 비효율을 감안할 만큼 훌륭하다면 대신 지라를 업데이트 하고 이 분이 익숙해 하시는 모양으로 업무 목록과 일정을 제시할 수 있습니다. 하지만 그렇더라도 이 정보는 지라 쪽이 우선시 되어야 합니다.

또 지라에 등록된 업무는 존재하는 업무 이지만 지라에 등록되지 않은 말로만 전달된 업무는 그 업무가 심지어 고위 의사결정자나 그보다 더 높은 알 수 없는 먼 곳에서 온 것이라 할지라도 존재하지 않는 것이나 다름 없는 취급을 해야 합니다. 이런 자잘한 상황을 허용하면 지라는 순식간에 신뢰할 수 있는 정보의 원천에서 업데이트 되지 않은 오래된 글자를 저장한 의미 없이 돈을 지출하게 만드는 시스템과 다르지 않게 됩니다.

자. 이런 상황에서 지난 짧은 서비스 이후 우리가 해 온 일은 이번 마일스톤의 에픽 목록에 나열 되어 있었고 아무래도 이 목록을 그냥 복붙 해서 보내는 건 또 좀 아닌 것 같아 외부에서 보기에 그리 나쁘지 않은 문서 모양을 만들기로 결정하고 에픽 목록을 CSV 형식으로 내보낸 다음 엑셀로 열어 태스크 이름의 현재 상태를 복사해 노션에 붙여 넣고 문서를 작성하기 시작했습니다. 그런데 에픽 목록은 우리가 이번 마일스톤에 개발하고 있는 모든 기능을 나열하고 있기는 하지만 팀 밖에 있는 각 에픽의 목록을 모르는 사람들이 이를 본다면 에픽 이름과 그 이름에 의해 실제로 일어나고 있는 일을 잘 이해하지 못할 수 있습니다. 그래서 각 에픽에 의해 일어나게 될 짧은 플레이시나리오를 언급하거나 반대로 한 가지 플레이시나리오를 달성하기 위해 어떤 여러 에픽을 진행하고 있는지 에픽 별로, 그리고 플레이시나리오 별로 서술해 문서를 작성합니다.

하지만 저는 지금까지 개발팀에 더 가까운 쪽에서 더 오래 일했고 고위 의사결정자나 그보다 더 높은 분들과 가깝게 일한 경험은 더 적습니다. 가령 큰 회사에서 반기 마다 수행하는 아주 중요한 경영진 보고를 준비할 때 보고에 필요한 기능을 실제로 개발하고 기능의 맥락을 팀 내 의사결정자들에게 설명하고 문서를 작성할 자료를 만드는 일은 제가 수행했습니다. 그런데 이 정보들을 모아 회사의 방향성과 일치하는 관점에서 프로젝트를 바라보고 프로젝트 안에서 일어난 일을 설명할 전략을 세우며 이에 따른 아름다운 시각 자료와 설명 방식을 만드는 일은 저보다 높은 분들이 주로 수행하는 일이었습니다. 제가 이분들께 제출한 업무 결과물과 여러 텍스트, 그리고 이미지는 상당히 다른 서술 방식으로 재가공되어 보고 자료에 포함되곤 했는데 종종 최종 발표 자료를 검토하며 제가 일하고 또 일을 관리하는 방식과 경영진이 일을 바라보는 방식 사이에는 상당히 큰 차이가 있다는 사실을 깨달았습니다.

이번 마일스톤에 우리가 만든 에픽은 에픽을 담당자들에게 할당하기 편한 방식으로 만들었습니다. 그래서 에픽 하나 단위로 정확한 플레이시나리오를 언급하기 어려운 에픽도 만들어졌습니다. 이는 좋지 않은 태스크 이름에 사례를 든 것과 비슷한 에픽 이름만 봐서는 이게 정확히 무슨 일인지 이해할 수 없는 형태의 이름이었는데 마음에 들지는 않았지만 담당자 단위로 할당하기에는 이런 모양이 편하다는 점을 인정해 마음에 안 드는 이름이라도 그냥 놔뒀습니다. 가령 [M6] 채팅 같은 에픽 이름은 ‘아. 이번 마일스톤이 끝나면 인게임에서 채팅을 할 수 있나보다’ 하고 직관적으로 이해할 수 있습니다. 반면 [M6] 전투 (PC)나 [M6] 전투 (몬스터)는 에픽 이름만으로 목표를 직관적으로 이해하기 쉽지 않습니다. 흔히 전투라고 말하는 코어메커닉은 플레이어, 다른 플레이어, 몬스터, 무기 등 서로 다른 다양한 요소가 상호작용 하는 가운데 완성됩니다. 그런데 만약 이를 [M6] 전투 같은 이름으로 뭉개고 플레이시나리오를 설명하면 보다 직관적으로 이해할 수는 있지만 그러면 이 에픽을 누가 담당하게 할 지가 모호해질 수 있습니다.

만약 프로젝트 규모가 훨씬 크고 흔히 ‘전투팀 팀장’ 같은 분이 있어 조직을 통제할 수 있다면 이런 식으로 에픽을 발행할 수 있습니다. 그런데 프로젝트 규모가 작고 코어 메커닉을 담당할 부서 규모 역시 작다면 모호하지만 직관적인 에픽 이름을 통한 목표 관리는 위험 부담이 있습니다. 차라리 플레이어 만들 담당자에게 전투 (PC) 에픽을 맡겨 어쨌든 플레이어의 모든 기능 개발을 담당하게 만들고 전투 (몬스터) 에픽은 몬스터를 조립 담당자에게 맡겨 어쨌든 적당한 시점에 레벨디자이너가 배치 가능한 몬스터들을 사용 가능하게 만들어지는데까지 담당하게 만들면 각각의 에픽은 직관적으로 이해하기 어려워지지만 담당자 단위로 에픽을 잘라 진행 시키고 이들이 상호작용을 일으키는 부분은 프로젝트를 관리하는 관점에서 통제할 수 있게 됩니다.

일단 이런 모호한 에픽 이름을 그대로 둔 채로 보고 문서를 재빨리 완성해 초안을 전달했는데 이어 이전에 경영진 보고 경험이 있는 분이 이를 받아 내용을 재구성하는 모습을 보니 여전히 저는 이런 보고 문서를 작성하기에는 경영진 수준의 고위 의사결정자들과는 멀고 개발팀에는 더 가까운 위치에 있다는 사실을 절감할 수 있었습니다. 가령 신규 필드 제작은 근본적으로 신규 게임모드를 위한 것이어서 개발에 가까운 저는 이들을 신규 게임모드로 묶어 이 플레이시나리오를 달성하기 위한 여러 가지 에픽이라고 설명했지만 더 높은 곳으로 올라가야 하는 보고서는 이런 설명 방법을 사용하지 않습니다. 신규 게임모드는 그게 무엇이든 그 양으로 포장 되었는데 이번 마일스톤에 우리는 서로 다른 신규 게임모드 2종을 개발할 예정이고 각 게임모드에는 서로 다른 신규 레벨 2개가 제작되어 대응하고 있다는 식으로 서술되었습니다. 몬스터 역시 제 관점에서는 이번 마일스톤에 코어 메커닉 대부분을 구축해 새 필드에 어울리는 몬스터와 싸울 수 있으면 된다고 생각한데 비해 ‘신규 몬스터 8종’ 처럼 수량에 중점을 둬 수정되었습니다. 또한 몬스터는 일반 몬스터와 보스 몬스터 사이에 제작 비용에 큰 차이가 있기 때문에 이들을 구분해 각각의 수량을 언급하기도 했습니다.

이렇게 수정된 제출용 문서에는 우리가 실제로 수행하고 있는 에픽 목록과는 약간 차이가 있는 여러 가지 항목과 각각의 목적과 수량을 언급한 일종의 기간 대비 효용을 언급하는데 가까운 내용이 되었습니다. 소프트웨어 개발 프로젝트의 일정 예측에 대한 의견에서 경영진이나 고위 의사결정자들은 ‘그래서 이 기능은 앞으로 며칠 안에 완료되는가’라고 질문하지만 저는 그런 질문 형태가 소프트웨어 개발의 실상과 어울리지 않는다고 이야기한 적이 있지만 그런 현실은 달라지지 않을 것이기에 결국 우리가 기록하고 운영하는 방식은 지금 상태를 유지하더라도 이와 유사한 경영진으로부터, 고위 의사결정자로부터, 그리고 그보다 높은 저 아득한 알 수 없는 곳으로부터 온 상태 확인 요구에 이 분들이 요구하는 방식에 따라 상황을 설명하는 연습을 해야겠다는 생각이 들었습니다.

제가 개발팀과 제품 관점에서 중요하다고 생각한 맥락은 위로 올라갈 수록 항목과 수량으로 바뀌고 업무 난이도는 기간에 가까운 모양으로 바뀌며 내용의 중요도가 바뀌었고 오래 전에는 이런 점이 불만 이었다면 이제는 어떻게든 이런 의사소통 방식의 차이에 적응해야 할 것 같습니다.