최고의 팀워크는 실력에서 오는게 아니다 - 후즈북 프로젝트 회고

📖 프로젝트 기간: 23/06/28 ~ 23/07/27
📖 프로젝트 이름: 후즈북 (추천 기반 도서 큐레이션 서비스)

후즈북 프로젝트가 끝났다. 처음으로 기획부터 배포 및 데모데이까지 완료한 프로젝트 다운 첫 프로젝트였다. 기술적인 부분은 차차 별도의 블로깅으로 하고, 회고에서는 우리 팀에 대해, 그리고 개인적인 소감을 말해보고자 한다.

 

👏 Keep 

1. 열정과 책임감이 강한 팀원들이 모여 업무 분담도 잘 되었던 점

일단 우리 팀은 프로젝트에 대한 열정과 의욕, 책임감이 강했고 이에 따라 프론트엔드, 백엔드 각자 업무 분담이 잘 된 편이었다. 아마 첫 단추를 잘 끼워서가 아닐까 싶다. 팀원을 모으고 어떤 서비스를 할지 이야기한 것이 아니라, 만들고자 하는 서비스를 먼저 기획해서 팀원들을 모집했기 때문이다.
 

모집 공고와 공지

 
모집할 때도 (1) 이 프로젝트에 참여하고 싶은 이유 (2) 이 프로젝트에서 기여할 수 있는 부분 (3) 이 프로젝트를 통해 얻어가고 싶은 것을 요청했고, 팀원 한 명 한 명을 모집할 때마다 기모집된 팀원들에게도 지원서를 공유하면서 서로를 알아갔다. 각자 코딩 실력은 어떠할지 몰라도 기본적으로 모든 팀원들이 사용자의 시선을 고려하는 사람들이었고, 고객의 니즈를 파악하는 것이 중요하다는 것에 어느 정도 공감하고 있었기에 기대가 되었다.
 

 
그렇게 후즈북을 만들어 갈 '책 4냥꾼' 팀이 꾸려졌다.
 

2. 기획에 시간을 들인 것

모든 팀원들이 시간이 조금 걸리더라도 기획에 시간을 들여야 한다는 점에 공감하고 있었다. 이에 4일 넘게 기획에만 할애해서 후즈북 서비스의 방향성, 타겟부터 각 기능의 존재 목적, 각 기능 구현의 난이도와 중요도까지 세세하게 짚고 넘어갔다. 다행히도 '무엇을 만들지'는 팀원 모집 전부터 큰 얼개가 짜여 있었어서 '어떻게 만들지'에 대해 이야기하는 데에 시간을 많이 쓸 수 있었다.
 
사용자를 지칭하는 단어나 페이지를 지칭하는 단어 등도 짚고 넘어갔고, 기능의 존재 목적 등 WHY에 대해서도 깊이 논의했는데 이유는 모든 팀원들이 개발에 앞서 싱크가 맞아야 했기 때문이다. 만약 같은 것을 이야기하는데 다른 단어로 이야기한다든가, 같은 페이지를 개발하는데 다른 방향으로 기능을 개발하는 일이 없어야 하기 때문이다. 지금 당장은 중요하지 않아 보이지만 돌이켜보면 이런 부분들을 하나하나 잘 짚고 넘어간 덕분에 개발이 스피디하게 이루어질 수 있었던 것 같다.
 

Idea Mix & Mingle 일부

 
언제는 이런 일도 있었다. 백엔드 팀장 분이 일요일에서 월요일로 넘어가는 새벽 1시쯤 논의할 것이 있는데 시간이 되는지 물어보셨고, 마침 나는 공부 중이었어서 급 논의를 했다. 우리가 3일 동안 논의한 부분에서 조금 더 테크적인 부분이 녹아들어가면 좋겠다는 이야기였다. 마침 그 부분이 애매하게 남아있는 것 같다고 느꼈는데 콕 집어주셔서 감사했다. 바로 다음날 아침에 긴급회의를 통해 기획을 수정했고, 다행히 나머지 팀원분들도 선뜻 동의해 주셔서 정말 고마웠다. 
 

사용자 요구사항 정의서 일부

 

3. 빠른 소통 → 해결 → 공유의 선순환

우리 팀은 이슈 대응 속도가 빨랐다. 가능했던 요인은 이슈가 생겼거나 해결이 잘 안 되는 것이 있을 때 최대한 서로 도와주려고 했기 때문이 아닐까 싶다. 이슈가 발생하면 오전 9시든 새벽 4시든 거의 실시간으로 소통하며 해결했다. 애초에 팀원들 모두 따뜻하고 기본적인 배려의 선을 아는 사람들이었기에 어려워하는 부분을 말해도 이해와 배려를 잘해주었고,  힘든 점에 대해 솔직하고 빠르게 공유할 수 있었다. 
 

