Vue에서 전역 스토어의 숨겨진 비용 (그리고 그것이 여전히 가치가 있을 때)

Source: Dev.to

글로벌 스토어가 매력적으로 보이는 이유

• 상태의 중앙 집중화 – 단일 진실의 원천.
• 우수한 DevTools 통합 – 손쉬운 검사와 타임 트래블 디버깅.
• 타입 안전성 – 특히 TypeScript를 사용할 때.
• 간단한 API – 액션과 getter를 직관적으로 사용할 수 있음.

Pinia의 흔한 오용

안티패턴: 로컬 또는 임시 상태를 저장하기

스토어가 존재한다는 이유만으로, 단일 컴포넌트나 뷰에 속하는 상태를 Pinia 스토어에 넣는 실수가 매우 흔합니다.

전형적인 예시

• 모달 열기/닫기 상태
• 폼 입력값
• 페이지‑특정 필터
• 임시 로딩 플래그

결과

• 스토어 비대화 – 관련 없는 상태가 섞여 축적됨.
• 소유권 불명확 – 어떤 컴포넌트가 데이터를 “소유”하는지 파악하기 어려워짐.
• 간접성 증가 – 간단한 로컬 문제조차 스토어를 거쳐야 함.
• 리팩토링 어려움 – 변경이 스토어 전체에 파급되어 무관한 부분까지 영향을 줌.

상태가 단일 컴포넌트 트리나 라우트에만 해당된다면, 로컬에 두는 것이 더 간단하고 건강합니다.

의존성 크리프

암묵적 의존성

컴포넌트가 스토어를 import 할 때마다 다음에 대한 암묵적 의존성이 생깁니다:

• 스토어 구조
• 내부 로직
• 부수 효과(예: API 호출)
• 라이프사이클

장기적 영향

• 컴포넌트 재사용이 어려워짐.
• 테스트에 더 많은 mocking 필요.
• 하나의 스토어 변경이 무관한 다수 컴포넌트에 의도치 않게 영향을 미침.

편리함으로 시작된 것이 결국 아키텍처의 중력처럼 작용해, 무관한 관심사가 같은 글로벌 레이어로 끌어당겨집니다.

글로벌 반응성의 성능 영향

반응성 오버헤드

글로벌 스토어는 기본적으로 반응형이므로:

• 모든 반응형 속성이 업데이트를 트리거할 수 있음.
• 스토어를 사용하는 모든 컴포넌트가 그 의존성 그래프에 참여함.

문제가 되는 상황

다음 경우에 문제가 발생합니다:

• 큰 객체를 전역에 저장할 때.
• 필요 없이 스토어가 깊게 반응형일 때.
• 컴포넌트가 실제로 사용하지 않는 상태까지 구독할 때.

이러한 상황은 다음을 초래할 수 있습니다:

• 불필요한 재렌더링.
• 비용이 많이 드는 computed 재계산.
• 미묘한 성능 저하.

shallowRef 같은 유틸리티나 스토어 분할로 문제를 완화할 수 있지만, 가장 좋은 최적화는 처음부터 상태를 전역화하지 않는 것입니다.

글로벌 스토어가 여전히 가치 있는 경우

이상적인 사용 사례

• 상태가 라우트 간에 지속되어야 할 때.
• 여러 멀리 떨어진 컴포넌트가 동일한 데이터를 필요로 할 때.
• 중앙 집중식 캐시나 동기화가 필요할 때.
• DevTools를 통한 디버깅이 중요할 때.
• 상태가 애플리케이션 전체의 관점을 나타낼 때(예: 인증, 기능 플래그, 전역 UI 설정, 공유 캐시 API 데이터, 알림).

스코프 규율

• 스토어를 작고 집중적으로 유지한다.
• UI‑전용 상태를 스토어에 넣지 않는다.
• 스토어 공개 API는 최소한의 반응형 표면만 노출한다.
• 스토어를 라이브러리 계약의 일부로 여기고, 일반적인 데이터 버킷으로 사용하지 않는다.

결론

글로벌 스토어는 강력하지만, 강력함에는 절제가 필요합니다. 의도적으로 사용한다면 아키텍처를 단순화시킵니다. 무분별하게 사용하면 조용히 아키텍처를 잠식합니다. 목적을 명확히 하고, 스코프를 제한하며, 적절할 때는 로컬 상태를 로컬에 두세요.

행복한 코딩 되세요! 🖥️