[Article]#서비스기획 우당탕탕 2022년, PM 회고하기

2023-03-21


2022년 1월, 윙잇에 PM으로 합류하게 되며 많은 변화를 겪었다.
개인적으로도 많은 변화가 있었지만, 조직 내 개편 또한 활발하게 진행되어 매주가 혼돈의 연속이었다.
작년 한 해를 돌아보며 배운 것들이 휘발되지 않도록, 간단하게 끄적여보려 한다. (TMI 대방출)


1. 나는 왜, 어떻게 PM이 되었나?

Product Manager, PM으로 직무를 확정하고 일하며 가장 많이 생각했던 질문이다.

'왜 나는 이 자리에서 PM으로 업무를 하고 있는 거지?'

경영학을 전공하고 심지어 대학원은 광고학으로 수료했지만 (아직 졸업은.. 논문이.. 헿..) IT 업계에 PM으로 일하고 있는 것에 대해 스스로도 많은 의문이 있었다.


2018년 1월, 취업 준비를 하며 방황하던 와중에 함께 스타트업을 해보자는 지인의 제안이 들어왔다. 패션 인플루언서와 협업하는 서비스를 만드는 사업이었는데, 굉장히 많은 일이 있었지만 결론적으로 웹과 앱을 기획하고 결과물을 만들어냈다. 물론 스타팅 멤버로 일하며 기획만 할 수는 없었고 마케팅, 인스타 광고, CS, 심지어 사진 보정까지 많은 일을 했다. 우여곡절 끝에 만 2년을 넘게 일한 회사에서 나오고 이직을 준비할 때, 어떤 일을 골라서 전문성을 키워야 할지 고민을 했다. 단순한 성격과 재미를 추구하는 ENFP로서, 고민은 길지 않았다. '내가 제일 재밌어했고, 가장 많은 시간을 할애한 PM이 되자!’


지금 생각해 보면, 혼자 깨져가며 주먹구구식으로 일한 주니어 PM이 겁도 대책도 없이 이직에 뛰어들었다고 생각할 수밖에 없다. 일례로, 이직 초기에 어느 한 면접에서 "린 스타트업과 애자일에 대해서 아나요?"라는 물음에 어버버 했을 때부터 '이건 뭔가 잘못됐다'라고 생각했다. 이와 관련된 일화는 추후 기회가 있으면 풀기로 하고, 아무튼 여차저차 윙잇 PM으로 일하기 시작한 것이 바로 올해, 2022년 1월 24일이다.


'나는 왜, 어떻게 PM이 되었나?'라는 질문에는 확실히 답변을 할 수는 없다는 것이 첫 번째 결론이다. 그냥 어쩌다 보니 우연히 서비스 기획이라는 업무를 알게 되었고, 또 어쩌다 보니 PM으로 이직을 성공했다. 아무도 나에게 PM이 어떤 직무라는 것을 가르쳐준 사람이 없고 아무도 나에게 너는 PM을 하라고 말해준 사람이 없었다. 그럼에도 한 가지 분명한 것은, 매일 새로운 도전을 하게 만드는 PM이라는 직무는 정말 어렵지만, 동시에 정말 재밌고 끊임없이 성장을 추구하는 원동력이 된다는 것이다.


2. 목적 조직의 구성, 셀(CELL) 단위 개편

처음 입사했을 당시에는 기능 조직으로만 구성이 되어있었다. PM은 서비스 기획팀, 그리고 개발자는 개발 1팀과 개발 2팀으로 묶여 서로 다른 조직의 팀원들이 함께 협업을 하는 형태였다. 장점은, 각 개발 팀에 PM이 두 명 혹은 세 명씩 짝지어 협업을 했기 때문에 상대적으로 한 명의 PM에게 주어지는 기획 시간이 부족하지는 않았다. 또 기획적으로 함께 논의할 수 있는 시간이 있어 혼자만 책임져야 한다는 부담감이 덜했다. 하지만 하나의 목적을 가지고 일을 하지는 않았기 때문에 기획을 하고 개발에 들어가기 전, 매번 우선순위를 새롭게 정해야 한다는 불편함이 있었다.