타 팀이 남겨준 피드백과 답변

 
게다가 팀원들은 각자 맡은 파트가 아니더라도 함께 수정하거나 도와주기도 했다. 프로젝트 막바지에 기술 발표 영상과 서비스 매뉴얼 제작이 겹쳐서 팀원들이 내 파트의 버그 해결을 도와주기도 했고, 타 팀이 남긴 피드백이나 팀 내에서 발견한 에러를 거의 실시간으로 해결했다. 또한 타 팀이 남겨준 피드백과 버그 제보에 대한 답변으로 '후즈북 업데이트 노트'를 만들어서 우리 서비스의 성장 과정도 함께 공유했는데, 멘토님으로부터 이 점을 좋게 평가받았다.
 

QA 리스트, 업데이트 노트

 

4. 문서화와 태스크 체크가 잘 된 점

스스로 강점을 '문서화를 잘하는 것'이라 생각해서 이 부분을 도맡아 했고, 팀원들도 전적으로 맡겨주었다. 매일 두 번씩 하는 스크럼과 주 1회 진행하는 회의는 노션 템플릿을 만들어 문서화에 너무 많은 시간을 쏟지 않도록 세팅했고, 일정과 진행상황 등은 각 포지션에서도 참고할 수 있도록 꼼꼼하면서도 간결하게 기록해 두었다. 문서화가 중요하다고 느낀 건 개발 단계에서였는데, 개발을 하면서 우리가 기능 구현을 언제까지, 왜, 어떻게 하기로 했지? 라는 방향성이 잊힐 때쯤 해당 문서를 참고하면 리마인드가 되었다. 

팀 회의록, 스크럼 보드

 
결론적으로 멘토님이 문서화를 굉장히 잘하고 자료실을 만들어 공유하는 부분이 좋았다는 평가를 해주셨다. 커뮤니케이션, 프로젝트 완성도, 추후 팔로업 등을 모두 모범적으로 잘했다는 평가를 받아 매우 뿌듯했다.

 
 

---

 

🔥 Problem 

팀 단위보다는 각자 개인적인 아쉬움들이 있었다. 

각 팀원들이 느낀 아쉬움

"배포 서버 테스트 시, 다른 팀원들이 배포 담당인 나에게 요청하는 부분이 어려워하실까 봐 그게 우려되었다. 진작에 어떤 툴을 만들어 두었다면 어땠을까 싶다. 더불어 팀장으로서 팀원 분들 한 분 한 분씩 돌아보지 못했던 게 아쉽다."

"기능 구현 시, ‘일단 되게 하자’ 진행해서 나 자신과 남을 설득할만한 이유가 부족했던 것 같다. 무지성 코딩을 하지 않았나 싶다."

"OAuth 소셜 로그인 기능 구현 시간을 많이 써서 다른 advanced 한 기능에 시간을 못 썼던 게 아쉽다. 기술적인 욕심에 비해 적용을 많이 못한 것 같아서 이 점이 아쉽다."

"React에 많은 라이브러리가 있는데, 다양한 라이브러리를 쓴다기보다 익숙한 라이브러리만 썼던 것 같다. 새로운 시도를 통한 공부를 더 많이 해야 할 것 같다."

"프론트 배포 쪽 CI/CD를 안 해두어서 아쉬웠고, 각 팀원들이 진행 상황을 깊게 더 잘 봐드렸어야 했는데 그러지 못해 아쉬웠다. 그리고 문제 발생 및 해결 과정에서 정리해야 될 게 많았었는데 정리를 해놓지 않아서 다 까먹었다."

 
아래는 개인적으로 스스로에게 느낀 아쉬움이다.

2. 멘토링을 더 잘 활용할걸

개인적으로는 코드스테이츠 측에서 프로젝트 기간 동안 제공해 준 주 1회 멘토링을 더 잘 활용하면 좋았을 것 같다. 개발에 시간을 많이 쓰다 보니 멘토링 준비에 시간을 쓰지 못했다. 다음에 이런 기회가 주어진다면 질문을 잘 준비해 가서 깊이 있는 대화와 토론을 하고 싶다. 
 

3. 기록을 더 잘할걸

프로젝트 중간중간 마주했던 어려움을 즉시 & 모두 기록해 두지 못했다. 중간중간 노션에 간단하게 적어두긴 했는데 후반부로 갈수록 마음이 급해져서 기록을 하지 못했다. 
 

4. 기초를 더 잘 다져놓을걸

