제목에서 말씀드린 것처럼 저는 학부 때 디자인을 전공했습니다. (TMI) 디자인을 배울 때도 보기 좋게만 만드는 것이 아니라 기획 단계에서 어떠한 의도와 목표를 갖고 사용자에게 질 높은 경험을 주는 것에 더 집중했고, 흥미를 느꼈었어요. (꼭 서비스뿐만 아니라 제품, 공간 등에서도요!) 의도한 방향대로 구현된 후에는 예측한 대로 사용자의 니즈가 딱 채워졌을 때 큰 성취감을 느끼기도 했습니다.

이렇게 자연스럽게 시각적으로 구현하기 전 기획이라는 영역에 관심이 생겼고, 개인보다는 팀으로 아이디어를 만들어 가는 것을 좋아하다 보니 딱 맞는 직무가 Product Manager였어요.

여러 직무의 사람들과 함께 하나를 만들어 나가는 특성도 저와 잘 맞을 것 같았고, 직접 기획한 내용을 매일 쓰는 앱에서 아웃풋까지 볼 수 있으니 ‘나를 위한 직무인가?’라고도 생각했었어요.

이때까지만 해도 PM이라면 화면 혹은 UX 기획만 할 것으로 생각했지만 제가 맡게 된 업무는 말만 들어본 백엔드 PM이었습니다.

여기서 잠깐! 정산플랫폼은 어떤 일을 하나요?

우아한형제들이 운영하는 배민, 배민1, 배민스토어 등에서 발생한 매출을 사장님들께 약속한 일자에 정확하게 정산해 드리고, 가게 운영에 도움이 되도록 상세한 내역과 정보를 제공하는 것이 저희 팀의 주요 업무입니다. (업계에서 가장 빠르다는 우아한형제들의 정산…)

이렇듯 정산이라는 도메인은 주로 데이터, 숫자가 왔다 갔다 하다 보니 눈에 보이지 않는 업무가 대부분인 편이에요.

출처: Frontend vs Backend, https://www.reddit.com/r/ProgrammerHumor/comments/aiqhsr/frontend_vs_backend

이 사진처럼 배달의민족 앱이나 사장님용 웹 서비스들은 깔끔하고 평온해 보이지만 뒤에는 이렇게나 복잡한 구조가 있다는 것을 입사하고서 알게 되었어요.^^

저는 그동안 고객용 서비스 기획, 와이어 프레임, UI/UX 디자인과 같이 가시적인 업무들에 익숙할 수밖에 없었고, 백엔드의 경우 회사가 아니라면 경험해 보기 어렵기 때문에 처음 입사했을 때 관련 정보를 많이 찾아다닐 수밖에 없었어요.

출처: 짱구는못말려 5기 1화(회사원이 된 짱구)

사진 속 짱구의 느낌으로 이미 능숙하게 업무를 하고 계신 분들 사이에서 저만 헤매는 듯한 기분이 들었고, 절망적이게도 관련 정보를 찾으면 찾을수록 백엔드 개발자 이야기만 나오더라고요.

더욱이 ‘나는 여기서 어떤 역할을 해야 하지?’, ‘백엔드에서 일을 잘한다는 것이 어떤 것일까?’라는 고민뿐 아니라 실무 시작 후에도 ‘다른 플랫폼 PM 들은 어떤 고민을 할까?’ 등의 의문이 끝없이 생겨났어요.

이것이 제가 글을 작성하게 된 이유이고 목표기도 해요. 우아한형제들 안에서도 굉장히 다양한 업무 방식들이 있지만, 그중 제 경험을 공유하면서 신입 PM분들께 도움이 되어보고자 합니다

그래서 저는 어떤 일을 하냐면요!

우아한형제들에 입사한 후, 초반에 진행했던 과제 중 하나의 진행 과정을 간단하게 소개해 드릴게요.

첫 과제. 정산내역을 개선하여 사장님들께 도움이 되고 싶어요.

입사 6개월 정도 되었을 때, 유관부서와 처음 함께하는 과제로 셀프서비스의 정산내역 개편을 진행하였어요.

