[MIL] 프론트엔드 데브코스 5기 (2023-12~2024-01) && 팀프로젝트 회고

2023...END

2023년이 끝났다.... 한살 더 먹었다....하하
연말이라 그런지 시간도 엄청 빠르게 지나갔다. 아마 내가 겪었던 12월중에 제일 빠르지 않았을까
심지어 현재 1월도 거의다 끝나간다. (왜 이렇게 시간이 빨리 지나가는건지... 겁난다....조금만 느리게 가다오!) 이번 한달은 꽉 채워서 팀프로젝트를 진행하였다. 팀 프로젝트 경험이 없던 나에게는 설레기도하고 두렵기도 하였지만 현재 끝난 시점에서는 이거보단 더 좋은 경험이 없었고 너무 재밌었다. 결과물을 낸다는것은 정말 뿌듯하고 실력이 올라간 느낌?! 레벨업을 한 느낌이라 기분이 좋다. 그래서 이번 한달 회고는 팀프로젝트를 하면서 느꼈던 경험들을 적어보려고한다

프로젝트 시작

우리팀의 프로젝트 첫 시작날은 12월 25일 크리스마스였다 ! 크리스마스에도 코딩이라니...이게 맞나 ?_?
이번 프로젝트 주제는 소셜 네트워크 서비스를 만드는것이었다. 그래서 어떤 소셜 네트워크 서비스를 만들건지 각각 의견을 한개씩 의견을 냈었고 결국 최종으로 우리팀은 맛집 소셜 네트워크 서비스를 만들기로 하였다. 이제 주제를 정했으니 팀명과 프로젝트명 또한 정하였다. 그리고 어떤 기술스택을 사용할 것인지를 정하였다. 내가 사용해본적이 없는 react-query와 recoil을 우리팀은 사용하기로 했다. 그래서 살짝 겁이 났지만 현업에서 많이 쓰이고 뭐든 새로운것은 잘 배워두면 좋겠다 생각해서 두려웠지만 설렜다. 역시 새로운것을 배우는것은 재밌다 !
이렇게 하나 둘 씩 정하고 드디어 레포지를 파서 초기세팅을 하였다. 다행히 팀 프로젝트 경험이 없던 나와 달리 팀원분들은 경험이 있어서 어떻게 초기에 세팅을 (eslint prettier husky) 하고 어떤식으로 브랜치 전략을 짤 것인지에 대해서 많은 대화를 하면서 배웠다. 처음 알게되고 처음 사용한 husky에 대해서 간단하게 설명해보겠다.

Husky

• git hook 사용을 도와주는 라이브러리이다.
• eslint와 prettier가 확인하지 않은, 오류가 있거나 읽기 어려운 코드가 git에 공유되는 경우가 종종 있다.
• 그런경우를 사전에 방지하기위해 Husky를 이용하면, git에 특정 이벤트(add, commit, push 등)이 일어나기 전 자동으로 eslint와 prettier가 작동하게 할 수 있다.
• 즉, 쉽게 설명하면 좀 더 eslint와 prettier 보다 엄격하여 팀끼리 정한 컨벤션에 맞지 않으면 특정 이벤트가 작동하지 않게 보호해준다.

Issue

• 우리팀은 대화를 통해서 자기가 하고싶었던 부분을 기준으로 task를 나누었고 각 task에 대해서 issue를 만들어서 아래와 같이 작성하고 기능마다 브랜치를 파서 작업을 하였다.
  
• issue를 활용해본적이 이번이 처음이라 처음엔 작성하는 거 조차 생소했지만 지금은 너무나 익숙하고 편하다. 확실히 눈에 잘들어와 팀원들이 무엇을 어떻게 개발할것인지를 알 수 있어서 좋았고 나 또한 어떤 것을 개발한것인지 목표를 정해두고 작업할 수 있어서 좋았다

프로젝트 중간회고

러비더기 팀 프로젝트 중간회고
위에 들어가면 우리팀의 중간회고를 확인할 수 있다. 사실 이때 연말 연초라 우리팀 자체가 개발속도가 늦어서 걱정을 많이한 상태였지만 오프라인으로 더기 멘토님을 만나 피드백을 받았다. 멘토님이 해주신 피드백으로는 첫번째는 현재 우리팀은 처음에는 페이지별로 개발을 하고있었는데 이러면 나중에 서로의 각 페이지에 대해 공통된 부분이 많아져 한번더 작업을 해야한다해서 이때 다시 곰곰히 생각하여 기능별로 작업을 나누고 공통으로 쓰이는 컴포넌트를 만들어서 재활용하는 쪽으로 작업 방향을 돌렸다. 두번째로는 협업과정에서 merge 방법과 rebase 방법에 대해서 말씀해주셨다. 간단하게 한줄로 정리해보면 아래와 같다.

Merge, Rebase

• Merge: branch를 통합하는 명령어
• Rebase: branch의 base를 옮기는 명령어
  멘토님께 설명을 듣고 팀원들과 대화를 통해 우리팀은 merge 방식으로 작업을 하기로 하였다.

