마지막 포스팅이 2월 25일이라니, 근 한 달만에 포스팅이다.

사실 포스팅을 한 지 이렇게 오래 됐는지 몰랐다. 틈틈히 글을 써왔어야 했는데..
마지막 포스팅과 지금 사이에 물리적 간극은 여느때와 다름 없었지만

개인적으론 12년지기와 함께한 7일간의 베트남 여행을 다녀오고
기술 블로그와 병행하기로 한 글 블로그 개설 작업을 비롯해서
여행 일지 정리를 하다보니 기술 블로그 쪽 포스팅을 잊고 지내게 되었다.

그러다 어제 문득 이카루스 테마 관련 글을 스스로가 참고하고자 기술 블로그를 열었는데…
이럴수가, 테마를 적용하는 파트까지도 적어놓지 않았다니??

난 당연히 테마를 적용하는 부분까지는 포스팅을 한 줄 알았는데, 겨우 개설만 해놓고 멈췄다니..
그래서 마저 포스팅을 하기 위해, 이번 포스팅을 작성한다.

이제 기본 landscape 테마가 아닌, 예쁘게 만들어진 템플릿들을 이용해서 블로그를 꾸며보자.

테마를 넣어보..기전에.

일단 내 포스팅에 사용된 Hexo의 테마는 이카루스 테마임을 밝혀둔다.

| 링크된 이클립스 테마는 포크(folk)를 통해 아래와 같은 사항들이 커스터마이징 된 테마다.
| 1. 헤더 고정
| 2. 모바일 해상도에 따른 Search box 배치 변경
| 3. 배경 색 변경

예시로 사용할, 그리고 지금보고 있는 블로그에도 사용된 이카루스 테마 말고도 Hexo는 190여개가 넘는 테마를 제공하는데
더 많은 테마는 Hexo Theme 사이트에서 확인할 수 있다.

직접 들어가서 보면 알겠지만 생각보다 다양한 테마들이 있으며 애초에 Hexo가 Node.js를 기반으로 이루어져 있기에
테마를 받아서 열어보면 node.js를 공부할때 튜토리얼에 늘상 나오는 ejs 파일들과 yml파일들, 그 외 css와 js파일들을 확인할 수 있다.

다만 다양한 테마가 있는만큼 테마들의 사용법도 다양하다.
물론 기본적인 사용방법은 같지만, 정말 기본적인 수순까지다.
이번에 글을 위한 블로그를 개설하면서 이카루스 외에 다른 테마로 가져가기 위해 두,세가지 정도의 테마를 사용해봤는데
각 테마마다 config.yml의 내용도 달라지고 어떤 테마는 grundle을 사용하는 테마도 있으며
css도 less나 sass등 테마를 만든 사람의 입맛에 맞게 구성되어 있었다.

물론 이런 파일적인 측면뿐만이 아니라 기능에서도 테마마다 차이가 있는데
search 엔진도 제각각이고 카테고리, 태그 기능이 아예 없이 이쁘기만 한 곳도 있으며
사진을 보여주는 라이브러리도 어떤 곳은 오픈된 라이브러리를 통해 이쁘게 보여주지만
어떤 곳은 그냥 일반형태로 보여주는 등..그야말로 천차만별이었다.

따라서 이 포스팅을 통해서 테마를 적용한다면, 그저 기본적인 형태의 테마 사용법 + 이카루스 테마에 대한 이야기 정도를 알아갈 수 있을 것이다.

테마를 적용해보자(공통)

일단 테마를 적용하기 위해선, 당연한 말이지만 적용하고픈 테마를 찾아야 한다.
물론 난 이런거 필요없어. CSS 따윈 씹어먹어주지! 라고 하시는 분들은 본 포스팅을 패스하시고
직접 장인의 손길을 담아 한땀한땀 블로그를 구성하셔도 된다고 미리 말씀을 드린다.

하지만 세상엔 능력자가 많고 나보다 미적감각이 뛰어난 이들은 얼마든지 있다.
나는 나를 과신할 정도로 능력을 맹신하지 못 하기에 Hexo Theme 사이트를 뒤지며 모든 테마를 검토했다.
물론 2편에도 언급했듯 Pilsner를 통해 이카루스 테마를 점지해두고 있었지만
보다 이쁘고 내 활용용도에 맞는 테마가 있다면 얼마든지 다른 테마를 이용할 용의가 있었다.

