🎧

객체지향 설계에서 자주 등장하는 디자인 패턴 중 하나가 바로 퍼사드(Facade) 패턴입니다.
이 패턴은 이름 그대로 “건물의 외관(Facade)” 처럼 내부의 복잡한 구조를 감추고,
사용자가 쉽게 접근할 수 있는 단순한 인터페이스를 제공하는 역할을 합니다.

퍼사드 패턴이란?

여러 개의 복잡한 서브시스템을 하나의 단순한 인터페이스로 감싸는 구조 패턴

즉, 내부적으로는 여러 객체가 협력하지만,
외부에서는 단 하나의 객체만 호출하면 되도록 만드는 패턴입니다.

왜 필요한가?

• 복잡한 라이브러리를 간단하게 사용하고 싶을 때
• 여러 API 호출을 하나의 함수로 묶고 싶을 때
• 레거시 코드와 신규 시스템을 연결해야 할 때
• 의존성을 줄이고 싶을 때

아래 예시를 통해 퍼사드 패턴의 장점을 이해해보자.

1. 퍼사드 패턴이 아닌 코드

class CPU {
  start() {
    console.log("CPU 시작");
  }
}

class Memory {
  load() {
    console.log("메모리 로드");
  }
}

class HardDrive {
  read() {
    console.log("하드디스크 읽기");
  }
}

const cpu = new CPU();
const memory = new Memory();
const hardDrive = new HardDrive();

cpu.start();
memory.load();
hardDrive.read();

이 코드에서 사용자는 각 Class 역할마다의 내부 동작을 전부 알아야 합니다.

2. 퍼사드 패턴 적용한 코드

class ComputerFacade {
  constructor() {
    this.cpu = new CPU();
    this.memory = new Memory();
    this.hardDrive = new HardDrive();
  }

  startComputer() {
    this.cpu.start();
    this.memory.load();
    this.hardDrive.read();
    console.log("컴퓨터 부팅 완료");
  }
}

const computer = new ComputerFacade();
computer.startComputer();

이제 사용자는 startComputer() 하나만 호출하면 됩니다.

프론트엔드 실무에서의 예시

프론트엔드 개발에서는 이런 식으로 자주 사용됩니다

1. API 래퍼 모듈

// apiFacade.js
export const loginUser = async (data) => {
  const token = await authAPI.login(data);
  await userAPI.fetchProfile(token);
};

컴포넌트에서는 복잡한 API 흐름을 몰라도 됩니다.

2. 복잡한 서드파티 라이브러리 감싸기

createSimpleChart(data)

예를 들어 차트 라이브러리를 사용할 때
초기 설정, 옵션 구성, 이벤트 바인딩이 복잡하다면

위 코드처럼 단순화해서 제공할 수 있습니다.

퍼사드 패턴의 장점

✔️ 코드 사용성 향상
✔️ 의존성 감소
✔️ 유지보수 용이
✔️ 시스템 복잡도 감소
✔️ 레이어 분리 가능

단점

❌ 퍼사드가 너무 많은 책임을 가지면 God Object가 될 수 있음
❌ 내부 서브 시스템 변경 시 퍼사드도 수정 필요

다른 패턴과의 차이

퍼사드 패턴은 여러 하위 시스템을 하나의 단순한 인터페이스로 감싸 외부 의존성을 줄이고 사용성을 높이는
구조 패턴입니다.
실무에서는 API 래퍼나 SDK 형태로 자주 활용됩니다.

언제 쓰면 좋을까?

• 서비스 레이어 구성 시
• BFF 계층 설계 시
• 내부 SDK 제작 시
• 디자인 시스템 유틸 통합 시

퍼사드 패턴은 거창한 이론이 아니라
우리가 실무에서 무의식적으로 자주 사용하는 설계 방식입니다.

복잡한 것을 단순하게 만들 수 있다면
그 자체로 좋은 설계입니다.

오늘은 브라우저 렌더링 방식인 SSG, CSR, SSR, ISR 내부 작동원리에 대해 살펴볼 것이다.

1. SSG (Static Site Generation) 작동원리

전체 흐름도

[빌드 타임]                    [런타임]
개발자 코드                     사용자 요청
    ↓                              ↓
npm run build                  CDN/Server
    ↓                              ↓
데이터 페칭 (API 호출)         정적 HTML 파일 전송
    ↓                              ↓
HTML 생성 (모든 페이지)        브라우저에서 즉시 렌더링
    ↓                              ↓
.next/static 폴더에 저장       (Hydration으로 인터랙티브)

1. 빌드타임(Build Time)

• 개발자가 코드를 작성하고 nun run build 명령어를 실행하면, 모든 페이지가 미리 HTML로 생성된다.
• 이 과정에서 필요한 데이터가 있다면 API를 호출해 가져오고, 가져온 데이터를 바탕으로 HTML 파일을 만들어 .next/static (Next라면) 같은 폴더에 저장한다.
• 즉, 사용자가 페이지를 요청하기 전 미리 모든 페이지를 준비하는 단계이다.

2. 런타임(Runtime)

• 사용자가 브라우저에서 페이지를 요청하면, 서버나 CDN이 미리 만들어둔 정적 HTML파일을 즉시 전송한다.
• 브라우저에서는 받은 HTML을 바로 화면에 보여주고, 필요하면 React의 Hydration 과정을 통해 인터랙티브 기능(버튼 클릭, 폼 입력 등)을 사용할 수 있다.

상세 작동 과정

1단계: 빌드 타임 (Build Time)

npm run build

내부에서 일어나는 일

1. Next.js가 모든 페이지 스캔
   ├─ app/page.tsx
   ├─ app/about/page.tsx
   ├─ app/blog/[slug]/page.tsx
   └─ ...

2. 각 페이지별로 실행:
   ├─ generateStaticParams() 호출 (동적 라우트)
   ├─ 데이터 페칭 함수 실행
   ├─ React 컴포넌트 렌더링
   └─ HTML 파일 생성

3. 출력물:
   ├─ .next/server/app/page.html
   ├─ .next/server/app/about.html
   ├─ .next/server/app/blog/post-1.html
   └─ JavaScript 번들 (.next/static/chunks/)

Next.js SSG 내부에서 일어나는 과정

1. 페이지 스캔
   • Next.js는 빌드 과정에서 프로젝트 내 모든 페이지를 확인합니다.
   • 예를 들어:
     • app/page.tsx → 홈 페이지
     • app/about/page.tsx → 소개 페이지
     • app/blog/[slug]/page.tsx → 동적 블로그 글 페이지
   • 이렇게 모든 페이지를 자동으로 찾아서 처리 대상으로 등록합니다.
