Week 1. 프론트엔드 팀 프로젝트
1주차: 21 / 10 / 14 (금 ) ~ 21/ 10 / 17 (일)
(1) 프로젝트 세팅 및 협업도구, 기술스택 결정
(2) Figma를 이용한 시안을 만들고 Work 분배, Work의 우선순위 결정

📌 프로젝트 기간

- 21 / 10 / 14 (금) ~ 21 / 11 / 03 (수)
총 21일

📆 (1) 프로젝트 방향성 결정

프로젝트 주제 선정

금요일에 처음으로 조원들과 모여 프로젝트 방향성을 결정하는 시간을 가졌다.
프로젝트 주제는 일전에 조금씩 생각해둔 아이디어들을 구체화해서 첫 오프라인 미팅 때 팀원들에게 PR하는 시간을 가졌다. 내 경우 기존의 관광 전공에서 만들고 싶던 서비스를 조금 더 실현 가능성 있게 다듬어서 발표하였고, 다른 팀원들도 참신한 아이디어들을 공유해 주셨다.
특히 팀원 분께서 제안해주신 아이디어는 공통 주제인 SNS 서비스에 좀 더 적합하고 구현 로직이 깔끔해서 이것도 괜찮았지만, 내가 제안한 아이디어 자체가 블루오션이라는 점과 적용할 수 있는 Open API를 발견하게 되면서 조금의 수정을 거쳐 여행 모임 서비스가 프로젝트 주제로 선정되었다 👏👏👏👏

UI 시안 배정과 work 우선순위 결정

주제를 선정하고 난 다음엔 UI 시안을 배정하고 해야할 일을 우선순위를 나눠 기획서에 반영하기로 했다.
구현 난이도가 낮은데 반드시 필요한 기능과, 구현 난이도가 높은데 반드시 필요한 기능, 구현 난이도가 높은데 반드시 필요하지는 않은 기능으로 나눴다.

기술 스택 정리

오프라인 미팅 전에 멘토님과의 Q&A 타임, 구글 검색, 다른 팀들의 의견을 물어가며 적용할 기술 스택을 정리해보았다.

• Typescript
  팀원 3명이 모두 사용해본 적이 없고, 프로젝트 기간이 2 ~ 3주로 짧기 때문에 러닝 커브가 길다고 판단하여 적용하지 않기로 하였다.
• Storybook
  마찬가지로 팀원 3명이 모두 사용해본 적이 없고, Vue 3 버전 + Storybook의 정보가 많지 않다고 판단하여 차후 생각해보기로 하였다.
• Grid system
  유명한 Bootstrap Gridsystem과 Vuerify도 Vue 3 버전을 지원하지 않기 때문에 sass의 mixin을 활용해 Gridsystem을 직접 구현해보기로 하였다. 이 부분은 일전에 개인 프로젝트에서 진행한 경험이 있기 때문에 내가 담당하기로 하였다.

💄 (2) 첫 Figma 활용 및 SRS 정리

각자 Figma를 활용해 스켈레톤 UI를 만들어보기로 했다.
Figma는 유투브에도 좋은 강의들이 많고, 예전에 인프런에서 유료 피그마 강의를 무료로 푼 적이 있던 것을 운 좋게 얻어서 짧은 시간동안 수강하며 진행했다.

Figma로 UI를 만들 때 팀원들의 다양한 의견들이 나왔다. 차후 시안이 어떻게 될 지 모르기 때문에 스켈레톤 UI만 만들고 구현을 빠르게 들어가자는 의견과, 코드로 바로 적용가능한 시안을 만들어 추후 디자인에 소요되는 시간을 줄이자는 의견이 존재했다. 따라서 우리는 각자의 의견을 모두 존중해서 원하는 대로 시안을 만들어오기로 했고 그 결과 굉장히 다양한(?) 색감과 디자인의 시안이 탄생했다.

대략적인 시안이 나오고 난 뒤에는 변수들과 padding들을 설정해 일관되게 짜는 방향을 모색해보았다.

