00. 프로젝트 소개

1개월간 팀 프로젝트를 진행했다. 프론트엔드 개발자 5명으로 이루어져 있고 백엔드는 강사님이 관리해 주셨다.

팀 레포지토리
fork한 내 레포지토리 - 여기서 배포했다
배포 링크
스토리북 배포 링크

00.1 TMI HOMERS

tmi를 뉴스 형식으로 공유하는 sns 플랫폼이다.
TMI(Too Much Information)과 전서구를 뜻하는 HOMERS를 합친 합성어로

자신의 tmi를 마음껏 이야기 할 수 있는 공간이 있으면 좋겠다는 생각으로 컨셉을 잡았고, 익명으로 글 쓰는 것이 익숙하지 않은 사람들을 위해 ‘뉴스기사를 작성하는 기자’라는 컨셉을 추가하여 글을 작성하는 데에 거부감을 줄이고자 했다.

디자인

01. 진행 한 작업

01.1 프로젝트 세팅

1. 브랜치 전략

• Github flow를 이용했고 feature브랜치에서 main branch로 머지할때는 1명이상의 코드 리뷰를 받아야 머지할 수 있도록 했다.
• 이를 위해 github에서 main branch 보호룰을 적용했다
• 만약 pr에 코드리뷰를 반영한 커밋이 추가되면 approve가 초기화되고 다시 코드리뷰를 받아야 하도록 설정하였다.
• 팀 프로젝트를 처음하는 팀원들이 있어서 이슈 생성 → 이슈에서 브랜치 생성 → 작업후 pr하는 워크 플로우를 문서화해 팀원들에게 공유했다

2. husky, lint-staged, commitizen, commitlint를 이용한 Commit, Push 검사

• husky와 lint-staged를 이용해 eslint를 통과한 코드만 commit이 가능하도록 하였다. 이로 인해 팀원들이 코드 리뷰에 사용하는 시간을 줄일 수 있었다
• 팀에서 정한 commit convention을 편하게 지킬 수 있도록 commitizen을 사용해 커밋 템플릿을 만들었다.
• 하지만 윈도우에서 commitizen를 사용하지 못하는 이슈가 있어서 commitlint를 이용해 커밋 컨벤션에 맞는 커밋만 작성할 수 있도록 검사했다.
• 또한 로컬 브랜치에서 원격 브랜치에 push하기 전에 build test를 진행하도록 설정해서 빌드 테스트를 통과한 코드만 push할 수 있도록 했다.

3. React Router

• React Router를 이용해 각 페이지의 라우팅을 설정했다.
• React Router가 제공하는 errorElement를 이용해 404페이지를 라우팅했다.
• 로그인이 필요한 페이지는 ProtectRouter Component를 이용해서 보호했다.

import { ReactNode } from 'react';
import { Navigate } from 'react-router-dom';
import { TOAST_MESSAGES } from '@/constants/Messages';
import useAuthQuery from '@/hooks/useAuthQuery';
import { useToastContext } from '@/hooks/useToastContext';
import { LoadingPage } from '.';

const ProtectedRouter = ({ children }: { children: ReactNode }) => {
  const { showToast } = useToastContext();
  const {
    userQuery: { data: user, isLoading },
  } = useAuthQuery();

  if (isLoading) {
    return <LoadingPage />;
  }

  if (!user) {
    showToast(TOAST_MESSAGES.NEED_AUTH, 'info');
    return <Navigate to="/login" replace />;
  }

  return children;
};

export default ProtectedRouter;

4. Tanstack Query

• QueryProvider를 이용해 어플리케이션에서 query를 사용할 수 있게 했고 기본 stale time(데이터가 신선한 시간)은 5초로 설정했다.
• 유저 정보를 Context로 저장했는데 Tnastack Query로 저장하도록 수정했다.

01.2 기능 구현

1. 회원가입 기능

• React Hook Form을 이용해서 validation 진행
• form을 제출할때 TanStack Query의 useMutation.mutate를 호출했고 성곰 및 에러 이후의 동작은 onSuccess, onError를 이용해 정의했다.

2. 회원정보 수정 기능

• 회원정보 수정 페이지에 들어가면 Tanstack Query에 캐싱되어 있는 user의 정보를 받아 React Hook Form의 setValue를 이용해 회원 정보 수정 form에 초기값을 입력했다.
• 만약 페이지에서 나가려고 하면 수정사항이 사라진다는 경고 모달창을 보여주었다.