2. 페이지별 처리
   • 동적 라우트 처리: generateStaticParams() 함수가 호출되어, 동적 URL(slug 등)에 필요한 모든 조합을 생성합니다.
   • 데이터 가져오기: 각 페이지의 데이터 페칭 함수(API 호출 등)를 실행해서 필요한 데이터를 불러옵니다.
   • React 컴포넌트 렌더링: 가져온 데이터를 이용해 React 컴포넌트를 HTML로 렌더링합니다.
   • HTML 파일 생성: 렌더링된 결과를 정적 HTML 파일로 변환합니다.
3. 출력물 생성
   • 생성된 HTML 파일과 JavaScript 번들이 프로젝트 내부 .next 폴더에 저장됩니다.
   • 예시:
     • .next/server/app/page.html → 홈 페이지
     • .next/server/app/about.html → 소개 페이지
     • .next/server/app/blog/post-1.html → 블로그 글
     • .next/static/chunks/ → React 기능과 인터랙티브를 위한 JS 번들

Next.js 코드 예제

// app/blog/[slug]/page.tsx

// 1. 빌드 시 생성할 경로 정의
export async function generateStaticParams() {
  console.log('🏗️  빌드 타임: 경로 생성 중...');

  // API에서 모든 포스트 가져오기
  const posts = await fetch('<https://api.example.com/posts>')
    .then(res => res.json());

  // 각 포스트마다 정적 페이지 생성
  return posts.map((post: any) => ({
    slug: post.slug, // /blog/post-1, /blog/post-2 등
  }));
}

// 2. 각 페이지의 데이터 페칭
export default async function BlogPost({
  params
}: {
  params: Promise<{ slug: string }>
}) {
  console.log(`🏗️  빌드 타임: ${params.slug} 페이지 생성 중...`);
  const { slug } = await params;

  // 이 fetch는 빌드 시 한 번만 실행됨
  const post = await fetch(`https://api.example.com/posts/${params.slug}`, {
    cache: 'force-cache' // SSG의 핵심 설정(DEFAULT)
  }).then(res => res.json());

  // React 컴포넌트를 HTML로 변환
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );

2단계: 빌드 결과물

.next/
├── static/
│   ├── chunks/          # JavaScript 코드 조각들
│   │   ├── main.js      # React 런타임
│   │   └── pages/       # 페이지별 JS
│   └── css/             # CSS 파일들
├── server/
│   └── app/
│       ├── page.html           # 미리 생성된 HTML
│       ├── about.html
│       └── blog/
│           ├── post-1.html     # 각 포스트의 HTML
│           └── post-2.html

생성된 HTML 예시

<!DOCTYPE html>
<html>
<head>
  <title>My Blog Post</title>
  <link rel="stylesheet" href="/_next/static/css/app.css" />
</head>
<body>
  <!-- 이미 렌더링된 콘텐츠 -->
  <article>
    <h1>내 첫 번째 포스트</h1>
    <div>
      <p>이것은 내용입니다...</p>
    </div>
  </article>

  <!-- JavaScript는 Hydration을 위해 로드 -->
  <script src="/_next/static/chunks/main.js"></script>
  <script src="/_next/static/chunks/pages/blog/post-1.js"></script>
</body>
</html>

3단계: 사용자 요청 (Request Time)

사용자가 /blog/post-1 접속
         ↓
CDN/Server가 미리 생성된 HTML 전송
         ↓
브라우저가 HTML 즉시 렌더링 (0.1초)
         ↓
JavaScript 다운로드 & 실행
         ↓
Hydration (HTML에 이벤트 리스너 연결)
         ↓
인터랙티브한 페이지 완성

Hydration 과정

// 1. 서버에서 생성된 HTML (정적)
<button>클릭하세요</button>

// 2. JavaScript 로드 후 Hydration
<button onClick={() => alert('클릭!')}>클릭하세요</button>
//      ↑ 이벤트 리스너가 추가됨

Hydration 코드 흐름:

// React가 내부적으로 수행
ReactDOM.hydrateRoot(
  document.getElementById('root'),
  <App />
);

// 과정:
// 1. 기존 HTML 요소 찾기
// 2. Virtual DOM 생성
// 3. 기존 DOM과 비교
// 4. 이벤트 리스너 연결
// 5. 상태 관리 활성화

2. ISR (Incremental Static Regeneration) 작동원리

전체 흐름도

[빌드 타임]              [첫 요청]            [revalidate 후]
모든 페이지 생성      → 정적 HTML 제공 →         백그라운드 재생성
                          ↓                    ↓
                    캐시된 버전 제공           새 버전으로 교체

ISR 상세 작동 과정

시나리오: revalidate: 60 설정

// app/blog/[slug]/page.tsx
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await fetch(`https://api.example.com/posts/${params.slug}`, {
    next: {
      revalidate: 60 // 60초마다 재검증
    }
  }).then(res => res.json());

  return <article>{post.title}</article>;
}

타임라인 분석

시간         요청          응답            내부 동작
──────────────────────────────────────────────────────────
00:00    빌드 완료      -              HTML v1 생성
         (초기 상태)

01:00    사용자 A      HTML v1 제공    ✅ 캐시 히트
         방문          (0.1초)         (타임스탬프: 00:00)

01:30    사용자 B      HTML v1 제공    ✅ 캐시 히트
         방문          (0.1초)         (아직 60초 안됨)

02:00    사용자 C      HTML v1 제공    🔄 재생성 트리거!
         방문          (0.1초)         (60초 경과)
                                      백그라운드에서:
                                      - API 재호출
                                      - HTML v2 생성
                                      - 캐시 교체 (10초 소요)

02:05    사용자 D      HTML v1 제공    ⏳ 재생성 진행 중
         방문          (0.1초)

02:10    재생성 완료    -              ✅ 캐시 업데이트
                                      HTML v2 준비 완료

02:15    사용자 E      HTML v2 제공    ✅ 새 버전!
         방문          (0.1초)

03:00    사용자 F      HTML v2 제공    ✅ 캐시 히트
         방문          (0.1초)

ISR 내부 캐시 메커니즘

// Next.js 내부 캐시 구조 (단순화)
const cache = {
  '/blog/post-1': {
    html: '<article>...</article>',
    timestamp: 1704067200000,      // 생성 시각
    revalidateAfter: 60,            // 재검증 간격 (초)
    isRevalidating: false           // 재생성 중인지
  }
};

