Jekyll을 사용한지 어느덧 2년이 흘렀다. 기존의 사이트를 보수하면서 많은 문제점과 개선점을 발견했다. CSS코드의 난잡함, Jekyll 컴파일링의 불편함 그리고 사용자와 소통할 수 있는 코멘트를 개발하는 것이 그것이었다. 따라서 해당 문제점을 해결하기 위해 다음 두 가지를 염두해두고 코딩했다. 모든 코드를 component화하여 재사용이 가능하게, 모든 코드는 일정한 규칙을 지정하여 코딩할 것.

SCSS

가장 먼저 눈에 들어온 것은 CSS였다. 이전부터 SCSS로 개발해 생산성을 늘리고 싶었다. 하지만 class명의 난잡함과 비효율적인 코드 누적은 이를 힘들게 하였다. 따라서 이전부터 눈여겨 보고 있던 프로젝트, rscss를 적용하여 모든 CSS코드의 class명을 수정하였다. 꽤 긴 시간이었다. 하지만 의미는 있었다. 코드의 난잡함을 해결하는 동시에 비효울적인 코드들을 많은 양 제거할 수 있었다.

Liquid + RubyGems

그 다음은 Liquid였다. 사실 사이트 레이아웃을 개발하는 용도로만 Liquid를 일부 적용하는 수준이었다. 하지만 Responsive image 등 반복 작업이 필요한 작업이 이어지면서 이를 효율적으로 관리할 방법이 필요했다. 따라서 Bundler를 사용하여 Liquid를 활용하기로 마음 먹었다. Jekyll을 빌드하며 자동으로 gem들을 적용시켜주는 도구다.

처음으로 사용하려한 gem은 jekyll-assets이었다. 기존처럼 레이아웃 등에서만 Liquid를 사용하는 것이 아니라 CSS, JS, IMG와 같은 assets 폴더의 자료들을 Liquid로 활용할 수 있는 gem이다. 이를 통해 얻을 수 있는 이점은 gulp의 사용횟수가 확연히 줄었다는 점이다. 기존엔 Critical CSS를 적용하기 위해 gulp로 작업하던 과정이 줄었다. Jekyll 환경이 production 모드이면 자동으로 코드를 압축하는 것도 큰 이득이었다.

두번째는 Jekyll-srcset-tag였다. 앞서 말한 Responsive image를 지원하기 위해서였다. 계획은 Jekyll-picture을 활용해 개발할 생각이었다. .config.yml를 활용하여 짧게 쓸 수 있는 코드가 마음에 들었었다. 하지만 gem과의 버전 충돌로 인해 사용이 어려웠고 결국 이를 활용해 개발한 jekyll-srcset-tag로 대체하였다.

세번째는 Jekyll-sitemap이다. SEO를 위해 sitemap을 만들 필요성은 느껴왔다. 하지만 포스팅을 할 때마다 번거로운 작업이 거슬렸다. 이 gem 덕분에 별다른 작업을 하지 않아도 바로 적용이 가능해 편리했다.

Markdown

일반적인 지킬 블로그의 경우 대부분 마크다운으로 글을 쓴다. 하지만 Responsive image와 footnotes의 지원때문에 쉽사리 쓰기 힘들었다. 마크다운의 가장 큰 장점은 편리함인데 그것이 부재된 마크다운은 의미가 없어보였기 때문이다.

그러다 새로운 방식을 생각했다. Jekyll의 include 기능을 이용하면 코드를 중첩해서 작성하지 않고, Liquid 태그를 이용해 불러올 수 있지 않을까. 다행히 멀지 않은 곳에서 답을 찾을 수 있었고¹ 이를 활용해 Responsive Image를 쉽게 사용할 수 있었다.

또한 Kramdown을 활용해 기존의 Footnotes 문제도 해결할 수 있었다. 모든 문법을 간단한 [^1] 와 같은 방식으로 옮겼다. 이에 맞춰 CSS 코드도 재설계했다. 기타 HTML 코드를 꼭 사용했어야 했던 부분도 이와 같은 문법으로 달성할 수 있었다.

Gitlab Page

