[BLOB] 프로젝트 회고

 

프로젝트 소개

혹시 여행 중 오래된 정보나 부정확한 정보로 인해 불편함을 겪은 적이 한번쯤 있지 않으신가요? 

또한 교통상황, 사건 사고 등 여행 중 실시간으로 업데이트되는 정보들을 모아볼 수 있는 곳이 없어서 . 날씨 이슈로 행사가 취소된다든가, 시시각각 바뀌는 현지 상황을 알지 못해  여행 중 예기치 못한 일들을 겪게 되기도 합니다.

이러한 불편함을 해결하기 위해 블롭이라는 서비스를 생각하게 되었습니다.

 

 

문제 해결 과정은 여기 링크 참조 해주세요.

무한스크롤 커스텀 hook

카테고리 버튼 상태관리 / 컴포넌트 props 분리

 

협업

각자 분업하는 것이 아닌, 협업을 하는 것에 중점을 두고 기획과 코드 컨벤션을 맞추는데 시간을 많이 투자했다.

 

프론트엔드 5명, 백엔드 2명, 디자이너 1명과 같이 협업을 시작했다. 월 / 수 / 금요일에는 게더타운에서 전체 회의를 진행하였고, 기획과 와이어프레임은 다같이 피그마를 공유하면서 설계하였다.

 

기획을 2주 정도 진행하면서 느낀 문제점은 8명이 게더타운이라는 온라인 공간에서 한 명씩 의견을 주고 받는게 쉽지 않았고, 그러다보니 회의 시간도 너무 길어진다는 것이다. 이 부분을 해결하기 위해서 조그만 기획이나 수정사항은 대표로 프론트엔드 1명, 백엔드 1명, 디자이너 1명에서만 이야기를 나누고 나머지 인원들에게 의견을 전달해주는 방식으로 진행하였다. 그리고 회의 시간에는 전체적으로 다룰 내용만 전달하고 그 외의 내용은 파트별로 회의를 하거나, 팀 미팅 시간이 아니더라도 디스코드로 소통하면서 회의 시간을 줄여나갔다. 

 

 

- 프로젝트 구조

디자인과 백엔드 api가 나오기 전까지 프론트엔드는 개발 환경 초기 세팅과 코드 컨벤션을 맞추어 나갔다.

 

페이지 레이어부터 유틸리티 레이어까지 5개의 상위 레이어로 나누고, 그 아래에 하위 레이어가 있는 구조로 통일했다. 상위 레이어에는 추상화된 로직을 작성하고, 디테일한 로직은 하위 레이어로 넘긴다. 하위 레이어에서 상위 레이어를 호출할 수 없도록 분리하여, 각 레이어에 속한 컴포넌트나 함수들이 서로간의 의존관계를 분명히 하도록 했다. 레이어 간의 분리를 통해 가독성과 유지보수성을 높힐 수 있었다.

 

 

- 코드 컨벤션

프로젝트 후반으로 갈수록 파일들은 기하급수적으로 늘어나고, 다른 사람이 작성한 코드의 위치를 찾기 어려운 문제가 생긴다. 하지만 아래의 규칙을 세움으로써 대략적인 위치를 짐작할 수 있게 하였다.

 

1. 해당 폴더 / 파일에서만 사용되는 코드는 동일 폴더 / 파일 안에서만 위치시킨다.
2. 재사용되는 코드는 공통 조상에 위치시킨다.
3. 전역에서 사용해야하는 util 등은 app 폴더의 바깥폴더에서 관리한다.

 

위처럼 코드 컨벤션을 잘 작성해놓더라도, 각자 컨벤션에 대하여 이해하거나 생각한게 다를 수가 있었다. 그래서 팀원들끼리 모여 일주일 동안 페어프로그래밍으로 작업하면서 서로의 코드 컨벤션을 체크해주었다. 덕분에 코드 리뷰를 할 때 코드 컨벤션에 관련된 부분에 대해 지적을 덜 하게 되었고 팀원들간에 코드도 읽기 쉬워졌다.

 

 

 

 

상태 관리

Zustand와 React Query

상태관리 라이브러리를 선택할 때 가장 기본적으로 고려한 것은

학습에 큰 어려움이 없어야 한다.

 

프로젝트 기간인 6주동안 상태관리 라이브러리 학습에 많은 시간을 투자할 수 없었다.

 

Redux vs Zustand

npm trends 자료를 보면 Redux의 다운로드 수가 압도적으로 높다. 하지만 Redux는 다른 라이브러리들에 비해 학습곡선이 가파르다.

짧은 기간동안 프로젝트를 진행하는 우리 상황에서, 배워야 할 내용과 작성해야 할 코드가 많은 Redux는 적합하지 않다고 판단했다. 그리고 6주간의 프로젝트에서 무겁고 복잡한 Redux를 쓸 필요성을 느끼지 못했다.

 

Zustand vs Jotai

 

 

- 다운로드 수

npm trends 다운로드 수를 다시 보자. 여기서 Redux는 제외했다.

다운로드 수는 Zustand가 높다. 새 라이브러리를 학습하는 우리 팀의 입장에서는, 사용자가 많을수록 학습자료가 많을 것이기에 장점으로 느껴졌다.

 

- 상태 관리 방식

Zustand는 하나의 store 안에 여러 상태들이 담기는 반면, Jotai는 각각의 상태가 atom(원자) 형식으로 흩어져 있다.

우리의 프로젝트에서는 상태를 여러 곳에서 관리하는 Atomic보다는, 한 곳에서 관리하는 Flux 방식이 더 맞다고 생각했다.

 

 

정리하면,

 

1. 컴포넌트 밖에서 상태 변경이 가능.(컴포넌트 내부의 로직 최소화)
2. 적은 보일러코드, 직관적 사용, 작은 패키지 사이즈.
3. 스토어하나에 모두 구현하면 됨, reducer, aciton 선언등을 간소화.
4. flux패턴을 사용하나, 간소화하여 러닝커브 낮음. 전역상태를 최소화하는 방향성에 적합했음.

 

 

하지만 상태 관리 라이브러리를 하나만 사용해서 클라이언트 상태과 서버 상태를 관리 했을 때,

 

1. 스토어에 상태관리보다 api 호출코드가 더 많았다.
2. 기존 라이브러리가 비동기 통신에 적합하다는 생각이 들지 않았다.

그래서 우리 프로젝트는 서버 상태 관리 라이브러리인 React Query를 도입하게 되었다.

 

 

 

배포

Vercel

프로젝트에서 프론트엔드는 Vercel로 배포하였고 백엔드 서버 부분은 AWS로 배포 하였다.

 

프론트엔드에서 Vercel을 사용한 이유

 

- 개발 시간 절약

 

Vercel을 이용하면 복잡한 설정 없이 간단하게 웹 사이트를 배포할 수 있어서 AWS로 배포하는 것보다 훨씬 간단하다.

그리고 Next.js를 Vercel로 배포할 경우 서버사이드 렌더링 여부가 크게 중요하지 않다. Vercel을 Next.js 개발자가 만들었기 때문에 서버사이드 렌더링의 특징을 잘 고려하여 간단하게 배포할 수 있는 장점이 있다.

 

 

- Github 자동화 설정

 

AWS는 Github Actions로 배포 자동화를 설정해줘야 하는데 Vercel은 복잡한 설정 과정이 필요없이 Github 배포 링크와 연결만 하면 된다.