한 줄 요약

완성된 책이 더 잘 팔릴까?

하이라이트

• Refactoring English가 역대 두 번째로 높은 월간 판매를 기록했다.
• 거의 완성된 초안과 완전히 완성된 책 중 어느 쪽을 사람들이 더 구매하는지 판매 데이터를 분석했다.
• 책 피드백 툴을 완성했다.
• 시간 추적을 위한 새로운 툴을 시험 중이다.

목표 달성 평가

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

Refactoring English 웹사이트 개선에 최소 5시간 투자하기

• 결과: 웹사이트 개선에 약 3시간 투자
• 평점: B-

웹사이트를 조금 개선했지만 아직 더 다듬을 여지가 있다.

Refactoring English 웹사이트에 순 방문자 3만 명 유치하기

• 결과: 순 방문자 1만 7,500명 달성
• 평점: B-

설계 문서(design doc) 챕터를 무료 발췌본으로 다듬어 공개했다. Lobsters와 Reddit에서는 반응이 좋았지만 Hacker News에서는 별 호응을 얻지 못했다.

설계 문서 챕터에 대한 긍정적인 반응이 놀라웠다. 보통 개발자들에게 설계 문서를 이야기하면 설계 문서 자체와 그와 관련된 모든 것을 싫어한다는 반응이 대부분이다. 그런데 이번 글의 댓글은 설계 문서 전반과 내가 제시한 권장 사항에 대해 신선할 정도로 우호적이었다.

독자 피드백 툴 완성하기

• 결과: 툴이 정상적으로 가동 중이다.
• 평점: A

한동안 거대한 AI 봉쇄(the great AI blockade)에 막혀 있었지만, 큰 기능을 더 잘게 나누는 방법에 대해 비판적으로 고민하고 코드 품질에 대한 집착을 내려놓으면서 돌파구를 찾았다. 이번 경우에는 완벽보다는 완성이 더 낫다.

Refactoring English 지표

6월은 초기 크라우드펀딩 론칭 이후 책 수익이 가장 높았던 달이었다. 방문자 증가는 설계 문서 관련 발췌본 덕분이었다.

마지막 8%는 얼마나 큰 차이를 만들까?

지난 몇 달 동안 Refactoring English 웹사이트에서는 내 책을 얼리 액세스에서 거의 완성 상태로 표시해 왔다. 거의 완성된 책에서 완전히 완성된 책으로 전환했을 때 판매에 어떤 영향이 있을지 궁금해 주간 판매량을 살펴보았다.

책을 완성으로 표시한 것이 주간 판매량에는 뚜렷한 영향을 주지 않았다. 하지만 일평균으로 보면 어떨까?

확실히 책을 완성으로 표시한 뒤 소폭 증가가 있었다.

특히 미국 독자들이 책을 완성한 뒤 더 높은 비율로 구매했는지도 궁금했다. 누군가 책을 구매할 때마다 이메일 알림을 받는데, 미국 가격으로 결제하는 고객의 판매 비중이 늘어난 것 같았지만 정확히 측정해 본 적은 없었다. 데이터로 확인해 보았다.

흥미롭다! 책을 완성한 것은 지역별 가격으로 구매하는 고객의 판매에는 영향을 주지 않았지만, 미국 달러(USD)로 결제하는 고객은 책 완성 후 3주 동안 20% 더 높은 비율로 구매했다.

최신 발췌본을 공개한 이후의 판매량은 수치를 크게 바꾸기 때문에 포함하지 않았다. 그 구간은 별도 카테고리로 다루어 보았다.

하지만 미국인이 내 독자 중 가장 큰 비중을 차지하므로 이 수치는 항상 다소 편향되어 있다. 방문자 수로 수익을 정규화하면 어떨까?

오, 이야기가 뒤집혔다. 방문자 수로 정규화하니 결과가 완전히 반대로 나타났다. 이제는 완성본과 미완성본에 대해 미국인 구매율이 동일하고, 오히려 미국 외 독자들이 완성된 책에 대해 방문자당 약 20% 더 많이 지출하고 있었다.

이 정보를 어떻게 활용해야 할지는 모르겠지만, 궁금증은 해소되었다.

독자들이 책 앱에 유용한 피드백을 남기고 있다

이전에도 독자들에게 책에 대한 피드백을 요청한 적이 있고, 일부 독자는 열정적인 피드백을 주었지만 그런 경우는 소수에 불과했다. 독자들이 책을 읽으면서 바로 메모를 남길 수 있는 웹 기반 피드백 앱을 만들면 재미있고 유용할 것 같았다. 일주일이나 이주 정도면 뚝딱 만들 수 있을 줄 알았다. 그리고 짧고도 긴… 두 달이 지나 마침내 가동하게 됐다!

