<div id="readability-page-1" class="page"><div>
 <div id="SE-531df391-ceff-45ff-a224-0d080a38b19d">
 "이 컴포넌트는 왜 또 렌더됐지?" 또는 "분명 state를 바꿨는데 왜 화면이 안 바뀌지?" — React를 쓰다 보면 반드시 부딪히는 질문이고, 면접에서도 단골입니다. 시즌 1에서 리렌더 조건을 곳곳에서 조금씩 봤는데(state, 트리, context), 이번 챕터에서 "컴포넌트는 정확히 언제 다시 렌더되는가"를 한 장으로 총정리합니다.
​
먼저 용어 하나. 컴포넌트가 화면에 처음 그려지는 것은 마운트(첫 렌더), 그 뒤 다시 그려지는 것이 리렌더(re-render)입니다. 이 챕터는 리렌더에 집중합니다.

 </div> <div id="SE-e9a82fab-ff97-4ac3-bd86-92f291b46f83">
 ​
컴포넌트가 다시 렌더되는 이유는 딱 세 가지뿐입니다.
​
​
① 자기 자신의 state가 바뀔 때
setState(또는 useReducer의 dispatch)로 자기 state를 갱신하면 리렌더됩니다.

 </div> <div id="SE-caf356ec-146e-45e8-b233-aea1f31a91ff">
 function Counter() {
 const [count, setCount] = useState(0);
 return &lt;button onClick={() =&gt; setCount(count + 1)}&gt;{count}&lt;/button&gt;;
 // setCount 호출 → Counter 리렌더
}
 </div> <div id="SE-82e97698-2151-42f1-8fe8-e0cea7b70a13">
 ​
​
② 부모가 리렌더될 때 (캐스케이드)
부모 컴포넌트가 리렌더되면, 그 자식들도 기본적으로 함께 리렌더됩니다. 자식의 props가 바뀌었든 아니든 상관없이요. 컴포넌트 트리를 타고 위에서 아래로 리렌더가 번지는 거죠.

 </div> <div id="SE-81f0eae9-2ff2-4517-b48b-4c5bfc8b8e71">
 function Parent() {
 const [count, setCount] = useState(0);
 return (
 &lt;div&gt;
 &lt;button onClick={() =&gt; setCount(count + 1)}&gt;{count}&lt;/button&gt;
 &lt;Child /&gt; {/* Child는 props도 없는데, Parent가 리렌더되면 같이 리렌더된다 */}
 &lt;/div&gt;
 );
}
 </div> <div id="SE-e00749b8-5e99-4916-b6ff-53650e0fdb04">
 ​
​
③ 구독 중인 context 값이 바뀔 때
useContext(SomeContext)로 어떤 context를 읽는 컴포넌트는, 그 context의 값(Provider의 value)이 바뀌면 리렌더됩니다. 중간에 props로 전달받지 않아도 직접 구독하니까요.
​
이 셋이 전부입니다. "props가 바뀌면 리렌더된다"가 여기 없다는 점에 주목하세요. 다음 절에서 그 이유를 봅니다.

 </div> <div id="SE-dc67013b-b609-4514-88d9-a53862db41a9">
 ⚠️ 오해 1 — "props가 바뀌어야 리렌더된다"
 </div> <div id="SE-c7020448-d5da-45d0-bbfc-2dfdc31cda9b">
 ​
가장 흔한 오해입니다. 정확히 말하면, props 변경 자체는 리렌더의 트리거가 아닙니다. props가 바뀌는 건 보통 ②번(부모 리렌더)의 결과일 뿐입니다.
​
<ul><li>부모가 리렌더되면 → 자식은 props가 그대로여도 리렌더됩니다(기본 동작).
</li><li>즉 자식이 리렌더되는 이유는 "props가 바뀌어서"가 아니라 "부모가 리렌더되어서"입니다.
</li></ul>​
이걸 구분하면 "props 안 바뀌었는데 왜 자식이 또 렌더되지?"라는 의문이 풀립니다. 답: 부모가 렌더됐으니까요. (그리고 이 불필요한 캐스케이드를 막는 게 뒤에서 볼 React Compiler의 일입니다.)

 </div> <div id="SE-e2977b89-4e62-4f8e-86ed-80d3ab700da7">
 ⚠️ 오해 2 — "setState하면 무조건 리렌더된다"
 </div> <div id="SE-6ba1cee0-09fb-4d55-8d98-8248b718dd51">
 ​
