코드스테이츠 프론트엔드 44기 main-project회고

https://letsmomo.netlify.app/

MOMO

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

GitHub - codestates-seb/seb44_main_001

메인화면

디자인과 기능이 정해져 있던 프리프로젝트와 달리 기획부터 디자인, 배포까지 만들어나가는 메인프로젝트가 끝이 났습니다. 아쉬운 점이 많지만 그래도 구현한 기능들은 큰 에러 없이 제대로 동작하며 백엔드와의 데이터연결과 배포에 성공했다는 점에서 스스로 박수를 쳐주고 싶네요. 

 

 

제가 구현한 기능들은 아래와 같습니다.

• 글목록 페이지 (R)
  • 글 목록
  • 필터링
  • 검색기능
  • 무한스크롤
• 검색결과 페이지 (R)
  • 검색 결과 가져오기
• 글 상세 페이지
  • 좋아요 기능 (CRD)
• 404 페이지
  
  
• 유저정보 페이지 (R)
  • 내가 쓴 글 목록
  • 내가 좋아요 한 글 목록
• 유저정보 수정 페이지 (U)
  • 유저 정보 수정

 

4L(Liked, Lacked, Learned, Longed)회고 템플릿에 따라 메인 프로젝트의 회고를 작성해 보겠습니다.

👍🏻 Liked (좋았던 점)

- 멘토링

현업에 종사하고 계시는 멘토분들을 팀당 프론트 한 분 백 한 분씩 붙여주신다고 해서 처음에 이렇게 까지 코스에서 메인프로젝트에 지원을 해주시다니 정말 감사하면서도 놀랐습니다. 저희 프론트 멘토분은 풀스택으로 경력이 5년 이상인 분 이셔서 프론트와 백의 상황을 둘 다 여쭤볼 수 있어서 좋았습니다.

 

한 번 아하 모먼트가 있었던 적은 저희 프로젝트에서 지역과 카테고리 데이터를 어떻게 관리해야 하는지에 대해서 여쭤보았을 때입니다. 백엔드와의 데이터 동기화를 위해서 페이지가 랜더링 될 때 데이터를 받아와서 react-query의 캐싱기능을 이용하거나 좀 더 효율성을 위해서 해당 데이터가 필요한 컴포넌트가 랜더링될 때만 요청하여 로컬스토리지에 저장하는 방법을 제안해 주셨습니다. 

 

이렇게 애매하거나 어려운 부분을 질문드리면 명쾌한 답을 내려주시고 오픈카톡방, 수시로 질문할 수 있는 리스트 등 소통할 수 있는 창구도 만들어 주셔서 감사했습니다. 데모데이 때 마지막 1:1 멘토링도 진행했는데 매우 유용한 시간이었고 카톡방도 유지해 주신다고 해서 앞으로 생기는 질문들도 계속할 수 있게 해 주셨습니다. 정말 운이 좋은 팀입니다!

진짜 가수 딘에서 영감받은 이름이라는..

 

- 팀워크

정규시간에는 무조건 팀 채널의 모각코방에서 작업을 진행했습니다. 항상 모두 상주해 주시니 필요한 사항이 생기면 질문하기 수월했고 각자 무슨 작업을 하고 있는지 파악할 수 있었습니다. 뿐만 아니라 질문방과 버그신고방 개설로 목적을 분리하여 같은 문제가 생겼을 때 찾아보기 쉽고 의논하기 편했습니다. 

 

한 달 동안 진행되는 프로젝트에 지칠 만도 한데 유쾌하게 힘듦을 이겨냈습니다. 보통 제가 주도적으로 채널을 만들곤 했는데 아래 두 개의 채널은 익명의 팀원분께서 만들어주셨습니다😂 꼭 끝내야 하는 작업이 있을 때 감옥에 스스로 들어가 있는 모습이 재밌었고 힘들 때마다 해당 채널에 웃긴 짤들을 남기는 것도 다른 팀원들에게 웃음을 주었습니다. 전체회의 때마다 계속 웃긴 에피소드들이 있어서 가끔 들어가 채팅을 다시 보곤 하는데요 그만큼 저희 팀원분들이 즐겁게 프로젝트에 임해주셔서 감사할 따름입니다 👍🏻

 

웃는건지 우는건지 모르는짤 올리는 방

간수는 본인입니다

🙂 Lacked (아쉬웠던 점)

- 배포 시점

프리프로젝트에서 배포를 먼저 하라는 팁을 전수받았지만 실천하지 못했습니다. 배포를 같이할 줄 알고 백엔드 분께 배포를 일찍 해달라고 전달은 했었지만 저 역시 기능 구현에 집중하느라 배포 시기를 놓쳤던 것입니다. 문득 과제 제출 1주 전에 생각나 서버 http 배포를 했으나 과제 제출 4일 전 배포한 클라이언트 배포 환경이 https인 관계로 부랴부랴 백엔드 분께서 도메인을 직접 구입하여 ssl인증을 받고 https로 최종 배포에 성공하였습니다. 후일담을 들어보니 https 인증받기 어려워서 눈물 날 뻔하셨다고...😂

