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

📌 이 면접 항목의 목표

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

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

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

• 브라우저의 6단계 렌더링 파이프라인을 완벽히 설명할 수 있습니다.
• 레이아웃 스래싱(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프레임을 그려내는 '렌더링 파이프라인' 어딘가에서 병목이 생겼다는 뜻이에요. 단순히 코드가 돌아가는 걸 넘어, 브라우저가 어떻게 일하는지 알면 해결책은 바로 나옵니다. 자, 면접이라 생각하고 대답해 보세요."

Q1. 브라우저의 렌더링 과정을 단계별로 설명해 보세요.

🎯 출제 의도

지원자가 단순히 프레임워크 사용법을 넘어, 웹이 동작하는 하부 환경(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 조작으로 끝!
}

📊 레벨별 답변 가이드 (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 등)의 최적화 전략과 연관 지어 답변합니다."

Q2. 리플로우(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)
    // 계산된 값으로 한 번에 스타일을 적용합니다.
    container.style.height = (currentScroll + 100) + 'px';
    
    // 3. 이제 읽어도 안전합니다. (이미 계산된 값을 반환)
    console.log(container.offsetHeight); // ✅ Reflow 없음!
}

📊 레벨별 답변 가이드 (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 단계에서 처리되어 가장 빠르다는 점을 연결합니다."

🐣 영철이의 복기 일기

오늘 '영수네 게시판'의 성능 저하 원인을 찾았다. 리스트 하나 추가할 때마다 브라우저 심장을 쥐어짜고 있었구나... 😭 DocumentFragment라는 훌륭한 도구가 있는데 왜 쓰질 못했니!

💡 "브라우저의 렌더링 파이프라인은 정해진 신호 체계가 있는 고속도로와 같다. 내 코드가 역주행인지 순항인지 늘 체크하자."

내일은 이벤트 루프라는 신호등 체계를 영호 님께 제대로 배워봐야겠다. 퇴근하고 시원한 맥주 한 잔 하면서 오늘 복기 끝! 🍺

🔗 더 알아보기

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