markdown_mess.qmd

---
editor: 
  markdown: 
    wrap: 72
---

# 심각한 현재 상황

초기 현생인류는 손가락, 물감, 동굴 벽화를 통해 자신의 생각과 감정을
표현했다. 이러한 원시적인 도구들을 활용해 사람들은 상상의 세계를 현실로
구현할 수 있었다. 시간이 흐르면서 손가락과 물감은 연필로, 동굴 벽화는
종이로 대체되었고 이렇게 진화된 도구들 덕분에 저자들은 이제 자신의
의도와 생각을 종이 위에 문자와 그림으로 자유롭게 표현할 수 있게 되었다.

처음으로 인쇄기가 등장했을 때 자신의 의도를 문자와 그림으로 자유롭게
표현하는 자유는 크게 변화하지 않았다. 목판을 이용한 인쇄 방식이었지만,
작가는 여전히 원하는 내용을 원하는 위치에 놓을 수 있었고, 1370년경
한국에서 가동활자가 발명되고, 1440년경 유럽에서 구텐베르그가 금속활자가
대중화되면서 인쇄술이 급속히 확산되었다. 이로 인해 수기로 글을 쓰는
필경사에 대한 존경은 점차 감소하기 시작했다.

활자를 사용하면 인쇄업자가 목판을 제작하는 것보다 훨씬 신속하게 인쇄면를
설정할 수 있는 장점이 있었지만 유연성이 떨어졌다. 이유는 조판업자는
일정한 크기 글자를 일렬로 배치해야 했기 때문이다. 필경사도 원하는 곳
어디에나 글씨를 써 넣든 그림을 그려 넣던 자유로웠던 시절은 점차 사라지기
시작했다. 도표는 여전히 가능했지만, 글자 비용이 낮아지면서 상대적으로 몇
배나 더 비쌌다.

1860년대에 발명된 타자기는 중산층 수백만 명에게 '인쇄'를 가능하게 했다.
기계식, 전기식, 전자식 컴퓨터는 모두 타자기 기술을 재활용하여
인쇄출력물을 생성했다. 1950년대 등장한 펜 플롯터 [^markdown_mess-1]는
라인 프린터를 대체하기에는 너무 느리고 비쌌다. 더 큰 문제는 두 기술 모두
완벽하게 작동하지 않았다는 것이었다. 아스키 예술로 그림을 표현하거나,
펜플롯터로 문자를 작성하는 것은 가능했지만, 어느 것도 특별히
매력적이라고 할 수 없었다.

