React 화면이 느려졌다면 memo보다 먼저 렌더 원인부터 좁히세요

AI가 만든 React 화면이 처음에는 잘 움직이다가 검색창, 필터, 목록, 카드 정렬을 붙인 뒤 갑자기 버벅일 때가 있습니다. 이때 초보자는 보통 두 가지 요청 중 하나를 AI에게 던집니다. "전체를 빠르게 고쳐줘" 또는 "memo 넣어줘"입니다. 둘 다 너무 넓습니다.

먼저 결론부터 잡겠습니다. 느린 React 화면의 첫 행동은 최적화 코드를 붙이는 것이 아니라 느린 동작 하나를 증거로 남기는 것입니다. react.dev의 React Developer Tools 문서는 이 도구가 컴포넌트를 살펴보고 성능 문제를 찾는 데 쓰인다고 설명합니다. developer.chrome.com의 Performance 패널 문서도 실행 중인 화면의 반응, 애니메이션, idle 구간을 분석하는 도구라고 안내합니다. 그러니 오늘 목표는 "성능을 완벽히 고치기"가 아닙니다. AI가 고칠 범위를 한 컴포넌트나 한 계산으로 줄이는 것입니다.

Tap to zoom

먼저 느린 동작을 하나만 고릅니다

성능 문제를 AI에게 맡길 때 가장 흔한 실패는 증상이 너무 넓은 것입니다.

화면이 느려요. 최적화해 주세요.

이 문장은 AI가 파일 전체를 뒤지고, 상태 구조를 바꾸고, memo, useMemo, useCallback을 한꺼번에 붙이게 만들기 쉽습니다. 먼저 느린 동작을 하나만 고릅니다.

검색창에 한 글자를 입력할 때마다 목록 화면이 0.5초 정도 멈춥니다.
필터 버튼을 누른 직후 카드 80개가 다시 그려지는 것 같습니다.
정렬 옵션을 바꿀 때 입력창 커서도 같이 끊깁니다.

이렇게 쓰면 문제는 "앱 전체가 느림"에서 "검색 입력 한 번", "필터 클릭 한 번", "정렬 변경 한 번"으로 줄어듭니다. React select가 안 바뀔 때 value부터 보는 순서와 원리가 같습니다. 화면 전체를 갈아엎기 전에, 멈춘 지점을 먼저 찾습니다.

Profiler에서 오래 걸린 컴포넌트를 봅니다

React 쪽이 의심되면 React Developer Tools의 Profiler를 봅니다. React 공식 <Profiler> 문서는 렌더링 성능을 측정할 수 있고, 대화형 프로파일링은 React Developer Tools의 Profiler 탭을 쓰라고 안내합니다.

초보자에게 필요한 확인은 세 가지입니다.

여기서 중요한 점은 "느린 컴포넌트 이름"을 얻는 것입니다. App 전체가 느리다고 말하면 AI는 구조 전체를 바꾸기 쉽습니다. ProductList, ResultCard, FilterPanel처럼 이름을 좁히면 수정 범위도 줄어듭니다.

Tap to zoom

memo는 원인을 본 뒤에 붙입니다

React 공식 memo 문서는 props가 바뀌지 않았을 때 컴포넌트 재렌더링을 건너뛸 수 있게 하는 최적화라고 설명합니다. 이 말은 반대로, props가 매번 바뀌면 memo만 붙여도 기대만큼 줄지 않을 수 있다는 뜻입니다.

아래 코드를 봅니다.

function ProductPage({ products }) {
  const visibleProducts = products.filter((item) => item.inStock);

  return <ProductList items={visibleProducts} />;
}

겉으로는 products가 같아도 filter 결과 배열은 렌더마다 새로 만들어집니다. 이 상태에서 ProductList에 memo만 붙이면 "props가 같다"고 판단하기 어렵습니다. 이때는 useMemo로 계산 결과를 캐시할지, 목록을 더 작게 나눌지, 필터 계산을 이벤트 뒤로 미룰지 먼저 판단해야 합니다.

const visibleProducts = useMemo(
  () => products.filter((item) => item.inStock),
  [products]
);

React 공식 useMemo 문서는 의존성이 바뀌지 않는 동안 계산 결과를 캐시한다고 설명합니다. 하지만 이것도 만능 버튼은 아닙니다. 계산이 가볍거나 의존성이 매번 바뀌면 효과가 작습니다. memoization은 원인 확인 뒤에 쓰는 도구이지, 느린 화면에 무조건 붙이는 처방이 아닙니다.

함수 props가 계속 바뀌는지도 봅니다

느린 목록에서 자주 나오는 다른 원인은 함수 props입니다.

function ProductPage({ products }) {
  return (
    <ProductList
      items={products}
      onSelect={(id) => console.log(id)}
    />
  );
}

