[Main Project 1주차] 8.24 ~ 8.31 | 기획, 디자인 완료 & 본격적으로 개발 준비

[Main Project 1주차] 8.24 ~ 8.31
기획, 디자인 완료 & 본격적으로 개발 준비

💬 프로젝트가 끝난 후에 데일리로 정리했던 기록을 보며 프로젝트 전체 과정을 정리하여 4주차로 나누어 작성했습니다.

1주차: 현재글

🔗 2주차

🔗 3주차

🔗 4주차

🔗 데모데이 & 프로젝트 전체 회고

 

👩🏻‍💻 Github Repository https://github.com/sw2377/smoothie

🚀 SUMMARY

 8.24 THU 
1. 팀 빌딩 & 팀 규칙 정하기
2. 프로젝트 아이디어 Mix & 전체적인 기획 회의
3. 팀 명 “🫐 블루베리스무디”로 결정

 8.25 FRY 
1. 어제에 이어서 기획 회의
2. 사용자 요구사항 정의서 작성

 8.28 MON 
1. 유저플로우 작성
2. 🧙🏻 1차 멘토링 세션 ➡️ 기획의 볼륨이 너무 큰 것 같으니, 핵심 기능 위주로 줄이는건 어떨까요?

 8.29 TUE 
1. 프로젝트 볼륨 줄이기 회의
2. 화면정의서 작업 (프론트팀)

 8.30 WED 
1. 화면정의서 작업 완료
2. 백엔드 테이블 & 프론트 화면정의서 공유 ➡️ 백엔드와 프론트엔드에서의 필요한 부분 소통
3. git convention 공유
4. 개발 작업 분배 및 본격적인 디자인 작업 시작 ➡️ 디자인 가이드 기반으로 각자 맡은 파트 디자인 (Figma)

 8.31 THU 
1. 디자인 작업 마무리
2. 프로젝트 개발 환경 세팅 ➡️ Vite - React, Typescript

 

📙 1주차 회고

📖 목차

팀 빌딩과 기획 회의
차별점을 어떻게 둘 것인가?
🧙 첫번째 멘토링 세션 : 프로젝트를 어떻게 시작하는 것이 좋을까?
프로젝트 볼륨 줄이기
화면정의서 작성 및 디자인 작업
  ◾️ Figma를 사용한 화면정의서와 디자인 작업
개발환경 세팅
  ◾️ FE 기술 스택에 대한 STORY
  우리는 왜 타입스크립트를 도입하려 했을까?
  상태관리 라이브러리는 왜 Redux Toolkit을 사용하기로 했을까?
  CSS는 어떻게 작업할까?

 

 주차별 회고를 프로젝트를 진행하면서 작성하려고 했었는데, 초반에는 기획 회의와 디자인 작업을 한다고, 중반부터는 개발도 해야 하고, 부족한 부분의 학습도 해야 했기 때문에 회고를 쓸 시간이 없었다. 결국 이렇게 프로젝트가 다 끝나고 난 후에야 기억을 더듬어 정리를 해본다. 

 그래도 프로젝트를 진행하며 꼼꼼히 기록은 다 해두어서 기억을 다시 떠올려보는건 어렵지 않았다. 게다가 프로젝트가 마무리된 후에 회고를 작성하니, 전체적으로 다시 되짚어볼수 있다는 점에서 의미가 있었다. 따라서 이 회고글은 당시 프로젝트가 어떻게 진행되었는지와 함께 프로젝트가 끝나고 난 후의 나의 생각도 조금씩 덧붙여질 것 같다. 🙂

 

