[W7D4] 데이터 프로덕트 매니저와 Flow Chart (오늘의집) 회고

[W6D1] 데이터 프로덕트 매니저와 Flow Chart (오늘의집)

PMB10 김무종 2022. 2. 24. 15:30 수정 공개 삭제

 

스타트업은 PM/PO에게 어떤 역량을 기대할까?

 

코드스테이츠 프로덕트 매니저 부트캠프에 참가하기 전에 스타트업 PM으로 일해보고 싶어서 이력서를 만들고 포트폴리오를 제출해본적이 있다. 그 때 당시 PM이라는 포지션 자체가 전문적인 교육기관이 거의 없다시피 했기 때문에 스타트업 자체에서 PM/PO에 대한 교육을 하고 양성하는 시스템이라고 생각했다. 하지만 코드스테이츠 PMB에서 데이터, 유저 리서치, 경쟁사 서비스 분석,A/B테스트 실험 설계 등 실제 실무에서 쓰이는 다양한 스킬을 배우다보니 이 일은 입사후 배우기에는 너무나 많은 노력과 시간이 필요하다는 것을 깨달았다. 

 

PM이라면 무조건

 

코드스테이츠에서 배우는 커리큘럼 중 가장 강조하는 것은 데이터 기반 사고방식과 분석을 통한 인사이트이다. 그리고 실제 취업플랫폼의 PM/PO 포지션의 주요 업무와 자격요건에는 빠지지 않고 등장하는 내용이 있다. 바로 데이터 기반
서비스에 대한 분석 능력과 데이터 분석 SQL 및 이를 통한 인사이트 도출 역량이었다. 버킷플레이스, 무신사, 자비스앤빌런즈 등 국내 유수의 스타트업들은 데이터 기반 사고능력을 공통의 자격요건으로 기재했다.

 

커리어 플랫폼인 Wanted에 게시된 버킷플레이스(오늘의집)의 채용공고 

 

데이터, 데이터, 데이터

 

이는 우리가 취업시장에 있어서 경쟁력을 갖춰야 할 전략적 목표다. PM이라면 정성적인 설득보다 데이터를 기반으로 하는 설득력 있는 판단이 필요하다. 이런 데이터 기반 사고방식이 스타트업에서 PM/PO에게 가장 기대하는 역량이 아닐까 싶다. 앞으로 몇 년에 걸쳐, 데이터 기반의 사고방식을 가진 새로운 유형의 프로덕트 매니저인 '데이터 프로덕트 매니저'에 대한 수요가 증가할 것이라는 전망이 지배적이다.

 

 

'데이터 프로덕트 매니저'란?

 

데이터 프로덕트 매니저은 데이터 기반 인사이트를 바탕으로 제품 및 기능을 설계하고, 통계 분석을 위한 시각화 도구로 데이터를 시각화하고, 가설 테스트 및 모델링을 통해 변수 간의 고유한 관계를 식별한다.

 

데이터 프로덕트 매니저로서 우리는 시장 지식 데이터를 활용하여 제품 개발 확대에 힘써야 한다. 데이터 과학기술, 데이터 엔지니어링 프로세스 및 시장 실험 테스트를 적용하여 맞춤형 제품 경험 제공, 데이터웨어 하우징 및 시각화의 우수성을 활용하여 제품 전략을 알린다. 강력한 분석을 위해 제품에서 수집된 데이터를 준비하는 데이터 파이프 라인 및 웨어 하우징 전략 개발 제품의 다음 반복을 형성하기 위해 다양한 A/B 및 다 변수 테스트를 설계하고 실행하는 방법을 포함하여 실제 제품의 데이터를 평가하는게 데이터 기반 프로덕트 매니저로서 해야할 부분이기도 하다.

 

데이터 프로덕트 매니저은 스스로 데이터 분석을 수행할 수 있어야 한다. 데이터를 지속적으로 모으고, 쓰는 것이 제품의 행동 방식을 결정하고, 새로운 종류의 제품을 가능하게 한다. 스스로 SQL을 작성하고 대시보드를 만들고, 설계한 실험을 직접 해석하고, 실험 결과를 얻는 것만큼이나 결과를 어떻게 분석했는지 아는 것도 중요하다. 이러한 요소들을 비즈니스 모델과 조직의 전략으로 연결시키는 것이 '데이터 프로덕트 매니저'가 해야하는 과업이라고 할 수 있겠다. 

 

---

데이터베이스의 구성

 