이에, 목적으로 이뤄진 셀(CELL) 단위 개편에 대한 이야기가 시작되었다. 한 번도 목적 조직으로 구성해본 적이 없었기 때문에, 많은 우려가 있었다. 물론 셀 단위 개편에 대해 반대하지는 않았지만, 개발자도 PM도 부족한 이 시기에 하필? 지금 셀 단위 개편이 필요한가? 에 대해 열띤 토론이 진행되었다. 그래도 결국 셀 단위로 개편이 되고 퍼널 단위로 쪼개져 두둥. 목적 조직이 생기게 되었다.


AARRR에 따른 목적 조직의 구성

흔히, AARRR로 많이 알려진 퍼널 구조에 따라 커머스에서 중요한 퍼널들을 뜯어보는 조직이 구성되었다. 그중에 나는 Activation, 즉 고객들이 윙잇의 주요한 기능들을 '잘' 사용할 수 있도록 고민하는 셀의 담당 PM이 되었다. 입사하고 약 4개월 만에 하나의 셀을 온전히 맡게 되어 정말 부담스러웠지만, 더 큰 문제는 과연 Activation의 관점에서 어떤 서비스를 제공해줘야 하는지에 대한 고민을 하지 못했는데 덜컥 셀을 맡아버렸다는 것이다.


처음 셀을 맡았을 때 집중했던 주요 페이지는 장바구니 페이지와 주문하기 페이지였다. 당연히 다른 페이지들도 많이 있었지만, 당장 맡았던 주요 과제는 최종 주문 전환율을 높이는 것이었다. 그러기 위해서는 현재 윙잇의 페이지에서 주문을 담당하고 있던 장바구니 페이지와 주문하기 페이지를 개편해야 했다. 그럼 이제, 어디서 부터 어디까지 어떤 문제가 있는지 분석을 할 시간이 필요했지만 휘몰아치는 업무는 깊은 고민과 통찰을 얻을 분석을 할 수 있는 시간을 주지 않았다.


셀로 개편된 직후 전사적으로 급한 과제들이 쏟아져왔다. 처음 셀 업무를 맡고 목적을 제대로 설정하기도 전에 사업적으로 급하다는 일감이 밀려 들어오자 어떤 걸 우선순위로 둬야 하는지 우왕좌왕했다. 우선, '급한 것부터 해결하자!'라는 마음으로 일감들을 쳐내기 시작했다. 이때, 첫 번째 실수가 나타났다.


첫 번째 Lesson, 목적은 반드시 명확하게 설정할 것

셀 단위로 개편된 후 제일 먼저 해결했어야 하는 문제는, 주문하기 페이지에서 구매불가한 상품들을 고객들이 자꾸 발견한다는 것이었다. 그 이유는 주문하기 페이지에서만 배송지를 선택하고 변경할 수 있었기 때문이었다. 주문하기 페이지에서 배송지에 따른 구매불가여부를 확인하게 되니 이탈률이 높아지고 CS 인입도 점차 늘어나고 있었다. 이에, 주문하기 페이지가 아닌 플로우의 앞 단에서 주소를 등록하고 확인할 수 있도록 하는 기능을 기획하고 개발했다. 즉, 메인페이지와 장바구니 페이지에서 주소를 확인하고 추가할 수 있도록 하는 것이었다.

