<div id="readability-page-1" class="page"><div>
 <div id="SE-db027d9b-ab20-4ffe-8237-ba3cc701a789">
 React 이전에는 화면을 바꿀 때 DOM을 직접 조작했습니다. "이 요소를 찾아서, 텍스트를 바꾸고, 저 요소는 숨기고…" 하는 식으로요. 그런데 실제 DOM 조작은 비쌉니다. 레이아웃 재계산, 리페인트 같은 작업이 따라붙거든요. 게다가 어디를 어떻게 바꿀지 일일이 챙기다 보면 실수가 쌓입니다.
​
React의 발상은 이렇습니다. 개발자는 "이 상태에서 화면이 어떻게 생겨야 하는지"만 선언하고, 실제 DOM을 최소한으로 바꾸는 일은 React가 알아서 한다. 그 "알아서 하는" 엔진의 한가운데에 Virtual DOM과 재조정이 있습니다.

 </div> <div id="SE-a42bcbe3-4820-4cf4-94e4-f4f3165446e5">
 ​
Virtual DOM은 실제 DOM을 본뜬, 메모리 속의 가벼운 JavaScript 객체 트리입니다. 우리가 JSX로 &lt;h1&gt;안녕&lt;/h1&gt;을 반환하면, 그건 브라우저 DOM 노드가 아니라 { type: 'h1', props: { children: '안녕' } } 같은 평범한 객체(React 엘리먼트)로 만들어집니다. 이 객체들이 모여 화면 전체를 나타내는 트리를 이루죠.
​
핵심은 이 객체 트리는 만들고 버리는 비용이 싸다는 점입니다. 실제 DOM 노드를 만들고 조작하는 것보다 훨씬 가볍거든요. React는 이 가벼운 사본 위에서 "무엇이 바뀌었는지"를 먼저 계산한 다음, 진짜로 바뀐 부분만 실제 DOM에 반영합니다.
​
용어 메모: "Virtual DOM"은 널리 쓰이는 이름이지만, 요즘 React 공식 문서는 이걸 구현 세부사항으로 보고 "렌더 트리(render tree)"라는 표현을 씁니다. 면접에서는 "Virtual DOM"으로 통하니 이 글도 그 이름을 쓰되, 본질은 "화면의 메모리 속 표현을 비교해 최소 변경만 적용하는 것*이라고 이해하면 됩니다.

 </div> <div id="SE-c349df6f-db45-46a1-bc89-eb4f465c882f">
 재조정(Reconciliation) — 두 트리를 비교하기
 </div> <div id="SE-a252d335-559b-478e-a223-ca8ac19f9f6f">
 ​
state가 바뀌면(트리거 → 렌더 → 커밋, 기억하시죠?), React는 컴포넌트를 다시 호출해 새 Virtual DOM 트리를 만듭니다. 이제 React에게는 트리가 둘 있습니다 — 이전 트리와 방금 만든 새 트리. 이 둘을 비교해서 무엇이 달라졌는지 알아내고, 실제 DOM에 적용할 최소한의 변경 목록을 계산하는 과정이 바로 재조정(Reconciliation)입니다.

 </div> <div id="SE-8664e95a-8bc2-497a-962d-dbbe0689ce67">
 이전 트리 새 트리 실제 DOM에 할 일
───────── ───────── ──────────────
&lt;ul&gt; &lt;ul&gt; (그대로)
 &lt;li&gt;A&lt;/li&gt; &lt;li&gt;A&lt;/li&gt; (그대로)
 &lt;li&gt;B&lt;/li&gt; → &lt;li&gt;X&lt;/li&gt; 텍스트만 B→X 변경
&lt;/ul&gt; &lt;/ul&gt; (나머지는 건드리지 않음)
 </div> <div id="SE-6cabe640-189c-4690-866f-876afcdffe42">
 위처럼 &lt;li&gt;B&lt;/li&gt;만 &lt;li&gt;X&lt;/li&gt;로 바뀌었다면, React는 전체를 새로 그리지 않고 그 &lt;li&gt;의 텍스트만 바꿉니다. 이게 "선언적으로 짜도 빠른" 비결입니다. 우리는 "전체 화면이 이렇다"고 선언만 하지만, React는 달라진 부분만 골라 적용하니까요.
 </div> <div id="SE-2d055dee-ccdc-4ad8-b54e-8aa00e482892">
 diffing의 비밀 — O(n³)를 O(n)으로
 </div> <div id="SE-c8e848de-09af-4ff3-9c50-b42ff076c56d">
 ​