기존까지 내 사이트를 호스팅하던 사이트는 Github Page였기 때문에 고민이 컸다. Github Page는 Bundle을 지원하지 않아 이 모든 것을 적용할 수 없었다. Github Page의 편리함도 버리고 싶지 않았다. 따라서 대안을 찾았다. Gitlab Page였다. Github Page와 비슷하면서도 Continuous Build를 지원하는 Gitlab은 이상적인 모델이었다.²

Gitlab Page는 Github와는 달리 자동으로 build를 지원하지 않았다. 따라서 .gitlab-ci.yml이라는 CI Configuration 파일을 이용해 bundle로 jekyll을 build하도록 만들었다. 또한 필요한 gems들의 반복 설치를 피하기 위해 vender 폴더를 두어 cache 하였다.

Algolia

사실 기존에도 검색 기능은 추가되어 있었다. Liquid 태그를 활용한 Simple Jekyll Search을 사용해 구현한 것이다. 하지만 한글 문서 특성상 완전한 검색을 지원하지 않았고, 간헐적으로 나타나는 버그는 신경을 거슬리게 했다. 따라서 한글을 지원하는 검색 엔진을 찾았다.

Algolia는 공식적으로 한글이 지원되었다. 내가 찾던 full-text 검색도 가장 확실했다. 검색한 글자를 Hightlighting 해주는 기능은 덤. 자바스크립트 Client를 추가하고, Helper를 적용해 부가적인 기능을 적용했다.

Staticman

왠만큼 문제를 해결하다보니 이젠 개선하고 싶은 점이 눈에 띄었다. 코멘트였다. 이전 티스토리 블로그를 썼을 때는 굳이 Disqus나 외부 플러그인을 적용하지 않아도 이미 구현되어 있어 좋았다. 하지만 Jekyll로 사이트를 옮기고 나선 이를 어떻게 구현해야 할 지가 문제였다.

Jekyll은 말그대로 static, 정적 사이트이다. PHP와 같이 server-side코드는 적용이 불가능했을 뿐더러 Gitlab page에서 작동하지 않았다. 코멘트를 POST로 넘겨주면 이를 처리할 중간자 역할이 필요했다.³ 최근의 Jekyll 사례를 검색하다 Staticman이라는 수확을 얻었다. 내가 딱 원하던 방식이었다. 누군가가 코멘트를 쓰면 이를 staticman에서 넘겨주고 data화하여 내 repository에 push한다. 이렇게 하면 static 사이트라 하더라도 코멘트를 활용할 수 있었다.

다만 아쉽게도 데모 사이트에선 1단 코멘트만 지원하는 듯했다. 서로 질문하고 답변할 수 있었던 티스토리 방식을 적용하기 위해선 구현 방법이 필요했다. 다행히 나보다 앞서 이런 생각을 한 사람이 있었다. mademistakes의 해결책은 정말 큰 도움이었다. 많은 코드를 여기서 도움 받았다.⁴

하지만 큰 산이 하나 있었다. 현 시점에서 staticman은 Github만 지원하고 있다. Gitlab 지원에 대한 이슈가 게시되어 있었지만 시일이 걸리는 모양이었다. 지금 즉시 어떻게 적용할 수 있을까 고민하다 한 포스트를 발견했다. 한 중국 개발자가 게시한 글이었다. Github의 Webhook과 Gitlab trigger을 사용해 사이트를 rebuild하는 방법은 참신했다.⁵

따라서 이를 적용하기 위해 Github submodule을 두어 Gitlab page와 연동이 가능하도록 만들었다. 이후 .gitlab-ci.yml 파일을 수정하여 자동으로 submodule을 remote origin과 연동하도록 코드를 짰다. 다소 삽질은 있었지만 정상적으로 잘 작동했다.

결론

사실 어마어마하게 큰 작업을 한 것은 아니다. 대폭 레이아웃을 변경한 것도 아니다. 오히려 쉬우면 쉬운 작업들이었다. 하지만 미루고 미러왔던 작업을 완료하니 기분만은 좋다. 이제 AMP를 비롯해 나머지 개선점도 고민해본다.