조용한 개발 노트

1편부터 27편까지, 이 시리즈에서는 Spring JPA 공식 문서를 기준으로왜 이런 개념이 존재하는지왜 이런 제약이 생겼는지왜 실무에서 문제가 되는지를 하나의 흐름으로 정리해 왔습니다.이 마지막 편에서는 개별 기능 설명이 아니라,Spring JPA를 어떻게 바라보고, 어떤 원칙으로 써야 하는지를 정리하며 시리즈를 마무리하겠습니다.원칙 1. JPA는 “쓰기 모델”에 최적화된 기술이다JPA의 핵심은상태를 가진 엔티티변경 감지(Dirty Checking)트랜잭션 단위의 일관성입니다.즉,JPA는 “상태 변경을 안전하게 관리하는 기술”이지,“모든 조회를 해결하는 ORM”이 아닙니다.그래서 JPA는 쓰기 모델(Command)의 중심에 둘 때 가장 강력합니다.원칙 2. 조회는 엔티티가 아니라 “전략”이다실무에서 가..

26편에서는 CQRS 관점에서“읽기 모델과 쓰기 모델을 분리해야 하는 이유”를 살펴봤습니다.이제 자연스럽게 마지막 질문에 도달합니다.“그럼 JPA는 도대체 어디까지 책임져야 할까?”이 질문에 답하지 못하면,JPA로 모든 걸 하려다 망하거나반대로 JPA를 너무 일찍 버리게 됩니다1. JPA의 출발점부터 다시 보자JPA는“객체 모델과 관계형 모델을 조율하기 위한 표준”로 출발했습니다.즉,SQL을 없애기 위한 기술 ❌DB를 추상화하기 위한 기술 ❌이 아닙니다.JPA의 역할은 명확합니다.객체 상태를 DB 변경으로 변환트랜잭션 단위의 일관성 유지반복적인 매핑 코드 제거2. JPA에 기대하면 안 되는 것들실무에서 JPA가 문제가 되는 순간은 대부분“책임을 넘어선 기대”때문입니다.다음 영역은 JPA의 책임이 아닙니다..

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

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