나는 PM(Project Manager)이다

나는 PM(Project Manager)이다 - 1. PM으로 태어 나는 사람은 없다

초하류 2011. 9. 16. 17:40
야 그 선배는 왜 그러냐.. 진짜 짜증난다. 아냐 그럴 수도 있을꺼 같아 난 그 선배가 이해 되는데?

2002년 어느 봄날 점심을 먹고 손에는 믹스커피 한잔씩을 들고 옹기 종기 모여서 수다를 떨고 있었다. 그 당시 회사에는 나와 같은 나이 또래의 개발자들이 4명 정도 있었는데 우리보다 1살 많은 선배에게 회사에서 PM으로 프로젝트에 투입하려고 조율하던중 그 선배의 강력한 반발로 회사 분위기가 별로 좋지 않은 상태였다.

지금 PM을 시키면 나에게 회사 나가라는 말과 같다며 강경하게 버티던 선배와 실갱이를 벌이던 회사는 결국 협력사에서 PM을 소싱해서 프로젝트를 진행했다.

동기인 4명의 의견은 크게 2가지로 갈렸다. 선배의 반응이 당연하고 회사에서 롤과 다른 PM으로 개발자를 투입 하는 것은 옳지 않다라는 의견과 PM이 뭐라고 저렇게까지 호들갑을 떠냐 너무 유난스럽다라는 의견이었다. 나는 후자쪽이었는데 은근히 PM들의 업무처리에 불만도 많았고 99년부터 쭈욱 개발일을 해왔던터라 나름대로 많은 프로젝트를 경험하면서 내가 하면 더 잘할 수 있는데 하는 근거없는 자신감을 가지고 있었기 때문이다.

그리고 일년 정도가 지나고 정신을 차리자 1억 미만의 작은 프로젝트에서 개발과 프로젝트 관리를 동시에 하는 위치에 가 있었고 개발 보다는 PM쪽으로 케이어가 쌓이기 시작했고 지금은 개발은 하지 않고 프로젝트 관리만을 하고 있다.99년 2월 부터 이 바닦일을 시작했으니 12년 정도가 지났는데 개발 없이 PM직만 수행한것은 5년 정도가 지났다. 물론 그 동안에도 간단한 개발들은 가끔씩 손을 댓지만 개발이라고 할 수 없을정도의 수준이니 프로젝트 관리만으로 밥을 먹고 살아온 셈이다.

내가 이렇게 오래 PM으로 생계를 유지해 왔으며 앞으로도 그럴 예정이니 틀림없이 PM이란 직업은 존재 하는 것이고 입에 풀칠을 할 수 있는 정도는 된다는것이 증명되었고 시중에 프로젝트 관리나 PM 관련 책자들도 존재 한다. 

그러나 이런 책들은 프로젝트 관리에 대한 아카데믹한 설명이나 경험적인 해법에 치중되어 있고 정작 직업으로서 PM이 어떤 위치에 있는지는 별로 관심을 두지 않는다. 

PM이란 직업은 어떻게 가질 수 있는것이고 앞으로 얼마나 잘 나갈것인가 혹은 얼마나 오래 유지될 것인가 즉 한마디로 직업으로 선택할 만한 가치가 있는것인가를 알아 보는 것으로 한번 시작해 보자.

1. PM은 전문직이다.

전문직과 비전문직은 어떻게 나눌수 있을까. 전문직이란 해당 직무를 수행하기 위해서 전문적인 능력이 필요한 업무라고 생각된다. 예를 들면 법률적인 문제해결에 전문적인 능력을 가진 변호사나 사람의 몸에 이상이 있는 부분을 파악하고 고칠 수 있는 의사 같은 직업이 대표적이다. 그런데 이런식이면 전문적이지 않은 직업도 있나 싶다. 그렇다면 전문직이라고 이름 붙이기에는 좀 더 구별할 수 있는 기준점이 필요할꺼 같다.

예를 들어보자. 어떤 사람이 의사가 되고 싶어서 병원에 갔다고 치자 그리고 의사를 하고 싶습니다. 하면 그 사람은 초보 의사가 되어서 치료를 하면서 배워 나갈 수 있을까? 불가능 하다. 의사의 업무는 사람의 건강 이라는 첨예한 부분을 다루기 때문에 의사가 되기 위해서는 의대를 졸업하고 국가고시를 치르고 인턴을 거치는 긴 과정이 존재한다.

