Node.js 프로그래밍이 나오기까지 #1
Node.js 프로그래밍이 나오기까지 #2



Markdown
작업을 시작하면서 대부분 원고를 MS Word로 작성해서 출판사에 넘겨준다는 것을 알게 되었습니다. 사실 그 전에도 베타리딩을 할 때 원고로 받은 적도 많았고 반드시 Word포맷이어야 하는 것은 아니었지만 대부분 이렇게 사용하고 있다는 건 저로써는 약간 충격이었습니다. 제가 보았을 때 MS Word는 다른 포맷을 위한 소스포맷이 아닌 완성형 포맷이었기 때문이었습니다. 물론 MS Word도 XML이므로 다른 포맷으로 출력할 수 있기는 하지만 제 입장에서 봤을 때 MS Word는 완성형 포맷이었습니다.

제가 보았을 때 책은 짧은 글도 아니었기에 글을 쓰는 과정과 글의 스타일을 잡는 과정이 분리되어야 한다고 생각했습니다. 이는 약간 HTML과 CSS의 분리라는 프론트엔드적인 관점이 들어간 것인지도 모르겠습니다. 그리고 이전 내용에서도 ebook에 대한 출판은 접었다고 얘기했지만 완전히 꿈을 버린 것은 아니었기 때문에 제가 작성한 내용이 Word뿐만 아니라 PDF와 epub까지 나왔으면 하는 바램이 있었습니다. 아무튼 저는 글을 쓸 때는 내용에만 집중하고 싶었고 거기서 자연스럽게 스타일을 잡아서 다양한 포맷으로 변환되는 형태를 기대했습니다.


저는 원래 Markdown을 좋아하기도 했고 기존에 위와 같은 Byword라는 맥용 마크다운 에디터를 사용하고 있었습니다. 사실 맥용 MS Word는 가지고 있지도 않았고 들은 바에 의하면 맥용 워드는 한글이 별로 좋지 않아서 문제가 있으므로 윈도우용 워드로 작업하는게 좋다는 말을 들은 터였습니다. 마크다운은 스타일을 그다지 신경쓰지 않고도 제목과 본문을 단계적으로 작성할 수 있고 리스트나 그림을 자유롭게 넣을 수 있기 때문에 책의 내용에 집중해서 글을 작성할 수 있습니다. 더군다나 위와 같은 ByWord는 풀스크린으로 화면에 띄울 수 있기 때문에 다른 데 시선을 빼앗기지 않고 글을 쓸 수 있고 그 외 작성하는 문단맛 밝게 보여주는 기능도 지원하고 있습니다.

처음에 마크다운에 적응할 때는 항상 프리뷰를 보면서 적었어야 했지만 지금은 그 간단한 문법에 익숙해 졌기 때문에 별도로 프리뷰를 보지 않고도 글을 쓸 수 있었습니다. 워드는 글의 작성과 스타일을 한꺼번에 작성하는 도구라면 마크다운 에디터는 글의 작성에 집중되어 있고 스타일은 나중에 CSS등을 통해서 얼마든지 변경할 수 있고 다양한 포맷으로 출력할 수도 있습니다.(여러 시행착오 끝에 결과적으로는 좀 달랐지만 이때의 생각과 의도는 이러했습니다.) 출판사에 초기 원고를 전달할 때 아직 문서변환에 적응이 안되어서 변환한 PDF에 글 복사가 안된다든가 페이지 구분이 제대로 안된다든가 하는 등의 문제로 출판사의 걱정을 끼치기는 했지만 제 입장에서 마크다운은 단순 텍스트 포맷이므로 이러한 걱정은 전혀 없었습니다.




생각과는 달랐던 Markdown 변환
마크다운의 변환은 원래 pandoc을 이용하려고 했습니다. pandoc을 이리저리 파봤지만 제대로 변환이 되지 않았습니다. pandoc을 이용하면 css로 스타일을 입혀서 epub와 pdf로 변환할 수 있었지만 일부 제대로 변환되지 않는 부분이 있었습니다. HTML로 변환후 다시 PDF로 변환할 때 그림의 설명이 2번 반복된다거나 하는 사소한 문제들이 약간씩 있었습니다.(여기까지 오기까지도 엄청 고생을 했습니다.) pandoc의 설명에는 progit이 pandoc을 사용한다고 나와 있지만 지금은 달라졌는지 pandoc을 쓰지 않는 것으로 보입니다. progit의 스크립트로 테스트해보았지만 PDF의 한글변환이 제대로 되지 않았던 것으로 기억하는데 최근 한글로 번역이 되면서 이 부분이 수정된 것으로 보아 다시 좀 살펴보아야 할 것 같습니다.

