SvelteKit 3

Svelte 팀의 Rich임. 어제 출시를 위해 마지막 PR, 문서 수정과 리디렉션, CLI 배포, 블로그 글까지 조율하느라 꽤 힘들어서, 끝나자마자 노트북을 닫고 맥주를 마시러 갔음. 요즘 프런트엔드 프레임워크에 대한 관심이 줄어 큰 반응을 기대하지 않았는데, 만족하는 사용자부터 다른 도구를 선호하거나 코딩을 LLM에 전부 맡긴 분들까지 함께 이야기하는 모습을 보니 기쁨.
우리도 코드 세부 사항에 까다로워 LLM 도입이 느린 편이었지만, 점점 더 많은 작업을 에이전트에 맡기고 있음. 프롬프트로 앱을 만드는 시대에 Svelte와 React 중 무엇을 쓰는지 왜 신경 써야 하냐는 질문에는 답할 필요가 있음. Svelte를 쓰면 더 나은 앱을 만들 수 있기 때문임. JavaScript 번들은 작아지고 서버 측 렌더링 시간은 줄어 사용자에게 더 빠르고 효율적인 앱을 제공할 수 있음. 에이전트가 소프트웨어의 양은 크게 늘렸지만 평균 품질은 나아지지 않았고, 오히려 신뢰성은 떨어지는 듯함. 접근성과 점진적 향상을 핵심으로 다루는 프레임워크는 더 나은 결과를 내도록 도와주며, 에이전트의 토큰 사용량도 줄여줌.
이는 원래부터 우리가 내세운 가치이며 에이전트가 등장해도 달라지지 않음. 계속 출시하고 세부 사항을 다듬는 이유도 여기에 있음. 앞으로 선보일 것들에 무척 기대하고 있으며, 이 열정을 나누는 커뮤니티의 지원에 감사함.

Svelte의 접근성 안전장치는 에이전트도 올바른 방향으로 이끌어줄 듯함. LLM에 유리하다는 이유만으로 프런트엔드 생태계가 React로 수렴한다면 아쉬울 것임. 특히 느린 모바일 기기에서 React의 성능은 최적과 거리가 있음.

2022년부터 열렬한 Svelte 사용자였음. 에이전트가 React를 기본으로 고른다고 더 나은 기술이 되는 건 아님..

코딩 에이전트에 점점 더 많이 맡기지만, 직접 선택할 수 있는 프로젝트에서는 계속 Svelte/SvelteKit을 사용함. Angular를 쓰다가 넘어왔는데 작업이 늘 수월했고, 학습 예제의 품질 덕분인지 생성되는 코드의 평균 품질도 다른 프레임워크보다 낫다고 느낌.
번들 크기와 성능은 여전히 중요하며, 원격 함수도 기대됨.

Svelte/SvelteKit 덕분에 프로그래밍이 제대로 이해되기 시작했고, 몇 년이 지난 지금은 내 작업을 인정해주는 이들을 위해 좋아하는 일을 하고 있음. 만드는 거의 모든 것의 출발점으로 SvelteKit을 가장 선호함.

Niftic에서는 수년째 고객 프로젝트에 거의 전적으로 Svelte/SvelteKit을 사용해왔음. v3를 본격적으로 살펴보려 함.

React를 오랫동안 사용한 끝에 Svelte가 가장 좋아하는 프런트엔드 프레임워크가 됨. Opus 4.6~4.8과 동시대 모델들이 나오기 전에는 LLM이 Svelte 4와 5 코드를 자주 혼동했음.
올해 개인 프로젝트, 대규모 업무, 일회성 웹 도구에 많이 써보니 최신 LLM은 Svelte를 잘 다룸. 원격 함수 같은 실험적 기능도 잘 처리함. 취향 차이겠지만 React나 Vue보다 Svelte 코드가 읽기 편함.

Svelte는 버전이 바뀔 때마다 방식을 바꿨으니 이런 결과가 생길 만함. v1부터 좋아했다 싫어했다를 반복해왔으며, 지금도 Claude는 Svelte 5를 지정해도 가끔 속성 선언에 export let을 쓰려 함.

