프론트엔드
TypeScript
자바스크립트는 본래 웹사이트의 보조적인 기능을 위해 한정적인 용도로만 사용되는 언어였다. 하지만 시간이 지나면서 SPA 등의 기술을 통해 자바스크립트가 담당하는 업무가 늘어나게 되면서 과거에는 크게 문제되지 않았던 부분들이 문제가 되기 시작했다. 타입스크립트는 이러한 자바스크립트의 단점을 보완하기 위해 나온 자바스크립트의 상위 확장으로, 정적 타입을 지원하여 브라우저 런타임 단계가 아닌 컴파일 단계에서 오류를 잡을 수 있고, 디버깅이 쉬워진다.
-> 내가 이 프로젝트에 타입스크립트를 사용하기로 결정한 이유는 프론트엔드 개발에서 타입스크립트가 많이 쓰이기 때문이다. 하지만 많은 회사들이 타입스크립트를 채택한 이유가 분명히 있을 것이기 때문에 이번 프로젝트 기술 스택을 정하면서 겸사겸사 이유도 같이 알아보았다. 타입 지정 이외에도 여러 장점이 있지만 역시 정적 타입을 지원하는 것이 타입스크립트를 사용하는 가장 큰 이유인 것 같다.
React
일단 React를 사용하면 개발이 훨씬 편리해지고, 페이지 전환을 부드럽게 할 수 있는 등의 장점이 있다. 하지만 Vue.js가 아니라 React를 사용하기로 결정한 이유는 역시 커뮤니티의 크기때문이었다. Vue.js로 웹사이트를 만들어 본 적이 있는데 구글링을 했을 때 리액트에 비해서 얻을 수 있는 정보가 훨씬 적다고 느꼈었다.
Redux Toolkit
Redux, Recoil, Zustand 등 상태 관리 라이브러리의 종류가 여러가지인데, 최대한 다양하게 사용해보고 그 차이를 직접 알아보고싶었다. 이전 팀 프로젝트에서 Recoil을 사용했었기 때문에 이번 프로젝트에서는 Redux를 사용하기로 결정했다. 다만 Redux를 배울때 상태 관리 코드를 작성하는게 너무 복잡했던 경험이 있어서 코드를 조금 더 쉽고 효율적으로 작성할 수 있게 도와주는 Redux Toolkit을 선택했다.
React-Query
Redux Toolkit이 클라이언트 측의 전역 상태 관리를 담당한다면, react-query는 서버 상태의 관리를 담당한다. Redux만 사용할 경우 서버 데이터까지 관리하기는 어렵기 때문에 react-query와 함께 사용하면 클라이언트/서버 데이터의 분리가 가능하다고 한다.
백엔드
Node.js
자바스크립트로도 백엔드 코드 구성을 할 수 있다고 해서 백엔드 코드도 직접 구현해보기로 했다. 웹사이트는 프론트엔드와 백엔드가 함께 데이터를 주고받으며 구성되는 것인데, 반쪽을 모른채로 개발을 하려니 내가 코드를 제대로 이해하고 작성하고 있다는 생각이 들지 않았기 때문이다. 그렇다고 새로운 언어를 배우기엔 시간이 너무 오래 걸리니까 일단 Node.js로 시작해보기로 했다.
express
Node.js를 기반으로 한 웹 서버를 제작하기 위해 express라는 프레임워크를 사용한다고 한다. express가 프레임워크인줄 몰랐는데, 이번에 백엔드 코드 구현을 위해 공부하면서 알게 되었다. 파이썬의 Django 같은 느낌인가보다. 아무튼 express를 사용하면 서버를 더 쉽게 만들 수 있고 라우팅과 미들웨어 추가를 도와주어 더 편리하게 개발을 할 수 있다.
MySQL
관계형DB를 선택한 이유는 정해진 스키마를 따라 데이터가 저장되기 때문에 데이터 구조를 설계하기가 더 좋아보였기 때문이다. 아직 백엔드 코드를 작성해 본 적이 없어 미리 어떤 타입의 데이터를 어디에 저장하고 어떻게 서로 관계되는지 확실히 정해두는 것이 나중에 코드를 작성할 때 예상치 못한 문제가 생기는 것을 방지할 수 있을 것 같았다.
그리고 비관계형DB는 테이블에 들어갈 데이터를 잘못 나누면 데이터를 가져올때 여러번 쿼리를 해야하는데, 관계형DB는 데이터를 쿼리할때 서로 관계된 정보들을 묶어 원하는 정보들을 한번에 가져올 수 있다는 점에서 데이터 설계에서 실수가 있어도 그것을 커버할 수 있지 않을까 하는 생각을 했다.
MySQL은 관계형DB중에서도 많이 사용되는 데이터베이스라고 해서 선택했다.
그 외 (기술 스택이라고 하기엔 애매하지만 기록 남기는 것들)
Webpack
여태까지 진행한 모든 리액트 프로젝트는 cra로 진행을 했었다. cra를 사용하면 리액트 개발환경을 쉽게 설정해줄 수 있지만, 사용하지 않는 설정이나 라이브러리까지 포함이 되어있어 번들이 무거워지고 빌드 시간이 길어진다고 한다. 그리고 언젠가는 개발자로써 웹팩을 커스텀해야할 일이 있을 것이기 때문에 cra가 아닌 웹팩으로 프로젝트를 설정하기로 했다.
CSS Module
이전 프로젝트에서 Styled Component를 사용했었는데, 간편하고 여러 기능들이 있어 사용하기가 좋았지만 타입스크립트 파일 안에 css가 함께 들어있어서 코드가 너무 길어졌었다. Css 파일을 분리해서 쓰고 싶었는데 styled component보다는 css module이 분리해서 쓰기에 더 편리해 보여서 css module로 작업하기로 했다. 이번 프로젝트를 진행하다보면 어떤게 더 나한테 잘 맞고 편리한지 알 수 있을 것 같다.