🔎데이터 베이스(DB)란? 컴퓨터 시스템에 전자방식으로 저장된 구조화된 데이터의 체계적인 집합 을 뜻한다.

 

데이터 베이스는 데이터가 관리되는 전체 시스템을 의미하며 이는 세가지로 구성되어 있다.

1. 데이터 서버 : 데이터가 저장되는 곳

2. DBMS(DM Management System) : 이를 관리하는 시스템

3. SQL(Structured Query Language) : 이를 관리하기 위해 사용하는 언어

 

 

 

 

SQL 명령어는 크게 데이터 조작어, 데이터 정의어, 데이터 제어어, 트렌젝션 제어어로 나뉘는데, 데이터를 다루는 PM은 데이터 조작어만 이해해도 충분하다.

---

오늘의집 Flow Chart (플로우 차트)

🔎플로우 차트 Flow Chart 온보딩 스크린 또는 홈페이지와 같이 소비자가 제품을 진입하는 시점을 시작으로 제품 구매 또는 회원가입과 같은 최종 조치 또는 결과로 끝나는 것을 말한다. 즉 프로세스 수행헤 필요한 일련의 단계와 결과를 시각적으로 표현한 것이다.

 

👀 오늘의집 프로덕트의 모든 유저플로우를 분석하기에는 양이 방대하기 때문에 디테일을 위해 특정TASK를 설정하고

오늘의집 Product Owner (콘텐츠)의 관점에서 분석해 보고자 한다.

 

TASK 

온라인 집들이 콘텐츠를 통해 커머스까지 이용하게 되는 유저의 플로우

 

 

오늘의집 Flow Chart

---

Flow Chart 기호

태스크를 실행하기 위한 유저 flow

🔷 해당 태스크를 수행하기 위한 유저 Flow를 오늘의집 프로덕트 기존 UI로 확인해보면 가장 빠르게 목표 TASK까지 도달하는 과정은 홈 ➡ 집들이 메뉴 선택 ➡ 콘텐츠 선택 ➡ 콘텐츠 확인 ➡ 제품 선택 ➡ 제품 정보 입력 ➡ 결제 정보 입력까지 7단계의 CTA를 거친다.

 

 

---

데이터 프로덕트 매니저의 관점에서 예측해 본 오늘의집 프로덕트

 

과제의 주제  오늘 강의를 바탕으로 본인이 선택한 프로덕트의 UI, 클라이언트, 서버, DB가 각각 어떻게 보이고 작동할지 예상하여 적어 봅시다.

 

서버는 이렇게 보이고 전기로 작동하지 않을까...?

사실 이 주제를 이해하는 것이 너무 어려웠다. 질문 자체가 너무 모호하고 최소한의 가이드라인이 없기 때문에 한참을 분석하려고 노력했다. 선배기수들의 과제를 조사하고 브런치와 티스토리를 다 서칭했는데도 힌트를 얻을 수 없었다. 도저히 답이 나오지 않아서 PMB QnA Help Desk에 문의를 해보니 W7D4세션에서 오늘의 과제를 다시 분석하여 Before&After를 확인하기 위한 과제라는 것을 확인했다. 지금 내가 얼마나 모르는 상태인지 체크해보고 W7D4세션에서 나의 생각이 어떻게 바뀌었는지를 확인할 수 있게 하는 것이 이번 과제의 목표였던 것이다. 모르면 모른다고 작성해도 된다고 했지만 일단 어떻게든 고민해보고 한 번 시도해 보다보면 뜻 밖의 인사이트를 얻을 수 도있기 때문에 엉망이더라도 작성해 보았다.  

 

관계도

 

위에 있는 관계도로 유추해 봤을 때, 오늘의집 메뉴인 '집들이' UI에 유저가 유입되면 클라이언트의 정보가 오늘의집 서버에 입력되고 이를 DB로 저장시킨다고 보여진다. 

클라이언트의 정보에는 회원가입시 수집되는 정보인 생년월일, 전화번호, 성별, 아이디, 기본키 등이 있을 수 있겠다. 서버는 클라이언트로 부터 데이터를 받아들이는 역할을 한다. 프로덕트 UI에서 수집하는 데이터를 서버에서 수집하는데, 카드정보, 방문자수, 매출 등이 될 수 있겠다. 데이터베이스는 서버로부터 클라이언트의 모든 정보를 받아 보관하는 역할을 하는 것 같다. DB에서 데이터 프로덕트 매니저가 필요한 데이터를 찾아 분석하여 프로덕트를 발전시키고 개선할 수 있는 데이터 기반 인사이트를 찾아내고 비즈니스 모델과 조직의 전략으로 연결시킨다. 

 

 

 

