React Developer Tools 사용법

React 성능 최적화 기초에서 가장 먼저 필요한 역량은 성능 문제를 정확히 측정하고 원인을 분리하는 것입니다.

감으로 최적화를 시작하면 코드 복잡도만 늘고 실제 병목은 그대로 남는 경우가 많습니다.

이번 절에서는 성능 분석의 출발점인 React Developer Tools를 설치하고, Components/Profiler 탭으로 문제를 진단하는 기본 루틴을 정리합니다.

React Developer Tools란?

React Developer Tools는 Meta가 제공하는 공식 브라우저 확장 도구입니다.

리액트 애플리케이션의 컴포넌트 트리, 상태/프롭스 변화, 렌더링 비용을 시각적으로 확인할 수 있습니다.

이 도구의 핵심 가치는 다음과 같습니다.

• 컴포넌트 계층 구조를 실제 렌더링 기준으로 추적할 수 있음
• props, state, hooks 값을 런타임 시점에 확인할 수 있음
• 어떤 컴포넌트가 얼마나 자주, 얼마나 오래 렌더링되는지 측정할 수 있음

설치와 활성화 확인

설치가 완료되어도 비리액트 페이지에서는 해당 탭이 비활성화될 수 있습니다.

반드시 리액트 앱이 실행 중인 페이지에서 확인하세요.

Components 탭으로 상태 흐름 확인

Components 탭은 현재 화면을 구성하는 리액트 컴포넌트 트리를 보여줍니다.

여기서 얻는 정보는 단순 구조 확인을 넘어 디버깅의 출발점이 됩니다.

기본 점검 절차

실무에서 자주 보는 패턴

• props 드릴링 누수: 중간 컴포넌트에서 불필요한 props 전달이 반복되는지 확인
• 상태 위치 오류: 전역으로 둘 필요 없는 상태가 상위에 있어 리렌더링 범위가 커지는지 확인
• 참조 타입 재생성: 객체/함수 props가 렌더링할 때마다 새로 만들어지는지 확인

Profiler 탭으로 렌더링 비용 측정

Profiler 탭은 어떤 상호작용에서 렌더링 비용이 발생했는지 시간 기준으로 보여줍니다.

성능 최적화는 반드시 이 측정 결과를 기준으로 진행해야 합니다.

측정 절차

결과 해석 포인트

• Commit Duration: 해당 커밋에 참여한 컴포넌트의 React 렌더링 비용. 네트워크·브라우저 레이아웃·페인트를 포함한 사용자 대기 시간 전체와는 구분합니다.
• 렌더링 횟수: 상호작용 대비 불필요하게 자주 렌더링되는 컴포넌트 존재 여부
• 상위 컴포넌트 영향: 부모 상태 변경이 넓은 하위 트리를 함께 리렌더링시키는지 여부

흔한 오진 방지 체크

• 개발 모드 측정 결과만으로 결론 내리지 않습니다. 개발 모드는 검사용 오버헤드가 있어 실제 프로덕션과 차이가 큽니다. 프로덕션에서 React 프로파일링을 하려면 프로파일링 지원 빌드가 필요하며, 전체 상호작용 지연은 브라우저 Performance 도구로 함께 확인합니다.
• 한 번의 측정으로 확정하지 말고 동일 시나리오를 2~3회 반복해 평균 경향을 봅니다.
• 최적화 적용 전/후를 같은 시나리오로 비교해 효과를 수치로 확인합니다.

성능 분석 루틴 체크리스트

• 문제 동작을 재현 가능한 시나리오로 고정했는가
• Profiler로 병목 컴포넌트와 커밋 비용을 먼저 확인했는가
• 최적화 대상이 실제 병목인지 수치로 검증했는가
• 최적화 이후 동일 시나리오 재측정으로 개선 여부를 확인했는가

처음의 진단 루프처럼 한 가지 가설을 수정하고 같은 조건에서 비용과 기능을 다시 확인합니다.

React Developer Tools를 사용할 때는 Components 탭과 Profiler 탭의 역할을 섞지 않는 것이 중요합니다.