여기서 면접에서 자주 파고드는 부분이 나옵니다. 두 트리를 완벽하게 비교해 최소 변경을 찾는 일반 알고리즘은 O(n³)입니다. 노드가 1,000개면 10억 번 비교 — 현실적으로 불가능하죠.
​
React는 두 가지 현실적인 가정(휴리스틱)으로 이걸 O(n)까지 낮춥니다.
​
​
가정 1 — 타입이 다르면, 다른 트리다
같은 위치에서 엘리먼트의 타입이 바뀌면, React는 비교를 포기하고 이전 것을 통째로 버린 뒤 새로 만듭니다.

 </div> <div id="SE-4cedbdfe-851a-4d1a-b58a-67c4d667a87c">
 // &lt;Counter /&gt;가 &lt;p&gt;로 바뀌면 → Counter를 통째로 버리고 &lt;p&gt;를 새로 만든다
{isPaused ? &lt;p&gt;일시정지&lt;/p&gt; : &lt;Counter /&gt;}
 </div> <div id="SE-e5732a62-e6c2-4c81-8f4a-a253b1344d80">
 &lt;div&gt;가 &lt;span&gt;으로, &lt;Counter&gt;가 &lt;Profile&gt;로 바뀌면, React는 "내용이 비슷한지" 따지지 않고 그냥 갈아엎습니다. 이게 "같은 위치에 다른 컴포넌트가 오면 state가 리셋된다"의 정체입니다. 버려지는 컴포넌트의 state도 함께 사라지는 거죠.
​
​
가정 2 — key로 형제의 정체성을 알려준다
리스트에서 항목이 추가·삭제·재정렬될 때, React는 key로 "이전의 어떤 항목이 새 목록의 어떤 항목과 같은 것인지" 짝을 맞춥니다.

 </div> <div id="SE-d267bf92-c0a5-44c6-8610-b8848f0b8af9">
 {items.map((item) =&gt; (
 &lt;li key={item.id}&gt;{item.text}&lt;/li&gt; // key로 항목을 추적
))}
 </div> <div id="SE-3aecf71d-dad2-486a-b222-640eb6a8f830">
 key가 없거나 index를 쓰면, React는 위치(순번)로만 비교해서 재정렬·삽입 때 엉뚱한 항목을 재사용합니다. "index를 key로 쓰지 말라"고 한 이유가 바로 이 재조정의 짝 맞추기가 어긋나기 때문입니다.
​
즉, 이전에 규칙으로 외웠던 것들(타입 바뀌면 리셋, 안정적 key)은 사실 전부 재조정 알고리즘의 두 가정에서 나온 결과입니다. 메커니즘을 알면 규칙이 외울 거리가 아니라 당연한 귀결이 됩니다.

 </div> <div id="SE-d2f86f46-8dc0-4c1c-80b0-f258ef4a6b76">
 ⚠️ 흔한 오해 — "Virtual DOM이 실제 DOM보다 빠르다"
 </div> <div id="SE-9f5c7868-def5-451a-aba6-fe5d7dbe124e">
 ​
