프로젝트 소개
일정 관리 서비스 Taskify
👉 Taskify 보러가기
👉 GitHub
👉 Team Notion
이번에 중급 프로젝트를 마무리하게 되었다.
프로젝트 기간동안 개발 실력 향상 뿐만 아니라 팀원들과 깃허브로 이슈관리, 코드리뷰, 일정 계획 등을 하면서 여러가지로 성장했다고 생각한다.
React, Typescript, Tailwind CSS, Jotai를 사용하였는데 각각의 기술 스택을 선택한 이유와 사용하면서 느낀점과 고민됐던 점들을 적어보려 한다.
Next.js 없이 React 만으로
아직 React의 기본기와 관련 라이브러리들에 대한 경험이 부족하다고 생각했다. 기초 프로젝트 때에 React를 사용하긴 했지만 hook이나 react-query, 공통 컴포넌트, 상태관리 등을 잘 활용하지 못했었다고 생각한다. 그래서 React에 대해 더 다양하고 깊게 다뤄보고 싶었기에 Next.js는 제외하고 React에 집중해보기로 결정했다.
Hooks
훅을 자주 만들어 사용했었는데, 고민되는 점이 있었다.
컴포넌트 내의 로직들을 전부 훅으로 빼주기 vs 필요한 로직만 훅으로 만들기
처음엔 후자의 방법을 사용해 코드를 작성하고 PR을 올렸었다. 하지만 팀원분이 "컴포넌트 내의 로직들을 전부 훅으로 빼주는게 어때요?"라고 제안하셔서 왜 그렇게 생각하셨는지 여쭤보니 UI와 로직의 분리를 위해, 그리고 그 편이 가독성이 좋게 느껴졌다고 말씀해주셨다
내가 분리가 필요하다고 생각되는 로직들만 훅이나 utils 폴더로 분리했던 건
- 작은 단위로 분리한 로직은 재사용성이 높아진다.
- 컴포넌트 파일 내에서 컴포넌트가 어떤식으로 돌아가고 있는지 명시적으로 보여주는 편이 남이 내 코드를 읽을 때도, 내가 나중에 내 코드를 읽을 때도 이해가 쉽다.
고 생각했기 때문이다.
이 부분에 대해서 팀원들과 얘기해 보았지만 어떤 방식이 더 좋을지에 대한 명확한 결론은 나지 않았다(어쩌면 케바케일수도 있겠다). 그래도 코드의 일관성 측면에서 의견을 취합하는 것이 낫기 때문에 전부 훅으로 분리해주는 방식을 사용해보기로 했다.
새로운 방식을 직접 경험해보는 것도 좋은 경험이 될 것이라 생각했다. 그리고 후에 멘토님께도 의견을 여쭤볼 생각이다.
react-query
이번에 리액트 쿼리를 본격적으로 사용해본 것은 처음이었는데 매우매우 편리했다..👍
특히 쿼리키를 사용해 원하는 부분만 데이터를 최신화 해주는 것이 너무 스마트하게 느껴졌다..
하지만 여기서도 의문이 들었던 것이 있었다.
데이터 최신화를 원할 때
invalidate과refetch중 어떤걸 사용해야 할까?
이 고민에 대해선 후에 블로그에 포스팅 후 링크를 남겨두겠다.
결론은 refetch를 더 자주 사용했지만 각각 필요한 부분에서 사용하는 방식으로(성능상의 이점을 챙길지 아니면 매끄러운 UI에 중점을 둘 것인지, 어떻게 stale을 고려하며 fresh한 데이터를 언제 어디에 사용할 것인지 등을 생각하며) 리팩토링 해봐야겠다.
Typescript
타입스크립트는 처음 배울 때는 적응도 어렵고 일일히 타입을 지정해주는 것이 귀찮기도 하다고 생각했다. 하지만 타입을 명시함으로써 예측 가능한 코드를 쓰고 읽는게 이제는 좋게(편리하게?) 다가왔다. 특히 api 관련 타입들을 미리 지정해주니 교통정리가 되는 느낌이었고 팀원들의 코드를 볼 때도 훨씬 읽기 수월했다. 또 변수에 넣을 값을 미리 타입으로 지정해둘 수 있는 것도 공통 컴포넌트에서 활용하기 용이했다.
Tailwind CSS
Tailwind CSS를 선택한 데엔 아래와 같은 이유가 있었다.
- Tailwind CSS는 자바스크립트를 사용하는 styled-components와 달리 정적 CSS 클래스를 사용하기 때문에 런타임 성능 향상을 기대할 수 있다.
- Tailwind CSS의 정적 스타일 시트는 브라우저 캐싱에 유리하고, 빠른 로딩 시간을 제공한다. 반면 styled-components는 런타임에 스타일을 생성하기 때문에 캐싱 전략이 어렵다고 한다.
- 추가적으로 Tailwind CSS의 정적 CSS가 SSR 환경에서도 효율적이어서 Next.js와 찰떡이라고 한다.(심지어 Next.js 공홈에서도 Tailwind CSS의 사용을 추천하고 있다.)
때문에 많은 기업에서 SSR을 도입하며 Next.js로 마이그레이션하는 요즘 자연스럽게 같이 자주 사용되는 Tailwind CSS도 미리 경험해둘 필요가 있다고 생각했다.
사용해본 솔직한 후기는 아래와 같다.
장점
클래스명 짓기 부담감 0- CSS 파일이 없어서 더 깔쌈함
- 성능향상?은 솔직히 아직 체감 못했다..
- 어떤 부분에 어떤 스타일이 적용되었는지 직관적으로 확인 가능
- 협업하는 사람들도 정해진 규칙을 사용하기 때문에 머릿속에 물음표(?)가 뜰일 없음
단점
- 가독성 떨어짐
- 반응형 구현 어질어질함
클래스명이 없어서 뭐하는 놈인지 바로 파악이 안됨(멘토님께서 말씀하시길 Tailwind에서도 클래스명을 적어주면 좋다고 하셨다. 이건 이 방법으로 해결이 될 듯 하다.)- 동적 스타일링 시 safeList 설정이나 스타일을 객체나 배열 형태로 변수에 넣어주는 등 뭔가 한 번 더 거치는 과정이 은근 맘에 안듦
- style도 prop으로 받아오는 경우가 생김
개인적으로는 장점보다 단점이 더 많게 느껴졌다..
물론 Tailwind CSS를 제대로 잘 사용해봤나?를 생각하면 그건 아닌 것 같아 무조건 별로라는 것은 아니다.
좀 더 커스텀을 잘 해주었다면 오히려 단점으로 느껴졌던 것들이 보완되며 다르게 느껴질지 모르겠다. 이 부분은 좀 더 경험과 공부가 필요할 것 같다.
🍀 회고
이번 프로젝트를 진행하며 치명적인 에러나 이슈는 없었지만 많은 것들을 느끼고 경험했다.
처음에 팀원들과 의지에 불타 목표를 이것저것 세웠지만(react-query/hook/공통 컴포넌트 잘 다뤄보기, 타입스크립트/테일윈드 익숙해지기, 깃허브로 프로젝트 관리, 코드리뷰 꼼꼼히 하기 등), 막바지에는 거의 시간에 쫒기며 프로젝트를 마무리해서 PR 리뷰도 초반처럼 꼼꼼히 하지 못하고 목표했던 기능들을 구현해내는 데에 집중했다. 마냥 의지만 앞서는게 능사가 아니라 프로젝트 일정 계획에 러닝커브 고려와 시간 내 구현 가능 여부 판단 등 현실적인 문제들을 고려하는 것도 매우 중요하다고 느꼈다.
그리고 리액트 기본기의 중요성도 다시금 느꼈다. 조만간 리액트에 대해 제대로 공부해보는 시간을 가져야겠다.
이번에 여러가지로 직접 부딪혀보고 팀원들과 적극적으로 소통하며 개발적인 부분 뿐만 아니라 "협업"을 넘어 "같이 해나가기"에 대해 많은 생각을 해보게 되었던 것 같다. 팀원들 모두 처음부터 끝까지 열정적으로 열심히 하는 모습 속에서 태도와 열정도 많이 배웠다. 앞으로도 이런 경험을 마주할 기회가 자주 찾아오면 좋겠다.
