많은 분들이 원대하게 계획만 세운 채 실행하지 못해 일을 그르치고는 하죠. 게임개발 역시 마찬가지입니다. 계획만 가지고 게임이 스스로 만들어지지는 않습니다. 누군가는 이 계획이 잘 실행될 수 있도록 옆에서 도와줄 수 있어야 하죠. 게임개발PM이 하는 일이 바로 그런 일입니다.
그렇다면 게임개발PM은 구체적으로 어떤 일을 하고, 또 게임개발PM이 되기 위해서는 어떤 역량을 갖추어야할까요? 오늘 강연에서는 <야생의 땅: 듀랑고>를 개발한 왓 스튜디오의 이해봄(본명 안광섭) PM이 3년간 게임개발PM으로 일하며 느끼고 익힌 바를 모두와 공유했습니다.
개발 PM 이라는 직군이 생소한 분들도 계실 겁니다. 한편 '매니저'라는 직업은 익숙하시리라 생각합니다. 특히 요즈음은 연예인 매니저를 주제로 한 TV 프로그램도 있으니까요. PM은 프로젝트 매니저의 약자입니다. 똑같이 '매니저'이기도 하고, 사실 PM이 하는 일과 연예인 매니저가 하는 일은 크게 다르지 않습니다.
연예인 매니저가 하는 일을 볼까요?
"연예인 매니저는, 연예인이 한정된 시간에 최대의 효율을 낼 수 있게 해주는 직업으로, 연예인의 스케쥴을 관리하고, 새로운 출연 프로그램을 잡아주고, 연예인 섭외 요청에 대응하는 일을 합니다."
자, 위의 문장에서 연예인을 프로젝트로 바꾸면, 프로젝트 매니저가 하는 일이 됩니다.
"프로젝트 매니저는, 프로젝트가 한정된 시간에 최대의 완성도를 낼 수 있게 해주는 직업으로, 프로젝트의 스케쥴을 관리하고, 새로운 일감을 잡아주고, 일감 추가 요청에 대응하는 일을 합니다."
그렇다면 프로젝트 매니저가 필요한 이유는 무엇일까요? 그것은 바로 '계획 오류'와 '호프스태터의 법칙', 그리고 '낙관적 편향' 때문이라고 강연자는 말합니다.
'계획 오류'란 "앞으로 닥칠 일에 대한 낙관적인 전망 때문에 실제 계획했던 일보다 더 많은 비용과 노력이 들어가는 오류"를 의미합니다. '호프스태터의 법칙'은 "일을 마치는데 예상한 것보다 더 오랜 시간이 걸리는 현상"을 말하죠.
이렇게 길게 풀어 설명하면 어렵지만, 우리는 모두 계획 오류와 호프스태터의 법칙을 경험하며 살아왔습니다. 바로 학교 숙제나 교수님이 주신 과제를 할 때 말이죠. 예를 들면 기자는 이 기사를 오늘 8시까지 끝내고 9시에 하는 <어벤저스: 엔드 게임>을 보러 가고 싶었습니다. 하지만 저는 오늘 영화를 보기는 커녕 9시까지 기사를 쓰고 있죠.
그렇다면 우리는 왜 이렇게 업무 완료 시간을 예측하지 못할까요? 강연자는 여기서 학자 로저 뷸러의 연구를 인용했습니다. 로저 뷸러는 사람들이 업무 완료 시간을 예측하지 못하는 문제의 원인을 파악하기 위해, 자신의 학생들에게 논문 작성에 걸리는 시간을 예측해 제출하도록 시켰습니다. "최선의 예상", "낙관적 예상", 그리고 "비관적 예상", 이렇게 3가지 시간을 적어달라고 했죠.
학생들은 모든 일이 잘 풀린다면 27.4일, 최선의 조건일 때 33.9일, 모든게 엉망이더라도 48.6일 정도 걸릴 것이라고 예측했다고 합니다. 하지만 실제 학생들이 논문 작성에 쓴 시간은 평균 55.5일이었으니, 최악의 경우와 비교해도 무려 일주일이 넘게 차이가 난 것이죠.
로저 뷸러는 이것을 "소망적 사고로 인한 낙관적 편향" 때문이라고 설명합니다. 다시 말해 사람들은 자기도 모르게 자신의 업무 계획에 대해서 낙관적으로 추측하는 경향이 있다는 것이죠. 특히 자신의 소망에 따라서 말입니다.
그런데 여기서 게임 개발로 돌아와봅시다. 회사에서는 정말로 다양한 직군의 사람들이 다양한 이해 관계 속에서 충돌하면서 업무를 진행합니다. 그런데 이 사람들이 하나하나 직접 계획을 세우고 관리하면, 모두가 낙관적으로 계획을 세울 것이고, 그렇게 된다면 프로젝트는 제 시간에 진행되지 못할 것이 뻔합니다.
그렇기 때문에 필요한 것이 바로, 이 모든 사람의 계획과 일정을 조정해주고, 프로젝트의 방향을 설정해줄 사람, 프로젝트 매니저인 것입니다.
그렇다면 게임 개발 프로세스에서 PM이 하는 일은 구체적으로 무엇일까요? 강연자는 복잡한 게임 개발 프로세스를 간단히 (1)디자인&기획, (2)담당자 지정 및 개발 계획 수립, (3)개발 진행, (4)배포 및 후속조치의 4단계로 나눠서 설명했습니다.
우선 첫 번째인 디자인&기획 단계에서 PM이 하는 일은 주로 문서화를 요청하는 일입니다. 기획자들이 아이디어를 내면, 그것은 아이디어일 뿐 구체적으로 실현하기는 어려운 상태로 있습니다. PM은 이것을 '기획문서'라는 문서 형태로 만들라고 요청합니다. 그리고 이 기획문서는 실제 실무자들이 작업에 투입할 수 있는 수준이 되어야 하죠.
하지만 실제 기획의 구현은 모두 시간 소모가 큰 일입니다. 따라서 PM은 이 문서를 기준으로 업무들을 S, A, B ,C의 4단계로 우선순위를 나누어줍니다. 이렇게 정하는 이유는 나중에 일감이 충돌할 때에 도움이 되기 때문입니다. 우선순위를 설정하고 나면, WBS, Work Breakdown Structure에 따라서 다시 나눕니다.
WBS는 쉽게 말해서 하나의 목표를 가진 업무를 실행 가능한 임무(task)의 단위로 쪼개고 쪼개어 배분하는 것입니다. 위 사진은 강연자가 공개한 WBS의 예시입니다. 작업이 세세하게 나뉘어 있고, 담당자, 시작일, 종료일이 표시되어 있죠. 이렇게 WBS에 따라 업무를 나누고 분배하는 일도 PM의 몫입니다.
이렇게 업무 분할이 끝나고 나면 (2) 담당자 지정 및 개발 계획 수립 단계로 넘어갑니다. 이 단계에서 PM은 '일감 회의'를 거쳐 앞 단계에서 분할된 작업들을 실제로 담당자들에게 배치하고 기간을 확정합니다.
여기서 중요한 것은 '버퍼', 즉 여유기간입니다. 강연자는 주로 버퍼를 전체 작업일의 절반 정도로 설정한다고 합니다. 예를 들어 작업일이 20일이면, 그 중에 10일은 버퍼로 설정하는 것이죠. 생각보다 버퍼를 소모하게 되는 이유는 다양합니다. 갑자기 직원이 휴가를 갈 수도 있고, 긴급한 건강 문제가 발생할 수도 있죠. 그렇기 때문에 전체 작업일의 절반은 결코 많은 양이 아닙니다.
여기서 강연자는 '문서화'의 중요성을 역설했습니다. 문서화를 잘 하면 잘 할 수록 전체 커뮤니케이션에 소모되는 시간이 줄어들고 업무를 효율적으로 진행할 수 있기 때문입니다. 뿐만 아니라 현재 팀이 마주한 기술적 한계와 제약도 명확하게 판단할 수 있고, 변수를 줄이는 데도 도움을 주죠.
이제 본격적으로 개발이 진행되면, 작업자들도 바빠지지만 PM도 더욱 꼼꼼한 업무 수행이 요구됩니다. 개발 진행 과정에서 모든 개발자들은 낙관적인 전망을 가지게 됩니다. 앞서 설명한 '계획 오류'의 사례처럼요. 하지만 현실은 그렇지 않습니다. 앞서 말한 팀원의 건강 문제를 비롯해 기획의 변경, 버그의 발생, 디버깅 등 여러가지 변수가 있기 때문입니다.
이 과정에서 PM은 주로 "체크하기"와 "이삭 줍기" 업무를 수행하게 됩니다. 체크하기는 말 그대로 앞서 한 기획 및 일감회의 단계에서 정해진 것들이 잘 진행되고 있는지 파악하는 것입니다.
문제는 PM이 업무 진행 상황을 체크하는 것을 작업자는 일종의 감시처럼 받아들일 수도 있다는 점입니다. 작업자가 PM을 감시자로 여기게 되면, 작업자는 나도 모르게 방어적으로 행동하게 되고, 본의 아니게 문제가 있어도 문제가 없다고 하는 등 거짓말을 하게 되죠.
그래서 PM에게 중요한 것은, 자신이 감시자가 아니라 앞으로 갈 길을 알려주는 길잡이라는 것을 어필하는 것입니다. PM의 업무 체크를 방해로 받아들이지 않도록 하는 것이죠. 특히 작업 중 문제가 발생했을 때, PM에게 조언을 구하면 문제가 해결된다는 인상을 주는 것이 중요하다고 강연자는 설명합니다.
두 번째로 이삭 줍기는, 전체 작업을 진행하면서 중간 중간 빠트리거나 흘린 작업들을 챙기는 일입니다. 앞서 말한 우선순위 경쟁에서 밀리는 등 여러가지 이유로 배분해놓은 작업들이 누락되는 경우가 생각보다 자주 발생합니다. 작업자는 일을 이미 해놨다고 생각해서 놓치고, 디자이너는 이미 문서를 보냈으니 끝났다고 생각해서 놓치는 등, 서로가 작업의 완성 여부를 챙기지 않는 '그레이 존'으로 빠지게 되는 거죠.
PM은 마치 이삭을 줍듯, 이런 일들을 잘 주워놨다가 다음 일감 회의에 다시 상정하고, 추후 업데이트나 폴리싱 과정에서 언급해주며 작업이 누락되지 않도록 도와주는 역할을 수행합니다. 특히 이삭 줍기를 통해 누락된 일들을 진행되게 만들었을 때에 개인적으로 뿌듯함을 느끼기도 한다고 강연자는 밝혔습니다.
마지막 4단계는 유저들에게 게임을 선보이는 단계입니다. 이 시점에서 담당 PM들은 자기가 맡은 게임의 빌드에 대해서 누구보다 더 잘 아는 사람이 되어 있습니다. WBS를 통해 업무를 배치하면서 무슨 일이 시작되고 끝났는지를 항상 보고 있었기 때문이죠.
그래서 유저들이 흔히 보는 공지사항도 PM들이 WBS를 보고 작성하게 됩니다. PM이 초안을 작성해서 운영팀에 전달하면, 운영팀이 유저들이 더 읽기 좋은 형태로 변경해서 업로드를 하게 되죠. 또 모두가 잘 아는 4대 명검, 점검의 진행도 PM의 역할입니다. 버그나 문제가 발생했을 때, 자기가 직접 그걸 고치지는 않지만, 해당 조치가 진행될 수 있도록 선도하는 역할을 수행합니다.
그렇다면 개발PM이 되기 위해서는 어떤 역량을 갖춰야 할까요? 강연자는 개인적으로 "이과예요, 문과예요?"라는 질문을 많이 듣는다고 말했습니다. 다시 말해, '개발' PM이니까 '개발'을 할 줄 알아야한다는 생각이 있는 것이죠.
강연자는 개발PM에게 있어 개발 능력은 "영어"와 비슷하다고 설명했습니다. 영어를 잘하면 여러가지 다양한 기회를 얻을 수 있지만, 생활이 불가능한 것은 아닙니다. 개발PM에게 있어 개발 능력도 마찬가지입니다. 그렇기 때문에, "영어를 할 줄 아는 만큼 개발 실력도 갖춰라."라고 강연자는 조언합니다.
그 외에 개발PM이 가져야하는 역량을 강연자는 크게 4개로 표현했습니다. 맥락적 이해, 새로운 지식 습득 능력, 신뢰 주기, 그리고 타협하기 입니다.
맥락적 이해는 업무적 맥락을 이해하는 능력을 뜻합니다. 맥락적 이해 능력은 전체 상황을 구조화해서 원인을 파악하고 또 문제를 해결하는 데에 도움을 줍니다. 업무적인 영역에서 뿐만 아니라 자기 일상의 영역을 어떻게 기록해서 개선했는지 보여주는 사례도, 신입 PM을 뽑을 때 좋은 포트폴리오로 참고한다고 강연자는 밝히기도 했습니다.
새로운 지식 습득 능력은 제네럴리스트(Generalist), 즉 모든 일을 두루두루 할 줄 아는 사람이 되어야 하는 PM에게 필요한 능력이라고 할 수 있습니다. 한 사람이 모든 일을 다 잘할 수 있으면 좋지만, 그건 너무 많은 시간이 소모되는 일이겠죠. 하지만 PM은 다양한 직군과 함께 일해야만 하는 자리입니다. 그 분야에서 전문가 정도의 지식을 요구하지는 않지만, 어느 정도의 소통은 가능한 수준이 되어야하겠죠.
PM이 신뢰를 줄 수 있어야하는 이유는, 본의 아니게 거짓말을 하게 되는 경우도 많기 때문입니다. 분명 언제까지 이 작업이 끝날 것이라고 업무를 배치해놨는데, 예상치 못한 변수로 일감이 막 발생하는 경우, 작업자에게 추가로 업무를 주는 일은 어쩔 수 없겠죠.
그렇기 때문에 PM은 이유를 잘 설명할 수 있어야하고, 중간 중간 앞으로 발생할 수 있는 변수에 대해서 계속 언급해주면서 작업자와 신뢰를 구축할 수 있어야 합니다. 바로 도착한다고 해놓고 말없이 지각하는 친구와, 길이 막혀서 조금 늦을 수도 있다고 말하고 5분 늦는 친구에 대해서 우리가 느끼는 감정이 다르듯이 말입니다.
마지막 타협하기는 조금 생소할 수도 있겠습니다. 여기서 강연자는 버스 팩터라는 개념을 이야기했는데요. 버스 팩터는 특정한 수의 개발자가 작업에 참여하지 못하게 되었을 때에 프로젝트가 진행될 수 있느냐 여부를 말하는 숫자입니다. 예를 들어 개발자 1명이 버스 사고를 당해 개발에 참여하지 못하게 되면, 그 프로젝트의 버스 팩터는 '1'인 식이죠.
이러한 버스 팩터, 여러가지 외부적 변수들은 마음대로 조절할 수 없는 일입니다. 그렇기 때문에 PM에게는 때때로 원래 작업 계획이나 일정과 타협해야하는 경우도 발생합니다. 하지만 프로세스를 만들어 나가는 직군인 PM이 계속해서 타협해버리면 일이 진행되지 않겠죠. "에이, 한번만 해줘."하는 식으로 구두로 업무를 진행하다보면 프로젝트가 방종에 빠지기 마련입니다.
따라서 일의 우선순위와 전체 작업의 히스토리를 잘 문서화해놓고, 타협해야할 때에 문서화된 것을 잘 보면서 설득력을 확보, 작업자에게 잘 전달하는 일이 중요할 것입니다.
개발 PM은 그 어떤 직군보다도 다양한 직군과 매일 같이 이야기하고 또 새로운 것을 배울 수 있는 직군입니다. 사람에 따라서 정말 재미있을 수 있는 일이고, 강연자 역시 스스로 이 일을 매우 즐겁게 하고 있다고 밝히기도 했습니다.
하지만 실제로는 많은 프로젝트가 PM 없이 진행되고 있다고 합니다. 강연자는 이번 강연을 빌어 "많은 분들이 PM의 필요성을 느끼는 기회가 됐으면 좋겠다"는 자신의 소망을 밝히며 강연을 마무리했습니다.