// 요청 처리 로직
async function handleRequest(path) {
  const cached = cache[path];
  const now = Date.now();
  const age = (now - cached.timestamp) / 1000; // 초 단위

  // 1. 캐시가 유효한 경우
  if (age < cached.revalidateAfter) {
    console.log('✅ 캐시 히트: 신선한 데이터');
    return cached.html;
  }

  // 2. 캐시가 만료되었지만 재생성 중이 아닌 경우
  if (!cached.isRevalidating) {
    console.log('🔄 Stale-While-Revalidate: 오래된 캐시 제공 + 백그라운드 재생성');

    // 오래된 캐시 즉시 반환
    const staleResponse = cached.html;

    // 백그라운드에서 재생성
    cached.isRevalidating = true;
    regeneratePage(path).then(newHtml => {
      cache[path] = {
        html: newHtml,
        timestamp: Date.now(),
        revalidateAfter: 60,
        isRevalidating: false
      };
      console.log('✅ 재생성 완료: 캐시 업데이트됨');
    });

    return staleResponse;
  }

  // 3. 이미 재생성 중인 경우
  console.log('⏳ 재생성 진행 중: 오래된 캐시 제공');
  return cached.html;
}

ISR의 Stale-While-Revalidate 전략

ISR의 핵심은 "오래된 콘텐츠를 제공하면서 동시에 새 콘텐츠를 준비"하는 것입니다.

요청 → 캐시 확인
       ├─ 신선함 → 즉시 반환 ✅
       └─ 오래됨 → 오래된 것 반환 + 백그라운드 갱신 🔄
                   (다음 요청부터 새 버전)

On-Demand Revalidation

수동으로 캐시를 무효화할 수도 있습니다.

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache';
import { NextRequest } from 'next/server';

export async function POST(request: NextRequest) {
  const path = request.nextUrl.searchParams.get('path');

  if (path) {
    // 특정 경로 재검증
    revalidatePath(path);
    console.log(`🔄 수동 재검증: ${path}`);
    return Response.json({ revalidated: true });
  }

  return Response.json({ revalidated: false });
}

// 사용 예:
// POST /api/revalidate?path=/blog/post-1

ISR 내부 동작:

// revalidatePath 내부 로직
function revalidatePath(path) {
  // 1. 캐시에서 해당 경로 찾기
  const cached = cache[path];

  if (cached) {
    // 2. 타임스탬프를 과거로 설정 (만료시킴)
    cached.timestamp = 0;
    console.log(`✅ ${path} 캐시 무효화됨`);

    // 3. 다음 요청 시 자동으로 재생성됨
  }
}

3.  SSR (Server-Side Rendering) 작동원리

전체 흐름도

사용자 요청
    ↓
Next.js 서버
    ↓
데이터 페칭 (API 호출)
    ↓
React 컴포넌트 렌더링
    ↓
HTML 생성
    ↓
브라우저로 전송
    ↓
Hydration

상세 작동 과정

요청별 처리 흐름

// app/dashboard/page.tsx
export default async function Dashboard() {
  console.log('🖥️  서버에서 실행 중...');

  const data = await fetch('<https://api.example.com/user>', {
    cache: 'no-store', // SSR 활성화
    headers: {
      cookie: cookies().toString() // 쿠키 포함
    }
  }).then(res => res.json());

    return (
    <div>
      <h1>환영합니다, {data.name}님</h1>
      <p>마지막 로그인: {data.lastLogin}</p>
    </div>
  );
}

SSR 타임라인 분석

사용자 A가 /dashboard 요청 (10:00:00)
│
├─ [10:00:00.000] 요청 도착
│   └─ 서버: "새 요청 받음"
│
├─ [10:00:00.050] 쿠키/헤더 파싱
│   └─ 서버: "인증 토큰 확인"
│
├─ [10:00:00.100] API 호출 시작
│   └─ 서버 → API: "사용자 데이터 요청"
│
├─ [10:00:00.500] API 응답 대기 중...
│   └─ 서버: "응답 대기 중"
│
├─ [10:00:00.800] API 응답 도착
│   └─ 서버: "데이터 수신 완료"
│
├─ [10:00:00.850] React 렌더링
│   └─ 서버: "컴포넌트를 HTML로 변환"
│
├─ [10:00:00.900] HTML 생성 완료
│   └─ 서버: "최종 HTML 준비"
│
└─ [10:00:00.950] 브라우저로 전송
    └─ 사용자: "페이지 표시"

──────────────────────────────────────────

사용자 B가 /dashboard 요청 (10:00:01)
│
└─ 위 과정 반복 (캐시 없음!)
   └─ 총 소요시간: ~1초

서버 내부 처리

// Next.js 서버의 요청 핸들러 (단순화)
async function handleSSRRequest(req, res) {
  console.log('🖥️  SSR 요청 처리 시작');
  const startTime = Date.now();

  try {
    // 1. 라우트 매칭
    const route = matchRoute(req.url);
    console.log(`📍 라우트: ${route.path}`);

    // 2. 페이지 컴포넌트 가져오기
    const PageComponent = await import(route.componentPath);

    // 3. 서버 컴포넌트 실행 (데이터 페칭 포함)
    console.log('🔄 데이터 페칭 시작...');
    const props = await PageComponent.getServerSideProps?.(req, res);

    // 4. React 렌더링
    console.log('🎨 React 렌더링 시작...');
    const html = ReactDOMServer.renderToString(
      <PageComponent {...props} />
    );

    // 5. HTML 템플릿에 삽입
    const fullHtml = `
      <!DOCTYPE html>
      <html>
        <head>
          <title>${props.title}</title>
          <link rel="stylesheet" href="/styles.css" />
        </head>
        <body>
          <div id="root">${html}</div>
          <script src="/runtime.js"></script>
          <script>
            window.__INITIAL_DATA__ = ${JSON.stringify(props)};
          </script>
        </body>
      </html>
    `;

    const endTime = Date.now();
    console.log(`✅ 렌더링 완료 (${endTime - startTime}ms)`);

    // 6. 응답 전송
    res.setHeader('Content-Type', 'text/html');
    res.send(fullHtml);

  } catch (error) {
    console.error('❌ SSR 에러:', error);
    res.status(500).send('Server Error');
  }
}

SSR 인증/쿠키 처리

// app/profile/page.tsx
import { cookies, headers } from 'next/headers';

