💻 프로젝트 컨셉 및 목표
- 토스에도 자린고비 채팅방이라는 간단한 투표를 중심으로 운영되는 비슷한 서비스가 있는 걸로 알고 있는데, 시의 적절한 주제 같습니다.
- 타겟층에 대해서는 조금 더 구체화할 필요가 있어 보이는데요. 단순히 ~사람들로만 끝낼 것이 아니라 우리의 서비스를 사용할 유저들이 어떤 특징을 가지고 있는지까지 자세히 고려해보시면 좋을 것 같습니다.
- 기획쪽에서는 이를 퍼소나라고 해서 아예 가상의 인물을 설정하는 방식의 접근법을 자주 활용하는데 여기까지는 아니더라도 연령층과 직업, 거주지 등의 요소도 충분히 고려해볼 필요가 있습니다.
- 예를 들어 주요 타겟이 10대~20대 초반이라고 한다면 꿀매포청천이라는 서비스명에서부터 사용자의 공감을 불러 일으키기 힘들겠죠?
✅ 프로젝트 구조 및 설계
- 아토믹 디자인도 많이 알려진 디자인 패턴 중 하나긴 하지만, 잘 적용하기는 힘든 패턴입니다.
- molecule와 oragnism의 경계 불명확, 모든 재활용 가능한 요소는 atom에서부터 시작되기 때문에 atom 자체를 관리하는 방식의 어려움 등이 이유
- 한 번쯤 사용해보려는 시도 자체는 나쁘지 않다고 생각하기 때문에 잘 사용하기 위해 고민을 해보시기 바랍니다.
- 그러나 만약 아키텍처가 오히려 개발 효율과 생산성을 떨어뜨리게 된다면 해당 아키텍처는 좋은 아키텍처라고 볼 수 없기 때문에 팀에 맞는 아키텍처를 다시 고민해보셔야 합니다.
🛠️ 기술 스택 및 협업툴
- 기술들은 워낙 많이 쓰이는 것들이라서 딱히 의견을 드릴 부분은 없을 것 같습니다.
- 다만, 항상 말하는 것처럼 어떤 기술을 사용하기로 했다면 목적(얻고자 하는 효과)이 무엇인지, 해당 라이브러리의 대안에는 무엇이 있었는지, 왜 사용하기로 했는지 등의 사유과 근거는 있는 것이 좋습니다.
- 기술 사이의 우선 순위를 두는 것도 좋습니다. 예를 들어 Axios와 TanStack Query가 비슷한 역할을 수행한다고 볼 수 있는데, Axios는 사용해야 하더라도 TanStack Query는 사용하지 않아도 되는 일종의 의존 관계가 있기 때문에 프로젝트 진행 중 새로운 기술을 학습하기 위한 러닝 커브로 인해 프로젝트의 일정에 영향을 미친다면 TanStack Query는 과감하게 제외하는 것을 고려해볼 필요도 있습니다.
- 이와 마찬가지로 StoryBook이 방치되는 모습을 심심치 않게 보긴 했습니다…
🗓️ 일정 산정 및 관리 방법
- 소프트웨어 공학 이론에서는 LOC, COCOMO, FP 등의 소프트웨어 비용 모델이 있지만, 당분간 여러분들이 프로젝트에 이를 활용할 일은 없을 것이기 때문에 지금처럼 데드라인을 목표로 대략적인 일정을 분할하여 잡되, 일정에 변동에 따라 데드라인까지 프로젝트를 마칠 수 있도록 유기적으로 일정을 조정해 나가는 방식을 추천합니다.
👥 협업 방식
- main 브랜치와 release 브랜치의 역할이 불분명해보이는데, release 브랜치의 역할을 main 브랜치가 대신 수행해도 되지 않을까 싶긴 하네요.
- 혹시 PR의 머지와 리뷰에 관해선 따로 마련된 규칙 같은 게 없을까요?