네이버 블로그, 티스토리, Wordpress, Media Wiki, 등 다양한 후보를 고려한 끝에 최종 결정은 GitHub가 되었다.

책을 읽다 보면 오탈자도 발견하고 궁금한 것도 생긴다. 그래서 출판사는 독자의 이야기를 들을 수 있게 오탈자 제보 게시판이나 질문 게시판을 마련한다. 보통 큰 출판사는 자체 시스템을 운영하고 작은 출판사는 네이버나 카카오의 커뮤니티 기능을 활용한다.

예전에 번역만 할 때는 이 부분을 출판사가 알아서 했지만, 1인 출판을 풀 스택으로 해야 하는 입장이 되고 나니 이런 소통 채널도 직접 준비해야 했다. 소위 말하는 ‘도서 지원 페이지’를 뭐로 만들 것인가? 첫 책을 소개할 본진을 어디에 차릴지 과제가 생긴 것이다.

네이버 블로그, 티스토리, Wordpress, Media Wiki, 등 다양한 후보를 고려한 끝에 최종 결정은 GitHub가 되었다. 움? GitHub는 소스 코드 관리하는 곳 아닌가? 물론 그렇다. 다소 생뚱맞게 보이지만 ‘소스 코드’도 결국 ‘텍스트 파일’의 하나다. 그 텍스트가 사람에게 입력되나 기계에게 입력되나 차이가 있을 뿐, 애당초 한 층 위로 추상화해서 생각하면 모든 의문은 사라진다.

왜 하필 GitHub인가?

우선 하고 싶은 일이 뭔지 생각해보자.

• 책에 대한 기본 정보를 제공하고 싶다
• 다운로드 파일을 제공하고 싶다
• 오탈자, 질문, 제안 등의 독자 피드백을 받고 싶다

이 정도가 기본이고 조금 더 욕심부리면 이런 것도 괜찮겠다.

• 독자 피드백에 답하고 싶다
• 독자 피드백에 투표하거나, 처리 과정을 투명하게 보이고 싶다
• 변경 전의 내용과 변경 후의 내용을 확인하고 싶다
• 피드백이 언제 조치되는지 어느 개정판에 반영되는지 알리고 싶다

여기까지 보았다면 음? 어디서 많이 본 것 같은데?
하며 멀티 유니버스의 데자뷔를 본 느낌일 것이다. 그렇다. 눈치 빠른 사람이면 감 잡았겠지만 이건 전형적인 소프트웨어 버전 관리 기법이다.

왜 책을 보완하는데 소프트웨어 개발 툴인 GitHub인가? 라는 생각도 할 수 있는데 애당초 형상 관리라는 것이 소스 코드와 관련 문서를 관리하는 기법이었고 베이스라인을 긋고, 프로모션, 디모션 하는 과정이 창작물의 버전을 올리고, 목적에 맞게 태깅하는 과정과 일맥상통한다.

게다가 만들 창작물이 전자책이라면?
EPUB은 HTML과 CSS의 패키지이고 *.epub 이라는 이름으로 아카이빙 된다. 그리고 그 파일은 전자책 리더라는 디바이스에 배포된다. 아, 뭔가 또 한 번 멀티 유니버스의 데자뷔를 본 느낌인데? 맞다. 이건 웹 애플리케이션을 패키징해서 웹 애플리케이션 서버에 배포하는 것과 같다.

앞으로도 종이책은 내연기관 자동차보다 더 지속되고, 소장용 LP판보다 더 사랑받을 것이다.
그 와중에 전자책은 전기 자동차가 대세가 되는 것처럼 자리 잡을 것이다. 자동차의 핵심이 엔진이라는 이동 수단에서 소프트웨어라는 인포테인먼트로 옮겨가는 듯이 책의 핵심도 인쇄물이라는 하드웨어에서 콘텐츠라는 소프트웨어로 옮겨갈 것이다. 상황이 그렇다면 책을 만드는 공정 또한 소프트웨어 개발에 준하게 다루는 게 맞단 얘기다.

