[SpringBoot] 💥 관습적인 EntityManager 의 clear 사용을 멈추세요 (feat. JPQL 과 1차 캐시)

🤔 궁금증을 갖게 된 계기

리뷰어 분과 대화를 주고 받다가, EntityManager 의 clear 를 사용한 이유에 대한 질문을 받았다. 이에 대해 나는 단순 지식 확인 측면이겠거니 - 하고 딱히 나의 지식을 더블 체크하지 않고 답변을 작성했었다.

나의 의도는 레포지토리의 코드가 제대로 동작하는지에 대한 검증을 하고자 하는 것이었다.

만약 EntityManager 의 clear 를 하지 않으면 실제 쿼리를 날리는 것이 아니라 1차 캐시를 확인해 쿼리를 날리지 않을 것이라고 생각했다. 그래서 작성한 대부분의 테스트 코드에서 습관적으로 EntityManager.clear 를 호출했다.

나름 확신이 있었기에 호기롭게 대답했다. 그런데 리뷰어의 답변은 다음과 같았다.

오싹한 기분이 들었다. 혹시 영속성 컨텍스트를 안 타나..?

🔎 이 글을 이런 분들께 추천합니다

위의 리뷰 내용에서 나와 같이 오싹하신 분들
쿼리 메서드의 동작 방식을 잘 모르시는 분들
습관적으로 EntityManager 의 clear 를 하기는 했는데 솔직히 왜 하는지 잘 모르겠는 분들

이제부터 여러 실험들을 해보자. 진짜로 영속성 컨텍스트를 타는지 안타는지!

우선, 기본적인 세팅은 다음과 같다.

@Entity
@Getter
@NoArgsConstructor
public class Member {

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

    private String name;

    @ManyToOne
    private Team team;

    public Member(String name, Team team) {
        this.name = name;
        this.team = team;
    }
}

@Entity
@NoArgsConstructor
public class Team {

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

    private String name;

    public Team(String name) {
        this.name = name;
    }
}

간단히 설명하자면 회원이 팀에 속해있는, Member 가 Team 을 갖고 있는 구조다.

public interface MemberJpaRepository extends JpaRepository<Member, Long> {
    List<Member> findByTeam(Team team);
}

그리고 MemberJpaRepository 에는 Team 을 통해 Member 들을 찾아오는 findByTeam 이라는 메서드가 존재한다.

다시 한번 짚어보자. 나의 가설은

테스트를 할 때 EntityManager#clear 를 해야 하는 이유는 1차 캐시를 타지 않고 쿼리가 나가도록 하기 위함이다.

✅ 1. 쿼리 메서드에 대해 EntityManager#clear 를 호출하는 경우

@Test
@DisplayName("팀에 속하는 멤버들을 조회한다")
void test1() {
    // given
    Team team = new Team("히로의 팀");
    entityManager.persist(team);

    Member 히로1 = new Member("히로1", team);
    entityManager.persist(히로1);

    Member 히로2 = new Member("히로2", team);
    entityManager.persist(히로2);

    Member 히로3 = new Member("히로3", team);
    entityManager.persist(히로3);

    Member 히로4 = new Member("히로4", team);
    entityManager.persist(히로4);

    entityManager.flush();
    entityManager.clear();

    // then
    System.out.println("======");
    memberJpaRepository.findByTeam(team).forEach(member -> System.out.println(member.getName()));
}

위와 같이 Team 하나를 저장하고, 이에 해당하는 Member 들 4개를 저장했다.

그리고 저장된 Team 을 기준으로 Member 들을 조회해오도록 했다.

======
Hibernate: 
    select
        m1_0.id,
        m1_0.name,
        m1_0.team_id 
    from
        member m1_0 
    where
        m1_0.team_id=?
Hibernate: 
    select
        t1_0.id,
        t1_0.name 
    from
        team t1_0 
    where
        t1_0.id=?
히로1
히로2
히로3
히로4

그렇게 했더니, 위와 같이 쿼리가 나갔다. 여기까지는 clear 를 하면, 쿼리가 나간다 라는 내 가설에 부합한다.

✅ 2. 쿼리 메서드에 대해 EntityManager#clear 를 호출하지 않는 경우

======
Hibernate: 
    select
        m1_0.id,
        m1_0.name,
        m1_0.team_id 
    from
        member m1_0 
    where
        m1_0.team_id=?
히로1
히로2
히로3
히로4

clear 를 호출하지 않았음에도 쿼리가 나갔다. 즉, 1차 캐시에 이미 조회해야 하는 엔티티가 모두 존재함에도 쿼리가 나간 것이다.

