PM 체험기
아이고.. 난 멀었다.
Product Manager(or Project Manager)
PM(팀장)은 어떤 직군에서 일하던 프로젝트 단위로 일하는 회사, 팀에서는 필연적으로 마주치게 될 사람이다. 나도 팀원으로만 일해봤고, 회사에서 이 PM들이 맨날 놀고 먹는 줄 알고 있던 사람으로서 이번 경험을 통해 이 직군의 역할과 중요성을 알 수 있었다.
역할
PM의 역할이 이렇게 많을 줄은 몰랐다. 조금 규모가 있는 스타트업급만 되도 이런 것들은 각각 담당자가 있고 PM은 사람관리 정도만 할 거라고 생각했는데 규모도 작고 업무의 성격도 없으니 PM이 풀스택 개발자 + PM의 역할까지 해야해서 더욱 힘들었다. 나는 PM으로서 다음과 같은 일을 했다.
기획서 작성
기획서는 정말 간단히 작성하라고 하면 ReadMe정도로 작성할 수 있지만 깊게 들어가면 백페이지도 넘게 작성할 수 있는 문서다. 조사할 자료가 수백가지고 인터뷰, 시장반응 체크 등 발로 뛰어야 할 부분도 많다. BM, Exit같은 전략 요소는 엄두도 못낼 것 같지만 흉내내는 수준으로 넣는다. 지금 구조만 잡아두고 적당히 내용을 채우고 있는데, 실제 프로젝트가 끝나고 1달정도 서비스를 해본 뒤 마무리지을 생각이다.
업무환경 구성
업무라고 하기엔 조금 급이 떨어지지만 업무환경을 구성했다. 우린 오피스가 없는 사이드 프로젝트 팀이니까 오직 온라인으로만. Notion으로 프로젝트 Workspace를 구성하고 git이나 slack, figma같은 협업 툴을 세팅한다. slack엔 notion, git, figma, jenkins같은 다른 협업툴의 알림을 세팅하고 Notion에는 협업 과정과 업무 분장, 프로세스를 포함한 모든 시스템을 만들었다.
만약 업무라면 간단한 규칙까지 정해도 되지 않을까. 개발팀 컨벤션과 깃 플로우 및 깃 관리 규칙, 커밋 템플릿이나 pr템플릿과같은 디테일 까지 챙겨야한다.
기술 스택 선정
프로젝트의 기한, 방향성, 성격, 크기나 목적, 추상화 수준 등을 고려하고 팀원들의 수준이나 새로운 기술에 대한 열의, 가지고있는 기술 스택 등을 함께 생각하고 마지막으로 기술 구현의 용이함이나 Docs가 얼마나 잘 만들어져 있는지 등을 포함해서 기술스택을 정한다.
처음 Apollo - GraphQL, Node, React라는 스택을 정할 때 팀원들 대부분 이 스택들을 들어만 봤지 딱히 주력으로 써본적도 없었고 특히 Apollo, GraphQL은 사용조차 안해봤다. 호기롭게 모르는 부분은 내가 알려주겠다고 했지만 알려주는 과정이 쉽지많은 않았다.
Development Wiki에 엄청나게 많은 글을 작성했다.하지만 설명글을 쓴다고 모두가 읽는다는 걸 보장하지 못했고, 읽는다 한들 이해한다는 것을 보장하지 못했다. 이건 내 패착이다.
세팅
기술스택이 정해지면 서버와 클라이언트 빌딩을 시작한다. 개발을 시작하기 전 세팅해야할 것이 굉장히 많다. 실제 개발에 들어가면 단순한 반복작업일 수 있는 과정이 세팅에서는 굉장히 다채롭다. 특히 서버의 경우 DB 설계, 스키마 작성 및 DB 정규화, 서버 구축과 같은 과정이 포함되고 클라이언트의 경우 전역변수나 테마를 포함한 초기 설정 뿐만 아니라 페이지 구조, 컴포넌트나 유틸함수 등 구조를 생각해서 자리를 만들어둬야 한다. 예를 들어 다크모드같은 기능이 들어가야 한다면 초기부터 Context로 테마를 뿌려주는 것을 생각해서 템플릿을 만들어줘야 한다.
Best Practice
이 과정은 팀원들이 항상 새로운 것을 공부한다는 가정이 없기 때문에 프로젝트의 진척을 위해서 항상 공부하고 가장 효율적이고 잘 동작하는 코드를 만든다. 만들어보니 팀원들은 대부분 별다른 의심 없이 사용하게 된다. 팀원들이 따로 공부를 하지 않아도 된다는 부담감은 줄어들지만 학습의 목적이라면 그 효과가 반감될 가능성이 있다. 또한 Best Practice가 Best Practice가 아닐 경우엔 난처해질 수 있다. 코드 스타일이던 공통컴포넌트던 갈아엎어야 할 지 모르기 때문이다.
코드리뷰
나 말고는 딱히 깊게 코드리뷰를 해주지 않는다. 아마 다들 회사에서 코드리뷰를 하는 입장이 아닐 수도 있고 팀원으로서 코드리뷰를 하는게 부담스러울 수도 있다. 분명 팀원들 중 나보다 잘하는 사람이 있는데도 말을 아끼는 것을 보면 그냥 팀장이 하는 일이라고 생각할 수도 있다. 코드는 개발자에게 민감한 부분일 수 있기 때문에 그런건가 싶기도 하다. 그래서 나라도 코드리뷰를 열심히 해야한다. 코드 컨벤션을 무너뜨리거나 너무 과하게 구현된 컴포넌트, 나중에 문제가 될만한 구조 등을 코드리뷰를 통해 맞추고 정리해야한다.
일정 관리
회사에서 업무로 만난 관계가 아니라면 이 일정이라는게 마음먹기 나름이라 한없이 느려지고 더뎌질 수 있다. 잘 안되면 인력을 투입하고, 조금 더 박차를 가해서 끝내는게 아니라 다음주에 하지 뭐 하고 넘겨버릴 수 있다는 것이다. 이게 정말 버거운 일이고 시간이 촉박하거나 개인사가 있다면 당연히 감안해야겠지만, 사람의 마음가짐으로부터 비롯된 사항이라면 다음 일마저 그르칠 가능성이 있기 때문에 그냥 넘겨선 안된다. 이 역할을 PM이 해야한다. 우선 매주 회의 안건을 선정하고 회의가 끝나면 회의록을 작성한다.
그리고 Sprint마다 평가를 하고 다음 주 계획을 잡는다. 평가가 끝나면 Task를 나누고, 각각 assign한다. Assign받은 Task는 각자 KanBan에 등록하고 관리한다.
이것 말고도 다양한 일을 한다. 워크스페이스를 보며 이것저것 적어봣는데, 이것만 하지는 않았던 것 같다. 나는 추가로 개발자로서 FrontEnd, BackEnd 실개발에도 참여하고 있기 때문에 업무가 두배다.
후기
생각 만큼 잘 뭉쳐지지 않는다.
이 프로젝트는 시작부터 3개월을 예상했었다. 서비스 런칭보다는 스터디의 목적이 강했고 팀원들과 깊은 관계를 유지하기보단 가볍게 공부하고 헤어지는 것을 생각했다. 그래서 그냥 선착순으로 특별한 결격사유가 없다면 다 받았다. 이렇게 대충 뽑은 것 치고 놀랍게도 실력도, 성격도 좋은 사람들이 모여서 좋았던 기억이 난다.
그래도 바뀌지 않는 점은, 이 모임의 목적은 프로젝트라는 것이다. 프로젝트는 예상과 크게 벗어나지 않는 3개월 안팍으로 마무리될 예정이었다. 조금 늘어졌지만 잘 마무리되면 나중에 한 두번 만나서 놀 수도 있고 다른 프로젝트를 이 멤버 그대로 다시 시작할 수도 있지만 어찌되건 관계는 여기서 명목상 종료된다. 모임이 이런 성격을 가지다 보니 팀원들 간의 유대는 그리 깊지 않다.
옛날에 대학친구랑 프로젝트 했던 때와 군에서 친했던 후배 장교, 병사와 했던 프로젝트와도 조금 다르다. 원래 친했던 사람들이었고 붙어있는 시간도 많아서 소통도 잦고 일의 진척도 빨랐던 것 같은데 지금의 팀원들, 그리고 나중에 만나게 될 팀원들도 아마 나와 저말 비슷한 성향이 아니라면 지금과 다를 것 없는 관계이지 않을까 싶다.
생각 만큼 시키는 것을 다 하지 않는다.
아주 사소하다고 생각하는 부분들이 있다. 특히 Notion Workspace에 현재 진행상황이나 새 일정같은 것이 생기면 업데이트 해달라고 한 부분같이 PM의 입장에서는 굉장히 중요하지만 일터가 아닌 스터디 팀원의 입장에서는 딱히 안해도 문제 없는, 약간 더 나아가면 과한 요구일 수 있다고 느꼈다.
또한 환경의 차이도 있다고 생각한다. 나는 내 개인 Notion에 공유페이지가 있어서 바로바로 볼 수 있고, 내 모든 데이터가 Notion에 있어서 항상 켜두고 산다. 하지만 다른 팀원들은 이 툴 자체를 거의 처음 써보고 개인페이지가 아닌 다른 워크스페이스라서 항상 옮겨다녀야 하기 때문에 접근성이 좋지 않다. 알림이 온다고 하지만 계속 이것만 들여다 볼 수는 없는 노릇이다.
개인 시간도 그렇다. 퇴근하고 누구는 운동을 하러 가고 누구는 친구를 만나러 간다. 우리 팀원 모두가 퇴근하고 항상 공부를 하거나 팀 프로젝트에 기여하는 것은 아니다.
이 프로젝트가 업무였다면
일의 영역에서 벗어나니까 뭔가를 시키기가 조금 애매하다. 개발자와 디자이너밖에 없어서 기획서 작성같은 외적으로 커다란 파트도 팀원들에게 부탁하기 어렵다. 물론 버거운 부분들은 부탁하면 다 들어줄 착하고 훌륭한 팀원들이지만 각자 맡은 파트 이외의 일, 그것도 아예 다른 일을 하기엔 이미 우린 대학생의 신분을 넘겨 버린 후라서 그런지 말을 꺼내기가 어렵다.
내 생활패턴을 남들에게 대입해서 생각하자니 억지 같기도 하고, 팀장으로서 팀원들보다 훨씬 많은 일을 해야한다는 점은 이해하고 있지만 팀원들이 겉으로 별다른 기척을 드러내지 않고 있는걸 보면 나만 열심히 하고 있나 싶기도 하다.
하지만 또 만나서 들어보면 드러내지만 않았지 많은걸 하고 있기도 했다. 우리 회사에서 나의 입지에 대입해서 볼 수 있을 것 같다. 들어오는 일들은 다 하는데 일찍와서는 개인공부하고 퇴근은 칼같이 하는 나를 다른 사람들은 내가 우리 팀원들을 보는 느낌과 비슷하게 생각할 것 같다.
속을 모르겠다.
이게 사업이 아니기도 하고, 나와 아주 친한 사람들이 아닌 점도 있고, 목적이 뚜렷하다는 면도 있어서 친구들처럼 많은 대화가 오가진 않는다. 물론 나도 이걸 원하는건 아닌데, 이런 관계가 지속되다보니 도통 팀원들 속을 모르겠다. 아마 나중에 PM으로 일하게되면 분명 이와같은 답답함을 다시금 느낄 것 같은데 나부터가 깊은 이야기를 하지 않으니 아마 그런 듯 싶다.
또한 소통이 굉장히 소극적이고 인터랙션의 빈도 자체가 낮다. 스스로의 의견을 초반에는 팀장 외에 잘 내려고 하지 않는다. 일종의 방어기제가 있지 않을까 싶다.
Outro
아직 프로젝트가 끝나진 않았는데, 거의 4달이 다되가는 시점에서 나의 느낀점은 이렇다. 나도 이 팀에서 개발만 했으면 아마 모르고 넘어갔겠지만 PM이라는 직군이 얼마나 신경쓸 부분이 많은지, (아마 개발도 해서 그런지 두배로) PM이 얼마나 힘든지 알 수 있었다. 또한 많은 사람들이 말하길 개발을 잘 모르는 PM이 많다고 했는데 절대 그런 사람이 되어선 안된다고 다짐했다.
