Obsidian 노트를 Word로 내보내기: 2026 완벽 가이드

서식이 그대로 보존된 Microsoft Word 문서로 변환된 Obsidian 볼트

Obsidian을 주력으로 사용해 보신 분이라면 이 문제를 이미 겪어 보셨을 것입니다. 석 달 동안 공들여 작성한 리서치 노트에는 Obsidian 고유의 구문이 가득합니다. 이런 것들이죠.

[[Project Plan]]        → 다른 노트로의 링크
![[diagram.png]]        → 이미지 임베드
> [!note] Key insight   → 콜아웃 블록

그런데 동료가 Word 버전을 요청하는 순간, 위 비표준 요소들이 모두 깨져 버립니다.

저는 Obsidian을 절대 쓰지 않는 담당자에게 40 페이지짜리 기술 조사 보고서를 넘겨야 했을 때 처음 이 문제를 겪었습니다. 볼트 안에서는 깔끔하던 내용이 Word로 옮기자마자 괄호 덩어리와 사라진 이미지 자리표시자로 가득 찬 엉망이 되어 나왔습니다. 그 이후로 비슷한 변환 작업을 여러 번 거치면서 안정적인 워크플로우를 정착시켰습니다. 이 글은 그 과정을 기록한 것입니다. 대부분 건너뛰지만 실제로는 중요한 전처리 단계, Obsidian 특유의 세 가지 함정, 그리고 이미지나 콜아웃이 말을 듣지 않을 때의 대처법까지 정리했습니다.

Obsidian의 Markdown이 이식성이 없는 이유 (그리고 무엇이 깨지는가)

Obsidian은 노트를 순수한 .md 파일로 저장하기 때문에, 많은 분들이 Word로 내보내는 일도 당연히 간단할 거라고 생각합니다. 하지만 그렇지 않습니다. 일반 변환기가 이해하지 못하는 기능들로 Obsidian이 표준 Markdown을 확장해 놓았기 때문입니다.

Obsidian 고유 Markdown 구문과 표준 CommonMark 출력의 나란한 비교

내보내기를 실패시키는 주요 확장 구문은 다음 네 가지입니다.

Obsidian 구문	의미	Word에서의 결과
`[[Project Plan]]`	다른 노트로의 위키링크	`[[Project Plan]]` 문자열 그대로 표시
`![[diagram.png]]`	첨부파일 임베드	문자열만 남고 이미지는 유실
`> [!warning] Title`	콜아웃 블록	일반 인용구로만 렌더링, 헤더 정보 소실
`dataview` 코드 블록	동적 쿼리 결과	렌더링된 표가 아니라 쿼리 소스 그대로 출력

표준 Markdown 변환기, 예를 들어 Pandoc이나 대부분의 온라인 도구는 [[...]]를 일반 텍스트로, ![[...]]를 인식 불가 토큰으로 처리합니다. Obsidian 앱에서 보이는 깔끔한 화면은 프리뷰일 뿐 소스가 아닙니다. "왜 내보내기가 망가졌지"라는 당혹감의 근본 원인이 바로 이 차이에 있습니다.

조금 더 숨겨진 문제도 있습니다. 첨부파일 경로 문제입니다. Obsidian은 ![[image.png]]를 만나면 볼트 전체에서 파일명이 일치하는 파일을 폴더와 관계없이 찾아냅니다. 반면 표준 Markdown은 명시적인 상대 경로가 필요합니다. 볼트가 첨부파일을 99 Attachments/에 저장하고 노트가 10 Projects/에 있다면, 어떤 변환기든 이미지를 찾을 수 있도록 먼저 링크를 다시 작성해 주어야 합니다.

내보내기 전에: 여러분을 구해줄 전처리 단계

제 워크플로우에서 안정성을 가장 크게 끌어올린 비결은, 어떤 변환기를 돌리기 전에 5 분 정도의 전처리 작업을 하는 것이었습니다. 이 과정을 건너뛰면 변환 후 Word 파일을 정리하는 데 30 분을 쓰게 됩니다.

노트 폴더와 첨부 파일 폴더가 구분된 Obsidian 볼트 구조 예시

