엘리스 SW Engineer 트랙 - 2차 프로젝트
2022.12.12 ~ 2022.12.30 (3주)
2차 프로젝트는 1차와 달리 팀원들과 자유 주제로 웹 서비스를 구현하는 3주간의 프로젝트이다.
한 팀의 인원수도 더 많아져서 우리팀의 경우에는 프론트엔드 5명, 백엔드 2명으로 총 7명이 배정되었다.
나는 이번 2차 프로젝트가 프론트엔드로서 참여하는 첫 프로젝트였기 때문에 한명의 역할을 제대로 해내지 못하면 어쩌나 하는 약간의 우려와 동시에 그 동안 배운 리액트를 드디어 적용해볼 수 있겠다는 기대감을 담은 채 프로젝트에 임했다.
1주차 회고
에너지 가득한 팀원들!
프로젝트 팀이 정해지고 나서 첫 회의를 하고 난 뒤 팀원들이 모두 굉장히 활기차다는 느낌을 받았다.
모두 의견 제시도 적극적이고 새로운 기술에 대한 관심도 컸기 때문에 소통용 메신저부터 개발에 사용할 라이브러리까지 모두 새로운 툴 들을 적용해보고 익혀가는 프로젝트를 할 수 있겠다는 생각이 들었다.
▶ KEEP(다음 번에도 이어갈 부분)
- 상세한 프로젝트 기획( 주요 컨셉 -> 핵심기능 기획-> 페이지 별 기획 )
- 프론트와 백엔드가 함께 참여하는 기획 ( 피그마 단계에서 함께 참여하며 기능 기획 및 진행사항 공유 )
- 레퍼런스를 참고하면서 초기에 디자인 컨셉을 팀원들 간에 확실하게 정해두었음
- 노션에 회의내용, 이슈 등을 팀원 모두가 함께 기록함
▶ Problem(진행하면서 문제가 되었던 부분)
- 개발할 수 있는 시간 대비 너무 많은 기능을 기획함 -> 코치님의 피드백에 따라 메인기능 외의 부가기능을 축소함.
- 여러개를 개발하되 얕게?(우리만 사용하는 기능) VS 하나를 개발하되 깊게?(여러사람이 사용 할 수 있도록)
- 사용자 경험이 중요하므로 유저가 사용하기에 복잡하지 않은 UX 구현 - Gitmoji 이모티콘이 너무 다양하고 의미에 대한 이해가 모두 다름 -> 사용 빈도가 높은 몇가지 이모티콘으로 줄임
- 팀원들이 각자 npm과 yarn을 혼용해서 사용하여 install시 충돌 -> 속도가 빠른 yarn으로 통일.
- 기획 후 본격적으로 코드를 짜려고 하니 tailwind 적용에 어려움을 겪는 팀원이 많음 -> 익숙한 팀원이 적용 예시 코드 공유 및 팀원들과 적용 방법 추가 논의
- 테일윈드 자동완성 확장팩(Tailwind CSS IntelliSense) 설치 후 inline으로 우선 빠르게 구현하기로함
- 공통 컴포넌트이거나 가독성에 의한 필요시 styled-components로 수정하기
▶ Try(다음 진행에서 새롭게 시도해 볼 부분)
- 코치님께서 프론트에서 좀더 깊게 다뤄볼 만한 부분을 말씀해주심 (캐싱이용, 테스트코드, CICD, 라이브러리-직접개발 등)
1주차에 무슨 일들이 있었나?
- 사용할 스택 논의 (Tailwind, Recoil)
팀원이 구성된 첫날부터 이야기 나온 것이 프론트엔드에서 사용할 스택에 관한 부분이였다.
1차프로젝트에서 Tailwind CSS를 쓰고 만족했던 팀원이 2차에도 사용을 제안했고, 가독성 좋은 코드가 장점인 리액트에서는 Tailwind-styled-components를 써서 테일윈드의 간편함과 가독성 모두를 살려보기로 했다. 이전 코치님께서 테일윈드에 대한 이야기를 해주셨어서 나 또한 이번 기회에 사용해 보고 싶었고 다른 팀원들도 긍정적이였다.
상태관리 라이브러리를 어떤 것을 쓸지에 대한 부분을 결정하는것이 어려웠는데, 우선 학습은 리덕스(리덕스툴킷)로 했지만 팀원들 중 아무도 리덕스를 능숙하게 다루지 못했고, 어떤 라이브러리가 어떤 장점이 있는지가 사실 잘 와닿지 않는 상태에서 새로운 라이브러리를 익혀야 한다는 부담이 다들 어느 정도 있었던 것 같다. 나는 아무래도 프로젝트 전에 강의와 미니스터디를 통해 익힌 것을 활용해보고 싶어서 리덕스를 생각하고 있었지만 점점 다른 상태관리들을 찾아볼수록 리덕스만의 장점이 크게 와닿지 않았고 어느 순간부터는 결국 다 비슷한 전역상태관리 라이브러리로 느껴졌다. 고민이 길어지던 가운데 팀장이 주말동안 recoil을 알아올테니 함께 배워보자했고 나 또한 학습난이도가 쉽고 적용이 간단하다는 점에서 recoil로 마음을 바꾸었다. 고민스러웠지만 쉽사리 결정을 내릴 수 없었던 상태관리 툴이 금요일에나마 확정이 되어서 마음이 편안해졌다..!
- 구현 서비스 기획
더불어 첫째 주에는 협업에 관한 규칙들을 통일하고 구현할 서비스에 대한 기획을 하는 데에 대부분의 시간을 보냈다.
1차 때 구체적인 기획이 없던 상태로 프로젝트를 진행했었기 때문에 2차 프로젝트는 완벽하게 기획을 한 후에 개발을 시작하고 싶다는 바람이 있었다.
웹페이지에 진입한 후 최종 단계까지 유저 플로우가 끊김없이 잘 흘러가는 서비스를 구현해서 완성된 프로젝트 결과물을 만들어 내고 싶은 마음이 컸기 때문에 이렇게 상세히 의견을 나누는 과정들이 너무나 필요하다고 생각했고, 시간이 아깝지 않았다. 하지만 슬랙의 허들로 10시부터 새벽2~3까지 이어지는 음성 회의에 아이디어가 필요한 부분과 의논해야할 주제들이 계속 오고가다 보니 뒤로 갈수록 정신이 혼미해지기도 했다...ㅎㅎ
+이번 팀원들은 다들 기록이 습관화 되어있어서 어떤 기획에 대한 논의가 오고갔으면 팀 노션에 모두 적어주어서 나중에 확인하기 정말 수월했다. 스크럼, 오피스 아워에 나온 이야기들을 정리하러 노션 페이지에 들어가면 벌써 한 문단씩 맡아서 작성 중인 팀원들의 아이콘을 볼 수 있었다. (감동...)
- 협업규칙 통일
우리 팀은 협업 관련 규칙들을 굉장히 상세하게 정했다.
팀 진행 내용은 기본적으로 노션에 기록하고, 회의와 소통은 슬랙의 각 채널에서 이슈를 공유하며 진행했고, 일정관리는 Jira를 사용했다.
또한 GitLab의 커밋컨벤션은 Gitmoji를 사용하면서 통일하고 MR시 Squash를 통해 깔끔하게 커밋내용을 합치기로 했다.
이 외에도 Eslint, Prettier를 통해 코드 컨벤션도 통일하면서 하나씩 협업방식을 맞춰나가는 시간을 가졌다.
당연한 것일지 몰라도 1차때 제대로 적용해보지 못한 부분들이라 체계적으로 프로젝트를 할 수 있을 것 같다고 생각했다.
- 개별 페이지 마크업
피그마작업이 끝난 뒤 주말에는 각자 맡은 페이지에 대한 구현에 조금 더 집중할 수 있었다. 내가 마크업으로 맡았던 홈화면에서 기능을 조금씩 추가하고 네비게이션 바는 여러 페이지에 사용되기에 공통컴포넌트로 따로 빼서 구현하기로 했다.
- 활발한 git pull/push
페이지 구현에 들어가기 시작하면서 프로젝트 초기 세팅이 이뤄졌다. 기본 설정에 능숙한 다른 팀원들이 dev 브랜치에 수시로 업데이트를 해주었는데 하위브랜치를 파서 작업하고 있던 나는 처음에 이렇게 수시로 업데이트를 하면 언제 적용해오나 당황했다. git pull origin dev 의 존재를 몰랐기 때문인데... 이전에 1차 프로젝트때는 각자 dev브랜치에 본인의 브랜치를 merge 하고 다른사람들도 모두 merge완료 된 후에야 다시 dev에서 하위 브랜치를 생성해오는 방법으로 업데이트를 받아왔다. 1차 프로젝트를 하면서 나름 git을 잘 쓸수 있게 되었다고 생각했었는데 지금보니 이렇게 기본적인 사용법도 모르고 고생을 했었다는 사실이 충격이였다ㅎㅎ... 다른 브랜치의 내용을 받아올 수 있을거라곤 생각도 못했는데 이 방법을 알고 난 후 부담없이 pull, push를 해올 수 있었다. 아마...1차때 이걸 몰라서 각자 몰아서 병합하느라 conflict가 그렇게 많았나보다 싶은 생각이 들었다.