brunch

브런치북 오늘 프로덕트 매니저가 되었다 06화

라이킷 23 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by YB Mar 28. 2021

프로덕트 매니저는 누구와 함께 제품을 개발하는걸까?

기획에서 배포까지 제품 개발 사이클 알아보기

-

IT 기업에서 제품은 어떻게 운영되고 있을까?

최근 모바일 앱을 업데이트한 적이 있는가? 자주 사용하는 앱이라면 그럴 것이다. 앱에서 치명적인 오류가 생겼는가? 계속 고쳐지지 않는다면 그 앱을 휴지통으로 옮길 것이다. 제품 출시를 마쳤다고 끝이 아니다. 오히려 고객 반응과 피드백을 예의 주시하며 지속적으로 개선할 시점이다. 제품 조직은 이터레이션(iteration)으로 주기적으로 기존 기능을 개선하거나 새로운 기능을 출시한다. 이번 글에서는 하나의 이터레이션이 어떻게 운영되는지 업무 사이클을 알아보겠다.

-

이터레이션 중심의 제품 개발 사이클

우선 제품 조직이 어떻게 구성되었는지를 살펴보자. 각 조직의 문화, 체계, 시스템에 따라 다르지만, 큰 맥락에선 하위 제품 유닛으로 이루어져 있다. 이커머스 조직이라면 검색, 광고, 추천, 상품, 결제, 배송 등으로 나뉘는 것이다. 각 유닛에는 프로덕트 매니저, 제품 디자이너, 프런트엔드/백엔드 개발자 등이 속해있다. 상위 유닛에서 제품의 비전과 목표를 수립한다면, 하위 유닛은 세부 전략과 로드맵을 수립한다.

제품 개발과 배포를 마치면 하나의 이터레이션이 끝난다. 앱은 하나의 버전에 업데이트할 기능을 담아야 하므로 모든 유닛이 약속한 배포 일정을 준수해야 한다. 웹은 배포하는 즉시 해당 URL에 접속하여 사용한다. 따라서 유닛별로 다른 배포 일정을 가져도 상관없다. 따라서 고객 반응에 따라 잦은 이터레이션이 필요하면 웹으로 제품을 개발하는 게 좋다.

이터레이션에 포함되는 각각의 기능은 '요구 사항 기획 - 디자인 - 개발 - QA(품질 검증 테스트)'를 거친다. 프로덕트 매니저는 전체 과정에 관여하며, 본인이 수립한 요구사항과 배포 일정에 맞게 제품을 개발하도록 이끈다. 이터레이션을 끊김 없이 반복하기 위해서는 하나의 기능이 개발되는 시점에 다음 기능에 대한 요구사항을 작성해두는 게 좋다.

상황에 따라 동일한 이터레이션에 포함할 기능이 여러 개일 수도 있다. 프로덕트 매니저에게 여러 제품의 개발을 관리할 수 있는 멀티태스킹이 요구된다. 예로 아침에는 기능 A의 배포 준비 상황을 체크하고, 점심을 먹고 기능 B의 디자인을 검토하고, 퇴근 전에 기능 C의 요구 사항을 작성하듯이 말이다.

제품 이터레이션을 시각화하면 이렇다

-

하나의 제품을 세분화한 업무 사이클

하나의 '요구 사항 기획 - 디자인 - 개발 - QA(품질 검증 테스트)'를 조금 더 상세히 뜯어보자. 프로덕트 매니저가 요구사항 작성을 마쳤다면 디자이너는 와이어프레임을 설계한다. 이후 프로덕트 매니저와 UX/UI를 최종적으로 검토한다. 검토가 끝나면 프론트엔드 개발을 위한 디자인 가이드를 제작한다. 제품 개발은 크게 백엔드와 프론트엔드로 나뉜다. 대게는 백엔드 개발을 먼저 시작한다. 제품에 필요한 DB(Database), 클라이언트 즉, 화면과 송수신하기 위한 API가 있어야 하기 때문이다. 웹을 운영한다면 프론트엔드 개발이 필요하다. 디자인 가이드에 따라 퍼블리싱을 하고, 백엔드에서 제작한 API를 화면과 연결하는 작업을 한다. 앱을 운영한다면 클라이언트 개발이 필요하다. 상세하게 다른 점도 있지만 큰 맥락에선 프론트엔드와 같은 작업을 진행한다.

웹/앱 개발을 완료했다면 테스트 서버에 배포해 제품 테스트를 진행한다. 이를 QA(Quality Assurance)라 부르며, QA 테스터가 요구사항을 검토하고 TC(Test case)를 작성한다. 제품 품질 지표를 통과할 때까지 테스트를 반복하며 완성도를 높여나간다. QA를 마치면 엔지니어들은 배포를 준비한다. 웹, 앱의 특성이 다르므로 동일한 제품이어도 배포 시점이 다를 수 있다. 앱도 OS별로 배포 완료 시점이 다를 수 있다. 구글 플레이 스토어를 통하는 안드로이드가 앱 스토어를 통하는 iOS보다 승인 기준이 낮고 심사 기간도 짧기 때문이다.

하나의 기능을 중심으로 뜯어본 제품 업무 사이클

만약 가설 검증이 필요하면 A/B 테스트로 배포를 진행할 수 있다. A/B 테스트는 대표적인 제품 실험으로 동일한 기간에 일부 유저에게 새로운 기능을, 나머지 유저에겐 기존 버전을 제공한다. 가설을 검증하려는 지표를 기준으로 두 집단의 패턴을 분석한다. 처음에는 새로운 기능을 선보일 집단을 전체에서 일부로만 설정한다. 혹시 모를 오류에 대비하기 위해서이다.

수립한 가설에 맞게 유저들이 새로운 기능을 사용한다면 배포율을 차츰 높여간다. 그렇지 않거나 오류가 발생하면 해당 배포를 멈추고 롤백(Rollback) 할 수도 있다. 실험 문화가 활발한 조직이라면 이러한 배포 방식이 잦을 것이다. 따라서 여러 테스트를 동일한 기간에 진행할 수도 있는데, 각각의 테스트가 서로에게 영향을 주어서는 안 된다. 이러한 실험 설계는 대게 데이터 분석가, 데이터 과학자와 함께 진행한다.

프로덕트 매니저는 이러한 업무 사이클 전체를 관여하는 사람으로서 다양한 직군의 팀원들과 협업하게 된다. 이러한 특성으로 커뮤니케이션이 가능한 수준의 다방면의 업무지식이 필요한 것이다.