그리고 무엇보다 저는 markdown에 multi markdown을 사용하는데 pandoc은 multi markdown의 table 문법을 지원하지 않아서 제대로 변환되지 않았습니다. 그러자면 pandoc의 table문법을 사용해야 하는데 그렇게 하면 마크다운이 아닌 pandoc의 종속적이 되어버려서 고민스러운 일이었습니다. 마크다운의 가장 큰 문제는 코드블럭에 스타일을 줄 수 없다는 것이었습니다. 예를 들어 앞의 예제에서 변경된 코드는 굵은글씨로 표시하는 것으로 정했었는데 마크다운의 코드블럭은 <pre>태그로 변환되기 때문에 그 안에서는 다른 스타일을 주는 것이 불가능했습니다. 제가 생각할 수 있는 방법은 마크다운의 코드블락을 쓰지 않고 별도의 HTML을 사용해서 스타일을 지정하고 그에 대한 스타일을 주는 것이었는데 이유는 모르겠지만 pandoc이 임의의 HTML을 모두 날려버려서 이 방법도 사용할 수 없었습니다.

제대로 변환할 수 있는 방법이 없다는 것을 깨달았을 때쯤 Node.js에서 PDF문서를 생성할 수 있는 라이브러리인 PDFKit이 릴리즈되어서 직접 문서를 변환하는 코드를 짜기 시작했습니다. 한참 짜다가 책 쓰다가 이게 머하는 짓인가 싶어서 곧 접어버렸습니다. ㅠㅠ 결국 pandoc을 이용해서 epub과 pdf 문서를 생성하는 스크립트를 CoffeeScript의 Cake를 이용해서 작성했지만 위의 문제는 여전했습니다. 결국 최종 선택은 ByWord에서 작성한 문서를 Marked에서 커스텀 CSS로 HTML로 출력한 다음에 이를 복사해서 MS Word에 수동으로 붙혀넣었습니다. 그리고 굵은 글씨 처리가 필요한 코드에 대해서는 임의의 글자로 표시를 해 놓았다가 MS Word에서 수동으로 굵은 글씨 처리를 했습니다. ㅠㅠ

결국 수동으로 타협하고 자동화로 한방에 여러 문서로 만드는 방법은 현재로서는 실패했습니다. 변환해도 쓸 데가 없긴 하지만요. 그리고 작업을 하면서 마크다운으로 작업할 때의 느낀 문제점은 변환된 문서의 유효성을 검증할 수 있는 방법이 없다는 것이었습니다. 예를 들어 footnote설명과 코드블럭이 연이어 나타나면 footnote가 변환시에 사라지는 문제라거나 marked의 이전 버전에서 코드블럭에서 <script>코드를 작성하면 제대로 처리되지 않는 문제가 있었는데 검토하다가 찾아내기는 했지만 일일이 읽어보기 전에는 변환과정에서 삭제된 부분이 있어도 제대로 알 수 없다는 문제가 있었습니다. 앞으로도 계속 마크다운을 사용할 것이지만 저는 이 문제가 제일 큰 문제라고 생각되더군요.




본격적인 내용 작성
위는 책을 쓰는 내내 고민했던 부분이고 Node.js 프로그래밍이 나오기까지 #2에서 얘기했듯이 본격적으로 책을 쓰기 시작했지만 잘 써지지 않았습니다. 도입부 즉 Node.js에 대한 기본적인 설명을 쓰고 있었는데 진도가 잘 안나가고 고민만 계속 하고 있었습니다. Node.js에 대한 대략적인 설명을 해야 하는데 어떻게 설명해야 할지도 애매했고 어느정도까지 설명해야 할지도 어려웠습니다. 도입부에서 어느정도 설명하고 자세한 부분은 뒤에서 또 다뤄야 할텐데 뒷부분을 아직 안쓴상태에서 그에 대한 결정도 어려웠습니다. 한참을 1장만 고민하다가 뒤에서부터 써야겠다고 생각했습니다. 2장은 설치니까 나중에 쓰고 그 뒤부터는 각 기술에 대한 설명이니까 좀 쓰기 수월할 것 같아서 3장부터 쓰기 시작했습니다.

