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

[miniminjae92]

단계별 도달 지점

사전 설문

• JPA를 처음 다루는 상태에서 출발했습니다.
• 이번 미션 목표는 JPA가 무엇을 자동화하고, 왜 사용하는지 체감하는 것이었습니다.

사전학습

• JDBC, JdbcTemplate, JPA의 역할 차이를 정리했습니다.
• 영속성 컨텍스트, LAZY, fetch join, EntityGraph, JPQL을 이번 미션 코드와 연결해 학습했습니다.

0단계

• 기존 방탈출 미션 코드 위에서 JPA 전환을 시작했습니다.
• Controller, Service의 비즈니스 규칙, 예외 처리 흐름은 최대한 유지하고 Repository와 SQL 중심 코드를 전환 대상으로 잡았습니다.

1단계

• JdbcTemplate 기반 Repository를 Spring Data JPA Repository로 전환했습니다.
• Reservation, ReservationDate, ReservationTime, Theme를 JPA 엔티티로 매핑했습니다.
• Reservation이 날짜, 시간, 테마를 객체 참조로 가지도록 @ManyToOne(fetch = LAZY) 연관관계를 설정했습니다.
• 영속성 컨텍스트의 dirty checking, 1차 캐시, 쓰기 지연, flush 시점, LAZY 접근을 관찰했습니다.

2단계

• 내 예약 목록 조회를 JPQL + @EntityGraph로 구현했습니다.
• 유효 예약 조건은 JPQL로 표현하고, DTO 생성에 필요한 date, time, theme는 EntityGraph로 함께 로딩했습니다.

3단계

• WaitingReservation을 JPA 엔티티로 전환했습니다.
• 기존 JDBC 예약 대기 Repository 구현체를 제거했습니다.
• 예약 대기 순번은 JPQL의 count + 1 서브쿼리로 계산했습니다.
• N+1 방지를 위해 예약 대기 조회에도 @EntityGraph를 적용했습니다.

4단계

• 예약 취소/수정 시 같은 슬롯의 가장 오래된 예약 대기를 자동 승격하도록 구현했습니다.
• 현재는 ReservationService의 하나의 트랜잭션 안에서 예약 삭제, 대기 조회, 예약 생성, 승격된 대기 삭제를 처리합니다.

발행 SQL 발췌

예약 대기 순번 계산 JPQL은 아래와 같은 SQL로 변환되는 것을 확인했습니다.

select
wr1_0.id,
wr1_0.created_at,
d3_0.id,
d3_0.play_day,
wr1_0.name,
t5_0.id,
t5_0.content,
t5_0.name,
t5_0.url,
t6_0.id,
t6_0.start_at,
(select
(count(wr2_0.id)+1)
from
waiting_reservation wr2_0
where
wr2_0.date_id=wr1_0.date_id
and wr2_0.time_id=wr1_0.time_id
and wr2_0.theme_id=wr1_0.theme_id
and (
wr2_0.created_at<wr1_0.created_at
or (wr2_0.created_at=wr1_0.created_at and wr2_0.id<wr1_0.id)
))
from
waiting_reservation wr1_0
join reservation_date d3_0 on d3_0.id=wr1_0.date_id
left join theme t5_0 on t5_0.id=wr1_0.theme_id
join reservation_time t6_0 on t6_0.id=wr1_0.time_id
where
wr1_0.name=?
order by
d3_0.play_day,
t6_0.start_at,
wr1_0.id

망설인 결정

• 복잡한 조회 조건은 메서드 이름 쿼리보다 JPQL이 더 적절하다고 판단했습니다.
• N+1 해결은 join fetch 대신 @EntityGraph를 선택했습니다. 조건과 로딩 범위를 분리해서 읽는 편이 더 명확하다고 봤습니다.
• 예약 대기를 Reservation.status로 통합할지, 별도 WaitingReservation으로 유지할지 고민했습니다. 현재 요구사항만 보면 status도 가능해 보였지만, 이번 구현에서는 유니크 제약 차이를 기준
  으로 별도 도메인을 유지했습니다.

흔들린 지점

자동 승격을 하나의 트랜잭션에 묶는 방식이 항상 좋은지는 확신하지 못했습니다. 현재 방식은 단순하고 DB 일관성은 지키기 쉽지만, 승격 실패가 예약 취소 실패로 이어질 수 있고 동시성 상황도
충분히 방어하지 못할 수 있습니다.

비동기 이벤트로 분리하는 방법도 생각해봤지만, 중간 상태, 재시도, 중복 승격, 동시성 제어를 아직 명확히 해결하지 못해 이번 단계에서는 단순한 트랜잭션 방식을 선택했습니다.