[MIL] 프로그래머스 프론트엔드 데브코스 5기 한 달 회고 4편

한 달동안 팀프로젝트를 하면서 정말 많은 것들을 배웠다.

배운 것들을 정리하고 느낀점을 써보려고 한다!

 

무엇을 배웠나?

1.TanStack Query v5
2. React
3. Tailwind CSS
4. Axios
5. axios 인스턴스와 인터셉터
6. git rebase
7. GitHub Flow 전략
8. 타입스크립트

팀 프로젝트를 진행하면서 사용하고 배운 것들이다.

처음 써보는 것들도 있었고,

이전에 써봤지만 사용하면서 많이 배운 것 같았다.

 

 

배우고 나서 부족하거나 보충이 필요하다고 생각하는 부분은?

1. 리액트 쿼리..좋으면서 어려운 녀석

리액트 쿼리를 처음 써보면서 정말 많은 것들을 경험했다.

솔직히 말해서 리액트 쿼리는 정말 좋은 라이브러리였다.

비동기 요청을 할 때 정말 간편하게 사용할 수 있었다.

 

그리고 아주 다양한 기능을 제공했다.

useSuspenseQuery, useInfiniteQuery.. 등 

진짜 편리한 기능이 많았다.

근데 이런 기능이 있었다는 것을 잘 몰라서 활용을 못하고,

useQuery랑 useMutation만 사용했다.

처음에 리액트 쿼리를 사용하기 전에 좀 많이 공부했더라면 더 빠르게 프로젝트를 진행하지 않았을까 생각했다.

 

어려웠던 점은

리액트 쿼리를 사용하면서 처음에 isLoading 부분이 헷갈렸다.

이게 비동기 데이터를 요청하고 기다릴 때 사용하는 것인데

isLoading이 요청이 시작되면 true로 되고, 요청이 완료되면 false다.

근데 처음에 이 부분을 완전히 숙지하지 않고, 그냥 axios 쓰듯이 써버렸다.

그래서 undefined가 되고, 데이터를 못 갖고오고, 왜 그런지 이유를 찾지 못했었다.

 

지금도 사실 아직 완전히 이해하지 못해서 차근차근 다시 공부할 예정이다.

 

또 쿼리를 불러오면 캐싱을 하는데 처음에 사용할 때 이 부분을 완전히 이해하지 못했었다.

그래서 만약 최신데이터가 필요한 상황인데 계속해서 캐싱된 데이터를 갖고왔다.

근데 문제는 내가 리액트쿼리를 잘 몰라서 왜 이렇게 되는지 파악하지 못했다.

이후에 콘솔로그를 찍어가면서 이유를 찾게되었고, 

캐싱된 데이터를 쓰는구나를 알게되었다..진짜 멍청..

 

하여튼 리액트쿼리 열받아서 마스터할 것이다.

근데 공식문서에 기능별로 설명하는데 너무 짧다..ㅋㅋㅋㅋ

공식문서말고 블로그나 깃허브에 누군가 써놓은 글을 보고 배워야할 것 같다.

 

2. Tailwind CSS 너... 좋아 아니 안좋아 아니 좋아?

Tailwind CSS를 이번에 처음 사용해봤다.

다시말하면 사용은 해봤지만 그냥 찍먹만? 해봤다.

그래서 이번에 프로젝트에서 정말 제대로 사용해봤는데

정말 좋다가도 안좋다가도 좋았다.

스타일링을 할 때 정말 많은 기분을 느끼게했다.

 

먼저 좋았던 점은

클래스 이름을 따로 안 정해도 됐다!

이 부분은 정말 편했다.

그리고 기본적인 애니메이션을 제공해줬다.

특히 animate-ping이 좋았었다. 

사용자에게 알림이 왔을 때 동그란 원에서 ping 애니메이션이 추가되니 더 이뻤다.

그리고 빨랐다는 점이다.

원래 CSS In JS 를 사용하고 배포를 하면 뭔가 느리다는 느낌이 들었었다.

근데 이번에 배포를 하고 보니 엄청 빠르다는 느낌이 들었다.

마지막으로  다크모드가 지원된다는 점이다.

