🍊 JejuMonth 프로젝트 회고

약 5주간 진행했던 프로젝트의 배포와 발표가 마무리 되었다.
아직 고칠점이 많이 보이는 프로젝트 이지만 잠시 쉼표를 찍고 다시 나아가자는 의미에서 회고로 기록해보자.

프로젝트 결과물 jeju month 보러가기 jejumonth-github

---

프로젝트 준비

여행 서비스

이번 프로젝트의 요구사항은 기본적인 커뮤니티, 유저기능, 소셜 서비스기능을 구현하면서 open api를 활용하는 것이였다. 여기서 open api라는 것의 범위가 매우 넓었는데 첫주는 각자 흥미로운 컨텐츠를 제공하는 open api를 조사해보았다.

등산, 자전거대여 서비스, 제주도 여행 서비스, 도서서비스등 다양한 의견들이 많이 도출되었다. 팀 회의에서 사용할 api를 고르면서 자연스럽게 서비스주제에 관해 토의하게 되었다. 우리팀에서는 open api에서 제공하는 데이터에 사진이 들어가 있을 것, 다양한 정보를 제공해 줄것, 이미 만들어진 서비스를 카피하지 않고 우리팀만의 고유 기능을 넣을 것등을 고려해서 제주도청에서 제공하는 visit jeju api를 활용하기로하였다.

Jeju month

제주도청에서 제공하는 제주도의 여행지와 축제, 관광,숙소, 음식 정보를 기반으로 제주 한달살이를 계획하는 사용자에게 여행계획 작성기능을 함께 제공하는 서비스를 만들기로 했다.

주요 기능들로는 여행 커뮤니티, 여행 계획 작성 및 보기, 여행 장소 검색 및 스크랩등이 있다.

기획 및 디자인

기획과 디자인 단계에서 다양한 툴을 사용해본 프로젝트이다.
기획 명세서 작성을 위해 notion, IA와 와이어프레임 작성을 위해 miro, 디자인 시안 작성을 위해figma를 활용하였다.

문서화

팀장님을 제외한 다른 팀원분들의 협업 경험이 적어서 코드 컨벤션, 문서화 방법등을 미리 정리해가고 팀원들의 의견에 맞게 수정해가는 방식으로 프로젝트를 진행했다.(해당 내용은 팀위키에 정리되어 있다.)

프로젝트 관리에는 github을 사용했다. pr템플릿, 이슈템플릿을 정하고 merge는 1명이상의 승인을 받아야 가능하도록 했다. issue를 작성할 때에는 기능 요구사항을 세분화하여 커밋단위를 통일시키는 방법을 제안했다. 이전 프로젝트에서 이슈를 적극적으로 활용하지 못해서 아쉬웟는데, 확실히 협업인원이 많아질 수록 다른 팀원이 현재 어떤 작업을 하고 있는지, 어떤 작업이 남았는지를 이슈탭과 스크럼을 통해 확인할 수 있어서 효율적으로 진행할 수 있었다.

프로젝트 시작

프로젝트 개발이 시작되고 환경설정과 폴더구조화를 맡게 되었다. 확실히 초반 작업에 시간이 걸릴지라도 기반을 잘다져놔야 코드 구현이 수월해지기 때문에 해당 단계를 꼼꼼히 체크하기를 추천한다.

먼저 vite기반으로 프로젝트를 세팅하고 tailwind, antd와 같은 필요한 라이브러리 설정을 한뒤 eslint(air-bnb style), prettier를 설치해서 팀원모두가 동일한 코드 스타일을 가지도록 하였다. 이어서 react-query, redux, react-router를 사용하기 위한 프로바이더를 연결해주었다.

해당 프로젝트에서는 중간에 진행하긴 했지만 vite-javascript 를 사용한다면 상대경로 대신 절대경로로 파일을 임포트 할 수 있도록 설정하는 것을 미리 권한다.

// vite.config.js
export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: [
      { find: '@', replacement: '/src' },
      { find: '@public', replacement: '/public' },
      { find: '@pages', replacement: '/src/pages' },
      { find: '@components', replacement: '/src/components' },
    ],
  },
});

또한 tailwind를 사용한다면 tailwindcss-preset-px-to-rem를 사용해서 pxr 단위를 사용하는 것을 추천한다. 이렇게 하면 figma상에서 구현된 px단위를 개발시에 사용할 수 있으며 실제 브라우저에서는 Rem단위로 적용되어 매우 편리하다.

사진은 해당 기능을 도입하여 올린 pr 내용이다..

Keep, Problem, Try

