결론: 사용자가 서버로 보내는 요청은 기존 HTTP API로 처리하고, 서버가 사용자에게 알려 주는 배달 상태와 위치 변화는 SSE(Server-Sent Events, 서버가 사용자에게 실시간으로 정보를 보내는 방식) 로 전달하기로 했습니다.
퀵서비스에서는 주문자(부르미)와 배달원(드리미)에게 다음 정보를 제때 전달해야 합니다.
처음에는 '실시간 정보 전달'이라고 하면 가장 먼저 떠오르는 WebSocket을 검토했습니다.
WebSocket은 서버와 사용자가 하나의 연결을 유지하면서 서로 메시지를 주고받는 방식입니다. 이미 매칭 과정에서도 사용을 고려하고 있었기 때문에, 배송 단계까지 같은 연결을 사용하면 빠르게 구현할 수 있을 것으로 생각했습니다 (실제로는 SSE를 최종 선택했습니다.)
하지만 실제 서비스에서 오가는 정보를 살펴보니, 양쪽이 같은 연결로 계속 대화해야 하는 구조는 아니었습니다.
| 정보가 이동하는 방향 | 전달할 내용 | 적합한 처리 방식 |
|---|---|---|
| 배달원 → 서버 | 현재 위치 전송 | 기존 HTTP 요청 |
| 주문자·배달원 → 서버 | 주문 등록, 수락, 거절, 취소, 상태 변경 | 기존 HTTP API |
| 서버 → 주문자·배달원 | 매칭 및 배달 상태 알림 | 실시간 알림 |
| 서버 → 주문자 | 배달원 위치 변경 알림 | 실시간 알림 |
즉, 사용자가 서버에 보내는 내용은 기존 HTTP API로 충분히 처리할 수 있었습니다. 실시간 연결이 꼭 필요한 부분은 서버가 사용자에게 상태 변화를 알려 주는 방향이었습니다.
또한 배달원은 이동하면서 LTE, 5G, Wi-Fi 사이를 오갈 수 있고, 모바일 브라우저가 백그라운드로 전환될 수도 있습니다. 따라서 실시간 연결은 언제든 끊길 수 있다고 보고 설계해야 했습니다.
(특히 모바일 앱 없이 웹브라우저를 이용한다는 부분이 주요 고려포인트였습니다)
이런 상황을 바탕으로 고민의 기준을 다음과 같이 정리했습니다.
서버와 사용자가 하나의 연결로 계속 메시지를 주고받아야 하는가(양방향), 아니면 서버가 사용자에게 알림을 보내는 단방향 연결이면 충분한가?
배달원의 위치 전송과 사용자의 요청, 서버의 상태 알림을 모두 하나의 WebSocket 연결에서 처리하는 방식입니다.
장점