한 줄 요약

같은 챕터를 쉰 번씩 고쳐 쓰지 않으려면 어떻게 해야 할까?

하이라이트

• 왜 책 집필이 생각만큼 진척되지 않는 걸까?
• Asciidoctor 작성 및 미리보기 워크플로를 최적화했다.
• Hacker News 성과를 실시간으로 추적하는 사이드 프로젝트를 진행 중이다.

목표 달성 평가

매달 초에 이루고 싶은 목표를 정한다. 이번 달 목표 달성 결과는 다음과 같다:

Kickstarter에서 얻은 교훈에 대한 블로그 글 쓰기

• 결과: My $6k Advance as a Self-Published Technical Author 발행
• 평가: A

원래는 Kickstarter에 초점을 맞춘 가이드를 쓰려고 했지만, 쓰면 쓸수록 Kickstarter 자체가 흥미로운 부분은 아니라는 생각이 들었다. 자가 출판 작가에게 크라우드펀딩이라는 길이 더 흥미로웠고, Kickstarter는 그 방법 중 하나일 뿐이었다.

책의 새로운 챕터 완성 또는 책 주제에 대한 라이브 세션 진행

• 결과: 라이브 세션을 진행하고 새 챕터 작업을 시작했다.
• 평가: A

책을 사전 주문한 모든 분을 라이브 수업에 초대했는데, 세션이 즐거웠다. 몇 년 동안 내 블로그를 읽어온 분들을 직접 만날 수 있었지만 한 번도 대화하거나 이메일을 주고받은 적은 없었고, 질문들이 책 내용을 다듬는 데 도움이 됐다.

Kickstarter 후원자들과 리워드 조율하기

• 결과: 프리미엄 리워드를 구매한 모든 Kickstarter 후원자에게 연락했다.
• 평가: A

후원자들에게 제때 연락하지 못하는 것이 스트레스였다. 후원자들이 “왜 Kickstarter에 대해 새로운 블로그 글을 쓰면서 정작 후원한 사람들과는 소통하지 않느냐”고 생각할까 봐 걱정됐다. 하지만 대량 메시지를 보내고 싶지 않았다. 75~150달러 패키지를 사전 주문한 분들에게는 개인화된 답변이 마땅하다고 느꼈기 때문이다.

계속 이메일을 미루다가, 막상 쓰기 시작하니 모든 분에게 연락하는 데 두 시간 정도밖에 걸리지 않았다. 후원자가 웹사이트를 가지고 있거나 예전에 대화를 나눈 적이 있으면, 한 명 한 명 직접 쓰고 있다는 것이 드러나도록 메시지를 개인화했다.

책을 쓰며 시간 관리하기

매주 책 작업을 하고 있지만, 진척이 느리게 느껴진다.

진행 상황을 가늠하기가 어렵다. 어떤 챕터를 완료했고 어떤 챕터가 남았는지는 알지만, 챕터마다 난이도와 길이가 크게 다르기 때문이다.

또 다른 문제는 같은 챕터를 끝없이 쓰고 또 고칠 수 있다는 것이다. 어느 지점에서는 지금 수준으로 충분하다고 판단하고 다른 챕터로 넘어가야 한다. 특정 챕터를 언제까지 끝내야 한다는 압박이 없으면, 그냥 계속 고쳐 쓰게 된다.

또 한 시간 정도 글을 쓰고 나면 효율이 크게 떨어진다는 것도 알게 됐다. 기운이 빠지고 더 쉽게 산만해지거나, 중요하지 않은 것에 과도하게 매달리게 된다. 오전과 오후에 다른 주제로 쓰면 어느 정도 완화되지만, 어느 세션에서든 한 시간 정도 지나면 결국 기운이 빠진다.

다행히 글쓰기 슬럼프나 동기 저하는 겪지 않았다. 매일 업무 시간에 글을 쓸 수 있고, 여전히 책에 대한 열정이 있다.

이런 점들을 고려해 앞으로 더 집중해서 쓰기 위한 계획은 다음과 같다:

• 매일 최소 60분은 몰입 상태로 글쓰기에 집중한다.
  • 더 조사해야 하거나 서식을 고치거나 이미지를 추가해야 할 때는 TODO를 남겨 몰입이 끊기지 않도록 한다.
  • 지루해지더라도 이메일이나 소셜 미디어를 확인하고 싶은 충동을 참는다. 글이 마음에 들지 않더라도 해당 블록이 끝날 때까지 계속 쓴다.
    • 처음에는 LeechBlockNG가 도움이 됐지만, Firefox가 자주 멈추는 현상을 일으켜 사용을 중단했다. 알려진 이슈인 “LeechBlock doesn’t get along well with Firefox’s GC.”와 관련된 것으로 보인다. 작은 수정을 두 차례 제출했지만 별 차이가 없었다.