가중치 공개 모델을 원한다면 DeepSeek Latest가 Svelte/SvelteKit 앱을 잘 만들어줌.

Svelte가 좋았다면 Q.js도 마음에 들 수 있음. https://github.com/Qbix/Q.js.
다른 프레임워크와 달리 빌드 단계가 전혀 필요하지 않으며, 메서드와 컴포넌트 코드를 필요할 때 불러옴.

돈을 받고 하는 일이 아니라면 앞으로 HTMX나 Elixir/Phoenix 외에는 쓰지 않을 생각임.

React를 좋아하던 공동 창업자들에게 Svelte/SvelteKit을 도입하면서 싫어할까 걱정했는데, 모두 아주 만족함.
Orb.net에서는 웹사이트뿐 아니라 데스크톱·모바일 앱에도 폭넓게 사용함. Wails로 Go 코드를 연결하고 SvelteKit/Svelte로 사용자 인터페이스를 구현함. 여러 플랫폼을 지원하는 생산성이 뛰어나고 바이너리 크기도 20MB 미만이라 Electron과는 확연히 다름.

최근 Wails를 발견하면서 Svelte까지 접했는데 무척 만족스러움. Go 백엔드와 Svelte 프런트엔드로 Electron보다 훨씬 작은 데스크톱 앱을 만들 수 있다는 조합이 매력적임.

Svelte 웹사이트는 속도가 특히 좋음. orb.net도 확인해보니 페이지가 즉시 열림. 다른 프레임워크로 만든 사이트에서는 좀처럼 보기 어려운 속도임.

Wails는 Go용 Tauri 같은 도구인가?

2020~2024년에 Svelte를 주력 프레임워크로 매일 사용했음. 몇 년이 지나서야 독자적인 언어가 최대 강점이자 최대 약점이라는 걸 깨달음. 이를 지원할 전용 도구를 만들고 유지하는 데 많은 노력이 들며, 작은 Svelte 팀과 커뮤니티만의 부담도 아님. JetBrains의 Svelte 플러그인은 지금도 형편없어서 사실상 VSCode 확장에 묶이게 됨.
결국 일반 TS/TSX로 작성할 수 있다는 이유로 Solid로 옮겼음. 좋든 싫든 TS/TSX는 이제 표준이라 대부분의 편집기와 IDE가 기본 지원함. https://plugins.jetbrains.com/plugin/12375-svelte

2023년부터 Svelte를 많이 사용했지만 VSCode는 평생 한 번도 열어본 적 없음.

이 스레드의 흐름과는 묘하게 대비되지만, LLM으로 충분히 해결할 수 있는 문제라고 봄. Svelte 언어와 JetBrains API 모두 명확히 정의되어 있으니 LLM으로 플러그인을 생성하지 못할 이유가 없음.

Svelte로 직접 프로그래밍하는 개발 경험을 좋아함. 다만 지금은 2026년 10월이니 묻고 싶음. Svelte와 React의 바이브 코딩 경험은 다른가? 둘 다 써본 분의 이야기를 듣고 싶음.

차이가 있음. 약 1년 전 SvelteKit 기반 정적 사이트 생성기 https://statue.dev를 오픈소스로 공개하고 AI 도구와 제품 작업 흐름을 구축하기 시작했지만, 지금은 중단한 상태임.
2024~2025년 대부분의 기간 동안 최상위 모델들도 Svelte 4와 5의 호환성을 제대로 다루지 못했음. 주요 기여자들이 벤치마크와 MCP 등으로 개선하려고 애썼지만, 개인적으로 그런 도구를 좋아하지 않아 새 프로젝트에는 순수 CSS/JS를 쓰기로 함. https://svelte.dev/docs/ai/prompts/llms.txt처럼 많은 자료를 도구로 매번 읽게 하면 비용이 몇 배로 늘어남. 모두 입력 토큰과 맥락 수집을 위한 추가 대화 차례로 이어짐. 학습 우선순위에 들기에는 너무 작은 생태계라는 딜레마는 신규 개발 도구 대부분이 직면한 큰 문제임. 기존 강자들은 주요 벤치마크와 학습에 반영되어 모델 가중치에 지식이 내재되지만, 다른 도구들은 매번 문맥 안에서 사용법과 목적을 알려줘야 하므로 성능과 토큰 비용 면에서 불리함. Svelte 팀의 잘못은 아니며, 개발 도구 프로젝트가 최상위 모델의 학습 과정에 기여하거나 자체 코딩 에이전트 모델을 제대로 후속 학습할 더 나은 방법이 필요함.

