JPA/Hibernate가 생성하는 SQL 이해하기

지난 글에서 Raw SQL과 ORM의 트레이드오프를 살펴봤다. 이번에는 Java 진영에서 가장 많이 사용되는 Full ORM인 **JPA(Jakarta Persistence API)**와 그 구현체인 Hibernate가 실제로 어떤 SQL을 언제 발행하는지 집중적으로 알아본다. ORM 성능 문제의 대부분은 “어떤 SQL이 발행되는지 모르는 것”에서 비롯된다.

영속성 컨텍스트와 엔티티 생명주기

JPA의 핵심 개념은 **영속성 컨텍스트(Persistence Context)**다. EntityManager가 관리하는 1차 캐시이며, 여기에 등록된 엔티티를 Managed(영속) 상태라고 한다.

JPA 엔티티 생명주기

EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin();

// 1. Transient → Managed
Order order = new Order();     // Transient: DB와 무관
em.persist(order);             // Managed: 영속성 컨텍스트 등록, INSERT 예약

// 2. Managed 상태에서 변경
order.setStatus("PAID");       // Dirty로 표시, SQL 없음

// 3. flush 시 SQL 발행
tx.commit();
// → INSERT + UPDATE 순차 발행

em.close();                    // Detached 상태

Dirty Checking — 마법의 이면

Hibernate는 엔티티를 조회할 때 스냅샷을 내부에 저장한다. flush 시 스냅샷과 현재 상태를 비교해 변경된 필드만 UPDATE SQL을 생성한다. 별도의 save() 호출이 필요 없다.

@Transactional
public void pay(Long orderId) {
    Order order = orderRepo.findById(orderId).orElseThrow();
    // SELECT * FROM orders WHERE id = ?  ← 조회 + 스냅샷 저장

    order.setStatus("PAID");
    // SQL 없음 — 변경 사항만 내부 기록

    // 메서드 종료 시 flush → commit
    // UPDATE orders SET status='PAID' WHERE id=?  ← 변경 필드만
}

주의: 기본적으로 Hibernate는 변경된 필드만이 아니라 모든 컬럼을 UPDATE하도록 SQL을 생성한다. @DynamicUpdate를 붙이면 실제 변경된 컬럼만 UPDATE SQL에 포함된다.

쓰기 지연 (Write-Behind)

persist()나 필드 변경이 일어나도 즉시 SQL이 발행되지 않는다. flush(또는 commit) 시점에 모아서 발행한다. 이를 쓰기 지연이라 한다.

for (int i = 0; i < 1000; i++) {
    em.persist(new Order(...));  // 즉시 SQL 없음 — 큐에 쌓임
    if (i % 50 == 0) {
        em.flush();   // 50개씩 실제 INSERT 발행
        em.clear();   // 1차 캐시 초기화 (메모리 관리)
    }
}

배치 처리 시 flush() + clear() 주기를 조절해 메모리와 성능을 균형 있게 관리한다.

N+1 문제

가장 흔한 JPA 성능 함정이다. 컬렉션 연관관계를 기본 LAZY 로딩으로 설정하면, 루프 안에서 접근할 때마다 SELECT가 추가로 발행된다.

// N+1 발생: 주문 100건 조회 후 각 주문의 고객 접근
List<Order> orders = orderRepo.findAll();    // SELECT 1번 (100건)
for (Order o : orders) {
    System.out.println(o.getCustomer().getName()); // SELECT 100번 추가!
}
// 총 101번 쿼리 발행

해결 1: JOIN FETCH

@Query("SELECT o FROM Order o JOIN FETCH o.customer WHERE o.status = :status")
List<Order> findWithCustomer(@Param("status") String status);
// 발행: SELECT o.*, c.* FROM orders o INNER JOIN customers c ON ...
// 1번으로 끝

해결 2: @EntityGraph

@EntityGraph(attributePaths = {"customer", "items"})
List<Order> findByStatus(String status);
// LEFT OUTER JOIN으로 customer와 items 한 번에 페치

해결 3: @BatchSize

@BatchSize(size = 100)
@OneToMany(mappedBy = "order")
private List<OrderItem> items;
// 접근 시 IN절로 묶어서 SELECT: WHERE order_id IN (1,2,...,100)
// N번 → N/100번으로 감소

Hibernate SQL 패턴

JPQL vs Criteria API vs 네이티브 쿼리

JPA는 세 가지 쿼리 방식을 제공한다.

// 1. JPQL: 객체 중심 쿼리 언어
TypedQuery<Order> q = em.createQuery(
    "SELECT o FROM Order o WHERE o.amount > :min", Order.class);
q.setParameter("min", new BigDecimal("10000"));

// 2. Criteria API: 타입 안전, 동적 조건에 유리
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Order> cq = cb.createQuery(Order.class);
Root<Order> root = cq.from(Order.class);
cq.select(root).where(cb.gt(root.get("amount"), 10000));

// 3. 네이티브 쿼리: 복잡한 집계는 Raw SQL
@Query(value = "SELECT region, SUM(amount) FROM orders GROUP BY region",
       nativeQuery = true)
List<Object[]> getRegionSummary();

SQL 로깅 설정

개발 중에는 Hibernate가 실제로 발행하는 SQL을 반드시 확인해야 한다.

# application.yml
logging:
  level:
    org.hibernate.SQL: DEBUG
    org.hibernate.type.descriptor.sql: TRACE   # 파라미터 값 확인

spring:
  jpa:
    properties:
      hibernate:
        format_sql: true          # SQL 들여쓰기
        generate_statistics: true # 통계 (쿼리 수 등)

정리

JPA/Hibernate를 효과적으로 사용하려면 “내가 작성한 코드가 어떤 SQL을 발행하는가”를 항상 의식해야 한다. Dirty Checking과 쓰기 지연은 편리하지만, N+1 문제처럼 눈에 안 보이는 성능 함정을 만들기도 한다. SQL 로깅을 켜두고 연관 관계 로딩 전략을 명확히 설계하는 것이 JPA 성능 최적화의 출발점이다.

지난 글: Raw SQL vs ORM — 언제 무엇을 쓸까

다음 글: MyBatis 동적 SQL — 유연한 쿼리 빌드

읽어주셔서 감사합니다. 😊