[^markdown_mess-1]: [플로터(plotter)](https://ko.wikipedia.org/wiki/플로터):
    그래프나 도형, CAD, 도면 등을 출력하기 위한 대형 출력장치다.

## 세가지 패러다임

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

"펜을 위로, (x, y) 위치로 이동, 펜을 아래로, 다시 해당 위치만큼
이동한다"

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

반면에, 라인 프린터는 **조판 언어(Typesetting language)**를 사용하여
제어된다. 이 언어를 통해 저자는 컴퓨터에게 "두 번째 큰 제목을
설정하라"나 "특정 단어를 이탤릭체로 표시하라"와 같은 지시를 할 수 있다.
이러한 지시를 받은 컴퓨터는 단어 위치와 형식을 자동으로 결정한다. 조판
언어를 통해 문자 배치와 스타일을 정교하게 제어할 수 있게 되었다.

``` yaml
.t2 Section Heading

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

이 기간 동안, 문서 *외양*이 아닌 *콘텐츠(content)*에 중점을 둔 세 번째
유형의 언어가 등장했다. 의사나 변호사들은 환자 진료기록이나 판례를
효율적으로 검색하고자 했으나, 1970년 당시 컴퓨터는 자연어 처리 능력이
턱없이 부족했다. 당시 최고의 기술력을 자랑하던 IBM과 같은 컴퓨터
기업들이 *마크업 언어*를 개발했다. 마크업 언어를 통해 사람들은 문서
의미, 즉 *시맨틱(semantic)*을 명시적으로 표현할 수 있게 되었다. 마크업
언어는 문서 내용과 구조를 명확하게 기술하게 되면서, 정보 검색과 데이터
관리에 있어 새로운 가능성을 열었다.

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


## 패러다임의 충돌

이 세 가지 패러다임은 1970년대 레이저 프린터 발명 이후에 충돌했고, 
그 긴장감은 1980년대 고해상도 컴퓨터 화면과 
1990년대 월드 와이드 웹에 의해 더욱 확대되었다. 
한편으로 대부분의 사람들은 단순히 글을 저작하는 것이 목표다.
예를 들어, 이 단어는 여기에, 저 단어는 저기에 놓거나, 일부 단어는 녹색으로, 다른 단어는 이탤릭체로 만들고 싶어하는 것이 전부다. 
우리나라에서 아래한글, 전세계적으로 맥사용자는 맥라이트, 윈도우 사용자는 마이크로소프트 워드, 리눅스 사용자는 리브레오피스 라이터(LibreOffice Writer)나 오픈오피스 라이터(OpenOffice Writer)와 같은 위즈윅(WYSIWIG) 편집기가 이러한 저자들의 욕구를 충족시켰지만, 이런 방식으로 만들어진 문서는 두가지 결점을 갖고 있다:

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

2.  *불분명하다*. 컴퓨터에 무언가 이택릭으로 표현하도록 지시하면, 해당
    문구가 책제목인지, 혹은 새로운 용어를 정의하는지 분간할 수 없다.
    
즉, 아래한글과 워드 같은 위지윅 편집기로 생성된 문서는 종종 특정 플랫폼이나 소프트웨어에 종속되어 다른 시스템에서 문서를 편집하거나 여는 것조차 불가능하다. 이유는 위지윅 편집기가 주로 시각적인 표현에 중점을 두다보니 아래한글, 워드 문서파일 자체적으로 복잡한 내부 구조를 가지고 있고 문서 내용과 구조를 명확하게 구분하지 않아서 문서 내용을 다른 형식으로 변환하거나 자동화하는 것이 어렵다.
    

조판 언어와 마크업 언어는 앞서 언급한 두 가지 문제를 해법을 제시한다. 
저자는 텍스트나 그림 외관과 페이지 내 위치에 대한 직접적인 지시를 내리는 대신, 그것들이 어떤 유형인지—예를 들어 제목이나 새로운 용어인지—컴퓨터에게 알려준다. 컴퓨터는 입력을 받은 후에 그것들의 외관과 위치를 결정하여 표현한다. 이러한 방식으로 의미(시맨틱)와 외관을 분리하면, 저자는 "모든 두 번째 제목을 16포인트 나눔고딕체로 왼쪽 정렬하라"와 같이 지시를 내리면, 스타일도 일관되게 쉽고 빠르게 변경시킬 수 있다.

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

1.  컴퓨터는 텍스트를 이해하지 못하기 때문에 항상 인간과 같은 방식으로
    텍스트를 배치하지는 않는다. 따라서 사람들은 나중에 문서 유연성이
    떨어지더라도 직접 변경하고 싶어 하는 경우가 많다. 
    예를 들어, 논문을 작성할 때 컴퓨터가 자동으로 생성한 목차나 참고문헌
    위치가 저자 의도와 맞지 않을 수 있다. 이런 경우, 
    저자가 수동으로 목차를 조정하면, 나중에 문서 다른 부분을 수정할 때 
    목차도 다시 수동으로 조정해야 하는데 이렇게 되면 원래 자동화를 통해 
    얻을 수 있던 유연성이 사라지게 된다.

2.  문서의 의미를 지정하는 것은 대부분의 사람들에게 낯선 일이며 제목을
    몇 번 확대하는 것보다 훨씬 더 많은 작업이 필요하다. 예를 들어, 
    연구 논문을 작성하고 제목과 부제목을 강조하고 싶다고 가정해 보자. 
    아래한글을 사용한다면 제목 텍스트를 선택하고 "굵게"와 
    "글자 크기 키우기" 버튼을 클릭하기만 하면 된다. 하지만, 
    라텍이나 마크다운 같은 마크업 언어를 사용한다면, 
    제목을 특정 코드로 감싸서 그것이 '제목'임을 라텍에서 
    `\title{나의 연구 논문}`과 같이 작성해야 한다. 
    마크업 언어에 익숙하지 않은 저자는 불필요한 추가 작업처럼 
    느껴지고 전혀 직관적이지 않다.

3.  저자가 입력한 내용을 해석하고 표시할 내용을 파악하는 데는 컴퓨터
    시간이 오래 걸린다. 왜 문서가 의도한 바를 반영하지 못하는지
    알아내는데는 몇배 시간이 든다. 이것이 정확하게 프로그램을 디버깅하는
    것과 같은 상황이고 디버깅은 대체로 쉽지 않은 작업이다. 
    예를 들어, PPT 슬라이드에 제목과 몇 개의 항목을 넣었을 때
    컴퓨터가 자동으로 항목 크기를 줄인다. 이에 불만족해 
    수동으로 크기를 다시 조절하게 되는데, 원인은 컴퓨터가 
    사용자 의도를 완벽히 이해하지 못하기 때문에 발생된다.

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

- 아래한글, 리브레오피스, 마이크로소프트 워드 같은 **데스크톱 위지윅 도구**: 
편지와 같은 간단한 문서를 만드는 가장 쉬운 방법이지만, 유연성이 떨어지고, 수식이나 버전 관리 시스템과 호환성이 좋지 않다.

- 구글 독스 같은 **웹기반 위지윅 도구**: 워드나 한글, 리브레오피스와 비슷한
신속성을 갖추면서 협업도 수월(왜냐하면 모든이가 문서 사본
하나만 공유하기 때문)하지만, 여전히 유연성이 떨어지고 개인 정보를 민간 기업에 의존하는 것에 대한 불안감이 증가하고 있다. 

- **데스크톱 라텍(LaTeX)**: 강력한 조판언어로 수식과 참고문헌 관리기능이 뛰어나고, 텍스트 형식으로 문서를 작성하기 때문에 버전 관리와도 잘 호환되지만, 지금까지 학습하기 가장 복잡하고, 텍스트와 그림을 원하는 곳에 배치시키는 작업에 많은 시간이 소요된다.

- [Authorea](https://www.authorea.com/),[Overleaf](https://www.overleaf.com/) 같은 웹기반 도구: 위지윅 편집 인터페이스를 저자에게 제공하지만 문서는 라텍으로 저장되고, 변경사항을 타이핑해서 넣을 때마다 실시간으로 화면에 다시 출력해서 보여준다.

- **HTML**:  웹의 기본언어로 라텍보다 훨씬 (훨씬) 더 단순하지만, 훨씬 더 적은 기능을 제공한다: 주석, 참고문헌 관리, 절마다 번호매기기 같은 단순한 기능도 직접적으로 지원되지 않는다. CSS[^markdown_mess-2]는 브라우저에 어떻게 표시할지 지시하는 언어로 복잡한 것으로 유명하다.

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

- [**마크다운**](http://daringfireball.net/projects/markdown/): 일반-텍스트 전자우편 관례를 사용하여 HTML 간소화 대안으로 개발되었다. 빈줄은 문단을 구분하고, 이탤릭체로 만드는데 `*별표*`로 감싸는 등등. HTML보다 더 적은 작업을 수행하지만, 타이핑 양은 훨씬 더 적지만, 불행하게도 거의 모든 마크다운 구현결과물이 자체적인 기능이 추가되어서 "마크다운 표준"은 모순어법으로 볼 수 있다.
    

마크다운은 라텍과 HTML의 중간 정도의 복잡성을 갖고 있고, 라텍과
마찬가지로 텍스트 파일로 저장되기 때문에 버전 관리 시스템과 잘
호환된다. HTML과 마크다운 모두 직접적으로 수식을 지원하지 않지만, 플러그인 혹은 팩키지가 존재해서 저자가 LaTeX-유형 수식을 문서에 삽입할 수 있다.

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


## 엎친 데 덮친 격

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

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

강성 프로그래머는 위지윅 도구와 텍스트가 아닌 형식을 조롱할 수도 있지만,
그들도 완벽하지 않다.  마이크로소프트 워드와 한글과 컴퓨터 아래한글은 수십년 동안 존재해왔고, 그 기간 동안 문서 형식이 몇 번이나 바뀌었다. 그럼에도 불구하고, 명령줄을 선호하는 개발자는 이를 대체할 도구를 개발하지 못했다. 결과적으로, 버전제어 시스템 대부분은 세계에서 가장 널리 사용되는 문서 형식을 처리할 수 없다. 예를 들어, Git 같은 시스템은 두개 다른 버전의 마이크로소프트 워드 파일 혹은 아래한글 파일을 만났을 때 "차이가 있음" 정도만 제시할 수 있을 뿐이다. 이러한 상황은 미래 더 큰 생산성을 희망하며 수년 동안 효율적으로 사용해온 도구를 포기해야 한다는 것을 의미한다. 결국 버전 관리 도입은 미래의 생산성 향상을 위해 자신과 동료들이 수년간 생산적으로 사용해 온 도구를 버려야 하는 결과를 초래한다.

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

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

> 공동작업하는 지친 물리연구원에게 문서를 컴파일하는 개념을 설명하려고
한다고 보자. 그전에 일반 텍스트와 워드 프로세싱 사이 차이점을 설명해야
된다. 그리고 텍스트 편집기도 잊으면 안된다. 그리고 나서 마크다운/LaTeX
컴파일러. 그리고 BiBTeX. Git 그리고 GitHub 등등. 그러는 동안에 연구원은
다른 곳에서 호출 연락을 받을 것이다...
> 
> ... 달리 설득시킬만큼 노력하지만, 과학컴퓨팅 외부 사람들과 협업할 때,
이러한 얼개를 갖고 논문 협업을 하는 장벽이 너무나도 높아서 단순히 극복이
되지 않는다. 좋은 취지는 제쳐두고, 항상 "검토 메뉴에 변경내용 추적을
갖는 워드 문서만 주세요" 혹은 그와 유사하게 끝나게 된다.


가까운 장래에도 저작자 상당수는 순수 텍스트 조판 도구로 바꾸기 보다는
계속해서 위지윅 편집기를 사용할 것이다. [Authorea](https://www.authorea.com/)와
[Overleaf](https://www.overleaf.com/) 같은 하이브리드 시스템이 절벽을 완만한 경사로로 바꿀 것이고, 프로그래머가 궁극적으로 다른 99% 사용자가
선호하는 문서저작에 관심을 가질 것이지만 수년에 걸친 작업량이 될 것이다.

저작자 대부분이 이미 아래한글, 마이크로소프트 워드 같은
데스크톱 위지윅 시스템과 구글 독스같은 클라우드 대체 소프트웨어와
친숙하기 때문에 기존 관행이 바뀌기는 어렵다. 
하지만, 웹사이트와 블로그를 위한 마크다운, 논문 원고저작을 위한 
라텍이 여전히 영향력이 강하다. 웹 문서작업에 마크다운으로 HTML 문서를 저작하는데 큰 어려움이 없지만, 논문 원고저작에 마크다운을 사용하면 학술지 대부분은 받아주지 않고, 이미 라텍을 사용하고 있는 동료 저작자가 라텍을 버리고 마크다운을 채택할 가능성도 낮고, 저작자들이 문서작업에서 원하는 상당수 기능(예를 들어, 참고문헌 서지관리)을 구현하지 못하고 있다.
반면에 라텍은 PDF 형식으로 컴파일할 수 있고, 그림과 표 레이아웃을 잘 처리하고 버전 제어 시스템과 호환되며, 다양한 문헌 관리 소프트웨어와도 호환되지만 블로그와 웹사이트로 대표되는 웹 출판에 적합하지 않다.