1단계: 첨부파일 설정을 확인한다

Settings → Files and links를 엽니다. 두 가지 값을 확인하세요.

Default location for new attachments — 새 이미지/PDF가 저장되는 위치
New link format — Obsidian이 경로를 기록하는 방식 (Shortest path when possible, Relative path to file, Absolute path in vault 중 하나)

이 값이 Obsidian 기본값인 Shortest path when possible로 되어 있으면, 첨부파일이 노트와 다른 폴더에 있는 모든 노트의 내보내기가 깨집니다. 내보내기 전에 반드시 Relative path to file로 바꾸세요. 다만 이 설정은 앞으로 생성되는 링크에만 적용되고, 기존 링크는 다시 써주지 않는 한 옛 형식 그대로 남습니다. 이어지는 2단계에서 그 재작성 작업을 다룹니다.

2단계: 위키링크를 표준 Markdown 링크로 변환한다

Obsidian에는 전용 토글이 있습니다. Settings → Files and links → Use [[Wikilinks]] → OFF로 설정하면, 새로 만들어지는 링크가 [Note Name](Note-Name.md) 형식으로 기록됩니다. 그러나 이 토글 역시 앞으로 생성되는 링크에만 영향을 줍니다.

노트 안에 이미 작성된 [[wikilinks]]를 변환하려면 두 가지 선택지가 있습니다.