onSelect 함수가 렌더마다 새로 만들어지면, 자식 컴포넌트 입장에서는 props가 바뀐 것처럼 보일 수 있습니다. React 공식 useCallback 문서는 렌더 사이에 함수 정의를 캐시하는 Hook이라고 설명합니다. 다만 React 문서도 최신 React Compiler가 지원되는 환경에서는 수동 useCallback 필요를 줄일 수 있다고 안내합니다. 따라서 초보자가 기억할 문장은 하나입니다. 함수 props가 병목이라는 증거가 있을 때만 useCallback을 후보로 올립니다.

const handleSelect = useCallback((id: string) => {
  console.log(id);
}, []);

return <ProductList items={products} onSelect={handleSelect} />;

이 코드는 "항상 빠르게 만드는 코드"가 아닙니다. 자식이 memoized 되어 있고, 함수 props 때문에 렌더가 반복된다는 증거가 있을 때 의미가 있습니다.

Chrome Performance는 브라우저 전체 지연을 볼 때 씁니다

React Profiler가 컴포넌트 렌더를 보는 도구라면, Chrome DevTools Performance 패널은 브라우저가 실제로 어디서 시간을 쓰는지 보는 도구입니다. 입력이 늦게 반응하는지, 스크롤이 끊기는지, 클릭 후 긴 작업이 있는지 볼 때 유용합니다.

초보자는 긴 기록을 전부 해석하려고 하지 않아도 됩니다. 다음 네 줄만 적으면 AI에게 줄 증거가 됩니다.

느린 동작: 검색창에 "a" 입력
보이는 증상: 입력 후 목록 갱신까지 잠깐 멈춤
의심 구간: 긴 JavaScript 작업 또는 ProductList 렌더
바꾸지 말 것: API 호출 방식과 디자인 구조

이 정도면 AI에게 "성능 최적화해줘"보다 훨씬 안전하게 요청할 수 있습니다. AI가 파일을 너무 많이 고칠 때 범위를 막는 프롬프트에서 다룬 것처럼, 좋은 요청은 AI가 더 많은 일을 하게 만드는 문장이 아니라 건드릴 범위를 줄이는 문장입니다.

AI에게는 증거와 금지 범위를 같이 줍니다

이제 AI에게 붙일 문장을 만듭니다.

Tap to zoom

React 화면이 느려졌습니다. 전체 재작성은 하지 말고 원인 확인과 최소 수정만 제안해 주세요.

느린 동작:
[예: 검색창에 한 글자 입력할 때 목록 갱신이 늦습니다]

측정/관찰:
[예: React Profiler에서 ProductList가 입력마다 다시 렌더됩니다]

의심 코드:
[ProductPage, ProductList 관련 코드만 붙여 넣기]

확인해 주세요:
1. 무거운 계산이 렌더마다 반복되는지
2. 배열이나 객체 props가 매번 새로 만들어지는지
3. 함수 props 때문에 자식이 다시 렌더되는지
4. memo, useMemo, useCallback 중 필요한 것이 있는지
5. 바꾸는 파일과 줄을 최소화할 수 있는지

바꾸지 말 것:
[디자인, API 호출, 라우팅, 데이터 구조 등 유지할 것]

이 프롬프트의 핵심은 memo를 요구하지 않는다는 점입니다. 대신 AI에게 원인을 분류하게 합니다. 긴 계산이면 useMemo가 후보가 될 수 있고, 함수 props가 문제면 useCallback이 후보가 될 수 있고, 목록이 너무 크면 페이지네이션이나 가상화 같은 다른 접근이 필요할 수도 있습니다. 도구 이름보다 먼저 병목 종류를 고르는 것이 순서입니다.

오늘은 네 줄만 채우고 다시 묻습니다

느린 React 화면을 만났을 때 오늘 바로 할 일은 아래 네 줄입니다.

느린 동작:
오래 걸린 컴포넌트:
반복되는 계산 또는 새 props:
AI가 건드리지 말아야 할 범위:

이 네 줄이 비어 있으면 AI는 추측으로 고칩니다. 네 줄이 채워지면 수정 범위가 줄어듭니다. 코딩사관학교 초보자라면 오늘은 한 가지만 기억하면 됩니다. 느린 화면의 첫 수정은 memo 추가가 아니라 원인 증거 만들기입니다.

참고 출처

• React Docs, React Developer Tools: https://react.dev/learn/react-developer-tools
• React Docs, <Profiler>: https://react.dev/reference/react/Profiler
• React Docs, memo: https://react.dev/reference/react/memo
• React Docs, useMemo: https://react.dev/reference/react/useMemo
• React Docs, useCallback: https://react.dev/reference/react/useCallback
• Chrome for Developers, Analyze runtime performance: https://developer.chrome.com/docs/devtools/performance

이 글은 AI 코딩과 개발 학습의 일반 정보 제공 목적입니다. 도구, 모델, 커리큘럼, 요금은 버전과 시점에 따라 달라질 수 있으므로 실습이나 도입 전 공식 문서와 최신 릴리스 노트를 확인하세요.