심각한 현재 상황

현생인류 초기 손가락, 그림, 동굴벽화가 존재했다. 처음 그림을 그린 누구나 원하는 바를 생성할 수 있었다 – 전달 도구를 사용해서 상상하는 바를 생성할 수 있게 되었다. 연필과 종이도 그런 작업에 동원되었다: 그림과 텍스트가 저자가 원하는 바대로 종위위에 배열되었다.

첫 인쇄기계는 이런 점을 바꾸지는 못했다. 목판 조각으로 인쇄를 했지만, 여전히 저자는 원하는 장소 어디에나 원하는 바를 위치시킬 수 있다. 그리고 나서 1370년경, 한국의 장인이 가동활자(movable type)를 발명했다. 1440년경 유럽에 구텐베르그가 가동활자를 소개한 후에 들불처럼 번져나갔다. 더불어 손으로 글을 쓰는 인간에 대한 존경이 하락하기 시작했다.

가동활자는 조각가가 목판에서 생산하는 것보다 훨씬 더 빨리 대량으로 페이지를 인쇄업자가 설정하도록 한 반면에, 치뤄야 하는 댓가는 유연성이다: 필경사는 페이지 어디에도 글을 쓸 수 있는 반면에, 조판업자는 한줄에 균일한 크기 글자를 넣어야 했다. 그림도 여전히 가능했지만, 단어당 낮아진 가격은 상대적으로 그림이 더 고가로 인식되게 만들었다.

(1860년대 발명된) 타자기는 수백만 중산층 손에 “인쇄기”를 쥐어주었다. 기계식, 전기식, 그리고 나서 전자식 컴퓨터는 저작물을 출력하는데 활용된 타자기 기술을 재사용했다. 1950년대 펜플롯터(pen plotter)¹가 첫선을 보였을대, 라인 프린터를 대체하기에는 너무 느렸고, 너무 비쌌다. 더 심각한 문제는, 두가지 기술 모두 잘 동작하지는 못했다: 아스키 예술(ASCII art)로 그림을 도식화하거나, 문자를 펜플롯터로 작성하는 것이 가능했지만, 둘 중 어는 것도 딱히 매력적이지는 못했다.

문자전용 도구와 그림을 위한 도구 사이 간격을 보여주는 한가지 흔적이 문자와 그림을 제어하기 위한 별도 언어개발에서 찾아볼 수 있다. 플로터는 일반적으로 제도 언어(drawing language) 로 제어된다. 다음 예를 보면 이해가 쉽다. “펜을 위로, (x, y) 위치로 이동, 펜을 아래로, 다시 해당 위치만큼 이동한다”

PU;
PA200,150;
PD;
PA250,250;

반대로, 라인 프린터를 위한 조판 언어(Typesetting language) 로 저자는 컴퓨터에 두번째 제목으로 문구를 설정하고, 단어를 이탤릭체로 설정하게 지시한다. 그러고 나면, 컴퓨터가 단어 위치와 외양을 결정한다.

.t2 Section Heading

Empty lines separate
.it paragraphs
and lines starting with '.' are commands.

이 기간동안에 세번째 유형의 언어가 생겨났는데, 외양 보다는 문서 내용물 을 기술하려고 초점을 뒀다. 의사와 변호사는 환자 진료기록과 판례를 검색하고자 했지만, 그당시 컴퓨터가 자연어를 처리할만큼 강력하지 못했다. 그래서, IBM 같은 회사가 마크업 언어 를 개발해서, 사람들이 문서의 의미 즉 시맥틱 을 명시적으로 기술하게 만들었다:

<person>Derstmann</person> still questions the importance of <chemical>methane</chemical> release
in <event>the Fukuyama disaster</event>.

세가지 세계가 1970년대 레이져 프린터의 발명으로 충돌했고, 1980년대 고해상도 컴퓨터 화면과 1990년대 월드와이드웹으로 확대만 되었다. 다른 한편으로, 대부분의 사람들은 단순히 저작만을 원했다 – 이 단어는 여기에, 저 단어는 저기에, 단어중 일부는 녹색으로, 다른 단어는 이탤릭으로 … 아래한글, 마이크로소프트 워드, 맥라이트 같은 위지윅(WYSIWIG, What You See Is What You Get) 편집기가 이런 요구를 채워줬지만, 이런 방식으로 만들어진 문서는 두가지 결점을 갖고 있다:

1. 융통성이 없다(rigid). 누군가 수작업으로 배치를 바꾸고 나서, 페이지 크기를 변경하면, 다시 재작업을 수행해야만 된다.

2. 불분명하다. 컴퓨터에 무언가 이택릭으로 표현하도록 지시하면, 해당 문구가 책제목인지, 혹은 새로운 용어를 정의하는지 분간할 수 없다.

조판언어와 마크업 언어는 상기 두가지 문제를 다루고 있다. 텍스트와 그림 외양과 페이지 위치에 대해 언급하는 대신에, 저자는 컴퓨터에 텍스트와 그림이 어떤 유형인지를 전달한다: 예를 들어, 제목 혹은 신규 용어. 그리고 나면, 컴퓨터가 외양이 어떨지, 어디에 위치해야 될지 결정한다. 시맨틱 의미와 외양을 이런 방식으로 구별하게 되면 저자는 쉽고 일관성을 갖고 스타일을 전환할 수 있게 된다. 예를 들어, “모든 두번째 제목을 16 포인트, 나눔고딕체로 왼쪽정렬하라.”

하지만, 이런 접근법도 결점은 있다:

1. 컴퓨터는 사람이 하는 방식으로 텍스트를 항상 배치하지 못하는데 이유는 컴퓨터 이해도가 떨어지기 때문이다. 따라서 융통성 없음을 다시 재도입하는 한이 있더라도, 사람이 항상 컴퓨터가 선택한 것을 중단시킬 수 있어야 된다.

2. 문서에 시맨틱 의미를 명세하는 것이 대부분 사람에게 외떨어져 보이고, 제목을 몇배 확대하는 것보다 많은 작업이 필요하다.

3. 저자가 타이핑한 것을 이해하고 어떻게 표시할지 파악하는데 컴퓨터 시간이 든다. 왜 문서가 의도한 바를 반영하지 못하는지 알아내는데는 몇배 시간이 든다; 이것이 정확하게 프로그램을 디버깅하는 것과 같고, 디버깅은 대략 난감한 작업이다.

지금까지 그 누구도 상기 문제를 모두 피하는 무언가를 발명하지는 못했다. 그래서, 저작을 할 때면 오늘날 연구자를 비롯한 많은 분들이 다양하고 혼동되는 선택지를 받게 되었다:

1. 아래한글, 리브레오피스, 마이크로소프트 워드 같은 데스크톱 위지윅 도구 (리브레오피스와 워드는 .docx 파일형식으로 호환 동작된다). 지금까지 편지같은 단순한 저작물을 생성하는 가장 쉬운 방식이지만, 융통성이 없고, 불명확하고 수식을 배치하는 기능이 상대적으로 미약하고, 버젼제어 시스템과 궁합이 맞지 않는다.

2. 구글 독스 같은 웹기반 위지윅 도구. 워드나 한글, 리브레오피스의 신속성을 갖추고, 더불어 협업을 수월(왜냐하면 모든이가 문서 사본 하나만 공유하기 때문)하게 한다. 하지만, 웹기반 위지윅 도구는 여전히 융통성이 없고 불명확하며, 책임을 질 수 없는 개인회사 바구니에 모든 달걀을 놓는 것에 많은 사람들이 불편해하고 있다.

3. 데스크톱 LaTeX. 강력한 조판언어로 수식과 참고문헌관리에 정말 훌륭한 기능을 제공한다. 버젼제어 시스템과 조화가 잘 되는데, 일반 텍스트로 문서를 저작하기 때문이다. 하지만, 지금까지 학습하기 가장 복잡하고, 텍스트와 그림을 원하는 곳에 배치시키는 작업이 고생스럽게도 수시간 소요될 수 있다.

4. Authorea, Overleaf 같은 웹기반 도구는 위지윅 편집 인터페이스를 저자에게 제공하지만 문서는 LaTeX으로 저장되고, 변경사항을 타이핑해서 넣을 때마다 실시간으로 화면에 다시 출력해서 보여준다.