clear 를 하지 않으면 쿼리가 나가지 않고 1차 캐시만을 참조한다는 내 가설이 틀린 상황이다.

여기까지 봤을 때 우리는 어렴풋이 다음과 같은 결론을 내릴 것이다.

아! EntityManager#clear 아무 의미 없네. 그냥 다 쿼리 나가네! 싶어진다.

✅ 3. findById 에 대해 EntityManager#clear 를 호출하는 경우

그렇다면 나의 가설이 틀렸음을 검증하기 위해 또 다른 테스트를 해보자.

이번에는 직접 쿼리 메서드를 정의하지 않고 findById 를 통해 테스트를 해볼 것이다.

@Test
@DisplayName("id 를 통해 멤버를 조회한다")
void test2() {
    // given
    Team team = new Team("히로의 팀");
    entityManager.persist(team);

    Member 히로1 = new Member("히로1", team);
    entityManager.persist(히로1);

    Long id = 히로1.getId();

    entityManager.flush();
    entityManager.clear();

    // then
    System.out.println("======");
    memberJpaRepository.findById(id);
}

======
Hibernate: 
    select
        m1_0.id,
        m1_0.name,
        t1_0.id,
        t1_0.name 
    from
        member m1_0 
    left join
        team t1_0 
            on t1_0.id=m1_0.team_id 
    where
        m1_0.id=?
히로1

여전히 쿼리가 나가는 것을 볼 수 있다. 여기까지는 아까와 똑같다.

✅ 4. findById 에 대해 EntityManager#clear 를 호출하지 않는 경우

======
히로1

오잉. 이번에는 나가지 않았다.

EntityManager#clear 가 테스트에 아무런 영향이 없나보다 싶었던 수정된 가설이 또 다시 틀린 것이다.

그런데 어떤 차이점으로 인해 다른 결과가 나타나게 된 것일까?

정답은 findById 와 그렇지 않은 경우에 있다.

MemberJpaRepository#findByTeam 은 직접 새롭게 정의한 쿼리 메서드이다.

그러나 findById 는 컴파일 타임에 포함되는, 즉 JPA 가 제공하는 기본 메서드이다.

🐸 쿼리 메서드의 실행 과정

다음 문서에서 이야기하고 있듯이, JPA 의 쿼리 메서드는 내부적으로 JPQL 로 변환이 된다.

JPA Query Methods :: Spring Data JPA

By default, Spring Data JPA uses position-based parameter binding, as described in all the preceding examples. This makes query methods a little error-prone when refactoring regarding the parameter position. To solve this issue, you can use @Param annotati

docs.spring.io

예를 들어, findByLastnameOrFirstname 라는 메서드를 정의했다면 다음과 같은 JPQL 스니펫이 된다.

… where x.lastname = ?1 or x.firstname = ?2

즉, 우리가 정의한 쿼리 메서드는 메서드의 형태에서 JPQL 로 변환이 되고, 그 이후에 네이티브 쿼리가 되어 최종적으로 시행된다.

🐸 findById 의 동작 방식

public Optional<T> findById(ID id) {
  Assert.notNull(id, "The given id must not be null");
  Class<T> domainType = this.getDomainClass();
  if (this.metadata == null) {
      return Optional.ofNullable(this.entityManager.find(domainType, id));
  } else {
      LockModeType type = this.metadata.getLockModeType();
      Map<String, Object> hints = this.getHints();
      return Optional.ofNullable(type == null ? this.entityManager.find(domainType, id, hints) : this.entityManager.find(domainType, id, type, hints));
  }
}

findById 는 Hibernate 가 제공하는 구현체의 소스 코드를 통해 직접적으로 확인해볼 수 있다.

코드를 보면 알 수 있듯이, EntityManager 의 find 를 통해 엔티티를 조회해온다. 즉, 쿼리를 바로 보내는 것이 아니라 우선은 1차 캐시를 확인하고 그 이후에 1차 캐시에 존재하지 않으면 쿼리를 보낸다. 그래서 앞서서 entityManage.clear() 를 해서 1차 캐시를 비운 경우에는 쿼리를 보냈지만, 그렇지 않은 경우에는 쿼리를 보내지 않아도 됐던 것이다.

🐸 그래서 왜 쿼리 메서드는 1차 캐시를 안 보는데?

findById 는 1차 캐시를 보는 것을 코드를 통해 확인할 수 있었다.

