실제 DOM을 직접 다루면 왜 문제가 될까

브라우저의 실제 DOM은 단순 JavaScript 객체가 아니다.

DOM을 변경하면 브라우저는 상황에 따라 여러 작업을 수행해야 한다.

DOM 변경
→ style 계산
→ layout 계산
→ paint
→ composite

특히 layout에 영향을 주는 변경은 비용이 크다.

예를 들어

element.style.width = '500px';

같은 변경은 주변 요소의 위치와 크기까지 다시 계산하게 만들 수 있다.

이 과정을 흔히 reflow 또는 layout recalculation이라고 부른다.

또 색상, 배경, 그림자처럼 시각적 변화가 생기면 repaint가 발생할 수 있다.

즉 실제 DOM 조작이 비싼 이유는 DOM 객체 수정 자체만이 아니라, 그 이후 브라우저 렌더링 파이프라인이 함께 동작하기 때문이다.

React가 해결한 문제

React가 해결하려는 핵심 문제는 이것이다.

상태가 바뀔 때마다 개발자가 직접 DOM을 어떻게 바꿀지 계산하지 않게 한다.

예를 들어 직접 DOM을 다루면 이런 식의 코드가 많아진다.

const title = document.querySelector('.title');

if (isLogin) {
  title.textContent = '환영합니다';
} else {
  title.textContent = '로그인해주세요';
}

상태가 많아질수록 DOM 조작 코드도 복잡해진다.

React는 이 방식을 바꿨다.

개발자는 현재 상태에 따른 UI를 선언한다.

function Header({ isLogin }: { isLogin: boolean }) {
  return (
    <h1>
      {isLogin ? '환영합니다' : '로그인해주세요'}
    </h1>
  );
}

그리고 React가 이전 UI와 다음 UI를 비교해서 실제 DOM 변경을 처리한다.

즉 React의 핵심은 DOM을 직접 수정하는 방식에서, 상태에 따른 UI를 선언하는 방식으로 바꾸는 것이다.

Virtual DOM은 이 선언형 UI를 가능하게 하는 내부 표현 중 하나다.

Virtual DOM이란

React Element로 이루어진 JavaScript 객체 트리에 가깝다.

예를 들어 JSX

function App() {
  return <div>Hello</div>;
}

이 코드는 내부적으로 대략 이런 객체를 만든다.

React.createElement('div', null, 'Hello');

개념적으로 보면 이런 구조다.

{
  type: 'div',
  props: {
    children: 'Hello',
  },
  key: null,
}

이 객체는 실제 DOM이 아니다.

아직 브라우저에 <div>가 만들어진 것도 아니다.

그저 React가 “어떤 UI를 만들어야 하는지” 이해하기 위한 설명 객체다.

Virtual DOM 동작 흐름

React에서 상태가 바뀌면 대략 이런 흐름이 발생한다.

state 변경
→ 컴포넌트 다시 실행
→ 새로운 React Element Tree 생성
→ 이전 Fiber Tree와 비교
→ 변경 사항 계산
→ 실제 DOM에 필요한 변경만 반영

여기서 자주 말하는 Virtual DOM 비교는 실제로는 React의 Fiber 구조와 reconciliation 과정 안에서 일어난다.

1. Render Phase

상태가 변경되면 React는 컴포넌트를 다시 실행한다.

function App() {
  return <div>Hello</div>;
}

상태가 바뀌면 이 함수가 다시 실행되고, 새로운 React Element Tree가 만들어진다.

예를 들어 이전 UI가 이랬다고 하자.

<div>Hello</div>

상태 변경 후 UI가 이렇게 바뀐다.

<div>Hello world</div>

React는 이 새로운 결과를 기반으로 다음 화면을 계산한다.

중요한 건 이 단계에서 실제 DOM은 아직 건드리지 않는다는 점이다.

이 단계는 React Fiber 기준으로 Render Phase에 해당한다.

Render Phase
→ 다음 UI 계산
→ 실제 DOM 변경 없음

2. Diffing / Reconciliation

React는 이전 결과와 새로운 결과를 비교한다.

이전: <div>Hello</div>
이후: <div>Hello world</div>

여기서 React는 전체 DOM을 다시 만드는 것이 아니라, 텍스트 내용만 바뀌었다는 것을 계산한다.

변경 사항:
textContent "Hello" → "Hello world"

이 과정을 보통 diffing 또는 reconciliation이라고 부른다.

정확히는 reconciliation은 React가 이전 Fiber Tree와 새 React Element를 비교해 다음 Fiber Tree를 구성하고, 어떤 변경이 필요한지 표시하는 과정에 가깝다.

3. Commit Phase

Render Phase에서 변경 사항 계산이 끝나면 React는 Commit Phase로 넘어간다.

Commit Phase에서는 실제 DOM 변경이 발생한다.

텍스트 노드 변경
"Hello" → "Hello world"

이때 실제 DOM에 반영된다.

즉 흐름을 정리하면:

Render Phase
→ 메모리상에서 다음 UI 계산

Reconciliation
→ 이전 트리와 비교해 변경 사항 계산

Commit Phase
→ 실제 DOM에 변경 적용

이다.

Virtual DOM이 항상 빠른 것은 아니다

Virtual DOM은 마법처럼 항상 빠른 기술이 아니다.

상태가 변경될 때마다 컴포넌트가 다시 실행되고, React는 새로운 트리를 계산해야 한다.

즉 Virtual DOM도 비용이 있다.

특히

너무 큰 컴포넌트 트리
불필요한 리렌더링
복잡한 계산
큰 리스트

가 있으면 Virtual DOM 계산 자체도 부담이 된다.