팀 빌딩과 기획 회의

 이미 정해졌던 5명의 팀원과 마지막에 합류하게 된 한 명의 백엔드 팀원으로 우리 팀은 총 6명 바로 매칭이 되었다. 순조로운 시작을 알리는 것 같았다. 팀장은 함께 프로젝트를 하자고 제안해주셨던 백엔드 팀원분께서, 부팀장은 프론트 팀의 팀원이 하게 되었다.

 소통은 텍스트 채팅과 음성 채팅이 가능한 디스코드를 주로 사용했지만, 코드스테이츠 측에서 만들어둔 팀 노션 페이지도 과제 제출과 멘토링 세션 등을 위해 활용했다.

 

 어떤 주제로 프로젝트를 할지 초반 기획회의가 생각보다 길었다. 프로젝트의 주제는 사이드 프로젝트 플랫폼으로 의견을 맞추었다. 이미 시장에는 비슷한 웹사이트가 많았기 때문에 우리는 우리만의 차별화된 무언가를 넣고자 했다. 여러 웹사이트를 직접 사용해보고 장단점을 분석하고, 의견을 교류하며 어떤 식으로 만들어나갈지 첫 일주일 정도는 거의 하루종일 회의를 했다.

 이런저런 이야기를 나누는 동안 여러 의견이 나왔고, 처음에는 최대한 많은 의견을 수렴했다. 이후 가지치기를 통해 시간 내에 구현할 수 있을 정도로 범위를 축소하기로 했다.

 만들고 싶은 기능은 정말 많았지만 개발을 위한 시간이 채 한달도 안되었기 때문에 한정된 시간 안에 할 수 있는 기획을 하는 것이 중요했다. 범위를 줄이더라도 완성도 있는 결과물을 내야 한다고 생각했다. 아이디어 기획 회의를 기반으로 사용자 요구사항 정의서를 작성했고, 요구사항의 중요도를 상, 중, 하로 나누어 무조건 구현해야 하는 기본적인 중요도 “상”의 기능을 우선적으로 구현하기로 했다.

 

🔖 지금까지의 기획안

주제 : 검증된(나와 잘 맞는) 팀원을 구하는 사이드 프로젝트 플랫폼

1. 팀원 구하기 (이런 팀원을 찾고 있어요)
2. 프로젝트 구하기 (이런 팀을 찾고 있어요)
  - 카드 형태의 리스트로, 마우스를 올리면 뒤집히는 형태
3. 개인 프로필 페이지 (마이페이지)
  - 나의 하드스킬/소프트스킬과 팀원 리뷰 등 공개
4. 칸반보드를 활용한 프로젝트 과정 공유

 

 구체적인 사항들이 훨씬 많았지만 정말 간단하게 정리하자면 큰 틀은 위와 같았다.

 

차별점을 어떻게 둘 것인가?

 앞서 이야기했듯 시장에는 이미 비슷한 웹사이트가 많았다. 비사이드, 렛플, Hola 등 이보다 훨씬 많았지만 우리는 이 3개의 웹사이트를 벤치마킹 하였다.

 “사이드 프로젝트 플랫폼”의 우리만의 차별점으로는 좀 더 검증된 유저 프로필을 제공하고, 나와 잘 맞는 팀원을 구하기 위한 팀원 검증과 리뷰 시스템에 대해 깊게 생각해보기로 했다. 그 방안 중 하나로 칸반보드 시스템이 등장했다. 작업 시 흔히 사용하는 칸반보드를 적극적으로 활용해 프로젝트의 진행 과정과 맡은 역할 등을 공개하자는 것이었다. 칸반보드에는 프로젝트의 전반적인 내용이 들어있을테니 다른 유저들은 공개된 칸반보드를 참고하여 나와 함께 프로젝트를 할 팀원의 역량 등을 파악할 수 있도록 하는 것이다. (이와 관련하여 좀 더 세부적이고 구체적인 논의가 있었는데 이는 따로 정리해두었다.)

 하지만 우리가 생각해본 칸반보드 시스템은 사이드프로젝트 플랫폼의 기본이 될 팀원 찾기 게시판이 필수적으로 들어가야 하는 시점에서 (게다가 우리는 유저 개인의 프로필도 카드 형태로 업로드 하여 개인을 홍보할 수 있는 게시판 또한 생각해두고 있었다) 프로젝트 규모가 커질 것 같다는 걱정이 있었다. 시간이 부족할 것 같았다.

 

🧙🏻 첫번째 멘토링 세션 : 프로젝트를 어떻게 시작하는 것이 좋을까?

 칸반보드 시스템이 프로젝트에 큰 비중을 차지할 것이라는 걱정 속에 첫번째 멘토링 세션이 진행되었다. 우리가 만들려는 웹사이트를 유저플로우를 함께 보며 설명한 것을 기반으로 아래와 같은 이야기들을 나누었다.

 

