4  심각한 현재 상황

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

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

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

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

4.1 세가지 패러다임

문자전용 도구와 그림을 위한 도구 사이 간격을 보여주는 한가지 흔적이 문자와 그림을 제어하기 위한 별도 언어개발에서 찾아볼 수 있다. 플로터는 일반적으로 제도 언어(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.

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

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

4.2 저작도구 쓰임새

세가지 세계가 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 보다 훨씬 (훨씬) 더 단순하지만, 훨씬 더 적은 기능을 제공한다: 주석, 참고문헌관리, 절마다 번호매기기 같은 단순한 기능도 직접적으로 지원되지 않는다. 상당히 버보스하게 상세할 수도 있고, CSS2는 변덕스러운 것으로도 유명하다.

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

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

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

엎친 데 덮친 격

위지윅과 조판/마크업 구분은 실제 파일형식보다 도구로 작업하는 것에 더 연관되어 있다: .docx 파일은 실제로 LaTeX, HTML, 마크다운 파일처림 조판 명령어와 텍스트가 혼재되어 있다. 차이점은 조판/마크업 언어로 작성된 명령어는 사람이 읽을 수 있는 텍스트로 저장된다는 것이다. 이것이 함의하는 바는 유닉스 명령-라인 유틸리티가 처리할 수 있다는 점이다. (스택오버플로우에서 지적한 것처럼, 실제로 얼마나 많은 작업 수행할지에 대해 한계가 존재한다) 이와 비교해서, 아래한글, 마이크로소프트 워드, 리브레오피스에 내장된 서식 명령어는 특정한 전용 프로그램을 위해, 특정 프로그램에 의해서 제작되었다. 따라서, grep 같은 일반-텍스트 도구로는 처리가 되지 않는다.

구글 독스도 마찬가지다: 서식 명령어가 문서에 내장되어서 사용자가 상호작용하는 페이지를 렌터링해서 생성할 때 사용자 브라우져에서 돌고 있는 자바스크립트로 실행된다. 저장형식이 LaTeX이라는 점을 제외하면, Authorea 와 Overleaf 도 동일한다.

강성 프로그래머는 위지윅 도구와 텍스트가 아닌 형식을 조롱할 수도 있지만, 기초는 진흙으로 만들어져 있다. 마이크로소프트 워드는 수십년동안 시장을 지배하고 있다; 이 기간동안 문서형식은 몇번 변경되었지만, 명령-라인 애호가는 충분한 시간을 갖고 선호하는 도구로 이를 처리할 수 있었다. 하지만, 그런 일은 일어나지 않았다. 이것이 의미하는 바는 버전제어 시스템 대부분이 세상에서 가장 널리 사용되는 문서형식을 처리할 수 없다는 점이다: 두가지 다른 마이크로소프트 워드 파일을 마주쳤을 때, Git과 Git의 친족은 “차이가 탐지되었습니다”라고 말하는 것이 전부다. 전체적인 효과는 버전제어를 도입하려는 누구나 본인과 동료가 언젠가는 엄청난 생산성 향상을 목표로 도입하여 수년동안 사용한 도구를 포기하는 것이다.

상기 논의는 저자가 논문과 편지만 작성하다고 가정했지만, 과학연구자는 자주 본인 작업을 시연하는데, 포스터와 슬라이드 자룔를 생성할 필요가 있다. 파워포인트는 말이 필요없는 발표도구의 여왕이다: 많은 사람들이 파워포인트 때문에 발표가 엉망이 되어다고 비판하지만, 이것은 마치 시적 표현이 좋지 못한 것을 만연필 핑계를 대는 것에 비견된다. 파워포인트와 파워포인트 짝퉁은 컴퓨터 화면을 마치 칠판처럼 사람들이 쉽게 사용할 수 있게 만들었다. 중요항목 목록으로 구성된 너무나도 지루한 슬라이드를 쭉 생성할 수도 있지만, 쉽고 자유롭게 이미지, 도표, 텍스트를 섞어 사용할 수도 있다. LaTeX과 HTML로 그런 작업을 수행할 수 있지만, 어느쪽도 그다지 쉽지는 않다. 사실, LaTeX이나 HTML 모두 어려워서 대부분 사람들은 신경도 쓰지 않는다. 설사 그런 작업을 수행한다손 치더라도, 그래픽적인 요소는 문서의 중요한 부분이라기 보다는 외부 삽입에 불과하다.

논문과 발표자료를 함께 생각하면 다소 불편한 상황에 있음을 인지하게 된다. 다른 한편으로, 논문과 발표자료는 연구 프로젝트에서 핵심적인 부분으로 코드와 데이터처럼 공유되고 추적관리되어야 한다. 다른 한편으로 스테픈 터너(Stephen Turner)는 다음과 같이 언급했다:

공동작업하는 지친 물리연구원에게 문서를 컴파일하는 개념을 설명하려고 한다고 보자. 그전에 일반 텍스트와 워드 프로세싱 사이 차이점을 설명해야 된다. 그리고 텍스트 편집기도 잊으면 안된다. 그리고 나서 마크다운/LaTeX 컴파일러. 그리고 BiBTeX. Git 그리고 GitHub 등등. 그러는 동안에 연구원은 다른 곳에서 호출 연락을 받을 것이다…

… 달리 설득시킬만큼 노력하지만, 과학컴퓨팅 외부 사람들과 협업할 때, 이러한 얼개를 갖고 논문 협업을 하는 장벽이 너무나도 높아서 단순히 극복이 되지 않는다. 좋은 취지는 제쳐두고, 항상 “검토 메뉴에 변경내용 추적을 갖는 워드 문서만 주세요” 혹은 그와 유사하게 끝나게 된다.

4.3 과학기술 저작도구

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

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

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

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

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

  1. 플로터(plotter): 그래프나 도형, CAD, 도면 등을 출력하기 위한 대형 출력장치이다.↩︎

  2. 종속형 시트, 캐스케이딩 스타일 시트(Cascading Style Sheets, CSS) - 종속형 시트 또는 캐스케이딩 스타일 시트(Cascading Style Sheets, CSS)는 마크업 언어가 실제 표시되는 방법을 기술하는 언어로, W3C의 표준이며, 레이아웃과 스타일을 정의할 때의 자유도가 높다.↩︎