🎯 F-lab Java 11-12주차 통합 학습 커리큘럼

11-12주차 자료의 모든 토픽을 두 주에 걸쳐 정리한 학습 경로.
1) 11주차 — JPA의 정체와 영속성 컨텍스트 (싱글톤 → SQL Mapper → ORM → 엔티티 매핑 → 영속성 컨텍스트)
2) 12주차 — 연관관계와 성능 최적화 (4가지 연관관계 → 프록시 → N+1 문제 → CASCADE → JPQL/QueryDSL)

7주차에서 JPA의 입문을 봤다면, 11-12주차는 JPA의 모든 메커니즘을 깊이 파헤친다.

자바·Spring 학습의 또 다른 정점이며, 실무에서 가장 자주 만나는 영역이다.

---

📊 학습 경로 한눈에 보기

[Part A — 11주차: JPA의 정체와 영속성 컨텍스트]
  [Phase 1] 싱글톤 + SQL Mapper의 역사
     ↓
  [Phase 2] ORM과 JPA의 본질
     ↓
  [Phase 3] 엔티티와 테이블 매핑 기초
     ↓
  [Phase 4] EntityManager + 영속성 컨텍스트
     ↓
  [Phase 5] 영속성 컨텍스트의 4가지 장점 ◄ 11주차 정점

[Part B — 12주차: 연관관계와 성능 최적화]
  [Phase 6] JPA 연관관계 4가지 (1:1, N:1, 1:N, N:M)
     ↓
  [Phase 7] mappedBy와 연관관계의 주인
     ↓
  [Phase 8] 프록시와 지연/즉시 로딩
     ↓
  [Phase 9] N+1 문제와 해결 ◄ 12주차 정점
     ↓
  [Phase 10] 영속성 전이 + JPQL/QueryDSL

총 10 Phase × 39 Unit — 8-9주차와 비슷한 분량의 통합 커리큘럼.

🔗 1~12주차 흐름 정리

주차	주제	핵심 변화
1주차	OOP·JVM·GC·컬렉션·I/O 개론	자바 큰 그림
2주차	JVM 내부·바이트코드·G1 GC	"어떻게 돌아가나"
3주차	컬렉션·제네릭·함수형	자바 표현력
4주차	멀티스레딩·동시성·Executor	동시성 정복
5주차	Atomic + Spring IoC/DI 입문	자바 → Spring 다리
6주차	테스트 + 웹 인프라 + DB 접근 진화	Spring 실전 환경
7주차	JPA/ORM 입문 + 트랜잭션 추상화	DB 추상화 입문
8주차	프록시의 진화	AOP 메커니즘
9주차	Spring AOP 실전 + 트랜잭션 전파	AOP 실전 활용
10주차	트랜잭션 정리 + 빈 라이프사이클 함정 + 격리 수준	트랜잭션 마무리
11주차 (지금)	JPA의 정체와 영속성 컨텍스트	JPA 메커니즘 완전 이해
12주차 (지금)	연관관계 + 성능 최적화 (N+1 등)	JPA 실전 활용

---

🗓️ 권장 학습 일정 (압축 14일)

Day	Phase	학습 목표
Week 1 (11주차)
1일차	Phase 1	싱글톤 + SQL Mapper 역사
2일차	Phase 2	ORM/JPA 본질 + Hibernate
3일차	Phase 3	엔티티 매핑 + 임베디드 타입
4-5일차	Phase 4	EntityManager + 영속성 컨텍스트 + 생명주기
6-7일차	Phase 5	4가지 장점 (★ 정점)
Week 2 (12주차)
8-9일차	Phase 6	4가지 연관관계
10일차	Phase 7	mappedBy와 연관관계의 주인
11일차	Phase 8	프록시와 지연/즉시 로딩
12-13일차	Phase 9	N+1 문제 + 해결책 (★ 정점)
14일차	Phase 10	CASCADE + JPQL + QueryDSL

여유 일정 (21일): Phase 5와 9에 각 +2일. 영속성 컨텍스트와 N+1은 직접 SQL 로그를 보며 체화.

---

🌱 Part A — 11주차: JPA의 정체와 영속성 컨텍스트

📚 Phase 1 — 싱글톤 + SQL Mapper의 역사

목표: JPA가 어떤 흐름의 산물인지를 SQL Mapper(iBatis/MyBatis)와의 비교로 이해한다.

Unit 1.1 — 싱글톤 패턴 본질 (5주차 복습+심화)

선수 지식: 5주차 Phase 8 (싱글톤 빈)

핵심 개념

싱글톤 패턴의 정의:

"클래스의 인스턴스가 단 하나만 존재 하도록 보장 + 전역 접근"

핵심 3요소:
1. static 변수로 유일 인스턴스 저장
2. private 생성자로 외부 생성 차단
3. getInstance() 정적 메서드로 반환

public class Singleton {
    private static Singleton instance;
    
    private Singleton() {}  // private!
    
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

대표적인 싱글톤 사례:

• Spring의 Bean 객체 (5주차)
• JPA의 EntityManagerFactory ⭐ (이번 주차 핵심)
• Database Connection Pool (HikariCP)
• Logger, Caching System

자기 점검

• 5주차 Spring 싱글톤과 GoF 싱글톤 패턴의 차이는?
• private 생성자 없이 싱글톤이 가능한가?

---

Unit 1.2 — 멀티스레드 환경의 위험 + ThreadLocal 연결

선수 지식: Unit 1.1, 4주차 Phase 4, 10주차 Phase 4

핵심 위험

문제:

• 싱글톤은 인스턴스가 하나
• → 여러 스레드가 동시에 공유
• → Race Condition 가능

해결 방향:
1. stateless 설계 (가장 권장) — 멤버 변수에 가변 상태를 두지 않음
2. synchronized (성능 비용)
3. Atomic (5주차 Phase 2 — CAS)
4. ThreadLocal (8주차 Phase 1 — 스레드별 독립 저장소)

JPA에서의 적용:

• EntityManagerFactory = 싱글톤 (애플리케이션 전역)
• EntityManager = 트랜잭션 단위 (스레드별로 다름)
• → 동시성 문제를 EntityManager 분리로 회피

자기 점검

• ILIC의 Service 빈에 List 멤버 변수를 두면? (힌트: 동시성 사고)
• 4주차 ConcurrentHashMap을 멤버 변수로 두는 건 안전한가?

---

Unit 1.3 — iBatis → MyBatis (SQL Mapper의 진화)

선수 지식: 6주차 Phase 7 (JdbcTemplate)

핵심 개념

iBatis (Internet Based Abstraction for Tabular Information Systems):

• SQL을 XML 파일에 분리
• 자바 객체와 SQL 결과 매핑 자동화
• iBatis 3.0 이후 개발 중단

MyBatis = iBatis의 후계자:

• 어노테이션 기반 SQL 매핑 추가 (@Select, @Insert)
• 동적 SQL (<if>, <foreach>)
• 더 많은 데이터베이스 호환

JDBC vs MyBatis 비교:

	JDBC 직접	MyBatis
SQL 작성	자바 코드 안	XML 또는 어노테이션
자원 관리	수동 (try/finally)	자동
결과 매핑	수동 (rs.getInt 등)	자동 (resultType)
코드량	많음	적음

SQL Mapper의 한계:

• ✅ 자원 관리 자동화
• ❌ SQL은 여전히 직접 작성
• ❌ 객체-관계 매핑은 수동
• → 그래서 ORM(JPA)이 등장

자기 점검

• JdbcTemplate(6주차)과 MyBatis의 위치는 같은가? (힌트: 둘 다 SQL Mapper)
• 한국 SI 시장에서 MyBatis가 여전히 많이 쓰이는 이유는? (힌트: SQL 통제, 익숙함)

---

📚 Phase 2 — ORM과 JPA의 본질

목표: ORM의 패러다임과 JPA-Hibernate의 관계를 명확히 잡는다.

Unit 2.1 — SQL Mapper vs ORM (패러다임 차이)

선수 지식: Phase 1, 7주차 Phase 2~3

핵심 비교

