초안을 발행용 본문으로 다시 정리하고 있습니다. 현재 기준 버전과 오래된 javax.persistence 설명의 차이를 확인한 뒤, save -> isNew -> persist/merge 흐름이 초반에 바로 보이도록 구조를 다듬겠습니다.버전 차이까지 반영해 본문을 마무리 중입니다. 오래된 문서의 ID만 본다 설명과 현재 공식 문서의 @Version 우선 규칙을 분리해 적고, 직접 ID 할당 시 Persistable 을 왜 써야 하는지도 로그 예시와 함께 정리하겠습니다.# Spring Data JPA는 새 엔티티를 어떻게 구분할까: save, persist, merge까지 한 번에 이해하기 빠른 답 Spring Data JPA의 save() 는 먼저 isNew() 로 새 엔티티인지 판단한 뒤 persist() 와 merge() 를 나눕니다. 현재 기본 규칙은 non-primitive @Version 을 먼저 보고, 그런 필드가 없으면 @Id 를 봅니다. 직접 ID를 넣는 엔티티는 기본 규칙만으로는 신규로 판정되지 않아 merge() 와 불필요한 조회가 생기기 쉽습니다. 이런 경우 Persistable 로 isNew() 기준을 명시하면 동작과 성능을 더 예측 가능하게 만들 수 있습니다. Repository.save() 는 단순히 "저장"만 하는 메서드가 아닙니다. 같은 save() 를 호출해도 어떤 엔티티는 곧바로 insert 가 나가고, 어떤 엔티티는 먼저 select 를 한 번 더 수행합니다. 이 차이는 대부분 저장 직전의 새 엔티티 판별 규칙에서 시작됩니다. 목차 흐름으로 보기 왜 새 엔티티 판별이 중요한가 isNew는 무엇을 기준으로 판단할까 @Version과 @Id는 어떻게 다르게 작동할까 직접 ID 할당 시 Persistable을 어떻게 적용할까 save, persist, merge를 로그로 확인해보기 버전 차이와 마이그레이션 포인트 실무에서 자주 놓치는 주의점 흐름으로 보기 핵심은 이 다섯 단계...