SI 회사의 PM/PL은 무슨 일을 할까?

얼마 전, 옆 부서에서 진행하는 시스템 구축 프로젝트가 난항을 겪고 있다는 소식을 들었습니다. 프로젝트의 첫 번째 프로젝트 매니저(Project Manager, 이하 PM)가 제대로 일을 시작하기 전 퇴사하고, 두 번째 PM도 요구사항을 분석하고 기획하던 와중 퇴사했기 때문입니다. 정신을 차려보니 어느새 제가 그 프로젝트의 프로젝트 리더(Project Leader, 이하 PL)가 되어 있었습니다. 본격적으로 개발을 시작하기도 전, 두 번이나 PM이 바뀐 탓에 이 프로젝트의 초기는 말 그대로 ‘혼란’ 그 자체였습니다.

그런데 왜 프로젝트 진행이 구성원 하나 바뀌었다고 어려워지는 걸까요? SI 회사의 PM은 도대체 어떤 일을 하기에 이런 일이 생겼을까요? 이번 글에서는 SI 회사 프로젝트 관리 담당자의 역할과 중요성에 대해 다루어보고자 합니다.

PM은 어떤 일을 할까?

SI 기업의 PM은 프로젝트를 지휘하고 관리하는 총책임자입니다. 이해관계자들의 원활한 커뮤니케이션을 위해 의견을 조율하며 프로젝트 구성원들의 일정과 이슈 관리를 수행합니다.

1. 모든 것을 관리한다

프로젝트(Project)와 매니저(Manager)라는 단어에 걸맞게 프로젝트의 모든 것을 관리하는 것이 PM의 업무라고 말할 수 있습니다. PM을 맡는 순간, 담당자는 실무를 잠시 내려놓고 주로 관리자의 업무를 하게 됩니다. 고객을 관리하는 것부터 시작하여 프로젝트에 속한 인원도 챙겨야 하고, 팀장에게 프로젝트가 잘 진행되는지 역시 보고해야 합니다. 이처럼 사람을 관리하는 것뿐만 아니라 프로젝트의 진행 일정도 관리합니다. 프로젝트가 정해진 계획대로 진행되는지 체크하며 납기일에 맞게 고객이 원하는 품질로 만들어지도록 이끌죠. 이때 부족한 점을 발견하면 메꾸어야 합니다.

2. 보고, 그리고 보고

프로젝트의 이해관계자가 많을수록 당연히 보고의 횟수와 양도 많아집니다. 보고가 정말 끝도 없이 필요합니다. 착수, 중간, 최종 보고는 물론이고 주간 보고도 진행합니다. 이런 보고는 프로젝트의 주인이라 할 수 있는 PM이 맡습니다. 착수 보고에서는 이 프로젝트가 앞으로 어떻게 진행될지, 중간 보고에서는 어떻게 진행되고 있는지, 최종 보고에서는 어떤 성과로 마무리 되었는지를 보고합니다. 매주 주간 보고에서는 프로젝트가 계획대로 가고 있는지 고객에게 설명해야 합니다. 이슈가 발생했다면, 그 원인과 현재 상황에 대해 보고하며 영향도와 조치 상황 역시 함께 보고합니다.

3. 프로젝트의 분위기를 결정한다

SI 회사 내에서는 ‘프바프’라는 말을 자주 씁니다. ‘프로젝트 바이 프로젝트(Project by Project)’의 줄임말로, 이를테면 신입 사원이 “칼퇴 가능한가요?”라고 물을 때, “프바프입니다.”라고 답할 수 있습니다. 이러한 프로젝트의 분위기는 역시 PM의 성향에 따라 달라질 수 있습니다. 프로젝트 내에서 PM이 세우는 그라운드 룰(Ground Rule)이 법이 되기 때문입니다.

만약 고객에게 보이는 업무 태도도 일의 일부라고 생각하는 PM을 만나면, 업무량과 상관없이 출근 시간 보다 일찍 출근해 야근까지 할 것을 요구받을 수 있습니다. 반면 그런 것을 신경 쓰지 않는 PM을 만나면 출퇴근 시간에 자율성이 생기는 대신, 본인 업무에 대한 책임감이 가중될 수 있습니다. 이외에도 PM의 성향에 따라 고객사와의 관계가 결정되고, 그에 따라 적대적인 고객 또는 협조적인 고객이라는 이미지가 형성됩니다.

4. 고객과 프로젝트의 소통 창구

