"로그인은 됐는데 페이지 이동하면 로그아웃돼요. 장바구니 담았는데 새로고침하면 사라지고... 데이터를 어디에 저장해야 하는 건지 모르겠어요."

맞아요. AI한테 "저장해줘"만 하면 매번 다른 곳에 저장돼요. 어떤 건 메모리에만 있어서 새로고침하면 날아가고, 어떤 건 브라우저에만 저장돼서 다른 기기에선 안 보이고... 데이터가 어디에 있는지 모르니까 이런 일이 생기는 거예요.

왜 이런 일이 생길까요?

"어디에 저장할지" 안 말해줘서 그래요. 데이터(상태)를 어디에 둘지 정하지 않으면, AI가 알아서 적당한 곳에 넣어요. 근데 그게 여러분이 원하는 곳이 아닐 수 있어요.

18편에서 디자인 패턴을 배웠죠? 코드를 어떻게 짤지요. 근데 코드 구조만 알면 부족해요. 데이터를 어디에 둘지도 정해야 해요.

이걸 **상태 관리(State Management)**라고 해요.

상태 관리 개념을 알면 AI한테 **"로그인 상태는 전역으로, 폼 데이터는 로컬로 관리해줘"**라고 정확히 말할 수 있어요. 그러면 데이터가 날아가거나 동기화 안 되는 문제가 없어요.

중요한 건, AI가 만들어주면 끝이 아니에요.

로그인 기능 만들었으면 로그인해보고, 페이지 이동해보고, 새로고침해보고. 이 "확인 → 피드백" 과정이 없으면 나중에 다 꼬여요.

이 글을 읽고 나면

  • 상태(State)가 뭔지, 왜 관리가 필요한지 알 수 있어요
  • 전역 상태와 로컬 상태를 구분할 수 있어요
  • 상황에 따라 어디에 상태를 둘지 판단할 수 있어요
  • AI한테 "이 데이터는 전역으로, 저 데이터는 로컬로" 말할 수 있어요

상태(State)가 뭔가요?

**상태(State)**는 앱이 기억하는 데이터예요.

PART 4 복습: 디자인 패턴에서 상태 관리로

18편에서 코드를 어떻게 짤지를 배웠죠?

오늘 배울 것은: 그 상태를 어디에 둘지

  • 18편: 코드 구조를 어떻게? → 싱글톤 / 팩토리 / 옵저버
  • 19편(오늘): 상태를 어디에? → 전역 / 로컬 / DB / 브라우저

비유하면:

  • 디자인 패턴 = 물건을 어떻게 정리할까? (서랍장 / 옷장 / 책장)
  • 상태 관리 = 어디에 둘까? (방 / 거실 / 창고)

왜 상태 관리가 필요한가요?

상태를 제대로 관리 안 하면 이런 일이 생겨요.

상태를 둘 수 있는 곳 4가지

데이터를 저장할 수 있는 곳은 4가지예요.

상태 저장소 4가지 유형

1. 메모리 (로컬 상태)

**메모리(로컬 상태)**는 컴포넌트 안에서만 쓰는 데이터예요.

로컬 상태 예시: 검색창

2. 전역 상태 (Global State)

전역 상태는 앱 전체에서 쓰는 데이터예요.

전역 상태 예시: 로그인

3. 브라우저 저장소 (localStorage)

localStorage는 브라우저에 저장되는 데이터예요.

localStorage 예시: 다크모드

4. 서버 DB (Database)

**DB(데이터베이스)**는 서버(백엔드)에 저장되는 데이터예요.

DB 예시: 게시글

전역 상태 vs 로컬 상태

헷갈릴 수 있으니 정리해볼게요.

상태 저장 위치 결정 가이드

어떤 데이터를 어디에 저장할까요?

예시로 정리:

AI한테 이렇게 요청하세요

상태 관리 개념을 알면 AI한테 어디에 저장할지 정확히 말할 수 있어요.

상황 1: 로그인 기능

❌ 나쁜 예 (저장 위치 안 말함)

나: "Next.js로 로그인 기능 만들어줘"

→ AI가 알아서 만드는데, 새로고침하면 로그아웃될 수도 있어요.

✅ 좋은 예 (전역 상태 + localStorage)

나: "Next.js + Supabase로 로그인 기능 만들 건데,

    1. 상태 관리:
       - 로그인 정보는 전역 상태로 관리 (zustand 써줘)
       - 앱 전체에서 접근 가능하게
       - 헤더, 사이드바, 메인에서 다 쓸 거야

    2. 새로고침 대응:
       - 액세스 토큰은 localStorage에 저장
       - 앱 시작할 때 localStorage 확인해서
         토큰 있으면 자동 로그인

    3. 로그아웃:
       - 전역 상태 null로 초기화
       - localStorage도 삭제

    옵저버 패턴으로 로그인 상태 바뀌면
    모든 컴포넌트 자동 업데이트되게 해줘."