• 아침에 가장 먼저 하루 업무를 계획해, 각 글쓰기 작업에 얼마나 시간을 배분할지 정한다.
  • 캘린더와 할 일 목록을 확인한 뒤, 종이에 하루를 30분 단위 블록으로 나누어 계획한다.
• 각 챕터에 얼마나 글쓰기 시간을 할애할지 정한다.
  • 예를 들어, 독자들에게 초고를 보내기 전까지 이메일에 관한 챕터 집필에는 10시간만 쓰겠다고 미리 정한다.

목록 중 일부는 이미 하고 있어서 더 철저히 하려는 것이고, 일부는 생애 첫 책 집필이라는 과제에 대응하기 위해 새로 추가한 것이다.

Asciidoctor: 지금까지는 만족스럽다

지난달에 책 집필을 위한 다양한 마크업 언어 옵션을 평가한 글을 썼는데, Asciidoctor로 정착했다. 지금까지 만족하며 쓰고 있다.

Liran Tal의 asciidoc-book-starter를 출발점으로 삼아 Nix에 맞게 적용했다. 이제 Nix flake를 설정해 nix run을 실행하면 책이 PDF, epub3, HTML로 렌더링된다. nix run .#pdf 같은 명령으로 개별 형식만 렌더링할 수도 있다.

세 가지 형식을 모두 지원할지는 아직 모르겠다. 아직 커스텀 서식이나 이미지, 표 삽입도 시도해보지 않았으니, 세 형식 모두에서 레이아웃과 스타일을 맞추는 데 추가 작업이 얼마나 들지에 달려 있다.

Asciidoctor의 가장 큰 단점은 라이브 리로드를 할 수 없다는 것이다. Hugo로 글을 쓰는 데 익숙해서 VS Code를 한 창에, 렌더링된 결과를 브라우저 창에 띄워 놓고 작업한다. VS Code에서 저장만 하면 수백 밀리초 안에 브라우저에 반영된다.

Asciidoctor에서는 쓰기-빌드-확인 흐름이 이렇다:

1. 파일을 저장한다.
2. 터미널로 전환한다.
3. nix run .#pdf를 실행한다.
4. 브라우저 창으로 전환한다.
5. PDF를 새로고침한다.

이렇게 적고 보니 자동화해야겠다는 생각이 들어 LLM에 물어 간단한 스크립트를 받았다:

#!/usr/bin/env bash
set -euo pipefail

nix run .#pdf

zathura dist/Refactoring\ English.pdf &
ZATHURA_PID=$!

trap 'kill $ZATHURA_PID' EXIT

find book -type f \
  | entr -dr nix run .#pdf

zathura라는 프로그램은 처음 들어봤는데, 파일이 변경되면 자동으로 새로고침해 주는 오픈소스 PDF 뷰어다. 실제로는 이렇게 동작한다:

DIY 핫 리로드 흐름은 Hugo에서 경험하던 거의 즉각적인 성능보다는 훨씬 느리지만, 수동으로 하는 것보다는 5배는 편하다.

사이드 프로젝트: Hacker News Observer

나의 특별한 Hacker News 초능력 중 하나는 왜 어떤 글이 프론트 페이지에서 사라졌는지 대체로 안다는 것이다. 하지만 HN Rankings라는 Hacker News 과거 데이터를 차트로 보여주는 사이트를 안다면 누구나 할 수 있는 일이다. 몇 가지 패턴만 알면 된다.

HN Rankings에서 가장 잘 보이는 것은 글의 순위가 갑자기 크게 오르거나 떨어질 때다. 어떤 글이 천천히 3위까지 올라가다가 다음 틱에서 갑자기 45위로 떨어졌다면, 운영자가 수동으로 순위를 낮췄을 가능성이 크다.

차트는 운영자가 수동으로 글을 끌어올렸을 때도 드러낸다. 300위 근처에서 헤매던 글이 갑자기 10위로 뛰었다면, 운영자가 글을 부스트한 것이다. 아마도 정기 투표에서 프론트 페이지를 놓친 글을 운영자와 자원봉사자가 직접 선별하는 second chance pool 시스템 때문일 수 있다.

HN Rankings는 훌륭하지만, 순위와 함께 추천 수와 댓글 수도 보고 싶어서 직접 버전을 만들었다. 아직 공개하지는 않았지만, Hacker News API를 매분 폴링해 현재 Hacker News 스토리들의 메타데이터를 추적한다.

Hacker News 프론트 페이지에 있는 모든 스토리의 추천과 댓글을 시간에 따라 집계하면 어떤 패턴이 나타날지 늘 궁금했다:

