한 줄 요약

첫 번째 책 챕터를 공개했다.

하이라이트

• 책의 첫 챕터를 공개했고 반응이 만족스러웠다.
• 책 표지 디자이너를 고용하려던 시도가 실패했다.
• PicoShare에서 대용량 파일을 지원하는 방법을 찾은 것 같다.

목표 달성도

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

Refactoring English 두 챕터 완성하기

• 결과: 한 챕터를 완성하고 다음 챕터를 75%까지 진행했다.
• 평가: B

첫 챕터는 계속 고치고 싶은 부분이 나와 생각보다 오래 걸렸다. 일주일 정도 쉬면서 두 번째 챕터를 쓰다가 다시 돌아오니 오히려 도움이 됐다.

디자이너와 함께 Refactoring English 표지 디자인 완성하기

• 결과: 표지 디자인을 직접 하기로 결정했다.
• 평가: C

디자이너와 작업을 어느 정도 진행했지만 방향이 마음에 들지 않아 중단했다. 일단 직접 표지를 만들기로 했다.

Refactoring English 첫 챕터 완성에 대한 생각

내 책 Refactoring English의 첫 챕터를 공개했다. 챕터 제목은 “소프트웨어 튜토리얼 작성을 위한 규칙(Rules for Writing Software Tutorials)”이며, 수년간 튜토리얼을 따라 하며 잘한 점과 못한 점을 관찰한 경험을 바탕으로 썼다.

첫 챕터의 성공적인 반응

챕터의 반응은 기대했던 것 중에서도 높은 편이었다. 튜토리얼에 관한 규칙 모음이라 인터넷을 뜨겁게 달굴 거라고는 생각하지 않았지만, 잘 맞을 것 같았던 몇몇 사이트에서 꽤 괜찮은 반응을 얻었다.

• Hacker News: 375점, 10위까지 상승
• /r/programming: 159점, 당일 1위 달성(아마도?)
• Lobste.rs: 27점, 2위까지 상승

내가 주로 추적하는 지표는 메일링 리스트 구독자 수다. 글을 올린 다음 주에 245명의 신규 구독자가 늘었고, 책 구독자 총원이 31% 증가했다.

발행한 글을 어떻게 계속 개선해야 할까?

몇 년 전, Redis의 창시자인 Salvatore Sanfilippo는 프로그래밍을 잠시 멈추고 SF 소설을 썼다. 소설을 쓰는 동안 그는 이렇게 말했다.

글쓰기와 프로그래밍의 가장 뚜렷한 차이는, 한번 쓰고 편집하고 마무리된 소설은 대부분 그대로 변하지 않는다는 점이라고 생각한다.

Salvatore는 프로그래머가 소설가에게서 배워 앱이 완성된 후 핵심 로직을 다시 쓰려는 충동을 억제해야 한다고 말했다. 반면 나는 정반대의 교훈을 얻었다. 저자는 프로그래머처럼 더 반복적으로 책을 써야 한다는 것이다.

Refactoring English에서는 챕터를 거의 완성된 상태로 공개하되 독자 피드백이 글쓰기에 반영되도록 하려고 한다.

챕터가 계속 유동적인 상태로 공개되다 보니 지금껏 겪어보지 못한 문제가 생겼다. 댓글 스레드가 꼬이는 것이다. Hacker News와 Lobste.rs, reddit에서 댓글 작성자들이 “조건부 로직은 컴퓨터가 평가하게 하라(Let computers evaluate conditional logic)”는 내 주장에 반박했는데, 그 말이 맞는 것 같다. 가장 약한 부분이었기에 삭제했다.

문제는 그 토론을 읽는 사람이 내 글에는 없는 주장에 왜 사람들이 반박하는지 의아해한다는 점이다.

내가 생각한 최선의 해결책은 글 하단에 아직 책을 수정 중이라는 메모와 원본 링크, 주요 수정 사항 목록을 함께 넣는 것으로, 하단의 메모를 참고하면 된다.

어떻게 계속 독자를 찾아 피드백을 받을 수 있을까?

지금까지는 독자 피드백을 기반으로 반복 개선하려는 계획이 잘 작동하고 있는 것 같다.

첫 챕터로 공개한 내용 자체는 만족스럽지만, 수정에 도움이 될 만한 깊이 있는 비판도 독자들로부터 많이 받았다.

“좋아, 같은 채널에 미리보기 챕터를 계속 공유하면 되겠다”고 생각했다.

