성능 특성 — Svelte는 정말 빠른가

"Svelte가 빠르다"는 말을 면접에서 하려면, 왜 빠른지 설명할 수 있어야 합니다.

개념 정의

Svelte의 성능은 **컴파일 타임 최적화 **, ** 작은 번들 크기 , ** 최소한의 런타임 오버헤드 세 축으로 설명됩니다.

번들 크기 비교

Svelte는 프레임워크 런타임이 번들에 거의 포함되지 않습니다. 대신 각 컴포넌트가 필요한 유틸리티 함수만 import합니다.

** 주의 **: 앱이 커지면 컴포넌트별 코드가 누적되므로, 대규모 앱에서는 번들 크기 차이가 줄어듭니다. 작은~중간 규모 앱에서 Svelte의 번들 크기 이점이 가장 뚜렷합니다.

런타임 성능

Virtual DOM 없는 업데이트

React 업데이트 흐름:
상태 변경 → 컴포넌트 함수 재실행 → Virtual DOM 생성 → Diff → 실제 DOM 패치

Svelte 업데이트 흐름:
상태 변경 → 해당 DOM 노드 직접 업데이트

Svelte는 중간 단계(컴포넌트 재실행, Virtual DOM diff)를 생략합니다.

메모리 사용량

Virtual DOM 트리를 메모리에 유지할 필요가 없으므로, 큰 리스트나 복잡한 UI에서 메모리 사용량이 적습니다.

초기 로딩 성능

1. 작은 번들 → 빠른 다운로드
2. 적은 파싱 → 빠른 JavaScript 실행
3. 직접 DOM 생성 → 빠른 첫 렌더링

특히 모바일 환경이나 저사양 기기에서 차이가 두드러집니다. JavaScript 파싱과 실행이 성능 병목인 환경에서 작은 번들 크기는 큰 장점입니다.

Svelte가 느려질 수 있는 경우

1. ** 대량 반응형 상태 **: 수천 개의 $state 객체가 Proxy로 감싸지면 메모리 오버헤드가 생깁니다. → $state.raw 사용
2. ** 빈번한 리스트 업데이트 **: keyed each에서 key가 자주 바뀌면 DOM 재생성 비용이 발생합니다.
3. ** 거대한 컴포넌트 **: 하나의 컴포넌트에 수백 개의 반응형 바인딩이 있으면 업데이트 코드가 비대해집니다.

성능 측정 방법

<script>
  import { onMount } from 'svelte';

  let items = $state(Array.from({ length: 10000 }, (_, i) => ({ id: i, text: `항목 ${i}` })));

  onMount(() => {
    // 렌더링 성능 측정
    performance.mark('start');

    // 대량 업데이트
    items = items.map(item => ({ ...item, text: item.text + ' (수정)' }));

    requestAnimationFrame(() => {
      performance.mark('end');
      performance.measure('update', 'start', 'end');
      const measure = performance.getEntriesByName('update')[0];
      console.log(`업데이트 시간: ${measure.duration.toFixed(2)}ms`);
    });
  });
</script>

면접 포인트

• "Svelte가 항상 React보다 빠른가요?": 아닙니다. 작은~중간 규모 앱에서 초기 로딩과 번들 크기에서 우위가 있지만, 대규모 앱에서는 React의 가상 DOM과 Concurrent Features가 복잡한 UI 업데이트를 더 잘 처리할 수 있습니다.
• "컴파일러 기반의 성능 이점은?": 빌드 타임에 최적화를 수행하므로 런타임 비용이 거의 없습니다. Dead code elimination, 정적 분석 기반 최소 업데이트 등이 자동 적용됩니다.

정리

Svelte의 성능 이점은 "런타임에서 할 일을 빌드 타임으로 옮긴 것"에서 비롯됩니다. 작은 번들, 적은 메모리, 직접 DOM 조작이 핵심이지만, 모든 상황에서 최선은 아닙니다. 앱의 특성에 맞게 판단하는 것이 중요합니다.