[🌱 JPA 방탈출 예약 대기] 모카(최영철) 미션 제출합니다. by softmoca · Pull Request #579 · woowacourse/spring-roomescape-waiting

softmoca · 2026-06-18T08:19:53Z

체크 리스트

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

베이스 코드 선택 체크

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

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

0단계 — 범위

시작 브랜치: step2 / 작업 브랜치: step3-jpa
건드린 범위: adapter/persistence(어댑터·*JpaRepository) + domain(엔티티 4종 매핑 어노테이션) + 설정(ddl-auto=create-drop·SQL 로깅)
유지(불변): adapter/web·application(API 명세·DTO)·도메인 정책·예외 계층·reservation/waiting 분리 모델 — 0단계 "재구현 금지" 준수

단계별 도달 지점

1단계 ✅ 매핑(Theme·ReservationTime) → 연관관계(Reservation·Waiting 단방향 @ManyToOne) → 영속성 컨텍스트 6관찰(dirty checking·1차캐시·쓰기지연·flush·fetch기본·LazyInit)
2단계 ✅ 내 예약 목록 — name 유지 + 메서드 이름 파생 쿼리(기능은 1-2에서 충족, mine N+1 관찰)
3단계 ✅ 3-1 N+1 → @EntityGraph fetch join(mine 8→2) / 3-2 순번 — order_index 유지(JPQL rank 비교 후)
4단계 ✅ 자동 승인 — 단일 @Transactional + flush 순서 실측

발행 SQL 발췌 (예측-실제 갭이 가장 큰 것)

1) "EAGER면 항상 join"의 반례 — findById는 join fetch, findByName(파생)은 N+1

@EntityGraph 전: mine 경로 예약2+대기2 = 8 SELECT(main + 연관별 보조)
@EntityGraph 후: 단일 INNER JOIN = 2 SELECT

2) 자동 승인 flush 순서 — 트랜잭션 경계가 아니라 명시 flush가 delete-before-insert를 만든다
DELETE reservation → INSERT reservation → DELETE waiting → UPDATE waiting
flush 없으면 액션큐(INSERT→UPDATE→DELETE)가 재정렬 → 같은 슬롯 UNIQUE 충돌.

망설인 결정 1~2개

order_index 유지 vs JPQL rank: 둘 다 실행 후 유지(UNIQUE 방어선·승급 통합). JPQL rank는 미션 후 부기 제거 리팩터링 1순위.
fetch 전략: EAGER 유지하다 LAZY+@EntityGraph로 전환(기본값→문제→해결).

흔들린 한 장면

LAZY 전환 직후 ReservationServiceTest 3건이 LazyInitializationException — 1-3 ⑥에서 "reads tx-free + LAZY면 터진다"고 미리 적어둔 좌표가 실제 read 경로에서 그대로 터졌고, @EntityGraph로 닫았다. OSIV가 admin 경로만 가려준 것도 그때 드러남.

명시적 비결정 (Level 3 범위)

동시성·락(동시 취소·승급의 재번호 경쟁·중복 승급)은 이번 사이클(JPA 전환) 범위 밖 — 레이스 재현→비관적 락→격리 비교 아크로 분리. 현재는 UNIQUE 제약이 최악(중복 예약)만 방어.

@primary

FutureOnlyPolicy와 RecentWeekPopularPolicy가 생성자에서 Clock.systemDefaultZone()을 직접 만드는 숨은 의존성을 갖고 있어, 테스트에서 시계를 고정하려면 운영과 규칙이 같은 미러 클래스를 따로 둬야 했다. 이 우회 때문에 미러가 세 곳에 중복됐다 (FixedClockConfig.FixedClockPolicy, TestRecentWeekPopularPolicy,FutureOnlyPolicyTest.TestablePolicy). 두 운영 정책이 Clock을 생성자로 주입받게 바꾸고 운영 Clock 빈을추가했다. 테스트 고정 시계 설정은 미러 대신 운영 클래스를 그대로 생성(new FutureOnlyPolicy(fixed))해 @primary로 올린다. 시계 고정을 정책 빈단위로 캡슐화하므로, FixedClockConfig(05-13)와 FixedPopularPolicyConfig(05-09)가 각각 @primary Clock을 등록할 때 생기는 충돌도 구조적으로 없다. 결과적으로 테스트가 검증하는 규칙이 운영이 실제 쓰는 규칙과 같아지고, 미러 약 3개가 사라진다. 운영: - FutureOnlyPolicy: 생성자에서 Clock 주입받도록 변경 - RecentWeekPopularPolicy: 생성자에서 Clock 주입받도록 변경 - ClockConfig 추가: 운영 Clock 빈(systemDefaultZone) 등록 테스트: - FixedClockConfig: 미러 FixedClockPolicy 제거, new FutureOnlyPolicy(fixed) 사용 - FixedPopularPolicyConfig: new RecentWeekPopularPolicy(fixed) 사용 - TestRecentWeekPopularPolicy 삭제 - FutureOnlyPolicyTest: 미러 TestablePolicy 제거, 운영 FutureOnlyPolicy 직접 검증