그렇다면 PM은 어떨까? 지금 바로 사회에 진출할 당신이 소프트웨어 개발 PM을 하고 싶다고 해서 회사에 PM이 되고 싶다고 하면 PM이 될 수 있을까? 그것은 거의 불가능하다. 이유를 알기 위해서는 소프트웨어 개발 프로젝트에서 PM이 어떤일을 하는지 살펴볼 필요가 있다.

PM은 소프트웨어 개발 프로젝트 전체에 대해 관여한다.

소프트웨어 개발 프로젝트는 크게 영업 단계인 프리세일즈를 통해 확인된 프로젝트에 대해서 제안서를 쓰고 제안발표회를 거쳐 프로젝트에 투입된 후 개발을 마치고 프로젝트를 마무리하는 대강의 과정으로 진행 되는데 이 전분야에 걸쳐서 PM의 손이 가지 않는 곳이 없다.

제안서 작성에도 일부 제안작성 전문팀의 도움을 받기도 하지만 고객의 요청사항을 통해 제안서를 쓰는 전반에 걸쳐서 참여 해야 한다. 그리고 제안PT에서 제안 발표도 PM 몫이다. 특별한 경우는 PM이 제안PT에서 발표를 하지 않을 수도 있지만 최근에는 대부분 구축PM이 제안 발표하는것이 고객 요청사항에 포함 되어 있다. 

프로젝트에 들어가면 본격적으로 프로젝트 관리가 시작된다. PMP(Project management Professional)에서 이야기 하는 9가지 관리 포인트는 아니라 하더라도 프로젝트 규모에 따라 다르지만 프로젝트 범위, 인력, 프로젝트 일정 정도로 압축된다. 그런데 프로젝트에서 범위와 인력 일정을 관리하는 것은 결코 쉬운 일이 아니다.

고객은 일반적으로 최소한의 비용으로 최대한의 효과를 얻으려고 노력한다. 문제는 이 최대한의 효과에는 자신들에게 실제로 도움이 되는가라는 합리적인 관점이 빠져 있을때가 많다는 거다. 즉 지금 자신이 요구하는 기능이 계약서에 포함 되어 있는가 하는 기본적인 고려사항 이외에도 실제로 자신들에게 도움이 되는가 도움이 되더라도 그 기능을 계발하기 위해 소모되는 리소스 때문에 더 집중해야할 핵심 기능이 허술하게 되지는 않는가 하는 문제들이 발생 한다는거다. 

이럴때 PM은 고객에게 요구사항이 프로젝트에 미치는 영향을 때로는 설득 하고 때로는 윽박지르고 때로는 냉전하면서 범위 안으로 끌어 들일 수 있는 협상력이 필요하게 된다. 그리고 이런 협상력은 PM이 고객보다 해당 분야에 대해 더 많은 경험과 지식을 가지고 있을때 성공할 가능성이 높아진다.

고객만이 문제가 아니다. 프로젝트에 참여한 개발자, 디자이너, 기획자, 컨설턴트, 그리고 협력사까지 이해관계가 다른 많은 사람들의 요구를 충족시키기 위해서는 작업 결과물에 대한 퀄리티 확인은 기본으로해서 그들이 지향하는 바를 이해하고 프로젝트의 성공을 위해 업무를 진행 시키기 위해서는 각 분야에 대한 어느정도의 이해가 필요하게 된다. 

이런일들을 진행 하면서 발생하는 모든 공식문서 대응도 물론 PM이 해야 하는 일중에 하나다.

따라서 대부분의 프로젝트에서는 PM의 경우 소프트웨어 개발자 등급으로 한다면 최소 중급 이상 대부분은 고급 정도의 경력자를 요구하게 된다.

소프트웨어 개발자 등급에서 중급에 도달하기 위해서는 4년제 대학을 마치면서 정보처리기사를 획득하고도 3년의 실무 경험이 필요하다. 고급은 중급 취득후 3년의 시간이 더 필요하게 된다. 따라서 PM은 하고 싶다고 누구나 할 수 있는 일이 아니고 업무를 수행 하기 위해서 소프트웨어 개발 프로젝트 전반에 대한 전문적인 지식과 함께 일정한 경력이 필요하기 때문에 전문직이며 진입장벽이 꽤 높은편이라고 생각된다.

