스프링밖에 모르던 내가 Nest.js를?!

 요즘 블로그가 뜸했던 이유가 있었는데, 바로... 상반기부터 쭉 서비스 개발을 해왔기 때문이다. 그것도 스프링이 아니라 Nest.js + TypeORM으로.

 우리 회사는 SI회사이긴 하지만, 창사 때부터 줄곧 자체 서비스를 목표로 했다고 한다. 그리고 여러 회의를 거쳐 아이템이 선정되었고, 지금까지 발전시켜오다가 드디어 서비스 오픈을 목표로 본격적으로 개발에 돌입한 상황이었다.

 원래는 앱으로만 만들려다가 서버의 역할이 필요해졌는데, 때마침 내가 그 소식을 알게 되었고, 내가 개발자 전에 하던 업무와 밀접한 관련이 있는 앱 서비스이기도 해서 내가 자원해서 서버를 개발하기로 했다. 처음엔 서버는 한 사람으로 충분할 것 같다고 하셨지만, 우리 팀에서 나 말고도 하고 싶다고 한 사람이 있어서 팀장님은 고민하다가 두 사람을 모두 투입하기로 하셨다. 그리고 그 결정은... 신의 한수였다.

 이와 같은 히스토리로 줄곧 SI프로젝트만 해오던 내가 Nest.js + TypeORM으로 서비스를 개발하게 되었다.

 사실 내가 서버를 맡기 전에 이미 앱 개발 팀장님이 서버 인원이 없는 관계로 본인이 서버를 맡아서 만들고 계셨었다. 빠르게 만들어야 하므로 Nest.js와 TypeORM을 선택하셨는데, 처음 내가 서버를 개발하기로 했을 때 고민된 점은 Nest.js + TypeORM으로 만들 것인가, 다들 알고 있는 스프링(아마도 + JPA)으로 만들 것인가였다.

 Nest.js + TypeORM으로 할 경우, 앱 개발 팀장님이 어느 정도 닦아놓으신 기반 위에서 작업할 수 있다는 점과 낯선 기술스택을 사용해봄으로써 내 능력치를 더 키울 수 있다는 장점이 있었다. 하지만 우리회사에서는 Nest.js 프로젝트가 없었고, 나조차 프로젝트에 들어가기 전에 Nest.js에 대해 학습을 해야 했다. 그러므로 혹시 기존 인력을 대체할 인력을 구하기 어렵다는 단점이 있었다.

 스프링(+ JPA)로 할 경우, 회사에 있는 앱 개발자를 제외한 개발자가 전부 자바 개발자이기 때문에 대체 인력을 구하기 쉽다는 장점이 있었다. 하지만 아예 프로젝트 세팅부터 다 다시 해야 하는 단점이 있었다.

 결국 작은 규모의 프로젝트인 점, 이미 세팅된 환경이 있는 점, 확장성을 염두에 둬야 하는 점 등으로 Nest.js로 결정했다.

 그리고 회사의 야심찬 프로젝트이기 때문에 전사 대상으로 앱 이름 공모전도 했는데 글쎄 내가 1등을 해버렸다. 내가 이름도 짓고 내가 직접 개발하는 서비스라니. 어떻게든 성공시켜야겠단 생각이 든다.