[🌱 JPA 방탈출 예약 대기] 서여(박성열) 미션 제출합니다.

[yeo-li]

단계별 도달 지점

0단계

• 기존 JDBC Repository에서 사용하던 SQL 패턴과 비즈니스 제약을 먼저 확인했습니다.
• schema.sql의 generated column, unique index가 단순 DDL이 아니라 예약 중복/soft delete 정책을 보장하는 핵심 장치라는 점을 확인했습니다.

1단계 - JPA 전환

• Reservation, Time, Theme를 JPA Entity로 정리했습니다.
• ReservationRepository를 JpaRepository 기반으로 전환했습니다.
• 단순 조회는 메서드 이름 쿼리로, 락/복합 조건/벌크 soft delete는 JPQL로 분리했습니다.
• schema.sql의 제약 조건과 최대한 맞도록 generated column, index, enum, version 컬럼을 Entity에 반영했습니다.

2단계 - 본인 예약 조회와 영속성 컨텍스트 관찰

• GET /reservations-mine?name={name} API를 추가했습니다.
• 로그인/회원 도메인이 아직 없어서 "본인" 식별은 name query parameter로 처리했습니다.
• findReservationByName 메서드 이름 쿼리를 사용했습니다.
• Repository의 커스텀 update()를 제거하고 dirty checking 방식으로 변경했습니다.
• @Version을 적용하고, 요청 version과 현재 entity version을 비교해 오래된 수정 요청을 감지하도록 했습니다.
• 예약 취소, 예약 수정, 대기 승인 흐름도 managed entity 상태 변경으로 처리했습니다.

아직 남은 것

• 3~4단계는 진행하지 못했습니다.
• @ManyToOne(fetch = LAZY) 전환과 LazyInitializationException, N+1, EntityGraph 적용 여부는 아직 실험하지 못했습니다.
• /reservations-mine은 실제 회원 인증 기반이 아니라 이름 기반 조회라 동명이인 문제가 남아 있습니다.
• waitingNumber는 /reservations-mine 응답에서 아직 계산하지 않고 null로 내려줍니다.

발행 SQL 발췌

Hibernate DDL 관찰

JPA Entity만으로 생성한 DDL은 다음처럼 Entity 필드 중심으로 만들어졌습니다.

create table reservation (
    date date not null,
    deleted_at timestamp(6),
    id bigint generated by default as identity,
    theme_id bigint not null,
    time_id bigint not null,
    version bigint not null,
    name varchar(255) not null,
    status enum ('ACTIVE','CANCELED','WAITING') not null,
    primary key (id)
)

반면 기존 schema.sql에는 soft delete와 예약 중복 방지를 위한 generated column, unique index가 있었습니다.

active_date DATE GENERATED ALWAYS AS (
    CASE WHEN status = 'ACTIVE' AND deleted_at IS NULL THEN date ELSE NULL END
);

CREATE UNIQUE INDEX uq_active_reservation
ON reservation (active_date, active_time_id, active_theme_id);

이 차이를 보고 Entity 매핑만으로는 현재 도메인의 DB 제약을 충분히 표현하기 어렵다는 점을 확인했습니다.

INSERT SQL 관찰

기존 JDBC는 넣을 컬럼을 직접 지정했습니다.

INSERT INTO reservation (name, date, time_id, theme_id, status)
VALUES (?, ?, ?, ?, ?)

JPA 전환 후에는 Entity 상태를 기준으로 다음 형태의 SQL이 나갔습니다.

insert into reservation
    (date, deleted_at, name, status, theme_id, time_id, version, id)
values
    (?, ?, ?, ?, ?, ?, ?, default)

deleted_at, version처럼 JDBC에서는 DB default에 맡겼던 컬럼도 JPA insert에는 포함될 수 있다는 점을 확인했습니다.

findById 후 연관 객체 접근 SQL

다음 코드를 관찰했습니다.

Reservation reservation = reservationRepository.findById(reservationId).orElseThrow();
reservation.getTime().getStartAt();

처음에는 getTime() 시점에 추가 select가 나갈 것이라고 예상했지만, 실제로는 @ManyToOne 기본값이 EAGER라 findById 시점에 join이 함께 발생했습니다.

select
    r1_0.id,
    r1_0.date,
    r1_0.deleted_at,
    r1_0.name,
    r1_0.status,
    r1_0.theme_id,
    t1_0.id,
    t1_0.name,
    r1_0.time_id,
    t2_0.id,
    t2_0.start_at,
    r1_0.version
from reservation r1_0
join theme t1_0 on t1_0.id = r1_0.theme_id
join reservation_time t2_0 on t2_0.id = r1_0.time_id
where r1_0.id = ?

망설인 결정

1. schema.sql을 지울지, Entity로 최대한 표현할지

처음에는 JPA를 쓰면 schema.sql을 없애도 될 것 같았습니다.
하지만 현재 프로젝트의 핵심 제약은 soft delete를 고려한 unique index와 generated column에 있었습니다.

그래서 Entity에 columnDefinition, @Index를 추가해 최대한 맞췄지만, 이 방식도 결국 DB별 DDL 문자열에 의존합니다.
운영 수준에서는 schema.sql이나 migration 도구가 여전히 필요하다고 판단했습니다.

2. 예약 수정 로직을 JPQL update로 유지할지, dirty checking으로 바꿀지

처음에는 JDBC 시절의 update() 흐름을 JPA Repository 안에 JPQL 벌크 update로 옮겼습니다.
하지만 이 방식은 JPA를 쓰면서도 영속성 컨텍스트의 장점을 거의 쓰지 못했습니다.

그래서 최종적으로는 다음 방식으로 바꿨습니다.

Reservation reservation = reservationRepository.findByIdAndDeletedAtIsNull(id)
    .orElseThrow();

reservation.update(date, time, theme);

이제 save()나 커스텀 update() 없이 flush/commit 시점에 dirty checking으로 UPDATE가 발행됩니다.

흔들린 한 장면

가장 헷갈렸던 장면은 findById(reservationId).getTime().getStartAt()을 관찰할 때였습니다.

처음 예상은 다음과 같았습니다.

1. reservation만 select
2. getTime() 접근 시 reservation_time 추가 select

하지만 실제로는 findById 한 번에 theme, reservation_time이 join으로 같이 조회됐습니다.
객체 그래프를 탐색하는 코드만 보고 SQL을 예상하면 틀릴 수 있고, fetch 전략을 반드시 같이 봐야 한다는 점을 배웠습니다.