export default async function Profile() {
  // 1. 쿠키 읽기
  const cookieStore = cookies();
  const token = cookieStore.get('auth_token');

  console.log('🔐 인증 토큰:', token?.value);

  if (!token) {
    redirect('/login');
  }

  // 2. 헤더 읽기
  const headersList = headers();
  const userAgent = headersList.get('user-agent');

  console.log('👤 User-Agent:', userAgent);

  // 3. 인증된 API 호출
  const user = await fetch('<https://api.example.com/profile>', {
    headers: {
      'Authorization': `Bearer ${token.value}`,
      'User-Agent': userAgent || ''
    },
    cache: 'no-store'
  }).then(res => res.json());

  return

성능 최적화: Streaming SSR

// app/dashboard/page.tsx
import { Suspense } from 'react';

export default function Dashboard() {
  return (
    <div>
      <h1>대시보드</h1>

      {/* 즉시 렌더링 */}
      <QuickStats />

      {/* 느린 부분은 나중에 */}
      <Suspense fallback={<Loading />}>
        <SlowComponent />
      </Suspense>
    </div>
  );
}

async function SlowComponent() {
  // 3초 걸리는 API 호출
  const data = await fetch('https://slow-api.com/data', {
    cache: 'no-store'
  });

  return <HeavyChart data={data} />;
}

Streaming 동작:

클라이언트로 전송되는 HTML:

[0.1초]
<div>
  <h1>대시보드</h1>
  <div>빠른 통계: ...</div>
  <div id="suspense-boundary">로딩 중...</div>
</div>

[3.1초 - 추가 청크]
<script>
  // Suspense 경계 업데이트
  replaceSuspenseBoundary('suspense-boundary', `
    <div>느린 컴포넌트 내용...</div>
  `);
</script>

4. CSR (Client-Side Rendering) 작동원리

 전체 흐름도

사용자 요청
    ↓
빈 HTML + JavaScript 번들 전송
    ↓
브라우저에서 JavaScript 실행
    ↓
React 앱 초기화
    ↓
API 호출 (fetch/axios)
    ↓
컴포넌트 렌더링
    ↓
화면에 표시

상세 작동 과정

초기 HTML (거의 비어있음)

<!DOCTYPE html>
<html>
<head>
  <title>My App</title>
</head>
<body>
  <!-- 거의 빈 껍데기 -->
  <div id="root"></div>

  <!-- JavaScript 번들만 로드 -->
  <script src="/static/js/runtime.js"></script>
  <script src="/static/js/vendors.js"></script>
  <script src="/static/js/main.js"></script>
</body>
</html>

JavaScript 실행 흐름

// app/dashboard/page.tsx
'use client'; // CSR 명시

import { useState, useEffect } from 'react';

export default function Dashboard() {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    console.log('🌐 브라우저에서 실행 중...');
    console.log('📡 API 호출 시작...');

    fetch('/api/user')
      .then(res => {
        console.log('✅ API 응답 받음');
        return res.json();
      })
      .then(data => {
        console.log('📦 데이터 파싱 완료');
        setUser(data);
        setLoading(false);
      })
      .catch(error => {
        console.error('❌ 에러:', error);
        setLoading(false);
      });
  }, []);

  if (loading) {
    return <div>로딩 중...</div>;
  }

  return (
    <div>
      <h1>환영합니다, {user.name}님!</h1>
    </div>
  );
}

CSR 타임라인 분석

[0.0초] 사용자가 /dashboard 요청
│
├─ [0.1초] HTML 다운로드 (5KB)
│   └─ 화면: 빈 페이지
│
├─ [0.2초] JavaScript 다운로드 시작
│   ├─ runtime.js (50KB)
│   ├─ vendors.js (200KB - React 등)
│   └─ main.js (100KB - 앱 코드)
│   └─ 화면: 여전히 빈 페이지
│
├─ [1.0초] JavaScript 파싱 & 실행
│   └─ 화면: 여전히 빈 페이지
│
├─ [1.2초] React 앱 초기화
│   └─ ReactDOM.render(<App />)
│   └─ 화면: "로딩 중..." 표시
│
├─ [1.3초] useEffect 실행
│   └─ fetch('/api/user') 호출
│   └─ 화면: "로딩 중..."
│
├─ [1.8초] API 응답 도착
│   └─ 화면: "로딩 중..."
│
└─ [2.0초] setState 완료 & 리렌더링
    └─ 화면: 실제 콘텐츠 표시 ✅

CSR 브라우저 내부 처리

// React의 CSR 초기화 (단순화)
window.addEventListener('DOMContentLoaded', () => {
  console.log('📄 DOM 로드 완료');

  // 1. React 루트 생성
  const root = ReactDOM.createRoot(document.getElementById('root'));
  console.log('🌱 React 루트 생성');

  // 2. 앱 렌더링
  console.log('🎨 앱 렌더링 시작');
  root.render(<App />);

  // 3. 컴포넌트 마운트
  // App → Dashboard → useEffect 순서로 실행
});

CSR 상태 관리와 리렌더링

'use client';

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);

  console.log('🔄 Counter 컴포넌트 렌더링:', count);

  const increment = () => {
    console.log('➕ 증가 버튼 클릭');
    setCount(prev => {
      const newCount = prev + 1;
      console.log(`상태 변경: ${prev} → ${newCount}`);
      return newCount;
    });
    // 상태 변경 후 자동으로 리렌더링 트리거
  };

  return (
    <div>
      <p>카운트: {count}</p>
      <button onClick={increment}>증가</button>
    </div>
  );
}

실행 흐름:

[초기 렌더링]
└─ 🔄 Counter 컴포넌트 렌더링: 0

[버튼 클릭]
├─ ➕ 증가 버튼 클릭
├─ 상태 변경: 0 → 1
└─ 🔄 Counter 컴포넌트 렌더링: 1
   └─ Virtual DOM 생성
      └─ 실제 DOM과 비교 (Reconciliation)
         └─ 변경된 부분만 업데이트
            └─ <p>카운트: 1</p> ✅

React의 Reconciliation (재조정)

// React 내부 로직 (단순화)
function updateComponent(Component, newProps) {
  // 1. 새로운 Virtual DOM 생성
  const newVDOM = Component(newProps);
  console.log('🆕 새 Virtual DOM:', newVDOM);

  // 2. 이전 Virtual DOM과 비교
  const diff = compareVDOM(oldVDOM, newVDOM);
  console.log('🔍 변경 사항:', diff);

  // 3. 변경된 부분만 실제 DOM 업데이트
  diff.forEach(change => {
    if (change.type === 'UPDATE_TEXT') {
      const element = document.querySelector(change.selector);
      element.textContent = change.newValue;
      console.log(`✏️  텍스트 업데이트: ${change.oldValue} → ${change.newValue}`);
    }
  });

  // 4. 이전 VDOM을 새 VDOM으로 교체
  oldVDOM = newVDOM;
}

