피엠위키(PmWiki)로 구축해놓고 거의 방치되어 있던 Accessibilty Korea에 스벨트킷(SvelteKit)을 적용했다. Accessibility Korea는 예전에 접근성 관련된 일을 많이 할 때 정보화 진흥원에서 하지 않는 일들을 진행해 보려고 야심차게 만든 사이트였지만 많은 활동을 하지는 못했다. 장애인 웹 사용 실태 조사 빼고 나머지 내용은 크게 의미가 없는 것 같아서 이번에 싹 정리 했다. 웹 접근성 진단 서비스라는 좀 특이한 서비스가 돌아가고 있는데 예전 웹 접근성 품질마크 사전 평가에 사용되던 서비스다. 품질마크가 민간으로 넘어가서 자연스럽게 중단되었어야 했는데 이상하게도 사람들이 계속 들어오고 있어서 유지하고 있었다. 이 사이트에서 제일 많이 사용되는 기능이어서 메인으로 올려버렸다.

스벨트킷은 스벨트의 요즘 핫한 서버 사이드 랜더링 버전이다. 새퍼(Sapper)라는 동일한 목적의 프로젝트가 있었는데 개발 종료되고 스벨트 킷으로 대체 된다. 넥스트(next.js)나 넉스트(nuxt.js)를 직접 써보진 않았지만 유사한 도구라고 보면 된다. 이제 막 일반 공개가 되어서 초기 단계고 버그도 있지만 후발 주자여서 그런지 충분한 기능을 제공하고 있고 스벨트 답게 간결하다.

기존 콘텐츠를 거의 다 버려서 내용 이관은 어렵지는 않았다. 하지만 접근성 평가하는 부분까지 모두 자바스크립트로 옮기기에는 너무나 귀찮아서 핵심 로직은 그대로 뒀다. 스벨트는 몇개의 프로젝트를 해봐서 별 문제 없었는데 가장 어려었던 부분은 스벨트킷에서 사용하는 바이트(Vite)관련된 부분이었다. 바이트는 개발서버나 핫리로드, SSR 등을 제공하는 프론트엔트 툴링인데 브라우저의 esm 기능을 최대한 활용해서 번들링을 피하고 속도를 엄청 끌어올렸다. 바꿔 말하면 모듈들이 다 esm이어야 한다는 말인데 내 경우 cjs 기반의 sqlite3을 사용하고 있어서 삽질을 좀 했다. 결국 외부 모듈로 빼는 식으로 했는데 스벨트킷도 처음인데 바이트까지 살펴보는게 좀 부담이었다. 외부로 빼는게 올바른 판단이었는지도 아직 잘 모르겠다.

새퍼보다는 스벨트킷이 훨씬 정리되어 있다. 하지만 역시나 계속해서 이렇게 까지 할 필요가 있는가, 이렇게 하는 것이 올바른 방향인가에 대한 생각이 든다. 지금은 리액트가 중심을 잘 잡고 있지만 이제 소켓으로 HTML을 가져와 교체하고 있는 마당에 이 방식이 얼마나 갈지도 궁금하다. 일단 노드로 서버를 구성할 수 있다면 스벨트킷은 상당히 매력적인 도구라는 정도로 정리하고 무슨 도구들이 또 나오는지 봐야겠다.