🎨 08. useRef: 렌더링을 피하는 비밀 금고

🎯 이 섹션을 읽고 나면:

• useRef가 단순히 <input> 창에 포커스를 맞추는 DOM 연결 도구가 아님을 알게 된다.
• 상태(useState)와 참조(useRef)의 본질적인 기술적 차이를 스냅샷 vs 영구 변수 멘탈 모델로 구분할 수 있다.
• 화면 업데이트 없이 불변하는 값을 은밀히 추적하고 싶을 때(타이머 ID 저장, 이전 상태 추적) useRef를 훌륭하게 설계할 수 있다.

📋 목차

• 🤔 왜 알아야 하는가: 요동치는 컴포넌트를 견디는 닻
• 🏗️ 비유로 먼저 이해하기
• 🧩 실전 무기화: 숨겨진 변수들 다루기
  • ✅ 영호의 완벽한 리팩토링: current 무기고 사용
• 💥 에러 해결 카탈로그
  • ❌ useRef 금고 안의 값을 화면에 노출시키는 사상누각

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 10분 / 핵심 파트: 7분

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 영철(신입): "타이머 스톱워치를 만들고 있는데요! 시작 버튼을 눌렀는데 중지 버튼을 누를 때 타이머가 안 멈추고 계속 가요! 인터벌 아이디(ID)를 useState에 담아뒀는데 뭐가 문제죠?"
• 영호(리드): "영철 님, 화면에 그 숫자 보여주실 건가요? 안 보여줄 변수라면 과도한 렌더링(useState) 터뜨리지 말고 조용히 뒷주머니(useRef)에 넣고 다니라고 예전에 말씀드렸을 텐데요."

🤔 왜 알아야 하는가: 요동치는 컴포넌트를 견디는 닻

대부분의 React 예제 문서를 보면 useRef를 처음 소개할 때 꼭 "DOM 조작(<input ref={myRef}>)을 위한 갈고리입니다~" 라고 가르쳐. 하지만 이건 useRef 능력치 중 빙산의 일각도 안 되는 10%의 부가 기능에 불과해.

🤔 잠깐, 먼저 생각해봐
스톱워치 코드를 짜려고 해. 타이머를 멈추려면 자바스크립트의 clearInterval(아이디고유번호)가 필요하지.
이 고유 번호를 렌더링 사이클이 돌아도 기억하려면 어디다 변수를 만들어야 할까?

// ❌ 영철이의 위험한 선택 (상태 오남용)
function Stopwatch() {
  const [seconds, setSeconds] = useState(0);
  const [timerId, setTimerId] = useState(null); // 🚨 화면에 그리지도 않을 건데 굳이 상태로 만듦!
 
  const handleStart = () => {
    const id = setInterval(() => setSeconds(s => s + 1), 1000);
    setTimerId(id); // 불필요하게 상태 갱신 발동! -> 무의미한 렌더링 1회 추가 발사!
  };
 
  const handleStop = () => {
    clearInterval(timerId);
  };
 
  return (
    <div>
      <p>경과 시간: {seconds}초</p>
      <button onClick={handleStart}>시작</button>
      <button onClick={handleStop}>멈춰!</button>
    </div>
  );
}

영철이 코드는 얼핏 문제가 없어 보여(구동은 되니까).
하지만 이건 불필요한 렌더링을 만드는 코드입니다. timerId는 화면 UI의 픽셀 단 하나도 바꾸지 않는데, 얘를 갱신한답시고 setTimerId(id)를 호출하는 순간 리액트는 상태 변경으로 보고 컴포넌트를 한 번 더 렌더링합니다.

우리에겐 "값을 안전하게 저장하되, 값이 바뀐다고 렌더링을 요청하지는 않는 비밀 창고" 가 필요합니다. 그리고 그게 바로 useRef의 본질입니다.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?

1. useState는 방송국 마이크야. 마이크에 대고 숫자를 바꾸면 온 동네 마을 사람들(컴포넌트들)이 다 리셋돼서 다시 들으러 광장으로 모이지(리렌더링 파티).

2. useRef는 네 바짓단 깊숙이 숨겨놓은 작은 금고 박스(current 속성) 야.
   네가 몰래 금고 문을 열고 current 공간 안에 돈을 100만 원으로 바꾸든 10원으로 쪼개든 동네 사람들은 아무도 모르고 아무 소리도 안 나(리렌더링 무시).
   하지만 컴포넌트가 여러 번 다시 렌더링되어도, 그 바짓단 속 금고 상자는 컴포넌트가 살아있는 기간 내내 영구적으로 보존되면서 절대 정보가 증발하지 않아.

