[Project] 🔥모락모락 프로젝트 최종 회고🔥

🔗Links

Github : https://github.com/codestates-seb/seb40_main_004

배포 링크 : https://seb40-main-004.vercel.app/

팀 노션 : https://www.notion.so/Lab-HOME-bdd0941f584b43d1a9d2f735623d2b86

발표 문서 : https://www.notion.so/40-Team004-2317c8a3bc1a413aa9abf61052330824

🔥프로젝트 소개

개요

11월 초부터 시작해 12월까지 5주간 진행했던 "모락모락" 프로젝트가 끝이 났다.

프로젝트에 대해서 간략하게 소개하자면, '질문이 두려운 개발 뉴비'를 타겟으로 한 '따듯한 개발자 커뮤니티' 컨셉의 프로젝트이다. 누군가 질문에 답변을 달면 질문자는 답변자에게 따듯한 후기와 경험치(모락)을 후원할 수 있고, 그에 따라 랭킹도 집계된다. 대시보드에서는 본인이 작성한 게시글과 답변, 그리고 받은 후기 메시지와 태그를 확인할 수 있다. 

기간

2022년 11월 01일 ~ 2022년 12월 07일

역할

1. 프론트엔드 개발자 1로(ㅋㅋ) 게시글 리스트와 상세페이지, 답변, 코멘트 등 CRUD 로직 및 채택기능을 담당했다.

2. SWR을 활용한 데이터 캐싱을 적극 활용했다.

3. axios interceptor 를 활용해 리프레시 토큰을 활용한 액세스 토큰 갱신 로직을 담당했다.

4. 분야는 다르지만 어쨌든 디자인 스킬을 살려서 전반적인 UI 디자인을 주도했다. 피그마를 사용해 프로토타입을 제작하고 메인 컬러, 보조 컬러, 폰트 컬러등을 정해 UI에 전반적인 통일성을 주려고 노력했다. 메인에 들어가는 이미지 같은 것도 작업했다..ㅎㅎ

5. next.js 의 SSR 기능을 사용해 SSR 을 구현했다.

6. 리액트 퀼 에디터에서 presignedUrl 에 이미지를 업로드하고 프리뷰를 생성하는 로직을 담당했다. 

스택

• Typescript
• Next.js
• SWR
• Recoil
• Tailwind CSS
• React hook form, React Quill ...

협업 방식

• 팀 전체 소통, 백엔드와 프론트엔드 소통은 노션과 피그잼을 적극 활용했다. 페이지별로 사용할 api 에 대해서 논의를 나누는 공간을 만들어 관리했고, 또 각자의 진행상황이나 협의 사항은 오후 데일리스크럼을 통해 진행했다. 

• 프론트끼리는 오전 11시에 모여 세부적인 진행사항과 컨디션 등을 체크했다.

• 깃은 프론트, 백엔드 공통 컨벤션을 만들어서 사용했고, pr 시 간단하게나마 코드리뷰를 진행했다. 서로의 코드를 보면서 몰랐던 부분도 알게 되었고 또 다른 팀원의 실수도 방지할 수 있어서 깃을 문제없이 활용하는데 도움이 되었던 것 같다. 

🔥담당 기능 & DEMO

게시글 상세페이지 : 답변, 코멘트, 좋아요, 북마크 등...

• SWR 을 적극 활용해서 데이터 캐싱 + 최신화가 되도록 신경썼다. 답변이나 댓글 같은 경우에도 새로고침 없이 데이터를 최신화하고 싶어서 SWR 의 mutate 기능을 적극 활용했다.
• 리액트 퀼 에디터에서 S3 presignedURL 로 이미지 업로드 요청을 보내는 로직을 작성했다.
• 이미지 업로드의 경우 별도의 모듈 대신 리액트 퀼에서 기본 제공하는 이미지 업로드 기능에 이미지 핸들러 함수를 사용해 업로드 이벤트를 감지하도록 했다.
• 업로드 이벤트를 감지하면 서버에 presignedUrl 을 요청하여 받아오고 해당 주소로 PUT 요청을 보내 S3에 이미지를 업로드한다. 그 뒤 presignedUrl 에서 권한 부여되는 파라미터 전까지 url 을 잘라서 퀼에 임베드를 하면 이미지 프리뷰를 띄울 수 있다. 

