[JPA] JPA Fetch 타입 완전 정복

JPA에서 연관된 엔티티를 언제 가져올지 결정하는 것이 Fetch 전략이다. 이걸 제대로 이해하지 못하면 쿼리가 폭발하거나, 반대로 필요한 데이터를 가져오지 못해 예외가 터진다. 초보 단계에서 반드시 짚고 가야 할 개념이다.

Fetch 전략이란

엔티티를 조회할 때 연관된 데이터를 즉시 가져올 것인가, 아니면 나중에 필요할 때 가져올 것인가를 정하는 설정이다.

예를 들어 Feed를 조회할 때, Feed가 가진 author(User) 정보를 같이 가져올 것인가 말 것인가를 결정한다.

JPA는 두 가지 전략을 제공한다.

• EAGER : 즉시 로딩. 엔티티를 조회하는 시점에 연관 데이터도 함께 가져온다.
• LAZY : 지연 로딩. 엔티티만 먼저 가져오고, 연관 데이터는 실제로 접근하는 시점에 가져온다.

EAGER — 즉시 로딩

@ManyToOne(fetch = FetchType.EAGER)
private User author;

Feed를 조회하면 JPA가 즉시 JOIN을 걸어 User도 함께 불러온다.

SELECT f.*, u.*
FROM feed f
JOIN user u ON f.author_id = u.id
WHERE f.id = 1

데이터를 한 방에 가져오니까 좋아 보인다. 하지만 문제가 있다.

목록을 조회하는 상황을 생각해보자.

List<Feed> feeds = feedRepository.findAll();

Feed가 100개면 JPA는 각 Feed마다 User를 가져오기 위해 추가 쿼리를 100번 날린다. 이것이 N+1 문제다. 단건 조회에서는 괜찮지만, 목록 조회에서는 성능 재앙으로 이어진다.

LAZY — 지연 로딩

@ManyToOne(fetch = FetchType.LAZY)
private User author;

Feed를 조회할 때는 Feed만 가져온다.

SELECT * FROM feed WHERE id = 1

author 필드는 실제 User 객체가 아니라 프록시 객체로 채워진다. 겉보기엔 User처럼 생겼지만 내부는 비어있는 껍데기다. 실제로 접근하는 순간 쿼리를 날린다.

Feed feed = feedRepository.findById(1L); // 쿼리 1번 (Feed만)

String name = feed.getAuthor().getName(); // 이 줄에서 User 쿼리 1번

getAuthor()를 호출하는 시점에 비로소 DB에서 User를 가져온다.

기본값 정리

어노테이션	기본 Fetch	권장 설정
@ManyToOne	EAGER	LAZY
@OneToOne	EAGER	LAZY
@OneToMany	LAZY	LAZY 유지
@ManyToMany	LAZY	LAZY 유지

@ManyToOne과 @OneToOne의 기본값이 EAGER라는 점이 핵심이다. 나머지는 기본값이 LAZY라 별도 설정이 필요 없다.

왜 이 두 어노테이션만 EAGER가 기본값인지는 ManyToOne과 OneToOne의 기본값이 EAGER인 이유 참고.

실무 원칙

모든 연관관계는 LAZY로 설정하는 것이 표준이다.

LAZY로 설정하면 각 상황에 맞게 필요한 데이터만 가져올 수 있다. 필요할 때 fetch join이나 @EntityGraph로 한 번에 조회하면 된다.

// 필요한 경우에만 fetch join으로 한 번에 가져온다
@Query("SELECT f FROM Feed f JOIN FETCH f.author WHERE f.id = :id")
Feed findWithAuthor(@Param("id") Long id);

JOIN FETCH를 쓰면 LAZY로 설정했더라도 해당 쿼리에서는 즉시 JOIN해서 가져온다. 이렇게 하면 N+1 문제 없이 필요한 데이터를 정확히 가져올 수 있다.

자주 하는 실수

면접 Q&A

---