Java에서 데이터 객체를 만들 때 항상 이런 코드가 따라왔다.
public class UserDto {
private final Long id;
private final String name;
public UserDto(Long id, String name) {
this.id = id;
this.name = name;
}
public Long getId() { return id; }
public String getName() { return name; }
@Override
public boolean equals(Object o) { ... }
@Override
public int hashCode() { ... }
@Override
public String toString() { ... }
}
그래서 Java 16부터 언어 차원에서 “데이터 전용 타입”을 공식 인정한 게 record다.
[ DTO 설계할 때 권장 사항 ]
- 모든 필드를 final로 선언할 것
- 생성자에서 초기화된 값을 가지도록 할 것
- setter를 제공하지 말 것
- 각 필드는 getter로 접근할 것
- equals(), hashCode(), toString()을 직접 오버라이딩 할 것
record는 객체지향 원칙을 반드시 지키도록 만들어 졌습니다.
public record User(Long id, String name) {}
record의 장점
✅ 1) DTO의 의도가 명확해진다
DTO를 “비즈니스 로직이 없어야 하는 객체”라고 본다.
- 필드는 final
- setter 없음
- 상속 불가
👉 DTO에 로직이 스며드는 걸 구조적으로 막아준다
✅ 2) 코드량이 압도적으로 줄어든다
Controller ↔ Service ↔ Response DTO 이 구간은 거의 데이터 전달만 하는 객체다.
- Lombok 의존도 줄어듦
- 파일 길이 반 이상 감소
- 리뷰할 때 읽기 쉬움
Spring Boot에서 record는 “DTO를 DTO답게 만들기 위한 최고의 문법”이다.
하지만 Entity나 Domain까지 침범하면 바로 독이 된다.
'개발일지 > SPRINGBOOT' 카테고리의 다른 글
| Spring Boot 3.x + Elasticsearch 8.x 연동기 — 레거시 코드에서 타입세이프 클라이언트 (2) | 2026.04.23 |
|---|---|
| Spring HttpInterface 한 번에 이해하기 (0) | 2025.12.19 |
| UUID vs Sequential ID: 데이터베이스 설계에서 무엇을 선택할까? (0) | 2025.10.24 |
| JPA에서 @ManyToOne과 @OneToMany, 그리고 양방향 매핑의 차이 (0) | 2025.10.11 |
| Spring Data Envers와 RevisionRepository로 엔티티 변경 이력 관리하기 (0) | 2025.10.08 |