책에 포함된 노트옵시디언 활용법: 기록을 지식으로 바꾸는 개인 지식관리 시스템

동기화, 백업, 출판으로 오래 운영하기

2026-06-16Views 85약 11분생성형 AI 활용

Summary

오래 쓰는 시스템은 운영에서 결정된다

옵시디언을 오래 쓰려면 노트를 잘 쓰는 방법만큼 운영 방식이 중요합니다. 노트가 많아질수록 문제는 더 분명해집니다. 집 컴퓨터, 회사 노트북, 휴대폰에서 같은 보관소를 열고 싶어집니다. 실수로 지운 파일을 되돌리고 싶어집니다. 일부 노트는 다른 사람에게 보여 주고 싶어집니다.

이때 세 가지를 구분해야 합니다.

동기화: 여러 기기에서 같은 최신 상태를 유지하는 일
백업: 실수, 고장, 삭제, 랜섬웨어에 대비해 과거 상태를 따로 보관하는 일
출판: 개인 보관소의 일부를 외부 사람이 볼 수 있는 형태로 공개하는 일

동기화는 백업이 아닙니다. 한 기기에서 노트를 잘못 삭제하면 그 삭제가 다른 기기에도 빠르게 반영될 수 있습니다. 어떤 동기화 서비스에는 버전 기록이나 휴지통 기능이 있지만, 그것만 믿고 별도 복사본을 만들지 않는 것은 위험합니다. 그래서 지식 시스템의 기본 원칙은 간단합니다. 원본은 편하게 쓰고, 복사본은 안전하게 남기고, 공개본은 엄격하게 고른다.

동기화, 백업, 출판으로 오래 운영하기 AI 생성 이미지

동기화 방식 고르기

동기화는 무엇인지부터 분명히 하겠습니다. 동기화는 보관소 폴더의 파일을 여러 기기에서 같은 상태로 맞추는 작업입니다. 옵시디언 보관소는 Markdown 파일과 첨부파일이 들어 있는 일반 폴더이므로 여러 방법을 선택할 수 있습니다.

처음부터 모든 방식을 비교하려고 하면 복잡해집니다. 먼저 자신에게 중요한 기준을 하나만 정해 보세요.

설정이 쉬운가?
모바일에서도 안정적으로 열리는가?
비용을 감당할 수 있는가?
충돌이 생겼을 때 직접 해결할 수 있는가?
나중에 출판이나 버전 관리로 이어 가고 싶은가?

대략적으로 보면 다음과 같이 나눌 수 있습니다.

방식	잘 맞는 경우	조심할 점
Obsidian Sync	여러 기기를 오가며 편하게 쓰고 싶을 때	유료 서비스이며, 별도 백업은 여전히 필요함
클라우드 드라이브	이미 쓰는 Dropbox, iCloud Drive, OneDrive, Google Drive가 있을 때	운영체제와 모바일 환경에 따라 동작이 다르고 충돌 파일이 생길 수 있음
Git 기반 동기화	변경 이력, 원격 저장소, 출판 흐름까지 관리하고 싶을 때	초보자에게 어렵고 큰 첨부파일 관리가 번거로움

Obsidian Sync

Obsidian Sync는 옵시디언에서 제공하는 공식 유료 동기화 서비스입니다. 설정이 단순하고, 데스크톱과 모바일을 함께 쓰기 쉽습니다. 옵시디언 보관소 구조를 전제로 만든 서비스이므로 초보자에게 가장 부담이 적습니다.

이 방식이 필요한 경우는 분명합니다. 여러 기기를 오가며 자주 쓰고, 충돌 해결이나 Git 명령어를 배우고 싶지 않으며, 모바일에서도 안정적으로 같은 보관소를 열고 싶을 때입니다.

장점은 편의성입니다. 동기화 상태를 옵시디언 안에서 확인할 수 있고, 보관소 단위로 동기화할 항목을 조정할 수 있습니다. 버전 기록 기능도 있어 실수로 내용을 바꿨을 때 되돌아가는 데 도움이 됩니다.

