2. Record를 entity로! → 노놉, DTO로!!

안타깝게도 결론부터 말하자면 record는 entity로 쓸 수 없습니다. 모든 entity를 생각없이 record로 바꾼 후 소개팅 자리 나가는 설레는 마음으로 빌드 했지만 User declared non-static fields id are not permitted in a record 에러를 만났습니다.

record는 엔티티가 될 수 없는 이유는 다음과 같습니다.

hibernate와 같은 jpa는 프록시 생성을 위해 인수 생성자, non-final 필드, setter 및 non-final 클래스가 없는 엔티티에 의존합니다. 즉, 프록시를 생성하기 위해서 entity는 불변이면 안됩니다.(jpa의 프록시는 일대일 매핑 시 지연 로딩 제공 등 다양하게 쓰입니다.)
쿼리 결과를 매핑할 때 객체를 인스턴스화 할 수 있도록 매개변수가 없는 생성자가 필요합니다. → record는 매개변수가 없는 생성자를 제공하지 않습니다.(record는 불변 객체이기 때문에 setter를 사용할 수 없습니다. 이로 인해 모든 필드의 값을 입력한 후에 생성할 수 있습니다)
접근자 메소드인 getter가 필수 명명 규칙을 따르지 않습니다. record의 getter는 필드명을 그대로 사용하고 있습니다.(name(), pilot() …) → 쿼리 결과 처리 후 수행할 getter, setter에 접근할 수 없습니다.

위에서 상술한 이유로 record는 엔티티가 되기 위한 조건을 만족하지 않습니다. 결국 entity는 표준 java 클래스로 구현해야 해당 기준을 쉽게 충족할 수 있습니다.

그럼 어디다 써먹으라고 추가해준 record는 목적에 맞게 쓸 수 있는 곳이 없는 걸까요? 이 글을 시작하기에 앞서 살펴본 DTO가 있습니다. DB에 저장된 데이터의 전송 객체로서 record는 아주 적합한 형태를 가지고 있습니다.

읽어온 정보를 변경하지 않으려면 record 타입의 DTO가 적격입니다. record는 한 번 값이 정해지고 나면 setter를 통해 값을 변경할 수 없는데, 자바 내부에서 데이터 가공 시 중간에 변질될 우려가 없습니다.

일단 DTO를 사용하면 API에서 도메인 모델을 분리할 수 있는데 백엔드 내부의 entity를 외부에 공개할 필요가 없게 됩니다.

하지만, 여전히 한국의 자바 환경은 8버전이 주를 이루고 있으며 나머지 파이는 11버전이 차지하고 있습니다. record를 제대로 된 스펙으로 사용하려면 16이상의 버전을 사용해야 하는데 버전을 올렸을 때 겪을 리스크가 있습니다. 그러나 세계적인 추이가 점점 새로운 자바 버전의 사용이 늘고 있는 추이기 때문에 훗날을 위해서라도 record를 DTO로 사용하는 것에 대해 친숙해질 필요는 있다고 생각합니다.