3. 알림 기능

• Web Socket, SSE가 불가능한 환경이었기 때문에 TanStack Query를 이용해 폴링으로 구현해 실시간성을 제공했다.
• 페이지에 들어왔을 때 알림을 읽는 것처럼 보여주기 위해 useEffect의 cleanup을 사용해 페이지에서 나갈때 알림을 읽었다.

01.3 인프라

1. 배포

• 어플리케이션은 Vercel로 배포했고 Storybook은 원래 배포도구로 Netlify로 하다가 Chromatic으로 변경했다.
• Chromatic 도입하기 전에는 팀원마다 구현한 작업 결과를 캡쳐해 PR에 문서화함으로써 작업 상황을 공유했습니다.
• 그런데 이 반복되는 작업이 너무 번거롭다는 의견이 나왔고 이 문제점을 해결하기 위해 Chromatic을 도입했다.
• PR과 동시에 크로마틱에서 Storybook을 배포하고 이 배포된 링크에서 Story의 변경사항을 쉽게 추적할 수 있었다.

2. github action

• 빌드 테스트, 크로마틱 CI/CD github action를 추가했다.
• 원래 로컬 브랜치에서 원격 브랜치로 push할때만 Husky를 이용해 빌드 테스트를 진행했다.
• 그런데 PR에서 발생한 Merge Conflict를 github에서 해결할 때 생기는 commit은 원격 브랜치에서 발생한 commit이므로 push 이벤트가 발생하지 않는다
• 따라서 빌드 테스트가 진행되지 않아 빌드 에러가 나는 코드가 main으로 머지되는 일이 발생했다.
• 이를 해결하기 위해 PR이 작성될 때, 그리고 main으로 Merge될때 빌드 테스트를 진행하는 깃허브 액션을 추가했다.
• 프로젝트 마지막 날 코드를 많이 수정했는데 깃허브 액션 덕분에 main 브랜치를 잘 보호할 수 있었다.

02. 아쉬웠던 점

• React query 키 관리가 잘 안된 것 같다
• 이슈 관리가 잘 되지 않았다
• 기능 구현에 급해서 에러를 잘 처리하지 않았다. 그래서 발표 때 서버이슈로 어플리케이션이 동작하지 않는 상황이 발생했을 때 어플리케이션에서 적당한 대처를 하지 못했다
• 코드리뷰를 인원만 정해놔서 특정 인원들만 코드리뷰를 많이 해준 것 같다
• 팀원들에게 적극적으로 간섭하지 않았다. 예를 들면 페이지 단위로 useQuery를 사용하면 Suspense를 사용하기 어렵기 때문에 컴포넌트 단위에서 useQuery를 사용하라고 했어야 했는데 그렇게 하지 않았다.

03. 보완할 방법

• query key factory로 관리 or querykey를 함수로 추가
• suspense와 error-boundary를 초기부터 적용하기
• code-owner를 사용해서 코드 리뷰어를 자동으로 지정하도록 하자
• 코드리뷰 및 request change를 적극적으로 하자

04. 얻어 간 지식 및 경험들

1. husky, lint-staged, commitlint, commitizen으로 팀들이 편하게 일할 수 있는 시스템을 만드는 방법
2. React query 낙관적 업데이트
3. React Router의 eror element가 error boundary역할을 하는지 처음 알았다
4. Storybook 크로마틱에 배포 + ui 테스팅
5. 중간 점검 이후로 간트 차트를 사용해 일정을 관리했는데 태스크 현황과 재분배가 수월해서 좋았다.
6. Github action 사용해 본 경험
7. img의 srcset, width, height를 이용한 이미지 성능 최적화

05. 마무리

• 경험이 많은 팀원으로써 팀 프로젝트에 참여한 게 처음이라 팀원들에게 더 많은 도움을 주지 못한 것 같아 아쉽다.
• 성능 최적화를 위해 이미지 최적화, 코드 스플리팅에 대해 생각하고 있는데 다음 프로젝트에서 사용할 Next.js에서는 이미 이들을 최적화해서 제공하고 있다.
• Next.js 없이 성능 최적화해보고 Next.js와 비교해보면 좋을 것 같다.
• 프로젝트 동안 고생한 오프팀 다들 수고했어요!