단점도 있습니다. 유료 서비스이고, 공식 서비스에 의존합니다. 또 버전 기록이 있다고 해서 백업을 완전히 대신한다고 보기는 어렵습니다. 계정 문제, 장기 보관, 별도 매체 보관까지 생각한다면 백업은 따로 두는 편이 안전합니다. 그리고 어떤 동기화 방식이든 충돌이 완전히 사라지는 것은 아닙니다. 예를 들어 노트북을 오프라인으로 둔 상태에서 긴 노트를 고치고, 동시에 휴대폰에서도 같은 노트를 수정하면 서로 다른 변경 사항이 생길 수 있습니다.

클라우드 드라이브

Dropbox, iCloud Drive, OneDrive, Google Drive 같은 클라우드 드라이브에 보관소 폴더를 넣는 방식도 흔합니다. 이미 쓰는 서비스가 있다면 시작하기 쉽고 비용도 낮을 수 있습니다.

하지만 클라우드 드라이브는 옵시디언 전용 동기화 도구가 아닙니다. 파일이 완전히 내려받아지기 전에 옵시디언을 열면 일부 노트나 첨부파일이 늦게 보일 수 있습니다. '온라인 전용' 또는 '필요할 때 다운로드'처럼 파일을 실제 기기에 내려받지 않는 설정도 주의해야 합니다. 옵시디언은 로컬 폴더 안의 파일을 읽는 방식이므로, 파일이 눈에 보이는 것과 실제로 내려받아져 있는 것은 다를 수 있습니다.

모바일도 확인해야 합니다. iCloud Drive는 Apple 기기끼리 쓸 때 편하지만, 다른 운영체제와 섞이면 체감이 달라질 수 있습니다. Dropbox, OneDrive, Google Drive도 데스크톱에서는 쉬워 보여도 모바일에서 보관소 폴더를 여는 방식이 운영체제마다 다를 수 있습니다. "내가 쓰는 기기 조합에서 실제로 열리고, 수정되고, 다시 반영되는지"를 작은 테스트 보관소로 먼저 확인하는 편이 좋습니다.

여러 기기에서 동시에 같은 파일을 수정하면 충돌 파일이 생길 수도 있습니다. 특히 .obsidian 폴더 안에는 설정, 플러그인 정보, 화면 배치 정보가 들어 있어 기기마다 다르게 유지하고 싶은 설정까지 함께 섞일 수 있습니다. 집 데스크톱의 넓은 화면 배치와 휴대폰의 화면 배치가 같은 방식으로 동기화되면 오히려 불편해질 수 있습니다.

클라우드 드라이브를 쓸 때는 한 가지 규칙을 지키는 편이 좋습니다. 하나의 보관소에 동기화 도구를 여러 개 겹쳐 쓰지 않습니다. 예를 들어 같은 보관소에 Obsidian Sync와 Dropbox, Git 자동 동기화를 동시에 걸면 문제의 원인을 찾기 어려워집니다.

Git 기반 동기화

Git은 파일의 변경 이력을 기록하는 도구입니다. 개발자들이 코드를 관리할 때 많이 쓰지만, Markdown 노트와도 잘 맞습니다. 언제 어떤 줄이 바뀌었는지 남기고, GitHub나 GitLab 같은 원격 저장소에 올려 둘 수 있습니다.

Git 방식은 버전 기록에 강합니다. 특히 글, 연구 노트, 공개 문서처럼 변경 이력을 남기는 것이 중요한 경우에 좋습니다. 나중에 GitHub Pages, GitLab Pages, Quartz 같은 출판 흐름으로 이어 가기도 쉽습니다.

