Vue 3 마이그레이션 환경에서 전역 데이터를 관리하는 가장 표준적이고 깔끔한 구조는 **Pinia(피니아)**를 사용하는 것입니다. Vue 2의 Vuex보다 훨씬 가볍고, TypeScript 지원이 강력하며 사용법이 직관적입니다.
소스 코드 수정 없이, 논리적인 **데이터 흐름(Data Flow)**과 디렉토리 구조를 중심으로 설명해 드릴게요.
🏗️ 전역 카테고리 관리 구조 (The Architecture)
전체적인 흐름은 **"중앙 저장소(Store)가 API를 호출하고, 컴포넌트는 그 데이터를 구독한다"**는 원칙을 따릅니다.
1. 디렉토리 구조 (Recommended Layout)
프로젝트 내에서 카테고리 데이터는 다음과 같이 격리되어 관리되는 것이 좋습니다.
- src/api/: 백엔드 통신 로직 (Axios 등)
- src/stores/: 전역 상태 관리 (Pinia Store)
- src/components/: UI 컴포넌트 (검색바, 네비게이션 등)
2. 데이터 흐름도 (Data Flow)
데이터는 단방향으로 흐르며, 모든 컴포넌트는 동일한 '단일 진실 공급원(Single Source of Truth)'을 바라보게 됩니다.
- 초기화 (App Startup): 메인 앱이 로드될 때 또는 카테고리가 필요한 첫 번째 컴포넌트가 마운트될 때 Store의 Action을 실행합니다.
- API 호출 (Fetch): Store 내부의 Action이 API 폴더에 정의된 함수를 호출하여 DB에서 카테고리 목록을 가져옵니다.
- 상태 저장 (State Update): 가져온 데이터를 Store의 State에 저장합니다.
- 반응형 전파 (Reactivity): Store를 구독하고 있는 모든 Vue 컴포넌트(Header, Sidebar 등)에 데이터가 자동으로 뿌려집니다.
- 가공 (Getters): 만약 특정 화면에서 "활성화된 카테고리만" 혹은 "특정 그룹의 카테고리만" 보여줘야 한다면, Store의 Getter를 이용해 원본 데이터를 건드리지 않고 필터링된 값을 실시간으로 계산해 가져옵니다.
🧐 왜 이 구조를 써야 할까요?
1. API 중복 호출 방지
여러 컴포넌트(예: 헤더와 사이드바)에서 카테고리 데이터가 동시에 필요하더라도, Store에서 **"이미 데이터가 있으면 API를 호출하지 않는다"**는 로직을 한 줄만 넣어두면 불필요한 네트워크 트래픽을 막을 수 있습니다.
2. 유지보수의 편의성
카테고리 데이터 형식이 바뀌거나 API 주소가 변경되어도, 수십 개의 컴포넌트를 뒤질 필요 없이 오직 Store 한 곳만 수정하면 애플리케이션 전체에 적용됩니다.
3. 컴포넌트의 단순화
컴포넌트는 "데이터를 어떻게 가져올지" 고민할 필요가 없습니다. 그저 Store에 "데이터 줘"라고 요청만 하면 되므로, UI 로직에만 집중할 수 있어 코드가 매우 깔끔해집니다.
💡 실무 팁: 새로고침 대응 (Persistence)
설명하신 대로 localStorage를 함께 활용하고 싶다면, Pinia의 플러그인을 사용하여 Store의 State가 바뀔 때마다 자동으로 localStorage에 쓰고, 앱이 켜질 때 자동으로 읽어오는 설정을 추가하면 됩니다. 이렇게 하면 개발자는 직접 getItem, setItem을 호출하는 지저분한 코드를 작성하지 않아도 됩니다.