피드백 툴을 공개한 지는 며칠밖에 되지 않았지만, 독자들이 더 많은 피드백을 남기도록 유도하는 효과가 있는 것 같다. 한 독자는 최근 책을 완독한 뒤 피드백 앱이 경험 중 가장 좋았던 부분 중 하나였다고 말해 기분이 좋았다.

15년 만에 다시 시간 추적 툴 사용하기

일 년에 한 번쯤 스스로에게 묻게 된다. 내 시간은 다 어디로 간 걸까? 이 질문은 프로젝트에 집중하고 있는데도 생각만큼 진도가 나가지 않을 때마다 떠오른다. 지난 몇 년간 이 질문을 스스로에게 던졌던 기록은 다음과 같다.

• 2022
• 2023
• 2025

이번에는 ‘시간 추적 툴을 써 볼까?’라는 생각이 들었다.

약 15년 전에 RescueTime이라는 시간 추적 툴을 써 본 적이 있다. 그리 유용하다고 느끼지는 못했지만, 몇 주 정도 계속 써 보며 지켜보기로 했다. 그러다 문득 이름 모를 회사가 내 화면에 뜨는 모든 창에 대한 데이터를 수집하도록 허용하고 있다는 사실을 깨닫고 바로 삭제해 버렸다.

RescueTime의 오픈소스 버전이 있으면 좋겠다고 생각하다가 ‘어, 분명 있을 텐데?’라는 생각이 들었다. 실제로 있었다. 이름은 ActivityWatch다. 오픈소스이며 개인정보 보호를 우선으로 한다. 모든 창과 브라우징 활동을 기록하지만 데이터는 모두 로컬 기기에만 남는다.

문제는 ActivityWatch가 RescueTime에 비해 훨씬 덜 다듬어졌다는 점이다. 타임라인이 대체 무엇을 보여주려는 건지 전혀 이해할 수 없었다.

ActivityWatch에 활동을 어떻게 분류할지 규칙을 지정하게 되어 있는데, 그 UI 역시 사용하기 어렵다고 느꼈다.

ActivityWatch를 포기하려다 ‘뭐, 데이터 수집 부분은 아마 제대로 작동할 거야. 내가 직접 프론트엔드를 바이브 코딩해 보면 어떨까?’라는 생각이 들었다.

그래서 직접 만들었고, 생각보다 꽤 쉬웠다. 지금은 커맨드라인 툴로 시작했지만 웹 앱으로 확장할 계획이다.

내가 만든 ActivityWatch 커스텀 프론트엔드를 사용하려면 앱 이름, 창 제목, URL을 기준으로 활동을 분류하는 설정 파일을 만든다.

- name: Book/Feedback Site
  rules:
    - url: "*refactoring-english-feedback*"
    - window_title: "*refactoring-english-feedback*"

- name: Book/Website
  rules:
    - url: "*refactoring-english-landing*"
    - window_title: "*refactoring-english-landing*"

- name: Book/Writing
  rules:
    - app: Zathura
    - app: Code
      window_title: "*refactoring-english*"
    - app: firefox
      window_title: "mtlynch/refactoring-english *"

그러면 출력 결과는 다음과 같이 나타난다.

$ go run ./cmd/app --config data/config.yaml
...
Book               1h34m   19.7%
  Feedback Site      48m   10.0%
  Writing            46m    9.7%

지금까지 데이터는 흥미롭지만, 가장 큰 과제는 모든 활동을 자동으로 분류하기가 어렵다는 점이다. 예를 들어 위키백과(Wikipedia) 브라우징에 대한 카테고리를 추가할 수 있지만, 그게 책을 위한 정당한 작업의 일환인지, 아니면 그냥 토끼굴에 빠져 갑자기 발명품에 의해 목숨을 잃은 발명가들에 대한 글을 읽고 있는 것인지 구분하기 어렵다.

마무리

무엇을 해냈나?

• Refactoring English 피드백 툴을 완성했다.
• 일관성과 EPUB 호환성을 위해 Refactoring English 전자책을 수정했다.
• Little Moments를 위한 데모 영상을 만들었다.
  • 여기에 들어간 우스꽝스러운 사진들이 꽤 마음에 든다.

배운 점

• 고객은 100% 완성된 책과 거의 완성된 책의 차이를 내가 예상했던 만큼 크게 신경 쓰지 않는다.
  • 독자들이 완성된 책을 더 높은 비율로 구매하는 것은 맞지만, 웹사이트 방문자 수를 통제하면 그 효과는 꽤 미미하다.

다음 달 목표

• Refactoring English에 대해 이야기하기 위해 팟캐스트 5곳에 제안하기.
• Refactoring English 웹사이트에 순 방문자 3만 명 유치하기.
• 얼리 액세스를 마무리하고 책의 1.0 정식 출시를 선언하기.