01. 🌐 브라우저 렌더링과 CRP의 심층 원리

📌 이 면접 항목의 목표

⏱️ 예상 읽기 시간: 20분 (핵심 요약: 10분)

🗺️ 이 챕터의 흐름
[개념 사전] → [질문 1: 렌더링 파이프라인] → [질문 2: Reflow/Repaint 최적화] → [질문 3: 애니메이션 성능]

🎯 이 챕터를 다 읽으면 할 수 있는 것

• 브라우저의 주요 렌더링 파이프라인을 단계별로 설명할 수 있습니다.
• 레이아웃 스래싱(Layout Thrashing)의 원인과 해결책을 제시할 수 있습니다.
• GPU 가속이 일어나는 조건과 그 기회비용을 논리적으로 설명합니다.

📚 핵심 개념 사전 (Concept Glossary)

질문에 들어가기 전, 이 챕터를 관통하는 핵심 용어들을 먼저 정리합니다.

1. CRP (Critical Rendering Path)

브라우저가 HTML, CSS, JavaScript를 수신하여 실제 픽셀로 변환하기까지의 일련의 단계를 의미합니다. 이 경로를 최적화하는 것이 곧 웹 성능 최적화의 시작입니다.

2. 레이아웃 스래싱 (Layout Thrashing)

JavaScript 코드가 DOM을 변경하고 즉시 기하학적 정보(offsetWidth, scrollTop 등)를 읽으려 할 때, 브라우저가 최적화를 포기하고 강제로 레이아웃을 다시 계산하게 만드는 현상입니다. 메인 스레드를 차단하는 주범입니다.

3. 컴포지팅 (Compositing)

화면의 각 부분을 별도의 레이어로 나누어 그린 뒤, 마지막에 하나로 합성하는 단계입니다. transform, opacity 변경은 레이아웃 계산을 다시 하지 않고 합성 단계에서 처리될 수 있어 애니메이션 성능에 유리합니다. 다만 레이어가 늘면 GPU 메모리도 함께 사용합니다.

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

• 🐣 영철 (초반): "영호 님! 이번에 '영수네 게시판' 무한 스크롤을 구현했는데, 스크롤할 때마다 화면이 끊겨요. 분명 사양 좋은 맥북인데 왜 이럴까요?"
• 🦁 영호 (리드): "영철 님, 화면이 끊긴다는 건 브라우저가 초당 60프레임을 유지하지 못하는 구간이 있다는 뜻이에요. 단순히 코드가 실행되는지만 보지 말고, 브라우저가 HTML과 CSS를 픽셀로 바꾸는 순서를 따라가 봅시다."

면접 질문 1. 브라우저의 렌더링 과정을 단계별로 설명해 보세요.

🎯 출제 의도

지원자가 단순히 프레임워크 사용법을 넘어, 웹이 동작하는 하부 환경(Browser)의 메커니즘을 이해하고 있는지 확인합니다. 이는 성능 최적화 능력을 판단하는 가장 기초적인 척도입니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 게시물을 추가할 때마다 리스트 전체를 다시 그리는 비효율적인 방식을 사용했습니다.

// 🐣 영철: "데이터가 바뀌었으니 깔끔하게 새로 그려야지!"
function updateBoardList(posts) {
    const list = document.getElementById('board-list');
    list.innerHTML = ''; // ⚠️ 기존 DOM을 통째로 날리고 새로 생성 (비싼 비용)
 
    posts.forEach(post => {
        list.innerHTML += `<li>${post.title}</li>`; // ⚠️ 매 루프마다 문자열 파싱 & DOM 트리 재구성
    });
}

🦁 영호의 리뷰 포인트
"영철 님, innerHTML +=는 매 반복마다 기존 HTML을 다시 문자열로 만들고 파싱하게 만듭니다. 브라우저가 DOM 변경을 한 번에 모아 처리할 기회를 잃으니, 리스트가 커질수록 파싱과 렌더링 비용이 빠르게 늘어요."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드는 브라우저가 효율적으로 일할 수 있도록 DocumentFragment와 최적화된 API를 제안합니다.

// 🦁 영호: "브라우저에게 '최종 결과물'만 한 번에 던져주세요."
function updateBoardList(posts) {
    const list = document.getElementById('board-list');
    const fragment = document.createDocumentFragment(); // 메모리상 가상 컨테이너
 
    posts.forEach(post => {
        const li = document.createElement('li');
        li.textContent = post.title; // 텍스트만 안전하게 주입
        fragment.appendChild(li);
    });
 
    list.replaceChildren(fragment); // DOM 반영 지점을 한 번으로 모아 렌더링 비용을 줄임
}