	SQL Mapper (MyBatis, JdbcTemplate)	ORM (JPA/Hibernate)
매핑	SQL ↔ 객체	객체 ↔ 테이블
SQL 작성	개발자 직접	JPA가 자동 생성
학습 곡선	낮음	높음
DBMS 종속성	있음	적음
복잡 통계 쿼리	자유롭게	어렵 (JPQL/네이티브 쿼리 필요)

SQL Mapper의 시각:

"SQL을 작성하고, 결과를 객체에 채워주세요"

ORM의 시각:

"객체를 다루세요. SQL은 제가 만들겠습니다"

객체-관계 패러다임 불일치:

• 객체는 상속·다형성·연관 참조
• 관계 DB는 행과 열·외래 키
• → 둘 사이의 변환은 코드가 많아짐
• → 이 변환을 ORM이 자동화

자기 점검

• 복잡한 통계 쿼리에서 ORM의 한계는?
• SQL Mapper와 ORM을 한 프로젝트에서 같이 쓸 수 있는가? (힌트: YES, 실무에서 흔함)

---

Unit 2.2 — JPA = 표준 명세, Hibernate = 구현체

선수 지식: Unit 2.1

핵심 구조

JPA (Java Persistence API):

• 명세(Specification) — 인터페이스만 정의
• 직접 동작하는 프레임워크가 아니다
• ex) EntityManager, EntityManagerFactory 인터페이스

JPA 구현체:

• Hibernate (가장 대중적, ~95% 점유) ⭐
• EclipseLink
• DataNucleus
• OpenJPA

의존 관계:

[Application Code]
       ↓
[JPA Interface]   ← javax.persistence (또는 jakarta.persistence)
       ↓
[Hibernate]      ← JPA 구현
       ↓
[JDBC]
       ↓
[DB]

ILIC 사례:

• spring-boot-starter-data-jpa 의존성 추가
• 내부적으로 Hibernate 자동 설정
• 개발자는 JPA API로 코딩

Spring Data JPA와의 구분:

• JPA: 자바 표준 인터페이스
• Hibernate: JPA의 구현체
• Spring Data JPA: JPA를 더 편리하게 쓰는 Spring의 추상화 (Repository 인터페이스 등)

자기 점검

• 왜 JPA를 표준화했는가? (힌트: 구현체 교체 가능)
• Hibernate를 직접 쓰지 않고 JPA로 코딩하는 이유는?

---

Unit 2.3 — 객체-관계 패러다임 불일치 + JPA 위치

선수 지식: Unit 2.2

핵심 불일치 5가지:

측면	객체 (OOP)	관계 DB
모델링	상태 + 행동	행과 열
상속	있음	없음
연관	참조 (order.member)	외래키
식별	객체 동일성 (==)	PK
데이터 타입	풍부 (List, Map)	제한적

불일치를 해결하는 방법 (JPA의 일):

• 상속 → SINGLE_TABLE / JOINED / TABLE_PER_CLASS
• 참조 → @ManyToOne, @OneToMany 어노테이션
• 동일성 → 1차 캐시로 보장 (Phase 5에서)

JPA의 본질:

"객체와 RDB 사이의 번역기"

자기 점검

• "패러다임 불일치"의 가장 명확한 사례를 본인 코드에서 찾아본다면?
• ILIC의 Booking 객체와 bookings 테이블의 매핑이 자동화되는 이점은?

---

📚 Phase 3 — 엔티티와 테이블 매핑 기초

목표: 자바 객체 → DB 테이블 매핑의 기본 어노테이션을 손에 익힌다.

Unit 3.1 — @Entity와 엔티티의 조건

선수 지식: 7주차 Phase 4

핵심 개념

@Entity:

• "JPA가 관리하는 객체"라는 표시
• 이게 있어야 JPA가 인식 → 엔티티

엔티티의 필수 조건 ⭐ :

• ✅ 기본 생성자 필수 (public 또는 protected)
• ✅ 식별자 필드 (@Id)
• ❌ final 클래스 사용 불가 (Hibernate가 프록시 만들어야 함)
• ❌ enum, interface, inner class 불가
• ❌ 저장할 필드에 final 사용 불가

기본 생성자가 왜 필요한가?:

• JPA가 리플렉션 으로 객체 생성 (3주차 Phase 5)
• → 기본 생성자가 있어야 함

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    
    private String name;
    
    public Member() {}  // 기본 생성자 필수!
    
    public Member(String name) {
        this.name = name;
    }
}

자기 점검

• final 클래스를 엔티티로 만들면 어떤 에러가? (힌트: 프록시 생성 실패)
• 8주차 Phase 5의 CGLIB와 어떻게 연결되는가?

---

Unit 3.2 — @Table 매핑

선수 지식: Unit 3.1

핵심 개념

기본 매핑:

• 클래스명 → 테이블명 자동 매핑
• Member 클래스 → member 테이블

@Table 으로 명시:

@Entity
@Table(name = "MBR")  // 실제 테이블명을 MBR로
public class Member {
    // ...
}

@Column 매핑 (7주차 Phase 4 복습):

@Column(name = "user_name", length = 100, nullable = false)
private String userName;

Spring Boot의 자동 변환 (7주차 Unit 4.5):

• 자바 필드: userName (camelCase)
• DB 컬럼: user_name (snake_case)
• → 자동 매핑

자기 점검

• @Table 을 생략하면 어떻게 되는가?
• 한 엔티티가 여러 테이블에 매핑될 수 있는가? (힌트: @SecondaryTable)

---

Unit 3.3 — 임베디드 타입 (@Embeddable + @AttributeOverrides)

선수 지식: Unit 3.2

핵심 개념

임베디드 타입(Embedded Type):

• "값 타입(Value Type)"의 일종
• 여러 필드를 하나의 객체로 묶기
• 코드 재사용성 ↑

예시 — 주소를 임베디드 타입으로:

@Embeddable
public class Address {
    private String city;
    private String street;
    private String zipcode;
    
    protected Address() {}  // 기본 생성자 필수
    
    public Address(String city, String street, String zipcode) {
        this.city = city;
        this.street = street;
        this.zipcode = zipcode;
    }
    // Getter만 (값 타입은 불변 권장)
}

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;
    
    @Embedded
    private Address address;  // 임베디드 사용
}

DB 테이블 결과:

CREATE TABLE Member (
    id BIGINT PRIMARY KEY,
    name VARCHAR(255),
    city VARCHAR(255),     -- Address의 필드
    street VARCHAR(255),
    zipcode VARCHAR(255)
);

@AttributeOverrides — 같은 임베디드 타입을 여러 번 사용 시:

@Entity
public class Employee {
    @Id @GeneratedValue
    private Long id;
    
    @Embedded
    @AttributeOverrides({
        @AttributeOverride(name = "city", column = @Column(name = "home_city")),
        @AttributeOverride(name = "street", column = @Column(name = "home_street")),
        @AttributeOverride(name = "zipcode", column = @Column(name = "home_zipcode"))
    })
    private Address homeAddress;
    
    @Embedded
    @AttributeOverrides({...})
    private Address workAddress;
}

값 타입의 원칙:

• 불변(Immutable) — Setter 만들지 말고 생성자로만
• 공유하지 말 것 — 부작용 방지

자기 점검

