새로운 레벨 시작
2주간의 방학이 끝나고 레벨3기간이 시작되었다 ❤️🔥
이번 주는 첫 주여서(?), 이벤트도 많고 할 일도 많았기 때문에 정신없이 지나갔다.
첫날에는 레벨 인터뷰를 했어야 했다.
레벨 인터뷰에서는 레벨 1,2 기간동안 공부한 것을 인터뷰 형식으로 확인하는 과정이다.
레벨 2때에는 기술 인터뷰 관련 경험이 없어서 많이 떨렸었는데
이번에는 그래도 한번 경험을 해봤다고 긴장은 덜 되었다.
그래도 5시간이 넘는 인터뷰는 힘들었다ㅠㅠ
그리고 UX 특강(총 이틀!!)도 들어야 했어서, 코딩을 할 시간이 절대적으로 부족했다. 결국에는 이번 주에는 코딩을 하나도 하지 못하고 보내고 말았다ㅠ
공식
이번 레벨 3때에는 프론트와 백엔드로 이루어진 팀별로 아이디어를 가지고 서비스를 개발해야 한다. 사실상 우테코에서의 제일 메인 이벤트이다.
아이디어와 기술스택을 팀별로 자유롭게 선택하면 되는 것이였기에
내가 해보고 싶었던 것을 할 수 있는 기회이다.
그래서 아이디어 선정에도 기술 스택의 선정에도 많은 고민이 되었다.
어떤 아이디어를 하냐에 따라서 백엔드도 프론트 엔드도 얼머나 시간을 투자해야하는지, 어떤 기술을 써야할 지도 달라질 것이기 때문이다.
그래서 방학기간인 2주동안 3번정도 팀별로 회의를 해야만했다.
아이디어 선정에 오랜 시간이 걸렸다.
결국, 우리 조의 아이디어는 우테코 지식인이 되었다.
상태관리를 어떻게 할까? 🗂
리액트로 개발하는 것은 고정이 되어있었지만,
리액트의 상태관리를 어떻게 할 것인 지는 직접 정해야했다.
리액트 상태관리 선택지들에는
Context API, Redux, Redux Toolkit, Recoil, Mobx 등등이 있었다.
이 중 Context API 와 Redux의 경우 레벨2에서 미션들을 진행하면서 경험을 해보았다.
짧게나마 내가 느꼈던 장단점을 말해보자면
Context API는 따로 외부 라이브러를 설치하지 않아도 되었지만,
잘못 사용하면 상태 변화가 일어날때마다 내가 원하지 않는 전체가 재 렌더링되는 문제들이 발생하였다.
미션에서보다 규모가 커진 팀 프로젝트에서 재랜더링이 필요 없는 부분까지 계속해서 일어나게 된다면, 아무래도 속도 부분에서 마이너스가 될 수 있다.
Redux의 경우 초반에 개념을 익히는데 힘들었었다.
Redux자체에서 요구하는 룰에 따라서 상태관리를 해야했기 때문에 쳐야하는 코드양도 많았다.
그래도 어느 정도 익숙해지고 난 이후에는 오히려 요구하는 룰이 있다는 점이 나는 장점으로 다가왔었다.
상태관리 하는 것을 어떻게 구현 해야하지? 고민을 할 필요 없이 룰을 지키면서 따라가면 됐었다.
그럼에도 비동기 통신을 하는 로직까지 상태관리에 포함이 된다는 것이 마음에 들지 않기는 하였다. 이 로직 까지 분리 해버리고 싶다는 마음?
레벨 2 때 이런 고민을 가지고 있었을 때, 주변 크루들이나 코치분들에게 리코일과 리액트쿼리라는 것이 있다는 것을 알게 되었다.
리액트 쿼리가 비동기 통신과 캐싱에 유리하다는 정보를 알게 되었고
레벨2 방학때에, mat.zip이라는 토이 프로젝트를 진행할 때에 리액트 쿼리를 적용해보았다.
아주 간단한 GET 작업과 POST 작업이였는데도 편리함을 느낄 수 있었다.
우선, 리액트 쿼리에서 제공하는 옵션들이 많았다.
그중에서도 나는 isLoading과 isError , isSuccess가 마음에 들었는데
리액트 쿼리가 비동기 통신 중에 에러상황과 로딩 상황인지를 알려주어서 해당 케이스 별로 유저에게 다른 화면을 보여주기가 편리하였다.
앞선 Redux를 사용하였을 때에는, isLoading과 isError상태를 일일이 정의를 해서 관리를 해주었어야 했는데, React-Query에서는 그럴 필요가 없었다.
추가적으로 useInfiniteQuery를 활용하여서 무한 스크롤도 간편하게 구현할 수 있었다.
이렇게 리액트 쿼리의 장점을 토이프로젝트에서 느껴버렸기 때문에 레벨 3에서는 자연스럽게 react-query로 비동기 통신을 관리하기로 하였다.
전역상태관리의 경우, 페어와 합의하에 Recoil로 정하기로 하였다.
사실 Redux의 비동기 통신때에 불편한 점을 React-query를 통해서 어느 부분 해결하기 때문에 사용하여도 큰 문제가 없지만 특히 레벨2때 사용했기 때문에 익숙하기도 하다
하지만 프론트엔드 개발자의 도전정신? 이라고 해야할까
새로운 기술을 써보고 싶은 욕심이 들었다. 어떤 장점이 있길래 리코일을 사용하는 걸까? 라는 궁금증을 직접 경험을 하면서 해결해보고도 싶었다.
무엇보다 리액트를 만든 페이스북에서 만든 것 답게 사용 방법이 리액트 문법과 매우 유사하였다. 그래서 쉽게 배워서 사용해 볼 수 있을 것 같아 리코일을 선택하게 되었다.
UI/UX를 어떻게 할까? 🎨
UI/UX디자인의 경우 제일 신경쓰고 있는 부분 중 하나이다.
겉으로 보여지는 화면과 유저의 서비스 부드러운 사용경험이 서비스에 대한 평가의 대부분을 차지하고 있다. 우리가 수많은 은행앱들 중 토스를 선호하는 것도 사용자가 사용하기 편리한 UI를 가지고 있기 때문 아닌가
그리고 무엇보다도 우리와 같은 아이디어를 하는 조가 우테코 내에서 한 팀 더 있기 때문에 우리집이 더 사용하기 편해!!라고 열심히 유혹을 해야하는 강력한 동기도 있었다.
그래서 여러 UI 관련 영상을 등하교길에 열심히 찾아보았다.
그 중에서도 제일 마음에 들었던 영상은
이 것이다.
토스 팀에서 하고 있는 디자인 시스템 관련 영상인데, 이건 내가 개인적으로 코딩공부를 하면서 느꼈던 디자인의 중구난방을 디자인 시스템을 활용하여 해결하고 있었더.
예를 들어, 정해진 가이드라인이 없어서 버튼도 로그인 버튼, 글쓰기 버튼, 등록하기 버튼 등의 디자인들이 통일 성이 조금씩 엇나거나 콘텐츠들 마다 미묘하게 margin값이 다르거나 하는 등의 불편함이 있었다.
그리고 컬러들을 이름을 정할 때에도 애매한 부분들이 있다. 같은 보라색인데 opacity가 다른 경우라던지, 보라색 계열의 색들이 여러개 사용된다든지의 경우에 네이밍이 꽤나 난감했다.
해당 영상에서 primary fill , Danger weak 와 같은 색깔들의 네이밍 힌트들을 얻을 수 있었다.
이번 컴포넌트를 그릴 때에 영상에서 보았던 부분들을 최대한 반영하면서 그려보고 싶다.
열심히 하는 모습 칭찬해 ❤️🔥