[NestJS] 기존 Express 프로젝트 NestJS 이관기
Express로 개발한 김캐디 예약 서버를 NestJS로 이관 및 리팩토링 한지 3주가 지났다...
서버는 이제 안정화가 되었고, 그에 따라 회고겸 기록을 남긴다. :)
P.S. 메리크리스마스 🎄
# Express를 버리고 NestJS로 갈아탄 이유
여러 가지 이유가 있지만, 우선 Express의 자유로움이 싫었다.
(나중엔 자유로움을 원하게 될지 모르더라도, 그리고 그럴 것 같지만 지금 당장은 그랬다.)
자유로움이란 모든 것이 될 수 있다. 아키텍처부터, 디렉토리 구조, 심하게는 네이밍 컨벤션까지.
물론 모든 것엔 트레이드오프가 있기에, 이런 자유로움으로 인해 얻는 이점도 분명 존재한다.
다만 내 실력이 부족했던 탓인지, 자유로움 속에서 코딩을 하며 따라오는 스트레스가 너무 심했다.
내가 짠 코드와 방식, 패턴 등이 정석인지 아닌지, 올바른 방법인지 아닌지, 베스트 케이스인지 아닌지에 대한 끊임없는 고민이 샘솟았고, 이는 스트레스로 직결되었다.
물론, 어떻게든 베스트 케이스로 개발 해내면 그만인 문제이지만, 코드 리뷰도 없이 신입인 내가 단독으로 개발을 하기에 생긴 이슈라고 포장하고 싶다...
또한, 회사가 점점 커지면서 신입 개발자분들이 들어오고, 나 혼자 개발하던 프로젝트에 피처 단위로 여러 개발자들과 협업을 하게 되었을 때, 프레임워크단에서 정립되어 있는 아키텍처나 컨벤션이 없다 보니 비즈니스 로직 이외에 코드에 대한 설명을 하는 온보딩 절차가 추가되고 이로 인한 진입 러닝 커브가 높아지고... 이런 비용들이 생기는 것 또한 문제라 판단했다.
그 외에도 응답 속도 향상, 큼지막한 기능 개발이 예정되어 있던터라 확장성 등 여러 가지 요소들을 종합적으로 고려해 보았을 때 리팩토링도 할 겸 Express에서 NestJS로 이관하게 되었다.
알만한 사람들은 알겠지만, 기존에 잘 굴러가고 있는 서버를 다른 프레임워크로 재개발 한다는게 가진 리소스가 적은 스타트업 씬에서는 정말 쉽지 않은일이다.
그럼에도 불구하고, 미래를 위한 내 판단을 믿고 지지해주신 최재림 CTO님에게 감사의 말씀을 드리고 싶다.
# NestJS로 개발하며 느낀 점과 생긴 이슈들
먼저, 느꼈던 것은 아키텍처 및 디자인 패턴에 대한 존재 이유(?)와 필요성을 알게되었다.
사실 나는 테크 딥다이브 쪽이 아니다.
그저 유용한 서비스를 만들고, 내가 만든걸 사람들이 사용하는것에 희열을 느껴 개발을 시작했지, 언어나 프레임워크에 깊숙한 곳을 파헤쳐가는 재미로 시작한것이 아니였기 때문이다.
또한, 어떻게하면 효율적일까 생각하며 짜다보니 그게 싱글톤 패턴이었고, 내가 짠 것이 맞나 싶어 구글링하거나 오픈소스를 까서 남들이 짜 놓은걸 보면, 결국 사람들은 다 생각이 고만고만 하구나를 느꼈기에 필요성도 잘 못느꼈다.
하지만, 아키텍처와 패턴이 강제화 되어 있는 NestJS를 사용해보니 내 생각이 틀렸다는 걸 깨달았다.
NestJS 철학에 맞추어 코드를 짜다보니 재사용성도 높아졌고, 가독성도 높아졌으며, 코드 확장성도 눈에띄게 높아짐을 몸으로 체감했다. (그래서 어떻게 달라졌냐라고 하기엔 그냥 깔끔해졌다.)
이런 느낌을 받다보니, Express로 개발할 때 들었던 의문점도 해소가 되었는데,
나는 현업에서 개발을 하면서도 항상 들던 의문이 있었다.
지금 내가 실제 프로덕트를 잘 굴리고 있지만, 그냥 밖에서 개인 프로젝트를 진행하는 것과 코드 퀄리티가 뭐가 다른지, 과연 내 코드를 비춰봤을 떄 나를 현업 개발자라 말할 수 있는지? 등 그런 의문들이었다.
개발적으로만 보았을 때, 입사하고 나서 바뀐 차이는 단순히 유저가 있고 없고의 차이였기 때문이다.
그게 엄청난 차이이긴 하지만..
그런데 NestJS로 개발하며 DI, DTO, Repository 등 수많은 개념들을 공부하고 프로젝트에 적용한 순간, 내가 결여됐다고 생각했던 전문성이라는 부분이 채워지는 느낌을 받았다.
하긴 이런 개념들이 정립되기까지 오랜 경험과 최고의 효율성을 찾고자 하는 노력으로 도입된 것들일 텐데, 습득하고 적용하지 않는 것이 오히려 이상하다는 걸 깊이 깨달았다.
- 설계한 아키텍처
물론, 코드단에서의 이슈도 있었다.
NestJS는 Express를 베이스 프레임워크로 두고 추상화하여 굴러가는 프레임워크인데, 나이브 한 Express보다 성능이 밀리고 싶지 않았기에 Fastify를 어댑터로 붙여 퍼포먼스를 높였다.
그로 인해, 기존 Express 프로젝트에서 쓰던 미들웨어나 라이브러리들이 호환이 안됐고, Fastify용으로 전부 교체하거나 없다면 직접 만들어서 사용할 수밖에 없었다. 특히 body-parser 같은 경우 내가 interceptor로 직접 구현했다.
또한, ORM도 바뀌었는데 기존에는 Sequelize를 사용하다 TypeORM으로 갈아타게 되었다.
# 결과
그래서 각설하고 결과는 어떻게 되었을까?
- 2주간 서버 평균 반응 시간 차트 (이관 전 한 주, 이관 후 한 주)
서버 리팩토링을 했다면 제일 먼저 떠오르는 응답 속도가 기존 0.1초에서 0.01초대로 무려 90퍼센트나 향상되었다.
물론 이와 같이 드라마틱한 변화가 생긴 이유는 NestJS로의 이관뿐만 아니라 전체적인 코드 리팩토링 또한 했기 때문일 것이고, 그만큼 기존에 코드를 엉망으로 짜놨다는 반증 같아서 기분이 좋으면서도 화가 났다..
(아무것도 모르고 코딩하던 과거의 내가 저질러 놓은 실수들이 꽤 많았다...)
결과적으로 ECS 클러스터의 서버 인스턴스를 절반으로 줄일 수 있었고, 신입 개발자분들이 프로젝트에 조인해도 이해하기 쉬운 코드로 변신했기에 비용 절감과 클린 코드, 두마리 토끼를 동시에 잡은 성공적인 이관 및 리팩토링이었다.