스타벅스 딜리버스가
어떻게 작동될지 다시 예측해보기
지난글 회고 _코드스테이츠 PMB 10기
2주 전, 개발지식이 0인 상태에서 스타벅스 딜리버스는 어떻게 작동 될지 데이터를 예측하여 글을 작성했었다. PM이 꼭 알아야 하는 개발지식을 2주간 공부하고 해당 글을 업그레이드 시켜보고자 한다. 수박 겉핥기 같았던 지난글에 대한 회고록이다.
데이터에 대한 개념 정리
클라이언트, 서버, DB의 개념
출처 = https://velog.io/@sksgur3217/Interaction-With-Server-02-Server1. 클라이언트(Client)
클라이언트는 영어의 의미 그대로 데이터를 이용하는 고객인 사용자를 말하며 유저가 보는 부분을 담당한다. 좀 더 세부적인 의미의 Client는 데이터를 이용하는 유저가 이용하는 휴대전화, 컴퓨터 등과 같은 매체를 지칭한다. 예를들어 브런치에서 글을 보기 위해 휴대전화의 어플이나 컴퓨터 브라우저를 켜야한다. 이때 클라이언트인 핸드폰의 어플, 컴퓨터 브라우저가 서버에 '브런치 글을 보여달라'고 요청을 하고, 이걸 대신 받아와서 우리에게 보여주는 역할을 하게 되는 것이다. 스타벅스의 예시로 보면 '산미있는 커피를 주세요'라고 요청하는 고객이 바로 클라이언트이다.
2. 서버(Server)
서버는 클라이언트의 요청에 응답을 해주는 프로그램이다. 브런치로 따지면 글과 사진을 저장함과 동시에 글을 꺼내와서 보여주는 역할을 한다. 쉴틈없이 일을 해야 하기 때문에 서버는 24시간 365일 풀가동이 되어야한다. 만약 서버의 전원이 꺼졌는데 그 순간 누군가 브런치 글을 보려고 했다면 작동되지 않는다. 이를 서버가 먹통이 되었다, 서버가 다운되었다, 서버가 죽었다 라고 이야기한다. 스타벅스의 예시에서는 커피를 요청하는 고객과 산미있는 원두 사이에서 열심히 리소스 요청과 응답에 대한 처리를 하는 스타벅스가 서버인 것이다.
3. 데이터베이스(Database)
서비스를 제공하는 회사를 브런치라고 한다면 데이터베이스는 브런치가 갖고 있는 데이터 저장소를 의미한다. 즉, 여러 사람에 의해 공유되어 사용될 목적으로 통합하여 관리되는 데이터의 집합이라고 볼 수 있다. 스타벅스 예시로 보면 리소스가 저장되어 있는 산미있는 원두가 데이터베이스가 된다.
딜리버스 유저 플로우차트
User Flow Chart
이전ver.
데이터의 작동원리를 정확히 알지 못했을 때는 이전에 작성한 유저플로우 차트에서 상당히 많은 부분을 생략했음을 깨달았다.
업그레이드 ver.
유저가 딜리버스 서비스를 사용하면 데이터가 어떻게 작동할지 예측해서 DB와 API등 테크니컬한 부분까지 가능한 상세하게 유저플로우를 작성해보았다. 이전에 간단하게 작성할때는 보이지 않았는데, 상세히 작성하다보니 유저의 행동마다 데이터가 오가면서 앱화면이 유기적으로 실행된다는 사실을 알게 되었다. 물론 겨우 2주동안 개발지식을 공부하고 작성한 현재의 차트도 정답은 아니며 분명히 생략된 부분이 존재할 것이다.
단계별 작동 예측(UI, 클라이언트, 서버, DB)
1. 전체 UI
이전 ver.
이전버전의 유저플로우가 간단하다보니 UI도 일부분만 탐색했었다. 이번에는 업그레이드한 유저플로우에 맞춰서 단계를 나누어 UI를 다시 분석해보았다.
업그레이드 ver.
로그인단계 ▶주소검색단계 ▶ 메뉴탐색단계 ▶ 장바구니 및 결제단계로 나누어, 각 화면에서 유저가 경험할 UI를 분석했다. 스타벅스 앱에서 딜리버스 서비스를 이용하는 유저는 대략적으로 32단계를 거친다는 것을 알 수 있었다. 대략적이라고 표현한 이유는 24-2번에서 메뉴 재탐색이 몇번이나 반복될지 모르기 때문이다.
모든 단계에서 클라이언트, 서버, DB 등 데이터의 흐름을 자세히 살펴보면 좋겠지만 글의 길이가 너무 길어질 것 같아서 "주소검색 단계"만 탐색해보고자 한다.
2. '주소검색' 단계의 클라이언트, 서버, DB
클라이언트
유저가 UI상에서 다음 단계로 나아가기 위해 명령을 내릴 수 있는 모든 데이터는 클라이언트가 처리한다. 따라서 주소검색 단계에서는 [주소검색], [완료], [매장선택하기] CTA 버튼이 클라이언트가 요청할 수 있는 장치이다. 또한 요청한 값을 받아서 유저가 볼 수 있도록 노출한다.
[주소검색] : 입력한 주소지 검색 요청 ▶ 서버에게 전달받은 (경기도~ 이하) 주소지 노출
[완료] : 주소지 선택 완료 후 다음단계 진행 요청 ▶ 서버에게 전달받은 배달 가능 매장 리스트 노출
[매장선택하기] : 매장 선택 후 다음단계 진행 요청 ▶ 서버에게 전달받은 다음 페이지로 이동
서버
클라이언트에게 받은 요청에 답변해주는 역할을 한다. 클라이언트가 CTA버튼을 통해 요청한 값을 서버에서 DB를 통해 응답하여 다음단계로 진행 될 수 있도록 돕는다. 주소를 검색할 때는 주소지와 지도를 쉽게 노출 할 수 있도록 지도 오픈API를 사용한것으로 예측해보았다. API에 관한 자세한 글을 여기에서 볼 수 있다.
[주소검색] ▶ 주소API ▶ DB에서 받은 주소지 전달
[완료] ▶ 입력한 주소지를 바탕으로 DB에서 받은 배달 가능 매장 리스트 전달
[매장선택하기] ▶ 다음단계(메뉴선택) 페이지 전달
DB
서버가 클라이언트에게 요청받은 데이터의 값을 찾을 수 있는 저장소이다. 전국의 주소지, 배달가능한 매장의 목록 등 각종 값이 저장되어 있기 때문에 서버는 DB에서 데이터를 찾아서 클라이언트에게 전달 할 수 있다.
[주소검색 요청시] 검색어에 따른 주소지 리스트
[주소지선택 완료시] 배달 가능 매장 리스트
이전 글에서는 클라이언트에서 요청한 값을 서버에서 모두 수행한다고 뭉뚱그려서 적었는데 2주간 데이터와 개발지식에 대해 공부한 후에는 작동 원리를 조금 더 상세하게 쓸 수 있게 되었다. 이번 글을 쓰기 위해 스타벅스 딜리버스 서비스를 앱에서 작동해보니, 유저로서 이 행동을 하면 클라이언트에 어떻게 전달되고 서버는 어떻게 반응을 하는지 상상해 볼 수 있어서 재밌었다. 앞으로 서비스를 기획하게 될 때 이번에 쌓은 개발지식이 유용하게 쓰일 수 있기를 기대해본다.
문제를 기막히게 해결하는 유익한 기획자.
코드스테이츠 PM 부트캠프로 획기적인 프로덕트 매니저가 되어 가다.
기막힌 생각과 획기적인 방법론자, PM이야기 #18. 끝.
