2010년 7월 8일 크레올이냐 마크다운이냐
레딧에서 누가 위키크레올이 좋다고 하는 얘기를 듣고 이런 반박을 써 냈는데, 이왕 하는 김에 좀 더 반박을 해 보자. (제목이 어째 미안하게도 이전 글과 비슷하게 되었다…)
레딧에 썼듯, 마크다운이 다른 수많은 위키 문법들(특히 크레올)을 발라 버리는 이유는 몇 가지가 있다.
- 플레인 텍스트에 가깝다. 적어도 영어권에서 자주 사용하는
_emphasis_나*emphasis*같은 문법이 곧바로 지원되고, 총알 목록(bullet list, 그러니까 순번이 없는 목록)에서 총알에 무슨 글자를 써야 하는지 고민할 필요도 없다. - 그러면서도 처음 봤을 때 모호함이 많지 않다. 예를 들어 내가 지적한 링크 문법1은 사실 링크 텍스트와 링크 주소 간에 대칭성이 없어야 비로소 해결되는 문제인데
[text](url)문법은 이 조건을 충분히 만족된다. - 이건 순전히 구현체의 문제긴 하지만, 마크다운은 수많은 구현체가 존재하는 반면 대부분의 위키 문법은 그 문법을 구현하는 하나의 위키 엔진만이 구현체가 된다. 심지어 표준화를 한답시고 만든 크레올조차 일부 위키에서 “선택적”으로 지원할 뿐이다. (나는 기본적으로 탑재가 되어 있지 않으면 이런 종류의 표준화가 전혀 쓸모가 없다고 본다. 예를 들어 크레올 쪽에는 도쿠위키가 크레올 지원을 한다고 쓰여 있으나, 사실 문법 플러그인 하나 달랑 있을 뿐이고 popularity 보면 알겠지만 사용하는 곳도 별로 없다.)
물론 이럼에도 불구하고 마크다운이 지적받는 몇 가지 문제가 있긴 하다. 공평하게 말하자면, 마크다운은 다른 위키 문법보다 좀 나은 편이지 최적의 문법은 아닌 것이다. 이를테면:
- 확장에 부적합하다. 이는 마크다운 기본 문법 및 많이 쓰이는 확장들이 이미 상당히 많은 수의 좋은 특수문자를 잡아 먹은 덕택에 남은 특수문자라는 것이
@,&같은 일반 텍스트에서 많이 나올 법한 것들 밖에 없기 때문이다. 마크다운 오리지날 버전은 이 문제를 HTML 문법을 그대로 쓰는 방법으로 피해 가려고 했던 것 같지만, 전혀 상식적인 발상이 아니다. (그럼 유튜브 동영상 넣고 싶으면 object 태그 다 넣을래?) - 공백 문자에 지나치게 의존한다. (이 문제를 잘 설명하는 좋은 예로 크레올 측의 예시를 보시라. 이 쪽은 공백은 아니지만.) 특히 뒤에 공백 두 개 넣으면 줄바꿈이 되는 문법은 마크다운 문법에서 최악의 선택으로 길이 길이 남을 것이다. 다행히도 공백 문자를 “아주” 많이 써야 하는 경우는 포매팅되지 않은 텍스트 정도에 지나지 않고 그마저도
~~~~를 사용한 delimited block으로 대체되는 추세이긴 하지만… - 좋은 개발 모델이 부족하다. 크레올은 그래도 나름 기존의 위키 문법들을 분석하고 샘플 텍스트들의 분포도 분석하고 다른 위키 구현체들의 의견도 받아서 자기 딴에는 그럴듯한 문법을 만들어 냈다고 하고 있지만, 마크다운은 한 번 나온 뒤로 업데이트는 그냥 망해 버렸다.
그러니까 빨리 pandoc이 표준 마크다운 구현이 되어야 할텐데… - 좋은 개발 모델의 부재로 인해 확장들이 다소 난립하는 경향이 있다. 다행히 마크다운 엑스트라는 다들 채용하고 있는 것 같지만 그 이상의 확장, 이를테면 github에서는 낱말 안의 밑줄을 문법으로 해석 안 한다거나… 하는 쓸만하긴 한데 구현체마다 제각기 다른 확장들은 답이 없다.
- 물론 마찬가지 이유로 좋은 테스트 슈트도 모자란다. (레딧에서 내 의견에 누군가가 답글을 달면서 언급했듯, 이 문제는 “마크다운은 파싱이 어렵다”라는 인식을 만들어 내는 데도 한 몫 했다. 사실 마크다운은 공백에 의존한다는 점만 주의한다면 파싱이 그다지 어렵지 않다.)
내가 위키 문법이 마크다운에 비해서 절대적으로 우위를 차지하고 있는 거의 유일한 분야라고 생각하는 건 단연 확장 부분이다. 당연한 얘기지만 자기가 마음대로 정할 수 있다면 확장도 수월할 수 밖에. 이걸 좀 더 깊게 생각하면, 많은 부분에서 확장에 필요한 것은 완전히 새로운 문법보다는 기존에 존재하는 문법에 추가적인 정보를 덧붙이는 것이고, 이 annotation 기능은 위키 문법이든 마크다운이든 그다지 썩 좋은 게 없다. (이 면에서는 reStructuredText가 굉장히 좋은 편이다. 단지 널리 안 쓰일 뿐.) 예를 들어서 위에 언급한 유튜브 동영상 보여 주는 것은 단순히 링크에 “이 링크는 유튜브 동영상을 가리킨다”는 annotation만 있어도 충분한 것이다. 마크다운을 가상으로 확장해서 예제를 써 본다면:
아라카와 언더 더 브릿지 오프닝 무시하나요!
[오프닝](http://youtube.com/watch/?v=gPXmvqZIn8Q @youtube)
뭐 이런 느낌. 실제 문법에 대한 딴지는 걸지 말자. (굳이 youtube가 아니라 video라는 이름을 써도 좋다.) 심지어 @youtube라는 annotation을 몰라도 이걸 HTML에서 class 정도로만 올려 주면 자바스크립트 단에서 파싱을 한다던지 뭘 한다던지 하는 대안을 써 볼 수도 있는 것이다. 이 정도의 annotation만으로 확장이 용이치 않은 경우가 있긴 한데 (이를테면 위키 링크의 경우 충분히 자체 문법이 필요할 정도로 많이 쓰이니까…) 많은 편은 아니고, 약간의 센스만 있어도 문제를 해결할 방법은 충분한 것이다. 단지 나서서 하는 사람이 없어서 못… 할 뿐이지.
이 문제를 내가 해결을 안 해 보려고 한 건 아니다. 실제로 나는 세 개 정도의 커스텀 마크업 문법(…)을 고안한 적이 있고, 그 중 하나는 PHP로 거의 완벽하게 구현해서 상용 소프트웨어에 디플로이될 뻔한 적도 있다.2 다른 하나는 reST로부터 아이디어를 얻어서 위에서 말한 문제를 해결하려고 노력해 보았으나 귀찮아서 구현을 못 했고 (이 때 참조한 마크업 문법만 열 개 가까이 되는 것 같다), 그 뒤로는 때려 치고 HTML을 직접 쓰는 무지막지한(하지만 의외로 그럴듯한) 일을 하곤 했었다. 그러던 내가 지금 마크다운을 쓰는 것은 마크다운이 이런 내 까다로운 성향에도 상당히 부합하기 때문이다. 물론 확장 부분은 굉장한 문제로 남아 있어서 결국 Mako랑 갖다 붙이는 미친 짓을 하긴 했지만… 어쨌든 내가 필요한 정도의 확장은 되니까 나는 문제 없다. 다만 이 해법이 나 같은 사람이나 쓸만한 방법이기 때문에 여전히 문제가 사라지는 건 아니니까, 내가 애정으로 이렇게 까는 거다. 흑흑.