상황 2: 장바구니

❌ 나쁜 예

나: "장바구니 기능 만들어줘"

✅ 좋은 예 (로그인 여부에 따라 다르게)

나: "쇼핑몰 장바구니 만들 건데, 상태 관리 두 가지로 나눠줘.

    1. 비로그인 사용자:
       - 장바구니 데이터를 localStorage에 저장
       - 이 브라우저에서만 유지
       - 전역 상태로 앱 전체 공유

    2. 로그인 사용자:
       - Supabase의 cart 테이블에 저장 (user_id 연결)
       - 다른 기기에서도 접근 가능
       - 로그인하면 localStorage 데이터를 DB로 이동

    장바구니 담기, 삭제, 수량 변경하면
    옵저버 패턴으로 장바구니 아이콘, 목록, 총액 동시 업데이트."

상황 3: 게시글 작성

❌ 나쁜 예

나: "게시글 작성 페이지 만들어줘"

✅ 좋은 예 (단계별 상태 관리)

na: "게시글 작성 페이지 만들 건데, 상태를 단계별로 관리해줘.

    1. 작성 중 (로컬 상태):
       - 입력 중인 제목, 내용은 로컬 상태로 (메모리)
       - Container-Presenter 패턴으로
         PostEditorContainer에서 상태 관리

    2. 임시 저장 (localStorage):
       - "임시 저장" 버튼 누르면 localStorage에 저장
       - 키: draft_post_{timestamp}
       - 페이지 들어올 때 임시 저장본 있으면 복구 물어보기

    3. 작성 완료 (DB):
       - "등록" 버튼 누르면 Supabase posts 테이블에 저장
       - 필드: title, content, user_id, created_at
       - 저장 성공하면 localStorage 임시 저장본 삭제

    에러 처리도 해줘:
    - 네트워크 끊겼을 때 localStorage에 자동 저장
    - 복구 기능"

실제 대화 예시

AI랑 상태 관리 설계하면서 대화할 때 이렇게 해요.

┌───────────────────────────────────────────────────────────────────────┐ │ 1단계: 기능 설계 및 상태 관리 방향 결정 │ ├───────────────────────────────────────────────────────────────────────┤ │ │ │ 나: "할 일 관리 앱 만들 건데, Next.js + Supabase 쓸 거야." │ │ │ │ AI: "할 일 데이터를 어디에 저장할까요? │ │ 옵션: │ │ 1. localStorage (오프라인 가능, 이 기기만) │ │ 2. Supabase DB (다른 기기 동기화, 로그인 필요)" │ │ │ │ 나: "Supabase DB로 가자. 다른 기기에서도 봐야 하니까. │ │ 근데 로그인 전에도 쓸 수 있게 임시로 localStorage 쓰고, │ │ 로그인하면 DB로 옮겨줘." │ │ │ └───────────────────────────────────────────────────────────────────────┘

┌───────────────────────────────────────────────────────────────────────┐ │ 2단계: 상태 관리 구조 협의 │ ├───────────────────────────────────────────────────────────────────────┤ │ │ │ AI: "상태 관리는 어떻게 할까요? │ │ 1. 전역 상태 (zustand, React Context) │ │ 2. 로컬 상태 + props로 전달 │ │ 3. React Query로 서버 상태 관리" │ │ │ │ 나: "zustand로 전역 상태 관리해줘. │ │ │ │ 전역 상태: │ │ - todos: 할 일 목록 │ │ - addTodo, deleteTodo, toggleTodo 액션 │ │ │ │ 옵저버 패턴으로 todos 바뀌면 │ │ TodoList, TodoCounter 자동 업데이트되게. │ │ │ │ 입력 폼은 로컬 상태로 (메모리). │ │ 추가 버튼 누를 때만 전역 상태 업데이트." │ │ │ └───────────────────────────────────────────────────────────────────────┘