이 개선은 "DOM을 전혀 바꾸지 않는다"가 아니라 DOM 변경 횟수와 파싱 비용을 줄인다는 점이 핵심입니다. 면접에서는 textContent를 사용해 HTML 삽입 위험을 줄인 점까지 함께 말하면 더 설득력 있습니다.

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "HTML로 DOM 트리, CSS로 CSSOM 트리를 만듭니다. 이 둘을 합쳐 Render Tree를 만들고, 요소의 크기와 위치를 정하는 Layout, 색을 칠하는 Paint 단계를 거쳐 화면에 보여줍니다."
• Level 2 (Senior): "Render Tree에는 display: none 같은 요소는 포함되지 않음을 언급합니다. Layout 이후 Paint 단계에서 레이어가 나누어지며, 마지막에 Composite 단계에서 레이어가 합성된다는 점을 설명합니다. transform 속성이 왜 빠른지 파이프라인 관점에서 연결합니다."
• Level 3 (Specialist): "하드웨어 가속(GPU)이 일어나는 특정 조건(Will-change 등)을 설명하고, 무분별한 레이어 생성이 메모리 부족(Memory Bloat)을 유발할 수 있다는 트레이드오프를 제시합니다. 브라우저 엔진(V8, Blink 등)의 최적화 전략과 연관 지어 답변합니다."

면접 질문 2. 리플로우(Reflow)와 리페인트(Repaint)의 차이와 최적화 전략을 설명해 보세요.

🎯 출제 의도

단순히 용어를 아는지 묻는 것이 아니라, DOM 조작이 브라우저 내부 프로세스에 미치는 '비용(Cost)'을 이해하고 있는지, 그리고 이를 최소화하는 코딩 습관을 갖추고 있는지 평가합니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 스크롤 위치를 확인하고 싶어서 scrollTop을 읽은 직후, style.height를 변경했습니다. 이 순서 때문에 브라우저가 레이아웃 캐시를 버리고 즉시 다시 계산해야 하는 상황이 생겼습니다.

// 🐣 영철: "스크롤 위치를 확인하고, 그에 맞춰 높이를 조절해야지!"
function adjustLayout() {
    const container = document.getElementById('container');
 
    // ⚠️ 1. 읽기 (Read): 레이아웃 정보 요청
    const currentScroll = container.scrollTop;
 
    // ⚠️ 2. 쓰기 (Write): 레이아웃 변경
    container.style.height = (currentScroll + 100) + 'px';
 
    // ⚠️ 3. 다시 읽기 (Read): 방금 바뀐 높이를 다시 확인해야 함!
    console.log(container.offsetHeight); // ❌ 여기서 Reflow 강제 발생!
}

🦁 영호의 리뷰 포인트
"영철 님, scrollTop을 읽고 바로 height를 바꾸면 브라우저는 '아차, 방금 바뀐 높이로 다시 계산해야겠네?'라며 1번부터 4번까지의 과정을 강제로 반복합니다. 이걸 **레이아웃 스래싱(Layout Thrashing)**이라고 해요. 메인 스레드가 멈추는 주범이죠."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드는 읽기와 쓰기 작업을 분리하여 브라우저가 한 번에 처리할 수 있도록 유도합니다.

// 🦁 영호: "읽을 건 다 읽고, 쓸 건 다 쓰세요. 중간에 끼어들지 마세요!"
function adjustLayoutOptimized() {
    const container = document.getElementById('container');
 
    // 1. 읽기 작업 모으기 (Read Batch)
    // 이 단계에서 브라우저는 필요한 정보를 최대한 캐싱합니다.
    const currentScroll = container.scrollTop;
    const currentHeight = container.offsetHeight;
 
    // 2. 쓰기 작업 모으기 (Write Batch)
    // 계산된 값으로 한 번에 스타일을 적용합니다.
    const nextHeight = Math.max(currentHeight, currentScroll + 100);
    container.style.height = `${nextHeight}px`;
}

