Jekyll 에서 Ghost 로 블로그 이전 - 1. 스토리 편

블로그 시작은

처음 블로그를 시작할 때는 설치형 블로그에서 시작했었다. 그 당시 대학교 안에 있는 개인 PC에 리눅스를 설치하고 Wordpress 와 같은 설치형 블로그를 직접 디플로이하여 사용했었다. 처음 블로그를 시작할 때는 블로깅 자체에 비중 보다 개인서버에 블로그 자체를 설치하는 것이 더 의미있다고 생각했었다. 하지만 대학교내 PC서버는 안전하지 않았다. 전원 공급도 안정적이지 않아 다운타임이 발생하고 무엇보다 학교 보안이 강화 되면서 외부 접근이 제한적인 문제가 있어 이 마저도 별로 오래가지 못했다.

설치형 블로그의 한계와 불편함 때문에 포털 서비스의 블로그나 가입형 블로그 서비스를 찾게 되었고, Web2.0 시대에 인기있었던 Blogger를 사용했다. 그 당시 폐쇄적인 블로그 환경과는 달리 Blogger는 사용자가 직접 HTML, CSS 코드를 사용하여 원하는 디자인을 만들어낼 수 있었다. 하지만 익숙하지 않는 인터페이스(뭔가 우리 정서(?)와는 맞지 않았다). Blogger의 자유도에 매력을 느껴 Naver나 Daum과 같이 정해진 레이아웃과 뭔가 포털에서 반드시 끼워 넣은 서비스들이 불편하고 부담스러워 개발자 중심의 블로그라는 Tistory를 사용하기 시작했다.

Tistory는 HTML나 CSS를 자유롭게 다룰 수 있을 뿐만 아니라 모든 사이트에서 막아둔 JavaScript 까지도 허용해주었다. 이는 완벽한 나의 개인 서비스를 만들어낼 수 있는 환경을 제공해주었다. 한번은 모든 HTML을 지워버리고 내가 원하는 웹 사이트를 만들어 버린적도 있었다. 그 때는 한글 URL로 slug로 만드는 것이 싫어서 글번호로 URL을 사용했는데 지금 생각해보면 참 생각이 없었다.이런 URL은 나중에 다른 서비스로 이전할 때 큰 문제가 생기기 때문이다... 이문제는 나중에 Jekyll에서 Ghost로 블로그 이전하는 기술적인 이야기를 적을 때 자세히 소개할 예정이다. 개인적으로 절대 Naver 블로그를 사용하지 않는 이유도 이런 이유 때문이다.

Jekyll과의 만남

그렇게 Tistory를 사용하다가 개발자 사이에서 Markdown이 폭발적인 인기로 사용되기 시작했다. Github가 등장하자 Markdown은 개발자 사이에서 마치 문서를 만드는 표준처럼 받아들이기 시작했다. 그 당시 Tistory를 사용하여 블로깅을하고 있었고 이 서비스는 WYSIWYG 에디터를 사용하고 있었기 때문에 Markdown으로 블로깅을 할 수 없었다. 하지만 WYSIWYG 에디터는 HTML 타입으로 저장할 수 있었고, Markdown으로 만든 Static 파일을 HTML로 변환하고 Tistory API를 사용하여 블로그에 포스팅하여 사용했다. 그 때 만든 라이브러리가 바로 mark2htmlnode-tistory 였다. 프로그램적으로 단순화 작업을 만들긴 했지만 이런 편법은 곧 답답해지기 시작했다. 난 단순히 글을 Markdown으로 작성하고 싶었고 바로 블로깅을 하고 싶어졌다. 그 때 단비를 만났는데 그것이 바로 지금까지 사용해온 가장 자유도 높은 Markdown 블로그 플랫폼인 Jekyll 이였다.

