일 등급 한우 환상적인 마블링의 발그스름한 그 꽃등심을 보기만 해도 군침이 절로 돈다. 살짝 익혀서 한입 베어 물면 입안 가득 퍼지는 환상적인 육즙과 살살 녹는 식감.

하지만 모든 쇠고기가 이렇게 맛이 있는 건 아니다. 그리고 모든 쇠고기가 이렇게 구워 먹을 수 있는 것도 아니다. 구워 먹기는 아까워 육회로 먹는 부분, 구워 먹기는 질겨서 국에 넣는 부분 등등. 

PM도 마찬가지다. 프로젝트를 관리 한다는 것은 단순하게 한 가지 방법으로 정의될 수가 없다. 왜? 프로젝트의 규모와 성격이 엄청나게 다양하기 때문이다. 하지만 천명이면 천 가지라고 할 만큼 다양한 사람의 체질도 뭔가 정리를 하면 이제마 선생처럼 4가지 특징적으로다가 정리가 돼버린다. 비록 그 경지에는 발끝에도 못 미치지만 어쨌거나 프로젝트로 10년 넘게 굴러먹은 경험을 바탕으로 PM을 크게 세 가지로 나눠서 살펴보자.

첫 번째 PL 같은 PM

PL은 프로젝트에 투입된 개발자중 Leader를 일컫는 말이다. 여기서 PL에 대해서 다시 설명하자면 너무 긴 이야기가 될지도 모르니까 개발자중 젤 고참으로 기술적인 부분에 대해 다른 개발자들을 리드하는 역활이라고 간단히 정의하고 한번 살펴 보도록 하자.

PL 같은 PM은 대부분 소규모 프로젝트의 경우에 나타난다. 1~2개월 정도의 짧은 기간과 1억 미만의 소규모 프로젝트 투입되는 인력도 4~5M/M를 넘지 않는 정도.

그렇다면 그런 프로젝트에는 왜 PL 같은 PM이 필요하게 되는가. 생각해 보면 뻔하다. 일단 투입되는 인력도 적고 금액도 얼마 되지 않기 때문에 PM을 따로 투입할 만한 여유가 없는 것이 첫 번째고 프로젝트 범위나 투입되는 인력이 작아 프로젝트 관리가 그다지 어렵지 않기 때문이다.

이렇게 PL 같은 PM으로 투입 되는것이 개발자가 PM롤을 수행 하기 위한 첫걸음과 같은 것이다. 개발하랴, 고객 요구사항 협의하랴, 삽질하는 후배 놈 단속하랴, 정신없이 바쁘고 내가 개발자인지 프로젝트 관리자인지 정체성의 혼란을 겪기도 한다.

PM으로서 하는 일은 고객들과의 요구사항 조율 회의 및 같이 투입된 프로젝트 인력에 대한 관리 정도이다. 그 외에는 시스템 설계나 프로젝트에 투입되는 개발자들을 기술적으로 리딩하는 능력을 더 많이 요구받기 때문에 프로젝트 관리라기보다 산출물이나 프로젝트 일정에 관여하는 개발자 리더에 더 가깝다.

대부분 익숙지 않은 요구사항 조율과 프로젝트 산출물 및 고객이 요구하는 보고서 같은 문서작업에 스트레스를 많이 받는 시기이기도 하다. 이 시기에서 필요한 능력을 다시 한 번 정리해 보자면 이렇다.

1. 개발적인 리딩
2. 고객과 요구사항 조율
3. 산출물 작업

두 번째는 PM이라고 하기엔 조금 부족한 PM 단계다.

이제 직접적인 코딩을 하지는 않지만, 요구사항 정의부터 화면 및 DB 설계 단계 정도는 관여하고 그 이후는 일정 및 리소스 관리를 진행한다. 탄탄한 패키지를 바탕으로 진행하거나 3~4억 이하 사이즈의 프로젝트에서 주로 발견된다.

이 정도가 되면 프리세일즈에서부터 프로젝트에 관여하기도 하는데 고객사에 시스템 시연을 하고 영업과 함께 고객을 방문해서 기술적인 어드바이스도 하게 된다.

회사에 따라 다르지만 대체로 제안서 작성 작업에 참여하게 되고 제안발표도 직접 해야 하는 경우가 많다. 프로젝트에 투입되면 프로젝트 관리를 기본으로 고객 요구사항 등의 범위관리 및 시스템 설계 단계에 참여하게 된다.

