Svelte 5 가 달라진 점 / Svelte3, Svelte4와의 차이

공부일지/Web

Svelte 5 가 달라진 점 / Svelte3, Svelte4와의 차이

Viewee 2025. 1. 31. 23:19

다음은 GPT 를 이용해서 질문하고 받은 답변을 기록한 것입니다.

내용에 큰 문제는 없다싶어서, 공유하고 기록으로 남기고자 포스팅합니다.

Svelte 5 는 뭐가 달라졌어?

Svelte 5 는 이전 버전과 비교하여 여러 가지 주요 변경 사항과 새로운 기능을 도입했어요.주요 특징은 다음과 같아요:

룬(Runes) 도입: velte 5에서는 반응성을 처리하는 새로운 방법인 '룬'을 도입했어요. 이는 기존의 $ 구문과 반응 문을 대체하며, 코드를 더욱 직관적이고 유지 관리하기 쉽게 만들어줘요. 예를 들어, let count = $state(0);와 같이 상태를 선언할 수 있어요.
컴포넌트 구조 변경: 제 Svelte 5의 컴포넌트는 일반 JavaScript 함수로 정의돼요. 이를 통해 빌드 도구와 JavaScript 엔진이 최적화를 더 쉽게 수행할 수 있어 성능 향상에 기여해요.
새로운 CLI 도구 'sv' 도입: velte 5는 새로운 CLI 도구인 'sv'를 도입하여, Tailwind, TypeScript, Prettier, Storybook 등의 기능을 프로젝트에 손쉽게 추가할 수 있게 되었어요.
이러한 변화들은 Svelte 5를 더욱 강력하고 사용하기 쉽게 만들어주며, 개발자들이 효율적으로 작업할 수 있도록 도와줘요.

svelte3, 4, 5 의 차이를 알려줘

Svelte 3, 4, 5는 각각 중요한 변화를 거쳐 발전해 왔어요. 각 버전의 주요 차이를 정리해볼게요.

1. Svelte 3 (2019년 출시)

Svelte 3는 기존 프레임워크들과 완전히 다른 방식으로 컴파일하는 접근 방식을 도입하며, Svelte의 인기를 높인 버전이에요.

✅ 주요 특징

컴파일 기반 프레임워크: 런타임 없이 빌드 단계에서 최적화된 JavaScript로 변환
반응형 선언 방식 도입: $: 문법을 사용하여 자동으로 반응성을 처리
간결한 상태 관리: 별도의 상태 관리 라이브러리 없이 간단하게 반응형 상태 설정 가능
가벼운 번들 크기: React, Vue보다 훨씬 가벼운 결과물을 생성
기본적으로 Vanilla JavaScript 친화적

✅ 한계점

서버 사이드 렌더링(SSR) 기능이 부족하고 별도 설정이 필요함
복잡한 글로벌 상태 관리는 추가적인 라이브러리가 필요함 (svelte/store)
기업용 대형 프로젝트에 적용하기에는 생태계가 부족했던 시기

2. Svelte 4 (2023년 출시)

Svelte 4는 내부적인 개선이 주를 이루며, Svelte 5로 가기 위한 징검다리 역할을 한 버전이에요.

✅ 주요 특징

Vite 및 최신 빌드 도구 최적화: 최신 번들러 환경에서 더 빠른 빌드 속도 제공
Node.js 16 이상 지원: 더 최신 환경을 타겟팅
의존성 및 내부 코드 정리: 번들 크기를 줄이고, 코드 가독성 및 유지보수성을 향상

✅ 한계점

Svelte 3와 비교해 API의 큰 변화는 없었음
아직 반응성 개선이나 상태 관리의 혁신적인 변화는 포함되지 않음

3. Svelte 5 (2024년 출시 예정, 현재 베타 버전)

Svelte 5에서는 기존의 반응성 시스템이 완전히 새로운 방식(Runes) 으로 변경되었어요.

✅ 주요 특징

