영상공유 SNS 플랫폼 개발 프로젝트 - MAZI

 

1. 개요

패스트캠퍼스 데브캠프: 김민태의 프론트엔드 개발 1기

비기너반 프로젝트로써 진행한 영상공유 SNS 플랫폼 개발 프로젝트 소개 및 회고를 해보겠습니다.

 

2. 깃허브 주소

https://github.com/Dev-FE-1/Toy_Project_3_BeginAgain

GitHub - Dev-FE-1/Toy_Project_3_BeginAgain

 

3. 팀원소개 및 역할분담

 

처음에는 7명으로 시작했던 비기너반이 최종적으로는 4명이 되어 프로젝트를 진행하였습니다. 특히나 프로젝트가 시작되고 기획 및 디자인 단계에서 두 분이나 개인 사정으로 부트캠프를 하차하게 되면서 충분하지 않은 시간 동안 완성할 수 있을지 걱정이 많이 되었지만 팀원 모두가 추석이나 정규 프로그램을 따라가야하는 우여곡절 속에서도 최선의 노력을 해주셨기에 프로젝트 완성을 할 수 있었습니다.

 

처음으로 팀장이라는 자리에서 프로젝트를 진행해보았는데 제가 실력이 좋다거나 프로젝트 경험이 많은 상태가 아니었기 때문에 어떻게 하면 역할을 잘 수행할 수 있을지 고민이 많았습니다. 저희는 비기너반으로써 개발 경험이 적은, 또 프론트엔드 개발을 이 부트캠프에서 처음 배워보는 수강생들이 모였던 상황이라 Git 사용이라던지 필수 컨벤션, 프로젝트 초기 세팅과 같은 부분에 익숙하지 않았습니다. 따라서 제가 Git Wiki에 이슈 생성법, PR 생성 및 리뷰법, 팀 컨벤션 등을 정리하여 팀원분들이 Git을 사용할 때 최대한 불편함이 없도록 조치를 해 두었습니다. 회의 전에는 정해야 할 부분 중에 너무 어렵거나 처음 접해보는 내용은 빼고 정말 필수적으로 정해야 하는 rule이나 코드 컨벤션 등을 간결하게 정리해보았고 노션 템플릿 등을 이용하여 기획이나 문서 작성 시 예시를 제시하여 시행착오를 최대한 줄이고자 했습니다.

 

- Git Wiki에 정리해둔 가이드 일부 발췌

 

⠀⠀⠀⠀⠀⠀⠀

역할분담의 경우에는 팀원들의 강점을 잘 살릴 수 있는 분야로 분담이 되었습니다. 아무래도 한정된 시간에 개발 시간을 최대한으로 가져가기 위해서는 기획과 디자인 단계에서 시간을 최소화하는 것이 필요했습니다. 기획에 경험이 짙으신 분이 유저플로우 등 전체적인 기획을 주도해주셨고, 디자인 경험이 있으신 분이 디자인과 추후 발표자료까지 맡아주셔서 효율적인 협업이 가능했습니다. 문서 작성 역시 초안을 작성하고 변경된 부분을 수정하는 식으로 진행했고, 다은님께서 노션 템플릿이나 기타 문서 예시를 주셔서 경험이 많지 않은 저희 팀에게 많은 도움이 되었습니다.

 

- Notion에 정리한 것 일부 발췌

 

 

4. 프로젝트 진행 방식

-  프로젝트 일정

2024.09.02 - 2024.09.27

 

- 온라인 진행

부트캠프 역시 온라인으로 진행되며 각자 거주하는 지역이 상이한 이유로 오프라인으로 모여 프로젝트를 진행하기 힘든 상황이었습니다. 따라서 프로젝트 역시 온라인으로 진행하였습니다. Zoom, Zep을 이용하여 정기 회의와 긴급 회의 등 팀원 모두가 공유해야 할 상황이 생겼고 구두로 설명하는 것이 좋겠다고 판단할 시 즉각적으로 모일 수 있었습니다. 회의록이나 트러블 기록 및 문서화하여 공유하면 좋을 내용은 Notion을 통해 정리했습니다. 수정해야 할 버그 등도 문서화하여 공유하고 해결한 버그는 지워나가는 식으로 진행하였더니 팀원 모두가 진행 상황을 파악하기 쉬웠고 해당 부분을 맡았던 팀원도 한 눈에 문제를 파악할 수 있었습니다. 또한 Slack을 통해 기타 공지나 멘토님과의 소통 등을 진행했습니다.

 