테마를 살펴볼때 고려한 사항들은 여러가지였지만 일단 중요했던 건 카테고리와 태그 기능의 여부였다.
기술 블로그로써의 목적이었고 포스팅을 한다면 Web, Android, Spring등으로 카테고라이징은 필수라고 생각했고
거기에 태그 기능까지 있다면 차후 검색을 통해 찾기에도 제법 유용할 거라고 생각했기 때문이다.

그 외에 추가로 고려된 사항들이 UX 쪽의 세부사항들이었는데,
블로그이다보니 포스팅이 길어질 거고 스크롤을 내릴때 메뉴들은 고정인가에서부터
페이징인지 인피니티 스크롤인지, Search 엔진은 무엇을 썼는지등이 고려사항으로 적용되었다.

그러고 최종적으로 후보에 있던 것이 실제로 사용한 icarus와 tranquilpeak였는데 당시만해도
icarus는 기술 블로그로, tranquilpead는 글 블로그의 테마로 사용하기로 마음먹었었다.
(현재는 두 블로그 모두 icarus 테마를 사용중이다. 왜 그랬는지는 차후 포스팅에서 밝히기로 하겠다)

그래서 이제 마음에 드는 테마를 찾았다면 [Hexo] Github Page로 블로그 만들기 03에서 언급했던 hexo blog의 기본 디렉토리 구조를 떠올려보자.

tech-blog
├── _config.yml
├── package.json
├── scaffolds
|   ├── draft.md
|   ├── page.md
|   ├── post.md
├── source
|   └── _posts
└── themes

가장 하단부를 보면 버젓이 themes라는 디렉토리가 있음을 확인할 수 있다.
그냥 봐도 직관적으로 아, 저기에 테마관련 파일들을 넣어두면 되겠구나, 라는 생각이 들 것이다.

hexo에서 기본적으로 제공하는 테마는 landscape 테마다.
지금 hexo server 명령어 통해 서버를 올리면 까만 우주에 태양인지 뭔지 모를 빛무리가 떠오르는 배경이 있는 그 테마.

테마를 적용하는 방법은 의외로 간단하다.

1. themes 디렉토리로 이동을 한다.
2. 그 위치에서 테마가 올라가있는 git repository를 clone 한다.
3. _config.yml의 theme 값을 생성된 디렉토리의 명으로 해준다(보통은 테마의 이름이 디렉토리 명이다)

이렇게 3단계를 해주고 hexo server 명령어를 적용해주면 본인이 콕 짚은 테마가 적용된 블로그를 볼 수 있다
(혹시나 제대로 나오지 않는다면 hexo clean을 해보고 서버를 올리도록 하자)

그 뒤에 웹 브라우저상의 상단 타이틀이나 description등을 고치고 싶다면
root 디렉토리의 _config.yml 파일에서 아래와 같은 항목을 고쳐주도록 하자.

# Site
title: Grey Title # 좌상단 메인 타이틀 겸 브라우저 상단 타이틀
subtitle: Grey SubTitle 
description: Grey Description 
author: Grey Lee Author # 하단(Footer)에 추가 됨

테마를 적용해보자(icarus)

위의 설명을 따라 이용하고픈 테마를 적용시켰다면, 그 다음부터는 해당 테마가 제공하는 가이드를 참고하기 바란다.
이미 언급했지만 테마들 마다 사용하는 방법이나 스펙이 전부 다르기때문에 그 모든 것을 포스팅하는 것은 불가능하다.
(아니 뭐..물론 190여개를 다 해볼수야 있겠지만..테마 전문 리뷰어도 아니고, 굳이…?)

그래서 여기부터는 이카루스 테마를 사용한 사람들을 위한 추가 가이드이다.

1. 일단 Search 엔진을 좀 사용해봅시다.

이카루스 테마는 우상단부에 Search Box를 기본으로 제공한다.
다만 Search Box UI는 제공하는데 기능은 추가적으로 npm package를 설치해 줘야한다.
(UI는 있는데 기능은 없다니..github deploy 때도 그랬지만, 왜 이렇게 해놓은 건지는 모르겠다.)

