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

[dahxxn]

체크 리스트

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

베이스 코드 선택 체크

• 이전 미션의 내 코드에서 시작
• 이전 미션의 페어의 코드에서 시작

단계별 도달 지점

단계별 도달 지점

1단계: JPA 매핑 전환

• Theme, ReservationTime, Reservation, ReservationWaiting 엔티티 전환
• Reservation, ReservationWaiting 단방향 연관관계 매핑
• Spring Data JPA Repository 전환
• 기존 JDBC Repository 제거

2단계: 내 예약 목록 조회

• 이름을 기준으로 본인 예약 목록 조회

3단계: 예약 대기

• POST /waitings 예약 대기 요청
• DELETE /waitings/{id} 예약 대기 취소
• 예약과 예약 대기 통합 조회
• 중복 예약 및 중복 대기 방지
• 대기 순번 표시
• fetch join 또는 @EntityGraph 적용

4단계: 예약 대기 관리

• 예약 취소 시 첫 번째 대기 자동 승인
• 관리자 예약 취소 시 첫 번째 대기 자동 승인
• 자동 승인 실패 시 전체 트랜잭션 롤백
• 어드민 예약 대기 목록 조회
• 어드민 예약 대기 취소
• 동시 승인에 대한 명시적인 동시성 제어

관찰한 SQL

엔티티 기반 DDL 생성

create table reservation (
    date DATE not null,
    id bigint generated by default as identity,
    theme_id bigint not null,
    time_id bigint not null,
    name varchar(255) not null,
    primary key (id)
)
create table theme (
    id bigint generated by default as identity,
    description varchar(255),
    name varchar(255) not null,
    thumbnail TEXT,
    primary key (id)
)

기존에는 schema.sql이 스키마의 기준이었지만, JPA 전환 후에는 엔티티의 nullable, 길이, 타입 등의 매핑 정보가 Hibernate 생성 DDL에 반영되는 것을 확인했습니다.

LAZY 연관관계 조회

Reservation을 조회했을 때:

select
    r.id,
    r.date,
    r.name,
    r.theme_id,
    r.time_id
from reservation r
where r.id = ?

이후 다음 코드로 연관 엔티티의 실제 값에 접근했습니다.
reservation.getTime().getStartAt();
그때 ReservationTime을 조회하는 SQL이 추가로 실행됐습니다.

select
    rt.id,
    rt.start_at
from reservation_time rt
where rt.id = ?

@ManyToOne(fetch = LAZY)로 인해 최초 예약 조회에서는 외래 키만 조회하고,
연관 엔티티의 실제 필드에 접근할 때 추가 SELECT가 발생하는 것을 확인했습니다.

망설인 결정

단방향과 양방향

Theme이나 ReservationTime에서 예약 목록을 탐색할 가능성을 고려해 양방향 매핑을 고민했습니다.
하지만 현재 기능에는 부모 엔티티에서 예약 목록으로 이동해야 하는 요구가 없었습니다. 불필요한 컬렉션 관리와 연관관계 동기화 책임을 만들지 않기 위해 Reservation, ReservationWaiting에서만 참조하는 단방향 관계를 선택했습니다.

cascade와 orphanRemoval

예약이 삭제되더라도 Theme이나 ReservationTime은 함께 삭제되면 안 됩니다. 서로 생명주기가 독립적이므로 cascade와 orphanRemoval을 적용하지 않았습니다.

메서드 이름 쿼리와 JPQL

단순한 동등 조건은 메서드 이름으로 의도를 충분히 표현할 수 있어 파생 쿼리를 사용했습니다.
findByName(...)
existsByTime_Id(...)
existsByTheme_Id(...)
반면 대기 순번 계산이나 인기 테마 집계처럼 집계·정렬·DTO 프로젝션이 필요한 조회는 메서드 이름이 지나치게 길어지거나 표현 자체가 어려워 JPQL을 사용했습니다.

흔들린 한 장면

처음에는 연관관계를 EAGER로 변경하면 N+1 문제가 해결될 수 있다고 생각했습니다.
하지만 EAGER는 연관 엔티티를 즉시 로딩한다는 것만 보장하며, 하나의 JOIN SQL로 조회하는 것을 보장하지 않는다는 점을 확인했습니다. 오히려 연관 데이터가 필요 없는 조회에서도 항상 로딩이 발생할 수 있습니다.
따라서 엔티티의 기본 관계는 LAZY로 유지하고, 연관 데이터가 반드시 필요한 특정 조회에서 fetch join이나 @EntityGraph를 사용하는 방향이 적절하다고 판단했습니다.

현재 결정의 한계

자동 승인 로직을 하나의 @transactional 서비스 메서드 안에 두어 단일 요청 안에서의 원자성은 확보했습니다.
하지만 같은 슬롯에서 여러 취소 또는 승격 요청이 동시에 실행될 경우를 위한 명시적인 락은 적용하지 않았습니다. 데이터베이스의 UNIQUE 제약조건이 최종 무결성 안전장치 역할을 하지만, 충돌 발생 시 사용자 경험과 재시도 정책까지 충분히 다루지는 못했습니다.
현재 결정에서 가장 약한 부분은 동시성 제어입니다.