Lombok 을 사용할 때 주의해야 하는 점들 정리

Lombok을 사용하며 주의할 것들 정리

Lombok 은 편리한 기능을 많이 제공하지만, 때때로는 그 편리함이 독이 될 수 있다.

@AllArgsConstructor, @RequiredArgsConstructor 주의

얼핏 보기엔 단순히 생성자만 만들어주는 것 같은데, 어떻게 버그를 만들 수 있을까?

버그 시나리오

@AllArgsConstructor
@RequiredArgsConstructor
@ToString
public class TestUser {
    public String id;
    public String password;
}

위와 같은 롬복 떡칠한 TestUser 가 있을 때, 일단 사용하기는 편리하다. 간단한 테스트 코드를 만들어서 테스트도 해본다.

@Test
void test() {
    TestUser testUser = new TestUser("아이디", "패스워드");
    System.out.println("testUser = " + testUser);
}

당연히 생성 시 id 에 아이디 가 잘 들어가고 password 에 패스워드 가 잘 들어간다. 그런데 어떤 개발자가 사용자가 주소, 이름 등 추가적인 정보를 입력할 수 있도록 여러가지 필드를 추가하려고 하다가 갑자기 기획자가 나중에 추가하는 것이 좋겠다고 해서 다시 원복을 해놓았다고 가정하자.

@AllArgsConstructor
@RequiredArgsConstructor
@ToString
public class TestUser {
    public String password;
    public String id;
}

처음에 작성했던 TestUser 와 논리적으로는 거의 동치일 수 있다. 그런데 처음과 다른 점이 보이는가? 다만, password 와 id 의 위치만 변경되었다. 그런데 이로 인해, 기존의 생성자에는 어마어마한 오류가 생긴다.

@Test
void test() {
    TestUser testUser = new TestUser("아이디", "패스워드");
    System.out.println("testUser = " + testUser);
}

password 필드에 아이디 가 들어가고 id 필드에 패스워드 가 들어가게 된다. 그리고 딱히 이에 대한 에러도 뜨지 않아서, 실제로 이러한 버그를 초래하고 있는지 알기도 어려울 수 있다.

해결책

• @AllArgsConstructor 와 @RequiredArgsConstructor 사용을 금지한다.
  • 혹시 @Builder 등을 이용하기 위함이라면, 접근 레벨을 낮춰놓자.
• 생성자를 직접 만든다.
• @Builder 를 적극 활용한다. (이는 파라미터 순서가 아닌 이름으로 값을 설정한다.)

파라미터 없는 @EqualsAndHashCode 주의

@Setter
@AllArgsConstructor
@EqualsAndHashCode
public class TestUser {
    public String id;
    public String password;
}

위와 같이 TestUser 에 @EqualsAndHashCode 를 추가한다면, lombok 은 equals() 메서드와 hashCode() 메서드를 자동으로 구현해준다.

버그 시나리오

class AppTest {
    @Test
    void test() {
        TestUser testUser = new TestUser("tester", "test1234");
        Set<TestUser> users = new HashSet<>();
        users.add(testUser);

        boolean contains1 = users.contains(testUser);
        System.out.println("contains1 = " + contains1); // true

        testUser.setPassword("test12345");
        boolean contains2 = users.contains(testUser);
        System.out.println("contains2 = " + contains2); // false
    }
}

• 테스트 유저를 Set 에 넣고, 비밀번호만 바꾼 뒤 testUser 가 여전히 존재하는지 확인해보면 false 응답이 나온다.
• false 가 나오는 이유는 @EqualsAndHashCode 때문이다.
  • 자동 구현된 hashCode() 메서드의 결과 값이 달라서, 다른 값으로 판단하는 것이다.
  • equals()는 내부 값이 같으니 true 가 나온다.
  • @EqualsAndHashCode 애노테이션이 없었다면, Object 에 기본 구현된 정적 메서드 hashCode() 가 주소 값으로 판단하여 둘 다 true 가 나오게 되었을 것이다.
