React 18: useDeferredValue를 통한 입력창 무겁고 버벅이는 타자 현상 교정

React 18 useDeferredValue로 입력창 타자 밀림 현상 해결하기
3초 요약: 이렇게 고치세요
  • 원인: 입력값이 바뀔 때마다 무거운 리스트 렌더링이 같은 우선순위로 동기 처리되면서 메인 스레드를 붙잡음
  • 해결: 입력 자체는 즉시 반영하고 무거운 렌더링만 뒤로 미루고 싶을 때 → useDeferredValue / 하위 트리가 실제로 무거우면 React.memo도 같이 적용
  • 주의: 렌더링 자체를 빠르게 만들어주는 훅이 아니라 우선순위만 미루는 것 — 계산량이 줄지 않으면 체감 효과가 약할 수 있음
const deferredText = useDeferredValue(text);
<HeavyList query={deferredText} />
↓ 왜 이런 문제가 생기는지 원리 보기

대량의 리스트를 필터링하는 검색창에 타자를 치면 입력창 자체가 버벅이면서 글자가 밀리는 경우가 있습니다. 원인은 입력값이 바뀔 때마다 무거운 리스트 렌더링이 같은 우선순위로 동기 처리되면서 브라우저 메인 스레드를 잠깐 붙잡기 때문인데, React 18의 useDeferredValue는 이 렌더링의 우선순위만 뒤로 미뤄서 입력 반응성을 지켜주는 훅입니다.

입력창 타자 밀림 현상이 발생하는 구조적 원인

일반적인 React 앱에서 입력창의 상태(state)와 화면에 뿌려지는 리스트 데이터가 동일한 입력 흐름에 묶여 있을 때, 유저가 키보드를 입력하면 다음과 같은 현상이 순차적으로 일어납니다.

  1. 사용자가 텍스트 입력 (키 입력 이벤트 발생)
  2. onChange 핸들러가 트리거되며 상태 변경 (setState)
  3. [동기적 리렌더링] 입력값을 가공해야 하는 하위의 무거운 리스트 컴포넌트가 같은 우선순위로 곧바로 다시 렌더링을 시작
  4. 이 과정에서 브라우저의 싱글 스레드(Main Thread)가 렌더링 계산에 묶여버림
  5. 브라우저가 다음 키 입력을 즉각 화면에 반영(Paint)하지 못하고 프레임 드랍(Frame Drop) 발생

몇 년 전 외주로 맡았던 프로젝트 중에 수천 건의 상품 데이터를 다루는 필터링 화면이 있었습니다. 검색어를 입력할 때마다 화면이 순간적으로 멈칫거린다는 얘기를 듣고, 처음엔 리스트 쪽 key 값이 잘못됐거나 불필요한 리렌더링이 도는 줄 알고 React.memo부터 여기저기 붙여봤는데 큰 차이가 없었습니다. 나중에 크롬 개발자 도구 성능 탭으로 프레임을 찍어보고 나서야, 문제는 리렌더링 횟수가 아니라 입력값 갱신과 리스트 렌더링이 같은 우선순위로 동기 처리되고 있다는 데 있다는 걸 알았습니다. 디바운스로 우선 급한 불은 껐지만 타자가 빠른 사용자한테는 여전히 살짝 밀리는 느낌이 남아 있었는데, 이후 유지보수를 이어가다가 React 18로 올리는 김에 useDeferredValue로 바꾸고 나서야 입력 자체가 걸리는 느낌이 사라졌습니다.

useDeferredValue의 동작 원리와 특징

useDeferredValue는 값의 업데이트 우선순위를 낮춰 브라우저가 사용자 입력을 먼저 처리할 수 있도록 돕는 훅입니다.

  • 우선순위 분리: 텍스트 입력처럼 즉각적인 피드백이 필요한 '긴급(Urgent) 업데이트'는 먼저 처리하고, 데이터 필터링·렌더링처럼 시간이 걸리는 작업은 백그라운드에서 나중에 처리합니다.
  • 중단 가능한 렌더링: 지연된 값을 렌더링하는 도중에 사용자가 새로운 키보드 입력을 하면, React는 진행 중이던 렌더링 작업을 그대로 버리고 새 입력을 먼저 처리합니다.
  • 별도 타이머 불필요: lodash의 debounce 같은 외부 라이브러리나 setTimeout 없이 리액트 내장 스케줄러로 처리됩니다.

useDeferredValue 실전 코드 예제

아래 예제는 입력창 타자 지연을 해결하기 위해 useDeferredValue를 적용한 구현입니다. 지연 렌더링이 진행 중일 때 리스트를 살짝 흐리게 표시해서, 화면이 최신 입력을 아직 못 따라간 상태라는 걸 사용자에게 알려주는 패턴도 함께 넣었습니다. 

import { useState, useDeferredValue, useMemo } from 'react';