답변 채택/후기 보내기

• 자신이 작성한 게시글에 답변이 달리면, 답변 중 한 가지를 채택할 수 있다. 로그인 여부 및 본인 게시글 여부를 확인해서 버튼 표시/숨김처리를 꼼꼼하게 해주었다 ㅎㅎ
• 답변 채택하기 페이지로 넘어가면 최대 3개까지 후기 태그를 선택할 수 있는데, 후기 태그 선택이 완료되면 나머지 태그들은 disabled 상태가 되도록 구현했다. 
• 모락이라는 포인트 제도가 있는데, 해당 포인트를 최대 500 모락까지 후원해줄 수 있다. 이 모락 총액을 바탕으로 회원 랭킹이 결정되는 시스템이 있다.
• 각 단계의 데이터를 전역 상태로 등록해 두었다가 최종적으로 채택 버튼을 눌렀을 때 서버에 전송되도록 했다. 
• 답변이 채택되면 채택된 답변은 상단으로 이동하고 컬러가 변경된다 ㅎㅎ

게시글 리스트 : 정렬, 검색 등...

• 백엔드에서 조건과 키워드를 잘 입력하면 그에 맞게끔 결과를 응답해주는 통합(?) api 를 잘 짜주셔서 편안하게 사용할 수 있었다.
• 검색창에 입력되는 키워드와 태그, 정렬 드롭다운의 내용등을 모두 상태로 등록해놓고 해당 상태를 fetcher 함수의 url에 사용해 상태가 변함에 따라 요청이 되도록 구현했다.
• 이 부분도 각 페이지네이션 데이터마다 캐싱을 적용했다. 그리고 페이지네이션 버튼은 라이브러리를 사용할까 하다가 테일윈드로 스타일링하기가 힘든 부분이 있어서 직접 구현했다. ㅎㅎ 쉽다고 생각했는데 막상 하려니 다음 번호 그룹을 보여주도록 하는게 어려웠당🤭
• 게시글 리스트에 대해서 로딩 컴포넌트를 만들어 적용해보았는데, 나중에 기회가 되면 스켈레톤 ui로 만들어보고싶다. 높이가 잘 맞지 않다보니 크게 깜빡이는 것처럼 느껴져서 사용성이 살짝 아쉽다. 

로그인, 회원가입 유효성 검사 등...

• 지난 프리 프로젝트때와 마찬가지로 react-hook-form을 사용했다. 한가지 차이점은, 지난 프로젝트때는 formState라는 객체의 존재 여부를 몰라서 에러 메시지를 모두 상태로 등록해서 커스텀 인풋에 전달해주었는데, 이번에는 다른 팀원이 하신 코드를 보고 거기서 살짝 응용하여 컴포넌트화 하였다 ㅎㅎ
• 이번에 살짝 어려웠던것은 퀼 에디터에 어떻게 register 를 등록하느냐였는데, register 라는 것을 꼭 input 에 직접 등록하지 않아도 validation을 하는 formData 의 키 값으로 유효성을 검사하도록 등록을 해줄 수가 있었다. ㅎㅎ 

🔥이번 프로젝트를 통해 무엇을 배웠나?

새로운 기술 활용 : next.js / Typescript / SWR ...

이전에 사용해보지 않았던 타입스크립트를 조금 더 적극적으로 사용해볼 수 있었다. 사실 100% 잘 사용했다고 말할 수는 없을 것 같다. 리액트와 함께 사용하다보니 리액트의 이벤트에 대해서 타입을 지정해주는 부분이 좀 어려웠고, props 에 함수를 전달하게 될 경우 타입을 어떻게 지정해야할지 늘 헷갈렸던 것 같다.

 

다만 응답 데이터, props 데이터에 대해 타입을 지정해놓고 import 해서 사용하니 타입체킹을 통해 사전에 에러를 방지할 수 있어서 좋았고, 어떤 프로퍼티를 넘겨주어야 하는지 자동완성을 통해 쉽게 알 수 있어서 그 부분에서는 생산성이 많이 향상된 것 같다. 

 