• hashCode() 메서드는 해시테이블에서 이용될 때 성능을 위해 최대한 중복되지 않는 값을 만들려고 한다.
  • 그래서 롬복을 이용해 생성하면, 모든 필드의 값을 계산식에 이용하려 하는데 이 때문에 필드 하나만 바뀌어도 다른 해시코드가 나온다.

해결 방안

• @EqualsAndHashCode(of={"필드명"}) 과 같은 형식으로 식별자가 되는 특정 필드명을 지정하자.
• 필드명이 없는 @EqualsAndHashCode 를 사용하지 말자.

팁: @EqualsAndHashCode.Exclude 를 활용하자.

@Getter
@Setter
@EqualsAndHashCode
public class TestUser {
    public String id;
    @EqualsAndHashCode.Exclude
    public String password;
}

위와 같이 @EqualsAndHashCode.Exclude 애노테이션을 이용하면 특정 필드만 뺄 수 있다. 직접 글자로 치는 것보다 오타없이 뺄 수 있어서 좋다.

@Data 사용 금지

@Data 에는 @ToString, @EqualsAndHashCode, @Getter, @Setter, @RequiredArgsConstructor 라는 모든 애노테이션이 합쳐져있다.

한마디로 @Data 에도 @EqualsAndHashCode 가 자동으로 들어간다. 위와 같은 이유로 사용하지 말자. 물론, equals() 와 hashCode() 는 따로 커스텀 구현을 해주면 되겠지만, 협업 시 규칙을 모르는 개발자가 더 많을 것이다.

@Value 사용 금지

모든 필드를 private final로 변경해주는 기능이 있지만, 이 또한 @EqualsAndHashCode, @AllArgsConstructor 를 포함한다. @EqualsAndHashCode 는 애초에 필드 값 자체가 변경 불가능하게 바뀌기 때문에 상관이 없는데, @AllArgsConstructor 가 또 문제가 된다.

@Builder 는 웬만하면 직접 만든 생성자에서 사용해보자.

보통 @Builder 를 편하게 사용하기 위해 @AllArgsConstructor 와 같이 써버리는데, 이렇게 해도 access = PRIVATE 을 하면 웬만해서는 실수할 일이 없다. 그런데, 직접 만든 생성자에 @Builder 를 붙이면 더욱 안전하다.

@Setter
public class TestUser {
    public String id;
    public String password;

    @Builder
    public TestUser(String id, String password) {
        this.id = id;
        this.password = password;
    }
}

위와 같은 형식으로 하면, Builder 를 통해서 굳이 설정할 일이 없는 값 혹은 설정해서는 안되는 값을 제외하고 Builder 를 생성해줄 수 있다.

@ToString 의 순환 참조 주의

A 라는 객체의 멤버로 B 라는 객체가 있고, B 라는 객체의 멤버로 A 라는 객체가 있다면, 둘은 무한으로 순환하여 참조할 수 있기 때문에 @ToString 의 사용을 조심해야 한다. @ToString(exclude = "필드명") 으로 @ToString 항목에서 제외시켜도 된다.

@Setter 사용 주의

@Setter 는 모든 필드에 대한 Setter 를 만들어주는데, 편한 반면 변하지 않아야 할 필드에 대해서도 Setter 를 만들 수 있어 주의해야 한다. 특히 엔티티의 식별자와 같은 것은 거의 바뀔 일이 없으므로 주의해야 한다.

lombok.config 파일을 사용하자

lombok.Setter.flagUsage = error
lombok.AllArgsConstructor.flagUsage = error
lombok.ToString.flagUsage = warning
lombok.data.flagUsage= error

위와 같은 형식으로, 너무 많은 부작용을 일으킬 것 같은 것들은 애초에 에러로 표현되도록 설정해보자.

레퍼런스

권남 블로그 - Lombok 사용상 주의사항
실무 Lombok 사용법