고객과의 커뮤니케이션 역시 주로 PM이 담당합니다. 사소한 것은 PL이나 개발자들이 바로 소통하지만, 의사결정에 관련된 사항이나 클레임 등에 대해서는 PM이 판단하고 해결합니다. 이 밖에도 프로젝트를 하다 보면, 진척 사항에 대한 문의나 개발 요구사항에 대한 변경 요청도 빈번하게 발생합니다. 이때는 프로젝트에 대해 제일 많이 알고 있는 PM이 이에 응대합니다. 필요에 따라 실무 개발자들에 의견을 구하면서 고객과 소통하죠. 프로젝트의 소통 창구인 만큼 PM의 커뮤니케이션 능력이 중요합니다.

고객과의 커뮤니케이션에서 가장 중요한 점이 있습니다. 바로 상대방의 언어로 설명해야 한다는 점입니다. 개발 이슈를 고객의 언어로 전달하는 상황을 개발자와 PM, 고객과 PM의 대화 예시로 보겠습니다.

개발자: 오픈 API 통신 시에 HTTP 403 forbidden 에러가 떨어져요. 방화벽이 안 뚫려있는 것 같아요.

PM: 네트워크 담당자를 통해 방화벽 오픈 여부 확인해 볼게요.

고객: 이 기능 개발은 왜 지연되고 있나요?

PM: 우리 시스템은 내부 폐쇄망의 서버를 사용 중이라 외부와 단절되어 있다고 보시면 됩니다. 이 기능을 사용하기 위해서는 외부에 있는 서버와 통신이 필요합니다. 따라서 방화벽 설정을 할 때 서버의 주소를 특정하고 허용해 줘야 하는데, 해당 부분을 미처 고려하지 못해 지연되었습니다.

만약 개발자의 말을 그대로 전했다면 개발을 모르는 고객은 상황을 전혀 이해하지 못했을 겁니다. 상대방의 언어로 설명하는 것이 중요한 이유입니다.

PL은 어떤 일을 할까?

프로젝트 관리를 위한 일이 이토록 많기 때문에 PM을 돕는 직군이 있습니다. 앞서 프로젝트에서 제가 맡은 역할, PL(Project Leader)에 대해서도 살펴 보고자 합니다. 우선 SI 회사의 PM과 PL이 프로젝트에서 어떤 역할을 하는지 정리해 보겠습니다.

PL은 PM과 개발자를 연결하는 징검다리 역할입니다. 그래서 PL의 상세 업무는 PM이 어떤 일을 맡기는 지에 따라 달라집니다. PL의 숫자 역시 프로젝트의 크기에 따라 정해집니다. 영역별로 PL을 한 명씩 두어 관리하는 대규모 프로젝트도 있고 전체 프로젝트에 한 명만 두기도 합니다. 물론 이처럼 그때그때 조금씩 다르지만, 대표적인 PL의 업무를 정리해 보겠습니다.

1. 문서를 만들고 산출물을 관리한다

PL은 개발도 진척 문서 및 산출물을 관리합니다. 우선 개발자들이 일정에 맞게 진행할 수 있는 업무를 분배합니다. 즉, 어떤 화면을, 어떤 개발자가, 언제까지 완성해야 하는지를 파일로 정리합니다. 산출물 관리의 경우, PL마다 다를 것 같은데 제 경우에는 DB 정의서나 인터페이스 정의서를 관리하였습니다. 인터페이스 정의서를 예로 들면, 변경되어야 할 인프라 정보와 주고받아야 할 데이터를 꾸준히 하나의 문서로 정리해야 합니다. 문서가 정리되면 해당 문서를 기반으로 연계 시스템 담당자들에게 일정을 안내합니다. 곧이어 일정 내에 개발이 완료되는지 팔로우업합니다. 개발이 끝나고 테스트 준비가 되면 담당 개발자에게 안내하여 인터페이스 테스트를 진행합니다. 테스트 진행과 그 결과는 다시 인터페이스 정의서에 기록하고 관리합니다.

2. 이슈 보고의 최전선

PL은 개발에 이슈가 발생하면 가장 먼저 알게 됩니다. 간단히 해결할 수 있는 문제라면, 개발자와 머리를 맞대어 일단 해결한 후에 PM에 “이러한 문제가 있었다.” 정도로 간략하게 보고할 수 있습니다. 간단한 문제가 아닌 경우에는 PM한테 이슈를 보고합니다. 곧 다른 방안을 함께 찾거나 고객에게 이슈를 보고해 프로젝트 일정을 연기하게 될 수도 있습니다.

3. 개발자와 가장 가까운 관리자

