useTransition / useDeferredValue

처음 React 성능 최적화를 할 때는 대부분 이런 방향으로 접근했다.

memo
useMemo
useCallback

물론 중요하다.

그런데 실제 서비스를 운영하다 보면 단순 memoization만으로 해결되지 않는 문제가 있었다.

특히

검색창 입력
대량 리스트 필터링
차트 렌더링
탭 전환
dashboard UI

같이 “입력은 즉시 반응해야 하지만 뒤쪽 렌더링은 무거운” 경우다.

예를 들어 검색창이 있다고 하자.

사용자 입력
→ 5000개 리스트 filter
→ 렌더링

처음에는 그냥

setQuery(e.target.value);

만 사용했다.

근데 리스트가 커질수록 입력이 버벅이기 시작했다.

특히 느린 환경에서는

타이핑 지연
입력 씹힘
UI 멈춤

이 발생했다. 그때 처음 느꼈다.

“모든 업데이트가 같은 우선순위일 필요는 없구나”

React 18의 concurrent rendering과 함께 나온

useTransition
useDeferredValue

는 바로 이 문제를 해결하기 위한 hook이다.

핵심 아이디어는 하나다.

급한 UI 먼저
덜 급한 UI 나중

왜 UI가 버벅였을까

이걸 이해하려면 먼저 React 렌더링을 봐야 한다.

예를 들어 검색창 입력 시

setQuery(value);

실행하면 React는

state update
filter 계산
리스트 렌더링

전부 한 흐름으로 처리한다.

문제는 리스트 렌더링이 무거운 경우다.

입력 이벤트
→ React render 시작
→ 5000개 리스트 계산
→ DOM 업데이트
→ input 반영

즉 사용자가 체감하는 건

"왜 입력이 느리지?"

다.

실제로는 input 자체가 느린 게 아니라,
뒤쪽 무거운 렌더링 때문에 메인 스레드가 막히는 경우가 많았다.

React 18 이후 바뀐 관점

예전 React는

업데이트 = 동기 처리

느낌이 강했다.

근데 concurrent rendering 이후에는

업데이트 우선순위를 나눌 수 있게 됐다.

즉

urgent update
transition update

를 구분한다.

예를 들어

input typing
button click feedback

는 urgent하다.

반면

대량 리스트 렌더링
검색 결과 계산
chart redraw

는 조금 늦어도 된다.

이걸 React에게 알려주는 게 useTransition이다.

useTransition

const [isPending, startTransition] = useTransition();

핵심은

startTransition(() => {
  ...
});

이다.

이 안의 state update를 React에게

"이건 급하지 않음"

이라고 알려준다.

검색 필터링

const [query, setQuery] = useState('');

const filteredItems = items.filter((item) =>
  item.includes(query)
);

useTransition 적용

const [query, setQuery] = useState('');
const [filter, setFilter] = useState('');

const [isPending, startTransition] = useTransition();

const filteredItems = useMemo(() => {
  return items.filter((item) =>
    item.includes(filter)
  );
}, [items, filter]);

<input
  value={query}
  onChange={(e) => {
    const value = e.target.value;

    setQuery(value);

    startTransition(() => {
      setFilter(value);
    });
  }}
/>

여기서 중요한 건

setQuery(value);

는 urgent update.

setFilter(value);

는 transition update라는 점이다.

즉:

input은 즉시 반응
무거운 리스트 렌더링은 나중 처리

된다.

실제로 체감됐던 부분

특히 모바일 환경에서 차이가 컸다.

Before

입력 시 키보드 버벅임
타이핑 밀림

After

입력은 즉시 반응
리스트는 약간 늦게 갱신

사용자 입장에서는 훨씬 부드럽게 느껴졌다.

중요한 건
리스트가 조금 늦게 바뀌는 건 대부분 참을 수 있다는 점이었다.

반면 입력이 밀리면 바로 느리다고 느낀다.

isPending의 의미

const [isPending] = useTransition();

