💸사이트
배포 사이트 현재는 서버가 내려간 상태
💸작업기간
2023.02.13~02.24(12일)
💸팀원구성
프론트엔드 4명, 백엔드 4명
💸 백엔드랑 플젝을 한다..?!
이 프로젝트 전까지 두 번의 프론트엔드 팀 프로젝트가 있었다. 소통 창구(문서화, 음성 및 영상, 작업물 공유, 메신저)를 만들고, 치열하게 회의하고, 치열하게 개발하고, 배포하기! 의 사이클이라는 건 알고 있었다. 그런데 백엔드분들과 함께할 땐, 사이클에서 어떤 과정이 더 추가될지 어떤 것이 꼭 필요한 것인지 예측할 수가 없었다. 파트가 따로 해야할 것과 같이 해야할 것의 역할 분담에 대해, 나름 열심히 구글링 해봤지만 마음에 드는 건 찾지 못했다. 그렇게 마음만 단단히 먹은 채로 시작하게 됐다.
💡돌이켜보기💡
백엔드와 부딪히며 협업해보지 않은 사람 또는 과거의 나에게 미리 알아야할 것을 알려줘야 한다면..?! 간단한 버전은 위의 사이클에서(1)기획을 함께하여 기능구현이 가능한지 불가능한지 의견 주고받기 (2)API명세 같이 꼼꼼히 확인하기 (3)서버 배포 후 수정사항 주고받기가 추가될 수 있다고 말할 수 있지만... 음.. 현실 버전은 딱잘라 말한 것 세가지 +1000 정도의 할 일이 더 많은 느낌이랄까. +1000은... 아래에서 충분히 설명해보고자 한다. 기술적인 면에서는 이때 새로 배우는 라이브러리들을 좀 더 자세히 공부해놨더라면 어땠을까 싶다.
💸 Fastcampus 프로젝트 설명회
Fastcampus 운영진, 프론트엔드 수강생, 백엔드 수강생 모두 줌에서 모였다. 프로젝트의 총 일정과 조편성, 멘토링, 프로젝트 요구사항에 대해 설명해주셨다. 설명회가 끝나고 편성된 조원들이 다같이 모여 간단히 인사하고 다음날 오프라인 회의 일정을 잡았다.
📍 프로젝트 협업 가인드라인
궁금했던 협업 진행 사이클은 아래와 같이 운영진분들께서 가이드라인으로 알려주셨다. 물론 세부적으로 팀만의 규칙과 과정이 필요했지만, 가이드 라인이 있어서 수월하게 작업할 수 있었다.
1.기획 확정하여, 기능 명세 작성
2.프론트엔드 : 와이어프레임 -> UI/디자인
3.백엔드 : DB 설계 -> API 명세 작성
4.API 명세 공유 및 협의
5.개발 시작
📍 프로젝트 요구사항
요구사항은 아래와 같았고, 우리 팀만의 기획으로 다시 세부사항을 정했다.
1.로그인, 회원가입을 JWT 방식으로 구현
2.상품 검색, 정렬, 필터
3.데이터를 Redux로 관리
4.페이지별 화면 전환을 react-router-dom으로 구현
💸협업툴
프로젝트 초반 자연스럽게 협업툴을 정했고, 아래와 같이 활용했다.
📍노션
이 전의 팀 프로젝트를 통해 문서화와 진행 상황 공유의 필요성을 절실히 느낀 나는, 프로젝트에 참여할 때마다 시작과 동시에 노션부터 만들어서 팀원들에게 공유하곤 했다. 이번에도 만들어 공유했지만, 여러모로 부족한 점이 많아 깨달은 점이 있다.
노션은 혼자서 만들어 두기만 하면 안 되고, 팀원들에게 어떤 소통 창구들이 있는지 어떻게 활용해야 하는지 설명을 해줘야 한다는 것이다. 사진처럼 백엔드분들께서는 파트별 체크리스트를 활용하지 않기도 했고, 사진엔 없지만 팀원 정보를 입력하지 않으시는 분들도 계셨다. 활용 방법을 적극적으로 공유할 것!
📍구글 스프레드시트
표를 사용할 때는 노션보다 구글 스프레드시드가 더 가독성이 좋고, 깊은 depth도 잘 나타낼 수 있었다. 버전 기록도 남아 사용하기 편리했다.
📍슬랙
Fastcampus 운영진분들께서 슬랙 채널에 팀 전원을 초대해 주셨고, 기간 내내 직접적인 대화는 슬랙 메시지/음성/영상(일대일)으로 소통했다. 개인적으로는 다른 것에 비해 슬랙이 더 좋았다. 메시지뿐만 아니라 음성, 영상도 pc에서 이용하기 편리하도록 지원해 줘 사용하기 편리했다.
📍Zoom
단체 영상 미팅은 Fastcampus에서 제공해주시는 줌을 활용했다!
📍깃허브
코드는 github으로 관리했다.
💸 회의.. 회의.. 회의!
협업툴을 마련하고, 주어진 과제를 바탕으로 열심히 회의를 했다. 지금에서야 깨닫는 생각이지만, 회의의 내용이 좀더 쫀쫀할 수록 팀프로젝트의 성공률?이 올라가는 것 같다. 왜냐면 신기하게도 같은 A를 두고, 팀원 전부가 똑같이 A라고 생각하는 경우는 하나도 없고 A-1, A-2, A-3.. 으로 생각한다. 설령 일부가 A-1로 생각했을 지는 몰라도, 그건 나중에 알고보면 A-1-1, A-1-2, A-1-3 이더라..ㅎㅎ 그래서 조금이라도 생각의 간격을 줄이기 위해, 구체적이고 유기적인 사고로 생각을 주고받는다면 프로젝트의 일관성이 증가
📍 프론트&백 회의
1.상품 데이터 어떻게 가져올지
- 화면 구성이 돼있지 않아 상품의 어떤 데이터가 필요할지 정확히 정해지지 않은 상태임. 그러다보니 화면을 구성하는 프론트엔드가 상품 데이터를 모으기로 함.
2.로그인 방식
3.주요 기능
💡돌이켜보기💡
백엔드 분들과 기능에 대해 논의하는 시간이 현저히 적었다. 기획에 관하여는 이때 간략히 논의했던 게 마지막 전체회의였다. 프론트 파트에 기획을 맡겨주셔서 프로젝트는 빠르게 진행됐지만, 다같이 확인하는 시간이 없어 크로스체크가 잘 안됐고, 결국 프론트 파트에서 진행한다고 알고 있던 A기능을 백 파트에서는 모르고 있던 상황이 발생했다. 감사하게도 백 파트에서 API추가가 가능하다고 해주셨지만, 이 상황을 알게 됐을 땐 정말 아찔했다.
4.진행 일정
-2/00까지 프론트가 백에게 : 필요한 데이터 정보, 구현할 기능
-2/00까지 백이 프론트에게 : API 명세
-각자 개발 시작
💡돌이켜보기💡
일정을 촘촘히 짜지 않았는데, 당시엔 적당한 방법이었던 것 같다. 다만 큼직하게 짜놓은 목차 속에서 더 자주 소통할 필요는 있었다. 서로의 진행상황을 알 수 없어, 프론트는 마냥 서버 배포를 기다렸고 백은 마냥 화면 구성만을 기다렸다. 지금 다시 한다면, 초반에 WBS를 활용해 일 단위로 전체 일정 계획을 짜두고(물론 계획대로 안됨), 매일매일 데일리스크럼을 진행하며 진행상황을 공유할 것이다.
📍 프론트엔드 회의
1.기술스택 정하기
2.요구사항의 주요 기능 위주로, 대략적인 페이지 구성과 기능 정하기
💡돌이켜보기💡
- Top -> Down 으로 컴포넌트를 구성했는데, 그 안에서 재사용 컴포넌트를 미리 고려해두고 개발했던 것이 좋았다.
- 당시 회의할 때 무척 치열했던 걸로 기억한다. 기획이 뚜렷하지 않으니 기능과 레이아웃도 흔들리는 상황이었다. 우리의 선택은 기획을 뚜렷히 하는 대신, 기능과 레이아웃의 큰 틀 및 대략적인 것만 협의하고 그 안에서는 팀원 각자가 자율성을 갖기로 했다.
3.상품 데이터 모으기
4.역할 분담
-페이지별로 역할을 분담했고 맡은 것 안에서 각자의 자율성을 갖고 기능을 구체화하기로 했다. API도 담당 백엔드 분과 각자 논의하기로 했다.
💡돌이켜보기💡
역할 분담을 하여 기능마다 담당자가 있는 것이 좋았다. 하나하나 모두의 동의를 얻어 진행하기엔 짧은 기간이기 때문이다. 프로젝트 기간 중 오프라인으로 팀원들이 참석하는 날이 많아 프론트끼리는 소통이 매우 원활했던 걸로 기억한다. 다만 코드리뷰나 데일리 스크럼을 진행했더라면, 팀의 연결성을 더 높일 수 있지 않았을까 싶다!!!!
💸 기능명세서와 API정보 작성하기
프론트엔드 파트에서는 역할분담한 것을 토대로 작업을 시작했다. 구두로만 정했던 것을 더 구체적으로 적은 문서를 만들기로 했다.
📍 기능명세서
- 백엔드와 협업하기 위해 사전에 준비하던 중, 기능명세서에 대해 알게 됐다. 사이드프로젝트에서 개발자랑 안싸우는 앱기획하기!와 Figma를 이용하여 프로토타입 제작하기, 기능명세서 작성하기, 회고를 참고하여 프론트엔드 팀원들이 작성할 수 있도록 템플릿을 마련했다.
- 위 사진은 본인이 작업한 부분을 가져온 것이다. 이렇게 미리 기능들의 분기처리까지 상세히 적어놓은 덕분에, 개발하면서 할 고민을 줄일 수 있어 았다. 또 다른 프론트엔드 팀원들이 적어두신 것을 보고, 컴포넌트와 컴포넌트 간의 연결성을 생각해보고 미리 논의할 수 있었다. 다만 기능명세서뿐만 아니라 와이어프레임을 꼼꼼히 짰다면 좋았을 것 같다. 화면의 레이아웃이 서버 데이터 형태까지 영향을 주기에!
📍 API정보
- fastcampus 에서 예시로 적어주신 것을 참고하여, 프론트엔드 팀원이 작성할 수 있도록 템플릿을 만들었다. 나중에 안 것이지만 너무 자세히 적을 수 있게 만들었다..ㅎㅎ..
- 멘토링 시간에 이 부분은 백엔드 파트의 역할이지만, 학습 차원에서는 도움이 될 작업인 것 같다는 피드백을 받았다. 이렇게 주고받을 Request 값과 Response 값의 형태를 프론트엔드 파트가 원하는대로 자세히 적자고 본인이 제안했는데, 백엔드 파트의 역할이라는 피드백을 받아서 할 일이 많은 팀원들에게 미안하기도 했다.
💸 프론트엔드 개발 컨벤션
개발 컨벤션은 오랜 시간 들이지 않고 금방 정했다.
💸 서버 배포 전과 후
- 백엔드는 서버 개발에 들어갔고, 프론트엔드도 API 자리를 비워두고 개발에 들어갔다. 마크업, 스타일링, UXUI를 고려한 기능, 화면 전환을 위한 라우터 등의 작업해나갔다.
- 개발하다보니 postman mock 서버가 나왔고, 며칠 뒤 서버가 배포됐다. 서버가 배포되기 전에 기능은 70% 정도 개발됐다. API를 붙인 후의 개발은 또 다른 세상이었다... 예상하지 못했던 분기처리와 에러가 계속 생겨났다.
💡돌이켜보기💡
- 지금 생각해보면 mock server가 나오자마자 API 처리에 대한 작업을 추가했어야 했는데, mock server를 어떻게 활용해야할지 감이 안와서 시간을 조금 지체했던 것이 아쉽다.
- 제출 시간은 다가오는데 서버가 꺼질 때가 있어 API 테스트를 하는데 곤란했었다. 백엔드 파트에게 서버 상태 변경시 알려달라고 적극적으로 요청하지 않았던 것이 아쉽다. 더 적극적으로 소통했더라면 시간을 지체하지 않았을 것 같다!
- 누락이나 변경이 필요한 값들이 많지는 않았고 소수였지만, 서버 배포 후 요청했던 API가 기능대로 구현된 것이 맞는지, 데이터 타입, 반환 값들을 꼼꼼히 확인하는 게 중요하다는 것을 깨달았다. 시간이 없어 'API가 나왔구나!'하고 당장 작업하고 있는 기능에만 몰두해서, 검토하는 시간이 없었다. 덕분에 다른 기능을 작업할 때가 돼서야, 누락되거나 변경이 필요한 값들을 발견했다. 발견하고 요청해도 되지만, 이게 만약 큰 변경이 필요한 건이라면 수정이나 추가가 불가능할 수도 있기 때문에 서버 배포 후 바로 발견하는 게 좋다는 걸 깨달았다.
- 서버가 배포되자 백엔드 분들과 협업하고 있다는 것을 몸으로 느꼈다. 기획할 때와 다르게 흘러가는 기능 때문에 API 수정도 필요하게 됐는데, 감사하게도 그때마다 바로바로 수정 요청을 받아주셨다.
💸 완료! 결과물 발표회&회고 발표회
결과물 제출과 동시에 프로젝트는 끝났다. Fastcampus 운영진과 프론트엔드 수강생, 백엔드 수강생, 강사님 모두가 모여 하루는 결과물 발표회를 진행했고 하루는 회고 발표회를 진행했다.
📍 나의 협업에 대한 회고
위에서 💡돌이켜보기💡를 통해 이야기했던 것처럼, 그 당시 프로젝트가 끝난 직후에도 비슷한 생각들을 했다. 아래는 프로젝트 종료 직후 나의 회고다.
- 기획과 문서화(회의록, 기능명세서, 와이드 프레임)와 일정 계획을 구체적으로 해야하는 것의 필요성을 느낌.
- FE와 BE의 시스템에 대한 이해도가 증진돼 좋았음.
- 백엔드와 API에 대해 논의시, 데이터별로 중복처리, 정렬, 데이터 타입에 대해 명확히 하는 것이 중요하다는 것을 알게 됨.
- 백엔드 서버 배포시, API가 기능대로 구현된 것이 맞는지/데이터 타입/반환 값을 전부 확인하는 것의 중요성을 알게 됨. 꼼꼼히 확인하지 못해서 작업 중간 또는 마지막에 수정 요청한 것들이 있었음.
- 1일 1회, 3일 1회 등 백엔드와 진행상황을 공유하는 룰이 있었다면, 더 원활한 소통을 통해 프로젝트에 대해서 놓치는 부분이 줄어들 수 있었을 거라고 생각함.
아래는 지금에서 다시 돌이켜보는 회고!
- 아쉬웠던 것(가장 크게 깨달은 것)은 소통, 소통, 그리고 또 소통이었음. '자주', '많이' 소통을 했더라면 오해나 시간지체가 더 적었을 것임. 어려웠지만 결국엔 다 개발이 되어 있고, 우리 나름의 고난과 역경을 헤치고 프로젝트도 잘 완료되어, 개인적으로는 더 재밌는 경험을 했다고 생각함
- 프로젝트 기간 동안 여럿이 볼 수 있는 문서를 잘 정리하려고 애썼는데, 언젠가 한 팀원에게서 매번 문서를 잘 정리해줘서 고맙다는 말을 들음. 노력했던 부분이 팀원에게 도움이 돼 좋았음.
- 소통이 익숙하지 않았던 것일 뿐, 탈주하는 팀원없이 모두 프로젝트를 위해 열심히 개발해주어 생각했던 것이 모두 개발된 완성도 있는 프로젝트였음! 가장 큰 배움은 백엔드와 협업하는 사이클을 대략적으로 이해할 수 있게 된 것임. 내가 어떤 역할을 맡아야 하고, 프론트엔드 팀원에게 어떤 걸 요청 및 제안해야하며, 프론트엔드 파트에서 정한걸 백엔드 파트에게 어떻게 요청하고 제안해야하는지 알게 됐음.
- 다음 프로젝트에는 소통에 대해 더 고민하여 팀원들과 좋은 팀 분위기를 만들어 재밌게 프로젝트를 해보고 싶음.
📍 전체 회고 포스팅
이 포스팅에서는 협업과정을 상세히 담아봤다. 그 외의 구현 기능이나 알게된 것, 해결한 것에 대해서는 아래에 상세히 담았다.