PM은 고객사와 회의가 많아 자리를 비우고는 합니다. 그렇기에 프로젝트 룸에서 개발자와 가깝게 지내는 사람은 PL입니다. 저 역시 프로젝트 투입 초반에 개발자들과 친밀감을 쌓기 위해 노력했습니다. 저보다 나이가 최소 10살 이상 많은 개발자의 업무를 관리하려면 친밀감 없이는 힘들다고 생각했기 때문입니다. PL은 개발자들의 개발 일정과 테스트 일정을 관리합니다. 개발 진척도를 체크하고 어떨 때는 일정을 독촉해야 하는 상황이 처음에는 어렵게 느껴질 수 있습니다. 그럴 때는 개발자와 스몰톡으로 먼저 마음의 벽을 허무는 것이 좋습니다. 친밀감을 만들고 나면 업무에 어떤 어려움이 있는지, 또는 일정 내에 마칠 수 있는지를 좀 더 쉽게 물어보며 개발 상황을 공유할 수 있습니다. 본인보다 경험이 많은 개발자와 협업할 때 먼저 친밀감을 쌓는 것, SI 회사에서 관리 역할을 맡을 사원을 위한 팁이기도 합니다.

만약 개발 과정에서 어려움이 생겼다면 이를 해결하기 위해 유관 업무 담당자를 수소문하는 것도 PL의 역할입니다. 해당 담당자를 찾아내 직접 해결법을 문의하거나 개발자와 연결해 주어 문제가 빨리 해결되도록 조치합니다.

4. 뭐든 다 한다

앞서 언급했듯, PM이 어떤 역할을 주는지에 따라 PL의 업무는 달라집니다. 저는 PL로 참여한 프로젝트에서 급한 일정을 맞추기 위해 개발자 역할을 맡기도 했습니다.

해당 프로젝트 중반부, 개발자의 갑작스러운 퇴사로 새로운 인력을 구하는 기간이 생기며 시스템 오픈 일자가 미뤄졌습니다. 그렇게 찾은 새로운 개발자도 일주일 만에 퇴사했을 때는 제가 일정을 맞추기 위해 개발에 투입되었습니다. 처음 PM에게 개발을 부탁받았을 때는 당황스러웠습니다. 개발자들이 작성한 코드를 본 적은 있었지만, 보는 것과 실제로 작성하는 것은 큰 차이가 있기 때문입니다. 다행히 제가 경험이 있던 기술 스택인 JAVA와 Vue.js를 사용한 시스템이어서 금방 적응할 수는 있었습니다. 다만 중요한 기능이 들어간 화면을 개발하는 데에는 짧은 시간 내에 무리가 있다고 판단하였습니다. 그래서 PM과 협의해 간단한 CRUD가 포함된 리스트 화면 개발을 할당받아 만들었습니다. 이처럼 PL은 PM의 지휘 아래 프로젝트 수행을 위한 역할은 뭐든 다 합니다.

마치며

PM은 프로젝트에서 매우 중요한 역할을 합니다. 고객과 PL, 개발자를 비롯해 무수한 관계자들은 배를 열심히 젓는 PM의 뒷모습을 쳐다보고 있습니다. 사원 때는 “너도 이제 PM 해야지!” 만큼 싫은 소리가 없었습니다. 부담은 큰 데다 은연중에 관리직인 PM 직무에 부정적인 시각도 있었습니다. 개발에서 손을 떼고 프로젝트 관리만 하는 PM이 학생 때부터 꿈꿔온 개발자의 모습과 다르다고 느꼈기 때문입니다.

제 이런 시각이 긍정적으로 바뀌게 된 계기가 있습니다. 글의 초반부 언급했던 프로젝트에 세 번째로 투입된 PM과 함께 일하면서부터입니다. PM은 실무를 잘 모른다고 생각했는데, 그분은 탄탄한 실무 지식을 가지고 있었습니다. 제가 개발이 막혀 고민이 깊어질 때는 코드를 보고 조언을 줄 수 있을 정도였죠. 또한 이러한 실무 지식을 바탕으로 프로젝트에 이슈가 생길 때마다 좋은 해결책을 제시했습니다. 곧 프로젝트는 제 선로를 찾아 성공적으로 시스템을 오픈했고, PM은 전문성을 인정받아 포상까지 받았습니다.

SI 회사에 입사한 신입사원은 저처럼 연차가 쌓여감에 따라 개발보다 프로젝트를 관리해야 한다는 점이 실망스럽게 다가올 수도 있을 겁니다. 하지만 부정적인 시각만 가지기보다는 열린 마음으로 이를 바라봤으면 좋겠습니다. 그만큼 PM이라는 직무는 충분히 가치 있는 자리입니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.