요즘 내가 개발자가 되기 위한 활동에서 가장 많은 시간을 투자하고 있는 것은 데브코스 최종 프로젝트인 것 같다.
이번 프로젝트에서는 백엔드와 프론트엔드가 함께 협업하여 하나의 서비스를 개발하기 위하 다같이 노력하고 있다.
개인적으로 처음 백엔드와 하는 협업이다보니 어려움을 겪는 부분과 서로의 소통에 문제가 생기는 부분도 있었지만 팀 중간 회고를 거친 지금까지는 마주치게 된 어려움을 팀원들과 잘 해결해나가고 있는 것 같다.

주제 선정 과정

프로젝트 주제를 선정할 때 우리가 가장 신경썼던 부분은 3가지가 있었다.

1. 적은 인원으로도 서비스의 원활한 이용이 가능한가?

기존에 팀 프로젝트를 진행하게 되면 가장 많이 하는 주제는 중개 플랫폼이나 SNS 관련 관련 주제를 많이 생각하게 된다. 당장 나도 이번 최종 프로젝트에서는 같은 취미를 가진 사람들이 모이는데 도움이 되는 모임 관련 SNS를 주제로 제출하였다. 하지만 이러한 서비스가 원활하게 이용이 가능하려면 많은 사람들의 이용이 필요하다.
이번 팀 프로젝트에서는 팀원들 모두 적은 이용자가 있어도 원활하게 모든 서비스 사용이 가능한 주제를 원했다.

2. 서비스 구현과 사용에 현실성이 있는가?

서비스를 구현하는데 우리의 개발 레벨에서 현실적으로 가능한지, 너무 어렵거나 불가능한건 아닌지를 생각하였다.
구현하기 어렵다고 생각하는 주제를 선택해 새로운 것들을 공부하며 프로젝트를 진행하는 것도 큰 의미가 있겠지만 비교적 짧은 시간안에 결과물을 완성해야하기에 서비스 구현 난이도도 중요한 요소라고 생각했다.

또한, 이용자가 정말 사용할만한 서비스인지도 중요하게 생각한 요소였다.
서비스를 만들었지만 막상 사용하기 불편해서 사용하지 않는 서비스라면 개발에 의미가 없다고 생각하였다.

팀 프로젝트 주제 선정 마지막 과정에서 이용자가 가지고 있는 옷 정보를 모두 등록해 세탁 방법과 날씨에 맞는 추천 의상, 자주 입는 옷과 입지 않는 옷을 알려주는 옷 관리 서비스와 이번 프로젝트 주제 두 가지를 고민하였다.
옷 관리 서비스는 이용자가 옷을 모두 수동으로 등록해야한다는 불편함이 있었고 이를 해결하기 위해 옷 태그를 카메라로 분석해서 등록 과정을 줄이자는 의견도 나왔지만 지금 팀의 지식으로는 개발에 현실성이 없다고 생각되었다. 또한, 입은 옷을 사용자가 계속해서 체크해야한다는 불편함에 서비스 이용이 현실성이 없다고 생각하여 다른 선택지를 고르게 되었다.

3. 구현을 통해 배울 요소들이 있는가?

난이도를 적절히 가져가면서 구현 과정에서 새로운 지식을 얻을 수 있는도 중요한 주제 선정 요소였다.
프론트엔드와 백엔드 모두가 단순 반복 작업이나 이전에 만들어둔 프로젝트 코드를 복붙하는 개발을 벗어나 윈윈할 수 있는 주제를 원했다.

프로젝트 주제

그래서 이번 프로젝트에 우리 팀이 선택한 주제는 위치 기반 다이어리 작성에 중점을 둔 커플 애플리케이션이다.
2명의 사용자만 있으면 모든 서비스를 사용이 가능하고, 두 명을 하나의 그룹으로 묶어 관리하는 과정과 현재 위치를 기반으로 한 다이어리 구현에서 백엔드와 프론트엔드 모두 새로운 경험을 할 것이라고 생각하였다.
기존 커플 앱의 장점과 단점들을 확인해 커플 앱에서 부족했던 부분을 채워 실제 사용해볼만한 서비스를 기획하고자 노력하였다.

프론트엔드 팀원들은 반응형 웹으로 제작을 계획해서 개발 과정에서 CSS에 대한 이해도를 높이고 사용자 경험도 향상 시킬 수 있도록 기획하였다.

협업 방식

협업 방식을 선택할 때 협업 툴의 사용을 최대한 간소화하여 모두가 빠르게 확인이 가능하도록 하는 방향을 선택하였다.
우리 팀의 협업 툴은 크게 Slack, Gather, Notion, GitHub이다.
Slack를 통해 비동기 소통을 하며, Gather를 사용해 팀 스크럼 및 동기 소통을 하고있다.
Notion은 팀 프로젝트 개발 과정에서 수정할 점들이나 회고에 대한 문서화를 담당하고 있고, GitHub를 사용해 스케줄 관리 및 개발 문서화를 진행하고 있다.
처음에는 Jira와 같은 프로젝트 관리 앱을 사용하지 않는 것에 걱정이 있었지만 팀 규모(프론트 3명, 백엔드 3명)가 크지 않고, 각각의 협업 툴의 목적을 확실하게 정하고, 스크럼과 꾸준한 소통을 적절히 가져가다보니 오히려 또 다른 툴을 관리하는 데 시간을 줄이고 팀원들이 모두 빠르게 현재 상황을 공유할 수 있어서 좋은 선택이였다는 생각이 든다.

