순수 텍스트 서식 언어
마크다운은 소수의 구두점 기반 규칙만으로 순수 텍스트에 제목, 굵게·기울임 글씨, 링크, 목록, 코드 같은 서식을 추가하는 경량 마크업 언어입니다. 별표 한 쌍이면 텍스트가 기울임이 되고, 두 쌍이면 굵게가 되며, 맨 앞의 해시 기호 하나가 한 줄을 제목으로 바꿉니다. 따로 배워야 할 파일 형식도 없고, 이를 작성하는 데 필요한 애플리케이션도 없습니다: 마크다운 문서는 어떤 텍스트 편집기에서도 열 수 있는 .md 또는 .txt 파일일 뿐입니다.
핵심 아이디어는 서식을 입히지 않은 마크다운 자체도 이미 읽을 수 있고 순수 텍스트로서 의미가 통해야 한다는 것입니다 — 이는 HTML과 대조적입니다. HTML에서는 문단을 <p><strong> 태그로 감싸면 원본 형태 그대로는 렌더링된 결과보다 읽기가 훨씬 어렵습니다. 마크다운은 그다음 HTML(또는 다른 형식)로 변환, 즉 “렌더링”되어 화면에 표시됩니다.
간략한 역사
마크다운은 2004년 John Gruber가 만들었으며, 문법에 대해서는 Aaron Swartz의 조언을 받았습니다. Gruber가 이 형식의 첫 릴리스 노트에서 밝힌 원래 목표는 “가능한 한 읽기 쉽고 쓰기 쉬운” 문법이었습니다 — 마크다운을 한 번도 본 적 없는 사람이 읽어도 완전히 이해할 수 있을 만큼, 순수 텍스트 이메일이나 포럼 게시글에서도 충분히 읽기 쉬워야 한다는 뜻이었습니다.
다만 그 최초 명세는 몇몇 경계 사례를 모호하게 남겨두었습니다 — 중첩된 목록이나 구두점 옆의 강조 표시 같은 것을 도구마다 다르게 처리했죠. 2014년 Jeff Atwood와 John MacFarlane 등이 포함된 그룹이 CommonMark를 발표했습니다. 이는 모든 구현체에서 마크다운이 동일하게 동작하도록 설계된, 엄격하고 모호함이 없는 명세입니다. 이 사이트 자체 도구를 뒷받침하는 파서를 포함해, 오늘날 대부분의 마크다운 파서는 CommonMark를 기반으로 합니다.
짧은 예시
“렌더링하지 않아도 읽을 수 있다”는 개념이 실제로 어떻게 보이는지 살펴보겠습니다. 다음 순수 텍스트는:
## Weekly update
Shipped the new **onboarding flow** and fixed the *login redirect* bug.
Next up:
- Finish the billing page
- Write release notes제목 하나, 굵은 문구와 기울임 문구가 하나씩 들어간 문단, 그리고 두 개짜리 글머리 목록으로 렌더링됩니다 — 하지만 렌더링되기 전에도 이미 읽을 수 있고 정확히 무슨 내용인지 이해할 수 있습니다. 그것이 바로 이 형식의 핵심입니다.
오늘날 마크다운이 쓰이는 곳
마크다운은 매우 다양한 도구에서 기본 순수 텍스트 서식 문법으로 자리 잡았습니다:
- 개발자 플랫폼 — GitHub, GitLab, Bitbucket은 마크다운으로 작성된 README 파일, 이슈, 풀 리퀘스트 설명을 렌더링합니다.
- 채팅·커뮤니티 도구 — Reddit, Discord, Slack은 모두 메시지에서 굵게·기울임·코드 서식을 위한 마크다운과 유사한 문법을 지원합니다.
- 노트·문서 앱 — Notion, Obsidian, 그리고 여러 정적 사이트 생성기(Jekyll, Hugo, Next.js의 콘텐츠 레이어 등)가 콘텐츠를 마크다운 파일로 저장합니다.
- 기술 문서 작성과 블로깅 — GitBook, Read the Docs 같은 문서화 도구와 Ghost, dev.to 같은 블로깅 플랫폼 모두 서식 있는 텍스트 편집기 대신 마크다운을 기본 작성 형식으로 받아들입니다.
- 데이터 과학 노트북 — Jupyter를 비롯한 노트북 도구들은 실행 가능한 코드 셀과 함께 서술형 텍스트와 설명을 위해 마크다운 셀을 사용합니다.
- 대규모 언어 모델 — ChatGPT, Claude 같은 채팅 기반 AI 도구는 응답 대부분을 마크다운으로 형식화합니다. 아주 적은 추가 텍스트만으로 제목, 목록, 코드 블록을 표시할 수 있기 때문입니다. 자세한 이유는 LLM을 위한 마크다운 에서 확인하세요.
CommonMark 대 GitHub Flavored Markdown
오늘날 사람들이 “마크다운”이라고 말할 때 대부분 다음 둘 중 하나를 뜻합니다:
| 기능 | CommonMark | GitHub Flavored Markdown |
|---|---|---|
| 제목, 강조, 목록, 링크 | 지원 | 지원 |
| 표 | 미지원 | 지원 |
| 작업 목록 | 미지원 | 지원 |
| 취소선 | 미지원 | 지원 |
| 자동 링크(순수 URL) | 미지원 | 지원 |
| 명세 상태 | 공식 명세 | CommonMark의 상위 집합 |
실제로는 GFM이 사람들이 일상적으로 쓰는 문법입니다 — GitHub이 렌더링하는 문법이자, 이 사이트의 도구들이 지원하는 문법이기도 합니다. 정확히 어떤 항목이 CommonMark이고 어떤 항목이 GFM 확장인지 전체 참고 자료는 마크다운 치트시트 에서 확인하세요.
이 차이는 문서를 도구 사이에서 옮길 때 실제로 문제가 됩니다: 엄격한 CommonMark만 구현한 파서에 표나 작업 목록을 붙여넣으면, 표 마크업은 일반 문단으로 되돌아가고 체크박스는 문자 그대로 [ ] 텍스트로 남아 렌더링되지 않습니다. GitHub에서는 멀쩡해 보이는 마크다운이 다른 곳에서 깨진다면, 대개 GFM 전용 기능이 원인입니다.
첫걸음
마크다운이 처음이라면, 시작하는 데 필요한 대부분은 세 가지 문법으로 충분합니다: 제목을 위한 해시 기호(# Heading), 강조를 위한 별표(**bold** 또는 *italic*), 목록 항목을 위한 대시(- item). 표, 코드 블록, 링크 등 그 외 나머지는 모두 같은 순수 텍스트 논리 위에 세워져 있습니다.
감을 가장 빨리 익히는 방법은 짧은 문서를 써보고 렌더링되는 모습을 지켜보는 것입니다. 마크다운 에디터 를 열어 몇 줄 입력해 보세요 — 입력하는 대로 미리보기 패널이 업데이트되므로, 각 문법이 정확히 무엇을 만들어내는지 바로 확인할 수 있습니다. 문법에 익숙해지는 동안 치트시트 를 다른 탭에 열어두세요.
지금까지 살아남은 이유
마크다운 이전에도 수많은 마크업 언어가 있었고, 이후에도 수없이 등장했습니다. 20년 동안 마크다운을 계속 쓸모 있게 만든 것은, 누구에게도 무언가를 설치하거나 무거운 도구 체인을 배우라고 요구하지 않았다는 점입니다 — 그냥 텍스트일 뿐이라, 이메일 클라이언트든 터미널이든 채팅창이든 코드 편집기든 별다른 지원 없이도 그대로 작동합니다. 이 낮은 진입 장벽은 또한 기계가 생성하는 콘텐츠에 자연스럽게 어울리는 이유이기도 합니다: 스크립트든 API 응답이든 언어 모델이든, 그냥 평범한 문자열로 마크다운을 내보낼 수 있고, 그것을 받는 쪽이 렌더링할 줄 알든 모르든 여전히 읽을 수 있습니다. Gruber의 첫 릴리스 이후 20년이 지난 지금도, 사람이 읽을 수 있고, 기계가 쓸 수 있고, 사실상 아무 의존성도 없다는 이 조합이야말로 마크다운이 새로운 도구들에 밀려나는 대신 계속 그 안에 등장하는 이유입니다.