다만 Git을 로컬 폴더 안에서만 쓰면 백업이라기보다 버전 관리에 가깝습니다. 백업의 성격을 가지려면 원격 저장소나 별도 저장장치처럼, 내 컴퓨터가 고장 나도 살아남는 위치에 복사본이 있어야 합니다. 반대로 원격 저장소를 쓸 때는 공개 범위도 조심해야 합니다. 개인 메모, 회사 자료, 고객 정보가 들어 있는 보관소를 공개 저장소에 올리면 안 됩니다.

대신 초보자에게는 어렵습니다. 충돌이 생기면 직접 해결해야 하고, 모바일 사용도 불편할 수 있습니다. 이미지, PDF, 음성 파일처럼 큰 첨부파일이 많으면 저장소가 무거워집니다. Git은 좋은 도구이지만, 모든 사용자에게 가장 편한 동기화 방법은 아닙니다.

충돌을 줄이는 작은 습관

충돌은 두 기기에서 같은 파일을 서로 다른 상태로 수정할 때 생깁니다. 충돌 자체보다 더 위험한 것은 충돌을 모르고 지나가는 것입니다. 어느 날 회의록을 열었는데 conflicted copy 같은 파일이 생겨 있고, 어떤 내용이 최신인지 알 수 없다면 이미 관리 비용이 커진 상태입니다.

다음 습관만으로도 대부분의 문제를 줄일 수 있습니다.

다른 기기에서 옵시디언을 열면 먼저 동기화가 끝날 때까지 기다립니다.
같은 노트를 두 기기에서 동시에 오래 편집하지 않습니다.
긴 글은 한 기기에서 마무리한 뒤 다른 기기에서 엽니다.
중요한 회의록이나 원고는 저장 후 잠깐 기다렸다가 다른 기기에서 확인합니다.
충돌 파일이 생기면 지우기 전에 두 파일을 열어 차이를 비교합니다.
충돌이 자주 생기는 노트는 더 작은 노트로 나눕니다.

Daily Notes는 충돌을 줄이는 데도 도움이 됩니다. 하루 기록은 날짜별 파일로 나뉘기 때문에 여러 노트가 한 파일에 몰리는 일을 줄여 줍니다. 프로젝트별 회의록도 2026-06-15 회의록처럼 날짜를 붙이면 동시에 같은 파일을 고칠 가능성이 낮아집니다.

또 하나 기억할 점은 첨부파일입니다. 노트 본문은 충돌을 비교하기 쉽지만, 이미지나 PDF처럼 바이너리 파일은 어느 쪽이 맞는지 비교하기 어렵습니다. 중요한 첨부파일을 덮어쓰기 전에 파일명에 날짜나 버전을 붙여 두면 실수를 줄일 수 있습니다.

백업 범위 정하기

백업은 무엇인지 다시 확인하겠습니다. 백업은 현재 파일을 다른 기기와 맞추는 것이 아니라, 나중에 되돌릴 수 있는 별도 복사본을 만드는 일입니다. 좋은 백업은 평소에는 조용하지만 문제가 생겼을 때 바로 꺼낼 수 있어야 합니다.

옵시디언에서 백업할 범위는 세 단계로 나눌 수 있습니다.

첫째, Markdown 노트입니다. 가장 중요합니다. 보관소 안의 .md 파일이 여러분의 생각, 회의, 프로젝트 기록, 독서 노트의 본문입니다. 이것만 있어도 대부분의 지식은 살아남습니다.

둘째, 첨부파일입니다. 이미지, PDF, 녹음 파일, 스크린샷은 노트 본문과 따로 저장됩니다. 노트에는 보통 첨부파일을 가리키는 링크만 들어 있습니다. 첨부파일 폴더를 백업하지 않으면 노트 안의 이미지가 깨질 수 있습니다.

