덕분에 스프링, JPA 말고도 자바 전반에 걸쳐서 정말 많은 걸 재밌게 배우고 있어서 감사드립니다. 공부를 해도 의문이 해소되지 않는 부분이 있고, 제가 이해하는 것이 맞는지 확신이 안 가는 것들이 있어 질문드립니다.   1. 왜 2:23초 정도의 equals() 오버라이딩에서, 클래스 비교를 instance of가 아니라 !=로 하였는지 프록시로 생성된 객체는 원본 클래스를 상속한, 생성된 클래스에 속하기에 equals 오버라이딩 할 때, ==이나 !=를 이용한다면 적절한 구현이 이루어질 수 없지 않나요? 1) 기본적으로 instance of를 써야 프록시로 생성된 객체가 원본 클래스와 적절하게 동등성 비교가 가능하다고 알고 있었습니다. 2) 한편, 실전예제에서 instance of를 사용하지 않은 것이 값 타입이라서 그런것이 아닌가 추측했습니다. 왜냐면 값 타입은 식별자를 갖지 않기 때문에 getReference() 메서드로 프록시를 가질 일 자체가 없어서 위의 문제가 발생하지 않으리라는게 제 추측이었습니다. 이와 관련해서 의문이 들었던 부분이:   2. 이전 강의(값 타입 컬렉션)에서 값 타입 컬렉션에 대해 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본 키를 구성해야함: null 입력X, 중복 저장X 이라고 정리했었는데, 그렇다면 값 타입 컬렉션의 경우 PK가 존재하는 것인가요? 또, 그걸 통해서 find나 getReference가 가능한 건가요? 별개로, 값 타입이 불변 타입으로 사용되기에 equals 오버라이딩이 필요하다는 점은 이해했습니다.   마지막으로 3. getter를 사용해서 equals나 hashCode 메서드를 구현하는 것이 프록시 문제를 피해갈 수 있다는 것이 이해가 가지 않습니다. 오히려 저는 getter 사용이 아니라 클래스 판별 부분을 ==로 하지 않고 instance of로 하는 것이 더 맞다고 생각했습니다. 그 이유는 1) 제가 보기에, 위에서 언급했듯이, 프록시가 비교에서 문제가 발생하는 부분은, 프록시로 얻은 객체는 원본 객체와는 다른 클래스(JPA에 의해 생성된, 원본 클래스를 extends 하는 클래스)라는 점이기에 그렇습니다. 2) getter 사용이 아니라 instance of 사용이 프록시와 연관이 있다고 IntelliJ가 안내문으로말해주는 것 같아보였습니다. 단축키로 equals와 hashCode 메서드를 생성하려고 하면 다음과 같은 안내문이 나왔었는데요:   generate equals() and hashCode() Accept subclasses as parameter to equals() method While generally incompliant to Object.equals() specification accepting subclasses might be nessesary for generated method to work correctly with frameworks, which generate Proxy subclasses like Hibernate. 생성된 메서드를, 하이버네이트처럼 프록시 서브클래스들을 만드는 프레임워크들과 호환시키고 싶으시다면, 일반적인 Object.equals() 규격과 다르게, 서브클래스들을 포함시키는 것이 필요할 수 있습니다. Use getters during code generation 해당 클래스에 getter 만들지 않으면 당연히 위 옵션을 체크하더라도 getter 메서드 사용하지 않고 구현된다.   제가 잘못 번역한 것인지는 모르겠습니다만 위의 안내문은 제가 위에서 생각했던 것처럼 서브클래스를 포함시키는 것 (!=으로 동등 클래스만 포함시키는 것이 아니라 instance of로 서브클래스까지 포함시키는 것) 이 하이버네이트 등의 프록시 서브클래스 문제를 해결해준다고 말하는 것 같았기 때문입니다.   공부가 얕아서 질문이 많았습니다. 하이버네이트에서 실제 프록시를 생성하거나 할 때 무언가 제가 모르는 부분이 있는 것은 아닌가 해서 하이버네이트 라이브러리에서 em을 extends 하는 Session이나 SessionImpl을 뒤져 보기도 했는데, 도통 답을 찾기가 어렵네요. 도움이 필요합니다..