08 05

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

08-05 (3주차 수)

회의 날짜: 2026-08-05 · 점심: 집 밥

스크럼

• 동혁
  • 수업을 열심히 듣고
  • 오늘 할 일 계획 정도만 짰습니다.
    1. DB 연동 및 트랜잭션 경계 설정 인메모리 상태와 Entity 매핑, 저장 시점, 조회·갱신 순서, 롤백 범위를 정합니다. 재시작 후 복구가 필요한 상태도 확인합니다.
       • MatchingReposiory의 fire-and-forget MatchingRepository는 이 메서드들을 전부 물려받으며, 런타임에는 Spring Data JPA가 프록시 구현체를 만들어 주입합니다. 현재 상황: 한 가지 주의할 점은 matchingService.acceptByBoormi(offerId)가 인메모리 fire-and-forget 방식이라면, 이 호출은 DB 트랜잭션 커밋보다 먼저 실행될 수 있다는 것입니다. 이후 트랜잭션이 롤백되면 인메모리 매칭은 확정됐지만 DB에는 저장되지 않는 불일치가 생길 수 있습니다. 해결 가능 방안: 커밋 이후에만 실행되어야 한다면 @TransactionalEventListener(phase = AFTER_COMMIT) 같은 방식도 검토할 수 있습니다.
       • SSE를 통해서 fire된 알람으로 요청을 보낼 수 있게 한다면 너무 문제가 있음. Client가 SSE알림을 보냈을 때 그것을 못받았다면? → discussion 남겨놓음.
         • 이러면 Client가 특정 요청을 통해 지금 주문에 대한 현재 상태를 알 수 있어야 함.
       • 매칭 제안의 영속화가 필요함.
    2. API 구현 및 DTO 유효성 검사 Controller–Service 연결, 인증 사용자와 리소스 소유자 검증, 입력값·상태 전이 검증을 적용합니다.
    3. ErrorCode 기반 반환값 정형화 존재하지 않는 주문, 권한 없음, 중복 요청, 유효하지 않은 상태 전이, 만료된 제안 등을 공통 응답 형식으로 통일합니다.
    4. 배달로 넘길 때 매칭 테이블 수정. 드리미: register할 때 Order 참고
• 석희
  • 배포본 오류 수정을 위해서 작업중
  • 부르미 로직 오늘 끝내고 공유하기
    • 드리미 부분까지 프론트 같이 붙여서 내일 시연 할 수 있게
  • 결제 도메인 골자정도는 만들어놓기
  • 매칭 서비스 리팩토링 생각중(동혁님과 논의)
• 현성
  • 수업 듣기
  • 배달 도메인 프론트엔드-백엔드 연동 (드리미 화면)
  • delivery-proof (픽업, 배달 완료 인증) 프리뷰
  • 픽업 취소 (드리미측)
  • PR
  • 오늘 할 일
    • 프론트엔드 SSE
    • Delivery 부르미 화면 구현
    • 양쪽으로 시연
• 현서
  • 수업 듣기
  • sql 커서 기반 말고 단일로 해도 될듯
  • issue 48번 완성하고
  • issue 49번 대시보드 넘겨주기
  • 프론트랑 연결하기

저녁 회고

• 석희
  • 부르미 부분 끝냄
  • 결제 서비스 부분 들어가기
  • 프론트 붙이려고 했는데 sse 기다리느라 못함
  • 핫픽스만 반영해서 올림
  • 배포본에 핫픽스 반영할때 좀 더 빠르게 할 수 있게 (지금은 괜찮을듯)
• 현성
  • DeliveryService 내에 있는 메소드 중에서, 배송 상태(DevlieryCd)를 참조하거나 수정하는 모든 메소드에 대해 모든 상태에 대한 분기 처리 완료
  • 신규 Delivery ErrorCode 스프레드시트에 반영
• 동혁
  • Errorcode 명세서 대로 만들고
  • ERD 부르미 거절 내역 Default값 추가
  • 리팩토링 계획 초반부
  • cleanup 매칭완료 하도록 구현 (#185)
• 현서
  • 드리미 콜 취소 구현하다가 문제 상황 공유
  • 대시보드 만들기
    • transaction → ledgers로