[태그:] ODF

2026년 3월 5일, 국가인공지능전략위원회가 회의 결과 문서를 마크다운(.md) 파일로 공개한다고 발표했다. 공공기관 마크다운 채택이 공식화된 순간이다. 대부분의 사람에게는 “정부가 또 뭔가 새로운 포맷을 도입하나 보다” 수준의 뉴스로 지나갔겠지만, 나에게는 지난 몇 달간 내가 겪은 변화와 완전히 겹치는 결정이었다.

지난해 말까지 Word를 쓰던 내가 Google Docs로 갔다가, 석 달 만에 다시 마크다운과 옵시디언으로 옮겨온 움직임과 정부의 이번 결정은 같은 메커니즘의 결과다. 그 메커니즘은 단순하다. AI가 문서 포맷을 선택하기 시작했다.

정부가 .md 파일을 공식 채택했다

국가인공지능전략위원회는 2026년 3월 5일, 분과별 회의와 토론 결과를 마크다운(.md) 형식으로 작성·관리하고 위원회 누리집을 통해 순차적으로 공개하겠다고 밝혔다. 위원회가 지목한 문제는 명확했다. 기존 한글(HWP) 문서는 “글꼴·자간·기호표 등 다양한 편집 요소가 포함돼 AI가 문장·문단 구조를 정확히 인식하는 데 어려움이 있다”는 것이었다 [출처: 디지털투데이 2026-03-05].

임문영 상근부위원장의 발언은 이번 결정의 성격을 요약한다.

AI 시대에는 정책 내용뿐 아니라 정책이 축적·관리되는 방식 자체를 혁신하는 것이 중요하다. 이번 문서 체계 전환은 정부가 AI를 활용하는 방식과 일하는 문화를 바꾸는 출발점이 될 것이다.

“출발점”이라는 표현이 의미심장하다. 분과별 회의 문서 하나로 시작해 범정부 공문서 체계로 번지는 흐름을 전제한 발언이다. 실제로 4월 1일 후속 보도에서는 이미 정부·공공기관·민간 기업으로 마크다운 채택이 확산 중이라는 진단이 나왔다
[출처: 디지털투데이 2026-04-01].

1년간 공공기관에서 겪은 한글의 왕국

“여기서는 다 한글 쓰니깐 무조건 한글 쓰셔야 됩니다”

이 뉴스가 얼마나 이례적인지 이해하려면 공공기관에서 한글(HWP) 파일이 어떤 위상인지 알아야 한다. 나는 보건복지부 산하 기관에서 약 1년 근무한 적이 있다. 외국계 기업에서 이직한 직후라 Word가 훨씬 익숙한 상태였다.

출근 2일차 오후, 서무가 법무법인으로부터 받은 개인정보보호법 관련 법률검토보고서를 들고 찾아왔다. 결론이 어색하다며 봐줄 수 있냐는 요청이었다. 훑어보니 법령해석 등에 어색한 부분이 있어 내가 새로 작성하기로 했다. 다만, 퇴근시간이 촉박해 가장 익숙한 Word로 후다닥 보고서를 만들었다.

작성한 보고서를 출력하여 서무에게 주었고, 서무는 내가 쓴 보고서 내용이 맞는 것 같다며 서식만 수정해서 팀장님과 국장님에게 보고하려 하니 문서 파일 원본을 달라고 요청했다. 그래서 Word 파일을 보내주었는데, 그녀는 “왜 한글이 아니라 Word를 쓰세요?”라고 물었고 내가 “Word가 익숙해서 썼습니다”고 답했더니, 돌아온 답은 이랬다.

사기업에서는 한글 안 쓰나 보네요. 그런데 여기서는 다 한글 쓰니깐 무조건 한글 쓰셔야 됩니다.

화면과 단축키도 익숙하지 않았고, 업무방법까지 강제하는 그 요구 자체가 못마땅했다. 하지만 모든 사람들이 한글로 문서를 만들어 공유하는 환경이라 개인이 버틸 방법이 없었다. 결국 한글을 썼고, 너무 불편해서 한동안 짜증이 났다.

한글은 법적 표준이 아니다 — 관행이 표준을 이긴 현실

여기서 한 가지 사실을 짚고 가야 한다. 한글(HWP)은 법적 표준이 아니다. 2007년에 이미 OpenDocument Format(ODF)이 한국 산업표준(KS)으로 지정됐고, 같은 해 정보통신부가 행정 문서 표준으로 ODF를 채택했다
[출처: ZDNet 2020-11-16].

