🔥 브라우저 렌더링부터 React Fiber까지

관태·2026년 2월 18일

모닥불

목록 보기

5/7

들어가며

솔직히 말하면 저도 예전에 코딩을 처음 배울 때 <script> 태그를 <body> 맨 아래에 두는 게 그냥 "관례"인 줄만 알았어요.
실제로 스크립트를 <head> 안에 뒀다가 페이지 렌더링이 눈에 띄게 느려지는 걸 겪고 나서야 궁금증이 생겼었어요.
"왜 느렸지?"라는 질문 하나가 브라우저 내부 메커니즘 전체를 이해하게 만들어줬어요.

이 글은 브라우저가 파싱하는 방식부터 레이아웃 비용을 거쳐 리액트의 추상화 원리와 Fiber 스케줄링까지 연결되는 흐름을 다뤄요.
브라우저 동작 원리를 처음 파고드는 개발자나 리액트 내부 동작이 궁금한 분에게 도움이 될 거예요.

브라우저 엔진과 파싱 차단 구조

현대 브라우저는 성능을 위해 멀티 프로세스 아키텍처를 사용하지만 우리가 보는 웹페이지 하나는 보통 하나의 렌더러 프로세스(Renderer Process) 내부에서 동작해요.

이 프로세스 안의 메인 스레드는 매우 바빠요.

렌더링 엔진: HTML과 CSS를 해석해서 화면에 시각적으로 출력해요. (Chrome의 Blink)
자바스크립트 엔진: 자바스크립트 코드를 해석하고 실행해요. (Chrome의 V8)

두 엔진은 메인 스레드를 공유해요. 한쪽이 스레드를 잡고 있으면 다른 쪽은 기다려야 해요. 성능 문제의 상당수가 바로 이 대기 시간에서 발생해요.

점진적 파싱과 Script 차단

브라우저는 HTML 파일을 전부 다운로드받을 때까지 기다리지 않아요. 네트워크 버퍼에 데이터가 들어오는 대로 즉시 토큰화를 시작하는 점진적 파싱(Incremental Parsing) 방식을 써요. 이 방식이 LCP(Largest Contentful Paint)와 직결돼요.

파싱 흐름은 아래와 같아요.

Bytes → Characters: 8비트 데이터를 UTF-8 인코딩에 따라 문자로 변환해요.
Tokens: 문자를 <html>, <body> 같은 의미 있는 단위로 쪼개요.
Nodes: 각 토큰을 속성을 가진 객체(Node)로 변환해요.
DOM Tree: 노드들을 부모-자식 관계의 트리로 연결해요.

그런데 이 과정에서 <script> 태그를 만나는 순간 파싱이 멈춰요. 이유는 자바스크립트의 "강력한 권한" 때문이에요. document.write() 같은 명령으로 파싱 중인 HTML 흐름에 새 태그를 즉석에서 주입할 수 있어요. 브라우저가 파싱을 계속하면서 JS도 동시에 실행했는데 그 JS가 방금 파싱한 노드를 삭제하거나 새 노드를 끼워 넣으면 상태 불일치(Race Condition)에 빠져요.

결국 "CSS는 JS 실행을 막고(스타일 정보 참조를 위해) JS는 HTML 파싱을 막는" 연쇄 차단이 발생해요. 이를 Critical Rendering Path(CRP)의 병목이라고 부릅니다.

async와 defer의 차이

파싱 차단을 피하는 방법이 async와 defer인데 둘이 헷갈리기 쉬워요.

<!-- async: 다운로드 완료 즉시 실행, 파싱 도중에 끼어들 수 있음 -->
<script async src="analytics.js"></script>

<!-- defer: 다운로드는 병렬로 하되, DOM 파싱이 끝난 뒤에 순서대로 실행 -->
<script defer src="app.js"></script>

async는 다운로드가 끝나는 순간 바로 실행돼요. 파싱 중이어도 멈추고 JS를 먼저 실행하고 실행 순서도 보장하지 않아요. 서로 독립적인 스크립트(Google Analytics, 광고 태그 등)에 써야 하는 이유예요.

