중간 회고록

• 중간 회고록 기간: 21/11/25 - 21/12/13

🗂 프로젝트 개요

주제

성장곡선으로 자신의 성장을 기록하고 공유하며 동기부여 받는 서비스

팀원

• FE: 김예임(팀장), 김찬민, 김지영
• BE: 최승은(팀장), 박정미, 박수빈

총 기간

• 21/11/25 ~ 21/12/21

🧐 중간 회고

기획서 제출 및 주제 선정

앞으로 한달여간 프론트와 백앤드가 모여 서비스를 만들기 위해 각자 하루동안 기획안을 써서 제출하였다. 하루라는 시간은 괜찮은 아이디어가 구체화되어 나오기에 짧은 시간이라 느껴졌지만, 다행히도 평상시에 만들고 싶은 아이디어들을 메모장에 적어놓았던 터라 그 중 내 인생 성장곡선 기록 서비스를 구체화하여 제출하였다.
이번 프로젝트는 제출된 기획서 중 익명 투표를 통해 프론트 + 백앤드 합쳐 상위 10개의 주제에 선정되어야 했기 때문에 간결하면서도 최대한 구체적으로 작성하였고 투표를 받아 내 아이디어가 상위 10개에 포함되었다! 박수 👏👏👏👏

• 기획서를 보러 오세요! 👈🏻

최종 프로젝트 팀 결과가 발표된 그 날밤, 프론트끼리 모여 주제와 앞으로의 생각에 대해 얘기를 나누었고 꽤 잘 맞는다 생각이 들었다. 팀장에 관해선 주제를 제안한 내가 하면 좋았겠지만 아쉽게도 리액트를 한번도 해본 적이 없었기 때문에 리액트에 익숙한 다른 분께 넘겨주되 자유롭게 의견을 나누는 방향으로 결정이 되었다.

백앤드와의 만남과 일정 공유

며칠 후 처음으로 백앤드와 스크럼을 진행했다. 기획서를 설명하고 궁금한 점에 대해 얘기를 나눴다. 이것저것 설명을 하고 기획서의 고칠 부분과 추가할 부분을 반영하여 프론트에서 시안을 먼저 만들어오기로 했다! 백앤드는 시안을 같이 만드는 것보다 의견을 공유하여 프론트에서 반영하는 것이 작업을 분리하기에 적절하다고 생각했다.

FE- 와이어 프레임 만들기

11/25 ~ 11/26 이틀 간 하루 세시간 정도 시간을 들여 시안을 후다닥 완성했다. 팀원들이 피그마를 잘 활용한 덕분에 원하는 아이디어를 빠르게 적용할 수 있었다. 덧붙여 저번 프로젝트에서는 각자 시안을 완성했다면 이번 프로젝트에선 다같이 모여 아이디어를 공유하고 실시간 수정을 통해 작업을 빠르고 통일성 있게 진행할 수 있었다.
또 프로토타입이라는 기능으로 마치 실제 웹에서 동작하는 것처럼 user action을 반영하였다.
아이디어를 우리쪽에서 만들고 와이어 프레임까지 만들기 때문에 백앤드에서 그 흐름을 이해하는 데 프로토타입이 큰 도움이 될 것 같았다.

BE - 와이어 프레임을 바탕으로 ERD 설계하기

백앤드는 11/27 ~ 11/29 3일간 ERD를 설계하고 API 설계 작업도 진행한다고 했다. ERD(Entity Relationship Dirgram)란 DB 테이블 관계를 시각화해서 API 설계에서 참고하는 다이어그램이라고 한다.

FE - MosCoW, 개발환경설정

ERD 설계를 기다리는 동안 프론트의 할 일

• 개발환경, 컨벤션 설정
• 레포지토리 적용, base 컴포넌트 만들기
• MosCoW 작성

개발환경, 컨벤션 설정

이전 프로젝트 경험에서 개발환경의 버전을 맞추는 것이 제일 선행돼야 함을 깨달았다. 버전이 맞지 않았을 때 어떤 컴퓨터에선 실행되는 작업이 다른 컴퓨터에선 오류가 발생하는 일을 방지하기 위함이다.
커밋 규칙은 commitizen이란 라이브러리의 type을 따라가기로 했다. commitizen은 커밋 타입을 통일화하고 issue를 간단하게 작성할 수 있어서 편했다.
또 커밋메시지는 한글로 작성하기로 했다.

레포지토리 적용, base 컴포넌트 만들기

레포지토리를 파고 개발환경을 적용한 뒤 base 컴포넌트를 순차적으로 만들기로 했다.

base 컴포넌트가 완성되는 건 나중 일이지만, 재사용 가능한 컴포넌트를 미리 만들어놓는 것은 나중에 작업하기에 너무 편했다. 이전 Vue 프로젝트에선 재사용성을 신경쓰지 않고 페이지 단위로 만들어서 효율성이 떨어졌었는데 다음에 또 Vue 프로젝트를 진행한다면 컴포넌트화해서 진행해보고 싶다.

MosCow 작성

백앤드에서 부탁한 MoSCoW 작성도 같이 진행했다.

MoSCoW란 1순위, 2순위, 3순위 중에서도 Must, Sholud, Could, Won't have로 세분화시키는 작업이었다.

사용자의 액션을 예상하고, 반드시 해야하는 작업 중에서도 순위를 매겨 꼭 필요한 작업과 상대적으로 아닌 작업들을 구분하기에 정말 좋았다. 다음 프로젝트를 진행할 때에도 MosCoW를 적용하면 좋을 것 같다 ☺️

API와 FE, BE의 역할 구분

