데브코스를 시작한지도 어느 덧 3개월이 훌쩍 지났습니다. 이번 달의 강의에서는 Vue와 React를 중점으로 배우고 프로젝트를 진행했습니다.

vue 사용후기

Pinia 적용

강의에서는 pinia의 option stores를 사용하여 프로젝트를 진행하였습니다. 영화 검색기에도 option store를 사용했는데 actions가 두 개 이상 늘어나니 가독성이 급격히 떨어지는 것을 느낄 수 있었습니다.
pinia에서 제공하는 다른 방법은 setup store입니다. 상태, getter, actions를 객체로 정의하는 option stores와 달리 setup store는 커스텀 훅과 비슷한 형식으로 상태, getter, actions를 정의할 수 있습니다. 이로 인해 option stores보다 action과 상태가 한 눈에 들어와 가독성, 유지 보수 면에서 좋다고 생각했습니다. 또, 프로젝트 전반에서 composition api를 사용하고 있기 때문에 일관성도 있다고 생각해 변경하게 되었습니다.

useFetch 구현

바닐라 자바스크립트로 프로젝트를 구현할때부터 useFetch를 만들어 사용하려는 시도를 했습니다. get 요청은 다른 요청과 다르게 UI와 밀접한 연관이 있습니다. 이는 데이터가 상태로 관리되어야 하기 때문에 따로 커스텀 훅 형식으로 개발해두면 다양한 get 요청에서 사용하여 중복 로직을 줄이고 함수들이 한 가지 일에 더 집중할 수 있다고 생각했습니다.

바닐라 자바스크립트 프로젝트에서는 렌더링 이슈 때문에 결국 useFetch를 사용하지 못했습니다. 이번 프로젝트에서 처음부터 useFetch를 구현할 생각은 없었지만 이번에 get 요청이 세 가지였고, 스토어에 로딩 상태, 에러 상태, 데이터 상태를 변경하는 로직들이 여러 번 등장하여 결국 만들게 되었습니다. 짧은 시간 안에 구현했기 때문에 범용성을 고려하여 개발하는 것이 까다로웠습니다. 특히 pagination 관련 로직들의 구현과 타입이 까다로웠습니다.

쉽게 생각하면 tanstack query의 useQuery를 가져다 사용하면 단순히 끝날 일이지만 손수 구현해가며 범용성과 구조를 고민해보는 시간이 많이 도움이 되었습니다. 기회가 된다면 useQuery를 참고하여 pagination 로직을 다시 구현해보는 것도 좋을 것 같습니다.

후기

프로그래머스를 통해 Vue를 배우기 전까지는 Vue에 대한 필요성을 크게 느끼지 못했습니다. 리액트가 지배적인 시장 환경에서 저는 리액트를 주로 사용하고 있었고, Vue를 배울 계획이 없었습니다. 하지만 실제로 Vue를 경험해보니, 그 독특한 장점이 눈에 띄었고 흥미로웠습니다.

최근 리액트에 대한 불만이 쌓이며, 내심 리액트의 세계가 빨리 끝나기를 바라고 있었습니다. 리액트의 자유도는 다양한 기술적 접근을 가능하게 했지만, 이로 인해 많은 고민을 하기도 했습니다. 기술을 다루는 방식과 형태가 여러 가지였고, 하나의 기능을 더 할 때마다 지금 나의 방식이 최선에 가까운 방식인지 고민하고 best practice를 찾아보는 시간이 많았습니다. 이로 인해 불필요하게 개발 속도가 느려진다는 생각이 들기도 했고 스트레스로 다가왔습니다.
또, 리액트의 함수형 컴포넌트는 props나 상태가 바뀌면 컴포넌트와 그 컴포넌트의 자식 컴포넌트가 리렌더링 됩니다. 이는 리액트 함수형 컴포넌트의 고유한 특성이기 때문에 불필요한 리렌더링이 발생하진 않는지, 성능 이슈가 있는 건 아닌지 확인해야 하고, 이로 인해 useCallback, useMemo, useEffect 같은 것을 사용해야 했습니다. 앞에서 말한 것과 같이, 리액트는 자유롭기 때문에 useEffect나 useMemo를 어느 상황에서, 언제 써야 하는지, 또 쓴다면 어떻게 사용해야 하는지, 어떤 방법이 가독성을 덜 해치는지에 대한 고민도 뒤따라왔습니다.

이런 배경에서 Vue에 대해 알아보니, 여러 가지 장점이 마음에 들었습니다. 우선, props나 state가 변경된다고 script가 재평가 되는 것이 아니기 때문에 성능 최적화나 리렌더링에 대한 고민이 없었습니다. 프레임워크로서의 강제성은 기술적 결정에 대한 고민을 줄여주었고, 이벤트 수식어를 사용하여 이벤트 리스닝을 더 세밀하게 제어할 수 있습니다. 특히 Transition 컴포넌트는 리액트에서의 애니메이션 처리와 비교해 간결하고 편리해보였습니다.

그러나 막상 프로젝트를 시작하니 어색하고 불편한 점도 있었습니다.
리액트에 익숙해져 있어 부모 상태가 변경되면 당연히 자식 컴포넌트가 리렌더링 된다고 생각하여 꽤 많은 시간을 고민하기도 하고, 문제가 생겨서 검색했을 때 자료가 적어 애를 먹기도 했습니다. 또 타입스크립트로 ref로 선언한 변수의 타입을 지정할 때 항상 Ref를 사용해야 하는 점이 불편하기도 했습니다.
또, 리액트는 모든 이벤트를 delegation으로 처리하기 때문에 항상 돔에 직접 이벤트 바인딩해도 성능 이슈가 없으나, Vue는 각 돔 요소에 직접 이벤트 리스너를 할당하기 때문에 delegation을 직접 해야 하는 것도 불편한 점 중 하나였습니다.

Vue에 대해 딥 다이브한 것은 아니지만 짧게 나마 새로운 기술을 익히고 기존에 알고 있던 기술과 장단점을 알아 보는 게 즐거웠습니다.

프로젝트 후기

작은 프로젝트를 현재 팀원들과 함께 협업하고 있습니다. 팀원분들이 항상 적극적이고 다양한 의견을 내주셔서 프로젝트가 더욱 풍부하고 다채로운 방향으로 나아가고 있다고 생각합니다. 의견 조율과 협업 과정에서 발생하는 어려움이 있지만, 이것 또한 중요한 학습 기회가 되고 있습니다. 서로 다른 배경과 경험을 가진 개발자들과 함께 일하면서, 의사소통의 중요성과 팀워크의 가치를 더욱 깊이 이해하게 되었습니다.

프로젝트의 진행 과정에서, 커뮤니케이션의 역할이 얼마나 중요한지 다시 한번 깨닫게 되었습니다. 모든 팀원이 자신의 의견을 자유롭게 표현할 수 있는 환경을 조성함으로써, 각자의 아이디어와 기술을 최대한 활용할 수 있었습니다.

개발 컨벤션과 스타일의 차이를 조율하는 과정은 시간이 많이 소요되고 있지만, 이를 통해 각 팀원의 개발 방식과 생각을 더 깊이 이해할 수 있었습니다. 서로의 작업 스타일을 존중하고 배우면서, 협업을 하는 방식을 배워갈 수 있었습니다.