WordPress로 운영하던 블로그를 Jekyll 기반의 정적 웹사이트로 변경한 이유와 과정

2010년부터(사실 더 그전부터) blog.munilive.com 도메인으로 블로그를 시작하였다.
별다른 내용은 없었고, 그냥 내가 개발하면서 간간이 기록으로 남기고 싶은 글들, 또는 기록하고 싶은 내용들 퍼 온 내용도 있었고, 다른 분의 글에 내 생각 또는 내 코드를 합쳐서 다시 올리곤 하였다.
그리고 온전히 내가 만든 코드들을 보관하기 위해 글을 남기기도 하였다.
하지만, 일하기 바빠서 였는지, 아니면 블로그에 글을 올리는 건 그래도 조금이라도 정성을 들여야 한다는 생각 때문이었는지 글을 쓰는 빈도는 점점 줄어들었다.
2015년까진 그래도 간간이 몇 달에 한 번씩이라도 글을 남겼었는데 그 이후 3년간 글을 쓰지 않았다. 그리고 다시 생각이 나서 또 글을 잠깐 쓰고는 다시 2년이 흘렀다.

사실 쓸 주제가 없었을지도 모른다. 그래서 글을 남기지 않았는지도 모르겠다. 블로그에 글을 남기지 않는 대신에 에버노트에 기록이 넘쳐나기 시작했고, 의미 없는 기록, 알 수 없는 기록들이 마구마구 생겨났다.
워드프레스도 계속해서 버전업을 해갔다. 중간에 한번 에디터가 업데이트되더니 이전에 썼던 글들과는 먼가 미묘하게 글이 맞지 않았다. 점점 흥미를 잃어가기도 하고 정리해야 할 글들도 많아지기 시작했다. 너무 귀찮았다.
정리가 필요한데, 블로그에 정리 한번 해야지 하고 시간을 보낸 지가 벌써 2년이 넘은 거 같다.

이전을 결심한 이유

2년 동안 방치하던 블로그를 갑자기 이전하기로 결심한 이유는 단순했다. 돈(Money) 이었다. 매년 블로그를 운영하기 위해 들어가는 서버 비용이 생각보다 적은 비용은 아니었다.
10년이 넘은 서버여서 성능도 오래되어 반응도 느려졌지만, 내는 비용만큼 활용하지 못하고 있다는 생각이 들었다. 단순히 블로그의 정적인 페이지를 보여주기 위해서 ‘내가 왜 10만원이 넘는 돈을 내고 있어야 하지?’라는 생각이 드는 순간 서버를 내리고 정적 사이트로 변경해야겠다고 생각했다. 그리고 10년이 넘은 서버를 더 이상 쓰고 싶지 않았다. 요즘 대세라고 할 수 있는 클라우드를 써보고 싶었다. AWS S3에 정적 페이지를 올리고 CloudFront를 이용해서 웹사이트를 제공하면 비용도 절약하고 좋을 것 같았다.
비용적으로 따지고 보면 AWS가 더 비쌀 수 있겠지만, 당장 블로그만 운영하기에는 현재 서버를 유지하는 게 더 비쌌다. 블로그 운영하는 거 말곤 쓰고 있는 게 없으니깐.

정적 웹페이지 제작 도구를 찾아라

일단. 기존의 워드프레스에 작성한 글을 모두 옮겨줄 만한 정정 페이지 생성 도구를 찾아야 했다.
10년 전 블로그 운영을 시작할 때 내 스스로 다짐한 게 하나 있다. 내가 운영하는 사이트는 절대 링크가 깨지거나 사라지지 않게 하겠다고, 좋은 블로그도 몇 년만 지나면 문닫고 접속 안되는 경우가 태반이었기 때문에(그래서 그런 글들을 긁어모아 내 블로그에 올려두고 보관하고 싶은 마음도 있었다.) 내 블로그만은 정정 웹사이트로 이동하더라도 기존의 링크들은 대부분 살려두고 싶었다. 적어도, 포스트의 글들은 그대로 접근되었으면 했다.
생각보다 많은 정정 웹사이트를 만들어주는 도구들이 많았다. 오히려 너무 많아 이렇게 많았나 싶었다. 무엇을 선택해야 하지 선택 장애가 오기 시작했다.

정적 웹사이트 도구 모음 사이트 - https://www.staticgen.com/

가장 유명하고 사람들이 가장 많이 쓰는 툴을 사용하기로 했다. 3가지로 범위를 좁혔는데, Jekyll, Hexo, Gatsby 였다.