"예약 시점이 어떤 기준 시각보다 이후인가"라는 비교는 지금까지 정책 (FutureOnlyPolicy) 내부에 !date.atTime(time).isAfter(now) 형태로 숨어 있었다. 하지만 이 비교는 외부 상태·시계에 의존하지 않고 입력(날짜·시간)과 기준 시각만으로 결정되는 순수한 사실이므로, 도메인이 자기 책임으로 가져야 한다. 날짜+시작시각을 묶은 값 객체 ReservationDateTime을 도입하고, 순수 비교 startsAfter(moment)를 부여한다. 의도적으로 Clock을 갖지 않는다 — 기준 시각을 인자로 받는 비교라야 시계 없이 결정적으로 테스트되고, 도메인이 "지금이 몇 시인지"라는 환경 의존성을 다시 떠안지 않는다. 경계 규칙: 같은 순간은 '이후'가 아니다(false). "동일 시각을 허용할지 거부할지"는 이 비교 위에서 정책이 내리는 판정으로 남긴다. 단위 테스트는 DB·스프링·정책 없이 다섯 경계(이전 날짜/같은 날 이전 시각/동일 순간/같은 날 이후 시각/이후 날짜)를 입력만으로 검증한다.

기존 PolicyCollaboration은 RecordingPolicy로 "policy.validateCreatable을 호출했는가"(creatableCalled)를 단언했다. 이는 Mockito를 안 썼을 뿐 본질적으로 호출을 보는 행위 검증이라 런던파에 가깝다. 우리가 단위의 기준으로 삼는 고전파는 "외부 의존(DB·HTTP·시계)을 격리하되 협력자는 실제 객체를 쓰고, 결과(상태)를 본다". FutureOnlyPolicy는 협력자이지 외부 의존이 아니고, Clock 주입으로 시간 결정성을 확보했으므로 충분히 격리된 실제 객체로 쓸 수 있다. 그래서 수동 스텁 RecordingPolicy·RejectingPolicy를 삭제하고, 고정 Clock을 주입한 실제 FutureOnlyPolicy로 "거부 시점이면 생성이 실패하고, 허용 시점이면 생성된다"는 결과만 검증한다. "위임했는가"는 구현 디테일이므로 더 이상 보지 않는다. 메시지·경계는 여기서 단언하지 않는다. 같은 정책이 FutureOnlyPolicyTest에도 쓰이지만 보호 대상이 다르기 때문이다: - FutureOnlyPolicyTest: 규칙의 경계·연산별 메시지 정확성 - 여기: 정책 결과가 create의 성공/실패로 연결되는가 (정책 호출 누락 회귀 방지) 보호 대상이 달라 둘 다 필요하며, 5개 경계를 여기서 반복하지 않으므로 중복도 아니다.

ReservationPolicy의 네 메서드가 (LocalDate, LocalTime) 원시값 대신 ReservationDateTime을 받도록 바꾼다. 이제 책임이 또렷이 갈린다: - 도메인(ReservationDateTime): "내 시점이 기준 시각보다 이후인가"라는 사실 - 정책(FutureOnlyPolicy): "지금"(Clock)을 공급하고, 이후가 아니면 위반으로 판정하며 연산별 메시지를 입히는 조합자 네 호출 지점이 한 타입으로 통일된다. 특히 생성·변경대상은 아직 Reservation 객체가 없는 "예정 슬롯"이라 도메인 객체에 판단을 맡길 수 없었는데, 값 객체를 (date, time)으로 직접 만들 수 있어 자연스럽게 통일된다. 취소·변경은 기존 객체의 reservation.scheduledAt()을 넘긴다. Reservation.create는 값 객체를 만들어 검증한 뒤 생성하므로 "검증 후 생성" 순서가 유지된다. 부수 발견(미러가 가려온 결함): 운영 변경대상 메시지는 "지나간 날짜, 시간..." (쉼표)인데 테스트 미러는 "지나간 날짜·시간..."(가운뎃점)으로 달랐다. Clock 주입으로 운영 클래스를 직접 검증하게 되자 이 드리프트가 드러났다. 운영 메시지(쉼표)로 통일한다. 이것이 미러 제거의 실질 이득 — 테스트가 운영이 실제 쓰는 코드·메시지를 검증하게 된다. 테스트 재분배 및 구성: - 시점 비교의 다섯 경계 → ReservationDateTimeTest로 이동(순수, 가장 빠름) - FutureOnlyPolicyTest는 판정만 검증하고, "무엇을 보호하느냐"로 묶는다: · RejectionMessages — 생성/취소/변경/변경대상의 연산별 메시지(연산마다 다른 것을 대등하게) · AllowAndBoundary — 미래 허용 + '정확히 지금' 거부(네 연산이 공유하므로 대표 하나로) 연산별 nest로 쪼개지 않는다. 허용·경계는 생성 전용이 아니라 공유 메커니즘이고, 단일 테스트 nest는 묶을 것 없이 껍데기만 늘리기 때문이다. 운영 동작은 동일하다(같은 입력에 같은 판정·메시지). 구조와 책임 위치만 바뀐다.