1. 역시나 프로젝트 볼륨이 좀 큰 것 같다고 걱정을 하셨다. 개발을 할 시간이 한 달도 안될텐데, 그에 비해 기능이 많은 것 같다는 의견이었다. 조금 더 보수적으로 잡고, 프로젝트를 완성할 수 있는 방향으로 가는 것이 좀 더 좋지 않을까?
   → 이에 관해 다음날 우리는 프로젝트 볼륨 줄이기 회의에 들어갔다.
2. 시장성보다는 우리의 성장에 초점을 맞추는 것이 어떨까, 라는 조언이 있었다. 시장에서 좋은 평가를 받는 앱보다는 우리가 팀 프로젝트를 통해 이러한 어려움이 있었고, 이걸 어떻게 해결했으며, 이러한 결과물을 내었다라는 것을 어필하는 것에 초점을 맞추는 것이 어떨까?
    생각해보면 특별한 아이디어도 좋지만, 이미 내가 생각하는 것들은 어딘가에 존재할 가능성이 컸다. 멘토링을 진행하기 전까지는 우리의 프로젝트가 시장의 수많은 상품들과는 다른 차별점이 반드시 존재해야 한다고 생각했었는데, 멘토링 후에 생각을 해보니 특별한 무엇보다도, 이 프로젝트가 어떻게 진행되었는지 그 과정 속에서 우리가 얼마나 성장했는지를 보여주는 편이 훨씬 좋지 않을까? 라는 생각이 들었다.
3. 프론트 팀원들끼리 계속해서 고민했던 타입스크립트 도입에 대한 이야기도 나누었다. 우리는 모두 타입스크립트를 사용해 프로젝트를 하고 싶은 마음은 있었지만, 한번도 스터디 외의 목적으로는 사용해본 적이 없고, 아직 많이 부족한 상태라 고민을 하고 있었다. 나 또한 타입스크립트를 이번 프로젝트에서는 정말 사용해보고 싶었지만 잘 할 수 있을지 확신이 없는 상태였다.
    멘토님은 앞서 얘기했던 것처럼 개발 스코프를 줄이고, 타입스크립트 등의 기술적인 측면을 공부하고 도입하는 것을 추천하였고, 멘토님의 의견과 프론트 팀원들의 의견을 반영해서 타입스크립트를 사용하기로 결정했다.

프로젝트 볼륨 줄이기

 멘토링 세션에서 이야기가 나왔던 프로젝트 볼륨 줄이기 회의에 들어갔다. 어느 정도 기획 회의가 끝나나 했더니, 다시 회의가 시작되었다. 멘토링 세션을 진행하며 생각이 들었던 대로, 차별성 있는 무엇도 중요하지만 우선은 마무리를 기간 내에 짓는 것이 더 중요할 것 같다는 의견을 냈다.

 팀원들끼리 각자 추구하는 방향이 조금씩 달라서 의견을 공통된 하나로 취합하는게 쉽지는 않았다. 하지만 팀원들 모두 “마무리된 결과물”이 중요하다는 의견은 같았기 때문에 이를 토대로 버릴 것을 과감하게 버리기로 했다.

 많은 고민과 의견 종합 끝에 칸반보드 시스템을 과감하게 쳐내기로 했다. 대신 사용자 요구사항 정의서에 중요도 “하”로 표기하고, 다른 작업이 만약 시간 내에 끝난다면 다시 한 번 고민해보기로 했다. 물론 다른 작업들을 전부 구현하는데도 시간이 부족했기 때문에 내쳐진 칸반보드를 다시 불러오는 일은 일어나지 않았지만 🥲

 기존에 칸반보드 시스템을 활용해 팀원 요청과 수락 등의 기능도 넣으려고 했는데, 칸반보드를 구현하지 않는 대신 댓글을 통해 팀원 요청과 수락 기능을 넣기로 했다.

 그렇게 가지치기된 프로젝트는 기존의 팀원 매칭 서비스라는 개념은 그대로 가지고가되, 우리가 추구하고자 했던 검증된 유저 프로필을 보여주기 위해 개인 프로필(마이페이지)에 더 자세하고 많은 정보를 담을 수 있도록 해보기로 했다.

 