법령상 공공기관이 HWP를 써야 한다는 조항은 없다. 그런데 왜 그토록 견고한가. 강제성이 없는 표준을 관행이 이긴 것이다. 수십만 건의 축적 문서, 공무원과 시민 양쪽의 학습비용, “한컴 뷰어로 열리긴 한다”는 안심이 결합해 지금까지 버텨왔다.

그런 공공기관에서 마크다운 전환을 공식 선언한 것은, 단순한 포맷 교체가 아니라 콘크리트 같던 관행마저 깨뜨릴 외부적 요인(AI)이 들어왔다는 것이다.

마크다운이 뭔데 정부까지 쓰나

마크다운(Markdown)은 2004년 존 그루버(John Gruber)가 에런 스워츠(Aaron Swartz)와 함께 만든 경량 마크업 언어다
[출처: Wikipedia Markdown].

그루버가 처음 제시한 설계 철학은 한 문장이었다.

“마크업 태그나 포맷 지시 없이도 평문으로 읽을 수 있어야 한다.”

문서를 여는 프로그램이 없어도 메모장에서 그대로 읽을 수 있는 수준의 단순함이 목표였다. 문법은 최소 학습량이면 시작할 수 있다.

요소	기호	예시
제목	#, ##, ###	# 대제목
굵게	**텍스트**	**중요**
목록	- 또는 1.	- 항목
링크	[텍스트](URL)	[구글](https://google.com)
인용	>	> 인용문
코드	`코드`	`print()`

20년 동안 이 언어는 조용히 세상의 인프라로 스며들었다. GitHub의 README, Reddit 게시물, Stack Overflow 답변, Discord 메시지, Notion의 문서 내부, 대부분의 정적 블로그 — 이들이 모두 마크다운이거나 마크다운 변형이다. 2014년에는 CommonMark 표준화가 시작됐고, 2017년 GitHub Flavored Markdown(GFM)이 공식 명세로 발표되면서 표·체크박스·자동링크 등의 확장이 표준으로 정착했다.
[출처: CommonMark, GFM Spec]

Word, Google Docs, 마크다운을 나란히 놓으면 이런 차이가 보인다.

항목	Word (.docx)	Google Docs	마크다운 (.md)
저장 방식	바이너리 + XML	클라우드	순수 텍스트
기본 무게	무겁다	무겁다	가볍다
AI 친화도	낮다	중간	높다
협업	파일 공유	실시간 편집	Git 등 병행 필요
학습 곡선	낮다	낮다	초기 살짝 있음
전용 도구 필요	Word	브라우저	선택 (옵시디언 등)

이 표 하나로 정부가 왜 마크다운을 택했는지가 설명된다. 가볍고, AI가 읽기 좋고, 어떤 운영체제에서도 열리고, 20년 뒤에도 메모장만 있으면 열 수 있다. 아카이빙과 AI 처리를 동시에 만족하는 포맷은 현재 마크다운이 거의 유일하다.

AI는 왜 마크다운을 선호하는가

AI가 마크다운을 “좋아한다”는 말에는 세 가지 기술적 근거가 깔려 있다.

첫째, 파서(Parser)가 필요 없다. 마크다운은 순수 텍스트라 LLM이 바로 처리한다. HWP나 .docx는 바이너리 구조라 별도 파서가 없으면 본문 추출부터 실패한다. 실제로 ChatGPT·Claude·Gemini는 한글(HWP)·HWPX 파일을 네이티브로 파싱하지 못한다. AI가 문서를 못 읽으면 엉뚱한 요약을 내놓기 쉬운데, 이걸 설명한 글을 따로 썼다. 그래서 HWPower AI Assistant, HWP-MCP, rhwp 같은 서드파티 우회 솔루션들이 등장했는데, 이들이 하는 일은 결국 하나다. HWP를 마크다운으로 변환해서 AI에 넘기는 것이다. 이미 실무에서는 마크다운이 AI와 한국어 문서 사이의 중간 언어가 되어 있었다.

둘째, 구조가 기호로 명시된다. #은 제목이고 -은 목록이며 **는 강조다. AI가 “이 부분이 제목이구나”를 추론할 필요가 없다. HWP처럼 글꼴 크기와 자간, 들여쓰기로 제목을 시사하는 방식은 기호가 아니라 시각적 신호라서, AI가 구조를 재구성하는 데 추가 비용이 든다.

셋째, 토큰이 절약된다. 같은 내용을 HTML로 쓰면 <h1>제목</h1><p>본문</p> 식으로 태그 오버헤드가 붙지만, 마크다운은 # 제목\n본문 두 줄이면 끝이다. 컨텍스트 윈도우가 한정된 LLM에게 이 차이는 누적되면 꽤 크다.

거기에 마크다운은 LLM들이 학습 단계에서 GitHub, Reddit, Stack Overflow 코퍼스로 이미 대량 노출된 포맷이다. AI가 마크다운을 잘 읽는 건 훈련된 결과이기도 하다.

AI 도구가 내 문서 포맷을 바꿔버렸다

여기부터는 내 체험담이다. 이 흐름이 중요한 이유는, 정부의 이번 결정이 거시적으로 일어나고 있는 일을 개인 차원에서 그대로 복기한 것이기 때문이다.

2025년 말 — Gemini와 Word의 불화

당시 내가 메인으로 쓰던 AI 도구는 Gemini였다. Word로 작성한 보고서를 업로드하면 본문을 잘 못 잡아내는 일이 잦았다. 표가 망가지고, 서식이 섞이고, 요약이 엉뚱한 방향으로 나갔다. 어느 날 “Google Docs로 쓰면 Gemini가 훨씬 잘 읽는다”는 말을 어디선가 듣고 Docs로 옮겼다. 실제로 인식 품질이 눈에 띄게 올라갔다. 이때만 해도 나는 “AI가 읽기 편한 포맷을 쓰자” 정도의 의식이었다.

2026년 초 — Claude로 이동, .md의 등장

주력 AI 도구를 Claude로 교체했다. 비개발자가 AI를 업무에 결합하는 과정은 이전 글에 자세히 썼다. 그런데 Claude는 내가 요청한 문서를 자꾸 .md 파일로 생성했다. 처음엔 낯설었다. 로컬 폴더에 저장된 .md 파일을 더블클릭하면 바로 열리지도 않아서, Claude 채팅 화면에서만 읽을 수 있는 파일인 줄 알았다.

그런데 Gemini에서는 잘 읽히던 Google Docs 파일을 Claude에게 주었더니 “양이 많다”며 힘들어하는 상황이 자꾸 발생했다. 반면 .md 파일은 잘 읽고, 잘 분석하고, 잘 수정했기에 울며 겨자먹기로 매번 Google Docs 파일을 .md 파일로 저장해서 클로드에게 첨부해주는 노가다를 반복했다.

그 무렵 회사 동료들 사이에서도 .md 공유가 퍼지기 시작했다. AI를 깊게 쓰는 사람들이 먼저 갈아타는 모양새였다. 왜 저런 불편한 파일을 쓸까라고 생각하면서도 그들이 그렇게 하는 데에는 다 이유가 있을 것이라 생각하고 관심을 가지기 시작했다.

2026년 봄 — 옵시디언으로 정착

마크다운을 메인으로 쓰려면 전용 편집기가 필요하다는 사실을 뒤늦게 알았다.

찾아보니 Notion을 많이 쓴다고 되어 있긴 했는데, 내 업무 환경에서는 Notion을 사용하지 않았기 때문에 다른 도구를 찾아보았다. 그래서 주변 개발자들이 많이 쓰는 옵시디언(Obsidian)을 써보기로 했고, 실제로 내 업무 스타일과 잘 맞았다.
[출처: Obsidian 공식].

옵시디언을 사용하게 된 가장 결정적인 이유는 AI(클로드 코워크)와의 궁합이었다. 옵시디언은 내 로컬 폴더를 그대로 볼트(vault)로 읽고, 마크다운 파일 수정도 즉시 반영하며, PDF·이미지 첨부까지 수용한다. Claude가 직접 접근하는 내 로컬 폴더를 그대로 옵시디언 볼트로 쓰는 구성이 가능했다.

지금 내 워크플로우는 이렇다. Claude가 .md 파일을 생성하면, 옵시디언에서 그 파일을 읽고, 그 자리에서 수정하고, 다시 Claude가 수정본을 읽는다. 사람과 AI가 같은 파일을 주고받으며 협업하는 방식이다. 옵시디언은 더 이상 노트 앱이 아니라 AI 협업 인터페이스가 됐다.

각 도구에 대한 솔직한 평가

세 도구를 다 써본 지금 내가 내리는 평가는 이렇다.

• Word: 무겁다. 기능은 많지만 AI와는 궁합이 나쁘다. 완성본 배포용으로는 여전히 유효하지만 작업 도구로는 불편해졌다. 그래도 법원에 제출하는 서면이나 공문을 쓸 때에는 꼭 필요하기에 버릴 수 없다.
• Google Docs: 구글 생태계 안에서는 훌륭하다. Gmail·Drive·Meet와 엮여 돌아간다. 그러나 Claude 같은 외부 AI에 넘길 때는 여전히 무겁게 느껴진다.
• 마크다운(.md): 가볍다. 그런데 아직 일반 보급까지는 거리가 있다. 옵시디언 같은 편집기가 필요하고, 옆 사람에게 “이거 .md로 볼래?”라고 하면 어색해하는 경우가 많다. 솔직히 아직은 AI를 능동적으로 쓰는 사람들 위주의 도구라는 느낌이다.

Word에서 마크다운까지의 전환에 석 달이 걸렸다. 그 석 달 동안 나는 “마크다운이 좋아서 선택했다”기보다 “AI와 대화하려면 이 쪽으로 와야 한다”는 압력을 따라간 쪽에 가깝다. 정부의 이번 결정도 본질은 같다.

지금 마크다운을 시작하려면

공감이 생겼다면, 시작 장벽은 생각보다 낮다.

첫째, 문법은 세 개만 외우면 시작할 수 있다. 제목(#), 목록(-), 링크([텍스트](URL)). 나머지는 쓰면서 배우면 된다. 어떤 텍스트 편집기로든 바로 .md 파일을 만들어 볼 수 있다.

둘째, 전용 편집기를 하나 고른다. 개인 추천은 옵시디언이다. 개인 사용은 무료이고, 로컬에 파일이 그대로 저장되어 클라우드 종속이 없다. Windows·macOS·Linux·iOS·Android 다 된다. 대안으로 Logseq(오픈소스, 아웃라이너 성향), Typora(WYSIWYG 단순), VS Code 마크다운 확장(개발자 친화)이 있다.

셋째, AI와 붙여놓고 쓴다. ChatGPT든 Claude든 Gemini든 상관없다. .md 파일을 만들어 작성한 뒤, AI에게 파일을 전달하고 수정·요약·확장 요청을 하는 순환을 만들면 마크다운의 진짜 가치를 체감할 수 있다.

마지막으로 한 가지 유보. 주변에서 “우리도 .md로 가자”고 합의되지 않는 한, 당분간 마크다운은 개인 작업 영역에서만 쓰게 될 것이다. 공유 문서는 여전히 Word·HWP·Docs·PDF일 가능성이 크다. 이 과도기를 받아들이고 시작하면 된다.

한글이 사라질까? — 현실적 전망

현실적으로 보자. 한글(HWP)은 가까운 시일 안에 사라지지 않는다. 과거 전례가 있다. 2007년 ODF가 한국 산업표준으로 지정됐고, 2017년 행정안전부가 “온나라 문서 2.0″으로 ODT·PDF를 공식 지원하기 시작했으나, 1년 차 도입률은 사용기관 294개 중 78개(약 26.5%)에 그쳤다. 2020년 시점까지도 공공기관 웹사이트 첨부 문서의 80~90%가 HWP였다. 표준은 선언했지만 관행은 남았다.
[출처: ZDNet 2020-11-16]

그런데 이번 국가AI전략위의 결정은 배경이 조금 다르다. 과거 ODF 전환 시도는 “개방성”이라는 명분이었고, 이번은 “AI가 읽을 수 있어야 한다”는 실용적 압력이다. 명분에는 관행이 이겼지만, 실용에는 관행이 버티기 어렵다. 공무원 개인이 GPT에 자기 보고서를 넣어보고 엉뚱한 답이 나오는 경험이 누적되면, 바꿀 동기가 내부에서 생긴다.

물론 범정부 공문서 체계가 완전히 마크다운으로 넘어가려면 수년이 걸릴지도 모른다. 나름대로 AI를 적극적으로 쓴다고 자부하는 우리 회사도 문서체계를 완전히 바꾸지는 못했다. 무겁고 단단하며 보수적인 공직에서 조직 전체의 문서체계를 바꾸는 일은 더 오래 걸릴 것이다. 하지만 민간에서 시작된 변화가 개인으로 퍼질 것이고, 그 흐름은 다시 공직으로 퍼질 것이다. 그러면 마크다운 점유율은 알아서 올라갈 것이다.

내가 3개월 만에 Word에서 마크다운까지 온 것은 내 선택이 아니라 AI가 날 끌고 온 결과였다. 정부가 공공기관 마크다운을 채택한 것도 결국 같은 힘의 결과물이다. 누가 먼저 느꼈느냐의 차이일 뿐이다.