그러다 목차를 다시 살펴보고 첫 챕터를 공유했던 채널에 어울릴 다른 챕터가 없다는 걸 깨달았다. 그 사이트 대부분에는 “코드에 대한 글이 아니면 여기에 올릴 수 없다”는 명문화된 혹은 암묵적인 규칙이 있다. 예를 들어 /r/programming에서 내가 수동태를 왜 싫어하는지에 대해 열정적으로 쓴 챕터를 반가워할 가능성은 낮다.

떠오른 아이디어 중 하나는 다른 작가들을 위한 프리랜스 편집 일을 하면서 얻은 경험을 Refactoring English에 반영하는 것이다.

다만 ‘편집’이 내가 잘할 수 있는 일을 정확히 표현하는 것 같지는 않다. ‘에디터’라고 하면 사람들이 내가 대신 글을 다듬어 줄 거라고 생각한다. 내가 진짜 하고 싶은 건 글의 문제점을 짚어내고 스스로 개선할 수 있도록 원칙과 기법을 설명해 주는 일이다. 이걸 뭐라고 불러야 할지 모르겠다. 글쓰기 멘토링? 코칭?

어쨌든 관심이 있다면 연락해 달라. 블로그 글이나 문서, 소프트웨어 관련 글쓰기라면 무엇이든 도울 수 있다. 더 많은 독자를 끌어모으고 글을 더 매력적으로 만드는 방법을 알려줄 수 있다. 기본적으로 이 블로그에서 내 글쓰기 스타일이 마음에 든다면, 여기에 쓰인 기법을 그대로 전수할 수 있다.

• 2회 리뷰에 100달러를 받는다.
  • 비용에는 초안 검토와 내 피드백을 반영한 수정본 검토가 포함된다.
• 글은 최대 2,500단어까지 가능하다.
• 비용을 받는 주된 이유는 당신이 책임감을 가지고 임하도록 하기 위해서이므로, 100달러가 부담된다면 다른 방법을 찾을 수도 있다.

Reedsy에서 겪은 형편없는 책 표지 디자이너 고용 경험

11월에 책 작업을 하면서 스스로에게 전문적으로 디자인된 표지가 필요하다고 설득한 것이 작업에 방해가 됐다. 과정은 11월에 시작했지만 실제 작업은 12월에 이뤄졌다.

디자이너는 Write Useful Books 커뮤니티에서 여러 사람이 추천한 플랫폼인 Reedsy에서 찾았다. 대체로 비싸지만 값어치를 한다는 평이었다.

디자인 브리프를 작성해 원하는 내용을 담아 Reedsy의 디자이너 네 명에게 보냈다. 예산은 350~650달러로 적어냈다. 한 디자이너는 내 최대 예산보다 20% 높은 금액을 부르면서 “네, 해드릴 수 있습니다”라는 형식적인 답변만 보냈고 브리프를 읽었다는 흔적은 없었다. 다른 한 명은 예산이 너무 낮다며 거절했고, 한 명은 아예 답이 없었다.

유일하게 유효한 제안은 Gary에게서 왔는데, 350파운드(약 434달러)에 표지를 만들어 주겠다고 했다. 그는 브리프의 세부 내용을 언급한 성의 있는 메모를 보냈고, 포트폴리오에는 수십 개의 책 표지가 있었으며 Reedsy에서 평점 5.0 만점을 받고 있었다. 그는 한 달 일정을 제안하며 비용을 세 번에 나눠 내는 방식을 제시했고, 괜찮아 보여서 그를 고용했다.

Gary와의 작업

일주일이 지났지만 Gary에게서는 아무 소식이 없었다. 첫 번째 결제가 자동으로 청구된 뒤에야 초기 시안에 대한 예상 일정을 물었고, Gary는 다음 날 콘셉트를 보내주겠다고 했고 실제로 보냈다.

샘플 1은 괜찮아 보였지만, 내 브리프에서 언급했던 Beautiful Code를 너무 대놓고 베낀 느낌이었다. 나머지는 기대 이하였지만, 브리프에 더 시간을 쏟지 않은 내 탓이라고 생각했다.

콘셉트를 검토하면서 내가 전달하고 싶었던 건 신중하고 의도적인 작업이라는 이미지임을 깨달았다. 선 정원(zen garden) 샘플 6과 점토 틀 샘플 5가 방향성은 맞다고 느껴 그쪽을 더 발전시켜 보자고 했다. 돌을 조각하는 조각가 이미지를 제안했다.

또 일주일이 지나 Gary는 선 정원 아이디어를 살짝 변형한 시안을 보냈다. 조각가 콘셉트로는 끌과 원석이 나온 이미지를 시도했는데, 사진 속 돌은 전혀 조각되지 않은 상태라 신중한 작업이라는 느낌을 주지 못했다.

