[집필] 프로젝트 이제 이렇게 하는걸로!

INTRO

https://ridibooks.com/books/2773000095

프로젝트 그거 어떻게 하는 건데?!! - IT 초보자들을 위한 프로젝트의 모든 것

 

두 번째 책 집필이다. 처음 집필할때는 상대적으로 잘 모르는 주제를 집필하는 거라서 걱정이 많았었는데 이번에는 집필 과정을 경험해봐서 그런지 과정에 대한 걱정이 더 컸다. 원래는 집필을 할 생각이 없었는데 뮤딕 프로젝트를 하면서 느낀 점이 많아서 잘 정리해보고 싶은 욕심이 생겼다. 멋사 프론트엔드 7기 모니터링 매니저를 하면서 알게된 분이 프로젝트 진행을 하신다고 해서, 그간 봐왔던 문서화 능력이면 퀄리티 있는 결과물이 나올 거라는 생각에 합류하게 되었다.

 

과정1

조금 늦게 합류해서 첫 회의는 함께하지 못했다. 전에 작성된 회의록을 읽어보니 역할을 나누고 있었고 퀄리티에 대해 기준을 잡아둔 것을 확인할 수 있었다. 여러 역할이 있었지만 전에 집필 경험을 되살려보니 마지막에 검수할 때 시간도 인력도 부족했던 기억이 나서 집필 내용 검수를 맡기로 했다. 목차에 대해서 각자 정리해오기로 했다는 말에 경험했던 프로젝트 과정을 목차로 정리해갔고 다음 회의에 각자 작성한 목차를 보니 얼추 비슷했다.

 

리더가 피드백을 원활하게 하고 변경사항에 대한 기록을 남겨놓는 것이 좋을 것 같다고 해서 집필 도구는 깃허브를 사용하기로 했다. 노션은 여러 사람이 작성하면 내용이 날라가는 경우가 많았고 이전 작성 내용이 사라지기 때문에 사용하지 않았다. 그리고 목차별로 누가 작성할 것인지 정했는데 각자 하고자 하는 파트가 명확해서 나는 그 외의 남겨진 파트들을 작성하겠다고 했다. 어차피 필요한 내용이고 누군가는 작성해야 하니 최대한 경험을 녹여보자는 생각을 가졌다.

 

과정2

내가 맡게된 파트는 (나중에 또 추가된 것까지 한번에 정리했다) 다음과 같았다.

2.5 자원 고려 일정 산정
4.2 이해관계자간 커뮤니케이션
5.2 사용자 피드백
5.3 디버깅 및 오류수정
6.5 고도화 전략

 

이렇게 파편화 된 파트에서 내가 통일성을 가질 수 있는 부분이 어떤 것일까 고민하다가 공통적으로 결국 커뮤니케이션이 가장 필수적인 요소라는 생각에 최대한 적은 커뮤니케이션으로 프로젝트가 진행될 수 있도록 작성하려고 했다. 파트가 2뎁스였고 내용은 3,4뎁스까지 작성하는 것이 집필 기준이었다. 많은 내용을 넣기에는 다른 파트와 겹치는 부분도 있고 해서 간단하게 작성했다.

 

작성하는 과정에서 진행상황 공유를 위해 스프레드 시트에 각자 작성하는 파트와 작업 진행 퍼센트, 피드백 여부를 체크하기로 했다. 4뎁스 기준으로 글자수를 체크했는데 어쩌다보니 내가 제일 많았다. 목차 개수와 글자수가 차이가 많이 나는데 이 부분은 너무 줄글로 설명하려고 하지 않다보니 생긴 일이었다. 또한 기획은 내용이 많을 수 밖에 없어서 그런 부분을 감안하면 나쁘지 않았다는 생각이 들었다. 나중에 확인해보니 다들 4뎁스까지 안적고 3뎁스나 2뎁스까지만 적었다. 하라고 해서 한건데 너무 과했나 하는 생각이 조금 들었다.

 

과정3

