Obsidian에서 Word로: 2026년 완벽 내보내기 가이드

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

Obsidian 안에서 사는 사람이라면 이 문제를 이미 알고 있을 겁니다. 석 달을 들여 만든 리서치 노트에는 Obsidian 고유의 구문이 가득합니다 — 이런 것들 말이죠.

[[Project Plan]]        → link to another note
![[diagram.png]]        → embedded image
> [!note] Key insight   → callout block

그러다 동료가 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페이지짜리 노트라면 이걸로 충분합니다.
큰 볼트는 커뮤니티 플러그인으로 — 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을 쓰지 않는 사람이 읽을 Word 문서라면 찾아 바꾸기로 제거하세요.

수동 변환이 자동화를 이기는 경우

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

이 읽기 뷰 붙여넣기 방식은 세 가지에서 무너집니다.

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

그러니, 코드나 이미지가 없는 짧은 노트는 → 붙여넣기. 더 길거나 기술적인 것은 → 위의 4단계 워크플로우.

문제 해결: 뭔가 깨졌을 때 할 일

아래는 제가 가장 자주 보는 실패 패턴입니다. 더 넓은 레퍼런스가 필요하다면, Markdown 변환 문제 해결 가이드가 흔한 15가지 변환 문제를 상세히 다룹니다.

Word 파일에서 이미지가 누락됩니다. 90%는 경로 문제입니다. .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 to Word 완벽 가이드가 복잡한 문서에서 중요한 변환기 기능들을 짚어 줍니다.

마치며

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

전처리 습관이 한번 몸에 붙으면, 노트 하나당 파이프라인 전체가 약 5분 정도 걸립니다. 그것이 "나중에 해야지"와 오늘 실제로 문서를 보내는 것 사이의 차이입니다.