지도에 없던 상점들

직접 영업한 상점은 주소와 담당자가 등록돼 있습니다. 그런데 배달앱 상점은 주문이 들어올 때 상점 이름과 좌표가 함께 넘어올 뿐, 우리 쪽 목록에는 없습니다.

두 권역에서 배달앱 주문은 전체 주문의 42~45%였습니다. 그런데도 “이 상점들이 어디 몰려 있나”, “어디로 배달 나가는 주문이 힘든가”를 볼 화면이 없었습니다. 라이더 대기 위치나 할증 지역은 경험과 감으로 정해 왔습니다.

상점 목록은 없어도 주문 기록에는 모든 게 남아 있었습니다. 주문 한 건마다 픽업 위치, 도착 위치, 접수·배차·픽업·완료 시각을 꺼내 행정동 경계 위에 올렸습니다. 상점 점 크기는 주문 수, 선은 실제 배송 방향입니다. 고객 주소는 약 45m 격자로 뭉개 개인을 특정할 수 없게 했습니다.

지점 단위로 일주일 부하를 보던 ⑧과 달리, 이 지도는 주문 한 건 한 건의 경로를 하루 단위로 봅니다. 매일 아침 전날 기록이 자동으로 더해집니다.

한 권역에서는 배달앱 상점의 74%가 3개 동에 있었고, 16개 동 중 상점이 있는 곳은 7개뿐이었습니다. 라이더가 기다려야 할 곳은 권역 전체가 아니라 이 몇 개 동이었고, 나머지 동은 “배달만 나가는 곳”이었습니다. 배달이 나가는 쪽 중 멀고 돌아오기 힘든 동이 바로 지연과 거절이 몰리는 곳이었습니다.

거절이 많은 이유가 배달이 멀어서인지, 동선이 안 맞아서인지도 나눠 봤습니다. 제안을 받은 시각에 라이더가 있던 곳(직전 배송지)에서 픽업 상점까지의 거리와, 상점에서 고객까지의 배달 거리를 따로 놓고 거절률을 비교했습니다.

거절은 배달 거리보다 “지금 있는 곳에서 픽업지가 먼가”에 훨씬 크게 반응했습니다. 그렇다면 먼 배달에 할증을 붙이는 것보다 라이더 대기 위치를 상점이 몰린 동으로 옮기거나 같은 방향 주문을 묶는 것이 먼저일 수 있습니다. 실제 GPS가 아니라 직전 배송지로 추정한 값이라, 결론이 아니라 확인해 볼 가설로 둡니다.

지도는 3개 권역 기록을 매일 아침 자동으로 더하고, 같은 파트 팀원들이 사내 계정으로 열어 봅니다. 무엇을 어떤 기준으로 셀지는 제가 정했고, 데이터 추출과 화면 구현은 AI(Claude)와 함께 했습니다.

이 지도를 근거로 한 할증·배치 요청은 아직 정식으로 내지 않았습니다. 거절 이유도 추정이라 몇 주 더 쌓아 같은 경향이 반복되는지 봐야 합니다. 그래서 이 기록도 “문제를 해결했다”가 아니라 “감으로 정하던 것을 근거로 따져볼 수 있게 됐다”로 씁니다.