[매일메일+개발] 전역 상태 관리 라이브러리 + 레거시에 대한 간단 생각

전역 상태 관리 라이브러리를 사용하는 이유

컴포넌트 간 상태 공유가 용이해짐

• 여러 컴포넌트에서 공통적으로 사용되는 상태를 중앙화해 관리할 수 있음.
• 여러 곳에서 쉽게 값에 접근할 수 있음
• props drilling을 겪지 않고 상태를 공유할 수 있음

 

이 props drilling이란 무엇인가!

- 상위 컴포넌트에서 하위 컴포넌트로, 여러 단계를 거쳐 props를 전달하는 현상

어떤 데이터가 깊은 자식 컴포넌트에서 필요한 경우, 그 자신의 부모 -> 부모의 부모 -> 부모의^3....

중간 컴포넌트들이 props를 하위로 '전달'만 함

 

컴포넌트가 많아질수록 props 전달이 '복잡'하고 '지저분'해짐

중간 컴포넌트들이 불필요하게 '리렌더링'됨

 

지금 리팩토링 중인 코드 중 컴포넌트 하나가 props를 16개 넘기고 있는 게 있음

근데 start api의 응답값을 낱개로 쪼개서 props 16개로 넘기고 있음

 

기록 문서가 하나도 없어서, 레거시 코드를 5개월 읽은 짬으로 유추해보자면

-아마 처음에는 그냥 한두개 넘겨도 기능 구현이 가능했을 것임

-근데 기능이 점점 늘어남 -> 이때 전역 변수로 갈아탔어야 했는데 빨리 나가고 나중에 하지 뭐 라는 생각 했을 듯

-그래서 props를 한 두개씩 늘리다 보니까 이렇게 늘어난 것으로 추정 됨

 

하지만, 기존 컴포넌트에서 기능이 추가되어야 한다고 무작정 props를 새로 파는 건 좋은 패턴이 아님

 

이건 feconf 모노레포 세션 듣고 깨닫게 된 점인데(https://developer-dreamer.tistory.com/180)

기존 완성된 컴포넌트는 이전 개발자가 나름의 사고 회로를 거쳐 완결된 형태로 로직을 구성했을 것임

이걸 다른 곳에서 써야하니 props를 늘린다고 해서, 기존에 이 컴포넌트가 쓰이던 곳을 면밀하게 검토하냐? 보통 아님

그리고 이 props가 닿는 하위 컴포넌트들의 리렌더링이 연속적으로 발생해 발열 이슈랑도 연관될 수 있음

 

props를 늘려서 빠르게 구현한다면 비즈니스 임팩트는 내겠지만, 장기적으로 개발 환경은 나빠지는 선택일 수 있음

결국 trade off지만 어쨌든 내가 치는 코드가 후임자에게 어떤 영향을 미치는지 한번씩은 고민했음 좋겠음

 

관심사 분리가 용이해짐

상태 관리 로직을 컴포넌트에서 분리해 별도로 관리하면, 컴포넌트는 ui 로직에만 집중할 수 있게 됨

 

예) Redux

상태 변경 로직을 Reducer에 정의해두고, 컴포넌트 단에서 dispatch를 통해 Reducer를 호출하는 방식으로 동작

관심사의 분리 원칙을 따르며 코드 재사용성과 테스트 용이성을 높여줌

 

성능 최적화에 도움이 됨

현대의 상태 관리 라이브러리들은 불필요한 리렌더링을 방지하는 매커니즘을 제공함

예) zustand

구독 메커니즘을 통해 실제로 상태가 변경된 컴포넌트만 리렌더링 되도록 보장함

 

전역 상태 관리 라이브러리 도입을 고려할 때 주의할 점

작은 규모의 프로젝트에서는 전역 상태 관리 라이브러리가 오버엔지니어링이 될 수 있음

작은 규모임에도 도입한다면 불필요한 복잡성이 추가되어 개발 생산성이 저하될 수 있음

React의 내장 기능인 useState, useContext 만으로도 충분할 수 있음

 

프로젝트 규모가 크고 복잡한 상태 관리가 필요하거나, 여러 컴포넌트에서 공유하는 상태가 많다면 도입하면 좋음

 

---

 

학생 시절 토이프로젝트로 개발할 때는 전역상태 라이브러리 굳이 필요없을 수 있음

page depth도 별로 안깊고, 공용으로 써야 할 값도 별로 안많음

 

하지만 회사 규모의 프로덕트로 넘어가는 순간 이야기가 달라진다고 생각

 

현 레거시는 메인 파일에 useState만 300줄이 넘어감

이게 다 start api의 response 값을 낱개로 쪼개서 저장하는 용도임

그리고 그 값이 어떤 조건일 때 특정 컴포넌트가 노출되고...이런 식으로 관리되고 있음

근데 이걸 굳이 useState로 해야 하나?

아니라고 생각함

 

메인 파일에 useState로 선언하면

결국 이 state가 진짜 필요한 곳까지 props drilling을 할 수밖에 없음...

 

그래서 이 무한굴레를 부러뜨리려고 기능 개발하고 나서 개인 시간을 내서 리팩토링이든 뭐든 하고 있음

 

start api를 axios로 직접 호출하는게 아니라 tanstack query로 감싼 버전도 하나 만듦

리팩토링하는 코드나 새로 개발하는 코드는 props drilling이 아니라 tanstack query의 데이터 캐싱 값을 사용하도록 함

 

그리고, 진입하자마자 보여줘야 하는 기능이 있다면

메인 파일의 useState가 아니라 zustand의 persist로 세팅해서 열람 여부를 관리하도록 함

 

일단 눈 앞에 있는 것부터 하나씩 정리하다보면

더 고도화된 전략이 눈에 보이겠지

 

일단은... 개발을 할 수 있는 환경으로 만드는 게 우선이다

 

---

출처

1. 매일메일. 251002. 전역 상태 관리 라이브러리는 왜 사용하나요? https://www.maeil-mail.kr/question/124

2. 레거시 2+5개월차의 많은 생각