코드노트

WIL 프론트엔드 + 백엔드 팀 프로젝트 회고 본문

Code note/TIL, WIL

WIL 프론트엔드 + 백엔드 팀 프로젝트 회고

코드노트 2023. 5. 19. 03:12

완성된 사이트 mockup

 

개인프로젝트 이후 이번 프로젝트는 2023.05.01 ~ 2023.05.15 2주간 진행했다.

이번 팀프로젝트는 프론트엔드와 백엔드가 같이하는 프로젝트였다.

 

개인프로젝트 회고는 추후에 따로 남기도록해야겠다..리팩토링도 진행해야하는데 시간이 부족하다..

 

이번 프로젝트도 팀장을하게되었다. 부족하지만 잘따라와준 팀원들 너무 고생했다..

 

GitHub - kjungit/smash-teams-FE

Contribute to kjungit/smash-teams-FE development by creating an account on GitHub.

github.com

 

백엔드와 협업은 처음이였고. 생각했었던것만큼 쉽지않았던것 같다.

처음이기도 했지만 기획 디자인부터 시작해서 처음부터 같이 시작하다보니

백엔드가 구현되고나서 API연결을 할수있었다보니 더 그랬던것 같다.

 

 

주제는 연차/당직을 관리하는 협업툴이였다.

캘린더를 사용해야했고,

기능은 로그인, 회원가입 jwt token 사용, 개인정보 수정, 연차/당직 등록, 관리자 계정으로 권한설정 등이였고

기능들을 녹여낼 수 있도록 백엔드와 회의전 프론트엔드 팀들과 와이어프레임을 진행했다.

 


기획 및 컨셉 UI/UX

- 백엔드분들은 UI에 대해서 관심이 없을 줄 알았지만

의견들도 내주셔서 정해진 틀에서 변경을 하면서 어느정도 마무리작업이 진행되었다.

- 와이어프레임과 기능들을 정리하고 기본틀을 잡은 후 UX/UI를 먼저 진행하기로했다.

- 필요한 API명세서는 백엔드와 협의전 프론트엔드에서 정리를해보기도했다.

 

 

정해진 이번 프로젝트의 UI/UX

프로젝트 서비스명은 팀원중 한명이 SMASH라는 이름으로 연차때려!라는 말에서 시작하여 아이디어가 도출되었다.

 

그에 맞게 로고도 쉽게 나오게된거같고 이름에 맞는 컬러를 선택하여 디자인작업은 무리없이 진행되었다.

 

전공이였던 디자인..디자이너로 일하였던 경험이 프론트엔드로 전향을 준비하면서 도움이될까? 라는 생각을 많이 했었는데..

uxui디자이너들과 협업을 하는건 파이널뿐이다보니깐 그 이전 작업에서는 디자인도 직접해야하다보니 큰 도움이 되는거 같다.

팀원분들께서도 믿고 맡겨주셔서 더 자유롭게 할 수 있었던거같다.. 항상 잘한다잘한다 해주시던 팀원분들 감사합니다..

 


기술스택

리액트를 사용하였고, 타입스크립트를 사용하였다.

next..는 이번프로젝트에 맞지않다고 판단했다. 규모가 그렇게 크지않았고, 라우터도 리액트라우터로 충분하다고 생각했다.

번들러는 vite를 사용했다. 빠르고 좋다..

 

- 가장 문제가 되었던건 상태관리툴

 

첫번째 멘토링에서 리덕스를 사용하는게 어떻겠냐는 이야기가 나왔고 우리는 리액트쿼리를 사용할거라고 대답을했다...

그래서 왜 리액트쿼리를 사용하려고하냐는 질문에서 우리는 제대로 답을하지 못하였다...

 

React-Query와 Zustand의 차이, 사용하는 목적 정리

리액트를 하면서 항상 고민하게되는 부분은 상태관리인거 같다. 이번 팀 프로젝트를 진행하면서 리덕스를 사용하지않고 ReactQuery와 Zustand를 통해 상태관리를 하기로 하였다. 두 상태관리 라이브

codeno-te.tistory.com

그렇게 정리한 글.. 어느정도 상태관리 기술스택을 정할때 기준을 어떻게 잡아야할지 감이 잡히는거같다.

우리는 대부분 데이터들을 서버데이터를 사용했다.그렇다보니 리덕스를 사용하기에는 늘어나는 보일러플레이트를 감당할 자신이 없었다.

