07 30

📄 원본(노션): https://app.notion.com/p/3ad19935b8ae8034b2a3e467cd2b565e — 최종 동기화 2026-07-30

07-30 (2주차 목)

• 회의 날짜: 2026-07-30
• 점심: 맥도날드

---

아침 스크럼

• 현성
  • 따로 X
• 석희
  • 인증 번호 멱등성 처리 관련 코드 수정
  • LoginRequired annotation 바꿈.

오늘 스케줄

• 현성
  1. 동혁님 매칭엔진 참고해서 배달도 그렇게 만들고 ⇒ PR
  2. DB 관련 연결 (매칭과 배달이랑 관련있는 DB 실제)
• 석희
  • ci에 workflow test code - API key test들이 다 같이 돌아가서 실패하는 중.
    • tag external을 통한 선택적 테스트 공부하기
  • 동혁과 매칭 websocket 연결 고려
• 동혁
  • domain 분리 discussion 스크럼 끝나고 이야기 하기.
    • 이걸 기반으로 새로운 issue 하나 만들기.
  • 석희님과 오전에 이야기 해보기
  • 내일 시연에 보여줄게 있도록 하는 것을 목표
• 현서
  • S3 putobject권한이 없다는 것을 확인.
  • 다시 presigned url로 요청 보내보고 실패하면 권한 요청하기
  • Issue #46 완성.

---

논의 - 요금 책정을 어떻게 해야하는 것인가?

도보 배달은 단순 이동 거리 외에 픽업 대기, 엘리베이터 이동, 수령 확인 등 고정 소요 시간(건당 약 8~10분)이 반드시 발생합니다. (보행 속도 평균 4km/h 기준)

• 500m 이동 (소요시간 약 15~18분)
  • 요금: 3,000원
  • 환산 시급: 약 10,000원~12,000원 (합리적)
• 1km 이동 (소요시간 약 23~25분)
  • 요금: 3,000원 + 500원 = 3,500원 (또는 4,000원)
  • 환산 시급: 약 8,500원~9,000원 (최저임금 하회 가능성)
• 1.5km 이동 (소요시간 약 32~35분)
  • 요금: 3,000원 + 1,000원 = 4,000원
  • 환산 시급: 약 6,800원~7,500원 (라이더 배차 거절 확률 극대화)

저녁 회고

