React · Vue 기초 중의 기초

그런데 진짜 많은 개발자가 여기서 헤맨다

useState, ref는 그냥 변수랑 다르다.
이걸 이해하면 React, Vue는 물론이고 어떤 언어·프레임워크도 훨씬 빨리 배운다.

AA로 일하면서 여러 개발자들이 단순한 오해에서 고생한다. 화면이 안 바뀌니까. 여기에 비동기까지 겹치면, 지금 아래 반응형 변수를 알고 있어도 또 헷갈린다.

1️⃣ 우리가 원래 알고 있던 "변수"의 세계

JavaScript, Java, C, Python…
우리는 이렇게 배웠다.

let count = 0;
count = count + 1;

이때 변수의 의미는 단순하다.

값 저장
값 변경
끝

💡 중요한 특징

값이 바뀌어도
그걸 누가 쓰는지는 변수는 모른다

즉, 변수는 세상에 관심이 없다.

2️⃣ UI 프레임워크가 등장하면서 문제가 생김

React, Vue 같은 프레임워크의 목적은 하나다.

"데이터가 바뀌면 화면도 자동으로 바뀌게 하자"

그런데 기존 변수는 이런 능력이 없다.

let count = 0;
count++;
// 화면은 그대로임 😅

그래서 등장한 개념이 바로 👇

3️⃣ 반응형 변수 (Reactive State)

React: `useState`

Vue: `ref` / `reactive`

이건 변수처럼 생겼지만, 사실은 다르다.

📌 핵심 정의

반응형 변수란
"값 + 값이 바뀌었음을 세상에 알리는 장치"다

4️⃣ `useState` / `ref`가 "다른 변수"인 이유

React 예제

tsx

const [count, setCount] = useState(0);

이 순간 일어나는 일:

count → 값
setCount → "값 바뀌었어!"라고 알리는 버튼

tsx

setCount(count + 1);

이건 단순 대입이 아니다.

값 변경
React에게 알림
관련된 컴포넌트 다시 그림 (re-render)

👉 이 3단계가 자동으로 묶여 있음

Vue 예제

const count = ref(0);
count.value++;

여기서 ref는:

값을 감싸는 상자
Vue가 계속 지켜보고 있음

count.value = 1;

이 순간 Vue는 말한다:

"아 값 바뀌었네? 화면 다시 그려야겠다"

5️⃣ 그래서 이런 실수가 나온다

❌ 자주 보는 실수

let count = 0;
count++;

그리고 말한다:

"왜 화면이 안 바뀌지?"

💥 이유는 간단하다.

이 변수는 반응형이 아니기 때문

6️⃣ 반응형 변수는 "상태(State)"다

여기서 중요한 사고 전환이 필요하다.

개념	일반 변수	반응형 변수
목적	값 저장	UI 상태 표현
변경 감지	❌ 없음	✅ 있음
화면 영향	❌ 없음	✅ 자동 반영

👉 모든 변수는 상태가 아니다
👉 화면에 영향을 주는 것만 상태다

7️⃣ Store (Redux, Zustand, Pinia 등)에 대한 오해

❌ 가장 흔한 착각

"store는 무조건 써야 하는 고급 기술"

아니다.

📌 store의 정체

store = 반응형 상태를 여러 컴포넌트가 공유하기 위한 장소

8️⃣ 그럼 언제 store를 써야 할까?

❌ 쓰지 말아야 할 경우

한 컴포넌트에서만 쓰는 값
잠깐 입력받는 폼 상태
UI 열림/닫힘 상태

👉 useState, ref면 충분

✅ store가 필요한 경우

여러 화면에서 같은 값 사용
로그인 정보
사용자 설정
장바구니
알림 개수

👉 "여기저기 전달하기 귀찮다"가 느껴질 때

9️⃣ store를 쓰면 생기는 또 다른 오해

txt

store = 만능

아니다.

store도 결국 반응형 변수들의 묶음
단지 범위(scope) 가 넓을 뿐

❗ store는 상태 관리 도구지
로직 저장소가 아니다

🔟 이 개념 하나만 잡히면 생기는 변화

