[🌱 JPA 방탈출 예약 대기] 모카(최영철) 미션 제출합니다.

README.md

@@ -19,8 +19,11 @@
 - `Waiting` — 그 슬롯을 기다리는 줄. 순번을 가진다.
 - `Waitings` — 대기들의 일급 컬렉션. 순번 부여·중복 검증·재정렬 같은 비즈니스 규칙을 소유한다.
 
-예약이 취소되면 슬롯이 비고, 첫 대기가 예약으로 승격된다.
-`reservation` 테이블에는 `UNIQUE(date, time_id, theme_id)`, `waiting` 테이블에는 `UNIQUE(date, time_id, theme_id, name)` 제약을 둔다.
+예약이 취소되면 슬롯이 비고, 첫 대기가 예약으로 승격된다.   
+reservation 테이블에는 UNIQUE(date, time_id, theme_id), waiting 테이블에는 UNIQUE(date, time_id, theme_id, name)(같은 사람 중복 대기 방어)과
+UNIQUE(date, time_id, theme_id, order_index)(순번 충돌 방어)를 둔다. 전자는 모델이 바뀌어도 남는 도메인 불변식, 후자는 저장된 순번 모델에 종속된 제약이다.
+
+
 
 > 통합 모델(status 컬럼)·절충 모델(FK 참조) 대신 분리 모델을 택한 자세한 근거는 PR 본문에 포함.
 
@@ -184,3 +187,35 @@
 - [x] 예약 페이지(`reservations.html`)에 예약/대기 상태 렌더링
 - [x] 내 예약 페이지(`my-reservations.html`) 예약/대기 상태 렌더링
 - [x] 각 케이스 요구사항 테스트 추가
+
+## 트랜잭션 경계와 그 근거
+
+두 흐름을 각각 하나의 트랜잭션으로 묶는다.    
+묶는 기준은 "부분 실패 시 어떤 깨진 상태가 남는가"로 도출.
+어느 단계가 실패해도 데이터 모순 + 사용자에게 보이는 깨진 약속이 남으면, 그 작업들은 함께여야 한다.
+
+### 예약 취소 → 자동 승격 (`deleteByOwner` , 두 테이블 4종 변경)
+
+[1] reservation DELETE(취소자) → [2] reservation INSERT(승격자) → [3] waiting DELETE(승격된 1번) → [4] order_index UPDATE×N(나머지
+당기기)
+
+- **[2] 실패([1]만 성공)** — 취소자 예약은 사라졌는데 승격이 안 됨 → 슬롯이 텅 빔. 1번 대기자는 목록엔 "대기 1번"인데 슬롯은 예약 가능 상태 → 누구나 새로 예약해 기존 1번을 추월. 가장
+  망가지는 시나리오.
+- **[3] 실패([1,2] 성공)** — 승격자가 예약이 됐는데 그의 대기 ROW가 안 지워짐 → 예약자이면서 동시에 대기 1번. 내 목록에 같은 슬롯이 두 줄로 중복 노출.
+- **[4] 실패([1,2,3] 성공)** — 승격은 됐지만 뒷순번이 안 당겨짐 → 순번에 구멍(1 없이 2,3만). 이후 그 슬롯 대기 신청이 충돌(500).
+
+→ 셋 다 데이터 모순 + 깨진 약속이므로 4종을 한 경계로 묶는다.
+
+### 대기 취소 → 순번 재정렬 (`cancelByOwner` · waiting 한 테이블 2종 변경)
+
+[1] waiting DELETE(취소 대상) → [2] order_index UPDATE×N(뒤 순번 당기기)
+
+- **[2] 실패([1]만 성공)** — 대기는 빠졌는데 재정렬이 안 됨 → 순번에 구멍([1,2,3]에서 2 취소 시 [1,3]). 3번이던 사람이 계속 "대기 3번"인데 앞엔 1명뿐 → 표시 순번과 실제 줄
+  길이 불일치. 이후 그 슬롯 신청이 충돌(500).
+
+→ 2종을 한 경계로 묶는다.
+
+### 검증
+
+이 깨진 상태들은 각 단계가 실패할 때 생기지만 **모두 하나의 `@Transactional` 경계가 막는다.** 따라서 검증은 쌓인 변경이 가장 많은 [4](재정렬) 실패 하나로 대표하고(같은 회귀를 중복 검증하지
+않음), 나머지 끝 상태는 이 문서로 남긴다. → `ReservationPromotionTransactionTest`, `WaitingCancelTransactionTest`.