이걸 loading state 처럼 생각하기 쉽다.

근데 핵심은 우선순위 분리다.

isPending은 결과적으로 transition 작업이 아직 끝나지 않았다는 상태일 뿐이다.

useDeferredValue

처음엔

useTransition
useDeferredValue

차이가 굉장히 헷갈렸다.

근데 핵심은 이렇다.

useTransition
→ 업데이트 자체를 지연

useDeferredValue
→ 값 반영을 지연

useDeferredValue 기본 구조

const [query, setQuery] = useState('');
const deferredQuery = useDeferredValue(query);

여기서

query
→ 즉시 변경

deferredQuery
→ 늦게 따라옴

구조가 된다.

예를 들어 이미 이런 코드가 있었다.

const filteredItems = useMemo(() => {
  return items.filter((item) =>
    item.includes(query)
  );
}, [items, query]);

이걸 useTransition 구조로 바꾸려면:

state 분리
transition 적용

코드 수정이 꽤 들어간다.

반면 useDeferredValue는

const deferredQuery = useDeferredValue(query);

const filteredItems = useMemo(() => {
  return items.filter((item) =>
    item.includes(deferredQuery)
  );
}, [items, deferredQuery]);

정도만 바꾸면 된다.

즉:

기존 구조 유지 가능
최소 수정으로 최적화 가능

장점이 있다.

useDeferredValue를 더 자주 쓴 경우

기존 코드 변경 최소화
값 하나만 늦추면 되는 경우

에서는 useDeferredValue가 편했다.

chart filtering
search highlighting
markdown preview

“값 기반 무거운 계산” 이 있는 경우 잘 맞았다.

pending 체크

useDeferredValue는 pending state를 직접 주지 않는다.

보통 이렇게 비교한다.

const isUpdating = query !== deferredQuery;

즉:

query는 최신값
deferredQuery는 이전값

이면 아직 업데이트 중이라는 뜻이다.

주의점

1. 비동기 fetch를 대신하는 게 아니다

많이 헷갈린다.

startTransition(async () => {
  await fetch(...)
});

이걸:

async scheduler
처럼 생각하면 안 된다.

react render priority 조정이다.

fetch 자체는 여전히 직접 관리해야 한다.

2. 작은 리스트에서는 필요 없다

이것도 중요하다.

예를 들어

아이템 20개
렌더링 가벼움

이면 오히려

코드 복잡도 증가
mental overhead 증가

가 더 크다.

실제로는

profiling
flame chart
interaction delay

를 보고 적용해야 했다.

3. 모든 버벅임을 해결하진 않는다

예를 들어:

hugeCalculation();

같은 CPU-heavy synchronous 작업은 여전히 메인 스레드를 막는다.

이런 경우는

Web Worker
virtualization
algorithm optimization

이 필요하다.

탭 전환에서도 유용했다

예를 들어 dashboard 탭.

Analytics
Users
Payments
Logs

탭 클릭 시

chart render
table render

가 무거웠다.

처음엔:

탭 클릭
→ UI 멈춤

느낌이었다.

useTransition 적용

startTransition(() => {
  setSelectedTab(tab);
});

이후

버튼 클릭 반응은 즉시
무거운 화면 렌더링은 transition

구조가 됐다.

실제 UX가 꽤 좋아졌다.

App Router와도 연결된다

App Router에서도

route transition
suspense boundary

와 연결된다.

특히

navigation pending UI
streaming

철학 자체가 비슷하다.

핵심은

"당장 필요한 UI"
vs
"조금 늦어도 되는 UI"

를 나누는 것이다.

선택 기준

useTransition

사용 시점:

특정 state update 자체를 낮은 우선순위로 처리하고 싶을 때

예:

탭 전환
route transition
무거운 리스트 업데이트

useDeferredValue

사용 시점:

값 하나만 늦춰도 되는 경우
기존 코드 구조를 크게 바꾸기 싫은 경우

예:

검색 query
chart filter
markdown preview

useTransition , useDeferredValue