한 줄 요약

홈런을 노리며 크게 휘두르는 대신, 번트를 대보면 어떨까?

하이라이트

• 적은 투자로 쓰는 ‘번트’ 스타일의 블로그 글을 실험하고 있다.
• 프리랜서 에디팅 전략을 책을 읽은 사람 중심으로 조정하고 있다.
• 해커 뉴스 프론트 페이지에 오를 확률에 대한 내 직감이 크게 빗나갔다.

목표 달성 점수

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

Refactoring English 웹사이트에 새로운 독자를 끌어올 콘텐츠 발행하기

• 결과: “The Software Essays that Shaped Me”를 발행했고, 첫 3일간 1만 6천 명의 독자가 방문했다
• 성적: B+

목표는 달성했지만 글 하나에 너무 오랜 시간을 썼고, 최종 결과물도 기대에 살짝 못 미쳤다.

Refactoring English 새 챕터 발행하기

• 결과: 새로 발행한 챕터 없음
• 성적: F

새 챕터 초고는 썼지만 발행하지는 못했다. “The Software Essays that Shaped Me”와 프리랜서 에디팅 의뢰에 계획보다 많은 시간을 쓰게 됐다.

이전에 대화한 적 없는 독자 20명에게 개인화된 이메일 보내기

• 결과: 2명의 새로운 독자에게 이메일 발송
• 성적: D

더 이상 고객에게 연락해도 새로 배울 게 없다고 치부하려던 참이었다. 그런데 며칠 전 연락했던 한 독자로부터 내 책에서 배운 내용을 활용해 처음으로 해커 뉴스 프론트 페이지에 글을 올렸다는 답장을 받았다. 명백히 가치 있는 성과였고, 이런 아웃리치를 더 많이 해야겠다는 생각이 들었다.

이에 대해서는 아래에서 좀 더 고민해 보았다.

Refactoring English 지표

9월에는 웹사이트 방문자와 예약 판매가 모두 눈에 띄게 늘었다. 독자가 다른 독자를 끌어오는 선순환 구조를 만들고 싶지만, 아직 그 단계까지는 아닌 것 같다. 그래도 한 달에 거의 1천 달러를 벌었다는 건 기분 좋은 일이다.

번트 실험하기

야구에서 번트는 배트를 휘두르는 대신 공의 궤적에 배트를 갖다 대는 기술이다. 장점은 헛스윙할 확률이 낮다는 것이고, 단점은 공이 멀리 나가지 않는다는 것이다. 번트로 기대할 수 있는 최선은 1루까지 가는 것이고, 번트로 홈런을 치는 일은 거의 없다.

내 블로그 글 대부분은 ‘담장을 노리고 휘두르는’ 글이다. 해커 뉴스나 reddit, 검색 결과에서 1위를 차지하고 싶은 마음에 많은 노력을 들인다.

문제는 그런 ‘홈런을 노리는’ 글을 하나 쓰는 데 한 달가량 걸린다는 점이다. 그래서 책을 쓰면서 블로그 글을 쓰려면, 글 하나 쓸 때마다 책 집필을 한 달씩 멈춰야 한다.

그래서 ‘번트’성 글을 써보면 어떨까 고민하기 시작했다. 그러면 책을 한 달이 아니라 일주일 정도만 멈추면 될 테니까.

깊이 있게 다뤄야 할 주제를 대충 쓰는 건 원치 않는다. 오히려 쉽게 다룰 수 있는 주제를 골라 반응을 지켜보고 싶다.

나의 첫 번째 번트는 “I Once Appeared in The Old New Thing”이었다. 22살 때 첫 직장에서 겪은 경험에 대한 글이다. 특별히 통찰을 담을 내용은 없었지만 흥미로운 이야기라고 생각했다. 약 네 시간 만에 쓸 수 있었고, 그 자체로 완결성 있는 글이라는 느낌이 들었다.

다음 번트는 “The Software Essays that Shaped Me”였다. 다른 사람들이 좋아하는 소프트웨어 블로그 글을 모아 공유하는 걸 본 적이 있는데, 쉽고 재미있게 할 수 있겠다 싶었다. 무엇보다 좋은 소프트웨어 글쓰기를 좋아하는 사람이라면 내 책에도 관심을 가질 수 있을 것 같았다.

