Markdown의 탄생: plain text가 웹을 장악한 이유

GitHub 저장소를 열어보자. 첫눈에 들어오는 것은 코드가 아니다. README.md 파일이다. 이 파일은 보통 Markdown으로 작성되며, 프로젝트에서 가장 많이 읽히는 문서다. 채용 공고, 학술 논문, 법률 계약서는 Markdown에 담기 드물지만, 웹의 기술 문서 상당수는 Markdown으로 쓰인다. 그 이유를 이해하려면 렌더링되기 전에 먼저 사람이 읽을 수 있도록 설계된 형식으로 거슬러 올라가야 한다.

Markdown의 기원

2004년, 기술 작가 John Gruber는 Aaron Swartz의 의견을 반영해 Markdown 문법 사양을 공개했다. Gruber의 목표는 실용적이었다. 그는 plain text로도 읽기 좋으면서 나중에 HTML로 변환할 수 있는 웹 글쓰기 방식을 원했다. 당시 웹은 태그로 돌아갔다. 블로그 글을 쓰려면 모든 단락, 목록, 링크를 꺾쇠 괄호로 감싸야 했다. Gruber는 대부분 사람들이 출판하는 산문에 그런 잡음은 불필요하다고 봤다.

결과는 작은 관례의 집합이었다:

• 제목은 # 기호를 쓴다.
• 목록은 -나 *를 쓴다.
• 링크는 [text](url)를 쓴다.
• 강조는 *text*나 _text_를 쓴다.
• 코드는 백틱을 쓴다.

이 관례들은 이미 작가들이 알고 있던 이메일 관례, Usenet, plain text 습관에서 따왔다. Markdown이 새로 발명한 것은 많지 않다. 그저 규칙을 정리해 문서로 남겼을 뿐이다.

Gruber는 참조 구현체인 Markdown.pl도 공개했다. 이 Perl 스크립트는 해당 문법을 HTML로 변환했다. 읽기 좋은 소스 형식과 결정적 출력 형식의 조합은 도입을 쉽게 만들었다. 작가는 어떤 텍스트 편집기에서도 수정할 수 있는 파일을 얻었다. 출판자는 CSS로 스타일을 입힐 수 있는 깔끔한 HTML을 얻었다.

Markdown은 HTML이 아니다

당연한 말처럼 들리지만, 기술적으로 이 구분은 중요하다. HTML은 구조화된 문서 형식이다. 요소, 속성, 중첩, 동작을 기술한다. 브라우저는 소스가 사람에게 어떻게 보이는지 신경 쓰지 않는다. 마크업에서 만들어낼 DOM(Document Object Model)이 중요할 뿐이다.

Markdown은 글쓰기 관례다. DOM도 없고, 이벤트 핸들러도 없고, 폼도 없으며, 사용자가 추가하는 frontmatter(문서 앞머리 메타데이터) 외에는 메타데이터 스키마도 없다. 마크업 언어보다는 속기법에 가깝다. Markdown을 파서에 넣으면 출력은 보통 HTML이지만, Markdown 자체는 작가가 직접 입력하는 문서 부분, 즉 제목, 단락, 강조, 목록, 링크, 이미지, 코드만 다룬다.

이 차이는 각 형식이 쓰이는 위치를 결정한다:

HTML은 최종 페이지다. Markdown은 원고다.

Markdown이 빠르게 퍼진 이유

세 가지 힘이 Markdown을 틈새 Perl 스크립트에서 기술 문서의 기본 언어로 밀어올렸다.

버전 관리. Git이 표준이 되면서 개발자는 문서를 코드 옆에 저장하기 시작했다. Plain text가 승리한 이유는 diff가 읽기 쉬웠기 때문이다. HTML이나 Word 문서는 사소한 수정도 diff에서 읽을 수 없는 덩어리로 만든다. Markdown은 읽기 좋게 남는다.

GitHub. 2009년 GitHub는 저장소 페이지에서 README.md 파일을 렌더링하기 시작했다. 갑자기 모든 프로젝트에 Markdown 파일이 필요해졌다. Stack Overflow도 질문과 답변에 Markdown을 도입했다. 개발자는 매일 쓰는 플랫폼이 요구했기 때문에 문법을 익혔다.

정적 사이트 생성기. Jekyll, Hugo, Gatsby, 그리고 나중에 Next.js 같은 도구는 Markdown 파일을 완전한 웹사이트로 바꿨다. 작가는 CMS 없이도 출판할 수 있었다. 소스 파일은 Git 저장소에 있고, 빌드 단계에서 HTML을 생성했다. 이 워크플로우는 지금 docs-as-code라 불리며, 현대 웹의 상당 부분에서 Markdown을 입력 형식으로 만들었다.

메모 앱이 마지막 밀어붙임을 더했다. Obsidian, Notion, Bear, Logseq, iA Writer 모두 Markdown이나 이에 가까운 파생 형식을 지원한다. 이 형식은 개발자 도구를 벗어나 개인 지식을 정리하는 방법이 되었다.

