사람은 누구나 자신 일을 가장 힘들다고 생각한다. 남자의 경우 군대 얘기를 할 때만 해도 안 힘들다는 사람은 한 명도 없다. 땡보직처럼 보이는 관사당번병도 암호병도 모두 모두 몇 날 밤을 이야기로 늘어놓을 수 있는 저마다의 고충이 있는 법이다. 

업무도 마찬가지다. 누구나 자신이 하는 일이 가장 어렵고 힘들고 짜증 나는 것이라 생각한다. 프로젝트 현장도 마찬가지다. 프로젝트 현장은 기본적으로 납기라는 데드라인을 두고 일하는 곳이기 때문에 시간적으로 여유가 없어진다. 이렇듯 여유가 부족한 상황에 처하면 자신이 맡은 롤 이외의 일에 신경을 쓸기란 무척 힘들다. 아직 프로젝트 팀원인데도 불구하고 이런 어려움을 무릅쓰면서 PM이 되고 싶다면? 어떻게 해야 할까? 

PL(Project Leader, 개발자 중 리더로 책임자라기 보단 고참에 가까운 의미) 같은 PM, PM이라고 하기엔 조금 부족한 PM의 등급으로 올라서려면, 더 나아가서는 진정한 PM이 되고 싶다면 어떤 준비를 해야 할까?

PL 같은 PM이 되려면?

우선 아직 프로젝트팀원이지만 작은 프로젝트나마 책임지고 진행해 보고 싶다면 (그것이 자신의 커리어를 올릴 욕심 때문이든 PM이라는 직업이 마음에 들었기 때문이든) 할 수 있는 방법이 있다.

바로 지원 하는 것이다. 당신의 상사에게 '이렇게 작은 프로젝트라면 제가 PM없이 진행 할 수 있습니다. 한번 맡겨 주십시오'하고 의견을 내는 거다. 

상사들은 대부분 좋아한다. 당신이 맡기를 원하는 프로젝트 규모에서는 무척 한정된 예산 규모에서 움직이기 때문에 당신이 제시한 의견은 받아들여지기 쉬울 것이다. 단 평소에 상사에게 믿을 수 있는 사람이라는 인상을 주었다는 전제에서 그렇다.

이렇게 PL 같은 PM으로 일하다가 약간 부족한 PM이 되려고 한다면 어떻게 해야 할까? (여기서 약간 부족한 PM이란 앞서 살펴본 개발은 하지 않고 프로젝트 관리만을 할 수 있는 3~5억 정도의 프로젝트 관리자를 말한다.)

PM이라고 하기엔 약간 부족한 PM이 되려면?

사실 이 단계는 전 단계 보다 쉽지 않은 여러 가지 문제들이 있다. 우선 자신이 소속된 회사가 그 정도 사이즈의 프로젝트를 진행할 수 있어야 한다. 1억 미만의 프로젝트에서 개발 없이 관리만 한다는 건 거의 불가능하기 때문이다. 

자신의 소속 회사가 그런 사이즈의 프로젝트를 진행하고 있다면 가장 쉬운 방법은 여기서도 자신이 PM으로 자원하는 것이다. 하지만 개발과 프로젝트 관리를 동시에 진행하고 있었다면 이렇게 PM으로 프로젝트에 투입된다고 하더라도 코딩 없이 프로젝트 관리에 전념하는 것은 생각보다 쉽지 않을 것이다. 

우선 코딩 할 수 있는 PM이라는 인식은 프로젝트 인력 산정에서 개발자의 역할까지 떠 안고 일할 것을 부지불식간에 강요하도록 만들기 때문이다. 본인 스스로도 프로젝트 일정에 쫓기면 결국 자신의 코딩 실력을 발휘해서 해결하고 싶은 생각이 든다. 하지만 일정이 망가지기 시작하는 프로젝트에서 PM이 코딩을 시작하게 되면 일정을 위한 커뮤니케이션이 등한시되거나 하루종일 회의 후에 코딩을 시작하게 되고 생각한 것보다 진도도 잘 안 나가서 결국 전체적인 일정이 더 늦어질 가능성이 더 커진다.

이런 문제를 타개하려면 외적으로 회사가 3~5억 규모의 프로젝트를 빈번히 수행하는 환경이라야 한다. 개발자와 함께 전문적으로 프로젝트를 관리할 인력에 대한 필요성이 높아지면 회사에서도 자연적으로 개발보다는 프로젝트 관리에 주력하는 인력을 활용하고자 하는 분위기가 만들어 진다.