✅ 핵심 원리:
React 공식 문서의 표현대로, useRef는 { current: initialValue } 형태의 같은 객체를 다음 렌더에서도 돌려준다. current는 직접 바꿀 수 있지만, 이 변경은 상태 변경 신호가 아니기 때문에 React가 다시 렌더링하지 않는다.

그래서 useRef는 렌더링 결과를 바꾸지 않는 값에 어울린다. 타이머 ID, 이전 스크롤 위치, DOM 노드처럼 이벤트 핸들러나 Effect에서 읽고 쓰는 값은 좋지만, 화면에 보여줄 값은 useState로 관리해야 한다.

🧩 실전 무기화: 숨겨진 변수들 다루기

✅ 영호의 완벽한 리팩토링: current 무기고 사용

1. UI(화면)에 그릴 내용은 -> 렌더링에 반응하는 useState 마이크에 담는다 (seconds)
2. 내부 로직 통제용(알람, 타이머 아이디, 드래그 스크롤 픽셀 이전 위치 등) 백그라운드 데이터는 -> 비밀 금고 useRef에 담아 몰래 관리한다 (timerRef)

// ✅ 우아한 고성능 렌더링 코드 (Pro Approach)
function Stopwatch() {
  const [seconds, setSeconds] = useState(0); // 화면 UI와 직결된 유일한 친구
  const timerRef = useRef(null); // 🎯 리렌더링 감시 면제권 발급!
 
  const handleStart = () => {
    if (timerRef.current) return; // 이미 돌고 있으면 방어!
 
    // 이 값을 갱신해도 리액트는 눈도 깜짝 안 합니다. 불필요한 렌더링 0회 달성.
    timerRef.current = setInterval(() => setSeconds(s => s + 1), 1000);
  };
 
  const handleStop = () => {
    clearInterval(timerRef.current);
    timerRef.current = null; // 초기화
  };
 
  return (
    <div>
      <p>경과 시간: {seconds}초</p>
      <button onClick={handleStart}>시작</button>
      <button onClick={handleStop}>멈춰!</button>
    </div>
  );
}

깔끔합니다. setTimerId(id)로 렌더링을 한 번 더 만들 필요가 없어졌어.
timerRef.current = ... 할당문은 React에게 렌더링을 요청하지 않으므로, 타이머 제어 값처럼 UI와 직접 연결되지 않은 데이터에 적합합니다.

💥 에러 해결 카탈로그

❌ useRef 금고 안의 값을 화면에 노출시키는 사상누각

언제 나오는가?

const countRef = useRef(0);
 
const handleAdd = () => {
  countRef.current += 1;
  // 💥 영철: "히히 눌렀는데 화면 숫자가 안 바뀌잖아요!"
};
 
// ... <button onClick={handleAdd}>나비 누름 횟수: {countRef.current}</button> ...

원인: useRef가 렌더링을 발동시키지 않는다는 것을 인지하지 못하고 화면 UI(JSX 반환 공간)에 넣은 거야. 버튼을 눌러 current를 바꿔도 React는 상태 변경 신호를 받지 않았기 때문에 화면을 다시 계산하지 않는다.
그러다가 우연히 다른 상태(State)가 setState되어 컴포넌트가 리렌더링되면, ref에 쌓여 있던 값이 그제야 화면에 반영될 수 있다. 사용자는 "방금 누른 값이 왜 이제 나타나지?"라고 혼란을 겪는다.

해결책:
useRef의 current 속성값을 렌더링 결과물(<p>{여기}</p>)의 핵심 데이터로 쓰지 마세요. UI와 직결되는 데이터라면 반드시 useState를 고르십시오.
"데이터의 변경이 시각적인 변화를 낳는가?" -> YES면 State, NO면 Ref입니다.

🏁 이번에 배운 내용 총정리

💡 한 줄로 기억하기
"나만의 이 소중한 데이터가 바뀌었을 때, 온 마을을 뒤집어엎고 화면을 새로고침하고 싶은가?" 이 문항에 "아니요, 그냥 데이터 숫자만 혼자 기억해주면 돼요."라고 외치고 싶다면 무조건 망설이지 말고 useRef 안주머니를 짜라.

📝 마무리 퀴즈

Q1. useState 대신 useRef를 선택하는 것이 가장 완벽한 베스트 프랙티스(Best Practice)로 부합하는 상황을 하나 고르세요.

