한 줄 요약

킥스타터에서 처음으로 펀딩에 도전한 달

하이라이트

• 첫 킥스타터 프로젝트를 론칭했는데, 킥스타터가 의외로 수월했다.
• 킥스타터 목표 달성은 어느 정도 순항 중이지만, 남은 3분의 2를 채우려면 창의적인 방법을 찾아야 한다.
• 4코어 ARM CPU / 24GB 클라우드 서버에서 돌릴 재미있는 서비스를 추천받고 있다.

목표 달성 평가

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

Refactoring English 블로깅 챕터 완성하기

• 결과: 블로깅 챕터 대신 커밋 메시지 챕터에 집중하기로 했고 기한 내에 완성했다.
• 성적: A

블로깅 챕터를 쓰던 중간에 커밋 메시지에 대해 쓰면 Hacker News, /r/programming, Lobsters 같은 개발자 중심 소셜 네트워크에서 공유하기 좋은 챕터가 되겠다는 생각이 들었다.

안타깝게도 해당 글은 Hacker News에서 크게 주목받지 못했고 /r/programming이나 Lobsters에서도 반응이 미미했다. 아쉽지만 충분히 예상했던 결과이기도 하다.

Refactoring English 사전 판매 시작하기

• 결과: 킥스타터에서 사전 판매를 시작했다
• 성적: A

킥스타터: 의외로 만족스러웠다

Refactoring English 사전 판매를 킥스타터에서 진행하기로 했다. 킥스타터를 써본 적이 없어서 꽤 고생할 각오를 하고 있었다.

내가 겪어온 ‘크리에이터 플랫폼’의 전형은 프로젝트를 돕기보다는 업셀링으로 돈을 짜내는 곳이었다.

다행히 첫 킥스타터 프로젝트 론칭은 의외로 수월했다. 비용을 지불하라는 요구를 한 번도 받지 않았다. 킥스타터는 크리에이터에게 업셀링을 강요해 수익을 내기보다, 프로젝트가 자금을 모을 수 있도록 도와 수익을 내는 식으로 인센티브를 잘 설계해 두었다.

서류 작성, 은행 정보 인증, 공개 페이지의 텍스트와 영상, 이미지 제작까지 킥스타터에서 작업한 시간은 모두 합쳐 6~8시간 정도였다.

이 프로젝트에는 킥스타터 모델이 잘 맞는다. 일반 사전 판매였다면 세 달이 지나 고객이 충분치 않다는 걸 알게 됐을 때 난처한 상황에 처했을 것이다. 세 달 동안 작업은 했는데 전액 환불을 해야 하는 상황이 되는 것이다. 킥스타터는 후원자들에게 ‘여정에 투자하는 것’임을 명확히 알려주는 점이 마음에 든다. 크리에이터는 최선을 다해 결과물을 만들어야 하지만, 일이 뜻대로 풀리지 않을 수도 있다는 가능성을 후원자도 받아들인다.

목표를 정하고 올-or-낫싱으로 진행할 수 있는 점도 좋다. 목표 금액을 5천 달러로 잡은 이유는 야심 차면서도 달성 가능해 보였고, 책을 출간한 뒤에도 1만~2만 달러 정도를 추가로 벌 수 있으리라는 희망을 줄 만큼 충분히 높은 금액이었기 때문이다. 목표에 미달해 아무것도 받지 못한다면 실망스럽겠지만, 이 아이디어에 대한 명확한 ‘아니오’라는 답을 얻었다고 생각하면 위안이 될 것이다.

단, 킥스타터 스팸은 예외…

킥스타터의 유일한 단점은 스팸이다. 수많은 스패머들이 킥스타터를 지켜보는지, 캠페인을 도와주겠다며 교묘한 사기 메일을 하루에 세 통씩 받는다. 처음에는 관심 있는 고객인 척 어설프게 접근한 뒤, 대화가 진행되면 돈을 받고 도와줄 ‘지인’을 소개하려 든다.

모금 현황: 지금까지의 경과