하지만 회사의 사정이 여의치 않다면? 그 다음 선택지는 프로젝트 전문관리 인력이 필요한 회사로 이직을 하는 것이다. 필자의 경우는 다른 이유에서의 이직이긴 했지만 닷넷으로 개발하다가 자바로 개발하는 회사로 이직했기 때문에 개발에서 자연스럽게 멀어지고 프로젝트 관리에 집중할 수 있었다. (물론 초기에는 필요한 몇몇 기능들을 닷넷으로 개발해 버리는 무리수를 두기도 했었지만...)

본인 스스로도 프로젝트의 문제를 자신이 코딩에 참여하는 것이 아니라 프로젝트 관리를 통해 해결하려는 강한 의지가 필요하다. 당장에는 코딩을 하면 일이 줄어 드는 것이 보이기 때문에 이 유혹을 참기 힘들지만 결국 회사 차원에서 보아도 개인 차원에서 보아도 프로젝트 관리로 해결하는 것이 이익이다. 

프로젝트 수주를 위한 제안발표 같은 프리젠테이션 능력도 능숙해져야 한다. 하나 같이 쉽지 않은 일이기에 꽤 많은 경험과 노력이 필요하다.

PM같은 PM이 되려면?

마지막으로 진짜 PM이 되는 단계다. PMP(Project Management Professional)에서 발행하는 PMBOK의 프로세스를 정말 전문적으로 돌려야 하는 PM이 되기 위해서는 어떻게 해야 할까. 

이 단계에서는 대형 SI 업체에 취직하는 것 이외에는 답이 없다. 우리나라에서 IT 프로젝트 중 대형 프로젝트는 대부분 상위 SI 업체들이 싹쓸이하기 때문이다. 이 취직을 해내기 위해서는 단지 실무경력뿐만이 아니라 그 회사들이 원하는 스펙까지 준비할 필요가 있다. (예를 들면 어학 점수 라든가.)

PM 레벨업의 정석

단순히 생각해 보면 RPG 게임은 대부분 지루해보인다. 몹 잡으려고 던전 도는 것도 하루 이틀 해서는 어림 없고퀘스트도 사실 거기서 거기다. 하지만 그 게임을 하는 사람들은 재미를 느끼고 있다. 심지어 중독되는 사람도 있다. 몇 시간 접속하지 않았을 뿐인데 금단현상을 경험하기도 한다. 왜 그럴까? RPG 게임의 몹 사냥이나 퀘스트 깨기는 단순히 그 행위 자체에서 오는 즐거움도 어느 정도 있겠지만 사실 그 행위로 인해서 일어나는 캐릭터의 레벨업이 더 중요한 관심사이기 때문이다. 레벨업에 관심 없는데 몹은 잡아서 무엇하며 퀘스트는 수행해서 뭐하겠는가.

PM의 경우도 크게 다르지 않다. 사실 IT 프로젝트에서 처음에 단순히 개발자로 참여해서 PL이 되고 그 이후에 PM이 되고 나면 더 이상 레벨이 올라가지 않는 것 같은 느낌이 든다고들 한다. 어려운 프로젝트도 있고 비교적 쉬운 프로젝트도 있지만 결국 PM이 하는 일은 앞서서 이야기한 몹 잡고 퀘스트 깨는 것과 같이 프로젝트 사이클에 따른 반복이기 때문이다. 그런데 게임에서와 마찬가지로 그 단위 작업이 좀 지겨운 경향이 있더라고 자신의 레벨이 올라간다면 좀 더 즐겁게 작업할 수 있고 즐겁게 작업하면 성과도 좋아지기 마련이다.

그렇다면 자신의 레벨이 올라가는 프로젝트는 어떤 것이 있으며 그런 프로젝트를 맡으려면 어떻게 해야 할까? 이른 바 PM으로서의 커리어를 관리하려면 어떻게 해야 할까, 하는 이야기를 한번 해볼 필요가 있겠다. 

 ① 회사에서 가장 큰 프로젝트를 맡아라

흔히 사람들은 규모가 큰 프로젝트는 어렵고 규모가 좀 작은 프로젝트는 쉬울 거라고 생각하지만 이는 잘못된 생각이다. 일단 규모가 작은 프로젝트를 해보면 생각보다 쉽지 않다. 그러면 '아, 이렇게 작은 프로젝트도 어려운데 더 큰 프로젝트는 얼마나 더 어려울까'하는 생각을 하면서 위축되기도 한다.

