[배송 권역 시스템 4편] 새벽 배송 알림 설계 — 기사 위치를 직접 노출하지 않는 이유

음식 배달 앱처럼 기사 위치를 실시간으로 보여주면 되지 않을까?

 

새벽 배송에서는 그렇지 않다. 사용자 압박으로 인한 CS 폭주, 새벽 시간대의 안전 이슈, 기사 개인 위치 정보의 민감성. 이 세 가지가 위치 직접 노출을 어렵게 한다.

 

그래서 이 프로젝트에서는 위치 좌표 대신 "원 영역"으로 추정 영역만 표시하고, AND 조건 트리거로 false positive 를 차단했다.사용자는 "곧 도착" 신호만 받고, 기사는 본인 좌표 노출 없이 동선 자유도를 유지한다.

요약

• 음식 배달 앱은 사용자가 "조금만 더 빨리" 욕구가 강해도 동선 변경 여지가 적다 (식어버리는 음식 + 짧은 거리). 새벽 배송은 다르다.
• 새벽 배송에서 기사 위치를 직접 노출하면 (1) 사용자 압박 CS, (2) 새벽 시간대 안전, (3) 기사 개인 정보 세 가지 문제가 동시에 발생한다.
• 대안으로 설계한 구조: AND 조건 트리거 (sequence gap + 거리 임계값) + 원 영역 표시 (정확한 좌표 X) + dedup (한 번 알린 건 재발송 X).
• 결과: 사용자는 러프하게 "내 차례가 오는구나" 인지, 기사는 본인 위치 노출 없이 동선 자유도 유지, 운영은 CS / 안전 이슈 회피.

1. 시작 — 사용자 입장의 원시적 욕구

평소 문전 수거 서비스를 자주 쓴다. 새벽 배송도 마찬가지다. 사용하면서 가장 자주 드는 생각이 있다.

"기사님이 올 때에 맞춰서 미리 내놓고 싶다."

 

이유는 단순하다.

• 이웃 민원: 새벽에 문 앞에 물건이 오래 쌓여 있으면 옆집 / 윗집 시선이 부담스럽다.
• 도난 우려: 새벽 시간대 외부 노출은 도난 위험이 있다.
• 공간 제약: 좁은 복도형 아파트는 물건 두는 자리 자체가 애매하다.

이걸 시스템으로 어떻게 지원할까 고민했고, 가장 단순한 해답은 음식 배달 앱처럼 기사 위치를 실시간으로 보여주는 거였다.

2. 그런데 음식 배달 방식을 그대로 가져오면 문제가 생긴다

기획을 하면서 다양한 측면을 검토해보니 그렇지 않았다. 세 가지 문제가 있었다.

2-1. 사용자 압박 → CS 폭주

음식 배달은 메뉴와 배달 시간 자체가 짧다 (30분 ~ 1시간). 음식이 식기 전에 도착해야 한다는 명확한 시간 제약이 있어 사용자도 결과를 기다리는 인내심이 자연스럽게 형성된다. 하지만 새벽 배송은 다르다.

• 한 기사가 약 60 ~ 100건을 처리할 수 있다.
• "내 차례 빨리" 라는 욕구가 더 강하게 발현된다 (잠을 자야 하는 시간대).
• 위치가 가까이 보이는데 안 오면 곧장 항의 전화로 이어질 수 있다.

이게 운영 측면에서 곧바로 CS 폭주로 직결된다. 한 명의 기사가 80 명의 고객을 책임지는데, 각 고객이 위치 보고 압박하면 기사는 정상 동선을 탈 수 없게 된다.

2-2. 새벽 시간대의 안전 이슈

새벽 배송은 일반적인 도로 상황과 다르다.

• 도로의 교통량: 새벽 시간대는 교통량이 적어 기사의 이동 패턴이 비정형적으로 변할 수 있다
• 단지 내 접근: 아파트 진입로, 골목길, 좁은 도로 등 차량 통행이 자유롭지 않은 구간이 많다
• 연속 단지 이동: 물류 거점에서 여러 단지를 연이어 방문하는 동선 특성상, 최적 경로가 수시로 바뀐다

기사 입장에서 본인 위치가 사용자에게 그대로 노출되면 동선 선택의 자유도가 사라진다. "이 길로 가려고 했는데 사용자가 지켜보고 있어 우회할 수 없다"는 압박. 새벽 시간대의 비정형 도로 환경에서는 이런 압박이 운영 효율을 크게 떨어뜨린다.

2-3. 개인 위치 정보의 민감성

수행하는 업무 중 정확한 좌표가 60~80 명의 고객에게 실시간으로 노출되는 건 받아들이기 어렵다. 특히 새벽 시간대의 본인 위치 좌표 라는 정보는 일반적인 위치 정보보다 더 민감하다. 운영 정책 차원에서도 "기사 위치를 사용자에게 그대로 노출" 은 가능한 회피하는 방향이 맞다고 생각한다.

3. 그래서 설계한 구조 — AND 조건 + 원 영역

위 세 가지 문제를 해결하면서 사용자의 "곧 내놓고 싶다" 욕구는 만족시키는 게 목표였다. 설계는 두 축으로 갔다.

3-1. 알림 트리거 — AND 조건

