많은 PM들과 일을 하다 보면 다양한 성향의 업무 스타일을 경험 할 수 있다. PM마다 장단점이 있고 배울 점들이 있다. 직접 경험도 했었지만 성공이란 결과를 갖는 PM은 극히 일부임은 틀림없는 사실이다. 게임을 개발하고 성공시키기 위해서 많은 업무경력이 출중한 분들이 PM으로 기회를 얻고 개발을 한다. 경영자는 이러한 PM을 어떻게 잘 선택하고 기회를 주어야 하는지 기준을 갖는 것이 개발사의 운명을 가늠한다는 사실을 알아야 한다.  각각의 PM의 성향을 기록에 남기고 정리해 보니 크게 두 가지로 정리 할 수 있었다. 

 

 가장 대표적인 케이스 중 하나가, 편 나누기와 같은 정치적 성향이 강한 PM들이다. 이런 PM은 현업에 종사하고 있거나 종사했던 사람이라면 한 두 번씩은 경험해 봤을 것이다. 경험이 부족한 경우에 대부분 이런 실수를 많이 한다. 경험이 없는 사람이 프로젝트 개발 책임자이다 보니 냉철한 판단을 못하고 주위 영향을 받게 되면서 개발적인 이슈에 신경 쓰는 것이 아니라 개발 외적인 부분에 시간 투자를 하게 된다. 결과는 항상 좋지 않았다. 그렇다고 사내의 정치가 필요 없다는 것은 아니다. 필요에 따라 할 수 있다. 말장난일 수 있지만 원래 정치는 조직이 있는 곳에는 반드시 있기 마련이다. 이런 정치가 조직을 망가뜨리는 정치인지 아니면 조직을 살리는 정치인지가 중요하다. 단순히 정치적 스킬 만을 가지고 PM이 개발을 이끈다면 정치는 물론이거니와 개발을 망칠 수 있다. 반면 프로젝트의 성공을 위해서 자원 동원이나 협상을 한다던가 혹은 설득을 하기 위한 정치는 포괄적인 이득을 가져올 수 있으므로, 이는 조직을 살리기 마련이다. 이런 정치는 사실 개발 중에 필요한 경우가 많다. 하지만 이러한 정치보다는 전자에 말한 조직을 망칠 수 있는 정치가 문제되는 것이다. 이런 경우는 대부분 프로젝트를 너무 과하게 포장하려 하거나 실수나 문제를 감추기 위해서 시작된다.

 

또 한 분류는 바로 갈대 같은 성향을 갖고 있는 PM들이다. 줏대 없이 다른 사람의 의견을 받아들이다 보면 게임의 전체적인 틀이 점점 틀어지게 된다. 이는 프로젝트의 게임성뿐만 아니라, 외적인 프로젝트 관리 부분에도 해당되는 부분이다. 경험과 지식을 바탕으로 소신과 신념으로 받아드릴 점과 받아들이지 못하는 것을 잘 구분해서 업무를 해야 하는데 그러지 못한 경우 문제가 된다. 사공이 많으면 배가 산으로 가는 것처럼 PM이 주위에 휘둘리게 되면 해당 개발팀만이 피해를 보는 것이 아닌 결국 개발사 전체에 피해를 주는 것을 잊어서는 안 된다.

 

일반적인 프로젝트 관리자의 역할에 대해서 정리를 잘한 “’MBA가 회사를 망친다.(2009년8월)’는 자극적인 제목으로 책을 출판해서 경영학계를 떠들썩하게 했던 캐나다 맥길대학의 헨리 민츠버그(Henry Mintzberg)를 인용하면 아래와 같다.

 