값의 출처는 Components에서 좁히고, 렌더링 비용은 Profiler에서 확인해야 원인과 증상을 분리할 수 있습니다.

예시

앞서 만든 React 프로젝트의 App.jsx를 다음 독립 예제로 바꾸세요. 검색 상태와 카운터 상태는 App이 소유하고, ResultList는 목록을 props로 받습니다. 성능 차이를 억지로 크게 만들기 위한 예제가 아니라, 어떤 값이 바뀌었고 무엇을 기록하는지 익히는 작은 앱입니다.

import { useState } from 'react';

const products = [
  { id: 1, name: 'Notebook' },
  { id: 2, name: 'Pen' },
];

function ResultList({ items }) {
  return <ul>{items.map(item => <li key={item.id}>{item.name}</li>)}</ul>;
}

export default function App() {
  const [query, setQuery] = useState('');
  const [count, setCount] = useState(0);
  const visible = products.filter(item =>
    item.name.toLowerCase().includes(query.toLowerCase())
  );
  return (
    <main>
      <label>검색어 <input value={query} onChange={event => setQuery(event.target.value)} /></label>
      <button onClick={() => setCount(value => value + 1)}>횟수: {count}</button>
      <ResultList items={visible} />
    </main>
  );
}

첫 화면에는 횟수 0과 두 상품이 보입니다. 검색어에 note를 입력하면 Notebook만 남고, 버튼을 한 번 클릭하면 횟수만 1이 됩니다. 이때 App의 query는 note, count는 1이고 ResultList의 items에는 id 1이 들어 있어야 합니다. Components에서 App의 Hook 값과 ResultList의 props를 나란히 확인하세요. 값을 읽는 동안 도구로 상태를 직접 편집하지 않아야 같은 사용자 동작을 재현할 수 있습니다.

이제 검색어를 비우고 카운터를 0으로 초기화하려면 페이지를 새로 고칩니다. Profiler 기록을 시작한 뒤 버튼만 세 번 클릭하고 멈춥니다. 검색 결과는 계속 두 상품이고 카운터는 3인지 먼저 확인한 다음, 기록된 커밋과 렌더링된 범위를 관찰하세요. 클릭 수와 커밋 수를 무조건 같다고 가정하거나, 이 작은 예제의 시간 차이를 곧바로 병목이라고 단정하지 않습니다. 개발 모드·React Compiler 사용 여부·도구 설정도 전후 기록에 함께 남깁니다.

측정에서 바로 결론을 내릴 수 있는가?

다음 숫자는 실제 이 예제를 실행해 얻은 결과가 아니라, 해석을 연습하기 위한 가정입니다. 같은 빌드·데이터·동작에서 React 렌더링 비용이 세 번 각각 12·14·10ms였고, 변경 뒤에는 3·4·5ms였습니다. 두 평균과 줄어든 렌더링 비용을 계산하세요. 별도로 측정한 전체 상호작용 시간은 전후 모두 200ms였다면, 사용자 대기 시간도 같은 만큼 줄었다고 말할 수 있을까요?

독립 동작에서는 페이지를 새로 고친 뒤 pen을 입력하고 버튼을 두 번 클릭합니다. App의 두 상태와 ResultList가 받는 상품을 예상하고, Components와 Profiler 중 어떤 도구로 각각 확인할지 적으세요.

설치 경로는 React Developer Tools 공식 안내, 렌더링 측정의 범위와 프로덕션 프로파일링 조건은 Profiler 공식 설명을 확인할 수 있습니다. 프로그램의 Profiler 컴포넌트와 확장 도구의 Profiler 탭은 같은 이름의 서로 다른 사용 경로입니다.

요약 및 다음 절

React Developer Tools의 핵심은 컴포넌트 구조 확인(Components) + 렌더링 비용 측정(Profiler)의 조합입니다.

이 두 도구를 기반으로 진단하면 최적화를 어디에 적용해야 하는지 우선순위를 명확히 잡을 수 있습니다.

다음 절에서는 이 진단 결과를 바탕으로, 불필요한 리렌더링이 발생하는 대표 패턴과 방지 방법을 구체적으로 다룹니다.