Hexo 블로그 구축 및 서비스 구성

컴퓨터/IT작업기록

lu

luasenvy (luasenvy)

개요

Hexo는 블로그 관리에 특화된 도구로 명령을 통해 사이트 구조를 관리하고 결과물을 만들어낼 수 있는 기능들을 제공한다. 프로그래밍에 관심이 있고 사이트 구성에 큰 욕심이 없다면 작업을 진행할 수 있지만 어디까지나 보조 도구로써 서버 구매, 구성, 테스트, 유지보수 등 서비스를 위한 다양한 문제들을 직접 해결해야하므로 일반인들이 접근하기에는 상당한 학습 장벽이 있다.

따라서, 이 글은 프로그래밍에 대해 어느정도 경험이 있는 수준이라 가정하고 작성되었다. 설명이 친절하지 않은 점은 감안해주길 바라며 Hexo 블로그를 구성할 계획이 있는 경우 이 문서를 통해 어떤 작업들을 해야하는지 전체적인 설계를 참고하는 용도로 사용하면 좋겠다.

도구의 선정 과정

Hexo를 찾고 선택하기까지 10년정도의 시간이 걸렸다. 수 년전에도 Hexo를 봤었지만 당시의 내 목적과는 맞지 않았고 지금보다 지원되는 기능도 훨씬 적었기에 선택하지 않았었다. 각각의 소프트웨어나 서비스들은 저마다의 목적과 목적을 달성하기 위한 기능들이 존재한다. 어디까지나 나의 기준에서 나의 목적을 이루기 위해 가장 적당한 도구였다는 것이지 Hexo가 블로그 구축 도구 중 가장 좋다는 이야기도 아니며 새로운 도구나 서비스가 출시될 때 지금보다 더 합리적이라면 전환하게 될 것이다. Hexo를 사용하기까지의 여러가지 방법들을 소개한다.

사이트 직접 제작

한 줄 요약: 이걸 다 할 줄 아는 사람은 다른 일을 하느라 바쁘다.

다양한 방법을 동원하여 서비스를 구성하다가도 결국 내가 원하는 맞춤형 기능을 제공하기 위해 PHP Lalavel, Java Spring 같은 CGI 프로그램을 직접 작성하여 서비스를 하게 되었다. 그러나 이 방식은 시간이 흐를수록 유지보수에 대한 관리 포인트가 점점 더 커지고 안정화 이전까지 발생하는 예기치 못한 오류들이 너무나 많았다.

서버 아키텍처, 소프트웨어 구성, 네트워크 구성, 도메인 구성, 서비스 기획, 웹 프로그램 작성, 데이터 모델링, 등등 서버부터 브라우저까지 모든 구간에 있는 구성을 확인하고 관리해야만 하기 때문에 쉽지 않은 길이다. 이 모두를 차치하고 당장 화면에 렌더링된 결과물만 하더라도 퀄리티가 아주 저열했는데 디자이너라는 직업이 왜 별도로 존재하는지 가슴 깊이 느낄 수 있었다.

오픈소스 사용

한 줄 요약: 남에거 수정할 바에 만드는게 빠르다.

직접 제작을 통하여 느꼈던 점들을 고려하며 두번째 서비스는 오픈소스를 활용하기로 하였다. 당시 업계 최강자였던 워드프레스를 활용하여 쉽게 빠르게 홈페이지를 구성/관리할 수 있기를 기대하였다. CMS 수준의 강력한 기능과 다양한 템플릿을 사용할 수 있고 한국에서도 어느정도 인지도가 있기 때문에 접근하기 쉬웠다.

그러나 대부분의 사용자가 해외 사용자이기 때문에 모든 기능이 해외기준으로 맞춰져 있고 테마를 사용하더라도 이 기준에 맞춰진 템플릿 들이 대부분이라 국내에서 사용하기에는 부족한 부분들이 항상 존재했다. 시간이 흘러 결국 템플릿이나 기능을 직접 구현하기 위해 프로그램을 뒤적거리게 되는 것이 수순이었지만 이미 국내에서는 많이 가라앉은 php가 주 언어였기 때문에 문제 해결도 쉽지 않았다.

