파이널 프로젝트는 순식간에 지나갔고, 벌써 수료가 코 앞이다. 처음엔 서로 어색했던 팀원들과 유대감(?)이 생겨 조만간 회포를 풀기로 했다. 짧지만 많은 것을 얻었던 시간이라고 생각한다.

1. 팀 빌딩

팀장을 맡게 되어 내가 주도적으로 팀 빌딩을 해야했다. 프로젝트 시간은 필드에서의 실무 경험을 간접 체험하는 것이라고 생각하였고, 번거롭더라도 최대한 애자일스러운(?) 실무환경과 유사한 규칙을 수립하여 협업하고 싶었다. 먼저 노션 페이지를 만들어 기본적인 규칙들을 적어 넣은 뒤 팀원을 설득했는데, 다행히 모든 팀원이 흔쾌히 동의하여 그대로 진행하게 되었다. 깃 브랜치 전략의 경우에는 관련 강의를 첨부하여 팀원 모두 동일한 강의를 듣고 git-flow전략을 따르도록 유도했다.

2. 기획

기획을 할 때, 두 가지 생각이 떠올랐다.
"수익을 낼 수 있는 서비스를 고민하여 만들어 볼까?", "우리가 배운 것을 최대한 활용할 수 있는 서비스를 만들어 볼까?".

팀 회의 결과 전자보다는 후자를 선호하여 후자를 중심으로 어떤 서비스를 개발할지 고민했다.

기본적인 CRUD와 함께 관리자페이지에 대한 의견이 나왔고, 개인적으로는 화상 채팅을 구현해보고 싶었다.

그 결과 화상토론 상대를 찾아주는 서비스가 떠올랐다.
기본적인 기능에 랭킹시스템, 토론 키워드 관련 뉴스, 화상 채팅 속 기능 등 advanced한 요소를 추가 개발하기에도 좋을 것 같다고 판단했다.

그 후 모든 팀원들과 현재 실력에 관한 충분한 이야기를 나누 었고, 확실하게 구현 가능할 것 같은 기능과 어려울 것 같은 기능을 분리하여 정리했다.

화상 채팅은 팀원 중 아무도 구현해본 경험이 없어서 만일 백엔드에서 시간이 나지 않을 경우 내가 express를 통해 소켓 서버를 구현하기로 했다.

정리 후 팀원들과 Bare Minimum까지는 어떻게든 일정 내에 끝내보자고 파이팅했다.

3. 기술스택 선정

프로젝트의 기술스택으로 react-typeScript, redux-toolkit(클라이언트 상태관리), react-query(서버 상태관리), styled-component를 선정했다.

프로젝트 시작 전 기술스택에 대한 고민이 들어서 기술블로그를 찾아보던 중 카카오 기술블로그에서 react-query에 관한 글을 보았다. 서버상태를 우아하게 해결할 수 있는 리액트 쿼리에 매력을 느껴 프로젝트에 적용하고 싶어서 짬짬이 사용법을 숙지했다. 또한 채용시장을 스윽 둘러보니 typescript를 선호하는 회사가 많았다. 아무래도 협업 시 타입 안정한 언어가 유리하기 때문인 것으로 판단되는데, 문제는 코드스테이츠 과정엔 타입스크립트가 포함되어 있지 않았다. 그래서 급한대로 노마드 코더 타입스크립트 첼린지 과정을 통해 공부했다.

퍼스트 프로젝트 당시 기술 스택을 정할 때 프론트엔드 팀원은 위의 기술스택 도입을 달가워 하지 않았지만 사용 예시를 직접 보여주고, 관련 레퍼런스와 영상물을 공유하여 설득했다. 프로젝트 중 시간이 날 때마다 지속적으로 위의 스택들에 대한 지식을 전달했다. 그 결과 파이널 프로젝트에선 리덕스와 리액트 쿼리를 제외하고 팀원도 위의 모든 기술 스택을 사용하여 개발했다.

추후 팀원의 코드를 리액트 쿼리를 통해 함께 리팩토링 할 예정이다.

4. 프로젝트 결과

https://github.com/codestates-seb/seb39_main_030

막판에 소켓서버를 직접 구현하게 되어 일정이 간당간당 했지만 다행히 제출 이틀 전까지 Bare Minimum수준을 구현하여 발표자료를 만들 수 있었다. 아직은 소켓 id관리가 완벽하게 이루어지지 않아서 예외 상황에서 완벽하게 동작하지 않아 추후 추가 개발이 필요하긴 하지만 그래도 구현해냈다는 것에 큰 뿌듯함을 느꼈다.

약간의 우여곡절도 있었지만 팀원 모두 묵묵히 각자의 역할을 다 하여 원하는 만큼의 기능을 구현할 수 있었다.

팀원들과 이 프로젝트를 지속적으로 리팩토링하기로 했으며 리팩토링 과정에서 배울 것들에 대한 기대감이 든다.