• 값 타입을 가변으로 만들면 어떤 사고가? (힌트: 다른 엔티티에 영향)
• ILIC에서 임베디드 타입으로 표현하기 좋은 도메인은? (힌트: 주소, 운임, 연락처)

---

Unit 3.4 — ddl-auto + DDL/DML/DCL 참고

선수 지식: Unit 3.3

핵심 개념

spring.jpa.hibernate.ddl-auto 옵션:

옵션	동작
create	시작 시 기존 테이블 삭제 + 새로 생성
create-drop	create + 종료 시 삭제
update	변경 사항만 반영 (안전하지 않음)
validate	스키마 매핑만 검증 (변경 없음)
none	자동 처리 안 함

⚠️ 운영 환경 절대 금지 ⭐ :

• create, create-drop, update → 데이터 손실 위험

개발 단계별 권장:

• 로컬: create 또는 update
• 스테이징: validate
• 프로덕션: none (Flyway/Liquibase 사용)

SQL 분류 참고:

분류	의미	명령
DDL (Data Definition Language)	골격 정의	CREATE, ALTER, DROP, TRUNCATE
DML (Data Manipulation Language)	데이터 조작	SELECT, INSERT, UPDATE, DELETE
DCL (Data Control Language)	권한·트랜잭션	GRANT, REVOKE, COMMIT, ROLLBACK

자기 점검

• 운영에서 ddl-auto=update가 위험한 이유 3가지는?
• ILIC의 102개 테이블을 운영 환경에서 어떻게 관리하는 게 좋을까? (힌트: Flyway)

---

📚 Phase 4 — EntityManager와 영속성 컨텍스트

목표: JPA의 핵심 메커니즘 — 영속성 컨텍스트의 정체와 엔티티 생명주기를 이해한다.

Unit 4.1 — EntityManagerFactory (싱글톤)

선수 지식: Phase 1, 2

핵심 개념

EntityManagerFactory (EMF):

• EntityManager를 생성하는 팩토리
• 애플리케이션 전체에서 1개만 존재 (싱글톤)
• 생성 비용이 크기 때문에 한 번만 생성

Spring Boot에서의 동작:

• @SpringBootApplication 실행 시 자동 생성
• 빈으로 등록 → DI 가능
• 애플리케이션 종료까지 유지

자바 표준 사용 (참고):

EntityManagerFactory emf = Persistence.createEntityManagerFactory("my-pu");

Spring 환경 (실무):

@PersistenceUnit
private EntityManagerFactory emf;  // 자동 주입

자기 점검

• EntityManagerFactory가 싱글톤인 이유는?
• Spring Boot가 EMF를 자동 등록하는 시점은? (힌트: 컨텍스트 초기화)

---

Unit 4.2 — EntityManager (트랜잭션 단위)

선수 지식: Unit 4.1, 7주차 Phase 7

핵심 개념

EntityManager (EM):

• 영속성 컨텍스트를 관리하는 인터페이스
• 트랜잭션 단위로 생성·소멸

Spring + @Transactional 조합:

• 트랜잭션 시작 시 EM 자동 생성
• 트랜잭션 종료 시 EM 자동 닫힘
• 개발자는 직접 닫을 필요 X

핵심 메서드:

• persist(entity): 영속화 (저장)
• find(Class, id): 조회 (1차 캐시 활용)
• getReference(Class, id): 프록시 반환 (Phase 8)
• remove(entity): 삭제
• merge(entity): 준영속 → 영속
• detach(entity): 영속 → 준영속

중요 — 스레드 안전 X:

"EntityManager는 공유 X — 트랜잭션마다 별도 인스턴스"

이게 EntityManagerFactory(싱글톤)와의 결정적 차이.

자기 점검

• 한 EntityManager를 여러 스레드에서 쓰면 어떤 문제가?
• @Transactional 메서드 안에서 EM을 직접 close()하면? (힌트: 하지 마라)

---

Unit 4.3 — 영속성 컨텍스트 정의

선수 지식: Unit 4.2

핵심 개념

"엔티티 매니저 내부에서 동작하는 메모리 공간 — 엔티티를 보관하고 관리하는 곳"

위치:

EntityManager
   └── 영속성 컨텍스트 (Persistence Context)
         └── 1차 캐시 (엔티티 보관)

역할:

• 엔티티의 생명주기 관리
• 1차 캐시 제공
• 변경 감지 (Dirty Checking)
• 쓰기 지연

중요 통찰:

"JPA의 모든 신기한 동작은 영속성 컨텍스트 안에서 일어난다"

이게 Phase 5에서 설명할 4가지 장점의 출발점.

자기 점검

• 영속성 컨텍스트와 1차 캐시는 같은 것인가? (힌트: 1차 캐시는 일부)
• EntityManager가 닫히면 영속성 컨텍스트는 어떻게 되는가?

---

Unit 4.4 — 엔티티 생명주기 (비영속/영속/준영속/삭제)

선수 지식: Unit 4.3

핵심 4가지 상태 ⭐ :

new        ─persist()──> [영속(Managed)] ──remove()──> [삭제(Removed)]
[비영속]                       │
(Transient)                    │ detach()
                               │ close()
                               │ clear()
                               ↓
                       [준영속(Detached)]
                               │
                               │ merge()
                               ↓
                          [영속(Managed)]

4가지 상태 자세히:

상태	정의	영속성 컨텍스트	DB
비영속(Transient)	new로 생성, 영속화 X	❌	❌
영속(Managed)	persist 또는 find로 관리 중	✅	(커밋 시 반영)
준영속(Detached)	영속이었으나 분리됨	❌	(이전 데이터 존재)
삭제(Removed)	remove로 삭제 예정	✅ (제거 표시)	(커밋 시 삭제)

상태 변경 메서드:

• persist(entity): 비영속 → 영속
• find(Class, id): → 영속
• remove(entity): 영속 → 삭제
• detach(entity): 영속 → 준영속 (개별)
• clear(): 모든 영속 → 준영속
• close(): EM 종료 → 모두 준영속
• merge(entity): 준영속 → 영속

중요한 차이 ⭐ :

• detach(): 영속성 컨텍스트에서만 분리 — DB는 그대로
• remove(): DB에서도 삭제 (커밋 시)

자기 점검

• 비영속 엔티티에 setter를 호출하면 DB에 반영되는가? (힌트: NO)
• detach()와 close()의 차이는? (힌트: 범위)

---

📚 Phase 5 — 영속성 컨텍스트의 4가지 장점 (★ 11주차 정점)

목표: JPA가 왜 강력한지를 영속성 컨텍스트의 4가지 동작 메커니즘으로 이해한다. 면접·실무 단골.

Unit 5.1 — 1차 캐시

선수 지식: Phase 4

핵심 개념

1차 캐시:

• 영속성 컨텍스트 내부의 엔티티 저장 공간
• 같은 트랜잭션 안에서 DB 조회 회피

동작 흐름:

EntityManager em = emf.createEntityManager();
User user1 = em.find(User.class, 1L);  // ① DB 조회 + 1차 캐시 저장
User user2 = em.find(User.class, 1L);  // ② 1차 캐시에서 즉시 반환 (SQL 실행 X)

1차 캐시의 6단계:
1. 첫 조회: 1차 캐시 비어있음
2. DB에서 엔티티 조회
3. 1차 캐시에 저장
4. 결과 반환
5. 같은 엔티티 재조회 시 1차 캐시에서 반환
6. 객체 동일성 (==) 보장

범위:

• 트랜잭션 단위 (EntityManager 생명 주기와 같음)
• 트랜잭션 종료 시 1차 캐시도 사라짐

자기 점검

• 1차 캐시가 트랜잭션 단위인 이유는?
• ILIC의 동일 트랜잭션에서 같은 엔티티를 5번 조회 시 SQL은 몇 번 실행되는가?

