☝️ 우선 모든 것을 털어내 봅시다.
좋았던 점, 아쉬웠던 점 무엇이 되었든 좋으니 우선 모든것을 털어내봅시다.
Good
- 기획
- 기획과 설계에 전체 프로젝트의 절반에 가까운 시간을 투자했다. 중간에 바뀌는 부분도 있었지만 튼실한 기획서와 Figma를 바탕으로 개발 단계에서 지체되거나 헤매는 일을 줄일 수 있어서 집중도가 올라갔던 거 같다.
- 중간중간에 잔버그는 보였지만 기본 요구사항은 모두 충족시켰고, 추가적인 요구사항에도 발을 들여보며 마감과 완성도에 대한 trade-off를 배우게 되었다.
- 프로젝트 관리
- Github repository 안에 있는
Projects를 이용하여 태스크 분배를 시도했다. 여기서 issue나 PR과 연관시킬 수 있고 각 태스크에 대한 assignee를 빨리 확인할 수 있어서 좋았는데, 추후에 협업 시에도 활용하면 좋을 것 같다.
- 리액트 숙련도
- React-query, Jotai, Reect hook form 등 실제로 많은 프로젝트에서 사용되는 유명한 패키지에 대한 경험을 할 수 있었다. 현재는 기본 기능만 사용한 정도지만, 더 잘 사용하려면 각 패키지의 공식문서를 참고하여 기존 기능에 대한 확장이나 개선을 할 수 있을 것 같다(https://react-query.tanstack.com/reference/useMutatio, https://react-hook-form.com/advanced-usage 등)
- 팀 문화
- 문제가 발생했을 때 해결방안은 여러가지가 나올 수 있고 이를 혼자 고민하다가 지체되는 시간과 옳고 그름을 판단하기 어려워질 때가 있을 텐데, 디스코드나 슬랙으로 팀원과 즉각적인 소통 혹은 비동기적인 의견 교환을 통해 더 나은 선택지를 고를 수 있었다.
- 짧은 기간 안에 개발을 하기 위해 문제, 어려운 부분이 있어 시간이 지체되고 있을 때, 해결하기 위해 모두 같이 의견을 모아 빠른 의사결정으로 막힘없이 진행할 수 있었다.
- 그 외
- 비록 정식 진행 기간은 끝났지만, 모두 프로젝트 개선 의지가 있으셔서 보다 나은 수준의 결과물로 바꿀 수 있을 것 같다.
Bad
- 프로젝트 문서화
- 회의록을 주기적으로 작성하지 못했고, 후반부로 갈수록 PR, issue 등 템플릿을 지키며 개발 단계를 문서화하여 공유하는 작업에 대한 완성도가 떨어지게 되었다.
- 개발
- Typescript를 사용해보고자 야심차게 시작했지만 ESLint에 휘둘리며
any가 많이 쓰이면서, 이점을 많이 챙기지 못했다. - 당장의 기능 구현에만 신경을 쓰느라 더 좋은 방법에 대한 고찰이 부족했다. 멘토님께 여쭤보거나 돌아다니는 잘 만들어진 오픈소스에 대한 참고를 더 많이 했다면 좋았을 것 같다.
- 처음 계획은 모바일을 우선으로 하는 레이아웃을 만들고자 했지만, 처음 설정 width부터 잘못되었었고 반응형에 대한 대비를 하지 못했다. 그 외에도 여러 컴포넌트들에 대한 애니메이션도 부족해서 현재는 사용자 경험을 평가하기도 힘든 정도라고 생각한다.
- 코드 가독성에 대해 신경을 많이 쓰지 못했다. 디렉토리 구조를 나눌 때의 네이밍이나, emotion 스타일 코드 분리 등 추가적인 개선이 필요할 것 같다.
- 코드리뷰 및 프로젝트 관리
- PR을 main에 통합할 때, 일정 수의 approve가 필요했는데, 처음엔 2 이상의 approve가 필요하다가 프로젝트 후반부에는 일정에 쫓겨 1로 낮추다보니 서로의 코드를 체크하는 시간이 부족했던 것 같다.
참고 내용
✌️ KPT(Keep, Problem, Try) 회고
Keep
- 좋았던 점 중에서 다음에도 유지하고 싶은 것들을 적어주세요.
- 프로젝트 관리
- 이슈기반으로 브랜치를 만들어서 기능개발하는 것이 명확한 단계와 현재 개발 단계를 알수 있었기에 좋았다.
- 코드리뷰
- 고정적인 코드리뷰 시간을 두는 것은 생각보다 더 많은 도움이 되었다. 코드리뷰를 병행해서 PR에 대해 판단하다보니 프로젝트의 완성도와 follow up에 큰 효과를 주었던것같다
- 팀 문화
- 비대면상황에서는 웬만하면 캠을 켜고있는 것이 좋은 것 같다. 바로바로 질문이나 의논을 할수 있고 팀원간의 유대감과 결합력도 높아지는 것 같다. 또한 상주하면서 서로 이슈를 공유하고 해결하는 과정이 성장에 도움이 되었다.
- 이번 팀 프로젝트의 가장 큰 장점은 바로 모든 팀원들의 적극적인 대화, 의견 제시였다고 생각한다. 적극적인 참여도와 의견제시는 프로젝트의 완성도를 높여줄수있을뿐만 아니라, 각 팀원들이 프로젝트의 흐름, 진행사항을 파악할수 있게 해주고, 이는 곧 효율적인 작업으로 이어진다고 생각한다.
Problem
- 아쉬웠던 점에서 실제로 문제로 발생했던 것들을 적어주세요.
- 기획
- 기획에서 개발로 넘어가는 부분이 매끄럽지 않았던것같다. 조금 더 지체되지 않고 개발을 시작할수 있는 방법이 있지 않을까..? ( 기획시에 개발 프로세스에 대한 틀 정립 등)
- 일정산출의 어려움 아직 프로젝트 경험이 많지 않고, 실력적인 부분에 대해서도 미지수라는 점에서 기능 구현 이슈를 생성하고 이 이슈를 resolve하기까지의 일정을 산출하는 것이 어려웠다. 그러다보니 체계적인 개발이 이루어지지는 못했다는 점이 다음 프로젝트에서는 개선해야할 부분이라고 생각한다
- UI / UX
- UI 흐름도의 부재 UI흐름도를 미리 그리고 시작하려하였으나 오히려 복잡한 흐름도가 나와서 다시 봐도 파악하기 힘들것이라고 파악하여 따로 진행하지 않았다. 하지만 그러다보니 세세하게 페이지 이동을 해야하는 부분을 놓치거나 모달을 띄울때 어떤식으로 할지 등 더 구체적으로 정하지 못하고 개발에 착수하게 되었다. 또한 UI흐름도가 있었을 때 생기는 많은 장점들이 있다고 생각하는데 그러한 이득을 보지 못해 아쉬웠다.
- 개발
- 다운탑방식 개발의 어려움 다운탑 방식의 컴포넌트 제작은 초반 개발진척에 어려움을 주었다. 프로젝트의 기획기간이 부족하여 상세한 부분까지의 기획이 이루어지지않은 상황속에서 다운탑 방식으로 개발을 진행하는것은 효과적인 방식이 아니었다. base 컴포넌트에서 고려하지 못한 부분이 너무나 많았고, 불완전한 base 컴포넌트나 hook를 무리하게 사용하려하며 허비한 시간이 많았다.
- 팀 문화
- 미흡한 기록화 프로젝트를 위해 쓴 시간에 비해서 기록물이 그 만큼 남아있지 않아서 아쉬운 부분이 있다. 물론 커밋을 하면서 그 결과물을 코드로서 남겨두긴 했지만, 코드에는 전부 담지 못했던 고민들도 많았기 때문에 그런 것들을 꼭 정제된 언어가 아니더라도 기록해두었으면 좋았을 것 같다.
Try
- Keep 사항 중에서 한단계 더 발전하기 위해 시도해볼 것들을 적어주세요.
- Problem 사항 중에서 문제를 예방하기위해 시도해 볼 것들을 적어주세요.
- 기획단계에서 명확한 세부 프로세스를 설정하자. 명확한 타켓층과 니즈를 바탕으로한 프로젝트 주제가 결정되면 그것을 바탕으로 주요기능, 기술스택, 디자인, 색상, 로고와 와이어프레임이 명확하게 나오기에 그러한 세부스텝을 정해두면 좋을 것 같다.
- 고정적인 코드리뷰 시간을 가지되 그때만 코드리뷰가 일어나는 현상을 최소해야한다.
고정적인 코드리뷰시간은 코드리뷰가 가장우선시되는 시간으로 매우 도움이 되었으나 그외의 시간에 대해서는 코드리뷰를 하지 않는 현상도 나타났다고 생각한다. 이 부분을 팀원 모두가 인지해야만 한다고 생각한다.
- 다운탑 방식의 문제점을 해결하기위해 대략적인 디자인 시스템이 필요하다 디자인시스템이 어느정도 있어야 그것을 바탕으로 명확한 기준이 있는 base 컴포넌트 개발이 가능해진다고 생각한다. 따라서 스케치 수준일 지라도 디자인 시스템이 있으면 좋을 것 같다. 다만 단기 프로젝트에서 그것이 가능한지는 의문이다.
- 탑다운방식을 고려해보자 다운탑 방식이 여러가지 고충이있다는 것을 알았으니 크게 레이아웃을 먼저 짜두고 개발하는 탑다운 방식으로 개발을 진행하는 것도 고려해보면 좋을것 같다.