집필을 완료하고 이미지 작업에 들어갔다. 이미지는 각자 필요한 내용을 레퍼런스를 찾아 올리거나 대략적으로 만들면 담당자가 피그잼으로 작업하기로 했다. 그리고 초고를 각자 확인해 피드백을 작성하기로 했다. 파트마다 이슈를 생성하고 permalink를 달아 수정이 필요한 부분을 댓글로 남기기로 했다. 그리고 이 두 가지 작업은 난항을 겪었다. 첫 번째 이유는 깃헙으로 해당 기능을 사용해보지 않은 사람이 많았고, 두 번째 이유로는 이미지를 찾거나 만드는 작업이 오래 걸렸기 때문이다.

 

이슈는 또 있었다. 책의 형태는 E-BOOK이다. 그래서 우리는 PDF로 결과물을 만들어야 한다. 그 결과물에는 여백과 페이지 넘버와 목차와 기타 등등 깃허브에서 작업하기 어려운 결과물들이 포함되어 있다. 원래는 리더가 옵시디언으로 PDF를 만드려고 했고 나도 그렇게 알고 있었다. 마감이 다가오는 걸 느끼면서 설마 하는 걱정이 들어 샘플을 뽑아봤는지 물어봤다. 리더가 해보지 않았다고 했고 샘플을 요청해 받아보니 여백과 이미지가 수정이 안될 정도로 엉망이었다. 물론 시간이 넉넉하면 가능했을지도 모른다. 사실 가능 하다 해도 손 대고 싶지 않은 퀄리티였다. 그래서 결국 우리는 피그마로 PDF를 만들게 되었다.

 

과정4

피그마로 작업하겠다고 결정함과 동시에 매일 저녁 리더와 피그마에서 만나게 되었다. 일단 피드백을 남긴 것을 바탕으로 수정해야 했고, 그 내용을 깃헙에서 피그마로 옮겨야 했고, 이미지를 해당 위치에 넣어야 했고, 페이지를 분리할 때 애매하게 넘어가는 것들을 다시 수정해야 했다. 일이 너무 많았지만 다들 사태의 심각성을 느껴서인지 최대한 각자 집필한 파트를 작업했고 마지막 검수 작업이 생각보다 시간이 덜 걸리게 되었다. (3일 밤을 새야 하나 걱정했는데 하루만 밤샘작업해서 끝난,,) 이렇게 작업한 것을 가지고 상반기 집필 팀 전체가 모여 발표하는 시간에 무사히 발표를 끝냈고 내용이 좋다는 평가와 산출물이 아쉽다는 평가를 받았다.

 

과정5

 

최종 원고 전달까지 1주일정도 시간이 있으니 각 파트별로 산출물을 만들어 올리자는 이야기가 나왔다. 나는 집필 파트가 상대적으로 많고 검수를 맡고 있어서 해야 할 일이 많았다. 그래도 일주일만 버티면 된다는 생각으로 작업을 진행했다. 산출물이 들어가면서 레이아웃이 전체적으로 변했고 이미지도 추가되었다. 그래도 같이 하는 팀원들이 이제 일주일만 하면 집필도 정말 끝난다는 생각으로 열심히 참여했다. 검수하고 있을 때도 와서 도와줄 일이 있는지 계속 확인하러 왔다.

 

그렇게 작업을 잘 마무리하고 집필도 끝났다고 생각했는데 문제가 생겼다. 리디북스에 올라간 책 소개와 목차가 누락된 내용이 있었던 것이다. 분명 리더가 몇번을 확인해서 최종 파일을 전달했다고 했는데 이게 무슨 일인가 싶었다. 알고보니 책 소개를 깃헙에 main 브랜치 README 내용을 가져가셨던 거였다. 우리는 write에 작성하고 깃헙은 수정이 가능하니 README 수정을 완료하고 PR하자고 일정을 잡았는데.. 그래도 다행히 발견하고 수정 요청을 해서 무사히 수정할 수 있었다.

 

OUTRO

 

오늘 확인해보니 무료 IT 부분 1위였다. 확인하고 기분이 좋았다. 저번 책도 1위를 했었지만 제목이 어그로를 잘 끌어서 그런 것도 있다는 생각이 있었는데 이번 책은 완성도에도 자신이 있어서 그런지 좀 더 뿌듯했다. 그동안 했던 작업들이 머리를 스쳐 지나가면서 고생을 조금 했지만 재밌었다는 생각이 들었다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

https://www.notion.so/sleepingoff/df146934b1dc499c9d7a30163cce79b1?v=87ef9b2b0ec340f7af59017c5b5103c6

HOME | Notion