Spring Kotlin Response DTO 사용하는 방법

스프링에서 api에 대한 응답을 전해줄 때 불필요한 정보를 제외하고 필요한 정보만 전해주기 위해서 DTO(Data Transfer Object)를 사용한다. 가장 흔한 예로 유저의 상세 정보를 조회할 때 비밀번호는 공개되면 안되기 때문에 비밀번호를 제외한 다른 정보들을 응답으로 전달해주는 케이스가 있다.

 

 

Kotlin에서 테스트 코드 응답으로 DTO를 만들어서 return 했는데  뜻 밖의 에러가 발생했다. password와 같이 전달하고 싶지 않은 값들이 null이라서 역직렬화가 안된다는 내용의 에러 같았다. Java에서는 단순히 DTO Class를 만들어서 return하면 되었는데 kotlin은 다른 무언가가 있는 모양이다. 유저 Entity를 예시로 DTO를 다음과 같이 생성했다. Constructor에 User Entity를 통째로 넘기고 필드 하나씩 매핑을 시켜주었다. Constructor로 넘기는 유저 엔티티에 모든 필드에 값이 존재하지 않는 상황이라 null이 매핑할 수 없다는 그런 내용 에러가 났다.

 

 

이를 해결하기 위해서 유저 DTO를 data class로 변경해주고 User Entitiy를 통째로 넘기는게 아니라 필드를 하나씩 넘겼다. 이렇게 해결하니 일단 문제는 해결이 되었다. 그런데.. User 정보를 받아오는 모든 api에서 위와 같이 10줄이 넘는 코드를 넣어 줘야 했다. 보기에도 안좋고 필드가 늘어나면 모든 코드를 수정해야하는 최악의 코드가 된 것이다. 이를 해결하기 위해서 Entity를 VM으로 Convert 해주는 companion object method를 만들었다.

 

 

위와 같이 공통으로 처리할 수 있는 method를 하나 만들어줘서 User를 조회하는 모든 api에서 유용하게 사용할 수 있게 되었다. 리스트의 map 함수에서도 아름답게 사용하고 있다. User Entity 이 외에도 다른 Entity 들에도 동일하게 적용해보려고 한다. 이게 최선의 방법인지는 잘 모르겠지만 단순 매핑하는 작업에 시간을 많이 쏟지는 않을 생각이다. 컨버팅 함수를 생성해 놓았기 때문에 추후 더 좋은 방법이 있으면 개선해 나가보도록 하겠다. 

 

 

 

오늘의 결론은 코틀린이 Java에 비해서 코드량도 많이 줄어들고 fancy 하지만 엄격한 Null 체크 때문에 개발하는데 좀 더 알아야 할 내용들이 있어서 적응하는 시간이 필요하다는 것이다. 최근 Java -> Kotlin으로 갈아타는 프로젝트가 많아지기 때문에 Kotlin 역량을 꾸준히 키워보도록하겠다.