Java record와 Lombok 비교: DTO에는 어떤 방식을 선택해야 할까?

Java record와 Lombok 비교를 통해 DTO에 어떤 방식을 선택해야 하는지 정리합니다. java lombok vs record 차이부터 @Value, Getter, Builder, Jackson, JPA 활용 시 주의점까지 실무 기준으로 비교합니다.

recode vs lombok

Java record와 Lombok은 무엇이 다른가요?

Java record와 Lombok은 모두 반복적인 코드를 줄이는 데 도움이 되지만 출발점부터 다릅니다.

record는 Java 언어 자체에서 제공하는 데이터 중심 클래스 문법입니다. 반면 Lombok은 애노테이션 처리를 통해 Getter, 생성자, Builder 등의 코드를 생성하는 라이브러리입니다.

간단한 사용자 응답 DTO를 일반 클래스로 작성하면 필드, 생성자, Getter 등을 직접 정의해야 합니다. Lombok을 사용하면 애노테이션으로 상당 부분을 줄일 수 있으며, record를 사용하면 더 짧게 표현할 수 있습니다.

일반 클래스 방식

사용자 정보를 전달하는 DTO를 일반 클래스로 작성하면 다음과 같은 요소가 필요합니다.

  • 필드 선언
  • 생성자 작성
  • Getter 작성
  • 필요에 따른 equals() 구현
  • 필요에 따른 hashCode() 구현
  • 필요에 따른 toString() 구현

DTO가 많아질수록 비슷한 코드가 반복되기 때문에 Lombok이나 record를 검토하게 됩니다.

Lombok을 사용한 DTO

Lombok에서는 @Getter, @RequiredArgsConstructor, @Value, @Builder 등을 조합할 수 있습니다.

예를 들어 불변 데이터 객체가 필요하다면 @Value를 사용할 수 있습니다. 이 경우 필드를 변경하기 어려운 형태로 만들면서 Getter와 주요 메서드를 자동으로 생성할 수 있습니다.

Lombok의 장점은 필요한 기능을 선택적으로 조합할 수 있다는 점입니다.

@Getter만 적용할 수도 있고, 생성자만 만들 수도 있으며, 필드가 많은 DTO에는 @Builder를 추가할 수도 있습니다. 기존 클래스 구조를 크게 바꾸지 않고 반복 코드를 줄일 수 있다는 점도 장점입니다.

Java record를 사용한 DTO

record는 데이터 구성 요소를 선언부에 직접 정의합니다.

예를 들어 name과 age를 가진 DTO라면 record 선언만으로 해당 값을 보관하는 데 필요한 기본 구조가 만들어집니다.

record에는 주요 구성 요소를 기반으로 다음 기능이 제공됩니다.

  • private final 형태의 구성 요소 저장
  • 전체 구성 요소를 받는 기본 생성자
  • 각 구성 요소에 접근하는 접근자 메서드
  • equals()
  • hashCode()
  • toString()

단순 데이터 전달 객체라면 record의 코드량이 매우 적고 구조도 명확합니다.

java lombok vs record 핵심 차이 비교

두 방식의 차이를 한눈에 정리하면 다음과 같습니다.

비교 항목Java recordLombok

제공 방식 Java 언어 기능입니다 외부 라이브러리입니다
주요 목적 데이터 중심 객체 표현입니다 반복 코드 생성을 줄입니다
불변 데이터 표현 기본 구조와 잘 맞습니다 @Value 등으로 구현할 수 있습니다
Getter 이름 name() 형태입니다 getName() 형태가 일반적입니다
Builder 기본 제공하지 않습니다 @Builder를 사용할 수 있습니다
상속 일반 클래스를 상속할 수 없습니다 일반 클래스 설계가 가능합니다
인터페이스 구현 가능합니다 가능합니다
코드량 매우 적습니다 애노테이션 조합에 따라 달라집니다
기존 JavaBean 호환 확인이 필요할 수 있습니다 비교적 익숙한 방식입니다
의존성 별도 라이브러리가 필요하지 않습니다 Lombok 의존성이 필요합니다

핵심 차이는 간단합니다.

record는 데이터 객체 자체를 간결하게 표현하기 위한 언어 기능이고, Lombok은 기존 클래스 구조를 유지하면서 반복 코드를 자동 생성하는 도구입니다.

이 차이를 이해하면 DTO 선택 기준도 훨씬 명확해집니다.

java record vs lombok value 차이는 무엇인가요?

검색할 때 자주 비교되는 조합이 java record vs lombok value입니다. 두 방식 모두 불변 데이터 객체를 만드는 용도로 사용되기 때문에 비슷하게 보일 수 있습니다.

하지만 완전히 같은 것은 아닙니다.

공통점

