[KB IT’s your life 7기] Vue3 Pinia 상태관리 완벽 정리

안녕하세요! KB IT’s your life 7기 기자단입니다
저는 요즘 스켈레톤 프로젝트 한창 진행 중인데요!
Pinia를 써야 하는 상황이 왔는데 막상 쓰려니까 수업 때 배웠던 내용이 정리가 안 된 느낌이더라고요...
그래서 이번 기회에 제대로 복습 겸 정리해 봤어요!
저처럼 Pinia 개념이 아직 어렵다! 하는 분들께도
도움이 됐으면 좋겠습니다 ㅎㅎ

Pinia 전에 알아야 할 것

Pinia를 왜 써야 하는지 이해하려면
먼저 기존 방식인 Provide/Inject가 뭐가 문제인지부터
알아야 해요!
Provide/Inject는 부모 컴포넌트가 데이터를 제공(Provide)하고
자식 컴포넌트가 받아서(Inject) 쓰는 방식이에요
근데 프로젝트가 커지니까 이런 상황이 생겨요

문제 1. 형제 컴포넌트끼리 데이터 공유가 안 돼요

App (Provide)
├── C1 (Inject 가능 )
└── C2 (Inject 가능 )
    └── C2-1 (C1 데이터 못 받음 )

Provide/Inject는 같은 트리 안에서만 데이터를 공유할 수 있어요
C1이랑 C2-1처럼 서로 다른 가지에 있으면 공유가 안 되거든요

전체 앱에서 다 공유하려면 무조건 최상단 App에서 Provide 해야 하는데 그러면 지금 당장 안 쓰는 데이터까지 항상 메모리에 올라가 있어야 해서 비효율적이에요.

2. 문제 상태 데이터 보호가 개발자 책임이에요

전역으로 공유되는 데이터는 아무나 수정 못 하게
읽기 전용으로 노출해야 해요.
근데 Provide/Inject는 이걸 시스템이 막아주는 게 아니라 개발자가 직접 신경 써야 합니다.

그래서 computed로 감싸서 읽기 전용으로 노출하는데요

const readOnlyList = computed(() => state.todoList)
provide('todoList', readOnlyList) // 읽기 전용으로 전달
provide('addTodo', addTodo)       // action 함수는 그대로 OK

이게 시스템이 강제해 주는 게 아니라서
실수하기 딱 좋아요 ㅜㅜ

그래서 Pinia가 뭔데요?

Pinia(피니아)는 Vue3의 공식 상태관리 라이브러리예요
한마디로 여러 컴포넌트에서 공통으로 쓰는 데이터를
한 곳에서 관리하는 전역 저장소라고 보면 돼요!

Provide/Inject랑 비교하면 이런 차이가 있어요:

컴포넌트 결합	강하게 결합	완전 독립
공유 범위	하위 컴포넌트만	앱 전체
모듈화	어려움	스토어 단위로 쉽게
메모리 효율	항상 메모리 상주	필요할 때 생성

---

Pinia Store 만들기 (defineStore)

스토어는 src/stores 폴더 안에 만드는 게 관례예요.

// stores/todoStore.js
import { defineStore } from 'pinia'
import { reactive, computed } from 'vue'

export const useTodoStore = defineStore('todo', () => {

  // State — 반응형 상태 데이터
  const state = reactive({
    todoList: [],
    isLoading: false,
  })

  // Getter — 읽기 전용 노출
  const todoList = computed(() => state.todoList)
  const isLoading = computed(() => state.isLoading)
  const doneCount = computed(() =>
    state.todoList.filter(todo => todo.done). length
  )

  // Action — 상태를 수정하는 함수
  function addTodo(todo) {
    state.todoList.push(todo)
  }
  function deleteTodo(id) {
    state.todoList = state.todoList.filter(t => t.id!== id)
  }
  function toggleDone(id) {
    const todo = state.todoList.find(t => t.id === id)
    if (todo) todo.done =! todo.done
  }

  // 외부에 노출할 항목 반환
  return {
    todoList, isLoading, doneCount,
    addTodo, deleteTodo, toggleDone
  }
})

여기서 제일 중요한 포인트!
state자체는 절대 반환하지 않아요.
computed로 감싼 읽기 전용 버전만 노출해서
외부에서 직접 수정하는 걸 막아야 합니다.

---

컴포넌트에서 스토어 사용하기

<script setup>
import { computed } from 'vue'
import { useTodoStore } from '@/stores/todoStore'

const store = useTodoStore()

// Action 함수는 분해할당 OK
const { addTodo, deleteTodo, toggleDone } = store

