[🌱 JPA 방탈출 예약 대기] 로지(이지현) 미션 제출합니다.

[Jihyun3478]

체크 리스트

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

---

어떤 부분에 집중하여 리뷰해야 할까요?

0단계: 시작 구조 파악

기존 코드 구조는 Controller → Service → Dao → Domain이었고, Service가 비즈니스 로직을 맡고 Dao는 SQL 실행과 객체 매핑만 책임졌습니다. Controller에서 Service로 Dto를 넘기기 전에 Command를 활용해 Service가 DTO 계층에 의존하지 않도록 설계되어 있었습니다.

JPA 전환 범위 판단

유지: Controller 계층, Service 계층
교체: Repository(Dao) 계층 전체

Repository에 존재하는 ROW_MAPPER, baseSelectSql() 같은 필드·메서드가 JPA의 객체 참조를 활용하면 모두 불필요해지기 때문입니다.

---

1단계: JPA 전환

방탈출 미션 INSERT (JdbcTemplate)

INSERT INTO reservation (NAME, DATE, TIME_ID, THEME_ID)
VALUES ('로지', 2026-06-18, 5, 3);
JPA 전환 후 INSERT (Hibernate)

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

• 동일한 점: 4개의 컬럼을 삽입하는 구조가 같습니다.
• 다른 점: JPA는 id 컬럼을 명시하되 default 키워드로 위임합니다. 또한 파라미터가 ?로 바인딩됩니다.

findById(reservationId).getTime().getStartAt() 발행 SQL

select r1_0.id, r1_0.name, r1_0.date,
       t1_0.id, t1_0.description, t1_0.name, t1_0.thumbnail,
       t2_0.id, t2_0.start_at
from reservation r1_0
left join theme t1_0 on t1_0.id = r1_0.theme_id
left join reservation_time t2_0 on t2_0.id = r1_0.time_id
where r1_0.id = ?

@manytoone의 기본 fetch 전략이 EAGER이기 때문에 findById 한 번에 연관된 Theme, ReservationTime까지 LEFT JOIN으로 한 번에 가져옵니다.

영속성 컨텍스트 관찰: 쓰기 지연 + flush 순서 / 발견한 버그와 원인

예약 삭제 후 대기자를 예약으로 승격하는 코드에서 ConstraintViolationException이 발생했습니다.

// deleteById 호출
// save 호출 (같은 슬롯 unique constraint)
→ ConstraintViolationException 발생

• 예측: deleteById를 먼저 호출했으니 DELETE가 먼저 나가고 INSERT가 나갈 것이다.
• 실제: Hibernate의 action queue는 INSERT를 DELETE보다 먼저 실행합니다.
• 원인: flush 시점까지 쓰기 지연이 쌓이며, 실행 순서는 호출 순서가 아닌 Hibernate 내부 우선순위를 따릅니다.
• 해결: deleteById 직후 reservationRepository.flush()를 명시적으로 호출해 DELETE를 먼저 DB에 반영했습니다.

---

2단계: 내 예약 목록 조회

메서드 이름 쿼리 vs JPQL

JPQL이 먼저 떠올랐습니다. 인증/인가 코드가 없어 "어떻게 내 예약을 구분하는가"를 쿼리 관점으로 먼저 고민했기 때문입니다.

실제로는 메서드 이름 쿼리를 선택했습니다. name으로 필터링하는 조건 자체는 메서드 이름으로 표현 가능했기 때문입니다. 예약과 대기를 합산·정렬하는 과정은 애플리케이션 레이어에서 처리했습니다.

이 결정의 한계

• 한계 1 (쿼리 횟수): 예약 조회 1번 + 대기 조회 1번, 대기자 순번 계산 N번 → 총 2+N번의 쿼리
• 한계 2 (정렬 위치): 정렬을 DB가 아닌 Java에서 수행 → 데이터가 많아질수록 전체를 메모리에 올린 뒤 정렬
• 한계 3 (표현 불가): Reservation과 ReservationWaiting을 UNION하거나 함께 조회하는 것은 메서드 이름 쿼리로 표현 불가

Member 도메인 추가

2단계에서 name 파라미터로 내 예약을 조회하던 방식의 한계를 느껴, Member 엔티티를 추가하고 Reservation, ReservationWaiting 모두 String name → @manytoone Member member로 교체했습니다. 덕분에 GET /reservations-mine?name=로지 대신 GET /reservations-mine?memberId=1로 변경할 수 있었습니다.

망설인 결정

• 결정 1: 메서드 이름 쿼리를 쓸 것인가, JPQL을 쓸 것인가

  • 단순 필터링(findByMember_Id)은 메서드 이름으로 충분했습니다. 하지만 예약과 대기를 합쳐 정렬하는 순간 메서드 이름 쿼리의 한계에 부딪혔습니다. JPQL로 시작했다면 이 벽을 더 일찍 넘었을지도 모릅니다.

• 결정 2: Member 도메인을 추가할 것인가

  • 이번 미션은 인증/인가 학습이 목적이 아니라 JPA 학습이 목적이기 때문에 처음에는 Member 없이 진행하려 했습니다. 그러나 String name으로는 진짜 "내 예약"을 표현할 수 없어 결국 추가했습니다. 추가하자 Reservation, ReservationWaiting, 관련 Repository, Service, Controller, 테스트 전체를 다 건드려야 했고, 변경 범위가 예상보다 훨씬 넓었습니다.

---

흔들린 한 장면

ConstraintViolationException을 처음 마주했을 때입니다. deleteById를 먼저 호출했는데 왜 DELETE보다 INSERT가 먼저 나가는지 이해하지 못했습니다. 로그를 보며 Hibernate의 action queue가 INSERT를 먼저 처리한다는 것을 알게 됐고, flush 타이밍이 호출 순서와 다를 수 있다는 것을 처음으로 체감했습니다. 영속성 컨텍스트를 "이론"이 아닌 "버그"로 처음 만난 순간이었습니다.

---

미완 사항

• 3단계 (JPQL·페치 전략): 미진입 상태
• N+1 문제 탐색: 2단계의 2+N번 쿼리 문제를 fetch join 또는 @batchsize로 해결하는 것을 시도하지 못했습니다
• 4단계: 미진입 상태