[ 기본 정보 ]
[ 이번 프로젝트의 개인적인 목표 ]
😸개발 팀장
😁react-hook-form
로그인 페이지를 구현하면서 처음에는 새로운 라이브러리 도입에 부담감을 느끼기도 했지만 react-hook-form은 이해하기 쉽고 간단한 API로 구성되어 있었기에 채택하였다.
이 라이브러리를 사용하며 무엇보다 좋았던 점은 선언적으로 코드를 작성할 수 있어 가독성이 좋아지는 점이었다.
아직은 기능 개발 역량을 키우고 싶어 평소에는 이런 라이브러리 사용을 지양하였는데, 이런 단기적인 프로젝트에서는 적극적으로 라이브러리를 활용해 보는 것도 또 하나의 좋은 연습일 수 있겠다고 느꼈다.
🤔검색 페이지 렌더링 성능 최적화
검색 페이지에서는 Blocking rendering을 해결하는 것이 가장 중요한 문제였다. 해결책으로는 가장 먼저 디바운스
를 떠올렸다. 하지만 디바운스는 단순히 작업을 뒤로 미루는 것일 뿐이라 유저가 계속해서 입력을 하는 경우라면 화면 업데이트가 계속해서 지연되는 이슈가 있었다. 또한 적절한 딜레이를 선택하는 것도 고민되는 지점이었다. 딜레이가 너무 길면 유저 입력에 대한 반응도 그만큼 느려지지만, 너무 짧아도 적용하는 의미가 없어지기 때문이다.
쓰로틀
의 경우에는 일정 시간을 주기로 화면을 렌더링하도록 할 수 있겠지만, 그 일정 시간 내에 연속적으로 입력하는 것이 아니라 중간에 입력을 하지 않는 경우에는 무의미하게 기다리는 시간이 생기는 문제가 생긴다.
따라서 Blocking rendering을 해결할 때 디바운스와 스로틀 모두 근본적인 해결책은 아닐 수도 있겠다는 생각이 들었고, 리액트 18에 새롭게 추가된 useTransition
훅을 사용해서 해결하고자 하였다.
startTransition으로 화면을 업데이트 하는 중에도 input 의 우선순위를 높여 입력이 끊기는 상황을 줄여주고, isPending의 boolean 값을 활용하여 로딩 중을 표시하는 ui를 띄워 손쉽게 ux를 향상 시킬 수도 있었다.
가장 좋은 점은 역시 간편한 hook으로 기능이 제공되기 때문에, 기존 로직에 아주 쉽게 적용할 수 있었다는 점이다.
아쉬운 점은 최근에서야 AbortController
를 사용해서 API 비동기요청을 취소하는 기능을 구현할 수 있다는 사실을 알게 되었다. 이것을 함께 사용했다면 필요하지 않은 API 호출을 애초에 취소하여 웹페이지 성능이 더욱 크게 개선되지 않았을까 싶다.
기능 구현이 어렵진 않았지만 리액트 컴포넌트의 재사용성에 대해 많은 고민을 했던 기억이 난다.
두 페이지 모두 하나의 컴포넌트 안에서 분기처리를 해야할 부분이 많았다.
회고하며 결론을 내어보자면 하나의 컴포넌트 안에서 분기처리 해야할 것이 많아지면, 역할 별로 쪼개서 사용하는 것이 오히려 효율적일수 있겠다는 생각이 든다. 컴포넌트를 나누는 일관적인 기준이 가장 중요하겠지만 복잡하지 않은 재사용성
이라는 키워드를 마음에 새기게 된 것 같다.
애초에 view와 logic을 깔끔하게 분리했다면 이런 고민을 할 일이 없었을까?😥🥲
🚀 Issue와 칸반보드:
진행 중인 기능을 Issue로 발행하고 페이지 별로 구분한 칸반보드에 전체 현황을 공유하였다. 그 결과 직관적으로 남은 과업을 트래킹 할 수 있었다.
🚀 Wiki:
위키에 회의록과 컨벤션을 기록하였고, 우리 팀만의 스터디 노트를 만들어 활용하였다. 개인이 공부하고 정리한 내용을 공유함으로서 학습 비용을 절감할 수 있었다.
🚀 게더타운:
게더타운은 유연한 화상 대화 및 멀티미디어 연동 기능을 갖춘 강력한 협업 툴입니다. 저희는 게더타운을 적극 활용하면서 비대면 협업의 단점을 극복하고 원활한 의사소통을 이끌어내고자 하였습니다.
🚀 몹 프로그래밍:
중요하거나 복잡한 기능의 경우 몹 프로그래밍을 진행하였다. 프로젝트를 통한 공동 성장을 추구하였기에 이러한 방법을 채택하게 되었는데, 비록 생산성은 낮아질지언정 지식과 노하우의 공유라는 측면에서 함께 자라기를 실천할 수 있었다.
또한 정해놓은 협업 컨벤션에 적응하고 서로의 관점을 이해하게 되면서 팀워크를 강화하는 계기가 되었다.
[ 팀 및 커뮤티케이션 측면 ]
한 달동안 효율적인 의사소통에 대해 많은 고민을 하면서 마음속으로 되새기게 된 포인트가 몇 가지 있다.
두 가지 모두 분업을 하면서 발생한 문제점과 연관이 있었다.
[ 프로젝트 측면 ]
역시나 전역상태관리 라이브러리를 채택하지 못한 것이 아쉽다. 하지만 파일럿 프로젝트도 없이 섣불리 기술 스택을 채택하는 것은 복잡도를 크게 올려 프로젝트 일정은 물론 모두에게 큰 부담이 따를 것으로 예상되었다. 결과적으론 팀을 위해 옳은 결정이었다고 생각한다.
개발 분야에서는 첫 협업이었기에 너무 귀중한 경혐이고, 소중한 팀원들이다. 이번 주에 팀원들과 만나기로 하였는데 회포를 풀며 재밌게 이야기도 나누고 앞으로도 좋은 인연으로 이어가고 싶다.❤️