조용한 개발 노트

24편에서는 조회 전용 모델(DTO Projection)이“엔티티를 보호하기 위한 조회 전략”이라는 점을 살펴봤습니다.그 다음으로 자연스럽게 등장하는 질문은 이것입니다.“엔티티를 그대로 조회해야 한다면, Fetch 전략은 어떻게 제어해야 할까?”이 질문에 대한 Spring JPA 공식 문서의 또 다른 답이 바로EntityGraph입니다.1. EntityGraph는 어떤 문제에서 출발했을까JPA에서 Fetch 전략을 제어하는 방법은 크게 세 가지였습니다.엔티티에 EAGER/LAZY 지정JPQL Fetch JoinBatch Size하지만 이 방법들에는 각각 명확한 단점이 있었습니다.EAGER → 전역 설정, 되돌리기 어려움Fetch Join → 쿼리마다 JPQL 필요Batch Size → 근본 해결 아님En..

15편에서는 N+1 문제가Lazy Loading의 문제가 아니라, 조회 시점과 탐색 시점이 분리된 구조의 결과라는 점을 살펴봤습니다.그래서 자연스럽게 등장하는 해결책이Fetch Join입니다.이번 글에서는 Fetch Join이어디까지는 훌륭한 해결책이고어디서부터는 구조적 한계가 되는지를 Spring JPA 공식 문서 관점에서 정리해보겠습니다.1. Fetch Join은 무엇을 해결해 주는가Fetch Join은 JPQL 단계에서 연관 엔티티를“같은 쿼리로 함께 로딩하라”고 명시적으로 선언하는 방법입니다.select o from Order ojoin fetch o.member이 한 줄로:N+1 문제 제거Lazy 로딩 제어조회 쿼리 수 감소라는 명확한 이점을 얻을 수 있습니다.그래서 Fetch Join은N+1 ..

14편에서는 Lazy Loading이“항상 터지는 기능처럼 보이는 이유”가 실제로는 트랜잭션과 엔티티 상태를 잘못 다룬 결과라는 점을 살펴봤습니다.이번 글에서는 Lazy Loading과 항상 함께 언급되는,N+1 문제가왜 실수로 생기는 버그가 아니라 구조적으로 발생할 수밖에 없는 문제인지를 Spring JPA 공식 문서 관점에서 정리해보겠습니다.1. N+1 문제를 단순한 “실수”로 보면 안 되는 이유N+1 문제는 보통 이렇게 설명됩니다.“쿼리를 잘못 써서 SELECT가 N번 더 나간다”이 설명은절반만 맞습니다.왜냐하면 N+1 문제는JPA의 동작 방식과객체 그래프 탐색 모델이결합되면서의도하지 않아도 자연스럽게 발생하기 때문입니다.2. N+1의 기본 구조다음과 같은 상황을 생각해봅시다.List orders ..