다음 주는 크리스마스였고, 12월 30일 마감일까지 프로젝트가 끝나지 않을까 봐 걱정되기 시작했다. Gary는 크리스마스 직전 월요일에 12월 27일에 복귀해 작업할 예정이니 일정대로 진행 중이라는 이메일을 보냈다.

27일이 다 가도록 Gary에게서 연락이 없자 곤란한 상황에 처했음을 깨달았다.

내 시간으로는 미국 동부 시간 금요일 오후 4시였지만 Gary는 영국에 있어 이미 업무 시간이 한참 지났다. Reedsy는 월요일 동부 시간 정오에 자동으로 결제할 예정이었다. Reedsy에서 청구에 이의를 제기할 수 있는 마지막 날은 청구 24시간 전이라 완성된 결과물을 받을 수 있는 영업일이 하나도 남지 않은 셈이었다.

Gary가 작업을 전달하지 않았으니 마지막 결제를 일주일 미뤄달라고 Reedsy 고객 지원에 요청했다. Reedsy는 Gary와 직접 해결해야 한다고 답했다. 다음 영업일까지 Gary의 답변을 기다리면 결제를 미루기엔 너무 늦는다고 설명했지만, Reedsy 지원팀은 그래도 Gary와 해결해 보라고 고집했다.

금요일 동부 시간 오후 5시에 Gary에게 이메일을 보냈고, 그는 “회사 근무 시간(corporate hours)”대로 일하지 않으므로 주말에 작업해 기한 내에 끝낼 수 있다고 답했다. 그는 호의로 내 결제를 미뤄주었지만 내가 Reedsy에 불만을 제기한 것에 대해 언짢아하는 듯했다.

반면 나는 가급적 정규 근무 시간을 지키려 하고 주말을 Gary와 함께 이 프로젝트를 급하게 마무리하는 데 쓰고 싶지 않았다. 월요일에 다시 확인했을 때 Gary는 두 콘셉트에 대한 업데이트를 보내왔지만 둘 다 꽤 평범했다. 하나는 누가 봐도 AI로 생성된 비현실적인 이미지였고, 다른 하나는 내가 요청한 톤을 전혀 살리지 못했다.

이미지가 AI로 생성된 것인지, 브리프에 명시한 라이선스 요건을 충족하는지 Gary에게 물었다. 그가 얼버무리자 프로젝트 취소를 요청했다. 이미 지불한 231파운드(약 287달러)는 그대로 가져가고 마지막 결제를 취소하며 프로젝트를 종료하자고 제안했고, 그가 동의해 그렇게 마무리됐다.

Gary에게 모든 항목에 3점을 줬다. 형편없다고 생각하진 않았지만 그냥 그저 그렇고 일정 소통이 미흡했다. 내 리뷰는 공개되어 있지만 Reedsy는 내가 3점을 줬음에도 Gary가 여전히 평점 5.0 만점에 리뷰 5개를 유지하고 있다고 표시한다.

직접 만든 책 표지

Gary와의 일을 정리한 뒤 직접 표지를 만들어 보기로 했다. Unsplash에서 찾은 로열티 프리 이미지를 활용해 조용하고 신중한 작업의 느낌을 담고 텍스트를 더했다.

아마추어처럼 보인다는 건 알지만, Gary의 작업에서 기대했던 만족도의 80% 정도는 충족한다. 게다가 이건 무료였고 한 시간밖에 걸리지 않았다. 일단 임시 표지로 생각하고 있다. 나중에 누군가를 고용하거나 더 시간을 투자하면 된다.

사이드 프로젝트

PicoShare에서 대용량 파일 지원하기

PicoShare는 인터넷으로 파일을 공유하기 위한 나의 미니멀하고 호스팅하기 쉬운 웹 앱이다. 몇 년 전에 만들었고 지금도 매주 사용하고 있다.

PicoShare에 대해 살짝 부끄러운 점은 대용량 파일에서 확장이 잘 안 된다는 것이다. 공유 CPU와 256MB RAM을 가진 VM에서 PicoShare는 약 1GB까지의 파일에서는 훌륭하게 작동한다. 1GB보다 큰 파일을 업로드하려고 하면 대개 RAM이 고갈되어 충돌한다. 하드웨어를 더 투입하면 해결할 수 있지만, PicoShare가 임의로 큰 파일의 업로드를 지원하면 좋을 것이다.

이 문제를 몇 번 파고들었는데, 내 강한 추측으로는 성능 문제의 원인이 PicoShare가 모든 파일 데이터를 SQLite에 저장하기 때문이다. 특이한 선택이지만, 이렇게 하면 파일 데이터를 포함한 앱의 전체 상태가 SQLite 데이터에 담긴다. 그래서 PicoShare가 엄청난 양의 데이터를 SQLite에 쓰려다 RAM이 고갈되어 죽는 것 같다.