5. HTML. 웹의 네이티브 언어로 LaTeX 보다 훨씬 (훨씬) 더 단순하지만, 훨씬 더 적은 기능을 제공한다: 주석, 참고문헌관리, 절마다 번호매기기 같은 단순한 기능도 직접적으로 지원되지 않는다. 상당히 버보스하게 상세할 수도 있고, CSS²는 변덕스러운 것으로도 유명하다.

6. 마크다운 : HTML에 대한 단순화 대안으로 개발되었다. 마크다운은 일반-텍스트 전자우편 관례를 사용한다: 빈줄은 문단을 구분하고, 이탤릭체로 만드는데 *별표*로 감싸는 등등. HTML보다 더 적은 작업을 수행하지만, 타이핑 양은 훨씬 더 적다. 하지만, 불행하게도 거의 모든 마크다운 구현결과물이 자체적인 기능이 추가되어서 “마크다운 표준”은 모순어법에 해당된다.

HTML과 마크다운은 직접적으로 수식을 지원하지 않지만, 플러그인 혹은 팩키지가 존재해서 저자가 LaTeX-유형의 수식을 문서에 삽입할 수 있다. 쥬피터 노트북(Jupyter Notebook)은 이런 팩키지에 의지해서 사용자가 수식과 기타 다른 것들을 마크다운 셀에 넣어서 브라우져에서 렌더링할 수 있게 구현한다.

저작 도구를 선택할 때 마지막으로 고려할 점은 LaTeX 같은 데스크톱 텍스트 기반 시스탑과 재현가능 연구를 지원하는 연산기능을 관리하는 다른 도구를 적절히 통합하는 것이다. 적어도 지금으로는 전형적인 지구물리학 혹은 생물정보학 파이프라인과 구글 독스 혹은 리브레오피스를 통합하는 것이 훨씬더 복잡하다. 예를 들어, 데이터가 변경될 때 그림이 자동으로 갱신되는 것을 들 수 있다.

가까운 장래에는 과학 연구자 상당수가 순수 텍스트 조판 툴로 바꾸기 보다는 계속해서 위지윅 편집기 혹은 연관된 파일형식을 사용할 것이다. Authorea와 Overleaf 같은 하이브리드 시스템이 이러한 절벽을 경사로로 바꿀 것이고, 프로그래머가 궁극적으로 다른 99% 사용자가 선호하는 문서형식에 체면을 갖추고 관심을 가질 것이지만, 수년간의 작업이 소요될 것이다.

대부분 과학분야 연구원이 이미 아래한글, 마이크로소프트 워드 같은 데스크톱 위지윅 시스템과 구글 독스같은 클라우드 대체 소프트웨어와 친숙하기 때문에, 순수 텍스트 대체 언어만 다룰 예정이다: 웹사이트와 블로그를 위한 마크다운, 원고 저작을 위한 LaTeX. 웹에는 마크다운을 추천하는데 이유는 대부분 사람이 HTML로 원하는 모든 것을 그다지 많이 타이핑하지 않고도 수행하기 때문이다. 원고 저작에 (적어도 지금은) 마크다운을 추천하지 않는다. 이유는 다음과 같다:

• 저널 대부분이 제출형식으로 받아주지 않기 때문이다.
• 고위 연구협력자가 이를 받아줄 가능성은 없다. (물론, 고위 연구협력자가 LaTeX을 사용하지 않았다면, LaTeX으로 전환하지도 않을 것이다…).
• 과학연구원이 원하는 기능 상당수를 마크다운이 지원하는 않는다. (예를 들어, 참고문헌 서지관리)

반면에 LaTeX을 추천하는 이유는 다음과 같다:

• PDF와 다른 표준형식으로 컴파일 작업을 수행한다.
• 그림과 표를 배치하는데 탁월한 성능을 보여준다.
• 버젼제어와 잘 묶어 작업할 수 있다.
• 서지관리 소프트웨어 상당수와 호환된다.
• 많은 저널에서 받아주는 형식이다. (하지만, 학문 분야마다 상당한 다양성이 존재한다.)