"로그인은 됐는데 페이지 이동하면 로그아웃돼요. 장바구니 담았는데 새로고침하면 사라지고... 데이터를 어디에 저장해야 하는 건지 모르겠어요."
맞아요. AI한테 "저장해줘"만 하면 매번 다른 곳에 저장돼요. 어떤 건 메모리에만 있어서 새로고침하면 날아가고, 어떤 건 브라우저에만 저장돼서 다른 기기에선 안 보이고... 데이터가 어디에 있는지 모르니까 이런 일이 생기는 거예요.
왜 이런 일이 생길까요?
"어디에 저장할지" 안 말해줘서 그래요. 데이터(상태)를 어디에 둘지 정하지 않으면, AI가 알아서 적당한 곳에 넣어요. 근데 그게 여러분이 원하는 곳이 아닐 수 있어요.
18편에서 디자인 패턴을 배웠죠? 코드를 어떻게 짤지요. 근데 코드 구조만 알면 부족해요. 데이터를 어디에 둘지도 정해야 해요.
이걸 **상태 관리(State Management)**라고 해요.
상태 관리 개념을 알면 AI한테 **"로그인 상태는 전역으로, 폼 데이터는 로컬로 관리해줘"**라고 정확히 말할 수 있어요. 그러면 데이터가 날아가거나 동기화 안 되는 문제가 없어요.
중요한 건, AI가 만들어주면 끝이 아니에요.
로그인 기능 만들었으면 로그인해보고, 페이지 이동해보고, 새로고침해보고. 이 "확인 → 피드백" 과정이 없으면 나중에 다 꼬여요.
이 글을 읽고 나면
- 상태(State)가 뭔지, 왜 관리가 필요한지 알 수 있어요
- 전역 상태와 로컬 상태를 구분할 수 있어요
- 상황에 따라 어디에 상태를 둘지 판단할 수 있어요
- AI한테 "이 데이터는 전역으로, 저 데이터는 로컬로" 말할 수 있어요
상태(State)가 뭔가요?
**상태(State)**는 앱이 기억하는 데이터예요.
🧠 기억 비유
- 단기 기억: 방금 들은 전화번호 (메모리)
- 장기 기억: 집 주소, 생일 (DB)
→ 기억하는 곳이 다름
💻 앱 상태
- 지금 로그인한 사람이 누군지
- 장바구니에 뭐가 담겼는지
- 검색창에 뭐 입력했는지
- 다크모드가 켜져 있는지
→ 앱이 기억해야 할 모든 데이터
💡 왜 중요해요?
- 상태가 없으면 앱이 아무것도 기억 못 해요
- 로그인했는데 페이지 이동하면 까먹어요
- 상태를 어디에 둘지 정해야 제대로 작동해요 PART 4 복습: 디자인 패턴에서 상태 관리로
18편에서 코드를 어떻게 짤지를 배웠죠?
| 싱글톤 | 팩토리 | 옵저버 |
|---|---|---|
| 하나만 | 찍어내기 | 구독하기 |
| 로그인 상태 | 버튼 여러 개 | 상태 변화 알림 |
오늘 배울 것은: 그 상태를 어디에 둘지
- 18편: 코드 구조를 어떻게? → 싱글톤 / 팩토리 / 옵저버
- 19편(오늘): 상태를 어디에? → 전역 / 로컬 / DB / 브라우저
비유하면:
- 디자인 패턴 = 물건을 어떻게 정리할까? (서랍장 / 옷장 / 책장)
- 상태 관리 = 어디에 둘까? (방 / 거실 / 창고)
왜 상태 관리가 필요한가요?
상태를 제대로 관리 안 하면 이런 일이 생겨요.
❌ 관리 안 했을 때 (데이터 날아감)
- 로그인했는데 페이지 이동하면 로그아웃됨
- 장바구니 담았는데 새로고침하면 사라짐
- 입력 중이던 내용 페이지 나갔다 오면 없음
- 다크모드 켰는데 다시 들어오면 꺼져 있음
✅ 관리 했을 때 (데이터 유지)
- 로그인 상태 → 전역 상태로 → 앱 어디서든 유지
- 장바구니 → DB에 저장 → 새로고침해도 유지
- 입력 중 내용 → 로컬 상태로 → 페이지 안에서만 유지
- 다크모드 → 브라우저 저장 → 다시 켜도 설정 유지
💡 핵심: 데이터 성격에 맞게 저장 위치를 정해야 해요 상태를 둘 수 있는 곳 4가지
데이터를 저장할 수 있는 곳은 4가지예요.
1️⃣ 메모리 (Memory) - 로컬 상태
→ 컴포넌트 안에서만 씀. 페이지 나가면 날아감
→ 예: 검색창 입력 내용, 모달 열림/닫힘
2️⃣ 전역 상태 (Global State)
→ 앱 전체에서 씀. 새로고침하면 날아감
→ 예: 로그인 상태, 장바구니 (임시)
3️⃣ 브라우저 저장소 (localStorage)
→ 이 브라우저에만 저장. 새로고침해도 유지
→ 예: 다크모드 설정, 언어 설정
4️⃣ 서버 DB (Database)
→ 서버(백엔드)에 저장. 어디서든 접근 가능
→ 예: 회원 정보, 게시글, 주문 내역
💡 위로 갈수록 휘발성 (날아감), 아래로 갈수록 영구적 (유지) 1. 메모리 (로컬 상태)
**메모리(로컬 상태)**는 컴포넌트 안에서만 쓰는 데이터예요.
📝 메모장 비유
- 메모장에 전화번호 적어둠
- 메모장 덮으면 다시 안 봄
→ 잠깐만 기억하면 되는 것
💻 코드 예시
- 검색창에 입력 중인 내용
- 모달 창 열림/닫힘
- 드롭다운 선택된 항목 (임시)
- 폼 입력 중인 데이터 (제출 전)
→ 잠깐 쓰고 말 데이터
✅ 특징
- 빠름 (메모리에 있으니까)
- 페이지 나가면 날아감
- 새로고침하면 사라짐
- 다른 컴포넌트에선 못 씀
💡 언제 쓰나요?
- 입력 폼 (제출 전)
- 모달, 드롭다운 같은 UI 상태
- 임시 검색 결과
→ 저장할 필요 없는 것들 로컬 상태 예시: 검색창
로컬 상태: 입력 중인 텍스트 "맥북" [검색 버튼 클릭] → 입력 내용을 서버에 요청 → 검색 결과는 DB에서 가져옴 → 입력 내용 자체는 저장 안 함 [페이지 나가면] → 입력 내용 날아감 (OK, 저장 안 해도 됨)
2. 전역 상태 (Global State)
전역 상태는 앱 전체에서 쓰는 데이터예요.
🏛️ 게시판 비유
- 회사 게시판에 공지 붙임
- 어느 부서에서나 다 볼 수 있음
→ 전체가 공유하는 정보
💻 코드 예시
- 로그인한 사용자 정보
- 장바구니 목록 (임시)
- 알림 목록
- 앱 전체 테마 (다크/라이트)
→ 여러 페이지에서 같이 쓰는 데이터
✅ 특징
- 앱 어디서든 접근 가능
- 한 곳에서 바꾸면 전체 동기화 (옵저버 패턴 활용)
- 새로고침하면 날아감 (DB는 아님)
- React Context, zustand 같은 걸로 구현
💡 언제 쓰나요?
- 로그인 상태 (헤더, 사이드바, 메인 모두 씀)
- 장바구니 (여러 페이지에서 접근)
- 현재 선택된 언어, 테마
→ 여러 곳에서 같이 봐야 하는 것들 전역 상태 예시: 로그인
{ name: "김철수", email: "..." }
헤더 │ │ 사이드바 │ │ 메인
"김철수님"│ │ "내 정보" │ │ "환영..."
↑ ↑ ↑
같은 전역 상태 참조
[로그아웃하면]
→ 전역 상태 null로 변경
→ 헤더, 사이드바, 메인 모두 자동 업데이트
[새로고침하면]
→ 전역 상태 날아감 (문제 발생!)
→ 해결: localStorage나 DB와 함께 써야 함 3. 브라우저 저장소 (localStorage)
localStorage는 브라우저에 저장되는 데이터예요.
💾 메모장 저장 비유
- 메모장에 쓰고 파일로 저장
- 컴퓨터 껐다 켜도 파일은 남아 있음
→ 이 컴퓨터에만 저장됨
💻 코드 예시
- 다크모드 설정
- 언어 설정 (한국어/영어)
- 최근 본 항목
- "다시 보지 않기" 체크한 팝업
→ 이 브라우저에서만 유지되면 되는 것
✅ 특징
- 새로고침해도 유지됨
- 이 브라우저에만 저장 (다른 기기 X)
- 용량 제한 있음 (보통 5~10MB)
- 문자열만 저장 가능 (JSON 변환 필요)
💡 언제 쓰나요?
- 다크모드 같은 개인 설정
- 장바구니 (로그인 전 임시 저장)
- 최근 검색어
→ 기기별로 달라도 되는 것들
⚠️ 주의!
- 다른 기기에서 안 보임
- 비밀번호 같은 민감 정보 저장 금지
- 브라우저 청소하면 날아갈 수 있음 localStorage 예시: 다크모드
localStorage에 저장:
{ theme: "dark" }
[앱 시작할 때]
→ localStorage에서 theme 읽기
→ "dark"면 다크모드 적용
→ 전역 상태에도 넣기
[다크모드 토글]
→ 전역 상태 변경 ("dark" ↔ "light")
→ localStorage에도 저장
→ 다음에 다시 켜도 유지됨
[다른 기기에서]
→ localStorage는 이 브라우저에만 있음
→ 다른 기기에선 다시 설정해야 함
→ 모든 기기에서 같게? → DB에 저장해야 함 4. 서버 DB (Database)
**DB(데이터베이스)**는 서버(백엔드)에 저장되는 데이터예요.
☁️ 클라우드 비유
- 구글 드라이브에 파일 올림
- 어느 기기에서나 접근 가능
→ 서버에 저장되니까 어디서든 봄
💻 코드 예시
- 회원 정보 (이름, 이메일, 프로필 사진)
- 게시글, 댓글
- 주문 내역
- 친구 목록
→ 다른 기기에서도 봐야 하는 것
✅ 특징
- 어느 기기에서든 접근 가능
- 영구 저장 (회사가 망하지 않는 한)
- 용량 제한 거의 없음
- 여러 사람이 같이 씀
- API를 통해서만 접근 (프론트엔드가 직접 접근 X)
💡 언제 쓰나요?
- 회원 정보 (로그인 정보)
- 게시글, 댓글, 좋아요
- 주문, 결제 내역
- 친구, 팔로우 관계
→ 영구적으로 보관해야 하는 것들
⚠️ 주의!
- 프론트엔드(웹 브라우저, 앱)가 DB에 직접 접근 안 됨
- 반드시 API를 거쳐야 함
→ "Supabase로 users 테이블에 저장해줘" 이렇게 요청 DB 예시: 게시글
1. 입력 중
→ 로컬 상태 (메모리)
→ "안녕하세요..." 입력 중
2. [작성 완료 버튼]
→ API 호출 (프론트 → 백엔드)
→ 백엔드가 DB의 posts 테이블에 저장
3. 다른 기기에서 접속
→ API로 게시글 목록 요청
→ 백엔드가 DB에서 가져와서 전달
→ 프론트엔드가 화면에 표시
💡 핵심: 프론트엔드 → API → 백엔드 → DB
(프론트엔드가 DB에 직접 접근 X) 전역 상태 vs 로컬 상태
헷갈릴 수 있으니 정리해볼게요.
🌍 전역 상태 (Global State)
- 앱 전체에서 공유
- 여러 컴포넌트가 같이 씀
- 한 곳에서 바꾸면 전체 동기화
- 예: 로그인 상태, 장바구니, 알림
📍 로컬 상태 (Local State)
- 컴포넌트 안에서만 씀
- 다른 컴포넌트 접근 불가
- 페이지 나가면 날아감
- 예: 검색창 입력, 모달 열림/닫힘
💡 판단 기준:
다른 페이지/컴포넌트에서도 봐야 하나? → 전역
이 컴포넌트에서만 쓰나? → 로컬 상태 저장 위치 결정 가이드
어떤 데이터를 어디에 저장할까요?
❓ 다른 기기에서도 봐야 하나?
YES → DB (서버)
NO → ⬇️
❓ 새로고침해도 유지되어야 하나?
YES → localStorage (브라우저)
NO → ⬇️
❓ 여러 페이지/컴포넌트에서 같이 쓰나?
YES → 전역 상태 (Global State)
NO → 로컬 상태 (Local State, 메모리) 예시로 정리:
📱 로그인 상태
- 다른 기기? NO (이 브라우저만)
- 새로고침 유지? YES
- 여러 곳 공유? YES
→ localStorage + 전역 상태 (조합)
(localStorage에 토큰 저장, 전역 상태로 공유)
🛒 장바구니
- 다른 기기? YES (로그인 했으면)
→ DB (Supabase의 cart 테이블)
- 비로그인? localStorage (임시)
🔍 검색창 입력
- 다른 기기? NO
- 새로고침 유지? NO
- 여러 곳 공유? NO
→ 로컬 상태 (메모리)
🌙 다크모드
- 다른 기기? NO (기기별로 달라도 됨)
- 새로고침 유지? YES
- 여러 곳 공유? YES (헤더, 본문 모두 적용)
→ localStorage + 전역 상태
✏️ 게시글 작성 중
- 작성 중: 로컬 상태 (메모리)
- 임시 저장: localStorage
- 작성 완료: DB (posts 테이블)
→ 단계별로 다름! 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 테이블에 저장해줘" 하면 됨.
주의사항: 조합이 중요해요
⚠️ 하나만 쓰는 게 아니라 조합해서 써요
❌ 비현실적 (하나만 씀)
"로그인 상태는 전역 상태로만"
→ 새로고침하면 날아감
✅ 현실적 (조합)
"로그인 상태는:
- 전역 상태 (앱 전체 공유)
+ localStorage (새로고침 대응)
+ DB (사용자 정보는 서버에)"
💡 실전 패턴:
로그인: 전역 + localStorage + DB
장바구니: 전역 + (비로그인: localStorage, 로그인: DB)
게시글 작성: 로컬 → localStorage(임시) → DB(완료)
다크모드: 전역 + localStorage 다음 단계: AI한테 설계 지시하는 법
상태 관리 개념까지 배웠으면, 이제 PART 4의 마지막이에요.
PART 4에서 배운 것:
16편: 자료구조 - 데이터를 어떻게 조직할까?
17편: 아키텍처 - 전체 구조를 어떻게 잡을까?
18편: 디자인 패턴 - 코드를 어떻게 짤까?
19편: 상태 관리 - 데이터를 어디에 둘까?
다음 편(20편): 이 모든 걸 조합해서 AI한테 설계 지시하기
→ 실전 대화 예시로 처음부터 끝까지
오늘의 핵심 정리
→ 로그인 정보, 장바구니, 입력 중인 내용 등
✅ 상태 저장 위치 4가지
→ 메모리 (로컬 상태): 잠깐 쓰고 버림 (검색창)
→ 전역 상태: 앱 전체 공유 (로그인)
→ localStorage: 브라우저 저장 (다크모드)
→ DB: 서버 저장, 어디서든 접근 (게시글)
✅ 판단 기준
→ 다른 기기? → DB
→ 새로고침 유지? → localStorage
→ 여러 곳 공유? → 전역 상태
→ 그 외 → 로컬 상태
✅ AI한테 요청할 때:
"로그인 만들어줘" (X)
"로그인 상태는 zustand로 전역 관리하고,
토큰은 localStorage에 저장해줘.
Supabase Auth로 인증하고,
새로고침하면 localStorage 확인해서 자동 로그인." (O)
✅ 조합이 중요
→ 로그인: 전역 + localStorage + DB
→ 장바구니: 전역 + localStorage(비로그인) / DB(로그인)셀프체크
이 글을 이해했다면 아래 질문에 답할 수 있어요:
- 검색창 입력 내용은 어디에 저장하면 좋을까요? (페이지 나가면 날아가도 됨)
- 다크모드 설정은? (새로고침해도 유지, 기기별로 달라도 됨)
- 게시글 데이터는? (다른 기기에서도 봐야 함)
- 로그인 상태는? (앱 전체 공유 + 새로고침 유지)
정답 보기
- 검색창: 로컬 상태 (메모리) - 컴포넌트 안에서만 씀
- 다크모드: 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한테 설계 지시하는 법
↓
...
궁금한 점이나 다뤘으면 하는 주제가 있으면 댓글로 남겨주세요!