by
Jun 25. 2022
배달의민족은 어떤 데이터 플로우를 가질까?
[코드스테이츠 PMB 11] Ep20. Flow Chart
PM이 이해해야 할 데이터 지식의 범주는 어디까지일까.
지난 PMB 과정에서 데이터베이스의 정의와 구성, 데이터 분석의 절차, 관계형 데이터베이스(RDBMS), E-R 다이어그램, 스키마, SQL, NoSQL 등 PM에게 필요한 기초적인 개발 지식의 개념들을 학습하였다. 멀게만 느껴졌던 개발의 세계에 살짝 발을 적신 느낌이랄까..ㅎ
PM으로서 중요한 역량 중 하나로 최근 강조되는 것이 'Data-driven 의사결정을 할 수 있느냐' 이다. 유저들로부터 발생하는 데이터는 우리 서비스가 어느 부분에서 만족스럽고, 부족한지 사용자 후기보다도 더 정확하게 보여주기 때문이다. 데이터에 기반한 사고를 통해 인사이트를 발견하고, 문제를 해결할 수 있는지가 중요한 것이다. PM 직무 또한 더욱 세분화되어 데이터 기반 프로덕트 매니저란 직무도 새롭게 각광받고 있다.
데이터 PM은 데이터 기반 인사이트를 바탕으로 제품 및 기능을 설계하고, 통계 분석을 위한 시각화 도구로 데이터를 시각화하고, 가설 테스트 및 모델링을 통해 변수 간의 고유한 관계를 식별합니다.
DB를 접하는 기획자의 역할데이터 기반 PM의 경우 직접 DB 서버를 설계하거나 DB 프로그래밍을 하는 경우는 사실상 없다. 그러나 데이터에 대한 기본적인 이해는 갖춰야 한다. 기획자는 데이터의 수집범위를 정의하고, 수집한 데이터의 운용 정책을 수립하여 안정적인 서비스를 구축할 수 있어야 한다.
즉, 여러 이해관계자들과의 효과적인 커뮤니케이션을 위해 최소한 개발단의 상황이 어떻게 진행되고 있는지 파악할 수 있을 정도의 개발 지식은 필요하다. 프로덕트를 만드는 과정에서 개발자와 기획자, 디자이너는 서로 다른 역할과 업무에 대한 이해의 부족으로 종종 커뮤니케이션에서 어려움을 겪기도 한다.
여기에서 발생하는 리소스 낭비와 잡음을 줄이기 위해, 우리는 서로의 입장에 대해서 한번쯤 생각해보고 그 간극을 줄여 나가야 한다. PM은 개발팀의 상황에 계속해서 관심을 가지고 서비스의 어떤 데이터들을 서버에서 불러오는지, 어떤 데이터들이 클라이언트에 있는지 구분하여 해당 기능을 구현하는 작업이 요구된다.
PM이 모든 데이터를 분석하고 정리하는 데 한계가 있을 수는 있다. 그러나 프로덕트의 개선을 위한 데이터의 흐름에 대한 이해를 바탕으로, 문제 상황에 따라 어떤 데이터를 적절히 꺼내 읽어야 할지 파악할 정도의 데이터 리터러시*는 갖추고자 노력해야 한다.
*데이터 리터러시(Data Literacy) : 데이터를 읽고 이해하고 분석하며 비판적으로 수용 및 활용할 수 있는 능력
그래서 프로덕트 하나를 선정하여 서비스의 UI와 서버, 데이터의 흐름을 예상하고, 플로우 차트를 그려보고자 한다. 아무래도 초기 프로덕트 보다는 이미 안정적으로 앱이 구축되어 있는 서비스가 분석하기에 용이할 것 같아서 국민 배달 서비스 '배달의민족'으로 정하였다. 더욱이 기술 블로그를 운영하고 있어 데이터 관련 내용을 참고하기에도 좋을 듯 했다.
1. 배달의민족 플로우 차트를 그려보자
최근 배달의민족은 2019년부터 다양한 환경에서 축적해온 서빙로봇 서비스 경험을 토대로 로봇 배달서비스에 집중하는 행보를 보인다.(참고) 오는 8월부터 서울 삼성동 무역센터와 테헤란로 일대에서 로봇 서빙·배달 서비스를 선보일 계획이라고 한다.
우아한형제들은 지난 2월까지 전국 500여곳 외식 매장에 630여대 서빙 로봇을 공급한 바 있다. 배달의민족의 실내외 배달로봇 '딜리 드라이브'를 활용한 실외 D2D 배달 서비스도 선보인다. 딜리 드라이브가 식음료 매장에서 음식을 수령한 뒤 테헤란로의 다른 오피스까지 배달하는 방식이다.
*D2D(Door to door) : 무언가를 팔거나 홍보하기 위해 같은 구역의 집을 각각 방문하는 것, 운전배달 서비스
최근 윤여정 배우가 출연한 tvN 예능 프로그램 '뜻밖의 여정'을 보는데 흥미로운 장면이 나왔다. 미국에서 작고 귀여운 로봇이 도르륵 바퀴를 굴리며 배달에 성공하는 모습이었다. 비록 배달 시간이 좀 오래걸리는 것 같지만 울퉁불퉁 장애물이 있는 도로를 달려 스타벅스 커피를 배달하는 모습을 보니 신기했다. 배달의민족에서 선보이는 실외 배달로봇 서비스도 초기엔 저런 형태를 띠지 않을까. 배달의민족에서 주문을 하면 귀여운 로봇이 집 앞까지 배달해주는 경험을 할 수 있는 때가 얼른 왔으면 좋겠다.
유저 프로세스에 따른 플로우 차트
배달의민족 앱을 다운로드 받은 신규 유저가 하는 행동은 아래 2가지로 구분할 수 있다.
1) 회원가입 및 로그인
2) 배달 주문 및 결제
이 2가지 Flow에 대해 유저 프로세스를 살펴보고 플로우 차트를 그려보자.
1) 회원가입 및 로그인
배달의민족 서비스의 전체 플로우 중 회원가입과 로그인까지의 플로우 차트(Flow Chart)를 그려보았다. 앱 접속 후에 회원 유무에 따라 약관동의 폼과 로그인 폼으로 구분되어 해당 페이지로 이동한다. 순서도는 아래 범례를 참고하여 작성하였는데, 현업에선 기업이나 팀마다 다르게 사용할 것이다.
출처: Axure 프로토타이핑 #8. 플로우차트 설계(by 기획자 데이먼)2) 배달 주문 및 결제
로그인 후 주소가 설정되어 있지 않으면 홈 화면 최상단에 주소 설정 버튼을 선택하면 주소를 설정한다. 이미 주소가 설정되어 있다면 바로 카테고리를 탐색할 수 있다.
상단 메뉴는 배달, 배민1, 포장 등으로 구분되어 있어 해당 카테고리에서 돈까스, 회, 중식 등 음식 카테고리 선택한다. 그리고 주문할 가게 선택, 음식과 수량 선택 후 장바구니 담기, 주문 및 결제로 이어진다.
2. 데이터 흐름을 예측해보자
내 경우엔 한 달에 2~3번 정도 배달의민족을 이용한다. 예전에는 한 주의 스트레스를 풀거나 기분 전환을 위해(..ㅋㅋ) 금요일이나 토요일 저녁에 주로 배달을 시켰었다. 퇴사를 하고부터 최근까지는 먹고 싶은 게 생겼을 때 바로 이용하는 편이다. 나름 배달의민족 충성 고객으로서 사용 플로우가 익숙해서인지 꽤 사용경험이 좋은 프로덕트라 생각한다.
초기 서비스에서 시작하여 거듭된 업데이트를 거쳤을 것이고, 그만큼 매우 방대한 양의 고객 데이터를 분석하고 불편사항은 개선하고 만족스러운 부분은 극대화하려는 노력을 지속해왔을 것이다.
그렇다면 배달의민족은 어떤 데이터 구성을 가지고 작동하며, 어떻게 서비스를 구현할 수 있는지 흐름을 예측해보자.
서버, 클라이언트와 DB
네트워크에서 데이터를 주는 컴퓨터를 서버(Server), 데이터를 요청하고 받는 컴퓨터를 클라이언트(Client)라고 한다. 컴퓨터가 데이터를 주고받는 목적은 특정한 기능, 즉 서비스를 제공하고 사용하기 위한 것이다. 이름 그대로 네트워크로 연결된 컴퓨터 중 서비스를 제공하는 쪽을 서버라 하고 그 서비스를 요청하고 받는 쪽(사용하는 쪽)을 고객 즉, 클라이언트라고 부른다.
네트워크의 서버와 클라이언트클라이언트는 서비스가 필요한 경우 네트워크에 접속해 서버에게 서비스를 요청하고 받으면 되지만, 서버는 언제 어떤 클라이언트가 요청을 해도 서비스를 제공할 수 있게 준비하고 있어야 한다.
따라서 서버는 네트워크 전체를 모니터링하며 클라이언트와의 연결을 관리한다. 이렇게 24시간 내내 네트워크를 관리하며 다수의 클라이언트에게 서비스를 제공해야 하는 서버는 큰 용량을 가진 고성능 컴퓨터인 경우가 많다. 그러나 서버와 클라이언트는 컴퓨터의 성능과 상관없이 그 역할에 따라 구분되는 것이다.
한 대의 서버에 다수의 클라이언트가 접속하여 서비스를 이용할 수 있는 방식을 서버 클라이언트 구조라고 한다. 서버 클라이언트 구조 방식은 다수의 사용자들이 공동으로 사용하는 데이터를 서버라는 중앙 컴퓨터에 저장하고 관리함으로써 수많은 클라이언트의 동시적인 요구를 효율적으로 처리할 수 있다.
배달의민족 '오프라인 모드' 기능으로 알아보는 데이터 구조
배달의민족의 데이터 구조를 쉽게 이해할 수 있는 자료가 없을까 여기저기 찾아보다 우아한형제들 기술블로그에서 '오프라인 모드' 기능에 대하여 소개한 글(참고)을 보았다.
배달의민족 앱에 적용되어 있는 '오프라인 모드'라는 기능을 설명하면서 User와 App, 서버 API의 상호작용을 대략적으로나마 파악할 수 있는 자료로 보였다. 모든 내용을 다 이해하기엔 무리가 있었지만 기본 동작 로직의 다이어그램을 이해할 수 있을 것 같았다..!
1) 오프라인 모드란?
'오프라인 모드' 기능이란 배달의민족 앱을 서버 응답이 없는 상황에서도 사용할 수 있게 만든 기능이다. Google Map, Youtube 같은 여타 다른 앱에서도 구현되어 있는 기능으로, 일반적으로는 해외에 나가거나 장시간 네트워크 없이 활동하는 순간에 앱을 이용할 수 있게 만들어주는 기능이다.
2) 기능의 목적
서비스를 운영하다 보면 부득이하게 장애라는 상황을 맞이하게 된다. 장애라는 불청객을 조금이라도 준비하고 맞이하기 위해서 "오프라인 모드"를 개발하였다. 서버의 응답이 없어도 가장 최근에 서버로부터 받아온 데이터를 기반으로 화면을 구성하여 사용자로 하여금 최소한의 기능을 사용할 수 있도록 하는데 목적이 있다.
3) 기본 동작 로직
오프라인 모드의 기본 동작User가 App(클라이언트)에 화면을 요청하면 App은 Server API에 데이터를 요청한다. 일차적으로 정상적인 API* 응답을 앱 클라이언트 내부에 저장한다. 그리고 Server에서는 다시 App에 응답하고, App에서 User에게 화면을 보여준다.
*API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스) : 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
API 응답이 비정상적으로 오는 경우API 응답이 비정상적으로 오는 경우에는 잠시 시스템의 지연을 허용하고 저장된 API 응답을 이용하여 화면에 출력하는 기능이다.
Local Cache(로컬 캐시)는 네트워크를 통해 파일의 일부를 한 번 읽은 다음 이 로컬 캐시에 보관하여 네트워크 트래픽을 줄이는 데 도움을 준다. 간단한 기능이지만 크고 작은 장애 상황에서 큰 역할을 해준다.
서버의 응답이 없는 경우에도 가장 최근에 서버로부터 받은 데이터를 기반으로 화면을 구성하는 과정에서 User와 App, Server API 사이의 상호작용을 보여준 것으로 이해된다. 적어도 이 셋의 관계는 긴밀히 연결되어 있으며 API는 컴퓨터나 소프트웨어를 서로 연결하는 매개체로의 역할을 하는 것을 알 수 있었다.
여담으로 기술블로그에 사례를 공유한 글쓴이의 마무리 멘트가 인상적이어서 인용해 보았다..!
해당 기능이 기술적으로 뛰어나고 혁신적인 기능은 아니지만, 서버에서 발생할 수 있는 장애를 대비하는 역할이 비단 서버개발자만의 역할이 아니라 클라이언트 개발자들도 충분히 작업하여 대비할 수 있음을 보여주는 단적인 사례라고 생각되어 공유합니다.
우리 모두 장애 없는 세상을 이루어내어 크게는 인류 공영에 이바지하고 작게는 동료들의 숙면을 보장할 수 있는 세상이 왔으면 하는 아주 작은 소망을 내비치며 글을 마무리하고자 합니다.