https와 고군분투하고 계신동 안 저는 과제 제출 단 며칠 전이라 버그 잡기도 바쁜데 이 모든 게 배포가 안된다면 물거품이 된다는 생각에 머리가 아팠습니다. https에서 http 통신하는 방법도 아래와 같이 찾아보았지만 저희 프로젝트에서는 동작하지 않았습니다.

https://velog.io/@jiheon788/Netlify%EC%97%90%EC%84%9C-HTTPS-HTTP-%ED%86%B5%EC%8B%A0-%ED%95%B4%EA%B2%B0-%EA%B3%BC%EC%A0%95
https://wellsw.tistory.com/34

Netlify에서 HTTPS -> HTTP 통신 해결 과정

Mixed content 문제 해결(https 사이트에서 http 사이트 요청 시 발생하는 보안 문제)

그리고 백엔드와 함께 배포하는지 따로 배포하는지에 관해서도 멘토님께 여쭤봤는데 현업에서는 보통 따로 한다고 하셨습니다. 같은 깃허브 레포를 사용하니 merge 하는 코드가 바로 반영이 되어 같이 배포하는 게 편해 보였는데 말이죠! 같이 배포하게 된다면 성능문제가 생길 수 있고 따로 배포하게 된다면 각각의 서버를 필요에 따라 별도로 확장시킬 수 있어 트래픽이 증가하더라도 성능을 유지하기 좋다고 합니다. 
사실 작은 규모의 프로젝트라 같이 배포했어도 상관없을 듯했으나 배포 방법에 대한 이유를 한번 더 생각해 볼 수 있는 기회가 되었네요.

 

- 기록

개인적으로 에러로그를 남긴 게 거의 없어서 아쉽고 전체회의록도 보통 디스코드 채널 내에서 모든 소통이 이루어지고 웬만한 기록이 남겨져 있다 판단, 생각이 들어서 노션에 기록 문서화를 제대로 못한 부분이 있습니다. 다른 팀들 노션 페이지를 살펴보았을 때 하루에 2번씩 회의록을 남긴 팀도 있더라고요. 매일 기록을 잘하고 싶어 하지만 놓치는 부분이라 분명한 개선이 필요합니다. 마지막 멘토링 때 습관화의 중요성에 대해서 멘토님이 강조를 해주셨는데요 PR이나 코드작성할 때를 포함해서 기록 또한 습관화를 시키기 위해서 노력하겠습니다.

 

 

🤓Learned (배운 점)

- React-Query

프리 때 사용해보고 싶었던 React-Query를 사용하면서 불명확했던 이 라이브러리의 특징을 알 수 있었습니다.

React-Query는 데이터 패칭, 캐싱, 동기화, 서버 쪽 데이터 업데이트 등을 쉽게 다룰수있게 도와주는 리액트 라이브러리입니다.

특정 시간마다 계속 요청을 해서 최신 데이터를 받아올 필요 없이 리액트 쿼리는 시간이 조금 지나면 데이터가 유효하지 않다고 간주하고 데이터를 다시 불러옵니다. 이때 데이터 변경점이 있는 경우에만 리랜더링이 일어납니다. 다른 브라우저탭을 보고 있다가도 돌아오면 사용자는 항상 최신의 데이터를 볼 수 있습니다.

 

저는 이번에 글목록 페이지를 구현하며 React-Query의 useInfiniteQuery훅을 사용했습니다. 

데이터는 스크롤을 내릴 때마다 9개씩 랜더링 되면서 이미 로드된 데이터는 캐시되고 사용자가 페이지를 스크롤하여 새로운 데이터를 요청하더라도 이전에 로드된 데이터를 재사용하게됩니다.

 

https://tanstack.com/query/v4/docs/react/reference/useInfiniteQuery

useInfiniteQuery | TanStack Query Docs

https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API

Intersection Observer API - Web APIs | MDN

  const {
    data,
    fetchNextPage,
    hasNextPage,
    isLoading,
    isError,
  }: UseInfiniteQueryResult<CardData[], unknown> = useInfiniteQuery(
  		//의존성 배열 : 검색어, 선택된 지역, 선택된 카테고리
    ['filteredList', keyword, selectedCategoryId, selectedLocationId],
    ({ pageParam = 1 }) => {
		// 생략
      return getData(urlPath, searchData, categoryId, locationId, pageParam);
    },
    {
      getNextPageParam: (lastPage, allPages) => {
        const nextPage = allPages.length + 1;
        return lastPage.length === 0 ? undefined : nextPage;
      },
    },
  );

 

