개발이 레거시 문제를 해소하고 있을 때 PO는 뭐했을까
나는 이런 것을 했고, 이런 점을 배우고, 이런 것이 성장했다.
올해 조직개편이 되면서 나에게도 작은 변화가 있었는데, 상품팀과 주문팀을 동시에 하던 업무를 하나로 줄이고 주문클레임팀에만 집중하게 되었다. 전혀 의도한 바나 예상한 바가 아니었지만 이렇게 할 수 있었던 것에는 지난 7개월동안 정말 노빠꾸의 자세로 착실하게 성장해서 든든하게 함께해준 우리 주니어인 '서리'의 공이 가장 컸다. 조직개편 후 하나의 모듈만을 바라보고 진행하려니까 전전긍긍 바쁘고 정신없던 작년의 한해가 어느 정도 정리되는 것 같다. 그럼에도 아쉬운 것은 하고 싶었던 것이 많았기 때문이었다.
그래서 작년에 가장 주력으로 했던 성과인 레거시를 개선했던 일들과 그를 통해서 우리팀들이 함께 해낸 일들을 잠시 정리해볼려고 한다. 개인 블로그기 때문에 구체적인 수치나 세세한 내용은 다룰 수가 없다. 종종 백엔드 중심으로 일하는 PO는 뭐하냐고 물어보는 사람들이 많아서 이런 이야기가 도움이 될 것 같기도 하다.
(사실 다른 일을 해야하는데 너무 힘들어서 잠시 쉬는 타이밍이라고 봐도 된다)
레거시의 문제점을 개선하기 위한 2021년
2020년 10월 5일에 지금 회사에 입사했다. 입사할 때 나는 당연히 내가 기존에도 주력하고 있던 업무인 주문팀을 담당하는 것으로 이야기하고, 밖에서부터 구조적인 부분들을 역기획하면서 몇가지 정책적 문제들을 찾아낸 상태였다. 예를 들어 쿠폰의 클레임 처리방식을 봤을 때 비용 처리 방식이 무지막지하게 자사에 부담이 되는 형태로 되어 있을 것라는 점이나, 몇가지 형태의 클레임 케이스를 고려하지 않아서 셀러들이 어떤 불만을 품고 있겠다라는 것은 입사하지 않아도 알 수 있었다. (이건 순전히 국내 이커머스의 동질성에서 오는 짬바같은 거다)
그리고 막상 입사했을 때, 주문팀은 정책은 일단 냅둔 채 레거시에 대한 문제를 줄이기 위해 대대적인 리팩토링 작업을 하고 있었고 나는 무엇을 해야하나 고민에 휩싸였다. 그런데 그 고민은 딱 입사후 1주일 내에 사그러 들 수 있었다. 딱 다음주가 되었을 때, 회사에서는 전사플래닝을 준비하기 시작했고 갑작스럽게 상품팀을 한번에 하게 되었다. 가장 큰 이유는 레거시의 문제를 개선하기 위한 프로젝트를 누군가 진행해야했고 감사하게도 다양한 이커머스 경험이 많았던 사람이 나였던 탓(?)이었다.
스타트업의 레거시는 여러가지 이유로 복잡하게 만들어진다는 이야기는 익히 들어왔었다. 특히 성공할지 안할지 모르는 서비스를 위해서 기존의 시스템에 얽어서 모든 것을 만들었다가는 빠른 실패의 뒷수슴이 어렵기 때문에 '연관성을 만들지 않고' 만드는 시스템이 훨씬 효율적이고 안정적일 수 있다는 것이다. 그렇지만 내 눈으로 직접 보게 되었을 때는 대기업의 오랜 경험으로 납득이 잘 가지 않는 부분도 많이 있었다.
"아니, 이건 왜 이렇게 생긴거지?? " 이런 생각이 골백번도 들었지만, 원래 대기업 서비스기획은 기능조직으로 이루어져 있어서 APPLE이 기능조직을 유지하는 이유가 특정 서비스에서의 '완전성(perfectness)'를 추구한다는 말을 들었던 것이 생각났다. 요즘의 프로덕트팀 형태의 서비스들은 그것보다는 효과의 측정을 더 중요시 한다고 했으니까 레거시가 이럴 수 있겠구나 이해했다. 어차피 나의 역할은 그것들을 정리하는 역할이었기에 내가 생각하는 나의 장점과도 일치한다고 생각했다.
그래서 주문팀의 리팩토링은 일단 한발 물러서서 지켜보고, 상품팀의 서비스 단위로 분산되어 있는 상품의 레거시를 통합하여 하나로 교체하는 프로젝트를 함께 진행하게 되면서 프로덕트팀 양다리 생활을 하게 되었다. 그나마 장점은 이커머스에 대해서는 두루 모듈을 돌았었기 때문에 상품도 아예 낯선 것은 아니었다는 점이었다. 일하는 방식은 달라도 이커머스도메인 지식이 먹혀들어가고 있었다.
MSA환경에서 레거시를 교체할 때 PO가 하는 일
MSA의 환경에서 하나의 도메인은 3가지 정도의 업무 구분을 해볼 수가 있다.
1) 데이터의 입력과 생성되는 백엔드,
2) 데이터의 제공(API, Queue, DB간 ETL 통한 타 MSA에 제공),
3)MSA내 프론트엔드의 구현과 그것을 위한 API gateway
이 중에서 상품팀은 특히나 주문데이터가 생성되는 과정까지 모든 곳에서 상품의 근간 데이터가 되기 때문에에 영향을 받는 모듈이 정말 무지무지많다. 사실 그냥 전부다 였다고 봐도 무방했다.
팀의 테크리더와 팀원들이 너무나 전문가들이라서 사실상 백엔드의 변경은 척척 진행됐다. 앞으로 교체해야할 새로운 하나의 통을 만들고 기존의 레거시 데이터로 바꾸는 작업이 정말 숨가쁘게 진행됐다. 마치 '어밴져스 인피니티워'에서 비전과 마인드스톤의 연결된 수많은 연결고리를 하나하나 수작업으로 분리하던 슈리를 떠올리면 된다. 이것을 분리하기 위해서 어디어디에 연결되어 있는지를 계속 찾아내고 계속 변경하는 것의 연속이었다. 이 일은 정말이지 꼬박 만 1년하고도 3개월이 더 필요했다. 커다란 것들은 9개월 내에 마무리 한 것 같은데, 계속해서 발굴되었던 탓이 크다.
그럼 이러한 과제를 진행할 때 PO가 했던 일은 무엇일까? 엄청나게 많은 오버커뮤니케이션이었다.
정말 수차례에 걸쳐서 상품의 레거시 변화가 가져오는 변화를 시간 단계별로 설명했고, 내부의 플랜에 따라서 각 팀에서 수정해야하는 사항을 미리 알려주고 협의를 해야했으며, 정책이 변경되는 부분에 대해서 입이 닳도록 설명하고 다녀야 했다. 그 중간중간에 합리적인 정책 변경에 대한 의사결정도 당연히 필요했다.
개발 테크리더간의 의사소통이 분명 있었지만, 서비스의 변화에 시점 설명은 회사의 다음 전략 방향과도 닿아 있었기에 세세하게 CS부서부터 마케팅, 영업, 전략 등등 다른 유관부서에 소통해야했고, 임팩트가 더 큰 방향으로 변화의 방향을 조정하기 위해서 노력했다.
여기서 과거에 폭포수방식으로 '차세대'라고 부르면서 레거시를 전환했다면, 한번에 1년여를 개발해서 바꿨을 거고 오류와 교육되지 않은 혼동의 과정이 동시에 왔겠지만 스프린트 단위로 조금씩 일정에 맞게 바뀌는 과정은 기차가 역을 지날 때마다 역을 안내하는 것과 비슷한 과정이었던 것 같다. 그리고 비즈니스 관점에서 더 중요도가 높은 곳이 있다면, 미리 협의하여 먼저 변경하거나 하기도 했다. 지나쳐야 하는 역의 순서를 바꿀 수 있는 시점들이 계속 존재했기 때문이다.
상품 레거시를 교체하고나서 할 수 있었던 일
그렇게 새로운 상품통을 단순하게 만들면서 꼭 필요한 몇가지 회사의 숙원사업들도 선결과제로 해결했다.
자체적인 상품을 바탕으로 빠른 배송 서비스를 할 수 있는 풀필먼트 서비스의 초석을 만들었고, 그리고 가장 중요한 변화는 파트너센터에서도 상품 관리 방식이 2가지라서 항상 혼동에 빠져있었던 부분을 하나로 통합하면서 정리하고 다듬었고, 직접 상품을 등록할 수 있는 기능과 플랫폼에서만 지원하는 상품 자체 할인도 함께 만들었다.
그 과정에서 가장 많이 성장했던 부분은 '이것이 정말 필요한 것인가'에 대해서 재고민을 해볼 수 있었다는 점이었다. 기존에 모든 것을 갖춘(갖추지 않으면 누구라도 화를 내는) 조직에서 '차세대'를 만들 때 나는 하나라도 빠지지 않도록 챙기는 것이 굉장히 중요했다. 그런데 사실 '언제 쓸지, 얼마나 쓸지 모르는 서비스'를 만드는 것은 기획, 개발, 디자인, 테스트 리소스 낭비일 뿐 아니라 서비스의 복잡도도 높인다. 요구사항이 많은 서비스는 엔트로피가 높아지고 자연히 오류가 날 상황도 더 많다. 그래서 그 때부터 머리 속에 이등병처럼 툭 치면 튀어나오는 기능 리스트들 중에서 꼭 필요한 것만을 '어떻게 줄이나'를 많이 고민했다.
우선순위를 정하는 것에는 여러가지 프레임워크가 많은데, 나는 익숙한 것이 없다보니 당시 내가 정한 상품팀의 Vision에 충실하기로 했다.
"상품팀은 다양한 BM으로 확장 가능한 유연한 커머스 구조를 구축한다.'
그래서 매번 귀를 열고 다른 사업부가 슬랙에 흘리고 다니는 다음분기나 그 다음에 하려고 아이데이션하는 사업에 대한 소식에 집중했다. 이렇게 정의한 후 정의한 Mission이 2가지였다.
'상품의 양적 확보'와 '상품의 질적 확보'였다.
양적 확보를 위해서 비즈니스임팩트가 높은 사업팀과 협업하여 Open API를 통해서 상품을 연동하여 통합 솔루션인 상품 솔루션으로 입점을 받는 것도 빠르게 만들어 낼 수 있었고, 엑셀 일괄 업로드 기능을 하기로 했고, 질적 확보를 위해서 기존에 보유하고 있지 않던 상품 데이터를 머신러닝을 통해서 추가할 수 있는 방법들을 함께 고민했다. 워낙 좋은 동료들이 많으니까 고민을 함께 하면 뚝딱뚝딱 결과가 나오는 게 너무나 신기했다.
그 외에도 이래저래 설명하기 어려운 크고 작은 변화와 분쟁, 정신없음을 통해서 정말 1년만에 상품 레거시가 훌륭하게 정리되었다.
정리해보면 레거시의 변화와 스프린트 단위의 발전 속에서 PO로서 내 역할은 2가지가 가장 컸다.
첫째, 레거시의 변화에 따른 각 연관 부서와 도메인에 시점별로 상황이 어떻게 변하는지 앞으로는 어떻게 변할 것인지 계속 알리고, 같이 사업의 전개의 시점을 맞출 수 있도록 함께 조율했다.
둘째, 여러가지 변화의 과정에서 어떤 것을 먼저 바꾸고, 어떤 것을 먼저 시작할지를 전사적인 비즈니스의 관점에서 정리하고 선택했다.
부족했던 점도 있다.
숙원사업들과 이커머스라면 응당 필요한 부분들에 집중하느라 상품팀을 중심으로 좀 더 비즈니스를 발의해서 만들어내지는 못했다는 점이었다. 그리고 그건 21년 12월쯤에 뭔가 머리속에서 차츰 정리되면서 해야할 것들을 찾아내고 이니셔티브를 가져가려고 하고 있었다. 사실 마음 한켠이 희망으로 조금 부풀었었다. 아쉽게 도 놓아주게 되었지만, 어차피 함께 하고 있었던 주니어친구가 PO가된 것이니 잘 인수인계를 해주었다.
주문 리팩토링이 완료된 후, 할 수 있었던 것
그 사이에 21년 3월 정도에 주문의 리팩토링 작업도 어느 새 완료되어가고 있었다. 정말 긴급한 일이 아니면 뭔가 일을 진행하고 않고 있었고 그 나마도 최소화 요건으로 진행하려고 노력했는데, 이 형태로는 한계가 올 것을 알고 있었기에 해야할 일들을 리스트업하고 이것을 끊어서 장기적인 로드맵 플랜을 세워보았다.
구체적으로 말할 수 없지만, 가장 큰 목표는 '주문-클레임-배송-정산'으로 이어지는 플로우에서의 정책적 유연성을 확보하고 비용 구조를 개선하고, 안정성을 높이는 것이었다. 그런데 이러한 프로젝트를 중간에서 한번씩 끊어간다는 것은 중간단계에서 분명 불편함이 발생하는 한계가 있다. 그래서 기존의 대기업에서는 왕창 뜯어서 차세대를 하는 방식이었다. 하지만 이 상황을 겪으면서 '목적에 적합한 수준'에 대해서 조금 더 고민해볼 수 있었다. 가장 큰 목적을 위해서 작은 부분에 대한 완성도를 조금 뒤로 미루는 것에 대해서 '완전무결주의'에서는 용납할 수 없을 것 같다. 하지만 '성장주의'라면 효과있는 곳을 먼저 하기 위해서 조금 뒤로 미루는 것도 가능하다. 이 상황도 그랬다. 한계는 있었지만 큰 성과가 보이는 변화만 떼어서 하기로 했다.
그렇게 작게 떼어낸 것인데도 주문 프로젝트의 특성상 5개월이상 소요되는 긴 호흡의 프로젝트가 시작됐다. 주문의 정책을 뜯으면 보통 클레임과 쿠폰쪽, 정산은 무조건 따라오게 되는 경우가 많다. 사이즈가 자꾸 커질 수밖에 없다. 하지만 기존의 회사라면 나머지를 다 합쳐서 2년동안 바꿨을 프로젝트였다고 생각한다. 내부적인 비용 구조를 효율적으로 바꾸는 프로젝트였다. (보통 구조를 바꾸는 프로젝트의 목표는 UI나 사용성보다 비즈니스적인 목표가 앞선다)
모두가 고생한 끝에 이 프로젝트는 올해 초에 완료됐고, 지금 두근거리는 마음으로 성과를 측정하기 위해서 준비를 하고 있다.
작년의 가장 많이 발전한 것
물론 프로젝트 진행을 도와주거나 한 친구들이 있었기에, 모든 프로젝트 실무를 직접하지 않았다. 화면 설계는 프로덕트 디자이너들에게 위임했고, 작은 프로젝트는 방향성과 기본 정책을 세운 뒤 주니어PO에게 넘겨주기도 했다. 우당탕탕 그렇게 1년이 지났다.
가장 큰 변화는 문서의 양식과 그 이면에 담긴 애자일 사상으로 일하는 방식에 적응하는 것이었고, 그리고 비즈니스 임팩트에 대해서 고민해 볼 수 있는 시점이 주어졌고 거기에 대해서 발언할 수 있는 환경이 생겨서 습관적으로 하던 부분을 의식적으로 바꿀 수 있었다. 나는 꽤 많이 배우고 성장했고 그 과정에는 정말 좋은 동료들이 있었기 때문에 가능했다.
그런데 딱 하나, 당시에 불만이 있었던 부분은 폭포수 프로젝트에서 가지고 있었던 '빠짐 없는 기획'과 '정확한 일정 산정'이 안되는 것 같은 느낌이었다. Userstory와 프로젝트의 목적도 분명히 하고 성과 데이터도 측정하고 있지만, 내가 무언가를 분명 잘 못하고 있다는 생각이 들었다.
그건 바로 Userstory에 대한 완료조건(acceptence Cretria)의 활용에 대한 부분이었다. 연말에 주문팀에서 우연찮게 DDD(도메인 주도 설계), ATDD(acceptence test driven development)를 공부하면서 다른 방식으로 협의를 하면 더 좋은 성과와 업무 측정이 될 수 있겠다는 것을 깨닫게 되었다. 일단 내가 잘하면 개발의 DDD, TDD적인 방향이나 스프린트의 예상은 훨씬 나누기가 용이해졌다. 그리고 그 다음에 오는 프로젝트부터 시간을 들여서 Userstory와 완료조건을 세밀하게 기록하고 협의하는 과정을 프로젝트 시작시점으로 당겼다.
그제서야 티켓별 스토리 포인트와 작업 시간 추정이 가능해졌고, 그제서야 함께 일하는 팀원들의 불안감, 그리고 나의 어딘가 정책이 빠졌을 것 같은 불안감도 함께 해소되기 시작했다. 그리고 변경되는 정책에 대한 관리도 PRD에서 하던 것에서 훨씬 안정적으로 체크할 수 있게 되었다.
작년 연말에는 주문팀, 상품팀 두 팀의 경험많은 테크 리더들과 대화를 해가면서 어떻게 프로젝트를 정리하고 진행할지 우리들만의 방식을 좀 더 구체적으로 협의할 수 있었다.
지금와서 생각해보면, 정말이지 기승전결이 아름다운 2021년의 성장 이야기다.
어쩌다보니 꼭 회고를 쓴 거 같지만, 이건 목표대비 회고라기 보다는 내 성장에 대한 이야기다. 작년에 읽은 책들과 실무에서의 교훈들, 그리고 함께 정의내린 여러가지 방식과 사고방식을 전파하기 위해 노력한 것들 모두가 많은 부분 마음의 안정을 가져다 주었다. 그리고 어쩐지 올해는 더 잘할 수 있을 것 같은 마음을 주었다고 할까..
그런데 어쩌다보니 한 팀으로 다시 업무를 줄이게 되니 아쉬운 마음도 들긴 하다. 특히 비즈니스 임팩트에 대한 챌린지는 주문팀에 비해서 변화의 호흡이 짧고 앞단에서 움직이는 상품이 컸기에 그 부분에 대한 성장이 컸다. 함께 일한 분이 이런 이야기 또 글로 쓸거냐고 했는데,, 어쩌다보니 약간 두루뭉수리하게 쓰게 됐다. (미안해요 이미 썼네요.. 근데 그 멘트는 꼭 나중에 쓸께요)
주문팀에서라도 필요한 것만 하지 말고, 더 먼저 나서서 비즈니스 임팩트를 찾아내고 꼭 사업적 이니셔티브를 만들어낼 수 있도록 해야겠다. 10년이 훌쩍 넘은 연차에 스스로 성장할 수 있었다고 말하는 것은 아마도 대놓고 자랑이라고 생각한다.
(이제 진짜 할 일 하러 가야지....)