KEEP : 잘했던 점, 앞으로의 프로젝트에도 유지해야할 사항

1️⃣ 내 코드 뿐 아니라 올라온 PR을 모두 확인하고 적극적으로 코드리뷰를 하려고 노력했던 점.

내 코드 뿐 아니라 동료의 코드를 보면 다양한 구현방식에 대해서 알게된다. 대표적으로 여러 api를 순차적으로 가져와야할 때 사람마다 구현방식이 달라서 어떤 방법이 좋은지 고민해보는 계기가 되었다.

또한 나와 비슷한 로직을 작성하는 동료의 코드를 보면 이를 모듈화해서 사용하는 방법이 떠오르게되고 결국 전체 팀 생산성에 큰 도움이 된다. 이번 프로젝트에서도 다른 사람의 코드를 읽으면서 공통되는 로직을 분리한 'useMySelector'와 'useQueryString','useAuth'훅을 만들었다.

리뷰를 하면 시야를 프로젝트 전체로 넓게 가지게 된다. 주석을 통해 어떤 고민을 하는지 알 수 있고, 특정 컴포넌트가 내가 담당한 페이지 뿐아니라 다른 페이지에서도 반복적으로 쓰인다면 공통 컴포넌트로 만들수도 있다.

2️⃣ 공식문서로 지식을 쌓았던 점.

이전에는 남이 소화한 지식을 보는 블로그에 먼저 손이 갔다면,프로젝트를 진행하면서 Axios, Redux, Tanstack-query의 공식문서를 읽고 나의 지식으로 소화하려는 노력을 기울였다.

이는 과정중에서 진행한 타입스크립트 스터디, 리액트 공식문서 스터디의 영향이 컸다고 생각한다. 좀더 어려운 글을 읽으려고 시도하니 읽기능력이 더 향상된 것같고, 특히 공식문서에서 설명하는 영어단어로 익혔을 때 직관적으로 이해할 수 있는 점들이 있어서 이제는 공식문서를 먼저 찾아보는 습관이 들었다. 혹여 지식을 완벽하게 암기하고 있지 않더라도 '해당 개념이 여기 있었지'라고 떠오르면 찾아서 읽고 다시 찾아보는 횟수가 현저히 줄어들게 되었다.

3️⃣ 프로젝트 중간마다 리팩토링을 진행했던 점.

아주 여유있지는 않았지만, 빈 시간이 생길 때마다 이전 코드를 복기하고 개선점을 찾으려고 노렸했다. 특히 이번프로젝트는 혼자하는 프로젝트가 아니였기 때문에 타인도 이해하기 쉬운 코드를 짜야겠다는 목표가 있었다.

예를 들면, 여행 계획을 등록하는 과정을 멀티스텝폼으로 구현하면서 다른 동료들이 보았을 때에도, 추가 설명없이 코드만으로 등록과정이 이해됬으면 하는 바램이 있었다.여기서 토스의 useFunnel 라이브러리를 구현과정을 설명하는 영상을 접하게 되었고 이를 해당 프로젝트에서도 적용해보았다.페이지를 넘나들며 상태를 변경하는 방식대신 하나의 페이지에서 각 단계의 흐름을 파악할 수 있도록 하였다.
onNext, onSkip, onBack을 통해 각단계의 이전단계는 무엇인지, skip시 어디로 이동하는지를 한눈에 파악할 수 있다.

 return (
    <div>
      {step === 'SEARCH' && (
        <Search
          onBackClick={handleBackClick}
          onNext={data => {
            // "장소 이미지 "클릭시
            setDetail(data);
            setStep('DETAIL');
          }}
          onSkipDetail={data => {
            // "선택"버튼 클릭시
            setRegisterData(prev => ({ ...prev, ...data }));
            setStep('TIME');
          }}
        />
      )}

      {step === 'DETAIL' && (
        <Details
          onBackClick={() => {
            setStep('SEARCH');
            setDetail('');
          }}
          onNext={data => {
            // 일정 생성 클릭시
            setRegisterData(prev => ({ ...prev, ...data }));
            setStep('TIME');
          }}
        />
      )}

      {step === 'TIME' && (
        <div className=" h-full">
          <RegisterDayAndTime {...RegisterTimeProps} />
        </div>
      )}
    </div>
  );
};

problem : 아쉬웠던 점, 앞으로 개선해야할 사항

1️⃣ bottom up 개발의 중요성