Ruby 프로그램언어를 아주 애용하고 있었고 Octopress를 설치해서 사용해본적이 있어서 Jekyll이 내가 원하는 가장 이상적인 블로깅 환경이라고 생각했다. 더구나 Jekyll은 Database를 사용하지않고 markdown 자체를 사용하기 때문에 어느 시스템이든 데이터를 가공할 수 있다는 장점도 마음에 들었다.(이런 특성 때문에 Jekyll에서 Ghost로 블로그 이전을 할 수 있었다) 뿐만 아니라 Github Pages에서 공식적으로 Jekyll을 지원하고 있기 때문에 블로깅을 위해 호스팅하기 위한 서버도 필요하지 않는다. 개발자는 그냥 Jekyll의 _posts/ 디렉토리 안에서 markdown 파일을 만들고 git push만 하면 블로깅이 되었다.

Jekyll과 GitHub의 장점

Jekyll의 장점은 완벽한 Markdown 중심이라고 말할 수 있다. Markdown 파일만 있으면 바로 블로깅이 가능하다. 그래서 데이터베이스를 사용하지 않는다. Markdown을 HTML로 변환하여 서비스할 때는 HTML 파일을 사용한다. 그래서 Markdown을 사용하는 어떠한 어플리케이션과 호환이 가능하다. 또한 사용자가 직접 HTML,CSS,JavaScript를 이용해서 레이아웃을 만든다. 포털서비스처럼 자사 서비스를 반드시 끼워 넣어야하는 제약사항도 없다. 100% 사용자가 직접 만든다. 난 Jeyll을 사용해서 _drfats/에 있는 파일들과 합해서 약 300여개의 markdown 파일을 만들었다. 2년동안 사용하였으니 대략 2~3일에 블로깅을 했다고보면 된다. 그만큰 개발문서 생산성이 뛰어나다. 아마 지금 이전한 Ghost를 사용할 수 없을 때는 난 주저없이 다시 Github Pages과 Jekyll을 사용 할 것이다.

Jekyll의 단점

Jekyll을 사용하면서 단 한번도 단점이라고 생각한 적이 없었고 장점이라고 생각했던 그 자유도 라는 것에 단점을 느끼기 시작했다. 2016년 12월 31일 난 한해를 회고하면서 의미있는 글을 포스팅하려고 했다. 새해가 바뀌면 theme도 바꾸어서 새 마음으로 다시 시작하겠다는 의지를 가지고 theme를 제작하려고 했다. Kakao 기술 블로그에 pull request 를 요청하면서 소스코드를 분석한적이 있어 난 Github Pages로 운영하고 있는 Kakao 소스코드를 fork해서 몇 가지 수정해서 내 모든 글을 이전했다. 하지만 난 결국 deploy 하지 않았다. 이유는 난 Kakao가 아니기 때문이다. Kakao 기술 블로그는 오픈소스로 운영하고 있지만 소스 내부에 Kakao font가 있다. 공식적으로 Kakao font는 오픈 소스가 아니다. Naver 폰트처럼 공개되지 않아 어떤 라이센스를 가지고 있는지 알 수 없었을 뿐만 아니라 Kakao 스타일로 만든 잘 짜여진 코드에 숟가락은 얹는 기분이 들었다. 물론 여러가지 수정을 했고 좀 더 유연하게 사용할 수 있도록 _config.yml을 이용해서 유연하게 만들었지만 결국은 사용하지 않기로 결정했다. 2017년 새해가 되었지만 난 여전히 새로운 theme를 만들려고 했다. Google Material Design을 사용해서 만들어보기도 하고 HTML5, CSS3 기반 프레임워크를 사용해서 만들어보기도 했다... 며칠 반복하다보니 이런 생각이 들었다. Jekyll을 사용하게 된 가장큰 이유가 글에 집중하기 위해서였는데 Jekyll의 자유스러움 때문에 오히려 글보다 다른 것에 시간을 소비하고 있는 모습을 발견하게 되었다.

좀 더 단순해지고 싶다.

Jekyll의 가장 큰 단점은 Mobile first 시대에 맞지 않게 Jekyll은 모든 작업을 Client 로컬에서 작업해야 한다는 것이다. 내가 쓴 글을 버스를 타고 다니거나 틈틈히 아이폰을 사용해서 확인하는데 오탈자가 발견되거나 글을 수정하고 싶어도 즉시 수정할 수 없다. 수정해야 할 것을 생각하고 있다가 맥북 앞에 앉아야만 처리할 수 있었다. 즉시 수정할 수 없기 때문에 막상 앉아서 수정할때 기억을 하지 못하는 경우가 대부분이다.