원래는 별 차이가 없다고 답했을 것임. Svelte의 개발 경험과 성능은 작은 생태계를 감수할 가치가 있었고 모델도 잘 다뤘음.
그런데 모델에 React+Shadcn 프로젝트를 한 번에 생성하게 하니 세부 사항까지 완벽했고, 고칠 버그도 찾지 못했음. 직접 코딩할 때의 기술과 개발 경험은 여전히 Svelte가 낫다고 생각하지만, React와 LLM의 조합은 놀라웠음. 코드를 읽고 수정하는 일도 좋아하므로, 모델이 격차를 완전히 좁혀 계속 Svelte를 쓸 수 있기를 바람.

앞으로 가장 중요한 기능은 엄격함이 될 것임. 에이전트가 작업할 가장 안전한 경계를 제공하는 프레임워크가 주목받을 것이며, 그래서 Effect의 미래가 밝다고 봄.

2026년 초에는 모델이 Svelte 4와 5를 혼동해서 꽤 고생함. 원격 함수가 출시되면 load 함수와 원격 함수 사이에서도 같은 일이 생길 것이라 봄.

Svelte에는 계속 다시 계산하는 섀도 DOM이 없으니 대부분의 앱에서 성능과 메모리에 상당한 이점이 있을 듯함. 다만 전문가가 아니라 정확한지는 확신하지 못함.

Svelte에서 가장 좋은 점은 기본 HTML에 가깝다는 것임. React를 늘 사용하는 게 아니라면 계속 변화를 따라가야 하는 부담이 있는데, Svelte는 덜함.

2026년에도 직접 코드를 작성하는 사람이 많은가? 이제 Claude/Codex가 처리하니 React의 변화를 따라가는 일을 걱정할 사람은 많지 않을 듯함.

React를 먼저 배우고 Svelte를 배웠음. Svelte는 이점은 그대로 갖추면서도 얻는 것보다 고통이 큰 React의 추상화는 없는 듯함.

지난 몇 년간 SvelteKit은 신선한 돌파구였음. 업무상 Next.js를 써야 했지만 SvelteKit이 훨씬 마음에 들며, 이번 출시 버전도 써보고 싶음.

압도적으로 많은 학습 데이터 덕분에 LLM이 React를 훨씬 잘 다루는 세상에서 Svelte를 쓸 이유는 무엇인가?

아직도 끝없이 중첩된 폴더에 +page.svelte 를 두는 끔찍한 라우팅 명명 규칙을 고수하고 있는가?

SvelteKit 3의 개선에서 뛰어난 개발 경험을 만들려는 팀의 노력이 드러남. SvelteKit 2에서는 Svelte 4에서 5로의 전환도 매우 잘 처리했으며, 실서비스에 쓰기에도 아주 안정적인 프레임워크임.

미리 Markdown으로 추출해둔 SRD를 바탕으로 Opus 5.5에 5e 캐릭터 시트 관리 도구를 만들어달라고 했더니, 세션 한도의 20%만으로 전부 작동하게 만들었음. 프런트엔드뿐이라 아주 복잡하지는 않고 일부 UI가 어색하거나 취향에 맞지 않지만, 처음부터 기능이 모두 동작함.
지난 일주일쯤 TanStack으로 작업할 때는 이만큼 빠르고 쉽지 않았음. 다만 회사에서 SvelteKit을 사용하므로 내게 더 익숙하다는 점은 감안해야 함. AI가 Svelte를 잘 다루지 못할까 걱정된다면 적어도 Opus는 잘한다고 보증할 수 있고, svelte-check 같은 도구로 실수도 잡아낼 수 있음.