한 줄 요약

매번 담장을 노리고 힘껏 휘두르는 대신, 번트를 대보면 어떨까?

하이라이트

• 적은 공수로 가볍게 써보는 스타일의 블로그 글을 실험하고 있습니다.
• 제 책을 읽은 분들과 주로 작업할 수 있도록 프리랜서 교정 전략을 조정하고 있습니다.
• Hacker News 전면 페이지에 오를 확률에 대한 제 직감은 크게 빗나갔습니다.

목표 달성 평가

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

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

• 결과: “The Software Essays that Shaped Me”를 발행했으며, 첫 3일 동안 독자 1만 6천 명을 끌어모았습니다
• 평가: B+

목표 자체는 달성했지만, 글 하나에 시간을 너무 많이 썼고 최종 결과물에도 다소 아쉬움이 남았습니다.

Refactoring English 새 챕터 발행하기

• 결과: 새로 발행한 챕터 없음
• 평가: F

새 챕터 초안은 썼지만 발행하지 못했습니다. “The Software Essays that Shaped Me”와 프리랜서 교정 의뢰에 계획보다 많은 시간을 쓰게 되었습니다.

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

• 결과: 새로운 독자 2명에게 이메일 발송
• 평가: D

독자에게 연락해도 더 이상 새롭게 배울 게 없다고 치부하려던 참이었습니다. 그런데 며칠 전 제가 연락했던 독자 한 분에게 답장이 왔습니다. 제 책에서 배운 내용을 활용해 처음으로 Hacker News 전면 페이지에 글을 올렸다는 내용이었습니다. 명백히 가치 있는 성과였고, 이런 시도를 더 해야겠다는 생각이 들었습니다.

이에 대한 고민을 아래에서 더 풀어보았습니다.

Refactoring English 지표

9월에는 웹사이트 방문자와 사전 예약이 눈에 띄게 늘었습니다. 독자가 다른 독자를 끌어오는 선순환이 만들어지길 바라지만, 아직 그 단계까지는 아닌 것 같습니다. 그래도 한 달에 1천 달러 가까이 수익을 낸 것은 기분 좋은 일입니다.

번트 실험하기

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

제 블로그 글 대부분은 ‘담장을 노리고 크게 휘두르는’ 글입니다. Hacker News나 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시간을 썼으면서도, 이렇게까지 공을 들일 가치가 있는지 중간에 멈춰 판단하지 않았습니다.

제 블로그를 읽는 분들에게는 이 글이 흥미로울 거라고 생각합니다. 제가 아는 사람이 자신에게 영향을 준 글 목록을 올리면 저도 흥미롭게 읽을 것 같습니다. 하지만 글에 달린 댓글에서 낯선 사람들이 올린 목록을 보니 전혀 흥미롭지 않았습니다. 코멘트에 공을 들여 그 한계를 어느 정도 보완했을지도 모르지만, 좋은 블로그 글 목록 자체가 그렇게까지 흥미로운 형식은 아닌 것 같습니다.

두 글 모두 성과는 좋았습니다. 둘 다 Hacker News 전면 페이지에 올랐지만, 세컨드 찬스 풀을 통해 오른 것이라 진정한 녹아웃보다는 TKO로 이긴 느낌이 듭니다.

흥미롭게도 결과가 들인 노력에 거의 비례했는데, 보통은 그렇지 않다고 느끼는 편입니다.

영광의 순간을 허비하다

이전에는 Refactoring English 관련 글이 Hacker News에서 잘 되면 책 구매가 눈에 띄게 늘었습니다. 이번에는 “The Software Essays that Shaped Me”가 2위까지 오르고 11시간 동안 전면 페이지에 머물렀는데도 구매는 한 건에 그쳤습니다.

Hacker News에서 제 글을 본 사람들은 이미 제가 책을 쓰고 있다는 걸 알고 있어서, 관심 있는 사람은 이미 다 샀던 걸까요?

글이 Hacker News 전면 페이지에서 내려온 다음 날 아침에 일어나 문득 깨달았습니다. 책 광고를 넣지 않았다는 것을요!

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

블로그 글에 그 자체 광고를 넣는 것을 잊어버려서, 처음 1만 4천 명의 독자는 제가 책을 쓰고 있다는 사실조차 모른 채 글을 보았습니다. 아뿔싸!

앞으로는 절대 잊지 않도록 블로그 템플릿을 수정해 두었습니다.

프리랜서 교정 방식 조정하기

몇 달 전, 다른 개발자들의 블로그 글쓰기를 돕기 위해 프리랜서 교정 서비스를 시작했습니다. 책에서 개념을 설명하는 방식이 실제 독자에게도 잘 통하는지 확인할 기회라고 생각했습니다.

단점은 교정에 들어가는 비용이 크다는 점입니다. 작업 하나에 네 시간에서 일곱 시간이 걸리고, 하루치 ‘고도의 사고력’을 다 써버려 같은 날 제 글을 쓰기가 어렵습니다. 아무도 재촉한 적은 없지만 빨리 피드백을 줘야 한다는 압박도 느낍니다. 제 글쓰기 과정을 생각해보면 피드백을 며칠씩 기다리는 게 얼마나 답답한지 잘 알기 때문입니다.

