All Articles

블로그 이사

이번 가을에 개인적으로 사용하던 AWS 계정을 정리하게 되었다. 그 동안 여기저기서 크레딧을 지원받아 잘 사용하고 있었지만 아무래도 개인적으로 돈을 내고 쓰자니 조금 부담이 되었다. 굳이 개인 블로그를 위해 서버를 운영하는 것 또한 피곤하기도 했다. 고민을 하다보니 Github Pages 를 활용하는 것으로 생각이 좁혀졌고, 다시 정적 페이지 생성기들을 한번 두루 써봤다.

서비스형 블로그 사용도 잠시 고민했지만, 여러 Pain Point 들을 극복해서 참고 쓸 자신이 생기지 않았다. Medium 이 그나마 가장 나았는데, 여긴 한글폰트가 구리고 이걸 내가 어떻게 바꿔서 쓸 수가 없다. 그렇다고 드래그와 오른쪽 클릭을 막아버린 브런치라던가, 네이버 블로그를 쓸 수는 없지 않은가. 티스토리는 에디터가 불편했다. 무엇보다도, 서비스형 블로그들은 대체로 코드 스니펫을 사용하기 매우 불편하다. Gist 나 Github 에 코드를 올리고 Javascript 로 로드해서 보여주는 방식이 있기는 하지만 블로그 글을 쓰는 데 코드를 다른 데 올리는 것도 귀찮고 Javascript 로 끌어다 뿌려주는 방식도 내 취향이 아니다.

정적 페이지 생성기 중에서 가장 편하고 익숙한 건 Python 기반의 Pelican 이지만, 이번에는 다른 걸 사용해 보기로 했다. 사실 직접 만들까도 생각해봤지만 나중에 너무 귀찮아질 것 같아서 남들이 관리해주는 프로젝트를 믿기로 했다.


정적 페이지 생성기 선택

사실 Github Pages 를 활용할 생각이라면 Ruby 기반의 Jekyll 을 사용하는 것이 여러모로 좋다. Github 은 기본적으로 Jekyll 을 기본 제공해주고 있기 때문에 테마, 환경설정 파일, 마크다운 문서만 올려도 렌더링 된 페이지가 올라가기 때문이다. 하지만 나는 Ruby 언어를 선호하지 않는데다 잘 쓰지도 못해서 Jekyll 은 피하고 싶었다.

Gatsbyjs

Gatsbyjs 라는 React 기반의 정적 페이지 생성을 해주는 도구를 알게 되었다. React 공식 문서 또한 이것으로 작성되었다고 하여 관심을 가지고 한번 사용을 해봤다. 리스트 페이지와 상세 페이지 사이의 전환은 매우 빨랐지만, 첫 리스트 페이지 로드 시에 해당 목록의 모든 글 정보를 .js 로 미리 로드하는 것이 (어쩔 수 없었겠지만) 조금은 불만이었다. 무엇보다도, 페이지 생성 시간이 너무 오래 걸렸다. 그리고 내 블로그 특성상 페이지의 전환은 많지 않을거란 생각이 들자 사용을 포기하게 되었다. 나중에 전처리기를 붙이게 될 것 같은데, 아직 React 를 잘 몰라서 추가 기능을 붙이기 힘들어보이기도 했다. 개념 자체는 참신한데다 마음에 들어서 여러모로 좀 더 나아진다면 다시 사용해 볼 의사가 있다. 궁금하신 분들은 Lumen 테마 데모 를 한번 보거나 Rinae 님의 글 을 참고하시면 좋을 것 같다.

Hexo

HexoNodejs 기반의 정적 페이지 생성기다. Nodejs 기반이다보니 예쁜 테마가 많다.1 하지만 Hexo 는 중국인들이 많이 사용해서 그런지 중국어로 된 이슈가 꽤 보인다. 그리고 개인적인 취향 문제로 Nodejs 로 정적 페이지를 생성할 바엔 차라리 Python 을 쓸 것 같다.

Hugo

HugoGo 기반의 정적 페이지 생성기다. 결론적으로 이 페이지는 이것을 이용하여 생성되었다. 다른 정적 페이지 생성기들보다 압도적으로 빠른 것이 장점이다. 그리고 Go 언어의 빌트인 패키지인 html/template 을 사용하는 것 또한 장점이라고 생각한다. 단점이라면 html/template 패키지가 jinja2 와 비교하자면 좀 불편하다는 점이 있겠지만 이 부분은 내가 아직 html/tempalte 패키지가 jinja2 만큼 익숙치 않아서 그럴수도 있다. 그리고 요즘 Go 언어를 주 언어로 사용하기 위해 노력하고 있어서 나에게 맞다고 판단했다.


마이그레이션 계획

기존의 블로그에서 건질 만한 글들이 몇 개 없었다. 사실상 수작업으로 옮겨도 무의미할 정도. 천천히 일부만 옮길 예정이다. 그렇다고 이미지 경로와 slug, date 등을 일일이 다 입력해 줄 수는 없는 노릇이니 스크립트 하나 짜서 옮길까 고민중이다. 전형적인 직업병스러운 고민인 것 같다. 아마 수작업으로 옮기는 게 빠를 것 같은데, 이걸 굳이 코딩해서 옮길 생각을 하고 있다. (…)

1년 넘게 방치 중인 Today I Learned 페이지의 글도 대충 옮기고 정리하고 해야 할 것 같다. 이건 Pelican 으로 만들었고, Travis CI 도 붙여서 마크다운 문서가 마스터 브랜치에 푸시될 때 자동으로 빌드하여 gh-pages 브랜치에 배포하도록 만들어놨으나 어느샌가 TIL 문서 작성은 머릿속에서 잊혀지고 방치되기에 이르렀다. 나 같이 게으른 사람은 용도에 따라 블로그를 여러개 나누어서 운영을 하면 안 된다는 교훈을 얻었다. 한 곳을 정해서 잘 관리해야 할 것 같다.

테마 개발

백엔드에서 주로 쓰이는 언어로 개발된 테마들은 뭔가 대체로 비주얼이 그닥 좋지가 않다. Pelican 도 그랬고 Hugo 역시 내 마음에 드는 미려한 테마가 딱히 보이지 않았다. 그래서 직접 만들어서 쓰려고 테마의 글 상세 페이지 초안을 잡아봤으나 뭔가 부족하고 아쉬운 느낌이 들어서 일단 중단했다. 그러던 중 MKdocs 의 테마를 Hugo 용으로 포팅한 Material Docs 테마를 발견하였는데, 이건 개발문서를 위한 테마라 블로그용으로는 조금 부족했다. 페이지네이션도 없었지만 일단은 이걸 마개조해서 쓰기로 했다. 디자인을 입힐 뼈대용 테마 를 미리 만들어놨으니 디자인이 어느정도 완성되면 뼈대 테마에 디자인 입혀서 쓰면 될 것 같다. 그 전까지 일단은 마개조 테마를 쓸 예정이다.

앞으로는

당장은 시간이 여유로우니 블로그 글을 천천히 다시 써 볼 생각이다. 마이그레이션이니, 도구 변경이니, 다 부질없다. 블로그의 본질은 글인데 자꾸 쓸데없는 짓만 한 것 같아 반성이 좀 된다. 그래도 한번씩 다 써보고 장단점을 알게 되었으니 마냥 손해는 아닌 것 같다.


  1. Nodejs 잘 하는 분들은 프론트엔드 개발도 잘 하시는 분이 많다. 아무래도 Javascript 기반이다 보니 프론트엔드 개발하시는 분들이라 대체로 센스가 남다르신듯.