build.gradle

@@ -20,7 +20,7 @@ dependencies {
     implementation 'org.springframework.boot:spring-boot-starter'
     implementation 'org.springframework.boot:spring-boot-starter-web'
     implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
-    implementation 'org.springframework.boot:spring-boot-starter-jdbc'
+    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
     implementation 'org.springframework.boot:spring-boot-starter-validation'
 
     implementation 'io.jsonwebtoken:jjwt-api:0.11.2'

docs/00-overview.md

@@ -0,0 +1,166 @@
+# 00 · 미션 개요 & 학습 방향
+
+> JPA 전환 + 예약 대기 미션의 큰 그림. 이 문서는 큰 그림을 잡는 단계에서 작성하고, 단계가 진행되며 갱신한다.
+> 🖊️ 가이드 블록(이 인용문들)은 초안용. 완성 시 지워도 됨.
+
+---
+
+## 메타
+
+| 항목           | 값                                     |
+|--------------|---------------------------------------|
+| 저장소          | `softmoca/spring-roomescape-waiting`  |
+| 시작 브랜치       | `step2` (JdbcTemplate 방탈출 코드)         |
+| 작업 브랜치       | `step3-jpa`                           |
+| 단일 PR 마감     | 06-18(목) 18:00                        |
+| JPA 설계 토론    | 06-19(금) 10:40~11:30, 강의장             |
+| 자기점검·사후설문 마감 | 06-22(월) 18:00                        |
+| 커밋 표기        | `[1단계] 매핑 변환` 식 단계 prefix (PR 본문 경계용) |
+
+---
+
+## 이 미션의 본질
+
+새 라이브러리 사용법 암기가 아니라 **내 어노테이션 한 줄이 만드는 실제 SQL을 추적**하는 미션. JPA가 자동화한 만큼 감춰진 SQL을, 내 JDBC 코드를 객체 그래프로 옮기며 다시 눈에 보이게 만든다. "
+내가 쓴 SQL = 나가는 SQL"이던 JDBC의 투명성을 자동화와 맞바꾼 비용을 손으로 만진다.
+
+> 자동으로 무엇이 일어나는지 모르면 의도와 다른 SQL이 나가도 그 사실 자체를 모른다. 무엇이 어디로 옮겨가고 무엇이 새로 생기는지 **내 코드 위에서** 본다.
+
+## 학습 목표 (LMS)
+
+- JdbcTemplate ↔ JPA 표현력 차이를 내 코드 위에서 비교
+- 영속성 컨텍스트(1차 캐시·dirty checking·쓰기 지연·flush·fetch) 직접 관찰 + 발행 SQL 추적
+- 연관관계 결정(단/양방향·페치·cascade·orphanRemoval)의 근거·한계 설명
+- N+1 발견 + fetch join·`@EntityGraph`·JPQL 비교
+- 트랜잭션 경계·동시성 의식하며 도메인 로직(자동 승인) 위치 결정
+
+---
+
+## 진행 방식 & 1주 흐름
+
+1주 미션, 별도 OT 없음. **사전학습 → 0~4단계 본인 페이스 → PR → JPA 설계 토론 → 자기점검** 순.
+
+| 일                | 활동                                  |
+|------------------|-------------------------------------|
+| 월                | LMS·사전학습 통독 → 방탈출 코드 동작 확인 → 0단계 시작 |
+| 화~목              | 0~4단계 본인 페이스 (커밋·푸시)                |
+| **목 18:00**      | **PR 제출 (마감)**                      |
+| 금                | JPA 설계 토론 (10:40~11:30, 강의장)        |
+| 토~일              | 자기점검 + LMS+ 산출물 작성                  |
+| **다음 주 월 18:00** | **자기점검 + LMS+ 산출물 마감**              |
+
+- **단계 권장 종료선 없음** — 가는 만큼 본다. 4단계까지 못 가도 PR 본문에 "어디까지 만들고 무엇이 남았는지" 적으면 됨.
+- 깊이·분량·양식·페이스는 자율. 운영 기본 틀은 둘뿐: **① 첫 PR 1회(목 18:00)** **② 자기점검+사후설문(다음 주 월 18:00)**.
+
+### PR은 1회만
+
+5단계로 나뉘지만 PR은 종료 시 1회. 단계별로 커밋·푸시(`[1단계]…` prefix)하고 마지막에 통합 PR. PR 본문 = 0~4단계 도달 지점의 **결정·SQL·한계 통합 정리**. 막힘은 짧은 사이클
+채널(기록·동료)에 흘려보낸다.
+
+### 산출물
+
+| 단계      | 시점      | 항목                                  |
+|---------|---------|-------------------------------------|
+| 사전 설문   | 시작 전    | 도달 상태·JPA 경험·목표·마친 후 모습 (↓ 내 답변)    |
+| 단계별 응답  | 단계마다    | 0~4단계 자기진단·확인 과제 폼 총 16개 (도달한 단계까지) |
+| 첫 PR 1회 | 목 18:00 | 통합 PR (발행 SQL·망설인 결정·흔들린 장면이 토론 재료) |
+| 자기점검    | 월 18:00 | 4영역(매핑/설계 판단/피드백 순환/종합) — 회고용       |
+| 사후 설문   | 자기점검 직후 | 사전설문과 비교하며 작성                       |
+| AI 인터뷰  | 종료 후    | 별도 안내                               |
+
+> **API 명세는 고정.** 명세를 바꾸면 JDBC↔JPA SQL 비교가 흐려진다.
+
+---
+
+## 코치가 보는 3차원 (이 docs의 설계 축)
+
+| 차원             | 무엇을 보나                      | 이 docs의 어디서 회수되나            |
+|----------------|-----------------------------|-----------------------------|
+| **A — 매핑 정확성** | 어노테이션 → 발행 SQL을 추적했는가       | 각 단계 `SQL 관찰 로그` (예측 vs 실제) |
+| **B — 설계 판단**  | 대안 비교·근거·한계를 말할 수 있는가       | 각 단계 `결정 기록` + `06 설계 토론`   |
+| **C — 피드백 순환** | SQL 로그·예외·테스트·리뷰·토론을 살려 썼는가 | 각 단계 `피드백 채널 신호`            |
+
+> 🖊️ 각 단계 문서의 결정·인사이트 끝에 `(A)`/`(B)`/`(C)` 태그를 달아두면, 06(토론 결정 3개)·07(자기점검 4영역)·단일 PR 본문이 자동으로 조립된다. (인증인가 미션에서 06이 step
+> 문서를 당겨왔던 그 흐름)
+
+---
+
+## 내 출발점
+
+### 사전설문 (시작 전 기록 — 사후설문과 비교용)
+
+**Q. JPA 경험은?**
+토이 프로젝트에서 2년 이상.
+
+**Q. 미션 목표(얻고 싶은 것)?**
+우테코 오기 전에는 JPA의 추상화를 전혀 의식하지 않고 "편한 스택"으로만 썼다. N+1도 "해결법을 외운" 수준이었지, 내 코드 어느 지점에서 왜 터지는지는 보지 못했다. 그렇게 쓰는 건 — 내 어노테이션 한
+줄이 어떤 SQL을 던지는지조차 모른 채 '잘 돌아가니 괜찮다'고 믿는 위험한 상태다. 이번 미션에서 얻고 싶은 건 그 자동화의 비용을 직접 만져보고, **내가 작성한 매핑·연관관계 결정이 실제 어떤 SQL·동작을
+만드는지 설명할 수 있는 힘**, 그리고 그 SQL을 근거로 연관관계·페치 전략 결정의 **한계까지 말할 수 있게** 되는 것.
+
+**Q. 마친 후 바라는 모습?**
+어노테이션·연관관계 매핑을 볼 때 "JPA가 알아서 해준다"로 넘기지 않고 **발행할 SQL의 모양이 먼저 떠오르는** 상태. N+1을 "해결법을 아는 문제"가 아니라 "내 코드 어느 줄에서 터지는지 보이는 문제"로
+보고, LAZY·추가 쿼리가 생기는 지점을 직접 추적. 단/양방향·EAGER vs LAZY·fetch join vs `@EntityGraph`·트랜잭션 경계를 관행이 아니라 **각 선택이 만들 SQL과 한계 근거로
+** 설명.
+
+### 코드 상태 (step2)
+
+- 헥사고날 (`adapter/persistence` ↔ `domain/repository` 포트 ↔ `application` ↔ `adapter/web`)
+- **member 테이블 없음** — 예약자는 `name VARCHAR` 컬럼 (별도 객체 아님)
+- reservation / waiting **분리 모델**, `UNIQUE(date, time_id, theme_id, name)`
+- 조회 핵심 경로는 **3중 조인 SQL 직접 박음** (reservation INNER JOIN reservation_time INNER JOIN theme)
+- `waiting.order_index` = FIFO 순번을 저장해 둔 materialized 파생값
+
+---
+
+## 0단계 — 변경/유지 경계
+
+**바꿀 것**: `build.gradle`(jdbc→data-jpa) · `adapter/persistence`의 Jdbc 구현 4개(RowMapper·KeyHolder·수기 SQL 제거) · `domain` 객체
+매핑(`@Entity`/`@Id`/`@GeneratedValue`/`@ManyToOne`, protected 기본 생성자 추가) · UPDATE 메서드(dirty checking 검토) ·
+`application.properties`/DDL 설정.
+
+**유지할 것**: `adapter/web` 컨트롤러·DTO(API 명세 고정) · `application` 서비스·`@Transactional` 경계 · `exception` 계층·도메인 규칙/정책 · 분리
+모델 + UNIQUE 제약 · `data.sql`.
+
+**경계의 핵심 결정 (확정 대기)**: 도메인 객체에 직접 `@Entity` vs 순수 도메인 + 별도 JPA 엔티티 분리. → 이번 미션은 **영속성 컨텍스트 관찰(1-3)을 살리기 위해 직접 매핑** 쪽으로
+잠정. 엔티티를 분리해 경계에서 변환하면 entity가 즉시 detach되어 dirty checking·LAZY가 가려지기 때문. (헥사고날 순수성 일부 양보 = 의도된 범위 한정, PR에 명시)
+
+> 🖊️ 이 결정은 1단계 진입 시 최종 확정. 확정 후 이 문단 갱신.
+
+---
+
+## 대화 로드맵 (대화 단위 ↔ 산출물)
+
+| 대화       | 산출물                          |
+|----------|------------------------------|
+| 학습 방향·개념 | `00-overview`, `01-concepts` |
+| 1단계      | `02-step1-jpa-mapping`       |
+| 2단계      | `03-step2-my-reservations`   |
+| 3단계      | `04-step3-waiting`           |
+| 4단계      | `05-step4-waiting-admin`     |
+| 토론 준비    | `06-design-discussion`       |
+| 자기점검·PR  | `07-self-check`              |
+
+> 단계 진입 시: 해당 step 문서를 먼저 열어 **"전환 전(JDBC)" 확정 → 구현 → "전환 후·SQL 관찰" 채움** 순으로 진행. 대화가 바뀌어도 docs를 읽고 시작하면 흐름이 안 끊긴다.
+
+## docs 구조
+
+```
+docs/
+├── 00-overview.md              # (이 문서) 개요·학습 방향·차원 매핑·로드맵·0단계 경계
+├── 01-concepts.md              # 사전학습: 영상·4질문 가설·키워드 정의·코드 다시 읽기·참조 매뉴얼
+├── 02-step1-jpa-mapping.md     # 1단계: 1-1 매핑 / 1-2 연관관계 / 1-3 영속성 컨텍스트 관찰
+├── 03-step2-my-reservations.md # 2단계: 내 예약 목록 (메서드 쿼리 vs JPQL)
+├── 04-step3-waiting.md         # 3단계: 3-1 N+1·fetch join / 3-2 JPQL rank
+├── 05-step4-waiting-admin.md   # 4단계: 어드민·자동 승인·트랜잭션 경계·flush 순서
+├── 06-design-discussion.md     # JPA 설계 토론 준비 (결정 3개 + 한계)
+└── 07-self-check.md            # 자기점검 4영역 + 단일 PR 본문 종합
+```
+
+(별도 `decisions/` ADR 폴더 없음 — 결정 기록은 각 step 문서에 인라인. 인증인가 때 분리 폴더가 비어버린 교훈.)
+
+## 진행 원칙
+
+- **도달한 만큼을 본다** — 미완은 부끄러워하지 말고 정확히 적는다(미완 정확 기록 = 핵심 신호).
+- **단일 PR** — 단계별 커밋·푸시, 마지막에 통합 PR 1회.
+- **API 명세 고정** — 명세를 바꾸면 JDBC↔JPA SQL 비교가 흐려진다.
+- **문서량 자랑 경계** — SQL 관찰 로그는 두껍게, 산문은 짧게.