4P by GN⁺ 8일전 | ★ favorite | 댓글 2개
  • Go 언어에 빠지게 된 계기와 책을 쓰게 된 개인적 여정 중심의 이야기임
  • 블로그 포스트 성공을 시작으로 Manning과 계약해 3년에 걸쳐 책을 완성한 경험담
  • 수많은 시행착오와 감정의 기복, 특히 편집 과정의 갈등이 생생하게 묘사된 글

Go 언어와의 첫 만남, 그리고 전환점

  • 2018년 스위스에서 Scala/Akka로 PoC 작업 후 Go 언어의 효율성과 간결성에 매료됨
  • 새로운 회사에서 Go를 활용하며 실무 경험 축적, 동료들이 같은 실수를 반복하는 것을 보고 블로그 글 작성 시작함
  • Medium에 올린 블로그 글이 예상외로 큰 반응을 얻으며, 글쓰기에 대한 자신감을 얻게 됨

책 출간의 시작: 아이디어에서 계약까지

  • 블로그 글의 연장선으로 100개의 Go 실수 사례를 수집해 책으로 확장하려는 계획 수립
  • Manning 한 곳에만 출판 제안서를 보내고, 간단한 이메일로 빠르게 긍정적 답변을 받음
  • 7명의 외부 리뷰어의 긍정적 피드백을 받아 2020년 12월 공식 계약 체결

집필 과정과 편집자들과의 협업

  • ‘최소 자격 독자(MQR)’ 설정 후 불필요한 기본 내용을 과감히 제거
  • 비기술적 편집자인 개발 편집자(DE)와 협업하며 글쓰기 기술 향상 경험
  • 반복적인 리뷰와 수정 과정을 통해 글을 10번 이상 고쳐 쓴 챕터도 존재함

외부 리뷰와 피드백 수용

  • 책은 3단계(1P, 2P, 3P)로 나뉘어 외부 기술 리뷰 진행, 점점 평점 향상
  • 1P: 13명 리뷰어, 평균 4.10점 → 2P: 4.15점 → 3P: 4.6점 달성
  • 피드백 수용 원칙은 “하나의 피드백이라도 무시하지 않는다”는 Bill Kennedy의 조언에서 옴

편집 과정에서의 큰 위기

  • 초반 지정된 기술 편집자(TDE)는 Go에 대한 기본 지식조차 부족해 불만 발생
  • 복잡한 교정 시스템과 협업 방식의 비효율성, 심지어 편집자가 오류를 대량으로 삽입함
  • 큰 좌절감에 작업 중단 선언, Manning이 빠르게 새로운 편집자를 배정해 문제 해결

완성까지의 여정과 출간 후 우울감

  • 모든 과정이 끝난 후 “끝났다”는 감정보다는 공허함이 밀려옴 (출간 후 우울증)
  • 3년 가까운 시간 동안 쏟아부은 에너지와 감정이 일순간 사라짐
  • 이후 점차 회복하며 자신이 만든 콘텐츠에 대한 자부심을 회복함

책의 성공과 커뮤니티 반응

  • 출간 직후 긴 홍보 없이 Reddit, Twitter 등에서 자발적인 공유가 일어남
  • 1년 후 오픈소스 사이트 100go.co를 통해 무료 요약 콘텐츠 제공
  • Manning 측에서도 좋은 반응, 향후 저자 지원 역할 제안도 받음

인세, 수익, 그리고 그 이상의 의미

  • 2024년 말 기준 영문판 11,452부 판매, 총 수익 약 $47,000 발생
  • 시간당 수익은 낮지만, 금전이 아닌 커뮤니티 기여와 개인 성취에 더 큰 의미 부여
  • Java, C++, SQL Server 등의 후속 시리즈에 영향 미침

마무리와 개인적인 다짐

  • Goodreads 평점 4.66으로 목표 초과 달성
  • 최고의 Go 책은 아닐 수 있으나, 당시 자신이 만들 수 있는 최고의 책이라는 확신
  • 2판 제안도 받았으며 독자 피드백을 기다리는 중임
Hacker News 의견
  • 리뷰 워크플로우를 PR 기반 설정에서 설명하고 개선 제안을 했지만, 상대방이 시도하지 않으려 했음. 협업 과정의 원활함과 효율성을 원했음
  • 카피 에디터가 웹 기반 리뷰 도구보다 git 사용에 더 익숙한 것이 놀라웠음. 특히 Go 책을 리뷰하면서 Go에 대해 잘 모르는 것 같았음
  • Manning의 카피 에디터가 있다는 것이 이상하게 느껴짐
  • Manning과의 부정적인 경험을 공유함. 책을 쓰고 있으며 자가 출판 중인데, Manning에 두 번째 판을 신청할 가능성을 문의했음. 그들은 제안을 거절했다고 답장했음
  • Google Docs만 문서 형식으로 언급했지만, 블로그 게시물에 따르면 AsciiDoc도 수용하는 것으로 보임
  • sync.Pool과 관련된 문제를 언급하며, 관련 링크를 공유함
  • Go의 표준 라이브러리에서 sync.Pool 사용을 살펴보면 다양한 크기의 tiered pools가 있으며, 큰 크기의 항목은 버리는 경우가 많음
  • DocBook으로 Manning에서 책을 썼던 경험을 공유함. 카피 에디팅 후 모든 내용이 한 줄로 돌아와 실망했음. 자가 출판으로 전환했음
  • O'Reilly와의 초기 접촉은 이메일로 시작했으며, 그들의 도구가 훌륭하다고 언급함. git 커밋에서 지원되는 형식의 전체 버전을 생성할 수 있음
  • 책의 형식이 북클럽에 적합하다고 언급함. 실수들이 좋은 토론 주제가 되었고, 경험 많은 사람들은 실수를 피한 방법을 공유했음
  • 책의 많은 "실수"가 Go의 일부 측면을 소개하는 것으로, "fuzzing 사용 안 함"과 "errgroup 사용 안 함"이 그 예임
  • Tim의 리뷰가 매우 가치 있다고 언급했지만, 리뷰에 대한 구체적인 설명이 없어 실망스러웠음
  • Manning의 다른 저자가 책을 칭찬하며, 실용적인 정보가 많다고 언급함. 새로운 Go 프로젝트를 시작하면서 다시 참조할 계획임
  • goroutine 관련 예제에 대한 질문을 제기함. goroutine을 사용하지 않고 함수 클로저를 만들면 동일한 'i' 변수를 참조할지 궁금해함
  • 저자가 피드백을 받고 의사소통 방법을 배우는 과정에 대해 존경을 표함. 문제 있는 카피 에디터에 대해 단호한 태도를 취한 점도 언급함
  • 스위스에서 C++ 레거시 코드베이스를 리팩토링한 경험을 공유함. 새로운 스택을 시도하고, 어려우면 다른 것을 시도할 수 있는 환경이 좋았음
  • Sensei's Library에서 Go에서 발생한 실수에 대한 페이지 모음을 언급함