처음 책을 쓸 생각을 했을 때는 1년을 생각하고 있었습니다. 올해 여름정도를 생각하고 있었는데 특별한 이유가 있었다기 보다는 제 주위에 책 쓰시는 분들이 대부분 1년 이상정도는 쓴다고 생각했기 때문이죠. 그 때 이미 한권의 번역서가 출간예정으로 알고 있었고(결국 이 책은 못나왔습니다.) 에이콘에서도 번역서를 준비하고 있는 걸 알고 있었습니다. 초반부터 토비님은 번역서가 먼저 나오면 김빠진다고 빨리 내야한다고 계속 채찍질을 하셨지만 크게 맘에 두지는 않았습니다. 작업의 내용 자체가 속도로 앞지를 수가 없기 때문이죠 그럼에도 불구하고 (인셉션을 당한건지 몰라도)언제부터인지 저는 올해 초 출간을 노리고 있었고 후반부에가서는 작년 말 목표까지 일정을 땡기고 있었습니다. 원래 일정예측을 잘 못하는 저는 이게 어떤 작업인지도 잘 모른채 계약서를 쓸 때 11월 말까지 할까요 하시는데 10월 말까지 하죠! 라고 얘기했었습니다.

암튼 3장부터는 속도를 좀 내서 쓰기 시작했습니다. 각 장의 설명흐름에 어울리면서도 설명과 관계없는 코드는 최대한 줄이는 예제를 짜는 것 외에는 그래도 순조롭게(?) 글을 썼던 것 같습니다. 처음에 "책은 뭘 넣을 건지가 아니라 뭘 뺄건지가 중요하다"란 말을 계속 들었었는데 책의 분량만큼 채울 것도 없는데 무슨 말인가 싶었지만 이내 곧 이 말을 이해했습니다. 수많은 모듈들과 관련 내용들을 다 적을 수는 없었고 그 중에서 적절한 것은 무엇인가.. 꼭 필요한 것은 무언인가는 꽤나 고심되었습니다. 그렇다고 제가 다 써본것도 아니고 제가 써본 모듈이나 기능들이 다 좋다고 할 수도 없었습니다.(그런 면에서는 킬러앱인 express나 socket.io는 고민이 덜해서 나았습니다.)

그리고 9월 말정도에 책 원고의 끝이 보이기 시작하면서 베타리더들을 모으기 시작했습니다. 온라인에서 공개적으로 모집했을 때 피드백을 받을 수 있다는 보장이 없었기 때문에 지인들을 위주로 모았습니다. 총 6명을 모았는데 기술 검증을 해줄 Node.js의 고수분들 3분과 어찌 보면 대상 타겟인 프론트앤즈에 기반을 두고 node.js를 안해보신 1분, 서버쪽에 기반을 두고 node.js를 안해보신 1분과 node.js는 안해봤지만 프로그래밍에는 깊은 지식을 가지고 계신 한분으로 구성했습니다. 처음에 책을 쓰라고 꼬실 때 토비님이 "블로그에 글쓴거랑 이번에 발표한거 살만 붙히면 되요."라고 했단 말을... 겉으로는 "에이~"하면서 실제론 믿어버렸었는지도 모르겠습니다. 전 블로그에 글을 쓸때 탈고나 재검토같은건 잘 하지 않고 그냥 한번에 쓰는 편인데(문학적 소설이 아니기 때문이죠. ㅎ) 책도 그냥 한번에 죽~~ 쓰고는 들고 갔습니다. 문체를 이상하게 썼다고 출판사에서 빠꾸먹고 돌아와서 다시 문장검토에 들어갔습니다. 결국 10월초 예정이었던 베타리딩은 10월 중순이 넘어서야 시작할 수 있게 되었습니다.

이 당시만 해도 거의 끝까지 왔나보다 했지만 진짜 시작은 베타리딩부터였죠.. ㅠㅠ