Refactoring English: Month 5

Michael Lynch

Refactoring English: 5개월 차

한 줄 요약

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

하이라이트

  • 왜 책 집필이 생각만큼 속도를 내지 못하고 있을까?
  • Asciidoctor 집필·미리보기 워크플로를 최적화했습니다.
  • Hacker News 성과를 실시간으로 추적하는 사이드 프로젝트를 진행 중입니다.

목표 점검

매달 초에 이달에 이루고 싶은 목표를 정합니다. 이번 달 결과는 다음과 같습니다.

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

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

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

  • 결과: 라이브 세션을 진행하고 새 챕터 집필을 시작했습니다.
  • 성적: A

책을 사전 주문한 분들을 모두 라이브 수업에 초대했고, 세션 자체를 즐겁게 진행했습니다. 몇 년째 제 블로그를 읽어 온 분들 중 한 번도 대화하거나 메일을 주고받은 적 없던 분들을 만날 수 있었고, 질문 덕분에 책에 들어갈 내용을 다듬는 데 도움이 됐습니다.

Kickstarter 후원자 리워드 조율

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

제때 연락을 드리지 못한다는 생각에 스트레스를 받았습니다. 후원자 입장에서는 “후원해 준 사람들과는 대화도 안 하면서 왜 Kickstarter 얘기로 새로운 블로그 글만 쓰고 있지?”라고 느낄까 봐 걱정됐습니다. 하지만 75~150달러 패키지를 사전 주문한 분들에게 단체 메시지를 보내고 싶지는 않았습니다. 그 정도 금액이라면 개별적으로 답을 드리는 게 맞다고 생각했습니다.

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

책을 쓰며 시간 관리하기

매주 책 작업을 하고 있지만 진도가 느리게 느껴집니다.

진척도를 가늠하기가 어렵습니다. 어느 챕터를 끝냈고 어느 챕터가 남았는지는 알지만, 챕터마다 난이도와 분량이 크게 다르기 때문입니다.

또 하나의 문제는 같은 챕터를 끝없이 고쳐 쓸 수 있다는 점입니다. 어느 시점에서는 ‘이 정도면 됐다’고 판단하고 다음 챕터로 넘어가야 합니다. 특정 챕터를 언제까지 끝내야 한다는 압박이 없으니 계속 고쳐 쓰게 됩니다.

글을 쓴 지 한 시간쯤 지나면 효율이 눈에 띄게 떨어진다는 점도 있습니다. 기운이 빠지고 산만해지거나 중요하지 않은 데 과도하게 몰두하게 됩니다. 오전과 오후에 다른 주제로 쓰면 어느 정도 완화되지만, 그래도 각 세션에서 한 시간 정도가 지나면 힘이 빠집니다.

다행히 글쓰기 슬럼프나 동기 저하를 겪고 있지는 않습니다. 평일에는 매일 글을 쓰고 있고, 책에 대한 흥미도 여전합니다.

이런 점들을 고려해 앞으로 더 몰입해서 쓰기 위한 계획을 세워 봤습니다.

  • 하루 최소 60분은 몰입 상태로 글쓰기에 전념합니다.
    • 추가 조사가 필요하거나 서식을 고치거나 이미지를 넣어야 할 때는 흐름이 끊기지 않도록 TODO로 표시해 둡니다.
    • 지루해지더라도 이메일이나 소셜 미디어를 확인하고 싶은 충동을 참습니다. 글쓰기가 마음에 들지 않더라도 정해 둔 시간이 끝날 때까지 계속 씁니다.
  • 아침에 가장 먼저 하루 일정을 계획해 각 집필 작업에 얼마를 쓸지 정합니다.
    • 캘린더와 할 일 목록을 확인한 뒤 종이에 하루를 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 뷰어입니다. 실제로는 이렇게 동작합니다.

Asciidoctor, Zathura, Nix로 만든 셀프 핫 리로딩 PDF 워크플로

Hugo에서 익숙했던 거의 즉각적인 속도에 비하면 제가 만든 핫 리로드는 확실히 느리지만, 수동으로 하는 것보다는 5배는 편합니다.

사이드 프로젝트: Hacker News Observer

제가 가진 Hacker News 관련 특기 중 하나는 글이 왜 프론트 페이지에서 사라졌는지 대개 안다는 점입니다. 하지만 사실 HN Rankings라는 Hacker News 과거 데이터를 차트로 보여 주는 사이트를 알면 누구나 할 수 있습니다. 몇 가지 패턴만 알아보면 됩니다.

HN Rankings에서 가장 잘 보이는 것은 글의 순위가 갑자기 크게 오르거나 떨어지는 순간입니다. 천천히 3위까지 올라가던 글이 다음 측정 시점에 갑자기 45위로 떨어졌다면, 운영진이 해당 스토리를 인위적으로 순위를 낮췄을 가능성이 큽니다.

Hacker News 게시물의 순위가 갑자기 떨어졌다면 운영진이 수동으로 순위를 낮췄을 가능성이 큽니다.

차트를 보면 운영진이 스토리를 수동으로 끌어올린 경우도 알 수 있습니다. 300위 근처에서 헤매던 글이 갑자기 10위로 올라왔다면 운영진이 부스트한 것입니다. 일반 투표에서 프론트 페이지에 오르지 못한 스토리를 운영진과 자원봉사자가 직접 뽑아 올리는 세컨드 찬스 풀(second chance pool) 때문일 수도 있습니다.

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

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

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