- 문서화

진행상황 공유와 회의에서 결정된 내용을 명확히 해두기 위해서 매 정기회의마다 회의록을 작성하였습니다.

* 트러블 슈팅

저희 팀이 프로젝트를 진행하면서 가장 힘들었던 부분은 Git 활용이었습니다. 토이프로젝트 1으로 프로젝트 경험이 있는 분과 개인프로젝트 진행으로 협업 프로젝트는 처음인 분이 섞여있었고, 이론 강의를 들었을 때와는 또 다르게 직접 버전관리를 하려니 혼란한 부분이 많았습니다. 예시로 저희는 회의를 통해 개발 기간에는 develop에 merge를 하여 진행하고 마지막에 모든 것이 완성되었을 때 main으로 한번에 merge하기로 규칙을 정했었습니다. 기획 및 디자인을 끝내고 기능 개발에 들어가는 날, 팀원 분이 main으로 병합하는 PR을 올리셨고 승인한 팀원들도 그 부분을 유념히 검토하지 않고 병합이 되는 실수가 발생했습니다. 이를 되돌리려고 저희끼리 노력해보았지만 역부족이라 부트캠프 다른 수강생 분들도 와서 도와주시다가 나중에는 멘토님과 매니저님까지 달려와 장장 8시간의 회의가 되어버린 상황을 겪게 되었습니다. 결국 너무 꼬여버려 본질적인 해결은 하지 못하고 repository를 하나 더 생성하는 걸로 결론을 내렸습니다. 

 

위에 설명한 사건 이후, 저는 어떻게 하면 이러한 상황을 방지할 수 있을까 생각하다가,

첫 번째, GitHub 자체에서 설정할 수 있는 Rulesets를 활용했습니다. 규칙을 설정함에 있어서 서윤님이 많이 기여해주셨는데, 서윤님이 제안해주신 방법은 main에 합병하는 PR의 경우 승인을 받아야 하는 팀원의 수를 3명으로, develop에 합병하는 PR의 경우에는 승인을 받아야 하는 팀원의 수를 2명으로 차이를 두어 혹시나 모를 상황을 미연에 방지하는 방법이었습니다. 실제로 이 규칙을 설정해 놓은 덕분에 한 두번정도 main으로 합병을 시도한 PR이 승인 과정에서 발견되었고 main에 합병되는 상황을 보호할 수 있었습니다.

 

 

두 번째, 노션에 트러블 상황을 정리하기 시작했습니다. 하단에 첨부된 사진과 같이 어떤 문제가 발생한 상황을 구체적으로 설명하고 어떻게 해결했는지를 정리해두어 추후 비슷한 상황이 발생했을 때 당황하지 않고 빠른 대응이 가능하도록 해보았습니다. 또한 혜진님께서 도움을 주신 부분인데, Git을 사용하면서 특히 버그가 발생했을 때, 개발 중 develop 브랜치가 업데이트 되었을때, 로컬에서 브랜치 생성하는 방법 등을 명령어와 함께 설명해주셔서 이를 정리하여 팀원들께 공유할 수 있었습니다. 이는 Git을 사용할 때 매우 유용한 참고자료로 사용할 수 있었습니다.

 

- 팀 컨벤션

git flow

• main: 개발 완료 후, 마지막에 사용할 브랜치
• develop: 개발 중 사용할 브랜치(프로젝트 기간 중 이 곳에 merge 해 주세요)
• feature: 각 기능 개발 시 사용할 브랜치
• bugfix: 버그 수정 시 사용할 브랜치
• style: 스타일 관련 변경사항이 있을 경우 사용할 브랜치
• help: 도움이 필요할 경우 사용할 브랜치
• test: 테스트 코드 추가 시 사용할 브랜치

PR규칙

• PR을 올린 자신 이외에 2명의 승인이 있어야 merge할 수 있습니다
• 승인을 한 사람이 머지와 브랜치 삭제까지 함께 진행합니다

commit 규칙

• 커밋은 다음과 같은 형태로 작성합니다

keyword: 설명

• 예시

git commit -m "feature: 다크모드 라이트모드 기능 개발"

 

- 코드 컨벤션

• 컴포넌트 이름: PascalCase 사용
• 폴더 이름: 소문자 사용
• 이벤트 핸들러: 'on'으로 시작
• 함수 및 변수명: camelCase 사용
• 상수: 모두 대문자로 작성하고 단어 사이에 _ 사용 ex) API_URL
• 커스컴 훅(Custom Hook): use로 시작 ex) useInput

 