프로젝트 기간에 있어서도 가장 컸던거 같다. 기획부터 시작을해야했고 백엔드와의 협업을 하다보니 API도 늦게나오는데 2주도안되는 시간동안 API로직을 리덕스로 작성하고 스토어로 관리하려니 맞지 않다고 느껴졌다.

 

그렇게 제대로된 대답을 한 후 멘토님께서도 2차 멘토링에서 리액트쿼리를 사용할만한 이유가 충분하다고 대답을 해주었다.

 

그리고 클라이언트 상태관리는 zustand를 채택했지만 딱히 사용할곳이 없었다.

여담이지만 유저정보를 zustand를 통해서 관리하려했지만 새로고침을 하게되면 리셋이되어버리는 이슈가 발생했다.

로컬을 사용할까?도 생각했지만 유저정보를 로컬에 저장하는건 음..아니야 용납이 되지 않았다..

리액트쿼리를 통해서 토큰을 통해 서버로 계속 요청을하여 유저데이터를 사용할수있도록 로직을 구성하기로 했다.

 

- 여기서 발생한 문제

- 유저데이터를 로그인을 하게되면 서버에서 받게된다.

- 유저데이터를 로컬에 저장하지않으니 새로고침을하게되면 그이후에 유저정보를 받으려면 API요청을 해야하는데 내정보를 받을때 백엔드에서 path값에 유저id를 넣어서 요청하게 API를 설계하였다.

- 새로고침 이후에는 유저 id를 모르기때문에 요청할수가 없었다. 그래서 백엔드측과 상의후 API를 수정하여 토큰으로만 검증 후 유저정보를 받게 변경하여 새로고침이되더라도 유저정보를 다시요청하여 사용하는 방향으로 로직을 구성하였다.

 

그래서 결론은 서버 데이터 = 리액트쿼리, 클라이언트 데이터 = 주스탄드!

 


API.. feat.MSW

어떻게 보면 이번 프로젝트를 하면서 가장 많이 꼬였던 문제중에 하나이다.

API명세서의 기본틀을 받아서 더미데이터를 사용하여 프로젝트를 진행하고 싶었지만

백엔드분들에게 정해진 API명세서를 받기에는 조금 무리였었나보다.. 수정이되더라도 어느정도 기본의 명세서는 받고싶었다..

다른팀들은 API문서를 다 받고 진행한다는 이야기를 듣고 부러웠지만..

그래도 팔은 안으로 굽는다고..우리 백엔드분들의 마음을 이해하려했다..

 

처음 작업해본 MSW...MSW가 필요한가? 라는 생각을 자주했었다.

그냥 json사용하면 되지 않아...?라는생각을 했다..

이번 프로젝트로 MSW의 중요성을 많이 느끼게된것 같다.

백엔드에서 API가 언제나올지 모르기때문에..프론트에서 언제까지 기다릴수가 없다..

그렇다면.. MSW를 통해서 더미데이터를 만들고 API명세서에 맞도록 세팅하고 사용하니깐 정말 좋았던거 같다..

 

앞으로 개인프로젝트를 진행하더라도 꼭 사용할거같은 느낌..? 그래도 큰 규모의 프로젝트에서는 그 모든 서버코드를 짤 자신이 없다..

 

개인프로젝트는 백엔드도 express로 서버를 구현한 경험이있다보니깐 MSW를 사용하는데 큰 어려움이 없었던거 같다..!


그리고 계속 바뀌는 API 와 axios error...

백엔드에서 처음에 줬던 API에서 응답데이터 및 path값이 계속 바꼈다.

백엔드도 코드가 수정되다보니깐 그럴수 있지만 정해진 path값이 바뀌다보니깐 MSW로 작성했던 부분들의 코드들도 API가 확정되었을때 API로직들도 전부 변경했어야했다..

 

이번 팀프로젝트를 하면서 백엔드와의 소통이 중요하다는걸 느낀부분인거 같다.

백엔드에서 배포한 API가 제대로 안되는부분들을 바로바로 이야기하고 백엔드분들은 바로 바로 수정을하며

업데이트 해놓은부분들을 피드백해주었다.

그렇게 마지막까지 소통을 했고 배포까지도 문제가 있었다.. 앞으로의 프로젝트에서는 백엔드들과 소통을 자주해야겠다..

사랑해요 백엔드..사이좋게 지내요..


재사용 컴포넌트

이번 프로젝트에서 재사용할 컴포넌트들이 여러가지가 있었다.