면접에서 함정으로 자주 나오는 주장입니다. 틀렸습니다. Virtual DOM은 그 자체로 마법처럼 빠른 게 아닙니다. 오히려 "새 트리를 만들고 + 비교하는" 추가 작업이 있죠.
​
​
Virtual DOM의 진짜 이점은 속도가 아니라 두 가지입니다.
​
<ul><li>최소 변경. 실제 DOM은 꼭 바뀐 부분만 건드린다. (비싼 DOM 조작을 최소화)
</li><li>선언적 개발. 우리는 "전체 화면이 이렇다"만 선언하면 되고, "무엇을 어떻게 바꿀지"는 React가 계산한다.
</li></ul>​
손으로 정교하게 최적화한 명령형 DOM 코드가 특정 상황에서 더 빠를 수도 있습니다. Virtual DOM의 가치는 "사람이 명령형 최적화를 안 해도, 선언적으로 짠 코드가 충분히 빠르게 유지된다"는 데 있습니다. "항상 더 빠르다"가 아니라 "충분히 빠른 것을 쉽게 얻게 해준다"가 정확한 표현입니다.
​
​
면접 포인트 정리
<ul><li>Virtual DOM이란? 화면을 본뜬 메모리 속 가벼운 객체 트리. 실제 DOM보다 만들고 비교하는 비용이 싸다.
</li><li>재조정이란? 이전 트리와 새 트리를 비교(diff)해 실제 DOM에 적용할 최소 변경을 계산하는 과정.
</li><li>어떻게 빠른가? 일반 트리 비교는 O(n³)이지만, React는 ① 타입이 다르면 갈아엎기 ② key로 형제 추적, 두 휴리스틱으로 O(n)으로 낮춘다.
</li><li>VDOM이 항상 빠른가? 아니다. 속도 자체가 아니라 "최소 변경 + 선언적 개발"이 본질이다.
</li></ul>
 </div> <div id="SE-d73512b0-dd94-4708-9f2c-8e7c290f278d">
 ​
<ul><li>Virtual DOM은 화면의 메모리 속 가벼운 사본(JS 객체 트리)이다.
</li><li>재조정은 이전 트리와 새 트리를 비교해 실제 DOM에 적용할 최소 변경을 계산하는 과정이다(9장의 렌더 → 커밋 사이에서 일어난다).
</li><li>diffing은 두 휴리스틱으로 O(n): ① 타입이 다르면 통째로 교체("타입 바뀌면 state 리셋"), ② key로 형제 추적("index를 key로 쓰지 마라").
</li><li>key·정체성 규칙은 전부 재조정 알고리즘의 결과다.
</li><li>"Virtual DOM이 항상 빠르다"는 오해다. 본질은 속도가 아니라 최소 변경 + 선언적 개발이다.
</li></ul>​
재조정이 "무엇이 바뀌었는지" 계산하는 과정이라면, 그 계산을 언제·어떻게 실행하는지를 담당하는 엔진이 따로 있습니다. 다음 챕터에서 React 16부터 도입된 Fiber 아키텍처를 맛봅니다. 동시성(렌더링을 중단했다 재개하는 능력)이 어떻게 가능한지, 그 바탕을 들여다봅니다.

 </div> <div id="SE-173052ef-617c-405b-b7d9-6e295a3ae272">
 ​
<ul><li>Preserving and Resetting State — React 공식 문서 (재조정의 타입·위치·key 동작; 확인: 2026-06-24)
</li><li>Render and Commit — React 공식 문서 (렌더 → 커밋; 확인: 2026-06-24)
</li><li>Rendering Lists — Keeping list items in order with key — React 공식 문서 (확인: 2026-06-24)
</li></ul>
 </div> </div></div>

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

React 이전에는 화면을 바꿀 때 DOM을 직접 조작했습니다. "이 요소를 찾아서, 텍스트를 바꾸고, 저 요소는 숨기고…" 하는 식으로요. 그런데 실제 DOM 조작은 비쌉니다. 레이아웃 재계산, 리페인트 같은 작업이 따라붙거든요. 게다가 어디를 어떻게 바꿀지 일일이 챙기다 보면 실수가 쌓입니다. React의 발상은 이렇습니다. 개발자는 "이 상태에서 화면이 어떻게 생겨야 하는지"만 선언하고, 실제 DOM을 최소한으로 바꾸는 일은 React가 알아서 한다. 그 "알아서 하는" 엔진의 한가운데에 Virtual DOM과 재조정이 있습니다. Virtual DOM — 화면의 가벼운 사본 Virtual DOM은 실제 DOM을 본뜬, 메모리 속의 가벼.......

Virtual DOM과 재조정 — React는 화면을 어떻게 바꾸나

댓글