…로 다듬기 JdbcWaitingRepositoryTest만 다른 세 슬라이스(Reservation/Theme/ReservationTime)와 달리 단순 CRUD까지 검증하고 있었다. save 단건, deleteById·findById 단건을 별도 테스트로 들고 있었는데, 이는 "직접 작성한 비단순 SQL만 본다 / save·findById의 해피 패스는 서비스 통합·인수에서 거쳐가니 두껍게 보지 않는다"는 나머지 슬라이스의 원칙과 어긋난다 변경: - save 단건 테스트 제거 — 평범한 INSERT의 해피 패스는 WaitingService 통합·인수 흐름(대기 신청 → 내 목록 조회)이 라운드트립한다. order_index 컬럼이 하나 더 있다는 것만으로 4컬럼 reservation save(이미 제외됨)와 다르게 취급할 근거는 약하다. - deleteById·findById 단건 테스트 제거 — 삭제는 ReservationServiceTest의 자동 승격 (existsWaiting=false)에서, 조회는 순번 갱신 검증에서 이미 거쳐간다. - updateOrderIndex 검증은 유지 — reservation 슬라이스가 updateDateAndTime을 남긴 것과 같은 자리. 직접 작성한 부분 UPDATE의 컬럼명·SET/WHERE 정확성은 SQL을 실제 실행해야만 잡히고, 대기 재정렬의 핵심이다. (여기서 findById는 검증 도구로만 쓴다.) - 남은 검증: findBySlot(정렬+필터+조인) / findByName(다중정렬+필터) / updateOrderIndex. - 클래스 javadoc에 제외 원칙과 "한때 단건까지 들고 있었던 흔적"을 기록해, 네 슬라이스가 같은 기준으로 읽히도록 했다.

@nested

Available 블록(findAvailable 3케이스)이 JdbcReservationTimeRepositoryTest와 같은 SQL 회귀(NOT IN 정확성·테마 경계·빈 상태)를 검증하고 있었다. 네오 피드백의 "검증 가치 × 비용" 두 축으로 보면, 같은 가치를 슬라이스가 더 싸게(@jdbcTest, 톰캣·풀컨텍스트 없음) 그리고 더 넓게(슬라이스는 날짜 경계까지 본다) 사고 있어, 서비스 통합은 같은 회귀를 두 번째로 비싸게 사는 잉여였다. 서비스가 추가로 사던 건 DTO 매핑(stream.map().toList()) 한 줄뿐이고, 이건 회귀 위험이 거의 없다. 토론 규칙 2번("같은 것을 두 번 검증하지 않는다")과 4번("안 하는 것도 결정")에 따라, SQL 회귀는 슬라이스에 일임하고 서비스에서 제거한다. 변경: - Available @nested 블록 전체 제거 (예약된_시간_제외 / 다른_테마는_가능 / 예약_없으면_전부_가능). 동일·상위 검증이 JdbcReservationTimeRepositoryTest에 있다. - 사용하지 않게 된 import 정리 (java.util.List, ReservationTimeResult, assertThat). - 클래스 javadoc 갱신: 남는 검증 대상을 "삭제 거부 정책(서비스만의 예외 전환 협력)"으로 명확히 하고, findAvailable·create·findAll을 "왜 이 자리에서 검증하지 않는지"로 기록. 남는 것 — DeletePolicy 블록만 유지한다. existsByTimeId(boolean)를 받아 예외로 전환하는 의사결정은 슬라이스로 내려갈 수 없는 서비스 고유의 협력이라 이 자리만의 가치가 또렷하다. 블록이 하나만 남는 건 이 서비스가 그만큼 단순하다는 자연스러운 결과이지 검증 부족이 아니다. (create·findAll은 단순 위임이라 처음부터 서비스 통합 대상이 아니었다.)

ReservationServiceTest는 서비스만의 협력(예외 전환·다중 도메인 협력·병합/정렬·분기)을 검증하는 가치 있는 자리지만, 두 가지 검증 모드가 한 파일에 섞여 있으면서 그 기준이 드러나 있지 않아 "왜 어디는 분기를 다 보고 어디는 한 케이스만 보는가"가 흐릿했다. 두 모드를 의식적으로 구분하고 각 블록·테스트에 표시한다: - 모드 A(분기 전부): 회귀가 서비스 안의 로직이라 슬라이스로 못 내려오고 분기 결과가 서로 의미 있게 다를 때. CancelAndPromote, MyReservationsAndWaitings, Update, 그리고 Create의 사전 조회 실패 두 분기. - 모드 B(대표 한 케이스): 같은 회귀를 슬라이스가 더 싸게 이미 사주고 서비스는 "그 검증을 흐름에서 호출하는 협력"만 할 때. Create의 중복 검사·정책 연결. 핵심은 "빠짐없이 다 짠다"가 아니라 "각 회귀를 어디서 가장 싸게 보호할지 정하고 그 결정을 드러낸다"이다. 그 관점에서 조정한 것: - 존재하지_않는_시간 테스트 추가(모드 A). 기존엔 존재하지_않는_테마만 있었다. 시간·테마는 서로 다른 Repository 조회이고 서로 다른 메시지("존재하지 않는 시간입니다." / "...테마입니다.")를 주는 별개 분기라, 한쪽만 두면 다른 쪽 회귀가 샌다. 분기 결과가 다르므로 모드 A로 둘 다 명시한다. - 정상_생성 → 미래_예약_생성으로 의도 명확화(모드 B·정책 통과 측). 기존엔 doesNotThrow만 봐서 "정책이 미래를 통과시킨다"는 의도가 이름·단언에 드러나지 않았다. 반환 결과의 날짜·시간을 단언해 해피패스 산출물을 확인하고, 거부 측(과거_거부)과 짝지어 정책 연결의 양면을 또렷이 한다. - 다른_테마_허용에 "왜 테마 축 한 케이스로 충분한가"(세 축 정확성은 슬라이스가, 여기선 호출 협력만 대표 확인)를 주석으로 명시. 날짜·시간 축을 추가하지 않는 것은 의식적 생략이다. - 클래스 javadoc에 두 모드의 정의와 선택 기준을 박아, 다음에 읽는 사람이 각 자리의 분담을 볼 수 있게 했다. 테스트 개수를 늘리는 게 목적이 아니다(시간 분기 하나만 늘었다). 이미 있던 결정들을 의식적 결정으로 드러내고, 일관성이 비어 있던 한 칸을 채운 것이다.