defer는 다운로드를 파싱과 병렬로 진행하지만 실행은 DOM이 완성된 뒤로 미뤄요. 선언 순서대로 실행도 보장해요. 실무에서 기본값은 defer로 두고 async는 다른 스크립트와 전혀 관계없는 독립 스크립트에만 선별해서 쓰는 게 안전해요.

실무에서 기본값은 defer로 두고 async는 다른 스크립트와 전혀 관계없는 독립 스크립트에만 선별해서 쓰는 게 안전해요.

CSSOM과 Preload Scanner

HTML이 DOM을 만들 때 CSS는 CSSOM(CSS Object Model)을 만들어요. CSSOM의 핵심은 Cascade(우선순위 결정 알고리즘)예요. 부모로부터 내려오는 규칙과 명시도(Specificity) 선언 순서를 종합해서 최종 스타일 값을 결정해요.

오해하기 쉬운 부분이 있어요. CSSOM이 생성되는 동안 DOM 파싱 자체는 멈추지 않아요. 다만 생성된 DOM을 화면에 그리기 위한 Render Tree 생성과 JS 실행은 CSSOM이 완성될 때까지 차단돼요. CSS는 HTML 구조 해석 자체의 병목이 아니라 화면 출력과 스크립트 실행의 병목이에요.

현대 브라우저는 Preload Scanner를 탑재하고 있어요. 메인 파서가 JS에 막혀 멈춰있을 때 별도의 가벼운 파서가 뒤쪽 HTML을 미리 훑어서 <img>, <link>, <script> 리소스를 찾아 미리 다운로드해요.

Preload Scanner의 핵심 한계는 정적인 마크업만 읽는다는 거예요. JS로 동적으로 생성하는 리소스는 미리 찾아낼 수 없어요.

<!-- Preload Scanner가 감지할 수 있음 - 마크업에 직접 써있음 -->
<img src="hero.webp" alt="히어로 이미지">

<!-- Preload Scanner가 감지 못함 - JS가 실행되기 전까지 존재하지 않음 -->
<script>
  const img = document.createElement('img');
  img.src = 'hero.webp'; // 스캐너 입장에선 보이지 않는 리소스
  document.body.appendChild(img);
</script>

JS로 동적 생성하는 이미지나 폰트가 LCP에 영향을 준다면 <link rel="preload">로 직접 힌트를 줘야 해요.

<link rel="preload" href="hero-image.webp" as="image">
<script src="analytics.js" defer></script>
<link rel="stylesheet" href="critical.css">

preload를 남발하면 브라우저가 우선순위 판단을 포기해서 정작 중요한 리소스가 늦게 불러와지는 역효과가 생겨요. LCP에 영향을 주는 hero 이미지나 첫 화면에 필요한 폰트 정도에만 선별적으로 써야 해요.

레이아웃과 페인트: Reflow 비용

파싱이 끝나면 브라우저는 실제로 픽셀을 찍는 작업을 시작해요.

렌더 트리와 레이아웃

브라우저는 DOM 트리 루트부터 순회하면서 화면에 실제로 보이는 노드들만 골라 CSSOM 스타일을 적용한 렌더 트리를 만들어요.

display: none → 렌더 트리에 포함되지 않아요
visibility: hidden → 공간은 차지하니까 포함돼요
::before, ::after 가상 요소도 이 단계에서 노드화돼요

단계	발생 유발 속성 (예시)	비고
Reflow	`width`, `height`, `margin`, `top`, `left`	주변 요소까지 재계산 (비쌈)
Repaint	`color`, `background-color`, `visibility`	시각적 요소만 변경
Composite	`transform`, `opacity`	GPU 가속 활용 (가장 저렴)

렌더 트리가 완성됐어도 각 요소의 정확한 위치와 크기는 아직 몰라요. 레이아웃(Layout/Reflow) 단계에서 뷰포트 크기에 맞춰 계산해요. %, em, vh 같은 상대 단위들이 이 단계에서 물리적인 픽셀 값으로 확정돼요.

Layout Thrashing

