너구리소굴 Backend Framework 변경을 결정한 계기

이전 게시글에서 백엔드 프레임워크를 Nest.js로 설정한 이유에 대해 기술했다.

 

두 달이 조금 안되는 기간 동안 프레임워크에 대해 충분히 익히지 못한 상태로 개발에 착수하기도 했고, 업무중에는 Spring Boot를 사용하다 보니 Nest.js의 단점이 더 두드러졌다.

 

그동안 개발하며 본인이 느낀 Nest.js의 단점은 아래와 같다.

 

1. DI 대상 객체들을 수동으로 등록해주어야 한다.

 Spring Boot와 비교했을 때 Nest.js의 가장 큰 단점은 DI 설정에 귀찮은 타이핑이 많이 들어가야 한다는 것이다. Spring Boot에서는 클래스를 정의한 뒤 어노테이션을 DI 대상 구현체에 하나, DI 대상 변수에 하나. 총 두 개의 어노테이션 만으로 별도의 추가 작업 없이 DI가 가능하다. 하지만 Nest.js의 경우 정의한 클래스를 모듈의 providers 또는 controllers에 클래스를 등록해준 뒤 어노테이션을 작성해야 DI가 수행된다.

 지금은 너구리소굴에만 집중할 수는 없는 상황이다. 따라서 최대한 개발 시간을 단축시켜야하는 내 입장에선 설정할 게 많다는 것이 가장 큰 단점으로 다가왔다. 물론 Spring Boot도 초기 설정이 간단해지기는 했으나 아주 손이 안가는 편은 아니다. 그래도 초기 설정만 하는 것과 개발 내내 타이핑 해야하는 것은 다르다.

 

2. DI가 생성자에서만 이루어진다.

Nest를 처음 다룰 때 Spring Boot처럼 Contorller 메소드 파라미터로 의존성을 바로 주입 받으려고 했던 적이 있었다..ㅋㅋ 이건 사용법을 제대로 숙지하지 못한 내 실수이기도 했다. 문서를 보니 Custom Decorator를 이용해 구현이 가능해 보이지만, 어쨌든 Spring boot에 비해 추가 공수가 들어간다는 것은 단점으로 꼽을만 하다고 생각한다.

 

3. Module 등록 순서에 신경써야한다.

 1번과 이어지는 단점이다. Nest.js에서는 모듈 단위로 나누어 providers, controllers를 등록할 수 있는데, 모듈로 나누어 등록하는 것 자체는 좋지만, 의존 관계에 따라서 다른 모듈의 컴포넌트(UseCase 혹은 Service)를 참조해야하는 경우, Module이 등록되어있는 순서에 따라 빌드 시 에러가 발생할 수 있다.

 

4. 생각보다 무겁다

 어디까지나 주관적인 의견이지만 같은 생각을 하는 사람이 꽤 있을 것 같다. TypeScript 계열 언어를 사용하면서 느낀 점인데, tslint에.... tsc에... 그리고 nest에서는 ts 컴파일이 끝나면 모듈 로드까지 평균 15초 정도 소요되었던 것 같다. 이건 개발환경 문제일 수도 있을 것 같다.

 

 

위와 같은 이유로 Spring boot로 백엔드 프레임워크를 바꿔야겠다고 생각했다.