7년차 PM 의 커리어 고민 - 2020

나는 Back-end Platform PM 이다. 

개발자분들이 개발 셋을 가지고 있는 것처럼 백엔드 PM 은 개발 셋을 이해하는 기술(?) 을 가지고 있어야 한다고 생각한다. 

나는 IT 산업의 가치가 마음에 들었다. PM 업무를 하던 하루하루가 흥미로웠고, 돈벌이 이상의 의미였다. 미래에도 IT 산업에 기여하고 싶었다. 하지만 통상 PM 의 수명이 40대 초반 정도에 끝난다고들 했다. 그 이후에는? 사업이나 전략 직군으로 전환한다는 얘기도 많았다. PM 의 역할은 소위 어르신들이 하기에 너무 구질구질한 일이라고들 했다. 

맞는 말일지도. 사실 프로덕트 구현은 바람 잘 날이 없어서 외부에서 기대하는 것만큼 멋있는 일들만 하는 것은 아니다. 5% 의 멋있는 결정을 하기 위해 25 % 의 매 순간에 놓이는 의사결정, 프리젠테이션과 70% 의 스몰톡, 일정조율, 으쌰으쌰 분위기를 위한 회식일정 잡기 등등 의 일이 있다. 처음에는 프리젠테이션이나 의사결정 기여도가 적으니, 남는 것들을 할 수밖에. 

자존심이 상했다. 개발자의 '안되요' 단호한 말을 듣는 것이 지치기도 했다. 내가 기술이 없어서 겉도는 건가? 역시 IT 에서는 개발자가 짱인가? 라는 생각을 숱하게 했다. 마침 쿠팡의 신입개발자가 3~4년차인 나보다 돈을 더 번다는 소문도 들려왔다. 억울했다. 학교 다닐 때는 내가 더 공부를 잘했을텐데... 이래서 기술이 있어야 하나 싶었다. 

"이래서 기술이 있어야하나..."
모든 PM 들의 번뇌일듯.

 

PM 으로 몇 년 생활하니 그나마 의사결정 기여도가 높아지는 것이 스스로도 느껴졌다. 사업팀의 요구사항을 취합하고, 협의 하에 취사선택하였으며, 개발팀간 의견차가 있는 것들을 조율하기도 했다. PM 이 결정하는 것처럼 느껴질 수도 있겠지만, 사실 많은 사람들이 합의하고, 올바르게 결정할 수 있도록 지원하는 사람에 가깝다. (PO 쯤 되면 강단있게 의사결정할 수 있을지도. 물론 그 책임은 모두 PO 가 부담하는 것이다. )

모든 종류의 조율은 매우 섬세하게 다뤄야 한다. 이 것은 어느정도 타고나는 역량과 기질이 필요하다. 큰 수고로움 없이 조율과 설득을 잘 하는 PM 이 있다. 냉정하게 진단했을 때, 나는 그런 타고난 사람은 못되었다. 조율을 잘하는 PM 을 흉내내려고 해도 내가 따라하면 내 옷이 아닌 옷을 입은 느낌이 들었다. 조율의 형태도 개개인마다 달라서, 내가 흉내낸다고 동일한 효과를 가져오는 것은 아니었다.

나는 PM 인데 조율하는 역량이 부족하다. 추상적인 조율 역량은 도대체 어떻게 키우는 것인지도 감도 안 잡혔다. 돌이켜보면 그냥 시간이 필요했던 것 같지만. 당시에는 조바심나서 뭐라도 이 상황을 해결하고 싶었다. 그래서 선택한 것이 개발공부였다. 어차피 IT 에서 계속 일하고 싶었고, 개발자 분들처럼 기술을 갈고 닦아야겠다고 생각했다. 개발자의 '안되요' 단호한 말을 들으면서 절치부심으로 개발 공부했던 것 같기도 하다.

덕분에 지식 면에서 많은 부분 성장했다.

나는 어느순간 프로덕트 개발환경을 이해하고 개발을 잘 아는 PM 으로 인정받고 있었다.  

나의 경우는 이들을 업무를 하면서 배웠다. 개발 회의시간에 모르는 개념이 나오면 구글링하고, 이 기술이 다른 것들과 어떻게 조합되는지 검색결과를 숱하게 읽었다. '도메인 주도 개발', '마이크로 서비스', '응답결과를 단축시키기 위한 알고리즘 개선' 등 개발 트렌드를 읽고, 프로덕트 설계에 반영하려고 노력했다. 개발분들이 저런 설계를 도입하기 위해 검토 및 개발 일정이 담보되어야 한다고 하면, 기꺼이 일정을 조정했다. 개발 분들이 시간을 가지고 고민했을 때, 장기적인 관점에서 프로덕트의 질을 높인다고 믿고 있었기 때문이다. 그리고 나도 옆에서 같이 주워들었다. 내가 이 환경을 잘 이해해야 이후에 더 기꺼이 개발 일정을 조정하고, 그들의 고민을 이해할 수 있으니까. 

