[🌱 JPA 방탈출 예약 대기] 밀란(조강래) 미션 제출합니다.

[kangrae-jo]

체크 리스트

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

베이스 코드 선택 체크

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

이번 미션에서 건드릴 범위

• JPA 전환에서 바꿀 부분은 영속성 계층이다. JdbcTemplate Repository, 직접 작성한 SQL, ResultSet 매핑, join 조회 코드를 Entity 매핑과 Spring Data JPA Repository로 대체할 예정이다.

• 만약 메서드쿼리로 구현 불가능하다면 JPQL 등을 사용한다.

• 유지할 부분은 비즈니스 규칙과 API 동작이다. 예약 생성, 조회, 삭제 흐름과 Controller, Service의 큰 책임 구조, 테스트가 검증하는 결과는 유지한다.

• 따라서 이번 전환의 경계는 기능 변경이 아니라 DB 접근 방식 변경이다.

단계별 도달 지점

1단계 - JPA 기반 마련과 동작 이해

• JDBC 저장소를 Spring Data JPA로 전환했다.
• 도메인을 Entity와 Embeddable로 매핑했다.
• Dirty Checking, 1차 캐시, 쓰기 지연, flush, EAGER/LAZY 동작을 확인했다.
• 메서드 이름으로 정렬 조건을 표현했다.

2단계 - 메서드 이름 쿼리

• findByReserver를 통해 단순 동등 조건 조회를 파생 쿼리로 구현했다.
• 단순 조회는 별도의 JPQL 없이 메서드 이름으로 해결할 수 있음을 확인했다.

3단계 - 조회 최적화와 JPQL

• 일반 조회에서 발생하는 N+1 문제를 확인했다.
• fetch join과 EntityGraph를 적용해 연관 엔티티를 SELECT 한 번으로 조회했다.
• 메서드 이름으로 표현할 수 없는 대기 순번 계산을 상관 서브쿼리와 COUNT를 사용한 JPQL로 구현했다.
• JPQL 생성자 표현식으로 ReservationWaitingWithOrder projection을 생성했다.

4단계 - 예약 대기 로직의 JPA 동작 확인

• 예약 삭제 후 대기자를 승격하는 과정의 SQL 실행 순서를 확인했다.
• 기존 예약을 flush하지 않으면 DELETE 전에 새 예약의 INSERT가 실행되어 유일성 제약 조건을 위반했다.
• 명시적으로 flush하면 기존 예약의 DELETE 이후 새 예약의 INSERT가 실행되어 정상적으로 전환됐다.
• flush가 예약 대기 전환 과정의 SQL 실행 순서와 일관성을 보장한다는 점을 확인했다.

최종 도달 지점

• JPA로 저장소를 전환하고 파생 쿼리와 JPQL을 구분해 사용할 수 있다.
• N+1 문제를 확인하고 fetch join과 EntityGraph로 해결할 수 있다.
• 영속성 컨텍스트와 flush가 실제 도메인 로직의 성능과 일관성에 미치는 영향을 테스트로 설명할 수 있다.

키워드 정리

목적	키워드	1줄 정의	미션1에서 해당하는 지점
패러다임 차이	ORM	객체와 관계형 DB를 매핑하고 객체의 상태 변화를 SQL로 변환하는 기술	JdbcTemplate으로 SQL을 직접 실행하던 방식을 Entity와 Repository 중심으로 전환한 부분
	객체-관계 임피던스 불일치	객체 모델과 관계형 DB 모델의 표현 방식이 달라 생기는 차이	객체는 참조로 관계를 표현하지만 DB는 외래키와 JOIN으로 관계를 표현하는 부분
	영속성	객체의 상태를 DB에 저장하고 조회하며 유지하는 개념	직접 작성하던 INSERT, UPDATE, DELETE를 JPA가 엔티티 상태에 따라 처리하는 부분
핵심 개념	영속성 컨텍스트	JPA가 조회하거나 저장한 엔티티를 관리하는 공간	findById()로 조회한 Reservation이 변경 감지와 1차 캐시의 관리 대상이 되는 부분
	1차 캐시	같은 영속성 컨텍스트에서 조회한 엔티티를 보관하는 캐시	같은 ID를 두 번 조회했을 때 SELECT는 한 번만 실행되고 같은 객체가 반환된 부분
	dirty checking	영속 상태 엔티티의 변경을 감지해 UPDATE SQL을 생성하는 기능	save()를 다시 호출하지 않아도 엔티티 변경 후 flush 시 UPDATE가 발생한 부분
	쓰기 지연	변경 SQL을 모아두었다가 flush 시점에 DB로 전달할 수 있는 방식	DELETE가 즉시 실행되지 않고 flush 시점까지 지연된 부분. 단, IDENTITY INSERT는 즉시 실행될 수 있음
	flush	영속성 컨텍스트의 변경 내용을 DB에 동기화하는 동작	예약 삭제 후 명시적으로 flush하여 DELETE를 먼저 실행한 뒤 승격 예약을 INSERT한 부분
	FlushMode.AUTO	쿼리 결과에 영향을 줄 수 있는 변경 사항을 JPQL 실행 전 자동으로 flush하는 기본 모드	Reservation 변경 후 관련 JPQL을 실행했을 때 SELECT 전에 UPDATE가 발생한 부분
	비영속	아직 영속성 컨텍스트가 관리하지 않는 새 객체 상태	new Reservation(...)으로 생성했지만 아직 저장하지 않은 상태
	영속	영속성 컨텍스트가 관리하는 엔티티 상태	Repository로 저장하거나 조회한 Reservation이 변경 감지 대상이 된 상태
	준영속	영속성 컨텍스트의 관리를 벗어난 엔티티 상태	clear(), detach() 이후 기존 객체가 변경 감지 대상에서 제외되는 상태
	삭제	삭제 대상으로 등록되어 flush 시 DELETE가 실행될 엔티티 상태	deleteById() 이후 DELETE가 실행되기 전까지의 상태