모바일에서 markdown을 사용하여 글을 관리하고 싶다.

Brunch

개인적으로 느끼는 Jekyll의 단점 때문에 블로그를 관리해주는 서비스를 사용하고 싶어졌다. Medium, Tumblr 그리고 Brunch을 생각하고 있었는데 Medium의 가장 큰 단점은 데스트탑 환경에서 한글 폰트에 문제가 있었다. 모바일 환경에서는 흠 잡을 때 없을 만큼 만족도가 높지만, 데스트탑 환경에서는 극도로 가독성도 낮고 이뻐보이지 않는다. Tumblr는 Instagram 공식 블로그가 운영하는 만큼 훌륭하게 좋은 서비스지만 데스트탑 환경에서 편집기에 한글이 제대로 입력되지 않는 문제가 있다. 한글 폰트 문제로 Medium의 블로깅에 아쉬움이 커져 있을 때 Brunch라는 서비스를 알게 되었다. brunch는 불과 얼마전만해도 사용하는 사용자가 적었는데 지금은 꽤 많은 사용자가 이 서비스를 사용하고 있다. brunch는 현재 beta 서비스라 글을 작성하고 발행하기 위해서 작가 신청을 하는데, 여기서 난 좌절을 했다. 작가 신청은 간단히 내가 활동하는 블로그 URL와 작가신청의 이유를 간단히 적어서 제출하면 되는데, 신청 결과는 메일로 통보가 온다.

결과의 메일을 살펴보면 안타깝게도 이번 기회에는 브런치 작가로 모시지... 이런 내용으로 메일이 오는데, 난 뭔가 추첨에서 뽑히지 않은 줄 알고, 다시 작가신청을 했다. 그런데 똑 같은 메일이 왔다. 뭔가 작가신청 평가는 어떻게 하는건지? 왜 이번 기회에 될 수 없었는지를 알려줬더라면 다시 신청할 때 보완하고 신청할 수 있었을텐데... 아쉽지만 뭔가 추첨의 뽑기 처럼 자세한 피드백 없이 이번 기회만을 이라는 답장을 주는 서비스에 작가 언제 어떻게 될지 모를 재신청을 계속할 수는 없었다.

Ghost

하이브리드 어플리케이션을 개발할 때 부터 Node.js를 알게되어 작년에는 웹 서비스를 Node.js 기반으로 개발하는 프로젝트를 진행했다. 이젠 Java, Ruby 와 더불어 가장많이 사용하는 언어는 JavaScript가 되었다. 내가 front-end 개발자도 아닌데 말이다. Ghost는 Node.js 기반 Markdown 블로그 서비스 플랫폼이다. SQLite, MySQL 또는 PostgreSQL 등 데이터베이스를 사용하는 설치형 블로그이다. 설치형 블로그의 단점은 이 글 서두에 언급했듯 서버가 반드시 필요하고 서버는 물리적인 제약사항이 많다. 개발자 대부분은 ghost 블로그를 사용해보고 싶지만 개인서버를 운영해야한다는 부담감 때문에 쉽게 사용할 수 없는 것이 현실적인 문제이다. 작년부터 AWS 기반으로 프로젝트를 진행하면서 AWS에 익숙해졌고, 연구목적으로 AWS의 일부를 사용할 수 있어 Ghost를 AWS에 설치해서 사용할 수 있게 되었다.

다음 글

Jekyll에서 Ghost로 블로그이전에 관한 글은 2편에 의해서 작성하기로 했다. 왜 블로그를 이전했는지에 대한 소개도 꽤 의미있다고 생각했기 때문에 첫 도입부가 많이 길어졌다. 또한 Jekyll to Ghost 의 기술적인 내용이 흥미롭고 소개할 내용이 많아서 글을 나누고 싶었다. 다음 글 Jekyll에서 Ghost 블로그 이전 - 2.기술 편에서 기술적 내용을 소개한다.