조용한 개발 노트

25편에서는 EntityGraph가“엔티티를 반환해야 할 때, Fetch 전략을 국소적으로 제어하는 도구”라는 점과 그 유효 범위를 살펴봤습니다.이제 한 단계 위에서 지금까지의 조회 전략을 정리할 필요가 있습니다.“왜 조회는 점점 복잡해지고, 엔티티는 점점 위험해질까?”이 질문의 답이 바로읽기 모델과 쓰기 모델의 분리즉, CQRS(Command Query Responsibility Segregation) 관점입니다.1. 하나의 엔티티에 모든 책임을 맡기면 생기는 문제전통적인 JPA 사용 방식에서는엔티티가 곧 도메인 모델이고엔티티가 곧 조회 모델이며엔티티가 곧 응답 모델이 되는 경우가 많습니다.하지만 실무가 복잡해질수록 이 구조는 다음 문제를 낳습니다.조회 요구사항이 엔티티를 오염시키고연관관계가 과도하게 ..

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이 해결하려 한 문제는 기술적으로 보면 ..