9월은 팀 프로젝트를 진행했다. 프론트엔드만 모여서 진행하는 팀 프로젝트는 처음이였기 때문에 나에게는 팀 문화, 개발 규칙, 기술 스택 등을 정하는 과정부터 개발까지 모두 새로운 경험이였고 그만큼 시간이 너무 빠르게 지나갔다.
이번 팀 프로젝트에서는 SNS 서비스를 뼈대로 1인가구를 타겟팅한 혼콕이라는 서비스를 제작하였다.
서비스를 만들기 위해 기획, 개발, 배포까지 여러 과정들을 경험하면서 느꼈던 점들을 정리해보고자 한다.

---

협업 툴

협업을 위해 우리 팀은 기획 단계에서는 figjam을 사용하였고 개발 단계에서는 Github를 적극적으로 사용하였다.

Figjam??

이번에 처음 사용해보게 되었던 figma 기반의 툴로 실시간으로 공유되는 노트 앱이다.
주제 선정부터 주제 구체화까지 프레인스토밍 형식으로 진행하였는데 간단하게 글로만 표현하는 것 보다 나의 생각을 시각적으로 보여줄 수 있도록 간단한 그림과 함께하니 내 의견을 더 구체화하기 쉬웠고 다른 팀원의 의견을 이해하기 쉬웠다.

GitHub

맨 처음 Github로만 개발 협업툴을 사용하기로 정했을 때 부족할 것 같기도 하다라는 생각이 들었지만 내가 Github의 기능들에 무지했다는 생각이 든다.
issue와 project의 칸반보드를 사용한 일정 관리부터 discussion, 문서화를 위한 wiki, settings를 활용한 규칙 설정까지 소규모 프로젝트를 진행하기에 Github가 제공하는 기능들은 충분하고 유용했다.
진행 예정이나 진행하고 있는 작업에 issue로 등록하고 태그로 진행 상태를 알 수 있어서 서로가 어떤 작업을 하고있는지 한눈에 볼 수 있어서 좋았고 PR에 연결해서 issue가 자동으로 닫히게 하는 과정이 너무 편리했다.
개인적으로는 Action 기능을 추가로 사용하면 더 편리하게 협업할 수 있을 것 같다는 생각이 들어서 공부해볼 예정이다.

팀 문화

• 주체성을 가지고 움직이기
  • 회의는 모두가 돌아가면서 진행해요. 🧐
• 느긋하고 느슨한 것을 지양하기
  • 2일 이내 작업과 스프린트 기반으로 일정과 목표를 선정해요. 🏃
• 다른 사람의 의견에는 최소한의 반응하기
  • 침묵보다는 작은 리액션 및 간단한 이모지라도 남겨요. 🙂
  • 이야기가 끝날 때 박수로 마무리해요. 👏
• 특이 사항은 즉각적으로 공유하기
  • 일정이 늦어질 것 같으면 바로 이야기해요. 😆

우리 팀의 팀 규칙은 위와 같았다. 팀원간의 소통이 원활하게 되는 것을 중요하게 생각해서 이러한 규칙들을 정했고 모두가 지키기 위해 노력했다.
팀 프로젝트를 마무리한 지금 규칙들이 모두 잘 지켜졌나를 생각해보면 대부분 잘 지켜진 것 같다고 생각된다. 모두가 문서화와 소통을 통해 현재 자신의 작업 진행 상황을 공유하려고 노력했다. 하지만 기획 단계에서 유저스토리 작성을 통한 개발해야할 작업들을 세분화하지 못해 스프린트에 대한 아쉬움이 살짝 남는다.

개발 규칙

혼콕 팀 개발 규칙
우리 팀의 개발 규칙은 변수명과 커밋 컨벤션 등을 제외하면 Github 기능과 Eslint, Prettier를 사용해 자동으로 적용할 수 있게 하였다.
좋은 변수명이 무엇인지 이해하고 쉽고 가독성 좋은 컨벤션이 어떤 것인지 다같이 고민하고 이야기하는 과정을 통해 나쁜 변수명 설정 습관이나 컨벤션 습관을 고치려고 노력했다.
또 Eslint와 Prettier의 중요성에 대해 깨닫게 되는 계기가 되었다. 개인 프로젝트를 진행할 때는 Eslint와 Prettier를 모두 코드 포맷터처럼 사용했었다. Eslint와 Prettier의 차이점을 알고 있었지만 그 필요성을 별로 느끼지 못했다. 하지만 Eslint에 다양한 확장을 붙이고 팀원 간의 상의를 통해 필요하지 않은 규칙들을 제거해서 사용하니 너무 편리하게 느껴졌다. 코드 컨벤션에 위반되는 코드나 안티 패턴을 검사해줘서 일관성있는 코드를 작성하기 쉬웠고 때문에 내가 개발하지 않은 코드에 대해 빠르게 이해할 수 있었다.!

