✅ Lazy VS Eager

• 모든 연관관계는 기본적으로 LAZY로 설정하고, 필요한 경우만 명시적으로 패치(fetch)하는 것이 권장됨

✅ 지연 로딩의 동작 구조

val order = orderRepositoryfindById(1L)
val member = order.member // 여기서는 프록시 객체
print(member.name) // 이때 실제 SELECT 발생

• 연관된 엔티티는 실제 객체가 아니라 프록시(proxy)로 로딩됨
• 이후 프록시 객체의 필드에 접근할 때 SELECT 쿼리가 발생하고 값을 사용할 수 있게됨

✅ N + 1 문제

val orders = orderRepository.findAll()
for(order in orders) {
	println(order.member.name) // 각 order 엔티티마다 member 조회 SELECT 발생
}

• 하지만, 지연 로딩도 잘못 사용하면 쿼리가 폭발적으로 발생하게됨
• 예시는 총 N + 1 개의 쿼리가 발생하게되어 N + 1 문제로 불림

✅ 지연 로딩의 최적화 전략

• Fetch Join

  @Query("select o from Order o join fetch o.member")
  fun findAllWithMember(): List<Order>
  

  • 가장 일반적이면서 강력한 방법
  • 한 번의 쿼리로 연관된 엔티티까지 모두 가져옴
  • 하지만 페이징과 함께 쓸 때 문제가 있고 조인 대상이 많으면 중복 데이터가 증가
    • JPA는 엔티티 단위로 페이징을 하고 싶지만 DB는 조회된 레코드를 기준으로 페이징하기 때문에 문제 발생
    • 예를 들어 10개의 팀 엔티티를 조회하고 싶은데 각 팀 회원이 5명씩 있어서 레코드에서는 2개 팀으로 10개가 채워져서 조회가 되고 결과적으로는 2개의 팀만 조회가 되는 경우가 있기 때문
  • 실무에서 1:N 관계에서 fetch join은 N이 아닌 1 쪽에서만 사용(N쪽 fetch join은 1 쪽의 엔티티 중복을 일으킴)

• Batch Size 설정

  // 1. @BatchSize
  @OneToMany(mappedBy = "order"
  @BatchSize(size = 100)
  val orderItems: List<OrderItem> = mutableListOf()
  
  // 2. hibernate.default_batch_fetch_size(yaml)
  spring:
  	jpa:
  		properties:
  			hibernate.default_batch_fetch_size: 100
  

  • JPA가 지연 로딩 시 여러 건을 묶어서 in 절로 한 번에 조회하게 하는 설정
  • 간단하면서 fetch join보다 유연함을 가지고 페이징에도 안전
  • 실제로 대규모 서비스에서 가장 자주 사용하는 N + 1 완화 기법
  • 결론적으로는 목록 조회에는 좋긴 한데 단건 조회에 대해서는 조인을 이용하는 다른 방법이 좋을 수 있음

• EntityGraph

  @EntityGraph(attributePaths = ["member", "delivery"]
  @Query("select o from Order o")
  fun findAllWithMemberAndDelivery(): List<Order>
  

  • fetch join과 달리 JPQL 변경 없이 가능
  • 조건적으로 fetch할 때 사용하기 좋음 또한 JPA 표준이라 Hibernate 외 구현체에도 동일하게 동작
  • 하지만 복잡한 그래프 구성에는 사용하기 어렵고 조합이 많아지면 관리가 어려움

• DTO Projection

  @Query("""
  	select new com.example.dto.OrderDto(o.id, m.name, d.address)
  	from Order o
  	join o.member M
  	join o.delivery d
  """)
  fun findOrderDtos(): List<OrderDto>
  

  • 조회용일 때는 굳이 모든 필드를 가져올 필요가 없기 때문에 사용하기 좋음
  • 하지만 엔티티가 아니기 때문에 변경 감지 불가능(따라서 조회용으로만 사용)
  • 유지보수가 어렵고 코드가 늘어나게됨

✅ 대규모 프로젝트에서의 선택

• 조회 전용 API
  • 쿼리 기반(DTO, projection)
  • 명시적 fetch join, group by, pagination을 직접 제어
  • 성능/트래픽 중심
• 도메인 내부 로직(쓰기/비즈니스용)
  • 영속성 컨택스트 기반, batch size + lazy로 관리
  • 재사용성 중심
• ‼️ 결론적으로 읽기는 쿼리 중심 쓰기는 엔티티 중심으로 설계