[SI이야기] SI프로젝트에서 PL이 하는 일

오늘은 슈 과장이 가장 최근까지 했던 일에 대해서 이야기해보겠다. (그렇다, 슈 과장은 PL이었다.) PM과 같은 듯하지만 다른 PL의 업무에 대해서 하나씩 살펴보도록 하자.

 

0. PL(Project Leader / Part Leader)

PL은 PM과 달리 관리자의 Manager라는 단어보다 Leader라는 단어가 들어간다. 관리자라기보다 리더의 역할이 있다. PM 아래에는 모두가 관리 포인트로서 존재한다면, PL 아래에서는 모두가 프로젝트 수행원으로 존재한다고나 할까? (절대 슈 과장이 PL이었기 때문에 묘사하는 것이 아니다.)

 

PL의 주요 업무를 묻는다면, 그건 '업무에 대한 정리'라고 하겠다. 우리가 무엇을 개발할지 어떻게 개발할지에 대해서 고객도 만족하고 개발자도 만족하는 방법을 찾는 일이 PL이 해야 하는 일이다. PM은 그 환경을 주고 PL은 그걸 해내야 하는 사람이다.

 

PL이 하는 일의 특징을 하나씩 살펴보도록 하겠다. 정확히는 슈 과장이 어떻게 PL로서 일했는지를 짚어보도록 하겠다. 어떤 본보기로서 적합하다...라고 자신 있게 말하지는 못하지만 욕먹는 PL은 아니었다. 계속 PL을 시키려고 회사는 생각했으나, 힘들어서 최근에 업무를 바꿨다. 슈 과장이 생각하는 PL의 업무가 다른 사람들이 생각하는 것과는 다소 다를 수 있으니 참고로 읽기를 바란다...

---

1. PM은 허수아비다.

PL은 PM 아래에서 PM의 지시하에 움직이고 일을 하는 사람이다. PM이 어떻게 하라고 하면 해야 하고 저렇게 하라고 하면 해야 한다. 하지만 일을 하다 보면 자연스럽게 깨닫게 되는 부분이 있다. 결국 PM은 PL이 고객과 협의해놓은 상세 내용을 가지고 가서 고객에게 보고하는 사람이라는 것을 말이다. 여기서 포인트는 '상세 내용'이다. PL은 큰 줄기에 대한 권한이 많지는 않다. 어차피 그건 제안서에 다 명시되어 있으니 말이다. 하지만 상세는 프로젝트 들어가서 정의를 하게 된다. 이 정의는 PM이 챙기지 못하는 부분으로서 PL이 정의를 해야 하는 부분이다. 

 

그런데 왜 PM이 허수아비냐? 그건 두 가지 이유다. 첫 번째로는 PM이 결국 PL의 상세 내용을 보고하는 사람이기 때문도 있고, 두 번째로는 PL이 고객과의 협의에서 밀리거나 질 것 같을 때 PM 뒤로 숨을 수 있기 때문이다. "아 그건, 제가 의사 결정할 수 있는 부분이 아닙니다. PM과 다시 이야기하시죠." 그러고 PM과 작전을 짤 수가 있다. 엄청나게 노련한 PM을 만나면 PM과의 회의가 승리를 보장하기도 한다. 고객이 까마귀라면, 우리 허수아비를 보면 도망간다고나 할까? 후훗

 

2. PL은 다 잘해야 한다.

슈 과장이 다 잘한다는 것은 아니다. 다 잘하지 못해서 너무나도 힘들었다. 뭘 잘해야 하는지... 보자... (하아 한숨)

 

2.1 말을 못 하면 다른걸 다 잘해도 PL은 못한다.