npm install -S hexo-generator-json-content

hexo-generator-json-content는 hexo 블로그 내부의
page나 post형태의 글에 대해서 json 형식으로 검색 엔진을 제공한다고 한다. 트위터의 미리보기나 ajax를 통한 사이트 검색등에 유용하다나 뭐라나..
제공되는 Github Repository의 설명을 보면 _config.yml에 일부 옵션 값을 명시함으로서 커스터마이징하게 사용할 수 있을 것 같지만
그 부분은 차후에 시간을 별도로 할애해서 직접 해보고 포스팅을 추가하든지 해야겠다.

일단, 지금은 디폴트 상태의 insight search 기능을 추가해보도록 하자.
…라고 하지만 위와 같이 npm package를 설치하는 걸로 끝이다.

더 정확하게는 이카루스 테마 디렉토리 내부의 _config.tml에 아래와 같이 옵션값을 true로 설정해줘야 하지만

# Search
search:
    insight: true

설정해주지 않아도 괜찮다. 애초에 기본값이 true 다.

이것으로 생성된 블로그 내부에서 검색기능을 사용할 수 있게 되었다.
Search Box를 누르면 모달창과 같은 검색창이 나올 것이고 키워드를 입력하면 타이틀, 내용에 상관없이 전수검색이 적용되는 것을 확인할 수 있다.

2. 카테고리랑 테마를 눌렀..응? 404…?

이제 search 엔진도 적용시켰겠다..본격적으로 포스팅을 하고 블로그 관리를 하면 된다고 생각했었다.
그리고 적용된 테마가 신기해서 이곳저곳을 누르다가
상단 메뉴의 카테고리와 태그를 눌러보면 404가 뜨는 걸 볼 수 있다.

아마 창세기처럼 새하얀 바탕에 Get/~~~~ 어쩌구 에러메시지가 본인들을 반겨줄 것이다.

처음엔 이게 뭐야, 내가 또 설정을 어디서 삐꾸냈나? 하고 한참을 헤맸더랬다.
그러다 발견한 이카루스 Github Repository의 wiki를 보다보니

If you want enable the Categories and Tags for your blog, please copy _source/categories and _source/tags folder to sources folder under your site’s root folder, and then add menu to your _config.yml.

라는 안내 문구가 있었다.

(직역주의)
만약 너님이 허용하려면, 카테고리 그리고 태그를 너의 블로그를 위해.
부디 복사해라 _source/categories 그리고 _source/tags 폴더를, 너의 사이트 root 아래에 source 폴더로.
그리고 _config.yml에 메뉴항목으로 추가해라.

..아,음 새벽 1시쯤이라 그냥 드립을 좀 해보려한..겁니다.
네, 그냥 이카루스 테마 아래에 있는 _source/categories랑 _source/tags 폴더를 root/source로 복사해주시고
_config.yml 상단에 있는 menu 항목에 해당 정보를 추가해주면 된다.

# Menus
menu: # 요 아래 뒤에 붙는 건 URL임. 그러니까..깃헙 기준으로 보자면
  # Home: . # 얘는 http://localhost:4000/tech_blog/
  Archives: archives # 얘는 http://localhost:4000/tech_blog/archives
  Categories: categories # 얘는 http://localhost:4000/tech_blog/categories 뭐 이런 식
  Tags: tags
  About: about

위 코드에도 적어놨지만 좌측의 값이 화면 상단 메뉴바에 표시되는 텍스트이고
우측의 값은 사용하는 URL의 뒤에 붙는 값이다.

이렇게 폴더를 복사하고 _config.yml 에 추가함으로써 탈 없이 카테고리와 태그를 사용할 수 있다.

그리고 이 쯤에서 포스팅을 하며 문득 떠오른 기억이지만 블로그에 테마를 적용하고
기본적인 메뉴구성을 한 것이 한 달도 전이라..정확히 기억이 나질 않는데
아마 About 메뉴도 이와 비슷한 에러가 있었던 것 같다.
(이래서 제때제때 포스팅을 해야 하는 것인데..)

참고로 위에 인용된 문구를 보면 알겠지만 이카루스에서도 카테고리와 태그에 대해서만 언급하고 있다.
(그래서 나마저도 기억이 가물가물한 거다..처음부터 about 디렉토리가 source 아래에 있던 건지 내가 옮긴건지…)