기술스택

StoryBook

우리 팀은 컴포넌트에 대한 문서화를 위해 storybook을 사용하였다. 초반엔 storybook의 사용법에 대해 공부한 상태가 아니여서 많이 헤매고 어려움을 겪었지만 익숙해진 후 다른 팀원이 개발한 컴포넌트에 대해 테스트 코드를 작성하지 않아도 시각적으로 컴포넌트에 props을 변경하며 확인해 볼 수 있어서 컴포넌트에 대한 이해를 쉽게 할 수 있었다. 프로젝트 막바지에는 시간에 쫓겨 storybook을 잘 사용하진 못했지만 프로젝트의 뼈대를 잡는데 큰 역할을 했다고 생각한다.

React Query(Tanstack Query)

이번 프로젝트를 진행하면서 가장 깊게 공부했다고 생각하는 라이브러리는 react query라고 생각한다.
사용자 로그인 상태 관리 부분을 맡았기 때문에 react query를 자세히 공부해야했고 그 결과 로그인 상태 관리 부분을 완성할 수 있었다고 생각한다.
react query를 사용하면서 가장 어려움을 겪었던 부분은 staletime과 cachetime에 대한 이해도가 낮아서 발생했는데 문제를 해결하기위해 공부하면서, 또 해결하고 난 후 문서화(staletime과 cachetime 이란?)를 통해 팀원들과 문제와 해결 방법을 공유하면서 이해도를 높이려고 노력했다.
react query를 사용해본 결과 react query는 서버 상태 패칭, 캐싱, 동기화 및 업데이트를 하는데 너무나 큰 도움을 주는 라이브러리이기 때문에 다른 프로젝트에서도 적극적으로 사용하고 싶고 더 공부해볼 필요가 있는 라이브러리라는 생각이 들었다.

4L

Liked (좋았던 점)

• 기능 개발 중 공식 docs를 많이 활용하려고 노력했다.
• PR을 통해 다른 팀원의 코드를 보면서 다양한 방법과 구조에 대해 공부할 수 있었다.
• 협업 툴로 Github를 사용하다보니 다양한 Github 기능을 경험할 수 있었다.
• 어려움을 겪었던 문제에 대한 해결방법을 팀원들과 공유하기 위해 노력했다.

Learned (배운 점)

• 사용자 로그인 상태 관리 파트를 맡아 개발하면서 react-query에 대해 이해하고 적절하게 사용하려고 노력을 했었다.
• 리액트에 타입스크립트를 사용하는게 어려웠었는데, 프로젝트를 하면서 학습을 많이 한 것 같다.
• 팀 프로젝트를 위해 개발 규칙이나 팀 문화를 만들어가는 과정을 통해 팀 프로젝트의 흐름에 대해 배울 수 있었다.

Lacked (부족했던 점)

• 추가 요구사항을 포함한 모든 요구사항들을 구현하는 것이 목표였는데 그 중 다크모드를 구현하지 못한 부분이 아쉬웠다. (리팩토링!! 🔥)
• 스스로 팀 규칙에 대해 잘 지켰는지 생각해보면 그렇지 않은 것 같다. 특히 작업 단위를 작게 가져가는 부분을 많이 지키지 못한 것 같다.
• 후반에 맡은 기능 구현을 급하게 하다보니 다른 팀원의 PR에 많은 신경을 쓰지 못한 것 같다.

Longed For (바라는 점)

• 팀 문화에 대해 더 많이 고민하고 다음 프로젝트에서 더 좋은 팀 문화를 만들 수 있도록 노력하기!
• 개인 프로젝트도 한번 진행해보기! ⇒ 새로운 것들을 적극적으로 사용해보자!
• 더 좋은 문서화를 고민하고 작성해보기