Optimizing Code Splitting and Lazy Loading: Claude Code 활용 가이드

먼저 나눌 경계를 정하기

코드 스플리팅은 모든 파일을 작게 쪼개는 작업이 아닙니다. 첫 화면에는 제목, 가격, CTA, 주요 폼처럼 매출과 신뢰에 필요한 코드만 남기고, 차트, 지도, 리치 텍스트 에디터, 관리자 도구, 동영상 플레이어처럼 늦게 써도 되는 기능을 뒤로 미루는 작업입니다.

함께 볼 글은 성능 최적화, Next.js 개발, Playwright 테스트 입니다. 공식 문서는 React lazy 와 Next.js dynamic imports를 확인하세요.

먼저 용어를 정리한다

bundle은 브라우저로 보내는 JavaScript의 묶음입니다. chunk는 코드 분할 후에 생기는 작은 파일입니다. dynamic import는 import("./Chart")처럼 실행 시점에 모듈을 불러오는 구조입니다. Suspense는 아직 불러오는 중인 컴포넌트 대신 로딩 UI를 보여 주는 경계입니다.

hydration은 서버가 반환한 HTML에 브라우저 쪽 JavaScript가 이벤트와 상태를 다시 연결하는 처리입니다. 여기서 서버와 클라이언트의 표시가 어긋나면 hydration error가 납니다. 지연 로딩은 편리하지만, 브라우저에서만 동작하는 처리, 시각, 난수, window 참조를 섞으면 이 어긋남을 일으키기 쉽습니다.

코드 분할에서 노려야 할 곳은 첫 표시에 불필요하고, 크기가 크며, 사용자 조작 후에 필요해지는 부분입니다. 반대로 첫 화면의 제목, 본문, 구매 버튼, 내비게이션 같은 중요 UI는 함부로 지연 로딩하지 않습니다.

대상	분할하기 쉬운 이유	주의점
관리·설정 화면	일반 독자에게는 불필요	인증 후 로딩을 짧게
그래프·지도·에디터	의존 라이브러리가 무거움	표시 영역을 고정해 layout shift 방지
모달·위저드	클릭 후에만 필요	첫 클릭이 너무 느리면 사전 로딩
동영상·음성·검색 UI	초기 표시와 관련이 적음	접근성과 오류 문구를 넣음

Claude Code 프롬프트

이 React/Next.js 화면에서 안전한 code splitting 후보를 찾아 주세요.
첫 화면 제목, 가격, CTA, 주요 폼은 지연 로딩하지 마세요.
차트, 에디터, 지도, 관리자 패널, 동영상은 lazy load 후보로 검토하세요.
lazy/Suspense 또는 dynamic import 코드, fallback UI, error boundary, 검증 체크리스트를 주세요.

Use case checklist

글 페이지: 본문과 CTA는 즉시 표시하고, 댓글과 공유 패널은 늦게 로드합니다.
SaaS dashboard: KPI는 먼저 보여주고, 상세 차트와 export 기능은 분리합니다.
관리자 화면: 권한 편집기, 감사 로그, 설정 화면은 route 단위로 나눕니다.
이커머스: 상품 정보와 구매 버튼은 우선, 추천과 리뷰와 영상은 이후에 로드합니다.

구현 예시

import { lazy, Suspense } from "react";

const HeavyChart = lazy(() => import("./HeavyChart"));

export function DashboardPanel() {
  return (
    <section>
      <h2>Revenue overview</h2>
      <Suspense fallback={<p role="status">Loading chart...</p>}>
        <HeavyChart />
      </Suspense>
    </section>
  );
}

import dynamic from "next/dynamic";

const RichTextEditor = dynamic(() => import("../components/RichTextEditor"), {
  loading: () => <p role="status">Loading editor...</p>,
  ssr: false,
});

Pitfall checklist

CTA까지 lazy load하면 전환 흐름이 느려집니다.
fallback 높이가 고정되지 않으면 layout shift가 생깁니다.
error boundary가 없으면 lazy component 실패 시 화면이 비어 보일 수 있습니다.
너무 잘게 쪼개면 request가 늘어 느린 네트워크에서 불리합니다.
dev server만 보지 말고 production build chunk를 확인해야 합니다.