그렇다보니 조건부렌더링을 통해서 바뀌는 부분들을 활용했다.

 

페이지의 전체가 비슷한 컴포넌트들도 있었는데 컴포넌트를 재사용해야하는 경우를 어디까지 해야할지 계속 고민했던것 같다.

어느정도의 비슷한 UI라면 괜찮지만 들어있는 버튼들의 옵션들이 바뀌거나 사용하는 데이터의 형태가 다르다면

꼭 재사용을 하지않아도 되었고 조금이라도 다른점이 있다면 재사용하는 컴포넌트 기준이 전체가 되면 안된다는것도 멘토링을 통해서 알게 되었다. 컴포넌트를 세분화시켜서 재사용하는 컴포넌트를 만드는게 좋은거 같다. 아토믹..음..항상 고민되는부분이다..

 

- memo와 useCallback을 통해서 최적화에도 신경을쓰도록 했다.

- 필터링을해서 계속하여 props로 리스트들을 계속 내려줘야하는 상황이였고, 렌더링이될때마다 실행되지않도록 하였다.

- 프로젝트 기간에 맞춰서 진행하다보니 최적화 및 성능테스트를 비교해보지는 못했던게 아쉽다. 앞으로에 있는 팀프로젝트에서는 코드를 구현하면서도 성능을 비교해보고 코드를 비교해보며 기록하는 습관들을 길러야겠다.

 


예상치 못했던 이슈

- 백엔드 팀원 한분이 탈출하였다.. 회원가입, 로그인, 개인정보수정 부분을 맡은 분이 프로젝트 일주일을 남겨놓고 하차를 하셨다.

백엔드도 멘붕이왔고 우리 프론트엔드도 멘붕이왔다.. 애초에 API도 잘못된부분이 있었던터라 계속 소통중이였는데 그렇게되어버려서 백에드분들께서 파트를 나누어서 작업을 해주었다.

 

- 프론트엔드에서도 구현하는데 조금 어려워하는 팀원이 있었다. 그부분을 미리 알고있었고, 나도 최대한 작업을 빨리 진행한 후 팀원과 함께 작업을 하며 진행을 하려했다. 그러나 생각보다 작업일정이 늦춰지고 API이슈들이 생기다보니 내작업시간도 오래걸리게되다보니 같이 진행하는게 조금은 어려워졌다. 로그인 회원가입부분들까지는 같이 로직을 짜고 내가아는선에서는 설명을 해주며 진행하였지만 마감기간이 다가온 후에는 어쩔수없이 혼자서 로직을 구현하게 되었다. 팀원한테도 미안했지만 프로젝트를 마무리하는게 최우선이였기에 어쩔수 없는 선택이였다. 그래도 끝까지 포기하지않고 팀프로젝트에 참여해준 팀원에게 고마움을 느낀다..!


배포 http vs https

하루를 남겨놓고도 백엔드에서 제대로 작동하지 않는 API때문에 백엔드와 수정..수정..또 수정..

그리고 밤을 새며 8시간을남겨두고 우리는 배포를 하려했다..

netlify를 사용해서 프론트 배포를 진행했는데

백엔드는 http였고 netlify를 사용해서 배포하다보니 프론트는 https로 배포가 되었다.

 

이부분에서 AWS로 배포를해야하나..?라는 생각을 했지만 백엔드에서 https로 변경해주겠다고 했다..

너무너무 감사했다ㅠㅠ.... 그렇게 기다리고 기달려서 https로 재배포를 해준 덕분에 프로젝트는 잘 마무리할 수 있었다.


팀프로젝트 후기

- 백엔드와 협의를 하면서 하는 프로젝트를 기대했었는데 백엔드 팀원들도 제대로 구현을 해주었고,

여러가지 이슈들이 있었지만 유종의 미를 거둔거같아서 기쁘다.

- 프로젝트를 하고나면 언제나 아쉬운점들이 많은것 같다.

- 프로젝트를 하면서 신경써야하는것들이 시간이 지나면서 더 많아지는것 같다. 아는것들이 많아져서일까..?

- 성장하는만큼 더 좋은코드를 작성하려고 노력하고 협업에 있어서도 소통에 있어서도 부족하지않도록 더 많은것을 알아야할것 같다.

- 이제 PM + UX/UI디자이너 + 프론트엔드 + 백엔드와 함께하는 파이널 프로젝트가 기다리고있다. 정말 기대가된다..

 

- next.js 공부하러 가야겠다..