이걸 이해하면:

React → Vue 전환 쉬움
Vue → Svelte 이해 빠름
상태 관리 라이브러리 두렵지 않음
"왜 안 바뀌지?" 질문 사라짐

🔁 비동기(Async)가 들어오면 왜 더 헷갈릴까?

현업에서 정말 많이 보는 상황이 있다.

"값은 분명 바뀌었는데 화면이 안 바뀌어요"
"콘솔에는 맞는데 UI가 이상해요"

이때 범인은 대부분 비동기 + 반응형 상태 오해다.

1️⃣ 비동기의 본질부터 정리

비동기란 간단히 말하면 이거다.

"지금 말한 코드 순서대로 안 끝날 수도 있다"

console.log('A');
fetchData();
console.log('B');

결과는 보통:

txt

A
B
(나중에 fetch 결과)

👉 비동기 작업은 나중에 끝난다

2️⃣ 현장에서 가장 많이 터지는 React 사례

tsx

const [user, setUser] = useState<User | null>(null);

async function loadUser() {
  const data = await fetchUser();
  setUser(data);
  console.log(user); // ❌ 왜 null?
}

이 코드는 초보뿐 아니라 경력자도 헷갈린다.

❌ 잘못된 기대

"setUser 했으니까 바로 user가 바뀌겠지"

✅ 실제로 일어나는 일

setUser 호출
React에게 "나중에 상태 바꿀게"라고 예약
현재 함수는 그대로 진행
console.log는 이전 상태를 출력
렌더 사이클 후에 user 변경

👉 상태 변경은 즉시 반영되지 않는다

3️⃣ Vue에서도 똑같이 발생하는 문제

const user = ref<User | null>(null);

async function loadUser() {
  user.value = await fetchUser();
  console.log(user.value); // ❌ 기대와 다를 수 있음
}

Vue는 React보다 직관적이지만,

렌더링 반영은
여전히 다음 tick에서 일어난다

그래서 존재하는 게 👇

await nextTick();

4️⃣ "값은 바뀌었는데 화면이 안 바뀌는" 진짜 이유

가장 흔한 패턴

tsx

setCount(count + 1);
setCount(count + 1);

기대:

txt

+2

현실:

txt

+1

이유

count는 같은 렌더 사이클의 값
React는 상태 변경을 모아서 처리

✅ 올바른 방식

tsx

setCount(prev => prev + 1);
setCount(prev => prev + 1);

👉 비동기 환경에서는 이전 상태 기반 업데이트가 필수

5️⃣ 비동기 + 일반 변수 = 사고 폭탄

let loading = false;

async function load() {
  loading = true;
  await fetchData();
  loading = false;
}

그리고 화면은 말한다:

"난 아무것도 모르겠는데?"

이유

loading은 반응형이 아님
값은 바뀌었지만 UI는 모른다

✅ 반드시 이렇게

tsx

const [loading, setLoading] = useState(false);

또는

const loading = ref(false);

6️⃣ 비동기 사고를 단순화하는 공식

현장에서 통하는 사고 공식은 이거다.

비동기 함수 안에서

일반 변수 ❌

상태(State) ✅

그리고 하나 더.

상태 변경 직후 값을 믿지 말 것

7️⃣ store에서도 동일하게 발생한다

store.user = data;
console.log(store.user); // ❌ 타이밍 이슈 가능

store라고 특별하지 않다.

store도 반응형
렌더 반영은 비동기

👉 store = 마법 아님

✨ 핵심 요약 (비동기까지 포함해서 이것만 기억)

반응형 상태 변경은 즉시 반영되지 않는다
비동기 함수 안에서는 이전 상태를 조심해야 한다
상태 연속 업데이트는 함수형 업데이트 사용
일반 변수 + 비동기 + UI = 거의 항상 버그
store도 동일한 원리를 따른다

💬 현장은 문법 문제가 아니라
타이밍과 상태에 대한 감각 싸움이다.

이 감각이 잡히면
"왜 화면이 안 바뀌지?"라는 질문은 사라진다.

React · Vue 기초 중의 기초

중년개발자