• 석희

  • cloudfront 에 프론트 배포 근데 배포 자동화가 안되어 있음 → role 추가해서 내일 고쳐보기

  • sse 기본 global 세팅

  • 부르미 요금 거리 계산하는 api 추가

    • 못한것
    • mysql 설정 찾아보기 실패 JPA 문제였던거 같음
    • 문서화 하는거 실패 (웹소켓 vs SSE 에 대해 매칭로직과 관련해 선택 결과)
    논의 내용

    1. WebSocket을 사용한다면 개인 채널 위주로 구성하는 것이 적절

    현재 매칭 시스템에서 실시간으로 전달되는 이벤트는 대부분 특정 사용자만 받아야 하는 정보이다.

    예시

    • 드리미에게 매칭 제안
    • 부르미에게 드리미 수락 알림
    • 선점 실패한 드리미에게 팝업 종료
    • 매칭 실패/재매칭 알림

    따라서 모든 사용자가 하나의 공용 Topic을 구독하는 구조보다는 사용자별(또는 필요 시 주문별) 채널을 사용하는 것이 적합하다고 생각한다.

    공용 Topic을 사용할 경우

    • 모든 클라이언트가 불필요한 메시지를 수신
    • 클라이언트에서 추가 필터링 필요
    • 다른 주문 정보가 클라이언트까지 전달될 가능성 존재 이것 자체도 서버가 다 줘야하는 정보임.

    반면 개인 채널을 사용하면

    • 필요한 사용자에게만 이벤트 전달
    • 보안 측면에서도 안전
    • 클라이언트 구현이 단순

    또한 "방을 여러 개 관리하면 서버 부담이 커지지 않을까?"라는 우려는 크지 않을 것으로 보인다. 어차피 서버는 사용자 또는 세션을 관리하기 위한 내부 Map(Session, User Destination 등)을 유지해야 하며, 특정 사용자에게 메시지를 전달하기 위한 조회는 공용 Topic 구조에서도 동일하게 필요하기 때문이다.

    ---

    2. WebSocket 대신 HTTP + SSE도 충분히 가능해 보임

    현재 시스템에서 클라이언트가 서버로 보내는 입력은 모두 단발성 명령이다.

    • queue
    • dequeue
    • accept
    • reject

    반대로 서버는 처리 결과만 사용자에게 알려주면 된다.

    • MATCHING_STARTED
    • OFFER_CREATED
    • MATCHED
    • OFFER_WITHDRAWN
    • MATCHING_FAILED

    즉 통신 구조는

    Client → Server : HTTP POST
    Server → Client : SSE
    

    만으로도 충분히 구현 가능해 보인다. HTTP는 명령을 전달하고, Action Queue에서 순차 처리한 결과를 SSE를 통해 사용자에게 실시간으로 전달하면 된다.

    이 방식은

    • REST API 활용 가능
    • Swagger 테스트 용이
    • 구현 단순
    • 양방향 WebSocket이 꼭 필요하지 않은 현재 요구사항과 잘 맞음

    이라는 장점이 있다.

    ---

    결론

    • WebSocket을 사용할 경우에는 공용 Topic보다는 개인 채널(User Destination) 중심의 구조가 적절하다고 생각한다.
    • 기술 선택을 다시 검토할 수 있다면, 현재 요구사항은 HTTP + SSE만으로도 충분히 구현 가능해 보인다. 클라이언트는 명령만 보내고 서버가 결과를 푸시하는 구조이기 때문에, 양방향 통신이 필요한 상황은 많지 않다.

    추가로

    Action의 정의

    • 드리미가 대기중이다
    • 부르미가 주문을 등록했다
    • 부르미 요청을 재주문한다

    BlockingQueue<Action> queue

    Action을 큐에 집어넣음. 이거 쓰는 이유는 thread safe를 위해서. 한 thread에 있는 큐에 Action들 넣는 것. queue에서 한 Action이 수행 완료되면 다음 상태를 queue에 집어넣음. 기다리고 있는 드리미나 하나의 주문에 대해 동시에 뿌린 제안 묶음 등은 map(방)으로 관리함.

    드리미들에게 주문 뿌려주는 방식

    일정한 반경내에 있는 드리미들에게 뿌려줌. 미리 설정해둔 인원수, 예를 들어 10명의 드리미들에게 뿌림. 이 10명이 모두 매칭 거절하면 해당 부르미의 주문을 다시 재주문 Action으로 queue에 집어넣음. 미리 설정한 인원수에게만 뿌리기 때문에 반경내의 새로운 드리미를 찾아서 계속 보여줄 필요가 없음.

    그럼 WebSocket vs SSE?

    새로운 드리미를 계속해서 가져오는 것이 아니라 일정한 인원수의 드리미들에게 뿌리고, 이들이 모두 거절한다면 새로운 요청을 큐에 집어넣는 방식이기 때문에 완벽한 실시간성이 필요없음.

  • 내일 할것

    • 부르미 도메인 작업
    • mysql 설정
    • 1일 1배포 가능하도록 사전 설정
• 현서
  • S3 presigned url 용도의 권한 찾기가 너무 시간 오래걸림
  • DreamiAuthController → UploadController로 책임 이동
  • 실제로 s3에 업로드 되는지 테스트
  • 내일 할 것
    • 드리미 도메인
• 동혁

  • main에다가 pr남겨서 빨리 해달라고 재촉해서 다른분들이 merge해버려서 revert 삽질함 열심히 방법 찾고 있었는데 merge하신 현성님이 revert 버튼 딸깍으로 해결해주심

  • 매칭 전반부 로직 코드로 구현

    🖼️ (이미지: 매칭 로직 구조 다이어그램 — 원본 노션 페이지에서 확인)

  • 코드 짜면서 테스트도 계속 만들면서 확인 해서 배포

    • 석희님께서 제가 만든 api 기반으로 sse로 당겨와서 내일 시연할 수 있도록 만들어주심

  • 구조 사진 위키에 올렸음.

  • 매칭 로직 웹 소켓이 아닌 SSE로 하는 것으로 결정

  • 마지막 한 시간동안 PR 섞여서 Order, Orders merge 꼬인거 푸느라 삽질함

  • 못한것: Cancel은 만들었는데 html에 연결 못했음. 집가서 해야 함.

  • 내일 할 것

    • 시연 대비하기
• 현성
  • Delivery 로직 거의 완성
    • 픽업 사진 인증 + 배달 완료 인증 하는 부분은 일단 넘김
  • SSE 구현해놓으신거 pull 해서 배달 로직에 SSE 적용했는데 코드는 못보고 클로드 믿고 있습니다. 내일 분석 할 예정
  • 내일 시연
  • 내일 할일
    • 기능 추가나 코드 수정은 거의 안할듯
    • 오늘 내가 만든 코드 중에서 분석 안한 부분이랑 + SSE 코드 로직 및 원리 분석

논의 - 드리미 응답도 SSE로 하자