여기서 셀프서비스란, 배달의민족에 입점하기 위한 계약, 승인 시스템과 입점 후에 사장님이 더 쉽고, 효율적으로 가게 관리(메뉴, 정산 등)를 하실 수 있는 서비스에요.

출처: 셀러셀프서비스팀이 소개하는 셀프서비스

주요 요구사항은 정산내역 내 여러 항목들(주문금액, 배달비, 결제정산수수료, 부가세 등) 중 유사도가 높은 항목끼리 그룹 지어 제공하는 것이었습니다. 기존처럼 매출 금액과 차감 금액으로 나누는 것이 아닌, 카테고리 별(주문, 배달, 광고 등)로 확인하실 수 있도록 하여 정산에 대한 이해도를 높이고자 하였어요.

제가 처음 정산을 접했을 때는 정산이라는 단어에서 오는 장벽이 있었어요. 굉장히 복잡할 것만 같고, 숫자만 많을 것 같았거든요. (저만 그랬나요?)

과제를 진행할 때도 셀프서비스 담당 PM 분들과 함께 여러 가지 조합을 해보며 어떤 형태일 때 사장님들이 가장 쉽게 이해하시고, 필요한 형태일까를 가장 고민했습니다.

여러 유관부서와 논의하여 주문중개/배달/그 외/추가광고/부가세를 큰 카테고리로 삼아 내역을 개편하는 것으로 결정하였는데요.

정산플랫폼팀에서는 외부에 제공하고 있는 API를 위 카테고리와 동일하게 제공될 수 있도록 하위 컬럼 재분류 및 그룹화 작업이 필요했고, 부가세를 따로 분리하여 별도 컬럼으로 제공될 수 있도록 계산 로직을 추가해야 했어요.

첫 QA 과정도 쉽지 않았는데요, 담당 QA쪽에서도 해당 내용을 완벽히 이해하신 후 테스트 케이스를 작성하실 수 있도록 꼼꼼한 기획서 작성과 리뷰가 필요했습니다. (사소한 정책이나 변경 전후 로직까지 공유해야 하니 기획리뷰보다 QA 리뷰가 더 긴장되더라구요…)

아무래도 숫자 데이터()를 검증해야 하다 보니 단 1원의 오차도 없도록 정말 꼼꼼히 검증하였던 것 같아요. 정산에서 API를 통해 응답드린 금액이 프론트에서도 정상 노출되는지 셀프서비스에서 검증해 주시는 과정을 거친 후, 무사히 운영 오픈을 할 수 있었습니다.

서비스 화면에서 정산내역의 구성을 바꾼다고 해서 이렇게 많은 고민과 리소스가 들어가는 줄 상상도 못했는데요. 그동안 제가 사용하던 화면 뒤에는 정말 많은 데이터와 테이블이 엮여있다는 것을 처음 느끼고, 백엔드가 탄탄해야 완성도 높은 프론트가 구현 가능하구나!를 깨달은 첫 과제였어요.

혹시 다들 어떤 고민을 갖고 계시나요?

위에서 소개해 드린 과제 외에도 크고 작은 과제들을 맡다 보니 잘하고 싶은 욕심도 생기고, 개인 역량에 대해서 고민이 정말 많았던 것 같아요. 정답이 있는 고민이 아니다 보니 입사 초반에는 2주에 한 번 팀장님과 피드백 시간을 갖기도 했고, 입사 동기들과 고민을 나누는 시간을 갖기도 했어요!

다른 신입 PM 분들도 비슷한 고민을 하고 있지 않을까 해서 제가 했던 고민들을 한번 공유해 보려고 합니다.

첫 번째 고민. PM은 개발 지식을 얼마나 알고 있어야 할까?

가장 고민이 되는 부분이었고, 입사 직후에도 두려움이 많았던 부분이었어요.

출처: 김중철, 김수지, “오늘도 개발자가 안 된다고 말했다”, 디지털북스(2021), http://www.yes24.com/Product/Goods/97919905

제가 생각했던 개발자와의 협업은 이런 느낌이었거든요.