하지만 필자의 경험 상 프로젝트의 난이도는 결코 프로젝트의 규모에 비례하지 않는다. 물론 프로젝트의 이슈나 리스크는 확실히 프로젝트의 규모에 비례하는 경향성이 있다. 하지만 난이도만큼은 아니다. 근거가 뭐냐고?

프로젝트가 크면 그만큼의 지원과 여유가 생기기 때문이다. 예를 들어 프로젝트가 크면 기술적인 이슈가 생길 가능성도 크지만 투입된 프로젝트 인력을 좀 더 핵심 개발자들로 구성할 수 있게 된다. 운용할 수 있는 예산 면에서도 어느 정도 여유가 생기기 때문에 리스크에 대한 예비비도 생각할 수 있게 되고 본사의 지원을 받기가 비교적 쉽기 때문이다. 따라서 자신이 할 수 있는 가장 큰 프로젝트를 맡으려고 노력하고 될 수 있으면 회사에게 가장 큰 프로젝트를 맡을 수 있도록 노력하는 자세가 필요하다. 결국 PM은 어느 정도 규모의 프로젝트를 관리해봤느냐로 능력을 평가 받기 때문이다. 

 ② 금융권 프로젝트를 맡아라

IT 프로젝트중 가장 보수가 좋은 프로젝트는 금융권 프로젝트다. 금융권 프로젝트는 대부분 수주금액도 크고 요구되는 기술 수준도 높다. 게다가 금융권 프로젝트의 경험이 없는 사람은 참여하기가 무척 까다롭다.

그래서 자신의 이력서에 금융권 프로젝트가 있느냐 없느냐는 PM은 물론이고 개발자의 몸값이나 역량판단에 중요한 잣대라 될 수 있다. 따라서 될 수 있으면 금융권 프로젝트에 참여할 수 있도록 노력하는 것이 좋다.

 ③ 다수의 협력업체를 관리하는 프로젝트를 맡아라

같은 규모의 프로젝트라도 다수의 협력사를 관리하는 프로젝트와 그렇지 못한 프로젝트는 관리 난이도가 확연하게 차이가 나고 요구되는 스킬셋도 다르다. 따라서 PM으로서 다수의 협력사들과 협업해서 훌륭하게 프로젝트를 진행해본 경험은 역량을 평가 받는데 중요한, 객관적 지표가 될 수 있다.

 ④ 정식 감리가 포함된 프로젝트를 맡아라

일반적으로 규모가 크면 감리가 포함된다. 공공분야에서는 프로젝트 규모가 5억이 넘어가면 감리를 필수적으로 포함해야 한다. 물론 IT 감리는 사후적이고 문서 꼬투리 잡기에 치우치는 등 프로젝트를 진행하다 보면 왜 돈 주고 이런 뻘짓을 해야 하나 회의감이 들 때도 있다. 이런 단점들에도 불구하고 프로젝트 방법론에 따른 정식적인 진행을 외부에서 체크해주는 것과 그렇지 않은 것은 아무래도 차이가 있을 수밖에 없다.

그리고 감리에 대한 대응이나 감리에 필요한 산출물을 제출하는 것도 한번 경험해 보지 않으면 대응하기가 상당히 까다로울 수 있기 때문에 감리가 포함된 프로젝트는 PM으로서 꼭 경험해야 하는 것이다.

 ⑤ 하드웨어가 포함한 프로젝트를 맡아라.

프로젝트에 하드웨어가 포함 되면 고려해야 할 사항과 프로젝트 진행이 많이 달라진다. 따라서 하드웨어가 포함된 프로젝트를 해보는 것이 PM으로서의 능력 향상에 도움이 된다.

자, 지금까지 PM의 레벨을 올리는 퀘스트 5개를 제시해드렸다. 반드시 이 퀘스트를 다 거쳐야 좋은 PM이 될 수 있다는 얘기는 아니다. 이외에도 많은 요소들이 필요하다. 하지만 운전을 아무리 잘 해도 운전면허가 없으면 차를 살 수 없 듯이 자신이 아무리 능력이 좋은 PM이라 하더라도 외부에서 인정 받으려면 객관적인 지표가 필요하기 마련이기 때문에 PM으로서 능력을 인정 받기 위해서는 위에서 언급한 프로젝트는 다소 힘들고 피곤하더라도 본인이 적극적으로 움직여서 경험을 쌓을 필요가 있다는 조언을 드리고 싶다. 

초하류

편집 : 딴지일보 퍼그맨