그래서 React 성능 최적화에서는 여전히 다음이 중요하다.

memo
useMemo
useCallback
state 위치 조정
component boundary 분리

즉 Virtual DOM은 실제 DOM 조작을 줄이는 데 도움을 주지만, 모든 성능 문제를 자동으로 해결해주지는 않는다.

Fiber Tree와 Virtual DOM

React 16 이후 내부 구조는 Fiber 기반으로 바뀌었다.

그래서 지금 React를 이해할 때는 단순히 Virtual DOM만 보는 것보다 Fiber Tree까지 같이 보는 게 좋다.

Fiber는 React Element를 기반으로 만들어지는 작업 단위다.

각 Fiber는 대략 다음 정보를 가진다.

컴포넌트 타입
props
state
부모/자식/형제 관계
변경 flags
DOM node 연결 정보
우선순위 정보

즉 Fiber Tree는 단순 UI 설명 객체를 넘어서, React가 업데이트 작업을 쪼개고 관리하기 위한 자료구조다.

왜 Fiber가 필요했을까

기존 Virtual DOM 설명만으로는 다음 질문을 설명하기 어렵다.

React는 어떻게 렌더링 작업을 중단하고 다시 시작할 수 있을까?
useTransition은 어떻게 덜 급한 업데이트를 나중에 처리할까?
Suspense는 어떻게 일부 UI를 기다리게 할까?

이걸 가능하게 하는 기반이 Fiber다.

Fiber는 렌더링 작업을 작은 단위로 나누고, 우선순위를 부여할 수 있게 한다.

즉 React는 렌더링 중에

지금 이 작업이 급한가?
잠시 멈춰도 되는가?
더 우선순위 높은 업데이트가 들어왔는가?

를 판단할 수 있다.

Double Buffering

React Fiber는 두 개의 트리를 사용한다.

current tree
→ 현재 화면에 반영된 트리

work-in-progress tree
→ 다음 화면을 계산하는 트리

현재 사용자가 보고 있는 화면은 current tree를 기준으로 한다.

상태가 변경되면 React는 current tree를 기반으로 work-in-progress tree를 만든다.

그리고 새로운 상태를 반영해 다음 화면을 계산한다.

current tree
   ↓
work-in-progress tree 생성
   ↓
변경 사항 계산
   ↓
commit
   ↓
work-in-progress tree가 current tree가 됨

이 구조를 Double Buffering이라고 볼 수 있다.

Double Buffering이 왜 중요한가

이 구조 덕분에 React는 현재 화면을 유지하면서 다음 화면을 준비할 수 있다.

즉 사용자가 보고 있는 DOM은 유지하고, React는 메모리상에서 다음 화면을 계산한다.

계산이 끝나면 commit 단계에서 한 번에 반영한다.

이게 중요한 이유는 다음과 같다.

계산 중인 화면을 사용자에게 보여주지 않는다.
중간 상태의 깨진 UI를 방지한다.
렌더링 작업을 중단하거나 버릴 수 있다.
최종 결과만 DOM에 반영한다.

특히 Concurrent Rendering에서는 이 구조가 중요하다.

React는 낮은 우선순위 작업을 진행하다가 더 급한 업데이트가 들어오면 기존 work-in-progress 작업을 버리고 다시 계산할 수 있다.

하지만 commit된 화면은 항상 일관성을 유지한다.

current tree와 실제 DOM의 관계

current tree는 현재 화면에 대응하는 Fiber Tree다.

그리고 실제 DOM과 연결되어 있다.

예를 들어 <div>Hello</div>가 화면에 있다면, 해당 Fiber는 실제 DOM 노드에 대한 참조를 가지고 있다.

반면 work-in-progress tree는 다음 화면을 계산하기 위한 트리다.

아직 실제 DOM에 반영되지 않았다.

그래서 Render Phase에서는 WIP Tree를 만들고 계산하지만, 실제 DOM은 바꾸지 않는다.

Commit Phase에서만 실제 DOM이 변경된다.

key가 왜 중요한가

리스트 diffing에서 key는 React가 어떤 항목이 같은 항목인지 판단하는 기준이다.

items.map((item) => (
  <Item key={item.id} item={item} />
));

key가 불안정하면 React는 기존 항목을 재사용하지 못하고 잘못된 방식으로 비교할 수 있다.

예를 들어 index를 key로 쓰면 순서 변경 시 문제가 생길 수 있다.

items.map((item, index) => (
  <Item key={index} item={item} />
));

key는 단순 warning 제거용이 아니라 reconciliation 정확도와 성능에 영향을 준다.

렌더링과 DOM 변경

React에서 “렌더링됐다”는 말은 실제 DOM이 바뀌었다는 뜻이 아닐 수 있다.

Render Phase에서는 컴포넌트가 실행되고 다음 UI를 계산한다.

하지만 Commit Phase까지 가지 않으면 실제 DOM은 바뀌지 않는다.

즉

render
→ 계산

commit
→ 실제 DOM 반영

으로 구분해야 한다.

이 차이를 알면 useEffect, useLayoutEffect, useTransition의 동작도 더 명확해진다.

side effect 위치를 이해할 수 있다

Render Phase는 여러 번 실행되거나 버려질 수 있다.

그래서 컴포넌트 본문에서 side effect를 실행하면 위험하다.

function Component() {
  sendAnalytics();

  return <div>Hello</div>;
}

이 코드는 렌더링 시마다 실행될 수 있다.

하지만 해당 렌더링이 실제 DOM에 반영되지 않을 수도 있다.

그래서 이런 작업은 useEffect로 분리해야 한다.

useEffect(() => {
  sendAnalytics();
}, []);

Vdom