페이지 라우터, api엔드포인트를 객체상수로 관리해야겠다는 생각이 있었는데 이를 좀더 빨리 프로젝트에 도입하지 못했다. 결국 마지막 주차에 몰아서 정리를 하게 되었는데 프로젝트 초반부터 미리 정하고 갔더라면 후반에 다시 코드를 정리하는 작업을 하지 않아도 되었을것 같다.
해당 과정을 어떻게 정리하고자 하였는지는 qeury key 구조화 과정과 함께 포스팅할 예정이다!

2️⃣ 기획, 설계의 중요성

기획은 매우매우 중요하다. 프로젝트 전체의 청사진을 그리고, 우리 서비스가 해결해야할 문제를 정의하고, 사용자에게 어떤 데이터를 어떻게 보여줄지를 결정하는 과정이기 때문이다.

이번 프로젝트에서 기획단계에서 놓친 부분 두가지가 있었다.
1. 데스크탑 view와 모바일 view에 어울리는 UI는 따로있다.
여행계획 생성시 검색창을 모바일 뷰 스럽게 디자인했다는 피드백이 있었다. 레퍼런스한 서비스의 디자인을 그대로 가져온것인데, 이는 모바일화면에 맞는 Ui였다.
2. open api를 선택할 때는 풍푸한 정보를 제공하는 것을 선택하자.
비짓제주 API의 장점은 일관된 데이터로 생략되는 필드값이 적다는 점. 고화질의 사진을 제공한다는 점이였다. 다만 해당 관광지에 대한 상세정보가 description 필드로만 오기 때문에 다른 팀들에 비해 상세페이지가 빈약해보이는 단점이 있었다.

다음 프로젝트에서 open api를 선택하게 된다면 보다 충분한 정보를 제공하는 것을 선택해야겠고, 타깃 디바이스에 맞는 화면을 디자인해야겠다는 생각이 들었다.

try : 다음 프로젝트에 적용해볼 Action Item

1️⃣ 기술적으로 도전하기

기술적으로 도전하는 과제에 목말라있다는 팀장님의 마음이 이해가되었다.나도 멘토링에서 반복적인 게시판만 양산하는 포트폴리오가 되는것 같다는 고민을 말씀드렸었기 때문이다. 후반 멘토링을 통해 웹워커, 모킹 등 다양하게 도전할 거리가 주어져있어서 이후 성능개선을 진행하면서 기능을 추가해보려한다!

2️⃣ 감정적으로 공감하며 커뮤니케이션하기

나는 대문자 T 성향이라 상대방을 논리적으로 설득시키겠다는 마음이 앞서 동료의 마음을 먼저 헤아리지 못할 때가 많다. 이런 단점을 알기에 나도 의식적으로 독성말투를 지양하려고 노력하고있다.

이번 프로젝트에서 팀장님의 커뮤니케이션 방법이 나와 달라서 많이 배웠다. 프로젝트 초반에는 axios 인스턴스를 생성하지 않고 생(?)으로 사용하고 있었는데 여러 요구사항이 추가되면서 axios인스턴스를 생성하고 인터셉터로 에러를 핸들링하는것이 좋겠다는 의견을 팀에게 어필했었다. 하지만 api 연결이 활발하게 진행되던터라 해당기능을 바로 추가하면 충돌이 많이 발생할것 같다는 팀장님의 의견이 있어서 다른 동료들이 기능을 완성할때까지 보류하면 어떻겠냐는 피드백을 받게되었다. 사실 속으로는 인스턴스 추가하는 것정도의 변경이 충돌을 고려해야되는 것인지 크게 납득되지는 않았지만 '정수님이 하고 싶으신게 느껴져요 이해되요'한마디에 자연스레 의견을 굽히게되었다. 상대를 설득하는 것은 논리적인 설명 뿐아니라 상대의 마음을 헤아리는 것도 고려해야 한다는 점을 알게되었다.

3️⃣ 많은 사람에게 피드백 받기

강사님과 멘토님께 여러번 피드백 받으며 미처 생각치 못한 부분에서 개선해야할 점을 찾게되었고, UX 관점에서 무엇을 신경써야하는지 알게되었다.

이번 프로젝트에서 서비스의 첫인상인 메인페이지를 맡게 되어서 가장 피드백을 자주 받게되었다. 배포 후에 멘토님께서 직접 서비스를 사용해보는 모습을 보게되었는데, 캐러셀을 무한으로 넘겨보기, 로그인 폼에서 유효성 처리, 캘린더를 여러번 클릭했을 때 버그는 발생하지 않는지 등을 중점적으로 보셨다.
실제로 개발자도구로 css를 만져보시며 반응형 레이아웃에서 고려해할 점들을 짚어주셔서 개선사항에 추가할 수 있었다.