혹시나 About도 404와 같은 에러가 난다면 카테고리와 태그 폴더를 복사해서 옮겼듯이
About 또한 이카루스 테마 디렉토리의 _source/about 을 복사해서 동일한 위치에 가져다 놓도록 하자.
그러고 about 디렉토리 아래의 index.md를 수정하면 화면에서도 잘 동작하는 것을 확인할 수 있다.

번역해보면 카테고리랑 태그 메뉴를 사용하려면 이카루스 테마 디렉토리 내부의 폴더 2개를 root/source로 옮겨줘야 한다는 거다.

일단 오늘 포스팅은 여기까지.
다음에는 _config.yml을 통해서 일부 설정을 변경하는 내용을 포스팅할 예정이다.
그러고나면 Disqus을 이용해서 Comment를 넣는 부분도 포스팅할 예정이다.

Hexo 시작해보기

앞 선 포스팅에서 밝혔지만 지금 보는 블로그 icarus 테마가 적용되어있다.

사실 블로그를 만들어야 겠다는 생각은, Intro 포스팅을 보면 알겠지만 오래된 생각이다.
그러다 더 이상 미루고 미루다가는 절대 안 할 거 같은 수동적 성격의 나를 채찍질해서 집 근처 스벅으로 오게되었다.
(사실은 설 귀성 기차가 저녁 6시라 이때다 싶었다..)

Github 작업거리

블로그를 만들기 위해서는 무엇보다도
첫 번째, 블로그를 서비스할 Github repository를 생성해야 한다.
내 경우에는 tech_blog라는 이름의 repository를 생성하고
Settings 에서 Github Page 를 master 브랜치로 설정 후 Save 해줬다.
(굳이 master 브랜치가 아니라 다른 브랜치로 해도 상관은 없다.
다만 일부 repository의 경우 로컬에서 master 브랜치로 Direct Push가 안 되는 경우도 있으니
이 경우엔 Github Page 서비스 브랜치를 다른 걸로 바꾸거나
다른 브랜치에 Push해서 Pull Request를 날리도록 하자.)

로컬 작업거리

상세한 포스팅을 보기 전에, hexo로 블로그를 띄우는 명령어만 순서대로 뽑아보면 아래와 같다.

npm install hexo-cli -g
hexo init tech_blog
npm intall
hexo server

겨우 4줄!
겨우 4줄만 터미널에 입력해주면 나만의 블로그가 생성되는 것이다.

자, 이제 일련의 과정을 좀 상세히 풀어보겠다.
Github의 준비는 끝났으니 이제는 로컬에서 필요한 작업을 해 줄 차례다.

사실 hexo는 예전에 회사에서 사내 Github 도입기념으로 사내 블로그나 만들어볼까 싶어 건드린 적이 있었다.
(이라고 하기엔 벌써 몇 달 전이니 그게…사실 써봤던 녀석이라 ‘Jekyll vs Hexo’에서 선택된 이유 중 하나다.)

앞 선 포스팅에서도 말했듯이 hexo는 npm을 이용해서 설치를 해준다.
그렇기에 Node.js가 설치되어 있지 않다면 이 링크를 통해 설치해주길 바란다.

Node.js가 설치 완료되었다면 hexo로 블로그 관련 파일들을 생성할 디렉토리로 이동한 뒤
터미널(window는 cmd나 powershell)을 열어준다.

npm을 통해 hexo를 설치해주기 위한 명령어는 아래와 같다.

npm install hexo-cli -g

위 명령어로 hexo 를 global(어디서 터미널을 열든 hexo 명령어를 쓰겠다는)로 설치한다.
(..하려 했는데 root 권한이 필요하다. sudo -s 로 유저를 root로 변경 설치해주세요)

다음으로 현 위치(블로그 관련 파일들을 받을 디렉토리)에서

hexo init tech_blog

를 입력한다.

hexo init 만 입력해도 블로그 관련 파일들이 생성되는데는 문제가 없다.