@disabled

사이클 1에서 WaitingService.create의 분기들을 통합(WaitingServiceTest)과 Mock 단위 (WaitingServiceMockTest) 두 방식으로 짜서 비교했다. 이제 그 비교를 끝내고 한쪽을 메인으로 확정한다 — 둘 다 영구히 활성으로 두면 같은 회귀를 두 자리에서 사는 비용 중복(토론 규칙 2)이기 때문이다. 결론: (B) 통합을 메인으로 둔다. 네 축으로 판단했다. - 셋업 비용: 분기 5개는 셋업 폭발 직전이지만 아직 폭발은 아니고, fixture가 한 줄 셋업이라 통합 준비 비용이 작다. - 실행 비용: Mock이 가볍지만 사이클 1 규모에선 결정적 단점이 아니다. - 회귀 안전성: 통합은 분기 + SQL + 빈 협력을 한 번에 보장한다. Mock으로 가면 SQL은 "리턴한다 치고"라 슬라이스 짝짓기가 필수다(슬라이스는 이미 있어 Mock도 정당화는 됨). - 일관성: 다른 세 서비스가 모두 통합이라, 여기만 Mock이면 검증 스타일이 비대칭이 된다. 분기가 폭발하지 않고 fixture가 가벼우며 일관성 가치가 큰 현재 상태에선 통합이 자연스럽다. 변경: - WaitingServiceMockTest에 @disabled를 붙여 학습 기록으로 park한다. 영구 삭제하기엔 "Mock vs 통합"을 코드로 비교한 학습 가치가 커서 보존하되, 활성 검증에서 빼 비용 중복을 없앤다. 컴파일은 계속 검사되므로 운영 API가 바뀌면 드러난다. - WaitingServiceMockTest 주석 확장: 비교 4축(셋업/실행/회귀 안전성 종류/핀포인트 vs 리팩토링 친화성)과 판단 가이드, create에 적용한 결론(B), "사이클 2에서 다시 본다"를 기록. 트랜잭션 경계는 "결과로 안 보이는 협력"의 전형이라 Mock 가치가 살아날 수 있는 자리라, @transactional을 넣으며 park를 풀지 다시 판단한다. - WaitingServiceTest 주석을 "비교 기준선"에서 "메인 검증 + (B) 결론"으로 갱신. 테스트 동작 변화: WaitingServiceMockTest의 5개 테스트가 실행에서 제외된다(통합이 같은 분기를 커버). 통합·슬라이스·인수는 그대로다.

@entity

JdbcTemplate 기반 Theme·ReservationTime 영속화를 JPA로 전환한다. 연관관계가 없는 1-1 대상(독립 클래스) 둘을 @entity로 직접 매핑하고, 헥사고날 포트는 순수하게 둔 채 JPA 어댑터를 끼운다. ■ 엔티티 매핑 (domain/Theme, domain/ReservationTime) - @entity + @id + @GeneratedValue(strategy = IDENTITY) - final 제거 + protected 기본 생성자 추가(JPA 리플렉션 진입로). 단 정적 팩토리 (create/withId)와 생성자 검증은 유지 → 불변을 통째로 버리지 않고 진입로만 추가. - 컬럼명은 CamelCaseToUnderscoresNamingStrategy 에 위임(startAt→start_at, thumbnailUrl→thumbnail_url). @column 은 제약(nullable/length/unique)만 명시. - withId 는 reservation·waiting 의 Jdbc RowMapper 가 아직 사용하므로 보존. ■ 리포지토리 (adapter/persistence) — 포트 순수 유지 + JPA 어댑터 - 포트(ThemeRepository·ReservationTimeRepository)는 Spring import 0 으로 유지. - ThemeJpaRepository·ReservationTimeJpaRepository(Spring Data) 신설 → CRUD 자동. - ThemeRepositoryAdapter·ReservationTimeRepositoryAdapter 가 포트를 구현, CRUD 는 위임. - 교차 테이블 쿼리는 과도기 처리(아직 reservation 이 엔티티가 아님 → JPQL 불가): · findAvailable → native @query (결과는 ReservationTime 엔티티로 매핑) · findPopularBetween → 기존 JdbcTemplate + POPULAR_ROW_MAPPER 유지 (PopularThemeProjection 이 생성자 기반이라 native 부적합) 1-2 에서 Reservation 엔티티화 후 둘 다 JPQL 로 승격 예정. - 설계 변경: 직전 안내의 "포트를 JpaRepository 로 확장" 권고를 철회. 미엔티티 reservation 을 참조하는 두 쿼리 때문에 포트 확장 시 native+projection 꼼수가 강제됨 → 포트 순수성 보존을 위해 어댑터 방식 채택. - 구 Jdbc 구현(JdbcThemeRepository·JdbcReservationTimeRepository)은 후속 커밋에서 제거. ■ 설정 - build.gradle: spring-boot-starter-jdbc → spring-boot-starter-data-jpa - application.properties(main): ddl-auto=none + show-sql + hibernate.format_sql + logging org.hibernate.SQL=DEBUG / org.hibernate.orm.jdbc.bind=TRACE - application.properties(test): ddl-auto=none 추가 ■ DDL 소유권 — ddl-auto=none + schema.sql 전체 권위 (과도기, 중요) - 처음엔 theme·reservation_time 을 Hibernate(create-drop)가, reservation·waiting 을 schema.sql 이 소유하도록 쪼갰으나 — Hibernate 가 없는 @jdbcTest 슬라이스와 schema.sql 선실행(@SpringBootTest, defer 기본 false)에서 reservation 의 FK 가 아직 없는 reservation_time 을 참조 → ScriptStatementFailedException(63개 실패). - 원인: DDL 소유권 분할은 비-JPA 슬라이스와 양립 불가. - 해결: schema.sql 을 4개 테이블 전체 권위로 복구 + ddl-auto=none(main·test 양쪽). 4개 테이블이 모두 엔티티가 되는 1-2 종료 시 create-drop 으로 전환 예정. - Hibernate 자동 생성 DDL 은 격리 환경(Boot 3.4.4/Hibernate 6/H2)에서 관찰해 문서화. ■ 실측 발행 SQL (격리 관찰, 02 문서에 전문) - DDL: id bigint generated by default as identity(AUTO_INCREMENT 아님), start_at time(6) not null unique(인라인·무명), varchar(30)/varchar(255). - INSERT: insert into theme (description, name, thumbnail_url, id) values (?,?,?,default) · id 가 컬럼에 포함되어 default 로 발행(Hibernate 6, 5와 다름) · 컬럼 순서 = 알파벳순(id 마지막), 선언/손글씨 순서 아님 · IDENTITY 라 save 시점 즉시 INSERT, 바인딩 (n:TYPE) <- [값] 분리 로깅 ■ 테스트 - 삭제 예정(후속 커밋): JdbcThemeRepositoryTest·JdbcReservationTimeRepositoryTest (대상 클래스 제거). JPA 어댑터 슬라이스 테스트는 reservation 엔티티화(1-2) 이후로 이연. - ThemeServiceTest·ReservationTimeServiceTest 는 포트 의존이라 무영향. - 전체 144개 통과(./gradlew test BUILD SUCCESSFUL). ■ 문서 - docs/02-step1-jpa-mapping.md 1-1 대폭 확장: 자기진단 가설, 전환 전/후 코드, 발행 SQL 실측 전문, 관찰①②③(예측/실제), 확인 과제 답, 갭 분석, 결정 기록(A/B/C), 테스트 변경, 피드백 신호, 막힘→다음 정의, 인사이트.