이 부분이 진짜 정말 좋았다.

다크모드를 맡아서 어떻게 구현하지 하고 있었는데

Tailwind에서는 정말 간편하게 쓸 수 있었다. 소리 질러~

 

이렇게 좋았던 점이 있었던 만큼 어려웠던 점도 있었다.

 

먼저 기본적인 명령어 숙지가 안되어있어서 시간을 많이 소모했다.

처음에 사용하다보니 스타일링 명령어를 처음에는 계속 공식문서를 보면서 사용했다.

그러다보니 하나 스타일링하는데 많은 시간을 소모했다.

 

두 번째로 keyframe을 사용해 애니메이션을 만들 때 className에서 작성하기에는 어려웠다.

그래서 global.css에 css방식으로 애니메이션을 작성하고 

tailwind.config.js에 등록해주고 사용해야했다.

이 부분이 처음에는 조금 복잡했다. tailwind.config.js에 등록하는걸 까먹어 왜 안되지하면서 몇시간을 썼다.

 

세 번째로는 twmerge의 한계가 있었다는 점이다.

우리가 스타일링을 할 때 small, medium.. 등 단위를 사용자 정의 클래스로 저장하고 사용했었다.

그리고 twmerge와 cva를 사용해서 더욱 간편하게 사용하고 있었다.

근데 사용자 정의 클래스를 사용한 값들은 이후 컴포넌트를 사용할 때 className으로 덮어씌워지지 않는 것이다.

그니까 즉 rounded-small을 먼저 사용하면 이후에 Tailwind의 단위인 rounded-full을 사용하면 적용이 안됐다.

또 text-primary text-xsmall을 하면 text-primary만 적용이 되었다.

text 저 문제는 특히 더 골치가 아팠었다.

둘은 폰트사이즈와 폰트 색상인데 적용이 안되는 것이다.

처음에는 왜 안되지 하면서 시간을 많이 소모했고, 이후 검색하면서 찾아냈었다.

twmerge 개발자가 이런 경우에는 "공식 문서의 예시를 참고하여 커스텀을 추가"하거나, "상수로 관리해서 tailwind에서 정의한 기본 속성 활용하기의 두 가지 방법" 을 제시했다고 한다.

우리는 일단 프로젝트 완성이 목표라서 사용자 정의 클래스를 일단 제외하고 사용했다..

 

네 번째로는 동적인 값을 사용하지 못한다는 점이었다,

이 부분때메 위에서 말했듯이 cva를 사용했다.

보통 mx-${size}와 my-${size}와 같이 스타일 값을 동적으로 만들어야할 때가 있다.
그러나 이런 접근 방식은 Tailwind CSS의 핵심 철학과 맞지 않았다.

Tailwind CSS는 일반적으로 미리 정의된 클래스를 사용하여 스타일을 적용하고, 동적으로 클래스를 생성하는 것은 이를 어길 수 있다.

그래서 컴포넌트를 재사용할 때 동적인 값들은 되도록 사용하지 못하도록 하고 만약 사용해야한다면 style 속성을 사용했다.

이 부분을 계속해서 고려해야 한다는 점이 어려웠었다.

 

이처럼 희노애락이 가득한 Tailwind 사용 후기였다.

근데 지금 생각해보면 Tailwind가 더 좋은 것 같다는 생각도 든다.

어찌됐건 Tailwind를 더 잘 이해하고 사용하면 장점이 아주 많은 것 아닌가?

이후 프로젝트할 때도 고려해봐야겠다고 생각했다.

 

---

 

 

사실 더 많은데 너무 길어질 것 같아서 가장 어려웠던 두가지를 얘기해보았다.

추후에 블로그에다가 프로젝트 기간동안 발생한 상황들을 정리해서 올릴려고한다.

내 과거 메모리가 이제 가비지컬렉터로 인해 없어지고 있기 때문이다.

 

 

한 달 동안 중요하다고 느낀 것?

음 이번에 중요하다고 느낀 것은

프로젝트를 할 때라던지, 컴포넌트를 만들 때라던지, 페이지를 만들 때라던지

어떤 것을 시작할 때 계획을 확실히 해야한다는 점이다.

