한 줄 요약

드디어 책을 쓰게 됐습니다!

하이라이트

• 책 사전 판매에 성공했습니다. 간신히요.
• 블로그 글을 여러 개 썼는데, 반응 예측은 영 틀렸습니다.
• 이제 책을 쓸 마크업 언어를 골라야 합니다.

목표 점검

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

Refactoring English 킥스타터 5,000달러 목표 달성하기

• 결과: 킥스타터에서 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

결과적으로 목표를 달성해서 다행이지만, 한 달 내내 다섯 개 아이디어가 모두 실패하면 얼마나 어리석어 보일까 걱정했습니다. 다행히 다섯 개 중 두 개가 성공했습니다.

책 사전 판매에 성공했습니다

한 달 대부분은 책이 망한 줄 알았습니다. 사전 판매가 5,000달러 목표에 1,500달러가량 미달할 흐름이었기 때문입니다.

사전 판매 종료 나흘 전, 제 블로그 글 하나가 Hacker News에서 주목을 받으면서 판매 흐름이 완전히 뒤바뀌었습니다.

결국 킥스타터에서는 6,551달러를 모으며 5,000달러 목표를 넘겼고, 마감 후 추가 주문까지 합치면 현재 6,701달러입니다.

사전 판매 과정에 대해 지난주에 더 자세히 썼습니다.

• My Book’s Pre-Sale Just Barely Succeeded

킥스타터에 대해서는 따로 글을 쓸 예정이지만, 전반적으로 아주 좋은 경험이었습니다. 책에 대한 관심을 가늠하기에 좋은 방법이었고, 6,500달러의 사전 주문 금액은 전통 출판사가 지급하는 선인세보다도 많은 액수였습니다.

줄리아 에반스 모델을 나에게도 적용할 수 있을까?

Refactoring English 사전 판매에서 가장 고무적인 점은 블로깅으로 생계를 꾸릴 수 있다는 희망이 보인다는 것입니다.

TinyPilot을 운영할 때는 블로그 덕분에 확실히 첫 수십 명의 고객을 확보할 수 있었습니다. 하지만 어느 순간부터는 개인 블로그가 판매에 전혀 도움이 되지 않는다고 느껴졌습니다. 생각해 보면 당연합니다. 인디 창업자의 일기에 관심 있는 독자가 굳이 400달러짜리 KVM over IP 장비를 살 이유는 없으니까요.

하드웨어 사업은 복잡해서 늘 시간이 부족했고, 하루 중 가장 집중이 잘 되는 ‘깊은 사고’ 시간을 개인 블로그에 쓰기가 어려웠습니다. 그 뒤로 저는 블로깅이 수익과 자연스럽게 연결되는 사업이 무엇일지 계속 고민해 왔습니다.

제 가설은 교육용 제품을 만들면 블로깅을 지속 가능하게 할 수 있다는 것입니다. 제가 하는 일을 글로 쓰고, 더 깊이 다룬 책이나 강의가 있다면 독자는 더 배울 수 있고, 그 수익으로 제 작업을 이어갈 수 있습니다.

블로그와 연계된 콘텐츠로 수익을 내는 가장 좋은 사례는 Julia Evans(줄리아 에반스)입니다. 그녀는 소프트웨어 블로그를 운영하면서 일러스트로 된 zine을 판매해 수익을 올립니다.

줄리아는 요즘 수익을 공개하지 않지만, 2019년 기준으로 zine으로 연 10만 달러 정도를 벌고 있었습니다. 그것도 블로그를 전업으로 하기 전, 부업으로 할 때의 수치였습니다. 물론 매출이지 순이익은 아니지만, zine이 디지털 제품이라 결제 수수료와 Gumroad 같은 플랫폼 수수료 정도만 빠지니 마진은 90~95%였을 것으로 추산됩니다.

부업으로 연 매출 10만 달러라면 정말 괜찮은 성과입니다. 전업으로 하면서 매출이 세 배가 됐다고 가정해 보겠습니다. 제가 그 절반만큼만 성공해도 블로깅과 관련 상품으로 연 15만 달러를 벌 수 있다는 계산이 나옵니다. 도전적이지만 충분히 가능해 보입니다.

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