Java record와 Lombok @Value는 다음과 같은 상황에서 비슷한 역할을 할 수 있습니다.

  • 생성 후 값을 변경하지 않는 DTO
  • API 응답 데이터
  • 서비스 계층 간 전달 객체
  • 조회 결과를 담는 객체
  • 값 자체가 중요한 객체

두 방식 모두 Setter를 중심으로 값을 계속 변경하는 객체보다는 생성 시 값을 확정하는 구조에 적합합니다.

차이점

record는 클래스의 종류 자체가 데이터 중심 객체에 맞게 정의되어 있습니다. 따라서 선언만 보더라도 해당 객체가 값을 전달하기 위한 용도라는 의도가 명확하게 드러납니다.

반면 Lombok @Value는 일반 클래스에 불변 객체 생성을 돕는 기능을 적용하는 방식입니다.

따라서 다음과 같이 구분할 수 있습니다.

단순한 값 묶음을 표현한다면 record가 더 직접적입니다.

일반 클래스 구조를 유지하면서 Lombok의 다른 기능과 함께 사용해야 한다면 @Value가 더 유연할 수 있습니다.

기존 프로젝트가 Lombok 중심으로 구성되어 있고 Builder 패턴이나 여러 애노테이션 조합을 적극적으로 사용한다면 @Value를 계속 사용하는 것도 자연스러운 선택입니다.

java record lombok getter 차이를 주의해야 합니다

record를 처음 적용할 때 자주 헷갈리는 부분이 Getter 이름입니다.

일반적인 Lombok DTO에서는 다음과 같은 형태가 익숙합니다.

user.getName()

하지만 record에서는 일반적으로 다음과 같이 구성 요소 이름으로 접근합니다.

user.name()

즉, java record lombok getter 차이는 단순한 문법 차이처럼 보이지만 기존 코드와 연결할 때 영향을 줄 수 있습니다.

기존 코드가 getName()을 기대하는 경우

프로젝트 내부에서 getName() 호출을 직접 많이 사용하고 있다면 DTO를 record로 변경할 때 호출부도 함께 수정해야 할 수 있습니다.

특히 다음과 같은 환경에서는 확인이 필요합니다.

  • 기존 JavaBean 규칙을 강하게 사용하는 코드
  • Getter 이름을 직접 참조하는 자체 공통 모듈
  • 리플렉션 기반 내부 도구
  • 오래된 라이브러리와의 연동
  • 템플릿이나 표현식에서 접근 방식을 전제로 한 코드

최신 프레임워크와 라이브러리는 record를 지원하는 경우가 많지만, 프로젝트에서 사용하는 정확한 버전과 연동 방식을 확인한 뒤 적용하는 것이 안전합니다.

DTO에는 record가 더 좋은 선택일까요?

DTO라고 해서 무조건 record를 선택할 필요는 없습니다. DTO의 종류를 나누어 보면 판단하기 쉬워집니다.

API 응답 DTO에는 record가 잘 맞습니다

API 응답 데이터는 일반적으로 생성된 후 값을 계속 변경할 필요가 없습니다.

예를 들어 다음과 같은 데이터입니다.

  • 사용자 조회 결과
  • 상품 목록 응답
  • 게시글 상세 응답
  • 통계 결과
  • 검색 결과

이러한 객체는 값을 전달하는 역할이 명확하고 생성 후 변경 가능성이 낮기 때문에 record와 잘 맞습니다.

응답 DTO를 record로 만들면 필드와 Getter가 길게 반복되지 않아 코드 구조를 빠르게 파악할 수 있습니다.

단순 요청 DTO에도 record를 고려할 수 있습니다

회원가입, 검색 조건, 게시글 등록처럼 요청 데이터를 한 번 받아 서비스 계층으로 전달하는 구조라면 record를 사용할 수 있습니다.

다만 다음 항목은 확인해야 합니다.

  • 현재 사용하는 Spring Boot 버전
  • Jackson 버전과 설정
  • Validation 적용 방식
  • 커스텀 역직렬화 여부
  • 기본 생성자를 요구하는 기존 코드 존재 여부

일반적인 최신 환경에서는 record를 DTO로 활용하기 편리하지만, 오래된 프로젝트에서는 라이브러리 호환성을 먼저 확인하는 편이 좋습니다.

필드가 많은 요청 객체는 Builder가 편할 수 있습니다

DTO의 필드가 많아지면 생성자 인자 순서를 확인하기 어려워질 수 있습니다.

예를 들어 문자열과 숫자 타입의 필드가 여러 개 있다면 다음과 같은 문제가 생길 수 있습니다.

  • 인자 순서를 잘못 넣기 쉽습니다.
  • 테스트 데이터 생성 코드가 읽기 어려워집니다.
  • 선택값이 많은 객체는 생성 코드가 길어집니다.