@entity

직전 매핑 전환 커밋의 학습 기록. 1-1 섹션을 LMS 제출 수준으로 확장한다. - 들어가기 전 자기진단: Repository SQL 패턴 가설, 객체 참조 자연스러움 가설 - 전환 전(JDBC: INSERT+KeyHolder+RowMapper) / 전환 후(JPA @entity + 포트 순수+어댑터) 코드와 "왜" - 발행 SQL 실측 전문: Hibernate 생성 DDL(generated by default as identity, time(6), 무명 인라인 unique, varchar 길이) + save INSERT(id default 포함·알파벳 컬럼순·바인딩 분리 로깅) - 관찰 ①②③ 표(예측 vs 실제), 확인 과제 답(예약 INSERT가 JDBC와 같고 다른 3가지) - 갭 분석(적중/빗나간 3신호), 결정 기록 4건(직접 @entity / 포트 순수+어댑터 / native·JdbcTemplate / ddl-auto=none) — A/B/C 태그 - 테스트 변경(슬라이스 삭제·144 green·schema 충돌 수정), 피드백 신호, 막힘→다음 정의, 인사이트 1-2·1-3 이하 템플릿은 보존(미작성 유지).

CRUD는 ThemeJpaRepository(Spring Data)에 위임, findPopularBetween은 어댑터의 과도기 JdbcTemplate로 이전 완료. 포트(ThemeRepository) 구현이 어댑터로 일원화됨.

@query

…dapter(JPA)로 대체 CRUD는 ReservationTimeJpaRepository(Spring Data)에 위임, findAvailable은 native @query로 이전 완료. 포트(ReservationTimeRepository) 구현이 어댑터로 일원화됨.

@DataJpaTest

JPA 어댑터 슬라이스 테스트(@DataJpaTest)는 reservation 엔티티화로 findPopular를 슬라이스에서 검증 가능한 1-2 이후로 이연. ThemeServiceTest는 포트 의존이라 유지.

@DataJpaTest

…meRepository) 삭제로 무효화 JPA 어댑터 슬라이스 테스트(@DataJpaTest)는 reservation 엔티티화로 findAvailable을 슬라이스에서 검증 가능한 1-2 이후로 이연. ReservationTimeServiceTest는 포트 의존이라 유지.

@entity

