1. 문제

DreamiService.acceptOffer()가 주문 상태를 확인하지 않고 무조건 씀.

Orders order = orderRepository.findById(orderId)...
order.markPendingBoormiConfirmation();   // MATCHING인지 확인 없이 무조건 PENDING 전이

• isDreamiOfferOwner는 "내 오퍼인가"만 확인, 오퍼가 아직 살아있는지(OFFERED 여부)는 미확인
• 선착순에서 진 드리미도 수락 버튼을 누르는데 성공하고 이 검사를 통과 → DB 먼저 쓰고 커밋 후 매칭 엔진에 제출 → "마감됨"을 뒤늦게 들음 → 되돌리는 로직 없음
• 추가로 Orders에 @Version/@DynamicUpdate 부재 → dirty checking이 전체 컬럼 UPDATE 발생 → 늦게 커밋되는(패배한) 트랜잭션이 자기 트랜잭션 시작 시점의 낡은 스냅샷(예: dreami_id=null)까지 같이 덮어씀

2. 원인으로 발생한 문제

• 200건 중 4건(≈1%)에서, ORDERS가 이미 IN_PROGRESS 확정된 뒤 나중에 커밋된 패배자 트랜잭션이 order_cd를 PENDING으로, dreami_id를 null로 되돌림(전체 컬럼 덮어쓰기) → DELIVERY는 이미 생성돼 살아있는데 ORDERS만 되감겨 두 테이블 불일치
• 그중 1건은 되감기가 배달 시작 트랜잭션보다 먼저 발생 → 엔진이 주문 재조회 시 IN_PROGRESS가 아니라고 판단 → 배달 자체가 미시작(실제 서비스 장애)
• 나머지는 SSE delivery_started 알림 유실로 이어짐 — 별개 버그 아니고 이 문제의 하위 증상

3. 해결책과 장단점

① if 조건문 가드

• 장점: 구현 간단
• 단점: 확인·쓰기 사이 시간차 존재 → 진짜 동시 통과 케이스 차단 불가, 근본 해결 아님

② 낙관적 락(@Version)

• 장점: JPA 표준, 엔티티 방식 유지 가능
• 단점: 스키마 컬럼 추가 필요, 충돌이 커밋(flush) 시점에야 예외로 발현 → 예외 변환 로직 별도 필요, AFTER_COMMIT 이벤트 구조와 맞물려 복잡도 증가

③ 비관적 락

• 장점: 확실한 순차 처리, 이해가 쉬움
• 단점: 락 대기 행렬 발생, 다수 드리미 경합 시 손해 증가