지금보고 계시는 이 블로그(velog에서 보고 계신다면 이곳)은 Astro와 Solidjs, Tailwindcss를 활용하여 GitHub Pages에 정적 배포된 것인데요. 블로그를 구축하면서 중요시했던 것들과 여러 기술들을 선택한 이유를 이야기해보려 합니다.
어디서 시작해야 하지? - 요구사항 결정
처음에 블로그를 만들어봐야겠다 생각했을 때엔 다양한 선택지가 있었는데요. 당연히 고려해봄직한 네이버 블로그나 티스토리와 같은 기성 블로그 플랫폼부터, Jekyll과 같은 SSG(Static site generator)까지 여러 방면에서 고려해 보았었습니다.
고려를 하면서 가장 중요시한 조건들은 다음과 같은데요:
1. 마크다운(Markdown)이 지원되어야 할 것
제가 전체적인 글쓰기를 하는 플랫폼은 옵시디언이기 때문에 여기서 사용하는 마크다운을 이용한 글쓰기가 지원되어야 했습니다. 또 아무래도 마크다운을 이용하면 문서의 내용 이외의 것들을 글을 쓸 때 신경쓰지 않아도 된다는 장점이 있죠.
여기서 기성 블로그 플랫폼들이 탈락했습니다 ㅠㅠ
2. 포트폴리오가 될 수 있는 공간이 될 것
제가 구축하려는 블로그의 구상에는 제가 했던 프로젝트의 짤막한 소개 페이지나, 제 소개와 같이 제 퍼스널리티가 표현되고, 주목될 수 있는 포트폴리오 페이지가 포함되어 있었습니다. velog와 같은 서비스는 깔끔한 글쓰기 기능과 좋은 커뮤니케이션 기능이 있지만 이런 기능은 거의 없죠. 홈페이지와 블로그를 따로 구축해 볼까 고민해 보았지만 블로그 포스트를 통한 유입이 쉽게 전환되지 않을 것 같아 고려 대상에서 제외했습니다.
3. 포스팅이 간편해야 할 것
1번과 연결되는 내용인데, 제가 마크다운으로 글을 쓰다 보니 제가 쓴 글을 간편하게 포스팅할 수 있어야 했습니다. 마크다운으로 썼는데 html으로 변환하고 복붙하고… 이런 과정이 글쓰기에 동반된다면 글쓰기 의욕이 사라질 것 같더라고요. 그래서 포스팅을 위한 자동 워크플로우가 구축될 수 있거나 간편하게 포스팅할 수 있는 방법이 있는 플랫폼을 원했습니다. 옵시디언에서 쓰고 버튼 하나만 눌러도 될 정도로요.
이 세가지 조건을 전부 만족하려면 역시 직접 블로그를 구축하는 방법밖에 없었습니다. 블로그 운영에 직접 서버를 구축하게 되면 유지보수도 어렵고, 가격도 꽤 될 것 같아 결국 SSG 프레임워크로 홈페이지를 생성하고 깃허브 페이지와 같은 호스트에 배포하는 방법으로 블로그를 구축하기로 결정했습니다.
어떤 SSG를 사용해야 할까?
직접 웹사이트를 구축하는 일은 제게 익숙한 일이지만(OMSUserDB, arcinfo 등등 여러 웹페이지를 제작해 본 경험이 있으니까요) 블로그의 경우, 처음 만들어보는 유형의 웹페이지기 때문에 구현에 어떤 요구사항이 필요한지 많이 생각했습니다. 가장 큰 부분으로 느껴졌던 것은 마크다운을 HTML으로 변환하는 방법입니다. remark같은 마크다운 처리기는 존재하지만, 이를 일반 웹 사이트에 붙이려면 신경쓸 부분이 많아 보였습니다.
자연스럽게 마크다운을 홈페이지로 쉽게 만들어줄 수 있는 여러 SSG(Static Site Generator)를 찾아보게 되었는데요. Gatsby, Jekyll등 다양한 SSG 후보군이 있었고, 기존 프로젝트에서 여러 번 사용해보았던 SvelteKit나 Nuxt도 고려했으나, 지금 이 블로그가 만들어진 기반인 Astro를 선택하게 되었습니다.
Astro를 만나다
여러 후보군 중에서 굳이 Astro를 선택한 이유는 역시 두번째 조건(포트폴리오가 될 수 있는 공간이 될 것)인데요. 이를 다시 풀이하면 사이트가 컨텐츠-기반 사이트이면서 상호작용-기반 사이트이기도 하여야 한다는 뜻입니다. 물론 조건을 고려해 보면서 이 두가지 분류의 사이트에 각각 다른 기술 스택을 선택하여 개발할까? 라는 생각도 있었지만 Astro의 아일랜드 기능을 보고 그런 선택은 하지 않기로 했습니다.
Astro 아일랜드
Astro의 큰 강점 중 하나인 아일랜드 기능은 꽤나 독특한 컨셉인데요. Astro의 기본 컨셉은 All-in-one web framework 입니다. 즉, 웹사이트를 만들 때 필요한 모든 기능을 포함하겠다…는 당돌한 포부를 가지고 있죠. 이를 허황되지 않게 만들어 주는게 바로 아일랜드 기능입니다. 이를 간단히 풀이하면 Partial hydration 개념이라고 할 수 있습니다.
Partial(혹은 Selective) Hydration은 기존 웹 프레임워크의 개념인 “Hydration을 각 구역마다 하자!” 라고 생각하면 됩니다. 즉, HTML 내부의 각 부분들을 나누어 Hydration이 필요한 경우엔 해당 영역만 수행하고 이외의 구역은 정적으로 놔두어 로딩 속도나 SEO 등의 장점을 가져갈 수 있는 방법입니다.
더 자세한 정보는 Jason Miller의 블로그 글(영어)를 참고하세요.
이런 Partial Hydration을 Astro에선 Islands 라는 이름으로 소개하고 있고, 이 아일랜드의 장점 때문에 Astro에서는 각 컴포넌트에 서로 다른 UI 프레임워크(React, Vue, Svelte, SolidJS 등등…)를 사용할 수 있습니다.
이 장점은 제게 아주 크게 다가왔는데, 다양한 스택(특히 실험적인…)을 많이 사용하는 제 개발 이력의 특성상 각 프레임워크의 장점만을 사용하는 시나리오는 매력적으로 보였고, 앞으로 블로그에서 스케치라는 이름으로 여러가지 장난감들을 만들어 볼 생각이라 그 과정에서 웹사이트의 기반을 그대로 유지할 수 있기 때문에 마다할 이유가 없었습니다.
다양한 기본 기능
게다가 Astro는 결국 Content-driven 프레임워크이기 때문에 블로그 등 컨텐츠를 serving하는 기능이 강력해서 신경을 쓸 것이 많이 없었습니다. 기본 튜토리얼부터가 블로그를 만드는 가이드이기도 했고, 마크다운이나 MDX를 코드 한두줄로 웹 페이지에 표시할 수 있다는 것도 굉장히 좋았습니다.
이렇게 여러 장점을 확인하니 제 요구사항에 맞는 프레임워크라는 생각이 들었고, 생태계가 (비교적)작은 프레임워크를 많이 써본 입장으로썬 멀티 프레임워크가 가능하다는 점도 실험적인 스택에 기존 대형 프레임워크의 큰 생태계까지 가져갈 수 있다는 점을 높게 평가해 제 블로그에 바로 사용해 보기로 마음 먹었습니다.
Reactivity의 동반자, SolidJS
Astro 위에 올라갈 프레임워크로는 SolidJS를 선택했습니다. 아무래도 Astro의 기본 템플릿 엔진만으로는 반응성이 필요한 컴포넌트를 만들기 조금 힘들 것이라고 생각했고(충분한 기능을 제공하지만 생태계도 부족하니까요) 어떤 프레임워크를 도입할까 고민하다 React와 비슷하지만 런타임이 작은 SolidJS를 선택했습니다.
어찌되었든 제가 제작하고자 하는 사이트는 정적 웹사이트이고, 정적 웹사이트에서 높은 성능을 달성하려면 적은 런타임 요소를 가지는 것이 매우 유리합니다. 그런 측면에서 Svelte, SolidJS를 후보군으로 두었는데요. Svelte의 철학과 여러가지 요소들은 분명 훌륭하지만 이전에 Svelte를 이용해서 숭실대학교 IT대학 사물함 예약 시스템을 개발하였을 때 양방향 바인딩과 같은 기본적 시스템이 개인적으로 너무 혼란스럽다고 생각해서 React의 Hook(SolidJS에선 Signal이라고 불리죠)과 같은 UDF(Unidirectional Data Flow; 단방향 데이터 흐름)가 이상적이라는 생각을 하게 되었습니다(이에 대한 자세한 생각은 이 글의 범위를 벗어나므로 추후 작성해 보겠습니다).
따라서 React와 유사한 API와 Svelte와 유사한 런타임 철학을 가지고 있는 SolidJS를 한번 선택해 보는 것이 유리하겠다는 생각을 하게 되었고, SolidJS를 이용해서 반응성 컴포넌트들을 개발하기로 결정했습니다.
추가로 선택한 스택들
- 당연히 TypeScript를 주 개발 언어로 정했습니다(저는 정적 타입 없으면 개발을 못합니다).
- 빠른 퍼블리싱을 위해 TailwindCSS를 도입했습니다(이것만 있어도 디자인 수정이 엄청 빨라지더라고요).
다음 글: 블로그 컨셉과 디자인
제 블로그는 개발자로써의 제 자신을 표현하는 일이라고도 생각했기 때문에, 제 개발자로써의 이미지를 블로그에 담아보려 노력했습니다. 기본 레이아웃과 프로토타이핑 과정을 다음 글에 공유해 보겠습니다.
