요약 · 마크다운은 일반 텍스트로 서식을 표현하는 가벼운 마크업 언어입니다. 읽기 쉬움, 어디서나 열림, HTML로의 손쉬운 변환이 장점이며, AI도 학습 친화성과 토큰 효율, 명확한 구조 때문에 마크다운을 선호합니다.
마크다운이란?
마크다운은 일반 텍스트로 서식을 표현하는 가벼운 마크업 언어입니다.
일반 텍스트는 메모장처럼 아무 장식 없는 글자를 뜻하고, 마크업 언어는 글자에 의미나 모양을 덧입히는 규칙을 말합니다. 마크다운은 태그가 길게 드러나지 않아 그대로 읽어도 자연스러운 문장을 유지합니다. 그래서 “보기 좋은 문서”와 “읽기 쉬운 원문”을 동시에 노립니다.
설계 철학과 원조 문서는 John Gruber가 공개한 프로젝트 페이지에서 확인할 수 있습니다. 참고: Markdown 프로젝트 페이지(daringfireball.net/projects/markdown/). 또한 위키백과 항목에는 개념과 역사 요약이 잘 정리되어 있습니다. 참고: 위키백과(영문) Markdown.
왜 마크다운을 쓰나
첫째, 읽기 쉽습니다. 문장 속에 기호가 드문드문 들어갈 뿐이라 소설처럼 훑어도 의미가 전달됩니다. 예를 들어 샵 하나에 공백을 붙인 "# 제목"은 큰 제목이 됩니다.
둘째, 어디서나 열립니다. 메모장, 이메일, 모바일 메모 앱 등 텍스트를 다루는 도구면 거의 모두 열 수 있어 이식성이 높습니다. 파일을 주고받을 때 상대의 앱에 덜 의존합니다.
셋째, HTML로 쉽게 변환됩니다. 웹 문서는 HTML로 표시되는데, 마크다운은 변환 도구를 통해 제목, 목록, 링크 같은 구조를 안정적으로 바꿀 수 있습니다. 그래서 블로그, 위키, 기술 문서 배포가 수월해집니다.
마크다운 개발 연대기
2002년, Aaron Swartz가 'atx' 형식을 만들었습니다. 이 아이디어가 나중에 마크다운 제목 표기에 영감을 주었습니다.
2004년 3월 9일, John Gruber가 Aaron Swartz를 사운딩 보드로 두고 마크다운을 발표했습니다. 목표는 “읽고 쓰기 쉬운 일반 텍스트로 작성하고, 필요하면 올바른 XHTML/HTML로 변환”하는 것이었습니다. 출처: Daring Fireball의 원조 문서.
2012년에는 Jeff Atwood와 John MacFarlane이 원조 명세의 모호함을 줄이려는 표준화 운동을 시작했습니다. 2014년 10월 25일, CommonMark가 공개되어 모호함 없는 표준 명세와 테스트 모음을 제공했고, 명칭은 ‘Markdown’ 사용에 대한 반대에 따라 CommonMark로 정리되었습니다. 2016년 3월에는 RFC 7763과 RFC 7764가 발표되어 미디어 타입과 설계 지침이 명시되었습니다. 2017년 GitHub는 CommonMark 기반의 GitHub Flavored Markdown(GFM) 명세를 발표하며 표, 취소선, 자동 링크, 체크리스트를 확장으로 추가했습니다. 참고: CommonMark, GitHub의 GFM 명세, 위키백과.
AI는 왜 마크다운을 좋아하나?
첫째, 학습 데이터 정합성입니다. 대형 언어모델은 GitHub, Stack Overflow, 기술 문서 등 마크다운으로 작성된 자료를 대량 학습했습니다. 모델 입장에선 익숙한 문체라 문맥 해석과 생성이 안정적입니다.
둘째, 토큰 효율입니다. 토큰은 모델이 문장을 쪼개 이해하는 최소 단위로, 불필요한 기호가 많으면 더 많은 토큰이 듭니다. 마크다운은 같은 목록을 써도 HTML 대비 약 10~20% 적은 문자를 사용해 비용과 속도에서 이점이 있습니다.
셋째, 의미적 구조가 선명합니다. 샵 기호로 제목 단계가 드러나고, 표에서는 수직선 기호로 열 구조를 표현할 수 있어 모델이 문서의 뼈대를 파악하기 쉽습니다. 이런 명시성은 요약과 변환 품질을 높입니다.
노션·워드·옵시디언에 붙여 넣으면 자동 서식
마이크로소프트 워드는 제목 기호, 굵게, 기울임, 글머리 기호, 번호 목록 같은 패턴을 자동 서식으로 인식합니다. 다만 전용 마크다운 에디터처럼 파일을 .md로 저장하거나 원문을 그대로 보이는 방식은 아닙니다.
노션은 마크다운 단축 입력을 지원합니다. 예를 들어 "# 뒤 공백"이면 큰 제목, "## 뒤 공백"이면 중간 제목이 됩니다. 붙여넣기 시 대체로 서식이 반영되지만, 라이브 에디터의 즉시 변환은 상황에 따라 들쭉날쭉할 수 있습니다.
옵시디언은 모든 노트가 .md 파일인 네이티브 앱입니다. CommonMark·GFM 기반에 위키 링크 표기와 콜아웃 같은 확장을 얹습니다. 같은 파일을 다른 마크다운 에디터에서도 그대로 열 수 있다는 점이 큰 장점입니다.
제목·표·목록 등 마크다운이 표현하는 것
마크다운은 문서의 뼈대를 만들어 줍니다. 제목과 부제목을 계층적으로 나누고, 본문을 단락으로 이어가며, 문맥상 중요한 부분은 굵게 또는 기울임으로 강조합니다.
아이디어를 정리할 때는 목록이 유용합니다. 글머리 기호 목록은 순서를 가볍게 나열하고, 번호 목록은 단계나 절차를 표현합니다. 체크박스를 써서 진행 상황을 표시하는 작업 목록도 가능합니다.
표를 이용하면 항목 간 비교가 쉬워집니다. 수직선 기호로 열을 구분하는 방식이 대표적이지만, 이 글에서는 원리만 설명합니다. 링크와 이미지도 삽입해 출처를 밝히거나 시각 자료를 더할 수 있습니다.
마크다운 문법: 핵심 개념과 사용법
제목은 샵 기호 뒤에 공백을 넣어 씁니다. 예를 들어 "# 큰 제목", "## 중간 제목", "### 작은 제목"처럼 계층을 만듭니다.
목록은 하이픈이나 별표로 시작합니다. 예로 “- 항목 하나”, “- 항목 둘” 같은 줄을 연속으로 쓰면 글머리 기호 목록이 됩니다. 순서를 강조하려면 “1. 첫 단계, 2. 둘째 단계”처럼 번호를 붙입니다.
강조는 별표나 밑줄을 씁니다. 별표 두 개로 감싸면 굵게, 하나로 감싸면 기울임처럼 표현됩니다. 링크는 대괄호와 소괄호를 조합해 제목과 주소를 함께 적습니다. 예: "[CommonMark](commonmark.org)"라는 식의 표기입니다.
마크다운과 일반 워드 문서의 차이
워드 문서는 눈에 보이는 모양을 먼저 다룹니다. 버튼을 눌러 굵게나 색상을 지정하고 레이아웃을 즉시 확인합니다. 반면 마크다운은 글자 속 의미와 구조를 먼저 적고, 모양은 렌더링 단계에서 정해집니다.
이 차이는 협업과 버전 관리에서 큰 영향을 줍니다. 마크다운은 텍스트 변경점을 줄 단위로 비교하기 쉬워 합치기가 수월합니다. 반면 워드의 바이너리 형식은 비교와 병합이 상대적으로 어렵습니다.
또한 마크다운은 앱 종속성이 낮습니다. 다양한 도구에서 동일한 원문을 열고 편집하기 쉬워 장기 보존과 마이그레이션에도 유리합니다.
마크다운 파일과 확장자 이해
.md 확장자는 마크다운 문서의 관례적 표기입니다. 일부 프로젝트는 .markdown을 쓰기도 하지만, 대부분의 도구가 .md를 표준처럼 취급합니다.
파일 안에는 평범한 텍스트만 있습니다. 그래서 버전 관리 시스템에서 이력 추적과 충돌 해결이 단순합니다. 문서 길이가 늘어나도 편집기가 가벼운 이유입니다.
이미지나 첨부는 링크로 참조합니다. 원문 폴더 구조를 깔끔히 유지하면 다른 에디터에서 열어도 경로가 깨지지 않습니다.
렌더링이란? 초보자 시선에서
렌더링은 기호로 적힌 원문을 사람이 보기 좋은 모양으로 바꾸는 과정입니다. 예를 들어 "# 제목"이라고 적힌 줄을 실제 화면에서는 큰 제목으로 보여 주는 일을 말합니다.
이 변환은 규칙에 따라 자동으로 이뤄집니다. 같은 원문이라도 웹사이트, 앱, 프린터 등 환경에 따라 글꼴과 색이 달라질 수 있습니다. 핵심은 원문이 구조를 명확히 담고 있어야 어떤 환경에서도 일관되게 보인다는 점입니다.
이 원리는 접근성과 보존성에도 좋습니다. 의미가 살아 있는 원문은 스크린 리더 같은 도구가 내용을 더 쉽게 해석합니다.
마크다운과 HTML의 관계
마크다운은 사람이 쓰기 쉬운 표기, HTML은 브라우저가 이해하는 표준 언어입니다. 마크다운 작성 후 변환기를 거치면 올바른 HTML로 바뀌어 웹에 게시할 수 있습니다.
HTML을 직접 쓰면 세밀한 제어가 가능하지만, 태그가 길어 가독성이 떨어질 수 있습니다. 마크다운은 요점을 간결히 적고 필요할 때 HTML로 내려가는 전략을 취합니다.
이 덕분에 기술 블로그나 문서 사이트는 마크다운 초안으로 협업하고, 배포 단계에서 HTML을 생성하는 파이프라인을 많이 사용합니다.
협업과 버전 관리에서의 장점
텍스트 중심의 형식은 변경 내역 비교를 쉽게 만듭니다. 누가 무엇을 추가했는지 줄 단위로 확인하고, 충돌도 의미 단위로 해결할 수 있습니다.
리뷰 과정도 단순합니다. 제안된 수정을 그대로 눈으로 읽을 수 있어 의견 교환이 빠릅니다. 툴을 바꾸더라도 원문은 그대로 재사용할 수 있어 팀의 도구 의존이 줄어듭니다.
오랫동안 보관해야 하는 정책 문서나 기술 명세도 마크다운으로 관리하면 이력과 출처가 투명해집니다.
쓰기 환경 고르기: 에디터와 플랫폼
가벼운 시작이 목적이면 메모장 또는 노션처럼 손에 익은 앱에서부터 연습하세요. 붙여넣기만으로도 상당수 서식이 인식됩니다.
전문적인 집필과 버전 관리를 염두에 둔다면 마크다운 전용 에디터나 옵시디언처럼 .md 파일을 직접 다루는 도구가 유리합니다. 원문을 그대로 보며 미리보기를 병행할 수 있습니다.
팀 작업에는 이슈 트래킹 시스템, 위키, 저장소 호스팅 서비스처럼 마크다운 친화적 플랫폼을 고려하세요. 리뷰와 배포 자동화가 쉬워집니다.
초보자를 위한 10분 루틴
1분: 오늘 쓸 주제와 큰 제목 한 줄을 적습니다. 예: "# 주간 회의 메모"처럼 단순히 시작하세요.
3분: 소제목 2~3개와 글머리 기호 목록을 거칠게 나눕니다. 예: "## 안건", "- 진행 상황 요약"처럼 짧은 구로 채웁니다.
6분: 링크 한 개와 굵게 강조 한두 곳을 더합니다. 예: "[참고 자료](commonmark.org)"처럼 출처를 붙이고, 포인트 문장을 굵게 표시합니다. 이 루틴을 반복하면 손이 먼저 움직입니다.
흔한 실수와 예방 팁
제목 뒤 공백을 빼먹는 경우가 잦습니다. “#제목”은 일부 도구에서 인식되지 않을 수 있어 “# 제목”처럼 공백을 두세요.
목록 기호 뒤 문장을 들쭉날쭉 쓰면 가독성이 떨어집니다. 각 항목을 한 줄 요약으로 시작하고 필요하면 다음 줄에서 설명을 보태세요.
링크 텍스트를 모호하게 쓰면 독자가 맥락을 놓칩니다. “여기 클릭” 대신 “API 문서”처럼 목적을 드러내는 텍스트를 권장합니다.
한국어 문서 작성 시 주의점
줄바꿈 규칙을 일정하게 유지하세요. 한국어는 조사와 어미가 변화해 문장 나눔이 흐름에 큰 영향을 줍니다. 문단을 너무 짧게 쪼개면 요지가 끊깁니다.
굵게·기울임 남용은 피하세요. 강조가 많아질수록 중요한 부분이 사라집니다. 핵심 정의나 결론 문장에만 집중 배치하는 편이 낫습니다.
한자어나 외래어 표기는 초보 독자에게 장벽이 됩니다. 처음 등장 시 한 문장으로 쉽게 풀이를 덧붙이는 습관을 들이세요.
저장·공유·변환 워크플로 제안
작성 단계에서는 의미와 구조에 집중합니다. 파일명에 날짜와 주제를 넣어 버전을 명확히 하세요. 예: “2026-05-회의-메모.md”.
검토 단계에서는 오탈자와 구조만 다듬습니다. 변환 도구로 HTML 또는 PDF를 만들고, 링크와 이미지가 정상 동작하는지 확인합니다.
배포 단계에서는 저장소나 문서 사이트에 게시합니다. 출처 링크를 남기고, 변경 이력과 태그를 정리해 나중에 찾기 쉽게 관리하세요.
앞으로의 표준과 호환성 관전 포인트
CommonMark는 모호함을 줄이는 기반 명세와 테스트를 제공합니다. 이 호환성 층이 두터울수록 도구 간 결과가 일치합니다. 참고: commonmark.org.
GFM은 표, 취소선, 자동 링크, 체크리스트 같은 실용 확장을 정의해 개발자의 실제 요구를 반영합니다. 참고: GitHub GFM 명세.
문서 생태계는 계속 진화합니다. 원조 철학과 공개 명세를 존중하는 도구를 선택하면 장기적으로 포맷 잠금 위험을 줄일 수 있습니다.
마무리 + 초보자 체크리스트
마크다운은 구조를 먼저 생각하게 하는 글쓰기 도구입니다. 간결한 표기와 높은 호환성으로 개인 메모부터 팀 문서까지 폭넓게 쓰입니다. AI가 선호하는 이유도 이 간결함과 구조적 명확성에 있습니다.
체크리스트:
- 큰 제목과 두세 개 소제목부터 잡는다
- 글머리 목록으로 개요를 만든다
- 링크와 굵게 표기로 맥락과 강조를 더한다
- 변환 미리보기로 구조가 의도대로 보이는지 확인한다
- 원문과 배포본(HTML·PDF)을 함께 보관한다
한 번의 연습으로 감이 오지 않아도, 매일 짧게 쓰면 몸에 배는 표기입니다. 원조 자료와 표준 명세를 가끔 확인하며 습관을 다져 보세요. 참고: Daring Fireball, CommonMark, GFM, 위키백과.
한국 정부도 ‘AI가 읽는 형식’으로: HWP에서 개방형으로
마크다운 이야기를 하다 보면 “한국 정부가 공식 문서를 마크다운으로 바꾼다”는 말을 듣기도 합니다. 사실관계를 정확히 짚으면, 정부가 공식 표준으로 지정한 대체 형식은 마크다운이 아니라 HWPX(개방형 한글 문서 형식)입니다. 행정안전부와 국가인공지능전략위원회 등은 2026년 5월 18일부터 공무원 문서 시스템인 ‘온나라’에서 폐쇄형 HWP 대신 개방형 HWPX 적용을 확대하기 시작했고, 온메일·정부통합메일에도 2026년 10월부터 단계적으로 넓혀 갑니다.
핵심 이유는 이 글이 말한 것과 똑같습니다. HWP의 닫힌(독점) 구조는 AI가 내용을 읽고 학습·처리하기 어렵게 만들기 때문입니다. 반대로 HWPX나 마크다운처럼 구조가 투명하게 드러나는 개방형 형식은 AI가 다루기 좋습니다. 정리하면, 정부가 마크다운 자체를 공식 표준으로 채택한 것은 아니지만, “AI는 개방적이고 구조가 드러나는 형식을 선호한다”는 큰 흐름은 이 글의 주제와 정확히 맞닿아 있습니다. (출처: The Korea Times, 2026-04-26)
마크다운 문법 한눈에 보기 (복사용 치트시트)
아래는 자주 쓰는 마크다운 문법입니다. 왼쪽처럼 기호를 입력하면 해당 서식이 됩니다. 그대로 따라 써 보세요. 노션·워드·옵시디언 등에 붙여 넣으면 대부분 자동으로 서식이 적용됩니다.
# 제목 1 (가장 큰 제목, H1)
## 제목 2 (H2)
### 제목 3 (H3)
**굵게** *기울임* ~~취소선~~ `인라인 코드`
- 목록 항목
- 목록 항목
- 들여쓴 하위 항목
1. 첫 번째
2. 두 번째
> 인용문입니다.
[링크 텍스트](https://example.com)

| 이름 | 역할 |
| --- | --- |
| 마크다운 | 텍스트로 서식 표현 |
```python ← 백틱 3개 + 언어명으로 코드 블록 시작
print("안녕, 마크다운")
``` ← 백틱 3개로 코드 블록 끝
예시: 셸 스크립트(shellscript)로 보는 코드 블록
마크다운에서는 코드를 백틱 세 개로 감싸고 언어 이름(bash)을 붙이면 코드 블록이 됩니다. 아래는 마크다운 메모 파일을 만드는 간단한 셸 스크립트 예시입니다.
#!/bin/bash
# memo.md 파일을 만들고 마크다운 제목과 목록을 추가합니다
echo "# 오늘의 메모" > memo.md
echo "" >> memo.md
echo "- 마크다운 문법 익히기" >> memo.md
echo "- 글에 적용해 보기" >> memo.md
# 만든 파일 내용 확인
cat memo.md
자주 묻는 질문
- 마크다운은 워드보다 배우기 어렵지 않나요?
- 쉽습니다. 기호 몇 개만 익히면 제목, 목록, 강조 같은 기본 서식을 바로 쓸 수 있습니다. 모양은 변환기가 알아서 처리하고, 원문은 읽기 쉬운 텍스트라 진입 장벽이 낮습니다.
- AI에게 마크다운으로 질문하면 답이 더 좋아지나요?
- 도움이 됩니다. 제목과 목록으로 구조를 명확히 하면 모델이 의도를 파악하기 쉬워 요약과 단계 안내 품질이 올라갈 수 있습니다. 토큰 사용량도 줄어 더 많은 맥락을 제공하기 좋습니다.
- 노션이나 워드에 복사해 붙여도 서식이 보장되나요?
- 대체로 적용됩니다. 노션은 단축 입력과 붙여넣기 서식을 잘 인식하고, 워드는 일부 패턴을 자동 서식으로 변환합니다. 다만 전용 마크다운 에디터와 동일하게 동작하지는 않습니다.
- 표나 체크리스트 같은 확장 문법은 어디까지 호환되나요?
- 도구마다 다릅니다. CommonMark는 공통 기반을, GFM은 표·취소선·체크리스트 같은 확장을 정의합니다. 사용하는 플랫폼의 지원 범위를 문서나 테스트로 확인하는 것이 안전합니다.