PL은 PM 다음으로 고객과 많이 대화하는 사람이기 때문에 말을 잘해야 한다. 어색한 기류가 맴도는 낯섦에서 스몰 토크(small talk)를 시작할 수 있어야 하고, 그 새로 만나는 사람들과 친해질 수 있어야 하고, 누구의 편도 되지 않으면서 모두의 편이 될 수 있어야 한다. 고객이 요구하는 내용을 수용하되 호의를 베풀듯이 수용하고, 거절할 경우에도 합당한 거절로 기분이 상하게 해서는 안된다. 고객이 IT를 잘 모르는 경우 쉽게 이해할 수 있게 설명을 해줘야 하지만 기분이 상하지 않게(자존심 상하지 않게) 말해야 한다. 가끔은 뻔뻔하게 철판 깔고 대답할 수 있어야 하고, 어쩔 때는 비굴하고 초라해 보일지 몰라도 사과하고 이해를 구하고 사정하고 빌어야 할 수도 있다. 이 모든 걸 PL이 하는 이유는 단 한 가지다. '시간 안에 프로젝트를 잘 끝내기 위해서' 이거 하나다. PL은 그걸 위해 저 모든 대화를 한다.

 

2.2 소속 인력이 무엇을 하는지 알아야 한다.

PL에 따라서 맡게 되는 조직의 규모가 다르다. 규모가 커질수록 PL이 PM처럼 일하게 되는데 이런 경우는 프로젝트가 건강하게 굴러가기가 다소 힘들다. 그 이유는 PL이 같이 일하는 직원에 대해 알고 있어야 하는 정보의 수준이 매우 디테일해야 하기 때문이다. 실제로 슈 과장은 PL로 있을 때 같은 소속의 직원들이 어떤 일을 맡고 있는지, 얼마나 빨리 일을 하는지, 어떤 일을 잘하는지, 어떤 식으로 문제를 해결하는지 등 모든 것들을 알고 있었다. 물론 그 사람이 오후 3시에 뭐 했고 오후 4시에 뭐 했는지는 알지 못했다. 그 사람이 커피를 마시러 갔는지, 놀러 갔는지도 알 수 없었다. 하지만 그 사람이 금요일이면 어디까지 일을 해놓을 거라는 사실은 알고 있었다. 주말에 나오게 되면 그 사실도 알고 있었고, 야근을 하면 무엇 때문에 왜 남아서까지 했는지도 다 알았다. 

 

이렇게까지 알아야 하는 이유? 그 프로젝트할 동안에는 내 가족이었기 때문이다. 어떤 일이 막혀서 어려워서 기술적으로 부담이 된다고 하면 그걸 해결하기 위해 같이 고민을 했다. 어떤 일을 해왔는데 문제가 있다면 어쩌다 그렇게 됐는지 파악을 같이 했고 같이 해결을 했다. 그렇게 하나 둘 지켜보며 내가 고객과 이야기하며 하기로 한 일들이 기술적으로 어떤 장단점이 있었는지를 배워갔다. 필요하면 고객에게 사정해서 그 부분을 없애기도 했고, 다른 방법으로 하게 해달라고 회의를 요청하기도 했다. 내가 관리가 목적이었다면 개발자들은 나에게 이야기를 해주는 일이 보고에 지나지 않았을 것이다. 하지만 해결해준다는 믿음이 있었고, 내가 해결해주기 위해 노력한다는 것을 알았기 때문에 이들은 문제가 생기면 씨름을 해보다가 먼저 나에게 와서 도움을 요청했다. 모든 것을 해결해주지는 못했지만, 나의 최선이었다는 것을 모두가 이해해줬던 것 같다.

 

슈 과장은 PL로 일하면서 개발자들과 일일보고, 주간보고를 단 한 번도 해본 적이 없다. 주간보고를 프로젝트 내내 직접 다 쓴 적도 있었다. 내가 주간보고를 쓰고, 각 개발자들에게 컨펌을 받았었다. 결국 보고하는 사람은 나였고 나는 내 파트 직원들이 뭐했는지 다 알았으니 전혀 문제가 없었다.

 

2.3 문서 작업을 잘해야 한다.

PL은 개발자가 아니다. PL은 관리자이면서 실무자다. 되게 애매한 역할인데 중요한 것은 한 가지를 앉아서 할 수 있는 사람은 아니라는 것이다. 프로젝트 들어와서 맡은 영역의 요구사항을 정의하고, 세부 요건까지 협의하고, 확정하고, 기술적으로 설계를 하고, 개발자에게 일정에 맞게 일을 나눠주고, 그 모든 것을 매주 보고하고 필요하면 부수적인 보고를 해야 하는 게 PL의 역할이다. 필요하면 PL이 문서작업도 하게 되는데 사실 문서 작업 안 하는 PL은 본 적이 없을 정도로 PL에게 문서 작업은 뗄레야 뗄 수 없는 관계다. 

 

