검색 엔진 최적화(SEO; search engine optimization) 측면에서는 서버측 랜더링(SSR; server side rendering)을 사용해야 한다. 하지만 로그인이 필수여서 검색 엔진에 노출되지 않는 사이트에 SSR을 적용할 이유는 별로 없어 보인다. 단일 페이지 애플리케이션(SPA; single page application)은 웹서버만 있으면 되지만 SSR은 서버에 노드(Node.js)를 구동을 해야 하기 때문에 유지 운영해야 하는 컴포넌트를 하나 더 추가된다.

스벨트킷(SvelteKit)은 SSR을 기본으로 사용하지만 필요에 따라서 SPA 모드나 정적 사이트 생성(SSG; static site generation) 용도로 사용할 수 있다. 스벨트킷이 나오기 전에 스벨트(Svelte)를 단독으로 사용할 때에는 라우터로 라우티파이(Routify)를 사용했는데 스벨트킷을 SPA 모드로 운영 가능하다는 얘기를 듣고 프로젝트에 적용해 봤다.

SPA 모드 설정은 매우 간단하다. src/routes/+layout.js 파일에 ssr = false 한 줄 추가하고 svelte.config.js에 @sveltejs/adapter-static을 적용해주면 된다.

export const ssr = false;

import adapter from '@sveltejs/adapter-static';
 
export default {
  kit: {
    adapter: adapter({
      fallback: '200.html' // may differ from host to host
    })
  }
};

이렇게 하면 서버 랜더링은 건너뛰고 브라우저 런타임에서만 돌아가고 빌드했을 때 웹서버 만으로 구동 가능하게 구성된다. window나 document도 자유롭게 쓸 수 있다.

보통 SSR을 사용하여 개발할 때에는 서버와 클라이언트 코드를 분리해서 개발하고 클라이언트에서만 돌아가는 코드는 환경을 체크해서 분리해 주어야 한다. 스벨트킷도 크게 다르지 않은데 특히 +layout.js나 +layout.server.js, +layout.svelte, +page.js, +page.server.js, +page.svelte와 같이 각 역할과 환경에 따라 파일들이 나눠져 있어서 처음에는 굉장히 복잡해 보인다. 여기에 src/routes/(private)/과 같은 그룹 디렉토리까지 더해지면 이렇게까지 라우팅이 복잡할 필요가 있는가 하는 생각이 든다. 파일 기반 라우팅의 한계로 생각된다. 물론 저 파일을 다 사용할 필요는 없고 상황에 맞게 생략이 가능하고 SPA 모드일 때는 거의 +layout.svelte, +page.svelte파일만 사용해도 된다.

내가 필요한 것은 스벨트와 직관적인 파일 기반 라우팅인데 SSR 때문에 복잡도가 올라가는 것 같아서 스벨트킷의 SPA모드는 아직 확신이 들지는 않는다. 다시 SPA 프로젝트 세팅을 한다면 라우티파이를 좀 더 검토해 볼 것 같다. 그렇다고 스벨트킷에 회의적인 것은 아니고 SSR을 사용해야 한다면 망설임 없이 스벨트킷을 선택할 것이다. 스벨트킷 보다는 SSR에 회의적이다. 이렇게 환경별로 분리해서 개발하고 관리할 것이면 굳이 자바스크립트를 서버에서 사용하는 것이 이득이 큰지 모르겠다. JSX만 벗어나면 선택지가 아주 많아지는데 말이다.