php가 예전 자바스크립트처럼 아주 쉽고 간편한 보조용 도구라는 생각하는 경우가 많은데 워드프레스처럼 대형 프로젝트에 사용된 php프로그램은 매우 복잡하게 구성되어있어서 가벼운 마음으로 작성할 수 없다. 모든 언어가 그렇듯 조금만 파고 들어가면 학습량이 방대해지고 PHP라고 예외는 없었다.¹

이러한 작업들은 언어에 대한 학습과 시스템에 대한 이해를 고려하지 않더라도 나의 사용자 정의 코드를 이곳에 작성하는 것이 맞는지, 시스템에 영향은 없을지, 앞으로 원본 프로그램이 업데이트 된다면 어떻게 이 기능을 유지할지_(merge) 등등 새로운 도전과제들을 만나게 되어있다.

또한 이러한 거대 프로젝트들은 고수준 언어로 작성되어 다양한 기능들을 제공하는데 이는 최소 사양을 요구치가 높다는 이야기로도 바꿔 말할 수 있다. 사람마다 원하는 수준은 다르겠다만 대단한 서비스를 하려는 것도 아니고 HTML 일기장 치고서 과하다는 느낌을 많이 받았다.²

한 때 인기였던 국산 CMS³인 XpressEngine_{(구 제로보드)}도 도입한 적이 있었다. 국산인만큼 익숙한 UI/UX들과 한글로 학습이 가능해 접근성이 좋았지만 결국 다른 소프트웨어와 동일한 문제점들을 안고 있었다.

서비스 사용

한 줄 요약: 포기하면 편해

국내 서비스로는 네이버 블로그, 이글루스 등이 대표적이고 구글 블로거나 윅스, 미디엄, 텀블러 등 이름만 들어도 기억나는 쟁쟁한 서비스 들이 많이 있었다. 회원가입만하면 고수준의 강력한 CMS 기능을 제공받을 수 있고 바로 컨텐츠 작성에 집중할 수 있다. 서버와 네트워크 관리에 대해서 신경을 쓸 필요도 없다는 것 또한 큰 장점이었다.

그러나 반대로 생각하면 서버나 네트워크에 문제가 생기거나 갑작스러운 서버점검에 대해서 손 쓸 방도 또한 없으며 반드시 제공된 기능만을 써야하는 한계점이 있다. 해외 서비스들은 서버가 해외에 있는 경우가 대다수이고 국내에 있다 하더라도 메인 서버는 해외에 있어 컨텐츠가 동기화되기까지 시간이 걸려 답답하다고 느껴지는 경우도 많았다.

스크립트릿처럼 변수를 사용할 수 있거나 HTML 직접 입력할 수 있는 수준의 가벼운 사용자 정의도 대부분 서비스가 제시하는 제약내에서만 사용해야하며 이를 위한 학습 비용이 소프트웨어를 이해하는 것과 별반 다를 것이 없었다.

Hexo

한 줄 요약: 남에 거 수정하기는 여전히 힘들지만 할만해 보인다.

결국 돌고 돌아 오픈소스를 사용하는 것으로 다시 돌아왔다. 다만 이 때에는 호스팅이나 홈페이지 구성보다는 더 쉬운 관리방안과 불편을 감수하더라도 최소한의 기능 높은 성능을 위주로 찾게 되었다. Hexo는 이러한 요구사항을 어느정도 밸런스있게 구성한 솔루션이었다. 아시아권 사용자들이 많다 보니 익숙한 UI/UX 컴포넌트들을 사용할 수 있던 점도 좋게 보였다. 익숙한 컴포넌트와 배치, 테마, 템플릿 등을 사용할 수 있어서 조금만 수정하면 마음에 드는 기능으로 변경하거나 또는 손을 볼 필요없이 설치만하여 구성할 수 있었다.