• A) 사용자가 쇼핑몰 검색창에서 타이핑하고 있는 실시간 검색어 텍스트 값을 유지하고 싶을 때.
• B) 현재 로그인한 토큰이 유효한 유저인지에 대한 boolean(T/F) 값을 저장하고 권한 에러 모달을 띄울 때.
• C) 컴포넌트 마운트 이후 30초 동안 아무 클릭도 하지 않으면 경고 팝업을 띄워줄 setTimeout 함수의 예약 고유 통제 아이디(ID)를 저장할 때.
• D) 사용자의 현재 쇼핑 카트에 담긴 물품 총 결제 금액을 실시간 계산하여 우측 하단 영수증에 보여줄 때.

✅ 정답: C

💡 상세 해설: 렌더링 트리거 여부만 구상할 줄 알면 됩니다! A의 검색어, B의 모달 T/F, D의 카트 결제액 숫자는 전부 "값이 한 번이라도 바뀌면 화면의 픽셀 UI가 유저 눈앞에서 즉시즉시 변경되어야 하는" UI 직결형 데이터이므로 무조건 useState의 영역입니다.
반면 C의 타이머 아이디는 단순 정수 숫자(1, 2, 3...)일 뿐 브라우저 DOM 어디에도 출력될 일이 없으며, 오직 클린업 시 clearTimeout(ID) 처리 로직을 통제하기 뒷구멍 데이터이므로 리액트 엔진에 시비(리렌더링 부담)를 걸 필요가 전혀 없는 useRef의 최적 무대입니다.

Q2. 다음 중 영철이가 짠 useRef 조작에 대해, 리액트 핵심 팀 동료가 가장 경악(Horrify)하고 코드 리뷰 시 바로 반려를 먹일 치명적 패턴은 무엇인가요?

• A) <input ref={myInputRef} /> 형태로 DOM 요소에 직접 갈고리를 던진 것.
• B) useEffect 외부 클린업 공간에서 myRef.current = null로 초기화한 것.
• C) <div>내 비밀 금고: {secretRef.current}</div> 형태로 JSX 렌더링 반환 공간안에 변수를 넣어둔 것.
• D) 외부 환경에 const initial = 'abc'를 빼두고 useRef(initial)로 값을 초기 세팅한 것.

✅ 정답: C

💡 상세 해설: 안티패턴입니다. useRef는 값을 저장하지만 변경 사실을 React 렌더러에 알리지 않습니다. 따라서 secretRef.current를 JSX에 직접 보여주면 값은 바뀌었는데 화면은 갱신되지 않는 상태가 생깁니다. 화면에 보여줄 값은 useState, 이벤트 핸들러나 Effect에서만 필요한 값은 useRef로 나누는 것이 안전합니다. (A는 기본 사용법, B와 D는 정상 사용법).

Q3. 주관식 논술: useRef가 컴포넌트의 렌더링 횟수(재실행)에 관계없이 어떻게 항상 "단 하나의 온전한 통(박스)"을 기억하고 영구 불변하게 저장하는 구조를 리액트 내부에서 흉내(구현) 내었을지, useState 개념을 빗대어 그 비밀의 작동 원리를 서술하시오.

✅ 정답 및 주관식 해설:

내부 작동 원리: 공식 문서 기준으로 useRef(initialValue)는 current 속성을 가진 객체를 반환하고, 다음 렌더에서도 같은 객체를 반환합니다. initialValue는 첫 렌더 이후에는 다시 쓰이지 않습니다.

핵심은 "같은 ref 객체의 current만 바뀌고, React 상태 큐에는 아무 업데이트도 들어가지 않는다" 는 점입니다. 그래서 값은 렌더 사이에 유지되지만, 값 변경만으로 화면은 다시 그려지지 않습니다. 이 특성 덕분에 타이머 ID처럼 화면과 무관한 값은 안전하게 보관할 수 있고, 화면에 보여줄 값은 state로 분리해야 합니다.

🐣 영철이의 퇴근 일기

화면에 그리지도 않을 타이머 아이디로 무의미한 렌더링을 만들고 있었다니, useRef가 단순히 포커스 잡는 용도가 아니라 '안주머니 비밀 금고'라는 비유가 핵심을 관통했다.

💡 "상태(State)는 마이크, 참조(Ref)는 비밀 금고. 데이터가 변할 때 화면 픽셀이 바뀌어야 하는지 한 번만 생각해보자!"

자바스크립트 변수랑 다를 게 없지만 컴포넌트 수명 내내 영구 보존된다는 게 신기원이다. 당장 내일 출근해서 쓸데없이 상태로 빼놓은 스크롤 위치값이나 타이머 식별자들 다 useRef로 갈아엎어야지. 속이 뻥 뚫리는 기분이다.