한 줄 요약

끝나지 않은 작업들을 너무 많이 동시에 붙잡고 있습니다.

하이라이트

• 미완성 상태로 붙잡고 있는 작업 수를 줄일 방법을 모색합니다.
• 더 많은 얼리 액세스 독자들과 대화할 방법을 고민합니다.
• Gleam 언어의 한 설계 결정을 받아들이는 데 어려움을 겪습니다.

목표 달성도

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

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

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

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

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

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

• 결과: “매력적인 소프트웨어 릴리스 노트 작성법”을 공개했습니다.
• 평점: A

이 글은 Lobsters에서 좋은 반응을 얻었고 Hacker News에서도 반응이 좋았지만, 운영진에 의해 메인 페이지에서 내려갔습니다. Hacker News 이용자들이 마케팅에 초점을 둔 내용을 싫어해 신고한 것으로 추측합니다.

이전 어떤 챕터보다 유용한 피드백을 많이 받았습니다. 부정적인 피드백이 많았지만, 비판이 타당하다고 느껴 오히려 큰 도움이 되었습니다. 피드백을 반영해 글을 수정했고, 논의를 통해 두 개의 새로운 섹션(“제품을 간략히 소개하기”와 “숫자를 그래프로 바꾸기”)에 대한 아이디어도 얻었습니다.

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

• 결과: 화상 통화로 독자 3명을 만났습니다.
• 평점: D

목표에 한참 못 미쳤습니다. 한 달 내내 두 번의 통화만 잡은 것도 문제였지만, 진행한 통화에서 얼리 액세스 독자들의 참여를 끌어내지 못한 것도 문제였습니다.

Refactoring English 지표

지표가 돌아왔습니다!

예전에는 매달 재정을 공개했습니다만, TinyPilot을 매각한 뒤로는 보고할 만한 흥미로운 숫자가 없어 중단했었습니다. 이제 사전 판매가 진행되면서 다시 공유할 만한 숫자가 생겼습니다.

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

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

이 책을 쓰면서 효과를 본 전략 중 하나는 매일 최소 한 시간은 ‘어려운’ 글쓰기에 투자하겠다고 다짐한 것입니다. 즉, 그 한 시간 동안은 서식 작업이나 문법 검사, 교정을 하지 않는다는 뜻입니다.

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

문제는 쉬운 글쓰기 작업을 미루다 보니 거의 다 썼지만 문법 검사와 교정이 필요한 글이 쌓인다는 점입니다. 특히 지난달에는 미완성 상태의 글이 많았고, 무엇이 발행됐고 무엇이 아직 최종 편집이 필요한지 추적하느라 정신적인 에너지를 낭비하는 느낌이었습니다.

근본적인 문제는 계속 새로운 블로그 글을 시작했다는 점인 것 같습니다. 간단한 해답은 아마 미완성 글이 남아 있을 때는 새 글을 시작하지 않는 것인지도 모릅니다.

얼리 액세스 독자들과 더 많이 대화하려면 어떻게 해야 할까?

Refactoring English를 집필과 동시에 판매하는 것의 장점 중 하나는 미완성 책을 기꺼이 사전 주문하는 사람들이 평균적인 독자보다 특히 열정적일 가능성이 높다는 점입니다. 제 계획은 얼리 액세스 독자들과 자주 대화하며 책이 그들의 궁금증을 잘 다루고 쉽게 이해되는지 확인하는 것이었습니다.

실제로는 독자들과 연결되는 데 어려움을 겪었습니다. 샘플 챕터에 대한 짧은 설문조사를 보내거나 답장으로 피드백을 보내 달라고 요청했지만, 메일링 리스트 구독자 약 1,400명과 사전 주문 고객 약 250명 중 겨우 두어 명에게서만 답을 받았습니다.

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

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

이를 바탕으로 독자들과 더 많이 대화하기 위한 아이디어를 정리해 봤습니다.

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

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

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

당장 할 수 있는 자잘한 마케팅 과제들을 떠오르는 대로 정리해 봤습니다.

• 웹사이트 개선하기.
  • 파비콘 추가하기.
  • 콜투액션이 메일링 리스트 가입이 아니라 얼리 액세스 구매가 되도록 UI 조정하기.
  • 얼리 액세스 페이지 개선하기.
    • 이미 “사전 주문”에서 “얼리 액세스”로 명칭을 변경했습니다.
  • 웹사이트에서 챕터 개수만 표시할 것이 아니라 어떤 챕터가 이용 가능한지 보여주기.
• 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에서 가장 적응하기 어려운 점 중 하나는 루프 없이 작업해야 한다는 것입니다. Gleam은 의도적으로 루프를 제공하지 않습니다. 대신 재귀 함수를 사용하거나 리스트의 각 요소에 대해 매핑 함수를 호출해야 합니다.

루프가 없는 것이 가장 문제가 되는 부분은 파싱을 위해 채팅 로그를 토큰으로 나누려고 할 때입니다. 제가 구분자로 다루는 문자는 [' ', '\n', '[', ']']입니다. 콜론도 구분자이지만, 뒤에 공백 하나가 따라오는 경우(': ')에만 해당합니다.

Go 같은 언어라면 for 루프로 문자열을 순회할 것입니다. 공백 문자를 찾으면 이전 문자가 :인지 확인해 : 케이스를 처리할 수 있습니다.

Gleam에서는 루프가 없으니 결국 이상한 결정 트리를 만들게 되고, 그 말단 노드들 중 상당수가 동일한 복잡한 함수 코드를 중복하게 됩니다.

Gleam의 많은 설계 결정은 흥미롭습니다. “Gleam다운 방식”으로 하면 우아하게 느껴지지만, 루프에 대해서는 필요한 도구를 빼앗긴 채 작업하는 느낌이 듭니다.

Gleam 실험은 계속할 예정이지만, Elixir나 OCaml도 한 번 시도해 보려고 합니다. 두 언어는 Gleam에서 마음에 들었던 많은 기능을 가지고 있으면서 제가 겪는 고충도 일부 해소해 주기 때문입니다.

마무리

무엇을 완료했나?

• “매력적인 소프트웨어 릴리스 노트 작성법” 공개
• “goHardDrive, 수천 명 고객의 개인정보 유출” 공개
• “Gleam 첫인상” 공개
• “Gleam에서 Elixir 라이브러리를 호출하는 간단한 예제” 공개
• Refactoring English 전자책에 세 개의 신규 챕터 집필
• 웹 발췌본으로 공개했던 기존 챕터 세 개를 전자책에 통합

배운 점

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

다음 달 목표

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