다만, 뒤에 디렉토리명을 붙이면 동명의 디렉토리가 생성되면서 거기에 파일들이 생성되는 것이다.
hexo init 를 했을 때의 주의점은 명령어를 실행한 위치에 파일들이 생성되기 때문에 해당 디렉토리에는 그 어떤 파일도 있어서는 안 된다는 것이다.
만약 단 하나의 텍스트 파일정도만 존재해도 hexo init 명령어는 Error 메시지를 뱉으면서 생성에 실패하게 된다.

hexo init 후 조금만 기다리면 콘솔이 주루루루룩 위로 넘어가더니 뙇하고 각종 파일들이 생성될 것이고
아마 기본적인 디렉토리 구조는 아래와 같을 것이다.

tech-blog
├── _config.yml
├── package.json
├── scaffolds
|   ├── draft.md
|   ├── page.md
|   ├── post.md
├── source
|   └── _posts
└── themes

생성된 디렉토리로 이동 후 가장 먼저 해야 할 건 dependency package를 통해서
package.json 에 명시된 package를 설치해주는 것이다.

npm install

을 입력해주면 또 콘솔이 주루루루룩 하면서 위로 넘어가더니 뙇하고 끝이 난다.

자,이제 이 것만으로도 블로그 띄울 준비는 85%는 끝난 것이다.
가볍에 콘솔에 아래 명령어를 입력해보자.

hexo server

그러면 http://localhost:4000 으로 hexo server가 뜨는 것을 확인할 수 있다.
(hexo의 기본 테마는 landscape 로 되있기에 설정의 변경없이 그냥 서버를 띄웠다면
우주의 까만 배경으로 빛무리가 뜨왛하는 landscape 테마가 보이는 게 정상이다)

hexo를 통해 블로그를 띄웠으니 이젠 설정에 대한 부분을 조금 설명하겠다.

hexo의 모든 설정은 _config.yml 파일 에서 담당한다.
가져다쓰는 테마들은 모두 각 테마들만의 _config.yml 파일을 가지고 있는데
root 디렉토리에 있는 _config.yml 파일이 총괄대장역할을 하며
테마 디렉토리 안에 있는 _config.yml 파일들은 위치에 맞게끔 각 테마들을 담당하는 부대장이라 할 수 있다.
(그렇기에 root의 _config.yml 내부에 theme 속성 값으로 부대장을 임명하면 해당 테마가 동작하는 방식이다)

root의 _config.yml 에서 타이틀이나 subtitle, description, root url등의
굵직한 설정들-총괄대장이니까-을 추가, 변경, 삭제등 관리할 수 있다.
(아래에 삽질2라는 이름으로 포스팅을 했는데, 여기서 root url 부분을 간과한게 내 뒷통수를 때렸다)

이제 로컬에 띄운 블로그를 아~~까 만든 Github Repository에 배포해보려고 한다.
배포를 하려면 당연히 배포처를 지정해야 하고 hexo의 모든 설정은 _config.yml 이 한다고 이야기해왔다.
배포처 설정도 마찬가지로 _config.yml 에 있는데 해당 파일을 열어보면 맨 아래에

# Deployment
## Docs: https://hexo.io/docs/deployment.html
deploy:
  type:

요런 상태로 초기 값이 텅 빈 상태일 것이다.
이제 여기에 위에서 생성한 Github Reposity를 설정해주면 되는데

deploy:
  type: git
  repo: https://github.com/GithubUsername/RepoName.git
  branch: master

위와 같은 값으로 입력하면 된다.
type은 git 이고 repo는 배포하려는 Github Repository의 URL이 들어가며
branch는 배포 시 push 될 타겟 브랜치를 적으면 된다.

자, 이제 저기까지 설정이 끝난 상태에서

hexo generate

명령어를 실행하면 index.html 을 포함해서,
Github Repository에 올라갈 정적 파일들이 public 디렉토리 아래로 생성된다.

파일들의 생성을 확인했다면

hexo deploy

이 명령어로 Github Repository로 hexo가 배포될 것이다.

…그렇게 배포되어야 하는데…무사히 잘 올라가야 되는데…읭?
Error Deployer not foundgit?? 에러? 읭?

이게 뭐지, 하고 구글링을 해보니 배포 대상이 Github일 경우 npm으로 설치해줘야 할 패키지가 또 있었다
(아니, 이런 건 기본으로 좀 넣으라고 hexo님들아..)

그래서

npm install hexo-deployer-git --save