3월은 블로깅 측면에서 흥미로운 도전이었습니다. 성공적인 블로그 글로 책의 고객을 찾아야 했기 때문입니다. 평소에는 마감에 쫓겨 글을 쓰거나 조회수를 최대로 끌어올릴 주제를 고르는 일이 거의 없어서 제게는 낯선 방식이었습니다.

주제 아이디어와 반쯤 써 둔 초안이 길게 쌓여 있었고, 다음 기준으로 후보를 평가했습니다.

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

점수를 매겨 정식으로 평가한 건 아니지만, 머릿속에서 대략 이렇게 가늠했습니다.

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

“No Longer My Favorite Git Commit”은 가장 유력한 아이디어라고 생각했습니다. 빠르게 쓸 수 있을 것 같았고, 원문이 워낙 인기 있었으니 잠재 독자도 많을 것 같았기 때문입니다. 결과는 Lobsters에서는 좋았고, reddit에서는 무난했으며, Hacker News에서는 실패했습니다. 이 글을 쓰려고 앉기 전까지는 몰랐는데, 존재 자체를 몰랐던 Google Discover에 글이 노출되면서 1만 5천 명의 독자가 유입됐습니다.

이 글은 제게는 조금 특이한 경우였습니다. 다른 사람의 글을 반박하는 글을 써 본 적이 없기 때문입니다. 쓰기 시작할 때는 원문에 대해 할 말이 많아 신이 났습니다. 그런데 초고를 마치고 나니 생각이 바뀌었습니다. 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로 옮긴 뒤로 개인 머신에서 더 많은 서비스를 직접 호스팅하는 게 즐거워졌습니다. 그중 가장 마음에 드는 건 Go, Svelte, SQLite로 만든 미니멀 RSS 리더인 fusion입니다.

fusion이 좋은 점은 메인테이너가 친절하고 코드 기여를 열린 마음으로 받아준다는 것입니다. 그래서 여유 시간에 작은 개선들을 보태고 있습니다.

가장 뿌듯한 기여는 pull 패키지를 리팩터링하고 테스트를 더 많이 씌운 일입니다.

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

계기는 If-Modified-Since HTTP 헤더 지원을 추가하려는 것이었지만, HTTP 요청을 시작하는 코드를 보니 수정하기가 어려웠습니다. 몇 가지 문제가 있었습니다.

• 코드가 너무 많은 책임을 한데 섞고 있었습니다. 데이터베이스 읽기, 피드를 언제 조회할지에 대한 로직, 외부 데이터 파싱, 결과를 다시 데이터베이스에 쓰는 작업까지 모두 뒤엉켜 있었습니다.
• 이 코드를 검증하는 자동 테스트가 없었습니다.
• 테스트를 작성하려면 이 코드를 실행하는 유일한 export 함수가 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 데이터베이스에 갇힌 레코드가 아니라 검색 가능한 일반 텍스트 파일이 됩니다.

사이트를 유지하는 데 비용이 들지 않고, 유지보수에도 1년에 5시간 정도밖에 쓰지 않아서 당장 종료할 급한 이유는 없습니다. 다만 가입은 이미 닫아 두었습니다.

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

흥미로운 링크

• Four years of running a SaaS in a competitive market - 경쟁이 치열한 시장에서 부트스트랩으로 회사를 운영하는 것에 대해 제가 읽어 본 최고의 글 중 하나입니다. Max가 공유한 교훈 대부분에 동의합니다. 부트스트랩 창업자로서의 제 경험에 비추어 봐도 모든 내용이 사실로 느껴집니다.

마무리

이번 달에 한 일

• “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를 출시했습니다

다음 달 목표

• 킥스타터에서 배운 점에 대한 블로그 글을 쓰기.
• 책의 새로운 챕터를 완성하거나 책 주제 중 하나로 라이브 세션을 진행하기.
• 공개 감사 인사나 블로그 글 첨삭 지원을 선택한 모든 킥스타터 후원자와 리워드 협의하기.

도움이 필요합니다

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