[이룸] 240205 왜 우리는 생성자 주입을 쓰는가?

 

저희 팀 백엔드 코드 컨벤션에는 의존성 주입을 직접 생성자를 작성하자는 내용이 있습니다.

 

의존성 주입은 객체가 다른 객체(혹은 자원)들을 필요로 하기 때문에 생겨납니다. 이때 직접 주입을 하면, 필요한 인스턴스를 직접 생성하기 때문에 객체 간 결합도가 높아져 유연성이 떨어지겠죠.

 

따라서 스프링 프레임워크는 외부에서 의존성을 주입하는 방법을 채택합니다. 객체를 스프링 컨테이너에서 빈으로 관리하고, 해당 빈을 생성자 혹은 어노테이션을 사용하여 자동으로 주입하는 방식이죠. 이는 객체 간 결합도를 낮춰 코드 유연성을 높이고, 유지보수와 테스트도 더 쉬워집니다.

 

의존성을 주입하는 방법은 여러 가지가 있지만, 보통 직접 생성자를 작성하거나 lombok을 사용할 경우 @RequiredArgsConstructor 을 씁니다.

 

@RequiredArgsConstructor 어노테이션을 사용하면…

 

<장점>

• 코드가 더욱 깔끔합니다.
• 작성해야 하는 코드 양이 줄어듭니다.
• 의존성 주입 추가, 제거할 때마다 생성자를 수정할 필요가 없습니다.

<단점>

• lombok 라이브러리에 대한 의존성이 높아집니다. lombok에 변화가 생길 경우, 코드 전체를 수정해야 합니다.

----------------------------------------------------------------------------------------------------------------------

 

직접 생성자를 작성하면…

 

<장점>

• 생성자 코드가 눈에 딱 보입니다!
• lombok에 의존하지 않습니다.
• @Autowired 를 대신 사용할 수도 있습니다.

<단점>

• 필요한 필드가 많을수록 코드가 길어지고 수정이 불편합니다.

저희는 lombok 의존성을 줄이기 위해 직접 생성자를 작성하는 방향을 채택하였습니다. lombok을 쓰면 코드가 간결해지고 작업도 수월해지지만, 게터와 세터 등 실제 코드에 나타나지 않는 메서드가 많아지기 때문에 코드를 읽는 사람에겐 불친절한 코드가 될 수 있습니다. 코드를 하나하나 디버깅하기도 어렵겠죠. setter는 사용을 지양하고 있는데, 그렇다고 해서 getter를 안 쓰는 것은 아니라서 이것도 참 애매한 부분입니다. lombok을 완전히 안 쓰려니 너무 힘든 여정이 될 것 같았습니다.

 

무엇이든 편리해지는 것을 사용할 때는 그 장점을 극대화하고 단점을 최소화하는 방법을 찾는 것이 중요하겠습니다. 이를 위해서는 lombok은 여기까지만 사용하자, 같은 마지노선의 룰이 있어야 한다고 생각합니다. 하지만 개발 속도를 높여 주는 편리한 라이브러리가 있는데, 이것을 굳이 쓰지 않는 것도 비효율적인 선택이 아닌가 싶어요. 답이 없는 문제이고 팀의 분위기에 따라 롬복을 사용할 수도 있고, 아닐 수도 있겠지만 어떤 방향이든 팀원 전체가 이해할 수 있다면 괜찮다고도 생각합니다.