오늘 기준으로 킥스타터 프로젝트에 1,585달러의 후원이 모여 목표의 31%를 달성했다.

프로젝트는 금요일에 시작했고 이달 말에 종료되므로, 25일간의 모금 기간 중 6일째(24% 경과)이다.

타임라인의 24%밖에 지나지 않았는데 목표의 31%를 달성했다니 좋아 보이지만, 문제는 이미 쓸 수 있는 가장 좋은 카드를 다 써버렸다는 점이다. 책 메일링 리스트와 소셜 미디어, 그리고 이 블로그 하단의 작은 자체 광고를 통해 킥스타터를 알렸다.

그래서 이제 또 뭘 할 수 있을까?

아직 남아 있는 카드는 두 가지 정도가 떠오른다.

첫 번째는 Hacker News 메인에 오르는 것이다. 보통은 어려운 일이지만, 나는 자칭 전문가다. 이달 말까지 최소 한 번, 가능하다면 두세 번 정도는 해낼 수 있다는 자신감이 있다. 몇 가지 글감은 사실상 ‘번트’ 같은 것들이다. 1위를 차지하는 홈런급 글은 아니겠지만, 5시간 정도 들여 써서 Hacker News 10~20위권에 오를 만한 글들이다.

두 번째 아이디어는 공개 글쓰기에 투자를 많이 하는 기업들에 연락해 프로젝트 후원에 관심이 있는지 타진해 보는 것이다. 기업 후원을 받은 책은 본 적이 없어서 어쩌면 나쁜 아이디어일 수도 있지만, 가능성은 있어 보인다.

사이드 프로젝트: 취미용 클라우드 서버에서 뭘 돌려볼까?

최근 무료로 4코어 ARM CPU / 24GB RAM Oracle Cloud 서버를 하나 얻었다. 문제는 이 제법 쓸 만한 서버가 99% 가까이 놀고 있다는 점이다.

지금까지 설치한 것은 다음과 같다.

• Woodpecker CI — 아직 상용 CI 중 Codeberg를 지원하는 곳이 없기 때문에 Codeberg에 올려둔 프로젝트에 유용하다
• Snowflake proxy — 검열 우회를 돕기 위한 것이다

서버에서 돌릴 재미있는 것들에 대한 추천을 받고 있다. 기준은 다음과 같다.

• 시간이 날 때 운영하면 재미있지만, 시간을 강요하는 의무가 되지 않는 서비스였으면 한다.
  • 포럼이나 채팅방처럼 관리에 시간을 써야 하는 것은 원하지 않는다.
• 내가 지지하는 일을 돕는 자발적 컴퓨팅(volunteer computing) 프로젝트여도 좋다.
  • ArchiveTeam Warrior로 웹사이트를 Internet Archive에 아카이빙하고 싶었지만, ARM을 지원하지 않는다.
  • 자발적 컴퓨팅이라면 SETI@home처럼 컴퓨팅 자원을 기부하고 그 실행 과정을 지켜보는 것만으로도 운영자가 재미를 느낄 수 있는 것이었으면 한다.
• 오픈소스였으면 한다.
• Oracle이 내 서버를 날려버려도 누구에게도 피해가 없어야 한다.
  • 즉, 내 서버에 데이터를 저장한 사람이 데이터를 잃는 일이 없었으면 한다.
• 암호화폐 채굴은 하고 싶지 않다.

endlessh-go는 내가 찾는 것의 좋은 예시이며, 설치할 예정이다.

내 서버에서 돌릴 재미있는 프로젝트에 대한 제안이 있다면 댓글로 알려주거나 이메일로 보내 달라.

흥미로운 링크

