DTO는 class + Lombok으로 만들까요, record로 만들까요?

[softmoca]

Spring에서 요청 DTO를 만들 때 보통 Lombok을 사용해 class로 작성하거나, Java record로 작성할 수 있습니다.

두 방식 모두 JSON 요청을 @RequestBody로 받을 수 있지만, 객체가 생성되는 방식과 표현하는 의도는 다르다고 생각합니다.
Lombok class는 기존 class에 생성자, getter, setter 같은 코드를 자동 생성해주는 방식이고, record는 자바 언어 차원에서 값을 담기 위한 불변 객체를 표현하는 방식입니다.

즉 Lombok은 기존 class의 보일러플레이트를 줄이는 도구이고, record는 데이터 전달 객체라는 의도를 타입 선언 자체에 드러내는 문법에 가깝다고 볼 수 있습니다.

다만 record는 기본적으로 불변이고 상속이 제한되며, 필드명이 JSON 프로퍼티 이름과 더 직접적으로 연결됩니다.
반대로 Lombok class는 생성자, setter, 기본 생성자 등을 조합할 수 있어 더 유연하지만, 어떤 어노테이션을 붙였는지에 따라 Jackson 역직렬화 방식이 달라질 수 있습니다.

이와 관련해서 여러분의 생각이 궁금합니다.

1. 요청/응답 DTO를 만들 때 class + Lombok과 record 중 무엇을 선호하시나요?
2. record를 DTO로 사용하면 어떤 장점과 단점이 있다고 생각하시나요?
3. Jackson이 JSON을 객체로 역직렬화할 때, 기본 생성자/setter/생성자/record canonical constructor 중 어떤 방식을 사용하는지 이해하고 계신가요?
4. Spring의 @RequestBody 추상화가 편리한 만큼, 내부 변환 과정을 몰랐을 때 어떤 문제가 생길 수 있을까요?

[Uechann]

나의 기준

현재 저는 요청 DTO에서는 class + Lombok, 응답 DTO에서는 record를 주로 사용하는 것을 추구합니다.

1. 응답 DTO를 record로 사용하는 이유

• 불변성의 의미 전달, 응답 데이터를 반환한다는 의미가이 자연스럽다.
  응답을 만들어서 내보내기만 해서 변경될 일이 전혀 업다고 생각합니다.
• 직렬화가 record 자료형과 잘 맞는다고 생각합니다.

2. 요청 DTO를 class Lombok으로 사용하는 이유

• 요청 DTO에서 검증 어노테이션 필드와 함께 두는 것이 익숙하고, record보다 가독성이 좋다.
• class를 사용할 때, 역직렬화 과정에서 NoArgsConstructor + setter 를 통한 유연성이 필요할 때
• 요청을 record로 사용한다면, Jackson이 객체 생성 시점 검증 에러가 아닌 Jackson이러가 발생할 수 있다.
  그래서 검증 에러에 대한 일관성으로 생성 후에 검증을 진행하는 class + lombok이 일관적이라고 생각한다.

[sangjun121]

이전 디스커션인 Record 클래스와 명시적 타이핑에서도 언급되었던 내용인데요, 데이터가 중요한 시대로 넘어오면서 데이터 자체를 명확히 표현하기 위해 등장한 개념이 Record 타입이라고 생각합니다.

그래서 저는 요청/응답 DTO를 데이터 자체를 표현하는 의도이기에, Record를 사용하여 표현하는 것을 선호합니다.

결국 요청 응답은 외부의 영향을 받으면 안되는 오직 데이터 자체를 표현해야 합니다. 그래서 외부에 상속되어 수정되거나 불변성이 깨지면 안되는 순수 데이터의 성격을 가져야 합니다. 결국 이를 잘 표현해주기 위해 record가 등장하였고, 이런 컨포넌트들 사이에서 데이터 전송에서 사용할 객체를 표현하기 위해 등장한 개념이 Record이기 때문에 사용에 자연스럽다고 생각합니다.

추가적인 장점으로 보일러 플레이트코드를 줄여준다는 장점도 있으며, 역직렬화 시점에도 record의 canonical constructor를 사용해 생성시점에 모든 값이 결정되는 구조라는 측면에서도 불변성을 보장해주기 용이할 것 같습니다!

[haeyoon1]

저는 요청/응답 DTO를 만들 때 record 사용을 선호하는 편입니다.

1. record를 DTO로 사용하면 어떤 장점과 단점이 있다고 생각하시나요?

record는 생성자, accessor, equals, hashCode, toString이 자동으로 만들어져 코드가 짧아집니다.
또한 기본적으로 불변이기 때문에 요청이나 응답 값을 생성 후 변경하지 못하게 할 수 있습니다. 이 덕분에 사이드 이펙트를 줄이고, DTO가 단순한 값 전달 객체라는 의도도 명확하게 드러납니다.

하지만 단점은 유연성이 떨어진다는 점입니다.
record는 상속이 제한되고, 필드를 나중에 변경할 수 없습니다. 그래서 setter가 필요한 구조, builder가 필요한 복잡한 생성 구조, 공통 DTO 상속 구조가 필요한 경우에는 불편할 수 있습니다.

2. Jackson이 JSON을 객체로 역직렬화할 때, 기본 생성자/setter/생성자/record canonical constructor 중 어떤 방식을 사용하는지 이해하고 계신가요?

이번 기회에 한번 찾아보게되었습니다!
Jackson은 보통 class에서는 기본 생성자로 객체를 만든 뒤 setter나 필드로 값을 주입하거나, 생성자 기반이면 @JsonCreator, @JsonProperty, 파라미터 이름 등을 보고 생성자를 호출합니다.
하지만 record는 setter가 없기 때문에 canonical constructor를 호출해 한 번에 객체를 생성한다고하네요!

3. Spring의 @RequestBody 추상화가 편리한 만큼, 내부 변환 과정을 몰랐을 때 어떤 문제가 생길 수 있을까요?

@RequestBody는 JSON을 DTO로 자동 변환해주지만, 내부적으로는 HttpMessageConverter와 Jackson이 객체를 생성하고 값을 매핑합니다. 이 과정을 모르면 요청 값이 왜 안들어오지? 등의 문제를 겪을 수 있습니다.

• DTO에 기본 생성자나 적절한 생성자가 없어 역직렬화 실패
• JSON 필드명과 DTO 필드명이 달라 값이 null로 들어옴
• record나 생성자 기반 DTO에서 파라미터 매핑이 안 됨
• setter가 없는데 setter 방식으로 값을 넣으려 해서 실패
• 타입 변환 실패
• 요청 객체가 생성되긴 했지만 검증이 없어 잘못된 값이 그대로 들어옴
  • 필수값 검증은 @Valid, @NotNull, @NotBlank 같은 Bean Validation으로 따로 처리해야 합니다!