09. 🚀 웹 성능 최적화와 Core Web Vitals

📌 이 면접 항목의 목표

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

🗺️ 이 챕터의 흐름
[개념 사전] → [질문 1: Core Web Vitals (LCP/CLS)] → [질문 2: 코드 분할 & 번들 최적화] → [실전 변형 질문]

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

• LCP, CLS 등 핵심 성능 지표의 의미와 구체적인 개선 방법을 제시합니다.
• Dynamic Import를 통해 초기 로딩 속도를 획기적으로 줄이는 전략을 세웁니다.
• 브라우저의 렌더링 파이프라인(CRP)과 연계된 성능 병목 지점을 진단합니다.

📚 핵심 개념 사전 (Concept Glossary)

1. LCP (Largest Contentful Paint)

페이지의 주요 콘텐츠(가장 큰 이미지나 텍스트 블록)가 화면에 나타나는 데 걸리는 시간입니다. 사용자에게 '페이지가 실제로 로딩되었다'고 느끼게 하는 결정적인 지표입니다.

2. CLS (Cumulative Layout Shift)

로딩 도중 예상치 않게 레이아웃이 움직이는 정도를 측정합니다. 버튼을 누르려는데 갑자기 이미지가 뜨면서 버튼이 아래로 밀리는 등의 불쾌한 경험을 수치화한 것입니다.

3. 코드 분할 (Code Splitting)

하나의 거대한 자바스크립트 번들을 여러 개의 작은 조각으로 나누는 기술입니다. 당장 필요하지 않은 코드는 나중에 로딩하여 초기 구동 속도를 높입니다.

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

• 🐣 영철 (후반): "영호 님! '영수네 메인 페이지' 라이트하우스(Lighthouse) 점수가 빨간색입니다. 특히 이미지가 늦게 떠서 사용자가 첫 화면을 불안하게 볼 것 같아요."
• 🦁 영호 (리드): "영철 님, 점수 자체보다 중요한 건 사용자의 체감입니다. 이미지가 늦게 뜨는 건 소스가 무거워서일 수도 있지만, 브라우저가 이미지의 자리를 미리 몰라서 레이아웃이 움직이기 때문일 수도 있죠. 지표와 사용자 흐름을 함께 봅시다."

면접 질문 1. Core Web Vitals 중 LCP와 CLS 지표를 개선하기 위한 구체적인 전략을 설명해 보세요.

🎯 출제 의도

현대적인 웹 성능 지표를 이해하고 있는지, 그리고 이를 단순히 아는 것을 넘어 실제 코드로 어떻게 개선할 수 있는지(예: 이미지 태그 속성, 폰트 로딩 등) 확인합니다.

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

영철이는 이미지 태그에 크기를 지정하지 않고, 모든 이미지를 한 번에 로딩하려 합니다.

<!-- 🐣 영철: "이미지가 알아서 크기에 맞춰 나오겠죠?" -->
<img src="/hero-banner.jpg" alt="메인 배너">
<!-- ⚠️ 문제:
   1. 이미지 로딩 전 크기를 몰라 CLS 발생 (레이아웃 흔들림)
   2. 최적화되지 않은 큰 용량으로 인해 LCP 지연
-->

🦁 영호의 리뷰 포인트
"영철 님, 브라우저는 예언자가 아니에요. 이미지 자리를 미리 잡아주지 않으면 그림이 그려질 때마다 전체 화면이 널뛰기를 합니다. 그리고 메인 이미지는 '가장 높은 우선순위'로 받아야죠."

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

영호 리드가 제안하는 성능 최적화의 정석입니다.

<!-- 🦁 영호: "브라우저에게 크기, 우선순위, 포맷 힌트를 함께 주세요." -->
<img
  src="/hero-banner.webp"
  width="1200"
  height="600"
  style="aspect-ratio: 2 / 1; width: 100%; height: auto;"
  fetchpriority="high"
  alt="메인 배너"
>

width와 height는 CLS를 줄이기 위해 이미지가 로드되기 전 공간을 예약합니다. fetchpriority="high"는 LCP 후보처럼 첫 화면에서 중요한 이미지에만 신중하게 쓰고, 나머지 이미지는 기본 우선순위나 lazy loading에 맡기는 편이 좋습니다.

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

• Level 1 (Junior): "LCP는 로딩 속도, CLS는 화면 흔들림입니다. 이미지를 작게 만들고 크기를 지정하면 좋아집니다."
• Level 2 (Senior): "LCP 개선을 위해 서버 응답 시간(TTFB) 단축, 불필요한 자바스크립트 실행 차단, 이미지 최적화(WebP, Lazy Loading) 전략을 제시합니다. CLS 방지를 위해 이미지와 광고 영역의 Aspect-ratio 확보, 폰트 로딩 최적화(font-display: swap) 등을 설명합니다."
• Level 3 (Specialist): "사용자 기기별 네트워크 환경에 따른 'Adaptive Loading' 전략을 설명합니다. 또한 브라우저의 전처리 지시자(preload, preconnect)를 전략적으로 배치하여 임계 경로(Critical Path)의 자원을 선점하는 고도화된 최적화 기법을 제안합니다."