---

Unit 5.2 — 동일성 보장

선수 지식: Unit 5.1

핵심 개념

User user1 = em.find(User.class, 1L);
User user2 = em.find(User.class, 1L);
System.out.println(user1 == user2);  // true!

왜 가능한가:

• 1차 캐시에서 같은 인스턴스 반환
• → 객체 동일성(==) 보장

객체 동등성 vs 동일성:

• 동등성(equals): 값이 같음
• 동일성(==): 인스턴스가 같음

JPA는 트랜잭션 안에서 동일성을 보장한다.

의의:

• "같은 엔티티는 같은 객체" 라는 객체지향적 직관 유지
• DB 행 = 자바 객체 라는 1:1 매핑

자기 점검

• 다른 트랜잭션에서 조회한 같은 ID의 엔티티는 == 비교가 true일까? (힌트: NO)
• equals/hashCode를 엔티티에 어떻게 구현해야 하는가? (힌트: ID 기반)

---

Unit 5.3 — 쓰기 지연

선수 지식: Unit 5.2

핵심 개념

쓰기 지연(Write-Behind):

• persist() 호출 시 즉시 INSERT 안 함
• 트랜잭션 커밋 시점에 한꺼번에 SQL 실행

예시:

em.getTransaction().begin();

em.persist(memberA);  // INSERT SQL 안 보냄
em.persist(memberB);  // INSERT SQL 안 보냄
em.persist(memberC);  // INSERT SQL 안 보냄
// 여기까지 DB는 아무것도 모름

em.getTransaction().commit();
// → 커밋 직전에 INSERT SQL 3개를 한꺼번에 보냄!

내부 동작:

• 영속성 컨텍스트 안에 SQL 저장소 존재
• persist 시 SQL을 저장소에만 모음
• commit 시 모든 SQL을 DB에 전송

효과:

• 배치 처리 최적화 가능 (Hibernate 설정으로 batch 사이즈 조정)
• 네트워크 왕복 ↓
• 성능 ↑

자기 점검

• 쓰기 지연이 작동하지 않는 경우는? (힌트: IDENTITY 전략 — 7주차 Phase 4)
• 100개 INSERT를 1번의 네트워크 호출로 처리할 수 있는 옵션은? (힌트: hibernate.jdbc.batch_size)

---

Unit 5.4 — 변경 감지 (Dirty Checking) ⭐⭐⭐

선수 지식: Unit 5.3

핵심 개념 — JPA의 가장 신기한 동작

em.getTransaction().begin();

Member member = em.find(Member.class, 1L);  // 영속 상태
member.setUsername("hi");  // setter 호출만!
member.setAge(10);

em.getTransaction().commit();
// → UPDATE 쿼리 자동 실행!

em.update() 호출 X. setter만 호출했는데 UPDATE 가 일어났다.

내부 동작 — 스냅샷 비교:
1. 엔티티가 영속성 컨텍스트에 들어올 때 스냅샷 저장 (1차 캐시 옆)
2. setter 호출 → 엔티티 변경
3. 커밋 시점에 스냅샷과 현재 엔티티 비교
4. 차이가 있으면 → UPDATE SQL 자동 생성
5. 쓰기 지연 저장소에 추가
6. DB 반영

비교 흐름:

[조회 시점]                     [커밋 시점]
엔티티: {name: "A", age: 20}    엔티티: {name: "B", age: 25}
스냅샷: {name: "A", age: 20}    스냅샷: {name: "A", age: 20}
                                       ↓
                               [차이 검출] → UPDATE SQL 생성

중요한 함정:

• 준영속 엔티티는 변경 감지 X — merge() 또는 다시 영속화 필요
• 영속성 컨텍스트 밖에서 변경한 값은 자동 반영 안 됨

자기 점검

• "변경 감지"가 작동하는 전제 조건은?
• 명시적으로 변경 감지를 비활성화하려면? (힌트: Hibernate.unproxy(), readOnly)

---

Unit 5.5 — 플러시 + 2차 캐시 보너스

선수 지식: Unit 5.4

플러시(Flush):

"영속성 컨텍스트의 변경 내용을 DB에 반영하는 시점"

플러시 발생 3가지 시점:
1. em.flush() 직접 호출
2. 트랜잭션 커밋 직전 (자동)
3. JPQL 쿼리 실행 직전 (자동)

3번이 중요한 이유:

• 변경 감지로 메모리에만 있는 변경을
• JPQL 실행 전 DB에 반영해야 일관된 결과

플러시 ≠ 커밋:

• 플러시: SQL을 DB로 전송 (메모리 → DB 동기화)
• 커밋: 트랜잭션 종료 (영구 반영)
• → flush 후에도 rollback 가능

---

2차 캐시 (보너스):

• 애플리케이션 전역 캐시 (1차 캐시는 트랜잭션 단위)
• 여러 트랜잭션이 공유
• 별도 설정 필요 (Ehcache, Redis, Hazelcast)

왜 복사본을 반환하는가:

• 캐시된 객체를 직접 반환 → 동시성 충돌
• → 트랜잭션마다 독립 복사본 반환

1차 vs 2차 캐시:

	1차 캐시	2차 캐시
범위	트랜잭션	애플리케이션 전역
기본 제공	✅	❌ (별도 설정)
객체 반환	같은 인스턴스	복사본
동시성	안전	복사본으로 격리

자기 점검

• JPQL 실행 전 자동 플러시가 일어나는 이유는?
• ILIC에서 2차 캐시를 도입한다면 어떤 데이터가 적합한가? (힌트: 마스터 데이터, 변경 적음)

---

⚡ Part B — 12주차: 연관관계와 성능 최적화

📚 Phase 6 — JPA 연관관계 4가지

목표: 객체 참조와 외래 키를 어떻게 매핑하는지 4가지 관계로 정리한다.

Unit 6.1 — 연관관계의 분류 + 단방향 vs 양방향

선수 지식: Phase 5

핵심 개념

4가지 연관관계:

• 1:1 (@OneToOne)
• N:1 (@ManyToOne) — 가장 많이 사용 ⭐
• 1:N (@OneToMany)
• N:M (@ManyToMany) — 실무에서 잘 안 씀

단방향 vs 양방향:

• 단방향: 한 엔티티에서만 다른 엔티티 참조 (A → B)
• 양방향: 양쪽이 서로 참조 (A ↔ B)

핵심 통찰:

"양방향은 사실 단방향 2개"

객체 입장: A → B 와 B → A 의 두 참조

DB 입장: 외래 키 1개로 충분

→ 그래서 연관관계의 주인 개념이 등장 (Phase 7)

자기 점검

• 양방향이 객체 입장에서는 자연스러운데 DB 입장에서는 왜 그렇지 않은가?
• 단방향만으로 충분한 시나리오는? (힌트: 거의 모든 경우)

---

Unit 6.2 — 1:1 (OneToOne) 매핑

선수 지식: Unit 6.1

핵심 개념

언제 사용:

• 회원 → 사물함
• 사용자 → 프로필
• 부가 정보

FK 위치 결정:

• 자주 조회되는 쪽에 FK 권장
• 회원이 사물함을 자주 조회 → 회원에 FK

단방향 매핑:

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    
    @OneToOne
    @JoinColumn(name = "locker_id")  // FK는 Member 테이블에
    private Locker locker;
}

@Entity
public class Locker {
    @Id @GeneratedValue
    private Long id;
}

양방향 매핑:

@Entity
public class Locker {
    @Id @GeneratedValue
    private Long id;
    
    @OneToOne(mappedBy = "locker")  // 주인이 아님
    private Member member;
}

자기 점검

• 1:1을 1:N과 구분 짓는 명확한 비즈니스 규칙은?
• FK를 양쪽 어디에 두든 결과는 같은가? (힌트: 성능 차이 있음)