제 글에 대한 더 자세한 데이터를 보는 것도 흥미로웠습니다. 예를 들어 “My $6k Advance as a Self-Published Author”에 대한 Hacker News 토론이 그렇습니다. 차트를 보면 이 글은 프론트 페이지에 오른 적이 없지만 추천을 계속 받았는데, 꽤 놀라운 일입니다. Hacker News 토론 링크를 어디에도 걸지 않았는데 어떻게 그런 일이 생겼는지 아직도 잘 모르겠습니다.

앞으로 추가하고 싶은 기능은 다음과 같습니다.

  • Hacker News가 한산한 날인지 프론트 페이지가 붐비는 날인지 자동으로 판단하기
  • 운영진이 부스트하거나 억제한 스토리에 자동으로 태그 달기
  • 초반 투표와 댓글 추이를 기반으로 스토리의 향후 궤적 예측하기

오랜만에 ‘빅데이터’ 프로젝트다운 프로젝트를 하는 느낌입니다. 제 사이트들은 보통 한 달에 1MB 정도 데이터를 생성하는데, HN Observer는 하루에 30~40MB를 생성합니다. 얼마나 많은 데이터를 수집하고 얼마나 자주 업데이트하느냐에 따라 양을 조절할 수 있습니다.

Hacker News 데이터 저장은 Turso를 써 보기에 좋은 기회로 느껴집니다. 멀리서 지켜보고만 있었는데, SQLite의 장점을 대부분 유지하면서 서비스 형태로 제공하는 데이터베이스인 것 같습니다.

DRM 없는 영화 구매하기

최근 친구에게 DRM이 없는 영화나 드라마를 합법적으로 구매할 수 있는 곳이 하나도 없다고 불평했습니다. 대형 스튜디오나 스트리밍 플랫폼이 DRM을 포기할 생각이 없다는 건 알지만, 작은 스튜디오나 인디 영화감독이라면 10달러에 4K DRM-free mp4를 판매하는 결제 페이지를 만드는 건 어렵지 않아 보입니다.

찾아보니 나름 비슷한 것이 있긴 했습니다. Vimeo on Demand에서 DRM 없는 영화를 판매하고 있습니다. 대부분 인디 영화나 비영어권 영화지만, 합법적으로 구매할 수 있는 DRM-free 영화 중에서는 제가 본 것 중 가장 많은 컬렉션입니다.

Vimeo on Demand는 제가 찾은 합법적인 DRM-free 영화 구매처 중 가장 큰 컬렉션입니다.

Vimeo on Demand를 직접 써 보니 경험은 그저 그랬습니다. 하지만 DRM 없는 영화를 파는 곳이 여기뿐이라 단서를 달아 추천하려 합니다.

구매하려는 작품이 다운로드를 제공하는지 꼭 확인하세요. 모든 작품이 다운로드를 지원하는 것은 아닙니다. 버튼에 “Stream anytime”이라고 표시되어 있으면 DRM-free가 아닙니다.

진짜 DRM-free 옵션을 나타내는 다운로드 옵션을 찾으세요. ‘Stream anytime’ 구매는 DRM-free도 아니고 다운로드도 불가능하니 피하세요.

실수로 구매한 뒤 취소하는 과정을 겪고 나니 Vimeo를 선뜻 추천하기가 더 꺼려졌습니다. 사람과 직접 대화할 수 있는 명확한 창구가 없습니다. 대신 챗봇과 대화해야 했는데, 챗봇은 “보안상의 이유”로 주문형 비디오 구매는 환불할 수 없다고 했습니다(제가 구매한 영상을 시청하지 않았다는 걸 확인하면서도 말입니다). 유일한 방법은 영화 배급사에 직접 연락해 환불을 요청하는 것이어서 그렇게 했습니다. 하지만 일주일 안에 답이 없으면 그냥 신용카드 차지백을 진행할 생각입니다.

Vimeo 이용 약관에는 구속력 있는 중재 조항이 포함되어 있어, Vimeo가 위법 행위를 하더라도 법원에 소송을 제기하거나 집단 소송에 참여할 수 없습니다. 중재인이 기업에 크게 유리한 판정을 내리는 경우가 많은데도 이런 조항이 미국에서 합법이라는 것 자체가 터무니없습니다. 구속력 있는 중재에서 탈퇴(opt-out)할 수 있어 저는 그렇게 했습니다.

마무리

무엇을 했나?

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

배운 점

  • 한 챕터에만 끝없이 매달리지 않도록 챕터별로 시간 제한을 둬야겠습니다. 시간 목표가 있으면 책 전체의 진행 상황도 더 잘 가늠할 수 있습니다.
  • Asciidoctor로 간이 라이브 리로드 흐름을 만드는 것은 생각보다 쉽습니다.

다음 달 목표

  • 사전 주문 독자에게 책 챕터 두 개를 공개합니다.
  • 모든 챕터에 유연한 집필 시간 제한을 둡니다.
  • 책의 미리보기 챕터를 Asciidoc으로 옮깁니다.

원문은 Michael Lynch님이 에 게재했습니다.

이 글은 muse-spark-1.2-contributor 모델을 사용해 번역했습니다.