깃헙 페이지 VS 일반 블로깅 플랫폼

한동안 이 블로그를 방치하면서까지 깃헙 페이지를 열심히 관리하고 있었습니다. 하지만 GitHub을 마이크로소프트에서 인수한 뒤로 크고 작은 서버 장애들이 발생하고 있네요. 그러다 보니 깃헙 페이지(GitHub Pages)의 단점들이 조금씩 눈에 들어오기 시작했습니다.

그래서 약간의 화풀이(?) 겸 다시 일반적인 블로그 플랫폼으로 옮겨올까 하는 진지한 고민을 하는 김에 일반 블로깅 플랫폼과 깃헙 페이지의 경험을 비교해보는 글을 한번 써보고자 합니다.

깃헙 페이지의 장점

원하는 마크업 언어 및 에디터 사용 가능

아마도 가장 큰 장점은 이것일 것 같습니다. 원하는 언어로 원하는 에디터로 편하게 글을 작성할 수 있다는 큰 장점이 있습니다.

Emacs 27 + Doom Emacs + Org Mode

개인적으로는 이맥스에서 글쓰기에 좋게 흰색 배경이라는 변태(?) 같은 색상을 쓸 정도로 이맥스로 글 쓰기를 좋아합니다.

마음대로 꾸미기

블로깅 플랫폼의 경우 테마나 스킨의 한계 내에서 레이아웃을 바꿀 수 있습니다. 그런데 그게 좀 까다로운 편이지요. 그리고 스킨을 외부에 공개하지 않은 채 내부에서 테스트할 수 있는 방법도 없습니다.

하지만 깃헙 페이지는 깃헙에 푸시하기 전까진 마음대로 테스트를 해 볼 수 있다는 큰 장점이 있습니다. 물론 글을 출력한 뒤 로컬에서만 확인할 수 있다는 점도 장점이라면 장점이겠지요.

디렉터리 구조도 내 맘대로

사실 블로깅 플랫폼이 제한이 많다고 보는 게 맞을 것 같습니다. 예를 들자면 이미지가 올라가는 경로나 파일 업로드 제한 같은 것 말이죠. 깃헙 페이지는 마음대로 디렉터리를 관리할 수 있습니다.

깃헙 페이지 대비 일반 블로깅 플랫폼의 장점

왜 일반 블로깅 플랫폼의 장점이 아니라 깃헙 페이지 대비 장점이냐면, 아무래도 깃헙 페이지의 단점에 의해 느껴지는 장점이 많기 때문입니다.

웹브라우저 하나로 언제 어디서나

깃헙 페이지는 직접 HTML로 작성하는 게 아닌 이상 글을 올리거나 수정하려면 별도의 마크업 언어로 글을 작성한 뒤 이를 정적 사이트 제너레이터로 출력하고 이를 다시 깃헙에 푸시하는 과정이 필요합니다.

역시 스샷은 사파리가 이뻐요

하지만 일반 블로깅 플랫폼은 글 작성 혹은 수정 버튼만 누르고 바로 작성한 뒤 바로 완료 버튼을 누르면 즉시 업데이트가 끝납니다.

바로 확인 가능

깃헙 페이지는 푸시 후 디플로이(deploy) 과정이 필요합니다. 이 과정은 짧게는 수 초에서 길게는 수 십 초의 시간이 필요합니다. 따라서 글을 올리거나 수정했을 때 그걸 확인하기 위해 약간의 기다리는 시간이 필요합니다. 그런데 짧다고 생각했던 이 시간은 생각보다 길게 느껴지지요.

하지만 일반 블로깅 플랫폼에서는 버튼만 누르면 업데이트가 즉시 끝나며 바로 바뀐 글을 볼 수 있습니다.

편의 기능

예를 들어 이미지나 파일을 업로드 하는 기능이 단순합니다. 버튼만 누르거나 파일을 드래그하면 끝나는 경우가 대부분이지요.

깃헙 페이지의 경우는 어떤 마크업 언어로 어떤 도구로 만드는지에 따라 난이도가 완전히 달라지지만, 적어도 일반 블로깅 플랫폼에 비해서 이런 이미지 업로드 작업 등이 편하지는 않을 거라고 생각합니다.

동적 콘텐츠

