한 줄 요약

공식적으로 책을 쓰게 됐다!

하이라이트

• 책 사전 판매에 성공했다(아슬아슬하게).
• 블로그 글을 여러 개 썼는데, 반응을 예측하는 데는 영 젬병이었다.
• 이제 책을 쓸 마크업 언어를 골라야 한다.

목표 성적표

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

Refactoring English 킥스타터 $5k 목표 달성하기

• 결과: 킥스타터에서 196명의 후원자로부터 $6,701을 모금했다.
• 성적: A+

킥스타터는 예상보다 잘 됐고, 막판에 극적으로 뒤집었다.

Refactoring English의 블로깅 챕터 발행하기

• 결과: “How to Write Blog Posts that Developers Read” 발행
• 성적: A

이 글은 Hacker News와 Lobsters에서는 반응이 좋았지만 reddit에서는 그렇지 않았다.

3월 말까지 Hacker News 프론트 페이지에 두 번 오르기

• 결과: “How to Write Blog Posts that Developers Read”와 HN Popularity Contest 모두 프론트 페이지에 올랐다.
• 성적: A

목표를 달성해서 지금은 기분이 좋지만, 한 달 내내 다섯 개 글 아이디어가 모두 실패하면 얼마나 바보처럼 보일까 걱정했다. 다행히 다섯 개 중 두 개가 성공했다.

책 사전 판매에 성공했다

한 달 대부분 동안 책은 망한 것처럼 보였다. 사전 판매는 $5k 목표에 $1.5k 모자란 채로 진행되고 있었다.

사전 판매 마감 4일 전, 블로그 글 하나가 Hacker News에서 주목을 받으면서 판매 흐름이 완전히 뒤집혔다.

결국 킥스타터는 $6,551을 모금해 $5k 목표를 넘겼고, 마감 후 주문까지 합치면 현재 $6,701이다.

지난주에 사전 판매에 대해 더 길게 썼다:

• My Book’s Pre-Sale Just Barely Succeeded

킥스타터에 대해 따로 글을 쓸 예정이지만, 경험은 아주 만족스러웠다. 책에 대한 관심을 가늠하기에 좋은 방법이었다. 그리고 $6.5k의 사전 주문액은 전통 출판사가 선인세로 주는 금액보다 많다.

Julia Evans의 비즈니스 모델을 나도 만들 수 있을까?

Refactoring English 사전 판매에서 가장 신나는 점은 블로그로 생계를 꾸릴 수 있다는 희망이 보인다는 것이다.

TinyPilot을 운영할 때는 블로그가 첫 수십 명의 고객을 찾는 데 분명 도움이 됐다. 하지만 결국 내 개인 블로그는 매출에 전혀 도움이 되지 않는다고 느껴졌다. 인디 창업자의 일기에 관심 있는 사람이 꼭 $400짜리 KVM over IP 장비를 사고 싶어 하는 건 아니니 당연한 일이다.

하드웨어 사업은 복잡해서 늘 시간에 쫓겼고, 하루 중 가장 깊게 생각할 수 있는 시간을 개인 블로그에 쏟기 어려웠다. 그 이후로 나는 블로그가 사업 수익과 잘 맞물리는 사업이 무엇일지 계속 고민해 왔다.

내 가설은 교육용 제품을 만들면 블로그를 지속 가능하게 할 수 있다는 것이다. 내가 하는 일에 대해 글을 쓰고, 더 깊이 다루는 책이나 강의가 있다면 독자는 더 배울 수 있고 나는 그걸로 활동을 이어갈 수 있다.

블로그를 운영하면서 관련 콘텐츠를 팔아 수익을 내는 가장 좋은 사례는 Julia Evans다. 그녀는 소프트웨어 블로그를 운영하면서 일러스트 zine을 팔아 수익을 올린다.

Julia는 이제 수익을 공개하지 않지만, 2019년 기준으로 zine으로 연 약 $100k의 매출을 올리고 있었다. 그 $100k는 그녀가 블로그를 전업으로 하기 전의 수치였다. 물론 매출이지 순이익은 아니지만, zine이 디지털 상품이라 Gumroad 같은 결제·콘텐츠 플랫폼 수수료만 내면 되니 마진은 90~95% 정도였을 것이다.

