1차 프로젝트가 끝나고 바로 2차 프로젝트를 시작하였고 순식간에 마무리되었다. 최종 프로젝트답게 기간이 1차 프로젝트의 두배였고, 돌이켜보니 꽤 긴시간이었다는 생각이 든다. 기획부터 개발까지 오로지 팀원들만의 힘으로 프로젝트를 진행한적은 처음인만큼 소중한 프로젝트이다. 소개보다는 느낀점 위주로 작성하였다.
기획
테오의 스프린트
백엔드와 기획단계부터 하나의 제품을 만든다는 각오로 프로젝트를 진행한적은 처음이어서 긴장이 됐다. 심지어, 같은 프론트엔드 팀원도 만난지 얼마 안됐었고 백엔드 팀원에 대해서는 아예 일면식이 없는 사이라서 더더욱 그랬다.
하지만, 정말 다행히도 백엔드 분들이 초반 단계에서 게임을 비롯한 아이스 브레이킹을 주도적으로 잘 진행해주셨고, 의사소통을 적극적으로 하려는 태도가 느껴졌다. 덕분에 편안한 마음을 가지고 프로젝트에 임할 수 있었다. 감사합니다!!
기획은 넉넉하게 2주동안 진행되었고, 초반 일주일은 테오의 스프린트 방식을 이용했다. 프로젝트 직전에 테오님의 세션을 통해서 기획단게에서 테오님이 소개하신 스프린트 방식이 좋아보여서 백엔드 팀원들에게 소개를 하였고 흔쾌히 받아들이셨다.
형식은 테오의 스프린트 14기 템플릿을 사용했고, 원래는 일주일동안 기획단계부터 개발/배포까지 스프린트 형식으로 진행하는 방식이었는데 두달동안의 개발 기간이 주어지기도 했고, 빠른 개발/배포는 현실적으로 불가능하다고 판단해서 기획단계만 활용하였다.
결과는.. 대만족이었다!
피그잼으로 동시에 특정 주제에 대해서 시간을 정해놓고 고민하고 공유하는 방식이 처음에는 조금 어색하고 화면이 화려한(?) 느낌이어서 집중이 풀리는 느낌이 있었는데 대면의 장점 + 비대면의 장점이 합쳐져서 시간을 굉장히 아낄 수 있으면서도 높은 완성도의 기획을 진행할 수 있었다. 다른팀도 대부분이 테오의 스프린트 방식을 이용해서 기획단계에 적용해 덕을 많이 봤지않나 싶다.
이후에 디자인은 팀원들이 만든 와이어프레임을 바탕으로 한 분이 수고해주셨다. 디자인 경험이 있으신 분이라 그런지 빠르고 근사하게 만들어주셨다. 감사합니다!!
개발
개발은 약 6주동안 진행되었다. 이전 프로젝트에 비해 2배나 늘어난 기간이다보니 넉넉할 것 같다는 생각이 들었고 자신감이 치솟았다. 이 당시에는 개발기간과 프로젝트의 완성도는 비례한다는 생각에 거의 완벽에 가까운 프로젝트를 상상하며 개발을 시작했다.
1주동안 총 6번의 스프린트 단위로 개발을 하기로 계획했고, 각종 컨벤션을 정하고 개발에 들어갔다.
컨벤션
초기 개발 세팅과 컨벤션 정하는 회의를 이전부터 주도해보고 싶었고, 막상 맡아서 해보니 크게 어렵지는 않았다. 내가 이전 프로젝트에서 사용해보고 괜찮았던 싶은 형식을 그대로 가져왔고, 각 팀원들이 주장하는 것과 비교해서 실시간으로 최선의 컨벤션을 빠른 시간내에 모두 정할 수 있었다.
다만, 조금 아쉬웠던건 나 포함 다른 팀원들이 일관성 있는 코드 작성을 위해 만들어진 코드 컨벤션에 대한 숙지가 잘 되어있지 않아 서로의 코드상태가 뒤죽박죽이어서 이것을 다시 맞추고 가는데 시간을 꽤 소비했던 것 같다.
회의
초기에 task 분배, Git 오류 수정, 전역상태관리 고민 등 같이 얘기할 거리가 많았었다. 하지만, 배보다 배꼽이 커지듯 하루에 주어진 코어타임 시간 5시간 대부분을 차지할 정도였고, 이런 흐름이 일주일이 되도록 계속되어서 정작 기능 구현을 제대로 하지 못하는 일이 발생하였다.
그러던 중...
팀원중 한분이 회의가 끝나자마자 슬랙에 스레드를 남겼다.
내가 회의를 주도하지는 않았지만 팀원분이 공유해주신 회의에 대한 글을 읽고 현재 진행되고 있는 회의 방식이 완전히 잘못되고 있다는 것을 깨달았다.
글의 내용은 핵심 내용은 다음과 같았다.
회의는 아주 생산적이거나 완전한 시간낭비 둘 중 하나이다. 중간은 없다. 회의에서 가장 중요한것은 시간 지키기이다.
하지만, 회의가 예상시간보다 길어지는건 일상아닌가? 왜그럴까? 이유는 대부분 주제가 꼬리에 꼬리를 물어 엉뚱한 곳으로 가는 경우, 원래 회의에 없던 안건을 얘기하는 경우, 결론이 나려면 한참이 나는 경우이다.
어떻게 하면 회의 시간을 잘 지킬 수 있을지 몇가지 방법을 소개하겠다.
1.회의 전에 Summary 및 주제에 관한 context 전달
2.회의에서 얻고자 하는 것을 직설적으로 얘기하기
3.회의시간을 철저히 준수하겠다고 미리 양해 구하기
4.회의가 주제에서 조금이라도 벗어날 경우 과감히 자르기
등등...
우선, 위에서 언급한 것들 중 대부분의 사항들이 지켜지지 않았는데 특히 "회의에서 얻고자 하는 것을 직설적으로 얘기하기", "회의시간 철저히 준수", "주제에서 벗어날경우 자르기" 정도가 핵심이라고 생각하였다.
현재 회의는 짧은시간안에 딱! 정할걸 정해야하는데 시간을 정하지 않다보니 점점 긴 회의가 당연하게 여겨져 한 주제를 가지고 느슨하게(?) 애기하다보니 이야기가 딴 길로 새는것도 문제도 발생하고 있었다.
또한, 노션이나 slack이라는 비동기 소통방식을 제대로 이용하고 있지 않은것도 크다고 생각했다.
따라서, 완전히 개선되지는 않았지만 위에 언급한 개선점들을 수용해 회의에 대한 시각을 다르게 바라봐 시간 낭비를 조금이나마 줄일 수 있었다.
시간의 소중함을 알려준 팀원에게 감사하다..!!
새롭게 알아가게 된 것들
개발 시작 직후 컨벤션을 정하면서 서로가 개발하면서 얻은 지식, 트러블슈팅등을 공유하고자 노션에 지식공유 탭을 만들었고, 좋은 공유 문화를 형성할 수 있었다.
또한, 다양한 라이브러리를 도입해서 사용했다.
chakra UI라는 간편한 디자인 라이브러리, react-hook-form 라이브러리, 백엔드 API 개발과 UI개발이 동시에 진행되어야하는 경우에 유용한 msw, 코드를 작성할때 관심사 분리, 다양한 리액트 디자인 패턴 등 많은 지식과 경험을 얻을 수 있었고, 한층 더 성장할 수 있었다.
진행상황 공유
이번 프로젝트에서 제일 큰 문제점은 스프린트를 제대로 진행하지 않은 점이라고 생각한다.
분명 일주일단위마다 Task를 분배하고, Github Project의 칸반보드를 활용했지만 스프린트가 제대로 지켜지지 않았다.
백엔드 팀원은 매일 서로의 진행상황을 공유하고 오늘 할일을 간단하게 공유하는 데일리스크럼을 진행했지만 우리팀은 잠깐하고 말았다.
몇일간은 백엔드를 따라서 데일리 스크럼을 진행했지만 점점 갈수록 기능구현이 우선이니까, 피곤하니까, 하루정도는 안해도 상관없으니까 등등 여러가지 핑계로 진행하지 않았고 일주일에 한 번 정도 말로만 서로의 상황을 공유하는 정도로 퉁쳤었다.
결국은 프로젝트가 사실 기능이 어렵거나 많지 않았음에도 불구하고 충분한 시간내에 마무리를 하지 못한 이유는 서로의 진행상황을 공유하지 않은 의사소통의 부재가 주 원인이라고 생각했다. 소통을 제대로 하지 않으니 각자 주어진 Task에 대해 압박감을 덜 느끼는것은 당연한 것이었고
이전 프로젝트에서는 스프린트를 철저히 진행했었다. 회고도 하였고, 매일 매일 진행상황에 대한 소통을 하였다. 그 결과 개발 기간이 3주가 채 되지도 않았었는데 예상했던것 보다 완성도 높은 프로젝트를 만들 수 있었다.
역시 잃어야만 소중함을 안다.
마치며
솔직히 여러모로 많이 아쉬운 프로젝트였다. 문제점을 중간에 인지하고 있으면서도 이를 언급하지 않은 나의 잘못도 있다. 꼭 팀장이어야만 잘못된 점을 바로잡으려 노력해야 하는 것이 아니다. 우린 좋은 제품, 좋은 서비스를 만들기 위해 한 마음을 가지고 모인 팀원들이다. 팀장이 아니어도 책임감을 가져야하고 문제점이 보이면 바로바로 나서서 해결하려 노력해야한다.
다음에 프로젝트를 해본다면 좀 더 책임감을 가지고 주도적으로 해봐야겠다. 팀장을 할 수 있으면 해보고 아니더라도 이전보다 훨씬 적극적으로 임하는 자세가 필요함을 느꼈다. 그리고 이번 프로젝트에서 다른 팀원들이 주로 도맡아 했던 공통 컴포넌트 제작, 에러바운더리 처리, Github actions를 통한 CI/CD구축 등에도 관심이 많은데 꼭 해보고싶다!