집들이 메뉴 UI

---

회고

어느덧 W7D4가 되었고 W6D1에서 했던 '데이터 프로덕트 매니저의 관점에서 예측해 본 오늘의집 프로덕트'에 대한 생각이 얼마나 바뀌었는지에 대한 Before&After를 파악하고자 한다.

우선 개발자와의 커뮤니케이션을 위해 IT 지식을 배웠다. 학습을 통해 UI, 클라이언트, 서버, DB를 접하게 되었다. 익숙하지 않은 개념이었기에 이해하는데 오랜시간이 걸렸다. 그러다가 동기가 추천해준 책인 '비전공자를 위한 이해할 수 있는 IT지식'을 읽은 것이 큰 도움이 되었다. 

 

---

 

'클라이언트와 서버' 예시

 

우리는 식당에 가서 종업원에게 이렇게 얘기한다.

 

"여기 메뉴판 좀 주세요."

"물 좀 가져다주세요."

"주문이요."

 

이때 우리는 가게의 손님(클라이언트)이다. 종업원은 서빙하는 사람. 즉 '서버'라고 한다. 같은 개념이다. 클라이언트는 서버에게 계속 무언가를 달라고 한다. 일반적으로 컴퓨터를 클라이언트라고 칭하지 않는다. 클라이언트는 보통 '일을 맡긴 사람'을 뜻한다. 하지만 개발자의 세상에서 클라이언트는 대부분 컴퓨터이다. 서비스를 사용하는 사용자들이 소유한 컴퓨터를 뜻한다. 여러분의 스마트폰이나 고객의 컴퓨터가 모두 클라이언트이다. 

 

한편 고객의 입장에서 보면 클라이언트 컴퓨터를 직접 볼 수 있고. 만질 수 있다. 고객의 바로 앞에 있는 이 클라이언트 컴퓨터를 다른 말로 '프론트 엔드'라고 표현한다. 반면, 서버는 고객이 볼 수 없는 곳에 있다. 고객에게 보이지 않는 곳. 즉 고객의 뒤에 있다. 그래서 서버를 다른 말로 '백 엔드'라고 부른다.

 

'클라이언트'

'클라'

'프론트 엔드'

'프론트'

 

모두 같은 말이다. 고객의 컴퓨터를 뜻한다.

 

'서버'

'백 엔드'

'백'

 

이 또한 모두 '주는 컴퓨터'라는 뜻이다. 개발자와의 대화에서 자주 등장하는 아주 중요한 용어들이다.

 

결론

[W6D1]

위에 있는 관계도로 유추해 봤을 때, 오늘의집 메뉴인 '집들이' UI에 유저가 유입되면 클라이언트의 정보가 오늘의집 서버에 입력되고 이를 DB로 저장시킨다고 보여진다. 

클라이언트의 정보에는 회원가입시 수집되는 정보인 생년월일, 전화번호, 성별, 아이디, 기본키 등이 있을 수 있겠다. 서버는 클라이언트로 부터 데이터를 받아들이는 역할을 한다. 프로덕트 UI에서 수집하는 데이터를 서버에서 수집하는데, 카드정보, 방문자수, 매출 등이 될 수 있겠다. 데이터베이스는 서버로부터 클라이언트의 모든 정보를 받아 보관하는 역할을 하는 것 같다. DB에서 데이터 프로덕트 매니저가 필요한 데이터를 찾아 분석하여 프로덕트를 발전시키고 개선할 수 있는 데이터 기반 인사이트를 찾아내고 비즈니스 모델과 조직의 전략으로 연결시킨다. 

 

[W7D4]

오늘의집 메뉴인 '집들이'는 프론트엔드이다. 클라이언트 프론트엔드의 화면 구성을 UI라고 한다. 유저가 UI에서 클라이언트를 통해 원하는 기능을 요청하게되면 서버는 해당 기능을 수행하기 위해 DB에 있는 데이터를 클라이언트에게 전달한다. 이 과정에서 서로 요청과 응답을 주고 받기 위해서는 사전에 '여기로 요청하면 이러한 응답을 보고, 저기로 요청하면 저러한 응답을 보낸다'라고 하는 일종의 체계가 필요하며, 이 체계를 API라고 한다.