안녕하세요 강사님. 참 좋은 강의 감사드립니다.예제 고도화 과정에 Request DTO nullable 필드 처리에 어떤 방식이 적절할 지 알수 없어 남기게 되었습니다.Kotlin 객체 필드타입을 크게 두 방식으로 선언 할 수 있습니다.nullablenon-null코프링 기반에서 Request DTO 의 경우,객체필드를non-null 타입으로 선언하면 WebMvc 와 spring-validation 을 함께 사용하면, 발생 가능한 가설을 세워보았습니다.문제:서버 요청에 '비 유효값'`[공백문자["", ' '], null 필드값, 공백 JSON( {} )]`이 넘어올 때, Kotlin 언어의 non-null 타입 속성은, sprint-validation 절차를 거치지 못함. 원인:1. 속성 타입을 non-null 타입 선언 후 컴파일 시 Intrinsics.checkNotNullParameter(field, "field"); 함수가 non-null 검증코드로 DTO 생성자 함수 본체에 추가.2. 앞선 checkNotNullParameter 함수는 DTO 생성을 원천 차단.3. 때문에 Kotlin non-null 검증이 spring-validation 검증 이전에 수행됨을 뜻함. 즉, 검증 대상이 생성이 되어야 spring-validation 절차를 거칠텐데, 검증 대상이 없는 상황이 된다.(이 부분은 저의 뇌피셜이 포함되었으므로 검증되지 못한 분석결과 입니다) 이 문제에 대해 다음의 해결 방법을 생각할 수 있습니다.field 타입을 nullable 하게 선언, 기본값 null 설정data class UserCreateRequest( @param:JsonProperty("email") @field:NotBlank @field:Email val email: String? = null, ⬅️`?`및 기본값 설정 ) { fun toCommand() = UserCreate( /* String ❌ String? 미스매치 */ email = email!!, ✅단언 해결 ) }이 방법은 단언 !! 을 사용하여 전적으로 spring-validation 의 검증에 전적으로 의지하는 코드입니다.의문점은 개인적으로 우아하지 못한 단언 !! 을 꼭 사용해야 할까? 인데요, 다른 방법으로는,Backing 필드 생성자 선언 ➡️ 커스텀 getter 로 Backing 필드값 반환이 떠오르는데요, 이것 또한 보일러-플레이트 코드량이 늘어나서 우아하지 않아 보입니다^^;강사님의 경우에는 어떠한 해결방법을 사용하지는지 궁금해서 질문 남겨보았습니다.읽어 주셔서 감사합니다.