쓰기 이후에 다시 offsetHeight를 읽으면 브라우저가 새 레이아웃을 계산해야 할 수 있습니다. 그래서 개선된 코드는 측정값을 먼저 모두 확보하고, 변경은 마지막에 한 번만 적용합니다.

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "Reflow는 요소의 크기나 위치가 바뀌어 레이아웃을 재계산하는 것이고, Repaint는 색상이나 배경 등 시각적 스타일만 바뀌어 다시 그리는 것입니다. Reflow가 더 비용이 많이 듭니다."
• Level 2 (Senior): "Reflow는 DOM 트리 전체 또는 일부의 기하학적 구조를 재계산하는 과정입니다. width, height, margin, padding, font-size 변경 시 발생합니다. Repaint는 레이아웃은 유지된 채 색상만 바뀌는 경우입니다. color, background-color 변경 시 발생합니다."
• Level 3 (Specialist): "레이아웃 스래싱(Layout Thrashing)을 언급하며, 읽기(Read)와 쓰기(Write) 작업을 분리하는 것이 핵심 최적화 전략임을 설명합니다. 또한, transform, opacity를 사용하면 Reflow와 Paint 단계를 건너뛰고 Composite 단계에서 처리되어 가장 빠르다는 점을 연결합니다."

📝 마무리 퀴즈

Q1. 영수네 게시판 무한 스크롤이 버벅일 때, 영철이가 면접 답변에서 가장 먼저 설명해야 할 흐름은 무엇인가요?

✅ 정답: DOM/CSSOM 생성 → Render Tree → Layout → Paint → Composite로 이어지는 렌더링 파이프라인

💡 상세 해설:

• 원리 설명: 브라우저 성능 면접은 "React가 느려요"에서 시작하면 얕아집니다. 먼저 브라우저가 HTML, CSS, JS를 어떤 단계로 픽셀까지 바꾸는지 말해야 병목을 좁힐 수 있습니다.
• 오답 피드백: useMemo나 debounce부터 말하면 도구 이야기는 할 수 있지만, Reflow와 Paint 중 어디가 문제인지 설명하지 못합니다.
• 📌 핵심 기억법: 화면이 느리면 먼저 브라우저의 공정표부터 펼칩니다.

Q2. 영호가 scrollTop을 읽고 바로 style.height를 바꾸는 코드를 지적한 이유는 무엇인가요?

✅ 정답: 읽기와 쓰기가 섞여 브라우저가 강제 Layout을 반복하는 레이아웃 스래싱이 발생하기 때문

💡 상세 해설:

• 원리 설명: 레이아웃 정보를 읽은 뒤 스타일을 바꾸고 다시 읽으면 브라우저는 캐시한 레이아웃을 버리고 즉시 다시 계산해야 합니다. 스크롤, 애니메이션, 대량 DOM 조작에서 프레임 드롭으로 이어집니다.
• 오답 피드백: 단순히 style.height가 나쁘다는 뜻이 아닙니다. 문제는 읽기와 쓰기를 섞어 브라우저의 최적화 기회를 빼앗는 순서입니다.
• 📌 핵심 기억법: 측정은 모아서 읽고, 변경은 모아서 씁니다.

Q3. 영철이의 테스트 타임: 무한 스크롤 개선 전 가장 설득력 있는 검증 방법은 무엇인가요?

✅ 정답: Performance 패널로 Layout/Paint/Composite 비용을 확인하고, DOM 조작을 batch 처리한 전후 프레임 변화를 비교한다

💡 상세 해설:

• 원리 설명: 면접에서 좋은 답변은 "이렇게 고쳤습니다"가 아니라 "이 지표가 병목이었고, 이 변경으로 이렇게 줄었습니다"까지 이어집니다.
• 오답 피드백: 체감상 빨라졌다는 말만으로는 재현성과 설득력이 부족합니다.
• 📌 핵심 기억법: 성능 답변은 감상이 아니라 타임라인으로 말합니다.

🐣 영철이의 퇴근 일기

오늘은 면접 답변을 외우는 대신, 화면이 느릴 때 브라우저 안에서 어떤 일이 벌어지는지 순서대로 말하는 연습을 했다. 예전 같으면 "React 최적화하면 됩니다"라고 답했을 텐데, 이제는 Layout과 Paint가 어디서 반복되는지 먼저 확인해야 한다는 걸 알았다.

💡 "성능 문제는 감으로 잡는 게 아니라, 브라우저가 지나간 발자국을 따라가며 좁혀야 한다."

내일부터는 스크롤이나 애니메이션 이슈를 만나면 바로 코드를 뜯기 전에 Performance 패널부터 켜야겠다. 영호 님이 말한 "읽기는 읽기끼리, 쓰기는 쓰기끼리"라는 기준 하나만 붙잡아도 오늘의 나는 어제보다 덜 막연한 개발자가 된 것 같다.

🔗 더 알아보기

• MDN: Critical Rendering Path
• Web.dev: Avoid Large, Complex Layouts and Layout Thrashing