Svelte 구축할 때 경험에 의한 장단점

작년에 Next.js 로 프로젝트를 만들면서, 특정 연구과제 프로젝트는 헤까닥 돌아가 미친 상태로 SvelteKit 로 구축한 경험이 있다. 실무다. 충격과 공포다 그지 깽깽이들아.
내 경험에 입각한 의견이니, 크로스체크는 본인에 맡긴다.

장점

• 빠른 개발: 확실히 컴포넌트 하나 만드는데 Vue보다 빨랐다. 컴포넌트 안에 구조 잡는 규칙이 빠지고 구문 중심으로 개발하기 때문이다. 물론 Vue 3.2 의 가불기 <script setup> 쓰면 비슷해진다.
• 비동기 구문: React, Vue 에도 없는 {@await} 공식 구문이 <Suspense> 컴포넌트 안 부럽다.
• 쉬운 확장: 특히 아무 CSS 프레임워크 갖다 붙여도 일단 동작 잘 한다. PostCSS, SCSS 궁합은 최고라 자부한다.
• Plain JS와의 친밀도: 내가 Svelte 쓰면서 가장 좋은 경험을 했던 게, 바닐라 JS로 만든, 특히 DOM 건드리는 위주의 비주얼 라이브러리나 프레임워크와의 이식성이 매우 쉬웠다. use:action 속성과 합치면 모듈화는 이미 끝난 셈이다. 이건 강추.
• 일정한 렌더링 성능: 예전엔(Sapper 시절) 스케일과 복잡도는 비례했지만, 현재는 많이 개선되어 스케일에 비해 복잡도가 일정하여 속도가 느려진다면 네트워크와 컨텐츠 크기를 빼면... 없다. 정말 없다. 게다가 React, Vue에 비해 가상 DOM을 안 쓰는 특성 상 빠르다.

단점

• 느린 빌드 속도: 같은 Vite 사용 기준, 타 프론트엔드 기술 대비 빌드 속도가 느리다. 때가 쏘옥~ Vite 쓰면 뭐해 이건 Turbopack 애미가 와도 어쩔 수 없는 태생적 빌드 구조의 한계
• 여전히 아쉬운 TypeScript 지원: React야 애초에 스크립트로 정의하니 강력하지 않은 게 이상하고, 요즘은 그대로 Vue 와 유사해진 Typescript 지원이 돋보이지만, 문제는 상당히 잦은 업데이트와 잦은 추가 기능. React와 Vue의 버전 주기와 버전 관리 정책에 비하면, 진보적인 것까진 좋으나 신규 문법이 생기면 Typescript 가 못따라가는 경향이 있다.
• 작은 생태계: React와 Vue에 비하면 생태가가 작은 건 어쩔 수 없는 현실. Apple, IBM, IKEA가 쓰면 뭐해 작은데... 갖다 쓸 게 한정적이라는 점은 아쉬운 점이지만, 다행히도 JS 친밀도를 통해 일반 JS에서 제공하는 라이브러리나 프레임워크를 손쉽게 도입하는 것으로 타협 가능.
• 작은 커뮤니티: React나 Vue 질문 올라오면 금방 답변이 오지만, Svelte 질문은 답변을 받으려면 상대적으로 시간이 더 필요하다.

추천 케이스

• 관리자 페이지: 왜냐고 묻는다면, Apple의 애플뮤직 베타가 스벨트로 만들었고, New York Times, Bloomberg 등의 언론사의 컨텐츠 페이지, IKEA의 컨텐츠 페이지가 스벨트로 만든 만큼, 특정 컨텐츠를 기술하고 관리하는 측면에서 목적이 확실한 웹 앱 구축에 가장 유리하다.
• CMS 페이지: 컨텐츠 중심의 페이지를 만든다면, Vue보다 더 빠른 구축과 표현이 가능하다.

비추 케이스

• 통합: 그냥 하지마라. 이런 건 React 같은 역할 집중에 맞는 플랫폼이 오히려 낫다.
• SNS: 굳이 스벨트로 하고싶으면 Astro 같은 아일랜드 아키텍쳐를 끼고 하는 게 낫다. 애초에 소셜 네트워크는 작은 소셜의 집합체인 구조인 만큼, 작은 컴포넌트를 대량으로 만들어야 하는 마이크로 아키텍처를 따르게 되어 있다. 물론 성능 자체는 스케일에 비해 복잡도는 일정하지만, 관리 단위로 넘어가면 얘기가 다르다. Vue는 그나마 자체적으로 JSDoc 쓰고 명칭 지정도 가능해서 그나마 관리가 편하지만, Svelte는 그런 문서화 기회가 없다. 하고싶으면 .d.ts 파일 만들어서 따로 문서화 해야 한다. 그렇다고 이걸 컴포넌트로 제작해서 하겠다면 가능이야 하겠지만... 귀찮지 않니?

대규모 프로젝트일 경우

대규모 프로젝트라면 Svelte 도 충분한 성능이 입증되었다. Ember.js 만 주구장창 쓰는걸로 알려진 애플이 미쳤다고 스벨트를 Apple Music에다 썼는데, 베타긴 하지만 운영하고 있고 애플 생태계를 생각하면 스케일이 클 수밖에 없지만 빠른 렌더링 속도를 보여주고 있고, IKEA는 말할 것도 없이 이상할 정도로 빠르다(단, 쇼핑 컨텐츠는 Svelte 안 쓴다).

하지만 관리 측면에서는 오히려 불리하다. React 및 Angular는 순수 스크립트 위주라 문서화가 가장 유리하고, Vue의 경우는 Vue 파일 자체적으로 문서화를 지원할 수 있는 환경이 갖춰져 있지만, Svelte 는 문서화를 하려면 공식 플러그인 연동 말고는 아직까진 뾰족한 수단이 없어 별도의 .d.ts 파일을 직접 작성해야 하는 불편함이 있다.

따라서 Svelte로 대규모 협업을 할거면, 하나의 거대한 프로젝트보다, 작은 프로젝트 여러개 합친 마이크로 아키텍쳐에 적합하다고 보면 된다. 어자피 빌드한 다음 하나로 합쳐도 이상할 것 없고 이건 어느 프론트엔드나 가능한 일이지만, 현재 가상DOM 안 쓰고도 안정화된 기술임은 알아야 한다. 같은 가상DOM 안 쓰는 Preact, Solid 등 JSX 기반 라이브러리도 새로이 급부상을 타고 있지만, 스벨트에 비하면 아직 부족한 생태계와 다른 프론트엔드에 비해 준비가 덜 됐다는 점을 감안하면 현재는 스벨트가 좋은 선택이라 하겠다. (근데 난 SolidJS 준비 중)

마치며

스벨트 질문받는다. 시간나면 답변해주겠다. (전체 생태계같은 포괄적인 질문은 못받을 수 있다.)
끗.