[🌱 JPA 방탈출 예약 대기] 보예 미션 제출합니다.

[boyekim]

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

단계별 도달 지점

1단계: JPA 전환

• JdbcTemplate 기반 저장소를 Spring Data JPA Repository로 전환했습니다.
• Reservation -> ReservationSlot -> Theme/Date/Time 구조로 연관관계를 매핑했습니다.
• Theme + Date + Time 조합은 ReservationSlot으로 분리하고 유니크 제약을 두었습니다.

2단계: 내 예약 목록 조회

• GET /reservations-mine 로 엔드포인트를 변경했습니다.
• 메서드 이름 쿼리 대신 JPQL(@Query)을 사용했습니다.
• 사용자 조건, 연관 엔티티 조인, 날짜/시간 정렬, 대기번호 계산이 함께 필요했기 때문입니다.
• 서비스에서 대기번호를 계산하지 않고, JPQL 생성자 표현식으로 ReservationWithWaitingNumber를 바로 조회하도록 했습니다.

3단계: 예약 대기 조회와 N+1 관찰

• 별도 Waiting 엔티티를 만들지 않고, ReservationStatus.WAITING으로 예약 대기를 표현했습니다.
• Reservation이 ReservationSlot, User를 참조하고 ReservationSlot이 Theme, Date, Time을 참조하도록 모델링했습니다.
• DTO 변환 시 reservation.getReservationSlot().getTheme()처럼 연관 객체를 타고 들어가면 N+1이 발생할 수 있음을 확인했습니다.
• 단순히 fetch = EAGER로 바꾸는 것은 “언제 로딩할지”만 정할 뿐, 항상 하나의 쿼리로 가져온다는 보장은 없다고 판단했습니다.
• 따라서 조회 API에서는 필요한 연관 엔티티를 JPQL 조인으로 명시하고, 대기 순번은 JPQL 생성자 표현식과 상관 서브쿼리로 함께 조회했습니다.
• 이로써 애플리케이션 메모리에서 대기 목록을 다시 순회하지 않고, 조회 쿼리에서 waitingNumber까지 함께 가져오도록 했습니다.

4단계: 어드민 대기 관리 및 자동 승인

• GET /admin/waitings, DELETE /admin/waitings/{id}를 추가했습니다.
• 수동 승인 대신 자동 승인을 선택했습니다.
• 확정 예약 취소와 첫 번째 대기 예약 승격을 하나의 @Transactional 안에서 처리했습니다.
• 자동 승인 흐름에서는 ReservationSlot을 변경하지 않고, 두 Reservation의 상태만 변경합니다.

발행 SQL 발췌

내 예약 목록 조회에서 대기번호는 상관 서브쿼리로 계산됩니다.

select
    r.id,
    r.reservation_slot_id,
    r.user_id,
    r.status,
    r.created_at,
    r.updated_at,
    (
        select count(r2.id) + 1
        from reservation r2
        where r2.reservation_slot_id = r.reservation_slot_id
          and r2.status = ?
          and (
              r2.updated_at < r.updated_at
              or (
                  r2.updated_at = r.updated_at
                  and r2.id < r.id
              )
          )
    ) as waiting_number
from reservation r
join users u on u.id = r.user_id
join reservation_slot rs on rs.id = r.reservation_slot_id
join reservation_date rd on rd.id = rs.date_id
join reservation_time rt on rt.id = rs.time_id
join theme t on t.id = rs.theme_id
where u.name = ?
order by rd.date desc, rt.start_at desc, r.id;

망설인 결정

대기번호 계산 위치

처음에는 엔티티를 조회한 뒤 서비스에서 대기번호를 계산했습니다.
하지만 대기번호는 상태를 변경하는 도메인 규칙이라기보다 조회 화면에 필요한 표시 값에 가까웠습니다.

그래서 서비스에 계산 로직을 두지 않고, JPQL 생성자 표현식으로 ReservationWithWaitingNumber를 바로 반환하도록 변경했습니다.
서비스는 조회 결과를 응답으로 감싸는 역할만 하도록 단순화했습니다.

흔들린 한 장면

처음에는 JDBC에서 하던 것처럼 대기번호나 인기 테마 count를 쿼리에서 바로 DTO로 뽑으려 했습니다.
하지만 JPA로 옮기면서 select new ...Dto(...)를 쓰면 DTO의 전체 패키지 경로를 JPQL 문자열 안에 적어야 했고, 생성자 인자 순서까지 쿼리와 강하게 묶였습니다.

그래서 한때는 엔티티를 조회한 뒤 서비스에서 대기번호를 계산하는 방향으로 바꿨습니다.
이 방식은 쿼리가 단순해지고 도메인 흐름은 읽기 쉬웠지만, 대기번호가 실제 상태 변경 규칙이라기보다 조회 화면에 필요한 표시 값에 가까운데도 서비스가 계산 로직을 많이 들고 있게 됐습니다.

결국 대기번호는 조회 전용 값이라고 판단해 JPQL 생성자 표현식으로 다시 옮겼습니다.
서비스는 ReservationWithWaitingNumber를 받아 응답으로 감싸는 역할만 하도록 줄였고, Repository 쿼리에서 같은 슬롯의 앞선 WAITING 예약 수를 세어 waitingNumber를 함께 반환하도록 정리했습니다.