Markdown이 docx와 PDF를 대체할까?

아니다. Markdown은 가볍게 느껴지고 다른 형식은 무겁게 느껴져서 이런 질문이 나오지만, 이들은 서로 다른 문제를 푼다.

.docx 파일은 복잡한 편집을 위해 만든 압축 XML 패키지다. 수정 추적, 댓글, 스타일, 목차, 메일 머지, 임베디드 미디어를 포함한다. 비기술 사용자가 왕복 편집해야 하는 계약서, 보고서, 원고에 쓰이는 형식이다.

PDF는 고정 레이아웃 전자 문서 형식이다. 폰트, 여백, 페이지 매김을 기기 간에 보존한다. 최종 송장, 이력서, 어디서든 똑같이 보여야 하는 학술 논문에 딱 맞는 특성이다.

Markdown은 교환용 형식이다. 초안 작성, 버전 관리, 웹 출판에는 적합하다. 페이지 레이아웃, 정밀한 타이포그래피, 인쇄용 출력에는 부적합하다. 현실적인 워크플로우는 글쓰기는 Markdown으로 하다가, 텍스트 편집기를 벗어나야 할 때 docx나 PDF로 변환하는 것이다.

여기서 브라우저 기반 변환기가 쓸모 있다. Markdown 초안을 공유 가능한 PDF로 만들어야 할 때, 우리의 Markdown to PDF 변환기는 변환을 로컬에서 처리한다. PDF에서 출발해 수정 가능한 Markdown을 원한다면, PDF to Markdown 변환기는 파일을 업로드하지 않고 구조를 추출한다.

Markdown이 잘하는 것과 묻지는 지점

장점

• 읽기 쉬운 소스. Markdown 파일은 렌더링된 페이지만큼 깔끔하다. 터미널, 이메일 클라이언트, 휴대폰 메모 앱에서도 읽을 수 있다.
• 이식성. Plain text다. 특정 벤더나 라이선스가 없고, 손상될 바이너리 형식도 아니다.
• diff 친화적. Git이 어떤 문장이 바뀌었는지 정확히 보여준다. 작가와 리뷰어가 즉시 이득을 본다.
• 도구가 많다. 모든 프로그래밍 언어에 파서가 있다. 모든 주요 플랫폼에 편집기가 있다.
• 웹 친화적. 웹의 실제 출력 형식인 HTML로 컴파일된다.

한계

• 모호한 사양. Gruber의 원래 사양은 경계 사례를 정의하지 않는다. 같은 입력에 대해 다른 파서가 다른 HTML을 낸다. CommonMark가 존재하는 이유다. 하지만 모든 도구가 CommonMark를 따르는 것은 아니다.
• 레이아웃 제어 불가. HTML이나 CSS로 내려가지 않고는 이미지 위치를 정하거나 페이지 여백을 설정하거나 인쇄 스타일을 정의할 수 없다.
• Flavor 혼란. GitHub Flavored Markdown, Pandoc Markdown, MultiMarkdown, Obsidian Markdown, MDX 모두 서로 호환되지 않는 확장을 추가한다. 한 도구용으로 작성된 파일이 다른 도구에서는 잘못 렌더링될 수 있다.
• 표와 각주는 사후 확장이다. 기본 문법이 아닌 확장으로 지원되며, 동작이 제각각이다.

솔직한 요약은 이렇다. Markdown은 단락, 목록, 링크, 코드로 이뤄진 글쓰기의 90%에서 좋다. 나머지 10%는 HTML이나 전문 형식에 넘긴다.

AI 시대의 Markdown

대형 언어 모델(LLM, Large Language Model)을 써봤다면 Markdown을 본 적이 있다. 대부분의 채팅 인터페이스는 LLM 출력을 기본적으로 Markdown으로 렌더링한다. 그 이유는 실용적이다.

첫째, Markdown은 간결하다. 토큰은 비싸고, <h1></h1> 대신 #을 쓰는 형식은 공간을 절약한다. 둘째, Markdown은 구조가 단순하다. 제목, 목록, 코드 블록은 모델이 생성하기 쉽고 파서가 검증하기도 쉽다. 셋째, 학습 데이터에 Markdown이 가득하다. GitHub, Stack Overflow, Reddit, 문서 사이트 모두 Markdown을 쓰므로 모델은 이 문법을 안정적으로 학습한다.

채팅 출력을 넘어, Markdown은 AI 지식 시스템의 저장 형식이 되었다. RAG(Retrieval-Augmented Generation) 파이프라인은 구조가 예측 가능하기 때문에 문서를 Markdown이나 plain text로 청크 단위로 나누곤 한다. 벡터 데이터베이스, 메모 도구, 코딩 어시스턴트는 장기 컨텍스트를 Markdown 파일로 저장한다. 사람이 읽을 수 있고 기계가 파싱할 수 있기 때문이다.

