[JPA] N+1 문제

알림 목록 조회 성능을 고려한 Fetch 전략 수립 (@EntityGraph)

알림 시스템(Notification)을 기획하면서 가장 우려되었던 부분은 “사용자가 알림 목록을 조회할 때 발생할 DB 부하” 였습니다. 알림은 단순 텍스트 정보뿐만 아니라, ‘누가(Sender)’ 보냈는지에 대한 정보가 필수적으로 함께 노출되어야 하기 때문입니다.

1. 기획 단계에서의 고려사항: N+1 문제의 선제적 방어

JPA를 사용하여 연관 관계(ManyToOne)를 맺을 때, 기본 전략인 Lazy Loading(지연 로딩)을 그대로 사용할 경우 다음과 같은 시나리오가 예상되었습니다.

1. 알림 목록 조회 요청: 사용자가 알림함에 들어옵니다.

2. 알림 데이터 로드: DB에서 최근 알림 20개를 가져옵니다. (SELECT * FROM notification ...)

3. 발신자 정보 로드: 20개의 알림을 화면에 그리기 위해, 각 알림마다 연결된 Sender(User) 정보를 조회하는 쿼리가 20번 추가로 발생합니다.

이는 조회 한 번에 총 21번(1+N)의 쿼리가 발생하는 비효율적인 구조이며, 사용자가 몰릴 경우 DB 커넥션 풀을 빠르게 고갈시킬 위험이 있습니다.

2. 구현 전략: @EntityGraph를 통한 Eager Fetching

우리는 알림 조회 시 Sender 정보가 “선택적” 이 아니라 “필수적” 으로 필요하다는 점에 주목했습니다. 따라서 쿼리 실행 시점에 연관된 데이터를 한 번에 가져오는 Fetch Join 전략을 채택했습니다.

📝 Implementation Code (NotificationRepository.java)

public interface NotificationRepository extends JpaRepository<NotificationEntity, Long> {
 
    // [Strategy] 알림 조회 시 Sender 정보는 필수이므로 Fetch Join으로 한 번에 조회
    // JPQL을 직접 짜는 것보다 가독성이 좋은 @EntityGraph 사용
    @EntityGraph(attributePaths = {"sender"})
    Slice<NotificationEntity> findAllByReceiverUserIdOrderByCreatedAtDesc(Long receiverId, Pageable pageable);
    
}

💡 설계 의도 및 효과

1. 쿼리 비용 최소화: @EntityGraph는 내부적으로 LEFT OUTER JOIN을 수행합니다. N번의 네트워크 왕복 비용을 단 1번으로 줄여 응답 속도를 획기적으로 개선했습니다.

2. 유지보수성: JPQL로 SELECT n FROM NotificationEntity n JOIN FETCH n.sender ...라고 길게 작성하는 대신, 어노테이션 하나로 **“이 쿼리는 Sender 데이터도 즉시 필요하다”**는 의도를 명확히 드러냈습니다.

⚙️ 비유: 배달 기사의 효율적 동선

상황: 아파트 101호부터 120호까지 택배(알림)를 배달해야 합니다.

• 기본 전략(Lazy): 배달 기사가 101호에 물건을 주고, 다시 물류센터(DB)로 돌아가서 102호 물건을 가져오는 식입니다. (총 21번 왕복)

• 채택한 전략(EntityGraph): 출발할 때 커다란 카트에 101호~120호 물건과 수취인 정보(Sender)를 한 번에 실어서(Join) 아파트로 옵니다. (단 1번 이동)

이러한 설계를 통해 트래픽이 증가해도 DB 부하를 일정 수준으로 유지할 수 있는 안정성을 확보했습니다.

---