명령어를 통해 배포를 위한 전용 npm package를 추가 설치해줘야 한다.
(npm의 –save 옵션에 대한 건 하단에 별첨을 참고바란다)

자, 배포에 필요한 패키지도 설치했으니 다시

hexo deploy

명령어를 실행해주면 깔끔하게 지정해 준 Github Repository로 배포되는 것을 확인할 수 있다.

그러고나서 Github Repository에 접속해서 지정된 URL로 들어가면 쫘잔, 하고 로컬에서 띄웠던 페이지가 나온다.
(Github Page의 경우 배포 후 즉각 반영되진 않는다. 물론 수분내로 반영되지만 딜레이가 좀 있음을 알아두자)

자, 그럼 이제 직접 만들고 배포한 Github Page가 이상없이 동작하는 것을 확인할 수 있을 것이다.

…정말? 잘 나오나요? CSS 하나도 안 깨지고, resource들 잘 읽어옵니꽈??
그럼 요 아래는 안 읽으셔도 됩니다. 네? 깨져요? 그럼 요 아래 좀 더 읽으세요.
(참고로 전 깨져서 여기서 한동안 삽질을 했습니다. 하…ㅠㅠ)

몇가지 삽질

삽질 1.
몇 번이나 언급했지만 hexo는 로컬에서 정적파일로 떨어트린 뒤에 Github에 업로드한다.

정적파일로 떨어트리는 이 과정(hexo generage)에서,
기존 로컬에 남아있던 찌꺼기들로 인해 새로운 정적파일이 만들어질 때 불순물이 섞일 수도 있다고 한다.
(어떤 파일, 데이터, 뭐가 불순물인지는 명확히 모르겠습니다. 그걸 알면 내가 이미 Guru지…)

그래서 hexo generate를 하기 전에 hexo clean 을 실행해서 청소를 한 번 싹 해줍니다.
이러면 hexo clean 하는 과정에서 뭔가 delete 되었다는 걸 확인할 수 있습니다.
그 후에 hexo deploy를 통해 Github으로 배포해보시기 바랍니다.
(참고로 hexo deploy —generate 를 하면 정적파일을 로컬에 떨군 뒤에 배포까지 한 방에 해버립니다)

명령어만 순차적으로 나열해서 요약하자면 아래와 같군요.

hexo clean
hexo deploy -generate

이제 되나요? 되면 그만 읽으셔도 되구요.
여전히 안 되나요? 그럼 좀 더 읽어주세요ㅋㅋㅋㅋ

삽질 2.

이게 제가 삽질한 문제점입니다
(삽질1은 그냥 이 삽질을 해결코자 구글링을 하다보니 찾은 문제라, 이런 경우도 있구나 한 거구요)

저는 애초에 Gitub을 통해서 여러개의 블로그를 운영할 계획이었습니다.
메인 블로그(개인 프로필과 서브 블로그들의 링크만 담당)가 있고
기술 블로그, 글, 사진 블로그등을 생성할 생각이기 때문에
일부러 Repository의 이름에도 tech라는 단어를 넣어서 tech_blog로 한 것인데요.

여기서 문제가 발생한 겁니다.

커스터마이징이 가능한 대부분의 서비스(앱이든 홈페이지든 뭐가 됐든)는
최소한의 기능만을 디폴트로 제공하고 너님이 필요하시면 수정해서 쓰세요, 라는 것이 정석입니다.
hexo도 당연히 그런 불문율을 따르고 있구요. Github 또한 그렇습니다.

그 중에 하나가 바로 Github Page의 URL 규칙인데요.
기본적으로 Github은 username을 바탕으로 Page의 URL을 제공합니다.
제 Username인 blinders를 예로 들자면 https://blinders.github.io/ 의 형태가 디폴트입니다.
즉, https://username.github.io/ 의 형태이지요.
(이에 대한 건 [Hexo] Github Page로 블로그 만들기 01의 아래 별첨에도 포스팅했습니다)

그럼 여기서 내가 별도로 생성한 Repository에 블로그를 생성한다면?
네, URL의 기본형태는 https://username.github.io/RepoName가 됩니다.
그리고 Github에서 저 URL을 root로 잡아버리기 때문에,
정적인 파일로 떨궈서 서비스하는 hexo의 경우에는
필요한 resource들의 경로를 제대로 잡지 못 하는 문제가 발생합니다.
(아,내가 이것 때문에 얼마나 허망한 구글링의 시간을 보냈던가ㅠㅠ)