리스크는 flavor 불일치다. 한 모델은 GitHub 스타일 표를 출력하고, 다른 모델은 같은 표를 HTML로 출력할 수 있다. 여러 flavor를 섞은 지식 베이스는 도구 사이를 옮길 때 깨질 수 있다. CommonMark나 문서화된 flavor로 표준화하는 것만이 AI가 생성한 Markdown을 이식 가능하게 유지하는 길이다.

Markdown의 미래와 진화

Markdown은 더 많은 기능을 담은 형식이 되지 않을 것이다. 표, 각주, 정의 목록, 속성처럼 기능을 늘리려는 모든 시도는 Markdown을 인기 있게 만든 단순함에서 멀어지게 한다. 진정한 진화는 두 방향에서 일어나고 있다.

표준화. 2014년에 시작된 CommonMark는 엄격한 파싱 사양을 정의한다. 이제 더 많은 도구가 CommonMark를 구현하므로, 파일을 한 파서에서 다른 파서로 옮길 때의 예상 밖 결과가 줄어든다.

임베딩. MDX는 Markdown 안에 React 컴포넌트를 가져오게 한다. Jupyter 노트북은 Markdown 셀과 실행 가능한 코드를 섞는다. 정적 사이트 생성기는 Markdown을 구조화된 콘텐츠의 데이터 소스로 다룬다. 각 경우 Markdown은 작게 유지되고, 주변 도구가 기능을 더한다.

가능성 높은 미래는 비슷한 형태를 유지할 것이다. Markdown은 보편적인 plain text 초안 형식으로 남고, 변환기는 이를 HTML, PDF, docx, 슬라이드, 혹은 목적지가 요구하는 어떤 형식으로든 바꾼다.

플랫폼별 읽기 및 편집 도구

Markdown을 쓰려면 특별한 앱이 필요 없다. 어떤 텍스트 편집기라도 동작한다. 하지만 일부 도구는 경험을 분명히 개선한다.

Windows

• VS Code와 Markdown 확장: 개발자의 기본 선택이다. 미리보기, 린트, Markdown-it 렌더링을 지원한다.
• Typora: 필요할 때까지 문법을 숨기는 미니멀한 WYSIWYG 스타일 편집기다.
• MarkText: Typora의 오픈소스 대안으로 깔끔한 분할 화면을 제공한다.
• Notepad++: 플러그인으로 Markdown 문법 강조가 가능해 빠른 수정에 적합하다.

macOS

• iA Writer: 방해 없는 글쓰기와 문법 제어에 집중한다.
• Bear: Markdown과 유사한 문법을 사용하는 메모 앱으로 개인 지식 관리에 쓰인다.
• Ulysses: 웹에 출판하는 장문 작가들 사이에서 인기가 있다.
• Marked 2: 편집기는 아니지만, 다른 곳에서 편집한 파일의 기능이 많은 실시간 미리보기 렌더러다.

Linux

• Ghostwriter: 실시간 미리보기를 제공하는 방해 없는 Markdown 편집기다.
• Apostrophe: 산문 작성을 위해 설계된 깔끔한 GTK 기반 편집기다.
• ReText: 여러 형식으로 내보내는 간단한 편집기다.
• Vim / Neovim / Emacs: 이미 터미널에서 작업하는 작가에게 맞설 도구가 없다.

크로스 플랫폼

• Obsidian: 링크, 그래프, 플러그인을 갖춘 로컬 우선 지식 베이스다.
• Logseq: 모든 것을 Markdown이나 Org 파일로 저장하는 아웃라이너다.
• Joplin: 종단간 암호화와 Markdown 지원을 갖춘 오픈소스 메모 앱이다.

프로그래밍 언어별 Markdown 라이브러리

Markdown을 파싱하거나 렌더링하는 소프트웨어를 만든다면, 직접 파서를 작성할 필요는 거의 없다. 생태계가 성숙했다.

이 라이브러리 대부분은 기본 문법을 잘 처리한다. 차이는 확장, 성능, CommonMark 준수 엄격성에서 드러난다. 사용하는 언어만 보지 말고 지원해야 할 flavor에 따라 선택하라.

결론

Markdown이 승리한 이유는 강력해서가 아니다. 길을 비켜 서기 때문이다. 작가는 어떤 텍스트 편집기라도 열어 문서를 입력하고, 파일 형식을 신경 쓰지 않은 채 버전 관리에 커밋할 수 있다. 이 트레이드오프는 의도적인 것이다. Markdown은 레이아웃 정밀도를 포기하는 대신 이식성과 가독성을 얻는다.

이 트레이드오프 덕분에 Markdown은 README, 문서, 정적 사이트, 메모 앱, 그리고 이제 AI 출력을 떠받친다. 또한 docx와 PDF 옆에서 계속 살아갈 이유이기도 하다. 각 형식에는 할 일이 있다. Markdown의 할 일은 plain text 출발점이 되는 것이다. 이 출발점을 더 복잡한 형식으로 옮겨야 할 때, 변환기가 보통 다음 단계다.