▲

마크다운이 세상을 장악한 이유

 (anildash.com)
19P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 단순한 텍스트 기반 포맷이 전 세계 기술 산업의 공통 언어로 자리 잡아, 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와 웹의 핵심 구조 속에서도, 그 뿌리는 여전히 한 명의 개발자가 만든 텍스트 파일 포맷에 있음
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 글이 잘 쓰였음. 하지만 내가 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를 소개함

    • 예전에 Kraa를 봤는데, 다시 써보니 단어 줄바꿈이 어색하고, #을 숨겨서 헤더 스타일을 바꾸기 어렵고, 비표준 체크박스 문법([])을 써서 불편했음. UI는 멋지지만 Markdown 편집기로는 부족함
    • 제품이 좋아 보이지만 자체 호스팅 불가라 보안이 불명확함. 개인 노트라면 괜찮지만 업무용으로는 불안함. 수익화 계획이 있는지도 궁금함
    • <br>이 필요한 경우도 있음. 예를 들어 멀티라인 표 셀 같은 곳에서는 고정폭 폰트와 함께 써야 함
    • 자바스크립트를 끄면 빈 화면만 보임. 이건 좀 아쉬움

  • Markdown을 정말 좋아함. 그런데 아직도 대부분의 브라우저에서 .md 파일을 바로 열 수 없다는 게 놀라움. 브라우저가 자동으로 HTML로 변환해 보여주면 좋겠음

    • 나는 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)이 있음. 더 합리적이고 파싱이 쉬움

    • 하지만 한국어 사용자 입장에서는 “djot” 발음이 비속어처럼 들림
    • 사양이 명확하지 않아 새로운 구현을 만들기 어려움
    • 그래도 더 엄격하고 깔끔한 Markdown 같아서 시도해볼 예정임
    • 나는 Djot을 내 프로젝트(Moor 클라이언트)에 사용 중임. 안전하고 익숙하며 파싱이 쉬움

  • Markdown의 장점은 명확함
    텍스트 기반, git 친화적, LLM 친화적, 검색 가능성이 뛰어남
    하지만 복잡한 레이아웃이나 정밀한 타이포그래피, 바이너리 임베딩은 불가능함. 다른 제약이 있는지 궁금함

    • 다단계 리스트가 깊어지면 코드 블록처럼 렌더링되는 문제가 있음. 이건 Markdown의 큰 단점임
    • CommonMark는 HTML의 상위 집합처럼 동작함. 하지만 구현마다 미묘한 차이가 많음
    • Markdown은 간단한 메모에는 좋지만, 구조화된 문서에는 부적합함. 의미론적 마크업이 없기 때문임
    • 수식, 소문자 대문자 구분, 문서 구획 등 학술적 표현이 부족함
    • 확장 문법에서는 HTML/CSS나 base64 이미지를 넣을 수 있지만, 그건 이미 Markdown의 정신에서 벗어남

  • Markdown이 성공한 이유는 시기적 타이밍 덕분임
    AsciiDoc, org-mode 등은 더 구조적이지만 대중성이 부족했음.
    GitHub가 Markdown을 선택하면서 오픈소스 커뮤니티 전체가 자연스럽게 따라왔음.
    VHS와 Betamax의 경쟁처럼, 더 나은 기술이 아니라 먼저 자리 잡은 포맷이 승리한 셈임

  • “까칠하지만 따뜻한 사람, 지금쯤 Kubrick 영화를 보며 말도 안 되는 팀을 응원하고 있을 것 같다”는 묘사가 인상적이었음

답변달기