🎨 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)를 때리는 순간 리액트 전체 엔진이 "앗! 상태 변경! 렌더링 트리 탐색!" 요동을 치며 화면 전체를 불필요하게 새로 그립니다.

우리에겐 **"값을 안전하게 저장하되, 값이 바뀐다고 엄마(React)한테 일러일러 렌더링 폭풍을 부르지는 않는 비밀 창고"**가 절대적으로 필요합니다. 그리고 그게 바로 useRef의 본질입니다.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?

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

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

✅ 핵심 원리:
리액트 코어 개발자들의 머리통을 뜯어보면 이렇게 설계되어 있습니다.
사실 useRef 내부 코드는 자바스크립트의 단순한 꼼수입니다. useState({ current: initialValue })라고 세팅해두고 그 setter 함수를 평생 절.대 제공하지 않아서, 바구니 주소값이 컴포넌트 생애 내내 **철벽 방어 레퍼런스(불변 주소)**로 유지되게 만들어놓은 것입니다!
(화면 UI 파이프라인과 완벽히 격리된, 탈(脫)리액트 생태계의 스위스 은행 비밀 금고죠.)

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

✅ 영호의 완벽한 리팩토링: 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 = ... 할당문은 그저 순수한 바닐라 자바스크립트 코드가 도는 것과 똑같은 날렵한 수준의 속도를 보장합니다.

💥 에러 해결 카탈로그

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

언제 나오는가?

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

원인: useRef가 렌더링을 발동시키지 않는다(탈-리액트 성질)는 것을 인지하지 못하고 억지로 화면 UI 픽셀(JSX 반환 공간)에 쑤셔 넣은 거야. 리액트는 네가 버튼을 눌러서 current에 500을 쑤셔 넣든 100을 쑤셔 넣든 "어쩌라고? 나한테 렌더링하라고(setState) 신호 안 줬잖아?" 하며 태업해버리지.
그러다가 우연히 옆에 있던 다른 상태(State)가 setState되어 컴포넌트가 리렌더링을 한 바퀴 돌면... 놀랍게도 아까 쌓아둔 500이라는 누름 횟수가 영구보존되어 있다가 그제야 갑자기 화면에 팍! 하고 튀어나옵니다(밀린 렌더링). 사용자는 극도의 혼란을 겪죠.

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

🏁 이번에 배운 내용 총정리

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

🐣 영철이의 퇴근 일기

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

💡 "상태(State)는 마이크, 참조(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) 처리 로직을 통제하기 뒷구멍 데이터이므로 리액트 엔진에 시비(리렌더링 부담)를 걸 필요가 1도 없는 useRef의 최적 무대입니다.

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

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

✅ 정답: C

💡 상세 해설: 절대 금기사항(Antipattern)입니다! useRef는 태생부터 "리액트의 통제 밖(렌더링 트리거 기능 거세됨)"에 존재하는 비밀 상자인데, 이걸 억지로 화면에 그려달라고 넘겨주면 개발자와 프레임워크 간의 신뢰가 박살납니다. 값을 백날 천날 뒤에서 몰래 바꿔봤자 리액트는 리렌더링해주지 않으므로 사용자는 낡은 화면을 보게 되며, 컴포넌트의 생명주기를 완벽히 혼란에 빠뜨리는 버그 머신을 낳게 됩니다. (A는 기본 사용법, B와 D는 정상 사용법).

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

✅ 정답 및 주관식 해설:

내부 작동 원리: 리액트의 useRef는 사실 외계 기술이 아닙니다. 이놈의 내부는 철저하게 useState와 똑같이 "초기값 저장 로직"을 기반으로 깔고 있습니다. 소스코드 내부를 열어보면 대략 useState({ current: initialValue })[0] 코드를 던져주는 것과 매커니즘이 완전히 똑같죠.
가장 큰 핵심은 **"상태를 바구니({ current: ... }인 자바스크립트 객체) 껍데기에 감싸서 단 한 번 넘겨주고는, 그 상태를 변경시키는 방법인 Setter 함수(setState)를 외부 세계(개발자)에 절대 노출 제공하지 않는다"**는 것입니다.
결국 개발자는 이 자바스크립트 객체(Object)의 "주소(Reference)" 하나만 평생 공유받으며, 그 주소 안의 내용물(Property)인 current만 주구장창 직접 쑤셔서 변칙 조작하게 됩니다. 객체 주소는 만년 같으므로 리액트는 영원히 리렌더링을 일으키지 않고, 내용물은 무사히 살아남는 완벽한 탈출구가 되는 것이죠.