개발자라기보다는 관리자로 완전히 돌아서는 단계로 이전 단계에서 갈고 닦은 문서작성 및 요구사항 조율 능력과 함께 사업을 만들어 가는 과정에 참여해야 함으로써 기술영업에 필요한 최신 트렌드 및 고객의 요구사항을 캐치해서 사업의 전체 윤곽을 제시해 주는 등의 능력이 필요하게 된다. 또한, 제안 발표, 착수보고회, 완료보고회 같은 공식적인 프리젠테이션 자리가 많아짐에 따라 자연스러운 프리젠테이션 능력도 필요하게 된다.

프로젝트 사이즈가 커짐에 따라 협력사가 포함되기도 하고 시스템의 연동도 빈번하게 발생하기 때문에 소속이 다른 프로젝트팀끼리의 커뮤니케이션 및 의견조율 능력이 절실히 요구되고 프로젝트를 발주한 회사의 사내 정치적 상황에 따른 상황판단 등의 능력도 중요하게 부각된다.

점점 프로젝트 전반에 걸쳐서 관계 하면서 자신이 어느 부분에 강점이 있는지 알아 가는 시기이며 우리나라에서 PM 구인란에 가장 많이 등장하는 유형의 PM이기도 하다.

이 시기에 필요한 능력을 다시 한 번 정리해 보자면 이렇다.

1. 프리젠테이션을 포함한 기술영업 능력

2. 원활한 커뮤니케이션 능력
3. 프로젝트 관리

마지막으로 PM 같은 PM 단계다.

이 PM은 진정한 의미의 PM이다. 사업관리팀이 꾸려질 만큼 큰 프로젝트 최소 50억 이상인 차세대 혹은 그에 준하는 프로젝트의 PM이 여기에 해당한다. SDS나 CNS 같은 대형 SI 업체에 소속되어 일하는 게 일반적이며 이런 대형 프로젝트는 대부분 장기간(2~3년) 진행되기 때문에 한번 프로젝트가 시작되고 나면 본사와는 별개로 해당 사업의 오너와 비슷한 모양새가 된다.

각 파트의 PL들과의 협업, 발주사 임원들과의 정치적 갈등 해결, 전체 프로젝트 진행에 대한 책임을 지게 된다. 일반적으로 대형 SI 회사의 최소 부장급은 돼야 맡게 되는데 관리해야 할 프로젝트 인원만 해도 엄청난 경우가 많다. 경우에 따라 차이가 있을 수 있지만, 금융권 차세대의 경우 투입되는 인력이 2000M/M는 우습게 넘어간다.

이쯤 되면 거의 고객사의 임원들과 원활한 관계 유지가 되어야 하고 프로젝트 전체 추진일정 및 각 관리 포인트를 잃지 않아야 한다. 또한, 해당 프로젝트의 성공적인 수행뿐만이 아니고 기존 구축된 인맥을 통한 향후 유지보수 및 후속 프로젝트에 대한 영업력도 필수적으로 필요하다.

이 시기에 필요한 능력을 다시 한 번 정리해 보자면 이렇다.

1. 전체 프로젝트 관리 능력
2. 협업 및 프로젝트 쿠킹을 위한 인맥관리
3. 정치적 문제 해결 능력

PM은 한마디로 정의되기 힘든 일이다. 앞서서 크게 3가지로 나눠서 러프하게 살펴봤지만, 각각의 단계 사이와 각 단계가 짬뽕이 되면서 수없이 많은 단계와 상황이 생겨나게 된다.

각 프로젝트마다 유니크하게 발생하는 이런 모든 문제점을 파악하고 해결하는 것 투입된 서로 낯선 인력들과의 원활한 커뮤니케이션을 통한 협업의 유도를 원활하게 이끌어 내는 PM이라는 직업에 대해서 크게 나눠서 한번 살펴보았다.

대부분의 PM 채용공고를 보면 첫 번째와 두 번째 경우이다. 경력 10년 내외의 실질적으로 일하는 인력에 대한 요구가 많기 때문일 것이다. 그렇다면 다음 시간에는 이렇게 알아본 PM의 각 분류로 진입하고 단계에 올라설 수 있는 방법에 대해서 알아보도록 하자.

리뷰게시판 초하류

편집 : 딴지일보 너클볼러