화면정의서 작성 및 디자인 작업

 전체적인 기획 회의가 거의 마무리되고, 프론트 팀에서는 화면정의서와 디자인 작업을 시작했다. 화면정의서를 작업하는데도 시간이 꽤 걸릴것 같아서 주말과 수업이 끝나고 남는 시간에 틈틈히 화면정의서를 회의한 내용을 바탕으로 미리 작성해두었다. 이를 기반으로 팀원들과 검토를 하며 수정할 부분과 추가할 부분을 함께 작업했다. 화면정의서를 작성하면서 전체적인 틀은 공통으로 가져가되, 디테일한 기능은 작업자의 재량과 자유도에 맡기자는 이야기가 많이 나왔다. 직접 기획부터 하게 되니 좀 더 유동적인 작업이 가능해지는 것 같기는 하지만, 아무래도 거의 일주일간 기획회의만 하다보니 팀원들 모두 조금은 지친 상태여서 좀 더 자유도가 부여되었던 것 같다.

 

◾️ Figma를 사용한 화면정의서와 디자인 작업

 화면정의서에는 UI 구현과 개발에 필요한 모든 사항을 작성했다. 화면정의서와 디자인 파일 만으로 논의했던 부분에 대해서는 개발이 가능하도록 하는 것이 목표였다. 작업 후에 백엔드 팀원분들과 공유하고, 서로 확인하면서 개발 작업에 들어갔다. 정말 디테일하게 작성했다고 생각했는데도 논의할 부분이 생겼고, 변경 사항도 생겼다.

우리가 작성한 화면정의서

 

 디자인은 작업을 좀 더 빠르게 하기 위해 작업할 페이지 나눈 후 각자 디자인하기로 했다. 개별로 디자인을 하게 되면 일관성이 떨어질 것 같아서 디자인 가이드를 몇 개 찾아서 팀원들에게 보여주었고, 그 중 한가지를 골라 가이드를 기반으로 작업하기로 했다. 메인컬러와 서브컬러, 폰트를 정하고, 화면 정의서에 표시된 UI 컴포넌트 중 필요한 부분이 디자인 가이드에 있는지 확인하고, 없으면 추가하는 방식으로 진행했다.

UI Style Guidelines. Figma Community에 관련 키워드를 검색해보면 정말 많은 디자인 가이드나 시스템이 나와서 작업시 참고하기 좋다.

디자인

 

🧐 개발에 들어가기 전에 공통으로 사용될 컴포넌트(ex. button)를 미리 파악해두고, 한 사람이 재사용 가능한 컴포넌트로 미리 만들어두고 다른 사람들은 그 컴포넌트를 가져다 사용하는 방식으로 작업했다면 정말 좋았을 텐데 아쉽게도 놓쳤던 부분이었다.
결국 각자 작업할 페이지 내에서 각자 컴포넌트를 만들어 사용했었다.

 

<작업 분배>

- 로그인/회원가입 & Header, Footer → 팀원 1
- 팀찾기/팀원찾기 게시판 → 🙋🏻‍♀️ 나
- 마이페이지 → 팀원 2

 

 작업 분배는 위와 같이 진행되었다. 다들 하고 싶은 페이지를 먼저 선택하라고 하며 고르지 않고 있어서 내가 먼저 게시판 부분을 골랐다. 프리 프로젝트 때 로그인을 해봤던 터라 게시판 CRUD 기능을 해보고 싶은 마음이 있었는데, 팀원 두 분 모두 서로 먼저 고르라고 해서..ㅎㅎ 하고싶은걸 먼저 골랐다. 😊

 로그인과 회원가입은 인증/인가 전반에 걸쳐진 작업이라 따로 뺐고, auth를 담당하게 된 사람이 거의 모든 페이지에 들어갈 Header와 Footer를 작업하기로 했다. 팀찾기/팀원찾기 게시판은 웹사이트의 전체 게시판으로 공통된 부분이 많았기 때문에 내가 한번에 가져간다고 했다. 마이페이지는 저렇게 하나만 보여서 양이 적을거라 생각되지만, 마이페이지 내에서도 페이지가 몇 개 나누어져 있어 디자인과 개발 작업을 할 부분이 적지 않아 한 사람이 담당하기로 했다.

 