┌───────────────────────────────────────────────────────────────────────┐ │ 3단계: 구현 및 기능 단위 확인 │ ├───────────────────────────────────────────────────────────────────────┤ │ │ │ AI: "zustand store 만들고, 컴포넌트 연결했어요." │ │ │ │ [기능 단위로 직접 확인] │ │ 1. 할 일 추가 │ │ → 입력하고 추가 버튼 클릭 │ │ → 목록에 바로 뜸 ✅ │ │ → Counter도 자동 업데이트 ✅ │ │ │ │ 2. 새로고침 │ │ → 어? 데이터 날아가네? │ │ │ │ 나: "새로고침하면 데이터 날아가는데? │ │ Supabase todos 테이블에 저장하고, │ │ 앱 시작할 때 DB에서 불러와서 전역 상태에 넣어줘." │ │ │ │ AI: "todos 테이블 만들고 CRUD API 연결할게요. │ │ 컴포넌트 마운트될 때 DB에서 가져와서 zustand에 넣겠습니다." │ │ │ │ [다시 확인] │ │ - 할 일 추가 → DB에 저장 → 목록 업데이트 ✅ │ │ - 새로고침 → DB에서 불러옴 → 유지됨 ✅ │ │ - 다른 탭에서 열기 → 같은 데이터 ✅ │ │ │ │ 💡 핵심: │ │ - 전역 상태 (zustand): 앱 안에서 공유 │ │ - DB (Supabase): 영구 저장 + 다른 기기 동기화 │ │ - 로컬 상태 (입력 폼): 잠깐 쓰고 버림 │ │ → 데이터 성격에 맞게 위치 나눔! │ │ │ └───────────────────────────────────────────────────────────────────────┘

코드 문법 몰라도 돼요

💡 잠깐, zustand? React Context? 이게 뭔데요?

괜찮아요. 개념만 알면 돼요.

여러분이 알아야 할 것:
✅ 로컬 상태 = 컴포넌트 안에서만 씀 (검색창)
✅ 전역 상태 = 앱 전체에서 씀 (로그인)
✅ localStorage = 브라우저 저장 (다크모드)
✅ DB = 서버 저장 (게시글)

여러분이 몰라도 되는 것:
❌ zustand 코드 문법
❌ React Hook 구현 디테일
❌ localStorage API 사용법

→ AI한테 "전역 상태로 관리해줘" 하면 됨.
→ "localStorage에 저장해줘" 하면 됨.
→ "Supabase todos 테이블에 저장해줘" 하면 됨.

주의사항: 조합이 중요해요

⚠️ 하나만 쓰는 게 아니라 조합해서 써요

다음 단계: AI한테 설계 지시하는 법

상태 관리 개념까지 배웠으면, 이제 PART 4의 마지막이에요.

PART 4에서 배운 것:
16편: 자료구조 - 데이터를 어떻게 조직할까?
17편: 아키텍처 - 전체 구조를 어떻게 잡을까?
18편: 디자인 패턴 - 코드를 어떻게 짤까?
19편: 상태 관리 - 데이터를 어디에 둘까?

다음 편(20편): 이 모든 걸 조합해서 AI한테 설계 지시하기
              → 실전 대화 예시로 처음부터 끝까지

오늘의 핵심 정리

셀프체크

이 글을 이해했다면 아래 질문에 답할 수 있어요:

  • 검색창 입력 내용은 어디에 저장하면 좋을까요? (페이지 나가면 날아가도 됨)
  • 다크모드 설정은? (새로고침해도 유지, 기기별로 달라도 됨)
  • 게시글 데이터는? (다른 기기에서도 봐야 함)
  • 로그인 상태는? (앱 전체 공유 + 새로고침 유지)
  • 검색창: 로컬 상태 (메모리) - 컴포넌트 안에서만 씀
  • 다크모드: localStorage + 전역 상태 - 브라우저 저장 + 앱 전체 공유
  • 게시글: DB (Supabase posts 테이블) - 서버에 영구 저장
  • 로그인: 전역 상태 + localStorage + DB - 조합! (전역: 앱 공유, localStorage: 토큰 저장, DB: 사용자 정보)

다음 글 예고

오늘은 상태 관리 개념을 배웠어요. 데이터를 어디에 저장할지, 로컬/전역/브라우저/DB 중에 선택하는 법이요.

PART 4에서 여기까지 배웠어요:

  • 자료구조 (데이터 조직)
  • 아키텍처 (전체 구조)
  • 디자인 패턴 (코드 작성 방법)
  • 상태 관리 (데이터 저장 위치)

다음 글에서는 이 모든 걸 조합해서 AI한테 설계 지시하는 법을 알아볼게요.

20편: AI한테 설계 지시하는 법

  • PART 4 종합 실습
  • 처음부터 끝까지 실전 대화 예시
  • "할 일 관리 앱을 설계부터 구현까지 AI랑 대화하면서 만들기"

개념을 배웠으면, 이제 실전에서 어떻게 쓰는지 보여드릴게요.

이 시리즈 로드맵

PART 4: 기술 개념 - 설계
[ 16편 ] 자료구조 개념 ✅
   ↓
[ 17편 ] 아키텍처 개념 ✅
   ↓
[ 18편 ] 디자인 패턴 개념 ✅
   ↓
[ 19편 ] 상태 관리 개념 (지금 여기!)
   ↓
[ 20편 ] AI한테 설계 지시하는 법
   ↓
  ...

궁금한 점이나 다뤘으면 하는 주제가 있으면 댓글로 남겨주세요!