소규모 내보내기는 수동 처리 — 노트에서 Cmd/Ctrl+F로 [[를 찾아 하나씩 바꿔줍니다. 5 페이지짜리 노트에는 충분합니다.
큰 볼트에는 Community plugin 활용 — Settings → Community plugins를 열고 *"link converter"*나 "markdown links" 같은 검색어로 탐색하세요. 위키링크는 물론 임베드 ![[...]] 첨부 파일까지 표준 Markdown 구문으로 일괄 변환해 주는 플러그인이 여럿 있습니다. 현재 파일 단위로도, 폴더 전체로도 돌릴 수 있습니다. 최근에 업데이트가 이루어지고 사용자 수가 충분해서 믿을 만한 것을 고르세요.

변환 후 임베드 첨부파일은 ![image.png](path/to/image.png) 형태가 됩니다. 결과물을 꼭 검토하세요. 첨부 폴더 이름에 공백이 들어 있다면 URL 인코딩(My%20Vault/attachment.png)을 해주어야 합니다. 그렇지 않으면 변환기가 경고 없이 이미지를 그냥 누락시킵니다.

3단계: 콜아웃을 어떻게 처리할지 결정한다

Obsidian 콜아웃(> [!note], > [!warning] 등)은 볼트 내에서는 유용하지만 Word에는 대응되는 요소가 없습니다. 작업량 순으로 세 가지 선택지가 있습니다.

품질 저하 수용 — 평범한 인용구로 렌더링됩니다. 콜아웃의 종류(note/warning/tip)는 사라지지만 본문 내용은 보존됩니다. 대부분의 업무 인계에는 이 정도면 충분합니다.
중요한 것만 수동으로 다시 쓴다 — 내보내기 전에 > [!warning] Critical를 > **⚠️ Critical:**로 바꿔 적습니다. 두 도구 모두에서 자연스럽게 읽힙니다.
Word에서 후처리한다 — Word의 빠른 스타일 기능으로 인용구를 스타일 박스로 변환합니다. 격식 있는 산출물에만 쓸 만한 방법입니다.

저는 20 페이지 이하 문서에는 두 번째 방법을, 그 이상은 첫 번째를 씁니다.

4단계: Dataview 블록을 정적 콘텐츠로 변환한다

노트에 Dataview 쿼리가 들어 있다면, 내보내기 결과에는 렌더링된 표가 아니라 쿼리 코드가 그대로 나옵니다. 내보내기 전에 Obsidian에서 쿼리를 실행하고, 렌더링된 결과를 복사해 정적 Markdown 표로 코드 블록을 대체하세요. 네, 수작업입니다. 그리고 깔끔한 우회로는 없습니다. Dataview는 클라이언트 측에서 렌더링되기 때문에, 소스 파일에는 실제 데이터가 애초에 들어 있지 않습니다.

네 단계 내보내기 워크플로우

네 단계 워크플로우 다이어그램: Obsidian 볼트 전처리, Markdown 내보내기, 변환기 실행, Word 문서 후처리

전처리가 끝나면 실제 변환은 매우 간단합니다.

1. 노트를 복제한다 (제자리에서 내보내지 않는다)

대상 노트와 첨부파일을 볼트 바깥의 임시 폴더로 복제하세요. 링크 재작성이나 콜아웃 교체 같은 전처리가 원본 볼트를 오염시키는 것을 막기 위함입니다. 저는 바탕화면에 _export-staging/ 폴더를 고정해 두고 사용합니다.

2. 첨부파일 경로를 평탄화한다

참조되는 모든 이미지를 .md 파일과 같은 폴더로 옮기고, 링크도 단순한 파일명으로 고치세요. 예를 들어 ![diagram](../../99 Attachments/diagram.png) 대신 ![diagram](diagram.png)로 바꿉니다. 상위 폴더로 거슬러 올라가는 경로는 대부분의 변환기가 제대로 처리하지 못합니다.

3. 변환기를 실행한다

전처리를 마친 .md 파일을 MarkFlow의 Markdown to Word 변환기에 업로드하세요. GitHub Flavored Markdown(GFM)을 지원해서 표, 작업 목록, 각주까지 처리합니다. 전처리 이후 Obsidian이 만들어 내는 모든 표준 기능을 커버한다는 뜻입니다. 이미지는 인라인으로 임베드되고, 코드 블록은 구문 강조를 유지하며, 제목은 Word의 Heading 스타일에 매핑되어 출력 DOCX에서도 탐색 창이 바로 작동합니다.

노트에 LaTeX 수식( $E=mc^2$ 나 $$...$$)이 포함되어 있다면, 선택한 변환기가 이를 평문으로 납작하게 만들지 않고 Word 수식으로 보존하는지 꼭 확인하세요. 수식 비중이 큰 문서 — 연구 일지나 학술 초안 — 에서는 이 부분이 성패를 가릅니다. 최종 포맷이 Word가 아니어도 괜찮고 공유용 파일만 있으면 되는 경우라면, Markdown을 PDF로 변환하는 쪽이 Word의 수식 렌더링 이슈를 아예 피해 갈 수 있습니다.

4. Word에서 다듬는다

DOCX를 열고 여러분의 Word 템플릿이 있다면 적용합니다. Markdown의 제목 스타일이 Word의 기본 Heading 1/2/3에 깔끔하게 매핑되기 때문에, Design → Document Formatting 한 번이면 문서 전체 스타일을 다시 입힐 수 있습니다. 발송 전에 반드시 세 가지를 확인하세요.

목차 — References → Table of Contents로 목차를 삽입해서 모든 제목이 제대로 인식되었는지 검증
이미지 크기 — Obsidian은 원본 크기로 보여주는 반면, Word는 과장되게 키우는 경우가 있습니다. 필요하면 전체 선택 후 일괄 크기 조정
하이퍼링크 — 외부 링크는 반드시 동작해야 하고, 내부 [[wikilinks]]는 정상 링크로 해결되었거나 제거된 상태여야 함

Obsidian 특유의 예외 사례

자주 마주치는 몇 가지 시나리오를 개별적으로 짚어 두는 편이 좋겠습니다.

데일리 노트와 템플릿

{{date}}나 templater 변수를 사용하는 데일리 노트를 내보낼 때, 내보내기는 Obsidian이 변수를 치환한 이후에 일어납니다. 그래서 내보낸 .md에는 플레이스홀더가 아니라 실제 날짜가 들어가 있습니다. 따로 처리할 것이 없습니다. 예외는 Obsidian에서 노트를 열지 않고 파일 시스템에서 바로 내보낸 경우입니다. 이때는 치환되지 않은 템플릿 변수가 그대로 흘러나올 수 있습니다. 노트를 먼저 열어 Obsidian이 렌더링하게 한 뒤 내보내세요.

캔버스 파일

Obsidian 캔버스(.canvas) 파일은 Markdown이 아닌 JSON 형식입니다. 어떤 Markdown 변환기도 이를 건드리지 못합니다. 캔버스의 경우 실용적인 방법은 원하는 배율로 캔버스를 스크린샷으로 찍어 PNG로 저장한 뒤, 래퍼 역할을 하는 Markdown 노트에 그 이미지를 임베드해 내보내는 것입니다. 이 작업이 잦다면 "캔버스를 이미지로 내보내기" 기능을 제공하는 커뮤니티 플러그인을 설치하는 것도 좋은 선택입니다.

Mermaid 다이어그램

mermaid 태그가 붙은 펜스 코드 블록은 Obsidian에서는 다이어그램으로 렌더링됩니다. 대부분의 온라인 Markdown-to-Word 변환기는 이를 이미지로 렌더링하거나(좋음), 코드 그대로 남겨둡니다(나쁨). MarkFlow는 Mermaid를 변환 전에 인라인 SVG로 렌더링하는데, Word는 이를 편집 가능한 이미지로 표시합니다. 사용 중인 변환기가 Mermaid를 지원하지 않는다면, Obsidian의 뷰에서 다이어그램을 PNG로 내보낸 뒤 해당 코드 블록을 표준 이미지 임베드로 교체하는 우회로가 있습니다.

각주

좋은 소식입니다. Obsidian의 각주 구문([^1]과 [^1]: text 정의)은 표준 GFM이라서 Word 기본 각주 기능으로 깔끔하게 변환됩니다. 별도 전처리가 필요하지 않습니다.

태그와 프론트매터

YAML 프론트매터(노트 상단의 --- 블록)는 대개 변환기가 제거합니다. 프론트매터에 독자가 알아야 할 정보(작성자, 날짜, 상태)가 담겨 있다면, 내보내기 전에 일반 문단으로 본문에 옮겨 두세요. #project/research 같은 인라인 태그는 보통 일반 텍스트로 남아 살아남습니다. 대부분의 경우 이 정도면 괜찮지만, 어색하게 보이는 맥락도 있습니다. Obsidian을 쓰지 않는 독자가 읽을 문서라면 찾아 바꾸기로 제거하는 편이 낫습니다.

수동 변환이 자동화보다 나은 경우

솔직하게 말씀드리면, 서식이 단순한 2-3 페이지짜리 노트 하나뿐이라면 가장 빠른 방법은 Obsidian 읽기 모드에서 복사해 Word에 붙여넣기입니다. Obsidian의 읽기 모드는 HTML로 렌더링하고, Word는 HTML을 서식 있는 콘텐츠로 놀라울 만큼 잘 붙여넣습니다. 표도 그대로, 볼드/이탤릭도 살아남고, 제목은 Word 제목 스타일로 매핑됩니다.

다만 이 읽기 모드 붙여넣기 방식은 세 가지 상황에서 무너집니다.

이미지 — 볼트 내 파일을 참조하는 링크로 붙여넣어지기 때문에, 파일이 여러분의 기기를 떠나는 순간 깨집니다
코드 블록 — 구문 강조가 사라지고, 고정폭 폰트도 일관되지 않습니다
콜아웃과 Mermaid — 일반 내보내기와 동일하게 깨집니다

정리하면, 코드나 이미지가 없는 짧은 노트는 붙여넣기로 끝내고, 그 외에 더 길거나 기술적인 문서는 위의 4단계 워크플로우를 쓰세요.

문제 해결: 뭔가 깨졌을 때의 대처법

아래는 제가 가장 자주 만나는 실패 패턴입니다. 더 넓은 범위의 레퍼런스가 필요하다면, Markdown 변환 문제 해결 가이드에서 흔한 15가지 변환 문제를 상세히 다루고 있습니다.

Word 파일에서 이미지가 누락됩니다. 약 80%는 경로 문제입니다. .md 소스를 열어 첨부파일 경로가 단순 파일명(image.png)인지, 복잡한 경로(../../99 Attachments/My Folder/image.png)인지 확인하세요. 평탄화가 답입니다.

표가 한 줄짜리 엉망으로 렌더링됩니다. 소스가 Obsidian의 구형 표 형식을 쓰고 있거나 파이프 문자가 일관되지 않은 경우입니다. .md 파일을 일반 텍스트 에디터로 열어 모든 행의 파이프 개수가 같은지 확인하세요. 헤더 구분선도 | --- | --- | 형식과 맞아야 합니다.

코드 블록이 구문 강조를 잃어버립니다. 여는 삼중 백틱 바로 뒤에 언어 태그(예: python, js, bash)가 있는지 확인하세요. 변환기는 이 태그를 바탕으로 구문 강조를 적용합니다. 태그가 없으면 기본값은 일반 텍스트입니다.

내보낸 후에도 위키링크가 [[Note Name]]으로 표시됩니다. 전처리가 실행되지 않았거나 해당 파일을 포함하지 않은 것입니다. 설정에서 Use [[Wikilinks]]가 꺼져 있는지 확인하고, 2단계에서 설치한 변환 플러그인을 해당 파일 대상으로 다시 돌리세요. 대부분의 플러그인은 볼트 전체가 아니라 단일 노트에 대한 범위 지정 실행을 지원합니다.

수식이 날것의 LaTeX으로 표시됩니다. 변환기가 수식 렌더링을 지원하지 않는 것입니다. 변환기를 바꾸거나, Obsidian에서 렌더링된 수식을 스크린샷으로 찍어 이미지로 임베드하세요. 보기에 투박하지만 확실한 방법입니다.

팀을 위한 현실적인 워크플로우

팀 안에서 Obsidian을 쓰는 유일한 사람이고 Word 파일을 자주 넘겨야 한다면, 일회성 내보내기 스크립트보다 반복 가능한 프로세스를 만드는 편이 낫습니다. 제가 협업 프로젝트에서 쓰는 버전은 이렇습니다.

볼트 안에 Word로 갈 노트를 모아둘 전용 Exports/ 폴더를 둡니다
그 폴더 내에서는 위키링크가 아니라 처음부터 표준 Markdown 링크([text](note.md))를 씁니다. 전처리 수고를 아낍니다
매주 변경된 노트만 골라 일괄 변환을 돌립니다
DOCX 산출물은 볼트가 아니라 공유 드라이브에 보관합니다

핵심은 사고 공간(Obsidian 고유 기능이 살아있는 메인 볼트)과 전달 공간(표준 Markdown을 쓰는 Exports/ 폴더)을 분리하는 것입니다. 이런 구조로 리팩터링하는 데 처음에는 한 시간 정도 걸렸지만, 이후 매달 몇 시간씩 아끼게 되었습니다.

반대 방향 — Markdown으로 글쓰기를 시작해 기본기를 제대로 익히고 싶다면, Markdown 작성법 가이드가 어떤 내보내기든 수월하게 만들어 주는 기초 지식을 정리해 두었습니다. 변환 파이프라인을 더 깊이 들여다보고 싶다면, Markdown → Word 완벽 가이드에서 복잡한 문서를 다룰 때 중요한 변환기 기능들을 살펴보실 수 있습니다.

마치며

Obsidian의 진짜 강점은 비표준 기능들 — 위키링크, 콜아웃, 볼트를 살아 움직이게 만드는 동적 쿼리 — 에 있습니다. Word로 내보낸다는 건 그중 대부분을 포기한다는 뜻입니다. 요령은 더 이상 싸우지 않는 데 있습니다. Word 버전은 납작해진 표현일 수밖에 없음을 받아들이고, 그에 맞게 전처리를 해두고, 필요한 부분의 완성도는 Word의 스타일링 도구로 다시 쌓는 것입니다.

전처리 습관이 몸에 붙고 나면 노트 하나당 파이프라인 전체가 약 5 분 정도로 줄어듭니다. "나중에 해야지"와 "오늘 바로 문서를 보낼 수 있다" 사이의 차이가 바로 이 5 분입니다.