면접 질문 2. 리액트 애플리케이션에서 코드 분할(Code Splitting)을 적용하는 방법과, 이를 통해 얻는 정량적인 이점은 무엇인가요?

🎯 출제 의도

불필요한 자원 낭비를 줄이려는 아키텍처적 노력을 확인합니다. 모든 코드를 한 번에 다운로드하는 '모놀리식 번들'의 위험성을 인지하고 있는지 평가합니다.

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

영철이는 모든 컴포넌트와 라이브러리를 최상단에서 정적으로 임포트합니다.

// 🐣 영철: "나중에 쓸 수도 있으니 미리 다 불러올게요!"
import HeavyChart from './components/HeavyChart'; // ⚠️ 5MB 짜리 차트 라이브러리
import AdminPanel from './components/AdminPanel'; // ⚠️ 일반 유저는 안 보는 관리자 페이지
 
function App({ user }) {
  return (
    <div>
      <MainContent />
      <HeavyChart />
      {user.role === 'admin' ? <AdminPanel /> : null}
    </div>
  );
}

🦁 영호의 리뷰 포인트
"영철 님, 집 이사할 때 모든 짐을 한 손에 들고 가려는 거랑 같아요. 1년에 한 번 쓰는 물건(관리자 페이지)은 창고에 두었다가 필요할 때만 꺼내 써야죠. 그게 바로 Dynamic Import입니다."

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

영호 리드가 React.lazy와 Suspense를 활용한 번들 다이어트법을 보여줍니다.

// 🦁 영호: "사용자가 그 페이지에 도달할 때까지 코드를 다운로드하지 마세요."
 
import { lazy, Suspense } from 'react';
 
// ✅ 필요할 때만 불러오는 동적 임포트
const HeavyChart = lazy(() => import('./components/HeavyChart'));
const AdminPanel = lazy(() => import('./components/AdminPanel'));
 
function App({ user }) {
  return (
    <Suspense fallback={<Skeleton />}>
      <MainContent />
      {/* 차트와 관리자 코드는 이 경로가 실제로 필요해질 때 별도 chunk로 가져온다. */}
      {user.showChart ? <HeavyChart /> : null}
      {user.role === 'admin' ? <AdminPanel /> : null}
    </Suspense>
  );
}

코드 분할은 초기 JavaScript를 줄이는 데 도움이 되지만 모든 컴포넌트를 나누는 것이 정답은 아닙니다. 사용자가 자주 지나가는 경로에 작은 chunk가 너무 많아지면 요청과 로딩 경계가 늘 수 있으므로, 번들 분석과 실제 사용자 흐름을 함께 봐야 합니다.

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

• Level 1 (Junior): "React.lazy를 쓰면 컴포넌트를 나중에 불러올 수 있어서 초기 속도가 빨라집니다."
• Level 2 (Senior): "라우트 단위(Route-based) 및 컴포넌트 단위(Component-based) 분리 전략을 설명합니다. 이를 통해 TBT(Total Blocking Time)와 TTI(Time to Interactive) 지표를 개선할 수 있음을 정량적으로 언급합니다."
• Level 3 (Specialist): "번들 분석 도구(Webpack Bundle Analyzer 등)를 활용해 중복 라이브러리를 제거하고, 'Shared Chunk' 전략을 통해 공통 모듈의 캐싱 효율을 높이는 법을 설명합니다. 또한 리액트 서버 컴포넌트(RSC)를 활용해 브라우저로 보내는 JS 자체를 줄이는 최상위 최적화 개념을 제시합니다."

🔗 실전 변형 질문 (Related Variations)

면접 질문 145. 브라우저의 렌더링 파이프라인(CRP) 최적화란 무엇인가요?

• 🎯 출제 의도: HTML/CSS가 화면에 그려지기까지의 전 과정을 이해하고 병목을 찾아낼 수 있는지 확인합니다.
• 💡 핵심 원리 & 답변: CRP 최적화는 DOM과 CSSOM 생성을 방해하는 요소(Critical Resources)를 줄이는 작업입니다. CSS는 <head> 상단에 배치하여 렌더링 차단을 방지하고, JS는 async나 defer 속성을 써서 파싱을 방해하지 않게 해야 합니다. 또한 미디어 쿼리를 사용해 필요한 기기에서만 특정 CSS를 로드하게 하거나, 인라인 스타일링을 통해 최초 화면(Above the fold)에 필요한 스타일을 빠르게 제공하는 기법이 포함됩니다.

면접 질문 152. 서비스 워커(Service Worker)를 활용한 성능 개선 사례를 들어보세요.

