본 블로그는 휴고(Hugo)를 기반으로 만들어졌습니다. 휴고는 깃헙 페이지(Github page)에서 지원하는 지킬과 같은 정적 페이지 생성기입니다. 이 블로그가 처음 만들어 졌을 때는 블로그다운(Blogdown)을 이용해서 블로그가 빌드되고 배포되었는데, 오늘부터 휴고를 이용해서 블로그가 빌드되고, 배포되고 있습니다.
조금 자세히 말해보면, 본 블로그는 로컬에서 만들어져서 깃랩(gitlab) 저장소에 푸쉬됩니다.
깃랩에서는 .gitlab-ci.yml 파일을 기반으로 푸쉬된 블로그 파일을 빌드합니다.
보통 깃헙 페이지를 이용해서 정적 페이지를 만들기 위해서는 깃헙에서 자체적으로 지원하는 지킬을 이용하는 경우가 많습니다. 그런데 지킬은 빌드 속도가 상대적으로 느린 단점이 있어서 지킬의 대안으로 휴고를 많이 쓰고 있습니다. 깃헙에서 휴고를 이용하려면 저장소에 블로그 파일을 푸쉬하고, netlify 와 같은 외부 서비스를 이용해서 github page와 같은 정적 웹페이지를 운영하는 것이 보통입니다.
그러나 깃랩을 이용하면 휴고도 사실상 자체족으로 빌드가 가능합니다. 깃랩에서는 Gitlab CI/CD 기능을 지원하기 때문입니다. 코드를 올리면, 이를 자동으로 빌드해서 배포해주는 서비스입니다.
.gitlab-ci.yml 파일은 이러한 CI/CD을 어떤 방식으로 할지를 결정하는 파일입니다.
도커를 이용해서 가벼운 가상머신을 로딩해서 깃랩 저장소에 올린 코드를 실행해주는 개념입니다.
바로 이 방식을 이용해서 휴고 기반의 정적 페이지를 만들 수 있습니다.
앞서 블로그다운 방식에서 휴고를 이용한 방식으로 바꿨다고 언급을 했는데요.
조금 구체적으로 말하자면, 블로그다운 방식에서는 웹페이지를 빌드할 때, 리눅스 이미지를 로딩해서 R을 깔고, 블로그다운과 같은 R 라이브러리를 설치해서 웹페이지를 빌드하였습니다. 마치 로컬에서 블로그다운을 이용하는 방식을 그대로 깃랩으로 옮겨간 것이라고 할 수 있습니다.
그런데 문제는 이 방식이 너무 시간 낭비가 많이 발생했다는 것입니다.
간단한 포스팅 하나만 푸쉬를 해도 웹페이지를 업데이트를 위해서 너무 과도한 오버헤드가 소요되었다는 것입니다. 마크다운 파일을 하나만 올려도 리눅스 이미지를 로딩해서 R과 라이브러리를 깔고 페이지를 빌드하는데 너무나 시간이 많이 걸렸습니다. 최근 30회 커밋 통계를 보니 짧게는 8분에서 평균 15분이 넘게 소요되었습니다.(우측에 막대가 낮아진 부분은 휴고를 이용한 것입니다.)
로컬에서 페이지가 잘 나오는지 확인하고 그냥 올리고 기다려도 될 문제지만, 테스트를 해보고, 글을 올려서 결과물을 확인해보고 하는 과정들이 생각보다 자주 발생하는데 너무 비효율적인 상황이 되는 것을 알게 되었습니다.
그래서 블로그다운 방식을 버리고, 휴고 방식으로 바꾸게 되었습니다. 휴고의 장점이 빠른 속도에 있는데, 바로 그 휴고의 맛을 살리기에도 좋았습니다.
깃랩 휴고 샘플 페이지에 올라와 있는 .gitlab-ci.yml파일을 활용해서 쉽게 빌드 방식을 바꿀 수 있었습니다.(저의 IT스승 추장님의 조언이 결정적이었습니다.)
이 방식은 아래 .gitlab-ci.yml코드에서 볼 수 있듯이,
휴고 도커이미지를 바로 불러와서 페이지를 빌드하는 방식입니다.
얼마나 걸렸을까요? 짧아도 5분이상 걸리는 것이 불과 40~50초만에 완료되었습니다. 실은 더 빨리 끝나는 것인데, 현재 gitlab 페이지를 깃허브 페이지에도 자동으로 동기화를 하도록 해놓았기때문에 10~20초 정도 더 소요되는 것 같았습니다.
체감 속도에서 소요시간 10분과 45초는 말도 안되는 차이입니다. 블로그다운 방식도 휴고를 기반으로 하는 R 라이브러리이지만, 그냥 휴고만 쓰는 것은 정말 빨라서 좋습니다.
일단은 블로그다운 방식에서 휴고 방식으로 전환해서 블로그를 운영할 생각입니다만, 한가지 해결해야 할 점이 있습니다.
바로 R코드가 포함된 rmarkdown을 블로그에 올릴 때입니다. rmarkdown는 R을 이용해서 빌드를 해야하기 때문입니다. 일반 markdown에 r의 특수한 기능이 더 덧붙여진 개념입니다.
기존 블로그다운 방식에서는 rmarkdown파일도 잘 빌드가 되었는데, 휴고 방식에서는 다른 방법을 동원해야 합니다.
이에 대한 해결 방법에는 3가지가 가능할 것이라 잠정 결론을 내렸습니다. 자세한 내용은 추가적으로 포스팅하도록 하겠습니다.
간단하게 설명하자면, 첫번째 방식은 저장소 이원화 방식입니다. markdown용(휴고 기반) 기본 저장소와 rmarkdown용(블로그다운 기반) 세컨 저장소를 운영하는 것입니다. rmarkdown용 저장소를 따로 만들고 rmarkdown 파일만 블로그다운 방식으로 올리고, 기본 웹페이지와 연결하는 것입니다. 예컨대, gitlab.com/adalgu/rmarkdown.git을 만들어서 여기에는 블로그 다운 방식으로 빌드를 하는 것입니다. 그리고 여기서 만들어지 페이지를 기본 웹페이지인 https://adalgu.gitlab.com 과 연결하는 것입니다. 앞서 만든 저장소의 rmarkdown 파일이 빌드가 되면, https://adalgu.gitlab.com/rmarkdown/ 으로 접속할 수 있기 때문입니다.
두번째 방식은 로컬에서 미리 빌드해서 올리는 방식입니다. 로컬 컴퓨터에서 rmarkdown 문서를 작성하고 이를 rstudio에서 바로 빌드해서 .markdown이나 .html 파일로 만들어서 올리는 방식입니다. rmarkdown파일을 로컬에서 빌드하게 되면 부속파일을 위한 폴더가 하나 더 생성되게 되어서 컨텐츠 폴더가 조금 지저분 해지는 단점이 있지만, 휴고기반의 빠른 속도의 장점을 누릴 수 있으면서도 rmarkdown으로 생성되는 각종 문서포맷을 이용할 수 있게 되는 장점이 있습니다.
세번째 방식은 도커이미지를 만들어서 블로그다운 방식을 이용하는 것입니다. 깃랩에서는 도커이미지를 등록하고 이를 불러와서 실행할 수 있는 기능까지 지원합니다. 아직 시도해 보지는 않았지만, 블로그다운 방식의 문제점이었던 오버헤드문제를 일정수준 해소할 수 있지 않을까 예상하고 있습니다. 아직은 도커에 익숙한 상황이 아니라 테스트 수준으로 진행해 본 정도이고, 일단 첫번째 방식과 두번째 방식을 혼용해서 블로그를 운영해 볼 예정이지만, 여유가 좀 생기면 이 방식으로도 블로그를 빌드해 보려고 합니다.