08 07

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

08-07 (3주차 금)

회의 날짜: 2026-08-07 · 점심: 뱅뱅막국수

---

🐛 트러블슈팅 로그 — DELIVERY 테이블 컬럼 오류 (Unknown column 'd1_0.boormi_id')

두 경로에서 동일한 원인으로 반복 발생:

1. 매칭 엔진 스레드에서 DeliveryService.startDelivery(DeliveryService.java:88) — Delivery 저장 시
2. REST 요청에서 DeliveryService.getDeliveryDetail(DeliveryService.java:97) — Delivery 조회 시

org.hibernate.exception.SQLGrammarException / java.sql.SQLSyntaxErrorException
Unknown column 'd1_0.boormi_id' in 'field list'

SQL: select d1_0.delivery_id, d1_0.boormi_id, d1_0.current_latitude, d1_0.current_longitude,
     d1_0.delivery_cd, d1_0.delivery_end_dtm, d1_0.delivery_start_dtm, d1_0.dreami_id,
     d1_0.order_id, d1_0.picked_up_dtm, d1_0.received_dtm
     from DELIVERY d1_0 where d1_0.delivery_id = ?  (또는 where d1_0.order_id = ?)

Hibernate가 매핑한 boormi_id 컬럼이 실제 DELIVERY 테이블에는 없어서 SELECT 자체가 실패한다 — 엔티티/DDL 스키마 드리프트로 추정.

---

아침 스크럼

• 석희
  • 죽은 서버를 살림 (관련 트러블 슈팅 내용 정리해서 위키에 업로드)
  • sse 배포 서버 관련 트러블 슈팅
  • 결제 관련 정산받기, 포인트 충전, 조회 등 만들기 + 프론트 연동까지? 할듯
  • 부하테스트 어떻게 할지 찾아볼듯
• 동혁
  • 어제 로컬에서 프론트 매칭 테스트 하는거 설정
  • 매칭은 로컬에 잘됐었는데 delivery쪽 그 SQL 문제 있는 것 같아서 수정 PR날렸었는데 오늘 보니까 잘 안됨.
  • 오늘 할 일
    • 매칭 쪽에서는 시연할 때 문제 최대한 안생기게 troubleshooting.
    • 주말에 SSE 프론트 공부
    • 부하 테스트 찾아보기
    • 이벤트가 더 중요함.
• 현서
  • 프론트 연동
  • 드리미 정산 대시보드에서 status, type 둘 다 조건 걸어서 조회
  • 드리미 goOnline, goOffline 전환하는거 오전에 해보고
  • 주말에 할 일
    • 부하테스트 공부
    • p2 어떻게 구현할지
    • api 명세서 정리
    • 드리미 시작하기 버튼 눌렀을 때 주변 콜 리스트 보여주는 api 연동
• 현성
  • 로컬에서 테스트 중인데, 매칭→배달 넘어갈 때 안됨
  • 배달 단독 테스트 전혀 문제 없음
  • 계속 매칭→배달만 가면 문제가 될까..를 분석하고 수정해봐야될 것 같습니다.
  • 로컬에서 테스트해보고 문제분석해서 동혁님이랑 같이 얘기

---

메인프로젝트 조 순위: 4조, 1조, 5조, 7조, 6조, 3조, 2조 → 우리 6번째

📷 사진 업로드 에러

• URL 패턴: https://d3cev4xst074qp.cloudfront.net/uploads/PICKUP_CERTIFICATION_IMAGE/21d99fbe-42f9-4645-97f6-5e8662122879-IMG_1852.jpeg?X-Amz-...(서명 파라미터 생략)
• 상태: 403
• 소스: 네트워크 (index-k1o3t97c.js:133:19167)

요청 헤더

• Accept: application/json, text/plain, */*
• Content-Type: image/jpeg
• Origin: https://d3cev4xst074qp.cloudfront.net
• Referer: https://d3cev4xst074qp.cloudfront.net/delivery-proof?mode=photo&orderId=752f7ae6-35b5-4717-bce0-350f177f68d4&intent=pickup

응답 헤더

• Content-Length: 1053
• Content-Type: text/html
• Server: CloudFront
• x-cache: Error from cloudfront

쿼리 문자열에는 X-Amz-Security-Token/X-Amz-Algorithm/X-Amz-Signature 등 presigned URL 서명 파라미터가 그대로 실려 있었음(값 생략).

8/7 데모 이후 모니터링 상황

🖼️ (이미지 4장: 모니터링 대시보드 스크린샷 — 원본 노션 페이지에서 확인, 서명 URL이라 만료됨)

피드백

1. 분산 환경 구현하면 가산점
2. 폴리싱
3. 브랜치 커버리지
   1. 중요한 부분을 커버했는지
   2. 테스트 라이브러리 사용해서
4. 프로덕션 환경에서는 테스트 포함해서
5. query dsl을 사용하지 않은 명확한 이유가 있는가
6. 부하 테스트 툴: NGrinder, jmeter, locust
7. 숙소 예약도 오버부킹 허용해두고 나중에 관리자가 수정하게 하는것이 비지니스적으로 더 올바를 수 있음
8. 깃 플로우 사용: 버전 너무 많아서 다양한 기기를 내가 다 대응하고 있을 때(크롬, 사파리, 안드로이드 등)
   1. 깃헙 플로우가 적당하다
9. 태그 붙이기

회의 - 거리 정보 이슈

1. 어떤 하나의 주문에 대해, 100명의 드리미에게 팝업을 띄워야하는 상황이라고 하자.
2. 출발지↔도착지의 거리는 하나의 주문에 대해 고정임
3. 하지만, 드리미의 위치는 모두 제각각이고, 따라서 드리미의 위치와 출발지까지의 거리는 하나의 주문에 대해, 드리미의 수만큼 늘어남 (100명에게 알림을 뿌릴 때, 그 100명마다 모두 카카오API를 호출할 수 없음)
4. 직선 거리의 경우에는 위도와 경도정보로 바로 계산할 수 있음
5. 하지만 직선거리는 의미가 없는게, 예를 들어 현재 드리미와 물건 픽업 장소 사이에 한강이 있는 경우처럼 실제 직선거리와 현실적인 거리가 일치하지 않을 수 있음
6. 따라서, 드리미 입장에서 매칭 팝업이 뜨는 상황에서, 지도를 하나 보여줘서 현재 위치와 픽업지(출발지),도착지를 핀으로 찍어서 직관적으로 보여주게 개선 예정

Action 1

더 빠르게 (에이전트를 잘 활용하자) 물론 본인이 짠 것은 이해하고 있자.

Action 2

Logging을 체계화하자. 부하 테스트를 통해 문제를 파악하고 개선해나가자.

Action 3

문서화에 신경쓰고, 자동화 방안 모색 (클로드 스킬 사용) - 녹음?