독립 클래스(1-1)에 이어 연관관계 있는 Reservation·Waiting을 @entity로 전환한다. 이 둘이 엔티티가 되면서 1-1의 과도기 군더더기(native/JdbcTemplate/ddl-auto=none)가 후속 커밋에서 제거된다. ■ 엔티티 (단방향 @manytoone) - Reservation·Waiting: @entity, final 제거 + protected 생성자, 팩토리·검증·promote· withOrderIndex·dateTime 보존. - @manytoone(optional=false) @joincolumn(time_id/theme_id) — 단방향. fetch 기본값(EAGER) 유지: 1-3 관찰⑤·3-1 N+1에서 본 뒤 튜닝하려고 일부러 명시 안 함. - @table(uniqueConstraints=...)로 복합 UNIQUE 보존: reservation UNIQUE(date,time_id,theme_id) / waiting 2개(+order_index, +name). → schema.sql 없이 Hibernate DDL이 복합 UNIQUE를 생성함을 실측 확인. - 발행 DDL 관찰: @manytoone @joincolumn → `time_id bigint not null` + `foreign key (time_id) references reservation_time` (객체 참조가 FK 컬럼+제약으로 컴파일). ■ 리포지토리 (Spring Data 파생 + @Modifying) - ReservationJpaRepository/ReservationRepositoryAdapter: CRUD 내장 + existsByDateAndTime_IdAndTheme_Id(_AndName/_AndIdNot)·existsByTime_Id·existsByTheme_Id· findByNameOrderByDateAscTime_StartAtAsc(파생) / updateDateAndTime은 @Modifying JPQL. - WaitingJpaRepository/WaitingRepositoryAdapter: findByDateAndTime_IdAndTheme_Id OrderByOrderIndexAsc·findByNameOrderBy...(파생) / updateOrderIndex은 @Modifying. ■ flush 순서 수정 (4단계 예고 현상의 실물) - 승급 흐름(취소→같은 슬롯 첫 대기 승격): deleteById(em.remove)는 지연되는데 IDENTITY save가 즉시 INSERT → 옛 예약 미삭제 상태로 같은 슬롯 INSERT → UNIQUE(date,time_id,theme_id) 충돌(ConstraintViolation). JPA는 flush 시 INSERT→UPDATE→DELETE로 재정렬하기 때문. - 해결: ReservationRepositoryAdapter.deleteById에서 deleteById 후 flush()로 delete-before-insert(JDBC의 즉시 DELETE 의미) 복원. 전체 테스트 green. (Theme·ReservationTime 리포지토리 JPQL 승격 + schema.sql 제거 + create-drop 전환은 다음 커밋)

@query

Reservation 이 엔티티가 되어 교차 테이블 쿼리를 JPQL로 올리고, DDL 소유권을 Hibernate로 일원화한다. 1-1에서 남겼던 과도기 장치가 전부 사라진다. - ThemeJpaRepository.findPopularBetween: 과도기 JdbcTemplate → JPQL 생성자 표현식 (new PopularThemeProjection(t, count(r)) / 세타조인 / limit은 Pageable). ThemeRepositoryAdapter에서 JdbcTemplate 의존 제거. - ReservationTimeJpaRepository.findAvailable: native @query → JPQL 안티조인 (not in (select r.time.id ...)). - application.properties(main·test): ddl-auto=none → create-drop + defer-datasource-initialization=true (Hibernate DDL 후 data.sql 시드). - schema.sql 제거 + 구 Jdbc 구현/슬라이스 테스트 제거는 다음 커밋. 전체 테스트 green(./gradlew test BUILD SUCCESSFUL) 확인 후 푸시.

복합 UNIQUE 는 @table(uniqueConstraints) 로 엔티티에 이전 완료. FK·식별자도 매핑으로 표현.

…PA)로 대체

@DataJpaTest

JPA 어댑터 슬라이스 테스트(@DataJpaTest)는 후속 도입 후보. 서비스·인수 테스트가 동작 보장 유지.

이로써 adapter/persistence 슬라이스의 구 Jdbc 테스트 4종 정리 완료. 1-2 전환 끝.

@Modifying

1-1과 동일한 밀도로 1-2를 기록. 1-2/1-3 템플릿 중 1-2를 상세본으로 교체(1-1·1-3 보존). - 진입 가설 2개(@manytoone→무엇이 생기나 / 교차쿼리 JPQL화) - 전환 전(3중 조인 RowMapper+KeyHolder) / 전환 후(@manytoone 단방향 + 파생쿼리 + @Modifying + JPQL 승격)와 "왜" - 발행 DDL 실측: @manytoone @joincolumn → time_id FK 컬럼 + foreign key 제약 / @table 복합 UNIQUE 3개 보존 - 발행 SQL 실측(런타임): save INSERT(객체→FK 바인딩) / findById EAGER 단일 join fetch / findByName 파생쿼리의 N+1(메인+연관별 보조 SELECT) / findAvailable 안티조인 / findPopular 세타조인+group by+fetch first / show-sql·SQL 로거 이중 로깅 - 확인 과제 답: findById().getTime().getStartAt() → EAGER join fetch라 추가 SQL 0 - N+1 예고(→3-1): 같은 EAGER인데 by-id는 join fetch, 쿼리는 보조 SELECT - flush 순서 발견(→4단계): deleteById 지연 vs IDENTITY save 즉시 INSERT → UNIQUE 충돌 → flush()로 delete-before-insert 복원 - 결정기록(B): 단방향+양방향/cascade 명시적 비결정 / fetch 기본값 유지 아크 / @Modifying vs dirty checking / updateDateAndTime time 참조 - 테스트(C)·피드백신호(C)·막힘→다음정의·인사이트·회수 차원

@Modifying

