한 줄 요약

미완성 작업을 너무 많이 동시에 붙들고 있다.

하이라이트

• 동시에 붙들고 있는 미완성 작업 수를 줄일 방법을 모색한다.
• 더 많은 얼리 리더들과 대화할 방법을 고민한다.
• Gleam 언어의 한 설계 결정을 받아들이는 데 어려움을 겪는다.

목표 달성 평가

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

사용자가 더 쉽게 책을 사전 주문할 수 있는 방법 제공

• 결과: Kickstarter 사전 주문에서 Stripe 결제 링크로 전환했다.
• 평가: A

초기 사전 판매는 Kickstarter로 진행했기 때문에 이후 사전 주문도 그냥 그대로 유지하기로 했다. 몇 달이 지나고 나서야 Kickstarter에서는 책을 구매하려면 고객이 계정을 만들어야 한다는 사실을 깨달았다. 이 과정이 마찰을 크게 만들고 구매를 망설이게 한다.

Stripe로 전환한 것이 판매에 영향을 준 것으로 보인다. Kickstarter만 사용했을 때는 30일 동안 사전 주문이 7건에 그쳤지만, Stripe에서는 같은 기간 22건이 발생했다. 다만 Stripe로 바꾼 뒤 새로운 샘플 챕터를 함께 공개했기 때문에 완전히 동일한 조건에서의 비교는 아니다.

책 웹사이트에 새로운 샘플 챕터 공개

• 결과: “How to Write Compelling Software Release Announcements” 공개
• 평가: A

이 글은 Lobsters에서 긍정적인 반응을 얻었고 Hacker News에서도 반응이 좋았지만, 운영진에 의해 프론트 페이지에서 내려갔다. Hacker News 이용자들이 마케팅에 대한 강조를 탐탁지 않게 여겨 신고한 것으로 추측한다.

이 챕터에서는 이전 어떤 챕터보다 유용한 피드백을 많이 받았다. 부정적인 피드백이 많았지만, 지적이 타당하다고 느꼈기 때문에 오히려 실질적인 도움이 됐다. 피드백을 바탕으로 글을 수정했고, 논의를 통해 두 개의 새로운 섹션(“Briefly introduce your product”와 “Turn your numbers into graphs”)에 대한 아이디어도 얻었다.

최소 10명의 독자와 화상 통화로 만나기

• 결과: 3명의 독자와 화상 통화로 만났다.
• 평가: D

목표에 한참 미치지 못했다. 한 달 내내 두 번의 통화만 잡은 것도 원인이지만, 진행한 통화에서도 얼리 리더들의 참여를 끌어내지 못하고 있다는 점이 또 다른 문제다.

Refactoring English 지표

지표가 돌아왔다!

예전에는 매달 재무 현황을 공개했지만, TinyPilot을 매각한 뒤로는 공유할 만한 흥미로운 숫자가 없어 중단했다. 이제 사전 판매가 진행되면서 다시 공유할 만한 의미 있는 숫자가 생겼다.

방문자 수 증가가 판매 증가로 이어져 기쁘고, 특히 방문자 수보다 판매가 더 큰 폭으로 성장한 점이 더욱 반갑다. 이 추세를 유지할 수 있을지는 모르겠지만, 사람들이 책을 충분히 만족해서 다른 사람에게 추천하고 있다는 좋은 신호가 될 것이다.

어떻게 하면 동시에 붙들고 있는 초안을 줄일 수 있을까?

이 책을 쓰는 과정에서 효과를 본 전략 중 하나는 매일 최소 한 시간은 ‘어려운’ 글쓰기에 투자하겠다고 다짐한 것이다. 그 시간에는 서식 정리나 문법 검사, 교정을 해서는 안 된다는 의미다.