이건 어떻게 해결해야 할까요?
당연하게도 Github Page에서 명명한 URL 규칙을 우리가 바꿀 수는 없으니
hexo의 설정을 건드려줘야 합니다. 네, root 디렉토리의 _config.yml 에 해당 설정관련 값이 있습니다.

_config.yml 을 열어보면 상단에

# URL
## If your site is put in a subdirectory, set url as 'http://yoursite.com/child' and root as '/child/'
url: http://yoursite.com
root: /

이런 게 있습니다.
…네, 떡하니 써있네요.
너님의 사이트가 서브디렉토리를 쓰면 root 설정에 값을 추가해주라고…
무심결에 제대로 읽어보지 않고 성급히 구글링부터 한 제 잘못이네요..크읗ㅠ

이제 해결해 봅시다. 저기 root 항목에 /RepoName/ 을 적어주고

hexo clean 
hexo deploy —generate

를 해줍니다. 그럼 주루루룩 뜨더니 슝 하고 파일들이 Github Repository에 안착할 텐데요.
이제 블로그 URL로 들어가보시면 CSS도 깨지지 않는 평안한 블로그를 보실 수 있을 겁니다.

아, 험난한 블로그 생성기네요. 지나고 나니 별 거 아닌데 넘나 힘든 것..
마침 에픽하이 노래, 빈차가 나오는데 가사가 마음에 와닿네요.
자라지 않으면 성장통도 그저 pain
크으, 에픽하이 가사는 정말 사골국물이에요,
울궈먹고 울궈먹어도 새롭고 이성보단 감성에 꽂혀주시네요ㅠㅠ

…네, 샛길로 새는 걸 보면 아시겠지만 이 글은 여기까집니다.

다음엔 실제 포스팅을 해보고 포스팅 하는 거랑…
..아, 그 전에 일단 css랑 메뉴(카테고리나 아카이브나 프로필이나)들부터
좀 더 제 입맛에 맞게 커스터마이징하고 후기를 써야 겠군요.
그럼 다음편에 뵐게요.

별첨

1. npm install hexo-deployer-git –save : –save 옵션은 package.json을 함께 업데이트 해 줍니다.
   나중에 이런 귀차니즘이 또 발생하지 않도록… –save에 추가로 –save-dev 라는 옵션도 있는데
   둘의 차이는 package.json 내부에 업데이트를 해줄 때,
   대상으로 쓰여질 json 객체가 dependencies 냐 devDependencies냐의 차이입니다.
2. dependencies 와 devDependencies의 차이는 npm install 할 때 발생하는데.
   npm install은 기본적으로 package.json에 명시된 객체값들을 바탕으로
   의존(dependency) package들을 설치해줍니다.
   이때에 dependencies의 값은 항상 설치되고
   devDepenencies의 값은 –production 옵션을 붙이면 빠지게 됩니다..
   production에선 개발급(devDepenencies)은 뺀다는 의미로 받아들이시면 될 거 같습니다.
   만약 npm install “$package” 명령어를 통해서 하나하나 설치하신다면
   –dev 옵션을 붙이셔야 devDepenencies의 패키지들이 설치가 됩니다.

Jekyll vs hexo

앞 선 포스팅에서 Github Page를 좀 더 편하게 구성해주는 플랫폼에
Jekyll과 Hexo라는 아이들이 있는 것을 언급했다.

그러면 이제 둘 중 어느 것을 사용할 것인가를 정해야 하는 단계인데, 간단히 비교를 해보자면.

Jekyll의 장점은

1. Github Page의 기본 지원체제.
2. Git 히스토리를 통한 이력관리가 가능.
3. Hexo 대비 좀 더 많은 테마.

Github Page 라는 시스템의 기반이 애초에 Jekyll로 동작을 하기 때문에
하나의 파일로 구성된 정적페이지 형태로써 호스팅이 제공되는 게 아니라
Repository에 올라온 파일들이 Github에서 Jekyll을 통해 빌드되어 웹 페이지로써 호스팅되는 것이다.