Runes 시스템 도입: 기존 $: 문법이 사라지고, let count = $state(0); 같은 새로운 방식으로 반응성을 관리
컴포넌트 정의 방식 변경: 기존 export let props 방식 대신, 일반적인 JavaScript 함수 스타일을 따름
SvelteKit과의 통합 강화: SvelteKit과 더욱 긴밀하게 통합되어 사용성이 향상됨
새로운 CLI 도구 (sv CLI) 도입: 프로젝트 초기 설정을 쉽게 구성할 수 있도록 개선

✅ 한계점

기존의 $: 반응성 방식에 익숙한 사용자들이 적응해야 함
기존 Svelte 3/4 코드베이스와의 호환성이 낮아 마이그레이션이 필요함

4. 정리 (Svelte 3 → 4 → 5 변화 요약)

버전 주요 변화점

Svelte 3	$: 반응성 문법 도입, 가벼운 컴파일 방식
Svelte 4	내부 코드 개선, Vite 최적화, 성능 향상
Svelte 5	Runes 도입, 반응성 시스템 개편, 컴포넌트 정의 방식 변경

결론

Svelte 3는 현재까지 가장 널리 사용되는 버전
Svelte 4는 주로 성능 개선이 중심이었고, 큰 변화는 없었음
Svelte 5는 Runes 도입과 컴포넌트 구조 변경으로 Svelte의 사용성을 대폭 개편

즉, Svelte 5는 기존 Svelte 방식에서 벗어나 새로운 반응성 개념을 도입한 획기적인 업데이트라고 볼 수 있어요. 😊

반응성 처리를 위해 Runes 시스템을 도입한 이유가 뭐야?

Svelte 5에서 기존 $: 문법 대신 Runes 시스템을 도입한 이유는 몇 가지 중요한 개선점을 제공하기 때문이에요.

✅ 1. 기존 $: 문법의 단점

Svelte 3~4에서는 반응성을 처리할 때 $: 문법을 사용했어요. 예를 들면:

<script>
  let count = 0;
  
  $: doubled = count * 2;  // count가 변경될 때마다 doubled도 업데이트됨
</script>

이 방식은 간단하고 직관적이지만, 몇 가지 문제점이 있었어요.

① 스코프 모호성

$: 문법은 실행 순서가 자동으로 결정되는데, 복잡한 로직이 많아지면 어떤 코드가 먼저 실행될지 예측하기 어려움
특히 조건문, 반복문 안에서 반응성 문법을 사용할 때 문제가 발생할 수 있음

② 함수 내에서 반응성을 유지하기 어려움

$: 문법은 스크립트의 최상위에서만 작동함
즉, 함수 내부에서 로컬 상태를 반응형으로 만들기 어렵고, 이를 해결하려면 별도의 store(svelte/store)를 사용해야 했음

③ 복잡한 코드에서 반응성을 추적하기 어려움

$: 문법은 직관적이지만, 프로젝트가 커질수록 변수 간의 의존 관계를 명확하게 추적하기 어려운 경우가 많음

✅ 2. Runes 시스템의 장점

Svelte 5에서는 $: 문법을 없애고, Runes 시스템을 도입했어요. 예를 들면:

import { state, derived } from '@svelte/rune';

const count = state(0);  
const doubled = derived(() => count() * 2);

① 함수 기반 API → 더 명확한 실행 순서

Runes는 함수 호출을 통해 명확하게 실행 순서를 지정할 수 있음
예측하기 쉬운 코드를 작성할 수 있고, 실행 순서가 보다 직관적으로 보장됨

② 함수 내부에서도 반응성 유지 가능

기존 $: 문법은 스크립트 최상위에서만 동작했지만, Runes는 함수 내부에서도 반응성을 유지할 수 있음

function increment() {
  count(count() + 1); // 기존 변수처럼 사용 가능
}

③ 리액티브 상태 관리를 위한 별도 store가 필요 없음