일반적인 PM의 역할은, 주어진 프로젝트를 성공적으로 완료하는데 필요한 제반 의사결정을 주도하고 관련 프로세스를 이끌어 가는 사람이다. 물론 게임 개발 프로젝트에도 PM이 있고, 프로젝트를 총 지휘한다는 점 역시 동일하다. 개발 총 지휘자인 PM은 프로젝트 진행에 대해 많은 권한과 책임을 가지고 있으며, 게임 개발의 가장 중추적인 위치에 있는 자리이다. 보통 MMORPG을 기준으로 한 개 프로젝트 당 최소 20명에서 100명 내외의 인원으로 구성된다. 개발 PM은 이 인원 전체를 통솔하며 개발을 해야 하고, 개발 진행 도중 발생할 수 있는 이슈에 대한 처리 판단도 해야 하는 등 역할이 막중하다. 간혹 PM과 PD의 역할이나 책임에 대해서 혼동되는 경우가 많다. 이것은 게임 개발사마다 조금씩 달리 역할을 가져가고 있기 때문이다. 필자는 일반적인 PM의 어떠한 것인지 짚어보고자 한다. 따라서 명칭보다는 역할에 대한 이해로 보는 것이 더 적절할 것이다.

 

우선 게임 개발에 특화된 PM과 PD의 역할과 책임에 대해서 정리했다.

위의 표와 같이 역할의 차이를 구분 할 수 있다. 하지만 문제는 이러한 PM의 역할을 제대로 수행하지 못하는 경우가 많다는 것이다. 이는 어떤 역할을 해야 하는지 잘 알지 못하거나, 혹은 알더라도 잘못 이해하여 적절치 못한 역할을 하는 경우가 많다. 앞에서 잠깐 언급했지만 예를 들어서 PM의 독단으로 인해서 개발자들이 진행하던 게임의 방향성을 흔들리거나 아예 잃어버리게 만드는 경우도 있고, 혹은 정확한 계획 및 산출 없이 주먹구구식으로 개발을 진행하여 개발비용 낭비를 불러 일으키는 경우도 있다. 또는 개발자들 간 적절한 조화를 이루도록 이끌지 못해서, 결국은 인력 이탈로 인해 개발이 지연되는 경우도 있다. PM의 역할에 대해서 잘 알지 못한 채, 단순히 개발자로써 혹은 개발을 지켜본 사람으로써의 경험만으로 PM의 역할을 하려 하기 때문이다.

위와 같은 경우, PM의 지식과 관리 능력이 떨어진다는 점에서 문제는 시작된다. PM의 기본 수행 능력은 시작된 프로젝트에 대하여 본인이 아이디어를 냈고, 가장 잘 알고 있다고 해서 할 수 있는 것이 아니다. 앞의 표에서 나와있듯이 개발 전체적인 모습을 통해서 모든 것을 책임져야 하는 자리이다.

 

PM이 되기 위해서는 어떠한 자격증이나 제한 등이 있는 것은 아니다. 개인의 역량에 의해서 개발 경험은 적더라도 PM이 될 수 있다. 그러나 개발 프로젝트를 진행함에 있어 적합한 PM 선택을 위해서는 기본 소양과 능력이 갖춰져 있는지 확인해야 한다. 따라서 지금부터 프로젝트가 성공하기 위해 어떤 PM을 선택할 것인지를 알아볼 것이다. 프로젝트가 성공하기 위해서는 아래 5가지 예시 중 적어도 세가지 이상은 갖고 있어야 개발 PM으로서 프로젝트를 이끌 수 있는 역량과 자질을 가졌다고 할 수 있을 것이다.

최소 2년 이상 서비스를 해본 적이 있는가 (풀 사이클링)

새로운 개발 프로젝트가 시작되고 상용 서비스가 되기까지 짧게는 3년, 길게는 5-6년의 시간이 걸린다. 대부분의 개발자는 프로젝트 중간부터 참여하거나 혹은 상용 서비스를 앞두고 팀에 합류하는 경우가 많다. 그리고 개발 초기 멤버로써 처음부터 프로젝트 개발에 참여하고 상용 서비스까지 풀 사이클로 진행해본 경험을 가진 개발자는 의외로 많지 않다. 이유는 초창기 멤버라고 할지라도 여러 가지 상황으로 인해서 이탈하게 되는 경우가 많다. 온라인 게임의 개발특성상 개발기간이 오래 걸리고 그 안에 발생할 수 있는 이슈도 많다. 처음에 생각했던 것과 다른 프로젝트의 진행 방향이나, 팀 내 인간 관계, 혹은 개인적인 사정 등으로 인해 팀을 떠날 수 있는 이슈는 무궁무진하다. 이렇듯 처음부터 끝까지 프로젝트를 몇 년간 지속하는 것이 쉬운 것은 아니다.

 