기초가 부족하다는 점을 여실히 느꼈다. 코드를 짜면서 생각나지 않는 개념은 검색하면서 하느라 시간이 배로 걸렸던 것도 있다. 물론 검색이 필요할 수밖에 없겠지만, 기초적인 부분까지도 서칭 하는 나를 보며 지난날의 나를 탓하고는 했다. 부트캠프 특성상 개념을 빠르게 짚고 넘어가 왔고, 스스로 탐구하는 시간이 적었기 때문이 아닐까 싶었다. 특히 자바스크립트부터 기초를 탄탄하게 다져 놓아야 타입스크립트든 리액트든 잘할 수 있다고 느꼈다.
 
 

---

 

👩🏻‍💻 Try 

1. 에러를 모두가 확인할 수 있도록 세팅하기

에러 로그를 모두가 확인할 수 있는 시스템을 더 일찍 만들었으면 좋았을 것 같다. 각 팀원이 QA 테스트를 할 때서야 에러를 발견하는 것보다, 에러 발생 즉시 알아채서 미리 고쳐두는 편이 낫기 때문이다.
 

슬랙에 연동한 에러 로그

 
현업에서는 슬랙 채널에 로그가 찍히도록 연동해 두고 모두가 확인할 수 있도록 한다. 프로젝트 이후 백엔드 팀장 분이 슬랙과 연동하여 서버 에러를 파악할 수 있도록 만들어 주셨다. 다음 프로젝트는 이러한 시스템을 더 빠르게 적용해서 문제를 빠르게 파악할 수 있도록 하겠다.
 

2. 즉시, 되도록 모두 기록하기

다음 프로젝트에서는 애초에 VScode 옆에 프로젝트 기록용 노션 페이지를 템플릿으로 세팅해 두어 기록하고자 하는 것들을 복붙 해두고, 주말에 최소 2시간 정도 시간을 내서 블로깅까지 해야겠다. 프로젝트를 기점으로 블로깅을 통 하지 못한 게 마음에 걸린다. 사소한 것이라도 기록해 두면 나에게도 좋고, 남에게도 좋다. 특히 개인적으로 너무나 힘들었던 React Quill 부분은 꼭 블로깅을 해두어 다른 사람들에게도 도움이 되고 싶다.
 

3. 기초 다질 시간은 지금밖에 없다

기초가 부족하다고 느꼈다면, 기초를 다질 시간은 지금밖에 없다. HTML, CSS, JavaScript 등 부족하다고 느낀 개념은 즉시 채워 넣어 다음 프로젝트 때는 더 빠르게 코드를 짤 수 있도록 하고자 한다. 
 

5. A to Z 까지 경험해 보기

이번 프로젝트가 끝나면 백엔드 1명과 함께 프로젝트 하나를 더 진행하고자 한다. 프론트로서는 솔로 프로젝트인 셈이다. 아무래도 팀 프로젝트를 하면 기여도와 경험의 폭이 줄어들 수밖에 없기 때문이다. 다음 프로젝트에서는 기존에 구현한 기능을 더 잘 구현하고, 해보지 않은 기능을 시도하면서 서버와의 소통 및 배포도 많이 연습하고자 한다.
 

---

 

🎓 정리하며

이번 후즈북 프로젝트를 통해 내가 잘하는 것, 채워야 할 점이 더 명확하게 보였다. 백문이 불여일견. 일단 직접 해봐야 안다는 점에 매우 공감했고 앞으로도 재미없게 개념 공부만 하기보다 일단 뭐라도 만들어보면서 실전형 개발자가 되고 싶다는 생각을 했다.
 
더불어, 함께 후즈북을 만들어준 팀원들에게 정말 감사하다. 내가 최초로 기획한 건 껍데기에 불과하지만, 팀원들과 알맹이들을 가득가득 잘 채워 넣어 짧은 시간 내에 유의미한 결과물을 만들어냈다는 것이 뿌듯하다. 
 
마지막으로, 최고의 팀워크는 실력에서 오는 것이 아니라 서로에 대한 배려와 열정, 책임감에서 오는 것이라고 생각했다. 우리 팀은 최고의 팀워크를 보여주었고, 이번 프로젝트에서 배운 경험으로 다음에는 더 나은 결과물을 만들어 내고 싶다.
 

---

 
후즈북 배포 링크

Whose Book

 
Github Repository

GitHub - codestates-seb/seb44_main_004: 📖 추천 기반 도서 큐레이션 서비스, 후즈북

 
기술 발표 영상

 
서비스 매뉴얼

SEB_44_Main프로젝트_책4냥꾼_후즈북_WhoseBook_서비스매뉴얼