저는 전산개발로 밥을 먹는 사람입니다. 여타 다른 일처럼 전산 개발 현장은 여러 가지 업무분야로 나뉘어 있습니다. 저는 그중에 PM으로 일을 합니다.  

예전에 유명했던(지금도 유명한가요?) 이 무좀약을 말하는 게 아니고, 

Project Manager의 머리글자입니다. 

즉, 전산개발 프로젝트 전체를 관리 하는 일을 하는 거죠. 제안작업부터 프로젝트 마무리까지 PM은, 프로젝트 시작과 끝을 책임지는 역활을 합니다.

그런데 이 PM이란 직책이 좀 이상합니다. 처음부터 PM으로 일을 시작하지 않습니다. 개발자로 개발하다가 어느 정도 직급이 되면 갑자기 PM을 하라고 합니다. 당황스럽죠. 개발을 하며 경력을 쌓았는데 더 어려운 개발을 하는 게 아니라 이제 좀 개발할 만 하다 싶은 사람을 갑자기, PM이라는 개발과 그다지 관련이 없는 분야로 밀어 버리는 겁니다.

그러면 PM은 그냥 개발하던 사람이 대충 연차가 되면 할 수 있는 일인 걸까요? 고객과 투입인력에 대해 협상할 때면 "PM 공수가 이렇게 많이 필요해요?"라는 말을 들을 만큼 프로젝트 진행에 잉여로운 직책일까요?

저는 그렇지 않다고 봅니다. PM은 프로젝트를 책임지는 사람입니다. 프로젝트의 전체 흐름을 꿰뚫고 있어야 하고 고객사 현업, 그 현업의 상급자, 그리고 같이 일하는 직원과 협력업체와 원활한 커뮤니케이션을 할 수 있어야 하고 공식적인 보고서나 문서도 작성할 수 있어야 합니다. 제안발표로 시작해서 착수보고회 중간보고 완료보고 같은 프리젠테이션 능력도 필요합니다.

이렇게 할 일 많고 각종 복합적인 능력을 필요로 하는 PM은 실제 어떤 일을 하는 자리인 걸까요? 또 어떻게 하면 좋은 PM이 될 수 있는 걸까요? 

앞으로 차근차근 알아보려 합니다. 이 연재를 통해서 PM에 대해 궁금하거나 PM이 되고 싶거나 혹은 막연히 PM이 되는 것에 대해 거부감이 있는 개발자분들에게 유익한 정보가 될 수 있도록 노력하겠습니다.
 

"야, 그 선배는 왜 그러냐... 진짜 짜증난다." 

"아냐, 그럴 수도 있을 꺼 같아. 난 그 선배가 이해 되는데?"

2002년 어느 봄날, 점심을 먹고 손에 믹스커피 한 잔씩을 들고는 옹기 종기 모여서 수다를 떨고 있었다. 

그 당시 회사에는 나와 같은 나이 또래의 개발자들이 4명 정도 있었는데 우리보다 1살 많은 선배에게 회사에서 PM으로 프로젝트에 투입하려고 조율하던 중 그 선배의 강력한 반발로 회사 분위기가 별로 좋지 않은 상태였다.

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

동기인 4명의 의견은 크게 2가지로 갈렸다. 선배의 반응이 당연하고 회사에서 롤과 다른 PM으로 개발자를 투입하는 것은 옳지 않다라는 의견과 PM이 뭐라고 저렇게까지 호들갑을 떠냐, 너무 유난스럽다라는 의견이었다.

나는 후자 쪽이었는데 은근히 PM들의 업무처리에 불만도 많았고 99년부터 쭈욱 개발일을 해왔던 터라 나름대로 많은 프로젝트를 경험, '내가 하면 더 잘할 수 있는데' 하는 근거없는 자신감을 갖게 됐기 때문이었다.

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

내가 이렇게 오래 PM으로 생계를 유지해 왔으며 앞으로도 그럴 예정이니 틀림없이 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이라고 뭉뚱그려져 있는 이 직책을 나눌 수 있는 기준들을 살펴보기로 하겠다.

리뷰게시판 초하류

편집 : 딴지일보 퍼그맨