해당 기능을 처음 기획을 할 때는 꽤나 좋은 방법이라고 생각을 했다. 그리고 실제로도 해당 기능을 배포하고 난 이후 메인페이지와 장바구니 페이지에서 주소를 확인하는 비율은 75% 이상, 새로운 배송지 추가 비율은 90% 이상이었다. 하지만, 이 일감이 과연 주문하기 페이지에서 주소 확인하는 비율을 줄이고 주문 불가한 상품을 미리 확인하는 것에만 목적을 두는 것이 맞았을까? 지금 생각해 보면, 주소를 미리 확인하게 하여 주문을 하는 비율이 늘었는지, 또는 실제로 해당 부분의 사용성이 어떻게 좋아졌는지 미리 계획을 더 촘촘하게 세웠더라면 성과 측정을 좀 더 잘할 수 있었을 것이다.


추가적으로, 이 일감을 진행할 때 유관부서 및 이해관계자들이 원하는 것과, 내가 PM으로서 생각하는 부분들이 달라서 조율하는 데 시간이 들었다. 심지어 개발이 진행되는 와중에도 요구사항은 변경이 되어 그 부분을 전달하는 입장도 많이 난감했었다. 개발자들은 계속 코드를 수정해야만 했고, 다른 일감이 그 사이에 들어와 모든 일감의 스케줄링이 꼬였었다. 만약 이 일감의 목적이 좀 더 확실하고 구체적이었다면, 기능에 대한 구현 방식에 대해 논의를 하는 불필요한 커뮤니케이션이 많이 줄어들지 않았을까?


결론적으로, 이 일감 이후로 배운 점은 반드시 기획 전 목적을 분명하게 하여 성과측정 및 커뮤니케이션 코스트를 줄이는 것과, 개발 중에 추가 요구사항이 최대한 개입되지 않도록 하는 것이다. 그럼에도 이 일감이 배포되고 난 후 셀 분위기가 더 끈끈해지고 회고를 더 자주 하게 되는 계기가 되어 좋은 점도 분명히 있었던 소중한 경험이었다.


3. 우당탕탕 스프린트 진행기

흔히들 애자일, 애자일 하는데, 애자일 방법론이란 과연 뭘까?

Agile : 날렵한, 민첩한, 재빠른, 기민한

애자일 방법론은 요구사항을 민첩하고 빠르게 반영하는 것이라고 한다. 개인적으로는 프로젝트를 할 때 군더더기를 걷어내고 MVP를 구축하며 빠르게 도전해 보는 방법 정도로 이해하고 있다. 애자일 방법론에 대해서는 더 자세하고 정확하게 설명해 주는 사람들이 많으니 이쯤에서 정리하고...ㅎㅎ


애자일 방법론에서 나오는 개념 중에는 스토리와 스프린트가 있다.

스토리(story)란, 배포가 가능한 가장 작은 단위의 요구사항이며 독립적이다. 예를 들어, 장바구니 담기 시스템을 구축할 때는 1. 상품을 보여주고 담을 수 있도록 만들고, 그리고 2. 담은 상품을 확인할 수 있도록 하는 기능 등이 필요하다. 이때, 기획적인 측면에서는 플로우가 이어지지만 상품을 담는 기능과 상품을 확인하는 기능은 독립적이며 따로 배포가 가능하다. 그래서 스토리가 2개로 나눠질 수 있다. 물론 매번 이렇게 쪼갤 수는 없어 나는 개발자들과 상의해서 적정한 수준의 스토리를 쪼개고는 한다. 처음에는 스토리 쪼개는 것도 감이 오지 않아 너무 비대한 스토리를 만들거나 너무 작은 스토리를 만들고는 했다. (그리고 그 감을 찾는 것은 정말 많이 해보지 않고서는 어떻게 조언을 해줄 방법이 없다..)


스프린트(sprint)란, 1~2주 정도의 반복주기를 잡고 계획부터 실행, 회고까지의 프로세스를 반복하는 것을 말한다. 이때, 해당 스프린트에서 실행할 스토리들을 계획하고 각 스토리들의 공수를 파악한다. 그리고 회고 때는 스프린트에서 실행한 스토리들을 구현하는 과정과 결과 등에 대해 논의한다. 윙잇에 처음 입사했을 당시, 스프린트가 갓 만들어졌었다. 개발 1팀과 개발 2팀 각각의 스프린트가 따끈따끈하게 만들어졌고, 각각 2주씩의 주기가 주어졌다.