그러나 쿼리 메서드는 왜 1차 캐시를 보지 않을까? 어떤 특성에 의해 그런 것일까?

엄밀히 말하면 쿼리 메서드라서 라기보다는 JPQL 을 통해 실행되기 때문이다.

JPQL 은 1차 캐시를 바라보지 않는다. 왜 그럴까?

1. 어차피 효율적이지 않다.

1차 캐시는 Map 형태로 저장이 된다. 여기서 Key 는 Id 이고, Value 는 해당 엔티티이다. 즉, pk 를 통해 1차 캐시를 조회하고자 할 때에는 매우 빠르게 찾을 수 있다. 그러나 그게 아니라면, 어차피 전체 엔티티를 전부 돌아야 하기에 1차 캐시를 보는 것에 대한 이점을 전혀 찾을 수가 없다.

즉, PK 기반 메서드가 아니기에 1차 캐시를 보지 않는 것이 기본 설정 값인 것이다.

2. 데이터 일관성 문제

영속성 컨텍스트에 존재하는 데이터가 최신일 것이라고 확정 지을 수가 없다.

만약, 하나의 트랜잭션 내부에서 특정 팀에 멤버를 3명 저장했다고 가정해보자.

그러면 그 팀과 멤버들은 모두 영속성 컨텍스트에 존재할 것이다. 그렇다고 해서 해당 팀에 멤버가 정말 그 3명만 존재할까?

답은 그럴 수도 있고, 아닐 수도 있다. 그렇기에 확실하게 하기 위해 매번 쿼리를 직접적으로 보내는 것이다.

그렇다면 또 다른 의문이 생긴다.

findById 와 같이 컴파일 타임에 생성되는 메서드는 무조건적으로 JPA 의 1차 캐시를 거쳐서 쿼리가 아예 나가지 않나?

그건 사실 또 아니다.

🐸 findAll 의 동작 방식

findAll 은 findById 와 같이, 컴파일 타임에 존재하는 메서드이다.

 @Test
@DisplayName("멤버들을 전체 조회한다")
void test4() {
    // given
    Team team = new Team("히로의 팀");
    entityManager.persist(team);

    Member 히로1 = new Member("히로1", team);
    entityManager.persist(히로1);

    Member 히로2 = new Member("히로2", team);
    entityManager.persist(히로2);

    Member 히로3 = new Member("히로3", team);
    entityManager.persist(히로3);

    Member 히로4 = new Member("히로4", team);
    entityManager.persist(히로4);

    entityManager.flush();
    entityManager.clear();

    // then
    System.out.println("======");
    memberJpaRepository.findAll();
}

위와 같이 여러 멤버들을 등록하고, 테스트를 실행해보면 다음과 같은 결과가 나온다.

======
Hibernate: 
    select
        m1_0.id,
        m1_0.name,
        m1_0.team_id 
    from
        member m1_0
Hibernate: 
    select
        t1_0.id,
        t1_0.name 
    from
        team t1_0 
    where
        t1_0.id=?

clear 를 하지 않은 경우의 쿼리는 다음과 같다.

======
Hibernate: 
    select
        m1_0.id,
        m1_0.name,
        m1_0.team_id 
    from
        member m1_0

clear 를 하지 않은 경우에도 마찬가지로 멤버가 이미 영속성 컨텍스트에 존재하고 있음에도 Member 에 대한 쿼리가 나갔다.

public List<T> findAll() {
	return this.getQuery((Specification)null, (Sort)Sort.unsorted()).getResultList();
}

그 이유는 findAll 도 사실은 JPQL 이기 때문이다.

getQuery(...)가 반환하는 것은 결국 TypedQuery, 즉 JPQL 기반의 쿼리 객체이다.

😵 그러면 EntityManager#clear 왜 해?

EntityManager#clear 는 도대체 왜 하는걸까?

대부분의 메서드들이 JPQL 을 기반으로 동작하고, 그렇기에 1차 캐시를 거치지도 않을텐데 말이다.

✅ 1차 캐시와 상관없이 조회를 하더라도 참조는 한다.

@Test
@DisplayName("clear 없이 상태를 변경하면, 조회 결과가 실제 DB와 다를 수 있다")
void test7() {
    // given
    Team team = new Team("히로의 팀");
    entityManager.persist(team);

    Member member = new Member("히로", team);
    entityManager.persist(member);
    entityManager.flush();

    // DB에 반영된 상태: name = "히로"

    // when - DB에는 반영하지 않았지만, 엔티티 상태만 변경
    member.rename("히로_수정");

    // then
    List<Member> results = memberJpaRepository.findByTeam(team);
    System.out.println(results.getFirst().getName());
}

