🧩 02. 상태(State)의 진짜 의미 — 렌더링은 스냅샷이다

🎯 이 섹션을 읽고 나면:

• setState를 호출해도 바로 다음 줄에서 값이 바뀌지 않는 이유를 설명할 수 있다.
• 타이머나 비동기 함수에서 옛날 상태값(클로저 함정)을 참조하는 버그를 즉시 파악할 수 있다.
• 함수형 업데이트(setState(prev => prev + 1))가 언제 왜 필요한지 판단할 수 있다.

📋 목차

• 🤔 왜 알아야 하는가: 변수가 아닌 스냅샷
• 🏗️ 비유로 먼저 이해하기
• 🧩 클로저(Closure)가 부른 대참사
  • ❌ 영철이의 폭탄 코드: 좋아요 3배 이벤트
  • ✅ 영호의 리팩토링: 함수형 업데이트 (Functional Update)
• 💥 에러 해결 카탈로그
  • ❌ 비동기(setTimeout) 타이머의 침묵 버그

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 15분 / 핵심 파트: 8분

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

• 영철(신입): "어라? '가입 환영 메시지 보내기' 버튼을 눌렀는데, 5초 뒤에 뜨는 팝업에 방금 입력한 수신자 이름이 안 뜨고 빈칸만 나와요! 제가 귀신을 본 걸까요?"
• 영호(리드): "영철 님... 리액트 렌더링은 동영상이 아니라 '사진(스냅샷)' 이에요. 5초 전에 찍어둔 사진 속에는 당연히 빈칸 입력창이 찍혀 있었겠죠!"

🤔 왜 알아야 하는가: 변수가 아닌 스냅샷

프론트엔드 개발자들이 처음 리액트를 만났을 때 가장 당황하는 순간은 언제일까? 분명히 함수를 통해 값을 바꿨는데, 코드 바로 아랫줄에서 콘솔 로그로 그 값을 찍어보면 바뀌기 전의 값 이 여전히 나올 때야.

🤔 잠깐, 먼저 생각해봐
아래 코드에서 버튼을 클릭하면 콘솔 창에 어떤 숫자가 찍힐까?
setCount(count + 1); console.log(count);

