👥 그룹 프로젝트 시작
CS과정과 개인프로젝트를 마치고 FE, BE 에서 2명씩 모여 공동 프로젝트를 시작하게 되었다.
개인 프로젝트에서는 나만의 프로젝트니깐 나의 수준에 맞추어서 학습하고 구현을 진행했지만,
함께하는 프로젝트는 공동의 목표를 잡고 결과물을 만들어야 하기에 많은 부담감을 가지고 참여하게 되었다.
그렇게 시작된 나의 첫 프로젝트는 4주 동안 진행되었으며 이번 회고에서는 각 주차에 어떤 작업을 했는지
프로젝트가 끝난 지금 각 주차에서 좋았던 점과 아쉬웠던 점을 회고하면서 다음 프로젝트에 반영하고자 한다.
1주차
혼자하는 프로젝트가 아니기에 시작하기에 앞서 그라운드룰을 정해야 한다.
우리가 지켜야하는 약속 그리고 공감대를 형성하는 그라운드룰은 프로젝트를 잘 진행하기 위한 필수 사항이다.
그라운드룰에는 어떤 내용이 필요한가?
- 코어타임, 회의 시간, 데일리 스크럼 시간
- 프로젝트 관리방식
- 팀 분위기를 위한 룰
- 협업에 필요한 컨벤션
- 역할과 책임
그룹 프로젝트의 경험이 있는 동료의 주도하에 나의 첫 그룹 프로젝트 그라운드룰이 만들어졌다.
- 매일 아침 스크럼
- 매주 금요일 팀 회고
- Linear 도구를 이용한 이슈 관리
- 브랜치 전략
- 커밋 컨벤션
FE 동료와의 규칙
그룹의 그라운드룰 다음에는 함께 FE 작업을 진행하는 동료와의 규칙을 정해야한다.
함께 같은 코드를 공유하고 작업하기에 코드의 작성 방법부터 충돌을 막기위한 약속이 필요하다.
다른 사람과 같은 페이지를 함께 작업한다?
계속 혼자서 개발을 했던 나에게는 쉽게 그려지지 않는 상황이었다.
하지만 여기가 어디인가? 함께 성장하는 방법을 알려주는 코드스쿼드다.
프로젝트 경험이 있던 FE 동료가 차분하게 프로젝트를 시작하기 전에
필요한 프로젝트 환경세팅과 폴더구조 그리고 코드컨벤션을 정해보자고 리드해 주었다.
그렇게 CRA, ESLint, Prettier, CSS-module, MSW를 페어코딩으로 설치하고 폴더구조와 코드컨벤션을 정할 수 있었다.
1주차 좋았던 점
1주차에서 정한 규칙 중 가장 만족한 부분은 GitHub를 이용한 PR 규칙이었다.
- 개발을 위한 Story를 작성한다.
- 각 Story에서 필요한 작업(Task)를 작성한다.
- Task는 하나의 브렌치가 되며, 작업이 완료된 브렌치는 FE 브렌치에 PR 한다.
- 매일 아침 FE 그룹원은 서로의 PR을 리뷰 후 merge 한다.
함께 프로젝트를 진행하기에 서로가 어떤 기능을 구현했는지, 어떤 로직으로 개발했는지 공유하고,
서로에게 알려주고 또 배우며 함께 성장 할 수 있는 규칙이었다.
1주차 아쉬웠던 점
프로젝트 Story를 BE와 함께 싱크를 맞추고 작업 순서를 정했지만,
FE에게 최우선 되는 Story와 BE에게 최우선 되는 Story의 순서가 다름을 프로젝트 진행 중에 알게 되었다.
이는 4주차 API 연동에서 많은 오류를 만들게 되는데...
BE입장에서의 Story를 더 고민해보고 API 명세서 작성에 더 적극적으로 참여했으면 좋았을 것 같다.
2주차
팀에게 장애물이 되는것 같은 나
2주차에 들어오며 공통 컴포넌트 생성과 메인 페이지가 되는 이슈리스트 페이지를 제작하기로 했다.
문제는 내가 리액트 경험이 전혀 없다는 것이다...😱
프로젝트 시작하기 전에 이 부분이 걱정되어서 생활코딩의 리액트 강의로 CRAD정도의 기능은 만들어 봤지만,
막상 프로젝트가 시작되고 컴포넌트를 만들려고 하니 코드를 작성하는 것이 너무 두려웠다.
더욱이 FE 동료는 프로젝트 경험과 리액트 경험이 있고, 학습 성향 또한 나와는 정반대로 코드 작성에 거침이 없었다. 의욕있게 코드를 막 작성해 나가는 동료를 보니 나의 존재가 오히려 장애물이 된 것 같아 멘탈적으로 흔들렸다.
결국 개인적인 학습 시간을 동료에게 요청하게 되었는데, 팀 동료는 처음 리액트를 하는 거니 당연하다며 자기가 옆에서 알려줄테니 우선 코드를 생각나는대로 작성하면서 구현 중심으로 실습을 하는 것이 어떻겠냐는 조언을 주었다.
나의 학습 성향 버리기
무언가를 처음 시작하면 학습과 예제를 만들어보고 내가 이해한 내용만을 사용하려던 성향이 강했던 나에게는 정반대의 방식이었지만, 잘하는 동료가 옆에 있을 때 그 친구의 방식을 따라해보는 것도 좋은 경험이 되지 않을까? 라는 생각으로 코드를 작성해 나가기 시작했고 막히는 부분에서는 검색과 질문으로 완벽한 이해 보다는 구현을 위주로 프로젝트를 진행하게 되었다.
처음에는 이게 될까? 라는 심정으로 개발을 해나가던게, 어느덧 버튼 이라는 작은 컴포넌트 부터 데이터를 불어와서 화면을 렌더링하고 있는 페이지가 구현되니 즐거움의 단계에 들어서면서 자신감도 생기게 되었다.
- 2주차부터 구현되어가는 페이지
2주차 좋았던 점
제대로 알지 못하고 처음 접해보는 코드나 기능이라도 우선은 코드를 쳐보면서 구현을 해나가는 방식의 경험을 해보니 이런 방식의 학습 또한 좋은 방법이고 특히 기간이 정해져 있어 빠르게 구현해야하는 그룹 프로젝트에는 더욱 필요한 방식임을 느끼게 되었다.
2주차 아쉬웠던 점
구현을 최우선으로 작업을 하다보니 학습 내용 정리를 거의 못한점이 아쉽다.
개인 프로젝트에서는 하나의 주제를 학습하고 정리하고 적용하면서 실습과 학습 정리가 함께 되었는데 그룹 프로젝트는 팀의 목표가 있고 나의 실력이 부족하니 구현으로도 시간이 많이 부족하며 학습의 여유 또한 없었다.
3주차
본격적으로 개발에 박차를 가하는 3주차에서는 리액트에 조금 익숙해지면서 페이지 하나를 단독으로 담당하고 데이터의 수정기능을 추가하게 되었다. 단순히 데이터를 GET하여 화면에 렌더링하는 작업에서 본격적으로 API와 소통하며 작업이 필요한 단계였고 내 예상과는 벗어나는 오류들이 발생하기 시작했다.
구현에 앞서 설계의 필요성
오류가 발생한 원인 파악에 어려움이 생기고, 동료에게 도움을 요청해도 코드를 보여주며 설명하기에는 이해에 어려움이 많았다. 여러 컴포넌트에서 사용되는 상태가 스스로에게도 명확히 정리가 되어 있지 않았기 때문이다.
이에 현재 사용되고 있는 컴포넌트와 상태, props 등을 시각화하여 정리해야함을 느꼈다.
오류와 설계를 통해 배운점
상태관리에 대한 여러 플로우
- 상태 변경 함수를 호출하고, patch 요청을 날린다.
- 상태가 변경되면 patch 요청을 날린다.
- patch요청을 날린 후 완료되면 state를 변경한다.
상태관리는 부모에서 자식들은 최대한 view만을 가지도록
부모와 자식들(형제)가 상태를 공유하면서 또한 개별적인 상태 또한 가져야하는 문제에 오류가 많이 발생했다.
처음에는 부모, 자식들이 각각 상태를 컨트롤하게 구현을 하니 발생하는 문제였다.
- 부모, 자식들은 공통된 상태와 각자의 상태를 가진다.
- 각자가 공통된 상태(부모로부터 받은)를 컨트롤 한다. 또한 자신의 상태 또한 컨트롤 한다.
- 공통된 상태와 자신의 상태 컨트롤에 마찰이 발생한다.
설계를 하고 분석을 다시해보니 자식들이 공통된 상태를 컨트롤 할 필요가 없었다.
컨트롤 함수를 부모로 부터 전달받아 이벤트만 발생하게 하면 부모에서 모든 상태를 관리하고 자식들에게 전달해주면 되는 방식으로 오류들을 처리 할 수 있었다.
3주차 좋았던 점
설계의 중요성을 체감하고 오류를 해결했음에 굉장히 만족스러운 주차였다.
오류가 발생하고 고민이 많아지니 리뷰어에게 질문 할 내용도 많아지고 학습이 필요한 부분도 파악이 되니
오류란 고마운 존재임을 다시 한 번 배웠다.
3주차 아쉬웠던 점
설계 단계를 너무 늦게 깨달아서 아쉬움이 남았다.
하나의 오류를 해결하는데 소비된 시간이 2일인 경우도 있었기에 조금더 처음 단계에서부터 설계와 고민을 하고 구현했다면 더 많은 기능을 구혔 했을 수도 있다는 아쉬움이 남는다.
4주차
마지막주에는 서버 배포와 API 연동을 최우선으로 선정하여 버그 이외의 기능 구현은 배제했다.
3주차까지의 구현은 MSW를 이용한 mock API에서 작업을 하였고 이제는 BE에서 만들어준 API를 사용하여 웹을 보여주는 단계다.
서버를 배포하고 API와 연동하여 테스트를 하는데 계속해서 네트워크 오류가 발생했다.
오류의 원인은 대부분이 FE에서 작성한 데이터명과 API가 일치하지 않음이었다. 처음 단계에서 API 명세서를 FE와 BE가 함께 확인하고 수정해갔지만, 작업이 진행되면서 조금씩의 어긋남이 있었다. 작성된 코드가 많은 만큼 수정해야하는 코드의 양도 많았고 하나하나 BE와 확인을 하며 수정을 하니 생각보다 많은 시간이 걸리게 되었고, 버그들을 고치는 시간이 부족했다.
공동 프로젝트의 구현 첫 단계는 배포와 API 연동부터
FE도 BE도 함께하는 프로젝트가 처음이니 어쩔수 없는 문제였지만, 마감이 있는 주에 들어서 배포와 API 연동을 진행하려하니 수정해야하는 양도 많고 초조함에 팀원 모두가 잠도 못자고 초췌해진 상태에서 데모를 진행하게 되었다. 공동 프로젝트의 구현 첫 단계에 배포를 해두고 간단한 API 연동을 테스트 후 구현을 해가면서 계속 체크하고 API 명세서도 맞춰감이 마감을 지키고 버그를 줄이는데 베스트 방법임을 알게 되었다.
데모, 그리고 프로젝트 종료
모든 팀들의 프로젝트가 종료되고 데모가 진행되었다.
데모를 통해 다른 팀들의 결과물을 보면서 내가 어려웠던 부분을 어떤식으로 구현했는지,
우리와 다른 부분이 보인다면 어떤 기능을 사용했는지 이야기하며 서로의 프로젝트를 통해 또 배워가는 시간을 가질 수 있었다. (서로가 알지 못하고 있던 버그들도 서로가 귀신같이 찾아도 주었다 😂)
프로젝트를 마무리하며
4주간의 나의 첫 프로젝트는 이렇게 종료되었다.
팀원들 모두 우리가 처음 목표로 잡았던 "상" 항목들은 모두 구현했기 때문에 만족스러운 결과로 마무리 되었다.
개인적으로는 리액트가 처음이라 걱정이 굉장히 많았는데 그래도 팀에게 장애물이 아닌 한 팀원이 될 수 있었다는 점에서 만족스럽다. 아쉬운 부분이라면 리액트 사용에 집중한 나머지 "로그인" 구현에 대한 학습과 실습을 못한점과 GitHub의 이슈와 마일스톤과 같은 기능들을 활용하지 못한 점이 아쉽다.
다음 프로젝트에서는 아래 항목 만큼은 꼭 실천하고자 한다.
- 적극적으로 협업 전략에 참여하기 (그라운드룰, API 명세서 등)
- 프로젝트 구현 전에 배포와 API 연동 테스트 진행하기
- 컴포넌트 생성 전에 설계 먼저하기
- GitHub의 다양한 기능들 사용해보기