가장 눈에 띄는 점은 매일 동부시간 정오쯤에 글의 평균 연령이 크게 떨어진다는 것이다. 그때 오래된 글들이 프론트 페이지에서 내려가고 새로운 글들이 자리를 차지한다.

내 제출 글에 대한 더 자세한 내용을 보는 것도 흥미로웠다. 예를 들어 “My $6k Advance as a Self-Published Author”에 대한 HN 토론이 그렇다. 차트를 보면 이 글이 한 번도 프론트 페이지에 오르지 못했지만 계속 추천을 받았는데, 놀라운 일이다. Hacker News 토론 링크를 어디에도 공유하지 않았는데 어떻게 이런 일이 일어났는지 아직도 잘 모르겠다:

아직 추가하고 싶은 기능은 다음과 같다:

• Hacker News가 한산한 날인지 프론트 페이지가 붐비는 날인지 자동으로 판단하기
• 운영자가 부스트하거나 누른 스토리에 자동으로 태그 붙이기
• 투표와 댓글 초반 흐름을 기반으로 스토리의 추세를 예측하기

오랫동안 해본 것 중 가장 “빅데이터”에 가까운 프로젝트다. 내 사이트 대부분은 한 달에 약 1MB의 데이터를 생성하는데, HN Observer는 하루에 30~40MB를 생성한다. 수집하는 데이터 양과 업데이트 빈도에 따라 늘리거나 줄일 수 있다.

HN 데이터 저장은 Turso를 시험해보기 좋은 기회처럼 느껴진다. 멀리서 지켜보고 있었는데, SQLite 사용의 장점을 대부분 유지하면서 제공하는 서비스형 데이터베이스 같다.

DRM 없는 영화 구매하기

최근 친구에게 합법적으로 DRM 없는 영화나 TV 쇼를 구매할 곳이 없다는 불만을 털어놓았다. 대형 스튜디오나 스트리밍 플랫폼이 DRM을 포기할 마음이 없다는 건 알지만, 작은 스튜디오나 독립 영화 제작자가 결제 페이지를 만들어 DRM 없는 4K mp4 영화를 10달러에 판매하는 것은 쉬워 보인다.

찾아보니 비슷한 것이 아주 없지는 않았다. Vimeo on Demand가 DRM 없는 영화를 제공한다. 대부분 독립 영화나 비영어권 영화지만, 합법적으로 구매할 수 있는 DRM 없는 영화 중 내가 본 가장 큰 컬렉션이다.

Vimeo on Demand를 직접 써봤는데, 경험은 그저 그랬다. 하지만 DRM 없는 영화를 파는 곳은 여기뿐이라, 몇 가지 단서를 달아 추천한다.

구매하려는 타이틀이 다운로드를 제공하는지 반드시 확인하라. 모든 타이틀이 그런 것은 아니다. 버튼에 “Stream anytime”이라고 쓰여 있으면 DRM 없는 것이 아니다:

이런 실수를 하고 구매를 취소한 경험 때문에 Vimeo 추천이 더 망설여진다. 사람과 직접 대화할 수 있는 명확한 옵션을 제공하지 않는다. 대신 챗봇과 대화해야 했는데, 챗봇은 “보안상의 이유”로 VOD 구매를 환불할 수 없다고 말했다(내가 구매한 영상을 시청하지 않았다는 것을 확인하면서도). 유일한 방법은 영화 배급사에 연락해 환불을 요청하는 것이어서 그렇게 했다. 하지만 일주일 안에 답이 없으면 그냥 신용카드 차지백을 할 생각이다.

Vimeo 서비스 약관에는 구속력 있는 중재 조항이 있어, Vimeo가 불법적인 일을 하더라도 법원에 소송을 제기하거나 집단 소송에 참여할 수 없다. 미국에서 이런 조항이 합법이라는 것 자체가 터무니없다. 중재인은 기업에 크게 유리하다는 점 때문이다. 구속력 있는 중재 조항에서 제외할 수 있어, 나는 그렇게 했다.

마무리

무엇을 했나?

• Refactoring English 라이브 세션을 진행했다.
• 프리미엄 리워드를 구매한 모든 Kickstarter 후원자에게 개별적으로 연락했다.

배운 점

• 책의 챕터마다 시간 제한을 두어 한 챕터에 매달리지 않도록 해야 한다. 시간 목표는 책 전체 진행 상황을 더 잘 파악하는 데도 도움이 된다.
• Asciidoctor로 즉석 라이브 리로드 흐름을 직접 만드는 것은 쉽다.

다음 달 목표

• 사전 주문한 독자들에게 책 챕터 두 개 공개하기
• 책의 모든 챕터에 유연한 집필 시간 제한 부여하기
• 책의 미리보기 챕터를 Asciidoc으로 옮기기