[SEB-Main-Project] 대여가 대여 KPT 회고

22.11.08 - 22.12.04

---

약 1달간의 메인 프로젝트였고, FE 3명 BE 4명으로 구성된 팀

공간 대여 서비스를 주제로 한 대여가 대여라는 웹페이지를 만들었다. 

 

1.  프로젝트 설명

대여가 대여 github | 배포(현재는 서버 내림)

 

목적

- 원하는 시간만큼 공간을 대여할 수 있고, 자신의 공간을 등록할 수 있다.

- 사용자가 mbti를 등록한다면 사용자와 동일한 mbti 추천장소를 띄워준다.

- 짐 보관만을 위한 장소 대여가 가능하다.

 

구현하고자 했던 기능

- 장소 예약을 시간으로 받고자 했기 때문에 사용자가 시간을 선택할 수 있도록 캘린더를 조절해야했다.

- 사용자의 mbti와 일치하는 데이터를 받아 화면에 추천 장소를 띄워야했다.

- 짐 보관 카테고리를 만들고자했다.

- 마이페이지에서 등록 내역, 예약 내역, 찜한 내역, 리뷰 내역을 확인할 수 있게 만들고자 했다.

- 결제 기능을 추가하였다.

- 전체게시글 페이지에 무한 스크롤을 구현하고자 하였다.

 

사용 스택(FE)

React.js, React-Router-Dom, Styled-components, Axios, Json Server, Amazon3, ESlint, Prettier, Recoil, Github Actions, Postman

 

협업 툴

GitHub, Figma, Slack, Discord, Zep

 

맡은 부분

[프론트엔드, 팀원] 전체게시글, MBTI 추천 장소, 카테고리, 검색, 상세페이지 상세정보, 결제, 토큰 리이슈, 로그아웃, 라우터

 

2. 개인회고용 KPT

Keep

- 무한 스크롤 구현 시 스크롤 이벤트가 아니라 자바스크립트 내장 API인 IntersectionObserver API를 사용하여 요소가 관측되었을 때만 함수를 실행하였고, 그로 인해 무분별한 http요청이 가는걸 막을 수 있었다. 

- 프로젝트 진행 시 Axios 라이브러리를 사용하여 json 파싱하는 코드를 쓰지 않아 코드양을 줄일 수 있었다.

- promise를 관리할 때 .then .catch 대신 async, await 를 사용하여 코드 가독성을 높였다.

- React-Router-Dom을 사용하여 상세 페이지 장소 id를 params로 관리해서 사용자가 새로고침을 했을 때도 id에 맞는 데이터를 불러올 수 있었다.

- GitHub Actions을 통해 CI/CD를 경험할 수 있었다.

- 서버 데이터가 구현되기 전 json-server 라이브러리를 사용한 더미데이터 테스트를 진행하여 api 통신 준비 시간을 단축할 수 있었다.

- zep을 통한 상시 소통으로 문제를 바로 전달 받고 전달할 수 있었다.

 

Problem

1) 웹페이지 접속 시 헤더에 access token과 refresh token가 필요했지만 읽히지 않는 문제가 발생했었다.

2) 디자인 수정 후 무한 스크롤이 적용되지 않는 문제가 발생했었다.

3) 초반 테스트 진행 시 429 에러(요청 많이함)가 자주 발생했었다.

4) kakao map api key env 값이 배포 시 읽히지 않는 문제가 발생했었다.

5) 결제 상태가 마이페이지에서 바로 업데이트가 되지 않는 문제가 발생했었다.

 

Try

1) 웹 페이지 접속 시 헤더의 토큰 값이 읽히지 않았던 이유가 토큰을 로컬스토리지에 보관하였었고, cpu와 메모리의 속도차이 때문에 해당 이슈가 발생한 것이었다. 임시방편으로 async await과 조건문을 활용해 헤더를 수정하였지만 코드 가독성과 성능을 끌어올리기 위해 recoil을 활용해 리팩토링을 진행하였고, 프로젝트가 끝난 뒤라 반영은 되지 않았지만 CS지식의 중요함을 알게된 경험이었다.

 