브라우저는 스타일 변경을 큐에 쌓아뒀다가 한꺼번에 처리하려고 해요. 그런데 스타일을 바꾼 직후에 크기나 위치를 읽는 코드를 실행하면 브라우저는 즉시 다시 계산해야 해요. 이게 강제 동기 레이아웃(Forced Synchronous Layout)이에요.

루프 안에서 이걸 반복하면 매 반복마다 Reflow가 터지는 Layout Thrashing이 발생해요.

// 성능을 망가뜨리는 패턴
function updateBad(elements) {
  for (let i = 0; i < elements.length; i++) {
    // offsetWidth를 읽을 때마다 Reflow 강제 발생
    elements[i].style.width = (container.offsetWidth + 10) + 'px';
  }
}

// 읽기와 쓰기를 분리한 패턴
function updateGood(elements) {
  const width = container.offsetWidth; // 한 번만 읽기
  requestAnimationFrame(() => {
    for (let i = 0; i < elements.length; i++) {
      elements[i].style.width = (width + 10) + 'px'; // 쓰기만 반복
    }
  });
}

Composite Layer와 GPU 가속

현대 브라우저는 화면 전체를 한꺼번에 그리지 않아요. 여러 개의 레이어(Layer)로 나눠서 그린 뒤 합쳐요(Composite).

top이나 left를 변경하면 Reflow → Repaint → Composite 전 과정이 메인 스레드에서 일어나요. JS가 바쁘면 애니메이션이 뚝뚝 끊기는데 이걸 Jank라고 해요.

반면 transform과 opacity는 해당 요소를 별도의 Composite Layer로 승격시켜요. 이미 그려진 비트맵 이미지를 GPU가 좌표만 바꿔서 올리기 때문에 메인 스레드와 무관하게 60fps를 유지해요.

/* 레이어 승격을 미리 힌트로 알려주는 방법 */
.animated-element {
  will-change: transform;
}

/* transform으로 이동 - GPU에서 처리, 메인 스레드 무관 */
.move-with-transform {
  transform: translateX(100px);
}

/* left로 이동 - Reflow 발생, 메인 스레드 점유 */
.move-with-left {
  left: 100px;
}

will-change도 남용하면 안 돼요. 레이어를 만드는 데 메모리가 필요하거든요. 실제로 애니메이션이 일어나는 요소에만 써야 해요. Reflow를 유발하는 CSS 속성은 미리 알아두면 좋아요. width, height, margin, padding, top, left는 전부 Reflow를 발생시켜요. 반면 color, background-color는 Repaint만 일으키고 transform과 opacity는 Composite만 건드려요.

리액트의 추상화: 가상 돔과 재조정

브라우저 수준에서 이 모든 걸 개발자가 직접 챙기는 건 규모가 커지면 불가능에 가까워요. 리액트의 핵심 가치는 성능의 최저 하한선을 자동으로 지켜주는 것이에요.

렌더링이라는 단어의 두 얼굴

"렌더링"이라는 단어를 리액트와 브라우저가 완전히 다른 의미로 써요.

리액트의 렌더링: 컴포넌트 함수를 호출해서 새 가상 돔 스냅샷을 찍고 이전 것과 비교하는 JS 계산 과정이에요.
브라우저의 렌더링: 리액트가 DOM에 변경사항을 반영한 뒤 브라우저가 Layout → Paint → Composite를 거쳐 픽셀을 그리는 과정이에요.

리액트 렌더링이 일어났다고 해서 반드시 브라우저 렌더링(Reflow, Repaint)이 일어나는 건 아니에요. 이 구분이 최적화 포인트를 찾는 데 핵심이에요.

가상 돔과 Diffing

가상 돔(Virtual DOM)은 실제 DOM이 아닌 노드 정보를 담은 가벼운 JS 객체예요.

// 가상 돔 객체의 실제 생김새
{
  type: 'div',
  props: {
    className: 'container',
    style: { color: 'red' }
  },
  children: [
    {
      type: 'h1',
      props: { id: 'title' },
      children: ['안녕하세요']
    }
  ]
}

이 JS 객체를 이전 것과 비교(Diffing)해서 바뀐 부분만 찾아내고 그 차이점만 실제 DOM에 딱 한 번 반영(Patching)해요.