또한 개발 초기부터 상용 서비스까지 해당 프로젝트를 진행했다고 하여 프로젝트의 사이클을 전부 경험했다고 보기는 어렵다. 상용 서비스 시작 이후 약 2년 간 서비스를 지속하면서 최소한 4회 이상의 대규모 업데이트를 해 봐야 개발과 서비스까지 풀사이클을 경험했다고 볼 수 있다. 유저의 요구 사항을 분석하고 이에 대한 적절한 업데이트를 내놓는 것이야 말로 서비스에 얼마나 잘 대처하는지를 보여준다. 이런 부분을 경험하지 못했다면 이는 성공한 프로젝트를 경험한 것이 아니라 게임 개발만 진행한 것이나 다름 없기 때문이다. 개발에서부터 서비스까지의 일련의 활동을 경험한 PM이라면 서비스 중 발생한 문제에 대한 해결 및 대처 방안에 대해서 알고 있다. 서비스 중 중대한 문제가 발생하였을 때 현명한 선택으로 문제를 처리하는 것은 PM의 노하우에 의해서 결정되는 일이 많기 때문이다. 같은 종류의 문제가 발생했을 때, 경험을 해본 PM과 경험해보지 못한 PM의 대처 시간이나 해결 방법에 대한 결정은 차이가 있을 수 밖에 없다. 또한 경험으로 쌓인 노하우를 개발단계에 미리 적용 개발함으로써 유저가 느끼는 퀄리티가 높아 질 수 있다.

PM은 사람을 끌어들이는 힘이 있는가

게임은 혼자 만들 수 있는 것이 아니다. 어느 개발사의 프로젝트도 다 그렇겠지만 게임개발은 특히나 자기분야가 확실히 나뉘어 있기 때문에 다른 영역의 업무를 대신하기는 매우 어려운 부분이다. 따라서 프로젝트를 담당하는 인력 모두가 맡은 역할과 책임에 따라 개발을 해야 한다. 이 때 PM이 인성이 어떠한지에 대한 사항도 매우 중요하다. 여기서 말하는 인성이란 사람 좋고 나쁨을 말하지는 않는다. PM, 다시 말해서 프로젝트의 리더는 팀원에게 자신을 신뢰하게 만들 수 있는 믿음을 줘야 하며, 끝까지 프로젝트를 이끌고 나가겠다는 책임감과 비전이 있어야 한다. 이것이 바로 PM의 인성이라 할 수 있다.

예전에  프로젝트 진행 중 개발자의 반수 이상이 대거 퇴사를 하는 경우를 본 적이 있었다. 이유는 바로 PM의 독선적인 행동 때문이었다. 무조건 자신이 옳다는 잘못된 신념으로 인하여 발생한 일이었다. 개발자들이 프로젝트를 이탈하면서 어떠한 생각을 가지고 이탈 했는지 이야기를 들어보았을 때, 다음에는 결코 그 PM과 함께 일 하지 않을 것이 예상된다.

 

보통 회사마다 다르겠지만 프로젝트를 시작할 때 소위 말하는 핵심인력으로 인원을 구성한다.핵심 인력의 구성은 전적으로 PM의 능력이다. 적절한 핵심인력을 다른 회사나 다른 분야에서 끌고 오는 것도 바로 PM의 능력이다. 하지만 위에서 말한 인성을 갖고 있지 못할 때, 어떠한 개발자도 그 PM을 신뢰하고 일하려 하지 않을 것이다.

개발사 입장에서 프로젝트의 출범 가부를 결정할 때 핵심인력의 프로필이 중요한 데이터가 되기도 한다. 그만큼 인원 구성이 중요하다. 따라서 필요한 인력을 적재적소에 투입하고 결과를 만들어 내는 능력 또한 PM의 능력이다. 그러나 이러한 인성을 갖고 있지 못할 때는 좋은 인력을 자신의 프로젝트에 포함시킬 수 없다.