1-3 템플릿을 실측 상세본으로 교체하고, 끝의 doc-레벨 템플릿을 "1단계 종합(A/B/C 총괄)"로 대체. 6개 관찰(4필드: 시도/예측/실제/왜 + 발행 SQL): - ① dirty checking: 세터 없는 도메인이라 리플렉션 강제 → commit 시 full-column UPDATE 발행. 1-2 미결(@Modifying vs dirty checking)을 @Modifying 유지로 종결 - ② 1차 캐시: 같은 tx 2번째 find SELECT 0, t1==t2 동일 인스턴스 - ③ 쓰기 지연: IDENTITY persist 즉시 INSERT → 1-1 ③ 복선 회수 + 1-2 flush 버그 뿌리 확증 - ④ flush 시점: dirty 상태 JPQL 직전 auto-flush(UPDATE→count) - ⑤ fetch 기본값: @manytoone EAGER 단일 조인. @onetomany 부재(단방향 결정의 결과) 기록 - ⑥ LazyInit: EAGER는 detach 후 정상 / getReference 프록시는 tx 밖 LazyInitializationException → reads tx-free + 3-1 LAZY 전환 위험 좌표 + 결정(B): @Modifying 유지 확정 / reads tx-free LAZY 전환 시 재검토 + 1단계 종합: A/B/C 총괄 + 다음 단계 복선(3-1 N+1, 4단계 flush, 2단계 member, LAZY read)

기능은 1-2 findByName 파생쿼리로 이미 충족 → 2단계는 결정 명시 + mine N+1 관찰 + 기록. - 자기진단: 단일 조건+정렬이라 메서드 이름 쿼리 직감 - 현황: GET /reservations-mine 흐름(예약·대기 각 findByName + in-memory 병합 정렬) - 발행 SQL 관찰(예약2+대기2): distinct 8 SELECT · N+1 실물(예약·대기 두 갈래) · 1차 캐시가 공유 theme dedup(naive 1+2N 아님) · reads tx-free의 청구서: 예약 tx와 대기 tx가 캐시 비공유 → theme 재로드(tx 경계=캐시 범위) - 확인 과제: 메서드 이름 쿼리 사용 / 한계(이름 폭발·fetch join 불가·엔티티 결합 불가) - 결정1: name 유지(0단계 재구현 금지·1:1 비교 보존 vs 동명이인 불가) - 결정2: 메서드 쿼리(최소 코드 vs fetch join 불가 → 3-1 승격) - 테스트: 코드 변경 0·134 green / 막힘→3-1 입구 / 인사이트·회수 차원

@transactional

1-2/1-3에서 의도적으로 안고 온 N+1을 닫는다. "기본값(EAGER)→문제(N+1/LazyInit)→해결(fetch join)" 아크의 종착. ■ 문제 재현 (관찰 A) - EAGER + 파생 쿼리라 mine 경로(예약 N + 대기 M)가 main + 연관별 보조 SELECT. 예약2+대기2 기준 distinct 8 SELECT(예약 main+theme+time×2, 대기 main+theme+time×2). - 1차 캐시가 같은 tx의 공유 theme는 dedup하지만, reads tx-free라 예약 tx와 대기 tx가 캐시 비공유 → theme 재로드(tx 경계=캐시 범위). (2단계에서 기록) ■ EAGER→LAZY 전환의 청구서 (1-3 ⑥ 예고 실현) - Reservation·Waiting의 @manytoone(time/theme)를 fetch=LAZY로. - 그 순간 findMyReservationsAndWaitings(@transactional 아님, reads tx-free)의 DTO 변환에서 LazyInitializationException 3건(ReservationServiceTest) → 1-3 ⑥(getReference 프록시 tx밖 접근) 예고가 실제 read 경로에서 그대로 재현. - 관찰: findAll(admin)은 안 깨짐 — OSIV(open-in-view 기본 on)가 HTTP 경로의 LAZY를 뷰까지 열어 가려줌. 단 OSIV는 LazyInit만 가리고 N+1은 못 가림(서비스 직접 호출 테스트는 노출). ■ 해결 (관찰 B) - 조회 경로에 @EntityGraph(attributePaths={"time","theme"}): · ReservationJpaRepository.findByName...(mine) + findAll(admin) 오버라이드 · WaitingJpaRepository.findByName...(mine) - mine 경로 8 → 2 SELECT(예약 fetch-join 1 + 대기 fetch-join 1). N+1 제거 + LazyInit 해소. - @manytoone(to-one) fetch join이라 row 중복 없음(distinct 불필요) — 중복은 to-many 컬렉션 fetch join의 문제. optional=false라 INNER JOIN으로 발행. 전체 테스트 green(./gradlew test BUILD SUCCESSFUL) 확인 후 푸시.

3-1·3-2 템플릿을 실측 상세본으로 채움. 3-1 (N+1): - 자기진단: Waiting 분리 엔티티 근거(슬롯당 예약/대기 유일성 규칙 분리) - 관찰 A: EAGER mine 8 SELECT(1차캐시 dedup·tx 경계=캐시 범위) - 중간: EAGER→LAZY → ReservationServiceTest 3건 LazyInit(1-3 ⑥ 실현) / findAll은 OSIV가 가림(LazyInit만, N+1은 못 가림) - 관찰 B: @EntityGraph fetch join → 8→2, 단일 INNER JOIN, to-one이라 row 중복 없음(distinct 불필요) - 두 SQL 나란히 표 3-2 (JPQL rank): - A(order_index=3) vs B(JPQL 상관 서브쿼리 COUNT=2) 관찰 + 발행 SQL - 확인과제: JPQL SQL / 파생쿼리로 못 푸는 이유(상관 서브쿼리+자기참조 집계는 문법 밖) - 결정: order_index 유지(UNIQUE 방어선·승급 통합 vs JPQL rank의 무부기·자가치유) — 비교 후 유지, JPQL rank는 미션 후 리팩터링 1순위로 기록(시도→후퇴) + 테스트(C): LazyInit→@EntityGraph·green(134) / 막힘→4단계 + 비관적 락 백로그 / 인사이트·회수 차원