원문

https://tkdodo.eu/blog/deriving-client-state-from-server-state

휴가에서 막 돌아왔는데, Zustand를 사용할 때 가장 큰 트레이드오프에 대한 Reddit 질문을 보게 되었다.
코드는 대략 이렇다(최신 문법으로 조금 수정하고, 커스텀 훅 안에 넣었다).

Manual-sync

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  // If the selected user gets deleted from the server,
  // Zustand won't automatically clear selectedUserId
  // You have to manually handle this:
  useEffect(() => {
    if (!users?.some((u) => u.id === selectedUserId)) {
      setSelectedUserId(null) // Manual sync required
    }
  }, [users, selectedUserId])

  return [selectedUserId, selectedUserId]
}

물론, useEffect—특히 그 안에서 setState를 호출하는 경우—를 볼 때마다 나는 더 나은 해결책이 없을까 생각하게 된다.
내 경험상, 거의 항상 더 나은 방법이 존재하며, 보통 그 방법을 찾는 것이 가치 있는 일이다.
그러니 한 걸음 물러서서 우리가 먼저 무엇을 달성하고 싶은지를 먼저 살펴보자.

상태 동기화 유지하기 (Keeping State in Sync)

간단히 말하면, 우리는 클라이언트 상태(Client State)인 selectedUserId를 서버 상태(Server State)인 사용자 목록(users)과 동기화하고 싶다.
이것은 당연한 일이다.

예를 들어, useQuery를 통해 백그라운드에서 다시 데이터를 가져왔는데, 사용자가 목록에서 삭제되었음에도 여전히 상태에 저장되어 있다면, 그 선택은 유효하지 않다.

클라이언트 상태(Client State)

이 접근 방식은 Zustand에만 국한된 것이 아니다.
useUserStore()를 단순히 로컬 상태로 바꿔도 똑같이 적용할 수 있다:

const [selectedUserId, setSelectedUserId] = useState()

또는 URL 상태(nuqs 같은)를 사용해도 된다:

const [selectedUserId, setSelectedUserId] = useQueryState('userId')

중요한 건 상태가 어디에 저장되느냐가 아니라,
서버 상태(Server State)가 바뀔 때 업데이트해야 하는 클라이언트 상태(Client State)라는 점이다.

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  const selectedId = users?.some((u) => u.id === selectedUserId)
    ? selectedUserId
    : null

  return [selectedId, setSelectedUserId]
}

이 코드는 매우 간단하다.
스토어 값을 직접 업데이트하는 대신, Selection 자체는 그대로 두고,
서버 상태(Server State)에서 더 이상 해당 id를 찾을 수 없는 경우 커스텀 훅에서 다른 값을 반환하도록 한다.

즉, useSelectedUser()를 호출하는 곳에서는 이전처럼 null을 받게 된다.

그리고 스토어를 건드리지 않기 때문에 추가적인 이점도 있다:

• 사용자가 다시 목록에 추가되면, 선택(selection)이 자동으로 복원된다.
• UX 요구사항이 바뀌어 선택을 제거하고 싶지 않고, 단지 선택이 유효하지 않음을 시각적으로 표시하고 싶을 때도 가능하다.
  → 원래 값을 항상 유지하기 때문에 쉽게 구현할 수 있다.

isSelectionValid

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()
  const isSelectionValid = users?.some((u) => u.id === selectedUserId)

  return [selectedUserId, setSelectedUserId, isSelectionValid]
}

함정은 어디에 있을까요?

"상태 파생 솔루션"의 명백한 단점 중 하나는 사용자 저장소에 저장된 내용을 더 이상 "신뢰"할 수 없다는 것입니다. useUserStore에서 다른 곳의 selectedUserId를 읽어오면 추가 검사를 받지 못하므로 항상 사용자 정의 hook에서 읽어야 합니다.

저는 저장소를 최종 검증된 값의 소스라기보다는 UI에서 실제로 선택된 항목의 기록으로 보기 때문에 이 점에 대해서는 전혀 문제가 없습니다.

또, Reddit 질문에서 Redux Toolkit이 “이 문제를 해결한다”고 언급했지만, 실제로 크게 다르지 않을 것이다.
보통 API 슬라이스와 사용자 선택 슬라이스를 읽어 두 값을 결합하는 selector를 작성하게 되는데,
이것이 바로 우리가 커스텀 훅에서 하고 있는 방식과 동일하다.

오히려 이 방식은 상태를 파생(derive)하도록 유도하므로, 좋은 접근입니다.

다른 예시

서버 상태(Server State)가 바뀌어도 클라이언트 상태(Client State)를 업데이트하지 않는 개념은 여러 경우에 유용하다.
흔한 예시는 서버에서 가져온 기본값으로 폼을 미리 채울 때(prefilling forms)이다.

default-value-effect

function UserSelection() {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const [selection, setSelection] = useState()

  // use the first value as default selection
  useEffect(() => {
    if (users?.[0]) {
      setSelection(users[0])
    }
  }, [users])

  // return markup
}

이 효과는 장황할 뿐만 아니라, 쿼리에서 새 데이터가 들어올 때 현재 선택 항목을 덮어쓰는 버그도 있습니다. 🐛

이 문제는 다른 검사를 추가하면 쉽게 해결할 수 있지만, 더 나은 해결책은 여전히 ​​상태를 파생하는 것입니다.

derived-default-value

function UserSelection() {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const [selection, setSelection] = useState()

  const derivedSelection = selection ?? users?.[0]

  // return markup
}

지금 우리가 해야 할 일은 selection 대신 derivedSelection을 계속 사용하는 것뿐이며, 그렇게 하면 항상 원하는 값을 얻을 수 있습니다. 🚀

https://tkdodo.eu/blog/the-useless-use-callback

원문

메모이제이션(memoization)에 대해서는 이제 충분히 다뤘다고 생각했는데, 요즘 자주 보이는 한 가지 패턴을 보면서 생각이 달라졌다.
그래서 오늘은 useCallback과, 부분적으로는 useMemo에 대해 이야기해보려 한다.
특히 내가 보기엔 정말 불필요하게 사용되는 경우들에 대해 말이다.

왜 메모이제이션을 사용할까?

보통 useCallback으로 함수를, useMemo로 값을 메모이제이션하는 이유는 단 두 가지뿐이다.

function Meh() {
  return (
    <MemoizedComponent
      value={{ hello: 'world' }}
      onChange={(result) => console.log('result')}
    />
  )
}

function Okay() {
  const value = useMemo(() => ({ hello: 'world' }), [])
  const onChange = useCallback((result) => console.log(result), [])

  return <MemoizedComponent value={value} onChange={onChange} />
}