처음에는 계획대로 교정 일이 책에 좋은 아이디어를 주었습니다. 하지만 작업이 늘어날수록 책에 도움이 되는 아이디어는 점점 줄어듭니다. 이제 제가 쓰는 피드백 대부분은 이미 책에 써 둔 내용을 개인 맞춤형으로 다시 쓰는 것에 가깝습니다.

교정은 계속하되, 제 책을 읽은 분들에 한해 하고 싶습니다. 요금을 두 배로 올려 블로그 글 한 편 교정 비용을 400달러로 책정했습니다. 대신 책을 읽은 분께는 90% 할인을 제공할 예정입니다.

90% 할인하면 사실상 거의 무료나 마찬가지지만, 의뢰인도 어느 정도 비용을 부담해야 책임감을 느낀다고 생각해 일정 금액은 받으려 합니다.

책을 읽지 않은 분의 의뢰도 계속 받겠지만, 책 쓰는 시간을 내어줄 만한 가치가 있다고 느낄 만큼의 비용은 받고 싶습니다. 400달러도 아직 낮을 수 있지만, 일단 두고 보려 합니다.

왜 독자 접촉을 계속 미루게 될까?

독자 접촉 목표를 왜 계속 놓치는지 고민 중입니다. 겉보기에는 그리 어려운 일이 아닌데, 막상 가장 중요한 일처럼 느껴지지 않아 계속 미루게 됩니다.

다른 일들은 하기 싫어서 미루는 경우가 있는데, 독자에게 연락하는 일은 오히려 즐겁습니다. 다양한 독자들이 무엇을 하고 있는지, 제 기법을 어떻게 적용하는지 보는 것이 재미있습니다.

문제 중 하나는 독자에게 이메일을 보내는 데 꽤 큰 실행 에너지가 든다는 점입니다. 다음과 같은 과정을 거쳐야 하기 때문입니다.

1. 사전 결제 독자 목록으로 이동하기
2. 개인화된 이야기를 건넬 수 있도록 웹사이트가 있는 사람 찾기
3. 웹사이트를 읽으며 그 사람에 대해 알아보기
4. AI가 쓴 것처럼 들리지 않도록 문장을 신중하게 다듬어 이메일 작성하기

먼저 이메일을 보낼 고객과 웹사이트 목록을 미리 모아두면 도움이 될 것 같습니다. 그러면 연락하고 싶은 마음이 들 때 매번 처음부터 시작하지 않아도 됩니다.

Stripe로 구매 후 이메일 보내기의 번거로움

몇몇 Refactoring English 고객이 결제했는데 책 링크가 담긴 이메일을 받지 못했다며 혼란스러워하며 연락해 왔습니다. 결제는 Stripe로 받고 있으며, 결제가 완료되면 Stripe가 고객을 책 URL로 리디렉션합니다. 고객이 리디렉션을 눈치채지 못하거나 북마크를 깜빡하면 책에 접근할 방법을 잃게 됩니다.

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

지난달에야 마음을 먹고 Stripe 문서와 포럼 글을 샅샅이 뒤졌지만, 일회성 결제 완료 후 Stripe가 보내는 이메일을 커스터마이즈할 방법을 찾지 못했습니다. 제가 파악한 바로는 유일한 방법은 Stripe 웹훅을 수신할 웹 서버를 직접 띄운 뒤, 자체 이메일 제공자를 통해 이메일을 보내는 것뿐입니다. 판매자가 결제 완료 이메일의 문구 하나 바꾸지 못하게 해 놓은 Stripe 탓에 벌어진 일입니다…

웹훅에 응답하는 웹 서버를 세팅하는 것 자체는 저에게 그리 어려운 일이 아니지만, Stripe와 Buttondown, Netlify Functions를 엮는 코드를 작성해야 하고, 각각에 자잘한 함정과 버그가 있습니다. 특히 Stripe가 심합니다. 고객 결제 후 이메일이 발송되도록 만드는 데만 지금까지 10시간 정도 썼는데, 아직도 제대로 동작하는지 확신이 서지 않습니다.

지금까지 겪은 함정은 다음과 같습니다.

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

사이드 프로젝트

시간대별 Hacker News 성공률 분석

아직 출시하지도 않았고 앞으로 어떻게 할지도 정하지 못한 Hacker News Observer라는 제품을 계속 만지작거리고 있습니다. 당분간은 데이터를 모으며 Hacker News에서의 성공에 대한 궁금증을 해소하는 데 활용하고 있습니다.

오랫동안 궁금했던 것 중 하나는 하루 중 특정 시간대에 Hacker News 전면 페이지에 오르기 더 쉬운지였고, 그래서 시간대별로 전면 페이지에 오른 글의 비율을 집계해 보았습니다.

처음에는 성공률을 과대 집계하는 버그가 있는 줄 알았습니다. 제 체감상 Hacker News 제출 글 중 전면 페이지에 오르는 비율이 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에서는 구매 후 이메일을 커스터마이즈할 수 없다.
  • 고객에게 이메일을 보내려면 다른 여러 작업을 해야 한다.

다음 달 목표

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