• 🎯 출제 의도: 네트워크 계층에서의 최적화와 오프라인 경험(PWA)에 대한 이해도를 확인합니다.
• 💡 핵심 원리 & 답변: 서비스 워커는 브라우저와 네트워크 사이의 프록시 역할을 합니다. 정적 자산(JS, CSS, Image)을 로컬에 전략적으로 캐싱하여 재방문 시 네트워크 호출을 줄일 수 있습니다. 또한 네트워크 불안정 시에도 오프라인 페이지를 보여주거나, 백그라운드에서 데이터를 페칭하여 최신 상태를 유지하는 'Background Sync'를 통해 사용자 체감 성능을 개선할 수 있습니다.

면접 질문 160. 웹 폰트 로딩 성능을 최적화하는 방법은 무엇인가요?

• 🎯 출제 의도: 폰트 로딩 시 발생하는 텍스트 미표시(FOIT)나 갑작스러운 글꼴 변경(FOUT) 문제를 제어할 수 있는지 확인합니다.
• 💡 핵심 원리 & 답변: 첫째, preload를 통해 폰트 파일을 우선순위 있게 로드합니다. 둘째, font-display: swap; 속성을 사용하여 폰트 로딩 중에는 시스템 폰트를 먼저 보여줌으로써 LCP 지표를 방어합니다. 셋째, 폰트 파일의 서브셋(Subset)을 만들어 필요한 언어만 포함하거나 WOFF2와 같은 압축률 높은 포맷을 사용하여 용량을 줄이는 것이 핵심입니다.

📝 마무리 퀴즈

Q1. LCP 개선을 설명할 때 단순히 "이미지를 줄인다"보다 더 구체적으로 말해야 할 내용은 무엇인가요?

✅ 정답: 가장 큰 콘텐츠가 무엇인지 식별하고, 이미지 크기/포맷/우선순위/서버 응답 시간을 함께 줄이는 전략

💡 상세 해설:

• 원리 설명: LCP는 사용자가 주요 콘텐츠를 언제 보느냐의 문제입니다. 이미지 최적화뿐 아니라 preloading, fetchpriority, CDN, SSR 응답 시간도 함께 봐야 합니다.
• 오답 피드백: Lighthouse 점수만 외우면 실제 병목이 네트워크인지 렌더링인지, 이미지 자리 예약인지 설명하기 어렵습니다.
• 📌 핵심 기억법: LCP는 가장 큰 요소의 여행 시간을 줄이는 일입니다.

Q2. CLS를 줄이기 위해 이미지에 width와 height 또는 aspect-ratio를 주는 이유는 무엇인가요?

✅ 정답: 리소스가 로드되기 전에도 브라우저가 공간을 예약해 예기치 않은 레이아웃 이동을 막기 위해서

💡 상세 해설:

• 원리 설명: 브라우저가 이미지 크기를 모르면 로딩 후 박스 크기가 바뀌며 주변 콘텐츠가 밀립니다. 이 흔들림은 사용자의 클릭 실수와 불신으로 이어집니다.
• 오답 피드백: 단지 예쁜 비율을 맞추기 위한 속성이 아닙니다. 레이아웃 안정성을 위한 성능 속성입니다.
• 📌 핵심 기억법: 늦게 뜰 요소일수록 자리부터 예약합니다.

Q3. 영철이의 테스트 타임: 코드 분할을 적용하기 전 가장 먼저 확인할 것은 무엇인가요?

✅ 정답: 초기 렌더링에 필요하지 않은 무거운 기능이 번들에 포함되어 있는지 bundle analyzer와 실제 사용자 흐름으로 확인한다

💡 상세 해설:

• 원리 설명: 코드 분할은 초기 JS 비용을 줄이는 데 좋지만, 너무 잘게 나누면 요청 수와 로딩 경계가 늘어날 수 있습니다. 실제 사용자 여정에서 늦게 필요한 기능을 찾아야 합니다.
• 오답 피드백: 모든 컴포넌트를 dynamic import로 바꾸는 건 전략이 아니라 분산된 지연입니다.
• 📌 핵심 기억법: 지금 필요한 코드와 나중에 필요한 코드를 구분합니다.

🐣 영철이의 퇴근 일기

오늘은 성능을 "점수 올리기"가 아니라 사용자가 기다리는 시간을 줄이는 일로 다시 보게 됐다. LCP, CLS 같은 지표가 숫자처럼 보였지만, 사실은 영수네 커뮤니티 사용자가 첫 화면을 믿고 클릭할 수 있는지에 대한 약속이었다.

💡 "성능 최적화는 빠른 척하는 기술이 아니라, 사용자가 기다리지 않아도 되는 이유를 하나씩 만드는 일이다."

다음부터는 "느려요"라는 제보를 받으면 Lighthouse 점수만 찍지 말고, 어떤 사용 흐름에서 어떤 지표가 흔들리는지 먼저 적어야겠다. 영철이 이제 성능을 감상이 아니라 증거로 말하는 개발자에 가까워지고 있다.