이런 경우에는 Lombok의 @Builder가 편리할 수 있습니다.

필드 수가 많고 선택적으로 값을 조립해야 한다면 Lombok Builder가 더 읽기 쉬운 경우가 있습니다.

java record lombok을 함께 사용해도 될까요?

기술적으로는 프로젝트에 record와 Lombok이 함께 존재할 수 있습니다. 중요한 점은 한 프로젝트에서 반드시 하나의 방식만 선택해야 하는 것은 아니라는 점입니다.

실무에서는 DTO 역할에 따라 나누는 방식이 오히려 현실적입니다.

예를 들면 다음과 같습니다.

  • 단순 조회 응답 DTO는 record를 사용합니다.
  • 간단한 요청 DTO는 record를 사용합니다.
  • 필드가 많은 조립형 DTO는 Lombok Builder를 사용합니다.
  • 기존 JavaBean 연동 객체는 Lombok을 사용합니다.
  • JPA Entity는 일반 클래스를 사용합니다.

이렇게 구성하면 record와 Lombok의 장점을 각각 활용할 수 있습니다.

다만 팀 내에서 아무 기준 없이 섞으면 코드 일관성이 떨어질 수 있습니다. 따라서 다음과 같은 규칙을 정해 두는 것이 좋습니다.

값 전달만 담당하는 DTO는 record를 우선 검토하고, Builder나 기존 Bean 규칙이 필요한 객체는 Lombok을 사용합니다.

이 정도 기준만 있어도 개발자마다 다른 방식으로 DTO를 만드는 문제를 줄일 수 있습니다.

JPA Entity도 record로 만들면 좋을까요?

DTO와 Entity는 역할이 다르기 때문에 같은 기준으로 판단하면 안 됩니다.

record는 값 중심의 데이터 객체에 적합하지만, JPA Entity는 영속성 컨텍스트와 객체 생명주기, 프록시, 변경 감지 등 여러 요소를 고려해야 합니다.

따라서 JPA Entity를 단순히 코드가 짧다는 이유로 record로 바꾸는 접근은 적절하지 않습니다.

일반적으로는 다음과 같이 역할을 분리하는 편이 이해하기 쉽습니다.

객체 종류우선 검토할 방식

API 응답 DTO record
단순 요청 DTO record
서비스 간 전달 객체 record
필드가 많은 조립형 DTO Lombok + Builder
기존 JavaBean 연동 객체 Lombok
JPA Entity 일반 클래스 중심으로 검토

특히 Entity와 API 응답 DTO를 분리하면 데이터베이스 구조가 API 응답 형식에 직접 노출되는 문제도 줄일 수 있습니다.

Builder가 필요하면 Lombok을 선택해야 할까요?

Builder가 꼭 필요하다면 Lombok은 여전히 편리한 선택입니다.

다만 모든 DTO에 습관적으로 @Builder를 붙이는 방식도 다시 검토할 필요가 있습니다.

필드가 2~3개뿐인 단순 DTO라면 Builder가 오히려 코드를 길게 만들 수 있습니다. 이런 객체는 record의 기본 생성 방식을 사용하는 편이 더 간단할 수 있습니다.

반대로 다음과 같은 경우에는 Builder의 장점이 분명합니다.

  • 필드가 많습니다.
  • 선택적인 값이 많습니다.
  • 테스트 코드에서 다양한 조합을 만듭니다.
  • 같은 타입의 필드가 많아 생성자 순서를 구분하기 어렵습니다.
  • 객체 생성 코드의 의미를 명확하게 보여 주고 싶습니다.

따라서 Builder 사용 여부는 DTO라는 이유가 아니라 객체 생성 복잡도를 기준으로 결정하는 것이 좋습니다.

record를 사용하면 Lombok을 제거할 수 있을까요?

모든 DTO를 record로 바꾼다고 해서 Lombok을 바로 제거할 수 있는 것은 아닙니다.

프로젝트에서는 DTO 외에도 다음과 같은 기능을 사용하고 있을 수 있습니다.

  • @Slf4j
  • @Builder
  • @RequiredArgsConstructor
  • @Getter
  • @Value

따라서 record 도입과 Lombok 제거는 별개의 문제로 보는 것이 좋습니다.

DTO 일부를 record로 전환하더라도 생성자 주입, 로깅, Builder 등의 용도로 Lombok을 계속 사용할 수 있습니다.

반대로 프로젝트 규모가 작고 Lombok 사용 범위가 DTO에만 한정되어 있다면 record 전환을 계기로 의존성을 줄일 수 있는지 검토할 수 있습니다.

Java record와 Lombok 선택 기준

실무에서는 다음 순서로 판단하면 비교적 간단합니다.