슈 과장은 산출물도 작성했다. 개발자들이 개발할 수 있게 내가 직접 작성할 수 있는 산출물은 내가 다 작성했다. 데이터 값 검증도 내가 했고, 기능 테스트도, 버그 찾는 일도, 필요하면 테이블 raw data까지 다 열어봤다. 작성하지 못하는 산출물 몇 개를 제외하고는 다 작성했다. 실제 계약서에 협력업체에서 작성해야 했던 산출물이었어도 내가 작성했고, 협력업체에서는 작성해준 걸로 가름하기도 했다. 인력이 부족한 상황에서 개발할 줄 모르는 내가 도울 수 있는 방법은 그뿐이었다.

 

참고로 산출물이라는 건 프로젝트의 Output인데 주로 ppt, word, excel과 같은 형태로 정리가 된다. 그 기준으로 요구된 일을 했냐 안했냐를 가름하고 검수의 기준이 되기도 하는 만큼 그 문서의 내용에 대해서 최종 확정이 될 때까지 수정 요청이 지속적으로 들어오게 된다. 개발하면서 무언가가 바뀌면 문서도 다 싱크를 맞춰줘야 하는 번거로움도 존재한다. 그렇기 때문에 프로젝트에서 산출물은 최소화하는 게 좋다. ^^ 개발자들은 문서작업을 싫어한다.(슈 과장도 싫어한다.)

 

 

4. PL은 야근이 많다.

관리자가 야근이 많다니 의외라 생각할 수 있다. 실제로 인터넷에서 개발자로서 올린 글들을 자주 보게 되는데 그때마다 보이는 글들이 '나는 야근을 엄청 하는데, 관리자들은 다 퇴근하고 없다'이다. 그게 맞는지 틀린지는 사실 컨펌을 해줄 수가 없다. 그게 어디까지나 그 사람의 특성이기 때문에 내가 대답할 수 있는 범위 밖의 일이다. 하지만 내가 PL 할 때는 내가 파트원 보다 먼저 퇴근한 날은 1주일에 1일 정도였던 것 같다. 그 외에는 다 나보다 먼저 퇴근하거나 다 같이 퇴근했다. 

 

왜 야근이 많냐? 그건 내가 관리하는 파트의 개발자들을 지원하기 위해서 안 한 건 먼저 봐 두고, 다 한건 다시 확인해야 하기 때문이다. 요구사항을 받아서 개발할 내용을 설계할 때도 고객사의 상황을 파악하고, 개발 환경을 확인해가며 설계를 하는 것이 PL 역할이다. 내가 늦어질수록 개발자들이 손 놓고 앉아있는 시간이 늘어나는 것이고 그럼 개발 기간 뒤로 갈수록 힘들어진다는 이야기다. 그걸 막기 위해서는 미리 고민하고 미리 설계를 다 해놓아야 하는 것이다. PL은 언제나 일정에 쫓기면서 일을 한다. 설계를 내놓고 개발자에게 개발 업무를 넘겨도, 그들이 어떠한 이유로든 개발을 잘못해서 재작업하는 일이 적도록 계속 확인하고 검증하는 것도 PL의 역할이다. 그렇기 때문에 뭘 해도 시간이 부족한 게 PL이다.

 

심지어 데이터 검증이 중요한 프로젝트를 한다면 PL의 일이 더 힘들 수가 있다. 매일 남아서 값 검증을 한 적이 있는데, 정말 봐도 봐도 끝이 없었고 볼 때마다 새로 찾아내는 부분들이 있었다. 그래서 평일 오후 6시부터는 값 검증을 하는 일과를 잡았었는데, 퇴근할 때마다 나를 안쓰럽게 보던 옆 파트 PL의 얼굴이 기억이 난다.

 