깃헙 페이지는 정적 사이트만 운영할 수 있습니다. 즉 사이트의 내용을 수동으로 업데이트하지 않는 이상 내용이 바뀌지 않습니다. 따라서 조회수나 댓글에 기반한 동적인 콘텐츠 변경이 불가능합니다.

하지만 일반 블로깅 플랫폼은 동적(dynamic)으로 동작합니다. 조회수든 통계든 다양한 수치를 이용해 다양한 글을 홍보할 수 있습니다. 물론 해당 플랫폼에서 기능이 제공될 때의 이야기이지만 말이죠.

자체 통계 기능

서비스에 따라 다르겠지지만, 일반 블로깅 플랫폼은 자체 통계 기능을 웹 페이지 형태로 제공합니다. 그리고 이 페이지에 빠르고 가볍게 접근이 가능합니다.

하지만 깃헙 페이지는 별도의 구글 애널리틱스 같은 도구를 통해서 통계를 접해야 하는데, 이 도구가 상당히 무겁고 느리고 불편하고 개인 블로그에 그다지 어울리지는 않는 이상한(?) 기능을 많이 제공합니다. 뭐 주관적인 평가일 수도 있겠지말 말이죠.

깃헙 페이지의 단점

이미 위의 비교에서 단점이 상당수 드러났겠지만, 조금 더 첨부해야 할 내용이 있을 것 같네요.

별도의 정적 사이트 제너레이터 필요

사실 어떤 도구를 쓰느냐에 따라 설치와 설정 난이도가 다릅니다만, 직접 HTML로 작성하는 것이 아닌 이상 정적 사이트 제너레이터는 깃헙 페이지에선 필수이지요.

특히 저처럼 .org 문서를 org-publish를 이용하다 마음에 안 들어서 직접 사이트 제너레이터를 만드는 바람에 이 과정에 엄청난 시간을 소비했다는 점은 결코 배제할 수 없는 큰 단점 같습니다.

개인 컴퓨팅 자원의 소모

정적 사이트 제너레이터를 이용한 출력 과정에서 개인 컴퓨터의 컴퓨팅 자원을 크게 소모할 수 있습니다. 당연히 정적 사이트 제너레이터의 종류나 설정에 따라 다를 수는 있겠지만, 적어도 한 글만 적었다고 그 글만 출력하는 것이 아닙니다. 해당 글이 링크될 인덱스 페이지라던가 다른 연관 페이지도 업데이트가 발생합니다. 그리고 이걸 파악하기 위해 모든 글을 뒤져보는 수고가 필요할 가능성도 높습니다.

한 글에서 글자 하나 수정했는데 익스포트하는 데만 수 분 가량 걸린다고 생각해 보세요. 왠지 컴퓨터가 측은해집니다.

최근 깃헙의 오류

사실 이게 가장 큰 단점일지도 모르겠습니다만, 최근 들어 서버가 자꾸 뻗고 있습니다. 거기다 사이트 디플로이 과정에서 오류도 간간히 나타나고 있습니다.

특히 글을 새로 푸시했는데 이 과정에서 서버 오류가 발생하면 해당 글을 억지로 수정해서 다시 푸시하지 않는 이상 영원히 업데이트된 내용은 볼 수 없게 됩니다. 깃헙 페이지는 수정해서 푸시한 글만 디플로이(deploy) 하는데 오류로 이 과정이 빠져버리면 다시 디플로이를 자동으로 수행하지 않기 때문이지요.

맺음말

사실 이 글은 원래 깃헙 페이지로 개인 블로그나 글을 관리하는 것에 대한 단점을 쓰기 위한 목적의 글이었습니다. 하지만 어쩌다보니 장단점을 비교하는 글로 제목이 만들어졌지요. 그런데 쓰다보니 내용은 깃헙 페이지의 단점 위주로 정리가 되는 엉망진창 대참사 같은 글이 되어버리고 말았네요. 뭐 어쩌겠어요. 현재의 느낌을 그대로 적고 있으니 감정의 기복에 따라 뭔가(?)가 달라질 뿐이죠.

물론 다시 티스토리로 돌아오는 것이 어떤 장단점이 있는가를 진지하게 고민하고 있습니다. 왜냐하면 이맥스로 글을 쓴다는 것이 얼마나 편한 것인가는 다른 단점을 다 덮어버릴 만큼 큰 기능이거든요. 아마도 오랜 시간 고민하게 될 것 같습니다.