매핑	@Entity	클래스를 JPA가 관리하는 엔티티로 지정하는 어노테이션	Reservation, ReservationWaiting, Theme, ReservationTime을 테이블과 매핑한 부분
	@Id	엔티티를 식별하는 기본키 필드를 지정하는 어노테이션	각 엔티티의 id를 테이블의 기본키와 매핑한 부분
	@GeneratedValue	기본키 값을 지정된 생성 전략에 따라 생성하는 어노테이션	IDENTITY 전략으로 INSERT 시 DB가 ID를 생성하도록 한 부분
	GenerationType.IDENTITY	INSERT를 실행해 DB가 생성한 기본키를 받아오는 전략	승격 예약 저장 시 ID를 얻기 위한 INSERT가 지연된 DELETE보다 먼저 실행된 부분
	@Column	필드와 DB 컬럼의 이름, null 허용 여부, 길이 등을 설정하는 어노테이션	createdAt, name, date 등의 컬럼 조건을 지정한 부분
	@Table	테이블명과 유일성 제약 등 테이블 단위 설정을 지정하는 어노테이션	Reservation에 날짜·시간·테마 조합의 유일성 제약을 설정한 부분
값 객체 매핑	@Embeddable	다른 엔티티 내부에 포함될 수 있는 값 타입을 정의하는 어노테이션	Member와 Slot을 독립 엔티티가 아닌 값 객체로 정의한 부분
	@Embedded	값 객체의 필드를 소유 엔티티 테이블의 컬럼으로 펼쳐 저장하는 어노테이션	Reservation 테이블에 name, date, time_id, theme_id가 저장되는 부분
연관관계	@ManyToOne	여러 엔티티가 하나의 엔티티를 참조하는 N:1 관계 매핑	여러 예약이 하나의 ReservationTime과 Theme을 참조하는 구조
	@OneToMany	하나의 엔티티가 여러 연관 엔티티를 컬렉션으로 가지는 1:N 관계 매핑	이번 미션에서는 직접 사용하지 않음
	@JoinColumn	연관관계에 사용되는 외래키 컬럼을 지정하는 어노테이션	Slot.time을 time_id, Slot.theme을 theme_id 외래키와 연결한 부분
	단방향	한쪽 객체만 상대 객체를 참조하는 관계	Reservation은 Theme과 ReservationTime을 알지만 반대쪽은 예약 목록을 가지지 않는 구조
	양방향	양쪽 객체가 서로를 참조하는 관계	이번 미션에서는 직접 사용하지 않음
	연관관계 주인	외래키 값을 실제로 관리하는 연관관계의 주체	외래키가 있는 Reservation의 Slot.time, Slot.theme 쪽
	cascade	엔티티의 저장·삭제 작업을 연관 엔티티에도 전파하는 설정	이번 미션에서는 직접 사용하지 않음
	orphanRemoval	부모와의 관계가 끊어진 자식 엔티티를 자동으로 삭제하는 설정	이번 미션에서는 직접 사용하지 않음
페치	EAGER	조회 결과 반환 전까지 연관 엔티티를 반드시 로딩하는 전략	time, theme이 JOIN 또는 추가 SELECT로 조회된 부분. JOIN 자체를 보장하지는 않음
	LAZY	연관 엔티티에 실제로 접근할 때 로딩을 시도하는 전략	이번 매핑에서는 직접 적용하지 않았지만, 접근 시 추가 SELECT나 LazyInitializationException이 발생할 수 있음
	N+1	목록 조회 1번 이후 각 결과의 연관 데이터를 조회하기 위해 추가 SELECT가 반복되는 문제	예약 3개 조회 시 Reservation 1번, Theme 3번, ReservationTime 3번으로 총 7번 조회된 부분
	fetch join	JPQL에 JOIN FETCH를 명시해 연관 엔티티를 같은 SQL로 조회하는 방법	예약과 시간·테마를 한 번의 SELECT로 조회하여 N+1을 방지한 부분
	@EntityGraph	Repository 조회 메서드에 함께 로딩할 연관관계를 지정하는 방식	slot.time, slot.theme을 함께 로딩하여 한 번의 SELECT로 조회된 부분
쿼리	메서드 쿼리	Repository 메서드 이름을 분석해 JPQL을 자동 생성하는 방식	findByReserver(), findFirstBySlotOrderByIdAsc()를 사용한 부분
	JPQL	테이블과 컬럼이 아니라 엔티티와 필드를 대상으로 작성하는 쿼리 언어	ReservationWaitingWithOrder 조회와 fetch join을 엔티티 기준으로 작성한 부분
	Native Query	DB SQL을 그대로 작성해 실행하는 JPA 쿼리 방식	인기 테마 조회에서 GROUP BY, COUNT, ORDER BY, LIMIT를 직접 표현한 부분
	Pageable	조회 결과의 페이지 크기, 번호, 정렬 조건을 전달하는 Spring Data 기능	예약 목록 페이징에 사용했으며 인기 테마 상위 N개 조회의 JPQL 대안으로 검토한 부분