🧐 작업이 어느정도 진행되고 나서 생각해보니 작업을 좀 더 세부적으로 나누었어야 했나, 라는 생각도 들었다. 팀원1이 맡은 부분의 작업이 예상보다 빨리 끝났고, 나와 팀원3님이 생각보다 많은 부분을 작업하고 있었기 때문이다. 내가 맡은 게시판만 해도 형태는 비슷해 보였지만, UI 작업할 것도 생각보다 많았고, HTTP 통신도 많았다. 댓글도 디테일한 부분이 많아서 그 부분까지 작업하려고 하니 예상했던 것보다 시간이 좀 더 많이 걸렸고, 다른 팀원분도 작업 내내 엄청 바쁜 것 같았다. 그래도 사실 내가 하고 싶어서 한 부분이라 만족스러웠지만, 바쁜 일정으로 기능이 단지 동작한다는 것에만 신경을 썼다는 점은 아쉬웠다.

 

개발환경 세팅

 사용자 요구사항 정의서는 다함께 작성했고, 프론트엔드 팀원들은 유저플로우와 화면정의서, 디자인 작업을 하고, 백엔드 팀원들이 ERD 작업을 마무리했다. (API 명세서는 개발 중에 계속적으로 업데이트를 해주었다.)

 

 👉🏻 본격적으로 개발 작업에 들어가기 전에 함께 사용할 Git Convention을 정했다. 코드스테이츠 Repository에서 클라이언트와 서버가 함께 작업이 되어야 했기 때문에 Git Flow도 적용하기로 했다.

깃컨벤션

 

 👉🏻 Github Projects의 칸반보드와 Milestones도 적극적으로 사용하기로 했는데, 딱히 규칙을 정하지도 않았고, Agile하게 스프린트 단위로 개발한 것도 아니어서 그런지 이 부분은 조금 흐지부지 되었던 것 같기도 하다. 나는 기록하는 걸 좋아하는 편이라 적극적으로 사용했었고, 앞으로의 프로젝트에서도 칸반보드는 필수가 아닐까 생각이 들었다.

 

 👉🏻 프론트 팀원 분께서 프로젝트를 Vite로 하자고 해서 Vite에 React + TS로 세팅을 해주었다. 사용할 라이브러리나 기타 초기 세팅은 내가 해서 git에 올리기로 했다.

(우선 1주차 회고는 여기까지! 나머지 초기 세팅은 2주차 회고에서 👋🏻)

 

◾️ FE 기술 스택에 대한 STORY

🐤 FE 기술 스택
    - React (Vite), TypeScript, Module CSS, Redux toolkit

 

 기획과 디자인 작업까지 마무리하고 나서야 개인 공부를 할 시간이 났다. 일주일만에 기획 회의와 화면정의서 작업, 디자인까지 하느라 개인 공부할 시간이 하나도 없었다. TypeScript와 Redux Toolkit을 사용하기로 했는데, 프로젝트에 적용하는건 처음이라 익숙하지 않은 부분이 너무 많았기 때문에 따로 학습할 시간이 필요했다.

 Redux Toolkit 부터 학습을 하고, TypeScript를 적용하는 걸 학습하기로 했다. 조금 욕심을 내서 타입스크립트와 리덕스 툴킷까지 사용하자고 한거라 잘하고 싶다는 생각이 들었다.

 

