여러분은 오늘 컨디션을 표현해본다면 어떻게 하시겠어요? 개인마다 답이 다를 수 있죠. 좋다, 나쁘다를 비롯하여 1~100에 대입하여 표현할 수도 있고요. 배달상황도 마찬가지에요. 지금 비가 오는데 배달상황이 어떻지? 이처럼 주관적인 배달상황을 측정 가능한 지표로 새롭게 정의한 "배달 인프라 레벨"구축 경험담을 풀어볼게요😊
늘 그렇듯, 사용자 인터뷰를 시작으로 문제정의 하기
딜리버리서비스팀에서는 배달 도메인을 담당하고 있고, 주 사용자로는 라이더 및 배달상황 운영을 하는 운영자가 있어요. 운영자는 실시간 배달상황을 모니터링하며, 상황이 좋지 않을 때 다양한 설정을 통해 안정적인 상황을 만들기 위해 힘써주고 있어요. 그래야 고객님께 주문하신 음식을 더 빠르게 배달할 수 있거든요.
문제점 1. 모니터링을 위해 운영자가 확인하고 판단해야하는 지표가 많다.
배달상황에 영향을 주는 요소들이 많기 때문에 운영자는 실시간으로 다양한 지표를 파악하고 있었어요. 아래 보이는 8개의 지표를 보고 종합적인 판단을 해야하는데, 특정 몇 개의 지표만 악화되었을 때 전반적인 수준을 운영자 감에 의해 판단해야 했어요. 여러 지표를 적절히 통합하여 객관적으로 해석하기 어려움이 있었던 거죠.
- 주문 건수
- 배차대기 건수
- 평균 배달 소요시간
- 평균 배차 소요시간
- 운행 라이더 수
- 주문취소율
- 배달취소율
- 고객안내시간 준수율
문제점 2. 실시간으로 변하는 지역 상황을 즉각 인지하는 데 한계가 있다.
운영자는 지역마다 빠르게 변하는 상황을 주기적으로 체크하며, 운영하는 전체 지역을 확인해야하는 상황이었어요. 언제 어떻게 바뀔지 모르는데 배달상황이 좋지 않은 경우라면, 안정적인 상황으로 만들기 위한 각종 운영 조치도 이뤄져야 하는데 효율적이지 않은 상황이었죠. [모니터링 > 운영 설정 > 모니터링 > 운영 설정 해제]와 같이 반복적인 업무가 모두 수기로 진행되고 있었어요.
문제점 3. 지표의 기준이 일관되지 않고 상황마다 바뀐다.
또 위 지표들은 외부적인 변수(날씨, 월드컵 등과 같은 주문수 급증)에 따라 달라지는데, 전일/전주 기준으로 비교하므로 조회 시점마다 모니터링 비교군이 다르다 보니, 지표에 대한 정확한 기준이 없어 경험적 기준에 의존하여 실시간 배달상황을 판단하고 있었어요.
본격, 과제 계획을 세워보자
과제 방향 설정하기
사용자 인터뷰를 토대로 정의한 문제의 해결방안을 아래와 같이 정리했어요.
- 배달 인프라 상황을 알수있는 모니터링 지표를 하나로 통일하자!
- 8개의 모니터링 지표를 1개로 만들기
- 인지가 필요한 시점에 운영자에게 정보를 제공하자!
- 주의가 필요하거나, 급격히 악화된 시점으로 알람 제공
- 모니터링 지표를 객관적 기준으로 표현하자!
- 지금 배달상황이 안좋아요(X)
- 지금 안정 단계에요. 위험 단계에요(O)
시시각각 달라지는 배달상황을 측정가능한 지표로!
위 방향을 바탕으로 새로운 지표를 만들게 되었고, 이 지표는 “배달인프라 레벨"로 재탄생했어요. 지역별 주문수 대비 라이더 수가 적정한지를 판단하여, 이를 Level 1~9로 정의했어요. 누가봐도 지금 송파구는 배달인프라 레벨이 2야 = 배달상황이 안정적이구나 또는 지금 송파구는 배달인프라 레벨이 8이야 = 인프라 상황이 심각하구나를 알 수 있죠.
배달인프라 레벨을 만들기 위해서는 현재 레벨을 판단할 수 있는 기반 데이터와 이 데이터로 어떻게 상황을 판단할 것인지 기준을 잡는 게 중요했어요. 레벨별 상황이 의미하는 바는 결국, 우리가 만든 배달 인프라 레벨이 정말 현재의 배달상황을 잘 표현하는가?와 같은 뜻이니까요. 그래서 데이터과학자분들과 함께 협업이 필요했고, 과제 초반부터 PM, 데이터과학자, 개발자가 함께 과제에 참여했어요.
위 일정표를 보면, 데이터 분석과 개발이 병렬로 진행되는데요. [분석 > 개발 > 검증]의 구간을 짧게짧게 계획해서 여러번 다듬어 정확도를 높이려고 했어요. 데이터과학자는 지표 산출 과정 그리고 이 지표와 수식을 계속 보완하며 고도화하는 과정에 많은 시간을 쏟았어요. 개발자는 지표를 만들기 위한 기반 데이터를 쌓아야 했는데 하루 100만건 가량의 주문, 배달과 15만명 가량의 라이더 정보를 실시간으로 시스템 부하 없이 집계하는 부분에 집중했어요. PM인 저는 지표를 활용하게 될 운영자 및 유관부서와 과제방향 및 세부 정책을 맞추고, 로드맵을 세우는 부분에 집중했어요. 배달 인프라 레벨을 구축한 이후 어떻게 활용하는게 좋을지?에 초점을 맞췄죠.
이렇게, 반복되는 검증 과정을 겪고 약 3개월동안 만든 배달 인프라 레벨을 실시간 대시보드와 경고 단계에 있는 지역들을 Slack 알람으로 인지할 수 있는 기능으로 운영자(사용자)에게 오픈하게 됩니다.
오픈 이후 가장 기다렸던건 사용자 피드백이었어요.
운영자가 체감했을 때 우리가 정의한 양호, 주의, 경고, 위험 단계가 실제 배달상황을 잘 대변하고 있는지? 이 지표로 기존 수기 모니터링, 각종 운영설정 등을 판단하기 위해 활용할 수 있는지?가 주요했거든요. 막상 만들었지만, 기존에 판단하고 있던 배달인프라 상황을 실시간으로 반영하지 못하거나 위급하다고 판단했던 상황이 실제 그런 상황이 아닐 수도 있으니까요.
역시 프로덕트를 만들며 가장 짜릿한 순간은 사용자 피드백을 받을 때인 것 같습니다. 잘 활용할 수 있을 것 같단 답변과 함께 인프라레벨 별 운영 정책을 잡아보신다는 답변까지 받게됩니다~ 얼쑤
서비스에 녹아들기, 글을 마치며
배달 인프라 레벨은 기존 모니터링에 투입되는 인원을 최대 5명 → 3명으로, 모니터링에 소요되는 시간을 10분 → 3분으로 단축하는 성과가 있었어요. 모니터링~운영 설정 소요 시간으로 본다면 최대 30분 → 5분 내 설정하여 조치를 빠르게 할 수 있다는 측면에서도 개선효과가 있었죠.
이후 인프라 레벨을 활용하여 수립된 운영 정책 기준에 맞춰 할증, 배달반경 조정 등 수기로 설정했던 기능을 자동화하는 작업이 후속과제로 이루어져 수기업무에 투입되는 시간을 5.6시간(운영시간 대비 약 30%) → 0시간 으로 절감하여 운영 효율을 높이는데 큰 효과가 있었어요. 현재는 특정 배달 인프라 레벨이 되었을 때 고객/업주 대상으로 배달상황을 안내하는 기능도 적용되어 있고요.
그동안 사용자 화면, 기능 등과 같은 눈에 보이는 어떤 결과물을 만들었다면, 배달 인프라 레벨은 운영상황을 판단할 수 있는 기준점을 만들고, 객관적으로 상황을 표현할 수 있는 지표로 새롭게 정의하여 의미 있었던 프로젝트라고 생각해요. 기준점을 만들고 나니 다양한 조직과 배달상황을 이야기할 때 동일한 기준으로 이해하고 소통할 수 있었고, 이 기준점을 토대로 운영 설정 기능, 정책 등에도 활용되고 있어 과제를 시작으로 많은 산출물도 얻었으니까요. 회의 중에 "인프라 레벨 5인 상황에서" 라고 누군가 이야기하면, 가슴이 웅장해집니다 💖
현재의 배달 인프라 레벨은 실시간 배달수, 라이더수를 기반으로 만들어졌지만, 앞으로는 외부 환경 요소(계절, 실시간 날씨, 교통상황 등)에도 더 기민하게 판단하여 고도화할 계획이에요. (배달 인프라 레벨 Ver2 가보자고!!)
비슷한 사례로 고민하시는 분들께 도움이 되길 바라며, 앞으로도 다양한 문제를 해결하며 경험한 내용을 공유 할 날을 기대하며 글 마치도록 하겠습니다.
💌 함께할 동료를 찾습니다! 💌
문앞까지 “배달”되는 과정을 고민하는 딜리버리서비스팀 PM입니다.