TL;DR

  • Markdown은 읽기 쉬운 일반 텍스트라는 원칙과 개발 도구의 채택, 인공지능(AI) 비서의 기본 출력 형식을 거치며 기술 분야를 넘어 보편적인 문서 형식이 됨.
  • 2004년 John Gruber와 Aaron Swartz가 웹 문서를 HTML 없이 작성하기 위한 형식으로 Markdown을 만듦.
  • Stack Overflow, GitHub, 정적 사이트 생성기와 노트북 도구가 Markdown을 개발자 문서의 기본 형식으로 채택함.
  • Google Docs와 AI 비서가 Markdown의 사용 범위를 넓혔으며, AGENTS.md는 AI 에이전트를 위한 공유 형식으로 자리 잡음.
  • 렌더링 방식과 확장 기능이 도구마다 달라 Markdown의 보편적인 작성 방식과 일관되지 않은 표시 방식 사이에 간극이 남아 있음.

2004년: 있는 그대로 읽을 수 있도록 만든 형식

  • Markdown은 2004년 John Gruber가 Aaron Swartz의 도움을 받아 만들었으며, 웹 문서를 작성할 때 HTML을 직접 입력하지 않는 것이 소박한 출발점임.
  • 핵심 원칙은 Markdown 파일을 변환하지 않아도 읽을 수 있어야 한다는 것임. 해시 기호를 붙인 제목, 대시를 사용한 목록, 별표 사이의 굵은 글씨처럼 일반 텍스트 이메일과 포럼에서 이미 쓰이던 습관을 활용함.
  • 이 선택이 Markdown의 지속성을 뒷받침함. .md 파일은 Notepad, vim 또는 터미널에서 열어도 내용을 따라갈 수 있으며, 이런 특성을 갖춘 형식은 많지 않음.

2008~2014년: 개발자의 언어

  • 2008~2014년 Markdown은 누군가가 명시적으로 선택한 적도 거의 없이 개발자의 기본 작성 도구가 됨.
  • Stack Overflow는 2008년 출범 때 Markdown을 채택함. GitHub는 README를 시작으로 이슈, 풀 리퀘스트, 위키에 Markdown을 적용하고 자체 변형인 GitHub Flavored Markdown을 사용함. 정적 사이트 생성기와 IPython 노트북(이후 Jupyter)도 텍스트 셀에 Markdown을 사용함.
  • 도구별 도입 내역은 다음과 같음.
  • 2014년 — MkDocs: .md로만 작성하는 기술 문서
  • 2014년 — CommonMark: 방언을 통합하기 위한 명세
  • 2013년 — Hugo: Go로 만든 정적 사이트와 Markdown 콘텐츠
  • 2011년 — IPython Notebook: 코드 셀 사이에 놓이는 Markdown 텍스트
  • 2008년 — Jekyll: .md 파일로 작성하는 개발자 블로그
  • 2008년 — Stack Overflow: Markdown으로 작성하는 질문과 답변
  • 2008년 — GitHub: README, 이슈, 풀 리퀘스트, 위키
  • 저장소 안에서 Markdown은 README에 그치지 않음. CHANGELOG.md, CONTRIBUTING.md, SECURITY.md와 이슈 및 풀 리퀘스트 템플릿을 담은 숨김 .github 디렉터리까지 코드 주변의 모든 항목이 Markdown으로 작성됨.
  • 단점은 도구마다 확장 기능을 추가한다는 점임. 표, 체크박스, 구문 강조 코드 블록은 2004년 버전에 포함되지 않았음. 같은 파일이 도구에 따라 다르게 렌더링되는 문제를 해결하기 위해 2014년 CommonMark가 등장했지만, 문제는 완전히 사라지지 않음.

2015~2022년: 저장소 밖으로 한 걸음

  • 이 시기에 Markdown은 조금씩 저장소 밖으로 확산됨.
  • Slack과 Discord는 굵은 글씨, 기울임꼴, 코드 등 문법 일부를 받아들임. Notion과 다른 편집기는 줄 앞에 입력한 해시 기호를 제목으로 바꿈. 2020년 출시된 Obsidian은 로컬에 저장하는 .md 파일을 전체 사용 방식의 기반으로 삼으며 비개발자도 많이 끌어들임.
  • 2022년 Google Docs는 입력 중 Markdown 문법을 자동으로 감지하기 시작함. 이는 Markdown이 더 이상 기술 분야 종사자만을 위한 형식이 아님을 보여주는 신호였지만, 대부분의 사람은 그 이름을 모른 채 사용함.

