개요
A fast, simple & powerful blog framework
Hexo는 블로그 관리에 특화된 도구로 명령을 통해 사이트 구조를 관리하고 결과물을 만들어낼 수 있는 기능들을 제공한다. 프로그래밍에 관심이 있고 사이트 구성에 큰 욕심이 없다면 작업을 진행할 수 있지만 어디까지나 보조 도구로써 서버 계획, 구매, 설치, 설정, 테스트, 유지보수 등 서비스를 위한 다양한 문제들을 직접 해결해야하므로 일반인들이 접근하기에는 상당한 학습 장벽이 있다.
따라서, 이 글은 주 독자층이 프로그래밍에 대해 어느정도 경험이 있는 수준이라 가정하고 작성되었다. 설명이 친절하지 않은 점은 감안해주길 바란다. Hexo 블로그를 구성할 계획일 경우 이 문서를 통해 어떤 작업들을 해야하는지 전체적인 설계를 참고하는 용도로 사용하면 좋겠다.
도구의 선정 과정
Hexo를 찾고 선택하기까지 10년정도의 시간이 걸렸다. 수 년전에도 Hexo를 봤지만 당시의 내 목적과는 맞지 않았고 지금보다 지원되는 기능도 훨씬 적었기에 선택하지 않았었다. 앞으로도 새로운 도구와 서비스가 출시되거나 누군가의 추천을 통해서 새로운 도구를 접하게 된다면 사용해보고 나에게 더 잘 맞는 도구라면 전환하게 될 것이다.
각각의 소프트웨어마다 주요 사용자층이 있고 그에따라 기능과 사용법이 결정된다. 어디까지나 나의 기준에서 나의 목적을 이루기 위해 가장 적당한 도구였다는 것이지 Hexo가 블로그 구축 도구중 가장 좋다는 이야기는 아니다.
사이트 & 도구 직접 제작
장점 | 단점 |
---|---|
완전한 사용자정의 | 웹 서비스를 위한 최소 요구치 전체 학습 |
개인의 재능에 의해 결정되는 결과물 (성능, 디자인 등) | |
결과물과 서비스 목적에 비하여 너무 많은 작업량 |
이런 저런 방법들을 동원하여 서비스를 구성하다가 결국 더 다양한 기능을 제공하기 위해 PHP Lalavel, Java Spring 같은 CGI 프로그램으로도 서비스를 해보았다. 그러나 시간이 흐를수록 유지보수에 대한 관리 포인트만 점점 더 많아질 뿐 나아질 낌새는 보이지 않았다. 당장 결과물만 보더라도 어차피 혼자서 작업해야 하기 때문에 디자인부터가 골치 아팠다.
한 줄 요약: 이걸 다 할 줄 아는 사람은 개인 블로그 서비스를 구성하지 않는다.
오픈소스 도입
장점 | 단점 |
---|---|
비교적 적은 작업량 | 사용자정의를 위한 언어와 시스템에 대한 방대한 학습 장벽 |
웹 어플리케이션에 대한 학습량 감소 | 제한적인 사용자정의 |
서비스 목적에 비하여 너무 높은 서버 사양 요구 |
그래서 직접 제작하여 서비스 하는 것을 그만두고 오픈소스를 활용하는 방향으로 전환하였다. 당시 오픈소스로 가장 인기있는 블로그 관리 도구로 워드프레스를 사용한 적이 있다. CMS 수준의 기능과 다양한 템플릿을 사용할 수 있었고 한국에서도 어느정도 인지도가 있어 접근하기 쉬웠다. 그러나 대부분의 사용자가 해외 사용자라 그런지 어떤 테마를 사용하든 언제나 눈에 걸리는 부분들이 존재했고 시간이 흐르면 결국 템플릿이나 기능을 직접 구현하기 위해 프로그램을 뒤적거리게 되는 것이 수순이었다.
PHP로 작성되어 있길래 "그냥 수정해서 쓰자"라는 부담없는 마음으로 뛰어들어보았으나 모든 언어가 그렇듯 조금만 파고 들어가면 학습량이 방대해지기 마련이었고 PHP라고 예외는 없었다.1 이러한 작업들은 언어에 대한 학습과 시스템에 대한 이해를 차치하더라도 나의 사용자 정의 코드를 이곳에 작성하는 것이 맞는지, 시스템에 영향은 없을지, 앞으로 원본 프로그램이 업데이트 된다면 어떻게 이 기능을 유지할지merge 등등 새로운 문제점들이 눈에 보이기 시작했다.
또한 이러한 거대 프로젝트들은 대부분 고수준 언어로 작성되어 다양한 기능들을 제공한다. 조금 다르게 이야기하면 높은 최소사양을 요구한다. 사람마다 원하는 수준은 다르겠다만, 나의 경우 뭐 대단한 서비스를 하려는 것도 아니고 HTML 일기장 치고서 과하다는 느낌을 많이 받았다.2
한 때 인기였던 국산 CMS3인 XpressEngine구 제로보드도 도입한 적이 있었다. 국산인만큼 익숙한 UI/UX들과 한글로 학습이 가능해 접근성이 좋았지만 결국 다른 소프트웨어와 동일한 문제점들을 안고 있었다.
세상 어떤 것이든 가까이 두면 결점이 하나씩 보이지 않던가. 욕심을 버리고 감내하며 만족한다면 이런 고민을 할 필요가 없겠다만 내게 주어진 환경과 목적에 맞는 것은 없었다.
한 줄 요약: 남에거 수정할 바에 만드는게 빠르다.
서비스 사용
장점 | 단점 |
---|---|
매우 적은 작업량 | 매우 제한적인 사용자정의 |
대부분의 학습 비용 감소 | 해외 서버에 대한 물리적 속도 문제 |
문의 가능 | 복잡하고 완벽하게 지원되지 않는 서버 설정 |
국내 서비스로는 네이버 블로그, 이글루스 등이 대표적이고 구글 블로거나 윅스, 미디엄, 텀블러 등 이름만 들어도 기억나는 쟁쟁한 서비스 들이 많이 있었다. 회원가입만하면 고수준의 강력한 CMS 기능을 제공받을 수 있고 바로 컨텐츠 작성에 집중할 수 있다. 서버와 네트워크 관리에 대해서 신경을 쓸 필요도 없다는 것 또한 큰 장점이었다.
그러나 반대로 생각하면 서버나 네트워크에 문제가 생기거나 갑작스러운 서버점검에 대해서 손 쓸 방도 또한 없으며 반드시 제공된 기능만을 써야하는 한계점이 있다. 해외 서비스들은 서버가 해외에 있는 경우가 대다수이고 국내에 있다 하더라도 메인 서버는 해외에 있어 컨텐츠가 동기화되기까지 시간이 걸려 답답하다고 느껴지는 경우도 많았다.
스크립트릿처럼 변수를 사용할 수 있거나 HTML 직접 입력할 수 있는 수준의 가벼운 사용자 정의도 대부분 서비스가 제시하는 제약내에서만 사용해야하며 이를 위한 학습 비용이 소프트웨어를 이해하는 것과 별반 다를 것이 없었다.
한 줄 요약: 포기하면 편해
Hexo
장점 | 단점 |
---|---|
아시아권에 익숙한 UI/UX | 사용자정의가 필수 불가결 |
시스템에 대한 적은 학습 비용 | 사용자정의를 위한 학습 비용 |
대부분 사용자정의 가능 |
Hexo의 경우, 아시아권 사용자들이 많다 보니 익숙한 UI/UX 컴포넌트들을 사용할 수 있었다. 익숙한 컴포넌트와 배치, 테마, 템플릿 등을 사용할 수 있어서 조금만 수정하면 마음에 드는 기능으로 변경하거나 또는 손을 볼 필요없이 설치만하여 구성할 수 있었다.
비슷한 컨셉의 소프트웨어로 Hugo와 Jekyll지킬을 들 수 있겠으나 워드프레스와 마찬가지로 서구권 유저가 많기 때문에 원하는 기능을 찾기가 쉽지 않았다. 또한, 사용자 정의를 전제로 찾다보니 Ruby지킬나 Go휴고를 처음부터 학습하기에 부담이 됐다. 주력언어인 Nodejs로 작성된 Hexo에 자연스럽게 눈이 갔다.
작성한 마크다운을 파싱하여 생성된 HTML만 서비스 하면 된다는 점도 큰장점이다. HTML 파일을 단순히 읽고 전송하는 것이 워드프레스 서버 같은 CGI 프로그램을 구동하는 것보다 성능면에서 압도적으로 효율적이기 때문이다.
사용자 정의를 위해서 시스템에 대해 이해해야 했으나 템플릿 엔진EJS, 테마, 플러그인 작성법 정도만 학습하면 사이트 전체를 사용자 정의 할 수 있었다. 워드프레스와 같은 대형 프로젝트에 비하면 어려운 점은 없었으며 그중에서도 EJS는 JSP와 유사하여 만약 경험이 있다면 필요할 때 전역변수 정도만 찾아볼 뿐 딱히 학습할 필요도 없었다.4
한 줄 요약: 여전히 할게 많지만 할 만해 보인다.
사용법 학습
설치하기
npm i -d hexo
Hexo 메인 홈 페이지에 있는 설치 스크립트를 따라 Hexo 시스템을 설치하는 것도 좋으나, 개인적으로 글로벌 명령이 많아지는 것을 원치 않으므로 저장소로 사용할 디렉토리를 생성하고 npm i -D hexo
명령을 통해 프로젝트 의존성으로 설치 하였다.
포스트 작성하기
npx hexo new post My-First-Post
이렇게 설치하면 CLI에서 hexo
커맨드를 사용할 수 없지만 npx hexo
명령으로 node_modules
에 설치된 실행파일을 실행할 수 있으며 기능은 동일하다.
.
├── _config.yml
├── package.json
├── scaffolds
│ ├── draft.md
│ ├── page.md
│ └── post.md
├── source
│ └── _posts
│ ├── My-First-Post
│ └── My-First-Post.md
└── themes
hexo에서 제공하는 디렉토리 구조를 활용할 수 있다. 포스트는 모두 source 폴더안에 위치하며 마크다운을 통하여 글을 쉽게 작성할 수 있다.
개발 모드 실행
npx hexo clean
npx hexo generate
npx hexo server
작성한 포스트를 확인하기 위하여 hexo 웹 서비스를 실행할 수 있다. 웹 서비스를 하기 전에 서비스할 HTML을 생성하기 위한 generate
명령과 생성하기 전 구버전 파일들을 제거하기 위한 clean
명령을 지원한다. server
명령을 통해 설정한 포트가 준비되면 접속하여 페이지를 바로 확인할 수 있다. 생성된 페이지들은 설정한 디렉토리를 기준으로 각 포스트와 페이지들이 index.html로 생성된다. 이렇게 생성된 디렉토리를 nginx나 apache-httpd 같은 웹 서버를 통해 docroot만 정해준다면 바로 서비스할 수 있다.
블로그 서비스를 위한 업무 구성
- 글 관리:
npx hexo [new|publish] [--draft]
- 배포:
npx hexo clean && npx hexo generate
웹 서비스 구성
도메인
IP 주소만으로 웹 서비스를 제공하기에는 사용자들의 접근성이 매우 낮아진다. 이미 가지고 있는 도메인에 서브도메인 www
를 할당하고 nginx의 가상 호스트 기능을 활용하여 블로그 서비스를 제공하기로 하였다.
서버
실제로 동작시킬 서버로 vultr 호스팅 서비스를 사용하고 있다. 삼성 SDS 상암 데이터센터를 통해 제공되는 서비스로 4년 전 구매 당시 장난감 서버로 월 $8.5 구독 결제였는데 중간에 서버 사양을 올려 월 $11.00의 비용이 소모되고 있다.
1vCPUIntel Xeon 2.9GHz Cache 16MB, 2GB 램, 55GB SSD, 3테라 트래픽이 제공되어 업무 보조와 더불어 정적 HTML 웹 서비스용으로 함께 사용해도 무난할 것이라 판단했다. 월 $6 짜리도 있으니 요즘 물가로 밥 반끼도 안되는 돈이기 때문에 가벼운 마음으로 사용해보기를 적극 추천한다.
웹 서버
정적 파일 서비스라 전송만하면 돼서 더 쉽고 간단한 서버들도 있었지만 선택한 테마가 SPA 방식으로 구성되어 특정 라우팅 문제를 해결하기 위해서는 URL Rewrite와 같은 기능이 필요했다. 그리고 Nginx의 경우 이미 잘 사용하고 있기 때문에 학습할 필요도 없으므로 선택하였다.
목표 구성도
사용자 ─ 브라우저 ─┐ ┌───────────── Static File
Vultr ── Nginx │
편집자 ─ 브라우저 ─┘ └─── Code Server ──── Generate
이전에 포스팅했던 Code Server를 활용하여 편집자는 언제 어디에서든지 IDE 환경으로 포스트를 작성/관리하고 업데이트 된 페이지들은 모두 정적 파일로 생성되어 사용자가 갱신된 최신 페이지를 원활하게 서비스받을 수 있도록 구성하였다.
후기
가장 많이 한 작업 - 사용자정의
가장 마음에 드는 템플릿을 설치하여 웹 어플리케이션을 구성하였음에도 눈에 밟히는 부분들이 생긴다. 현재 테마는 Vue, Vite를 사용하여 학습이 필요했지만 익숙한 Nodejs 환경에서 작업할 수 있어 비교적 수월하였다. 그래도 한 달 이상의 시간이 들어갔으며 쫓아갈 수 없는 부분은 포기하거나 우회하며 작업해야했다.
당장 생각나는 것들만 나열해도 마크다운 확장
, 테마 의존성
, 해시태그 동작 방식
, 뷰포트에 따른 팝업
, 댓글
, 폰트
, 환경설정
, SEO
, Front-Matter 확장
등등 상당히 많은 작업을 진행했다. Hexo를 통해 관리 포인트와 학습비용을 많이 덜어내더라도 마음에 드는 수준까지 변경하기는데에 상당한 시간과 노력이 들어갔다.
"완벽해" 보다는 "이정도면 됐다"라고 타협하는 과정에 가까웠다. 사람이라는게 자고 일어나면 어제 했던게 이상해보이지 않던가? 앞으로 개선과 유지보수가 필요한 부분들이 분명히 생길것이다. 시간이 지나면 다른 것에 또 흥미가 갈지 모르겠지만 나름 재미있게 작업했다.
가장 기억에 남는 작업 - Google Search Console 최적화
검색엔진들은 보통 사이트에서 읽을 수 있는 페이지들을 열람하고 해당 문서의 키워드나 본문을 해석하여 후에 사용자가 검색을 할 때에 활용하고 검색결과에 해당 페이지를 표시한다. 이때 활용하는 태그가 <meta>
태그이다. keywords
, description
, author
등 검색엔진에서 문서를 해석할 때 이런 메타 태그를 읽어들이는데 이를 악용한 스팸성 메타태그들 때문에 일부 무시하는것들도 있다.5
동적으로 생성되는 게시글도 각각 URL을 가지고 있는 페이지들이다. 각 페이지들의 주제에 맞는 메타 태그를 제공한다면 조금 더 많이 검색엔진에 노출될 수 있고 사용자들은 더 쉽게 원하는 정보를 얻을 수 있게 된다. 이를 위한 최적화 작업을 검색엔진 최적화 또는 SEOSearch Engine Optimization라고 일컫는다.
선택한 테마는 전용 플러그인과 함께 동작하여 매핑된 사이트 데이터를 활용한 SEO가 구현되어 있었다. 그러나 게시글별로 SEO가 설정되어있지 않아 검색에서 약점을 많이 보여 게시글 별로 추가적인 데이터 매핑을 진행하고 동적으로 메타 태그를 생성하는 추가적인 작업이 필요했다.
Google에서 검색한 결과가 어떤 기준으로 키워드를 필터링하는지도 테스트도 해보았다. 제목과 본문내에서 키워드를 인덱싱하고 문서를 찾아내는 것이 기준으로 보인다. description 메타 태그를 제공하면 제목과 설명이 검색결과에 나오긴 하나 본문을 검색해서 추천해주는 것인지는 확실하지가 않다. 좀 더 시간을 들인다면 SEO의 수준을 높일 수 있겠지만 적용 후에 확인하기까지의 시간이 길기 때문에 이건 나중에 하기로 하였다.
투자 비용
여기에 대해서는 정말 해주고 싶은 말들이 많다. 이리저리 쓰고 지우고 편집해 봤지만 도무지 줄일 수가 없어 그냥 생략하기로 했다. 좋은 제안이나 방안보다는 가면 갈 수록 잡소리가 되었다. 어차피 쓸 사람은 도시락 싸들고 말려도 쓰고 안 쓸 사람은 귀에 딱지가 생겨도 쓰지 않는다. 나중에 기회가 된다면 글을 하나 별도로 써보는 걸로 하자.
블로그 운영 방향
과거에도 몇 번 운영해보았으나 역시 블로그 운영의 가장 핵심은 지속적인 신규 컨텐츠이다. 꾸준히 작성할 수 있어야하고 작성한 글이 반드시 누군가에게 도움이 되는 정보여야한다.
배운게 도둑질이라고 프로그래밍과 관련된 글을 작성하는 것이 가장 쉽기도 하고 잘 할 수 있는 소재이다만 단순히 설정이나 코드를 나열하고 발번역하는 수준의 글들은 이미 인터넷상에 넘쳐 흐른다. 당장 GPT를 통해 얻는 답변만해도 더 좋은 결과를 얻을 수 있을 거라 생각한다. 그렇기에 내가 다시 읽어도 쉽게 이해하고 설명할 수 있는 수준으로만 작성할 계획이다.
Footnotes
-
PHP도 엄연히 객체지향 언어이다. 워드프레스 같은 대형 프로젝트들은 집에서
mysql_connect()
나 깔짝거리던 나의 .php 와는 결이 달라도 한참 달랐다. 당장 라라벨같은 대형 프레임워크들만 보아도 같은 php를 공부한건지 의아할 정도이다. ↩ -
요즘 컴퓨팅 성능을 고려한다면 무리가 없을 수도 있겠다. 나의 경우 라즈베리파이로 서비스할 때
onload
이벤트가 발생하기 까지 상당한 시간이 걸렸다. ↩ -
최근에는 고수준의 CMS 기능들이 많이 제공되지만 당시에는 위젯 기반의 배치 시스템에 가까웠다. 편의상 CMS라 칭하였다. ↩
-
단순하게만 생각해봐도 워드프레스같은 대형 프로젝트들은 인증, 권한, 메뉴, 페이지 등등 학습해야할 데이터 모델은 물론 로직, 데이터베이스, 세션 관리기법도 있고 조금 더 나아가면 PHP, PHP 라이브러리, 기타 등등 학습량이 비교가 안된다. ↩