조용한 개발 노트

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

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 접근 위험영속성 컨텍스트..