비슷한 컨셉의 소프트웨어로 Hugo와 Jekyll을 들 수 있겠으나 워드프레스와 마찬가지로 서구권 유저가 많기 때문에 원하는 기능을 찾기가 쉽지 않았다. 무엇보다 각각 Go 언어와 Ruby 언어로 작성되어있는데 사용자 정의를 전제로 하다보니 학습장벽이 부담이 됐다. 주력언어인 Nodejs로 작성된 Hexo에 자연스럽게 눈이 갔다.

작성한 마크다운을 파싱하여 생성된 HTML만 서비스 하면 된다는 점도 큰장점이다. HTML 파일을 단순히 읽고 전송하는 것이 워드프레스 서버 같은 CGI 프로그램을 구동하는 것보다 성능면에서 압도적으로 효율적이기 때문이다.

사용자 정의를 위해서 시스템에 대해 이해해야 했으나 템플릿 엔진_(EJS), 테마, 플러그인 작성법 정도만 학습하면 사이트 전체를 사용자 정의 할 수 있었다. 워드프레스와 같은 대형 프로젝트에 비하면 어려운 점은 없었으며 그중에서도 EJS는 JSP와 유사하여 만약 경험이 있다면 필요할 때 전역변수 정도만 찾아볼 뿐 딱히 학습할 필요도 없었다.⁴

웹 서비스 구성

IP 주소만으로 웹 서비스를 제공하기에는 사용자들의 접근성이 매우 낮아진다. 이미 가지고 있는 도메인에 서브도메인 www를 할당하고 nginx의 가상 호스트 기능을 활용하여 블로그 서비스를 제공하기로 하였다.

실제로 동작시킬 서버로 vultr 호스팅 서비스를 사용하고 있다. 삼성 SDS 상암 데이터센터를 통해 제공되는 서비스로 4년 전 구매 당시 장난감 서버로 월 $8.5 구독 결제였는데 중간에 서버 사양을 올려 월 $11.00의 비용이 소모되고 있다.

1vCPU_{(Intel 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 최적화

SEO 작업과 관련하여 네이버와 구글을 대상으로 조금 진행해봤다. 구글은 표준을 조금 안지키더라도 본문 전체를 크롤링하여 인덱싱을 하는 것 같다. meta 태그를 통한 간단한 작업이었지만 크롤링 봇이 페이지를 확인하고 인덱싱하여 검색결과에 반영되기까지 상당한 시간이 요구되기 때문에 많이 지루한 작업이었다. 구글의 경우 keywords 메타 태그를 지원하지 않는다.

Google에서 검색한 결과가 어떤 기준으로 키워드를 필터링하는지도 테스트도 해보았다. 제목과 본문 내에서 키워드를 인덱싱하고 문서를 찾아내는 것이 기준으로 보인다. description 메타 태그를 제공하면 제목과 설명이 검색 결과에 나오긴 하나 본문을 검색해서 추천해 주는 것인지는 확실하지가 않다. 좀 더 시간을 들인다면 SEO의 수준을 높일 수 있겠지만 적용 후에 확인하기까지의 시간이 길기 때문에 이건 나중에 하기로 하였다.

투자 비용

여기에 대해서는 정말 해주고 싶은 말들이 많다. 이리저리 쓰고 지우고 편집해 봤지만 도무지 줄일 수가 없어 그냥 생략하기로 했다. 좋은 제안이나 방안보다는 가면 갈 수록 잡소리가 되었다. 어차피 쓸 사람은 도시락 싸들고 말려도 쓰고 안 쓸 사람은 귀에 딱지가 생겨도 쓰지 않는다. 나중에 기회가 된다면 글을 하나 별도로 써보는 걸로 하자.