1. 왜 기존 티스토리에 싫증이 났나?
티스토리 블로그를 운영한 지 2년차가 될 즈음, 새 단장이 필요함을 느꼈습니다. 기존의 엉성한 UI나 테마를 새로 가꾸고 갖가지 기능들을 추가할 예정이였죠. 그러나 커스터마이징이 너무 어려워서 결국 그간 등록된 블로그 스킨을 사용해야 했습니다.
그럼에도 티스토리 이용이 전반적으로 쉽지 않아 타 블로그 플랫폼을 물색하게 되었습니다. 그 동안 제가 겪은 어려움은 크게 다음과 같습니다.
게시물 작성이 유연하지 않음
글을 작성할 때 Markdown 포맷이 제대로 적용되지 않고, 테이블 정렬이나 모바일 환경에서의 수식 표현이 완전히 지원되지 않는 등의 이슈가 대표적입니다.
보통은 Notion에 포스팅 내용을 먼저 정리하고 블로그에 긁어 붙이는 편인데요. 문자나 머리말, 단락들이 모두 뒤엉켜 게시할 내용을 일일이 다시 검수해야하는 일이 잦았습니다.
불편한 디자인 수정 과정
티스토리의 블로그 레이아웃 정보와 모든 디자인 속성들은 각각 index.html
과 style.css
라는 파일에서 관리되는데요. 이 2개의 파일 안에 모든 내용을 때려 박아야 했기에, 파일 내 코드 줄 수가 1000줄은 족히 넘어갔으며 이로 인해 편집이 늘 불편했습니다.
구글 검색 노출이 원활하지 않음
2차 도메인 주소를 구매하여 블로그에 씌워주더라도 기존 블로그 주소가 검색됩니다. 그러다 보니 구글 검색 엔진이 새 도메인 주소를 검색 결과에 잘 띄워주지 않는 문제가 생기더라구요. 구글 서치 콘솔에 블로그 도메인을 등록하고 이러저러한 조치를 취해도 쉽게 나아지질 않았습니다.
또, 이용자가 신규 도메인 주소와 구 버전 주소로 쪼개져 접속하기 때문에 블로그 유입량 집계가 어렵다는 문제도 공존하고 있습니다.
2. Tistory를 대체하기 위해 찾아본 후보들
Wordpress나 Medium 등 국내 이용자가 적은 플랫폼은 제외했습니다.
- 네이버 블로그: 커스터마이징이 매우 제한적
- 벨로그(Velog): 댓글과 상호작용이 활발, But 획일적인 디자인
- 브런치(Brunch): 유입이 적고 기술 블로그 느낌은 아님
- GitHub Pages: 매우 다양한 테마와 API를 연동 가능하며, Jekyll이나 Gatsby와 같은 차세대 프레임워크를 지원
고려사항 1: 정적 페이지 vs 동적 페이지
위 후보들 중 GitHub Pages만 유일하게 정적 웹 페이지 방식을 채택하고 나머지 3개의 선택지는 모두 동적 웹 페이지 기반으로 동작합니다.
정적 페이지는 사용자가 누구든지 간에 항상 고정된 콘텐츠를 표시하는 반면, 동적 페이지는 사용자의 유형 또는 상호작용에 따라 페이지 내용이 달라지는 특징을 가집니다. (반응형 스킨과는 별개의 이야기입니다!)
네이버 블로그, 티스토리, 벨로그 등으로 구축된 블로그는 기본적으로 서버와 지속적으로 연계하여 방문자 수 조회, 댓글 관리, 게시물 백업 등의 작업을 처리하는 기본적인 틀이 갖춰져 있습니다.
그에 비하면 GitHub Pages는 Admin 페이지가 따로 있지도 않고, 최초 빌드 시에 레이아웃만 덜렁 나타나는 느낌이죠. 게시글을 작성할 때도, Github에 직접 commit을 날려야 하는 불편함도 감수해야합니다.
물론 그렇다고 해서, 타 블로그 플랫폼에서는 되는 기능들을 못 쓰는 건 또 아닙니다. 외부 API와 연동할 수 있는 스크립트를 페이지에 삽입하여 댓글 기능(ex., utterances, giscus)이나 조회 수 표시 기능(ex., goatcounter)을 추가할 수 있습니다. 그 과정이 다소 복잡하지만 말이죠.
그러나, 개인적인 의견으로는 블로그 운영에 있어 정적 페이지냐 동적 페이지냐는 굳이 따질 이유가 없다고 생각합니다. 온라인 커머스 등 로그인이 필요한 서비스가 아닌 이상, 블로그는 그저 작성된 게시글 내용을 원본 그대로 전달하기만 하면 그만이니까요.
무엇보다, 블로그가 상위 플랫폼(네이버, 카카오)의 관리 하에 있으면 활용할 수 있는 API나 플러그인이 제한적입니다. 블로그 스킨 같은 경우도 마찬가지로 다양성이 떨어지는데요. 플랫폼에서 요구하는 지침이 있기 때문에 웹 디자이너들이 개발을 꺼려하기도 합니다.
GitHub Pages는 이들과는 다르게 커스터마이징의 자유도가 높고 같이 연계할 수 있는 Hexo, Jekyll, Gatsby등의 정적 사이트 생성기(Static Site Generator, SSG)로 매우 편리하게 UI/UX 디자인을 할 수 있습니다. 참고로 나열한 프레임워크는 꼭 Git page가 아니더라도 개인 서버 위에 직접 구축도 가능합니다!
고려사항 2: Hexo, Jekyll, Hugo, Gatsby
여태 티스토리나 네이버 블로그처럼 이미 틀이 다 짜여져 있는 플랫폼만 쓰다가, 좀 더 다채롭고 트렌디한 디자인도 입혀보고 싶고 나아가 직접 나만의 테마를 개발하고자 잘 알려진 정적 사이트 생성 프레임워크들을 조사하였습니다.
아래와 같이 대표적인 4개의 선택지를 발견할 수 있었는데요. 각각의 특징들을 정리하면,
Hexo
- Node.js 기반 →
npm
으로 패키지 관리가 용이 - 다양한 테마와 플러그인 기능 제공
- 한글화된 레퍼런스가 적음
Jekyll
- Ruby 기반
- 빌드가 느린 편에 속함
- GitHub Pages에서 공식적으로 밀어주고 있음
Hugo
- Golang 기반
- 훌륭한 사이트 생성 속도
- 사용할 수 있는 테마가 적음 (솔직히 그 정도까지 인지는 모르겠습니다)
Gatsby
- React 기반
- 뛰어난 페이지 성능
- 개발 난이도가 상당한 편
3. 최종 선택: GitHub Pages + Jekyll
GitHub Pages는 Github 사용자라면 가장 빠르고 간단하게 블로그를 배포/운영할 수 있는 선택지입니다. 게다가 저는 업무며 스터디며 늘 Markdown 포맷으로 문서를 작성하고 있고 Notion 등의 앱을 사용하다 보니 Markdown 작성이 용이한지를 최우선으로 삼았습니다.
포스팅을 commit으로 수행해야하는 번거로움이 있지만, 게시글을 하나 올릴 때마다 Github에 잔디밭도 찍히니 나쁘지 않더라구요.
Jekyll을 택한 이유는 가이드라인/문서화가 잘 되어있고 예쁜 블로그 테마도 상당히 많이 보여서입니다.
https://jamstackthemes.dev/ssg/jekyll/
Jekyll을 선택하는데 있어 망설이는 가장 큰 이유가 Ruby/Liquid 언어에 대한 생소함 때문이라고 하는데요. 제 경험상 이 부분은 크게 문제될 부분은 아니라고 생각합니다.
어차피 레이아웃은 html, 스타일 속성은 css/scss, 기능 구현은 javascript 코드로 짜게 됩니다. Ruby가 필요한 첫 번째 이유는 빌드 툴 및 기타 플러그인을 관리하는 패키지 관리자 gem
이 Ruby 기반이기 때문입니다. npm과 비슷하다고 할 수 있는데, 말 그대로 패키지를 내려 받고 jekyll 애플리케이션을 구동시키는 것을 목표로 하기에 컴퓨터에 Ruby만 설치되어 있으면 되죠.
또 다른 이유는 html 파일 내부에서 Ruby 기반의 웹 탬플릿 언어인 Liquid가 간혹 쓰이기 때문입니다. Liquid는 주로 사이트의 메타데이터를 불러올 때 사용되며, 좀 더 고급 기능을 위해 조건문이나 for문을 지원하기도 합니다.
그러나 테마를 수정하거나 직접 개발하는 데 있어서 Liquid가 차지하는 부분은 적은 편이라 Liquid 언어를 ‘공부’까지 할 필요는 못 느꼈습니다. 간단한 함수들은 shopify에 문서화가 잘 되어 있어서 검색하면 금방 찾을 수 있습니다.
Ruby 기반인 Jekyll도 그렇지만, Go언어를 사용하는 Hugo 역시 마찬가지입니다.
생각보다 Jekyll이 매력적인 부분이 많았고 GitHub Pages로 블로그를 배포하고자 한다면 우선적으로 Try해볼 법하다고 보고 있습니다. 관련하여 Jekyll을 이용하고자 하는 분들에게 도움이 될 수 있도록 제가 Jekyll 테마를 개발하면서 정리한 내용들을 공유할 예정입니다.
https://github.com/byanko55/jekyll-theme-satellite