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

build.gradle

@@ -23,7 +23,7 @@ configurations {
 dependencies {
     implementation 'org.springframework.boot:spring-boot-starter'
     implementation 'org.springframework.boot:spring-boot-starter-web'
-    implementation 'org.springframework.boot:spring-boot-starter-jdbc'
+    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
     implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
     implementation 'org.springframework.boot:spring-boot-starter-validation'
     compileOnly 'org.projectlombok:lombok'

docs/jpa-mission/0단계-기본-코드-준비.md

@@ -0,0 +1,32 @@
+## 3. 0단계 - 기본 코드 준비하기
+
+평가 대기
+
+제출 완료2026. 6. 17. 제출
+
+# 0단계: 기본 코드 준비
+
+`spring-roomescape-waiting` 저장소의 **본인 브랜치**에 방탈출 미션에서 작업한 코드가 그대로 있습니다. 이 코드 위에 JPA 전환을 시작합니다. **0단계는 UI 동작 확인을 하지 않습니다** — 1단계가 끝나야 UI 연동이 완료됩니다.
+
+> **들어가기 전 자기 진단**
+
+Q. 본인 브랜치의 방탈출 미션 코드는 동작 가능한 상태인가요? 본인 코드의 구조를 한눈에 설명할 수 있나요?
+
+현재 전체 테스트가 통과하고 정상 작동하는 상태입니다. 코드는 예약, 예약 날짜, 예약 시간, 테마, 예약 대기 기능을 중심으로 Controller, Service, Repository 계층이 분리되어 있습니다. 일반 사용자 인증/인가는 없고, 예약과 예약 대기 조회는 name 요청 값을 기준으로 처리합니다. 다만 관리자 기능은 /admin/\*\* 경로에 대해 토큰 기반 인터셉터로 접근을 제한합니다. DB 접근은 JdbcTemplate, 직접 작성한 SQL, parameter binding, RowMapper를 사용하는 Repository 구현체가 담당합니다. 주요 도메인 객체는 Reservation, ReservationDate, ReservationTime, Theme, WaitingReservation이며, ReservationSlot과 ReservationSlotResolver가 날짜/시간/테마 조합의 예약 가능 여부를 판단하는 역할을 합니다. 저는 단위 테스트와 통합 테스트를 나누는 기준을 JUnit과 테스트 더블로 특정 객체의 책임만 확인하면 단위 테스트로 보았고, 그 이외의 여러 구성 요소의 통합 검증을 목적으로 하는 것들은 통합 테스트로 보았습니다. 그리고 단위 테스트를 최우선으로 하고, 필요한 경우에만 통합 테스트를 진행하는 것을 목표로 했습니다. Domain은 객체의 핵심 규칙과 유효성을 지키는 역할이라고 보고 핵심 규칙과 불변식을 단위 테스트했습니다. Repository는 DB 저장/조회와 SQL 결과를 객체로 변환하는 역할이라고 보고 해당 부분을 통합 테스트로 검증했습니다. Service는 도메인과 Repository를 조합해 비즈니스 규칙을 지키는 역할이라고 보았습니다. 그래서 Fake Repository를 사용해 DB 없이 예약 생성, 중복 방지, 마감된 예약 제한 같은 규칙을 검증했고, 예약 대기 승격과 롤백처럼 여러 저장소와 트랜잭션이 필요한 흐름은 통합 테스트로 확인했습니다. Controller는 HTTP 요청을 검증하고 Service에 위임한 뒤 상태 코드와 응답을 반환하는 역할이라고 생각했습니다. 그래서 MockMvc나 RestAssured로 요청 검증, 응답 상태 코드, JSON 응답을 확인했습니다.
+
+## 시작점
+
+이 선택미션은 `spring-roomescape-waiting`의 **본인 브랜치**에서 시작합니다. 자기 손으로 만든 SQL이 객체 그래프로 어떻게 옮겨지는지 **직접 비교**하는 자리가 이 미션의 핵심입니다.
+
+## 0단계 요구사항
+-   본인 브랜치에서 작업할 새 브랜치를 따고 시작합니다. 1단계 이후의 변환 diff가 깔끔하게 보입니다.
+-   처음부터 다시 구현하지 않습니다. 이 미션이 보려는 "내 방탈출 미션 SQL이 JPA로 어떻게 옮겨지는가"의 비교 대상이 흐려집니다.
+-   동작 확인: 본인 브랜치의 방탈출 미션 동작이 그대로 유지되는지 확인합니다.
+
+> 0단계는 푸시 후 PR을 열지 않습니다. 최종 PR(미션 종료 시) 본문에 0단계의 **시작 브랜치·작업 브랜치**와 **이번 미션에서 건드릴 범위**를 한 단락으로 적습니다.
+
+## 확인 과제
+
+Q. 방탈출 미션 코드 중 JPA 전환에서 건드릴 부분과 그대로 둘 부분의 경계를 적어주세요. 무엇을 바꿀 예정이고 무엇은 유지할 예정인가요?
+
+JPA 전환에서는 JdbcTemplate 기반 Repository 구현체, 직접 작성한 SQL, RowMapper를 중심으로 변경할 예정입니다. 단순 CRUD는 Spring Data JPA Repository로 전환하고, 예약 가능 여부 조회, 인기 테마 조회, 예약 대기 순번 조회처럼 조건이 복잡한 쿼리는 기존 SQL의 의미를 보존하면서 JPQL이나 별도 조회 전략을 검토하겠습니다. JPA 전환 과정에서는 기존 Repository 테스트와 서비스 통합 테스트를 기준으로 동작이 유지되는지 확인하겠습니다. Controller API 스펙, Service의 기존 비즈니스 규칙, 예외 처리 흐름, 관리자 토큰 기반 접근 제어, 현재 패키지 구조는 유지하겠습니다. 이번 단계에서는 사용자 인증/인가 구조를 새로 만들거나 UI 연동을 확인하지 않고, 기존 기능이 유지되는 범위 안에서 DB 접근 방식을 JPA로 바꾸는 데 집중하겠습니다.

docs/jpa-mission/1단계-JPA-전환.md

@@ -0,0 +1,98 @@
+## 4. 1단계 - JPA 전환
+
+평가 대기
+
+제출 완료2026. 6. 21. 제출
+
+# 1단계: JPA 전환
+
+JdbcTemplate Repository를 JPA Repository로 전면 교체하고, 도메인 간 연관관계를 객체 그래프로 표현하며, 영속성 컨텍스트의 동작을 직접 관찰합니다.
+
+이 미션에서 분량이 가장 큰 단계입니다. 매핑·연관관계·영속성 컨텍스트가 한꺼번에 등장하니 페이스를 잡을 때 가장 무거운 단계로 의식하면 좋습니다.
+
+> **들어가기 전 자기 진단**
+
+Q. 본인 코드의 Repository에서 가장 자주 등장하는 SQL 패턴은 무엇인가요?
+
+Theme, ReservationTime, ReservationDate처럼 독립적인 도메인은 insert, select by id, find all, delete, exists 같은 단순 SQL이 자주 등장했습니다. 반면 Reservation과 WaitingReservation은 reservation\_date, reservation\_time, theme 테이블을 JOIN해서 한 번에 조회한 뒤, RowMapper에서 ReservationDate, ReservationTime, Theme 객체로 직접 조립하는 패턴이 반복됩니다.
+
+Q. 객체 참조로 옮겼을 때 더 자연스러워지는 곳은 어디인가요?
+
+객체 참조로 옮겼을 때 가장 자연스러워지는 곳은 Reservation이 ReservationDate, ReservationTime, Theme를 참조하는 부분입니다. 기존 DB 테이블은 date\_id, time\_id, theme\_id 외래 키만 가지고 있지만, Java 도메인 객체는 이미 날짜, 시간, 테마를 객체로 들고 있어 연관관계 매핑하면 reservation.getTime().getStartAt(), reservation.getTheme().getName()처럼 객체 그래프로 접근하는 방식이 더 자연스러워집니다.
+* * *
+
+## 1-1. 매핑 변환
+
+다른 클래스에 의존하지 않는 클래스부터 시작합니다 — `Theme`, `ReservationTime` 등.
+
+### 요구사항
+-   `build.gradle`: `spring-boot-starter-jdbc` → `spring-boot-starter-data-jpa` 대체
+-   `@Entity`, `@Id`, `@GeneratedValue(strategy = IDENTITY)` 부여
+-   `JpaRepository<T, Long>` 인터페이스 작성, 기존 JdbcTemplate 기반 Repository 제거
+-   `KeyHolder`, `SimpleJdbcInsert` 같은 JdbcTemplate 잔재 제거
+-   `application.properties` 권장 설정:
+
+```properties
+spring.jpa.show-sql=true
+spring.jpa.properties.hibernate.format_sql=true
+spring.jpa.ddl-auto=create-drop
+spring.jpa.defer-datasource-initialization=true
+```
+
+> **양쪽 시도 시 비교 관찰 포인트**: ① 시작 시 발행되는 DDL의 차이 ② 재시작 시 데이터 보존 여부 ③ 컬럼명·타입을 entity로만 제어할 수 있는지. 이 셋이 안 보이면 그냥 양쪽 다 돌려봤을 뿐 차이는 못 봤다는 신호입니다.
+
+### 확인 과제
+
+Q. 예약 생성 시 콘솔에 찍히는 INSERT SQL이 방탈출 미션과 어떻게 같고 어떻게 다른가요?
+
+\`\`\` Hibernate: insert into reservation (date\_id, name, theme\_id, time\_id, id) \`\`\` 같은 점은 \`reservation\` 테이블에 예약자 이름, 날짜 id, 시간 id, 테마 id를 저장한다는 점입니다. 둘 다 DB에는 외래 키 값이 들어갑니다. 다른 점은 컬럼 순서가 기존 SQL의 \`name, date\_id, time\_id, theme\_id\`와 다르게 \`date\_id, name, theme\_id, time\_id, id\`처럼 찍혔고, \`id\`는 \`IDENTITY\` 전략에 따라 DB가 생성하도록 \`default\`로 처리된 것 입니다. 또 하나의 차이는 쓰기 지연입니다. JDBC에서는 예약 삭제 후 같은 슬롯의 대기를 승격할 때 DELETE가 즉시 실행되어 기존 슬롯이 바로 비었습니다. JPA에서는 DELETE와 INSERT가 영속성 컨텍스트에 모였다가 flush 시점에 동기화되면서, Hibernate 내부 ActionQueue에 따라서 INSERT가 먼저 처리될 수 있고, 실제로 발생하여 UNIQUE 제약에 걸렸습니다. 그래서 예약 취소/변경 후 대기 승격 전에 \`reservationRepository.flush()\`를 호출해 기존 슬롯을 먼저 DB에 반영하도록 조정했습니다.
+* * *
+
+## 1-2. 연관관계 매핑
+
+다른 클래스에 의존하는 클래스에 연관관계를 매핑합니다. 예: `Reservation`은 `Member`, `Theme`, `ReservationTime`을 참조합니다.
+
+### 요구사항
+-   `@ManyToOne` + `@JoinColumn(name = "..._id")`로 객체 참조
+-   **단방향으로 시작**합니다. 양방향이 필요한 이유가 생기면 그때 추가합니다.
+-   양방향 시도 시 **연관관계 주인** 명시, 무한 직렬화 가능성 검토.
+-   `cascade`, `orphanRemoval`은 **필요해질 때까지 적용하지 않습니다**. 적용한다면 PR 본문에 그 근거를 적습니다.
+
+> 양방향 또는 cascade를 한 번 시도했다가 단방향/제거로 후퇴하는 사이클을 의식적으로 한 번 굴려봅니다. 시도와 후퇴를 기록에 남기는 것이 차원 B(설계 판단)의 도달점입니다.
+
+### 확인 과제
+
+Q. \`findById(reservationId).getTime().getStartAt()\`이 발행하는 SQL을 적어주세요.
+
+Hibernate: select r1\_0.id,r1\_0.date\_id,r1\_0.name,r1\_0.theme\_id,r1\_0.time\_id from reservation r1\_0 where r1\_0.id=? Hibernate: select rt1\_0.id,rt1\_0.start\_at from reservation\_time rt1\_0 where rt1\_0.id=?
+* * *
+
+## 1-3. 영속성 컨텍스트 관찰
+
+코드를 추가하기보다 **관찰**합니다. JPA가 자동으로 무엇을 하는지 직접 봅니다.
+
+**이 미션의 본질 6개 중 영속성 컨텍스트가 가장 깊이 박히는 자리입니다.**
+
+| 관찰 대상 | 어떤 코드로 확인하는가 | 무엇을 본다 |
+| --- | --- | --- |
+| **dirty checking** | `@Transactional` 메서드에서 entity 필드 수정 후 save 미호출 | commit 시점에 UPDATE 자동 발행 |
+| **1차 캐시** | 같은 트랜잭션에서 `findById` 두 번 호출 | 두 번째 SELECT 생략 (1차 캐시 적중) |
+| **쓰기 지연** | `save` 호출 후 `flush` 전·후의 DB 상태 비교 | INSERT가 commit/flush 시점에 일괄 발행 |
+| **flush 시점** | 명시적 `flush` 호출 / 트랜잭션 종료 / JPQL 실행 직전 | 영속성 컨텍스트 → DB 동기화 트리거 |
+| **fetch 기본값** | `@ManyToOne` vs `@OneToMany` 무명시 시 | EAGER vs LAZY 차이 |
+| `LazyInitializationException` | 트랜잭션 밖에서 LAZY 필드 접근 | 영속성 컨텍스트 닫힌 후 프록시 미초기화 |
+
+### 관찰 과제 1: 영속성 컨텍스트 신호 캡처
+
+위 6개를 직접 만들어 기록에 남길수록 영속성 컨텍스트가 손에 잡힙니다. 관찰을 적을 때 다음 4가지가 함께 있으면 미션 끝난 후 가장 강한 회상 재료가 됩니다.
+
+```
+1. 시도한 코드
+2. 예측한 SQL/동작
+3. 실제 SQL/동작
+4. 왜 다른가
+```
+
+예측과 실제 사이의 갭이 보이는 순간이 본 미션의 핵심 학습 신호입니다.
+
+> 관찰 과제 2(N+1과 fetch join 비교)는 3단계에서 본격적으로 등장합니다. 1단계에서는 LazyInit을 만나는 것으로도 영속성 컨텍스트의 경계가 보입니다.

docs/jpa-mission/2단계-내-예약-목록-조회-기능.md

@@ -0,0 +1,30 @@
+## 5. 2단계 - 내 예약 목록
+
+평가 대기
+
+제출 완료2026. 6. 22. 제출
+
+# 2단계: 내 예약 목록 조회 기능
+
+내 예약 목록 조회 API를 추가합니다. **쿼리 메서드 도입의 벽**을 만나는 단계입니다.
+
+> **들어가기 전 자기 진단**
+
+Q. 내 예약 목록 조회를 풀 때, 메서드 이름 쿼리(\`findByMemberId\`)와 JPQL(\`@Query\`) 중 어느 쪽이 먼저 떠오르나요? 그 직감의 근거는 무엇인가요?
+
+처음에는 단순히 \`findByName\`으로 예약을 조회한 뒤 Java 코드에서 지난 예약을 제외하는 방식도 떠올릴 수 있다고 생각했습니다. 하지만 요구사항은 화면에 유효한 예약 목록만 보여주는 것이고, 유효 여부는 예약 날짜와 시간처럼 DB가 이미 가지고 있는 값으로 판단할 수 있습니다. 그래서 모든 예약을 가져와 애플리케이션에서 필터링하기보다는 DB에서 먼저 조건을 걸어 가져오는 편이 더 적절하다고 판단했습니다. 다만 이 조회는 단순히 이름으로만 찾는 문제가 아니었습니다. 오늘 이후 예약이거나, 오늘 예약이라면 현재 시간 이후인 예약만 조회해야 하므로 날짜와 시간 조건이 함께 필요했습니다. 또한 응답을 만들 때 예약의 날짜, 시간, 테마에 접근하므로 LAZY 연관관계에서 N+1이 발생할 수 있다는 점도 함께 고려해야 했습니다. 그래서 지금 기준으로는 조건의 의도를 명확히 드러내기 위해 JPQL이 먼저 떠오릅니다. 다만 JPQL을 쓴다고 N+1이 자동으로 해결되는 것은 아니므로, 응답 생성에 필요한 연관 객체는 \`@EntityGraph\`로 함께 로딩하는 방향이 더 적절하다고 생각합니다.
+
+## 요구사항
+
+### API
+-   `GET /reservations-mine` — 본인의 예약 목록
+
+### 확인 과제
+
+Q. 메서드 이름 쿼리·JPQL 중 어느 것을 썼나요?
+
+저는 JPQL(\`@Query\`)과 \`@EntityGraph\`를 함께 사용했습니다. JPQL은 예약 날짜가 오늘 이후이거나, 오늘 예약이라면 현재 시간 이후인 예약만 조회한다는 조건을 명확하게 표현하기 위해 사용했습니다. 메서드 이름 쿼리로도 어느 정도 표현할 수 있지만, 날짜와 시간 조건이 함께 묶이는 순간 메서드명이 길어지고 의도가 흐려진다고 느꼈습니다. 반면 연관 엔티티 로딩은 JPQL의 \`join fetch\`가 아니라 \`@EntityGraph\`로 분리했습니다. 이 API의 응답에는 날짜, 시간, 테마 정보가 필요하므로 해당 연관 객체를 함께 로딩해야 합니다. 하지만 저는 조회 조건과 로딩 범위를 한 JPQL 안에 모두 넣기보다는, JPQL은 조건을 표현하고 \`@EntityGraph\`는 필요한 객체 그래프를 표현하도록 나누는 편이 동작 의도, 변경에 강한 구조, 가독성 측면에서 더 낫다고 판단했습니다.
+
+Q. 그 결정의 한계는 무엇인가요?
+
+이 결정의 한계는 JPQL과 \`@EntityGraph\`가 모두 문자열 기반이라는 점입니다. 엔티티 필드명이 변경되면 Java 코드처럼 컴파일 시점에 바로 잡히지 않고, 실행 시점이나 쿼리 검증 시점에 오류를 발견할 수 있습니다. 그럼에도 JPQL과 \`@EntityGraph\`를 함께 사용한 이유는 역할을 분리해서 읽을 수 있기 때문입니다. 복잡한 조건은 메서드 이름처럼 선형적인 구조보다 JPQL의 괄호와 조건식으로 표현하는 편이 이해하기 쉽다고 생각했습니다. 반면 N+1을 줄이기 위한 로딩 범위는 \`@EntityGraph\`로 분리하면, 조회 조건과 객체 로딩 책임을 따로 볼 수 있어 가독성이 좋아진다고 판단했습니다. 페이징이 필요해질 경우에는 다시 확인이 필요합니다. 현재처럼 \`ManyToOne\` 연관 객체를 함께 로딩하는 정도는 비교적 안전하지만, \`OneToMany\` 같은 컬렉션을 함께 로딩하면 row 중복과 count query 문제가 생길 수 있습니다. 따라서 페이징이 들어오면 실제 SQL과 count query를 확인하면서 조회 방식을 다시 점검해야 한다고 생각합니다.