이 전략은 잘 통했다. 6월에는 내 커리어 중 어느 달보다 더 많은 글을 발행한 것 같다. Refactoring English 전자책에 세 개의 새로운 챕터를 추가했고, 샘플 챕터 하나를 새로 공개했으며, 이 블로그에도 세 개의 새 글을 썼다.

이 전략의 문제는 쉬운 글쓰기 작업을 미루다 보니 거의 다 썼지만 문법 검사와 교정이 필요한 글들이 쌓인다는 점이다. 특히 지난달에는 미완성 글이 많이 쌓였고, 무엇이 발행됐고 무엇이 최종 편집을 앞두고 있는지 일일이 기억하느라 정신적 에너지를 낭비하는 느낌이었다.

근본적인 문제는 계속해서 새로운 블로그 글을 시작했다는 점인 것 같다. 어쩌면 답은 간단하다. 미완성인 글이 남아 있을 때는 새 글을 시작하지 않아야 한다.

어떻게 하면 얼리 액세스 독자들과 더 많이 대화할 수 있을까?

Refactoring English를 집필하면서 동시에 판매하는 것의 장점 중 하나는, 미완성 책을 사전 주문하려는 사람들이 평균적인 독자보다 특히 열정적일 가능성이 높다는 점이다. 내 계획은 얼리 리더들과 자주 대화하면서 책이 그들의 궁금증을 해소하고 쉽게 다가가는지 확인하는 것이었다.

실제로는 독자들과 연결되는 데 어려움을 겪었다. 샘플 챕터에 대한 짧은 설문을 보내거나 피드백 답장을 요청했지만, 약 1,400명의 메일링 리스트 구독자와 약 250명의 사전 주문 고객으로부터 각각 몇 건의 응답만 받았다.

라이브 화상 세션을 시작했고, 강의, 글쓰기 워크숍, 오피스 아워, 인기 소프트웨어 블로그 글에 대한 북클럽 형식 토론 등 다양한 방식을 시도해 봤다. 라이브 세션 자체는 즐거웠고 참석자들은 훌륭한 피드백을 줬지만, 매번 참석하는 독자는 몇 명에 불과해 여전히 극소수의 독자에게만 닿고 있는 느낌이다.

또 다른 유용한 피드백 경로는 1:1 첨삭 피드백을 구매한 고객들이었다. 유료 고객은 세 명뿐이었지만, 그들과 작업하면서 타깃 독자들이 어떤 글쓰기 문제에 도움을 받고 싶어 하는지 알 수 있었다.

이를 바탕으로 독자들과 더 많이 대화하기 위해 다음과 같은 아이디어를 생각해 봤다:

• 구매 후 독자에게 개별적으로 연락해 책에서 무엇을 배우고 싶은지, 지금까지 기대에 부합하는지 물어본다.
• 글쓰기 컨설팅 페이지를 다듬어 더 매력적으로 만든다.
• 배우려는 의지는 있지만 비용이 부담되는 사람들을 위해 할인된 컨설팅 옵션을 제공한다.
• Hacker News에 계속 글을 올리지만 주목을 받지 못하는 이용자들에게 연락해 피드백 의뢰에 관심이 있는지 물어본다.
• “팀을 위한 초청 강연” 옵션을 제공해 직장 팀을 대상으로 글쓰기 주제를 발표하고 질문에 답한다.

책 마케팅을 어떻게 개선할 수 있을까?

미완성 블로그 글과 마찬가지로, 책을 마케팅하기 위해 하고 싶은 간단한 일들이 많지만 시간을 따로 내지 않다 보니 계속 머릿속만 차지하고 있다.

다음은 당장 해볼 만한 손쉬운 작업들을 브레인덤프한 목록이다:

• 웹사이트 개선.
  • 파비콘 추가.
  • 메일링 리스트 가입이 아니라 얼리 액세스 구매가 행동 유도 버튼이 되도록 UI 조정.
  • 얼리 액세스 페이지 개선.
    • 이미 “pre-order”에서 “early access”로 명칭을 변경했다.
  • 웹사이트에 챕터 개수만이 아니라 어떤 챕터가 이용 가능한지 표시.