셋째, .obsidian 설정 폴더입니다. 이 폴더에는 테마, 단축키, 코어 플러그인 상태, 커뮤니티 플러그인 설정, 화면 배치 등이 들어 있습니다. 새 컴퓨터에서 같은 환경을 빠르게 복원하고 싶다면 백업 대상에 포함합니다. 다만 설정 문제까지 함께 복사될 수 있으므로, 문제가 생겼을 때는 노트와 설정을 분리해 복원하는 것이 좋습니다.

초보자에게 권하는 최소 백업 규칙은 다음과 같습니다.

보관소 전체를 외장 저장장치나 별도 클라우드에 주기적으로 복사합니다.
한 달에 한 번은 백업 파일을 실제로 열어 봅니다.
중요한 보관소는 최소 두 곳에 복사본을 둡니다.
동기화 폴더 하나만 믿지 않습니다.
플러그인을 많이 쓰는 경우 .obsidian 폴더도 함께 백업합니다.

조금 더 엄격하게 운영하고 싶다면 3-2-1 규칙을 떠올리면 됩니다. 데이터 사본을 세 벌 정도 두고, 서로 다른 두 종류의 저장 매체나 위치를 사용하며, 그중 하나는 내 컴퓨터와 분리된 곳에 두는 방식입니다. 꼭 전문 백업 시스템을 갖추라는 뜻은 아닙니다. "노트북 안에만 있다", "동기화 폴더 안에만 있다"라는 상태를 피하라는 뜻에 가깝습니다.

백업은 복잡한 자동화보다 복원 가능성이 더 중요합니다. 백업해 두었는데 열어 본 적이 없다면 아직 안전하다고 말하기 어렵습니다. 가끔은 새 폴더를 하나 만들고, 백업본에서 몇 개의 노트와 첨부파일을 실제로 복원해 보세요. 그때 이미지가 열리는지, 링크가 깨지지 않는지, 필요한 설정이 살아 있는지 확인할 수 있습니다.

로컬 우선과 Markdown의 실제 의미

옵시디언을 쓰는 큰 이유 중 하나는 로컬 우선 구조입니다. 원본 노트가 특정 회사 서버 안에만 있는 것이 아니라, 사용자가 접근할 수 있는 폴더 안에 Markdown 파일로 존재합니다. 이런 구조는 소유권, 이동성, 장기 보존에 유리합니다. 실제로 옵시디언을 기반으로 공개 사이트를 만든 사례에서도 로컬 Markdown 파일이 콘텐츠의 원본이라는 점을 장점으로 설명합니다.¹

하지만 로컬 우선이 자동으로 완전한 개인정보 보호를 뜻하지는 않습니다. 내 컴퓨터에 원본이 있다는 말과 아무도 볼 수 없다는 말은 다릅니다. 보관소를 클라우드 드라이브에 동기화하면 그 서비스의 보안 정책을 따릅니다. 회사 컴퓨터에 보관소를 두면 회사의 관리 정책을 받을 수 있습니다. 노트북을 잃어버리면 디스크 암호화와 계정 잠금이 중요해집니다.

Markdown도 마찬가지입니다. Markdown은 오래 보관하기 좋은 형식입니다. 일반 텍스트라서 옵시디언이 없어도 다른 편집기로 열 수 있습니다. 제목, 목록, 링크 같은 구조가 비교적 단순합니다. 그러나 옵시디언의 위키 링크, 속성, 콜아웃, Canvas, 특정 플러그인 문법은 다른 도구에서 그대로 보이지 않을 수 있습니다.

그래서 장기 보존을 생각한다면 핵심 노트는 가능한 한 단순하게 씁니다. 중요한 내용은 플러그인 화면 안에만 두지 말고 Markdown 본문에 남깁니다. 첨부파일 이름도 알아볼 수 있게 정합니다. 예를 들어 IMG_3920.png보다 2026-06-15_세미나_화이트보드.png가 오래 살아남습니다.

일부 노트를 공개 지식베이스로 전환하기