👉🏻 회고: 와이어 프레임 작성 용도로 피그마를 사용했지만 다같이 디자인 컴포넌트를 구성하면서 한 페이지에서 와이어 프레임을 그려도 좋겠다는 생각이 들었다. 팀원 모두 Figma를 사용한 적이 없어 진입장벽이 높을 것이라 생각했지만 그렇지 않았고, 셋이 다같이 의견을 나누며 바로바로 시안에 적용해도 좋은 결과가 나왔을 것이라 생각된다.

👉🏻 기획단계에서 페이지별 이름을 확실히 정의하지 않아서 각자가 생각하는 페이지를 만들어 혼란이 발생했다. 예를 들어 글 내용 페이지 는 같은 명세라도 개인이 어떻게 해석하느냐에 따라 다른 기능을 한다. 때문에 페이지별 이름을 확실히 정의하고 어떤 기능을 하는지 명시해두어야 추후 소통 문제가 발생하지 않을 것 같다.

Header

헤더에 들어갈 정보는 추후 바뀔수도 있기 때문에 약간 러프하게 상상해서 시안을 만들었다.
일차적으로 Header에 색깔을 넣었지만, 전체 백그라운드 배경을 자연스럽게 Header 컴포넌트가 가져가는 게 더 깔끔하다고 생각이 들어 투명으로 바꾸었다.
추가적으로 background 버전도 4가지로 만들어서 팀원들에게 제안해보았고 결과적으로 두번째 흰 바둑이 백그라운드가 공통 백그라운드로 결정되었다.
내부 컴포넌트들의 이벤트가 발생했을 때 상태는 state 프레임에 적어 놓았다.

post 상세 페이지

post 상세 페이지는 시간이 가장 오래걸렸는데 필요한 컬러들을 변수로 저장하고 이곳저곳에 배치해보며 상상의 나래를 펼치는 데 시간을 많이 쏟았다.

컴포넌트를 다 만들고 나서 Gridsystem을 적용하고 나니 레이아웃이 어긋나서 컴포넌트를 늘려보았으나? 오른쪽 부분만 밀려나고 왼쪽은 고정되는 문제가 발생하였다.
(사진 상으로 Desktop 시안의 좌측이 약간 어긋나는 부분)
피그마에 미숙한 관계로 내일 다른 팀과 진행과정을 공유하는 시간에 한번 여쭤보는 게 좋을 것 같다.

로그인, 회원가입 페이지

로그인, 회원가입 페이지는 페이지가 아니라 컴포넌트로 만들어 필요한 분들이 공통으로 사용할 수 있게 논의가 되어서 모달형식으로 간단하게만 만들었다.
전체적인 디자인은 추후 진행하면서 바뀔 것 같다 👍

SRS 정리

소프트웨어 요구 사양서인 SRS를 작성하며 유저 이벤트마다 어떤 기능, 동작들이 필요한 지 정리했다. SRS 를 정리하며 어떤 기능들이 필요한 지 좀 더 구체화할 수 있었지만 실질적으로 기능을 구현하며 SRS를 잘 돌아보진 않은 것 같다는 생각이 들었다. 🧐 이 부분은 (1) SRS를 단순히 문서 형태로 쭉 작성하지 않아 가독성이 떨어지고 (2) 페이지별 기능이 한 눈에 들어오지 않기 때문에 발생하는 문제 같았다. 효율적인 SRS 문서에 대해 고민이 필요할 것 같다.

SRS를 작성하고 끝내지 않고, 한 명씩 돌아가며 각자 맡은 부분을 발표하는 과정에서 팀원들끼리 피드백을 주었다. 혼자 생각할 때 나오지 못했던 다양한 의견들을 정리해 놓고 다시 SRS에 반영하였다.

👉🏻 SRS 문서 작성 시 페이지별로 사용되는 API 명세도 함께 정리해 놓았으면 더 좋았을 것 같다. 현재는 필요한 API를 직접 만들어주시지만 일정이 타이트한 경우 API 수정이 불가능할 수도 있기 때문에 기획 단계에서 API 명세를 정리해 필요한 페이지를 파악하는 게 필요하다 생각된다.