팀프로젝트
👔 들어가며
이번 4개월차 회고는 한 달간 진행한 팀프로젝트에 대해 비중 있게 다뤄보려 한다. 사실 개인 혹은 둘 정도의 소수로 구성된 프로젝트를 진행한 경험은 두어 번 있긴하지만, 이렇게 많은 인원들로 본격적인 협업 프로젝트를 진행하는 것은 이번이 처음이였다. 리액트 학습 기간부터 함께한 팀원들과 함께 프로젝트를 시작하게 되었다. 배포된 프로젝트는 🔗이 곳에서 확인할 수 있다.
GitHub - prgrms-fe-devcourse/FEDC5_STYLED_sehee
Contribute to prgrms-fe-devcourse/FEDC5_STYLED_sehee development by creating an account on GitHub.
github.com
📝 기획
프로젝트의 요구사항은 기본적으로 SNS의 형태를 띄고 있었다. 로그인/로그아웃을 지원하고, 게시물을 통해 소통할 수 있으며 유저 간 메시지 교환이 가능했다. 요구사항과 API가 공개된 후, 우리 팀은 각자 아이디어를 하나씩 생각해와 회의를 진행했다. 다양한 테마와 컨셉들이 제시되었고, 그 중 요구사항에 가장 적합하다고 판단된 OOTD 공유 SNS인 스타일드를 채택하게 되었다.
🧑🏻💻 협업
Task 분담
Task의 분담은 제공된 요구 사항에 기반하여 기능 단위로 이루어졌다. 너무 Atomic하지도 않고, 하나의 feature 브랜치에서 작업한 후 PR을 보낼 수 있을 만한 적당한 단위로 잘 나뉘어졌다고 생각한다. 다만 Notion을 통해 Task 관리나 이슈 트래킹이 이루어졌었는데, 관리적인 측면이나 PR과의 연동성 측면에서 깃허브를 활용하면 더 좋았을걸 하는 생각을 했다.
PR과 코드리뷰
먼저 우리 팀은 Git-flow 브랜치 전략을 채택하였고, 이를 바탕으로 프로젝트 성격에 맞게 조금 커스텀하였다. 다섯 가지 형태의 브랜치를 활용하는 기존 방식에서 release 브랜치를 제외한 네 개의 브랜치(main, dev, feature, hotfix)를 사용하기로 했다. 따라서 모든 기능 개발은 feature 브랜치를 통해 이루어졌고 할당된 하나의 Task 단위마다 feature 브랜치를 분기해 작업을 진행하였다.
PR은 반영할 브랜치 / 구현한 기능에 대한 간단한 설명과 영상 / 변경 사항 체크리스트 / 질문사항으로 양식을 구성하여 작성하였다. 프로젝트를 진행하며 꽤나 만족스럽게 사용했어서 별 일 없는 한 해당 양식을 계속 써도 좋겠다는 생각을 했다. 물론 다소 귀찮을 수 있는 일이지만, 협업 과정에서 팀원들 상호 간의 코드를 이해하는 시간을 줄여주고, 코드리뷰의 퀄리티를 올려주는 아주 중요한 역할을 하지 않았나 생각된다.
코드리뷰도 원활히 이루어졌다. 친절하게, 그럼에도 날카로운 근거와 함께 개선 방안을 제시받을 수 있어 너무 좋았다. 놓치고 있던 부분도 있었고, 미처 생각지도 못했던 부분들도 있었다. 팀원 분들에 비해 상대적으로 부족했던 부분인 것 같기도 하다. 물론 브랜치를 옮겨 개발 서버에서 테스트도 해보고, 코드들을 읽어보며 최대한 더 나은 방안을 제안드리고자 노력했지만 개인적으로 아쉽지 않았나.. 하는 생각이 든다. 그래서 최대한 많이 경험해보며 피드백 받은 것들을 추후 응용할 수 있을 정도로 습득해놓으려 한다.
💡 배운 점
재사용성을 고려하여 프롭스를 추상화하기
첫 번째로 맡은 Task는 공용 컴포넌트들을 작업하는 일이었다. 가장 빈번히 사용되는 Button 컴포넌트부터, 사용자 경험을 향상시킬 수 있는 Spinner와 Skeleton까지 다양하게 작업하였다. 일단 명세해놓은 기능들을 보면서, 어떻게 해야 팀원들이 좀 편리하게 작업할 수 있을까를 계속 생각했던 것 같다. 그래서 최대한 수정 가능한 속성들을 많이 열어주면서, 굳이 값을 부여하지 않아도 사용하는 데에 문제가 없도록 구성을 하였다. 또한 rest props와 useRef 훅을 부착하여 추가적인 커스텀을 가능하게 해줌으로써 재사용성을 향상시켰다.
Task를 개발하는 루틴
하나의 기능을 구현하는 데에 있어 나만의 루틴이 어느 정도 형성되었다. 의사 로직을 주석으로 짜놓고 하나씩 해치우면서 최종 커밋 전에 지워주는 식으로 작업을 진행했다. 몇 번 해보니 속도가 붙어 하루에 두 개의 Task까지 해치울 수 있었다. 인간 J..나쁘지 않을지도..?
진행 과정은 다음과 같다.
- 대략적인 컴포넌트 구조 설계
- Props 설정과 Type 명시
- 대략적인 스타일링 (Styled-component를 사용했어서, 대부분의 HTML 요소들을 한 번씩 감싸줘야 했다)
- 컴포넌트 구현
- API 통신 구현
- 기타 에러 핸들링
- 이후 코드리뷰를 통해 피드백받은 사항들을 수정
Git을 통한 협업과 충돌처리
사실 처음엔 좀 걱정을 했다. 다섯 명이라는 적지 않은 규모로 프로젝트를 진행하는 것이 처음이기도 했고, Git이라고 해봐야 그 날 학습한 내용 커밋하고 코딩 테스트 문제 푸는게 전부였기에.. 이거 날리면 어떡하지? 중간에 코드 꼬이면 어떡하지? 일어나지도 않은 고민들을 사서 했던 것 같다. 결론적으로 굉장히 순탄하게 진행되었다. dev에서 feature 브랜치를 분기하여 작업하고, 테스트 후 PR하거나 도중에 dev에 변경점이 생긴다면 원격 저장소에서 당겨와 갱신해주고.. conflict 잡아주고.. 이렇게만 하니 크게 문제가 생기는 일은 없었고, 협업하는 사이클에 대해 굉장히 많이 배울 수 있었다.
순탄하게 프로젝트를 진행할 수 있었던 이유는 소통이었던 것 같다. 스크럼과 슬랙을 통해 활발히 의견을 나눴고, 특이사항이 발생하면 그때그때 공유했다. 이게 가장 1차원적으로 confilct를 방지할 수 있었던 방법이지 않았나 싶다. 울팀.. 최고..
PR들을 merge하는 과정에서는 git squash를 사용하였다. dev로 넘어오는 PR들을 굉장히 깔끔하게 관리할 수 있게 되었다. 또한 커밋마다 PR 넘버가 연동되어있어, 세분화된 커밋들을 추적하는 것도 그리 복잡하지 않았던 것 같다.
반응형 단위로 뷰 구성하기
다양한 환경에서의 사용자 경험을 고려해, px 단위의 사용을 최대한 지양하고 반응형 단위를 사용하기로 했다. 처음에는 익숙치 않았는데 쓰다보니 점점 적응되었던 것 같다. 의존성을 갖고 변경될 필요가 있는 속성들은 CSS-in-JS 방식으로 값들이 유동적으로 계산될 수 있게 구현해주었다.
Figma와 디자인시스템
최종 제출 기한 4일 정도를 앞두고, 꽤나 파격적인 제안을 했다. 저희..디자인 한 번 싹 갈아엎을까요?
프론트엔드 엔지니어에게 있어 디자인과 시각적인 영역이 가장 우선시되는 요소는 아니지만, 포트폴리오를 준비하는 주니어 지망생들에게 결코 무시할 수 없는 부분이라고 생각하였고, 이제 어느 정도 기능 구현도 마무리되었다 생각해 얘기를 꺼내보았다. 뱉은 말을 지키기 위해 사나흘을 거의 잠도 못자고 작업했던 것 같다. 농담안하고 다크써클이 뺨까지 내려왔었는데, 어 이거 좀 큰일 날 수도 있겠는데 하는 시점에 마무리가 되었다. 100% 만족스럽지는 않았지만 다크모드나 반응형도 고려해가며 시간 대비 괜찮은 디테일이 나와서 다행이라는 생각을 했다.
가장 힘들었던 점은 모든 팀원들의 코드 작성 방식을 이해하는 것이었던 것 같다. 물론 스타일링 하는데 깊은 로직까지는 안 건들였지만, 컴포넌트 배치부터 시작해 로직이 섞여 있는 경우도 있어서 팀원 분의 양해를 구하고 수정한 적도 있다. 근데 뭐.. 내가 뱉어놓은 말이니 그냥 머리 뜯어가면서 해야지.. 그래도 확실히 프로젝트 초기 단계에서 설정한 디자인시스템이나 공용 컴포넌트들 덕분에, 신경 써야할 부분이 훨씬 줄어들었었다. 재사용의 중요성을 절실히 깨달았던 경험이었다.
🙁 아쉬웠던 점
좀 더 체계적인 일정 산정
프로젝트를 진행함에 있어 크게 두 번의 스프린트를 통해 Task를 분담하였다. 첫 번째 스프린트에서는 기획이나 개발환경 구성, 기초 컴포넌트 제작이 이루어졌고 두 번째 스프린트에서는 본격적인 기능 개발이 이루어졌다. 물론 프로젝트의 기한에 맞춰 잘 마무리되었지만, 좀 더 체계적으로, 디테일하게 일정을 관리했다면 최적화나 리팩토링을 할 수 있는 여유가 더 생기지 않았을까하는 아쉬움이 있다. 개발 외에도 발표 준비에 기획서 정비 등.. 막바지엔 거의 며칠 동안 잠도 잘 못자면서 준비한 것 같다.
그래서 다소 빡빡할진 몰라도.. 스프린트를 잘개 쪼개고, 각 Task에 대해 작업에 필요한 예상 소요 일수까지 산정하여 여유를 두고 프로젝트를 고도화하는 것이 더 완성도 있는 프로젝트를 만들 수 있지 않았을까 생각해봤다.
요구사항을 너무 투명하게 구현한 점
앞서 말했듯 본 프로젝트의 요구사항은 소셜 네트워크 서비스, 즉 전형적인 인스타그램과 페이스북의 형태를 띄고 있었다. 그래서 기획 단계에서는 사실상 어떤 테마가 가미된 인스타그램을 만드느냐의 차이라고만 생각을 했었는데, 꽤나 잘못된 생각이라는걸 깨달았다. 프로젝트가 마무리되어가고 있는 시점에서 다른 팀들의 작업물을 보니, 되게 좋은 아이디어로 API를 잘 활용했다는 느낌을 받은 것들이 종종 있었다. 사~실 프로젝트 중후반 쯤 꽤 괜찮은 아이디어가 떠오르긴 했지만 그 때 가서 피벗팅을 할 수도 없는 노릇이었고, 그냥 내 아이디어 보따리에 고이 모셔두기로.. 했다.. 결론적으로 추가적인 API 가공이나 포장을 통해 좀 더 특색있는 서비스와 도메인을 기획해봤으면하는 아쉬움이 있었던 것 같다.
Task 관리, 이슈 트래킹에 깃허브 활용하기
프로젝트 간 기능 명세부터 기획서와 회의록 작성, Task 관리 등 협업에 있어 전반적인 요소들에 노션을 활용하였다. 물론 개인적으로 이전부터 노션을 잘 써왔고, 지금도 일정 관리나 브레인스토밍은 노션을 통해 이루어지고 있지만.. 접근성 측면에서는 그리 메리트있는 툴이 아니라 생각된다.
결국 이번 프로젝트의 목적은 협업을 경험해보고 누군가에게 보여주기 위한 포트폴리오를 만드는 것이라 생각했기에, 좀 더 접근성이 좋고 보기 편한 깃허브를 잘 활용했으면 어땠을까하는 아쉬움이 있다. Issues 탭을 통해 구현할 기능이나 발생한 문제들을 리스트업하고, 이를 Pull Request와 연동하여 정리하면 레포지토리 페이지 하나로 협업에 대한 전반적인 이해가 가능하기 때문이다. 그래서 프로젝트 기획 단계부터 팀원 분들을 설득해보았으나.. 어필이 다소 부족하지 않았나.. 하는 아쉬움이 있다 🥲
프로젝트 막바지에 추가로 알게 된 것이 Projects 탭의 칸반보드였다. 이러면 진짜 노션 쓸 필요가 없는데..? 라는 생각과 함께 2차 방학 기간에 공식문서를 공부해 파이널 프로젝트에 적용해볼 계획이다.
기술적인 부분에서의 적극적인 참여
개인적으로 가장 아쉬웠던 부분이다. 그냥 인간 황재웅의 특성일지 모르겠지만.. 할 만한 것들만 가져갔고, 할 만한 트러블 슈팅에만 의견을 냈던 것 같다. 좋게 말하면 배우려는 자세이나, 수동적으로 비춰지는 부분이 종종 있었던 것 같다. 그래서 좀 더 적극적으로 기술적인 의견을 내고, 난도 있고 깊이 있는 기능을 구현해보았으면 하는 아쉬움이 있다. 프로젝트를 진행할 때는 크게 체감하지 못했던 부분이었는데 돌이켜보니 그리 좋지 않은 스탠스라 생각 되어, 곧 있을 파이널 프로젝트에서 가장 중점적으로 개선해보고자 한다.
💬 프로젝트 후기
고려해야될 부분들이 굉장히 많다
사소한 것 하나하나 결정해야될 사안들이 너무 많다! 아마 API까지 직접 기획해야 하는 파이널 프로젝트에서는 더 많아지겠지.. 이 과정에서 팀원들과의 커뮤니케이션과 근거에 기반한 논리적인 의견 제시가 중요하다는 생각을 했다. 또한 개발 외적으로 소모되는 시간이 정말 많았다. 기획하고.. 회의하고.. 코드리뷰하고.. 다음엔 PM분들과도 함께 작업해보고 싶다.
그 와중에 협업은 재밌고
이번 프로젝트를 진행하면서 가장 크게 의의를 둔 것이 협업 프로세스를 경험하고, 방식을 익히는 것이었는데 정말 만족스러웠던 것 같다. 브랜치 관리나 충돌 처리하는 과정도 재밌었다. 물론 아직 제대로 혼이 안나봐서 그런 걸지도..? 한 번은 두 시간 가까이 수정한 충돌 이슈가 깃허브 세션 만료로 날아간 적이 있는데, 팀원 분들의 전폭적인 페어 프로그래밍 덕분에 빠르게 복구할 수 있었다. (충돌 처리는.. VSCode에서..🗒️)
팀원들 덕에 더 그렇게 느껴졌던 걸지도 모르겠다. 친절하고, 코드 잘짜고, 책임감 있고.. 과분하리만큼 좋은 분들을 만났다. 이게 바퀴벌레 포커의 힘..?
프로젝트에서 얻어가는 것
- 전반적인 협업 프로세스에 대한 이해
- 완성도 있는 파이널 프로젝트를 위한 초석
- 기술적인 부분 (jwt 토큰 교환 방식의 인증, API 활용로직, 컴포넌트 추상화, 커스텀훅 활용 등)
⚙️ 리팩토링
- 컴포넌트간 위임되는 Props들을 전역 Store에서 관리하기 (의존성)
- React-query 로직들(useQuery, useMutate)을 커스텀 훅으로 분리하기 (재사용성)
- 추상화할 수 있는 컴포넌트 찾아보기 (재사용성)
- API 통신 간 특정 시간 초과 시에만 스켈레톤 UI 적용하기 (사용자경험)
- 페이지 트랜지션 적용하기 (사용자경험)
- JSDoc을 통한 함수 문서화 (협업)
- 추가적인 성능 개선, 최적화 방안에 대해 생각해보기
🚀 파이널에 적용하기
- QA와 리팩토링까지 고려한 좀 더 디테일한 일정 산정
- 깃허브 Milestone, Projects를 이용한 Task 관리
- 인식한 문제에 대한 원인과 해결을 위한 사고 과정, 결론 도출 과정을 그때그때 문서화
- 백엔드와 원활히 소통할 수 있는 방법 구상 : 원하는 API의 형태를 미리 목데이터로 구성해 제안하는 등
- 더 적극적으로 논리적인 근거에 기반해 의견을 제안하고, 문제 해결에 참여할 것
- 다양한 기술과 구현방식을 경험해보고, 활용법과 특징을 익힐 것
- 특정 아키텍쳐 패턴을 적용하여 구현해보기
이번 달, 간단히 돌아보기
🧑🏻💻 코딩테스트 스터디
새해를 맞아 야심차게 준비했던 코딩테스트 스터디의 모집을 시작했다. 단 한 분! (소중..)께서 연락을 주셔서, 지난 주부터 같이 문제를 풀고, 간단한 코드리뷰도 진행하고 있다. 애초에 진행 중인 프로젝트나 학습에 크게 부담되지 않는 선에서 병행할 수 있도록 스터디를 기획하였기 때문에, 가벼운 마음으로 감을 되찾고 있는 중이다. 1월 달에는 PCCP 모의고사 문제들을 풀어봄과 동시에 NodeJS 입출력 처리를 공부하고, 2월부터 백준으로 넘어가려 한다. 차차 학습 비중을 늘려나갈 생각이다.
🏃🏻 페이스 점검
이번 달의 메인 토픽은 역시 팀프로젝트다. 느낀게 있다면 굉장히 자율적이라는 점이다. 프로젝트 규모에 비해 인원이 여유로웠어서 그런건지는 모르겠지만, 맡은 일을 끝낸 후엔 짬짬히 코딩테스트 준비나 리액트 강의를 복습하는 시간을 가질 수 있었다. 프로젝트에 온 힘을 쏟으면 완성도는 좋을지 몰라도 다른 것들을 챙길 수 없게 되고, 반대가 되면 흔히 말하는 빌런이 될 수 있기에.. 완급을 조절하는 일이 되게 어렵고 중요하구나라고 생각을 했다.
따라서 얼마 뒤에 있을 파이널 프로젝트에서도 맡은 바 최선을 다하고, 다른 취준과 관련된 부분들을 균형 있게 챙기기 위해 노력할 것이다.
앞으로의 계획
2️⃣ 2차 방학 기간
사실 벌써 방학이 끝나간다. 이틀 간의 달콤한 방학이었는데 이틀 째 회고를 쓰고 있다.. 아래는 내가 방학 때 진행하려고 계획했던 것들이고, 다음 한 주도 데이터 시각화 커리큘럼을 진행하며 비교적 여유가 있어 마저 실행해보려 한다.
- 팀프로젝트 회고 작성
- 자소서 및 이력서 정리
- 못들은 강의, 세션 수강하기
- 공식문서 공부 (Zustand, React-query, Github)
- 이번 프로젝트 리팩토링
- 파이널 프로젝트 준비
📅 다음 달
대망의 파이널 프로젝트가 시작된다. 이번 팀프로젝트를 진행하면서 느낀 것처럼 미리미리 준비해서 완성도 있는 프로덕트를 만들어 보고 싶다. 동시에 코딩테스트, 기술면접 준비도 꾸준히 병행해나갈 계획이다. 수료와 취준이 다가오는 만큼 후회없게 준비하고 싶다.
긴 글 읽어주셔서 감사합니다.
