저는 2026년 7월 Svelte 블로그 게시물을 보고 즉시 이해했습니다. 오랫동안 사용되어 온 svelte.config.js 파일이 이제 Vite 설정 안에 들어갈 수 있다는 사실을 말이죠. 여러 개의 SvelteKit 앱을 유지 관리하는 사람으로서, 이 변화는 특히 Vite 플러그인, 환경 변수(environment variables), 그리고 커스텀 빌드 단계를 이미 다루고 있을 때 생산성을 크게 높여주는 변화로 느껴집니다. 이 포스트에서는 왜 이러한 전환이 중요한지 설명하고, 채택해야 할 정확한 코드를 보여주며, 업그레이드를 결정하기 전에 고려해야 할 실질적인 트레이드오프(trade-offs)에 대해 논의하겠습니다.

왜 지금 이 변화가 중요한가

SvelteKit은 항상 Vite를 기반으로 구축되어 왔지만, 두 설정은 별개의 파일에 존재했습니다:

├─ vite.config.js
├─ svelte.config.js   ← Svelte 전용 설정
└─ src/

이러한 분리는 몇 가지 마찰 지점을 발생시켰습니다:

1. 중복된 컨텍스트 (Duplicate context) – 두 파일 모두 defineConfig 래퍼(wrapper)를 노출하므로, import { sveltekit } from '@sveltejs/kit/vite'를 반복하고 옵션을 수동으로 병합해야 하는 상황이 발생합니다.
2. 순서에 민감한 플러그인 (Order-sensitive plugins) – 일부 Vite 플러그인은 SvelteKit 자체 플러그인보다 먼저 실행되어야 하지만, 순서를 보장할 수 있는 유일하고 확실한 방법은 vite.config.js를 편집한 다음 svelte.config.js를 동기화 상태로 유지하는 것을 기억하는 것뿐이었습니다.
3. 도구의 혼란 (Tooling confusion) – IDE와 타입 체커(type-checkers)는 때때로 결합된 설정의 최종 형태를 추론하는 데 어려움을 겪으며, 이는 잘못된 경고(false-positive warnings)로 이어집니다.

2026년 7월 릴리스(SvelteKit 2.0)는 별도의 svelte.config.js가 필요하지 않게 합니다. vite.config.js 내부에 kit 키를 내보냄으로써(exporting), 프레임워크는 Vite의 설정 객체에서 직접 자신의 설정을 읽을 수 있습니다. 이는 빌드 파이프라인(build pipeline)에 영향을 미치는 모든 것에 대해 단일 진실 공급원(single source of truth)을 갖게 된다는 것을 의미합니다.

기존 방식 – 빠른 복습

만약 아직 2026년 7월 이전 버전을 사용 중이라면, 프로젝트는 아마 다음과 같은 모습일 것입니다:

// svelte.config.js
import adapter from '@sveltejs/adapter-auto';
import preprocess from 'svelte-preprocess';
...

// vite.config.js
import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';
...

SvelteKit보다 먼저 실행되어야 하는 Vite 플러그인 (Vite plugin)을 추가할 때마다 plugins 배열의 순서를 조정해야 했으며, 별칭 해석 (alias resolution)과 같은 작업을 위해 여전히 두 개의 설정 파일을 동기화해야 했습니다.

새로운 방식 – 모든 것을 vite.config.js에서 처리

SvelteKit 2.0 (2026년 7월)부터는 svelte.config.js를 완전히 제거하고, Vite 설정 내의 sveltekit 키 아래에 kit 설정을 포함할 수 있습니다. 다음은 최소한의 예시입니다:

// vite.config.js
import { defineConfig } from 'vite';
import { sveltekit } from '@sveltejs/kit/vite';
...

주의할 점 몇 가지:

• sveltekit 함수는 이제 기존 svelte.config.js의 형태(kit, preprocess 등)를 반영하는 객체를 인자로 받습니다.
• 여전히 동일한 어댑터 (adapters)와 프리프로세서 (preprocessors)를 임포트합니다. 내부적인 동작 방식은 변하지 않습니다.
• 모든 Vite 플러그인이 동일한 plugins 배열에 존재하므로, 순서가 명시적이고 명확합니다.

