Single-Source Publishing에 대하여

싱글 소스 퍼블리싱을 두 가지로 볼 수 있겠다.

하나는 두 가지 이상의 포맷으로 문서를 만드는 것이다. PDF와 HTML. ePub은 HTML을 압축한 것이니, HTML을 얻을 수 있다면 ePub을 만드는 것도 어렵지 않을 것이다.

PDF와 HTML을 생성하는 솔루션들은 여럿 있다. 스핑크스(Sphinx), 아스키독(AsciiDoc), 쓰리래빗츠(3Rabbits), 그리고 내가 알지 못하는 다른 많은 것들이 있을 것이다. 간단한 문서만 만들자면 주피터 노트북(Jupyter Notebook)과 타이포라(typora)도 선택지에 넣을 수 있다. 어느 솔루션을 사용하든 크고 작은 문제들에 맞닥뜨리게 될 텐데, 대부분 "jpg 이미지만 사용한다"거나 "색인은 만들지 않는다" 따위의 정책을 취하여 극복할 수 있을 것이다.

나는 PDF와 HTML을 동시에 만드는 것이 낭비라고 생각한다. 문서 성격에 맞게 한 가지 포맷으로만 만드는 게 합리적이다. 제조 장비의 매뉴얼을 HTML로 만드는 것에는 별 이익이 없다. 반면 프로그래밍과 관련된 문서는 HTML이 여러모로 PDF보다 나을 것이다.

아무튼 PDF와 HTML을 동시에 만드는 것은, 여러 솔루션들이 있으니, 큰 문제가 아니다. 하지만 그것은 싱글 소스 퍼블리싱이라기보다 멀티 채널 퍼블리싱이라 부르는 게 더 적절할 것이다. 아마도 많은 사람들이 싱글 소스 퍼블리싱이라는 말에서 연상하는 것은, 멀티 채널 퍼블리싱(multi-channel publishing)이 아니라, 하나의 데이터셋에서 내용이 다소 상이한 여러 문서들을 만들어내는 것일게다.

서로 다른 옵션들을 장착한 여러 제품들이 있을 때, 그에 맞게 매뉴얼을 개별적으로 작성하는 것이 최선일 것 같지만, 그것이 당위라고는 생각하지 않는다. 냉장고나 자동차 매뉴얼에서 내 것에는 없는 기능을 발견했을 때, "그 놈들이 내게는 불량품을 줬구나"라며 분개할 사람은 없다. 내가 선택하지 않은 옵션이거나 다른 상위 모델에 적용된 옵션이라고 생각할 것이다.

하지만 너무 다양한 옵션들이 있을 때에는 싱글 소스 퍼블리싱을, 그 개념조차 모르는 사람도, 갈구하게 된다. TV를 생각해 보자. 튜너와 AV 입출력 단자들만 갖고도 그것들을 조합하여 수십 가지 모델들을 만들 수 있다. 만약 매뉴얼 하나가 그 모든 모델들을 다룬다면, 소비자들은 "나와 무관한" 페이지들을 넘기면서 짜증낼 것이다.

영리하게도 요즘 TV 제조사들은 그렇게 다양한 모델들을 만들지 않는다. 거의 모든 제품들이 거의 모든 옵션들을 갖추고 있다. 단순한 제품 라인업을 유지하는 것이 싱글 소스 퍼블리싱을 운영하는 것보다 나을 수 있다. 그 경우에는 검소한 소비자가 선택할 수 있는 합리적으로 저렴한 제품이 없다는 것이 문제이다.

아무튼 싱글 소스 퍼블리싱이 필요하다면, 무엇을 선택할 것인가? 사실 답은 하나이다. XML밖에 없다. 골라야 할 것은 수많은 XML 관련 프로그램들이다.

레이텍(LaTeX)을 이용한 싱글 소스 퍼블리싱

나는 레이텍을 이용하여 개인적 수준에서 싱글 소스 퍼블리싱 방법론을 만들어 사용한 경험이 있지만, XML에 대해서는 그다지 긍정적으로 보지 않는다. 넘어야 할 산들이 너무 많기 때문이다.

첫째, 많은 인력이 필요하다.
XML은, 다른 마크업 언어들과 다르게, 철저하게 내용만 (또는 데이터만) 담고 있다. 그것으로부터 PDF나 HTML를 만들려면 서식 템플릿(.xsl)이 필요하다. 테크니컬 라이터가 XML 파일들을 작성하고, XSLT 전문가가 XSL 파일들을 만들어야 한다. 이것을, 테크니컬 라이터가 워드를 이용하여 원고를 만들고, 그것을 편집 디자이너가 인디자인으로 옮겨서 PDF를 만드는 것에 비유할 수 있을 것 같지만, 그보다는 훨씬 복잡하다. 자바 프로그래머, 또는 CSS와 자바스크립트에 능한 웹 디자이너가 필요할 수도 있다.