---

Unit 6.3 — N:1 (ManyToOne) — 가장 많이 사용 ⭐

선수 지식: Unit 6.2

핵심 개념

가장 자주 등장하는 관계:

• 회원(N) → 팀(1)
• 주문(N) → 회원(1)
• 댓글(N) → 게시글(1)

FK 위치:

• N(다수) 쪽에 FK 위치 ← 자연스러움
• → 연관관계의 주인은 @ManyToOne ⭐

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    
    @ManyToOne(fetch = FetchType.LAZY)  // 지연 로딩 권장!
    @JoinColumn(name = "team_id")  // FK는 Member에
    private Team team;
}

@Entity
public class Team {
    @Id @GeneratedValue
    private Long id;
}

⚠️ 주의 사항:
1. FK는 N쪽에 — 항상
2. fetch = FetchType.LAZY 권장 — N+1 방지 (Phase 9)
3. 잘못된 양방향 설정 시 무한 루프 — toString, JSON 직렬화 시

자기 점검

• @ManyToOne 의 기본 fetch 전략은? (힌트: EAGER — 위험!)
• 왜 LAZY로 명시해야 하는가?

---

Unit 6.4 — 1:N (OneToMany)

선수 지식: Unit 6.3

핵심 개념

보통 양방향에서 N:1 + 1:N 조합으로 사용:

• N:1 쪽이 주인 (FK 관리)
• 1:N 쪽은 mappedBy (읽기 전용)

@Entity
public class Team {
    @Id @GeneratedValue
    private Long id;
    
    @OneToMany(mappedBy = "team")  // 주인이 아님!
    private List<Member> members = new ArrayList<>();
}

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    
    @ManyToOne
    @JoinColumn(name = "team_id")  // 주인 (FK 관리)
    private Team team;
}

@OneToMany 가 주인이 되는 경우는?:

• 비추천 (추가 UPDATE 쿼리 발생)
• 단방향만 필요할 때 사용 가능

⚠️ 주의 사항:

• mappedBy 없으면 → 조인 테이블 자동 생성 (비효율)
• 항상 @ManyToOne 쪽이 주인이어야 함

자기 점검

• @OneToMany를 주인으로 만들면 추가 UPDATE가 발생하는 이유는?
• 'mappedBy = "team"' 의 "team"은 어디를 가리키는가? (힌트: Member 엔티티의 필드명)

---

Unit 6.5 — N:M (ManyToMany) — 중간 엔티티 패턴 ⭐

선수 지식: Unit 6.4

핵심 개념

N:M의 직접 사용 — 비추천:

@ManyToMany
@JoinTable(name = "MEMBER_PRODUCT")
private List<Product> products = new ArrayList<>();

왜 안 좋은가:

• 자동 조인 테이블에 부가 정보 추가 불가
• 등록일, 상태, 수량 등 못 넣음
• → 실무에서 거의 안 씀

중간 엔티티 패턴 (실무 표준):

@Entity
public class MemberProduct {  // 또는 Order로 이름 변경
    @Id @GeneratedValue
    private Long id;
    
    @ManyToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member;
    
    @ManyToOne
    @JoinColumn(name = "PRODUCT_ID")
    private Product product;
    
    private int amount;          // 부가 정보!
    private int price;           // 부가 정보!
    private LocalDateTime orderDateTime;  // 부가 정보!
}

원칙:

"N:M은 항상 1:N + N:1로 풀어라"

의미 부여:

• MemberProduct → Order 같이 비즈니스 의미 있는 이름으로 변경
• 단순 연결 테이블이 아닌 도메인 엔티티로 격상

자기 점검

• ILIC에서 N:M로 표현하고 싶지만 중간 엔티티가 더 나은 사례는? (힌트: 사용자-권한, 책-저자)
• 중간 엔티티의 PK 전략은? (힌트: 단일 PK 또는 복합 PK)

---

📚 Phase 7 — mappedBy와 연관관계의 주인

목표: 양방향 연관관계의 가장 어려운 개념을 정리한다.

Unit 7.1 — 연관관계의 주인이 필요한 이유

선수 지식: Phase 6

핵심 문제

양방향은 객체 입장: A → B + B → A (2개 참조)
DB 입장: FK 1개로 표현

문제:

• A에서 변경하는 것과 B에서 변경하는 것 중 어느 것을 DB에 반영?
• 둘 다 반영하면 충돌 / 비효율

해결:

"한쪽만 주인 으로 정하고, 그 쪽만 DB FK 관리"

다른 쪽은 읽기 전용

규칙:

• N쪽이 주인 (@ManyToOne 쪽)
• 1쪽은 mappedBy

자기 점검

• 데이터 무결성 측면에서 왜 한쪽만 주인이어야 하는가?
• 두 쪽이 모두 FK를 변경하면 어떤 사고가? (힌트: 충돌, 일관성 깨짐)

---

Unit 7.2 — mappedBy 사용법

선수 지식: Unit 7.1

핵심 개념

mappedBy:

• 주인이 아닌 쪽에 명시
• 값은 주인 엔티티의 필드명

@OneToMany(mappedBy = "team")  
//                    ↑ Member 엔티티의 team 필드를 가리킴
private List<Member> members;

의미:

"나는 주인이 아니고, 저쪽(Member.team)이 주인이다"

JPA가 하는 일:

• 주인이 아닌 쪽: 읽기 전용 — FK 변경 안 함
• 주인 쪽만 보고 DB 동기화

자주 하는 실수:

• 주인이 아닌 쪽에서 변경하고 DB 반영 기대
• → 변경 안 됨 → 디버깅 어려움

연관관계 편의 메서드 (실무 표준):

@Entity
public class Member {
    public void setTeam(Team team) {
        this.team = team;
        team.getMembers().add(this);  // 양쪽 동기화!
    }
}

자기 점검

• mappedBy의 값 "team"이 잘못된 필드명이면? (힌트: 컴파일 OK, 런타임 에러)
• 양쪽을 항상 같이 바꿔야 하는 이유는? (힌트: 1차 캐시 일관성)

---

Unit 7.3 — N:1 + 1:N 양방향 모범 사례

선수 지식: Unit 7.2

핵심 패턴

가장 흔한 양방향 — 회원과 팀:

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "team_id")
    private Team team;  // 주인 (FK 관리)
    
    // 편의 메서드
    public void changeTeam(Team team) {
        this.team = team;
        team.getMembers().add(this);
    }
}

@Entity
public class Team {
    @Id @GeneratedValue
    private Long id;
    
    @OneToMany(mappedBy = "team")  // 주인 X
    private List<Member> members = new ArrayList<>();
}

5가지 권장 사항:
1. ✅ N쪽이 주인 (@ManyToOne)
2. ✅ fetch = FetchType.LAZY 명시
3. ✅ 컬렉션은 필드 초기화 (new ArrayList<>())
4. ✅ 편의 메서드로 양쪽 동기화
5. ✅ Lombok @ToString 에서 컬렉션 제외 (무한 루프 방지)

자기 점검

• 단방향 매핑으로 시작하고 필요 시 양방향으로 확장하라는 조언의 의미는?
• 양방향이 무한 루프를 일으키는 시나리오는? (힌트: toString, JSON 직렬화)

---

📚 Phase 8 — 프록시와 지연/즉시 로딩

목표: JPA의 프록시 메커니즘과 로딩 전략 — 8-9주차 프록시와 다른 맥락의 프록시.

Unit 8.1 — em.find() vs em.getReference()

선수 지식: Phase 5

핵심 차이:

	em.find()	em.getReference()
