SvelteKit 1.0 발표!

* Announcing SvleteKit 1.0 아티클을 번역 및 참고하여 작성한 글입니다.

간결해진 웹 개발

2년 간의 개발 끝에, 마침내 스벨트킷 1.0 버전이 출시되었다.

오늘부터는 어떤 형태와 크기의 스벨트 앱이든 스벨트킷을 사용하여 만들기를 권장한다.

스벨트킷 1.0은 스벨트 코어 팀과 폭넓은 커뮤니티에서 수천 시간 작업한 결과이다. 소규모 프로젝트의 1인 개발자이든 대규모 팀의 일원이든, 프로덕션급 웹사이트를 빌드할 때 스벨트킷이 가장 즐거운 방법이 될 것이다.

 

스벨트킷을 시작하려면 npm create svelte@latest을 실행하고, 공식 문서와 (실험적인)인터랙티브 튜토리얼을 살펴보자.

Svelte Radio Live: the Christmas special

스벨트킷이란

스벨트킷은 성능이 좋고 익히기 쉬워 개발자들에게 사랑받는 UI 컴포넌트 프레임워크인 스벨트를 이용해 웹 어플리케이션을 개발할 때 사용하는 프레임워크이다.

스벨트와 같은 컴포넌트 프레임워크를 사용해 보았다면 프레임워크가 DOM을 직접 조작하는 것보다 유저 인터페이스 구축을 더 쉽게 할 수 있도록 해 준다는 것을 알 것이다.

하지만 이러한 프레임워크들은 다음과 같은 많은 질문들에 해답을 내놓지 못한다.

• 소스 코드를 어떻게 구성할 수 있는가?
• 서버 사이드 렌더링을 어떻게 추가할 수 있는가?
• 서버와 브라우저에서 동작하는 라우팅을 어떻게 추가할 수 있는가?
• 어떻게 클라이언트 사이드 라우팅에 접근할 수 있게 하는가?
• 데이터를 어떻게 가져올 수 있는가?
• 데이터를 어떻게 가공할 수 있는가?
• 오류를 어떻게 처리해야 하는가?
• 프로덕션 빌드를 어떻게 최적화할 수 있는가?
• 환경 변수를 민감하고 안전하게 다루려면 어떻게 해야 하는가?
• CSP 헤더를 설정하고 CSRF 방어를 추가하려면 어떻게 해야 하는가?
• 무엇을 캐시해야 하는지 알려주는 서비스 워커를 추가하려면 어떻게 해야 하는가?
• 애플리케이션을 배포하기 위해 무엇을 준비해야 하는가?

애플리케이션 프레임워크는 이러한 질문들에 답할 수 있도록 설계되었고, 스벨트킷 또한 그렇다.

스벨트킷을 프로덕션에 사용해 본 많은 사람들을 포함한 베타테스터들의 실제 요구와 그들의 가치 있는 피드백, Next.js나 Remix와 같은 다른 애플리케이션 프레임워크들의 훌륭한 아이디어들이 그 배경에 있다.

무엇이 다른가

오늘날의 웹 개발자들에게는 선택의 여지가 없다.

앞에서 언급된 프레임워크들 외에도 Astro나 검증된 서버 프레임워크인 Rails, Laravel, 그리고 그 외에 수백만의 정적 사이트 생성기들이 있다. 이들은 모두 훌륭한 도구이고, 그중에서 선택하는 것도 좋을 것이다.

하지만 스벨트킷은 조금 다르다.

 

1. 전통적인 멀티페이지 어플리케이션(MPA) 프레임워크와 달리 초기 서버 렌더링 페이지 로드 후 클라이언트 사이드 탐색이 기본으로 설정된다. 이로 인해 페이지 전환이 빨라지고, 사이드바의 스크롤 포지션과 같은 페이지 간의 상태가 유지되며, 데이터 사용량이 줄어들 수 있다. 또한 모든 페이지 로드 시마다 분석하는 것과 같은 써드 파티 스크립트의 재실행을 방지한다.

 

2. 전통적인 서버 프레임워크와 달리, HTML을 생성하고 클라이언트 사이드 상호작용을 다루는 두 개의 밀접한 앱을 사용하는 대신 하나의 언어를 사용할 수 있다. 스벨트킷은 자바스크립트가 실행되는 모든 곳에서 실행되므로 앱을 전통적인 노드 서버로 배포할 수도 있고, 엣지를 포함한 서버리스를 이용하여 배포할 수도 있다.

 

3. 정적 사이트 생성기와 달리, 성능 저하나 페이지 로드 후 브라우저에서 가져오는 레이아웃 쉬프트 효과 없이 개인화되거나 동적 데이터를 가지는 앱을 빌드할 수 있다.

 

