플케어 프로젝트 소개

프로젝트 주제가 뭔데?

팀원 구성 후 첫 모임에 프로젝트 주제까지 정해버렸다.

정말 많은 아이디어가 나왔고, 이번에 선정된 주제가 아니더라도 그 주제로 프로젝트를 진행하고 싶을 정도로 괜찮은 아이디어들이 많았다.

 

그중에서 최종 선정된 프로젝트 주제는 IT 프로젝트 팀원 구인 및 프로젝트 관리 웹사이트였다.

 

다른 팀플 구인 사이트랑 뭐가 다른데?

현재 여러 팀프로젝트 구인 사이트들이 존재하는 걸로 알고 있다.

나는 기존 사이트와의 차이점이 분명히 존재하는 프로젝트를 진행하고 싶었다.

이 프로젝트 설계 단계에서 UX에 상당히 집중해서 기능을 설계했다.

 

그래서 사용자 입장에서 우리 사이트의 장점은 다음과 같다.

- 팀원 구인 시에 프로젝트 리더의 경우, 지원자 프로필 상 평가, 프로젝트 경험을 토대로 팀 프로젝트 참여 여부를 결정할 수 있다.

- 다른 팀원 구인 사이트와는 다르게 팀원 구인 및 프로젝트 관리까지 활용할 수 있다.

- 다른 팀원 구인 사이트는 사용자가 직접 팀 리더에게 연락처 등을 공개한 후 연락을 해서 프로젝트 참여 여부를 밝히는 반면, 우리 프로젝트에서는 팀 프로젝트 지원하기 기능을 통해 지원자가 기존에 작성한 프로필 상 포트폴리오를 전달하도록 설정하였다.

 

사용자 프로필에 있는 평가는 어떤 건데?

우리는 프로젝트 인원을 구할 때 직접 겪어보지 않는 한 다른 사람들의 프로젝트 참여도나 태도 등을 알지 못한다.

이 지점에서 많은 불편함을 겪었고, 결국 이 웹사이트에서 그 지점을 해결해보자는 의견이 나왔다.

해결 방안은 프로젝트 중간 중간 사용자의 참여도를 다른 팀원이 평가하게 한 후, 해당 사용자 프로필에 평가 내용을 공개하도록 하는 것이었다.

그렇게 하면, 프로젝트 팀원의 평가를 토대로 팀원 구인에 유용하게 이용할 수 있다는 생각이 들었다.

 

프로젝트 관리는 어떤 방식으로 이루어지는데?

일단, 프로젝트 관리 페이지에서 사용자에게 제공하는 기능은 다음과 같다.

- 전체 일정 오버뷰

- 회의록 작성 및 관리

- 팀 일정, 개인 일정 관리

- 팀원 상호 평가
- 팀원 관리
- 프로젝트 관리

 

회의록 페이지에서는 팀원들이 회의록을 함께 공유할 수 있도록 하였다.

이때 북마크 기능도 추가하였는데, 이 북마크 기능은 본인이 북마크한 회의록들을 쭉 보여줄 수 있도록 하였다.

 

팀 일정의 경우 모임 일정이 있을 수 있고, 전체적인 타임라인에 대한 일정이 있을 수 있어 이를 구분해서 관리하도록 결정했다.

개인 일정에서는 팀 일정에 등록할 때 참여하는 사용자를 등록하도록 해서 해당 팀 일정에 참여하는 사용자의 일정을 사용자별로 구분해서 보여주도록 결정하였다.

 

팀원 상호 평가의 경우, 두 가지로 나뉘는데, 하나는 일정에 참여한 사용자에 한해서 참여도를 평가하는 것이고, 다른 하나는 프로젝트 전체 완료 후 팀원 전체에 대한 참여도를 평가하도록 결정하였다.
그래서 프로젝트 완료 전 보이는 차트, 랭킹과 완료 후 보이는 차트, 랭킹과 차이가 있다.

팀원 관리 기능에서는, 해당 프로젝트 모집 글에서 지원한 사용자의 지원서들을 모아서 볼 수 있고, 해당 지원자를 수락/거절하는 기능을 추가했다.

또한, 기존 팀원 중 방출, 리더 위임 등의 기능도 추가해서 팀원 관리에 관한 여러 경우의 수들을 고려해서 기능을 구상하였다.

 

프로젝트 관리 기능에서는 프로젝트 전체 완료, 삭제, 내용 수정의 기능이 있는데, 이 관리 페이지의 경우에는 프로젝트의 리더에게만 접근이 가능하도록 따로 설정을 해뒀다.

 

기본적인 기능은 이렇긴 한데, 각 페이지들마다 프로젝트 리더와 일반 멤버 간 권한을 다르게 주었기 때문에 권한이 없는 사용자에게는 버튼이 보이지 않는 등의 UI를 다르게 설정하였다.

해당 기능들에 대해서 조금 더 상세하게 알고 싶다면 이후의 글을 참고하면 좋을 것 같다.

 

사용 기술 스택

마지막으로, 사용 기술 스택에 대해서 말해보려고 한다.

 

백엔드는 스프링, 프론트는 리액트를 사용해보기로 했다.

 

조금 더 상세하게 말하자면, 프론트 쪽에서는 react, react-query, redux toolkit, vite, scss를 사용했다.

사실, 원래는 react, scss, context api만 사용해서 구현해보려고 했는데, 구현하다 보니까 점점 추가됐다.

 

context api를 사용하다 보니, 점점 중첩된 코드들이 많이 생기고, 비효율적인 렌더링이 많이 일어나 성능적으로 좋지 않다는 것을 알게 되었다.

그러다가, 전역 상태 관리 툴을 redux toolkit으로 사용해보자는 의견이 있어 그렇게 하기로 하고 context api로 작성했던 코드들을 모두 redux toolkit으로 관리하게 되었다.

 

redux로 전체적인 상태를 관리하고 있었는데, 서버와의 통신 구현을 하다 보니 redux 상태에 클라이언트 상태뿐만 아니라 서버 상태도 섞여버렸다.

그래서 무슨 방법이 없는지 고민을 하다가 react-query라는 것을 알게 되었고 도입하게 되었다.

react-query를 사용해서 클라이언트 상태와 서버 상태를 분리해서 관리하게 되었고, react-query 상 편리한 기능들도 같이 활용해서 관리할 수 있게 되었다.

 

그리고 vite는 최근 들어서 알게 된 것인데, 사실 리액트 프로젝트라고 하면 cra를 통해서 생성하고 작업한다.

하지만 cra의 경우 webpack 기반이고, vite보다 훨씬 느리다고 한다.

그래서 처음에는 cra로 생성해서 작업을 했지만 결국 vite로 마이그레이션하게 되었다.

 

이렇게 보니까 다사다난하기는 하는데, 중간중간 기술 스택 추가하고, 마이그레이션해보면서 실력이 정말 많이 늘었다.

처음부터 좋은 툴, 최신 기술 스택으로 작업해보는 것보다 이렇게 사용해보면서 불편함을 느껴서 마이그레이션해보게 되면 기존 것과 비교하게 되면서 더 실력이 많이 느는 것 같다.