Github 블로그를 포기하고 티스토리로 옮긴 이유 (장, 단점)

때는 2020년 11월, 개발 블로그를 만들어 보고자 하여 Github pages(github.io)를 통해 블로그를 만들었다.

티스토리, velog 등 다른 블로그도 있었지만 고려 대상에 들어가지도 않았다. 나름 웹 개발자인데 내 블로그는 내가 직접 만들어서 써야겠다는 생각과, 정형화되지 않은 나만의 유니크한 블로그를 만들고 싶다는 생각에 고민 없이 Github pages를 선택하였다.

2020년 대찬 포부를 가지고 시작한 개발 블로그

결론부터 말하자면, Github pages를 통해 블로그를 작성하는 것을 포기하고 티스토리로 옮겼다. 사실 완전히 포기한 것은 아니고 role을 변경해서 계속 사용 중이긴 하다. (링크)

지금은 TIL 전용 블로그가 되었다.

Github Pages의 장단점과 티스토리로 옮기게 된 이유

개인의 성향에 따라 블로그에 대한 선호도가 많이 달라질 수 있다. 나의 글 작성 성향은 아래와 같다.

• 마크다운을 싫어하진 않음 (불호보단 호에 가까움). 문법도 어느 정도 익힌 상태라 블로그 글 쓰는 데는 크게 문제는 없는 수준.
• Notion을 좋아함. 사실상 블로그의 역할은 Notion이 다 하고 있었음
  • 그래서 Notion에서 블로그로 글을 옮길 일이 많음
• 글 작성 시 이미지 첨부를 많이 함
• BackEnd 개발자 특유의 저주받은 디자인 감성

2020년 11월부터 2023년 4월까지 거진 2년 반 동안 github.io를 사용해 오면서 개인적으로 느낀 장단점을 써 보고자 한다. 위 성향을 가지고 있음을 바탕으로 장단점을 참고하는 게 좋을 것 같다.

장점

• 굉장히 높은 자유도

나는 jekyll을 사용해 블로그를 만들었다. jekyll은 굉장히 많은 테마를 지원하고 있고(jekyll 테마 모음 사이트), 테마를 받아서 css를 직접 수정하는 등 세부적인 디자인 또한 내 입맛에 따라 변경할 수 있다.

댓글도 기본적으로는 비활성화 되어 있지만 disqus나 utterances 등 본인 취향에 따라 댓글 플러그인도 바꿔 사용할 수 있다.

이외에도 커스터마이징 할 수 있는 요소가 굉장히 많아 정형화된 블로그가 아닌 나만의 블로그를 만들어 나갈 수 있다.

• github 잔디 깔기 좋음

포스팅을 하려면 github repo에 commit과 push를 해야 하니, 자연스럽게 잔디가 깔리게 된다. 최소한의 노력으로 github commit 내역을 잔디밭으로 만들 수 있다.

많지는 않지만, 그래도 노력대비 잔디 깔기는 좋다.

• 멋있고 있어보인다.

자세한 이유는 모르겠지만 도메인에 github.io가 박혀 있으면 왠지 모를 멋있음이 느껴진다. 남들과는 다른 나만의 블로그를 만들어나가는 홍대병의 일종일까. 다른 블로그에 비해 멋있어 보이는 것도 Github pages를 사용한 이유 중 하나이다.

• 웹 개발자로서 나만의 웹 페이지를 직접 만든다는 것에 대한 뿌듯함

다른 개발자도 아니고 나름 웹 개발자인데, 여러 기능들을 하나씩 뚝딱뚝딱 만들어서 올려가는 과정이 굉장히 뿌듯하다. (그렇다고 하기엔 추가한 기능이 별로 없긴 하다..) Github Action 창에서 deploy가 잘 된 것을 보고 나면 마음이 편안해진다.

위와 같은 이유들로 불편하더라도 2년이 넘는 기간 동안 Github pages를 포기하지 않고 있었지만, 결국 단점을 이기지 못하고 블로그를 바꿔 버렸다.

단점

• 자유에는 책임이 따른다. 높은 자유도만큼 직접 설정해야 하는 것이 굉장히 많다.

