MIL - 사이드 프로젝트 회고 2 : 서비스 기획 전반

1. 초기 기획

백엔드로 참여했던 팀원(중도포기)이 자신이 기획하고 있는 사업이 있는데,

프론트 개발자 팀원이 그만두게 되었다고 하여 그 부분에 대해 우리 팀에 설명함.

그래서 우리 팀은 그 서비스를 만들기로 하였음.

 

1) 유저의 실시간 위치 기반으로 반경 내에 있는 다이어트 식당을 검색해 줌

2) 다이어트 식당은 가맹점들이고, 가맹점들은 나중에 쿠폰이나 할인 등의 마케팅을 할 수 있는 플랫폼

3) 유저는 메뉴를 예약하거나, 점주와의 채팅 등을 할 수 있음.

 

 

기술선택에 대한 전제

1) 전역상태관리가 필요한가?

작은 프로젝트의 규모

>> 모바일 사이즈로, 페이지 내에 존재할 수 있는 컴포넌트의 양이 한정적

>> 처음 컴포넌트 설계를 잘 고민하면 복잡도를 줄여 props drilling을 피할 수 있을 것으로 판단

>> 필요 시에는 국부적으로 context API를 사용하거나, localstorage, Tanstack-query의 캐시데이터를 사용

>> 전역상태관리를 사용하게 되면 아무래도 컴포넌트에 대해서 고민을 잘 안하게 되는 경향이 있는데,

공부를 하는 입장에서 좋지 않다고 생각하게 되었음

 

Redux 없이 구현해보자.

 

2) tanstack-query vs thunk

redux를 사용하지 않는 시점에서 thunk를 단독으로 사용하기 위한 보일러 플레이트를 굳이 만들 필요가 없음

tanstack-query를 사용하면 캐시 데이터를 활용해서 props 전달 최소화 가능

쿼리무효화 또한 쉬워서 메서드 하나면 가능.

thunk의 경우 사용법이 매우 많은 부분이 정해져 있기 때문에 큰 고민이 없는데

tanstack-query의 경우 자유도가 높고 제공되는 옵션이 많기 때문에 여러가지 고민해보면서 코딩할 수 있음

 

tanstack-query를 파보자.

 

---

2. 기획 변경

기획자가 중도포기해서 나가버렸음.

다이어트식당은 강남역 이외에는 거의 없기때문에

실시간 위치기반으로 개발하면서 테스트를 하기 곤란

기획을 변경하기로 결정.

여러번 기획이 바뀌었지만 최종적으로 아래의 서비스로 픽스.

 

1) 유저의 실시간 위치 기반으로, 반경 내 카페 검색, 필터를 통해 컨셉에 따라 마커 리스트 변경

2) 가맹점의 쿠폰, 할인 등의 마케팅 요소는 컨텐츠에서 제외하기로 함

3) 유저는 카페에 방문하여 피드를 남기고,

유저끼리 피드페이지에서 필터링을 통해 정보공유를 하고 소통할 수 있는 플랫폼.

 

맵 화면 :

1) 유저의 실시간 위치 기반으로 반경 내에 있는 카페 검색

2) 컨셉에 따라 필터를 걸고 보여지는 마커를 다르게 함(일반카페,애견카페 등등..)

3) 하단에 캐러셀을 두어 해당 샵의 간략 정보를 게시

4) 클릭하면 카페 상세 페이지로 넘어감

 

카페리스트 화면 :

1) 유저의 실시간 위치 기반으로, 반경 내에 있는 카페 검색

2) 카드 형식으로 무한스크롤로 가게 간략 정보 게시

3) 클릭하면 카페 상세 페이지로 넘어감

4) 이슈 → 사실상 맵화면과 기능이 다를 바가 없음. 원래 메인페이지였으나 메인을 맵화면으로 변경

5) 필터기능을 강화해서 맵화면과의 차이점을 두기로 함

 

피드리스트 화면 :

1) 기본적으로 최신순으로 피드 리스팅.

2) 피드 작성 시 걸었던 태그 + 카페 컨셉의 이중 필터 넣고 피드 찾아 볼 수 있도록 구성

 

즐겨찾기 화면 :

1) 맵, 카페리스트, 피드리스트, 카페 상세페이지, 피드 상세페이지에서 추가한 즐겨찾기를 모두 저장한 페이지

2) 유저는 폴더를 커스터마이징 할 수 있고, 폴더에 따라 즐겨찾기 저장

 

마이페이지 화면 :

1) 닉네임 변경

2) 내가 작성한 피드 리스트 확인

 

---

3. 추가 기획 변경

 

PWA, 실시간 위치기반 불가능

1) 두 기술 모두 Https 통신 필요

2) 프론트는 가능했으나, 백엔드 쪽에서 인증서를 받고 진행하는 과정에서 이유를 모르게 진행되질 않음

3) 1주일 이상 여러 방법 시도했으나 https 배포 실패, 납기 고려하여 기술변경

4) 실시간 위치 변경이 아닌,  "이 위치에서 검색" 버튼클릭 시 fetch하는 것으로 변경

 

"이 위치에서 검색" 적용으로 인한 fetch 방식 변경 내역

1) 기존 :
유저의 위치(맵의 센터좌표)가 조금이라도 변경될 시에 fetch.
유저가 맵을 드래그해서 센터가 변경될 경우엔 debounce 를 넣어 일정시간동안 fetch 유예.

Zoom에 따라 반경값이 변하고, 반경이 변경될 경우에도 refetch

 

=>

반경 1km가 되면 평균 90~120개의 카페가 리스팅됨.

마커 수가 많아서 메모이제이션 적용 불가

(성능 하락 및 이상현상 발생 : 마커가 있어야 하는데 없다든지, 일부 마커가 기본이미지 상태라든지)

 

2) 변경 :

"이 위치에서 검색" 버튼을 누를 시에만 fetch.

유저가 맵을 단순 드래그 할때는 fetch 미실행.

1회 fetch 시, 최대 반경만큼의 데이터를 fetch. 최대 반경은 500m로 줄임.(실사용에 지장없음)

Zoom에 따라 반경이 변할때는, fetch한 데이터를 가공하여 렌더하는 양의 조절

최대 반경 500m 일 시, fetch되는 카페의 수는 10~20개 수준으로 메모이제이션 적용 가능

useMemo 사용, marker 배열을 셋팅하는 함수를 캐싱하고, 카테고리에 따라 보여지는 리스트 변경

=> 성능향상 (lighthouse 성능점수 : 43 => 93 점)

 

 

자잘한 트러블슈팅과 컴포넌트 고민에 대한 회고는 다음 포스팅에..