물론 때로는 useMemo 내부의 계산 자체가 느릴 때가 있다.
이럴 땐 불필요한 재계산을 피하기 위해 메모이제이션을 사용하는데, 이런 경우의 useMemo 사용은 전혀 문제 없다.
하지만 솔직히 말하자면, 이런 경우가 대부분은 아니다.

2. Effect가 불필요하게 자주 실행되는 것을 막기 위해

no-memo

function Okay() {
  const value = useMemo(() => ({ hello: 'world' }), [])
  const onChange = useCallback((result) => console.log(result), [])

  return <Component value={value} onChange={onChange} />
}

차이점을 찾을 수 있는가? 맞다 — 이제 value와 onChange를 메모이제이션된 컴포넌트에 전달하지 않는다.
그냥 일반적인 React 함수형 컴포넌트일 뿐이다.

이런 상황은 특히 결국엔 값이 React의 기본(built-in) 컴포넌트로 전달될 때 자주 발생한다:

react-built-ins

function MyButton() {
  const onClick = useCallback(
    (event) => console.log(event.currentTarget.value),
    []
  )

  return <button onClick={onClick} />
}

여기서 onClick을 메모이제이션해도 아무런 효과가 없다.
왜냐하면 버튼 컴포넌트는 onClick이 참조가 안정적인지 여부를 신경 쓰지 않기 때문이다.

“아무 효과가 없다(Achieves nothing)”라고 표현했지만, 엄밀히 말하면 약간 잘못된 표현이다. 사실 내부적으로는 분명 무언가 일이 일어나고 있다.

React는 onClick 함수를 유지하기 위해 캐시를 만들어야 하고, 의존성을 추적하며 매 렌더링마다 비교를 수행한다. useCallback에 전달된 인라인 함수도 매 렌더마다 새로 생성되지만, 캐시된 버전이 반환되면 즉시 버려진다.

결과적으로, 기술적으로는 내부에 약간의 오버헤드가 생긴다. 하지만 나는 이 오버헤드에 너무 집중하고 싶진 않다. 왜냐하면 진짜 문제는 그게 아니기 때문이다.

function OhNo({ onChange }) {
  const handleChange = useCallback((e: React.ChangeEvent) => {
    trackAnalytics('changeEvent', e)
    onChange?.(e)
  }, [onChange])

  return <SomeMemoizedComponent onChange={handleChange} />
}

<OhNo onChange={() => props.doSomething()} />​

이건 무해한 사용 사례다. 전혀 문제될 게 없다.
사실 오히려 좋은 패턴이라고 볼 수 있다.
이벤트 핸들러와 관련된 동작을 한곳에 모아두어, 파일 상단으로 끌어올려서 길게 이름 붙인 handleChange 같은 함수를 만드는 일을 피할 수 있다.

이 코드를 작성한 개발자가 메모이제이션이 깨진다는 사실을 알 수 있는 유일한 방법은, 컴포넌트 내부를 깊이 파고 들어가 props가 어떻게 사용되는지 확인하는 것뿐이다.
솔직히 말해, 그건 끔찍하다.

다른 해결책으로는 “모든 걸 항상 메모이제이션한다”라는 정책을 세우거나,
참조 안정성이 필요한 props에는 mustBeMemoized 같은 엄격한 네이밍 규칙을 적용하는 방법이 있다.
하지만 이 둘 다 좋은 방법은 아니다.

실제 사례(Real Life Example)

지금 나는 Sentry 코드베이스에서 작업하고 있는데, 이건 오픈소스라서 🎉 실제 사용 사례를 쉽게 보여줄 수 있다.

내가 발견한 한 가지 상황은 useHotkeys 커스텀 훅이다.
핵심 부분은 대략 이렇게 생겼다:

useHotkeys

export function useHotkeys(hotkeys: Hotkey[]): {
  const onKeyDown = useCallback(() => ..., [hotkeys])

  useEffect(() => {
    document.addEventListener('keydown', onKeyDown)

    return () => {
      document.removeEventListener('keydown', onKeyDown)
    }
  }, [onKeyDown])
}

이 커스텀 훅은 hotKeys 배열을 인자로 받고,
그걸 기반으로 onKeyDown 함수를 메모이제이션한 뒤, 해당 함수를 effect에 넘긴다.

함수를 메모이제이션하는 이유는 명백하다: Effect가 너무 자주 실행되는 것을 방지하기 위해서다.

하지만 입력값인 hotkeys가 배열이기 때문에, 사용하는 쪽에서 직접 hotkeys를 메모이제이션해주어야 한다.

그래서 나는 useHotkeys가 실제 코드에서 어떻게 쓰이고 있는지 전수 조사를 해봤다.
놀랍게도 거의 대부분(한 곳을 제외하고)은 입력값을 메모이제이션하고 있었다.

하지만 이야기는 여기서 끝나지 않는다.
더 깊이 들어가 보면, 결국에는 여전히 문제가 생기기 쉬운 구조라는 걸 알 수 있다.
예를 들어, 다음과 같은 사용 사례를 보자.

paginateHotKeys

const paginateHotkeys = useMemo(() => {
  return [
    { match: 'right', callback: () => paginateItems(1) },
    { match: 'left', callback: () => paginateItems(-1) },
  ]
}, [paginateItems])

useHotkeys(paginateHotkeys)

useHotKeys는 메모이제이션된 paginateHotkeys를 전달한다.
그런데 이 paginateHotkeys는 paginateItems에 의존한다.

그럼 paginateItems는 어디서 올까?

바로 또 다른 useCallback이고, 이 콜백은 screenshots와 currentAttachmentIndex에 의존한다.

그렇다면 screenshots는 어디서 오는 걸까?

breaking-memoization

const screenshots = attachments.filter(({ name }) =>
  name.includes('screenshot')
)

screenshots는 메모이제이션되지 않은 attachments.filter 함수에서 생성된다.
이 함수는 매번 새로운 배열(Array)을 생성하므로, downstream에 있는 모든 메모이제이션이 깨진다.

결과적으로 모든 메모이제이션이 무용지물이 된다.

즉, paginateItems, paginateHotkeys, onKeyDown
이 세 가지 메모이제이션이 매 렌더링마다 다시 실행되며,
마치 아예 작성하지 않은 것과 동일한 상황이 된다! (이렇게 되면 우리가 했던 메모이제이션은 전부 무용지물이 된다)