- 기술스택

• Front : React, Typescript, Vite, emotion, Zustand, TanStack Query, Playwright
• Back-end : Firebase
• 버전 및 이슈관리 : Github, Github Issues
• 협업 툴 : Slack, Notion, Zoom, ZEP
• 서비스 배포 환경 : Netlify
• 디자인 : Figma

 

5. 주제와 목표

저희가 이번에 진행한 프로젝트는 영상공유 SNS 플랫폼 개발 프로젝트입니다. 사용자들이 만든 자신만의 영상 링크 기반(유튜브, Vimeo, Dailymotion, Twitch 등) 플레이 리스트를 공유하고, 구독하여 자신만의 타임 라인을 만들고 네트워킹 할 수 있는 SNS 서비스 구현을 해보는 것을 프로젝트 목표로 설정했습니다. 저희는 이에 그치지 않고 영상 공유에서 조금 더 주제를 좁혀보자는 의견에 따라 '운동 영상'을 공유하는 SNS 플랫폼으로 최종 결정하였습니다.

 

필수 구현 사항은 다음과 같았습니다.

1. 영상 링크를 사용자로부터 입력 받아 복수의 플레이리스트 작성 기능 개발
2. RESTful API를 설계하고 API 상태를 관리하며 다양한 UI 구성
   • 아래 두 가지 중 선택
     1. 입력 받은 데이터를 전역 상태에만 추가해 UI 구성
     • 로그인 정보도 JSON 데이터로 관리
     • RESTful API를 설계하여 API 통신으로 데이타를 불러와 다양한 UI를 구성하는 방법
3. 공개된 플레이리스트를 구독하여 자신만의 플레이리스트 타임라인 기능 개발
4. 영상에 좋아요, 댓글 기능 구현

• React로 프로젝트 개발
  • React를 이용하여 프로젝트 내 모델의 타입 시스템을 설계, 구축하여 개발 생산성 및 안정성향상
• 컴포넌트 아키텍처 모델 설계 필수
  • 폴더 구분, 공통 컴포넌트, 함수 컴포넌트, 컨테이너 컴포넌트 등
  • 데이터와 UI(뷰) 역할을 적절히 분리하고 적절히 제어할 수 있는 컴포넌트 기반 프론트앤드 웹앱 아키텍처를 설계 및 구현
• 전역 상태 관리자를 이용해 상태관리 아키텍처를 설계 구현
  • 컴포넌트 기반 웹 앱 개발 구조에서 컴포넌트 상태와 전역 상태에 대한 이해를 바탕으로 적절한 상태 관리 아키텍처 설계 및 구현
• playwright, cypress 등 활용한 구축
  • 코드 기반 테스트에 대한 기술적 이해를 바탕으로 단위 테스트 및 종단 테스트를 적절히 활용한 구축

 

저희 팀은 아래 3가지 정도를 목표로 설정하여 프로젝트를 진행하였습니다.

1. 다양한 기능 구현해보며 React + TypeScript에 익숙해지기

2. 개발 전반의 프로세스를 이해해가며 진행해보기

3. 프로젝트를 통해 협업을 경험해보기

 

6. 내가 맡은 파트 소개

- 프로젝트 초기 세팅

폴더구조 및 라이브러리 세팅과 초반 화면 라우팅 설정을 하여 프로젝트 초기 설정을 해보았습니다.

비기너반에서 박영웅 강사님과 함께 수업 및 실습을 하였고, 중간 점검과 특강도 진행해주셔서 초기세팅의 경우 강사님의 블로그를 참고하여 진행하였습니다. 수정되어야 할 부분은 중간점검 이후 보완하였습니다.

React 프로젝트 시작하기 w. Vite

 

- 깃허브 위키 세팅

깃허브로 상태 관리 및 협업을 진행하는 것에 익숙하지 않은 팀원들을 위해 이용 가이드를 업로드 하였습니다. 서윤님이 공유해주신 내용을 기반으로 설명 등을 약간 추가하여 저희 팀에 맞도록 수정하며 진행하였고, PR 생성 및 리뷰 방법, 이슈 및 브랜치 생성법, 기타 팀 규칙을 문서화하여 헷갈릴 때 편하게 확인할 수 있게 해보았습니다.

- 공통 컴포넌트