막상 “The Software Essays that Shaped Me”를 쓰기 시작하니 단순한 번트를 넘어서 버렸다. 결국 9월 거의 내내 이 글에 매달렸다.

처음에는 좋아하는 블로그 글 목록만 나열하고 끝낼 생각이었는데, 그건 너무 심심해 보였다. 그래서 각 글에 짧은 코멘트를 덧붙여 보기로 했다. 그러다 욕심이 생겨 원문보다 더 긴 코멘트를 쓰게 됐다. 흥미로운 코멘트가 무엇인지 찾기 위해 여러 번 고쳐 썼지만, 여전히 성공했다고 느끼지는 않는다.

결국 “The Software Essays that Shaped Me”에 17시간을 쏟아부었고, 이렇게까지 공을 들일 가치가 있는지 중간에 멈춰 판단하지도 않았다.

이 글은 내 블로그를 읽는 사람들에게는 흥미로울 거라 생각한다. 내가 아는 누군가가 자신에게 영향을 준 글 목록을 공유한다면 나도 흥미롭게 읽을 것 같다. 하지만 이 글의 댓글 스레드에서 다른 사람들이 공유한 목록을 보니, 모르는 사람의 목록은 전혀 흥미롭지 않았다. 코멘트에 공을 들여 어느 정도 보완은 했겠지만, 좋은 블로그 글 목록 자체가 그리 흥미로운 소재는 될 수 없다고 생각한다.

두 글 모두 성과는 좋았다. 둘 다 해커 뉴스 프론트 페이지에 올랐는데, 세컨드 찬스 풀을 통해서였다. 진짜 녹아웃이 아니라 TKO로 이긴 느낌이 든다.

흥미롭게도 결과는 들인 노력에 거의 비례했는데, 평소에는 그렇지 않은 경우가 많다.

영광의 순간을 허비하다

이전에는 내 Refactoring English 글이 해커 뉴스에서 잘 되면 책 구매로 이어지는 것이 눈에 띄게 늘었었다. 이번에는 “The Software Essays that Shaped Me”가 2위까지 오르고 11시간 동안 프론트 페이지에 머물렀는데도 구매는 단 한 건에 그쳤다.

해커 뉴스에서 내 글을 본 사람들은 이미 내가 책을 쓰고 있다는 걸 알고 있어서, 관심 있는 사람은 이미 구매했을지도 모르겠다.

다음 날 아침 일어나 보니 기사는 이미 해커 뉴스 프론트 페이지에서 내려와 있었고, 그때서야 깨달았다. 책 광고를 넣지 않았다는 것을!

책 웹사이트의 샘플 챕터에는 모두 이 주제에 대한 책을 쓰고 있고 얼리 액세스를 구매할 수 있다는 작은 자체 광고가 들어간다.

블로그 글에 그 자체 광고를 넣는 걸 깜빡한 탓에, 처음 1만 4천 명의 독자는 내가 책을 쓰고 있다는 사실조차 모른 채 글을 봤다. 이런!

앞으로는 절대 광고를 빼먹지 않도록 블로그 템플릿을 수정해 두었다.

프리랜서 에디팅 방식 조정하기

몇 달 전, 다른 개발자들이 블로그 글쓰기를 개선할 수 있도록 돕는 프리랜서 에디팅 서비스를 시작하기로 했다. 책에서 설명하는 방식이 실제 사람들에게도 통하는지 확인하려는 의도였다.

단점은 에디팅에 비용이 많이 든다는 점이다. 한 건당 4~7시간이 걸리고, 그날의 ‘깊게 생각하는 시간’을 거의 다 써버려서 같은 날 내 글을 쓰기가 어렵다. 아무도 서두르라고 한 적은 없지만 빨리 피드백을 줘야 한다는 압박도 느낀다. 내 글쓰기 과정을 생각하면 피드백을 며칠씩 기다리는 게 얼마나 답답한지 잘 아니까.