처음 애자일 방법론에 대해 알지도 못하고 스프린트가 뭔지도 모르는 상태에서 회의에 참여했을 때는 뭐가 뭔지 도통 알기 어려웠다. 한 번에 많은 기획을 하고 한꺼번에 전달하는 워터폴 기획에 익숙한 나로서는 요구사항을 잘게 쪼개서 관리하는 방법이 어색했기 때문이다. 하지만 요구사항들을 잘게 나누어 개발을 하는 방식은 관리가 용이하고 불필요한 기능을 구현하지 않아도 된다는 장점이 있었다. 개인적으로 판단하기에는 비대한 기획을 스토리로 변환할 때, '진짜 이 기능이 필요한가?'에 대해 한번 더 고민할 시간이 있었기 때문이라고 생각한다.


하지만 분명히 단점도 존재했다. 기간을 정해놓고 기획과 개발을 진행하니 점점 스토리들을 기간 내에 쳐내는 것에만 신경을 쓰고 있었다. 회고를 하는 시간은 줄어들었고, 하나의 스프린트 다음에는 이전 스프린트의 문제점들을 개선하며 진해하는 것이 아닌, 스토리를 와장창 넣고 쳐내기식의 프로세스를 반복하고 있었다. 또 몇 개의 스프린트가 반복이 되면 하나의 스프린트 내 구현이 가능한 스토리들의 공수 파악이 가능할 줄 알았지만, 계속해서 어떤 스프린트는 너무 여유롭고 그다음 스프린트는 너무 넘치는 등의 현상이 반복되고 있었다. 또 개발자마다 강점이 다 다르니 똑같은 스토리들의 공수 측정을 '객관적'으로 하기에 힘든 점이 있었다.


4. 스프린트.. 꼭 필요할까?

셀 단위 구조로 개편하면서 가장 먼저 대두되었던 사안은, 스프린트를 계속 유지할 것인가? 였다. 스프린트의 장점이 분명히 있긴 하지만 시간의 압박감과 퀄리티에 대한 생각이 계속 남아있었다. 그래서 처음 셀 내 팀원들과 합의를 한 점은 바로 "셀 구조로 개편이 되었으니, 우선 스프린트를 깨 보자!"였다.


이후 스토리 포인트를 산정하던 방식에서 스토리를 분배하고 각 개발자분들이 본인의 공수에 맞게 해당 스토리의 개발 일정을 산정하는 방식으로 바꿨다. 객관적인 스토리의 공수 측정도 중요하지만, 그보다는 스토리 개별의 일정 관리가 더 중요하다는 것을 배웠기 때문이다. 또한 개발 일정을 산정하면 나는 해당 일정을 관리하고 그 일정에 맞춰 프로젝트들을 기획하고 또 사이사이 스토리들이 비지 않도록 끼워 넣는 방식으로 진행했다.


물론, 이 방식 또한 문제가 있었다. 스프린트 방식으로 진행할 때는 정해진 스토리의 양이 있기 때문에 배포가 진행되고 다음 스프린트 전까지 추가되는 스토리는 극히 적었다. 하지만 스프린트가 깨지고 스토리가 그때그때 여유가 있는 사람에게 배정되다 보니, 하나의 스토리의 배포가 되기도 전에 다른 스토리가 배정이 될 때가 많아졌다. 이 때문에 스위칭 코스트가 너무 많이 든다는 문제점에 직면했다. 그럼에도 스프린트 방식 때보다는 훨씬 자유도도 높고 일정관리가 편했기 때문에 스프린트로 돌아갈 수는 없었다.


