문제상황
평소 사이드 프로젝트를 하도 많이 진행하다보니 기본 코드를 템플릿해놓고 있다. 회원가입, CRUD 예제만 구현되어 있는 상태에서 안쓰는 코드만 지워주면 빠르게 개발할 수 있도록 설계해두었다.
그러나 어느순간부터 Boilerplate Code에 적용된 기술스택이 굉장히 불편하다는 생각이 들었다. 리팩토링이 필요한 시점이었다.
당시의 스택을 정리해보자면,
NodeJS, WebComponents, Handlebars, WebPack이었다. 사실 지금 생각해보면 가장 네이티브 하면서 기본적인 기능만 추구하기에 적합하다고 볼 수 있지만, 개발 속도가 저하되고 테스트 불가능 및 버그 발생률을 높인다는 점에서 굉장히 비효율적인 스택이라고 생각이 든다.
이 포스트에서는 보일러플레이트 코드의 리팩토링을 강행하며 적용한 기술과 그 이유에 대해 이야기 나눠보려 한다.
1. TypeScript 전환
필자의 경우 기술에 대해 보수적으로 접근하는 편이다. 단지 테스트로만 적용해본다면 누구보다 진취적인 입장을 취하지만, 실제 프로젝트에 적용하는 기술이라면 이야기는 조금 달라진다.
기존에 개인이 구사할 수 있는 기술 스택과, 프로젝트에 알맞는 스택에는 차이가 있다. 예를들어 UI가 필요없고, 앞으로도 필요 없다고 생각되는 프로젝트에 React를 적용하는 일은 오버 엔지니어링에 속한다. 대표적으로 3D 라이브러리인 ThreeJS의 경우 일절 UI를 적용하지 않는다는 가정 하에 화면 상에는 Canvas Components만 존재해도 된다.
React의 장점은 복잡한 UI를 단순한 코드 조각(컴포넌트)로 쪼개서 단순하게 개발한다는 것이다. 프로젝트에 ThreeJS만 적용한다면 React는 불필요한 스택에 해당한다.
TypeScript도 마찬가지로 보수적으로 접근했다. 대규모 프로젝트를 개발하지 않는 이상 필요하지 않다고 생각했다. JavaScript의 타입 기능을 덧붙혀 타입 안정성을 유지하는 일과 기존 JS의 개발 생산성 사이에 벌어지는 생산성 차이가 그리 크지 않다고 느꼈다.
하지만 TypeScript를 조금 더 적용해보고 난 후로 생각이 변했다. 일반적인 상황에서도 타입을 유지하는 일은 버그 발생을 줄이는데에 중요한 작용을 하고 굳이 대규모 프로젝트가 아니더라도 개발 속도를 2배 정도 향상시킬 수 있었다.
필자의 경우 처음부터 TypeScript를 적용하지 않았고 그럴 연유조차 없었다. 지금 생각해보면 당연히 적용하는게 권장되지만, 당시에는 불필요한 작업이라고 생각했다.
2. TypeORM 적용
SQL을 작성하는게 일상이 되어버린 어느날, 이걸 왜 하고 있지하는 불편함이 들었다. 역시나 ORM의 존재를 알아버렸다.
ORM은 객체로 데이터베이스에 접근하도록 도와주는 도구다. 기존에는 SQL문을 이용하여 데이터에 접근해야 했다면 객체를 통해 명시적으로 접근할 수 있다. TypeORM은 이같은 ORM중 하나인데, 앞선 TypeScript와의 호환성이 좋다는 결론 하에 새롭게 도입하게 되었다.
사실 개인적으로 상위 기술을 배우기 위해서는 그 기저가 되는 하향 기술을 배워야 한다는 주의다. SQL문에 대한 문법적 이해 없이 ORM를 적용하게 되면 ORM 문법에만 익숙해지게 되어 다른 ORM 툴이 나왔을때 쉽게 적응하지 못한다. 필자의 경우 TypeORM을 공부할때 공식 문서로 공부했는데 실상 SQL과 다른 바가 없어 쉽게 배울 수 있었다. 모르는 문법은 그때마다 문서를 뒤져보면 바로 해결책을 찾을 수 있게 되었다.
3. React 적용
이쯤 글을 읽었다면 왜 이제야 리액트를 적용했는지 이해할 수 있으리라 생각된다. 리액트를 적용한 현 시점에서 과거의 본인을 책망하고 있지만 또 그만큼의 필요를 느끼고 리액트를 더 빠르게 배울 수 있었다는 점에서 한편으론 다행이라는 생각도 든다.
현대 프론트엔드 개발에서 리액트는 필수적이다. 꼭 필수까진 아니더라고 대부분의 기업이 채택하고 있는 현 상황에서 리액트를 사용하지 않으면 상당히 불리해질 우려가 있다.
아래에 링크를 올려두었다.
