많은 글은 아니지만, tistory, notion을 통해 블로그 글을 작성해왔고 불편함을 느껴서 새로운 웹페이지 배포 방법을 찾다Hugo라는 tool을 발견했습니다. Hugo를 내 새로운 posting tool로 선택하게 된 이유는 3가지입니다.• None 포스팅 글을 저장하고 옮기고 수정하는데 용이하다• None 내가 사용하던 Tool에 비해 빠르고 간결하다• None 처음에는 낯설지만 적응하면 더 편하게 글을 작성할 수 있다이외에도 결정하게 된 여러가지 이유가 있지만 가장 큰 이유는 위 세가지였습니다. 생각보다 hugo 환경으로 블로그를 작성하고 배포하기까지의 과정이 쉽지 않았기 때문에 그 내용을 공유하고자 합니다.Hugo 설치부터 Gitlab을 통한 웹페이지 배포까지[STEP1] Gitlab에서 배포 용 프로젝트 만들기Hugo blog를 배포하기 위한 Project를 만드는 것이 첫번째입니다.gitlab에서는 [username].gitlab.io로 생성한 project를 gitlab page로 사용했을 때 도메인을 해당 이름으로 그대로 제공하는 기능이 있습니다.새로운 project name으로 만들게 되면 [username].gitlab.io/[proejct name] 으로 생성됩니다.제 컴퓨터는 Mac이기 때문에 brew로 설치했습니다.다른 OS인 경우 hugo 홈페이지에 들어가면 방법이 나와있습니다. (https://gohugo.io/)blog라는 이름의 hugo 사이트 디렉토리가 생성됩니다.생성된 디렉토리를 STEP1에서 생성했던 gitlab 저장서와 연결해 줘야합니다.처음 사용해보는 것이기 때문에 hugo에서 제공하는 theme를 사용하면 좋겠다고 생각했고,기본적으로 제공해 주는 theme중 PaperMod theme를 선택해서 submodule로 넣어주었다.theme 별 사용하는 방법이 다를 수 있으므로, 원하는 theme의 사용 설명서를 잘 읽어보길 바랍니다.저는 PaperMod의 Installation 문서를 참고하여 사용할 theme를 구성했습니다.Papermod 문서를 살펴보면, 테마를 사용하기 위해서는 config.yml을 생성해 줘야 합니다.제 기준에서 다음과 같이 파일을 구성하면 PaperMod 테마를 적용할 수 있습니다.gitlab의 CD/CI 기능을 통해 Page를 배포 할 것이기 때문에, 해당 파일을 구성해 줘야합니다.그동안 구성한 것들을 저장소에 커밋하고 Push 하겠습니다.이렇게만 하면 끝일 줄 알았는데 여기서 많이 헤맸습니다.Gitlab Page를 배포하기 위해서는 runner 관련 몇가지 사전 준비가 필요합니다.• None 먼저 Settings > CI/CD Settings 메뉴에서 Shared runners를 Off해야 runner가 작동되었습니다.• None runner를 통해 proejct가 배포될 수 있도록 구성해야합니다.저도 이부분에 대한 자세한 내용은 모르지만, Docker내에 구성하여 주로 사용하는 것으로 보입니다. 먼저 1번에서 보여드린 그림에서 New project runner 버튼

안녕하세요, 기술연구소에서 배달통 iOS개발을 맡고있는 신범철입니다.기술 블로그를 준비한다는 소식을 공식적으로 2017년 말에 접하게 되었고, 여러 구성원들이 기고에 참여하게 되었습니다. 운영 방식과 주제, 디자인 등에 대한 활발한 토론이 진행 되었고, 저는 이 모든것을 지켜보기만 하는 제 3자의 위치에 있었습니다.그러던 중 UX Lab에서 저와 같은 서비스를 만들고 있는 제 아내가 블로그 디자인을 맡게 되었습니다. 저는 여전히 응원을 해 주는 위치에 머물러 있었고 끝까지 그러려고 하였습니다. (성격상 앞에 나서거나 어딘가에 소속되어 있는것을 별로 좋아하지 않아요.) 하지만 모든 진행상황을 옆에서 다 전해 듣고 있자니 마냥 가만히 있을 수가 없어 이런 저런 조언을 해 주었고, 그러다 보니 (늦었지만) 이렇게 제작 후기까지 남기게 되었습니다.갑작스러운 참여초기 기획 단계부터 참여한게 아니였기에, 어느 정도는 정해져 있는 상태에서 작업 방향을 제시할 수 밖에 없는 상황이였습니다. 다행히도 제가 선호하는 GitHub Pages + Static Website 조합으로 블로그 framework이 결정 되었기에 제작 의뢰(?)를 좀더 수월하게 받아들일 수 있었습니다. 그럼에도 갑자기 뛰어든 만큼 여러가지 고민이 있을 수 밖에 없었고 빠르고 정확하게 의사 결정을 해야 했기 때문에 기존에 이미 결정된 사항들을 일부 바꾸면서 진행할 수 밖에 없었습니다. 그중에서도 가장 큰 부분은 framework을 변경하게 된 것인데, 제가 이런 결정을 하게 된 이유나 배경, 그리고 간략하게나마 Static Website 구성 방법에 대해 설명 해 보고자 합니다.일반적으로 우리가 많이 접하게 되는 웹 페이지들은, 특정 저장소에 있는 컨텐츠를 템플릿 웹 페이지에 얹혀서 화면에 뿌려주는 식으로 구성하게 됩니다. 이를 소위 dynamically generated site 라고 불리우는데, 이는 블로그와 같이 컨텐츠 위주의 웹 페이지를 구성함에 있어서 몇가지 불편함이 있습니다.첫째, 시스템 구성이 필요 이상으로 복잡해 집니다.기본적으로 화면에 보여주야 하는 웹 페이지를 위해서 웹 서버가 필요하고, 거기에 추가로 컨텐츠를 저장하기 위한 별도의 저장소가 필요하게 됩니다. 이 저장소를 위해서 작게는 별도의 파일을 이용할 수도 있고, 크게는 데이타베이스 서버를 별도 운용할 수도 있습니다. 무엇이 되었든 웹 서버와 컨텐츠를 제공하는 시스템 사이에 여러가지 상호관계를 생각하지 않을 수 없고, 이런 관리 포인트들이 하나 둘 늘어나는 것이 결국 웹 페이지를 지속적으로 유지하게 하는데 걸림돌이 될 수 있습니다.둘째, 새로운 컨텐츠를 추가하기가 번거롭 습니다.블로그 사이트는 글 특성상 컨텐츠에 스타일이 포함되어 있습니다. 그렇다는 것은 컨텐츠를 저장소에 저장할 때 단순 텍스트만 저장 할 수는 없다는 것입니다. 속성이 포함된 컨텐츠를 작성하기 위해서는 별도의 텍스트 에디팅이 필요하고 컨텐츠 추가를 위한 기능을 따로 구현해 두어야만 합니다. 게다가 HTML CSS 로 구성된 스타일은 자칫 글로벌