SQLite의 스트리밍 I/O API를 사용하면 데이터베이스에 더 효율적으로 쓸 수 있을 것 같아 관심이 있었다. 하지만 PicoShare를 Go로 작성했고, 내가 쓰던 Go용 SQLite 드라이버는 스트리밍 I/O API를 지원하지 않았다.

운 좋게도 Nuno Cruces가 스트리밍 I/O를 지원하는 새로운 Go용 SQLite 드라이버를 공개했고, PicoShare를 그의 라이브러리로 포팅하는 걸 도와주겠다고 제안했다. 9월에 그와 함께 조금 작업했고 어느 정도 진전도 있었지만, 스트리밍 I/O를 사용해도 PicoShare가 여전히 대용량 파일에서 메모리를 고갈시킨다는 걸 알게 됐다.

Nuno는 파일을 나눠서 SQLite에 청크 단위로 쓰면 RAM 사용량을 줄일 수 있을 거라고 제안했다. 사실 현재 구현에서도 이미 그렇게 하고 있지만 스트리밍 I/O의 의미 체계가 달라서 섬세한 코드를 많이 다시 써야 했다. 그래서 그때 동력을 잃고 작업을 보류했다.

12월에 스트리밍 I/O 문제를 새로운 시각으로 다시 보니 청킹 문제가 생각보다 쉽다는 걸 깨달았다. PicoShare는 대용량 파일을 읽을 때는 RAM이 고갈되지 않고 쓸 때만 고갈됐다. 그래서 더 효율적인 스트리밍 API로 쓰기 부분만 다시 구현하면 됐다.

스트리밍 I/O로 파일을 청크 단위로 쓰는 것이 SQLite 기본 API로 구현했던 것보다 더 간단했다. 처음에는 SQLite 데이터베이스를 io.Writer 객체로 추상화하고 io.Copy로 데이터를 밀어 넣는 것이 가장 쉬운 방법이라고 생각했다. 하지만 이번에는 직접 쓰기를 수행하는 것이 io.Copy를 거치지 않고 더 쉽다는 걸 깨달았다.

스트리밍 I/O 버전은 제한적인 테스트에서는 안정적이었지만 더 광범위한 테스트가 필요하다. 문제는 집 업로드 속도가 형편없이 느리다는 것이어서, VNC로 원격 접속할 수 있는 데스크톱 OS를 fly.io에서 구동하는 방법을 모색 중이다.

마무리

무엇을 해냈나?

• “소프트웨어 튜토리얼 작성을 위한 규칙(Rules for Writing Software Tutorials)” 공개
• “if got, want: 더 나은 Go 테스트를 작성하는 간단한 방법” 공개
• 새 NixOS 시스템을 세팅했고 지난 한 달 동안 Windows를 전혀 사용하지 않았다.
• offlineimap을 설정해 이메일 로컬 사본을 보관하고 매일 스냅샷으로 백업한다.
• 내가 좋아하는 오픈소스 RSS 리더인 fusion(Go와 SQLite로 제작)에 몇 가지 기여를 했다.

배운 점

• 그래픽 디자이너 고용 시 교훈
  • 전문가를 고용하기 전에 직접 임시 버전을 만들어 본다.
  • 결제는 날짜가 아니라 프로젝트 마일스톤에 연동한다.
  • 디자이너가 AI 생성 이미지나 AI 보조 이미지 합성을 사용하는 것에 동의하는지 명확히 밝힌다.
  • 사진이나 폰트 같은 서드파티 에셋의 라이선스 정보를 반드시 확인해야 함을 명확히 한다.
    • 브리프에서 모든 에셋이 호환 가능한 라이선스를 가져야 한다고 명시했었다.
    • 계약자가 단순히 라이선스를 준수하는 에셋을 제공한다고 구두로 약속하는 것이 아니라 라이선스 정보를 직접 전달해야 한다고 명시하는 편이 더 좋았을 것이다.
  • 크리스마스 직후에 끝나도록 프로젝트 일정을 잡지 않는다.
  • Reedsy는 의뢰인보다 계약자에게 크게 유리하도록 경험을 편향시킨다.

다음 달 목표

• 2024년 연간 회고 블로그 글 발행하기.
• 책의 다음 챕터 완성하기.
• 독자 피드백을 반영해 튜토리얼 챕터 수정하기.

도움 요청

• 연락해 달라 - 글쓰기 도움을 위해 나를 고용하는 데 관심이 있다면.