이 예시가 내가 왜 메모이제이션 적용에 반대하는 입장인지 잘 보여줬으면 한다.
내 경험상, 메모이제이션은 너무 자주 깨지고, 그럴 가치가 없다.

게다가 코드 전체에 엄청난 오버헤드와 복잡성을 추가한다.

여기서 해결책이 screenshots까지 메모이제이션하는 것은 아니다.

그렇게 하면 책임이 결국 컴포넌트의 prop인 attachments로 넘어가게 된다.
세 가지 호출 지점(call-side) 모두에서 실제로 메모이제이션이 필요한 useHotkeys와는 최소 두 단계 이상 떨어져 있게 된다.

이건 코드를 탐색하기 악몽 같은 상황을 만들며, 결국 아무도 메모이제이션 하나를 제거하지 못하게 된다.
왜냐하면 그 메모이제이션이 실제로 무엇을 하고 있는지 알 수 없기 때문이다.

실제로는, 이런 문제를 해결하려면 컴파일러에게 모든 걸 맡기는 것이 가장 좋다.

모든 환경에서 잘 작동한다면 정말 훌륭하다.
하지만 그 전까지는, 참조 안정성(referential stability) 필요성의 한계를 우회할 패턴을 찾아야 한다.

최신 Ref 패턴(The Latest Ref Pattern)

이 패턴에 대해서는 이전에 언급한 적이 있다.
핵심 아이디어는, Effect 안에서 즉시 접근하고 싶은 값을 ref 안에 저장해두고,
또 다른 Effect를 통해 의도적으로 매 렌더링마다 값을 업데이트하는 것이다.

the-latest-ref

export function useHotkeys(hotkeys: Hotkey[]): {
  const hotkeysRef = useRef(hotkeys)

  useEffect(() => {
    hotkeysRef.current = hotkeys
  })

  const onKeyDown = useCallback(() => ..., [])

  useEffect(() => {
    document.addEventListener('keydown', onKeyDown)

    return () => {
      document.removeEventListener('keydown', onKeyDown)
    }
  }, [])
}

그렇게 하면 hotkeysRef를 Effect 안에서 바로 사용할 수 있다.
의존성 배열에 추가할 필요도 없고, 단순히 린터를 무시하다가 발생할 수 있는 stale closure 문제도 걱정하지 않아도 된다.

실제로 React Query도 이 패턴을 사용한다.

예를 들어 PersistQueryClientProvider나 useMutationState에서 최신 옵션(latest options)을 추적할 때 그렇다.
즉, 검증된(tried-and-true) 패턴이라고 볼 수 있다.
만약 라이브러리가 사용자가 옵션을 직접 메모이제이션하도록 강제한다면 얼마나 귀찮을지 상상해보라.

UseEffectEvent

좋은 소식이 하나 더 있다.
React 팀은 대부분의 경우, 리액티브 Effect 안에서 최신 값을 명령형(imperative)으로 접근할 필요가 있지만, Effect를 명시적으로 다시 실행하고 싶지 않은 상황이 있다는 것을 인식했다.

그래서 이 패턴을 위한 1급 프리미티브(first-class primitive), useEffectEvent를 새로 추가할 예정이다.

이 훅이 도입되면, 기존 코드를 보다 깔끔하고 안전하게 리팩터링할 수 있게 된다:

the-latest-ref

export function useHotkeys(hotkeys: Hotkey[]): {
  const onKeyDown = useEffectEvent(() => ...)

  useEffect(() => {
    document.addEventListener('keydown', onKeyDown)

    return () => {
      document.removeEventListener('keydown', onKeyDown)
    }
  }, [])
}

nuqs는 Next.js에서 URL 쿼리 파라미터를 상태처럼 쉽게 관리할 수 있게 해주는 라이브러리이다.

오늘은 'nuqs'의 useQueryState에 대해 알아볼 것이다.

기본 개념

useQueryState는 React의 useState와 비슷하게 동작하지만, 상태를 컴포넌트 내부가 아닌 URL 쿼리 파라미터에 저장합니다.

import { useQueryState } from 'nuqs'

function SearchComponent() {
  const [search, setSearch] = useQueryState('search')
  
  // URL: /?search=hello
  // search 값: "hello"
  
  return (
    <input 
      value={search || ''} 
      onChange={(e) => setSearch(e.target.value)}
    />
  )
}

주요 특징

URL과 자동 동기화

• 상태가 변경되면 URL이 자동으로 업데이트됩니다
• 뒤로가기/앞으로가기 버튼이 정상 작동합니다
• URL을 공유하면 같은 상태를 공유할 수 있습니다

타입 안전성

• 파서(parser)를 사용해 타입을 지정할 수 있습니다

import { useQueryState, parseAsInteger, parseAsBoolean } from 'nuqs'

const [page, setPage] = useQueryState('page', parseAsInteger.withDefault(1))
const [isActive, setIsActive] = useQueryState('active', parseAsBoolean)

기본값 설정

const [sort, setSort] = useQueryState('sort', { defaultValue: 'name' })

여러 파라미터 동시 관리

import { useQueryStates } from 'nuqs'

const [filters, setFilters] = useQueryStates({
  search: parseAsString,
  page: parseAsInteger.withDefault(1),
  category: parseAsString
})

// 여러 값을 한 번에 업데이트
setFilters({ search: 'test', page: 1 })

실제 사용 예시

검색과 필터링이 있는 상품 목록:

function ProductList() {
  const [search, setSearch] = useQueryState('search')
  const [category, setCategory] = useQueryState('category')
  const [page, setPage] = useQueryState('page', parseAsInteger.withDefault(1))

  return (
    <div>
      <input 
        value={search || ''} 
        onChange={(e) => setSearch(e.target.value)}
        placeholder="검색..."
      />
      
      <select 
        value={category || ''} 
        onChange={(e) => setCategory(e.target.value)}
      >
        <option value="">전체</option>
        <option value="electronics">전자제품</option>
        <option value="clothing">의류</option>
      </select>
      
      {/* URL: /?search=laptop&category=electronics&page=2 */}
    </div>
  )
}

장점

• SEO 친화적: 필터링된 상태가 URL에 있어 크롤러가 인덱싱 가능
• 공유 가능: URL만으로 정확한 페이지 상태 공유
• 새로고침 안전: 페이지를 새로고침해도 상태 유지
• 브라우저 히스토리: 뒤로가기/앞으로가기 지원

Next.js의 App Router와 Pages Router 모두에서 사용할 수 있으며, 특히 검색, 필터링, 페이지네이션 같은 기능을 구현할 때 매우 유용합니다.

