저는 글쓰려고 Notion유료로 써봤고 Scrivener 구입도 하려 했었습니다. 지금은 VSCode와 github, 그리고 headless CMS인 hugo에 정착해 있는데, 툴의 종류와 그 경험, 그리고 현재 정착죽인 툴과 그 이유에 대해 이야기 해 보았습니다.
경험담
우선 저는 가상머신에서 작업을 많이 합니다. 특히 쓸만한 환경으로 세팅하기위해서 새로 설치했다가 지우고 다시 설정했다가를 반복하는데 , 로컬이 아닌 클라우드에 글을 저장하는 것은 매번 다운로드 받지 않아도 되기 때문에 매우 매력적으로 보였습니다. # 지금은 그렇게 생각하고 있지 않습니다.
또, 클라우드에 저장하게 되면 모바일 디바이스에 앱을 설치하여 작성하가나 하는 것도 가능했기 때문에, 디바이스 종류에 구애받지 않는 장점으로, 처음에는 이러한 방식의 글쓰기를 모색하고 있었습니다..
브라우저에서 작성하는 TiStroy, 브런치, Blogger, WordPress, DropBox Paper, Medium
글쓰는 패턴에 따라 좀 호불호가 나뉠 수 있겠습니다만, 주제는 가볍게 시작했다가, 어느 정도 진행을 하다가, 세부사항을 적는데, 저 하나의 주제에 그 자리에서 쭉- 집중하여 하나의 글을 완성해 내는 경우도 있지만, 다른 아이디어나 주제가 떠 올라 샛길로 빠지는 일도 많습니다.
그래서, 샛길로 빠지게 되면 제목만 적어두거나, 핵심 내용만 적어두거나, 코드만 적어두거나 하는 경우가 있습니다. 또는 곧 예정된 작업이 있어서 작성할 수 있는 시간이 부족하면 적을 수 있는 만큼 적어두다가 끝내야 하는 경우도 있습니다. 이런 때에는 현재의 페이지에서 다른 페이지로 페이지이동이 발생합니다.
이런 경우에 브라우저는 새로운 페이지를 랜더링하는데 시간을 필요로 합니다. 굉장히 빠른 컴퓨터라고 하더라도, 어느 정도(1초? 2초?) 의 시간이 발생하는데, 이 시간이 반복되면 마치 버퍼링이 있는 영화를 보는 것처럼 집중력을 떨어뜨립니다.
그렇기 때문에 뭔가 글을 작성할 때는 웹 페이지에서 직접 작성하는 것은 피하고 있습니다.
브라우저에서 작성하는 이 어플리케이션들은 저에게는 Out입니다.
Notion
Notion은 브라우저로 사용할 수 있습니다만, Single Web Application입니다. 즉 페이지를 새로 로딩하는 일이 없습니다. 또 Electron으로 만들어진 어플리케이션을 제공합니다. 즉 로컬에서 실행하는 데는, 브라우저에서 사용하는 것보다, 단축키, 설정면에서 약간의 편의가 제공됩니다. 물론 저장은 로컬이 아닌 클라우드에 저장됩니다. 새로 페이지를 만들기, 네비게이션하기, 검색도 편하게 잘 되어 있었습니다. 무료로는 사용할 수 있는 볼륨에 한계가 있어서, 1년 유료플랜으로 가입하여 사용한 적이 있습니다.
또 Notion은 글쓰기 플랫폼 자체를 제공합니다. 꽤 팬시한 페이지를 금방 만들 수 있습니다.
기타 임포트, 인터넷에 공개하기 등등의 부기능은 생략합니다.
그런데,
생각만큼 손에 착착 감기지 않는 겁니다. 딱히 문제가 없는데 그런 느낌이 듭니다. 그 알 수 없는 이유를 스스로 알아내는데에 상당한 시간이 걸렸습니다.
클라우드에 저장하는 읽어오는 것이기 때문에, 로딩, 네비게이션, 검색에 미묘한 랙이 있습니다. 이것은 웹어플리케이션에서 직접 글을 작성하는 것을 피하고 있는 이유와 같은 이유입니다.
Scrivener
작가로 활동하고 있는 어느 유투버의 소개로 써보게 되었는데, 작정하고 써 보면 괜찮았습니다. 또 어느 정도 효과를 봤기 때문에, 돈을 주고 어플리케이션을 구입하려고도 생각하고 있었습니다. 로컬에서 사용하는 어플리케이션이고, 검색도 편하고, 새로운 글을 작성하고 그 다음글, 그 전글로 이동하는 단축키도 제공하고 있었습니다.
사용하면서, 여러가지 글 쓰는 프로세스에 대한 팁을 많이 얻었습니다. 예를 들면 독자적인 글쓰는 순서가 정립이 되었는데,
- 제목을 정하고, 자료를 모으고, 생각을 정리한다 라는 틀이 잡히게 해주었습니다.
- 패러그래프는 완성되기 까지 조금 시간이 걸리는데, 패러그래프간의 네비게이션을 자유롭게 해 줄 수 있어서 약간 마인드맵과 같은 효과가 있습니다.
# 맥에서는 VSCode보다 글 내용에 더 집중할 수 있게 해주는 툴이었습니다.
# 윈도우즈 버전은 Trial기간이 지나도 계속 쓸 수 있는 버그(?)가 있었습니다.
Visual Studio Code
결국은 현재 VSCode를 사용하고 있습니다. VSCode가 처음 나왔을 때도, 버전업이 되어 가는 과정중에서도 사용해본 적이 있습니다만,
처음에 받았던 인상은 이러했습니다.
- 무겁고(이것도 Electron 어플리케이션입니다),
- 로컬어플리케이션인데도 불구하고 매크로를 작성하기도 어려웠습니다.
- 아니 몰랐습니다.
- 실은 지금도 모릅니다. 플로그인을 작성하는 방법 말고는.
- MarkDown 파일로 작성하는 것은 알겠는데, 이걸 CMS에 공개하는 것은 또 번거로웠습니다. # 이는 나중에 github에 commit하는 것만으로 Netlify에서 pull해 build하는 netlify.toml을 작성해 넣는 것으로 해결합니다.
현재의 결론과 팁
결론은 현재, VSCode, Markdown, Hugo, Github, Netlify의 조합입니다.
VSCode Extension
몇가지 시도해 볼 만한 Extensions를 소개합니다.
Hugo config.toml
newContentEditor
Hugo의 config.toml 안에서 선호하는 에디터를 다음과 같이 code로 설정해 둡니다. 이렇게 하면 hugo new 명령을 내렸을 때, 지정해둔 에디터가 실행됩니다.
# Set content editor
newContentEditor = "code"
간혹 hugo new 명령 뒤에 --editor="<your_editor>"를 지정해서 사용하기도 합니다.
저는 그냥 code안에서 shell을 사용합니다.
editURL
config.toml안에서 editURL은 `` 으로 표현되는 링크입니다. 만일 다음과 같이 github으로 설정해 둔다면, 이 링크로 이동하는 앵커를 보여줄 것입니다.
[params]
editURL = "https://github.com/matcornic/hugo-theme-learn/edit/master/exampleSite/content/"
이 파라메터를 이용하는 방법은
{ { .Site.Params.editURL } }
또는
<div class="github-link">
<a href="{{ (print (.Site.Params.editURL) (replace .File.Dir "\\" "/") (.File.LogicalName) ) | safeURL}}"><i class="fa fa-code-fork"></i>
{{T "Edit-this-page"}}</a>
</div>
를 이용해 링크를 출력하는 것이 가능합니다. 그런데, 다음과 같이 프로토콜을 vscode로 설정하는 방법도 있습니다.
[params]
editURL = "vscode://file/C:/Users/name/hugosite/content/"
이 방법을 사용하면 vscode가 실행되어 해당 폴더를 열게 됩니다.
shortcode를 이용해서 local에서 실행중인 경우에 한해서 동작하게 하면 좋을 듯 합니다.
Hugo용 Script
맥을 사용하시는 분들은 가끔 .zshrc에 쉘 스크립트를 정의하기도 하는 것 같습니다.
| |
저는 실제로는 PowerShell 모듈로 HugoModule을 만들어 쓰고 있습니다.
다시 결론
정착되었다고 해서 그대로 있는 것은 아닙니다. 지금도 불편하면 어떻게 개산할 방법이 있을까 고민하면서 써 나가고 있습니다. 아직 전문적인 환경은 아니지만, 그래도 고민한 흔적은 남기려고 하고 있습니다. 조금 더 깊은 부분까지 살펴, 함께 즐길 수 있으면 좋겠습니다.