기획도 (실무는 아니지만) 해봤고, 협업도 해봤고, 디자인도 해봤는데 개발만큼은 제가 안 해본 영역이었기 때문에 두려워했던 것 같습니다. 개발자로 입사한 것도 아닌데 말이에요. (실제로 저는 입사할 때 배치에 대한 개념도 없었어요. 팀 온보딩 교육 시간에 ‘배치가 뭐에요?’라고 질문했던 기억이 새록새록 나네요. 팀원분들이 얼마나 막막하셨을지… 정산팀 최고! )

이 부분에 대해서는 주변에도 많이 여쭤보았고, 지금 시점에서 다시 돌이켜보았을 때 제가 내린 결론은 ‘일하면서 배우면 된다.’ 는 것이었습니다.

입사 전에는 어떤 개념은 알아야 하고, 어떤 개념은 몰라도 되는지를 판단할 수도 없다고 생각해요. 회사마다, 팀마다 사용되는 개념이나 테이블 구조가 전부 다르기도 하고요!

물론 하나부터 열까지 누군가 가르쳐주기를 기다리는 것이 아니라, 업무를 하나씩 익혀나가는 노력과 그 과정 안에서 자연스럽게 개발지식을 습득하는 것이 맞다고 생각해요. 우리는 개발자가 아니니까요.

잘 모르는 영역에 대해서 질문해도 잡아먹는 개발자는 없으니, 의문이 생긴 부분은 확실하게 풀고 넘어가고, 다음 과제에 적용해 보는 것이 제가 생각하기에 가장 이상적인 것 같아요. (2022년도 우아한 PM의 밤 세션 중 김영한님의 "개발자가 생각하는 좋은 PM 나쁜 PM" 세션에서 추천해 주신 개발자에게 잘 통하는 ‘고민이 있어요.’ 스킬 추천합니다)

프로덕트라는 것이 PM 혼자 끌고 가는 것이 아니라 개발자 포함 여러 이해관계자와 함께 만드는 것이기 때문에 일정 개발지식이 있으면 커뮤니케이션에 있어서 유리해지는 것은 맞아요.

그렇기 때문에 매 프로젝트들을 끝내고 바로 다음 프로젝트로 넘어가기보다는 제 자산으로 만들려고 노력하는 것이 중요하다고 생각됩니다.

두 번째 고민. 정책 히스토리 찾아 삼만리

제 업무는 완전히 새로운 앱을 기획하는 것이 아니었기 때문에 기존 정책들이 어떻게 수립되어 있는가가 굉장히 큰 벽으로 느껴졌어요.

사소한 개선과제를 진행하더라도 영향범위 파악에 있어서 ‘내가 이 부분을 바꿔도 되는 것일까? 이때는 어떤 의사결정이 이뤄진 것일까?’에 대한 불확실함이 항상 있었어요.

함께 일하고 있는 팀원들도 사람이다 보니 모든 히스토리를 100% 기억할 수는 없기 때문에 서로 기록의 중요성을 강조하고 있습니다. 이슈가 있었다면 어떤 상황이었고, 원인은 무엇이었으며, 어떻게 대응하였는지 꼭 기록하고, 만약 미팅으로 결정된 사항이 있다면 슬랙 스레드에 남겨두는 것을 기본 규칙으로 지정하고 있어요! (가끔 몇 년 전 슬랙 기록에서 해답을 찾을 때도 있었습니다.)

이렇게 팀 차원에서 노력하더라도 신입으로 입사하게 되면 히스토리 찾는 데에 시간을 정-말 많이 사용하는 것 같습니다. 위키와 슬랙을 전전하며 몇 시간 동안 검색만 한 적도 있었는데요. 몇 번 겪어본 후에는 저만의 가이드를 만들면서 조금은 해소되었다고 생각해요.

질문을 통해 새롭게 알게 된, 하지만 위키나 슬랙에 공개적으로 적어두기에는 애매한, 그러나 언젠가 유용하게 사용되는 정책들. 다들 있으시죠? 

바로 그것들을 나만 보는 곳에 정리하는 것이고, 그렇기 때문에 거창하게 정리할 필요는 없다고 생각해요. 저는 아래 이미지와 같이 큰 도메인별로만 나누어 가볍게 저장하듯이 쌓고 있어요. (화려하게 정리하려다가는 포기하게 될 수 있음 주의)