그러니 사이드 프로젝트일 때 연 $100k 매출은 꽤 훌륭한 성과다. Julia가 전업으로 일하면서 매출을 세 배로 늘렸다고 가정해 보자. 내가 그녀의 절반만큼만 성공해도 블로그와 관련 상품 판매로 연 $150k를 벌 수 있다는 얘기다. 어렵겠지만 불가능하지는 않아 보인다.

생계가 달린 것처럼 블로깅하기

3월은 흥미로운 블로깅 도전이었다. 블로그 글을 써서 책의 고객을 찾아야 했기 때문이다. 보통은 마감에 쫓기거나 조회수 극대화를 위해 주제를 고르며 글을 쓰지 않는데 이번엔 달랐다.

써보고 싶은 주제와 반쯤 써둔 글 목록이 길어서, 다음과 같은 기준으로 평가했다:

• 작성 용이성: 얼마나 쉽게 완성도 있는 글을 쓸 수 있는가?
• 잠재 독자 규모: 이 글이 성공한다면 얼마나 많은 잠재 독자가 좋아할까?
• 성공 가능성: 이 글이 의도한 독자에게 도달할 가능성은 얼마나 되는가?
• 책과의 연관성: 독자가 이 글을 발견했을 때 내 책에 관심을 가질 가능성은 얼마나 되는가?

일일이 점수를 매기진 않았지만 머릿속 계산은 대략 이랬다:

결국 목록에서 상위 세 개를 골랐지만, 결과는 예상과 달랐다. 결과는 다음과 같다:

“No Longer My Favorite Git Commit”은 가장 강력한 아이디어라고 생각했다. 빠르게 쓸 수 있고 원본 글이 워낙 인기가 많아 잠재 독자도 많을 것 같았기 때문이다. 결과는 Lobsters에서는 잘 됐고, reddit에서는 그럭저럭이었으며, Hacker News에서는 망했다. 이 글을 쓰려고 앉기 전까지는 몰랐는데, 내가 존재조차 몰랐던 Google Discover에 글이 노출되면서 독자 15k명이 유입됐다.

이 글은 내게는 조금 이례적이었다. 다른 사람의 블로그 글에 반박하는 글을 써본 적이 없기 때문이다. 쓰기 시작할 때는 원본에 대해 할 말이 많아 신이 났다. 하지만 초고를 마치고 나니 생각이 바뀌었다. 6년 전에 쓴 글을 두고 굳이 다른 블로거를 공격하는 것처럼 느껴졌다. 어조를 다듬어 공격적인 느낌을 줄였지만 여전히 논쟁적으로 느껴졌다.

“How to Write Useful Commit Messages”는 사전 판매의 포문을 열 예정이었던 글이다. Lobsters와 reddit에서는 그럭저럭 반응이 있었지만 Hacker News에서는 망했다. 이 글이 매출에 얼마나 기여했는지는 가늠하기 어렵다. 이 글을 통해 사전 주문한 독자와 책 메일링 리스트 공지를 보고 사전 주문한 독자를 구분할 방법이 없기 때문이다.

“How to Write Blog Posts that Developers Read”는 책을 살린 의외의 히트작이었다. Lobsters에서는 그럭저럭이었고 reddit에서는 완전히 망했다. Hacker News에 처음 올렸을 때는 망했지만, 다음 날 아침 다른 사람이 다시 올리면서 엄청난 반응을 얻었고, 하루 순위 4위까지 올랐다. 무엇보다 Hacker News를 통해 글을 발견한 많은 사람들이 사전 판매 고객이 됐다.

Hacker News Popularity Contest

“Engineering as marketing”은 마케팅을 잘 못하는 엔지니어(예를 들면 나)에게 인기 있는 마케팅 기법이다.

아이디어는 유료 상품과 관련된 무료 도구를 만들고, 사람들이 무료 도구에 감탄해 유료 상품도 살펴보게 만드는 것이다.

나는 Hacker News 블로그 랭킹 시스템을 만들고 싶다는 생각을 오래전부터 해왔다. 다른 인기 Hacker News 필자들과 비교했을 때 내 위치가 궁금했기 때문이다. 지난해 여름 Hit the Front Page of Hacker News 강의를 다시 시작하려고 기본 프로토타입을 만들었다.