위의 코드에서 member 의 이름은 데이터베이스 상에서는 히로 이지만, 엔티티 상으로는 '히로_수정' 이다.

그렇기에 위의 메서드를 실행한 결과는 '히로'가 되어야 맞다.

'히로_수정'은 데이터베이스 상에 반영이 되지 않았기에 JPQL 이 모르는 정보여야 한다. 하지만 결과는 '히로_수정' 이 나오게 된다.

왜냐하면, JPQL 은 1차 캐시와 상관없이 쿼리가 나가긴 한다. 그러나 쿼리를 마치고 엔티티를 가져올 때, 1차 캐시를 다시 보게 되기 때문이다.

이 과정에서 이미 결과에 해당하는 PK 가 1차 캐시에 존재한다면 해당 엔티티를 새로 만들지 않고 그대로 가져온다.

1	member 의 주소값

member 의 id 가 1이라고 가정하면 다음과 같이 영속성 컨텍스트가 구성되어있을 것이다.

그리고 저 member 의 이름은 '히로_수정'이 되어 있을 것이다.

id	name	team_id
1	히로	1

JPQL 이 조회해 온 쿼리의 결과는 위와 같았을 것이다. pk 는 1이고, 이름은 '히로_수정'이 아니라 '히로'였을 것이다.

여기서 JPQL 의 쿼리 조회 결과와 상관없이 1차 캐시에 pk 가 1인 엔티티가 존재하기에, 데이터베이스에서 조회해 온 데이터를 토대로 엔티티를 새로 만들지 않고 기존의 영속성 컨텍스트에 존재하는 값들을 그대로 사용하게 된다.

그래서 결국 데이터베이스에서 조회해 온 데이터가 아니라 엔티티를 토대로 결과를 반환하게 되는 것이다.

@Test
@DisplayName("clear 없이 상태를 변경하면, 조회 결과가 실제 DB와 다를 수 있다")
void test7() {
    // given
    Team team = new Team("히로의 팀");
    entityManager.persist(team);

    Member member = new Member("히로", team);
    entityManager.persist(member);
    entityManager.flush();

    // DB에 반영된 상태: name = "히로"

    // when
    member.rename("히로_수정");
    entityManager.clear();

    // DB에 반영된 상태: name = "히로"

    // then
    List<Member> results = memberJpaRepository.findByTeam(team);
    System.out.println(results.getFirst().getName());
}

만약 위와 같이 clear 를 하게 되면, 영속성 컨텍스트에 아무런 엔티티가 존재하지 않기에 쿼리의 결과를 토대로 결과를 반환하게 된다.

flush 를 한 것도 아니기에 데이터베이스 상에서는 여전히 '히로'로 존재한다. 따라서 데이터베이스를 기준으로 정확한 결과가 나오게 되는 것이다.

이렇게 EntityManager 의 clear 를 사용하면, 예상치 못한 부정합을 방지할 수 있게 된다.

✅ 처음으로 돌아가서 다시 짚어보자

나의 첫 가설은 다음과 같았다.

“EntityManager를 clear하지 않으면, 실제 쿼리를 날리는 것이 아니라 1차 캐시에서 값을 조회할 것이다.
따라서 테스트의 정확도를 위해 clear가 필요하다.”

하지만 테스트를 반복하면서 다음과 같은 사실을 새롭게 알게 되었다.

1. 항상 1차 캐시만을 참조하는 것은 아니다.

EntityManager.clear()를 호출하지 않아도, 상황에 따라 실제 쿼리가 날아가는 경우가 있다.

즉, clear 여부가 무조건 쿼리 실행 여부를 결정짓지는 않는다.

2. 테스트의 정확도는 "쿼리를 날리느냐" 만으로 결정되지는 않는다.

어떤 쿼리가 실행되었느냐도 중요하지만, 더 중요한 건 그 쿼리가 어떤 결과를 반환하고, 그 결과가 어떤 컨텍스트에서 사용되느냐 이다. 즉, 1차 캐시의 영향뿐 아니라 조회된 객체의 상태, flush 여부 등도 테스트의 신뢰도에 큰 영향을 미친다.

결국 clear()는 단순히 쿼리 유무를 통제하기 위한 수단이라기보다, 엔티티의 상태를 초기화하여 명확한 테스트 조건을 구성하기 위한 도구인 것이다.

☀️ 결론

