👊 2년차 개발자의 PL 도전기


오늘은 내가 가장 최근까지 하고 있는 일에 대해서 이야기해보겠다. 올해 3월, 입사한지 1년이 조금 넘은 시점에서 갑작스럽게 프로젝트 리딩 포지션을 제안받았다. 개발자로 투입되었던 작은 프로젝트들이었지만 여러가지 내부 상황으로 외부 개발인력들이 들어오면서 그 프로젝트들의 PL 역할을 맡게 된 것이다..! 두렵기도 했지만 갓 입사한 개발자가 이런 기회가 어디있을까 생각해 해보기로 하였다.

담당한 프로젝트는 개인금융 파트의 전산개발 프로젝트로, 작게 담보대출 상담사 전용 웹 개발, 부동산등기부등본/공시지가 웹스크래핑 API 연동 개발, 비대면 중도금 대출 및 전자서명 개발 프로젝트 3개로 구성되어있었다. 그 중 이미 기획과 개발단계에 참여하고 있던 2개 프로젝트가 있었기 때문에 용기를 내어 PL 역할을 맡게된 것도 이유가 있었다.(잘못된 생각이었다..😭)

PL은 PM과 다르게 관리자의 Manager라는 단어보다 Leader라는 단어가 들어간다. 관리자라기 보다는 리더의 역할이 있다. PM 아래에는 모두가 관리 포인트로서 존재한다면, PL 아래에서는 모두가 프로젝트 수행원으로 존재하는 느낌이었다.

경험한 PL의 주요 업무는 ‘업무에 대한 정리’이다. 우리가 무엇을 개발할지, 어떻게 개발할지에 대해서 고객도 만족하고 개발자도 만족하는 방법을 찾는 일이 PL이 해야하는 일이다. 내가 경험한 PL의 업무가 다른 사람들이 생각하는 것과는 다소 다를 수 있기 때문에 참고 부탁드립니다. 😅


💭 내가 경험한 PL은


  1. 커뮤니케이션을 잘 해야 한다.

    PL은 PM 다음으로 고객과 많이 대화하는 사람이기 때문에 말을 잘해야 한다. 새로 만나는 사람들과 친해질 수 있어야 하고, 누구의 편도 되지 않으면서 모두의 편이 될 수 있어야 한다. 나의 고객은 내부 직원들이었고 어느정도 안면이 트인 상황이어서 보다 수월할거라 생각했지만, 생각치 못한 어려웠던 점은 나보다 훨씬 경력이 있는 분들이라는 점이었다..! 현업분들이 요구하는 내용을 거절할 경우 최대한 합당한 거절 사유로 전산적인 내용은 최대한 쉽게 설명할 수 있도록 노력했다. 가끔은 뻔뻔하게 철판깔고 대답할 수 있어야 하고, 어쩔때는 사과하고 이해를 구하기도 하였다. 이 모든걸 하는 이유는 단 한가지 ‘시간 안에 프로젝트를 잘 끝내기 위해서’ 이다.

  2. 소속 개발자분들이 무엇을 하는지 알아야 한다.

    PL은 같이 일하는 개발자들에 대해 알고있어야 하는 정보의 수준이 디테일할 수록 긍정적인 작용을 한다. 소속 개발자분들이 어떤 일을 맡고 있는지, 얼마나 빨리 일을 하는지, 어떤 일을 잘하는지, 어떤 식으로 문제를 해결하는지 등 최대한 파악하려 노력했다. 그 이유는 프로젝트를 진행하는 동안에는 정말 내 동료분들이기 때문이다. 어떤 일이 막혀서 어려워서 부담이 된다고 하시면 그걸 해결하기 위해 함께 고민했다. 어떤 일을 해왔는데 문제가 있다면 어쩌다 그렇게 됐는지 파악을 같이 했고 같이 해결을 했다. 그렇게 하나 둘 지켜보며 내가 현업과 이야기하며 하기로 한 일들이 기술적으로 어떤 장단점이 있었는지를 배워갔다. 필요하면 현업과 이야기해 그 부분을 없애기도 하고, 다른 방법으로 하게 해달라고 미팅을 요청하기도 했다. 내가 관리가 목적이었다면 개발자분들은 나에게 이야기를 해주는 일이 보고에 지나지 않았을 것이다. 하지만 같이 해결해준다는 믿음이 있었고, 내가 끙끙대며 해결해주기 위해 노력한다는 것을 알았기 때문에 이들은 문제가 생기면 씨름을 해보다가 먼저 나에게 와서 도움을 요청하였다. 물론 모든 것을 해결해주지 못했지만 나의 최선이었다는 것을 모두가 이해해주셨던 것 같다.

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

    PL은 개발자가 아니라 실무자이다. 애매한 역할이긴 한데 중요한 것은 한가지를 앉아서 하는 사람은 아니라는 것이다. 프로젝트 들어와서 맡은 영역의 요구사항을 정의하고, 세부 요건까지 협의하고, 기술적으로 설계를 하고, 개발자분들에게 일정에 맞게 일을 나눠주고, 그 모든 것을 매주 보고하고 필요하면 부수적인 보고를 해야하는 게 PL의 역할이다. 특히 개발자분들이 개발할 수 있게 내가 직접 작성할 수 있는 산출물은 내가 다 작성했다. 따로 회사 내 기획자가 없기 때문에 현업에서 정의한 요건을 가지고 전산적으로 참고할만한 소스나 화면을 업데이트하여 공유했다. 데이터 값 검증, 기능 테스트, 버그 찾는 일에 필요하면 테이블 raw data까지 열어보았다. 인력이 부족한 상황에서 초보 PL가 도울 수 있는 방법은 그 뿐이었다. 여러 문서작업을 하면서 느낀 점은 개발하면서 무언가 바귀면 문서도 다 싱크를 맞춰줘야하기 때문에 프로젝트 산출물은 최소화 하는게 좋다. 😅

  4. 야근이 많다.

    내가 관리하는 프로젝트의 개발자분들을 지원하기 위해서는 안 한 건 먼저 봐두고, 다 한 건 다시 확인해야하기 때문이다. 요구사항을 받아서 개발할 내용을 설계할 때도 현업의 상황을 파악하고, 개발 환경을 확인해가며 설계를 하는 것이 PL의 역할이다. 내가 늦어질수록 개발자분들이 손 놓고 앉아있는 시간이 늘어나는 것이고 그럼 개발 기간 뒤로 갈수록 힘들어진다는 이야기이다. 그걸 막기 위해서는 미리 고민하고 미리 설계를 다 해놓아야 하는 것이다. PL은 언제나 일정에 쫒기면서 일을 해야 한다. 설계를 내놓고 개발자에게 개발 업무를 넘겨도, 어떤 이유로든 재작업하는 일이 적도록 계속 확인하고 검증하는 것도 PL의 역할이다. 그렇기 때문에 뭘 해도 시간이 너무 부족했다.
    심지어 웹스크래핑 프로젝트의 경우에는 데이터 검증이 매우 중요했다. 예를 들어 매매가의 경우 숫자(300000000), 콤마가 포함된 숫자(300,000,000), 한글(일금삼억원정) 등 아주 다양한 패턴으로 데이터가 내려왔다. 그래서 평일 오후 6시부터는 값 검증을 하는 일과를 잡고 최대한 많은 테스트 케이스를 정리하여 예외처리를 하였다.

  5. 업무 프로세스를 이해해야 한다.

    이 부분이 가장 어려웠다. 1년이 조금 넘은 시간동안 채널계 개발자였던 나에게, 계정계를 포함해 전체적인 업무 프로세스는 아직 미지의 세계였고 이해하기는 어려웠다. 하지만 지켜야 할 법규가 많고 복잡한 핀테크 환경이기 때문에, 업무 도메인을 정확히 이해하고 개발하기 위해 현업 담당자와 최대한의 커뮤니케이션을 하고자 했다. 비즈니스 도메인은 현업 담당자분들께 현재 운영중인 업무 프로세스와 관련 자료들을 요청하여 공부하였고, 계정계 서비스 개발 시 데이터 보관 주기나 암복호화 대상 컬럼 등 주의해야할 사항들을 쫒아다니며 질문했다. 내가 이해를 정확히 하고 이를 개발자분들에게 공유해야 하기 때문이다. 감사하게도 바쁜 업무 중에도 많은 도움을 주셔서 큰 이슈 업이 프로젝트를 완수할 수 있었다.


