PM, PL, 그리고 개발자
각자의 위치
프로젝트에는 위치가 있다. 개발만 하는 사람, 파트를 이끄는 사람, 프로젝트 전체를 관리하는 사람. 직급은 회사마다 다르지만, 역할은 비슷하다.
신입일 때는 코딩의 기본 지식만 있으면 된다. 혼자서 기능 하나를 개발하기에도 힘들다. 프로젝트에 적응하기도 힘들기 때문에 사수 한 명과 같이 진행한다. 사수는 프로젝트마다 달라질 수 있다.
사수의 보조 역할이다. 사수가 할당해 주는 업무만 진행하면 된다. 상대하는 사람도 사수만 해당한다. 간단한 기능을 맡아서 개발하고, 막히면 물어보고, 코드 리뷰를 받고, 수정한다.
신입 때는 전체를 볼 필요가 없다. 화면 설계서 100페이지 중에서 자신이 맡은 2페이지만 보면 된다. 데이터가 어디서 와서 어디로 가는지도 사수가 알려준다. 그냥 시키는 대로 하면 된다.
앞서 전체를 봐야 한다고 이야기했지만, 모든 게 처음인 신입이 100페이지 이상의 화면 설계서를 보면 혼란만 가중될 뿐이다. 사수가 알려주고 지시하는 것만 해도 벅찬 시기이다. ‘프로그래밍이란 이렇구나’라는 것을 알아가는 시기다. 학교나 학원에서 동료와 진행하는 프로젝트와는 양적이나 질적으로 완전히 다르다는 것을 알아가야 한다.
하지만 그게 3년, 5년 계속되면 문제가 된다. 언제까지 누군가 알려주기를 기다릴 수는 없다. 화면 설계서 전체를 읽기 시작해야 한다. 자신이 만드는 기능이 전체 흐름에서 어디에 위치하는지 파악해야 한다.
5년 차 이상이면 혼자서 할당된 기능이나 화면에 대해서는 책임지고 만들 수 있어야 한다. 사수와 같이 진행되거나, 혼자서 진행하는 경우도 있다.
프로젝트를 설정할 수 있어야 한다. 개발에서 프로젝트를 설정하는 방법은 의외로 쉽지 않다. 서버의 개념도 얼마 정도 알아야 하고, 프로젝트에 필요한 라이브러리도 설정할 수 있어야 한다.
공통된 기능이라든지 파트의 한 부분을 맡아서 진행한다. 다른 연관된 개발자들과 상대해야 한다. 로그인 기능을 만든다면 회원가입 담당 개발자와 소통해야 한다. 어떤 데이터를 넘겨줄지, 어떤 형식으로 받을지 협의한다.
이 시기에 사수가 된다. 신입이나 초급 개발자와 같이 작업한다. 업무를 할당하고, 가이드하고, 코드 리뷰를 해준다. 처음으로 누군가를 이끄는 경험을 한다.
대부분 이 시기에 이직을 준비한다. 어느 정도 개발 실력이 올라오고 혼자서 만들 수 있는 수준이 되면 더 큰 회사를 보게 되거나, 연봉에 대해서 민감해진다. 프리랜서로 전향하는 경우도 많은 시기다.
기업체에서도 가장 많이 찾는 경력이다. 신입은 처음부터 가르치기 부담스럽고, 10년 이상을 일반 개발자로 채용하는 것도 부담스럽다.
10년 차 이상이면 한 파트를 책임지고 진행한다. 파트 단위는 프로젝트마다 다르다. 쇼핑몰이라면 장바구니/주문/결제를 한 파트로 보고, 상품 리스트/상품 상세를 한 파트로, 회원가입/로그인을 한 파트로, 마이페이지를 한 파트로 본다.
화면 설계서를 보고 기능별로 나누고 정리할 수 있어야 한다. 그냥 단순히 정리하는 것이 아닌, 공통된 부분은 따로 정리해야 한다. 어떤 기능을 누구에게 할당할지, 어떤 순서로 개발할지, 언제까지 완료할지 계획한다.
PL이 되는 시기다. PL은 Project Leader, 프로젝트 리더다. 파트를 책임지는 위치다. 파트 전체나 공통된 기능을 관리하거나 개발하는 업무를 진행한다. 개발자들과 상대도 하지만, 고객과도 상대해야 한다.
차세대 프로젝트에서 프론트엔드 개발 파트의 PL이 됐을 때가 그랬다. 프론트엔드 개발자들의 작업을 분배하고, 진도를 체크하고, 이슈를 해결했다. 백엔드 팀과 협업 구조를 만들고, API 명세서를 검토하고, 공통 컴포넌트를 설계했다.
업무가 늘어났지만 책임감이 생겼다. 단순히 주어진 기능을 개발하는 게 아니라, 파트 전체의 방향을 만들어간다는 느낌이었다.
PM은 Project Manager, 프로젝트 관리자다. 전체 프로젝트를 관리하는 위치다. 실제 개발자보다는 관리자에 가깝다. 일정을 관리하고, 이슈를 조율하고, 고객과 소통하고, 각 파트의 진행 상황을 체크한다.
아침마다 각 PL들로부터 일정과 이슈 사항을 보고받는다. 대부분 회의를 통해 전달받지만, 간소화하면 메일로 받는다. 지연되는 파트가 있으면 원인을 파악하고, 인력을 재배치하거나, 일정을 조정한다.
고객과 주로 미팅한다. 기획 변경 요청이 들어오면 개발 가능 여부를 검토한다. PL들과 협의해서 일정 영향도를 파악하고, 고객에게 답변한다. 때로는 불가능하다고 설득해야 하고, 때로는 어떻게든 가능하게 만들어야 한다.
대규모 프로젝트에는 여러 회사가 참여한다. 각 협력사는 현장 관리를 위해 PM을 파견한다. 계약 회사 PM이다. 소속 회사 인력들을 관리하는 역할이다. 전체 프로젝트 PM과 협의하고, 자기 회사 개발자들의 일정과 이슈를 챙긴다.
차세대 프로젝트에서 수평적 개발 방식을 제안했을 때, 계약 회사 PM이 1주일 실험을 승낙했다. PM의 결정 하나가 프로젝트 방식을 바꿨다.
프로젝트는 유기적이다. PM 혼자 프로젝트를 관리할 수 없다. PL들이 각 파트를 책임지고, 개발자들이 실제 코드를 만들어야 프로젝트가 진행된다. 하나라도 빠지면 돌아가지 않는다.
신입 개발자가 막히면 사수가 도와준다. 사수가 해결 못 하면 PL이 나선다. PL도 막히면 다른 파트 PL에게 물어보거나 PM에게 보고한다. PM은 고객과 협의하거나 외부 전문가를 투입한다.
반대로 고객의 요구사항 변경은 PM을 거쳐 PL에게 전달되고, PL은 개발자들에게 할당한다. 개발자가 불가능하다고 판단하면 다시 PL을 거쳐 PM에게 올라가고, PM이 고객과 재협의한다.
이 흐름이 막히면 프로젝트가 멈춘다. PM이 일정만 재촉하고 현장을 모르면 개발자들이 지친다. PL이 파트 이슈를 PM에게 보고하지 않으면 일정이 어긋난다. 개발자가 막힌 부분을 숨기고 혼자 끙끙 앓으면 전체가 지연된다.
일반 개발자가 고객과 직접 소통하면 문제가 반드시 발생한다. 또한 PL이 PM이 모르게 고객과 소통해도 문제가 발생한다.
고객은 어떻게 해서든 기능 하나를 더 추가하고 싶고, 자기가 담당하는 부분을 빨리 수정하고 싶어 한다. 고객이 일반 개발자에게 직접 연락해서 수정이나 추가 요청을 하게 되면 PM, PL이 짜놓은 일정이 무너진다. 또한 책임에 대한 대상도 개발자에게 돌아가기에 PM, PL이 도와주는 것에 한계가 있다.
다시 말해 일정, 관계 다 꼬인다. 프로젝트에서는 반드시 소통 채널을 통해 소통해야 한다.
각 위치마다 싸우는 게 다르다. 신입은 코드와 싸운다. 5년 차는 설계와 싸운다. 10년 차는 일정과 싸운다. PM은 고객과 싸운다. - 싸운다라는 표현이 과격할 수도 있지만, 적절한 단어가 생각이 나지 않는다. 실제 싸우고 이겨야 할 대상들이다. -
신입 때는 코드 한 줄이 안 풀려서 밤을 샌다. 5년 차 때는 구조를 어떻게 짤지 고민하다 주말을 보낸다. 10년 차 때는 파트 일정을 맞추려고 팀원들 일정을 조율하느라 회의만 한다. PM은 고객 요구와 개발 현실 사이에서 줄타기한다.
각자의 자리에서 각자의 전쟁을 치른다. 신입이 PL을 부러워하고, PL이 평개발자를 그리워한다. PM은 코드나 짜고 싶다고 말한다. 하지만 각자의 자리에서 할 일이 있다.
25년 동안 모든 자리를 거쳤다. 신입으로 윗사람 눈치를 봤고(지금까지 사수가 없었다.), 5년 차로 혼자서 기능을 책임졌고, 10년 차로 파트를 이끌었고, PM으로 프로젝트를 관리했다. 어느 자리가 편한지 물으면 답하기 어렵다. 각 자리마다 다른 무게가 있다.
중요한 건 자신의 자리에서 역할을 다하는 것이다. 신입은 주어진 업무에 충실하고, 5년 차는 잘 만들고, 10년 차는 잘 이끌고, PM은 잘 조율하는 것이 프로젝트를 완성하는 방법이다.
역할까지는 기본이다. 역할 범위를 넘어 더 한다면 주목받기 시작한다. 주목받는다라는 의미는 책임도 같이 온다는 의미다. 일을 정말 잘한다. 그 사람은 믿을 수 있다. 그 사람이 있어야 한다.라는 대체 불가 인력은 범위선 이상에서 이뤄진다.