필요할 때마다 이 가이드를 꺼내 찾아보면 분명 도움이 되더라고요. 두 번 세 번 문답하지 않아도 되니 업무 효율에도 많은 도움이 된다고 생각합니다.

매우 간단한 방법이지만 부끄럽게도 입사 초반에는 정신없다는 이유로 그냥 흘려듣고, 두 번씩 다시 질문한 적이 있었던 것 같아서 다시 돌아간다면 꼭! 저만의 가이드를 만들어 둘 것 같아요.

세 번째 고민. 좋은 기획서는 대체 어떻게 작성하는 것인가!

이 고민은 어제도 했는데요. PM이라면 평생 해야 하는 고민 중 하나인 것 같기도 합니다. 직접 개발하는 개발자, 기획 의도에 맞게 디자인하는 디자이너, 기획한 내용대로 구현되었는지 검증해 주실 QA 분들까지 단번에 이해시킬 수 있는 문서를 작성하는 것 자체가 절대 쉬운 일은 아니라고 생각해요.

문서를 작성할 때, 읽는 사람 입장에서 작성해 보라고 많이들 조언해 주시는데요. 개발자도 아니고, 디자이너도 아니고, 품질 담당자도 아닌 제가! 어떻게 읽는 사람 입장에 100% 이입할 수 있을지에 대한 고민과 의문이 많았어요.

지난 1년간 열심히 고민해 본 결과, 기획서는 함께 작업할 분들과 ‘싱크’를 맞춰가는 문서라고 정의하면 어떤 기획서가 좋은 기획서인지 정리되는 것 같아요.

‘제가 이렇게 기획했으니까 이렇게 만들어 주세요.’가 아니기 때문에 왜 이 과제를 진행해야 하고, 전체 영향범위는 이렇게 예상하는데 그 안에 이 부분이 새롭게 작업 되는 부분이라는 점을 명확히 보여줘야 한다고 생각해요.

그래야 개발자 입장에서 놓치는 부분 없이 검토나 작업이 가능하니까요! 특히 백엔드는 시각적으로 전달하기 어렵기 때문에 더욱 작업 범위가 명확히 정의되어야 하더라고요.

투입된 인원 모두의 과제 이해도가 일치하고, 세부 작업들의 필요성에 대한 싱크가 맞았을 때 기획 내용을 엎지 않고(), 놓치는 부분 없이 순조롭게 진행된다는 느낌이 들었어요.

문서는 그 싱크를 기록하고 소통하는 수단이 되는 것이고, 우리가 필요한 정보를 잘 골라 정리하여 ‘이것만 보면 작업할 수 있다!’ 했을 때, 좋은 기획서라고 생각되어요. 결국 기획서는 모두가 함께 작성하는 것이죠.

제가 생각했을 때는 이러한 결론을 내렸지만, 다른 분들은 좋은 기획서를 작성하기 위해 어떤 노력을 하고 계시는지 궁금하기도 하네요! 

마무리하며

출처: 데브경수, https://instagram.com/waterglasstoon

꿈에 그리던 PM이 되어보니 멋지고 완벽하게 기획하여 배포하는 상상과 다르게 의도한 대로 구현되지 않는 경우도 많고, 중단되는 경우도 꽤 많이 있었습니다.

특히 PM에게 요구되는 역량이 굉장히 다양하고 넓다고 느꼈어요. 단순히 기획자가 아니라 프로덕트라는 큰 숲을 보면서 나무를 심고 잘 크고 있는지 컨트롤하는 역할이 PM이더라고요. 그만큼 다양한 고민들을 하고 계실 것 같습니다. 특히 신입이라면 나의 역량 부족으로 인한 고민인지, 누구나 하는 고민인지조차도 걱정거리로 다가오더라고요.

왜 PM을 하게 되었는지, 어떤 업무를 하며 어떤 고민을 품어왔는지에 대해 간단하게 공유해 드렸는데요. 제 경험 공유를 통해 그 걱정 덜으셨으면 좋겠고, 이 글을 읽으신 모든 분께 조금이나마 도움이 되셨으면 좋겠습니다.