백앤드로부터 API 설계가 어느정도 진행되고 request, response를 FE에서 작성해달라는 부탁을 받았다. 팀원들과 모여 중간까지 작성했지만 이 부분이 과연 FE의 담당이 맡는지 의구심이 들었다. 백앤드에게 프로토타입을 적용한 시안과 함께 각 페이지의 역할과 MosCoW까지 작성드렸기 때문에 백앤드에서 흐름을 충분히 이해하고 request와 response를 작성하는게 맞다는 생각이 들었다.
프론트에서 논의끝에 의견을 전달드렸고 백앤드에서도 이 부분에 동의하였다. 결과적으로 API의 request, response는 백앤드가 작성하고 프론트가 확인해서 수정사항을 전달하는 식으로 진행하기로 했다.

본격 개발 시작!

기술 스택

• Next.js
  Next.js의 pages 라우팅이 너무 편할 것 같고, SEO도 적용해보고 싶었다.
• SWR
  Next.js를 사용하는 김에 같은 회사에서 만든 get 요청 특화 data fetching 라이브러리인 SWR을 적용하고 Context.API나 리덕스를 사용하지 않기로 하였다.
  get 요청은 SWR을 감싼 커스텀 훅으로 만들고, 나머지 요청들은 함수들로 만들어 전역에서 사용하기로 하였다.
• Storybook
  컴포넌트 단위 개발이기 때문에 base와 domain 쪽에서라도 Storybook으로 컴포넌트 테스팅을 진행하기로 하였다.
  
  👍 실제로 다른 페이지에 컴포넌트에 적용할 필요없이 스토리북에서 바로바로 확인이 가능한 것이 가장 큰 장점이라 느꼈다. 또 스토리가 하나씩 쌓일수록 뿌듯함도 쌓여갔다 ㅎㅎ
  🥶 다만 Next.js의 기능을 사용하기 위해선 storybook에 따로 처리를 해줘야 했고, plugins을 하나하나 등록해줘야 하는 단점이 있다. (이게 은근 스트레스)
• propTypes, defaultProps
  Typescript를 사용하지 않는대신 propTypes, defaultProps로 타입과 기본값을 명시했다. 덕분에 다른 사람이 만든 컴포넌트에 넣어야할 props를 확인할 때도 propTypes, defaultProps로 확인하면 되니 깔끔하게 파악이 가능했다.

프론트는 base, domain, pages로 컴포넌트 단위를 확장해 개발했다.
가장 작은 단위이며 재사용성이 높은 base를 조합해 domain이 되고 base와 domain을 사용해 page를 완성하는 식이다. 현재는 페이지 개발에 들어갔고 기존에 만들어놓은 컴포넌트들을 레고블록 조립하듯이 합치면 되는거라 그리 어렵지는 않았다.

내가 맡은 일

base, domain 컴포넌트는 다같이 했으니 따로 설명하지는 않겠다.
1. axios interceptor 설정, apis 함수와 swr 커스텀 훅 구현
2. Next.js의 Image, Link, Router를 Storybook에서 사용할 수 있도록 설정
3. 절대경로 설정
4. 로그인, 회원가입 form validation 설정
5. 로그인 시 유저 정보 cookie에 저장
6. react-toasify 적용
5. 로그인, 회원가입 페이지 구현
6. 카드 작성 페이지 구현

😉 좋았던 점

• material-ui나 commitizen, emoji-picker-react, dayjs, js-cookie, react-toastify 등 다양한 라이브러리를 사용해본 점. 앞으로의 프로젝트에도 무서워하지않고 공식문서를 차근차근 읽으며 적용할 수 있는 자신감이 생겼다.
• 작은단위의 컴포넌트부터 시작해 조립하는 방식을 처음 배웠고, 재사용성을 높일 수 있어서 좋았다.
• emotion.js를 통해 CSS-in-JS 를 경험해보았다. js 코드를 props로 받아 css에 적용가능하고 미약하게나마 sass 문법을 섞어쓸 수 있어 편했다. css가 컴포넌트로 바로 사용가능하다는 점도 신기했다. 다만 개발자 도구에서 컴포넌트 이름을 확인할 수 없어 디버깅이 어렵다는 점?... 설정이 가능할 듯 한데 아직은 찾지 못했다
• 겪었던 오류와 해결 경험을 Troble shooting에 정리하였다. 오류는 항상 까먹기 마련이라 두고두고 보기에 좋을 듯 하다. 또 다른 팀원들이 마주친 오류들을 간접적으로 경험하는 느낌이라 적극 추천한다!!!!
  
• 팀원들이 서로 존중하고 각자 할일을 찾아 열심히 하는 모습이 좋았다.
• 리액트와 조금 친해진 것 같아서 기쁘다 ☺️

🥲 아쉬웠던 점

• git을 확실히 이해하지 못했다는 것을 깨달았다. merge할 때 sqush, rebase의 차이점을 확실히 이해하고 사용하자!

• 패키지 매니저를 yarn으로 정했는데 라이브러리를 추가할 때 npm으로 깔아버렸다. 팀원들과 협업시 정한 룰을 지키자!

• 1순위로 만들고자 했던 API가 이번주 일요일까지 배포가 완료됐어야 했는데 기간이 연장되었다. websocket과 oAuth도 진행해보고 싶었는데 일주일 남은 시점이라 안될 것도 같아서 목표를 낮춰야 할지도 모르겠다.

• 나름 커밋을 열심히 했는데 sqush merge가 되다보니 커밋 횟수가 엄청나게 작아져버렸다...!
  

• 최대한 기능별로 PR을 나눠 커밋을 분할해서 작성하는 습관을 들이자.. ㅠ
  

🎯 다음 목표

• 배포된 API들을 적용하고 남은 페이지들을 완성하기
• 될 수 있다면 websocket 실시간 통신을 알람으로 적용해보기