이 블로그는 현재 GitHub Pages 기능을 사용하고 있다. 그 말인즉슨, 정적 리소스 형태로 빌드된 웹 사이트 소스가 GitHub 저장소에 저장되어 있고 GitHub Pages는 단순히 서버에 저장된 정적 리소스에 대한 요청이 들어오면 반환하는 웹 서버 역할만 하고 있고 서버에서 실행되는 코드는 하나도 없다는 것. GitHub Pages에는 커스텀 도메인을 설정할 수 있기 때문에, 도메인 주소만 갖고 있다면 별도의 비용 없이 블로그를 운영할 수 있다. 여기까지는 좋다.
여튼 처음 블로그를 만들 때에는 루비 기반의 Jekyll을 별로 사용하고 싶지 않아서 다른 Static Site Generator (이하 SSG)를 찾아보았고, 결국 node 기반의 Gatsby를 사용했다. GitHub Pages는 Jekyll만 빌드 작업을 지원하는데, Jekyll을 사용하지 않을 경우 유저가 정적 웹 사이트 리소스를 직접 GitHub 저장소에 푸시해야 한다.
이 경우 저장소 관리가 뭔가 약간 이상해지는데, 블로그 사이트의 소스 코드(설마 블로그를 만들고 소스 코드를 그냥 버리는 유저는 없을테니)와 빌드 결과물을 모두 저장소에 푸시해야 하기 때문이다. 몇 가지 옵션이 있기는 한데
- master 브랜치에 빌드 결과물을 푸시하거나
- master 브랜치의 /docs 경로에 빌드 결과물을 푸시하거나
- gh-pages 브랜치에 빌드 결과물을 푸시해야 한다.
GitHub 입장에서는 사용자에게 굳이 다양한 옵션을 줄 필요가 없어서 이렇게 했겠지만, 일반적인 GitHub 사용법에 익숙한 나같은 입장에서는 브랜치마다 아예 다른 내용을 푸시해서 관리해야 한다는 개념이 도저히 납득이 안 되어서 (이해가 안 간다기보다는 그냥 뭔가 잘못된 것 같다는 느낌을 받았다) 그동안 블로그의 소스 코드를 위한 저장소와 빌드 결과물을 저장하기 위한 저장소를 별도로 만들어서 관리를 해 왔다.
하지만 실제로 글을 하나 쓰려면 불편한 것이, 소스 코드 저장소에서 Gatsby 개발 서버를 띄워 글을 작성하고 결과물을 확인한 다음 빌드를 돌리고, 빌드가 끝난 파일을 빌드 결과물 저장소에 복사한 다음, 두 저장소 각각 푸시를 해야 한다. 아니 이게 뭐야…
보통은 npm run deploy 같은 커맨드를 만들어놓고 돌리니까 커맨드를 일일이 입력할 필요는 없지만 이것 또한 뭔가 잘못되었다는 느낌이 계속 들어 그 동안 미뤄오다가 오늘에야 저장소를 하나로 합침. 위에 있던 옵션 중 1번을 사용해서 소스 코드는 dev 브랜치에, 빌드 결과물은 master 브랜치에 저장하는 방식으로 해결.
여튼 SSG를 사용하여 GitHub Pages에서 블로그를 돌리고 싶은 분이 또 계시다면,
- (루비가 맘에 안 들더라도) 웬만하면 Jekyll 쓰세요.
- 그냥 브랜치 두 개 만들어서 소스/빌드 용도로 쓰세요. (gh-pages 사용한 스크립트가 지천에 널려있으니 그냥 갖다 쓰면 됨)
그럼 여기까지.