// ❌ 순진한 코드 (Naive Approach)
function Counter() {
  const [count, setCount] = useState(0);
 
  const handleClick = () => {
    setCount(count + 1);
    console.log(count); // 0일까, 1일까?
  };
  
  // ...

위 코드에서 count는 1이 되지 않고 여전히 0을 출력해. 왜 그럴까?

React에서 useState로 만든 상태는 일반 변수가 아니기 때문 이야. 영철이는 이걸 자바스크립트의 let count = 0처럼 여기고 값이 즉시 할당되는 줄 알았지만, 리액트는 이 값을 **스냅샷(Snapshot, 사진)**처럼 취급해.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?
네가 방에 들어가서 방금 폴라로이드 사진을 한 장 찰칵 찍었어. 그 사진 안의 시계는 '12시 정각'을 가리키고 있지.
너는 엄마한테 "엄마, 저기 벽시계 12시 5분으로 돌려줘!" 하고 소리쳤어. (이게 setState 야).
엄마가 벽시계를 5분 돌려놨지만, 네 손에 꽉 쥐고 있는 폴라로이드 사진 속 시계 는 여전히 12시 정각이야. 사진은 실시간 비디오가 아니니까!
다음 번에 엄마가 "시계 바꿨으니 사진 다시 찍어봐!" 하고 새로 찰칵 찍을 때(다음 리렌더링), 그제서야 12시 5분이 찍힌 새로운 폴라로이드 사진 을 받게 되는 거야.

✅ 핵심 원리:
렌더링이란, 리액트가 컴포넌트(함수)를 호출 하는 행위야. 그 함수가 호출된 딱 그 순간의 state 값과 props 값을 가지고 UI(JSX)를 만들어내지. 그 렌더링 안에서 살아가는 이벤트 핸들러(handleClick) 역시 함수가 만들어지던 그 순간의 고정된 스냅샷(예: count = 0) 에 갇히게 돼. 이를 전문 용어로 자바스크립트의 클로저(Closure) 라고 해.

🧩 클로저(Closure)가 부른 대참사

❌ 영철이의 폭탄 코드: 좋아요 3배 이벤트

커뮤니티 글에 '3배 좋아요 이벤트' 버튼을 긴급 추가하게 되었어. 누르면 좋아요가 한 번에 3씩 올라가야 해.

// ❌ 순진한 코드: 도대체 왜 3씩 안 오를까?
function LikeButton() {
  const [likes, setLikes] = useState(0);
 
  const handleTripleLike = () => {
    setLikes(likes + 1);
    setLikes(likes + 1);
    setLikes(likes + 1);
  };
 
  return <button onClick={handleTripleLike}>좋아요 {likes}</button>;
}

영철이는 호기롭게 버튼을 눌렀지만, 결과는 충격적이게도 likes가 1 만 올랐어. 왜냐고?

1. 첫 번째 렌더링 스냅샷에서 likes라는 상수의 값은 0이야.
2. setLikes(0 + 1)을 실행. 리액트에 "다음 렌더링 땐 1로 줘" 예약.
3. setLikes(0 + 1)을 실행. 여전히 내 핸들러가 들고 있는 사진 속 likes는 0이니까!
4. setLikes(0 + 1)을 실행. 역시나 0 + 1.

결국 리액트는 렌더링이 끝날 때 일괄 처리(Batching)를 하면서 "아, 1로 바꿔달라는 요청이 3번 연속으로 왔구나. 알았어, 1로 덮어씌울게." 하고 최종적으로 1로 업데이트해버리지.

✅ 영호의 리팩토링: 함수형 업데이트 (Functional Update)

이럴 때 스냅샷(클로저)의 벽을 뚫고 가장 최신 형태의 보장된 상태 를 얻어오고 싶다면 어떻게 해야 할까? 바로 setState 안에 값을 던지는 대신 규칙(함수) 을 집어넣는 거야.

// ✅ 우아한 코드 (Pro Approach)
function LikeButton() {
  const [likes, setLikes] = useState(0);
 
  const handleTripleLike = () => {
    // 값을 직접 계산해 넣지 말고, "이전 값을 받아서 어떻게 변환할지" 규칙을 전달해!
    setLikes(prevLikes => prevLikes + 1);
    setLikes(prevLikes => prevLikes + 1);
    setLikes(prevLikes => prevLikes + 1);
  };
 
  return <button onClick={handleTripleLike}>좋아요 {likes}</button>;
}

📖 용어: 함수형 업데이트 (Functional Update)
상태 업데이트 함수에 값 대신 (이전_상태) => 다음_상태 형태의 콜백 함수를 전달하는 방식.
이 함수들은 리액트 내부의 큐(Queue)에 담겨서 차례대로 실행되므로, 내 스코프의 오래된 스냅샷 값을 무시하고 항상 최신의 상태 결괏값(prevLikes) 을 물고 이어질 수 있다.

💥 에러 해결 카탈로그

❌ 비동기(setTimeout) 타이머의 침묵 버그

언제 나오는가?

const [message, setMessage] = useState('');
 
const handleSend = () => {
  setTimeout(() => {
    alert(`서버에 전송된 내용: ${message}`); // 💥 5초 뒤에 텅 빈 메시지가 뜸!
  }, 5000);
};
 
// ... <input onChange={(e) => setMessage(e.target.value)} /> ...

원인: handleSend 가 실행되던 타이밍의 렌더링 스냅샷에서 message 는 텅 빈 문자열이었어! 네가 그 5초 사이에 인풋창에 미친 듯이 키보드를 타이핑해서 컴포넌트 사진이 10장이나 새로 찍혔어도, 타이머 안에 적어둔 코드는 처음 버튼을 눌렀던 5초 전 낡은 사진 속 빈 message 에 영원히 갇혀있어. 이게 바로 예전 상태를 꼭 쥐고 놓지 않는 '클로저(Closure) 함정' 이야.

해결책:
이럴 때는 상태(스냅샷)가 아니라, 렌더링 스냅샷과 무관하게 언제나 현재 메모리 주소에서 최신값을 꺼내볼 수 있는 자바스크립트 객체의 비밀 창고, useRef 를 써야 해.

🏁 이번에 배운 내용 총정리

💡 한 줄로 기억하기
리액트의 상태(State)는 변수가 아니라 폴라로이드 사진(스냅샷) 이다.
빈번한 상태 업데이트는 내 손에 들린 그 낡은 사진에 빨간펜을 칠하는 게 아니다. "다음 번에 이런 포즈로 사진 다시 찍어주세요"하고 리액트 스튜디오 사장님께 예약서를 접수하는 행위다.

🐣 영철이의 퇴근 일기

setState 바로 다음 줄에 console.log 찍어놓고 왜 값이 안 바뀌냐고 리액트 버그 아니냐며 씩씩대던 내 모습이 부끄럽다. 클로저 개념을 예전에 책에서 보고 그냥 넘겼는데, 이게 비동기 타이머랑 맞물려서 나를 이렇게 괴롭힐 줄이야.

💡 "상태는 일반 변수가 아니라 폴라로이드 사진(스냅샷)이다. 최신 값을 보장받고 싶다면 함수형 업데이트를 쓰자!"

영호 리드 님이 '리액트 스튜디오 사장님' 비유를 해주셨을 때 진짜 이마를 탁 쳤다. 앞으로 콜백 지옥이나 타이머 함정에 빠질 때마다 이 폴라로이드 사진을 떠올려야지. 넷플릭스 보며 저녁 먹고, 내일은 오늘 배운 useRef로 버그 잡으러 출근하자.

📝 마무리 퀴즈

Q1. 다음 컴포넌트에서 버튼을 한 번 클릭하면, 화면에는 최종적으로 어떤 값이 렌더링될까요?

function QuizOne() {
  const [score, setScore] = useState(0);
 
  const raiseScore = () => {
    setScore(score + 5);
    setScore(score + 5);
    setScore(s => s + 2);
  };
 
  return <button onClick={raiseScore}>점수: {score}</button>;
}

• A) 12
• B) 7
• C) 5
• D) 2