반환	실제 엔티티	프록시 객체
SQL 실행	즉시	지연 (필드 접근 시)
타입	User	User$Proxy1 (CGLIB)

예시:

User user = em.find(User.class, 1L);  // 즉시 SELECT
System.out.println(user.getName());   // SQL 실행 X (이미 로드됨)

User proxyUser = em.getReference(User.class, 1L);  // SQL 안 함
System.out.println(proxyUser.getName());           // 여기서 SELECT 실행

프록시 객체 확인:

System.out.println(proxyUser.getClass().getName());
// 출력: com.sun.proxy.$Proxy1

자기 점검

• 8-9주차의 JDK 동적 프록시와 같은 메커니즘인가? (힌트: 비슷하지만 다른 목적)
• getReference()로 받은 후 EntityManager가 닫히면? (힌트: LazyInitializationException)

---

Unit 8.2 — JPA 프록시 메커니즘

선수 지식: Unit 8.1

핵심 동작 흐름:

Step 1 — getReference() 호출:

User proxyUser = em.getReference(User.class, 1L);
// 프록시 객체 반환
// proxyUser.target = null (실제 엔티티 미로드)

Step 2 — 필드 접근 시점:

proxyUser.getName();
// ↓ 이 순간:
// 1. 영속성 컨텍스트에 실제 엔티티 로드 요청
// 2. DB SELECT 실행
// 3. 영속성 컨텍스트에 실제 엔티티 보관
// 4. proxyUser.target = 실제 엔티티 연결
// 5. proxyUser.target.getName() 호출

프록시의 특징:

• 원본 엔티티를 상속한 클래스 (CGLIB 사용)
• ID는 가지고 있음 (생성 시 받음)
• 실제 데이터는 target 참조

⚠️ 주의 — 비교 시 instanceof 사용:

if (user instanceof User) { ... }   // 프록시도 잡힘 ✅
if (user.getClass() == User.class) { ... }  // 프록시는 false ❌

자기 점검

• 프록시가 원본 클래스를 상속하는 이유는? (힌트: 다형성)
• final 클래스가 엔티티가 될 수 없는 이유와 연결되는가? (힌트: YES)

---

Unit 8.3 — 지연 로딩 (LAZY)

선수 지식: Unit 8.2

핵심 개념

지연 로딩(Lazy Loading):

• 연관 엔티티를 즉시 조회하지 않음
• 사용 시점 에 SQL 실행
• 프록시 객체로 참조만 유지

@Entity
public class Member {
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "team_id")
    private Team team;
}

동작 시나리오:

Member member = em.find(Member.class, 1L);
// SELECT * FROM member WHERE id = 1;
// member.team = 프록시 객체 (Team$Proxy1)

System.out.println(member.getTeam());     // SQL X (프록시만 출력)
System.out.println(member.getTeam().getName());  
// ↑ 이 시점에 SELECT * FROM team WHERE id = ?;

언제 사용:

• 거의 모든 ManyToOne, OneToOne 관계
• 사용 안 할 가능성 있는 연관 엔티티

자기 점검

• 지연 로딩의 SQL 실행 시점을 정확히 언제인가?
• ILIC의 운임 견적 조회 시 어떤 연관 엔티티를 LAZY로 둘까?

---

Unit 8.4 — 즉시 로딩 (EAGER) — 주의 ⭐

선수 지식: Unit 8.3

핵심 개념

즉시 로딩(Eager Loading):

• 연관 엔티티를 즉시 함께 조회
• JOIN 또는 추가 SELECT

@ManyToOne(fetch = FetchType.EAGER)
private Team team;

Member member = em.find(Member.class, 1L);
// SELECT m.*, t.* FROM member m JOIN team t ON ... WHERE m.id = 1;
// 또는: SELECT * FROM member WHERE id = 1; + SELECT * FROM team WHERE id = ?;

연관관계별 기본값 (외워야 함) ⭐ :

관계	기본 fetch
@ManyToOne	EAGER (위험!)
@OneToOne	EAGER (위험!)
@OneToMany	LAZY
@ManyToMany	LAZY

⚠️ 즉시 로딩의 문제 ⭐ :

1. N+1 문제 — Phase 9에서 자세히
2. JPQL에서 예상치 못한 쿼리 폭증
3. 항상 모든 연관을 가져옴 — 성능 저하

실무 결론:

"모든 연관관계를 LAZY로 명시"

EAGER가 필요하면 fetch join (Phase 9)

@ManyToOne(fetch = FetchType.LAZY)  // 항상 명시!
@OneToOne(fetch = FetchType.LAZY)   // 항상 명시!

자기 점검

• 왜 ManyToOne의 기본값이 EAGER인가? (힌트: 직관적이지만 위험)
• ILIC에서 EAGER 때문에 어떤 사고가 가능한가?

---

📚 Phase 9 — N+1 문제와 해결 (★ 12주차 정점)

목표: 실무에서 가장 자주 만나는 JPA 성능 문제를 4단계로 해결한다.

Unit 9.1 — N+1 문제 정의 (즉시/지연 두 시나리오)

선수 지식: Phase 8

핵심 정의

N+1 문제:

"한 번의 쿼리(1)를 실행한 후, 추가로 N개의 쿼리 가 실행되는 문제"

즉시 로딩(EAGER) 시 발생:

// User에 @OneToMany(fetch = EAGER) private Set<Article> articles;
List<User> users = em.createQuery("SELECT u FROM User u").getResultList();

실행되는 SQL:

-- (1) User 100명 조회
SELECT * FROM user;

-- (N=100) User마다 article 조회
SELECT * FROM article WHERE user_id = 1;
SELECT * FROM article WHERE user_id = 2;
SELECT * FROM article WHERE user_id = 3;
... (100번)

→ 총 101개의 쿼리!

지연 로딩(LAZY) 시에도 발생 가능:

List<User> users = em.createQuery("SELECT u FROM User u").getResultList();
// (1) User 100명 조회 — LAZY라서 article은 안 가져옴

for (User user : users) {
    System.out.println(user.getArticles().size());
    // ↑ getter 호출 시점에 100번 SQL 실행!
}

→ 결국 같은 N+1 문제

핵심 통찰:

"단순히 LAZY로 바꾼다고 해결 안 됨. JPQL/getter 패턴 자체 가 문제"

자기 점검

• "유저가 100명이면 100번 쿼리 실행이 당연한가?"의 답은? (힌트: NO)
• N+1을 인지하는 가장 빠른 방법은? (힌트: SQL 로그 활성화)

---

Unit 9.2 — join vs fetch join

선수 지식: Unit 9.1

핵심 차이 ⭐ :

일반 JOIN — N+1 해결 안 됨:

List<Member> members = em.createQuery(
    "SELECT m FROM Member m JOIN m.team t", Member.class)
    .getResultList();

실행되는 SQL:

SELECT m.*  -- ← Member만 SELECT, Team은 미포함
FROM Member m
JOIN Team t ON m.team_id = t.id;

→ Team은 영속성 컨텍스트에 안 들어옴 → getTeam() 호출 시 추가 SQL → N+1 여전!

FETCH JOIN — 한 번에 해결 ⭐ :

List<Member> members = em.createQuery(
    "SELECT m FROM Member m JOIN FETCH m.team", Member.class)
    .getResultList();

실행되는 SQL:

SELECT m.*, t.*  -- ← Team도 함께 SELECT!
FROM Member m
JOIN Team t ON m.team_id = t.id;

→ Team도 영속성 컨텍스트에 들어옴 → getTeam() SQL X → N+1 해결!

JOIN vs FETCH JOIN 정리:

	JOIN	FETCH JOIN
결과	Member만	Member + Team
영속성 컨텍스트	Member만	둘 다
getter 시 추가 쿼리	발생	없음

자기 점검