Jekyll은 워낙 유명하고 또 사람들이 많이 쓰고 있었다, 여러 IT 회사에서도 기술 블로그로 많이 사용하고 있고, Github를 이용해서 무료로 웹사이트를 호스팅 할 수도 있었다. 하지만, Ruby가 맘에 걸렸다.
아무리 만들어진 걸 쓸 거지만 그래도 내가 무언가 수정하고 싶은데 그때 막히면 답답할 것 같았다. 그래서 그다음으로 본 게 Hexo였다.
Node.js로 만들어져 있고, 여기도 생태계가 풍부하고 지원하는 플러그인들도 많았다.
Jekyll 못지않다 생각했다. 그리고 요즘 한창 쓰고 있는 Node.js로 만들어진 게 마음에 들었다. Gatsby의 경우는 Hexo를 알아보다 알게 된 거였는데 React 기반의 정적 웹페이지를 만들어내는 도구였다. 어찌 보면 Hexo나 Jekyll보다 훨씬 강력한 도구였다. 하지만, 내가 쓰기에는 부담스러웠다. 일단, React 자체를 잘 몰랐다.

Jekyll, Hexo 모두 설치해보고 써보기로 했다. 제일 중요한 건 블로그의 글을 Markdown으로 변환하여 글을 옮기는 것이었다. 둘 다 워드프레스의 글을 가져오는 플러그인을 지원해 주었다.
하지만, 오래전에 쓴 글이어서 그런 걸까? 아니면 다국어 지원이 잘 안되어서 그런 걸까, 생각보다 제대로 변환되지 않았다. 일일이 글 하나하나를 다 변환해야 했고, 내가 작성한 글은 100여 개인데 변환되어 나온 파일은 천 개가 넘었다. 카테고리별, 태그별, 본문에 걸려있던 모든 링크들이 페이지가 되어 돌아왔다. 방법도 여러가지를 사용해보았지만 결과는 전부 만족스럽지 못하였다. 그나마 Hexo가 변환을 잘 해주었지만, 순수한 Markdown이 아니였다.

Jekyll로 이전하는 과정

결국, Jekyll을 선택했다. Front Matter로 몇 가지 설정만 추가하고 나머지는 순수한 Markdown만으로 작성할 수 있었기 때문이었다. 그리고 다양한 플러그인을 지원하고 있어서 기존 Wordpress로 이용하던 기능들에 대해서 이전하는데 문제가 없을 것이라 판단했다. (지금 생각해보면 너무 빠른 판단이지 않았나 싶다. Hexo로도 순수 Markdown으로 작성할 수 있지 않았을까?)
Jekyll을 이용하여 정적 웹사이트로 이전하기로 결정하고 하나씩 세팅에 들어갔다. 다행히 한글로 잘 설명된 사이트가 있어서 처음 설치 및 설정에서 별로 어려움은 없었다.

한국어를 지원하는 Jekyll 사이트 - https://jekyllrb-ko.github.io/
물론 영문사이트보다 업데이트가 느리지만 기초적인 것을 익히는 데는 충분하였다.

기본적인 설치를 하고 import 모듈을 통해 Wordpress로부터 가져온 데이터는 너무 불만족스러웠다. 카테고리, 태그 등을 알아서 가져와 매핑해주는 것과 첨부된 파일까지 가져와 주는 것은 좋았지만, 내용의 줄바꿈이나 포맷이 뒤죽박죽이었다.
그래서 2011년도의 글부터 다시 작성하기 시작했다. 모든 걸 다시 타이핑하기에는 시간이 너무 오래 걸려 복사 붙여넣기 후 포맷을 다잡아 가는 방식으로 하나씩 옮겼다. 이미지도 다운로드해 저장하고 새로운 경로로 지정해 주었다.
글을 하나하나 옮기는데 시간이 너무 오래 걸렸다. 빨리 블로그를 꾸며보고 이것저것 플러그인도 사용해보고 싶었다. 대략 20~30개의 글을 옮기고 나서 적절한 테마를 찾아보기 시작했다.

HTML/CSS가 능숙하고 디자인 능력이 있었다면, 사실 테마를 찾지 않았을 것이다. 직접 만들어 썼을 테니깐, 하지만, 나에게 그럴만한 능력은 없었다. 테마를 찾는 것도 일이었다. 생각보다 내 마음에 드는 걸 찾기란 어려웠다.
결국 찾은 테마가 현재 적용된 테마(Memoirs Jekyll Theme)이다. 사실 이것도 이것저것 수정을 조금 했다. 티는 안 나지만 그래도 기존 테마 디자인에서 마음에 들지 않거나 필요 없는 부분을 걷어내고 정리하는데 상당한 시간이 걸렸다.

Jeylll로 이전하면서 도움 받은 플러그인들

테마에서 사용된 기본적인 플러그인을 같이 설치하고 몇가지 기능이 더 필요했다.
기본적으로 설치한 플러그인은