비동기로 멀티 스레드를 구현한다? 많이들 async/await만 쓰면 작업이 “동시에” 돈다고 생각합니다. 하지만 비동기는 하나의 메인 스레드가 일을 잘게 쪼개 순서 없이 처리해 보이는 기법이지, 실제로 여러 스레드가 병렬로 계산하는 건 아닙니다.

UI가 멈추지 않게 하는 데는 비동기로도 충분하지만, 대용량 데이터 처리나 이미지/영상 변환처럼 CPU를 잡아먹는 작업은 결국 메인 스레드를 묶어버립니다.

1. 멀티 스레드가 필요한 이유

자바스크립트는 기본적으로 싱글 스레드 언어입니다. 즉, 한 번에 하나의 작업만 처리할 수 있습니다. 하지만 복잡한 계산, 대규모 데이터 처리, 이미지 변환 같은 작업은 시간이 오래 걸려 UI가 멈출 수도 있습니다. 이런 문제를 해결하기 위해 멀티 스레드 개념을 활용할 수 있는데요.

2. Web Worker로 동시성 구현

Web Worker는 별도의 스레드에서 자바스크립트를 실행할 수 있게 해주는 기능입니다. 메인 스레드(UI)와 독립적으로 동작하므로 무거운 연산을 맡기기 좋습니다.

// worker.js (별도의 파일)
self.onmessage = function(event) {
  let num = event.data;
  let result = 0;
  for (let i = 0; i < num; i++) {
    result += i;
  }
  self.postMessage(result);
};

// main.js
const worker = new Worker("worker.js");
worker.postMessage(1000000); // Worker에게 작업 요청

worker.onmessage = (e) => {
  console.log("결과:", e.data);
};

Web Worker를 사용하면 UI 멈춤 없이 무거운 계산을 처리할 수 있습니다.

3. WebAssembly를 활용한 멀티 스레드

WebAssembly(WASM)는 브라우저에서 동작하는 저수준 이진 코드 포맷입니다. 성능이 중요한 연산을 자바스크립트 대신 C/C++/Rust 같은 언어로 작성한 뒤, WebAssembly로 컴파일해서 실행할 수 있습니다.

// 예시: C 코드 (sum.c)
int sum(int n) {
  int result = 0;
  for (int i = 0; i < n; i++) {
    result += i;
  }
  return result;
}

이 코드를 emscripten 같은 도구로 WebAssembly로 컴파일하면 자바스크립트에서 고성능으로 실행할 수 있습니다.

4. Web Worker vs WebAssembly 비교

웹 환경에서도 멀티 스레드를 활용할 수 있는 방법은 다양합니다. 간단한 동시성 처리는 Web Worker, 고성능 연산은 WebAssembly를 선택하는 것이 좋습니다. 프로젝트 성격에 맞춰 두 기술을 적절히 조합하면 사용자 경험을 크게 개선할 수 있습니다.

프론트엔드 개발 환경은 지난 몇 년 동안 눈부시게 발전했습니다. 과거에는 단순히 <script> 태그로 JS 파일을 불러오면 되었지만, 규모가 커지고 모듈 단위 개발이 보편화되면서 “모듈 번들러(Module Bundler)”가 필수 도구가 되었습니다. 이번 글에서는 대표적인 모듈 번들러인 Webpack, Rollup.js, 그리고 차세대 번들링 도구로 각광받는 Vite에 대해 비교해 보겠습니다.

1. 모듈 번들러란

모듈 번들러는 여러 개의 JavaScript, CSS, 이미지 등의 파일을 의존성 그래프(Dependency Graph)로 분석해 하나의 파일(또는 최적화된 여러 파일)로 묶어주는 도구입니다.

목적: 브라우저가 효율적으로 로드할 수 있도록 최적화된 번들을 만들어주는 것.

왜 필요한가?

👀속도 개선: 파일이 많으면 브라우저가 하나씩 요청해야 해서 느려요. 번들러가 파일을 합쳐서 요청을 줄여줍니다.
👀최적화: 쓰이지 않는 코드를 제거(트리 쉐이킹)하거나, 코드를 압축해 용량을 줄여줍니다.
👀개발 편의성: 최신 문법(ES6, TypeScript 등)을 구버전 브라우저에서도 쓸 수 있도록 변환해 줍니다.

2. 주요 모듈 번들러

이제 많이 쓰이는 3가지 도구를 비교해볼게요

Webpack

가장 유명하고 오래된 번들러
설정이 강력하지만 복잡하다는 단점이 있다
entry → loader → plugin → output 구조로 동작.

대규모 프로젝트에서 안정적이고 확장성이 높습니다.

예시
React, Vue 같은 프레임워크의 기본 번들러로 많이 쓰였습니다.
복잡한 빌드(이미지, CSS, JS, TS 다 합치기)에 유리.

Rollup.js

라이브러리 제작에 강점.
Webpack보다 단순하고 가볍습니다.
트리 쉐이킹(tree shaking) 기능이 강력해서, 쓰지 않는 코드가 거의 남지 않아요.

예시:
Lodash, D3.js 같은 유명한 JS 라이브러리도 Rollup으로 빌드됩니다.
라이브러리 제작할 때는 Webpack보다 Rollup이 더 선호됩니다.

Vite

차세대 번들러로, 최근 가장 핫합니다.

내부적으로 Rollup을 기반으로 하지만, 개발 서버는 ESBuild(Go 언어로 만든 초고속 번들러)를 사용


🔴장점: 개발 서버 속도가 엄청 빠름 (변경된 부분만 즉시 반영 → HMR)

🔴단점: 아직은 Webpack만큼 플러그인 생태계가 방대하지 않음


예시:
Vue 3, React 최신 템플릿에서 기본 빌드 도구로 채택됨
스타트업이나 개인 프로젝트에서 빠르게 개발할 때 최적

회사에서도 기존에 React + Webpack 기반으로 운영하던 서비스를 Vite로 마이그레이션한 경험이 있습니다. 프로젝트가 무거워지면서 Webpack 환경에서 빌드 속도가 오래걸려 초기 개발 서버를 시작하는데에 10분 정도가 걸리는 아주 힘든 상황이 생겨버린거죠! HMR 속도도 개선하기 위함과 최신 생태계와 호환성을 고려해서 논의 결과 vite로 마이그레이션하기로 결정을 했습니다

그 결과, 개발 서버 구동 속도가 1분 미만으로 단축, HMR속도는 말할 것도 없이 현저히 빨라졌습니다.

결론적으로, Vite는 Webpack 대비 훨씬 가볍고 빠른 개발 경험을 제공했고, 팀의 생산성에도 긍정적인 효과를 줬습니다.