• 1년 전에 녹음한 블로거 인터뷰 공개.
  • 원래 Hit the Front Page of Hacker News 리부트를 위해 녹음한 것이지만 결국 그 프로젝트를 보류했고, 인터뷰를 부탁해 놓고 계속 묵혀두고 있다는 사실이 계속 마음에 걸렸다.
• 웹에 공개된 발췌본을 전자책으로 옮기고 웹사이트에서 해당 챕터를 완료로 표시.
  • 대부분은 해뒀지만 작업이 너무 지루해서 미루게 됐고, 아직 웹 발췌본에는 있지만 전자책에는 통합하지 않은 챕터가 세 개 남아 있다.

Gleam으로 프로그래밍하며 소박한 for 루프가 그리워지다

올해 새로운 프로그래밍 언어를 배우려는 노력의 일환으로 Gleam을 실험하고 있다. 예전 AOL Instant Messenger 대화 기록을 파싱하는 데 사용하고 있는데, 기록은 이렇게 생겼다:

Session Start (DumbAIMScreenName:Jane): Mon Sep 12 18:44:17 2005
[18:44] Jane: hi
[18:55] Me: hey whats up
Session Close (Jane): Mon Sep 12 18:56:02 2005

Gleam에 대한 첫인상을 다룬 더 긴 글을 쓴 바 있고, 그 이후로도 몇 시간 더 프로그래밍해 봤다.

Gleam에서 가장 적응하기 어려운 점 중 하나는 루프 없이 작업해야 한다는 것이다. Gleam은 의도적으로 루프를 제공하지 않는다. 대신 재귀 함수를 사용하거나 리스트의 각 요소에 대해 매핑 함수를 호출해야 한다.

루프가 없어서 가장 곤란한 부분은 파싱을 위해 대화 기록을 토큰으로 나누려 할 때다. 내가 신경 쓰는 구분자는 [' ', '\n', '[', ']']이다. 콜론도 신경 쓰이지만, ': '처럼 뒤에 공백 하나가 오는 경우에만 해당한다.

Go 같은 언어라면 for 루프로 문자열을 순회하면서 공백 문자를 찾았을 때 이전 문자가 :인지 확인해 : 케이스를 처리했을 것이다.

Gleam에서는 루프가 없으니 결국 기묘한 결정 트리를 만들게 되고, 그 말단 노드들에서 같은 복잡한 함수 코드가 많이 중복된다.

Gleam의 많은 설계 결정은 “Gleam다운 방식”으로 하면 우아하게 느껴져 흥미롭지만, 루프에 관해서는 제대로 된 도구 없이 작업하는 느낌이 든다.

Gleam 실험은 계속할 예정이지만, Gleam에서 마음에 드는 많은 기능을 갖추면서도 내가 겪는 불편함을 해소해 주는 Elixir나 OCaml도 한번 시도해 보려고 한다.

마무리

무엇을 해냈나?

• “How to Write Compelling Software Release Announcements” 공개
• “goHardDrive Leaked Personal Data for Thousands of Customers” 공개
• “My First Impressions of Gleam” 공개
• “A Simple Example of Calling an Elixir Library from Gleam” 공개
• Refactoring English 전자책 버전에 세 개의 새로운 챕터 집필
• 웹에 발췌본으로 공개했던 기존 챕터 세 개를 전자책에 통합

얻은 교훈

• 이미 미완성 글이 있을 때는 새로운 블로그 글을 시작하려는 유혹을 참는다.
• 효과가 있는 방법에 더 집중해 독자와의 대화를 늘려야 한다.

다음 달 목표

• 이전에 대화한 적 없는 독자 최소 10명과 대화하기.
• 밀린 마케팅 아이디어 backlog 해소하기.
• Refactoring English의 새로운 챕터 공개하기.