SIMULATION 한 장 · 배달 라이더 배차
저녁 7시에 시킨 배달은 왜 유독 늦게 올까?
기본 조건(라이더 10명, 3시간 동안 약 139건, 평균 조리 12분)에서 주문부터 도착까지 평균 23.3분이 걸렸고, 16.7%가 30분을 넘겼습니다. 19시 전후에는 배차를 기다리는 주문이 최대 25.6건까지 쌓였습니다.
라이더를 14명으로 늘리면 30분 넘는 주문이 0%로 거의 사라졌습니다. 라이더를 늘리지 않고 조리 시간을 8분으로 줄여도 6.8%까지 내려갑니다. 라이더가 식당에서 음식을 기다리는 시간도 라이더를 묶어 두기 때문입니다.
같은 식당의 가까운 주문을 최대 2건 묶으면 30분 넘는 주문이 11.3%로 줄었지만, 3건까지 묶으면 17.8%로 다시 늘었습니다. 묶음이 길어지면 마지막 집 주문이 늦어지기 때문입니다. 주문이 1.3배가 되면 평균 31분, 30분 초과 47.1%로 급격히 나빠집니다.
무엇을 시뮬레이션하나요?
저녁 7시 무렵 시킨 배달이 평소보다 한참 늦게 오는 경험은 흔합니다. 이 시뮬레이터는 식당 8곳과 주택가가 있는 가상의 동네에서 저녁 17:30~20:30 배달을 재현합니다. 주문은 19시 무렵에 가장 많이 몰리고, 라이더는 식당에 가서 음식을 기다렸다가 받아서 손님에게 갑니다.
주문이 라이더가 처리할 수 있는 양에 가까워지면, 쉬는 라이더가 없어 배차를 기다리는 주문이 쌓이기 시작합니다. 왼쪽 패널에서 라이더 수, 주문량, 묶음 배달, 조리 시간, 이동 속도를 바꿔 어떤 조건이 배달 시간을 가장 크게 줄이는지 비교해 보세요.
시나리오별 결과
| 시나리오 | 평균 배달 시간(주문→도착) | 30분 넘게 걸린 주문 | 느린 10%의 배달 시간 | 배차 대기 주문 최대 | 라이더 가동률 |
|---|---|---|---|---|---|
| 기본 (라이더 10명·단건) | 23.3분 | 16.7% | 31분 | 25.6건 | 86.4% |
| 최대 2건 묶음 | 22.2분 | 11.3% | 29.7분 | 20.2건 | 82.8% |
| 최대 3건 묶음 | 23.7분 | 17.8% | 33.4분 | 18.6건 | 82.1% |
| 라이더 14명 | 18.3분 | 0% | 22.3분 | 16.1건 | 74.9% |
| 조리 시간 8분 | 18.7분 | 6.8% | 26.2분 | 20.6건 | 80.7% |
| 주문 1.3배 | 31분 | 47.1% | 48.1분 | 46.6건 | 92.3% |
각 시나리오를 손님 흐름(난수 시드)만 바꿔 30번씩 돌린 평균입니다. 시나리오 이름을 누르면 같은 조건으로 위 시뮬레이터가 열립니다.
기본 (라이더 10명·단건) · 최대 2건 묶음 · 최대 3건 묶음 · 라이더 14명 · 조리 시간 8분 · 주문 1.3배
어떻게 계산하나요?
2초 단위로 시간을 진행하는 이산 시간 시뮬레이션입니다.
- 동네: 400m 간격 교차로 7×7개로 이루어진 격자 도시입니다. 라이더는 도로를 따라(가로 먼저, 그다음 세로) 움직입니다.
- 주문: 시간에 따라 주문률이 달라지는 포아송 과정이고, 19:00 무렵이 정점입니다. 식당은 8곳 중 무작위, 배달지는 식당에서 400m~2.4km 떨어진 교차로입니다.
- 배차: 주문이 들어오면 쉬고 있는 라이더 중 식당에서 가장 가까운 사람에게 배정합니다. 쉬는 라이더가 없으면 먼저 들어온 주문부터 기다립니다.
- 묶음 배달: 같은 식당 주문이고 배달지가 교차로 3칸(1.2km) 이내면, 아직 음식을 받기 전인 라이더에게 설정한 개수까지 함께 배정합니다. 배달은 가까운 집부터 합니다.
- 조리·전달: 조리 시간은 평균 설정값 기준 삼각분포(0.6배~1.6배)입니다. 음식을 받는 데 1분, 손님에게 건네는 데 1분이 걸립니다.
"배달 시간"은 주문 순간부터 손님 손에 건네질 때까지의 시간입니다. 시뮬레이션이 끝날 무렵 주문은 끝까지 배달되지 않을 수 있어, 마지막 30분 전까지 들어온 주문만 집계합니다. 대기행렬의 기본 관계(리틀의 법칙, 평균 대기 건수 = 도착률 × 평균 체류 시간)에 따라 주문이 몰리면 대기 건수와 배달 시간이 함께 늘어납니다.
이 시뮬레이션의 가정
- 17:30~20:30, 3시간을 시뮬레이션합니다. 화면 1초가 2분 15초입니다.
- 라이더는 주문을 받으면 바로 식당으로 가서 음식이 나올 때까지 기다립니다.
- 라이더는 모두 같은 속도로 움직이고, 배정을 거절하거나 쉬지 않습니다.
- 주문량·조리 시간·동네 크기는 가상의 값이며, 특정 배달 플랫폼의 실제 통계나 배차 알고리즘이 아닙니다.
- 같은 조건이라도 주문이 들어오는 순서가 매번 달라 결과가 조금씩 다르므로, 본문 표는 30번 반복한 평균입니다.
실제와 다를 수 있는 점
- 실제 플랫폼은 조리 완료 예상 시각에 맞춰 늦게 배차하거나, 여러 라이더를 동시에 최적화해 배정합니다. 이 모델의 '가장 가까운 쉬는 라이더' 규칙보다 효율적일 수 있습니다.
- 교통 신호, 엘리베이터, 주차 등으로 실제 배달 시간은 더 길거나 들쭉날쭉할 수 있습니다.
- 날씨, 프로모션, 식당별 주문 쏠림처럼 수요를 크게 흔드는 요인은 반영하지 않았습니다.
자주 묻는 질문
저녁 7시 배달이 유독 늦는 이유는 무엇인가요?
주문이 라이더가 처리할 수 있는 양에 가까워지면 쉬는 라이더가 없어 주문이 배차를 기다립니다. 이 시뮬레이션에서 19시 전후 배차 대기 주문은 최대 25.6건까지 쌓였고, 전체 주문의 16.7%가 30분을 넘겼습니다.
묶음 배달(합배송)은 빠른가요, 느린가요?
적당히 묶으면 빨라지고 많이 묶으면 느려집니다. 최대 2건 묶음에서 30분 넘는 주문은 11.3%로 단건 배달(16.7%)보다 줄었지만, 최대 3건 묶음에서는 17.8%로 다시 늘었습니다. 마지막 집 손님이 앞 집 배달을 기다리기 때문입니다.
라이더를 늘리는 것 말고 방법이 있나요?
식당 조리 시간을 줄이는 것도 효과가 큽니다. 평균 조리 시간을 12분에서 8분으로 줄이면 30분 넘는 주문이 16.7%에서 6.8%로 줄었습니다. 라이더를 14명으로 늘린 경우는 0%였습니다.
이 숫자가 실제 배달 앱 통계인가요?
아닙니다. 가상의 동네와 주문 흐름을 가정해 돌린 시뮬레이션이며, 특정 배달 플랫폼의 실제 데이터나 배차 알고리즘을 반영하지 않습니다. 조건을 바꿨을 때 결과가 어느 방향으로 움직이는지 비교하는 용도입니다.
이 시뮬레이션은 어떤 방법으로 만들었나요?
주문 도착, 라이더 배정, 이동, 조리 대기, 전달을 2초 단위로 계산하는 이산 시간 시뮬레이션입니다. 웹 브라우저에서 바로 돌아가도록 자바스크립트와 three.js로 만들었습니다.
참고 자료
다른 일상 시뮬레이션
마지막 업데이트 2026-10-22 · 만든 곳 데이터팝콘 · 유튜브 @simulation.hanjang · 인스타그램