2023년 이후: AI가 확산을 가속함

  • Markdown의 확산을 실제로 가속한 것은 AI 비서임. AI 비서는 제목, 목록, 굵은 글씨, 표, 코드 블록을 포함한 답변을 기본적으로 Markdown으로 생성하며, 수백만 명이 이를 인식하지 못한 채 매일 읽기 시작함.
  • 2024년 7월 Google Docs는 .md 가져오기와 내보내기, Markdown에서 붙여넣기를 추가함([Google Workspace 발표](Google Workspace announcement)). Google은 기술 문서 작성자를 주로 언급하지만, 그 혜택은 모두에게 돌아감.
  • 코드 분야에서는 Markdown이 읽는 대상까지 바꿈. 사람이 아니라 AI 에이전트가 읽도록 파일을 작성하기 시작함. 각 도구가 CLAUDE.md, .cursorrules, GEMINI.md 등 자체 형식을 사용하던 가운데 OpenAI가 2025년 8월 공유 형식인 AGENTS.md를 공개함.
  • OpenAI에 따르면 2025년 12월 기준 6만 개가 넘는 오픈소스 프로젝트가 AGENTS.md를 사용하고 있으며, OpenAI는 이를 Linux Foundation에 넘김(발표).
  • README는 프로젝트를 살펴보는 사람을 위해 작성되는 반면, AGENTS.md는 작업을 시작하려는 기계를 위해 작성됨. 둘 다 같은 형식임.

기본 지원은 확산을 따라가지 못함

  • Markdown은 어디에나 있지만, 모든 도구가 이를 이해하는 것은 아님. 이 지점에서 문제가 생김.
  • Markdown 표를 한 도구에 붙여 넣으면 깔끔하게 보이지만, 다른 도구에서는 파이프와 대시가 뒤섞인 형태로 나타남. AI 비서로 작성한 이메일을 보내면 받는 사람의 받은 편지함에 별표가 가득한 문장이 도착함. 같은 .md 파일도 GitHub, VS Code, Obsidian에서 각자 확장 기능을 처리하는 방식이 달라 똑같이 표시되지 않음.
  • LinkedIn은 Markdown을 전혀 렌더링하지 않음. 게시물에서 굵은 글씨를 쓰려면 유니코드 문자를 사용해야 하며, 이 방식은 별도의 접근성 문제를 일으킴.
  • Markdown은 작성 형식으로 보편화됐지만, 표시 방식은 여전히 도구마다 다름.

이제 어떻게 될까?

  • 어디서나 똑같이 렌더링되는 단일 Markdown이 등장할 것이라고는 생각하지 않음. 형식이 단순하고 누구나 확장할 수 있었기 때문에 성공했으며, 그 자유에는 비용이 따르고 복사해 붙여 넣을 때마다 그 비용을 치름.
  • Markdown이 얼마나 멀리 왔는지가 눈에 띔. 20년 전에는 HTML 작성을 피하기 위한 요령이었고, 10년 전에는 저장소에 자리 잡은 개발자들의 형식이었음. 오늘날에는 고객이 형식인 줄도 모른 채 Markdown을 받고, AI 에이전트에게 프로젝트를 설명하는 .md 파일을 작성함.
  • 도구가 따라잡을 때까지 거의 모든 곳에서 Markdown으로 작성함. Markdown으로 읽히지 않을 곳에서도 마찬가지임.

출처

  • Google Workspace Updates, 「Google Docs에서 Markdown 가져오기 및 내보내기」, 2024년 7월
  • OpenAI, 「OpenAI가 Agentic AI Foundation을 공동 설립」, 2025년 12월
  • InfoQ, 「AGENTS.md, AI 코딩 에이전트의 오픈 표준으로 부상」, 2025년 8월