// 참조 타입(배열)도 분해할당 OK — 반응성 유지됨
const { todoList } = store

// 원시 타입(숫자)은 반드시 computed로!
const doneCount = computed(() => store.doneCount)
</script>

<template>
  <div>
    <p> 완료된 할 일: {{ doneCount }}</p>
    <ul>
      <li v-for="todo in todoList" :key="todo.id">
        {{ todo.title }}
        <button @click="toggleDone(todo.id)">완료</button>
        <button @click="deleteTodo(todo.id)">삭제</button>
      </li>
    </ul>
  </div>
</template>

---

가장 많이 하는 실수 — 원시 타입 분해할당

이거 진짜 중요해서 따로 정리해요.
스토어에서 데이터 꺼낼 때 구조 분해 할당 편하게 쓰고 싶잖아요.
근데 숫자, 문자열, 불리언 같은 원시 타입을 분해할당하면 반응성이 깨져버려요!

// 원시 타입 분해할당 — 반응성 깨짐
const { doneCount } = store
// doneCount가 바뀌어도 화면이 안 바뀜!

// 올바른 방법
const doneCount = computed(() => store.doneCount)

왜 이런 일이 생기냐면
원시 타입은 분해할당 시 값이 복사돼요.

복사된 값은 원본 스토어랑 연결이 끊겨서 반응성이 사라지거든요.
반면 배열·객체 같은 참조 타입은 참조가 복사되기 때문에
원본이랑 연결이 유지돼서 반응성이 살아있어요.

타입	분해할당	권장 방법
number, string, boolean	반응성 깨짐	computed(() => store.value)
Array, Object	반응성 유지	분해할당 가능
Function (Action)	문제없음	분해할당 가능

---

새로고침 하면 데이터가 사라져요 — Local Storage 연동

Pinia 상태는 메모리에만 있어서
새로고침 하면 초기화돼요.
서버 없이 데이터를 유지하려면
Local Storage에 저장해야 합니다!

function addTodo(todo) {
  state.todoList.push(todo)
  syncStorage() // 상태 변경할 때마다 저장
}

function deleteTodo(id) {
  state.todoList = state.todoList.filter(t => t.id !== id)
  syncStorage()
}

// 로컬 스토리지에 저장 (문자열로 직렬화)
function syncStorage() {
  localStorage.setItem('todos', JSON.stringify(state.todoList))
}

// 앱 시작할 때 로컬 스토리지에서 복원
function loadFromStorage() {
  const saved = localStorage.getItem('todos')
  if (saved) state.todoList = JSON.parse(saved)
}

Local Storage는 문자열만 저장할 수 있어서
JSON.stringify()로 저장하고 JSON.parse()로 꺼내야 해요!

---

아키텍처 고민 — 단일 책임 원칙 (SRP)

스토어 안에 서버 통신 코드까지 넣으면 편하긴 한데,
이러면 Pinia 책임이 두 개가 돼버려요.

• 상태 관리 (원래 Pinia 역할)
• 서버 통신 (추가된 역할)

단일 책임 원칙(SRP)
“하나의 모듈은 하나의 이유로만 수정되어야 한다.”

API URL이 바뀌어도, 상태 구조가 바뀌어도
둘 다 스토어를 수정해야 하는 상황이 생기거든요.
그래서 통신 코드는 별도 파일로 분리하는 게 좋아요!

// 스토어가 통신까지 담당 — SRP 위반
async function fetchTodos() {
  const res = await fetch('https://api.example.com/todos')
  state.todoList = await res.json()
}

// API는 별도 파일로 분리
// api/todoApi.js — 통신만 담당
export const getTodos = () =>
  fetch('https://api.example.com/todos').then(r => r.json())

// stores/todoStore.js — 상태 관리만 담당
import { getTodos } from '@/api/todoApi'

async function fetchTodos() {
  state.isLoading = true
  state.todoList = await getTodos() // 호출만!
  state.isLoading = false
}

이렇게 하면

• API 주소 바뀌면 → todoApi.js만 수정
• 상태 구조 바뀌면 → todoStore.js만 수정

수정 이유가 딱 하나씩이 되는 거예요 😎

---

마무리

복습하면서 정리하다 보니까
수업 때 흘려들었던 부분들이 이제야 제대로 이해됐어요.
스켈레톤 프로젝트에서 Pinia 실제로 써보면서
더 익혀봐야겠습니다 💪
같은 내용으로 헷갈리셨던 분들께 도움이 됐으면 좋겠어요!
다음 포스팅에서 봬요 😊