더티 체킹(Dirty Checking)

더티 체킹(Dirty Checking)은 JPA(Java Persistence API)의 영속성 컨텍스트(Persistence Context)가 관리 중인 엔티티(Entity)의 변경을 스스로 감지해서, 플러시(Flush) 시점에 UPDATE 쿼리를 만들어 데이터베이스에 반영하는 기능이다. 개발자가 별도의 저장 메서드를 호출하지 않아도 트랜잭션 안에서 엔티티의 필드 값만 바꾸면 수정이 반영되므로, 수정 로직을 객체지향적인 코드로 쓸 수 있게 해 준다.

왜 변경 감지가 필요한가

SQL 중심 개발에서는 데이터를 수정할 때마다 UPDATE 문을 작성하고 어떤 컬럼을 바꿀지 일일이 나열해야 한다. 반면 JPA는 데이터베이스의 행을 자바 객체로 옮겨 와서 다루는 것을 목표로 하므로, 객체의 상태를 바꾸면 그 변화가 저장소에도 반영되는 것이 자연스럽다. 더티 체킹은 이 간극을 메우는 장치다. 조회한 엔티티의 세터(Setter)나 비즈니스 메서드로 상태를 바꾸기만 하면, 무엇이 어떻게 바뀌었는지 추적해 SQL로 번역하는 일은 영속성 컨텍스트가 맡는다.

스냅샷 비교로 동작한다

영속성 컨텍스트는 엔티티를 1차 캐시에 넣는 순간, 그 시점의 필드 값을 복사한 스냅샷(Snapshot)을 함께 보관한다. 이후 플러시가 일어나면 다음 과정이 진행된다.

1. 1차 캐시에 있는 모든 영속 엔티티를 순회하면서 현재 값과 스냅샷을 필드 단위로 비교한다.
2. 달라진 엔티티가 있으면 UPDATE SQL을 생성해 쓰기 지연 SQL 저장소에 등록한다.
3. 쓰기 지연 저장소에 쌓인 SQL을 데이터베이스로 전송한다.
4. 트랜잭션이 커밋되면 변경이 확정된다.

이때 하이버네이트(Hibernate)가 생성하는 UPDATE 문은 기본적으로 바뀐 필드만이 아니라 엔티티의 모든 컬럼을 포함한다. 컬럼이 고정된 쿼리를 재사용하면 구문을 미리 준비해 둘 수 있고 캐싱 효율이 좋기 때문이다. 컬럼이 매우 많거나 변경 폭이 좁은 테이블이라면 @DynamicUpdate를 붙여 바뀐 컬럼만 포함한 쿼리를 만들 수 있지만, 매번 쿼리를 새로 만드는 비용이 생기므로 측정 후에 적용하는 것이 좋다.

플러시 시점과 트랜잭션

더티 체킹은 아무 때나 일어나는 것이 아니라 플러시 시점에 일어난다. 플러시는 트랜잭션 커밋 직전, JPQL(Java Persistence Query Language) 쿼리 실행 직전, 그리고 flush()를 직접 호출할 때 발생한다. 따라서 스프링에서는 @Transactional 범위 안에서 엔티티를 수정해야 하며, 트랜잭션이 커밋되면서 변경이 자동으로 반영된다. 플러시는 SQL을 전송하는 것이지 트랜잭션을 커밋하는 것이 아니므로, 플러시 이후에도 롤백하면 변경은 취소된다는 점을 구분해야 한다.

코드 예시

회원 이름을 수정하는 서비스 코드는 다음과 같다. save()나 update() 같은 호출이 없다는 점이 핵심이다.

@Service
public class MemberService {

    private final MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Transactional
    public void changeName(Long memberId, String newName) {
        Member member = memberRepository.findById(memberId)
                .orElseThrow(() -> new IllegalArgumentException("회원이 없습니다."));

        member.changeName(newName); // 필드 값만 변경한다
        // 트랜잭션 커밋 시점에 플러시가 일어나며
        // 스냅샷과 비교해 UPDATE 쿼리가 자동 실행된다
    }
}

@Entity
public class Member {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    public void changeName(String newName) {
        this.name = newName;
    }
}

changeName처럼 의도가 드러나는 메서드로 상태를 바꾸면, 수정 로직이 엔티티 안에 응집되어 도메인 주도 설계와도 잘 어울린다.