• LAZY 설정을 유지하면서 fetch join을 쓰는 게 왜 좋은가?
• ILIC의 어떤 쿼리에 fetch join이 필요할까? (힌트: 운임 + 운임 항목)

---

Unit 9.3 — fetch join + 페이징의 OneToMany 함정

선수 지식: Unit 9.2

핵심 함정 ⭐ :

@ManyToOne + 페이징 — 정상 동작:

List<Member> members = em.createQuery(
    "SELECT m FROM Member m JOIN FETCH m.team ORDER BY m.id", Member.class)
    .setFirstResult(0)
    .setMaxResults(3)  // ✅ 정상
    .getResultList();

SELECT m.*, t.* FROM Member m JOIN Team t ON ... ORDER BY m.id LIMIT 3;

→ Member 기준 페이징 OK

@OneToMany + 페이징 — 데이터 조회 문제 발생 ⭐ :

List<Team> teams = em.createQuery(
    "SELECT t FROM Team t JOIN FETCH t.members", Team.class)
    .setFirstResult(0)
    .setMaxResults(3)  // ❌ 위험!
    .getResultList();

무엇이 문제인가:

-- 의도: Team 3개
-- 실제 SQL:
SELECT t.*, m.* FROM Team t JOIN Member m ON t.id = m.team_id LIMIT 3;

LIMIT 3 가 JOIN 결과의 행 수 에 적용됨!

• Team A(멤버 3명) → 3개 행 → LIMIT 3에 모두 잡힘
• → Team B와 C는 결과에 없음!

Hibernate의 대응:

• 메모리에서 페이징 (DB로는 모든 데이터 로드)
• → 전체 데이터를 메모리로!
• 경고 로그: firstResult/maxResults specified with collection fetch; applying in memory!

왜 이 문제가 일어나는가:

"OneToMany는 1행이 N행으로 늘어남. 페이징의 단위가 깨짐"

자기 점검

• ILIC의 "최근 주문 10건 + 주문 항목" 조회 시 이 함정에 걸리는가?
• 메모리 페이징의 위험은? (힌트: OOM)

---

Unit 9.4 — @BatchSize 해결 ⭐

선수 지식: Unit 9.3

핵심 해결

@BatchSize:

• LAZY 유지 + IN 쿼리로 묶어서 조회
• N+1 해결 + OneToMany 페이징 문제 해결

@Entity
public class Team {
    @Id @GeneratedValue
    private Long id;
    
    @BatchSize(size = 10)  // 최대 10개씩 묶어서
    @OneToMany(mappedBy = "team", fetch = FetchType.LAZY)
    private List<Member> members;
}

페이징 + @BatchSize 사용:

List<Team> teams = em.createQuery(
    "SELECT t FROM Team t ORDER BY t.id", Team.class)
    .setFirstResult(0)
    .setMaxResults(3)  // ✅ Team 기준 정확한 페이징
    .getResultList();

for (Team team : teams) {
    team.getMembers().size();
}

실행되는 SQL:

-- (1) Team 페이징 조회
SELECT id FROM Team ORDER BY id LIMIT 3;

-- (2) IN 절로 한 번에 멤버 조회
SELECT * FROM Member WHERE team_id IN (1, 2, 3);

→ 2번의 쿼리로 끝! (1+N → 2 또는 1+N/배치사이즈)

전역 설정:

spring:
  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 100

⚠️ 주의 — fetch join과 함께 쓰지 말 것:

• fetch join이 우선 → @BatchSize 무시

3가지 해결책 비교 ⭐ :

도구	적합 상황
fetch join	ManyToOne 단건, 페이징 없는 컬렉션
@BatchSize	OneToMany + 페이징, 일반 LAZY 최적화
EntityGraph	동적으로 fetch 전략 결정

자기 점검

• batch size를 너무 크게 설정하면 어떤 문제가? (힌트: IN 절 한도)
• ILIC에서 default_batch_fetch_size를 어떻게 설정하는 게 좋을까?

---

📚 Phase 10 — 영속성 전이 + JPQL/QueryDSL

목표: JPA 학습을 마무리하는 4가지 도구.

Unit 10.1 — CASCADE (영속성 전이)

선수 지식: Phase 5, 6

핵심 개념

CASCADE:

• "부모의 작업이 자식에게 전파"
• 부모 저장 → 자식 자동 저장
• 부모 삭제 → 자식 자동 삭제

@Entity
public class Parent {
    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL)
    private List<Child> children = new ArrayList<>();
}

CASCADE 옵션:

옵션	동작
ALL	모든 작업 전파
PERSIST	저장만 전파
REMOVE	삭제만 전파
MERGE	병합만 전파
REFRESH	새로고침
DETACH	분리

실무 사례:

Parent parent = new Parent();
parent.addChild(child1);
parent.addChild(child2);

em.persist(parent);  // child1, child2도 자동 저장!

언제 사용:

• 부모-자식 관계가 명확 할 때 (라이프 사이클 같이감)
• 단일 부모 가 자식을 소유 (다른 곳에서 자식을 참조 X)
• 예: 게시글-댓글, 주문-주문아이템

자기 점검

• 여러 곳에서 참조되는 자식에 CASCADE.REMOVE를 걸면? (힌트: 사고)
• ILIC에서 CASCADE가 적합한 관계는? (힌트: 주문-주문항목)

---

Unit 10.2 — orphanRemoval (고아 객체)

선수 지식: Unit 10.1

핵심 개념

orphanRemoval:

• 부모-자식 관계가 끊어진 자식 자동 삭제
• 자식 컬렉션에서 제거 시 → DB에서도 삭제

@Entity
public class Parent {
    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Child> children = new ArrayList<>();
    
    public void removeChild(Child child) {
        children.remove(child);
        child.setParent(null);
    }
}

동작:

Parent parent = em.find(Parent.class, 1L);
parent.removeChild(parent.getChildren().get(0));
// → DELETE 자동 실행

CASCADE.REMOVE vs orphanRemoval ⭐ :

	CASCADE.REMOVE	orphanRemoval
트리거	부모 자체 삭제	자식 컬렉션 제거
사용 시점	em.remove(parent)	parent.children.remove(child)

둘 다 있어야 완벽한 부모-자식 관리:

@OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)

⚠️ 주의:

• orphanRemoval은 단일 소유자 관계 일 때만
• 다른 곳에서 참조되는 자식에 쓰면 사고

자기 점검

• 부모를 삭제하면 자식도 삭제되어야 하지만 자식만 따로 삭제하지 않는다면 어떤 옵션이? (힌트: CASCADE.REMOVE만)
• ILIC의 운임 견적과 운임 항목 관계에 어떤 조합이 적합한가?

---

Unit 10.3 — JPQL의 본질

선수 지식: Phase 5

핵심 개념

JPQL (Java Persistence Query Language):

• JPA가 제공하는 객체 지향 쿼리 언어
• 테이블이 아닌 엔티티 객체 대상

List<User> users = em.createQuery(
    "SELECT u FROM User u WHERE u.age > 20", User.class)
    .getResultList();

JPQL → SQL 변환:

SELECT * FROM user WHERE age > 20;

SQL과의 차이:

• 대상: 엔티티 vs 테이블
• 대소문자: 엔티티 이름은 case-sensitive
• 자동 매핑: 결과를 엔티티 객체로

SQL이 필요한 시점:

• 매우 복잡한 통계 쿼리
• DB 특화 기능 사용
• 네이티브 쿼리: em.createNativeQuery(...)

자기 점검

• 왜 JPA가 자체 쿼리 언어를 만들었는가?
• JPQL과 SQL을 함께 쓸 수 있는가? (힌트: YES — Native Query)

---

Unit 10.4 — QueryDSL (실무 표준) ⭐

