Lombok 에 대한 짧은 생각
최근 Java / Spring 으로 스택을 변경하면서 작은 프로젝트를 하고 있다. 팀원의 추천으로 lombok 이라는 라이브러리를 사용하게 되었다. Lombok 을 쓰면 정말 간단하다. Getter, Setter, Constructor, equals, hashCode 과 같이 작성해야하지만 작성에 피로를 느끼는 코드들을 annotation을 통해서 너무 쉽게 만들 수 있다. 그런데, 이 라이브러리 사용할수록 필요성에 대한 의문이 생긴다. 생각을 정리할 겸 글로 남겨본다.
현재 프로젝트에서는 lombok 을 사용하고 있다. lombok 의 존재를 모르고 있다가 조사를 하고 도입을 하기로 결정한 것인데, 당시에도 나는 다소 부정적인 입장이었다. 이유는 다음과 같았다.
- lombok 이 주입하는 코드가 어떤 코드인지 모른다.
- 편의성을 핑계로 안전을 놓칠 가능성이 생긴다.
- 실수의 가능성을 주지 않도록 해야한다.
Setter,Constructor가 특히 그렇다.EqualsAndHashCode또한, 대충 쓰면 실수하기 쉽다.Data와 같은 복합 어노테이션은 말할 것도 없다.
그래서 이런 생각을 바탕으로, 제한해서 사용하기로 결정을 했다.
- 허용한 어노테이션만 사용한다.
Getter- 반드시 field 에 직접 걸어야한다.
Builder- 반드시 constructor 에 직접 걸어야한다.
- 클래스 위에서 통으로 걸어버릴 경우, 의도하지 않은 상황이 연출될 수 있다. 따라서, 생성자에서 직접 제한하도록 했다.
그럼에도 여전히 불안불안하다. (C/C++ 로 코딩을 시작해서 그런걸까?) 개발자가 직접 뜯어볼 수 없는 코드가 주입되고 있고, Lombok 에 대해서 내가 이해를 제대로 하고 있는지도 의문이다. 엄청 단순한 @Getter 로 코드를 줄일 수 있으며 꽤나 편리하다는 것에는 동의하지만, 그냥 Getter 를 intelliJ 로 넣으면 그만이다. 내 lombok 의 사용은 거의 Buiilder 를 위함이지만, 생성되는 코드가 노출되지 않고 있어서 그런지 불안불안하여 최대한 제약 조건을 건 것이다. 그런데, Builder 도 대안이 있다. BuilderGenerator 라는 플러그인을 사용하면 된다. 물론 코드의 양은 증가하겠지만, 더 명확하게 표현할 수 있으며 나중에 버그가 발생했을 때 고치기에도 편리하다.
그러면 lombok 을 사용할 이유가 있을까? Lombok 자체도 지원하는 IDE 가 제한되어 있으며, 작동 방식에 대해서도 컴파일 과정에서 AST 를 조작하는 것이므로 "일종의 해킹" 이다. 이런 문제를 차치하더라도, "개발자가 의도하지 않은 형태의 코드가 주입될 수 있다는 가능성"을 프로젝트에 심는다는 것이 큰 문제이다. 코드를 읽을 때 코드에서 표현하고자 하는 부분은 코드로 보여야한다고 생각한다. 그래야 추후에 문제가 발생했을 때 문제를 파악하고 해결할 수 있다. 아주 단순한 편의성을 위해서 위험을 짊어질 필요는 없다.
만약, 한번 빠르게 쓰고 버려둘 간단한 코드라면 lombok 의 사용으로 생산성을 증대시킬 수 있으니 꽤나 좋은 선택이다. 그러나, 내가 지금 하고 있는 프로젝트나 현실의 세계에서는 코드는 계속 읽혀야하고, 변경되어야하며 디버깅 해야한다. lombok 은 그런 환경에서 적합하지 않다. 현재 프로젝트에서도 더 많은 코드에 삽입되기 이전에 lombok 을 제외해보려고한다.