• “Writing commit messages” — Simon Tatham
  • 내 글을 쓰기 전에 커밋 메시지 작성법에 대한 블로그 글을 많이 읽었는데, 이 글이 가장 좋았다.
    • 사실 다른 글들은 다 별로였고 Tatham의 글만 좋았다고 하는 편이 더 정확하다.
    • 다른 글들은 하나같이 중요하지 않은 스타일 문제(예: “제목은 반드시 명령형이어야 한다”)에 집중하거나, 이유를 설명하지 않고 지침만 내린다.
  • URL과 사이트 디자인만 보고는 저자가 대학생인 줄 알았는데, 커밋 메시지에 대해 이렇게 통찰이 깊다니 놀랐다. 더 찾아보니 저자는 PuTTY SSH 클라이언트의 제작자이며, 그냥 친구 서버에 모든 것을 호스팅하는 것을 좋아할 뿐이었다.
• “Programming without Pointers” — Andrew Kelley
  • Zig의 창시자인 Andrew Kelley는 “포인터 없이 프로그래밍하기”라고 부르는 스타일을 만들며 프로그래밍 실력의 정체기를 벗어났다고 말한다.
  • Kelley의 스타일은 앱의 상태를 하나의 struct로 표현하되, 그 struct가 앱에 필요한 다양한 데이터 타입을 담으면서도 어떤 타입도 포인터를 포함하지 않도록 하는 것이다. 최상위 struct는 배열이나 해시맵을 담을 수 있지만, 그 안에 저장되는 객체들은 포인터를 가질 수 없다.
    • 그의 groovebasin 프로젝트가 그 예시이다.
  • 그는 문자열 저장 예시를 든다. 문자열 배열은 포인터의 포인터가 되므로 저장할 수 없다. 대신 모든 문자열을 하나의 배열로 모으는 커스텀 구조를 만들고, 그 배열에 대한 인덱스 목록을 유지한다.
  • 이 기법의 장점:
    • 상태를 직렬화하고 역직렬화하기가 아주 쉽다. 직렬화는 struct의 바이트를 파일이나 네트워크 소켓에 그대로 덤프하는 것이고, 역직렬화는 파일 전체를 읽어 원래 struct로 다시 매핑하는 것이다.
    • 서로 다른 환경(예: Zig 백엔드와 WASM 프론트엔드) 간에 상태를 공유하기 쉽다.
    • 메모리 관리도 단순해진다. 최상위 struct의 각 필드에 대해 메모리를 해제하면 되기 때문이다. 자식 객체의 메모리를 해제하기 위해 리스트를 순회하거나 트리 구조를 탐색할 필요가 없다.
  • 이 기법이 놀라운 이유는 인덱스가 사실상 컴파일러 지원 없는 포인터처럼 느껴지기 때문이다. 이 제안을 무작위 사람에게서 들었다면 무시했을 텐데, Andrew Kelley가 똑똑한 사람이라고 생각하기 때문에 한번 시도해 보고 싶다.
• “Reviving an Old Kindle Paperwhite 7th Gen” — Hemant Kumar
  • eBay에서 30달러짜리 오래된 e-리더를 사서 나만의 대시보드를 만들고 싶어 안달이지만, 정작 뭘 표시할지는 아이디어가 없다.
• “If You Ever Stacked Cups In Gym Class, Blame My Dad” — Kit Fox
  • 어느 날 새벽 2시에 잠에서 깨 다시 잠들지 못해, 이 글을 읽고 컵 쌓기 영상을 보는 데 두 시간을 보냈다.

마무리

무엇을 해냈나?

• Refactoring English 사전 판매를 킥스타터에서 론칭했다
• “How to Write Useful Commit Messages”를 공개했다
• My Zig Configuration for VS Code를 공개하고 Zig dev flake를 만들었다
• Never Pay The First Bill에 대한 내 노트를 공개했다

배운 점

• 킥스타터에서 자금 모금은 의외로 수월하다.

다음 달 목표

• Refactoring English 킥스타터 목표인 5천 달러를 달성한다.
• Refactoring English의 블로깅 챕터를 공개한다.
• 3월 말까지 Hacker News 메인에 두 번 오른다.

도움 요청

• 킥스타터 프로젝트에 대한 제안이 있다면 — 스팸봇이 아니라면 — 이메일로 보내 달라.