React의 state는 동기인가 비동기인가. with 이벤트 루프

🤔 시작하며

최근 과제테스트를 보면서 무한스크롤 구현 시 useEffect가 내 마음대로 동작지 않았다.
추후 해결하긴 했지만, 나는 useState와 useEffect사이에서 뭐가 어떤게 먼저 실행되는지 자신있게 말할 수 없었다.

 

결국 시작은 우리가 처음 리액트를 배울때 헷갈렸던 가장 기초적인 예제에서 시작한다.

const handleClick = () => {
  setCount(count + 1);
  console.log(count); // 이전 값이 찍힘
};

 

왜 여기서 이전 값이 찍히는가 ? 왜 바로 count+1된 값이 찍히지 않는걸까? state는 언제 업데이트 되는걸까?

이에 대한 답을 알아보도록 하겠다.

📚 동기와 비동기 간단 정리

동기(sync) : 실행순서가 보장되는 것을 뜻한다. 호출 시 결과를 바로 확인할 수 있다. (const, let, for, if, function, console.log() 기본적으로 모두 js의 함수는 모두 동기이다.)

 

비동기(async) : 실행순서가 보장되지 않는것을 뜻한다. 호출 시 결과가 나중에 도착한다. (setTimeout, fetch, Promise, await)

 

여기서 잠깐 자바스크립트의 이벤트 루프를 짚고 넘어가자면 아래와 같은 형태이다.

 

콜스택에서 호출된 함수가 백그라운드에서 실행되고 이에대한 콜백함수들이 콜백큐로 넘어간다.

 

MicroTaskQueue에 담기는 비동기 동작 : Promise, await, queueMicrotask
MacroTaskQueue에 담기는 비동기 동작 : setTimeout, setInterval, DOM 이벤트 등

 

 

(우선순위는 MicroTaskQueue > CallbackQueue 이다 )

 

⚙️ React 상태 업데이트 흐름

React의 렌더링 흐름은 다음과 같다. (setState → render → commit → effect)

자 이제 다시 예시를 보자

const handleClick = () => {
  setCount(count + 1);
  console.log(count); // 이전 값이 찍힘
};

 

위 예시에서 왜 이전값이 찍힐까?

 

그건 바로 setState가 즉시 실행되더라도 실제 반영은 렌더링 이후에 일어나기 때문이다.

 

이는 상태는 snapshot(정적인 UI 복사본)처럼 동작하기 때문이다.

 

Rendering : 이란 React가 컴포넌트인 함수를 호출하는 것을 의미한다.

해당 함수에서 반환하는 JSX 컴포넌트는 시간에 따른 UI스냅샷과 같다.

 

프로퍼티, 이벤트핸들러, 로컬변수 모두 렌더링 당시의 상태(스냅샷)를 기준으로 계산된다.
그래서 리액트는 이 스냅샷에 맞게 화면을 업데이트하고, 이벤트 핸들러를 연결한다.

 

렌더링 시점 → count = 0
   ↓
클릭 발생 → handleClick() 실행
   ↓
setCount(count + 1) → setCount(0 + 1) → "업데이트 예약"
   ↓
console.log(count) → 0 ← 아직 리렌더링 안 됐으니까!
   ↓
React가 리렌더링 → count = 1
## 

 

이렇게 스냅샷처럼 저장되는 이유는 React의 Batching 알고리즘 때문이다.

 

React는 효율적인 상태 업데이트를 위해 여러 개의 setState 호출을 즉시 반영하지 않고,

 

"하나의 렌더링 사이클로 묶어서 한꺼번에 처리"  배칭(Batching) 과정을 거친다.

이 덕분에 리액트는 성능을 최적화하고, 불필요한 렌더링을 줄일 수 있으며 기존의 업데이트에 비해 빠른 성능을 유지할 수 있다.

여기서 중요한건

setState()는 상태를 "즉시 변경"하는 것이 아니라 React의 업데이트 큐에 "변경 요청을 등록"만 한다.
React는 현재 실행 중인 이벤트 핸들러나 렌더링이 끝난 뒤에 모든 상태 업데이트를 한 번에 처리하기 위해 큐에 쌓아둔다.

 

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

• 위의 예시는 만약 배칭이 없다면 렌더링이 3번 발생할 것이다.
• 하지만 배칭 덕분에 React는 한번의 렌더링만 실행한다.
• 그리고 이 모든 setCount는 같은 count=0이란 상태의 스냅샷 기반이라 결과는 결국 count+1이다.
• 결국 다음 렌더링에서의 상태 변화는, 이전 렌더링 시점의 "스냅샷"을 기준으로 만들어진 업데이트 요청을 처리한 결과인 것이다.

 

그래서 만약 함수형 업데이트를 쓰고싶다면 리액트가 권장하는 다음과 같은 방식을 써야한다.

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

• 이 방식에선 React가 첫 번째 업데이트가 반영된 직후의 최신 값을 두 번째에도 넘겨준다.
• 즉, React는 이 두 개를 순서대로 "큐에 저장"했다가
  각 콜백을 최신 값 기준으로 차례로 실행한다.
• prev => ... 형태의 업데이트는 React가 상태 변경을 처리할 때
• "이전 상태를 넘겨줄게, 네가 계산해봐" 방식이기 때문에 함수형 업데이트는 항상 최신값을 받는다
• 이 덕분에 렌더링 중 만들어진 스냅샷에 의존하지 않고,
  실제로 큐 처리 순서에 따라 최신 값을 안전하게 계산할 수 있다.

일반 업데이트:

"내가 본 상태(이전 snapShot)(count=0)에서 1 더해줘!"

 

함수형 업데이트:

"네가 알고 있는 가장 최신 상태(이전에 +1된 상태)(prev)를 알려주면, 거기서 1 더할게."

📌 실제 흐름 요약

const handleClick = () => {
  setCount(count + 1); //이전 스냅샷(count : 0) +1
  console.log(count); //이전 스냅샷(count : 0)
};

 

결과 : 

0

✅ 결론: 동기인가, 비동기인가?

state 는 동기이다. useEffect도 동기이다.

 

하지만 리액트 내부의 스케쥴링 (리액트 내부에서 js런타임과 달리 스케쥴링 된다.)에 의해 useState와 useEffect의 실행시점이 다르다

 

useState: 재렌더링 하라는 Trigger

useEffect: state에 의한 sideEffect를 처리하는 용도 이기 때문에 useEffect의 동작은 렌더링 이후 mount 된후 (DOM업데이트) 이후에 실행된다

 

상태 변경 발생(setState 호출 등) 
⬇️ 상태 변경 배칭 
⬇️ 렌더링 (return 문 실행) 
⬇️ 화면(DOM) 업데이트 
⬇️ useEffect 실행

 

(이것도 중간에 비동기 함수가 껴있느냐 아니냐에 따라 달라지는데, 이는 다음에 쓸 글에서 잇도록 하겠다.)

📊 표로 정리하면

 

✅ React 상태 업데이트 및 실행 흐름 요약 표

단계	시점 / 실행 대상	설명
1️⃣	setState() 호출	상태 변경 요청 (즉시 실행됨)
2️⃣	업데이트 예약	상태는 아직 변경되지 않음. React의 업데이트 큐에 저장됨
3️⃣	배칭 처리	여러 setState()가 모이면 한 번에 처리됨 (배칭)
4️⃣	컴포넌트 재렌더링	새로운 스냅샷 생성. 이 시점의 state, props, 변수들은 "고정"됨
5️⃣	DOM 업데이트 (Commit Phase)	실제 DOM에 변경사항 반영됨
6️⃣	useEffect() 실행	렌더링 이후 실행되는 사이드 이펙트 처리 영역

 

🔄 일반 업데이트 vs 함수형 업데이트 비교 표

방식	코드 예시	처리 기준	결과
일반 업데이트	setCount(count + 1)	렌더링 당시의 스냅샷 기준	여러 번 호출해도 같은 값 기준 → 누적되지 않음
함수형 업데이트	setCount(prev => prev + 1)	React가 최신 상태를 넘겨줌	최신 상태 기준 → 누적 가능

 

🔍 상태와 useEffect 실행 흐름 비교

항목	실행 시점	비고
setState()	동기 (즉시 실행)	실제 상태 반영은 나중에(Batcing으로 한번에 처리)
렌더링 (return)	상태 변경 직후	JSX → Virtual DOM 계산
useEffect()	렌더링 & DOM 업데이트 이후	비동기처럼 작동. 사이드 이펙트 처리용

 

📌 핵심 개념 정리표

개념	설명
스냅샷	렌더링 시점의 상태, props, 클로저들이 고정된 상태
배칭(Batching)	여러 상태 변경을 하나의 렌더링으로 처리하여 성능 최적화
함수형 업데이트	최신 상태를 기반으로 상태를 계산할 수 있게 하는 React 기능
useEffect 실행 시점	렌더링 후, 실제 DOM 커밋 이후

 

---

 

 

결론
React의 상태는 동기적으로 실행되지만, 결과는 비동기처럼 반영되며, 이 모든 구조는 배칭과 렌더링 스케줄링 덕분이다.

 

✨ 마무리 포인트 요약

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

  const handleClick = () => {
    setCount(count + 1);
    setCount(count + 1);
    console.log("clicked!", count); // ✅ 여기서는 여전히 이전 count 값
  };

  useEffect(() => {
    console.log("effect!", count); // ✅ 여기는 업데이트된 값
  }, [count]);

  return <button onClick={handleClick}>Click</button>;
}

 

 

• 위처럼 업데이트 되는 순간은 이벤트핸들러가 다 실행되었을 때이다.
• 그래서 언제 업데이트가 되는걸까 ?

 

트리거	상태 업데이트가 실제로 반영되나?	비고
React 이벤트 핸들러	✅ Yes	렌더링 트리거됨 (배칭 적용)
useEffect 내부	✅ Yes	사이드 이펙트 후 상태 반영 가능
Promise.then / setTimeout	✅ Yes (React 18+)	자동 배칭 확장됨
단순 setState 호출 후 console.log	❌ No	아직 렌더링 안 됨

 

📌 다음에 다룰 내용

• useEffect안에 fetch와 같은 비동기 함수가 있을때랑 동기 내용만 있을때랑 또 이벤트 루프의 동작이 다르더라구요
• 그래서 다음 글은 useEffect에서 어떻게 흐름이 이어지는지 알아볼 예정입니다.

Reference

https://react.dev/

React

https://sckimynwa.medium.com/react-mount-system-deep-dive-sync-mode-c89c1ace14af

React Mount System Deep Dive (Sync Mode)