[스프링부트 #16] JPA 연관관계 성능 튜닝과 Dirty Checking 원리

오늘은 JPA에서 연관관계를 가진 엔티티를 조회할 때 성능 저하를 막는 방법과,

엔티티 수정 시 Dirty Checking(더티 체킹)이 어떻게 동작하는지 정리합니다.

여기에 인증·권한 체크와 같은 부가 로직 분리 팁도 함께 다룹니다.

1. 연관관계와 성능 문제

• Board 목록을 불러올 때마다, 각 Board마다 User를 추가로 조회 → N+1 문제

• 결국 SQL이 N+1번 실행되어 성능 급격히 저하

원칙

• EAGER 로딩 금지

• 항상 LAZY 로딩으로 설정 후, 필요한 경우 fetch join 사용

2. 성능 개선 방법

1. JOIN(fetch join)

2. IN query

public Board findByIdJoinUser(int id) {
    Query query = em.createQuery(
        "select b from Board b join fetch b.user where b.id = :id",
        Board.class
    );
    query.setParameter("id", id);
    return query.getSingleResult();
}

3. Dirty Checking(더티 체킹)과 flush

동작 원리

flush 시점

• em.flush() 직접 호출

• 트랜잭션 종료 시점(@Transactional 메서드 종료)

• JPQL/SQL 직접 실행 시

예제

@Test
public void update_test() {
    Board findBoard = boardJpaRepository.findById(1); // 1) 조회 → PC에 저장
    findBoard.update("title change", "content change"); // 2) 상태 변경
    // 3) flush 시점에 update SQL 실행
}

흐름 정리

1. findById(id)
• JPA가 DB에서 Board 엔티티를 조회해서 **영속성 컨텍스트(1차 캐시)**에 올림.
• 이 시점의 findboard 객체는 영속 상태.

2. findboard.update(...)
• 영속 상태의 엔티티 필드 값을 변경.
• JPA는 "변경 전 스냅샷"과 "현재 값"을 비교하기 위해 이 변경을 트래킹.

3. 트랜잭션 종료 시점 (@Transactional 종료)
• JPA가 flush() 실행.
• 변경 감지(Dirty Checking)로, 바뀐 필드만 UPDATE 쿼리 생성.
• 쿼리 전송 후 커밋.

왜 더티 체킹인가?

• update(...)는 DB에 직접 UPDATE 쿼리를 날리는 게 아니라, 엔티티 객체의 상태만 변경.

• JPA가 알아서 트랜잭션 끝날 때 변경된 부분을 찾아서 UPDATE SQL로 만들어 실행.

• 즉, SQL을 내가 안 써도 JPA가 변경 감지를 해줌.

4. 인증·권한 체크

브라우저로부터 받은 데이터는 절대 신뢰하지 말 것!

예시: 세션 로그인 여부 확인

User sessionUser = (User) session.getAttribute("sessionUser");
if (sessionUser == null) {
    throw new RuntimeException("로그인 하세요");
}

• 인증 실패: 401 Unauthorized

• 권한 실패: 403 Forbidden
(예: 내가 쓴 글이 아닌데 삭제 시도)

5. 부가 로직 분리

• 인증, 권한 체크, 로깅 등은 부가 로직

• 핵심 비즈니스 로직과 분리해야 유지보수가 쉬움

• 나중에 Interceptor, Filter, AOP로 빼서 관리 가능

6. Board.java의 Setter

7. Java HttpSession과 getAttribute() 이해하기

User sessionUser = (User) session.getAttribute("sessionUser");

오늘 내용 한 장 요약

• EAGER 금지, fetch join으로 N+1 방지

• Dirty Checking은 변경 내용을 모아 한 번에 반영

• flush 시점: 직접 호출 / 트랜잭션 종료 / 쿼리 실행 시

• 성능 최적화에서 I/O 줄이기가 핵심

• 인증(401) / 권한(403) 구분

• 부가 로직은 핵심 로직과 분리