첫 클릭이 느리면 사전 로딩을 검토한다

지연 로딩의 단점은 “필요해진 순간에 비로소 내려받기 시작”한다는 점입니다. 모달이나 에디터처럼 클릭 직후에 바로 보여야 하는 컴포넌트는, 이 첫 다운로드 대기가 그대로 사용자가 느끼는 지연이 됩니다. 이때는 사용자가 버튼에 마우스를 올리거나 포커스를 주는 시점에 미리 import()를 한 번 호출해 두는 사전 로딩이 효과적입니다. 즉, 첫 화면 번들에는 넣지 않되, 클릭보다 살짝 앞서 청크를 준비하는 절충안입니다.

다만 사전 로딩을 남발하면 결국 초기 네트워크가 다시 바빠집니다. 자주 쓰는 한두 개 컴포넌트에만 적용하고, 나머지는 클릭 시 로딩으로 두는 편이 균형이 좋습니다. Claude Code에 의뢰할 때도 “어떤 컴포넌트를 사전 로딩하고, 어떤 컴포넌트는 클릭 시 로딩할지”를 분리해 적게 하면, 무분별하게 모든 동적 import에 prefetch가 붙는 일을 막을 수 있습니다.

검증 방법

build 후 Network waterfall과 bundle analyzer를 확인합니다. 모바일 375px에서 fallback이 레이아웃을 밀지 않는지, 코드 블록이 스크롤되는지, CTA가 보이는지 확인합니다. Claude Code review에는 지연한 컴포넌트, 이유, 위험, 되돌리는 방법이 포함되어야 합니다.

수익화 관점

코드 스플리팅은 광고, 상품 카드, 상담 폼, 구매 버튼의 표시 속도에 영향을 줍니다. 팀에 적용하려면 Claude Code 교육과 상담에서 성능 개선과 리뷰 절차를 함께 설계할 수 있습니다.

마이그레이션 순서

첫 단계는 코드를 고치지 않고 현황을 정리하는 것입니다. Claude Code에게 무거운 컴포넌트, 첫 화면 필수 컴포넌트, 늦게 로드해도 되는 상호작용, SEO나 전환율에 영향을 줄 수 있는 영역을 표로 만들게 합니다. 두 번째 단계에서 차트나 에디터 같은 낮은 위험 컴포넌트 하나만 분리합니다. 세 번째 단계에서 route 단위 분리를 검토합니다.

팀 review 템플릿

이번에 지연 로딩한 컴포넌트와 그 이유.
fallback 높이가 안정적인지, layout shift가 없는지.
첫 화면 CTA, 가격, 폼, 광고 영역이 즉시 보이는지.
네트워크 실패 시 error boundary가 동작하는지.
production build에서 chunk 크기와 이름이 예측 가능한지.

운영 지표

성공 여부는 Lighthouse 점수만으로 판단하지 않습니다. 검색 유입 페이지의 체류 시간, CTA 클릭률, 광고 viewability, 상담 폼 도달률을 같이 봅니다. JavaScript가 줄어도 전환율이 내려가면 좋은 변경이 아닙니다. Claude Code를 매일 작은 review에 쓰면 성능 개선과 매출 동선을 동시에 지킬 수 있습니다.

실전 검증 메모

첫 화면 CTA는 유지하고 차트와 에디터만 늦게 로드하는 방식으로 테스트했습니다. 과도한 분할보다 무거운 컴포넌트만 분리하는 쪽이 리뷰하기 쉽고 매출 동선도 안전했습니다. 특히 ssr: false로 둔 컴포넌트는 hydration 어긋남이 사라지는 대신 검색 노출에 영향을 줄 수 있어, 본문이나 SEO에 중요한 영역에는 쓰지 않는 편이 안전했습니다. fallback의 높이를 실제 컴포넌트와 맞춰 두는 작은 조정만으로도 layout shift가 눈에 띄게 줄었습니다.