즉, 뭐든 계획하고 계획을 적어놓자.

 

프로젝트를 진행하면서 예상치못한 상황이나 개발 후의 자잘한 버그가 계속 발견됐다.

시간이 점점 촉박하다보니 급하게한 이유도 있는데

일단 계획을 완벽하게 하지 못했다.

이를 방지하기 위해 처음에 issue에다가 요구사항이나 예외처리와 같은 부분들을 적었었는데

이것마저도 부족했다.

그래서 어디가 안맞고 예외처리가 안되고, 계속 버그가 발생했다. 젠장~

그리고 API 명세서를 제대로 확인하지 못해서 프로젝트를 계획하고나서 바뀐 부분들이 많았다.

그냥 이렇게 되겠지 하고 프로젝트를 계획한 것이었다.

하지만 원하는대로 되지않은 부분들이 있었고, 이건 내가 제대로 API문서를 잘 보지 못한 잘못이었다.

 

이를 통해서 진짜 개발할 때 issue에다가 계획이란 계획은 다 적어서 꼭 기억하고 개발해야겠다고 생각했다.

J로는 부족해서  IJ로 해야겠다.   I

                                                   J

 

변화한 점?

이번 팀 프로젝트를 통해서 많이 성장했다고 느꼈다.

리액트 쿼리라던지

Tailwind 라던지

CSS 스타일링이라던지

어떤 문제가 발생했을 때 해결하는 방법을 많이 터득했다.

에이 이건 어쩔 수 없어라고 많이 생각했던 과거와 달리

어떻게든 해결할 수 있어라고 많이 생각하게 됐다.

 

특히 이번에 회원가입 페이지를 만들면서

처음에 개발하고, 잘 작동됐었던 코드를 다 지우고

새로 만들었던 상황이 있엇다.

 

회원가입에 필요한 이메일, 사용자 이름, 패스워드 입력과 검증을 만들면서

뭔가 비슷하게 중복되고 있다는 느낌이 들었었다.

근데 이게 타이핑이 되면서 계속해서 검증을 해야했고,

이메일과 패스워드는 특히 다른 처리가 또 필요했다.

이메일은 중복확인이라는 기능이 있었고,

패스워드는 confirm패스워드와 같은지도 타이핑 될 때마다 따로 검증해야했다.

그래서 생각은 계속 '뭔가 중복되는데..' 했지만

어쩔 수 없이 3개의 input과 3개의 validation을 만들게 되었다.

그래서 이후 팀원분에게 이 부분에 대해서 중복을 없애면 어떨까하고 리뷰를 받았고,

나도 이 중복이 계속 생각나게돼서 바꾸려고 했다.

근데 처음에는 너무 복잡했다. 기존의 코드에서 바꿀려고 하니 어려웠다.

위에서 말했듯이 각각 다른 검증과 이 검증들이 다완료하면 보내주는 boolean값도 필요했다.

3개의 input의 타이핑과 검증이 싱크가 맞아야했다.(중복확인과 비밀번호 확인 검증까지도)

 

하지만 머리를 비우고 다시 생각하면서 기존의 코드는 안될 것 같다고 판단해서

코드를 다 지우고 다시 만들었다.

성공하든 말든 누구하나 죽자는 마인드로 하니까 결국 성공했다.

너무 기쁜 나머지 아래처럼 만들고 자랑을 했다.

암튼 중요한건 뭐든지 해결할 방법은 있다는 점이다.

사실 이것도 처음에 컴포넌트 개발 계획할 때 정확히 했으면 문제없었을 텐데..라고 생각했지만

이 경험을 통해 '나중에는 더 실수 안하게 되리라' 라고, 위안을 얻었다.

 

 

향후 계획 또는 다짐

일단 리액트, 리액트 쿼리를 집중적으로 공부할 계획이다.

그리고 혼자서 프로젝트도 하나 만들 예정이다.

혼자 만든 프로젝트가 하나 있어야 된다고 모든 멘토님들이 말씀하셔서 꼭 만들어볼 예정이다.

혼자 프로젝트 만들면서 계획을 꼭 제대로할 생각이다..