# 마크다운이 세상을 장악한 이유 > Clean Markdown view of GeekNews topic #25717. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25717](https://news.hada.io/topic?id=25717) - GeekNews Markdown: [https://news.hada.io/topic/25717.md](https://news.hada.io/topic/25717.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-11T01:37:46+09:00 - Updated: 2026-01-11T01:37:46+09:00 - Original source: [anildash.com](https://www.anildash.com/2026/01/09/how-markdown-took-over-the-world/) - Points: 24 - Comments: 1 ## Summary **마크다운**은 단순한 텍스트 포맷이 웹과 AI 산업의 공통 언어로 자리 잡은 드문 사례입니다. 2004년 John Gruber가 블로깅의 불편함을 해결하려 만든 이 포맷은, **직관적 문법**과 **개방형 구조** 덕분에 GitHub·Slack·Apple Notes 등 거의 모든 플랫폼에 스며들었습니다. 이 글은 마크다운의 시작부터 확산, 그리고 성공한 이유에 대해서 설명합니다. 저도 요즘 가장 많이 쓰는 포맷이기도 하고, 제가 만드는 도구는 모두 마크다운 기반으로 만들고 있네요 ## Topic Body - 단순한 **텍스트 기반 포맷**이 전 세계 기술 산업의 공통 언어로 자리 잡아, AI 시스템부터 일상적인 메모 앱까지 폭넓게 사용됨 - 2004년 **John Gruber**가 블로깅 편집의 불편함을 해결하기 위해 만든 포맷으로, 누구나 쉽게 웹 문서를 작성할 수 있게 함 - 개발자와 일반 사용자 모두에게 **직관적 문법**과 **개방형 구조**를 제공해, GitHub·Slack·Apple Notes 등 거의 모든 플랫폼에 통합됨 - 상업적 이익보다 **공유와 협력의 정신**으로 만들어져, 오픈 기술 생태계의 지속 가능성을 보여줌 - 오늘날 **AI 산업의 핵심 제어 시스템**까지 마크다운으로 작성될 정도로, 인터넷 기술의 근간이 된 형식임 --- ### 마크다운의 기원과 확산 - 마크다운은 2000년대 초 블로깅 도구의 복잡한 HTML 편집 문제를 해결하기 위해 만들어진 **간결한 서식 언어** - John Gruber가 2002년 Apple 중심 블로그 *Daring Fireball*을 운영하며, 글 작성의 불편함을 해소하기 위해 개발 - 당시 블로거들은 링크나 굵은 글씨를 넣기 위해 HTML을 직접 작성해야 했음 - 2004년 Gruber는 **Aaron Swartz**와 함께 베타 테스트를 진행해 포맷을 다듬었고, 3월에 공개 - Swartz의 피드백이 안정성과 유연성을 높이는 데 기여 - 출시 직후 블로그뿐 아니라 다양한 용도로 확산되며, 단순한 개인 도구에서 **웹 전반의 표준 포맷**으로 발전 ### 마크다운의 원리와 특징 - 키보드의 일반 문자만으로 웹 서식을 표현할 수 있는 **직관적 문법 구조** - 예: `[링크텍스트](URL)` 또는 `# 제목` 형태 - “Markup”의 복잡함을 줄인 “Markdown”이라는 이름처럼, **단순함과 가독성**을 핵심 가치로 함 - 누구나 몇 분 안에 익힐 수 있을 만큼 쉬우며, 동시에 **강력한 표현력**을 제공 - 기술적으로 구현이 간단해, 대부분의 블로깅 도구와 앱이 빠르게 지원 ### 산업 전반으로의 확산 - 수십 년간 마크다운은 **소프트웨어 산업의 기본 언어**로 자리 잡음 - Google Docs(2022), Microsoft Notepad, Apple Notes 등 주요 앱이 지원 추가 - Slack, WhatsApp, Discord 등 메시징 플랫폼에서도 사용 - **GitHub**의 거의 모든 저장소가 마크다운 파일을 포함하며, 프로젝트 설명과 문서화의 표준으로 활용 - 전 세계 하드드라이브와 클라우드에 **수십억 개의 마크다운 파일**이 존재 - 심지어 게임기, 이어폰 등 임베디드 시스템에도 포함 ### 오픈 기술과 협력의 정신 - 마크다운은 **상업적 목적 없이 무료로 공개**되어, 누구나 자유롭게 사용 가능 - Gruber는 포맷에 대한 금전적 보상을 요구하지 않음 - 2000년대 초 오픈 웹 문화 속에서, **표준을 공유하고 개선하는 협력적 개발 방식**의 대표 사례 - 이러한 개방성 덕분에, 폐쇄적 대안이 등장하지 않고 **인터넷의 공공 인프라**로 자리함 ### AI 시대의 마크다운 - 오늘날 **대형 언어 모델(LLM)** 의 프롬프트와 제어 스크립트 대부분이 마크다운 형식으로 작성 - ChatGPT나 Claude 등에서의 고급 작업 지시도 마크다운 기반 - 단순한 텍스트 포맷이 **AI 산업의 핵심 제어 언어**로 발전 - Gruber가 만든 이 무료 포맷이 **수조 달러 규모의 AI 산업**을 뒷받침하고 있음 - 기술 발전의 근간에는 거대 기업이 아닌, **열정과 세심함으로 만든 개인의 기여**가 존재 ### 마크다운이 성공한 10가지 기술적 이유 - **1. 뛰어난 이름**: “Markup”의 반대 개념으로 직관적이고 기억하기 쉬움 - **2. 실제 문제 해결**: 복잡한 HTML 작성의 불편함을 해소 - **3. 익숙한 사용 습관 기반**: 이메일 등에서 이미 쓰이던 기호 활용 - **4. RSS와 유사한 개방형 발전 구조**: 블로그 문화와 함께 성장 - **5. 협력적 커뮤니티**: Dean Allen의 Textile 등 선행 기술과 Swartz의 참여 - **6. 다양한 변형 지원**: CommonMark, GitHub-Flavored 등 상황별 확장 - **7. 사용자 행동 변화 시점 포착**: 블로깅과 소셜미디어 확산기에 등장 - **8. 빌드 도구 시대와의 궁합**: HTML 변환 과정이 자동화 워크플로우에 적합 - **9. ‘View Source’ 철학 유지**: 누구나 원본을 보고 학습 가능 - **10. 지식재산권 제약 없음**: 특허나 라이선스 제한이 없어 자유로운 채택 가능 ### 결론 - 마크다운은 **단순함, 개방성, 인간 중심 설계**로 인터넷의 기본 언어가 됨 - 거대 자본이 아닌 **개인의 창의성과 협력 정신**이 기술 혁신을 이끌 수 있음을 증명 - 오늘날 AI와 웹의 핵심 구조 속에서도, 그 뿌리는 여전히 **한 명의 개발자가 만든 텍스트 파일 포맷**에 있음 ## Comments ### Comment 49004 - Author: neo - Created: 2026-01-11T01:37:46+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46556695) - 글이 잘 쓰였음. 하지만 내가 Markdown을 좋아하는 **가장 큰 이유**는 그게 근본적으로 **텍스트 기반**이라는 점임 포맷이나 벤더 종속이 없고 git 저장소에 넣기에도 완벽함. OneNote 같은 포맷이 2035년에 여전히 열릴지 걱정할 필요가 없음 또 LLM들이 기본적으로 Markdown을 이해한다는 점도 좋음. 서버 코드에서 API 문서를 만들어 달라고 하면, 텍스트 기반 요약을 원한다는 걸 바로 알아들음 - Markdown은 원래 사람들이 텍스트 파일에서 쓰던 **관습**을 공식화한 것임. 나도 평소에 텍스트로 문서를 쓰다가, 나중에 보니 이미 Markdown 문법을 쓰고 있었음. 그래서 확장자를 `.md`로 바꾸고 약간 수정하면 보기 좋게 변함 - 물론 AsciiDoc이나 reStructuredText 같은 더 나은 포맷도 있음. 하지만 결국 Markdown을 써야 하는 곳이 많아서 그냥 **충분히 괜찮은 선택**으로 남음 - Markdown은 본질적으로 **그럭저럭 보기 좋은 텍스트**임. 표를 지원하지 않는 이유도 여기에 있음. 아무리 문법을 잘 만들어도 순수 텍스트로 표를 예쁘게 표현하기는 어려움 - 나도 같은 이유로 텍스트를 선호하게 됨. 지금 **The UNIX Programming Environment (1984)** 를 읽고 있는데, 이 책 덕분에 텍스트 기반 형식의 영속성을 다시 느끼고 있음 - 그래서 Obsidian을 좋아함. 마치 **Markdown을 위한 운영체제** 같음 - 예전에 Google Docs에 **Markdown 지원 기능**을 20% 프로젝트로 추가했음. Markdown 역사에 이름이 언급돼서 영광스러움 - 그 기능 덕분에 Google Docs가 훨씬 즐거워졌음. 특히 `alt+/` 단축키와 함께 쓰면 정말 편함 - 빠르게 문서를 만들어 공유할 때 큰 도움이 됨 - 거의 매일 쓰고 있음. 고마움! - HTML을 직접 쓰는 게 어렵다기보다, Markdown의 매력은 **원본 텍스트 자체가 읽기 쉬움**이라는 점임 그리고 Markdown의 ‘모양’을 커스터마이징할 수 있는 내 편집기 [Kraa](https://kraa.io/about)를 소개함 - 예전에 Kraa를 봤는데, 다시 써보니 단어 줄바꿈이 어색하고, `#`을 숨겨서 헤더 스타일을 바꾸기 어렵고, **비표준 체크박스 문법**(`[]`)을 써서 불편했음. UI는 멋지지만 Markdown 편집기로는 부족함 - 제품이 좋아 보이지만 **자체 호스팅 불가**라 보안이 불명확함. 개인 노트라면 괜찮지만 업무용으로는 불안함. 수익화 계획이 있는지도 궁금함 - `<br>`이 필요한 경우도 있음. 예를 들어 **멀티라인 표 셀** 같은 곳에서는 고정폭 폰트와 함께 써야 함 - 자바스크립트를 끄면 빈 화면만 보임. 이건 좀 아쉬움 - Markdown을 정말 좋아함. 그런데 아직도 대부분의 브라우저에서 `.md` 파일을 바로 열 수 없다는 게 놀라움. 브라우저가 자동으로 HTML로 변환해 보여주면 좋겠음 - 나는 [Markdeep](https://casual-effects.com/markdeep/)을 사용함. 문서 끝에 코드 스니펫을 추가하고 `.md.html`로 저장하면 브라우저에서 바로 렌더링됨. Google Drive에 저장해두고 모든 노트 앱을 대체함 - 이 기능을 구현하려면 Markdown의 **표준화**가 필요함. CommonMark가 있긴 하지만 여전히 복잡하고 모호함 - 단순히 Markdown을 보기 좋게 렌더링할 **리더 앱**이 거의 없다는 게 이상함. 왜 이렇게 단순한 게 없는지 모르겠음 - 브라우저에서 “HTML로 보기” 같은 버튼으로 렌더링할 수 있게 하면 좋을 텐데, 왜 거부됐는지 궁금함 - 또한 Markdown을 안전한 HTML로 바꾸는 **기본 JS API**가 없다는 것도 아쉬움 - 글에서 Jeff Atwood(스택오버플로 창립자)가 Gruber에게 Markdown 표준화를 제안했던 이야기가 빠져 있음 Gruber는 결국 거절했지만, 자신이 하고 싶은 일을 고수한 점은 **영감을 주는 사례**라고 생각함 - 실제로는 Atwood가 먼저 “Standard Markdown” 문서를 공개했고, Gruber가 이를 승인하지 않음. 이후 프로젝트 이름이 **CommonMark**로 바뀜. 결과적으로 단순함을 유지할 수 있었음 - 하지만 표준 부재로 인해 여러 번 **호환성 문제**를 겪었음 - “모든 문맥에 맞는 맛을 가졌다”는 표현이 웃김. Markdown이 통일되지 않아 *bold*나 **bold**, *italics*가 헷갈림 그래도 **CommonMark**가 더 널리 쓰였으면 좋겠음 - 다른 포맷처럼 `/italics/`, `_underline_` 같은 직관적인 표기가 더 낫다고 생각함 - 실제로는 굵게나 기울임의 구분이 중요하지 않음. 강조만 전달되면 충분함 - 예전엔 이런 변형이 싫었지만, 이제는 **“실용적 포용성(Practical Postelism)”** 으로 받아들임. 완벽한 표준보다 현실적인 다양성이 시스템 성공에 도움이 됨 - Slack의 단일 별표 굵게 표기는 Markdown이 아님. 너무 불편해서 그냥 **단축키**를 외워버림 - CommonMark와 Pandoc의 제작자가 만든 새로운 포맷 **Djot**([djot.net](https://djot.net/))이 있음. 더 합리적이고 파싱이 쉬움 - 하지만 한국어 사용자 입장에서는 “djot” 발음이 **비속어처럼 들림** - 사양이 명확하지 않아 새로운 구현을 만들기 어려움 - 그래도 더 엄격하고 깔끔한 Markdown 같아서 시도해볼 예정임 - 나는 Djot을 내 프로젝트([Moor 클라이언트](https://timbran.org/moor.html))에 사용 중임. **안전하고 익숙하며 파싱이 쉬움** - Markdown의 장점은 명확함 **텍스트 기반**, **git 친화적**, **LLM 친화적**, **검색 가능성**이 뛰어남 하지만 복잡한 레이아웃이나 정밀한 타이포그래피, 바이너리 임베딩은 불가능함. 다른 제약이 있는지 궁금함 - 다단계 리스트가 깊어지면 코드 블록처럼 렌더링되는 문제가 있음. 이건 Markdown의 **큰 단점**임 - CommonMark는 HTML의 상위 집합처럼 동작함. 하지만 구현마다 미묘한 차이가 많음 - Markdown은 **간단한 메모**에는 좋지만, 구조화된 문서에는 부적합함. 의미론적 마크업이 없기 때문임 - 수식, 소문자 대문자 구분, 문서 구획 등 **학술적 표현**이 부족함 - 확장 문법에서는 HTML/CSS나 base64 이미지를 넣을 수 있지만, 그건 이미 Markdown의 정신에서 벗어남 - Markdown이 성공한 이유는 **시기적 타이밍** 덕분임 AsciiDoc, org-mode 등은 더 구조적이지만 **대중성**이 부족했음. GitHub가 Markdown을 선택하면서 오픈소스 커뮤니티 전체가 자연스럽게 따라왔음. VHS와 Betamax의 경쟁처럼, 더 나은 기술이 아니라 **먼저 자리 잡은 포맷**이 승리한 셈임 - “까칠하지만 따뜻한 사람, 지금쯤 Kubrick 영화를 보며 말도 안 되는 팀을 응원하고 있을 것 같다”는 묘사가 인상적이었음