많은 테마를 제공하고 있긴 하지만, 블로그의 완성도를 높이려면 세부적인 디자인 수정 또한 필요하다. 세부 디자인 수정은 Github pages 뿐만 아니라 티스토리에도 해당되는 사항이겠지만, Github Pages에서는 더 신경 써야 할 것이 많았다. footer를 바꾸기 위해서는 어딜 찾아야 하고, 폰트를 바꾸기 위해서는 어디를 찾아야 하고 등등.. 또한 댓글 기능이나 SEO도 지원하지 않아서 직접 설정해야 한다.

블로그에 기능을 넣고 꾸미기 위해서는 어찌되었든 FrontEnd 개발이 필요한데, 개발은 할 수 있다 쳐도 BackEnd 개발자 특유의 괴랄한 디자인 감성 탓에, 테마를 설정할수록 이상해진다는 느낌도 든다.

백엔드 개발자에게 프론트를 맡기면 생기는 일. 굉장히 좋아하는 프로그래머 유-모아 입니다.

• 높아진 허들

jekyll을 통한 Github pages 작성 방법이 많이 올라와 있음에도, jekyll에 대한 최소한의 이해는 필요하다.(Hugo와 같은 다른 프레임워크도 동일할 것이다) 물론 공부를 하면 되긴 하지만, 편안하게 글을 써야 하는 공간에 접근하기 위해 허들이 생겨버리게 된다. 오늘 공부한 내용을 간단히 적고 싶은데, 그 간단한 글을 적기 위해서 더 불편한 과정을 거치게 되는 것이다.

테마나 블로그의 기능을 변경하려고 할 때도 branch를 나누어 작업하긴 한다만, 그래도 이와 같은 블로그 자체의 수정이 일어날 때 동시에 블로그 글을 쓰기가 어려워진다. 글을 쓰려면 post 전용 branch로 가서 작성하고, post를 main에 merge 하고, layout을 수정하기 위해서 branch를 옮기고.. layout 수정 중에 글을 쓰려면 stash에 올려놓고 다시 글 쓰고.. branch 헷갈려서 글이라도 잘못 쓰면 귀찮아지고.. 이런 귀찮음에서 오는 허들이 있어서 블로그에 기능을 추가하거나 글을 쓰는데 주저하게 되는 것 같았다.

 

• 글 작성 및 수정의 어려움, 떨어지는 생산성

내가 느낀 최대의 단점이자 티스토리로 옮기게 된 결정적 이유. 글을 작성하고 수정하는 과정이 굉장히 불편하며, 글을 쓰는 것이 불편하다고 느껴서 블로그에 글을 쓰지 않게 된다.

내가 Github pages에 글을 작성하는 방법은 크게 두 가지로 나뉘었다.

 

1. 직접 Markdown을 작성

주로 Visual Studio Code를 사용해 Markdown을 직접 작성하였다. jekyll을 통한 포스팅에서는 글 제목, 날짜, 카테고리 지정을 위한 markdown 내에 일정한 템플릿이 들어가는데, 이를 편집하는 데는 VSCode가 제일 편했기 때문이다.

또한 VSCode의 extension으로 markdown의 preview를 실시간으로 볼 수 있게 해 주는 extention이 있어(링크), 결과를 보면서 작성하기도 편했다.

 

2. Notion을 통해 작성한 글을 옮기기

Notion에서는 현재 페이지를 markdown으로 내보내는 기능이 있다. 이 기능도 있지만 한 페이지를 통째로 내보내는 경우가 아닌 일부를 내보내고자 하는 경우도 많았으며, 이 때는 Notion의 내용을 복사하여 VSCode에 붙여 넣고 작업을 했다.

Notion의 페이지를 markdown으로 내보내도 글 제목과 작성일자, 카테고리 설정을 위해서는 결국 VSCode를 열어서 직접 markdown을 편집해야 한다. 이러나저러나 글을 쓰는데 markdown은 필수인 상황.

 

