08 12

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

08-12 (4주차 수)

회의 날짜: 2026-08-12

---

아침 스크럼

• 석희
  • 어제 매칭 테스트를 하다 매칭 로직자체에 특이한 점을 발견함
  • *오더 요청은 부르미수와 같음
  • *매칭락수는 한 offer요청이 한번에 부르는 드리미 수(기본값 = 3)
  • *주문등록→드리미에게 첫 Offer 제출은 클라이언트가 드리미가 첫 요청을 받을때까지의 지연

case	부르미	드리미	동시요청	매칭 락 수	주문등록→드리미에게 첫 Offer 제출 p99
1	1000	1000	100	3	96896ms
2	500	500	100	3	64236ms
3	250	250	20	3	43600ms
4	250	250	10	3	40000ms
5	250	250	10	15	148523ms
6	250	250	10	1	2132ms
7	250	750	10	3	2045ms

• case1,2) 테스트 서버 환경의 tomcat thread 및 DB 커넥션 수를 인지하지 못한 상태로 동시 요청 수를 과하게 잡아 실제로 api 요청 자체에 지연이 발생했다.

  (이미지 3장 — 부하 테스트 그래프. 노션 서명 URL이 만료되어 위키로 옮길 수 없음, 노션 원본에서 확인)

  이 케이스에서는 서버 환경을 고려하지 않은 부하 테스트로 동시요청에 커넥션수를 튜닝하지 않아 감당하지 못하고 timeout 이 발생했음을 확인할 수 있었다.

• case 3,4,5) 이번 테스트에서는 동시요청수를 낮추고 실제 요청 지연에 대해서 테스를 하기 위해 정리했다. 본 지표에서 p99 ~=40s 라는 경우는 부르미가 콜을 등록하고 어떤 드리미에게 요청이 처음으로 가기까지 40초 이상이걸렸다는 상황이다. 실제로는 부르미수 = 드리미 수 이기때문에 매칭으로 요청 자체가 막혔다는 것은 앞선 부르미들이 모든 드리미를 점유하고 있다는 상황이다. 이는 매칭 락 수 15로 올렸을때 급격히 상승한 상황에서 확인 할 수 있었다.

• case 6,7) 이 부분에서 매칭 로직 알고리즘의 허점을 발견하였다. 앞선 case 3,4,5에서 발견한 상황의 경으 매칭이 닫히는 경우 자체가 존재하므로 인당 최대 1건의 offer만 점유 가능하다면 알림 대기시간이 줄어들것이라고 예상하여 실제로 동시 offer수를 1명으로 제한 하니 batch 시간 2초를 제외하면 거의 바로 모든 건에 대해 매칭이 되었음을 확인하고 이를 부르미 : 드리미 = 1 : 3으로 테스트했을때 동일한 결과를 얻어 가설이 맞았음을 확인 할 수 있었다.

• result _) 매칭 부하테스트는 동시에 모든 부르미, 드리미가 콜을 등록하는 경우를 가정하였다. 그럼에도 부르미,드리미를 각각 250명씩 매칭했을때 최대 2분을 기다리게 한다는것은 매칭 알고리즘을 넘어서 구조적 문제임을 확인했다. 따라서 부르미, 드리미 수에 따라 동적으로 매칭 offer 제한을 수정하는 동적 매칭 구조가 필요함을 확인 할 수 있었다.

유실 = "와야 할 SSE가 제한 시간 안에 안 온 건" (summary.missing, 리포트 6절). HTTP 실패가 아니라 알림 누락이다.

판정 규칙

ledger.mjs:256 — 기준 시각(since)부터 제한 시간이 지났는데 이벤트가 없으면 유실, 아직 안 지났으면 pending(판정보류).

if (finishedAt - since >= limit) missing.push(item);
else pending.push({ ...item, waitedMs, limitMs });

5종

stage: 오퍼_미발송
기준점: 주문 생성
기다린 이벤트: 아무 드리미에게 offer_popup
제한: T_OFFER 15s
────────────────────────────────────────
stage: dreami_info_유실
기준점: 첫 수락 제출
기다린 이벤트: 부르미에게 dreami_info
제한: T_INFO 10s
────────────────────────────────────────
stage: offer_closed_유실
기준점: dreami_info 도착
기다린 이벤트: 패배 드리미에게 offer_closed
제한: T_CLOSED 10s
────────────────────────────────────────
stage: 만료알림_유실
기준점: offer_popup
기다린 이벤트: 무응답 오퍼 TTL 30초 만료 offer_closed
제한: T_EXPIRE 45s
────────────────────────────────────────
stage: delivery_started_{dreami,boormi}_유실
기준점: 확정 200
기다린 이벤트: 배달 시작 SSE 양쪽
제한: T_DELIVERY 10s

전부 config/env.example에서 조절 가능.

• 동혁

  PR 2개를 올림

  • 오퍼 팝업 mock → 실제 데이터로 바꿈
  • 드리미가 주문 끝나고 다시 들어가려고 할 때 온라인 전환시 오류 수정
    • 배달을 연속으로 할 수 있음 (5번까지 테스트 해 봄)
  • 어제 현성 말씀해주신 엔진/스케줄러 단일화 진행중. + DB/인메모리 상태 이상한거 고치기 도전

• 현서

  • 배달 완료 데이터 실제 데이터로 대입
    • claude 버그 수정
  • 레이스 컨디션 → 비관적 락 + 조건문

• 현성

오늘 수정 된 DDL