강의를 접고 Refactoring English에 집중하면서 이 블로그 랭킹 도구를 어떻게 할지 고민이었다. 3월이 되고 사전 판매를 반드시 성공시켜야 하는 상황에서, 프로토타입을 다듬어 공개하는 데 하루 이틀을 투자하면 되겠다는 생각이 들었다.

이 도구는 Hacker News 프론트 페이지에 오르는 데 성공했지만, 책 판매에는 아무런 영향을 주지 못했다.

예상치 못한 반응 중 하나는 상위 100위 안에 든 많은 사람들이 자신의 순위에 신경을 쓴다는 점이었다. Hacker News에서 가장 인기 있는 개인 블로거라면 이미 유명해서 Hacker News가 별 대수롭지 않을 거라고 생각했는데, 상위 100위 안에 든 많은 사람들이 공개 댓글이나 DM, 이메일로 순위에 대해 언급했다.

특히 상위 블로거들은 시간에 따른 순위 변화에 관심이 많아 보였다. 가장 대표적인 예가 John Gruber인데, 그는 내 도구가 최근 몇 년간 Hacker News가 자신의 사이트에 수동 패널티를 적용했다는 자신의 가설을 뒷받침한다고 느꼈다.

그런 반응을 보고 개별 블로그에 대한 더 자세한 통계를 볼 수 있는 기능을 추가했지만, 아직 그 기능에 대한 반응은 크지 않다.

책을 위한 마크업 언어 고르기

지금까지는 Hugo와 Markdown으로 책을 써왔다. 아직 공식 PDF 버전을 시작하지 않아 책 출판 기술을 고르는 일을 미뤄왔다.

이제 책 출간이 확정된 만큼 집필 방식을 정해야 한다. 관심 있는 기능은 다음과 같다:

• 도구가 PDF를 네이티브로 출력할 수 있는가?
• 도구가 epub을 네이티브로 출력할 수 있는가?
• 도구가 HTML을 네이티브로 출력할 수 있는가?
• 도구는 얼마나 성숙한가? 간단한 작업을 하다가 새로운 버그나 막다른 길을 만날 가능성은 얼마나 되는가?
• DRM-free 기술서를 내는 전통 출판사 중 이 포맷을 지원하는 곳이 있는가?
  • 초판은 직접 출판할 예정이지만, 2판에서 전통 출판사와 함께 종이책을 낼 수 있는 선택지가 있으면 좋겠다.

후보군은 다음과 같다:

보면 승자는 Asciidoctor나 LaTeX 중 하나인 것 같다.

AsciiDoc을 LaTeX로 변환해 주는 서드파티 도구도 있다. 재미있는 작업은 아니겠지만, No Starch가 내 책의 2판을 출판하고 싶다고 하면 한 번 정도는 변환 작업을 감수할 수 있을 것 같다.

Typst도 몇 시간 써봤다. 오픈소스이고 LaTeX보다 단순한 점은 마음에 들지만, 더 새롭고 덜 성숙한 도구를 쓸 만큼의 장점은 아니었다. 또 연구 논문 작성에 최적화되어 있고 책 집필에는 그다지 적합하지 않아 보였다.

사이드 프로젝트

fusion RSS 리더의 테스트 커버리지 늘리기

몇 달 전 NixOS로 갈아탄 뒤로 개인 머신에서 더 많은 서비스를 직접 호스팅하는 것이 즐거워졌다. 가장 마음에 드는 건 fusion이다. Go, Svelte, SQLite로 만든 미니멀 RSS 리더다.

fusion에서 가장 마음에 드는 점은 메인테이너가 친절하고 코드 기여를 열린 마음으로 받아준다는 것이다. 그래서 자투리 시간에 작은 개선들을 기여해 왔다.

가장 뿌듯한 기여는 pull 패키지를 리팩터링하고 테스트 커버리지를 늘린 것이다:

• pull 패키지 이전(v.0.8.9) vs. 이후(v0.9.3)

계기는 If-Modified-Since HTTP 헤더 지원을 추가하고 싶었던 것이었다. 그런데 HTTP 요청을 담당하는 코드를 보니 수정하기가 어려웠다. 몇 가지 문제가 있었다:

• 코드가 너무 많은 책임을 한데 섞고 있었다: 데이터베이스 읽기, 피드를 언제 조회할지에 대한 로직, 외부 데이터 파싱, 결과를 다시 데이터베이스에 쓰는 작업까지.
• 코드를 검증하는 자동화된 테스트가 없었다.
• 테스트를 작성하려 해도 이 코드를 실행하는 유일한 공개 함수는 Puller.PullAll이었고, 이 함수는 워커 풀까지 관리해서 복잡도가 더 높았다.

