Zustand

김하늘 님의 답변

프론트엔드 개발자

아무거나 쓰셔도 됩니다. 추정컨대 부트캠프 프로젝트의 기술 수준에서 상태 관리 라이브러리에 대한 아주 깊은 이해가 필요한 영역까지 다루시지는 않으시겠죠? 그렇다면 그냥 잘 다루실 수 있는 거 다루시면 됩니다. 혹은 어차피 학습하는 단계니까 일부러라도 낯선 도구를 사용해보시는 것도 좋습니다. (프로젝트 데드라인에 대한 압박이 심하지 않다면 개인적으론 이걸 더 추천합니다.) 물론 지원하는 회사의 job description과 내가 익숙한 기술 일치한다면 당연히 어느 정도 메리트는 있습니다. 그런데 신입 레벨에서 redux냐 zustand냐가 크게 고려될 거 같지는 않습니다. 그보다 크리티컬한 요소가 훨씬 많으니까요. 다만 기술 선택에는 항상 근거가 필요합니다. 그 근거가 부실하면 아래와 같은 다양한 면접 질문에 제대로 답하지 못하게 되겠죠. - 왜 상태 관리 라이브러리를 썼나, 그냥 리액트 기능만으로 짜면 안되나 - 왜 많은 옵션들 중에서 zustand를 선택했냐 - zustand가 팀프로젝트를 진행하는데 장점이 많다고 했는데 어떤 점이 그러한가 - zustand를 좋아한다고 하셨는데 그럼 혹시 이런 이런 기능을 써보셨냐 혹은 zustand의 어떤 어떤 api의 작동 원리에 대해 설명해줄 수 있나

상현 님의 답변

프론트엔드 개발자

글의 항간이 느껴져서 zustand를 잘 사용하는 법보다는 store를 보다 더 잘 쓸 수 있는 방법에 대해서 말씀드리고 싶은데요. react는 한마디로 "중첩 스코프의 세계"라고 말할 수 있습니다. 보통 App이라는 스코프 아래에 Layout이라는 스코프가 있고, 그 스코프 아래에 다시 여러 Component 스코프가 켜켜이 쌓일 겁니다. 이런 중첩 구조에서는 동등한 서열 간의 스코프나 분기되어 서로 다른 곳으로 뻗어나간 스코프 사이에서 어떠한 값을 공유하려면 분기되기 전의 상위 스코프에 그 값이 놓여있어야 합니다. 그래야만 참조가 가능하죠. react의 초기 문서에는 이것을 두고 "끌어올리기"라는 표현을 썼습니다. zustand를 사용한다고 해서 이 구조를 바꿀 수 있는 것은 아닙니다. state 도구의 provider는 늘 App을 감싸는 것이 보통인데, 이는 분기 이전의 스코프가 필요하다는 구조적인 이슈는 바뀌지 않으니 끌어올리기를 극단적으로 맨꼭대기까지 한 결과입니다. 이렇듯 react의 구조를 바꾸지 못하고 편승함에도 store라는 스코프를 사용하는 이유는, 실질적인 구조는 바꾸기 때문입니다. store 이하의 모든 컴포넌트는 실질적으로는 중첩이 아닌 모두 평행 상태가 됩니다. App으로부터 30개 이상의 중첩을 거친 스코프에서나 App 바로 아래의 스코프나 모두 store와 직접 연결할 수 있고, 어느 단계의 스코프에서도 set과 get이 가능하고 그 값을 공유할 수 있습니다. 이로 인해서 각 스코프는 자신이 참조해야 할 값과 그 값을 변경시켜야 할 파이프라인만을 지니는, 자기 성격이 매우 강한 형태가 될 수 있습니다. 따라서 props 의존성이 대폭 줄어들죠. 이를 돌려말하면 의존성을 주입받는 것이 아니라 스코프 자신이 의존성을 결정하는 방식으로 가버린다는 의미입니다. 쉽게 말하면 용도가 뚜렷해서 다른 것으로 확장하거나 전환하기 어려워집니다. 그래서 사용하는 데에 있어 안배가 필요합니다. props 의존성을 가지고 있어야 하지만, 그걸 받아오기 위한 drilling의 정도가 심하다면 store를 사용하되 그 부모 컴포넌트가 값을 참조하여 내려주도록 조정하시고, props 의존성이 없어도 되고 특정 값을 오롯이 사용한다면 store와 직접 연결하도록 만드세요. 만약 store부터로 값을 참조하고, 그 값을 다루어야 하는 이벤트들이 얽혀있다면 state 계층을 분리해서 hook으로 만들어 view로부터 떼어내는 것도 한 방법입니다. store가 코드의 복잡성이나 불가분한 것들을 해결해주는 만능은 아니라는 점에 유의하시면 좋을 것 같습니다.

진성주 님의 답변

무신사 프론트엔드 개발자

1번은 next.js 13버전 app에 대해서 공식문서(베타)를 보시면 없어짐을 아실 수 있습니다. 사실상 컴포넌트가 렌더링 되는 방식이 12에선 페이지 단위였다면 13에선 컴포넌트 단위로 변경되다보니 getStaticProps -> ISR or SSG, getServersideProps -> SSR로 페이지단위 렌더링 방식이 고정되는걸 서버컴포넌트와 클라이언트 컴포넌트로 컴포넌트 단위로 렌더링되는 방식이 변경되었다고 이해하시는게 더 나을거 같아요. 2번은 next.js13부터는 컴포넌트가 만약 상태라는걸 갖고 싶다면 클라이언트 컴포넌트를 사용하도록 강제화하고 있습니다. 서버컴포넌트에서 상태는 결국 디비라고 보시는게 더 편할거 같고 전역상태관리도 결국 top down이 아닌 bottom up 방식으로 변경되어감으로써 리덕스나 주스탄스 같이 정말 어플리케이션 전반에 걸치 상태라는 것은 이제 안쓰고 그 역할을 리액트쿼리 같은 캐싱기반으로 대체될것으로 전 생각하고 잇습니다. 3번은 아시다 싶이 가능이 한다는 것뿐이니 작은 서비스가 아닌 이상 백엔드 서버와 프론트엔드 서버는 분리되어야 관리도 용이하며 대용량 서비스에도 더 적합하기 때문에 next.js에 직접 디비를 연결할 일은 잘 없을것으로 보입니다. 4번은 아래의 deno 블로그에 올라온 글을 읽어보심이 더 좋을거 같습니다. https://deno.com/blog/the-future-and-past-is-server-side-rendering 제가 아는 지식선에서 설명을 드리자면 CSR에서 문제가 되었던 부분은 결국 프론트엔드에서 만드는 어플리케이션이 커짐에 따라서 한 화면을 이루는 번들 자체가 커져서 문제가 되었것으로 기억합니다. 추가적으로 모든 코드를 클라이언트에 돌리다보니 보안적인 문제도 있는것으로 알고 있습니다. 결국 SSR로 돌아온 것을 맞습니다만 jsp시절보다 낫다하는 면은 jsp시절에서는 클라이언트에서 렌더링하는 것 한벌, 서버에서 렌더링하는 것 한벌 짜야했던 점이 이제는 next.js와서 한벌로 가능해졌다는 점이 있고 위에서 설명드린 것처럼 한화면 모두 SSR인 것이 SSR과 SSG의 혼합 등으로 조금 더 나은 렌더링방식을 가져가는 것으로 보입니다.