기존에는 svelte/store의 writable()을 사용해야 했지만, Runes의 state()가 기본적으로 같은 역할을 수행
derived()를 사용하면 반응형으로 연산된 값을 쉽게 만들 수 있음

const count = state(0);
const doubled = derived(() => count() * 2);

④ 컴파일러 최적화가 더 쉬워짐

$: 문법은 Svelte 컴파일러가 내부적으로 코드의 실행 순서를 분석해야 했음
하지만 Runes는 함수 기반이므로, 실행 순서를 컴파일 단계에서 쉽게 최적화할 수 있음

✅ 3. 결론: Runes 도입 이유 요약

기존 $: 방식의 문제 Runes 도입으로 해결

실행 순서를 예측하기 어려움	함수 호출 순서로 명확하게 지정 가능
함수 내부에서 반응성을 유지하기 어려움	어디서든 반응형 상태 관리 가능
store를 별도로 사용해야 함	state() 하나로 해결 가능
컴파일러가 실행 순서를 분석해야 함	명확한 실행 구조로 최적화 가능

결국, 코드의 예측 가능성을 높이고, 유지보수를 쉽게 하며, 컴파일 성능을 개선하기 위해 Runes 시스템이 도입된 거예요. 😊

그러면 3으로 만든 프로젝트를 5로 마이그레이션 하는게 장기적으로 유리하겠네?

마이그레이션을 고려할 때 중요한 포인트는 현재 프로젝트의 규모, 유지보수 필요성, 그리고 Svelte 5의 장기적 이점이에요. 결론부터 말하면, 장기적으로는 Svelte 5로 마이그레이션하는 것이 유리하지만, 당장 급하게 전환할 필요는 없어요.

✅ Svelte 5로 마이그레이션이 유리한 이유

Runes 시스템 도입으로 코드 관리가 쉬워짐
- $: 문법이 사라지고 state(), derived() 같은 함수 기반 API로 통일
- 실행 순서가 명확해지고, 버그 발생 가능성이 줄어듦
컴파일러 최적화로 성능 개선
- $: 문법 기반 반응성보다 Runes가 최적화하기 쉬워 성능이 향상됨
- Svelte 5의 새로운 구조가 앞으로 더 많은 기능 추가와 개선을 지원할 가능성이 높음
SvelteKit과의 통합이 강화됨
- SvelteKit이 Svelte 5와 함께 발전하며, 앞으로 Svelte 3/4보다는 Svelte 5 기반의 프로젝트가 표준이 될 가능성이 큼
향후 유지보수 및 생태계 확장 고려
- 공식적으로 $: 문법이 더 이상 사용되지 않으므로, 앞으로 새로운 기능은 Runes를 중심으로 개발될 가능성이 높음
- 커뮤니티도 점점 Svelte 5로 이동할 것이기 때문에, 장기적으로는 기존 방식보다 Svelte 5 스타일이 유지보수하기 쉬움

❌ 당장 마이그레이션을 고려할 때 주의할 점

완전한 API 변경으로 기존 코드 수정이 필수
- $: 문법이 아예 사라졌기 때문에, 기존 코드를 하나하나 변환해야 함
- writable(), get(), set() 등을 사용하던 기존 상태 관리 코드도 state() 기반으로 수정 필요
생태계가 아직 완전히 전환되지 않음
- 많은 Svelte 라이브러리와 플러그인이 아직 Svelte 5를 완벽히 지원하지 않을 수도 있음
- 특히, Svelte 5의 Runes 시스템이 기존 store 기반 라이브러리와 다를 수 있음
기존 프로젝트가 안정적으로 동작하고 있다면 당장 변환할 필요 없음
- Svelte 3/4도 계속 사용 가능하고, 당장 사라지지는 않음
- svelte-adapter 같은 마이그레이션 도구가 나올 수도 있으므로, 좀 더 안정적인 지원이 마련된 후 변환하는 것이 효율적일 수도 있음