useRef훅과 Intersection Observer API를 이용해서 스크롤이 바닥에 닿을 때마다 hasNextPage가 true라면 fetchNextPage를 호출했습니다. 

이외에도 useInfiniteQuery는 다양한 속성을 제공하는데요 특히 isLoading, isError는 로딩 중이거나 에러발생 시에 대한 처리를 쉽게 할 수 있어서 유용하게 사용했습니다.

  if (isLoading)
    return (
      <Loading>
        <img src={roundingMomo} alt="loading" />
        <div className="message">로딩중...</div>
      </Loading>
    );

  if (isError)
    return (
      <Error>
        <img src={cryingMomo} alt="error" />
        <div>서버와의 연결이 끊어졌어요</div>
      </Error>
    );

 

- 폴더구조

팀원분 중 한 분이 제안한 폴더구조 전략입니다. 

📦src
 ┣ 📂common
 ┣ 📂pages
 ┃ ┣ 📂Details
 ┃ ┃ ┣ 📂api
 ┃ ┃ ┣ 📂components
 ┃ ┃ ┣ 📂views
 ┗ 📜vite-env.d.ts

common : 2개 이상의 컴포넌트에서 사용되는 파일( 컴포넌트, 훅 포함 ex. Header, Footer, custom hook) 

pages : 페이지에 해당되는 컴포넌트들

ㄴ api : 네트워크 요청 파일

ㄴ components : 해당 페이지에서만 사용하는 컴포넌트들

ㄴ views : 해당 페이지의 최상위 컴포넌트

 

처음에는 폴더가 너무 많고 할 일이 많아 보여서 복잡해 보였지만

한번 익숙해지고 나니 각 폴더의 목적이 명확해서 필요한 컴포넌트 찾아가기도 편하고

프로젝트 파일을 봤을 때 깔끔해서 좋았습니다.

 

- 깃 전략

처음 원본 레포를 전달받았을 때 가장 처음 한 일은 main과 dev 브랜치에는 바로 merge 할 수 없게 막는 일이었습니다.

앞서 협업 프로젝트를 할 때 다른 사람의 코드를 확인도하고 혹시 잘못된 코드가 바로 merge 되지 않도록 특히 main에 merge 하지 않도록 막는 방법으로 깃을 사용하면서 최소한의 혼란을 없앨 수 있었습니다.

 

그리고 팀원이 제안해 주신 추가적인 깃 전략이 있었습니다.

1. 각자 계정에 원본레포를 clone 하고

2. 작업한 내용을 본인 레포에 push 한 후

3. 매일 아침 10시 전에 원본레포에 PR을 날리고 

4. 팀장이 화면공유하면서 하나씩 PR을 merge 승인하고 컨플릭이 나면 같이 해결한다.

 

이 방법 또한 처음엔 복잡해 보였지만 한번 익숙해지고 나니 오래 걸리지 않고 브랜치별 목적을 분명히 하게 되며 다 같이 컨플릭을 해결하니 정확하게 문제를 해결할 수 있었습니다.

🫡Longed for (앞으로 바라는 점)

- 게시판 자체가 게시글 CRUD, 유저 CRUD 외에는 특별한 기능을 가지고 있는 건 아니기에 기가 막힌 한 방이 꼭 필요했습니다. 그게 채팅으로 그나마 해소되었지만 아무래도 이번 프로젝트에 시간이 조금만 더 있었으면 구현했을법한 부분들 (꼼꼼한 UI, UX , 알림 기능 등)이 자꾸만 떠올라 아쉽습니다. 물론 각자의 자리에서 모든 팀원이 열심히 작업해 주셨지만 더 잘 해낼 수 있었던 부분들이기에 더욱 아쉽고 그게 목표 기간을 추상적으로 잡은 게 원인이 아닐까 싶습니다. 모모에 앞에서 언급한 기능구현을 앞으로 덧붙여볼 계획인데 명확하게 기능과 해당 기능의 구현 목표 날짜를 잡고 해내는 방식으로 진행하고 싶네요. 

 

 

+ 의문의 스택 보드

이전 기수 분들 레포 리드미를 보면 이렇게 귀여운 블록형태의 스택 보드를 볼 수 있었는데요 도무지 어디서 만들 수 있는건지 검색을 해봐도 아무리 안나오다가 팀원분이 찾아주셨습니다.

https://www.cloudcraft.co/

Cloudcraft – Draw AWS diagrams

처음엔 이렇게나 블럭 하나씩 이미지를 불러와서 크기를 맞추는 등등 시간을 많이 쏟아야하는 작업인가..? 자동화가 없나..? 라는 생각에 더 찾아보고 다른툴을 써보기도 했는데요 결국 인내심을 가지고 하나씩 이미지를 맞춰서 겨우 완성했네요. 이 작업만 한 2시간 남짓 걸렸던것 같습니다.

피그마로 어떻게든 해보려던 노력..