이러나 저러나 markdown으로 포스팅을 하려면 템플릿을 사용해야 하고, 템플릿을 재사용하려면 기존 파일을 복사/붙여넣기 하여 내용을 수정하며 작성해야 한다. (물론 더 좋은 방법이 있을 수 있다. 하지만 제목과 템플릿 규격을 맞추려면 기존 파일을 복사하는 게 제일 편하다고 생각했다)

 

개인적으로는 글에 이미지를 많이 첨부하는 편인데, 어느 방법을 선택하든 이미지를 첨부하는 방법이 굉장히 귀찮았다.

다른 편집기에서는 편집기 상에 이미지를 붙여넣기만 하면 첨부되는데, markdown을 사용할 경우 이미지 경로에 파일을 올려놓고 태그를 통해 이미지를 삽입해야 한다. 이미지 경로 맞추고, 이름 맞추고, 태그 맞추고.. 이미지가 한두개도 아니고 여러개면 일일히 맞춰야 한다.

특히 Notion을 통해 작성한 글을 옮길 때 불편했다. Notion 글 안에 이미지가 첨부되어 있는데 그대로 붙여넣으면 이미지가 깨져서, Notion에 올라간 이미지를 다운받고, 이미지 경로에 옮기고... 글 작성하는게 10분이라면 이미지 옮기는데 20분이 걸렸다. 여기서 허무함을 느끼고 블로그를 옮겨야겠다고 결심했다.

github 상에서 직접 내용을 수정할 수 있긴 하다. 여기서 이미지를 붙여 넣으면 이미지 경로를 별도로 지정하지 않고도 이미지를 올릴 수 있지만, github 상에서 작성하면 템플릿을 재활용하기 힘들어진다는 단점이 있다. 제목, 파일 이름, 작성일자 등등 정보를 다른 곳에다 저장해놓고 매번 불러 와서 새로 작성해야 한다.

그리고 몇몇 문자들의 경우 markdown 문법에 해당이 되어 쓸 수 없는 문제가 발생한다. 예를 들어 |(파이프) 의 경우, markdown에서 인용을 나타내는 문법에 해당하여, 해당 문자가 들어간 글은 인용 처리가 되어 버린다. 그래서 매번 글을 쓸 때 | 를 찾아서 | 란 문자로 치환해줘야 하는 작업도 필요하다.

해결책 : 블로그의 분리

Github pages가 글을 작성하는데 허들을 높이고 있다 생각하여 바꾸긴 해야겠지만, 그래도 포기하고 싶지 않은 마음이 있어서 블로그를 용도에 따라 분리하기로 했다.

• 개발하면서 겪은 시행착오, 트러블슈팅, 기타등등 블로그로 기록할 만한 것들 : 티스토리, 현재 블로그 (https://tentasys.tistory.com/)
• 오늘 공부한 내용을 적을 개발 일기장, Today I Learned : Github Pages(https://tentasys.github.io/TIL/)
• 개인 포트폴리오 페이지 : Github Pages. 어떤 프레임워크로 정적 페이지로 올릴지 고민 중 (https://tentasys.github.io/)

맺음말

지금 티스토리를 사용하고 있긴 하지만, 아직 사용한 지 얼마 되지 않아 티스토리의 장단점을 잘 못 느꼈을 수 있다. 앞서 말한 단점이 그대로 티스토리에도 해당되는 단점일 수 있으며, Github pages도 내가 잘 활용하지 못해 장점을 잘 못 찾은 것일 수도 있다.

하지만 가장 중요한 것은, 내가 얼마나 편하게 글을 쓸 수 있는지라고 생각한다. 글을 쓰는데 저항감이 생겨서 쓰고 있지 않던 Github pages 시절 TIL만 올렸던 것에 비하면, 지금은 벌써 글을 3개나 썼지 않은가. 확실히 글 쓰는 데에는 개인적으로 티스토리가 편안하다고 느꼈기에 쓸 수 있었던 것이고, 충분히 성공적인 migration이라 생각한다.

근데 티스토리 행간이 너무 크다. 줄간격 줄이는 법 찾아봐야겠다.

-> 찾았다! https://tentasys.tistory.com/5