✅ 정답: B

💡 상세 해설: 첫 줄 setScore(0 + 5)로 값 '5'로 교체 예약이 들어갑니다. 두 번째 줄 setScore(0 + 5)역시 내 손의 스냅샷은 0이므로 '5'로 교체 예약(동일 값으로 덮어씌움)을 합니다. 마지막 줄 setScore(s => s + 2)는 큐(Queue) 연산이므로 큐에 가장 마지막으로 쌓인 최신 결과값인 '5'를 물려받아 5 + 2 = 7을 반환합니다. 따라서 다음 번 스냅샷의 렌더링 값은 7이 됩니다!

Q2. useRef는 상태 변수(useState)와 달리 클로저(옛날 사진) 함정에 빠지지 않습니다. 그 근본적인 이유는 무엇일까요?

• A) useRef는 브라우저의 전역 객체인 Window에 값을 직접 저장하기 때문.
• B) useRef는 내용물이 바뀌면 화면을 강제로 즉시 리렌더링시키기 때문.
• C) 컴포넌트의 렌더링 생명주기와 무관하게, 힙(Heap) 메모리 공간에 하나의 동일한 주소(reference)를 가진 객체를 영구 지속시키기 때문.
• D) useRef는 비동기 함수 안에서만 동작하도록 특수 설계된 API이기 때문.

✅ 정답: C

💡 상세 해설: useState는 렌더링마다 새로운 상수(const) 값을 던져주지만, useRef는 언제나 같은 바구니인 { current: 값 }이라는 자바스크립트 객체의 '동일한 메모리 주소'를 던져줍니다. 함수가 클로저 탓에 과거의 바구니 껍데기를 쥐고 있더라도, 그 바구니의 주소가 영원히 같기 때문에 언제든 뚜껑(current)을 열면 누군가 새로 집어넣은 가장 쌩쌩한 최신 값을 들여다볼 수 있습니다. 렌더링 폭풍에서 자유로운 단 하나의 '스위스 은행 비밀 금고'인 셈이죠.

Q3. 리액트는 상태 업데이트를 왜 굳이 이런 '예약 및 렌더링(Batching)' 방식으로 귀찮게 설계했을까요? 만약 setState를 호출하자마자 변수가 갱신되고 즉시 화면 DOM을 직접 고쳐버리는 방식이었다면 생길 치명적 단점은 무엇일까요?

✅ 정답 및 주관식 해설:

퍼포먼스(성능) 붕괴입니다. 버튼 클릭 한 번에 10개의 관련된 상태가 연달아 바뀐다고 쳐볼게요.
실시간 동기식으로 화면을 갱신한다면 브라우저는 무거운 DOM 구조 갱신 및 페인트 연산을 연달아 10번 수행해야 하며, 이는 화면 멈춤(Jank)이나 극심한 버벅임을 초래합니다.
리액트는 이를 방지하기 위해 일괄 처리(Batching) 전략을 취했습니다.
즉, 하나의 이벤트 사이클에서 발생하는 수많은 업데이트 예약들을 리액트 주문서에 차곡차곡 쌓아뒀다가, 이벤트가 전부 끝나는 마지막 순간에 딱 한 번만 가상 돔 정합성을 따져본 후 실제 DOM을 단 1회 렌더링합니다.
최상의 퍼포먼스를 얻기 위한 우아한 타협의 결과물이 바로 이 '스냅샷' 시스템입니다.