Record vs Lombok vs AutoValue 비교 분석

1. 왜 다시 “데이터 클래스”인가?

DTO·Value Object·Config Bean처럼 “값만 담는 객체”는 스프링 프로젝트 곳곳에 숨어 있습니다. 반복되는 getter‧setter, equals/hashCode, toString… 언제까지 IDE 자동 생성 버튼을 누를 순 없죠. JDK Record, Lombok, Google AutoValue 세 가지 방법을 놓고 보일러플레이트 제거 전략을 정리합니다.

---

2. 3파전 핵심 키워드 한눈에

• Record — 자바 언어 기능
  • Java 16+ 내장, 문법 자체가 “불변 데이터 전용 클래스”
  • 생성자·필드·equals/hashCode/toString 자동 생성
  • 상속 불가(암시적 final), 필드도 자동 private final
  • 제한적 커스텀: 로직 많은 객체에는 부적합
• Lombok — 컴파일러 플러그인
  • @Getter @Setter @Builder @Value … 풍부한 어노테이션
  • 버전 제약↓: Java 8~21 어디서든 동작
  • 빌더·가변 객체 등 “지정한 만큼만” 생성 → 유연성 최고
  • 단점: 외부 라이브러리 의존·IDE 플러그인 필요, Hidden Code 디버깅 난도↑
• AutoValue — 어노테이션 프로세서
  • 구글이 만든 “항상 불변 값 객체” 생성기
  • 추상 클래스 + 어노테이션 → 실제 구현을 별도 클래스에 생성
  • IDE 인식 잘 되고 리플렉션 안전, 하지만 빌더·커스텀 메서드 작성량이 Lombok 대비 많음
  • Android·저사양 환경에서도 안정적

---

3. 관점별 비교 & 실전 팁

① 선언 간결성

• Record > Lombok > AutoValue (대부분 1~3줄로 끝)

② 커스텀·확장성

• Lombok > AutoValue > Record
  • 비즈니스 로직·유효성 검사 등 추가해야 한다면 Lombok의 @Builder+@With 조합 추천.
  • AutoValue는 @AutoValue.Builder를 직접 코딩해야 하지만, 생성 코드가 분리돼 가독성이 좋음.

③ 빌드 / IDE 통합

• Record: JDK 자체 기능이므로 가장 평탄.
• Lombok: Maven/Gradle 플러그인 + IDE 플러그인 설치 필수. 팀원 환경 불일치에 주의.
• AutoValue: 표준 annotation-processing이라 IDE 지원이 자연스러움. Android Studio에서도 안정.

④ 런타임/성능

• 세 도구 모두 정적 코드 생성이라 실행 성능 차이는 미미.
• 단, Lombok은 delombok 과정 없으면 stacktrace 가독성이 떨어질 수 있고, HotSwap이 지원되지 않을 때 디버깅이 번거롭습니다.

⑤ 마이그레이션 전략

• Lombok → Record
  • @Value 혹은 @Getter·@AllArgsConstructor로만 구성된 불변 DTO부터 단계적으로 교체.
  • 빌더 필요 객체는 RecordBuilder(라이브러리)나 자체 util 활용.
• AutoValue ↔ Record
  • Android API 레벨(=JDK 버전) 낮으면 AutoValue 유지, 서버 사이드는 Record 권장.

---

4. 언제 무엇을 택할까? 실전 시나리오

시나리오최적 선택

최신 스프링 부트 3.x, 불변 DTO, 단순 값 객체	Record
레거시 Java 8, 계층 구조 DTO, 빌더 필수	Lombok (@Builder)
Android 앱, 코드 GWT / 프로가드 난독화 고려, IDE 자동 리팩터링 중시	AutoValue

 

TIP — 팀 내 코딩 규칙으로 “Record 우선, Lombok @Builder 예외 사용”을 정해 두면 미래 호환성과 생산성을 동시에 잡을 수 있습니다.