공동 책 집필 하는 방법

Jay·2022년 11월 28일
1

DOM - 잡았다, 요 돔!

DOM - 잡았다, 요 돔!
글을 작성하는 2022년 11월 28일 기준 리디북스 컴퓨터/IT > 개발/프로그래밍 카테고리 무료책 인기순 1위를 기록하고 있습니다. 다들 너무 고생 많으셨습니다!😄 출판에 많은 도움을 주신 호준 님 감사합니다.🙏🏻

작품 소개
Front-end 개발자를 지망하는 사람이라면 학습의 길에서 DOM을 한 번이라도 마주치지 않을 수 없습니다. <DOM - 잡았다, 요 돔!>은 초급자 대상의 책입니다. 옆자리 친구에게 물어보듯 친숙하게 대답을 들으실 수 있을 것입니다. DOM을 처음 접한 독자 여러분에게 어렵고 낯선 개념들과 실무에서 쓰일 수 있는 내용들을 다루었습니다. 이 책을 읽고 여러분이 DOM에 대한 이해와 더 깊은 곳으로 여행하기 위한 의문을 얻는다면 그것으로 우리는 무척 기쁠 것입니다. 모쪼록 이 책을 초석으로 삼아 여러분의 주체적인 학습이 이어지길 기대합니다.

필자는 27인이 참여한 해당 공동 집필 프로젝트에서 총괄 리더실무 응용 파트 집필을 담당하였습니다. 7주간의 길었던 프로젝트에 이제는 마침표를 찍고, 프로젝트를 총괄 리딩하며 느낀 소회와 과정을 남기려 합니다. 꼭 IT 개발 서적이 아니더라도 공동 집필 출간을 기획 중인 분들에게 이 글이 도움이 되리라 생각합니다.

기획

필자는 프로젝트를 총괄하는 총괄 리더(= PM)였고, 프로젝트의 원활한 진행을 위해서 매 순간 문제를 해결하기 위한 과정을 고민하고 설계하였습니다.

협업 툴

협업 툴은 노션디스코드를 이용하였습니다. 노션 공유 페이지를 활용하여 모두 함께 하나의 페이지를 편집하였고, 각자 다른 시간대에서 집필하였습니다. 해당 프로젝트는 전면 비대면으로 이루어졌기 때문에 모든 소통은 디스코드로 이루어졌습니다. 자세한 활용 방법은 뒤에 후술하겠습니다.

첫 회의

처음 DOM이라는 주제는 정해져 있었지만 그외에는 모든 것이 백지였습니다. 프로젝트의 데드라인으로 잡아놓은 기간은 7주. 이 기간 내에서도 각자가 책 집필에 할애할 수 있는 리소스는 한정되어 있고, 예상치 못한 문제가 발생할 것은 뻔했기 때문에 최대한 빨리 작업을 시작하는 것은 생산성을 높이기 위해 아주 중요한 일이었습니다.
프론트엔드 개발과 공동 책 집필은 전혀 다른 분야이지만 협업이라는 관점에서 바라볼 때는 그렇지도 않습니다. 보통 프론트엔드 개발 시에는 프로젝트의 디렉토리 구조를 나누어 놓은 후에, 기능 별 혹은 페이지 별로 분담하여 협업합니다. 책 집필도 이와 같습니다. 태스크를 적절하게 나누고 원활하게 협업하기 위하여 먼저 대목차를 세우고 인원을 적절히 분배하였습니다.

집필 프로세스

초안 작성 -> 개인 퇴고 -> 챕터팀 퇴고 -> 전체 팀 퇴고 -> 통합

여러 집필 방식

  • 페어 집필
  • 공동 집필 (= 몹 프로그래밍)
  • 소목차 별 개인 집필