두 트리를 완전히 비교하면 원래 O(n³)의 비용이 들어요. 노드 수가 1000개면 10억 번의 비교가 필요한 셈이에요. 리액트는 두 가지 휴리스틱으로 이 비용을 O(n)으로 줄였어요.

타입 가정: 부모 노드의 타입이 바뀌면 자식 트리 전체를 폐기하고 새로 만들어요. <div>가 <section>으로 바뀌면 그 안의 자식들을 일일이 비교하지 않고 전부 버리는 거예요.
Key 가정: 같은 레벨의 자식 목록에서 Key가 같은 노드는 동일한 노드로 보고 재사용해요. Key가 없으면 순서에 의존해야 해서 목록 중간에 아이템이 삽입될 때 취약해져요.

가상 돔이 실제 DOM보다 항상 빠른 건 아니에요. 연산을 한 겹 더 얹는 거라서 단순한 변경이라면 직접 DOM 조작이 더 빠를 수 있어요. 하지만 리액트의 진가는 "누가 코드를 짜더라도 성능의 최저 하한선을 지켜주는 것"에 있어요.

Key와 재조정

Key 가정에서 이어지는 얘기인데요. 리액트는 Key를 보고 노드를 재사용할지 결정해요. key={index}를 쓰면 배열 중간에 아이템이 추가될 때 인덱스가 밀리고 리액트는 멀쩡한 노드를 전부 업데이트해요. 더 심각한 건 Input 같은 내부 상태가 엉뚱한 위치로 붙어다니는 버그예요. 데이터 불일치 버그 중에 원인 찾기 제일 어려운 부류가 여기서 나와요.

Key는 전역 유일하지 않아도 돼요. 같은 배열 안에서만 유일하면 돼요. UUID를 매번 새로 생성해서 key로 쓰면 렌더링마다 key가 바뀌어서 리액트가 항상 새 노드로 인식하고 재사용을 못 해요.

useEffect vs useLayoutEffect

Key만큼이나 중요한 게 리액트가 DOM을 언제 읽고 쓰느냐예요. 훅의 실행 타이밍을 잘못 잡으면 브라우저 Paint와 충돌해서 깜빡임(Flickering)이 생겨요.

// useEffect: Paint가 끝난 뒤 비동기 실행 → 깜빡임 발생 가능
useEffect(() => {
  const rect = element.getBoundingClientRect();
  setTooltipPosition(rect); // 화면 그린 후 실행 → 위치 재계산으로 깜빡임
}, []);

// useLayoutEffect: Paint 직전에 동기 실행 → 깜빡임 없음
useLayoutEffect(() => {
  const rect = element.getBoundingClientRect();
  setTooltipPosition(rect); // Paint 직전 실행 → 사용자 눈에 보이지 않음
}, []);

useLayoutEffect는 동기로 실행되니까 무거운 작업을 여기서 하면 Paint가 블로킹돼요. DOM 수치 측정이나 즉각적인 스타일 동기화처럼 정말 필요한 경우에만 써야 해요.

React Fiber: 중단 가능한 렌더링

5000개 아이템 리스트를 렌더링하면 어떻게 될까요? 과거 리액트(Stack Reconciler)는 재조정이 시작되면 멈출 수 없었어요. 컴포넌트 트리를 콜 스택을 따라 재귀적으로 내려가는 구조였기 때문에 렌더링 도중엔 메인 스레드를 꽉 잡고 있어서 사용자 입력이 씹히는 프리징(Freezing) 현상이 생겼어요. 사람이 타이핑할 때 100ms 이상 반응이 없으면 "앱이 죽었나?"라고 느껴요.

Fiber는 그 한계를 근본적으로 뜯어고친 내부 재설계예요.

재귀에서 연결 리스트로

Stack Reconciler의 근본 문제는 재귀 호출이에요. 재귀는 중간에 멈출 수 없어요. Fiber는 이 구조를 연결 리스트(Linked List)로 바꿨어요.

// Fiber 노드의 개념적 구조
{
  type: MyComponent,
  stateNode: 컴포넌트_인스턴스,
  return: 부모_Fiber,   // 위로 올라가는 포인터
  child: 자식_Fiber,    // 아래로 내려가는 포인터
  sibling: 형제_Fiber,  // 옆으로 가는 포인터
  pendingProps: {},
  memoizedState: {}
}

