웹 캘린더 포트폴리오 만들면서

1. 프로젝트를 시작한 이유

• 윈도우의 DesktopCal 이라는 프로그램을 통해서 일정을 관리하고 있었는데, 일정들이 다른 기기들과 공유되지 않아 불편함을 느껴서 프로젝트를 시작하게 되었다.
• 그리고 이전에 만들었던 포트폴리오가 제출하기엔 부족하다고 판단되었기 때문이다.

 

2. 사용한 기술 스택

1. Vite
   1. 이번 포트폴리오에 처음으로 사용했다. CRA보다 빠른 자바스크립트 툴이라고 해서 사용해보게 되었다.
   2. 처음 사용해보는 툴이라 사용하기에 망설였지만, CRA로 개발했던 프로젝트보다 빠르다는 느낌을 받아 사용해보기 잘했다는 생각이 들었다.
2. React
   1. 이전 직장에서는 Vue.js를 사용했었다. Vue.js 보단 React가 더 많은 개발자들이 사용하는 언어라고 생각되어 이번 프로젝트에선 React를 선택했고, 앞으로도 React로 개발을 진행하려고 한다.
   2. Vue와의 차이점은 자유도가 많이 높았다는 것이었다. 프레임워크인 Vue는 Vue가 만들어놓은 템플릿에 맞춰서 사용해야해서 처음엔 편했지만 개발을 진행할수록 내 맘대로 할 수 없는 점들이 많아 답답함을 느꼈다. 예를 들면, 간단한 컴포넌트인데도 불구하고 템플릿을 따라야 한다던지, Props를 다루기 위해서 부모와 자식 컴포넌트에서 사용해야하는 코드들이 많아진다는 등의 불편한 점이 있었다. React는 컴포넌트에 Props값만 넣어주면 자식 컴포넌트에서 간단하게 사용할 수 있었다.
3. Typescript
   • Typescript는 사용하면 할수록 장점이 많다고 생각하여 이번 프로젝트에도 사용하게 되었다. 개발을 진행하면서 오류를 컴파일 단계에서 감지할 수 있다는 점과 코드를 이해하기 쉽게 만들어 준다는 점이었다. 공통적으로 사용될 상태값이나 변수에 타입을 설정하여 어떤 컴포넌트에서 사용해도 쉽게 오류를 찾을 수 있었다.
4. Recoil
   1. 이번 포트폴리오에 처음 사용했다. 포트폴리오를 시작하기 전에 TDD에 관련된 강의에서 Recoil을 사용하여 강의를 진행하셨다. 이 때 사용했던 Recoil이 Redux보다 사용하기 편해보여서 이번 포트폴리오에 적용시켰다.
   2. 많은 기능을 사용해보진 않았지만 Redux와 비교해보면 상당히 편하게 사용할 수 있었다. Redux의 경우, 사전에 작성해야하는 코드들이 있었다. slice, reducer, actions 등과 같은 코드들을 미리 작성해야만 온전하게 Redux 상태 관리 라이브러리를 사용할 수 있다라는 느낌 때문에 엄청 어렵게 느껴졌고, 배우는데 오랜 시간이 걸렸다. 현재도 다시 사용하라고 하면 헤맬 것 같다. 
   3. 하지만 Recoil의 경우, state 값만 atom으로 선언해두기만 하면 어디서든 간편하게 사용할 수 있었다. 심지어 RecoilValue, setRecoilValue와 같이 state 값만을 사용할 것인지, setState만 사용할 것인지 분리하여 사용할 수 있다는 점이 가장 인상깊었다. Redux는 state 값을 변화시키기 위해선 action을 보낸 후, reducer 에서 값을 정리해서 상태를 관리했기에 Recoil이 더 간편하게 state 관리를 할 수 있다고 생각했다.
5. Emotion
   1. 스타일들의 재사용성 때문에 채택했다. 이전 프로젝트에선 Styled Compoents를 사용해봤는데, 크게 차이는 없었다. 
   2. 그래도 Emotion의 장점은 css prop에 있다는 생각을 했다. CSS는 공통으로 사용해야 하지만 버튼의 개수나 자식 컴포넌트에 의해  css를 여러 개 작성해야 할 때, props를 이용해서 css 를 관리한다는 점이 좋았다.
6. Firebase

 

3. 프로젝트를 하며 느낀 점.

• 약 한 달 정도 걸린 것 같다. 처음 프로젝트를 시작할 땐, 최대한 많은 기능들을 넣고 싶은 욕심이 있었다. 하지만 막상 시작하니 로그인 기능을 만드는데도 오랜 시간이 걸리는 나를 보면서 '아직은 그럴 실력이 아닌가' 라는 생각을 했었다. 그래도 한 가지씩 기능을 넣으면서 페이지가 만들어지는 걸 보면 뿌듯하긴 했다.
• 처음 사용해보는 기술 스택들이 많아 어려웠던 점도 있었다.
  • Recoil은 ' 이거 완전 useState 랑 다를 게 없네!' 라며 RecoilState 를 남발했었다. 그러다보니 점점 코드가 더러워진다는 느낌을 받아 공식문서에서 하나씩 찾아보면서 했던 기억이 난다. 
  • Emotion에서도 css props 기능도 신기했다. 
  • Vite에서 Github로 배포하는 과정도 어려움이 많았다. Github actions를 통해 자동 build와 deploy까지 해서 그런지 오류가 많이 발생했다........ 배포하는데 몇 일은 걸렸다. 이 에러 관련해서는 다른 글에서 다뤄보려고 한다. 나중에 내가 또 덜 고통받게 하기 위해서
• 추상화와 재사용성을 엄청 신경써서 만들려고 노력헀지만, 잘 된건지 모르겠다. 페이지에서 콘솔 창을 켜놓고 input에 글자 하나 입력했을 때, 온 페이지가 깜빡이는 걸 보고 정신이 혼미해졌었다. 나름 추상화했다고 생각했고, 여기서 어떻게 더 줄이겠어라고 생각했었다. 쓸데없이 리렌더링 되는 부분을 어떻게 하면 줄일 수 있을까에 대한 고민을 좀 더 해볼 수 있는 좋은 기회였다고 생각한다. 
• 완성된 프로젝트를 보면서 그래도 이 정도면 깔끔하고 이쁘게 나온 거 같은데 라는 생각도 들지만 아직 많은 기능도 없고 포트폴리오로 부족한게 아닌가 라는 생각도 든다. 지금도 추상화나 컴포넌트 재사용성 부분에서는 부족한 점이 많다고 생각된다. 하지만 앞으로 취업 후에 프로젝트를 진행하면서 이런 부족한 점들은 채워나가고 개선해 나갈 수 있을 것 같다. 왜냐하면.... 테스트 하면서 깜빡이는 걸 보면 참을 수가 없기 때문이다. ^^;;;
• 그래도 내가 할 수 있는 최선을 다해서 만든 프로젝트여서 그런지 애정이 간다. 앞으로 추가하고 구현하고 싶은 기능들이 많다. 하나씩 취준하면서 추가해봐야겠다. 취업 후에도 시간이 남는다면 추가해야겠다.

 

4. 프로젝트 주소

• 프로젝트의 Github 주소 : https://github.com/taehankim-dev/DiaryWebService

GitHub - taehankim-dev/DiaryWebService: Diary

• 배포된 프로젝트의 주소 : https://taehankim-dev.github.io/DiaryWebService/

오늘의 할 일