공통 컴포넌트로는 Header, Navbar, Button, Layout, BottomSheet, EmptyInfo 컴포넌트를 만들어 보았습니다.

• Header와 Navbar

 

• LongButton과 ShortButton

 

• EmptyInfo: 데이터가 없을 때 보여줄 문구를 컴포넌트로 제작하여 조건에 부합할 때만 화면에 뜨도록 구현했습니다.

 

• ButtomSheet: framer-motion으로 구현

 

- 플레이리스트 페이지

이 페이지는 내가 생성한 플레이리스트를 모두 볼 수 있는 페이지입니다. + 버튼을 눌러 플레이리스트를 생성하면 이 곳에서 볼 수 있고 각 플레이리스트를 눌러 상세 페이지로 들어가면 동영상 시청 및 정보 수정과 동영상 삭제가 가능한 페이지로 이동합니다.

플레이리스트 제목, 설명, 생성 시간, 썸네일이 기본적으로 나오고 공개/비공개 설정에 따라 썸네일 우측 자물쇠 아이콘이 바뀌도록 설정했습니다. 자물쇠 아이콘 옆 삭제 버튼을 누르면 플레이리스트 삭제도 가능한데요, 삭제 버튼을 누르면 '정말 삭제하시겠습니까 ?' 모달이 뜨고 삭제를 누르면 비로소 삭제가 가능합니다.

또한 카테고리에 따라 버튼을 눌러 필터 기능 역시 가능합니다. 해당 카테고리에 맞는 영상만 띄울 수 있습니다.

 

 

- 플레이리스트 상세페이지

플레이리스트 상세 페이지는 영상 시청이 가능하며 내가 만든 플레이리스트를 편집할 수 있는 페이지입니다.

영상 재생 부분과 플레이리스트 제목, 설명, 생성시간, 공개 비공개 설정, 재생 목록을 한 눈에 볼 수 있습니다.

맨 위 부분에서 실제로 동영상 재생이 가능하고 재생 목록에 각 영상 썸네일을 클릭하여 재생하고 싶은 영상을 선택할 수 있습니다. 또한 드래그 앤 드롭 기능을 추가하여 영상 재생 순서를 바꿀 수 있고, 동영상 재생 부분은 재생 목록의 제일 첫 영상으로 설정되게끔 구현하였습니다. 재생목록 옆에는 포함된 영상의 개수를 표시하도록 하였고  이는 삭제 시 자동으로 반영됩니다. 4개 이상의 영상이 포함된 경우 스크롤을 통해 동영상을 확인할 수 있습니다. 각 영상의 오른쪽에 마련된 버튼을 클릭하면 동영상 삭제를 위한 바텀시트가 구현되고, 삭제 버튼을 누르면 영상을 삭제할 수 있습니다. 

 

 

- 플레이리스트 편집페이지

플레이리스트 상세 페이지에 있는 수정 버튼을 누르면 플레이리스트 편집 페이지로 이동하게 됩니다. 이 페이지로 넘어가게 되면 플레이리스트 제목, 설명, 카테고리, 공개 비공개 설정이 처음에 해당 플레이리스트를 생성했던 데이터 그대로 저장이 되어 수정할 수 있도록 구현했습니다. 또한 변경사항은 곧바로 플레이리스트 상세페이지와 플레이리스트 페이지에 반영됩니다. 

 

• 플레이리스트 페이지에도 바로 반영된 모습

 

- 테스트 코드

테스트는 playwright를 사용하여 진행하였습니다. 시간이 넉넉하지 않아 로그인 화면 정도 테스트 코드를 구현해보았습니다.

 

7. 더 많은 페이지들

팀원분들이 개발하신 더 많은 페이지를 소개합니다.

 

- 로그인 페이지

파이어베이스를 기반으로 로그인을 구현했고 이메일/비밀번호 로그인이 아닌 구글 로그인을 구현해보았습니다. 파이어베이스 초기세팅과 로그인 부분은 난아님이 모두 맡아 구현해주셨습니다.

 

- 홈페이지

홈페이지에서는 다른 사용자가 올린 플레이리스트와 내가 올린 공개 플레이리스트를 볼 수 있습니다.

좋아요 기능과 북마크 기능이 있고 댓글 버튼을 누르면 상세페이지로 이동하며 북마크 버튼을 누르면 북마크 페이지에 저장됩니다.

