세 번째 프로젝트 회고

마지막 프로젝트는 백엔드 개발자 2분, 디자이너 1분과의 협업 프로젝트였다. 서비스도 직접 제로베이스에서 논의하고 기획하여 만들어서 정말 애정이 많이 가는 프로젝트였고 6주의 프로젝트 기간이 끝난 후인 지금은 또 이어서 팀원들과 서비스 고도화를 진행하고 있다.

 

🐾 어떤 서비스?

팀원들 중 반려동물을 키우는 분들도 있고, 반려동물 시장에 관심이 많은 사람들이 대부분이라 비교적 주제는 쉽게 정할 수 있었다. 먼저 기존 펫 서비스 시장의 아쉬운 점들을 분석했고 이를 해소해줄 서비스를 기획하게 되었다.

그렇게 고안해낸 서비스는 바로, 가족 및 친구들과 공동으로 기록할 수 있는 반려동물 육아일기 & 건강수첩 기록 서비스이다. 초반 6주 기간의 MVP 구현 범위 내에는 SNS 기능이 없지만, 현재 추가 기능 고도화 작업에 포함하여 구현할 계획이다.

 

✅ 주요 링크

• 배포 사이트 https://mypetlog.site/
• 깃허브 레포 https://github.com/ppp-team/my-pet-log

 

💻 기술 스택 및 업무 방식

• 기간 : 2024.01.17(수) - 2024.02.28(수) (6주)
• 팀 구성 : 프론트엔드 5명, 백엔드 2명, 디자인 1명

 

 

⭐️ 주요 기능

 

🤔 개발시 고민사항과 레슨

- 서비스 특성상 유저 계정, 동물 계정, 동물을 공동으로 키우는 펫메이트 그룹 유저 계정으로 계정 구조가 복잡함

- 초반에 첫 가입 & 로그인 후 기획 플로우를 잡을때 고려해야하는 부분이 많아 어려움이 있었음

- 유징 케이스를 나누어 기획 플로우를 정리하고 이에 맞게 분기 처리하여 놓치는 로직이 없도록 꼼꼼하게 기획 초반에 정리

 

- 펫 계정 id값을 사용하는 곳이 많음. 주로 기록할 대상인 '대표적' 펫 계정을 선택하고, 선택한 펫 계정의 정보가 다양한 곳에서 렌더링 되어야 하기 때문

- 현재 대표로 선택되어 있는 petId가 아닌 특정하게 선택한 petId 값이 필요한 케이스도 발생. 케이스에 따라 나누어 사용할 수 있도록 세팅이 필요함

- 접근을 이원화 하여 사용할 수 있도록 변경 : param에 있는 petId가 있으면 이를 받아 적용하고 없을 경우 쿠키에서 가져와 적용하는 것으로 api 함수를 세팅함

 

- 리액트 쿼리를 사용해 SSR을 구현할 때, 데이터를 사전에 가져와 초기 데이터로 제공하는 방식은 두 가지가 존재함

1. prefetch해온 데이터를 직접 initialData로 넘겨주는 방식

2. 서버에서 query를 prefetch하고, 그 cache를 dehydrate해서 클라이언트에 rehydrate하는 방식

 

우리는 두 번째 방식을 적용하여 구현했고 이 방식의 장점은 아래와 같았다.

1. 클라이언트와 서버간 효율적으로 데이터를 동기화할 수 있다.

2. 캐싱 및 동기화로 최신 상태를 자동 반영한다는 점에서 이점이 있다.

3. SSR과 CSR의 유연한 전환이 가능해진다는 점, 네트워크 중복 요청을 방지한다는 점에서 최적화에 도움이 된다.

 

 

💖 짧은 소회

(작성중!)