회사에 입사한 지 약 일주일, 간단한 프론트엔드 로직을 개발한 후 8월 29일에 기존 백엔드 개발자분으로 부터 Strapi의 1차 인수인계를 받았다. 이후 본격적으로 백엔드 코드를 뜯어보면서 Strapi에 대한 몇 가지 중요한 문제를 경험하게 되었다.
현재 우리 회사는 개발자보다 다른 부서의 인원이 더 많기 때문에, 관리 페이지를 쉽게 생성할 수 있는 CMS 기능을 가진 Strapi는 처음에는 매우 적합한 도구라고 생각했다. Strapi는 관리 인터페이스를 제공하며, 복잡한 개발 없이도 관리자가 데이터를 손쉽게 처리할 수 있는 환경을 제공하기 때문이다. 하지만 직접 사용해보면서 Strapi의 몇 가지 한계를 인지하게 되었다.
우선, 커스텀 기능을 추가하거나 앞으로 AI와 같은 고급 기능을 지원하는 데 있어 Strapi는 제약이 많다는 점이 눈에 띄었다. 단순한 CMS를 넘어서는 복잡한 비즈니스 로직을 구현할 때 Strapi는 유연성이 부족하다는 한계가 명확했다.
깃허브 로그를 확인해보니, 한 명의 개발자 분마다 특정 기능의 대부분을 전담해 작업한 것으로 보였고, 이로 인해 백엔드 로직이 해당 개발자에게 크게 의존하고 있다는 것을 느꼈다. 이런 상황에서는 선임 백엔드 개발자가 없이 원 프로젝트를 유지보수하는 것은 상당한 위험이 따를 수 있다고 판단했다.
특히, crons.js 파일(알림을 보내는 로직이 포함된 파일)이 4500줄에 달할 정도로 코드 구조가 복잡해져, 유지보수가 어려워지는 상황이었다. Strapi 백엔드의 커스텀 코드가 많았기 때문에, 내가 모든 코드를 다 파악하지 못한 상태에서 변경하다가는 실서버가 다운될 수도 있다는 우려가 들었다. 이 때문에 Strapi를 최소한으로 이용하면서, 서비스 확장을 위해 더 유연한 개발 방식을 찾아야겠다고 생각했다.
내가 생각한 아이디어를 세희님께 말씀드렸고, 이후 대표님께도 공유하여 1차적으로 승인을 받았다. 이제 어떤 프레임워크를 사용할지 논의하게 되었는데, 프론트엔드와 백엔드 모두 Node.js를 사용하고 있는 상황을 고려해, 훗날의 나와 같은 인턴, 개발자(백엔드, 프론트)분들 모두를 고려해, Node.js 프레임워크 중에서 선택하기로 했다.
따라서 선택지는 Express.js, Koa.js, 그리고 NestJS였다.
결국 우리의 선택은 NestJS로 결정되었다. 그 이유는 여러 가지였다. 일단 세희님이 내 의견을 존중해주셨고, 내가 스프링(Spring) 경험이 조금 있었기 때문에, NestJS가 스프링과 비슷한 구조를 가지고 있다는 점이 흥미로웠다. 또한, 타입스크립트를 적극적으로 사용하여 객체지향 사용과 타입이 엄격하다는 점도 매력적으로 느껴졌다.
Express로 개발을 하면 단기적으로는 빠르게 개발이 가능하겠지만, 시니어도 아니고, 주니어 중 주니어인 나에게, 처음부터 잘 짜여져 있는 프로젝트 구조를 잡아간다는 것은 힘들다는 것을 스스로 잘 알고 있었고, 장기적인 유지보수와 확장성을 고려했을 때 NestJS가 더 적합하다는 결론에 이르렀다.
최종적으로 Strapi에서 NestJS로 완전히 전환하는 것이 나 (또는 우리?)의 장기적인 목표이다. 이 전환은 장기적인 프로젝트로 진행될 것이며, 이를 통해 서비스가 더 다양한 기능을 처리하고, 더 많은 사용자 트래픽을 감당할 수 있을 것으로 기대하고 있다. (일단은 초기에는 CMS 때문이라도 Strapi에 의존적이게 개발되긴 할것이다…)
이제 처음 NestJS로 간단한 코드와 구조를 만들어보면서 경험한 DX와 배운 점에 대해 설명해보겠다. (물론 다들 알고 계시는 내용이 많으시겠지만, 열심히 발표해 보겠습니다… 😅)