내가 한 주요 변경은 다음과 같다:

• HTTP 로직을 별도 파일로 옮겼다.
• RSS 파싱을 별도 파일로 옮겼다.
• 단일 피드를 조회하는 로직을 여러 워커를 관리하는 컴포넌트에서 분리해 단일 피드 로직을 테스트하기 쉽게 만들었다.
• 이 코드가 데이터베이스와 상호작용하는 더 단순하고 명확한 인터페이스를 만들어 테스트에서 데이터베이스를 모킹하기 쉽게 했다.
• 피드를 업데이트할지 결정하는 전용 함수를 만들어 업데이트 워크플로의 다른 부분과 뒤섞인 결정을 분리했다.

조금 더 다듬고 싶긴 하지만 지금까지의 진행에 만족하고, 덕분에 여러 버그를 고치고 fusion의 기능을 개선할 수 있었다.

What Got Done을 공식적으로 종료해야 할 때

2019년에 What Got Done이라는 웹 앱을 만들었다. 제대로 된 SaaS 사업을 해보려는 첫 시도였지만 고객을 찾지 못했다.

나는 아직도 매주 이걸 쓰고 있다. 매주 업데이트를 올린 지 5년째고, 꾸준히 쓰는 사람은 나뿐이다. 가끔 다른 사람들이 쓰기 시작해도 몇 주 지나면 질려서 그만둔다.

이 사이트는 웹 개발을 지금보다 훨씬 덜 알 때 만들었다. 원래는 Go, Vue 2, AppEngine, Google Cloud Firestore를 썼다. 이후 AppEngine을 fly.io로, Firestore를 SQLite로 교체해 개발이 조금 더 편해졌지만 여전히 Vue로 작업하는 건 괴롭다. Vue에서 바닐라 JavaScript로 점진적으로 옮길 좋은 방법을 모르겠고, 30시간 이상 걸릴 대규모 재작성에 투자하고 싶지도 않다.

최근에 이 사이트는 Hugo로 생성하는 정적 사이트로 만드는 게 더 낫겠다는 생각이 들었다. 원하는 에디터에서 주간 업데이트를 작성한 뒤 main 브랜치에 푸시하면 CI가 사이트를 빌드해 게시하는 방식이다. 지금 이 블로그가 그렇게 동작한다. What Got Done도 그렇게 하면 사용자 계정, 인증, 데이터베이스 관리 같은 복잡성이 많이 사라진다. 게다가 모든 업데이트가 SQL 데이터베이스에 갇힌 레코드가 아니라 검색 가능한 텍스트 파일이 된다.

사이트를 계속 운영하는 데 비용이 들지 않고, 유지보수에도 연간 5시간 정도밖에 쓰지 않는다. 그래서 당장 종료할 필요는 없지만 가입은 닫아 두었다.

언젠가 최근 사용자들에게 프로젝트 종료를 알리고 데이터를 내보낼 수 있게 안내하는 이메일을 보낼 것이다.

흥미로운 링크

• Four years of running a SaaS in a competitive market - 부트스트랩 회사를 만드는 것에 대해 내가 읽은 최고의 글 중 하나다. 나는 거의 모든 교훈에 동의한다. 부트스트랩 창업자로서의 내 경험에 비춰봐도 모든 내용이 사실로 와닿는다.

마무리

무엇을 해냈나?

• “No Longer My Favorite Git Commit” 발행
• “How to Write Blog Posts that Developers Read” 발행
• “My Book’s Pre-Sale Just Barely Succeeded” 발행
• 책 마케팅 도구로 Hacker News Popularity Contest 출시

다음 달 목표

• Kickstarter에서 얻은 교훈에 대한 블로그 글 쓰기.
• 책의 새로운 챕터를 완성하거나 책 주제에 대한 라이브 세션 진행하기.
• 공개 감사나 블로그 글 편집 도움을 선택한 모든 Kickstarter 후원자와 리워드 조율하기.

도움 요청

마크업 언어(즉, Word나 Google Docs가 아닌)로 책을 출판해 본 경험이 있다면 그 경험을 알려 달라.