GitHub에서 활용할 수 있는 기능

다음은 도서 지원 사이트에 필요한 기능과 GitHub의 기능을 매핑한 것이다.

IT 도서에서 제공하는 샘플 코드는 기본적으로 오픈 소스다. 특히 번역서라면 원서의 소스 코드를 국내 번역서에 맞게 현지화하면서 내용이 달라진다. 원저자의 GitHub 리포지터리를 fork하고 내용을 고친 후에 독자에게 다시 공개하는 것이다. 물론 그걸 기반으로 독자들이 개작하고, 응용하고, 기여할 것이라 기대하긴 어렵지만 아주 드물게 오류를 바로 잡아 Pull Request하는 의욕 충만한 독자도 만나게 된다.

그 밖에도 솜씨만 괜찮다면 GitHub Action으로 텍스트 파일이 push 될 때 텍스트를 분석하여 문서 통계 정보를 뽑는다거나, 맞춤법 검사, EPUB 검증도 가능하니 활용은 하기 나름 무궁무진하게 응용할 수 있다. (페이지 수가 아니라 단어 수, 글자 수로 원고료를 산정하기도 함) 더 부지런하면 도서 홍보 브로슈어를 발송하거나, 온라인 서점에서 API만 제공한다면 도서 입고 자동화도 가능하겠다.

특히 IT 도서는 설치 가이드와 같은 문서가 필요한데 책 지면의 한계 상 모든 플랫폼과 버전에 맞춰 내용을 넣을 수 없다. (전자책이라 하더라도 본 내용보다 많아지면 밸런스가 깨짐) 이때 지면에 미처 반영하지 못했거나 출간 이후에 변경된 내용을 Wiki에 정리하면 종이를 낭비하지 않을 뿐만 아니라 책을 사지 않은 사람도 참고할 수 있다.

대부분의 소프트웨어 개발 프로젝트에서 개발 초기에 개발 환경 가이드를 작성하는 데 많은 공을 들인다. 검색해보면 유튜브에 블로그까지 다양한 가이드를 찾을 순 있지만, 상품으로 판매되는 책의 내용만큼 검증되고 정제된 내용은 찾기 어렵다. 책 내용 모두를 공개할 순 없지만 보조 자료 정도는 공개해도 되는 수준이고, 책에 대한 관심을 유도하는 좋은 접점이 되기도 한다. 프로젝트를 준비해야 하는 누군가는 똑같은 가이드를 다시 만드는 대신 검증되고 정제된 양질의 문서를 인용하면서 본연의 업무에 더 집중할 수 있을 것이다. 개꿀

책의 내용은 저작권이 있으니 모든 텍스트를 Public으로 공개하진 못한다. GitHub을 최소한으로 활용한다면 소스 코드를 격납하는 수준에서 끝나겠지만, 이미 있는 Pages, Issues, Wiki, Release 같은 기능을 쓰지 않을 이유는 없다.

베타 리더나 편집자와 협업한다면 Private 리포지터리를, 독자와 소통한다면 Public 리포지터리를 활용해보자. 물론 GitHub이 한국어를 지원하지 않으니 생얼(?)을 마주하기 부담될 순 있다. (한국어 지원 여부를 고객지원했으나 그럴 계획 없다고 회신받음) 하지만 GitHub Pages의 Themes를 잘 고르고, Jekyll로 잘 꾸며서 보고 싶은 내용만 정리해준다면 어떤 툴에 못지않은 깔끔한 ‘도서 지원 페이지’를 구성할 수 있을 것이다. 절대 Jekyll이 쉽다곤 말 안 했다.

하나 더 팁을 주자면 다른 플랫폼은 자신이 가진 도메인에 연결하려면 월 구독료를 내야 하는데 GitHub Pages는 그냥 붙는다. 무료란 얘기다. 다른 걸 다 감내하더라도 해봄 직한 시도임엔 틀림없다.

그래서 내가 한번 해볼라고…

‘형용돈죵’이 부릅니다.
해볼라고