둘째, XML은 다른 마크업 언어들보다 사용하기 매우 어렵다. (며칠 들여다 보면서 독학으로 익힐 수 있는 것인지 확신하지 못했다.) 테크니컬 라이터는 (DocBook이나 다른 스키마들도 있겠지만) DITA 구조를 숙지해야 하는데, reStructuredText나 AsciiDoc보다 훨씬 긴 학습 시간이 필요할 것이다.

셋째, 효율성을 위해서는 Oxygen 같은 XML 에디터를 사용해야 한다. 범용 에디터로도 XML 문서를 작성할 수 있지만, 몹시 불편할 것이다. 이러저러한 상용 프로그램들을 사용하면 작업이 수월해질 텐데, 그렇다고 그것들이 개발 인력들을 완전히 대체하리라고 장담할 수 없다. 그리고 대신 그 프로그램들의 전문가들이 필요할 것이다.

결론적으로 XML로 문서를 만드는 것은 많은 인력, 많은 소프트웨어 비용, 그리고 (필요한 모든 것들을 학습하고, 시스템을 설계하고 구현하기까지) 많은 시간이 필요하다.

싱글 소스 퍼블리싱이 필연적으로 CMS로 귀결되어야 하는지는 모르겠다. 그리고 그 경우에 CMS가 뭘 하는지도 잘 모르겠다. (단지 문서 데이터와 산출물을 모아 두는 저장소도 CMS라 일컫는 것 같다.) 여러 사람들이 문서 파일들과 이미지 파일들을 업로드하여 공유하고, 필요에 따라 이런저런 조건들을 지정하면 서버에서 문서 파일들이 만들어지는 것인가? 아무튼 소수의 회사들이 대리자로서 외국 CMS 솔루션들의 판매를 위해 영업하고 있는데, 쉽지 않은가 보다. 잠재 고객들은 분명 레퍼런스, 그러니까 실제 적용 사례, 그것도 국내 기업이 도입한 사례를 요구할 것이다. 삼성전자나 현대중공업이 도입한 적이 있다면, 다른 기업들을 설득하기가 용이할 것이다. 하지만 내가 아는 범위에서 CMS를 도입한 기업이 별로 없다. CMS를 도입할 때, 비용은 차치하고, 기술 지원을 해줄 인력들이 있을까?

CMS를 논외로 하더라도, 싱글 소스 퍼블리싱은 엄청난 비용을 요구한다. 다수의 값싼 인력을 사용하여 파일들을 복사하고 짜깁기하는 것이 더 경제적일지도 모른다. 그래서 나는 싱글 소스 퍼블리싱이 우리 기업들에 도입되기 어려울 것이라고 본다. 많은 대기업들이 매뉴얼 제작을 하청 업체에 맡긴다. (대기업들이 테크니컬 라이터들을 많이 고용하고 있다면 일말의 가능성을 기대할 수 있겠지만) 그들의 관점에서 하청 업체들이 싱글 소스 퍼블리싱을 쓰든, 영혼을 갈아 넣든 관심을 둘까 모르겠다.

* * *

XML이 싱글 소스 퍼블리싱의 유일한 수단이라고 말하는 이유는, 멀티 채널 퍼블리싱과 컨디셔널 텍스트 둘 다 가능하기 때문이다. 마크다운 문서에 컨디셔널 텍스트(conditional text)를 구현하려면 메타 마크업 같은 것을 만들고 그것을 제어하는 프로그램을 만들어야 할 것이다. 얼핏 생각하면 그다지 어렵지 않을지도, 찾기-바꾸기만 하면 되니까.

레이텍 (LaTeX) 파일을 HTML로 변환하는 것은 불가능하지 않지만, 대신 포기해야 할 것들이 많다. 레이텍의 강점은 사용자들이 매크로를 정의할 수 있다는 것인데, 그런 것들을 특정 HTML 태그로 변환하는 것은 결코 쉬운 도전이 아닐 것이다. 그래서 나는 레이텍을 HTML로 변환하는 것은 거의 불가능한 것으로 간주한다.

HTML만 제껴 놓으면, 레이텍이 싱글 소스 퍼블리싱을 구현하는 가장 좋은 방법이 될 수 있다. 레이텍 프로그래밍이 쉽다고 할 수 없지만, XML을 활용하기에 들여야 하는 시간과 노력보다 크지는 않을 것이다. 무엇보다 가장 좋은 점은, 특별한 레이텍 에디터를 고집하지 않는 한 (그것들도 XML 에디터보다 훨씬 저렴하지만), 소프트웨어 비용이 들지 않는다는 것이다.