PM이 갖춰야 할 전문 지식이 있는가

PM은 프로젝트를 이끄는 리더의 역할을 한다. 그 역할을 잘하기 위해서는 리더의 역할 뿐만 아니라 이 역할을 잘 할 수 있도록 받쳐줄 수 있는 지식도 매우 중요하다. 다시 정리하면 전문적인 프로젝트 관리 능력을 갖고 있어야 한다는 뜻이다. 만약 PM의 역할을 하는 것이 목표라면 이에 관련된 지식이나 자격증 등을 공부하는 것도 필요하다. 요즘은 다른 업계에서도 많이 취득하던 프로젝트 관리에 대한 자격증인 PMP(Project Management Professional) 등을 게임 업계에서도 많이 따는 추세이다. PMP 관련 정보 사이트나 서적 등은 주변에서 쉽게 찾아볼 수 있다. 간단히 몇 가지 소개하자면 아래와 같다.

<>ü<>èhttp://www.pmi.org/

<>ü<>è<>è물론 자격증이 있어야지만 PM의 능력이 있다고 말할 수는 없다. 하지만 프로젝트 관리에 대한 지식을 얼만큼 알고 있는지에 따라 프로젝트 운영에 도움이 될 수 있기 때문에 꼭 자경증 취득을 위한 공부가 아니더라도 지식을 얻기 위한 공부는 필요하다.

 

표를 보면 알 수 있듯이, 프로젝트 관리에도 여러 분야가 존재하고 있다. PMP에 대한 주요 지식은 없더라도 왜 위와 같이 분야를 나누어 관리를 하는지에 대해서는 알고 있어야 한다. 본연의 역할과 기능들을 이해 못할 경우 잘못된 의사결정을 할 수 있기 때문이다.

 

위의 내용 중에서 흔히 실수하는 부분이 리스크 관리 부분이다. 경영자 입장에서는 프로젝트가 잘 진행되고 있는지, 혹은 안되고 있으면 어떤 부분에 문제가 있는지를 항상 빠르게 알기를 원한다. 리스크와 관련된 사항을 미리 알고 있지 않으면 차후 비용적인 측면에서 문제가 발생할 수 있기 때문이다. 그리고 정기저으로 경영자에게 자신의 프로젝트가 어떤 리스크를 가지고 있는지를 보고해야 할 의무가 있는 PM이 리스크 관리를 하지 않는 경우가 있다. 그래서 경영자는 리스크 관리는 품질적인 부분과 밀접한 관련이 있으니  품질 관련 부서가 리스크 관리를 담당해야 하는 것 아니냐는 오해를 하기도 한다.

 

개발 도중 발생할 수 있는 리스크에 대해서는 그 누구보다도 프로젝트를 관리하는 PM이 잘 알고 있어야 한다. 만약 내부에서 발생하는 리스크에 대해서 관리가 되지 않는다면 당장은 아무 문제 없을지라도 시간이 지남에 따라 문제는 걷잡을 수 없이 커진다. 따라서 PM과 경영자가 프로젝트 관리에 대한 중요한 한 분야를 모르기 때문에 이러한 문제가 발생할 수 있다.

 

 만약 지식이 부족하다면 프로젝트의 운명은 더 이상 이야기 하지 않아도 짐작 할 수 있을 것이다. 진행중인 개발 프로젝트의 PM에게 이러한 지식이 없다면 개발사는 이 부분을 어떻게 보완할 것인지에 대해 생각해야 한다. 즉 뽑을 때 지식이 있는지 확인 해서 지식이 있는 PM를 뽑던가 아니면 지속적인 교육 프로그램을 활용해서 지식을 쌓게 해야 한다.

 

재미의 철학을 갖고 있는 PM인가

