이 문서는 냉삼퀵의 부르미-드리미 매칭이 무엇을 보장하고, 현재 코드에서 어떻게 동작하며, 앞으로 어떤 방향으로 확장할지를 한곳에 정리한 기준 문서다.
기준 구현: backend/src/main/java/com/naengsam/quick/domain/matching
마지막 수정: 08/18 (화)
이 서비스에서는 사용자가 직접 드리미를 선택하는 방식보다, 서버가 적절한 후보를 제안하는 매칭 방식이 더 적합하다고 판단했다.
선택 자체가 사용자에게 인지 부하가 될 수 있기 때문이다. 사용자가 여러 드리미의 거리, 대기 시간, 응답 가능성 등을 직접 비교하게 만들면 서비스 이용 흐름이 길어진다. 반면 서버는 주문 위치, 드리미 위치, 대기 시간, 응답 이력 같은 정보를 더 잘 알고 있으므로, 이를 기반으로 적절한 후보를 먼저 제안하는 방식이 더 자연스럽다고 보았다.
수요와 공급의 불균형에 대응하기 쉽기 때문이다. 특정 주문에 드리미가 몰리거나, 반대로 특정 주문이 계속 선택되지 않는 상황이 생길 수 있다. 서버 매칭 구조를 사용하면 거리뿐 아니라 주문 대기 시간, 드리미 대기 시간, 후보 수 같은 요소를 정책에 반영하여 오퍼를 더 균형 있게 분배할 수 있다.
초기 기획에서 콜을 빠르게 잡는 게임적인 경험을 고려했기 때문이다. 사용자가 실시간으로 오퍼를 받고, 수락하거나 거절하고, 다시 매칭되는 흐름이 서비스의 핵심 경험이 될 수 있다고 판단했다.
매칭 구조가 실시간성을 가장 잘 보여줄 수 있는 구조라고 생각했다. 단순 목록 조회나 수동 선택보다, 주문과 드리미가 실시간으로 들어오고 나가며 오퍼가 생성되고 만료되는 흐름이 SSE, 상태 전이, 배치 매칭 같은 기술적 요소를 잘 드러낼 수 있다고 보았다.
물론 구현 과정에서 이 구조가 쉽지만은 않다는 점도 알게 되었다. 사용자가 직접 선택할 수 있는 일을 서버가 대신 처리하면, 그만큼의 복잡도와 책임은 개발자가 부담하게 된다. 특히 오퍼 상태, 만료, 수락 경쟁, 재매칭, 서버 재시작 복구 같은 문제를 고려해야 했고, 이를 통해 자동 매칭은 단순한 편의 기능이 아니라 상태 정합성을 계속 관리해야 하는 구조라는 점을 배웠다.
부르미가 배송을 요청하면 시스템은 다음 배치에서 매칭 가능한 드리미를 찾고 여러 명에게 동시에 제안한다. 드리미 한 명이 먼저 수락하면 같은 주문의 나머지 제안은 회수한다. 이후 부르미가 해당 드리미를 최종 승인하면 매칭이 확정되고 배달이 시작된다.
드리미 또는 부르미가 거절하거나 30초 안에 응답하지 않으면 해당 제안은 종료된다. 주문은 다시 대기 상태로 돌아가며 다음 배치에서 새 후보를 평가한다.
flowchart LR
A["부르미 배송 요청"] --> B["주문 매칭 대기"]
B --> C["주기적 배치 후보 평가"]
C --> D["드리미에게 동시 제안"]
D --> E{"드리미 수락?"}
E -- "거절·만료" --> B
E -- "예" --> F["나머지 제안 회수"]
F --> G{"부르미 최종 승인?"}
G -- "거절·만료" --> B
G -- "예" --> H["매칭 확정 및 배달 시작"]
핵심 규칙은 다음과 같다.