‘쓰기’에 최적화된 가벼운 문법
마크다운은 평문(plain text) 위에 최소한의 기호 규칙을 얹어서, 사람이 읽기 쉬운 상태로 쓰면서도 HTML 같은 “출판용 형식”으로 변환할 수 있게 만든 경량 마크업 언어입니다. 마크다운의 핵심 철학을 가장 잘 요약한 문장 중 하나는, “HTML은 publishing 포맷이고, 마크다운은 writing 포맷”이라는 설명입니다. [1]
이 접근은 단순한 취향 문제가 아닙니다. 마크다운은 다음 특성 때문에 ‘문서 작성의 기본 도구’로 자리 잡을 수 있었습니다.
- 가독성: 소스 코드가 복잡한 태그로 뒤덮이지 않아, 별도의 렌더링 과정 없이도 원문 자체를 읽고 이해하기 쉽습니다. [2]
- 이식성:
.md확장자를 가진 파일은 거의 모든 텍스트 편집기에서 열고 편집할 수 있으며, Git과 같은 버전 관리 시스템으로 변경 이력을 추적하는 데 매우 효율적입니다. - 변환 용이: HTML, PDF, 워드 문서, 위키 페이지, 정적 웹사이트 등 다양한 형태로 손쉽게 변환할 수 있어 콘텐츠의 재활용성이 높습니다. [2]
탄생과 초기 확산 (2004년 ~ 2010년대 초반)
존 그루버의 창안과 ‘애플 블로거 문화권’
마크다운은 2004년 존 그루버(John Gruber)가 애런 스워츠(Aaron Swartz)의 도움을 받아 공개한 “텍스트-HTML 변환 도구이자 문법”에서 출발합니다. [2] 그는 마크다운을 읽기 쉽고 쓰기 쉬운 평문 문법으로 설계하고, 이를 구현한 Perl 스크립트와 함께 배포했습니다.
흥미로운 점은 마크다운이 개발자 커뮤니티 외부에서 먼저 뿌리를 내렸다는 사실입니다. 그 중심에는 존 그루버 자신이 운영하는 애플 전문 블로그 ‘Daring Fireball’이 있었습니다. 2002년부터 운영된 이 블로그는 애플에 대한 깊이 있는 분석으로 막강한 영향력을 행사하며, 소위 ‘애플 블로거 문화권’의 구심점 역할을 했습니다. [11] 이 문화권의 사용자들은 자연스럽게 마크다운을 ‘코드를 위한 문서’가 아닌 ‘생각과 글을 담는 도구’ 로 받아들였습니다.
이러한 흐름 속에서 Ulysses와 같은 마크다운 기반 글쓰기 전문 앱이 등장했습니다. 2003년 첫 버전을 선보인 Ulysses는 마크다운 문법을 전면에 내세우기보다, 사용자가 글의 내용과 구조에만 집중할 수 있는 환경을 제공하는 데 초점을 맞췄습니다. [12] 이는 미려한 디자인과 사용자 경험을 중시하는 애플 생태계의 특징과 맞물려, 마크다운이 ‘글쓰기 애호가들의 언어’로 자리 잡는 데 결정적인 역할을 했습니다.
표준화와 개발 생태계 편입 (2010년대 중반 ~)
파편화 문제와 CommonMark의 등장
마크다운의 간결함은 양날의 검이었습니다. 문법이 단순한 만큼 모호한 부분(edge case)이 많았고, 이를 해석하는 방식이 구현체마다 달라지는 ‘방언(dialect)’ 문제가 심각해졌습니다. 특히 표, 각주, 체크리스트 등 확장 기능에 대한 요구가 늘면서 파편화는 더욱 가속되었습니다. [3]
이러한 혼란을 정리하기 위해 2014년, CommonMark 프로젝트가 시작되었습니다. CommonMark는 “모호하지 않은 명세와 이를 검증하기 위한 테스트 스위트”를 제공함으로써, 어떤 환경에서든 예측 가능한 결과를 보장하는 표준을 만드는 것을 목표로 했습니다. [4]
공식 표준으로의 인정
마크다운의 위상은 2016년 IETF(국제 인터넷 표준화 기구)가 RFC 7763을 통해 text/markdown을 공식 미디어 타입으로 인정하면서 한 단계 격상됩니다. [1] 이는 마크다운이 단순한 유행을 넘어, 웹과 인터넷 프로토콜의 세계에서 공식적으로 다뤄야 할 중요한 문서 형식으로 공인되었음을 의미합니다.
| 연도 | 주요 사건 |
|---|---|
| 2004 | 존 그루버, 마크다운 최초 공개 |
| 2014 | CommonMark 프로젝트 시작 |
| 2016 | IETF, text/markdown 미디어 타입 등록 (RFC 7763) |
| 2017 | GitHub, GFM(GitHub Flavored Markdown) 공식 명세 공개 |
GitHub가 만든 ‘마크다운의 일상화’
마크다운이 “개발자 문화권의 기본 문서 언어”로 굳어진 데에는 GitHub 의 영향이 결정적이었습니다. GitHub는 다음과 같은 방식으로 마크다운을 개발 워크플로우의 중심으로 가져왔습니다.
- README.md의 보편화: GitHub는 저장소의 첫 화면에
README.md파일의 내용을 자동으로 보여주도록 설계했습니다. 이로 인해 프로젝트의 목적, 사용법, 기여 방법 등을 마크다운으로 작성하는 것이 ‘오픈소스 협업의 기본 예절’처럼 자리 잡게 되었습니다. [6] - 모든 협업 과정에 적용: GitHub는 README뿐만 아니라 이슈 트래킹, 코드 리뷰(Pull Request), 위키(Wiki) 등 거의 모든 텍스트 입력 공간에 마크다운을 기본으로 채택했습니다. 개발자들은 자연스럽게 마크다운으로 소통하고 문서를 작성하는 데 익숙해졌습니다. [7]
- 정적 사이트 생성: 정적 사이트 생성기인 Jekyll과 GitHub Pages의 결합은 마크다운의 활용 범위를 더욱 넓혔습니다. 개발자들은 마크다운으로 작성한 콘텐츠를 손쉽게 블로그나 프로젝트 문서 사이트로 만들 수 있게 되었습니다. [8]
결론적으로 GitHub는 마크다운을 ‘코드 옆에 붙는 보조 형식’이 아니라 ‘개발과 협업 문서의 기본값’ 으로 만들었습니다.
개발자를 넘어 일반 사용자로, 노트 앱의 부상
GitHub가 개발자 생태계에서 마크다운의 확산을 이끌었다면, Bear와 같은 노트 앱은 마크다운을 일반 사용자들의 일상으로 가져왔습니다. 2016년 출시된 Bear는 마크다운의 강력한 기능은 유지하되, 문법을 몰라도 쉽게 사용할 수 있는 직관적인 인터페이스를 제공했습니다. [13] [14] 이를 통해 마크다운은 더 이상 개발자나 작가의 전유물이 아닌, 누구나 일상적인 메모와 기록을 위해 사용할 수 있는 도구가 되었습니다. 이러한 흐름은 Notion, Obsidian 등 마크다운을 핵심 기반으로 하는 차세대 지식 관리 도구들의 등장으로 이어지며 더욱 확산되고 있습니다.
생성 AI가 만든 ‘두 번째 폭발’
최근(특히 2023년 이후) 마크다운의 폭발적인 성장은 생성 AI가 마크다운을 사실상의 표준 출력 포맷으로 채택한 흐름과 맞물립니다.
- 대화형 AI의 가독성 확보: ChatGPT와 같은 챗봇의 답변은 길고 구조적인 경우가 많습니다. 마크다운은 제목, 목록, 코드 블록, 표, 인용 등 다양한 서식을 최소한의 비용으로 적용하여 정보의 구조를 명확히 하고 가독성을 극대화하는 최적의 수단입니다. AI 모델의 마크다운 인식 및 생성 능력을 평가하는 연구가 등장할 정도로, 이는 중요한 요소로 자리 잡았습니다. [9]
- AI 파이프라인의 중간 표현(IR): AI가 문서를 이해하고 처리하는 과정에서 마크다운은 매우 효율적인 ‘중간 표현(Intermediate Representation)’ 역할을 합니다. 예를 들어, 복잡한 PDF 문서를 AI가 분석하기 쉬운 마크다운 형식으로 변환하는 OCR 기술은 마크다운이 ‘기계가 읽기 좋은 텍스트’로서 높은 잠재력을 가지고 있음을 보여줍니다. [10]
마크다운은 ‘문서의 공용어’가 되었습니다
마크다운의 확산은 두 번의 큰 물결로 요약할 수 있습니다. 첫 번째는 존 그루버의 창안 이후 애플 블로거 문화권을 중심으로 한 ‘글쓰기 도구’로서의 성장과 GitHub를 통한 ‘개발 문서 표준’으로의 정착입니다. 두 번째는 생성 AI가 답변을 구조화하고 문서를 처리하는 과정에서 마크다운을 ‘AI 시대의 기본 언어’ 로 채택한 흐름입니다.
이제 마크다운은 단순히 “배워두면 좋은 문법” 수준을 넘어, 기술 글쓰기, 개발 협업, 지식 관리, 그리고 AI와의 소통에 이르는 광범위한 영역에서 없어서는 안 될 공통 기반, 즉 ‘문서의 공용어(Lingua Franca)’가 되었습니다.
각주
[1] IETF Datatracker. (2016). RFC 7763 – The text/markdown Media Type.
[2] Daring Fireball. (2004). Markdown.
[3] Wikipedia. Markdown.
[4] CommonMark. CommonMark Spec.
[5] The GitHub Blog. (2017). A formal spec for GitHub Flavored Markdown.
[6] GitHub Docs. About READMEs.
[7] GitHub Docs. Using Markdown and Liquid in GitHub Docs.
[8] GitHub Docs. About GitHub Pages and Jekyll.
[9] arXiv. (2025). MDEval: Evaluating and Enhancing Markdown Awareness of Large Language Models.
[10] Mistral AI. (2024). Mistral OCR.
[11] Vox. (2016). How Apple obsessive John Gruber built Daring Fireball into a must-read blog.
[12] Ulysses. Press Kit.
[13] Bear Blog. (2018). The who, what, and why of Bear.
[14] Bear Blog. (2024). Happy 8th bear-thday!.