next.js 같은 경우 처음에 게시글 데이터에 대해서 SSR을 적용하면서 공부를 많이 하게 되었다. SSR이 적용되면서 브라우저의 로컬스토리지에 접근할 수 없다는 것을 시간이 많이 흐른 뒤에 알게되었는데, 게시글 조회 부분에 액세스 토큰이 들어가면서 올바르지 않은 응답이 오는 현상이 있었다. 지금 회고를 쓰면서 생각났는데 굳이 액세스 토큰을 넣어서 조회 요청을 보낼 필요가 없는 것 같아서 추후에 수정을... 해야할 것 같다.

 

이번 프로젝트에서 SWR을 정말 잘 활용했다. 리스트 조회, 상세 조회, 코멘트와 답변글 등 내가 조회를 하는 모든 데이터는 SWR 을 활용했고, useSWR 훅을 다시 useFetch 라는 훅으로 가공해서 사용했는데 무척 편리했다. 만약 SWR이 없었다면 데이터의 구조를 파악해서 다 전역상태로 등록하던가 해야했을 것 같은데, 마치 전역상태를 불러와서 사용하는 것처럼 요청을 보내고 업데이트를 할 수 있다는 점이 큰 메리트였다.

 

뭐 각 기술을 어떻게 활용했고 기술적으로 무엇을 배웠는지는 추후에 따로 정리를 할 예정이다.

데이터 통신, 요청 방식과 처리 방식에 대한 고민

직접 기획한 내용을 가지고 진행을 하다보니, api 를 설계할 때도 프론트와 백이 논의를 해야될 부분이 꽤 많았다. 어떠한 기능에 대해서 어떤 데이터가 필요하고, 어떤 응답을 받아야 하고 이런 것들을 제대로 고민해보는게 처음이었던 것 같은데 재미있으면서도 상당히 어려운 부분이었다.

 

또 post 나 patch 처럼 데이터에 변화가 있을 때 화면에서는 어떻게 처리를 해줘야하는지, 업데이트를 위한 비동기 통신에 대해 많이 익숙해진 것 같다. 사실 비동기 통신, promise, asyn await 이것을 프로젝트 내내 사용했어도 딱 내가 사용했던 부분에 대해서만 알지 아직도 개념적으로 부족한 것은 사실이다.

 

하지만 발전한 부분이 있다면 지난 프로젝트에서는 한 페이지 내에서 일부분을 업데이트 시키기 위해서 페이지 전체를 새로고침 하는 방식을 사용했는데, 이번에는 SWR 라이브러리의 힘을 빌려 일부분만 업데이트가 되도록 구현했다는 점이다. 그것도 아주 쉽게. 전에는 이런 비동기 통신에 대한 이해가 정말 많이 부족했는데 이번에는 컴포넌트를 설계하는 단계에서 어느 부분에서 통신이 발생해야되고 이런 것까지 고민을 많이 해볼 수 있었던 것 같다. 

위와 같이 한 페이지 내에서 주요 기능을 담당하는 컴포넌트를 분리한 다음에, 각 컴포넌트가 어떻게 동작해야 하는지 데이터는 어느 시점에 어떻게 업데이트가 되어야 하는지 플로우차트를 그려가면서 정리하려고 노력을 많이 했다. 그 때는 mutate 라는 함수의 동작 방식에 대한 이해가 부족했기 때문에, mutate 함수에 url 만 전달하면 특정 시점에 알아서 조회하여 데이터를 업데이트 하도록 할 수 있다는 것을 몰랐다. 

컴포넌트 설계 방식

초반에 컴포넌트를 설계하면서 컴포넌트를 어느정도로 분리를 해야하는지 기준이 명확하지 않았었다. 처음에는 코드가 너무 길어지니까 그냥 길어지는 모든 부분을 컴포넌트로 분리해서 작성했다. 재사용이 되는 컴포넌트는 당연히 생산성이 높아지기 때문에 적절하게 분리하는게 맞지만, 그렇지 않은 컴포넌트까지 코드가 길어진다는 이유만으로 분리할 필요는 없다는 생각이 들었다.

 