프로젝트 기술 스택

프론트엔드의 기술 스택은 아래와 같다.

React, TypeScript, Vite, Storybook, Daisy UI, Tailwind css, Emotion, React-query

기술 스택을 정할 때 프론트엔드 팀원들의 가장 큰 고민은 Next js 적용에 대한 고민이였다.
react-query와 tailwind css를 처음 사용하는 팀원도 있고 아직 CSR, SSR, SSG에 대한 이해도가 낮다고 생각되어서 Next js는 과감하게 포기하게 되었다.
프로젝트를 진행하다보니 아직 react에 대해 깊게 배워가야 할 점들이 너무 많고 상태 관리 등 기본적인 부분에서 살짝 부족하다고 생각되는 부분들이 보여서 Next를 선택하지 않은 것은 짧은 프로젝트 기간에 잘했다고 생각되는 선택이다. 하지만 SSG, SSR, server component 등 next js를 공부해보면서 배울 점도 많다고 생각되기 때문에 지금은 틈틈히 next js도 공부하고 있다.

storybook은 이번 중간 팀 회고를 통해 프로젝트에서 삭제하고 더이상 사용하지 않기로 결정하였다. 팀원 모두가 Daisy UI를 적극적으로 사용하려고 노력하면서 공통 컴포넌트가 많이 줄어들기도 했고 3명의 프론트엔드 팀원이 꾸준한 PR 리뷰를 통해 작업 결과물에 대해 잘 이해하고 있기 때문에 필요성을 느끼지 못했다.
필요성을 느끼지 못하는 라이브러리는 과감하게 버리고 불필요한 코드 작성을 줄이면서 빠른 개발 속도를 챙기는 것도 중요하다고 생각되었다.

Tailwind css와 Emotion을 동시에 사용하는 것은 생각하지도 못했지만 멘토님의 피드백과 tailwind로 개발할 수 없는 기능(ex. 변수 값에 따라 색상이 동적으로 변경되어야 할때)등 tailwind만으로는 부족한 부분을 채우기 위해 Emotion을 추가로 사용하였다.
Emotion을 사용해 react-calendar와 같은 라이브러리에 스타일을 적용할 때 잘 사용하고 있지만 아직 팀원들간에 Emotion과 Tailwindcss 적용 기준에 대해 명확한 것 같지 않아 중간 데모가 끝난 지금 다시 한번 규칙을 정하고 개발을 시작하려고 한다.

새로운 상태 관리 방법

이번에 프론트엔드 팀원이 가장 신경 쓰고 있는 부분은 로직과 UI 렌더링 코드의 분리이다.
사용자에게 보여줄 UI를 담당하는 컴포넌트는 UI 렌더링만, 로직을 담당하는 파일을 로직만을 담아 사용하여 분리하는 것을 목표로 개발을 진행하고 있고 이 과정에서 react context api를 적극적으로 사용하고 있다. 사실 이전에는 context api를 많이 사용해 본 경험은 없어 어떤 방식으로 사용하면 좋은 사용 방향을 가져갈 수 있을 지 많은 고민을 했지만 React State Hooks - useContext 멘토님의 블로그 글이 정말 큰 도움이 되었다.
아직 컨텍스트 단위로 컴포넌트들을 구조화하고 구현하는게 미흡해서 리팩토링이 필요한 부분들이 많이 보이지만 하나의 모달을 관리하는 과정에서 큰 효과를 얻을 수 있었고 계속해서 context api 사용하여 로직과 렌더링 코드를 분리해나가려고 한다.

앞으로...

이번 중간 팀 회고를 통해 서로가 부족하다고 생각한 점들과 추가가 필요한 부분들이 있다는 것을 확인하였다.
이러한 점들은 자세한 규칙 설정, 코드 리팩토링, 문서화를 통해 해결해나가려고 계획하고 있다.

개인적으로는 반응형 디자인 개발 과정에서 불편함을 느껴 이를 해결하고자 관련 툴을 추가하려고 계획하고 있다.
지금은 반응형 디자인을 개발하고 확인하기 위해 chrome 개발자 모드를 사용하고 있다. 하지만 한눈에 모바일, 태블릿, PC 화면을 모두 확인할 수 없어 계속해서 화면 사이즈를 변경해줘야한다는 번거로움이 있고 PR을 남기거나 확인할 때 모바일 화면 캡처를 까먹는 경우가 있어 직접 확인해서 리뷰를 남겨야한다는 불편함이 있다.
이를 해결하기 위해 도움이 되는 툴을 찾아보았고 responsively라는 툴을 알게되어 이번 쉬어가는 기간에 공부하고 팀원들과 공유해서 적용해볼 예정이다.

백엔드와 프론트엔드 협업이 처음이라 걱정했던 부분이 많았지만, 팀원 모두가 개발 중에 겪는 어려움에 대해 해결하려는 모습과 서로의 피드백을 적극적으로 반영하려는 모습에서 걱정보단 배울 점이 더 많다고 생각되었고 프로젝트 마지막까지 모두가 화이팅해서 좋은 결과물을 만들 수 있으면 좋겠다는 생각과 함께 나도 더 열심히 달려야겠다는 생각이 든다.