재미의 철학이란 ‘게임에 대해 개인마다 다르게 느끼는 재미를 보편적 기준으로 한마디로 정리한 것’ 이라고 이야기 할 수 있다. 예를 들면 아래와 같이, 여러 가지로 재미에 대한 철학을 정의할 수 있다.

<>ü<>ü<>ü<>ü<>ü위의 경우 간단한 예를 든 것이다. 이 외에도 아주 함축적인 용어 해석부터 한 문장으로 정의 내릴 수 있는 부분까지 다양하다. 대표 정답은 존재하지 않는다. 재미에 대한 가치관을 어떻게 정리하는가가 문제다. 중요한 것은 재미에 대한 철학 없이는 개발 프로젝트가 진행되는 것은 위험할 수 있다는 것이다.

 

그러나 여기서 간과하지 말아야 할 점은 재미의 철학이 철저한 분석 없이 느낌이나 단순히 남이 말하는 것을 인용해서는 안된다. 재미의 철학 정의는 명문화 할 수 있어야 한다. 그리고 논리적으로 설명할 수 없다면 자기만의 철학이라고 말할 수 없기 때문이다. PM 자신이 좋아하는 취향으로 게임을 개발하는 것은 개발사가 추구하는 게임을 개발하는 것이 아닌 자신이 선호하는 게임을 만드는 것일 뿐이다.

 

 만약 재미의 철학에 대한 기준이 명확하지 않다면, 주변의 좋은 의견을 수렴할 수 있어야 한다. 하지만 이 부분 역시 주의해야 할 것이, 재미의 철학이 명확하지 않으면 이 사람, 저 사람의 의견에 따라 개발의 방향성이 바뀔 수 있기 때문에, PM은 좋은 의견을 잘 골라내는 능력을 갖고 있어야 한다.

 

재미의 철학을 갖고 있던가 아니면 남의 좋은 의견을 자기 것으로 만드는 능력이 필요하다. 만약 부족한 경우 재미의 핵심 자체가 바뀌어버릴 수 있기 때문에 문제가 될 수 밖에 없다. 개발이 지체되는 것은 물론이고 제대로 된 게임 즉 유저가 재미있게 즐길 게임을 만들기도 힘들다.

 

예로 3개월마다 마일스톤(Milestone)을 진행하는 개발사가 있었다. 마일스톤(주석 : 중요한 단계를 뜻함. 게임에서의 마일스톤이란 개발부터 서비스까지 단계를 나누어 중요 시점마다 개발 진행을 체크하는 개념으로 사용되고 있음) 을 진행하면서 결과물들을 점검한다. 프로젝트는 개발 기간 3년 동안 총 5번의 마일스톤을 진행하였는데 1차 마일스톤을 제외하고 2차, 3차, 4차, 5차까지 매번 게임성 관련한 핵심 시스템을 갈아 치웠다. 문제되는 부분을 개선하고 좋은 방향으로 선회하는 것이 아닌 재미의 핵심 시스템을 마일스톤 진행 때 마다 새로운 핵심 시스템으로 제안한 것이다.

 

프로젝트를 맡고 있던 PM은 경험이 많지 않은 PM이었다. 이 때문에 이곳 저곳에서 들은 여러 가지 이야기와 자신의 프로젝트를 비교해서 팀 내 상의 없이 핵심 게임성을 변경하려고 했다. 결국 PM은 개발 팀원들에게 변경할 것을 주장하였고, 게임 자체의 핵심 시스템을 바꾸게 된 것이다. 이로 인해 개발 기간은 예상보다 더 늘어나게 되었으며, 처음의 방향성으로 게임을 만들던 개발자들은 매번 새로운 게임을 개발하느라 갈피를 잡지 못하게 되는 결과를 초래했다.

 

이러한 결과를 통해서 PM이 가지고 있어야 할 재미에 대한 철학이 프로젝트의 운명을 어떻게영향을 끼치는지 알 수 있었다.

 

개발하는 게임의 핵심 콘텐츠를 알고 있는 PM인가

