Record의 "보일러플레이트 감소" 정도만 외워 왔는지, 아니면 불변·계층 경계·VO/엔티티와의 차이까지 같이 풀 수 있는지를 가른다.
Record는 필드가 final로 묶인 불변 객체에 생성자·접근자·equals/hashCode/toString을 컴파일러가 자동으로 만들어 준다. 그래서 "데이터만 옮긴다"는 DTO의 의도를 한 줄로 표현하고, 가변 setter에서 오는 사고(중간에 누가 값을 바꿔 둔 객체가 멀티스레드에서 꼬이는 류)를 원천적으로 막는다. 다만 상속 불가, 명시적 생성자 제약, JPA 엔티티처럼 가변·기본 생성자가 필요한 자리에는 안 어울리고, 외부 직렬화·역직렬화 라이브러리와의 호환은 별도 확인이 필요하다. 핵심은 "무조건 Record"가 아니라 "불변 데이터 객체 자리에 자연스럽게 맞는 도구"라는 점이다.
Lombok @Data로 만든 DTO에서 setter가 의도치 않게 호출돼 사고가 났던 경험이 있다면 "불변 DTO" 선택의 근거로 풀어낼 수 있다
JSON 역직렬화 라이브러리에서 Record 호환을 맞추며 시행착오를 겪은 경험이 있다면 도입 시 체크 포인트 사례로 보여 줄 수 있다
엔티티는 클래스, DTO는 Record로 계층을 명확히 나눈 경험이 있다면 "계층마다 다른 도구"라는 관점으로 일반화할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.