주어진 Source
FE 개발자: 2명
개발 기간: 최대 6주
사용되는 라이브러리: React
선택한 기술 스펙: TypeScript SWR Recoil Styled-Components
TypeScript?
동적 언어인 JavaScript에서 런타임에서 발생하는 에러를 로컬 환경에서 미연에 방지하고, 좀 더 strict 하게 타입을 정의하면서 정적 타입 언어로 변경시켜줍니다. 즉 타입 가드 등을 통해 JavaScript에서 발생할 수 있는 에러를 미연에 방지해 주기에 선택하게 되었습니다.
상태관리 라이브러리 선택과 그 이유
프론트엔드 상태 관리에는 크게 3가지 상태 관리가 존재
- 로컬 상태 관리 (컴포넌트 단위에서 관리하는 상태)
- Global 상태 관리 (프로젝트 내부에서 관리하는 상태)
- 서버 상태 관리 (서버와 통신하면서 관리하는 상태)
총 3가지 상태를 관리해야 합니다. 로컬 상태 관리의 경우 useState와 같이 react의 내장 hooks으로 관리할 수 있습니다. 이제 대두되는 것은 Global 상태 관리와 서버 상태 관리인데 상태 관리 라이브러리에 Mobx, Redux, Recoil 총 3가지 후보군을 선정했습니다.
3개의 후보군을 놓고 고민하던 도중 서버 상태 관리 라이브러리를 따로 선택하자는 주장이 있었고, React-Query 혹은 SWR 둘 중 하나를 선택해서 서버 상태 관리를 하자는 이야기가 나왔습니다.
각각의 특성을 보면 다음과 같습니다.
React-Query
React Query는 리액트 애플리케이션에 서버 상태를 가져오고, 캐싱하고, 동기화하고, 업데이트하는 것을 쉽게 해 준다.
- 커스텀 활용도가 높음
- 파일 자체가 무거움
- 업데이트에 특화됨
- 영어문서
SWR
SWR은 먼저 캐시에서 데이터를 반환한 다음, 서버에 데이터를 가져오는 요청을 보내고, 마지막으로 최신 데이터를 제공하는 전략이다.
- fetch에 특화됨
- 사이즈가 작음 (빠름)
- 캐싱 우선
- 한글 문서
즉 React-Query는 라이브러리가 크고 무거운 대신에 다양한 기능이 존재했고, 업데이트에 특화된 기능이었습니다. 반면에 SWR은 사이즈가 작지만 fetching에 특화되어 있는 라이브러리입니다. 즉, 동적으로 비동기 데이터 통신이 많이 일어나는 서비스의 경우 React-Query가 좀 더 유리하겠지만, 학생들의 성적 관리와 조회 등 대부분의 기능이 정적인 저희 서비스 특성상 좀 더 빠르게 클라이언트에게 정보를 보여주고자 SWR을 선택하게 되었습니다.
서버 상태 관리 라이브러리를 선택하고 나니 저희에게 필요한 것은 Global 상태 관리 라이브러리밖에 없었습니다. 각각의 특성을 비교하면 다음과 같습니다.
Redux
- 전통의 상태관리 강자
- 상태관리가 전부 read only이다.
- 보일러 플레이트 코드가 많아서 러닝커브가 존재한다.
- 대규모 프로젝트에는 용이할지 모르지만 중소 프로젝트에서 사용하기에는 너무 과한 면이 있다.
Recoil
- atom 설정 방식이 React의 useState와 유사하여 적응하기 쉽다. (간단한 구조를 가지고 있따)
- selector를 통해 비동기 처리가 어느정도 가능하다.
Mobx
- java 기반
- 객체지향 가능
- observable을 기본적으로 사용
- 캡슐화 가능
프로젝트의 규모가 작고, 개발 기간이 많이 남지 않은 상황에서 러닝 커브가 높고 체계적인 라이프 사이클을 가지고 있는 Mobx나 Redux의 경우에는 좀 더 큰 규모의 프로젝트에 어울리는 상태 관리 라이브러리라 생각했습니다.
반면에 Recoil의 경우 React Hooks와 쓰임새가 유사한 친 React 적인 라이브러리이고, 상태 관리 라이브러리의 쓰임이 전역 상태 관리로 제한되어 있기 때문에 Recoil의 선택이 좀 더 합리적이라 생각했습니다.
SCSS vs Styled-Component
CSS 관리 라이브러리도 2개의 후보군이 있었습니다. 각각의 특성을 정리하면 아래와 같습니다.
styled-components
- css in js → 렌더링 될 때마다 코드를 불러오게 됨. 즉 동적인 움직임이 많다면 렌더링 되는데 시간이 많이 걸리기 때문에 단점이 될 수 있음
- 컴포넌트의 상태 값이 변화했을 때 반응하기 쉬움
sass
- css in css → css 전처리를 하기 때문에 js 파일과 분리되어 있음.
- 컴포넌트 상태 값 변화에 따른 반응이 어려움
학생들의 데이터와 시험 데이터를 시각화해서 나타내는 기능이 주 기능인 저희 프로젝트 특성상, 컴포넌트들이 상태 값의 영향을 많이 받고, 동적인 움직임이 많지 않기 때문에 sass보다는 styled-components를 선택하게 되었습니다.
프론트엔드 아키텍쳐
https://velog.io/@teo/MVI-Architecture
상태관리에 대한 각각의 소고
https://techblog.woowahan.com/2599/
https://ridicorp.com/story/how-to-use-redux-in-ridi/
https://recoiljs.org/ko/docs/introduction/getting-started/
https://ko.redux.js.org/understanding/thinking-in-redux/glossary
서버 상태 관리에 대한 비교글
https://tech.madup.com/react-query-vs-swr/
https://tanstack.com/query/v4/?from=reactQueryV3&original=https://react-query-v3.tanstack.com/
styled-component vs sass
https://velog.io/@qksud14/portfolio-05#결론
https://styled-components.com/docs/basics#installation