각 Fiber 노드가 다음 노드의 포인터를 가지니까 중간에 작업을 멈추고 포인터만 저장해두면 나중에 정확히 그 지점부터 재개할 수 있어요.

스케줄링과 동시성 모드

Fiber는 렌더링을 작은 단위로 쪼개서 관리해요.

약 5ms마다 작업을 멈추고 급한 일이 있는지 확인해요.
급한 입력이 있으면 제어권을 먼저 넘기고 나중에 재개해요.
Current 트리와 Work-in-progress 트리를 분리(Double Buffering)해서 완성되지 않은 UI가 화면에 노출되는 걸 방지해요.

더블 버퍼링 (Double Buffering)

리액트가 계산 중인 어설픈 상태를 사용자에게 들키지 않는 비결은 무엇일까요? 리액트는 마치 연극 무대를 교체하듯 두 개의 트리를 관리하는 '더블 버퍼링' 전략을 사용해요.

Current 트리: 현재 관객이 보고 있는 '공연 중인 무대'예요.
Work-in-progress(WIP) 트리: 무대 뒤에서 소품을 배치하고 조명을 조절하는 '준비 중인 무대'예요.

이 과정은 다음과 같은 단계로 정교하게 진행됩니다

무대 뒤에서 준비 (Render Phase): 렌더링 내내 리액트는 오직 WIP 트리만 수정해요. 이때 실제 화면인 Current 트리는 전혀 건드리지 않고 그대로 유지하죠.
완성 후 한 번에 교체 (Commit Phase): 모든 계산과 소품 배치가 완벽히 끝나면 리액트는 단 한 번의 조작으로 두 무대의 위치를 순식간에 바꿔요(Swap).
원자적(Atomic) 실행: 이 교체 작업은 '전부 아니면 전무(All or Nothing)'로 처리되요. 덕분에 사용자는 소품이 하나씩 배치되는 과정 없이 늘 완성된 프레임만 보게 되요.

Git에서 feature 브랜치 작업을 마치고 main에 한 번에 머지하는 것과 같은 원리예요.

const [isPending, startTransition] = useTransition();

function handleInput(e) {
  // 즉각 반응이 필요한 작업 (Urgent)
  setInputValue(e.target.value);

  // 조금 늦어도 되는 작업 (Transition)
  startTransition(() => {
    setSearchResults(heavyFilter(e.target.value));
  });
}

startTransition 안의 작업은 타이핑 중에 새 입력이 들어오면 기존 계산을 폐기하고 입력에 먼저 반응해요. "빠른 렌더링"이 아니라 "우선순위에 따른 선택적 렌더링"이에요.

componentWillMount가 Unsafe 판정을 받은 이유도 여기에 있어요. Fiber에서 Render Phase는 언제든 멈추거나 버려지거나 다시 시작될 수 있어요. componentWillMount에서 API를 호출하면 여러 번 실행될 수 있는 부작용이 생겨요. 부수 효과는 반드시 Commit Phase 이후인 useEffect에서 처리해야 해요.

정리

브라우저 파싱 차단부터 Fiber 스케줄링까지 쭉 이어지는 이 흐름의 핵심은 결국 하나예요.
메인 스레드를 얼마나 잘게 쪼개서 사용자에게 제어권을 돌려주느냐가 성능 최적화의 본질이에요.

개념만 읽고 넘어가면 금방 잊히는데 Chrome DevTools Performance 탭을 열어서 직접 타임라인을 찍어보면 달라져요.
녹화 후 타임라인에서 보라색 블록이 Layout, 초록색이 Paint, startTransition 적용 전후로 Long Task(빨간 삼각형)가 사라지는 걸 눈으로 보면 이 글에서 다룬 개념들이 타임라인 위 어디에 해당하는지 바로 보여요.

참고 자료

관태

어제보다 나은 오늘

이전 포스트

🔥 LLM — 프롬프트 엔지니어링과 컨텍스트 엔지니어링

다음 포스트