조용한 개발 노트

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의 책임이 아닙니다..

2편에서는 Spring JPA 공식 문서 관점에서“JPA는 무엇을 해주고, 무엇을 해주지 않는가”라는 책임 경계를 정리했습니다.이제 다음 질문으로 자연스럽게 넘어가야 합니다.그렇다면 JPA는 왜 이렇게까지 ‘상태를 가진 객체’를 전제로 설계됐을까?이 질문에 대한 답을 이해하지 못하면,엔티티는 왜 불변이면 안 되는지왜 setter가 필요해지는지왜 JPA가 이렇게 복잡해 보이는지를 끝까지 이해할 수 없습니다.1. JPA에서 Entity는 단순한 DTO가 아니다많은 개발자가 처음 JPA를 접할 때 엔티티를 이렇게 생각합니다.“DB 테이블을 객체로 옮긴 것”하지만 공식 문서에서 정의하는 Entity는영속성 컨텍스트에 의해 관리되는 객체입니다.즉, Entity는단순 데이터 구조가 아니라현재 어떤 상태에 있는지JP..