이번에 깨달은 것은, 모든 방법론은 문제를 해결하기 위해 존재한다는 것이다. 내가 특별하게 불편함과 문제를 느끼지 못하는데 그 방법론을 무조건 따라야 하기 때문에 무리하게 도입하는 것은 오히려 좋지 않은 것 같다. 그래서 조금 편안하게, jsx 코드가 조금 길어보이더라도 이 페이지에서만 사용되거나 같은 state를 공유하는 경우에는 따로 분리하지 않았고 대신 정말 자주 사용되는 커스텀 Input 같은 경우 컴포넌트를 만들어서 정리했다. 

 

한 가지 아쉬운점은 멘토님도 지적하셨던 부분이지만 api 를 요청해 데이터를 불러오는 로직과, 컴포넌트의 view만 담당하는 로직이 한 컴포넌트에 합쳐져 있다는 것이다. 이게 동작하는데 있어서 당장 큰 문제는 없지만 분리가 되어있지 않다보니 가독성이 너무 떨어진다. 한 번은 삭제된 게시글을 다시 조회하면서 에러가 발생하는 현상이 있었는데, 코드가 너무 많아서 코드를 접어두고 수정하다보니 미처 발견하지 못했던 이상한 코드가 숨겨져 있었다. 또 에러메시지가 잘못 나가는 경우가 있었는데 이것도 너무 중구난방으로 위치해있다보니 비슷한 로직에 대해서는 재사용을 할 수 있도록 가공해서 쓰면 좋았겠다는 생각이 많이 들었다. 

🔥아쉬웠던 점과 보완할 방법

일정 관리, 문서화

지난 프리 때와는 다르게 이번 프로젝트 협업 부분에서 가장 아쉬웠던 점은 일정 관리와 문서화가 아닐까 한다. 초반 기획 단계 때부터 제대로된 문서화 단계를 거쳐서 어느정도 협의가 되었으면 백엔드에서도 api 를 설계하는데 큰 어려움이 없었을 것 같고 프론트에서도 어느정도 정형화된 틀이 있기 때문에 이를 참조해서 개발에 들어가기가 쉬웠을 것 같다.

 

우리 팀은 기획이 끝나고 백엔드는 바로 ERD 설계 및 API 개발에 들어가셨고, 프론트는 플로우차트 그리고 UI 디자인에 들어갔는데 이 과정에서 UI 가 나오고 난 다음에라도 좀 체계적인 단계를 거쳐서 문서화를 했으면 어땠을까 하는 생각이 든다. 사실 나는 플로우차트를 그리는 단계부터 백엔드 분들과 같이 했으면 서로 바라보는 그림이 같기 때문에 협의하는게 더 쉽지 않았을까 싶다. 이 페이지가 어떻게 동작하는지 다 같이 알고 있으면 어떤 방식으로 요청을 하고 어떤 데이터가 필요하다는걸 서로 알기 때문에 더 좋았을 것 같은데... 아쉬움이 많이 남는다. 

 

기획 단계가 중요하다는걸 정말 많이 깨달았고, 다음 프로젝트에서는 좀 힘이 들더라도 기획은 좀 더 꼼꼼하게 그리고 다 같이 하는게 좋을 것 같다.

소통은 어렵다.

서로 선호하는 방식이 다르기 때문에, 다른 사람들의 의견을 최대한 존중하려고 노력을 많이 했었다. 나는 기획 단계에서도 다 같이 진행하고, 어떤 문제점이 있어도 다 같이 공유하고 이런 분위기를 원했고 또 그게 맞다고 생각한다. 왜냐하면 다 처음이기 때문에..

 

우리가 능숙한 개발자라면 각자 위치에서 무엇을 해야하는지 너무나 잘 알고 있다면 꼭 다같이 하지 않아도 되겠지만... 우리팀은 초반에 이런 것을 선호하는 분위기가 아니었어서 크게 내 의견을 내기 보다는 받아들이자는 생각이었는데, 지금 와서 생각해보면 좀 더 강력하게 내 의견을 어필했으면 더 좋았지 않을까라는 생각이 든다.

 