JPQL 은 1차 캐시에 엔티티가 존재하더라도 무조건적으로 쿼리를 날린다.
쿼리는 1차 캐시와 연관성이 없지만, 조회해온 뒤에 결과를 반환할 때에는 영향을 받는다.
EntityManager#clear 는 1차 캐시로 인한 예상치 못한 부정합을 방지할 수 있도록 해준다.
쿼리가 나가느냐 아니냐 만이 테스트에 영향을 주는 요인은 아니다

☀️ 느낀 점

개인적으로 내린 결론은 테스트 과정에서 EntityManager#clear 를 사용하는 것은 그렇게까지 잘못된 습관은 아닌 것 같다.

의도치 않은 결과를 방지할 수 있고, 정말 테스트하고자 하는 대상에 집중할 수 있는 환경을 구성하는 데에 도움이 되기는 한다.

그러나, 이에 대해 무의식적으로 사용하는 것과 아닌 것에는 분명한 차이가 있다고 생각이 든다. 내가 어떤 목적으로 clear 를 하려고 하는지 한번 더 멈춰 서서 JPA 의 동작 방식에 대해 고민해본다면 더 좋은 개발자로 성장할 수 있지 않을까 하는 생각이 들었다.

무엇이든 관습적으로, 수동적으로 받아들이지 말자는 생각을 다시금 하게 됐다.

'SpringBoot' 카테고리의 다른 글

[SpringBoot] EAGER는 join 이 아니다 (3)	2025.07.27
[SpringBoot] 빈 등록과 생성은 다르다 (feat. BeanDefinition) (0)	2025.05.07
[SpringBoot] Presigned Url 을 이용해 S3에 이미지 업로드 하기 (1)	2024.08.17
[SpringBoot] 도메인 이벤트를 알아보고 AbstractAggregateRoot 를 이용해 채팅 서비스를 구현해보자 (0)	2024.04.18
[SpringBoot] 이벤트 기반 아키텍처를 알아보고 스프링부트의 이벤트를 구현해보자 (0)	2024.03.01

hee-ro.log

[SpringBoot] 💥 관습적인 EntityManager 의 clear 사용을 멈추세요 (feat. JPQL 과 1차 캐시)

🤔 궁금증을 갖게 된 계기

🔎 이 글을 이런 분들께 추천합니다

✅ 1. 쿼리 메서드에 대해 EntityManager#clear 를 호출하는 경우

✅ 2. 쿼리 메서드에 대해 EntityManager#clear 를 호출하지 않는 경우

✅ 3. findById 에 대해 EntityManager#clear 를 호출하는 경우

✅ 4. findById 에 대해 EntityManager#clear 를 호출하지 않는 경우

🐸 쿼리 메서드의 실행 과정

🐸 findById 의 동작 방식

🐸 그래서 왜 쿼리 메서드는 1차 캐시를 안 보는데?

1. 어차피 효율적이지 않다.

2. 데이터 일관성 문제

🐸 findAll 의 동작 방식

😵 그러면 EntityManager#clear 왜 해?

✅ 1차 캐시와 상관없이 조회를 하더라도 참조는 한다.

✅ 처음으로 돌아가서 다시 짚어보자

☀️ 결론

☀️ 느낀 점

'SpringBoot' 카테고리의 다른 글

티스토리툴바

[SpringBoot] 💥 관습적인 EntityManager 의 clear 사용을 멈추세요 (feat. JPQL 과 1차 캐시)

🤔 궁금증을 갖게 된 계기

🔎 이 글을 이런 분들께 추천합니다

✅ 1. 쿼리 메서드에 대해 EntityManager#clear 를 호출하는 경우

✅ 2. 쿼리 메서드에 대해 EntityManager#clear 를 호출하지 않는 경우

✅ 3. findById 에 대해 EntityManager#clear 를 호출하는 경우

✅ 4. findById 에 대해 EntityManager#clear 를 호출하지 않는 경우

🐸 쿼리 메서드의 실행 과정

🐸 findById 의 동작 방식

🐸 그래서 왜 쿼리 메서드는 1차 캐시를 안 보는데?

1. 어차피 효율적이지 않다.

2. 데이터 일관성 문제

🐸 findAll 의 동작 방식

😵 그러면 EntityManager#clear 왜 해?

✅ 1차 캐시와 상관없이 조회를 하더라도 참조는 한다.

✅ 처음으로 돌아가서 다시 짚어보자

☀️ 결론

☀️ 느낀 점

'SpringBoot' 카테고리의 다른 글

'SpringBoot' Related Articles

티스토리툴바