블로그 이전

작년 연말에 워드프레스에서 Jekyll로 이전했었는데, 지난 주말에 다시 hugo로 이전했습니다. 둘다 정적 사이트 생성기로 분류할 수 있는 것들입니다만…

처음 블로그 시작하던 2003년의 MovableType에서부터, 지금까지 이런 저런 블로그 프로그램들을 이용했습니다. 한동안은 대강 만든 루비 스크립트로 돌리기도 했었고요.

작년에 선택했던 Jekyll은 데이터베이스 대신 마크다운 파일들을 쓰는 점이나, 깃헙에서 서비스하기 쉽다는 점이 좋았습니다.

하지만, 어디 한군데 살짝 수정하고나면 브라우저에 반영되기까지 몇십초까지도 걸리는 큰 단점이 있었습니다. 처음엔 견디면서 썼는데, 시간이 갈수록 포스팅을 안하게 될 정도였습니다. (사실 페북이랑 트위터를 열심히 쓰고 있어서이기도 합니다만.)

옮겨갈 후보들로는 파이썬기반의 pelican 이나 go 언어로 만드신 hugo, 리액트로 만든 next.js 등이 있었습니다.

next.js 는 파일 이름의 한글 인코딩1말고는 딱히 어려움이 없었고, hmr livereload도 지원하고, 빌드속도도 밀리초 수준이었습니다. 회사에서도 쓰고 있어서 배워두면 도움도 될 것 같았습니다.

하지만, 포스팅 할 때 마다 webpack 이랑 npm 들을 업데이트해야 할지도 모른다는 점이 불안했습니다. hugo의 경우는 hmr livereload 나 빌드 속도는 비슷했는데, 실행파일 한 개만 있으면 된다는 점이 마음에 들었습니다. 어쩐지 환경에는 신경쓰지 않고 내용을 채우는데에만 집중할 수 있을 것 같았습니다.

그리고, 배포플랫폼으로 netlify 를 써봤는데요. 좋다는 말은 들었지만 이렇게 편할 줄은 몰랐습니다. 도메인 연결하고 나면 자기들이 알아서 무료 SSL 인증서를 받아다가 꽂아주는 부분이 특히 세심해 보였습니다. 마크다운 파일로 포스팅을 작성하고, git push 를 하면 ‘이건 hugo로 만든 블로그로군’ 하면서 자동으로 html file building 을 시작하더군요. 조금 지나면 배포까지도 자동으로 해주고요.

이렇게 이전하고나니, 뭔가 마음이 가벼워진 것 같습니다. 단지 실행파일 1개 라던가 포스팅 == 파일 따위의 변화입니다만 디지털 메타포어를 너무 실감나게 받아들이는 인간인 것 같습니다.

더이상 사용되지 않는 이미지들을 찾아서 지우는 작업 같은 것들이 아주 간단해지긴 했습니다만. ^^


  1. next.js 에서 파일이름을 slug 로 맵핑할 때에 params: { slug:post.slug } 부분을 params: { slug:encodeURIComponent(post.slug) } 해주어야 파일을 문제없이 읽어들입니다. 서양인들은 튜토리얼에서 이걸 빼먹더군요. ㅜㅜ [return]