Lombok 단점과 실무 사용에 대한 생각

Jeongkuk Seo

Published in

sjk5766

6 min readFeb 24, 2023

IntelliJ IDE가 제공하는 많은 기능들을 놔두고 Lombok을 왜 쓸까?

내 경우는 빌더 패턴 때문에 필요성을 느꼈다. dto에 필드가 10개가 넘는데 이걸 손수 Builer 패턴으로 return this 를 하는 set 함수를 10개 넘게 만들다 보면 현타가 찾아온다.

이번만 참고 다음번에 Lombok 쓰겠다고 다짐하는 나를 볼 수 있다. 물론 최근에 찾아보니 Builder Generator라고 Plugin을 설치하면 어렵지 않게 만들 수 있다는 걸 최근에 알았다.

Lombok Plugin을 설치해 적용해 보면서 문득 Lombok의 단점은 뭔지 궁금해졌다. 무릇 특정 기술의 단점을 모른다면 그건 기술이 완벽하기 보단 내가 단점을 모르고 있을 확률이 크다.

몇 가지 글을 보다가 손권남님이 쓰신 글을 보고 이게 내가 찾던 글이구나 싶었다. 잘 정리된 글이니 나는 간단하게 요약 정리하고 실무에서 Lombok의 필요성에 대한 내 생각을 적겠다.

Lombok의 단점

다음과 같이 @AllArgsConstructor 를 쓰는 함수가 있다고 가정하자.

@AllArgsConstructor
public class Product {
    private int discountPrice; // 할인 가
    private int price;         // 정가
}

서비스 Layer에서 이렇게 사용하고 있다.

@Transactional(readOnly = true)
@Service
public class ProductService {
    public void test() {
        new Product(5_000, 10_000);
    }
}

DB 테이블을 조회하는 관점에서 어떤 개발자가 정가가 왼쪽에 있는게 보기 편하겠다 싶어 아래와 같이 Product의 필드 순서를 바꾼다.

@AllArgsConstructor
public class Product {
    private int price;
    private int discountPrice;
}

둘 다 int 타입이기 때문에 IDE 에서 어떤 오류도 잡아 낼 수 없다. 그리고 화면에서는 정가 5000원의 제품이 할인되서 10000에 판매되는 희귀한 현상을 볼 수 있다.

이 문제는 @RequiredArgsConstructor 에도 동일하게 발생한다. 그럼 이제부터@AllArgsConstructor, @RequiredArgsConstructor 는 쓰지 말아야겠군. 이라고 정리 한다면 이제부턴 줄줄이 쓰지 말아야 할 어노테이션이 늘어난다.

@Data, @Value, @Builder 어노테이션은 모두 내부적으로 @AllArgsConstructor, @RequiredArgsConstructor 어노테이션을 사용한다.

아래와 같이 @Builder 어노테이션이 적용된 코드를

@Builder
public class Product {
    private int price;
    private int discountPrice;
}

Delombok 해서 어노테이션이 적용된 코드를 보면 아래와 같다.

public class Product {
    private int price;
    private int discountPrice;

    Product(int price, int discountPrice) {
        this.price = price;
        this.discountPrice = discountPrice;
    }

    public static ProductBuilder builder() {
        return new ProductBuilder();
    }
    
    // 아래에는 빌더 관련 코드들이 존재
}

생성자인 Product를 보면 접근 제어자가 없어 package 레벨로 동작한다. 즉 현재 클래스와 동일한 패키지 내에서 접근 가능하다. 따라서 @Builder 어노테이션을 사용하고 싶다면 private 생성자를 직접 선언하고 메소드 레벨에서 적용한다.

public class Product {
    private int price;
    private int discountPrice;

    @Builder
    private Product(int price, int discountPrice) {
        this.price = price;
        this.discountPrice = discountPrice;
    }
}

이 외에도 @EqualsAndHashCode, @ToString 을 사용할 때도 주의사항이 있지만 더 정리하지는 않겠다.

실무에서 Lombok 사용은 글쎄..

IntelliJ IDE는 생성자부터 getter, setter, toString, equals 등 반복적으로 생성해야 하는 code들에 대해 generator 기능을 제공한다. 그리고 위에서 언급했다시피 Builder 패턴도 Plugin을 통해 간단하게 만들 수 있다.

그럼 사용하는 방법에 주의할 게 많은 Lombok을 사용할 필요가 있을까? 모두가 Lombok을 잘 알고 주의사항을 안다면 어떨까?

손권남님 블로그 글을 보면서 정말 동의했던 글이 있다.

개발자에게 @Data 사용시 equals, hashCode 그리고 생성자를 직접 만들어주라고 “말해봐야” 아무 소용없다. 그냥 깔끔하게 금지시키는게 낫다.

왜냐면 내가 말해봐야 소용없던 녀석이었기에..

사용하는 IDE나 상황마다 다를 순 있겠지만 실무에서 Lombok은 사용을 자제하는게 좋을 것 같다고 생각하며 글을 마무리한다.

Lombok 단점과 실무 사용에 대한 생각

Written by Jeongkuk Seo