스벨트킷을 사용하면 유연함을 가질 수 있다. 많은 프레임워크는 앱을 빌드하는 한 가지 올바른 방법이 있다고 가정하지만, 현실은 좀 더 미묘하다.

예를 들어, 정적 페이지를 미리 렌더링하는 것이 단지 캐시 컨트롤하는 방법이라는 것은 사실이 아니다.

이는 엣지 함수가 접근할 수 없는 파일 시스템에서 빌드 타임에 유효성을 검증하거나 데이터를 렌더링할 수 있으며 취약한 데이터베이스에 대한 대비책이 될 수도 있다.

모든 것에 서버 사이드 렌더링이 필요하다는 것은 사실이 아니다.

좋은 SEO를 가진 강력하고 성능 좋은 앱을 위해서는 기본적으로 서버 사이드 렌더링이 좋은 선택이지만, 많은 예외가 있다.

 

스벨트킷 앱에서는 이 선택지를 원하는 만큼 취할 수 있다.

예를 들어 이 페이지는 사전에 렌더링되어 있지만 REPL은 동적 데이터를 이용하여 렌더링된다.

한 줄의 코드로 이 둘을 서로 전환할 수 있다. 이러한 접근법으로 구축한 앱을 'transitional apps'라고 부른다.

스벨트킷과 함께 사용할 수 있는 것은 무엇인가

스벨트킷은 엄청나게 빠른 빌드 도구인 Vite를 사용하기 때문에 핫 모듈 새로고침, 타입스크립트 등 개발자가 의존하는 많은 것들을 즉시 사용할 수 있도록 지원한다.

방대한 Vite 와 롤업 생태계에서 플러그인을 설치하여 다른 툴을 지원할 수도 있다.

 

스벨트킷 프로젝트를 생성할 때 타입스크립트, ESLint, Prettier, end-to-end 브라우저 테스트용 Playwrite, 및 유닛 테스트용 Vitest를 추가할지 묻는다.

Tailwind, Supabase 등 인기 있는 많은 프로젝트에 대한 통합 가이드도 이미 존재한다.

컴포넌트 스토리를 위해 스토리북이나 Histoire를 사용할 수 있다.

커뮤니티로 유지되고 있는 svelte-add를 사용하면 늘어나는 다른 통합 목록을 하나의 명령으로 추가할 수 있다.

 

그리고 물론 npm이 제공하는 모든 기능에 접근할 수 있다.(일부 패키지에는 Node.js가 필요하므로 노드 베이스 플랫폼에 배포할 때만 사용할 수 있다.)

앱을 어디에 배포할 수 있는가

어디든 배포할 수 있다!

스벨트킷 CLI는 Node.js를 로컬로 설치해야 하지만 프레임워크 자체는 어떤 플랫폼에도 의존하지 않는다.

즉, 자바스크립트가 실행되는 모든 환경에 배포할 수 있다.

 

이를 가능하게 하는 것은 어댑터이다.

기본 어댑터인 adapter-auto는 Vercel, Netlify, Cloudflare Pages와 Azure Static Web Apps을 zero-config로 지원하고 있으며 앞으로 더 많은 플랫폼이 지원될 예정이다.

커뮤니티에서 제공하는 어댑터는 Deno, Bun, Firebase, App Engine, AWS Lambda 등의 많은 플랫폼을 추가로 지원하고 있다.

 

adapter-node를 이용하면 앱을 Node.js 서버로 배포할 수도 있다.

 

만약 앱 전체가 사전 렌더링에 적합하거나 SPA라면 GitHub Pages를 포함한 모든 웹 서버에서 스벨트킷을 정적 사이트 생성기로 변환해 주는 adapter-static을 사용할 수 있다.

마이그레이션

스벨트킷의 사전 릴리즈 버전으로 구축된 앱이 있다면, 안정적인 릴리즈 버전이 사전 릴리스 버전 간 마이그레이션에 사용된 오류와 경고를 제거하므로 1.0으로 업그레이드하기 전에 최종 사전 릴리즈 버전인 @sveltejs/kit@1.0-next.588로 업그레이드하는 것이 좋다.

또한 이 마이그레이션 가이드를 참조하는 것도 추천한다. 특히 현재 1.0.0-next-406 이전 버전을 사용 중인 경우에는 더욱 그렇다.

다음 단계

스벨트킷 1.0은 시작이지 끝이 아니다.

이제 프로덕션에 사용할 준비가 되었지만, 막 시작한 단계이다.

로드맵에는 i18n 기본 지원, 점진적 정적 재생성(incremental static regeneration), 세분화된 배포 영역 및 런타임 제어, 이미지 최적화와 같은 많은 개선 사항이 포함되어 있다.

나중에 더 자세히 나오겠지만 내년에는 Svelte 4에 대한 작업도 시작할 예정이다.