그리고 마지막에는 멘토님께서 우리의 개발 속도가 느리다고 시간이 없다고 쓴소리를 해주시고 이제는 무조건 하루에 issue 1~2개 씩은 완료해야 한다해서 반성하였고 열심히 해야겠다고 생각을 하였다. 이때부터 우리팀은 각성?! 하기 시작했다. 점차 조금씩 하루에 작업하는 시간을 늘려갔고 하루에 1개 이상 무조건 PR을 날렸고 팀원분들이 날린 PR에 대해서도 코드리뷰를 바로바로 하도록 노력하였다. 하다가 막히는 부분이나 고민을 해야할 부분이 있다면 빠르게 슬랙이나 디스코드를 통해 같이 해결하니 한층더 속도가 붙었고 개발에만 집중할 수 있었다. 차곡차곡 쌓이는 PR을 보니 뿌뜻하였고 초반에 개발 속도가 너무 느려서 걱정이 많았지만 어느 순간부터 적응을 하고나니 몸으로 느껴질 정도로 기능구현하는 속도가 빨라졌다.(역시 엉덩이가 무거워야 한다...마지막 10일정도는 정말 앉아서 개발만 한것 같다...!)

새로운 기술 스택

React-query와 recoil을 들어본적도 없던 내가 이 기술들을 사용해야 한다고...?
이렇게 생각을 하니 처음에는 두려웠고 검색하여 개념을 살펴보니 너무 어렵게 느껴졌다. 그리하여 프로젝트를 하는 와중에 잘안된다거나 쉴때나 잘 잠 들기전에 공식문서와 유투브의 영상을 반복적으로 보았고 이 기술스택을 사용하여 기능을 구현한 팀원들의 코드를 보니 이해가 잘갔었고 이해가 잘안가는 부분에 대해서는 멘토님께 질문을 하여서 이해를 하여 이제는 내 기능에 사용을 해보니 어느 정도 개념과 사용방법이 익었다. 역시 실제로 사용해보는게 최고인거 같다 ! !

• React-query를 사용하며 간단하게 느낀점은 redux를 사용해서 비동기처리를 해본적이 있는데 이때 많은 양의 코드를 작성하였었고 상태에 따라서 재호출되는 경우를 방어코드를 작성해주어야 했는데 React-query를 사용하니 코드양이 많이 줄어드니 팀원분들의 코드를 이해하는데 훨씬 쉬어졌고 상태관리 또한 엄청편해졌다. 특히 상태가 변하면 자동으로 Update 해준다는것이 엄청큰 메리트였다. (React-query에 대해서는 블로그에 따로 정리를 꼭해야겠다 !)

• Recoil은 React를 위한 상태관리 라이브러리이다. 전역으로 데이터를 관리하는 방법으로는Redux 와 React contextAPI를 사용해본것이 전부였는데 이번에 Recoil을 사용하여 전역으로 데이터를 사용해보았는데 확실히 React에서의 useState와 비슷한 코드 작성법으로 인해 이해하는데 문제는 없었다.

어디서 Recoil을 사용했는가?

• 나는 프로필페이지를 구현하는데 있어서 Recoil을 적용하였다.

  프로필 페이지를 구현하려면 일단 사용자의 정보가 필요하다. 그 사용자의 정보를 얻어오기 위해서는 로그인을 해야하고 로그인을 하면 인증 토큰을 부여받는데 이 토큰을 통해서 사용자의 정보를 확인할 수 있다. 그러기 위해서는 이 토큰을 어떻게 저장할 것인가를 고민해야하는데 우리팀은 로컬스토리지에 세션스토리를 저장하는 방법을 택하였다. 이제 토큰이 있으면 사용자의 정보를 서버로부터 요청해서 불러올수있는데 처음에는 프로필페이지에 왔을때 서버에 요청을 하여 사용자 정보를 불러오는 쪽으로 하였는데 이때 문제점이 생겼다. 사용자 정보를 불러오는데 있어서 딜레이가 생기기에 아무것도 그려지지않거나 undefined로 값이 들어와 원치않은 결과가 생기는것이었다. 그래서 해결방안으로 애초에 처음에 로그인했을 때 토큰뿐만 아니라 토큰을 이용하여 유저정보 또한 로컬스토리지에서 저장을 한다면 프로필페이지로 이동한경우 딜레이 없이 곧 바로 로컬에 있는 유저정보를 통해서 그릴수 있다고 생각하여 매번 react-query에서 유저정보를 받아오는 부분을 한번받아와 recoil이용하여 로컬스토리지에 저장하는 방법으로 문제를 해결하였다.
  

프로젝트 최종 회고