52시간 근무를 꽉꽉 채워서 프로젝트를 했던 유일한 인력이었던 나는... PL이 당연히 그래야 한다고 생각했다. 당연히 힘들었고, 가끔은 서러웠고, 억울했고, 화가 났었다. PM 못지않게 PL도 업무적으로 외로울 때가 많다. 하지만 같이 일하는 사람들을 더 고생시킬 수가 없었고, 제시간에 철수하고 싶은 마음뿐이었다...

 

 

5. PL의 장점... PL 경험은 커리어가 된다.

지난 포스팅에서 리멤버 커리어에서 오퍼 받은 이야기를 적은 적이 있었다.

2020/03/24 - [슈르의 오피스라이프] - 리멤버 커리어에서 채용 포지션 제안 받은 후기

여기서 나에게 오퍼가 온 이유는 대부분 PL 경험 때문이었으리라 짐작하고 있다. PL로 일했던 프로젝트들의 연속선상에 있는 업무들이 오퍼로 왔기 때문이다. 그리고 나에게 요구했던 업무 역량도 PL로서의 역량이었다.(대표적으로 저 위의 2.1번...) SI 프로젝트의 PL은 현업(Biz)에서 요구한 내용을 IT로 온전하게 구현할 수 있느냐의 도전을 받는데, 그 역량은 Biz와 IT의 용어나 표현 방식을 가운데에서 잘 이해하고 중재하는 능력이다. 개인적으로 보기에 쉽게 얻는 능력은 아니다. 문과생에게 IT를 이해하라고 하면 어려워하고, IT에게 비즈니스를 이해하라고 백날 설명해도 그걸 개발로 설계하는 게 어렵기 때문이다.

 

슈 과장이라고 그걸 '잘한다' 하긴 사실 어렵지만 슈 과장은 그 일을 어떻게 해냈는지 간단하게 공유를 하자면, 항상 모든 걸 '그렸다'. 누구와 무엇을 협의하든, 정리하든, 설명을 하든 항상 그걸 가시적으로 보여줬다. 말로 표현할 때 발생하는 이해의 차이를 막기 위해 항상 예시를 들어서 그림을 그리고 설명했다. 내가 낙서한 걸 찍어간 사람도 있고, 이면지를 받아간 사람들이 있을 정도로, 서랍 한 칸이 이면지로 쌓여있을 정도로 계속 이면지를 썼다. 그리고 그렇게 했을 때 현업과 개발자가 생각하는 그림이 온전히 일치할 수 있었다. 그리고 예외 case까지 찾아낼 수 있었다.

 

역시 위의 이야기처럼 문서 작업이 엄청나게 많아지는 일이긴 했다. 그 문서의 양을 생각하면 정말 한숨만 나온다. PPT로 그림을 그리고 수정한 게 한두 번이 아니니 말이다. 하지만 '서로 잘못 이해했다', '전달이 잘못되었다'는 이야기는 거의 듣지 못했다. 프로젝트에서 Mis-communication이 제일 위험하다. 나는 실제로 그 부분을 인정받아서 채용 오퍼를 많이 받았던 것 같다.

---

확실히 PL은 힘들다. 다시 하라면 목에 칼이 들어와도 안 한다고 할 정도로 힘들었다. 혼자 모든 걸 다 짊어지고 간다는 게 생각처럼 쉽지가 않았다. 체력적으로도 힘들었고 결정적으로 건강이 많이 망가졌다. 너무나도 좋은 사람들하고 일해서 하루 종일 웃고 떠들었지만 저녁에 홀로 남아 PL로서 마지막까지 끙끙대며 일하는 건 너무나도 외로운 일이었다. 건강검진 결과가 나쁘게 나온 걸 듣자마자 모든 것을 다 그만두기로 결심했을 정도로, PL의 일은 힘들었다.

 

하지만 경험은 값진 것이었다. 잊지 못하는 경험이고, 지금의 나를 더 발전시켰다는 점에선 의심의 여지가 없다. 개발자라고 다 PL을 할 수 있는 것은 아니다. 하지만 주위에서 PL을 하면 잘할 것 같다는 이야기를 들었다면 (위의 내용을 미루어보았을 때 타당한 이유로), 한번 해보는 것도 추천한다. 새로운 커리어 경험을 쌓을 수 있을 것이다.