Adobe도 MS Word도 버렸다 — Git으로 책을 만드는 출판 파이프라인 구축기

책 한 권을 만드는 데 InDesign이 꼭 필요할까?

책을 출판해본 사람이라면 다 아는 워크플로우가 있어요. 원고는 MS Word로 쓰고, 편집은 Word에서 추적변경(Track Changes)으로 주고받고, 최종 조판은 Adobe InDesign에서 하죠. 이게 수십 년간 이어진 출판업계의 정석이에요. 그런데 한 개발자가 "이거 우리 개발자 워크플로우랑 너무 다른데? 그냥 Git으로 하면 안 되나?" 하는 의문을 품고 실제로 자기만의 출판 파이프라인을 구축한 이야기가 공개됐어요.

이게 단순히 "마크다운으로 책 썼어요" 수준이 아니라, 상업 출판물 수준의 조판 품질 을 유지하면서, 버전 관리와 자동화 까지 잡아낸 진지한 시도라서 읽다 보면 무릎을 치게 되거든요.

왜 기존 도구가 불편할까

Word와 InDesign의 가장 큰 문제는 파일 자체가 블랙박스 라는 거예요. .docx 파일은 사실 XML을 압축한 거긴 한데, 사람이 직접 diff를 보기엔 너무 복잡해요. "3장 두 번째 문단에서 뭐가 바뀌었지?"를 추적하려면 결국 Word를 열어서 추적변경 기능에 의존해야 하죠. 그리고 협업할 때 "최종.docx", "최종_진짜최종.docx", "최종_진짜진짜최종_v3.docx" 같은 비극이 반복돼요.

InDesign은 더해요. .indd 파일은 바이너리고, 라이선스도 비싸고, 매 페이지를 수동으로 조판해야 해요. 본문 한 줄이 추가되면 그 뒤 페이지가 다 밀려서 페이지 번호, 목차, 색인까지 다시 손봐야 하는 상황이 흔해요.

개발자라면 이 지점에서 자연스럽게 떠오르는 게 있죠. "이거 코드처럼 다루면 안 되나? Git에 올리고, CI에서 빌드하고, PDF는 자동으로 떨어지게 하면 안 되나?"

이 파이프라인의 핵심 구조

저자가 구축한 시스템의 핵심은 대략 이런 흐름이에요.

원고는 Markdown으로 작성해요. Markdown은 평문이라 Git에서 줄 단위로 diff를 볼 수 있고, 어떤 에디터에서든 열 수 있고, 협업자가 풀 리퀘스트로 수정 제안을 보낼 수 있어요. 작가 입장에서도 서식 고민 없이 글 자체에 집중할 수 있다는 장점이 있고요.

조판은 Pandoc과 LaTeX 조합으로 처리해요. Pandoc이 뭐냐면, 마크다운이나 다른 문서 형식을 PDF, ePub, HTML 등으로 변환해주는 만능 도구예요. 그리고 LaTeX는 학술 논문이나 책 조판에서 수십 년간 신뢰받아온 조판 시스템인데, 텍스트 명령어로 페이지 레이아웃을 정의하는 방식이라서 결과물의 품질이 InDesign에 견줄 만큼 정교해요. 본문 폰트, 행간, 페이지 여백, 챕터 시작 페이지 처리 같은 디테일을 코드로 명확하게 제어할 수 있죠.

빌드는 CI에서 자동화해요. GitHub에 푸시하면 GitHub Actions가 Pandoc + LaTeX를 돌려서 인쇄용 PDF, 전자책용 ePub, 미리보기용 웹 버전을 동시에 뽑아내요. 작가가 "3장 두 번째 문단" 한 줄을 고치고 푸시하면, 몇 분 안에 최종 인쇄 가능한 PDF가 떨어지는 거예요. 페이지 번호와 목차는 LaTeX가 알아서 다시 계산해주니까 수작업이 사라져요.

디테일에서 빛나는 선택들

저자는 단순히 "마크다운 → PDF"에서 멈추지 않았어요. 책 조판에서 중요한 디테일들을 챙기기 위해 몇 가지 추가 작업을 했거든요. 예를 들어 챕터별로 시각적 분위기를 다르게 하기 위해 커스텀 LaTeX 템플릿을 만들었고, 인용구나 코드 블록 같은 특수 요소의 스타일을 일관되게 유지하기 위해 Lua 필터로 Pandoc의 변환 과정에 끼어들어 후처리를 했어요.

또 하나 흥미로운 건 이미지와 도판 관리 예요. 책에 들어가는 그림은 가능한 한 SVG로 작성해서 텍스트와 함께 버전 관리되도록 했고, 다이어그램은 Mermaid나 PlantUML 같은 텍스트 기반 도구로 그려서 "그림도 코드처럼" 다룰 수 있게 했어요. 이렇게 하면 "이 다이어그램이 언제 어떻게 바뀌었지?"를 git blame으로 추적할 수 있어요.

업계의 비슷한 흐름

사실 이런 접근이 완전히 새로운 건 아니에요. Pragmatic Bookshelf 같은 출판사는 오래전부터 자체 마크업 기반 파이프라인을 써왔고, O'Reilly도 "Atlas"라는 AsciiDoc 기반 시스템을 운영해요. Bookdown(R 마크다운 기반)이나 Quarto 같은 도구도 이 영역의 강자예요.

하지만 대부분의 이런 도구들은 "학술 도서"나 "기술 도서"에 특화돼 있어서, 이번 글의 저자가 시도한 것처럼 일반 단행본 수준의 미감과 조판 품질 까지 잡아내려는 시도는 상대적으로 드물어요. 그래서 이 파이프라인이 의미 있는 거예요.

한국 개발자에게 주는 시사점

기술 블로그를 운영하시거나 사이드 프로젝트로 책을 내보고 싶은 분들에게는 정말 흥미로운 레퍼런스예요. 특히 자가출판(self-publishing)을 고민하시는 분이라면, InDesign 라이선스 비용 없이도 이 정도 품질의 결과물을 만들 수 있다는 게 큰 매력이거든요.

주의할 점도 있어요. 한글 조판은 LaTeX 환경에서 추가 설정이 필요 합니다. XeLaTeX이나 LuaLaTeX를 써야 하고, KoTeX이나 직접 폰트 설정을 통해 한글 줄바꿈, 자간, 본문 글꼴을 잡아줘야 해요. 영문 책보다 셋업 난이도가 한 단계 높지만, 한 번 잡아두면 그 뒤로는 쭉 재사용할 수 있어요.

팀 단위 기술 문서를 책처럼 만들고 싶을 때도 이 접근이 잘 맞아요. 사내 온보딩 문서, API 가이드, 기술 백서 같은 것들을 Git에 올려두고 PR로 리뷰하면서 PDF로 자동 생성하면, 워드 문서를 메일로 주고받는 것보다 훨씬 협업이 깔끔해져요.

마무리

결국 이 글이 보여주는 건 "우리에게 익숙한 개발자 워크플로우는 다른 분야에도 충분히 적용될 수 있다"는 거예요. 책이든, 논문이든, 사내 문서든, 텍스트로 표현되는 모든 결과물은 Git의 강점을 활용할 수 있거든요.

여러분은 책이나 긴 문서를 쓸 때 어떤 도구를 쓰시나요? 혹시 Word나 노션이 답답하다고 느낀 순간이 있다면, 어떤 점이 가장 불편했는지 댓글로 이야기해보면 재밌을 것 같아요.