[SpringBoot] EAGER는 join 이 아니다

✍🏻 글 작성의 계기

어느덧 레벨3의 프로젝트를 진행하며 팀원들에게 fetchType 은 LAZY 로 하는 게 좋다는 말을 했다. 그러자 팀원들이 왜냐고 물었고, 한마디로 선뜻 정리하지 못하는 나를 발견했다. 그저 'EAGER 는 join 이 아니야..' 라는 애매한 말만 되풀이했다.
 
이후 내용을 정리해서 팀원들에게 이를 바탕으로 글 작성까지 하게 됐다.
 

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

• LAZY 로 매번 설정하긴 하는데, 왜인지는 솔직히 잘 모르겠다 하시는 분들
• 매번 EAGER 는 join 이 되는 것이라고 생각하고 있는 분들

---

EAGER 가 고려되는 상황

블로그 서비스를 구현하고 있다고 가정해보자. Blog 는 게시글, BlogMember 는 작성자를 의미하며 Post 가 N:1 의 관계로 Member 를 갖고 있다. 
 
🤔 “Blog랑 BlogMember는 항상 같이 쓰이는데, 그냥 EAGER로 묶으면 편하지 않아?”
 
엔티티를 구성하며 위와 같은 고민을 한번쯤은 해봤을 것이다.
“매번 fetch join 하기도 귀찮고, 항상 함께 조회되니까!”
 
그러나 사실 'EAGER' 는 우리가 생각하는 그 ‘EAGER’랑은 좀 다르다..
 

findById 를 사용하는 상황에서의 EAGER

@Test
void test1() {
    // given
    BlogMember hero = new BlogMember("히로");
    BlogMember savedMember = blogMemberRepository.save(hero);

    Blog blog = new Blog(savedMember);
    Blog savedBlog = blogRepository.save(blog);

    // when
    Long id = savedBlog.getId();

    em.clear();

    System.out.println("======");
    Blog blog1 = blogRepository.findById(id).get();
    System.out.println(blog1.getMember().getName());
}

Hibernate: 
    select
        b1_0.id,
        m1_0.id,
        m1_0.name 
    from
        blog b1_0 
    left join
        blog_member m1_0 
            on m1_0.id=b1_0.member_id 
    where
        b1_0.id=?

 
findById 를 사용해서 조회를 하게 되면, 우리가 예상한 바와 같이 join 이 돼서 쿼리가 나가는 것을 볼 수 있다.
이 상황에서는 아무런 부작용이 발생하지 않는다.
 

Query Method 를 사용하는 경우

@Test
void test2() {
    // given
    BlogMember hero = new BlogMember("히로");
    BlogMember savedMember = blogMemberRepository.save(hero);

    Blog blog = new Blog(savedMember);
    Blog savedBlog = blogRepository.save(blog);

    // when
    Long id = savedBlog.getId();

    em.clear();

    System.out.println("======");
    Blog blog1 = blogRepository.findByMember(savedMember).get();
    System.out.println(blog1.getMember().getName());
}

Hibernate: 
    select
        b1_0.id,
        b1_0.member_id 
    from
        blog b1_0 
    where
        b1_0.member_id=?
Hibernate: 
    select
        bm1_0.id,
        bm1_0.name 
    from
        blog_member bm1_0 
    where
        bm1_0.id=?

 
 
만약 findByMember 와 같이 직접 정의한 쿼리 메서드를 통해 조회한다면 쿼리가 위와 같이 나간다.
우리가 상상한 바로는, EAGER 이기에 Blog 를 조회해올 때 join 을 해서 BlogMember 를 조회해올 것이라고 생각한다.
그러나 사실은 select 쿼리가 두번 나갔다. 왜 이렇게 달라지는 것일까?

우리는 이제까지 fetchType 을 잘못 이해하고 있었다

fetchType 은 사실 연관된 엔티티를 언제 로딩할지 에 대한 힌트일 뿐, 어떻게 로딩할지(쿼리 방식) 는 정의하지 않는다.
 
즉, FetchType.EAGER 은 '당장 이 연관 엔티티도 같이 필요하니까 지금 로딩하자' 는 의미지만, 조인으로 가져올지, 추가 쿼리를 날릴지 는 JPA 구현체(Hibernate) 가 선택하는 것이다.

Hibernate 에서의 fetchType 동작 방식

findById() (JPQL X)	보통 LEFT JOIN 으로 연관 엔티티까지 한 번에 가져옴
findByXXX() (Query Method)	프록시를 우선 반환하고, 실제 필드를 사용할 때 N번의 select 로 추가 조회 발생 (N+1 문제)
JPQL 작성 시 fetch join 명시	JOIN FETCH 로 명시적으로 조인하여 한 번에 가져올 수 있음

 
Hibernate 는 위와 같은 방식을 따르고 있다. 위와 같은 경우 findByMember 는 쿼리 메서드이기에 프록시로 BlogMember 가 우선적으로 반환된 것이고, EAGER 이기에 바로 BlogMember 를 가져와야 해서 바로 쿼리가 나간 것이다.
 
만약 LAZY 였다면, 실제로 사용되는 시점에 해당 객체가 프록시가 아닌 것으로 대체되기 때문에 .getBlogMember() 와 같이 실제로 호출되는 시점에 쿼리가 나갔을 것이다.
 
이는 공식 문서에서도 실제로 언급되어 있다.
 
https://docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html#fetching

Hibernate ORM User Guide

선택해야 하는 전략

• 모든 연관 관계는 기본적으로 LAZY로 설정
• 필요한 경우에만 JOIN FETCH 로 명시적 로딩 제어

EAGER 로 설정하게 되면, 무엇보다 개발자가 예측할 수 없는 쿼리가 나갈 가능성이 존재하기 때문에 LAZY 를 기본적으로 선택하고 FETCH JOIN 을 통해 제어할 수 있는 선에 두는 것이 가장 적절하다.

EAGER 는 그럼 왜 있을까?

아이러니하게도, Hibernate 의 공식 문서에서는 LAZY 로딩을 사용할 것을 강조하면서도 Jakarta 에서는 모든 구현체들이 EAGER 를 기본적으로 제공해야 할 것을 강요하고 있다.

 
JPA 1.0 에서는 모든 구현체들이 프록시를 사용할 것이라고 생각하지 않았다. 그래서 @ManyToOne, @OneToOne 의 모든 fetchType 이 기본적으로 EAGER 였던 것이다.
 
즉, 초기 JPA 표준이 모든 구현체가 프록시를 통한 유연한 지연 로딩을 제공할 것이라고 확신하지 못했기 때문에, 모든 공급자가 확실히 지원할 수 있는 '즉시 로딩'을 공통의 기본 작동 방식으로 삼아 호환성과 기본적인 데이터 로딩을 보장하려 했기 때문이다.
 
또한 개인적인 생각으로는, EAGER 자체가 객체지향적인 관점에 더 가깝다고 보여진다.
blog.getBlogMember() 를 했는데 그제야 쿼리가 나가고 프록시, 사실상 가짜 객체가 필드에 존재한다는 것 자체가 객체지향적이지는 않은 관점이다. 그렇기에 어떻게 보면 초기에는 EAGER 의 기본적인 사용을 고려했던 게 당연하지 않을까 싶기도 하다.