어떻게 보면 제대로 된 나의 첫번째 팀프로젝트라 할 수 있었는데 프로젝트 초반에 엄청난 걱정과 달리 엄청 만족할만한 프로젝트를 제 시간내에 완성하고 그 과정에 있어서 정말 많은 경험과 지식과 동기부여를 얻을 수 있어서 프로그래머스 데브코스 기간에 동안 가장 뿌듯하고 좋은 시간이였다. 프로젝트를 통해서 현재 나의 개발수준과 더 공부하고 부족한 부분이 한눈에 잘 들어와서 이러한 부분을 앞으로 최종프로젝트 전까지 어떻게 가다듬고 보완할것인지를 생각해보면 될 거 같다. 그리고 프로젝트를 끝났다고 해서 여기서 그치지 않고 계속해서 리펙토링하고 기능구현을 더 해볼거 같다. 팀원분들 또한 계속해서 리펙토링해보자고 해서 같이 으쌰으쌰해서 좀 더 완성도 있는 결과물이 될 때까지 계속해서 작업을 할거 같다. 이번 프로젝트에서 나의 주요 개발로는 프로필 페이지 구현이 있었는데 여기서 더 추가해볼만한 기능으로는 회원정보 변경부분을 모달로 추가해서 구현해볼까한다.

현재는 프로필 페이지의 모습인데 자기소개 부분 또한 회원정보 부분에 넣을까 생각중이다.
다음에 리펙토링하고 회고를 쓸 때의 모습과 비교하기 위해 사진을 넣어봤다.

새로 알게된 점

첫번 째로는 확실히 무언가를 만드는다는 것은 재밌고 즐겁다. 이런것이 내가 이쪽 길을 선택한 이유이기도 하다. 처음엔 막막하지만 막상 조금 조금씩 만들어지고 있다는 과정이 눈에 보이니까 이게 나는 너무 좋고 재밌는거 같다. 그러기에 보다 더 잘 만들고 싶고 더 완벽하게 만들고 싶어지는 마음이 든다는게 신기했고 이럴 때 마다 시간이 훅훅 지나가는지도 모른다는것이 내가 온전히 이 작업에 집중을 하고 있다는게 새로 알게된 점인거 같다. 두번 째로는 잘하는 분들이 너무나 많다...정말 같은 팀원분들이지만 이번 프로젝트를 하면서 엄청 많이 배운거 같다. 아마 데브코스 대부분의 분들이 다 잘할것이기에 적어도 짐은 되지않기위해 소홀히 개발하면 안될거같다는 생각이 많이 든다. 최종 프로젝트 때는 이번 프로젝트 때보다 새로운 팀원분들에게 큰 도움이 되고싶고 더 잘해보고싶다.

아쉬웠던 점

일정 분배가 생각보다 어려웠고 앞서 말했듯이 처음에는 페이지별로 작업을 하였었는데 작업을 하던 와중에 각 페이지별로 공통 컴포넌트가 있었는데, 이것들을 먼저 구현을 했었더라면 다른 이슈를 만들어 작업할 때 딜레이가 생기지 않았을텐데 하는 아쉬움이 있다. 다음에 최종프로젝트에서는 공통으로 사용되는 컴포넌트부터 분류하여 먼저 작업을 해야겠다. 두번째로도 아쉬웠던 점으로는 제출날짜가 다가오니 급해져서 팀원들의 코드리뷰를 하는데 있어서 지연되고 리뷰 또한 초반에 비해 퀄리티가 떨어져서 팀원분들에게 죄송했다. 내 코드 또한 가독성과 최적화에 신경쓰지 못하고 기능구현에만 급급한 느낌이여서 아쉬웠고..이러한점들이 위에서 말했던 일정분배가 생각보다 어려웠다는 점이었다.. 다음 프로젝트에 있어서는 좀 더 "J" 처럼 세세하게 일정을 계획해야할거 같다.

마지막으로..

지금 최종프로젝트를 앞두고 3차 팀으로 팀이 바뀌었다.. 이 또한 얼른 적응하고 이번 팀원분들은 또 얼마나 잘하시고 어떤 좋은 태도와 생각을 가지시고 계신지 궁금하고 이런 좋은 것들을 다 배우고 싶다. 잘하는 분들을 지켜보며 배우는 것 또한 재밌고 따라하는것도 재밌으니 잘 흡수해봐야겠다. ! 새로운 멘토님은 아직 만나보지는 못했지만 무려.. "당근"에 다니신다고하니까 되게 신기하고 멋져보인다... 이런 기회는 흔치않으니 질문도 많이 하며 커피챗에서 정보도 많이 얻고 많이 배워야겠다... 이제 마지막 프로젝트다,, 시간이 엄청 빨리 지났다..
최종프로젝트를 진행하는 시간이 길기에 이번 프로젝트를 진행하면서 아직 공부하지 못한 기술스택들도 열심히 공부하고 정리하고 이력서도 작성하고 요즘 코테를 잘 안풀었는데 코테 또한 내가 잘 못하는 부분이니 열심히 꾸준히 풀어야겠다. 아마 다음 회고 때는 지금보다 더 기록할만 것들이 있을거라고 생각한다.. 이쯤에서 정리하고 자 파이팅이다 !

아래는 프로젝트의 결과물인 맛남의 길이다.
맛남의 길