IT 서비스 고도화 단계에서의 PO의 역할
역할에 따라 엄청 달라진다.
굳이 따지자면 대충 시리즈 D 이상의 유니콘 스타트업이라고 불리는 IT 서비스나, 오래되고 잘 나가는 IT 기반의 서비스가 대부분 여기 속할 것 같다.
유니콘 스타트업은 검색하면 나올 것이고, 오래되고 잘 나가는 IT 기반의 서비스는 대략 네이버 카카오 계열사를 비롯한, IT 공룡과, 지마켓, GS샵, 11번가, 쿠팡 등등 잘 나가는 커머스가 여기에 속할 것이다.
대부분 이 정도 되었으면, 레거시가 엄청 쌓였을 것이고, 새로 할 비즈니스는 많고, 운영하고 있는 서비스도 많고 업무 영역이 엄청 세분화되어 있을 것이다.
이런 큰 회사에서는 업무영역이 어떻게 나누어 질까?
네이버에서 일을 해보지 않았지만, 네이버로 치면, 웹툰, 메일, 검색, 블로그, 지식인, 쇼핑.. 등등이 각각의 프로덕트 일 것이며, 각각의 프로덕트 내에도 기능에 따라서 도 나눠질 거 같은데,
대충 쇼핑(커머스) 기준으로는, 상품, 주문, 회원, 검색, 결제, 정산, 쿠폰, 메시지, 장바구니 등으로 나누어질 것이며, 여기서 상품도 상품 상세와 상품 전시, 상품 등록으로 나누어질 것 같다.
또, 고객에게 보이는 프런트 영역을 담당하는 부분과, 직원이나 내부 직원이 사용하는 어드민, 파트너가 사용하는 어드민 등으로 나누어질 것이다.
이건 대략적으로 예를 드는 것이고, 대부분의 이런 회사들이 작은 영역이면 2-3개의 영역을 한 명의 PO가 맡을 수도 있고, 큰 영역이면 하나의 영역을 여러 명의 PO가 나누어서 맡을 수도 있다.
아 네이버에서는 기획자라고 부르긴 하는데, 결국 하는 일은 같은 느낌이었다
그럼 이런 곳의 PO는 주로 무슨 일을 할까?
일단, 기존에 내가 이야기했던 영역은 본인이 맡은 프로덕트에 따라서 누군가는 하고 있을 것이다.
PMF는 계속 변하기 때문에, 누군가는 기존 프로덕트에 새로운 서비스를 붙이고 그 서비스에 PMF를 찾는 일, 메인 프로덕트의 성장을 위한 모든 일을 할 것이다.
그리고, 기존 레거시를 효율화하고 리팩터링을 하는 일을 할 것이고, 시스템에 뭔가 문제가 생기면 그것을 해결하기 위한 일을 할 것이고, 그 해결을 단기적으로 해결할 것인지, 기능적으로 풀 것인지 등에 대한 의사결정을 하고 각 부서에 공유하고 그런 일을 할 것이다.
또, 기존에 문서화가 잘 안 되어있을 확률이 크기 때문에, 서비스의 정책에 대한 문서화를 하고, 또 가이드를 만들고, 뭔가 이해가 안 되는 기존의 정책이 있으면 히스토리를 파악하고 좀 더 효율적으로 정책을 바꾸는 노력을 하고, 그렇게 서비스의 정책이 바뀌면, 기능이 바뀔 것이고, 그 기능을 바꾸기 위해서 회사 내, 외부의 시스템 이용자 그리고 개발자 분들과 회의를 하고, 고민하면서 더 좋은 정책을 만들고 새롭게 바뀔 정책과 기능을 가지고 또 회사 내 외부 사용자와 인터뷰를 하면서 결국 테스트하고, 배포하고 가이드와 배포 공지를 하고, 배포하고 나서 모니터링하고 문제가 없으면 일단 하나의 프로젝트가 끝날 것이다.
이런 일을 할 때, 본인이 맡은 프로덕트가 아닌 다른 프로덕트에도 영향을 끼친다면 당연히 해당 영역의 PO와도 정책 논의를 계속하게 될 것이다.
뭐 이런 걸 보통 제품 로드맵 정할 때 어느 정도 미리 해두는데, 당신이 속한 조직이 목적 조직이라면 이 로드 앱을 프로덕트 팀 내부/ 프로덕트 팀 내부로 나누어서 해당 업무의 긴급도, 비즈니스 임팩트 등등을 보고 판단하게 될 것이다.
만약 서비스의 트래픽이 크고, 시스템이 복잡한데, 계속해서 개발자와 PO를 많이 뽑을 용의가 있으면 요즘 대세인 MSA 전환을 하려고 할 것이다.
MSA에 대해서 간략하게만 설명하자면, Micro Service Archtecture를 줄인 말이다.
일반적으로 IT 서비스를 처음 시작 할 때는 모든 기능(프런트 화면 또는 백 어드민)과 데이터를 하나의 큰 덩어리로 만든다. 왜냐면 보통 한 명 또는 소수의 개발자가 동시에 작업해서 만들기 때문에 그렇게 만들 때 효율이 좋다. 이것을 모놀리식 서비스라고 한다(아마 MSA 만드는 사람이 나중에 이렇게 부른 것 같다)
그런데, 서비스가 복잡해지고 데이터도 방대해지고 새로운 개발자가 오게 되면 기존 히스토리를 찾기도 어렵고, 하나에 오류가 생기면 모든 서비스에 영향이 끼치는 등 문제가 생긴다.
이런 문제를 해결하기 위해서, 각각의 기능별로 DB와 서비스를 따로 분리하는 것을 MSA라고 한다.
여기서 말하는 기능은 위에서 이야기한 상품, 주문, 회원 등등을 이야기한다.
MSA로 전환하려고 할 때 PO는 주로 이런 일을 한다
기존 서비스(보통 레거시라고 한다) 운영하면서 각 기능을 하나씩 MSA로 이관시다보면 어느 순간은 레거시와 MSA를 동시에 운영하다가, 문제가 없다고 생각하면 레거시를 일몰 하고 MSA만 활용할 것이다.
이것을 아까 위에서 나누었던 기능 또는 도메인 영역으로 하나씩 다 할 것이고, 그를 위해서, 스펙 정의, 일정 조율, 테스트, 내부, 외부 공유 및 가이드 작성 등을 하다 보면 1년은 훌쩍 지나있을 것이다.
MSA로의 전환에 대한 자세한 내용은, 이 업계의 네임드 도그냥님의 https://brunch.co.kr/@windydog/581 블로그를 보면 좀 더 감이 올 것이다. 내가 이 글 쓰고 있는 중에 도그냥님 글이 업데이트가 돼서 읽어봤는데, 내가 굳이 이 부분에 대해서 자세히 쓰는 거보단 해당 블로그 읽는 게 나아 보였다.
그러면서도 계속해서 터지는 운영 이슈는 어떻게든 해결해야 하니, 이것을 MSA 나올 때까지 수기로 버틸지, 그전이라도 기능으로 해결할 것인지, 기능으로 해결할 것이면 어느 정도로 잘 만들 것인지도 해결해야 할 것이고, 또 그 와중에 새롭게 들어오는 비즈니스 요구사항에 따라서 새로운 형태의 비즈니스를 시도하는 경우도 있을 것이다.
만약 당신이 맡은 영역이 결제라면 새로운 결제 시스템(요즘이면 제로 페이나 차이 페이, 카카오 뱅크 등)을 붙일 것인지, 또 어떤 결제회사와 프로모션을 하기 위한 무언가를 기능으로 만들지, 어떻게든 하드코딩으로 해결할 것인지 등을 정하고, 또 내 외부를 설득해야 할 것이고, 일단 붙여놓고 이것에 대한 UX를 더 좋게 하기 위한 무엇인가를 할지 말지도 결정하고 협의하고 공유할 것이다.
대충 정리해서 이야기하면,
1. 앞에서 내가 쓴 스타트업 초기, 발전 단계의 영역의 일을 하던가 2. 신규 비즈니스나 업무 효율을 위한 기능 추가 및 고도화 3. 레거시 해결을 위한 리팩터링 및 /MSA로의 전환 정도의 일이 될 것이고, 이 모든 일을 할 때 대부분, A. 기존 기능에 대한 비즈니스적 기술적 분석 B. 각 사용자와의 인터뷰 or 데이터 분석, 정책 협의, C. 정책 확정 및 기획서 작성 D. 테스트 케이스 작성 및 테스트 E. 배포 및 배포 공지, 모니터링 등등의 작업을 다 하게 될 것이다.
이게 뭔가 말로 하니까 간단한데, 회사마다 업무 영역이 엄청 세부적으로 나누어져 있을 것이고, 또 그 세부적인 영역에 따라서 그들이 하는 일이 각각 다를 테니 내가 모든 일을 다 알 수는 없고, 대략적으로 하는 일이 저렇다는 것을 이야기한 것이다.
일단 나름 유니콘 커머스 회사에서 일하면서 내가 겪고, 본 일, 그리고 주변 큰 IT 회사에서 일하는 사람들이 랑 이야기하면서 생각해서 쓴 것인데, 혹시 내가 모르는 영역의 업무가 있거나, 좀 더 세부적으로 이야기하면 좋을 것을 이야기해주신다면 더 업데이트해보겠다.
