조용한 개발 노트

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

23편에서는 동적 쿼리가“조건을 유연하게 만드는 도구”이지, “복잡도를 숨기는 도구”는 아니라는 점을 살펴봤습니다.그 다음 단계에서 자연스럽게 등장하는 질문은 이것입니다.“그럼 조회 결과는 꼭 엔티티여야 할까?”이번 글에서는 이 질문에 대한 Spring JPA 공식 문서 흐름상의 답,조회 전용 모델(DTO Projection)이 왜 필요해졌는지를 구조적으로 정리해보겠습니다.1. 엔티티 조회가 항상 문제를 만드는 이유엔티티는상태를 가지고변경 감지 대상이며영속성 컨텍스트에 묶여 있습니다즉,“쓰기 모델”에 가깝습니다.그런데 실무의 많은 조회는수정할 의도가 없고일부 필드만 필요하며응답 형태가 화면 중심인 경우가 많습니다.이 상황에서 엔티티를 그대로 반환하면:불필요한 연관관계 로딩Lazy 접근 위험영속성 컨텍스트..

22편에서는 QueryDSL이“문자열 JPQL의 한계를 넘어, 타입 안전한 쿼리 표현을 제공하기 위해 등장했다”는 배경을 살펴봤습니다.그 다음으로 반드시 마주치는 질문이 있습니다.“그럼 동적 쿼리는 어디까지 허용하는 게 맞을까?”이번 글에서는 이 질문에 대해 Spring JPA 공식 문서 흐름에 맞춰 정리해보겠습니다.1. 동적 쿼리는 왜 필요해졌을까실무에서 조회 조건은 고정되어 있지 않습니다.검색어는 있을 수도 없을 수도 있고날짜 범위는 선택 사항이며상태 값은 복수 선택이 가능이런 요구사항은“동적으로 쿼리를 조합해야 한다”는 결론으로 자연스럽게 이어집니다.QueryDSL은 이 요구를if-else가 아닌 Predicate 조합으로 풀어낼 수 있게 해줍니다.2. 동적 쿼리는 언제부터 위험해질까동적 쿼리 자체..

21편에서는 Spring Data JPA의파생 쿼리 메서드가 어디까지는 안전하고, 어디서부터 위험해지는지를 살펴봤습니다.그 흐름에서 자연스럽게 등장하는 질문은 이것입니다.“그럼 복잡한 조회는 도대체 뭘로 해야 하지?”이 질문에 대한 Spring 생태계의 대표적인 답이 바로QueryDSL입니다.1. QueryDSL은 어떤 문제에서 출발했을까QueryDSL이 등장한 배경은 아주 명확합니다.파생 쿼리는 길어지고JPQL 문자열은 깨지기 쉽고동적 조건은 if-else 지옥이 된다즉,“조회 조건을 코드로 표현하고 싶다”는 요구가 강해졌습니다.QueryDSL은 이 문제를“타입 안전한 쿼리 모델”로 해결하려는 시도입니다.2. QueryDSL이 해결하려 한 핵심 문제QueryDSL이 해결하려 한 문제는 기술적으로 보면 ..

20편에서는 Spring Data JPA의findById()가 “항상 DB를 다시 읽는 메서드가 아니라, 영속성 컨텍스트를 신뢰하는 조회”라는 점을 살펴봤습니다.이번 글에서는 Spring Data JPA의 또 다른 핵심 기능,파생 쿼리 메서드(Derived Query Method)가어디까지는 안전하고, 어디서부터 위험해지는지를 공식 문서 관점에서 정리해보겠습니다.1. 파생 쿼리 메서드는 왜 매력적인가Spring Data JPA를 쓰다 보면 이런 코드가 자연스럽게 등장합니다.List findByStatusAndAgeGreaterThan(Status status, int age);이 한 줄로:JPQL 작성 ❌쿼리 객체 생성 ❌을 모두 생략할 수 있습니다.이 간결함이 파생 쿼리 메서드의 가장 큰 장점입니다.2..

19편에서는 Spring Data JPA의 Repository 추상화가“무엇을 편리하게 만들었고, 무엇을 보이지 않게 가려버렸는지”를 살펴봤습니다.이번 글에서는 그 추상화의 중심에 있는 메서드,findById()가“항상 안전한 조회 수단인지”를 Spring JPA 공식 문서 기준으로 정리해보겠습니다.1. findById()에 대한 가장 흔한 오해많은 개발자가 findById()를 다음과 같이 인식합니다.“ID로 조회하니까 항상 DB에서 최신 값을 가져온다”하지만 이 인식은정확하지 않습니다.2. findById()의 실제 동작 순서Spring Data JPA의 findById()는 내부적으로EntityManager.find()를 호출합니다.그리고 이 메서드는 다음 순서로 동작합니다.Persistence C..

18편에서는 Batch Insert / Update가“왜 JPA의 기본 전략이 될 수 없는지”를 엔티티 상태 기반 쓰기 모델 관점에서 정리했습니다.이번 글에서는 JPA 위에 한 겹 더 얹힌 추상화,Spring Data JPA Repository가우리에게 무엇을 주었고, 대신 무엇을 가려버렸는지를 공식 문서 관점에서 정리해보겠습니다.1. Repository 추상화는 왜 등장했을까Spring Data JPA의 목표는 아주 명확했습니다.“데이터 접근 코드를 최대한 단순하게 만들자”그래서 Repository는EntityManager 직접 사용 ❌반복적인 CRUD 코드 ❌를 숨기고,인터페이스 선언만으로기본 구현을 자동 제공하는 방향을 선택했습니다.이 선택은 생산성 측면에서압도적인 성공이었습니다.2. Reposit..

17편에서는 N+1 문제를 완화하기 위한Batch Size와 Hibernate 최적화 전략을 살펴봤습니다.자연스럽게 다음 질문이 이어집니다.“조회는 배치로 최적화하는데, 쓰기는 왜 기본적으로 배치가 아닐까?”이번 글에서는Batch Insert / Update가 왜 JPA의 기본 전략이 아닌지를 Spring JPA 공식 문서와 Hibernate 내부 동작을 기준으로 정리해보겠습니다.1. JDBC에서는 Batch가 기본적으로 빠르다JDBC를 직접 사용해 본 경험이 있다면 이 사실은 익숙할 겁니다.PreparedStatement ps = ...ps.addBatch();ps.addBatch();ps.executeBatch();이 방식은:네트워크 왕복 감소Statement 재사용DB 처리 효율 향상덕분에 대량 쓰..

16편에서는 Fetch Join이“N+1 문제를 해결하는 만능 도구가 아니라, 조회 범위를 명시하는 선언”이라는 점과, 그 구조적 한계를 살펴봤습니다.그래서 다음 질문이 자연스럽게 등장합니다.Fetch Join이 안 되는 상황에서는 N+1을 어떻게 완화해야 할까?이때 가장 자주 등장하는 해답이 바로Batch Size입니다.1. Batch Size는 왜 등장했을까Batch Size는 N+1 문제를“없애는” 기능이 아니라 “완화하는” 전략입니다.특히 다음 조건에서 필요해졌습니다.연관관계가 LAZY로 설정되어 있고Fetch Join을 쓰기 어렵거나페이징이 필요한 조회즉,Fetch Join의 한계를 메우기 위한 현실적인 대안으로 등장했습니다.2. Batch Size의 기본 아이디어Batch Size의 아이디어는..

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 ..