처음에는 데일리 스크럼이라는 개념이 없이 주 2회 만나서 회고를 하자고 하셨었는데, 나중에는 데일리 스크럼을 하자는 의견이 받아들여져서 하루 30분이나마 서로 얼굴을 보고 얘기할 수 있는 기회가 생겼다. 이게 자리를 잡은건 프로젝트 중반 쯤이었던 것 같은데 나는 그 때 이 의견이 받아들여져서 데일리 스크럼을 시작할 수 있었던게 너무 다행이라고 생각한다.

 

데일리 스크럼에서 엄청난 내용은 없었고 그냥 각자 작업 진행 현황과 어려운 점, 컨디션도 체크하고 협의할 내용이 있다면 간단하게 협의하고 이런 식으로 진행을 했다. 나중에는 다들 익숙해지셔서 뭔가 착착 진행이 잘 되는게 기뻤다. 사실 이렇게 차츰 자주 대화를 나누고 소통을 하면서 나 개인적으로는 팀프로젝트에 대한 부담감이 좀 덜어졌던 것 같다. 함께 하는 사람들에 대해서 잘 모르고 또 무엇을 담당하는지 잘 몰라서 소통도 그렇고 프로젝트 진행도 그렇고 막연하게 두려움과 부담감을 많이 느꼈었고 잠을 제대로 자지 못한 적이 많다. 

 

이 프로젝트를 통해서 느낀 것은, 결국 사람이 중요하다는 것이다. 함께 일하고 싶은 개발자가 되는 것이 중요하다고 생각했다. 그 기준이 개발 실력이 될 수도 있고(뭐 그건 기본인가), 소통이 될 수도 있고 뭔가 특출난 능력일 수도 있지만 같이 일하고 싶은 개발자의 첫 번째 미덕은 역시 소통이 아닐까 싶다. 다른 사람들의 의견을 존중하고 경청하는 것도 중요한데, 내가 좋은 의견이 있고 거기에 근거가 명확하면서 확신이 있다면 또 자신있게 의견을 제시하는 것또한 팀이 발전하기 위한 중요한 소통 역량이 아닐까 싶다. 

🔥이제 나는 무엇을 할 것인가?

리팩토링(?)

• 뭔가 엄청난 리팩토링이라기 보다는 미비했던 부분에 대해서 보완을 할 것 같다.
• API는 있으나 구현이 되지 않았던 기능들이 있기 때문에 그에 대한 VIEW 와 기능을 만들어야 할 것 같다.
• 스켈레톤 UI를 적용해보고 싶은 욕심이 있다.
• 요청이 쓸데없이 여러번 가는 문제가 있어서 그 부분도 해결을 할 것 같다.

프로젝트에서 사용했던 기술 복기

• 프로젝트에서 사용했던 기술들을 다시 보면서, 어떻게 보완했으면 좋았을지 공부를 더 하려고 한다.

취업준비

• 이제 이력서와 포트폴리오를 준비하고, 각종 취업 관련 프로그램에 참여해서 취업 준비에 돌입할 것 같다. 

🔥마치며...

정말 여러가지 일들이 있었던 시간이었다. 프론트 팀원들의 컨디션 저하로 외롭게 개발을 하는 시간이 많아지기도 했었고, 기능 개발에 급급해 제대로 파고들면서 공부하고 정리할 시간이 부족했던 것 등... 하지만 그런 어려움들이 있었기 때문에 배운 점도 많고, 또 결국은 여의치 않은 상황에서도 모두가 끝까지 열심히 해줬기 때문에 이렇게 결과물이 나올 수 있었다고 생각한다. 

 

정말 아쉬운 점이 많은데, 진짜 개인적인 아쉬움으로는 내가 조금 더 나를 혹사(?) 시켰으면 좋았을텐데 라는 생각이 든다. 뭔가 한 발짝 더 나아가서 조금 더 주도적이고 진취적으로 도전했다면 더 좋은 결과가 있었을 것 같아서 그런 개인적인 아쉬움이 있다. 

 

그래도 너무 즐거웠다. ㅎㅎ