처음에는 계획대로 에디팅이 책에 대한 좋은 아이디어를 줬다. 하지만 일을 많이 할수록 책에 도움이 되는 아이디어는 점점 줄어든다. 이제 내가 쓰는 피드백 대부분은 이미 책에 써 둔 내용을 개인 맞춤형으로 다시 쓰는 것에 가깝다.

에디팅은 계속하고 싶지만, 오직 내 책을 읽은 저자만을 대상으로 하고 싶다. 그래서 요금을 두 배로 올려 블로그 글 한 편 에디팅 가격을 400달러로 책정했다. 다만 책을 읽은 독자에게는 90% 할인을 제공할 예정이다.

90% 할인이라면 사실상 돈을 안 받는 것이나 마찬가지지만, 의뢰인도 어느 정도 비용을 부담해야 책임감을 느낀다고 생각해 약간의 금액은 받으려고 한다.

책을 읽지 않은 의뢰인도 계속 받겠지만, 책 집필 시간을 쓰는 것을 감수할 만한 가격을 받고 싶다. 400달러도 아직 낮을 수 있지만, 일단 지켜보려 한다.

왜 독자 아웃리치를 계속 미루게 될까?

독자 아웃리치 목표를 왜 계속 놓치는지 고민하고 있다. 겉보기엔 그리 어려워 보이지 않는데, 막상 가장 중요한 일처럼 느껴지지 않아 계속 미루게 된다.

하기 싫어서 미루는 일도 있지만, 독자 아웃리치는 사실 즐거운 일이다. 다양한 독자들이 무엇을 하고 있고 내 기법을 어떻게 활용하는지 보는 게 재미있다.

문제 중 하나는 독자에게 이메일을 보내는 데 시작 에너지가 많이 든다는 점이다. 다음과 같은 과정을 거쳐야 하기 때문이다:

1. 선결제한 독자 목록으로 간다
2. 웹사이트가 있는 사람을 찾는다 (그래야 개인화된 이야기를 할 수 있으니까)
3. 그들의 웹사이트를 읽으며 어떤 사람인지 파악한다
4. AI가 쓴 것처럼 보이지 않도록 문구를 신중하게 다듬어 이메일을 쓴다

미리 연락할 고객 목록과 웹사이트를 모아 두면 도움이 될 것 같다. 그러면 연락하고 싶을 때 매번 처음부터 시작하지 않아도 되니까.

Stripe로 구매 후 이메일을 보내는 번거로움

몇몇 Refactoring English 구매자들이 결제했는데 책 링크가 담긴 이메일을 받지 못했다며 혼란스러워하며 연락해 왔다. 결제는 Stripe로 처리하고, Stripe는 결제 완료 후 고객을 책 URL로 리다이렉트한다. 고객이 리다이렉트를 놓치거나 페이지를 북마크하는 걸 잊으면 책에 대한 접근을 잃게 된다.

고객이 책 링크를 찾을 수 없다고 할 때마다 Stripe에서 구매 후 이메일 설정을 찾아보다가 몇 분 만에 포기하고, 올바른 링크를 직접 이메일로 보내준다.

지난달에야 비로소 Stripe 문서와 포럼 글을 샅샅이 뒤져봤는데, 일회성 결제 완료 후 Stripe가 보내는 이메일을 커스터마이즈할 방법은 전혀 찾을 수 없었다. 내가 파악한 바로는 Stripe 웹훅을 수신할 자체 웹 서버를 띄운 뒤, 자체 이메일 제공업체를 통해 직접 이메일을 보내는 방법밖에 없다. Stripe가 결제 완료 이메일의 텍스트를 전혀 커스터마이즈할 수 없게 해뒀기 때문이다...

웹훅에 응답하는 웹 서버를 세팅하는 게 내게 그렇게 어려운 일은 아니어야 하지만, Stripe와 Buttondown, Netlify 함수를 엮는 코드를 작성해야 하고, 각각에 자잘한 함정과 버그가 있다. 특히 Stripe가 그렇다. 고객이 결제한 뒤 이메일이 발송되도록 만드는 데만 지금까지 약 10시간을 썼고, 아직도 제대로 작동하는지 확신할 수 없다.

지금까지 겪은 함정은 다음과 같다:

• Stripe의 Go 클라이언트 라이브러리는 정확히 하나의 Stripe 웹훅 API 버전과만 호환된다.
  • 아니, 문서에는 어떤 버전인지 나와 있지 않다. 실행해 보고 웹훅 실패를 통해 알아내야 한다!
• Stripe 계정을 최신 웹훅 API 버전으로 업데이트한 뒤 이전 이벤트에 대한 웹훅을 재전송해도, Stripe는 새 버전을 쓴다고 하면서도 여전히 이전 API 버전을 사용한다.
• checkout.session.completed에 대한 Stripe 웹훅 요청에는 문서에 나와 있음에도 실제로 line_items가 포함되어 있지 않다.
  • 즉, 별도의 API 호출을 하지 않으면 고객이 무엇을 구매했는지 알 수 없다는 뜻이라 꽤 번거롭다.
• Netlify는 HTTP 헤더 이름을 조용히 소문자로 변환하므로, Stripe-Signature: 헤더를 찾으려면 stripe-signature를 찾아야 한다.
• Stripe 웹훅 서명 시크릿은 Stripe API 키와 다르다.

사이드 프로젝트

시간대별 해커 뉴스 성공률 분석

아직 출시하지도 않았고 어떻게 활용할지도 모르겠지만, Hacker News Observer를 계속 만지작거리고 있다. 일단 데이터를 모으고 해커 뉴스에서의 성공에 대한 궁금증을 해소하는 데 활용하고 있다.

오랫동안 궁금했던 것 중 하나는 해커 뉴스 프론트 페이지에 오르기 더 쉬운 시간대가 있는지였다. 그래서 하루 동안 프론트 페이지에 도달하는 글의 비율을 집계해 봤다:

처음에는 성공률을 과다 집계하는 버그가 있는 줄 알았다. 내가 체감하는 해커 뉴스 제출 글 중 프론트 페이지에 오르는 비율이 12%보다 낮게 느껴졌기 때문이다. 그런데 최근 며칠간의 무작위 구간을 살펴보니 수치가 맞아떨어졌다. /newest를 보면 보통 프론트 페이지에 오른 스토리가 2~5개 정도 있다. 며칠 전 30분 구간에서는 제출 글의 27%가 프론트 페이지에 올랐는데, 놀라운 수치였다.

주말에는 제출 수가 적어 성공률이 훨씬 높을 거라 생각했다. 실제로 주말 글이 프론트 페이지에 오를 확률이 더 높긴 하지만, 생각보다 그 차이는 훨씬 작았다.

• 평일: 제출 글의 12.1%가 프론트 페이지에 도달한다.
• 주말: 제출 글의 13.2%가 프론트 페이지에 도달한다.

나는 평일 5% 대 주말 20% 정도를 예상했다. 주말에 제출하면 프론트 페이지에 오를 확률이 아주 조금 더 높을 뿐인데, 성공하더라도 독자 수는 훨씬 적으니 주말 제출의 매력이 떨어진다.

HN Popularity Contest에서처럼 데이터를 개인 블로그로 한정해 보고 싶다. 개인 블로그가 특정 시간대에 더 유리한지 궁금하기 때문이다.

마무리

무엇을 했나?

• “The Software Essays that Shaped Me” 발행
• “I Once Appeared in The Old New Thing” 발행
• “Get xkcd Cartoons at 2x Resolution” 발행
• Refactoring English 프리랜서 클라이언트 2명과 작업
• Refactoring English 구매자에게 구매 후 이메일을 보내기 위한 웹훅 핸들러 구축
• Hacker News Observer에 “시간대별 성공률” 기능 추가
• Jellyfin Roku 클라이언트 코드에 기여 시작
• AirGradient와 회사-커뮤니티 관계 개선에 대해 통화

배운 점

• 저투자로 시작한 글이 고투자가 되어 버리면 중단하는 것을 고려하라.
• Stripe에서는 구매 후 이메일을 커스터마이즈할 수 없다.
  • 고객에게 이메일을 보내려면 다른 여러 작업을 직접 해야 한다.

다음 달 목표

• 책을 읽은 독자를 위한 에디팅 할인 설정하기.
• 연락할 얼리 액세스 고객 목록 만들기.
• 책의 새 챕터 발행하기.