해당 플레이리스트를 생성한 유저의 사진과 닉네임이 보이며 이는 네트워킹 페이지에도 반영됩니다. 이 페이지와 무한 스크롤은 난아님이 구현해주셨고 특히 무한 스크롤 부분은 멘토님께서도 고민한 흔적이 보이신다고 하면서 좋은 피드백을 주셨습니다.

 

• 무한 스크롤 구현

 

- 네트워킹 페이지

이 페이지에서는 영상 시청 및 댓글을 통해 다른 유저와 소통하는 것이 중심 역할입니다. 다른 유저의 플레이리스트를 시청하는 것이기 때문에 플레이리스트 상세페이지와 달리 공개 비공개 설정이나 정보 수정 및 삭제 기능은 넣지 않았습니다. 모션 효과 이외의 댓글 섹션은 난아님이 구현해주셨습니다. 댓글 부분을 누르면 바텀시트가 나와 댓글을 작성할 수 있고 댓글 삭제가 가능합니다. 

 

- 플레이리스트 추가 페이지

플레이리스트 추가 페이지는 영은님이 구현해주셨습니다. 글자수 제한이라던지 툴팁과 같은 부분을 통해 페이지의 완성도를 높였습니다.

 

- 북마크 페이지

북마크 페이지는 연지님이 작업해주셨습니다. 특히 드롭앤 드롭 기능과 북마크 기능, 토스트 기능은 여러 페이지를 연결하는 것이라 까다로운 작업인데 성공적으로 수행해주셨습니다.

 

- 프로필 페이지

이 페이지에서는 닉네임과 이메일을 확인할 수 있고 수정 페이지에서는 닉네임과 사진을 수정할 수 있습니다. 영은님이 작업해주셨고 정보 수정 시 바로 다른 페이지에 반영됩니다.

 

- 오류 페이지

난아님이 구현해주신 페이지로, 잘못된 경로로 접근했을 때 뜨는 404 화면입니다.

 

8. 리팩토링

리팩토링은 프로젝트가 끝난 뒤 '9/30 - 10/4'에 진행하였습니다. 코드리뷰용 PR을 올리고 멘토님이 코드 리뷰를 하는 식으로 진행하였습니다. 추가 설명이 필요한 부분은 Zoom에서 진행한 실시간 멘토링을 통해 해결하였습니다. 이 과정에서 onError를 사용하는 것과 에러를 throw 했을 때의 장단점과 차이점, 옵셔널 체이닝 사용 시 주의점 그리고 유닛 테스트에 대한 중요성을 알게 되었습니다.

 

9. 회고

Keep: 이번 프로젝트에서 잘 한 점

- 팀원 모두가 파악해야 하는 정보(버그 발생 정보 등)나 팀에게 도움이 되는 부분(트러블 정리, 깃 정리 등)을 문서화하여 빠르게 공유함으로써 팀 프로젝트의 효율성을 높이려 노력한 점

- 동영상 삭제 기능을 구현할 때 버그가 발생했는데 처음으로 콘솔에 로그를 찍어보면서 디버깅을 해보았고, 결국 기능 구현을 완성해 낸 점

Problem: 문제가 있었거나 개선해야 할 점

- 아무래도 시간이 한정되어 있고 구현해야 할 기능은 많다보니 내용을 학습하고 이해하면서 기능 구현을 한다기 보다는 프로젝트 완성에 조금 더 초점이 맞춰진 것 같아서 개인 학습 부분에서는 아쉽다는 생각이 들었습니다. 다음에는 개인 프로젝트를 진행하면서 프로젝트 완성 보다는 학습 측면에 조금 더 초점을 맞춰 진행하여 실력을 쌓은 뒤 협업 프로젝트를 진행해보고 싶다는 마음이 들었습니다.

- 컴포넌트 재사용성이나 코드 퀄리티에 신경을 많이 못 쓰고 작업해서 같은 페이지를 동료와 작업할 때 서로의 코드를 읽는 것이 쉽지 않아 다음에는 그런 부분까지 고려하여 코드를 작성해보고 싶습니다.

Try: 다음 프로젝트에서 시도해볼 점

- 리팩토링 때 E2E 테스트 뿐만 아니라 유닛 테스트의 중요성도 알게되어 다음 프로젝트에서는 유닛 테스트를 진행해보고 싶습니다.

- 프로젝트 초기 세팅을 조금 더 꼼꼼하게 해서 프로젝트 중반에 초기 세팅 부분에는 수정사항이 없도록 진행해보고 싶습니다.