선수 지식: Unit 10.3

핵심 개념

QueryDSL:

• JPQL을 자바 코드로 작성
• 컴파일 시점에 오류 검출
• 동적 쿼리 작성에 강력

JPQL의 문제:

• 문자열 기반 → 오타가 런타임 에러
• 동적 쿼리 작성 어려움

QueryDSL의 해결:

List<User> users = queryFactory
    .selectFrom(qUser)
    .where(qUser.age.gt(20))
    .orderBy(qUser.name.asc())
    .offset(10)
    .limit(5)
    .fetch();

자동 SQL 변환:

SELECT * FROM user WHERE age > 20 ORDER BY name ASC LIMIT 5 OFFSET 10;

QueryDSL의 장점 ⭐ :
1. 타입 안전 — 컴파일 시점 오류 검출
2. 자동완성 — IDE 지원
3. 동적 쿼리 — BooleanBuilder, 조건문 자유롭게
4. 재사용성 — 메서드로 추출 가능

실무 표준 조합:

[Spring Data JPA] - 단순 CRUD, 메서드 이름 쿼리
       +
[QueryDSL] - 복잡 쿼리, 동적 쿼리
       =
실무 JPA 프로젝트

ILIC 사례 (가능성):

• 단순 CRUD: Spring Data JPA Repository
• 복잡 검색 (운임 다중 조건 조회): QueryDSL

자기 점검

• QueryDSL 학습 비용이 있음에도 권장되는 이유는?
• ILIC의 운임 검색 조건이 6개라면 QueryDSL이 어떻게 도움이 되는가? (힌트: 동적 where)

---

🎓 종합 자기 점검 (11-12주차 졸업 시험)

Part A: 11주차

SQL Mapper와 ORM

1. SQL Mapper와 ORM의 매핑 대상 차이는?
2. JPA, Hibernate, Spring Data JPA의 관계는?
3. 객체-관계 패러다임 불일치 5가지 측면은?

엔티티 매핑

4. @Entity의 4가지 조건은?
5. 임베디드 타입을 가변으로 만들면 어떤 사고가?
6. ddl-auto의 운영 환경 권장값은?

EntityManager와 영속성 컨텍스트

7. EntityManagerFactory와 EntityManager의 생명주기 차이는?
8. 영속성 컨텍스트의 정의를 한 문장으로?
9. 엔티티 4가지 상태와 전이 메서드는?

4가지 장점 (★)

10. 1차 캐시의 동작 6단계는?
11. 동일성 보장이 가능한 이유는?
12. 쓰기 지연이 작동하지 않는 경우는?
13. 변경 감지(Dirty Checking)의 내부 동작은? (스냅샷)
14. 플러시 발생 3가지 시점은?
15. 1차 캐시와 2차 캐시의 차이 4가지는?

Part B: 12주차

연관관계

16. 4가지 연관관계와 각각의 사용 시점은?
17. 단방향과 양방향의 객체 입장 vs DB 입장 차이는?
18. N:M을 실무에서 안 쓰는 이유와 대안은?

mappedBy

19. 연관관계의 주인이 필요한 이유는?
20. mappedBy의 값이 가리키는 것은?
21. 양쪽을 함께 변경해야 하는 이유는? (힌트: 1차 캐시)

프록시와 로딩

22. em.find()와 em.getReference()의 차이는?
23. 프록시 비교에 instanceof를 쓰는 이유는?
24. 4가지 연관관계의 기본 fetch 전략은? (외울 것)
25. 모든 연관관계를 LAZY로 명시하라는 권장의 이유는?

N+1 문제 (★)

26. N+1 문제의 정의를 한 문장으로?
27. 즉시 로딩과 지연 로딩 모두에서 N+1이 발생하는 이유는?
28. JOIN과 FETCH JOIN의 결정적 차이는?
29. OneToMany + 페이징 + fetch join 사용 시 발생하는 함정은?
30. @BatchSize가 OneToMany 페이징 함정을 어떻게 해결하는가?

CASCADE와 쿼리 도구

31. CASCADE.REMOVE와 orphanRemoval의 차이는?
32. JPQL이 SQL과 다른 본질적 차이는?
33. QueryDSL을 권장하는 이유 3가지는?

---

📌 학습 운영 팁

9-섹션 마스터 프롬프트로 깊이 파야 할 Unit

★★★ 면접·실무 단골 (반드시):

• Unit 5.4 — 변경 감지(Dirty Checking) 내부 동작
• Unit 6.3 — N:1 ManyToOne (가장 자주 사용)
• Unit 7.2 — mappedBy와 연관관계의 주인
• Unit 8.4 — LAZY/EAGER 기본값과 권장
• Unit 9.1~9.4 — N+1 문제와 4가지 해결책
• Unit 10.4 — QueryDSL

★★ 매우 권장:

• Unit 5.1 — 1차 캐시
• Unit 5.5 — 플러시
• Unit 6.5 — N:M 중간 엔티티 패턴
• Unit 8.2 — 프록시 메커니즘

Phase별 진도 체크리스트

[ Part A — 11주차 ]
[ ] Phase 1 — 싱글톤 + SQL Mapper의 역사 (Unit 1.1~1.3)
[ ] Phase 2 — ORM/JPA 본질 (Unit 2.1~2.3)
[ ] Phase 3 — 엔티티 매핑 (Unit 3.1~3.4)
[ ] Phase 4 — EntityManager + 영속성 컨텍스트 (Unit 4.1~4.4)
[ ] Phase 5 — 4가지 장점 (Unit 5.1~5.5)  ★ 11주차 정점

[ Part B — 12주차 ]
[ ] Phase 6 — 4가지 연관관계 (Unit 6.1~6.5)
[ ] Phase 7 — mappedBy (Unit 7.1~7.3)
[ ] Phase 8 — 프록시와 로딩 (Unit 8.1~8.4)
[ ] Phase 9 — N+1 문제와 해결 (Unit 9.1~9.4)  ★ 12주차 정점
[ ] Phase 10 — CASCADE + JPQL/QueryDSL (Unit 10.1~10.4)

[ ] 종합 자기 점검 33문항 통과

11-12주차의 두 정점

11주차 정점 — Phase 5 (4가지 장점):

• JPA의 핵심 가치를 이해하는 지점
• 1차 캐시 → 동일성 → 쓰기 지연 → 변경 감지의 연쇄
• "왜 JPA가 강력한가"의 답

12주차 정점 — Phase 9 (N+1 문제):

• JPA 실무의 최대 함정
• fetch join, @BatchSize 의 결정
• 면접·실무 모두에서 가장 중요

1~12주차 통합 흐름의 절정 (다시)

Java 학습의 또 하나의 클라이맥스:

• 1~3주차: 자바 언어
• 4주차: 동시성
• 5주차: Spring 입문
• 6주차: DB 접근 진화
• 7주차: JPA 입문 + 트랜잭션
• 8-9주차: AOP 메커니즘 (★)
• 10주차: 트랜잭션 마무리
• 11-12주차: JPA 완전 정복 (★★)

→ 8-9주차가 AOP의 정점, 11-12주차가 JPA의 정점

학습 시 주의

이번 2주차는 반드시 SQL 로그를 켜고 학습하세요:

spring:
  jpa:
    show-sql: true
    properties:
      hibernate:
        format_sql: true
        use_sql_comments: true
logging:
  level:
    org.hibernate.SQL: DEBUG
    org.hibernate.type.descriptor.sql.BasicBinder: TRACE

특히 Phase 5 (4가지 장점) 와 Phase 9 (N+1) 는 SQL 로그 없이는 이해 불가능. 직접 실행하면서 쿼리가 어떻게 나가는지를 시각적으로 확인하세요.

---