출판은 보관소 전체를 인터넷에 올리는 일이 아닙니다. 개인 보관소에는 미완성 생각, 사적인 기록, 업무 정보, 타인의 개인정보가 섞여 있습니다. 공개 지식베이스를 만들려면 먼저 공개 범위를 정해야 합니다.

가장 단순한 기준은 속성으로 표시하는 것입니다.

---
publish: true
status: public
---

이런 표시는 노트가 공개 후보라는 뜻입니다. 단, 표시만으로 안전해지는 것은 아닙니다. 공개 도구가 이 속성을 실제로 읽고 공개 대상을 제한해야 합니다. 도구가 속성을 읽지 않는다면, 이 표시는 단지 내가 보기 위한 메모일 뿐입니다.

Obsidian Publish

Obsidian Publish는 옵시디언에서 제공하는 공식 출판 서비스입니다. 기술 설정을 많이 하고 싶지 않은 사람에게 적합합니다. 공개할 노트를 선택하고, 사이트 형태로 보여 줄 수 있습니다. 별도 정적 사이트 생성기나 서버 설정을 다루지 않아도 된다는 점이 장점입니다. 여러 공개 방식 비교에서도 편의성 면에서는 Obsidian Publish가 가장 낮은 진입 장벽을 가진 방식으로 소개됩니다.²

단점은 유료 서비스이며, 디자인과 배포 방식의 자유도가 직접 구축 방식보다 낮을 수 있다는 점입니다. 그래도 글을 쓰는 일이 목적이고 서버 관리가 부담스럽다면 좋은 선택입니다. 특히 "내 보관소의 일부를 빠르게 공개 사이트로 만들고 싶다"는 목적이라면 복잡한 배포 파이프라인을 만들지 않아도 된다는 점이 큽니다.

Quartz, Hugo, GitHub Pages

Quartz와 Hugo는 Markdown 파일을 웹사이트로 바꾸는 정적 사이트 생성기입니다. 정적 사이트란 서버가 매번 페이지를 새로 계산하지 않고, 미리 만들어 둔 HTML 파일을 제공하는 방식입니다. 빠르고 관리 비용이 낮습니다.

GitHub Pages나 GitLab Pages는 이런 정적 사이트를 공개하는 호스팅 방식으로 자주 쓰입니다. 예를 들어 GitLab Pages를 이용한 흐름에서는 Obsidian 노트가 들어 있는 폴더를 MkDocs 같은 도구가 읽고, 빌드 결과물을 Pages가 배포합니다.³ GitHub Pages도 비슷하게 저장소에 있는 Markdown과 빌드 결과를 이용해 사이트를 공개할 수 있습니다.

Quartz는 옵시디언식 링크와 디지털 가든에 관심 있는 사용자에게 인기가 있습니다. 한 Quartz 사용 사례에서는 공개할 Markdown 노트에 publish: true를 붙이고, .obsidian 폴더와 비공개 첨부파일은 배포 대상에서 제외하는 방식으로 개인 보관소와 공개 사이트의 경계를 만들었습니다.⁴ 이런 설정은 강력하지만, 그만큼 사용자가 실수하지 않도록 규칙을 관리해야 합니다.

Hugo는 블로그나 문서 사이트처럼 구조가 분명한 공개물에 잘 맞습니다. 다만 옵시디언의 위키 링크, 콜아웃, 일부 플러그인 문법을 그대로 이해하지 못할 수 있으므로 변환 규칙이나 테마 설정을 확인해야 합니다. 옵시디언 안에서는 자연스럽게 보이던 링크가 웹사이트에서는 깨질 수 있기 때문입니다.

Quartz Syncer 같은 플러그인은 옵시디언과 Quartz 출판 흐름을 연결해 주며, 특정 폴더만 출판 대상으로 삼는 방식도 지원합니다.⁵ 공개할 노트를 별도 폴더에 모으고 싶은 사람에게 유용합니다. 다만 플러그인을 쓰더라도 공개 전 검토 책임은 사용자에게 있습니다.