공동 집필에도 여러 방식이 있지만 글을 처음 써보는 사람들의 모임이라면 먼저 페어 혹은 공동 집필을 추천합니다. 글을 처음 써본다면 집필에 확신이 안 생기고 막막한 기분이 들기 때문입니다. 저희 프로젝트에서 개요와 노드 팀은 공동 집필로 모든 집필 과정을 마무리하였는데 가장 빠르게 집필을 끝내는 효과를 보았습니다.
다만 팀마다 방식의 선호도와 효율이 다르기 마련입니다. 비효율이라 생각된다면 즉시 방향을 바꾸시기를 권장 드립니다.

글 쓰기

초안 작성은 책 집필에서 가장 어렵고 힘든 일이니 되도록 빠르게 끝내기를 권장 드립니다. 개념을 여러 번 보면서 점차 익숙해지고 윤곽이 잡히면 퇴고만큼 쉬운 일도 없기 때문입니다. 초안에서 완벽함을 추구하기 보다는 남에게 부끄러운 글이어야 합니다. 초안 작성 과정이 짧고 피드백을 받으며 퇴고하는 기간이 길수록 잘 읽히는 글, 좋은 퀄리티를 보장합니다.
그러므로 처음부터 모든 컨벤션을 지키면서 꼼꼼하게 글을 작성하려 하시기 보다는 공부하면서 넣어야될 것 같은 것들을 의식의 흐름대로 전부 넣어 보는 것을 추천드립니다. 나만 볼 예정인 공부 기록을 블로그에 포스팅하거나 처음 자소서에 글자수를 채우기 위해 내용을 우겨넣을 때 처럼요.

커뮤니케이션

팀 구성

의사소통 비용이 증가되는 것을 가장 경계하였습니다. 27인이 모든 것을 협의해서 고르게 진행하면 아주 이상적이겠지만 혼자서 모든 분의 의견을 듣고 조율해나가는 것은 현실적으로 어렵습니다. 때문에 각각의 대목차에 분배된 인원 중 한 분씩 팀 리더를 선정하여 팀 내의, 팀 간의, 그리고 저와의 소통이 효율적으로 진행되기를 원했습니다. 집필 또한 팀 단위로 5 개의 팀이 비동기적으로 작업할 수 있었습니다.

회의 최소화

잦은 회의 또한 의사소통 비용이 증가되는 행위입니다. 누군가는 그 시간에 집필에 몰입하고 싶을 수도 있으며 이것이 더욱 생산적인 측면에서 더욱 효율적이라 생각하였습니다. 각각의 팀 리더를 선정한 이유 중 하나로도 모든 이가 회의에 참석하여 내용을 듣고 있을 필요가 없기 때문이기도 합니다. 따라서 대부분의 사소한 안건은 다수결 투표를 통해 빠르게 합의하였고, 뒤탈이 생긴 일 또한 없었습니다.

회의록 공유

팀 단위로 작업을 진행하게 되었지만 팀 간의 의논이 필요한 지점은 분명히 있었습니다. 팀 단위로 고립되는 것을 방지하기 위하여 회의록을 프로젝트 인원 모두가 볼 수 있도록 공개하였습니다. 이 회의록을 읽는 것 만으로도 각각 팀의 진행 상황과 방식 등을 참고하면서 각 팀은 도움을 얻을 수 있었습니다. 읽어보기 쉽도록 공유할 회의록의 템플릿은 통일하였습니다.

마무리

결과적으로 작업 속도는 매우 빨랐고, 8주의 데드라인이 있었지만 대부분 6주차에 작업을 끝내고 피드백과 교정 작업을 반복했습니다. 책의 완성도를 높이는데 가장 중요한 프로세스인 교정 작업 기간이 최대화되었기 때문에 생산성과 퀄리티를 동시에 잡을 수 있었다고 생각합니다.

공동 책 집필, 즉 팀 프로젝트는 마치 다같이 통나무를 들고 산을 오르는 행위와 같습니다. 한 사람이라도 힘들다고 손을 빼버리면 다른 사람들이 두 배로 힘들어진다는 생각으로 케파가 되는 한에서 최대한 노력해야 합니다.
만약 공동 책 집필을 계획하셨다면 부디 이 글이 도움이 되어 성공적으로 출판 하시기를 응원하겠습니다!

0개의 댓글