@transactional

자동 승인은 1-2에서 구현·flush 픽스 완료 → 4단계는 flush 순서 정식 관찰 + 경계 결정 + 기록. 코드 변경 0. - 자기진단: 자동승인 위치=Service @transactional / 경계=취소+승급 한 트랜잭션 - 본질신호 ① 경계: 한 @transactional 원자성(분리 시 빈 슬롯) — 단 경계≠flush 순서 - ② 동시성: 의도적 deferred(Level 3 락 아크), UNIQUE가 최악만 방어 - ③ flush 순서(실측): deleteByOwner 1회 → SELECT R → SELECT time(LAZY) → DELETE reservation(①, flush) → SELECT waiting → INSERT reservation(②) → DELETE waiting(③) → UPDATE waiting(④) · 핵심: 트랜잭션 경계(원자성) ≠ flush 순서(액션큐 INSERT→UPDATE→DELETE) → delete-before-insert는 명시 flush로만 · IDENTITY 즉시 INSERT(1-3 ③)가 충돌 악화 - 확인과제: 자동승인 채택 / 가장 약한 축=동시성 - 결정: 단일 @transactional + 명시 flush, 동시성 deferred 명시 - 테스트(C): 코드 변경 0·green(134), 승급 롤백 테스트(@MockitoSpyBean 포트 spy) 무영향 - 📌 PR 본문 재료 채움(도달지점/브랜치·범위/망설인 결정/SQL 발췌/흔들린 장면) → 07 조립용

softmoca and others added 30 commits June 3, 2026 18:16

docs : 서비스 통합테스트 주석 설명기록 구체적으로 수정

9fc6c7a

chore(test): @MockBean → @MockitoBean 마이그레이션 (web 슬라이스 6개)

b3d1b9e

fix: 슬롯+이름 유니크 제약 추가 중복 대기 DB 방어선

cc436cc

docs : waiting 유니크 제약 명세 추가

994763c

feat : 트랜잭션 경계 적용

2a3adaa

test : 자동 승격 중간 실패 시 전체 롤백 증명

6c6c460

test : 대기 취소 재정렬 중간 실패 시 전체 롤백 증명 테스트 추가

1d5a34d

docs : WaitingServiceMockTest 사이클 2 재검토 결과 기록

059ef3a

docs : 트랜잭션 경계와 근거 문서 추가

fc66f42

test : 테스트명 수정 및 주석 추가로 의도 명확하게 되도록 개선

cb68c89

style : 불필요한 주석 제거

069852f

feat : wirte를 하는 모든 연산 메서드에 트랜잭션 적용

7a3e4fa

refactor : 얼리티런 적용 및 메서드 분리로 개독성 개선

f70a199

refactor: 예약 시점 메서드명을 도메인 용어로 변경

d34b4e8

refactor: 예약 시점 비교 메서드명을 명확하게 변경

3e462ed

docs : 학습 기록 문서 추가

bbf3097

docs : 학습 문서 모델 내용 수정

47cd79a

[1단계] 구 JdbcThemeRepository 제거 — ThemeRepositoryAdapter(JPA)로 대체

6f6f64b

CRUD는 ThemeJpaRepository(Spring Data)에 위임, findPopularBetween은 어댑터의 과도기 JdbcTemplate로 이전 완료. 포트(ThemeRepository) 구현이 어댑터로 일원화됨.

softmoca added 14 commits June 18, 2026 13:04

[1단계] schema.sql 제거 — 4개 테이블 모두 @entity, Hibernate(create-drop)가 DDL 소유

f3c7193

복합 UNIQUE 는 @table(uniqueConstraints) 로 엔티티에 이전 완료. FK·식별자도 매핑으로 표현.

[1단계] 구 JdbcReservationRepository 제거 — ReservationRepositoryAdapter(J…

cb59c26

…PA)로 대체

[1단계] 구 JdbcWaitingRepository 제거 — WaitingRepositoryAdapter(JPA)로 대체

7bd89e8

[1단계] JdbcReservationRepositoryTest 제거 — 대상 클래스 삭제로 무효화

b77b800

JPA 어댑터 슬라이스 테스트(@DataJpaTest)는 후속 도입 후보. 서비스·인수 테스트가 동작 보장 유지.

[1단계] JdbcWaitingRepositoryTest 제거 — 대상 클래스 삭제로 무효화

2de1190

이로써 adapter/persistence 슬라이스의 구 Jdbc 테스트 4종 정리 완료. 1-2 전환 끝.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

[🌱 JPA 방탈출 예약 대기] 모카(최영철) 미션 제출합니다.#579
softmoca wants to merge 44 commits into
woowacourse:softmocafrom
softmoca:step3-jpa

softmoca commented Jun 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

softmoca commented Jun 18, 2026

체크 리스트

베이스 코드 선택 체크

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

0단계 — 범위

단계별 도달 지점

발행 SQL 발췌 (예측-실제 갭이 가장 큰 것)

망설인 결정 1~2개

흔들린 한 장면

명시적 비결정 (Level 3 범위)

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant