스케줄링 직관 — 우선순위, 배칭, yielding

React 의 scheduler 내부 안 알아도 잘 씀. 다만 '고우선순위' 와 '저우선순위' 가 실제로 뭘 의미하는지 모델 필요 — 안 그러면 hook 들이 그냥 magic 처럼 느껴짐.

우선순위 세 레벨 (mental model)

동기 / 긴급 — input 이벤트, controlled-input 업데이트, 클릭 응답. 즉시 렌더. 사용자가 같은 tick 에 변경 봄.
Transition / 비긴급 — startTransition 안의 모든 것. React 가 메인 스레드 안 막고 렌더; 브라우저 반응 유지.
Suspense / async — suspend 하는 모든 것. React 가 promise 기다림, 이전 컨텐츠 (transition 으로) 또는 fallback (없이) 보이게 유지.

우선순위 수동으로 안 고름 — hook 고름 (useState 만, startTransition, use + Suspense), 우선순위 따라옴.

배칭

React 19 가 같은 이벤트 핸들러, async 함수, 콜백 안의 모든 state 업데이트 배칭. 클릭 핸들러의 setA(1); setB(2); 가 렌더 하나 트리거. 자동 — 흔한 케이스에 flushSync 필요 없음.

Yielding

Transition 렌더 중 React 가 주기적으로 브라우저에 yield. 사용자가 타이핑하거나 클릭하면 React 가 긴급 이벤트 먼저 처리, 그 다음 transition 재개. 무거운 렌더 중 앱이 반응 유지하는 이유.

본인 코드에 의미하는 것

대부분의 시간: 아무것도. React 가 처리. 중요한 자리:

무거운 state 업데이트는 useTransition 으로 표시 (lesson 1).
본인 소유 아닌 prop 엔 useDeferredValue (lesson 2).
도움 되는 자리에 memoize 하는 React Compiler (다음 lesson) 신뢰.
flushSync 손이 안 감 — 2026년에 거의 옳은 답 아님.

스케줄링은 React 일, semantic 은 본인 일. 본인이 의미 말함 (이 업데이트 긴급, 저거 아님); React 가 실제 paint 시점 결정. 타이밍 수동 제어 시도가 scheduler 사용 대신 싸움.

Code

배칭이 실전에 어떻게 보이는지·tsx

function MultiState() {
  const [a, setA] = useState(0);
  const [b, setB] = useState(0);
  const [c, setC] = useState(0);

  function onClick() {
    // 셋 다 한 렌더로 배칭 — React 19 자동.
    setA((x) => x + 1);
    setB((x) => x + 1);
    setC((x) => x + 1);
  }

  console.log("Render"); // 클릭당 한 번 로그, 세 번 아님
  return <button onClick={onClick}>Click ({a + b + c})</button>;
}

Exercise

useState 호출 셋 가진 컴포넌트 빌드. 클릭 핸들러에서 setter 셋 다 호출 + 컴포넌트 body 에 console.log('render') 추가. 한 번 클릭하고 로그 하나만 나타나는지 (배칭) 확인. 그 다음 setter 둘 사이에 flushSync 로 배칭 깸 — 로그 둘 관찰. 배칭 복원 + 얼마나 자연스럽게 느껴지는지 알아챔.

Hint

flushSync 는 react-dom 에서 import. 추가 렌더 보이면 왜 배칭이 디폴트이고 flushSync 가 예외인지 이해함.

스케줄링 직관 — 우선순위, 배칭, yielding

우선순위 세 레벨 (mental model)

배칭

Yielding

본인 코드에 의미하는 것

Code

External links

Exercise

Progress

댓글 0