이 부분은 앞서 이야기한 PM의 재미 철학과 관련 있는 부분이고 좀더 구체적인 내용이다. 자신의 프로젝트에서 핵심 콘텐츠, 혹은 핵심 시스템을 잘 알고 있는지를 확인해 보는 것이다. 사실 핵심 콘텐츠나 시스템은 PM이 전적으로 관여한다기 보다는 PD나 기획팀장의 역할이라 할 수 있다. 하지만 이 부분을 PM이 얼마나 알고 있고, 이를 다른 사람들에게 어필할 수 있느냐는 PM의 역량에 달려 있다.

 

신규 프로젝트를 진행하고자 하는 팀이 만들어졌다. 이 프로젝트는 처음부터 콘셉트를 갖고 팀이 구성된 것이 아니었기 때문에, 새로 꾸려진 개발팀 인력들이 콘셉트를 잡고 이를 개발사에 어필하기 위한 PT(프레젠테이션)까지 약 4개월 정도의 시간 여유를 갖고 있었다. 이 시간 동안 장르와 게임의 핵심을 잘 정리해야 했다. 개발사에서 프로젝트에 바라는 점은 한가지였다. 바로 시장 경쟁력을 갖춘 저비용으로 빠르게 개발하고 서비스 할 수 있는 온라인게임을 만들라는 것이었다. 신규팀은 콘셉트 발표 준비를 했고, 발표에 앞서 QA팀, 국내사업실, 고객지원실 등 각 유관부서에 PT 내용에 대한 리뷰를 요청했다. 그리고 리뷰 결과를 취합한 결과, 각 유관부서의 평은 그다지 좋지 않았다. 개발사가 원하는 경쟁력 있는 게임이라기 보다는 일반적으로 우리가 여태 많이 봐왔던 MMORPG라고 생각되었기 때문이다. 게임의 하이콘셉트(궁극적인 목표)도 알 수가 없었고, 이에 따른 핵심 시스템이 무엇인지 알 수도 없었다.

 

모든 MMORPG에 있는 기능들을 한데 나열한 것에 지나지 않은 게임이었다. 그러나 신규팀은 문제를 수정하지 못하고, 결국 그대로 콘셉트 발표는 진행되었다. 개발사는 이 게임은 경쟁력이 없음이라 간주하여, 프로젝트 승인을 거절했다.  결국 시작도 하지 못하고 프로젝트는 종료되었다. 각 유관부서들이 조언을 했을 때, 개발팀에서 대답한 답변은 하나였다. “MMORPG의 기능은 다 똑같다. 우리도 별반 차이가 없다. 그 중 한가지를 더 돋보이게 만들어서 서비스하면 경쟁력이 있을 것이다.” 성공한 MMORPG에서의 시스템을 벤치마킹하여 우리 게임에 적용하는 것은 유저에게 호감을 줄 수 있다. 이미 한번 겪어봤기 때문에 익숙하고, 재미를 느끼는 부분이기 때문이다. 따라서 위에서 말한 바와 같이 성공한 MMORPG와 현재 만들어지고 있는 MMORPG와 들어가 있는 시스템의 차이는 크지 않다.

 

그러나 위에서 말한 신규팀의 문제점은, 어떠한 방법으로 ‘한가지를 돋보이게’ 만들지를 깊게 생각하지 않았다는데 있다. 말로는 돋보이게 만들겠다고 이야기 하지만, 실제로는 이 부분을 심사숙고 하지 않았고, 의사결정권자들에게 게임을 어필 하지 못했다. 그냥 그냥 잘 만들어 보겠다는 정도의 느낌으로 다가간 것이다. 결과적으로는 어떻게 만들다 보면 특별한 것이 생길 것이다라는 막연한 생각으로 프로젝트를 시작하고자 한 것이다.

 

만약 PM이 좀더 하이콘셉트와 핵심재미 그리고 핵심시스템에 대한 생각을 좀더 잘 어필 했다면 결과는 달라 질 수 있었을 것이라 생각한다. 그리고 개발사가 원하는 저비용으로 빠른 개발을 위한 방법까지 제시 했다면 프로젝트를 진행안할 이유가 없었을 것이다.

 

[출처] http://www.itester.co.kr/2012/11/pm.html