결론적으로, 스프린트는 깨졌고 스위칭 코스트를 줄이기 위해 하나의 프로젝트 단위로 셀을 운영하기로 했다. 즉, 스프린트는 아니지만 스프린트와 비슷하지만 결이 다른..! 우리 셀 만의 약속을 만들었다. 하나의 프로젝트가 끝나기 전까지는 되도록 다른 일감을 전달하지 않고 매일 스크럼 시간에 프로젝트 일정을 체크하는 것이었다. 간단해 보이지만 이런 약속을 통해 스프린트보다 자유롭지만 규칙은 살아있는 최선의 방법으로 셀을 운영하게 되었다.


개인적으로 PM을 하면서 가장 어려운 점은 일정관리를 하는 것이다. 나만의 일정을 관리한다면 상관없지만, 셀 내 모든 인원들의 일정을 고려하며 관리를 하는 것이 처음에는 많이 어려운 점 중 하나였다. 더욱이 유관부서와 함께 협업을 하는 상황이라면 문제는 더 커진다. 기획과 개발을 하면서 많은 변수가 생기는데, 이를 유관부서가 이해할 수 있도록 일정을 잘 전달하는 것은 생각보다 어려운 일임을 PM을 하면서 깨닫기도 했다. 하지만 혼자서 일정을 관리하려고 고군분투하기보다 셀원들 모두가 함께 관리를 할 수 있도록 합의하고 약속을 하는 방식을 도입했고, 나름 성공적으로 진행하고 있다.


5. TMI 회고를 마치며...

셀로 개편된 이후 가장 좋았던 것은 나 혼자만 셀 운영이나 셀의 OKR에 대해서 고민하는 것이 아니라 셀원들과 다 같이 고민할 수 있었다는 것이다. 물론 개편되고 난 후 처음부터 아이디에이션 회의나 회고 회의를 진행한 것은 아니다. 작년 10월 말쯤부터 본격적으로 진행했는데, 이 또한 셀원들의 소중한 의견을 받아 시작하게 되었다. 짧게 회고나 아이디어를 논의한 적은 있지만 본격적으로 정기 회의를 진행하니 생각보다 더 좋았다. 혼자서 생각하거나 레퍼런스를 찾을 때보다 더 좋은 의견들이 많이 나왔고, 실제로 적용한 부분도 많았다. 화룡점정으로 12월 말, 셀 개편이 된 후 우리가 어떤 걸 했는지 나열하며 회고를 진행했다. 이때 내가 부족한 점도 많이 깨달았지만, 셀원들이 함께 했기 때문에 많은 일을 할 수 있다는 것을 절실히 느꼈다.


주니어 PM으로 살아가면서 아직도 잘하고 있는지, 이렇게 하고 있는 게 맞는지 고민할 때가 많다. 어떤 때는 잘하고 있다고 생각이 되다가도, 어느 날에는 맞는 방향성인가? 하며 밤잠을 이루지 못할 때가 많았다. 우당탕탕 회고를 쓴 이유도 사실 내가 뭘 잘했다고 적기보다는 지난 1년을 돌아보며 느꼈던 점들을 잊지 않기 위해 스스로 끄적이는 글에 가깝다. 결론적으로 내가 잊지 말아야 할 단 한 가지, 세상 어디에도 완벽한 정답은 없기 때문에 동료들과 많이 소통하며 합을 맞추는 것이 중요하다는 것이다. 갑자기 왜 이런 말이 나오지?라고 생각할 수 있다. 하지만 앞서 스프린트를 깨자! 라든가 회고랑 아이디에이션을 다 같이 하자!라는 것들은 누가 가르쳐주지 않는다. 책을 보면 스프린트는 아주 정답이고 모든 상황에 반드시 필요한 것처럼 보인다. 하지만 어떤 때는 일을 더 잘하기 위해 정답처럼 보이는 것들을 과감하게 깨버리는 결단이 필요하다. 그리고 그 결단은 나 혼자가 아닌, 함께 일하는 사람들과 함께 합의해야 한다는 것을 반드시 잊지 말자.