2) 디자인을 수정한 후 전체게시물에서 로그인을 하지 않았을 때 요소가 관측되지 않는 현상이 발생되어, 콘솔을 통해 Intersection Observer Entry의 isIntersecting의 값이 true가 될 때를 찾아서 요소의 크기를 조절해줬다. 

 

3) 초반 테스트 진행 시 429 에러가 너무 많이 발생하는 이슈가 생겨 요청을 어디서 자주 보내고 있는지를 찾아보았고, 눈에 띄게 요청을 자주 보내는 곳은 발견하지 못했다. 다른 FE분들도 이 429 에러가 흐름을 방해한다는 의견이었고, 나 또한 그랬어서 요청을 최대한 줄여보고자 react strict 모드를 풀어 api요청을 조금이나마 덜 보내는 방법을 사용했었다. (해당 기능이 완성되면 react strict 모드로 다시 진행을 해보자고 했지만 시간이 촉박하여 그 단계를 지나친게 아쉬웠던 방법이었다.)

 

4) kakao map api key를 env로 보관하고 아마존을 통해 배포했을 때 읽히지 않는 문제가 있었다. 다른 env(서버주소등등)은 잘 읽히는데 카카오맵만 읽히지 않아서 html에 사용한 env라 그런건가하고 삽질했는데 github secrets에서 env 보관을 environment secrets에서 repository secrets에 옮겨주니 잘 먹혔다. 물론 소스코드에는 어떻게 하든 노출되는 것 같지만....

 

5) 결제 상태를 마이페이지 예약 내역에서 보였으면 좋겠다는 의견이 있어서 예약 내역 페이지를 눌렀을 때 받는 데이터로 결제 상태 데이터를 표시했다. 문제는 결제를 진행하고 완료나 실패 시 바로 화면에 보였으면 좋았겠지만 프론트 측에서 결제가 완료된 시점에 응답을 받는게 아니라 결제가 언제 끝나는지 확인을 할 수가 없어 구현을 못했다.

 

 

3.  느낀점

두번째 팀 프로젝트였고, 다행히 좋은 팀원들을 만나서 큰 문제 없이 잘 마무리 할 수 있었다. 

시간이 촉박했던만큼 퀄리티가 제대로 나올 수 있을지 걱정을 많이 했지만 생각했었던 퀄리티 이상으로 나와서 뿌듯했다. 

조금 아쉬운 점이 있었다면 프로젝트 전에 회의를 했을 때 안전하게 가자는 의견이었어서 ts, next, react-query등 다들 관심 있어 하는 기술을 이번 프로젝트에서 사용해보지 못했다는 점이다. 구현하고자하는 기능이 많았기 때문에 도입한다면 시간 내에 끝내지 못할 가능성이 매우 높았을 것 같았기 때문이다. 다행인 점은 프로젝트 이후에도 마음이 잘 맞아서 도입해보고 싶어하던 새로운 기술 공부를 같이 하고 있는 중이다. 프로젝트들을 하면서 항상 집단지성이 꽤 강력하다는것을 깨닫는데 이번에도 그런 깨달음의 시간이 많았던 기간이었다. 

그리고 주마다 멘토링의 시간이 있었다. 멘토님은 아주 좋은 분이셨고, 멘토링 시간 덕분에 내 코드와 기술적인 피드백, 사람 자체로의 피드백을 받을 수 있어서 많이 성장할 수 있는 기회가 된 것 같다. 

부트캠프 초반부에 강사님께서 가장 협업하기 싫은 개발자는 과거의 나라는데 메인 프로젝트가 끝난 뒤 프리 프로젝트 코드를 봤는데 이해됐다. 구현에만 급급했던 모습이 아주 잘 보여서 프리때 팀원분들에게 죄송한 마음이 들었다. 

새로운 기술이랑 리팩터링도 열심히 또 습득해봐야겠다.