이미 svelte.config.js가 있다면, 해당 파일에서 내보낸 (exported) 객체를 sveltekit({ … }) 호출부로 단순히 복사한 뒤 파일을 삭제하면 됩니다. Vite가 병합된 설정을 자동으로 인식합니다.

단계별 마이그레이션 체크리스트

1. SvelteKit 2.0으로 업그레이드

   npm i -D @sveltejs/kit@2.0 vite@5.0

(두 패키지는 함께 출시되므로, 피어 의존성 (peer dependency) 정렬은 안전합니다.)

1. svelte.config.js 제거 – 만약을 대비해 먼저 백업해 두세요.

2. vite.config.js에 kit 블록 추가 – 위의 코드 스니펫을 템플릿으로 사용하세요.

이전에 svelte.config.js를 참조하던 커스텀 Vite 플러그인이 있다면, 그에 따라 임포트(import) 경로를 조정하세요.

3. 개발 서버 실행 – npm run dev. 이제 CLI에서 vite.config.js로부터 설정을 읽고 있다고 보고할 것입니다.

4. 빌드 결과물 확인 – npm run build. 다른 옵션을 변경하지 않았다면, 생성된 build/ 폴더는 업그레이드 전 버전과 동일해야 합니다.

5. CI 스크립트 업데이트 – CI 파이프라인(pipeline)에서 svelte.config.js를 Docker 이미지로 명시적으로 복사하거나 캐싱하고 있다면, 해당 단계를 제거하세요.

2026년 7월에 또 다른 새로운 소식은 무엇인가요?

설정 병합이 주요 헤드라인이지만, 이번 릴리스에는 이러한 변화를 자연스럽게 느끼게 해주는 몇 가지 관련 개선 사항도 도입되었습니다:

• SvelteKit을 위한 타입이 지정된 Vite 설정 (Typed Vite config) – sveltekit 헬퍼(helper)가 이제 완전히 타입이 지정된 UserConfig 객체를 반환하므로, TypeScript 사용자는 동일한 파일에서 Vite와 SvelteKit 옵션 모두에 대해 자동 완성(autocomplete) 기능을 사용할 수 있습니다.
• 개선된 에러 메시지 – 실수로 kit 옵션을 sveltekit({ … }) 호출 외부에 배치할 경우, 개발 서버는 "SvelteKit config must be passed to the sveltekit plugin"이라는 명확한 에러를 발생시킵니다.
• 향상된 SSR 처리 – 새로운 설정 경로는 Vite의 SSR 엔트리 포인트(entry points)와 일치하여, 별도의 설정 파일 없이도 커스텀 서버 미들웨어(middleware)를 추가하기가 더 쉬워졌습니다.

이러한 미세 조정(tweaks)들은 점진적이지만, SvelteKit이 이제 형제 프레임워크가 아닌 일급 Vite 플러그인(first-class Vite plugin)이라는 개념을 강화해 줍니다.

개인적인 견해: 업그레이드할 것인가 말 것인가?

일상적인 관점에서 볼 때, 두 개의 설정 파일을 하나로 통합하면 인지적 부하 (mental overhead)를 줄일 수 있습니다. 새로운 에일리어스 (alias)를 추가하거나 Vite 플러그인 (plugin) 순서를 조정하기 위해 더 이상 두 개의 파일을 열 필요가 없습니다. 모든 것이 Vite가 이미 기대하는 위치에 존재하기 때문입니다. 마이그레이션 (migration) 과정은 간단합니다. 기존의 kit 객체를 sveltekit 호출부로 복사하여 붙여넣기만 하면 되며, 런타임 (runtime) 상의 파괴적인 변경 사항 (breaking changes)은 없습니다.

유일한 트레이드오프 (trade-off)는 이제 단일 장애점 (single point of failure)이 생긴다는 점입니다. vite.config.js에서의 오타 하나가 Vite와 SvelteKit을 동시에 망가뜨릴 수 있습니다. 이러한 위험은