이것도 아닙니다. 새 state 값이 이전 값과 같으면(React는 Object.is로 비교), React는 리렌더를 건너뜁니다(bail out).

 </div> <div id="SE-0c0d0bed-13f2-4e84-839b-652d7b57d6ae">
 const [count, setCount] = useState(0);

function handleClick() {
 setCount(0); // 이미 0인데 또 0 → React가 리렌더를 건너뛴다
}
 </div> <div id="SE-e69ac882-05c7-464f-9926-06baf048f6e9">
 그리고 여기서 불변성이 다시 등장합니다. 객체나 배열 state를 직접 수정하면, 참조가 그대로라 React는 Object.is 비교에서 "안 바뀌었다"고 판단해 리렌더하지 않습니다.
 </div> <div id="SE-075b15e5-8f9c-42c8-9c83-90a0b3563099">
 const [user, setUser] = useState({ name: '홍길동', age: 30 });

function handleBirthday() {
 user.age = user.age + 1; // 🔴 직접 수정 — 참조 그대로
 setUser(user); // 같은 참조 → Object.is가 "같다" → 리렌더 안 함! (화면 그대로)
}
 </div> <div id="SE-bb2bad72-9fba-40bd-9c50-5fc5178caa09">
 "분명 값을 바꿨는데 화면이 안 바뀐다"의 단골 원인이 이겁니다. 새 객체로 교체해야 참조가 달라져 리렌더됩니다.
 </div> <div id="SE-31081d78-eaed-403a-a6f4-35cbeb533262">
 setUser({ ...user, age: user.age + 1 }); // ✅ 새 참조 → 리렌더
 </div> <div id="SE-59b7b4dd-cc90-4187-aad7-d5c847a6258d">
 ​
면접에서 한 단계 더 들어가는 포인트입니다. "리렌더"는 비싼 게 아닙니다. 리렌더는 그저 컴포넌트 함수를 다시 실행해 새 Virtual DOM을 계산하는 것일 뿐입니다. 그 결과가 실제 DOM을 바꿀지는 재조정이 따로 판단합니다.

 </div> <div id="SE-18760ccd-662f-4126-8371-af7d1f329a32">
 리렌더 = 컴포넌트 함수 재실행 + 새 VDOM 계산 (메모리 안의 일, 대체로 쌈)
 │
 ▼ 재조정(diff)
DOM 변경 = 이전 VDOM과 달라진 부분만 실제 DOM에 반영 (상대적으로 비쌈)
 </div> <div id="SE-2dcee972-fdc8-466c-9592-6c7df730c2db">
 그래서 컴포넌트가 리렌더돼도, 결과 VDOM이 이전과 같으면 실제 DOM은 하나도 안 바뀝니다. "리렌더가 일어났다 = 화면이 다시 그려졌다(느리다)"가 아니라는 거죠. 물론 리렌더가 과하게 잦으면 계산 비용이 쌓이긴 하지만, "리렌더 = 무조건 성능 문제"는 과장된 공포입니다.
 </div> <div id="SE-2769eb89-109a-435d-b7fa-5b79a2748c67">
 ​