그리고 하나 더. 왜 이것도 모르냐고 면박당할 생각하지 않고 편하게 물어봤다. 내 근처에는 참 좋은 개발자 분들이 많았다. 내가 기술을 습득하는 것을 즐긴다는 것을 이해해주고, 물심양면 지원해주시는 고마웠던 분들. 어느 순간 기술이 아닌 논리로 설계를 잡아가는 나를 발견할 수 있었다. 

어차피 개발자들도 선행기술은 잘 모른다. (이름 그대로 선행기술이니까.) 단, 새로운 기술이나 프레임워크를 찾고 도입하는 과정을 즐기는 것이다. 모르면 더 잘 아는 분을 찾아서 물어본다. 우리 팀은 이렇게 선행기술을 검토하고 도입하는 사람을 '선삽자' 라고 한다. 먼저 삽질해주시는 매우 감사한 분이라는 뜻이다. 널리 전파되어야 하는 개념이다. 어쨌든 개발 기술은 옆에서 보면 마치 레고 블럭을 한개씩 쌓는 듯한 느낌. 그래서 나도 시작했다. 모르면 모르는 대로 듣고, 찾아보고, 대입해보았다. 기술은 복잡하지만 명료하다. 이해하려고 하는 만큼 내 안에 쌓였다. 

이렇게 나는 Back-end Product PM 으로 성장하고 있다.

내가 왜 기술잘알 PM 을 지향하는지 글로 작성해보았다. PM 은 무슨 역할을 하나요? 에 PM 의 숫자만큼 다른 답변이 있겠지만. 다른 PM 들과 이런 생각을 공유해보고 싶다. 앞으로도 더 좋은 PM, 더 좋은 동료가 되기 위해서.

 

(끝)

 

아래 내용은 내가 헀던 Tool & Technology 을 마치 개발자들이 개발셋을 나열하듯 작성해보았다. 

 

Tool & Technology

UML ( Structure Diagram, Behavior Diagram, Interaction Diagram ) 을 통해 마이크로 서비스 간 책임범위를 명확하게 하고, 서비스 간 프로토콜을 맞추어 고수준의 기능을 설계하고 해석할 수 있다.

ERD ( Entity Relationship Diagram ) 를 통해 엔티티의 속성과 기능, 생애주기를 설계하고 해석할 수 있다. 

JIRA, WIKI 를 통해 PM ( Projec Management ) 를 수행하며, 상황에 맞게 Waterfall/Agile 또는 이를 종합한 개발문화를 적용할 수 있다. 

ES ( Elastic Search ) - Kibana 를 통해 API log, Kafka Event Streaming log 등 다양한 로그를 확인할 수 있다. 

DMP ( Data Management Platform ) 에서 데이터 수집, 파이프라인 관리, 전처리, 가공, 활용 절차와 기술셋을 이해하고 프로젝트에 도입할 수 있다.

MySQL 을 통해 데이터를 추출 및 분석하여, 비즈니스에 유의미한 결과를 도출할 수 있다. 

Web/App 클라이언트와 Server 동기/비동기 통신환경과 데이터 흐름을 이해하고, 설계할 수 있다. 

 

 

PM 은 업무분야 도메인 지식을 중요하게 생각한다. (모든 프로덕트 상황을 처음부터 배우면 시간이 오래걸리니까) 

그래서 또 나열해본 도메인 지식

 

Domain Knowledge

광고 입찰: CPT, CPC, CPM, CPA 비즈니스 모델 입찰구조를 이해하고 고도화할 수 있다. 

리포트: B2B 유저가 관리하는 광고/프로모션 성과에 대해 다양한 관점에서 리포트를 제공할 수 있다.

심사: 광고, 비즈니스 파트너 등에 대한 심사 프로세스를 설계하고, 빠르면서 안정적인 심사처리를 위해 전심사/후심사/자동심사 프로세스를 고도화할 수 있다. 

빌링 및 회계: 특정 개인 또는 법인의 유상/무상 캐쉬를 관리하고, 매출 발생건에 대해 세금계산서 발행 및 매출신고 프로세스를 이해한다. 

위임권 설정: 다양한 조직구조에 따른 업무 범위와 접근 권한구조를 이해하고, 설계할 수 있다. 

결제: 주문과 결제/취소 트랜잭션 처리를 이해하고, 구간 대사, 결제내역 조회, 증빙 발행 등 일련의 프로세스를 이해하고, 설계할 수 있다.

프로모션: 할인, 적립, 쿠폰, 응모, 추천인코드 등 요구사항을 이해하고, ROI 를 높이기 위한 다양한 기능을 설계할 수 있다. 

타겟팅: 서비스 데이터를 수집 및 가공하여, 타겟팅 데이터로 활용하도록 데이터 파이프라인 및 기능을 설계할 수 있다.