그렇기 때문에 어떻게보면 Github에서 공식지원을 해준다고 볼 수도 있고
Git 히스토리의 경우 파일이 바껴버리면 기존 파일의 삭제, 새 파일의 생성으로 인식해서
히스토리를 제대로 관리할 수 없는데 이 경우엔 정적파일로 아예 교체되는 게 아니라
기존 파일들의 내용만 수정되는 경우이므로 Git 히스토리 관리에도 용이하다.

Jekyll의 단점은

1. 기반언어가 Ruby다.
   외국이나 일본에서는 Ruby를 사용하는 개발자가 늘고있지만
   여전히 우리나라에선 Ruby는 생소한 언어이고 익숙치 않은 언어다.
   그렇기에 Jekyll을 사용하려는 입장에선 어색해할 수도 있으며
   환경에 따라 다를 수 있겠지만 Ruby는 느리다.

Hexo의 장점은

1. npm(Node.js)을 이용.
2. 문서화가 잘 되있다.
3. 자체 배포가 가능하다.

Hexo는 node.js를 기반으로해서 동작하는 언어다.
그래서 테마들을 열어보면 ejs 파일로 구성된 파일이 많으며 그 덕에 Jekyll보다는 코드들이 익숙하다.
설치시에도 npm install hexo-cli -g 명령어를 통해 간결하게 설치되며
공식 홈페이지의 구성도 Jekyll보다는 심플하고 한글화도 잘 되어있다.

Hexo의 단점은

1. Jekyll보다 테마가 적다.
2. Git 히스토리를 통한 이력관리가 불가능하다.

아무래도 Jekyll이 Github Page에서 지원하는 플랫폼이다보니 가져다 쓸 수 있는 테마가 적다.
하지만 그렇다고해서 월등히 차이가 난다, 라는 느낌까진 아니고 Jekyll이 100이라면 Hexo는 80쯤 되는 느낌이다.

2번 항목이 오히려 조금 문제일 수도 있는데 Hexo는 명령어를 통한 자체 빌드와 배포를 통해서
매번 완성된 하나의 파일(index.html)을 생성하는 방식으로 서비스를 제공한다.
위에서도 언급했지만 이런 경우 Git 히스토리는 기존의 파일에 대한 수정으로 보는 것이 아니라
기존 파일이 삭제 되고 아예 새로운 파일이 생성되었다고 판단하기 때문에 Git 히스토리를 통한 이력관리가 힘들어진다.
또한 css파일등을 보더라도 이 값이 어느 파일에서 기인한건지를 판단할 수 없기때문에 이 또한 이력관리에 애로사항으로 볼 수 있다.

그랬지만 결론은 Hexo

결국 둘 중 무얼 할까 고민을 했다.

Jekyll-Ruby의 경우 잠깐이지만 사용해 본 경험이 있기에(조금의 공부야 필요하겠지만) 어색하지도 않았고
엔터프라이즈급 대형 서비스를 호스팅 할 것도 아니기 때문에 Ruby의 느린 속도라는 단점도 감내할 수준이었다.

Hexo의 경우도 Git 히스토리를 통한 이력관리가 불가능한 단점이지만
이는 어디까지나 빌드&배포 후 정적파일에 대한 이력관리가 불가능한 것이지
PC에 있는 파일들에 대한 이력관리까지 불가능 한 것은 아니었다.
즉, 별도의 Repository를 하나 더 생성해서 거기서 관리하면 되는 것이었다.

결국 최종 선택은 Hexo였는데, 위에 주구장창 장단점을 비교한 것과는 달리 선택 사유는 심플했다.

하려는 것이 블로그이니 만큼 블로그의 목적에 맞는 테마가 있는 걸로 선택하기로 한 것이다.
(어차피 포스트 내용은 파일로써 남을 거고, 둘다 Markdown은 지원하니까)

이런 저런 테마를 찾아보던 중 Pilsner가 사내 금요토크에서 사용한 icarus 테마가 딱 마음에 들었다.
(카테고리&아카이브 기능, 심플한 디자인, 넓은 포스트 영역, 페이징, Internal Search 기능등)

해당 테마를 눈여겨 봐두고 있다가 결국 오늘(18.02.15), 결행을 감행했고 이 블로그가 탄생하게 되었다.