프로젝트 설명
끼니는 근처 위치기반 음식점 랜덤 뽑기, 밥모임 생성/참여할 수 있는 서비스입니다.
기획배경
끼니에 대한 고민을 해결하기위해 기획했습니다.
- 뭐 먹지? ⇒ 근처 음식점 중 한 곳 랜덤으로 뽑아줌
- 누구랑 먹지? ⇒ 밥모임 생성, 참여
협업
FE 3명, BE 4명 (FE로 참여) | FE기준 기여도: 35%
- 사용기술 : TypeScript, Next.js 13, TanStack Query, Axios, Recoil, Kakao Maps API, Chakra UI
- git 협업방식
- 오늘 할 작업 이슈에 적고, 프로젝트를 연결함 (github project 칸반으로 진행상황 파악)
- 작업한 pr을 pr템플릿에 맞춰 작성
- 코드리뷰 진행 (코드컨벤션 체크, 궁금한 점, 변수명 제안 등)
- 최소 1명의 approve후에 rebase merge 진행
프로젝트 결과물
- github :
- 배포서버 : https://kkini.vercel.app/
담당한 작업
- 렌더링 된 지도에 있는, 밥모임 보여주기
- 밥모임 신청서 페이지(받은 신청서, 보낸 신청서)
- 밥모임, 신청서 상태(대기 중, 승인..) 보여주는 Badge 컴포넌트
- 로그인 할 수 있는 모달 컴포넌트, 소셜 로그인 연결 작업
- Axios 인스턴스, 인터셉터 활용해 네트워크 요청 모듈화
- 반응형 고려한 Header 컴포넌트
구현 중 겪었던 문제
Cross-Domain인 서버와 cookie 공유 중 마주한 CORS 에러
문제 1. 서버에서 생성한 cookie를 받아오는 API에서 CORS 에러 발생
해결방법
- 네트워크 탭을 통해 preflight에서 에러가 났다는 걸 확인했고, 에러메시지 확인했을 때 OPTION method 관련 문제라고 판단.
- 백엔드에 OPTION method 지원하는지 여쭤봤고, 지원 요청 후 해결함.
문제 2. token이 필요한 API에서 CORS 에러 발생
해결방법
- 네트워크 탭을 통해 preflight에서 403 CORS 에러가 났다는 걸 확인했고, 403을 통해 token 검증에실패한다고 판단.
- preflight request 문서를 통해 본 요청에 보낼 헤더 key만 담긴다는 걸 알게되었고, 백엔드에 이를 공유함.
- preflight request에 한해 token 검증 로직없이 처리되도록 협의해 해결.
백엔드와 소통한 사진
배운 점
- Cross-Domain과 통신할 때 사용하는 CORS 정책의 작동흐름과 preflight request에 대해 학습할 수 있었습니다.
- 문제가 발생한 request 정보 뿐 아니라, 에러가 발생한 시간까지 함께 공유하는 것이 백엔드와 원활한 의사소통을 가능하게 한다는 것을 깨달았습니다.
지도에 밥모임 보여줄 때, 성능에 대한 고민
고민
- 지도에서 밥모임이 열린 가게에 마커를 표시해야하고, 마커 클릭 시 가게 정보를 보여줘야함.
- 보이는 지도에 있는 밥모임만 렌더링하는 게 성능 상 좋겠다고 판단.
- 이를 백엔드에게 공유하고, 보이는 지도 반경 안의 데이터만 받기로 협의.
문제 보이는 지도의 반경 구하는 방법
해결방법
- 시도 1 : 지도 zoom level에 따른 반경 정보 정해서 사용 → 디바이스에 따라 zoom level 반경 다르고, 모든 디바이스를 고려할 수 없기에 기각
- 시도 2 (채택) : 지도의 중심좌표, 북동쪽 좌표의 경도 값 차이 이용해 x축 반지름의 반경 활용
- 해당 로직을 랜덤 음식점 뽑기에도 적용해, 보이는 지도 내의 음식점 중에서 한 곳 뽑도록 적용
- 지도 위치 이동 시, 그려져있던 마커 제거, 마커에 연결된 이벤트 핸들러 제거해 필요없는 메모리 할당 해제
배운 점
특정 DOM 요소를 메모리 해제시킨다고 등록한 핸들러까지 해제되는 게 아니라는 점을 알게되었습니다.
로그인 후 참여하기 버튼 클릭 시, 로그인 성공한 다음 보여줄 페이지 처리에 대한 고민
고민
- 로그인 후 참여할 경우, 로그인 성공 후 사용자가 가려던 페이지로 이동해야함.
- 사용자가 가려던 페이지를 어디에 기록할지 고민.
- 소셜로그인 성공 후 백엔드에서 redirect url로 보내주기에 새로고침 시에도 보존해야했고, 단순 로그인 요청일 경우 home으로 보내야했기에 url query를 활용하기로 결정.
문제 redirect url에 사용자가 가려던 페이지를 query에 담았지만, query가 오지 않음.
해결방법
- 백엔드에 공유해 request 보내고 response 받는 과정을 검토함.
- 문제가 된 query만 한글이었기에 한글처리 관련 문제라고 생각했고, URL에 ASCII 문자만 허용한다는 걸 공유해 백엔드에서 한글 인코딩 처리해서 해결.
배운 점
URL에는 ASCII문자만 허용한다는 점, 브라우저에서 URL인코딩 후 요청보낸 다는 점을 알게되었습니다.
회고
오픈소스 github 저장소
이번 프로젝트에서 Next, react-query, emotion 등 처음 다뤄보는 기술이 많았습니다. 이 때, 해당 기술의 Github 저장소 example 폴더를 살펴보면서 많은 도움을 받았습니다. 예시 코드를 통해 기술의 활용 방법을 배울 뿐 아니라, 다른 기술과 함께 사용하는 방법을 배울 수 있었습니다. 이를 통해 Github 저장소를 확인하는 습관을 들이게 되었습니다.
다양한 린트와 코드 컨벤션
prettier, eslint 뿐 아니라 commitLint, husky, lint staged 등 다양한 린트를 적용해 코드의 통일성을 지킬 수 있도록 노력했습니다. 네이밍, 타입, 상태관리 등 코드 컨벤션을 설정하고 개발에 임했습니다. 이 덕분에 코드리뷰하기가 수월했고, 동료 개발자와의 협업에서 일관성 있는 코드 작성이 중요하다는 것을 깨달았습니다.
코드리뷰
올라온 PR은 1명 이상의 코드리뷰 후, approve가 되야만 merge할 수 있도록 설정했습니다. 제가 모르는 부분, 궁금한 부분을 적극적으로 물어보면서 몰랐던 부분을 많이 알 수 있었습니다. 또, 코드에 대한 고민이나 이슈를 다같이 논의할 수 있어서 좋았고, 팀원들의 다른 관점을 많이 배울 수 있었습니다.
기획부터 개발까지, 전반적인 프로세스 경험
주제 선정부터 구현할 기능을 정하고, mvp를 만드는 과정을 경험할 수 있었습니다. 매일 스크럼을 통해서 서로 어떤 일을 하는 지 알 수 있었고, 의문점이나 수정할 부분이 생기면 그 담당자와 소통하면서 작업했습니다. 원활한 소통을 이끈, 스크럼의 중요성을 느꼈습니다.