-- 포인트 transaction enum 변화
ALTER TABLE POINT_TX
  MODIFY `status` enum('PENDING', 'PAID', 'REFUNDED_PARTIAL', 'REFUNDED_FULL') NOT NULL;

-- delivery column 추가
ALTER TABLE `DELIVERY` ADD COLUMN `last_location_dtm` timestamp NULL COMMENT '드리미가 마지막으로 위치를 전송한 시각(GPS 끊김 판정용)';

CREATE TABLE `PUSH_SUBSCRIPTION` (
                                     `push_subscription_id`  binary(16)    NOT NULL,
                                     `boormi_id`             binary(16)    NOT NULL,
                                     `endpoint`              varchar(512)  NOT NULL  COMMENT 'push 서비스 엔드포인트 URL. 브라우저·기기·SW 조합마다 유일하므로 이것이 기기 식별자다',
                                     `p256dh`                varchar(255)  NOT NULL  COMMENT '클라이언트 공개키(base64url)',
                                     `auth`                  varchar(255)  NOT NULL  COMMENT '클라이언트 인증 시크릿(base64url)',
                                     `user_agent`            varchar(255)  NULL      COMMENT '디버깅용 기기 식별 문구',
                                     `created_dtm`           timestamp     NOT NULL  DEFAULT CURRENT_TIMESTAMP,
                                     `last_success_dtm`      timestamp     NULL      COMMENT '마지막 전송 성공 시각',
                                     `consecutive_failures`  int           NOT NULL  DEFAULT 0  COMMENT '연속 실패 횟수. 10회 도달 시 정리 대상'
);

ALTER TABLE `PUSH_SUBSCRIPTION` ADD CONSTRAINT `PK_PUSH_SUBSCRIPTION` PRIMARY KEY (`push_subscription_id`);

-- varchar(512) unique 는 utf8mb4 기준 2048바이트로 InnoDB 3072바이트 키 한계 아래다.
-- 768자를 넘기게 되면 해시 컬럼으로 바꿔야 한다.
ALTER TABLE `PUSH_SUBSCRIPTION` ADD CONSTRAINT `UQ_PUSH_SUBSCRIPTION_ENDPOINT` UNIQUE (`endpoint`);

-- 사용자에게 푸시를 보낼 때마다 findAllByBoormiId 가 실행된다.
CREATE INDEX `IX_PUSH_SUBSCRIPTION_BOORMI` ON `PUSH_SUBSCRIPTION` (`boormi_id`);

ALTER TABLE `BOORMI_REVIEW` ADD CONSTRAINT `UQ_BOORMI_REVIEW_ORDER` UNIQUE (`order_id`);

ALTER TABLE `DREAMI_REVIEW` ADD CONSTRAINT `UQ_DREAMI_REVIEW_ORDER` UNIQUE (`order_id`);

• 취소했을 때 환불이 되지 않음.

부르미

• 부르미일 경우에도 현재 위치 반영해야 함. → Connected
• 절감 금액 제거

큰 버그: 드리미

📎 첨부파일: notification-tiers-plan.md — 위키로 옮길 수 없는 노션 첨부파일, 노션 원본에서 확인

저녁 회고

• 석희
  • 기능 2개(리뷰달기, 배송 후 정산 받기)
  • 매칭 실시간 테스트 실험중,,, 어떻게 기능개선할지는 ,,, 몰루
  • Qa하면서 미구현된 부분 확인하고 구현 예정
• 현성
  • 웹 Push알림 구현 (매우 오래걸림)
  • GPS 이동 자연스럽게 구현
  • GPS 경고 메시지
• 동혁
  • 로컬 환경 PR 테스트
  • DDL 업데이트, 실제 반영
  • 매칭 엔진 단일화
  • Favicon
    • 돌아가서 매칭 동적으로 (이렇게 해야 부하테스트 예쁨)
• 현서
  • 어제 pr올린거에 대한 클로드 리뷰 수정
  • 부하테스트
  • 로컬로 부하테스트 하면서 인덱스 성능 확인해보기

QA

(아래는 8/13으로 옮김)

• 부르미가 물건사진 올린거 자체를 드리미가 못봄. 픽업하는 과정에서 보여야 물건을 들고가지
• 드리미가 수락하는 상황에서 배송 요청사항이 다름 (상세설명은 보이나..?)
• 그리고 배송요청사항 "없음"일때 TextField가 안막힘
• 알림 권한을 맨 처음에 알림권한
• 테스트 : 매칭 잡아두고 앱 꺼버려도 알림이 오는지
• 안드로이드 웹앱 아이콘 자동 생성했더니 못생겨짐 ⇒ 이게 192x192 자체를 안쓰는게 나을듯. 기존에 쓰던 사진으로 교체
• 부르미 "주문 등록"해놓고 드리미로 전환이 됨
• 정책 : 드리미가 30~1분 접속 안되면 드리미에게 웹푸시 가도록 추가 (드리미 시작해놓고 뒤로가기해서 다시 부르미로전환)
• 드리미나 부르미 전환할 떄 무조건 APi 요청 해야됨. 캐싱하면 안됨
• (시간 남으면) 지도를 끌어서 위치 선택하는 기능 ⇒ 대신에, 좌표를 "확인"누를 때만 실제 카카오 API 호출 (막 지도 이동할 떄마다 도로명주소 변환돼서 API 과호출 안되게)
• 연락하기 기능 추가

---

월요일에 만나서 산출물 최종 회의