---

 

 우리는 왜 타입스크립트를 도입하려 했을까?

 솔직하게 얘기하자면, 가장 큰 이유는 타입스크립트라는 스킬이 구직에 필요했기 때문이다. 신입 프론트엔드 채용공고를 둘러보다보면 타입스크립트가 정말 많이 등장하기 때문에 프로젝트를 하며 한 번쯤은 사용해봐야 할 것 같았다. 그러한 이유로 타입스크립트의 도입을 적극적으로 얘기했는데, 이론적으로 접근하자면 타입스크립트를 쓰지 않을 이유가 없다는 것도 사실이다.

 타입스크립트를 사용했을 때의 단점은 러닝커브가 있다는 것 정도겠지만, 장점은 훨씬 많다. 타입스크립트는 정적타입 검사 기능을 지원하여 런타임 에러를 방지하며, 타입을 명시함으로써 코드의 의도 또한 명확해지기 때문에 협업시 코드의 가독성도 높여준다. 또한 개발환경에서 자동완성 등의 기능을 통해 개발의 효율성도 높여주며, Interface, Generic과 같은 기능을 지원하기 때문에 객체 지향 프로그래밍을 보다 쉽게 할 수 있다는 장점이 있다.

 

 상태관리 라이브러리는 왜 Redux Toolkit을 사용하기로 했을까?

 우선은 로그인 등의 auth 기능을 구현하고, 확장하기 위해서는 상태를 전역으로 관리할 필요성이 있었기 때문에 상태관리 라이브러리를 사용하기로 했다.

 솔직하고 현실적으로 얘기하자면 Redux 말고는 사용할 줄 아는 상태관리 라이브러리가 없었다. (React의 Context API 제외. Context API는 나와 다른 팀원분이 프리 프로젝트에서 사용해봤기 때문에 다른 라이브러리를 사용하고 싶어했다.) Recoil이나 zustand 등의 새로운 상태관리 라이브러리를 사용하자니 역시 학습이 필요했기 때문에 부트캠프에서 배웠던 Redux를 보다 간편하고 효율적으로 사용할 수 있는 Redux Toolkit을 제안했다. 게다가 Redux 공식 웹사이트에서도 Toolkit을 권장하고 있으니, Toolkit을 사용해주어야지.

 Redux Toolkit은 상태관리를 위해 많은 코드를 작성해야 했던 Redux의 번거로움에서 벗어나 좀 더 직관적이고 간결한 코드를 작성할 수 있기 때문에 코드의 가독성과 유지보수성을 향상시킬 수 있다는 장점이 있으며, 비동기 작업을 처리하기 위한 createAsyncThunk와 같은 유틸리티 함수를 제공하여 비동기 코드도 간편하게 작성할 수 있다는 장점이 있다.

 Redux Toolkit도 이번 프로젝트를 하며 처음 사용해봤는데, 확실히 Redux에서 번거롭게 작성되던 코드를 훨씬 간결하게 작성할 수 있다는 점에서 편리했다.

 멘토링 세션에서 React Query도 제안하셨는데, 이 또한 갑자기 사용하기에는 폭풍같았기 때문에 보류해두었지만 프로젝트가 끝난 후에 학습할 의향이 있었던 터라 반갑게 들렸다.

---

 CSS는 어떻게 작업할까?

 CSS는 Module CSS를 사용하기로 했다. 요즘 많이 사용하는 Tailwind CSS 의견도 나왔었는데, 이 또한 3명 모두 학습이 필요했고, 커스터마이징이 자유롭지 않을 거라는 생각에 배제시켰다. (프로젝트가 끝나고 나서 생각해보니, Tailwind CSS도 좋은 방법 중 하나가 되었을지도 모르겠다는 생각이 들었다. 사용해본적도 없는데 무턱대고 부정적인 의견을 말한 것이 좋은 방법은 아니었던 것 같다.) 부트캠프에서 학습했던 Styled-components를 사용하는 것도 괜찮았는데, 다른 팀원들이 선호하지 않는 것 같아서 제외했다. CSS를 통합으로 사용하자니 className의 중복이 우려되어 Module CSS를 사용하기로 했다. 비교적 간단하고, 러닝커브가 없으면서도 중복된 className의 우려가 없다는 점에서 현재 타입스크립트와 RTK 만으로 벅차던 우리에겐 최선의 선택이었다.

 

---

 

 개발 부트캠프를 하는데 기획과 디자인까지 하려고 하니 사실 진이 다 빠졌다. 기획부터 시작해서 무언가를 만든다는게 싫지는 않지만, 떠오르는 아이디어가 더 좋았다면 훨씬 더 재미있는 작업이 되었을 것 같아 아쉬운 마음이 있었던 것 같다. 무언가 특별하고 더 재미있는걸 하고 싶었는데, 이미 흔한 주제의 프로젝트가 되어버렸다는 생각도 들었다. 하지만 내가 기획한 웹사이트를 프론트 개발을 하는 것은 처음이라는 점에서 설렘도 가득했다. 드디어 개발단계에 진입한다!