조건 A: 기사가 지금 향하는 방문 순서가 사용자의 배송 순서로부터 N 건 이내 (sequence gap) 조건 B: 기사가 사용자 좌표로부터 일정 반경 안에 진입 (거리 임계값) 둘 다 만족할 때만 알림을 보낸다. 한 번 알린 건은 dedup 으로 재발송 차단.

 

왜 AND 조건인가.

 

OR 또는 단일 조건의 false positive 를 차단하기 위해서다.

 

조건	단독 사용 시 false positive
sequence gap 만	다음 5건 안에 들지만 거리는 멀어서 사용자에게 가짜 알림
거리 임계값 만	차로 지나가는 먼 sequence 의 사용자에게 알림 (실제로는 한참 후 도착)
AND	둘 다 만족 시에만 → false positive 거의 없음

 

 

이 AND 조건이 알림의 정확도를 결정한다. sequence 기반 알림 시스템에서 흔히 거리 조건을 빼는 경우가 있는데, 이러면 "이 사용자는 다음 5번째인데 기사는 지금 5km 떨어진 다른 동에 있다" 같은 케이스에서 알림이 잘못 간다.

3-2. 화면 표시 — 정확한 좌표 X, 원 영역만

알림이 발송되면 사용자 앱에 "곧 도착" 표시가 뜨고, 화면에는 다음이 그려진다.

• 사용자 자신의 위치 (마커)
• 사용자 주변의 원 (반경 약 100m)
• "기사가 이 영역 안에 있을 수 있어요" 라는 안내

기사의 정확한 좌표는 화면에 표시되지 않는다. 사용자는 "내 주변 어딘가" 정도만 안다. 원 반경은 100m 로 정했다. 도시 1 블록 정도의 거리라 사용자 준비 시간 1~2 분이 자연스럽게 확보되고, 50m 처럼 짧으면 준비 시간이 부족하고, 200m 처럼 너무 크면 false positive (도로 건너편 다른 동)가 늘어난다.

4. 작은 디테일 — 한 번 알리면 다시 안 알린다

알림 dedup 은 운영 안정성에 의외로 큰 영향을 준다.

 

기사가 같은 사용자의 200m → 100m → 다시 150m 로 멀어졌다가 다시 100m 로 가까워지는 케이스가 있다. (예: 단지 안에서 다른 동을 먼저 들렀다 오는 경우, 또는 단지 입구 - 단지 안 - 단지 입구 - 다른 단지로 이동하는 경우.) 이 경우 거리 조건이 여러 번 트리거된다. dedup 없으면 같은 사용자에게 알림이 2~3 번 간다 → 사용자 혼란.

 

해결: 한 번 알림 보낸 deliveryId는 캐시에 기록해 재발송 차단. 캐시는 Redis에 보관되고, 배송 완료 시 정리된다.

 

이런 디테일이 시스템의 사용자 경험을 결정한다. 알고리즘 우수성이 아니라 "한 번만 알리는" 작은 디자인이 결과적으로 더 큰 가치다.

5. 사용자 가치와 기사 가치 모두 충족

이 설계가 만들어낸 가치를 정리하면 다음과 같다.

 

사용자 가치:

• 러프하게 "내 차례가 오는구나" 인지 가능
• 미리 내놓을 수 있어 이웃 민원 / 도난 / 공간 부담 회피
• 기사 압박 동기 약화 (정확한 위치를 모르니 "왜 안 와요" 전화 걸 정보가 없음)

기사 가치:

• 본인 위치 좌표 노출 X
• 동선 자유도 유지 (시스템 추천 5,6,7 순서를 6,7,5 로 바꿔도 사용자는 "근처 진입" 만 알기 때문에 ETA 영향 없음)
• 새벽 시간대 변칙 동선의 허용

운영 가치:

• 사용자 압박으로 인한 CS 회피
• 새벽 안전 이슈 회피
• 위치 정보 민감성 정책 준수

도메인을 제대로 이해하지 못하면 흔히 '실시간 위치 노출'에서 판단을 멈추기 쉽다. 사용자로서 새벽 배송과 음식 배달의 차이를 직접 경험해보지 않았다면 못 했을 결정이다.

6. 회고 — 도메인 이해는 사용자 경험에서 시작된다

이 설계를 하면서 가장 강하게 느낀 건, 알고리즘이나 코드 이전에 도메인 이해가 더 중요하다는 점이다.

 

알고리즘적으로는 "위치를 실시간 발행" 이 더 단순하다. 그냥 SSE / WebSocket 으로 좌표를 푸시하면 된다. 그런데 도메인이 다르면 같은 기술 결정이 정반대 결과를 낸다.

 

음식 배달 ≠ 새벽 배송. 같은 "배달" 이라는 단어로 묶이지만 사용자 행동, 기사 동선, 시간대 특성, 위치 노출의 무게가 모두 다르다. 이 차이를 코드 작성 전에 인지하고 설계에 반영하는 게 서비스의 품질을 결정한다.

 

도메인 이해는 책에서 오지 않는다. 직접 써본 경험이 없다면 도달하기 어려운 인사이트였고, 그 경험이 설계에 자연스럽게 녹아들었다.

 

실제 동작 화면

아래 영상은 실제 시뮬레이션 화면을 녹화한 것이다. 실제 GPS 데이터를 기반으로 시뮬레이션하는 것이 아니기 때문에 기사님의 마커 움직임이 실제와는 다를 수 있다.