💪 PL 경험은 커리어가 된다 !


짧은 경력이지만 감사하게도 꾸준히 오퍼가 들어오고 있다. 여기서 나에게 오퍼가 오는 큰 이유 중 하나는 PL 경험이 긍정적인 작용을 했다고 생각한다. 현업에서 요구한 내용을 IT로 온전하게 구현할 수 있는지에 대한 역량은 비즈니스 도메인과 IT를 잘 이해하는지에 대한 능력이다. 물론 스스로가 그걸 ‘잘한다’ 하긴 어렵지만 잘 해내기 위해서 항상 모든걸 ‘그렸다’. 누구와 무엇을 협의하든, 정리하든, 설명을 하든 항상 그걸 가시적으로 보여줬다. 말로 표현할 때 발생하는 이해의 차이를 막기 위해 항상 예시를 들어서 그림을 그리고 설명했다. 서랍 한 칸이 이면지로 쌓아두고 항상 가지고 다니며 사용했다. 그리고 그렇게 했을 때 현업과 개발자가 생각하는 그림이 온전히 일치할 수 있었다. 그리고 예외 CASE 까지 찾아낼 수 있었다. 위의 이야기처럼 문서 작업이 엄청나게 많아지는 일이긴 했다. 하지만 ‘서로 잘못 이해했다’, ‘전달이 잘못되었다’ 는 이야기는 프로젝트를 진행하면서 줄어들 수 있었다.


확실히 PL은 힘들다. 다시 하라면 안할정도로 힘들었다. 아직 회사에 적응해나가고 비즈니스를 다 이해하지 못한 주니어 개발자에게는 생각처럼 쉽지 않았다. 체력적으로도 힘들었고 결정적으로 건강이 많이 망가졌다. 너무나도 좋은 사람들과 웃으며 일할 수 있었지만 저녁에 홀로 남아 마지막까지 끙끙대며 일하는 건 너무나도 외로운 일이었다.


하지만 경험은 값진 것이었다 ! 잊지 못하는 경험이고, 지금의 나를 더 발전시켰다는 점에선 의심의 여지가 없다. 개발자라고 다 PL을 할 수 있는 것은 아니라고 생각한다. 만약 주위에서 PL을 하면 잘할 것 같다는 이야기를 들었다면 한번 도전해보는 것도 추천한다. 비즈니스 전체를 바라보며 개발하는 새로운 커리어 경험을 쌓을 수 있을 것이다.