1. 객체가 단순한 데이터 전달용인지 확인합니다

값을 받아서 전달하고 생성 후 변경할 필요가 없다면 record를 우선 검토할 수 있습니다.

2. 기존 JavaBean 규칙이 필요한지 확인합니다

getName() 형태의 Getter나 기본 생성자 등 기존 규칙을 요구하는 코드가 있다면 Lombok 또는 일반 클래스가 더 적합할 수 있습니다.

3. Builder가 실제로 필요한지 확인합니다

필드가 적다면 record 생성자로 충분할 수 있습니다. 필드가 많고 선택적인 조립이 필요하다면 Lombok Builder가 편리합니다.

4. 프레임워크 호환성을 확인합니다

Spring Boot, Jackson, Validation을 비롯해 프로젝트에서 사용하는 라이브러리 버전을 확인해야 합니다.

5. 팀 규칙을 정합니다

개발자마다 취향대로 선택하기보다 DTO 종류별 기준을 정해 두는 것이 유지보수에 도움이 됩니다.

어떤 방식을 선택하는 것이 좋을까요?

Java record와 Lombok 비교에서 가장 현실적인 결론은 DTO의 성격에 따라 선택하는 것입니다.

단순한 요청과 응답 DTO라면 record를 우선 검토하는 것이 좋습니다. 코드가 짧고 데이터 전달 객체라는 의도가 분명하게 드러나기 때문입니다.

반면 Builder가 필요하거나 기존 JavaBean 구조를 유지해야 하거나 세밀한 클래스 구성이 필요하다면 Lombok이 더 유연합니다.

정리하면 다음과 같습니다.

  • 단순 데이터 전달은 record를 우선 검토합니다.
  • 생성 후 변경이 필요 없는 응답 객체는 record가 잘 맞습니다.
  • 필드가 많고 조립 과정이 복잡하면 Lombok Builder를 검토합니다.
  • 기존 시스템과의 호환성이 중요하면 Lombok 또는 일반 클래스를 검토합니다.
  • JPA Entity는 DTO와 별도의 기준으로 설계합니다.

새로운 프로젝트에서는 모든 DTO에 Lombok을 적용하기보다 record로 충분한 객체인지 먼저 확인하는 방식이 합리적입니다. 반대로 기존 프로젝트를 무리하게 전부 record로 바꾸기보다는 새로 작성하는 단순 DTO부터 점진적으로 적용하는 편이 관리하기 쉽습니다.

FAQ

Java record는 Lombok을 완전히 대체할 수 있나요?

완전히 대체하지는 못합니다. record는 데이터 중심 객체를 간결하게 표현하는 데 적합하지만 Lombok은 Builder, 로깅, 생성자 생성 등 더 다양한 기능을 제공합니다. 프로젝트에서 사용하는 Lombok 기능을 확인한 뒤 판단해야 합니다.

DTO는 모두 record로 만드는 것이 좋나요?

그렇지는 않습니다. 단순한 요청과 응답 DTO에는 잘 맞지만 Builder가 필요하거나 기존 JavaBean 규칙을 따라야 하는 객체는 Lombok이나 일반 클래스가 더 적합할 수 있습니다.

java record lombok getter 방식은 어떻게 다른가요?

Lombok의 일반적인 Getter는 getName() 형태이지만 record의 접근자는 name() 형태입니다. 기존 코드나 라이브러리가 JavaBean Getter 이름을 전제로 한다면 호환성을 확인해야 합니다.

java record vs lombok value 중 어떤 것이 더 좋나요?

단순한 불변 데이터 객체라면 record가 더 간결합니다. 기존 클래스 구조를 유지하면서 Lombok의 다른 기능을 함께 사용해야 한다면 @Value가 더 유연할 수 있습니다.

record에서 Setter를 사용할 수 있나요?

record는 생성 후 구성 요소의 값을 바꾸는 방식과 맞지 않습니다. 값 변경이 필요한 객체라면 일반 클래스나 다른 설계를 검토하는 것이 좋습니다.

JPA Entity에 record를 사용해도 되나요?

DTO와 JPA Entity는 요구사항이 다릅니다. JPA Entity는 영속성 관리, 프록시, 객체 생명주기 등을 고려해야 하므로 단순 DTO와 같은 기준으로 record를 적용하면 안 됩니다. 일반 클래스 중심으로 설계하는 것이 적절합니다.

record와 Lombok을 같은 프로젝트에서 함께 사용해도 되나요?

사용할 수 있습니다. 단순 DTO는 record로 작성하고 Builder나 기존 Bean 규칙이 필요한 객체는 Lombok으로 작성하는 방식이 가능합니다. 다만 팀 내 적용 기준을 정해 두는 것이 좋습니다.