2. 그렇다면 대우는 어느정도?

PM이라고 특별히 급여가 높지는 않은것이 일반적이다. 분명한 것은 일반적인 개발자 보다는 대우에 있어서 조금 더 유리한 입장에 있다고 보여진다. 왜냐하면 소프트웨어 프로젝트를 성공 시키기 위해 여러가지 요소들이 고려 될 수 있지만 수행 하는 프로젝트들의 품질 유지를 위해서 실력 있는 PM의 능력이 상당히 중요하기 때문이다.

그리고 앞으로 소프트웨어 개발은 일반적인 업무로서 보다는 프로젝트성으로 진행 되는 경향이 더 강하기 때문에 소프트웨어 개발 프로젝트의 PM은 향후 전망도 어두운 편은 아니라고 생각된다.


3. PM이 되려면 필요한 조건은?

PM이 되려면 우선 프로젝트 경험이 필요하다. 프로젝트는 하나 하나가 무척 유니크 하기 때문에 글이나 말로 백날 배우는것 보다 한번 몸으로 겪어 보는것이 훨씬 잘 알 수 있는 방법이라고 생각된다. 그리고 무엇보다 서두에 밝힌것 처럼 PM에 대해서 고객이나 수행하는 업체에서도 프로젝트 경력을 최우선으로 고려 하기 때문에 필수적인 요소라고 생각된다. 

그런데 우리나라 소프트웨어 프로젝트에서 관리 포인트로 투입되는 인력은 무척 한정적이기 때문에 경력을 쌓기 위해서는 개발자로 프로젝트에 투입되어 경험을 쌓는것이 가장 쉬운 방법이라고 생각된다.

PM에 대해서 특별한 자격증이 필요하지는 않다. 하지만 전 세계적으로 프로젝트 관리에 대해서는 PMP 자격증이 가장 권위가 있다. PMP에서 만들어지는 PMBOK는 프로젝트 관리에 대해 이론적으로 접근할때 빠지지 않고 등장하는 프로젝트 관리 방법론이기 때문에 PM이 되려고 한다면 프로젝트 관리 전반에 걸쳐 이론적인 토대를 쌓는 차원에서도 한번쯤 취득할만한 자격증이다.

경력과 자격증말고도 PM이 되기위해서 필요한 조건은 커뮤니케이션 능력이다. 프로젝트는 정해진 시간안에 정해진 자원으로 목표를 당성 하는 다소 긴박한 상황이고 거기에 관계되어 있는 사람들도 많고 서로 목표도 다를 수 있기 때문에 이런 사람들을 프로젝트 완료라는 한가지 목표를 향해 나아가기 위해서는 처음 만난 사람들과의 관계를 부드럽게 가져갈 수 있는 비공식적인 커뮤니케이션 외에도 공식적인 보고서 및 회의를 통한 커뮤니케이션도 능숙해야 한다.

마지막으로 꼽아 보자면 책임감을 들 수 있다. 프로젝트가 시작되면 PM은 마치 그 프로젝트를 진행 하는 팀을 경영하는 경영자와 같은 위치에 들어가게 된다. 인력과 범위 그리고 한정된 시간안에 프로젝트를 마칠 수 있도록 자신의 최선을 다해야 하고 그 최선은 대부분 책임감이 없이는 유지되기 어렵다. 내가 만나본 인정 받는 PM 중 해당 분야에 전문적인 지식이 조금 부족한 사람은 있었지만 책임감이 결여된 경우는 찾아 볼 수 없었다. 

프로젝트팀원, 프로젝트를 진행 하는 현업 그리고 자신이 소속된 회사 모두에게 믿음을 얻을 수 있을 정도로 투철한 책임감은 PM이 꼭 갖춰야 할 요건이라고 생각된다.

PM은 어떤일을 하고 어떤 자격이 있는지 갖춰야 할 덕목은 어떤게 있는지 살펴 보았다. 다음 시간에는 PM은 어떤 종류가 있는지 단순이 PM이라고 뭉뚱그려져 있는 PM을 나눌 수 있는 기준들을 살펴 보기로 하자.