// 성능 부하가 예상되는 무거운 리스트 컴포넌트
function HeavyList({ query }) {
  const items = useMemo(() => {
    const list = [];
    // 5,000개의 무거운 아이템 시뮬레이션
    for (let i = 0; i < 5000; i++) {
      if (i.toString().includes(query) || query === '') {
        list.push(<li key={i}>검색 아이템 #{i} (매칭어: {query})</li>);
      }
    }
    return list;
  }, [query]);

  return <ul>{items}</ul>;
}

export default function App() {
  const [text, setText] = useState('');

  // 1. 입력 상태 값의 지연 버전 생성
  const deferredText = useDeferredValue(text);

  // 2. 최신 입력을 아직 못 따라간 상태인지 판별
  const isStale = text !== deferredText;

  return (
    <div style={{ padding: '20px', maxWidth: '600px', margin: '0 auto' }}>
      <h3>useDeferredValue 데모</h3>

      {/* 3. 입력창은 지연되지 않은 기존 text 상태와 바인딩 */}
      <input
        type="text"
        value={text}
        onChange={(e) => setText(e.target.value)}
        placeholder="검색어를 입력해보세요..."
        style={{
          padding: '10px 14px',
          width: '100%',
          fontSize: '16px',
          borderRadius: '6px',
          border: '1px solid #ccc',
          boxSizing: 'border-box'
        }}
      />

      {/* 4. 지연 중일 때는 살짝 흐리게 표시해 갱신 대기 상태임을 알려줌 */}
      <div style={{ opacity: isStale ? 0.5 : 1, transition: 'opacity 0.2s' }}>
        <HeavyList query={deferredText} />
      </div>
    </div>
  );
}

코드 동작 해설

deferredText는 text가 바뀔 때 곧바로 갱신되지 않고, React가 우선순위가 낮은 렌더링 단계에서 뒤늦게 반영합니다. 그 사이 text와 deferredText가 서로 다른 값을 가리키는 순간이 생기는데, 이 차이를 isStale로 판별해서 리스트를 흐리게 보여주면 사용자는 "지금 갱신 중이구나"를 자연스럽게 인지할 수 있습니다.

참고로 useDeferredValue는 아래쪽 렌더링을 더 빠르게 만들어주는 훅이 아니라, "언제 그 렌더링을 실행할지" 우선순위만 뒤로 미루는 훅입니다. 하위 컴포넌트가 실제로 무겁다면 React.memo로 감싸서 props가 그대로일 때 리렌더 자체를 건너뛰게 해줘야 체감 효과가 확실합니다. 위 예제의 HeavyList는 useMemo로 계산 결과를 이미 캐싱해 두었기 때문에 그것만으로 충분하지만, 컴포넌트 트리가 더 복잡해지는 경우라면 memo도 같이 고려하는 게 안전합니다.

입력 최적화 기법 비교

프로젝트 규모와 성격에 따라 골라 쓸 수 있는 방법을 정리했습니다.

구분 디바운스 (Debounce) 쓰로틀 (Throttle) useDeferredValue (React 18)
작동 원리 특정 시간 동안 입력이 없을 때 한 번 실행 설정한 주기마다 최소 한 번 렌더링 실행 React 스케줄러가 우선순위에 따라 렌더링 시점을 조정
사용자 경험 입력이 멈출 때까지 결과 화면이 갱신되지 않음 일정 주기로 화면이 끊기듯 갱신됨 입력창은 항상 즉시 반응하고, 결과는 뒤이어 갱신
기기 성능 대응 고정 지연 시간(예: 300ms)으로 하드코딩 기기 사양과 무관하게 고정된 주기 저사양 기기일수록 렌더링 자체가 오래 걸려 지연이 더 길게 체감됨
구현 방식 외부 라이브러리(lodash) 또는 커스텀 훅 필요 외부 라이브러리 또는 useRef 기반 구현 필요 React 내장 훅 한 줄로 적용 (단, 하위 트리가 무거우면 memo 병행 권장)
공식 참고 레퍼런스

React 18 useDeferredValue API 스펙과 동시성 렌더링에 대한 상세 내용은 공식 문서에서 확인할 수 있습니다.

호마다의 웹개발 팁

React 18 동시성 렌더링과 useDeferredValue를 좀 더 자세히 다룬 글은 [호마다의 IT 개발 입문 블로그] 에서 볼 수 있습니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

TypeScript: Unknown vs Any 타입 차이점과 안전한 타입 가드(Type Guard)

이미지
3초 요약: 이렇게 고치세요 원인: any 는 타입 검사 자체를 포기하는 선언이라, 잘못된 속성 접근이 컴파일 시점엔 통과했다가 런타임에 터짐 해결: 외부 API 응답처럼 타입을 확신할 수 없는 데이터는 unknown 으로 받고, data is T 형태의 타입 가드로 검증한 뒤에만 사용 주의: 타입 가드 내부에서 as Record<string, unknown> 같은 임시 캐스팅으로 속성을 하나씩 검사하는 절차를 생략하면 unknown 을 쓰는 의미가 없어짐 function isUserProfile(data: unknown): data is UserProfile { ... } ↓ 왜 any가 위험한지 원리 보기 실무에서 대규모 TypeScript 프로젝트를 마이그레이션하거나, 외부 API 또는 레거시 라이브러리를 통합하다 보면 필연적으로 "타입을 확신할 수 없는 데이터"를 다루게 됩니다. 이때 많은 개발자들이 급한 마음에 가장 손쉬운 탈출구인 any 를 사용하곤 합니다. 하지만 이는 TypeScript의 가장 큰 무기인 타입 안정성을 스스로 내려놓는 행위이자, 미래의 나에게 런타임 에러라는 시한폭탄을 던지는 것과 같습니다. any 가 왜 위험한지, TypeScript 3.0에서 도입된 unknown 이 이를 어떻게 막아주는지, 그리고 실무에서 바로 써먹을 수 있는 사용자 정의 타입 가드(User-Defined Type Guards) 작성 패턴을 정리합니다. any의 위험성과 unknown의 등장 프로덕션 환경에서 발생한 실제 에러 로그를 분석해 보면, 꽤 많은 비율이 TypeError: Cannot read properties of undefined 에서 시작합니다. 그리고 그 이면에는 높은 확률로 any 타입이 자리 잡고 있죠. any: 타입...
자세한 내용 보기

Next.js 하이드레이션 오류 원인과 해결법 완벽 정리

이미지
3초 요약: 이렇게 고치세요 원인: 서버가 렌더링한 초기 HTML과 브라우저가 처음 그린 HTML 구조가 서로 달라서 발생 — React는 둘이 같을 거라 믿고 결합을 시도하다가 실패함 해결: 잘못된 태그 중첩이면 마크업 수정 / window · localStorage 참조면 useEffect 로 이동 / 시간·랜덤값처럼 매번 달라지는 값이면 ssr: false 로 분리 주의: suppressHydrationWarning 은 경고를 숨길 뿐 원인을 고치는 게 아니라서, 불가피한 텍스트 불일치(타임스탬프 등)에만 제한적으로 써야 함 const [isMounted, setIsMounted] = useState(false); useEffect(() => setIsMounted(true), []); if (!isMounted) return null; // 서버와 첫 클라이언트 렌더는 항상 동일하게 ↓ 왜 이런 에러가 나는지 원리 보기 Next.js를 쓰다 보면 콘솔에 "Hydration failed because the initial UI does not match..."라는 붉은 에러가 뜰 때가 있습니다. 빌드는 멀쩡히 끝났는데 화면이 그려진 직후에 갑자기 나는 에러라서 처음 보면 당황스럽습니다. 원인은 대부분 서버와 클라이언트가 그린 첫 화면이 미묘하게 다르기 때문이고, 패턴이 정해져 있어서 하나씩 짚어보면 금방 잡힙니다. 하이드레이션(Hydration), 정확히 어떤 과정인가 Next.js의 핵심 기능은 서버 사이드 렌더링(SSR)입니다. 서버는 먼저 사용자에게 정적인 HTML 뼈대를 빠르게 그려서 브라우저에 내려보내 줍니다. 그 후, 브라우저(클라이언트)가 이 정적인 HTML 위에 React의 자바스크립트 코드와 이벤트 리스너를 결합하여 ...
자세한 내용 보기

Next.js App Router에서 getServerSideProps 대체 및 데이터 페칭법

이미지
3초 요약: 이렇게 고치세요 원인: App Router는 서버 컴포넌트에서 직접 async/await를 쓸 수 있어 getServerSideProps / getStaticProps 가 아예 없어짐 해결: 빌드 시 캐싱(SSG) → 기본 fetch / 매 요청 최신화(SSR) → { cache: 'no-store' } / 주기 갱신(ISR) → { next: { revalidate: N } } 주의: getServerSideProps 안에 있던 인증 체크 로직은 이제 컴포넌트 함수 내부나 미들웨어로 옮겨야 함 const res = await fetch(url, { cache: 'no-store' }); // SSR과 동일하게 매번 재요청 ↓ 왜 이런 에러가 나는지 원리 보기 Next.js 13 이상에서 App Router가 표준이 되면서, Pages Router에서 쓰던 getServerSideProps 와 getStaticProps 가 더 이상 동작하지 않습니다. 두 함수가 사라진 설계적 이유와, 이를 대체하는 데이터 패칭 방식을 정리했습니다. 왜 getServerSideProps와 getStaticProps가 사라졌을까 과거 Next.js는 페이지 컴포넌트 내부에서만 특정 정적 함수( getServerSideProps 등)를 실행하여 데이터를 미리 받아온 뒤, 이를 컴포넌트의 props 로 넘겨주는 복잡한 직렬화 구조를 가졌습니다. 이로 인해 컴포넌트 간 깊이가 깊어지면 'Props Drilling(프로퍼티 대물림)'이 심해져 코드 관리가 몹시 까다로웠습니다. App Router 환경에서는 서버 컴포넌트(Server Component)가 표준이 됨에 따라 컴포넌트 내에서 직접 비동기 함수(async/await)를 작성할 수 있게 되었습...
자세한 내용 보기