문제가 되는 건 주로 ②번 — 부모가 리렌더될 때 바뀐 것도 없는 자식까지 줄줄이 리렌더되는 캐스케이드입니다. 옛날에는 이걸 React.memo로 일일이 감싸 막았습니다(props가 같으면 리렌더 건너뛰기).
​
이 시리즈에서는 그럴 필요가 없죠. React Compiler가 자동으로 "이 자식은 입력이 안 바뀌었으니 이전 결과를 재사용"하도록 처리합니다. 즉 캐스케이드를 막는 일도 이제 대부분 컴파일러의 몫입니다. 우리가 할 일은 여전히 순수하게, 불변으로 짜는 것까지고요.
​
​
면접 포인트 정리
<ul><li>리렌더를 일으키는 3가지? ① 자기 state 변경 ② 부모의 리렌더(캐스케이드) ③ 구독 중인 context 값 변경. 이게 전부다.
</li><li>props가 바뀌면 리렌더된다? 아니다. props 변경은 보통 "부모 리렌더"의 결과일 뿐. 부모가 리렌더되면 props가 같아도 자식은 리렌더된다.
</li><li>setState는 항상 리렌더? 아니다. 새 값이 이전과 Object.is로 같으면 건너뛴다. (그래서 객체를 직접 변경하면 참조가 같아 리렌더가 안 된다.)
</li><li>리렌더 = 느리다? 아니다. 리렌더는 VDOM 계산일 뿐, 실제 DOM 변경 여부는 재조정이 결정한다.
</li></ul>
 </div> <div id="SE-f2d5da60-7b37-42ba-8c52-aab528084548">
 ​
<ul><li>리렌더 트리거는 딱 셋: ① 자기 state 변경, ② 부모의 리렌더(캐스케이드), ③ 구독 중인 context 값 변경.
</li><li>props 변경은 트리거가 아니다. 부모가 리렌더되면 props가 그대로여도 자식은 리렌더된다.
</li><li>setState해도 값이 이전과 같으면(Object.is) 리렌더를 건너뛴다. 객체를 직접 변경하면 참조가 같아 리렌더가 안 되므로, 새 객체로 교체해야 한다.
</li><li>리렌더 ≠ DOM 변경. 리렌더는 VDOM 계산, 실제 DOM 변경은 재조정이 판단한다. "리렌더 = 무조건 비싸다"는 오해다.
</li><li>불필요한 캐스케이드는 React Compiler가 자동으로 막는다. 우리는 순수·불변만 지키면 된다.
</li></ul>​
리렌더의 조건을 정리했으니, 다음 챕터에서는 사용자 입력을 받는 또 다른 내부 동작 — React의 합성 이벤트(SyntheticEvent)와 이벤트 위임 — 을 다룹니다. 이전에 이벤트를 "쓰는 법"만 봤다면, 이번엔 React가 이벤트를 어떻게 처리하는지 들여다봅니다.

 </div> <div id="SE-f73c67d1-3f42-477c-a46f-be61ddda5afa">
 ​
<ul><li>Render and Commit — React 공식 문서 (렌더 트리거와 단계; 확인: 2026-06-24)
</li><li>useState — 같은 값으로 갱신 시 bail out — React 공식 문서 (확인: 2026-06-24)
</li><li>Passing Data Deeply with Context — React 공식 문서 (context 구독; 확인: 2026-06-24)
</li></ul>
 </div> </div></div>

개발하는 기획자. 기획하는 개발자.

"이 컴포넌트는 왜 또 렌더됐지?" 또는 "분명 state를 바꿨는데 왜 화면이 안 바뀌지?" — React를 쓰다 보면 반드시 부딪히는 질문이고, 면접에서도 단골입니다. 시즌 1에서 리렌더 조건을 곳곳에서 조금씩 봤는데(state, 트리, context), 이번 챕터에서 "컴포넌트는 정확히 언제 다시 렌더되는가"를 한 장으로 총정리합니다. 먼저 용어 하나. 컴포넌트가 화면에 처음 그려지는 것은 마운트(첫 렌더), 그 뒤 다시 그려지는 것이 리렌더(re-render)입니다. 이 챕터는 리렌더에 집중합니다. 리렌더를 일으키는 3가지 (이게 전부다) 컴포넌트가 다시 렌더되는 이유는 딱 세 가지뿐입니다. ① 자기 자신의 state가 바.......

리렌더는 언제 일어나는가 — 트리거 총정리

댓글