정도였던 거 같다. 사실 무엇이 기본적으로 설치되어 있었고 추가했는지 확실히 기억나지는 않는데 이 정도가 기본으로 설정되어 있었던 것 같다.

코드의 highlight 방식이 맘에 들지 않았는데, Jekyll 4버전부터는 rouge 플러그인이 기본으로 탑재되면서 이전에 사용하던 {\% highlight ruby %\} some code {\% endhighlight %\}이런 방식의 입력은 사용하지 않는 것 같다.

테마 자체가 약간 갤러리 형식의 테마여서 그런지 모든 포스트에 이미지에 대한 설정을 해주어야 했다. 그게 너무 귀찮아서 jekyll-auto-image 플러그인을 설치했다. (하지만 AMP 설정 때문에 결국 대표 이미지의 경로와 가로, 세로사이지를 Front Matter에 추가해 줘야 했다.)
그리고 이미지에 대한 caption을 추가 해주고 싶어서 jekyll-figure를 설치 했다. 다른 플러그인도 있었지만 Jekyll-figure방식이 가장 마음에 들었다.

Wordpress에서 Jekyll로 이전하면서 가장 크게 달라진 점은 바로 포스트(글)에 대한 접속 경로였다. Wordpress의 경우에는 blog.munilive.com/포스트 주소형식이었는데, Jekyll로 변경하고 나서는 blog.munilive.com/posts/포스트 주소형식을 써야 했다. 물론, 이전 형식으로도 변경할 수 있었다. 하지만, 모든 글이 도메인 root 아래로 몰리는 것이 마음에 들지 않았다. 기존 Wordpress를 통해 구글 등 여러 검색엔진에 퍼진 주소들을 통해 접근했을 때 새로운 주소로 매핑이 되도록 jekyll-redirect-from 플러그인을 추가 사용했다.

Markdown으로 글을 작성하며, 링크를 추가할 때마다 {:target="_blank"}를 링크 뒤에 매번 다는 게 너무 거추장스럽고 기본적인 Markdown에 방해가 된다고 생각이 들어 jekyll-target-blank도 설치하였다.

아직 다 옮기지 못한 기능

Wordpress가 정말 많은 플러그인을 지원하고 있고, 전 세계 많은 사람들이 사용하다 보니 SEO관련 기능이라든지, AMP, PWA등, 정말 다양한 기능들을 지원한다. 그걸 정적 웹페이지로 모두 해결하기에는 한계가 있는 거 같다.
당장 AMP만 하더라도 Jekyll에 있는 amp-jekyll를 설치해서 사용하였지만, 단순히 <img> 태그를 <amp-img>로 변경해 주는 것 외 다른 기능은 없었다. 심지어. 내가 글을 작성하면서 이미지도 함께 보고 싶어서 이미지의 경로를 상대 경로로 지정해둘 경우 이미지 경로를 제대로 찾지 못해 이미지 사이지를 측정하지 못하는 버그가 있었다.
플러그인의 사이트를 방문하여도 개발은 더 이상 하지 않는 것 같고, 최초 개발자도 새로운 컨트리뷰터를 찾고 있는 듯했다.
결국 기존 코드를 fork 해서 원인을 찾아 수정할 수밖에 없었다. 그리고 기존 플러그인 대신 새로 fork 해서 수정한 github 주소로 대체하였다. (https://github.com/Munilive/amp-jekyll)

마무리

Workpress에서 Jekyll로 블로그를 옮기는 데만 한 달이 넘는 시간이 걸렸다.
매일 퇴근해서 새벽 2~3시까지 글을 일일이 옮기는데도 시간이 걸렸지만, 플러그인을 설치하고 이를 내 입맛대로 이리저리 수정하는데도 시간이 상당히 걸렸다.
Ruby 언어는 한 번도 써보지 못한 채 플러그인의 내용을 파악하고 수정하는 게 쉽지만은 않았지만 그래도 개발자 아닌가, 간단하게 수정해서 쓰는 건 문제가 없는듯했다. 구글이라는 막강한 지원군도 있고.

처음 계획했던 S3와 CloudFront 조합의 사용도 중간에 Netlify라는 사이트를 알게 되면서 비용이 들지 않고 운영하는 방식으로 변경했다. Netlify에서 제공하는 무료 플랜이면 개인 블로그를 운영하는 정도에는 충분하다 생각된다.

한 달이 넘는 시간 동안 Wordpress에서 Jekyll기반으로 블로그를 이동하고, 아직 모든 게 마무리된 게 아니지만, 그동안의 있었던 일을 기록할 겸 남겨 본다.
이 기록도 누군가에게는 도움이 되었으면 좋겠고, 나중에 다시 보았을 때 나의 추억이 되었으면 좋겠다.