Obsidian Git 플러그인으로 자동 백업 설정하기

이제 백업 비서를 옵시디언 안에 들여놓자

지난 장에서 우리는 GitHub Desktop으로 수동 백업을 해 보았습니다. 옵시디언에서 노트를 쓰고, GitHub Desktop에서 변경 사항을 확인하고, 커밋한 뒤, 푸시까지 눌렀습니다. 이 흐름을 한 번이라도 성공했다면 이미 절반은 온 것입니다. 왜냐하면 자동 백업도 결국 같은 일을 반복할 뿐이기 때문입니다.

이번 장에서 설치할 Obsidian Git 플러그인은 이 반복 작업을 옵시디언 안으로 가져옵니다. GitHub Desktop을 매번 열지 않아도, 옵시디언에서 일정 시간마다 변경된 노트를 커밋하고 필요하면 GitHub 저장소로 푸시할 수 있습니다. 플러그인 공식 저장소에서도 Obsidian Git의 핵심 기능으로 자동 commit-and-sync, 시작 시 자동 pull, 소스 컨트롤 화면, 히스토리 보기 등을 소개합니다.¹

쉽게 말하면, 이제 우리에게 작은 백업 비서가 생기는 셈입니다. 강의안을 고치고, 프롬프트를 다듬고, 수강생 질문을 정리하는 동안 이 비서는 조용히 뒤에서 묻습니다. "지금까지 바뀐 내용, 기록해 둘까요?" 그리고 우리가 정한 시간 간격에 맞춰 노트의 변화 기록을 남깁니다.

다만 중요한 전제가 있습니다. 자동화는 마법이 아니라 반복 작업의 위임입니다. GitHub Desktop으로 Pull, Commit, Push가 무엇인지 배웠기 때문에 Obsidian Git의 자동 백업도 이해할 수 있습니다. 이 장의 목표는 "자동으로 되게 만들기"가 아니라, "자동으로 무엇이 일어나는지 알고 안전하게 맡기기"입니다.

자동 백업은 정확히 무엇을 하는가

Obsidian Git에서 말하는 자동 백업은 단순히 파일을 복사해 두는 기능이 아닙니다. 정해진 간격마다 볼트 안에서 바뀐 파일을 확인하고, 변경이 있으면 커밋을 만든 뒤, 설정에 따라 GitHub 같은 원격 저장소로 푸시하는 흐름입니다. 플러그인 문서에서도 commit-and-sync 작업을 일정 시간마다 자동 실행하도록 설정할 수 있으며, 설정에 따라 pull이나 push 부분을 끌 수도 있다고 설명합니다.²

여기서 세 단어를 다시 붙잡아 봅시다. 커밋은 내 컴퓨터 안에 변화 기록을 남기는 일입니다. 푸시는 그 기록을 GitHub 서버로 올리는 일입니다. 풀은 GitHub 서버에 있는 최신 내용을 내 컴퓨터로 가져오는 일입니다.

자동 백업을 켠다는 것은 이 세 가지 중 일부 또는 전부를 옵시디언이 대신 실행하게 한다는 뜻입니다. 우리가 커피를 마시며 강의 사례를 정리하는 동안, 플러그인은 뒤에서 변경된 파일을 살피고, 약속된 시간이 되면 기록을 남깁니다.

하지만 여기서 조심해야 합니다. 자동 백업 간격을 너무 짧게 잡으면 노트를 한 줄 고칠 때마다 기록이 지나치게 많이 생기고, 작업 중간에 네트워크 요청이 자주 발생할 수 있습니다. 처음에는 5분에서 10분 정도로 시작하는 것을 권합니다. 이 정도면 강의 준비 흐름을 크게 방해하지 않으면서도, 컴퓨터가 갑자기 꺼졌을 때 잃을 수 있는 작업량을 줄여 줍니다.

시작 전 확인할 것

이번 장은 지난 장에서 만든 GitHub 저장소와 옵시디언 볼트가 이미 연결되어 있다는 전제로 진행합니다. 즉 GitHub Desktop에서 최소 한 번은 Commit과 Push를 성공했고, GitHub 웹사이트에서 내 노트 파일이 보이는 상태가 가장 좋습니다.

Obsidian Git 플러그인은 데스크톱 환경에서 사용하는 것을 기본으로 생각하세요. 공식 저장소에서도 모바일 지원은 실험적이며 불안정할 수 있다고 안내합니다.³ 우리 커뮤니티의 온보딩 기준은 Windows 또는 macOS 노트북입니다. 모바일까지 Git으로 자동 동기화하려는 시도는 나중에 별도 운영 규칙이 생긴 뒤 다루는 편이 안전합니다.

설정 전에 다음 세 가지를 확인합니다.

• GitHub Desktop으로 해당 볼트를 한 번 이상 커밋하고 푸시했다.

• GitHub 웹사이트에서 저장소가 보이고, 노트 파일도 실제로 열린다.

• Obsidian에서 열고 있는 폴더와 GitHub Desktop이 관리하는 폴더가 같다.

여기서 세 번째가 특히 중요합니다. Obsidian Git은 현재 열려 있는 옵시디언 볼트 안에서 작동합니다. 만약 옵시디언이 엉뚱한 폴더를 열고 있다면 플러그인도 엉뚱한 곳에서 Git을 찾게 됩니다. 자동화가 실패하는 초보자 사례의 상당수는 설정값 문제가 아니라 폴더 위치 문제입니다.

Obsidian Git 설치하기

이제 플러그인을 설치해 보겠습니다. 옵시디언 왼쪽 아래의 톱니바퀴 아이콘을 눌러 설정으로 들어갑니다. 왼쪽 메뉴에서 커뮤니티 플러그인을 선택합니다. 커뮤니티 플러그인이 꺼져 있다면 먼저 사용을 켭니다. 그다음 탐색 또는 Browse 버튼을 눌러 플러그인 검색 화면으로 들어갑니다.

검색창에 Git을 입력합니다. 플러그인 이름은 화면이나 버전에 따라 Git 또는 Obsidian Git처럼 보일 수 있습니다. 개발자 이름이 Vinzent 또는 Vinzent03으로 표시되는 플러그인을 찾으면 됩니다. 설치 버튼을 누른 뒤, 반드시 활성화 버튼까지 눌러야 합니다. 설치만 하고 활성화하지 않으면 플러그인은 작동하지 않습니다.

활성화가 끝나면 설정 왼쪽 메뉴 아래쪽에 Git 또는 Obsidian Git 관련 항목이 새로 생깁니다. 이 항목이 보이면 첫 번째 관문은 통과입니다.

만약 설치 직후 오른쪽 아래에 오류가 뜨더라도 너무 놀라지 마세요. 아직 설정이 맞지 않거나, 플러그인이 볼트 안의 Git 저장소를 확인하는 중일 수 있습니다. 먼저 다음 단계에서 명령 팔레트에 명령이 보이는지 확인해 봅니다.

명령 팔레트에서 네 가지 명령 확인하기

옵시디언에서 Ctrl + P, macOS에서는 Cmd + P를 누르면 명령 팔레트가 열립니다. 명령 팔레트는 옵시디언 안의 기능 검색창입니다. 여기에 Git 또는 Obsidian Git을 입력해 보세요.

이번 장에서 반드시 확인할 명령은 다음 네 가지입니다.

• Obsidian Git: Open source control view

• Obsidian Git: Backup

• Obsidian Git: Commit-and-sync

• Obsidian Git: Pull

버전에 따라 앞부분이 Git:으로 보이거나, Backup 명령이 Commit-and-sync 중심으로 표시될 수 있습니다. 중요한 것은 소스 컨트롤 화면 열기, 백업, 커밋 후 동기화, 풀에 해당하는 명령이 보이는지입니다. 공식 플러그인 설명에서도 소스 컨트롤 화면을 열어 변경 파일을 관리할 수 있고, Commit-and-sync, Pull, Push 같은 명령을 사용할 수 있다고 안내합니다.⁴

먼저 Open source control view를 실행해 봅니다. 그러면 옵시디언 오른쪽 또는 왼쪽 패널에 Git 변경 사항을 볼 수 있는 화면이 열립니다. GitHub Desktop의 Changes 화면과 비슷한 역할입니다. 여기에는 새로 만든 파일, 수정된 파일, 삭제된 파일이 표시됩니다.

이 화면을 열었을 때 아무것도 없어도 괜찮습니다. 변경 사항이 없다는 뜻일 수 있습니다. 테스트를 위해 옵시디언에서 자동백업 테스트.md라는 노트를 만들고 한 줄을 적어 보세요. 잠시 후 소스 컨트롤 화면에 해당 파일이 나타나면 플러그인이 볼트의 변경 사항을 감지하고 있는 것입니다.

상태 표시줄을 보는 습관

Obsidian Git을 활성화하면 옵시디언 하단 상태 표시줄에 Git 관련 메시지가 나타날 수 있습니다. 예를 들어 마지막 백업 시각, 진행 중인 작업, 오류 메시지, 변경 파일 개수 등이 표시됩니다. 화면 구성이나 플러그인 버전에 따라 보이는 정보는 조금 다를 수 있지만, 하단 상태 표시줄은 자동 백업의 건강 상태를 확인하는 작은 계기판이라고 생각하면 됩니다.

초보자는 자동 백업을 켠 뒤 "설정했으니 됐겠지" 하고 바로 잊어버리기 쉽습니다. 하지만 처음 며칠은 상태 표시줄을 자주 보는 습관을 들이는 것이 좋습니다. 자동차를 처음 운전할 때 속도계와 연료계를 자주 보는 것과 같습니다. 어느 순간부터는 자연스럽게 눈에 들어옵니다.

상태 표시줄에서 특히 확인할 것은 마지막 작업이 성공했는지입니다. up to date, pushed, committed, backup done처럼 성공을 암시하는 메시지가 보이면 안심할 수 있습니다. 반대로 failed, error, conflict, authentication 같은 단어가 보이면 자동 백업이 멈췄을 수 있습니다. 이때는 무시하지 말고 소스 컨트롤 화면이나 플러그인 로그를 확인해야 합니다.

핵심 설정 한 번에 이해하기

이제 Obsidian Git 설정 화면으로 들어갑니다. 설정 이름은 버전에 따라 조금 다르게 보일 수 있습니다. 어떤 화면에서는 Auto commit-and-sync interval, 어떤 화면에서는 Vault backup interval처럼 보일 수 있습니다. 이름이 조금 달라도 의미를 기준으로 판단하면 됩니다.

처음 설정할 때 꼭 이해해야 할 값은 네 가지입니다.

자동 백업 간격은 너무 짧게 잡지 마세요. 1분은 매우 부지런해 보이지만 초보자에게는 오히려 산만할 수 있습니다. 노트를 수정하는 중간중간 커밋이 많이 생기고, 네트워크가 불안정한 환경에서는 실패 메시지가 자주 보일 수 있습니다. 처음에는 10분으로 시작하고, 자료 손실이 걱정되는 사람은 5분으로 줄이면 됩니다.

커밋 메시지 형식은 자동 백업 기록의 이름표입니다. vault backup: {{date}}처럼 설정하면 나중에 GitHub에서 이력을 볼 때 언제 자동 백업이 되었는지 알아보기 쉽습니다. 자동 백업의 커밋 메시지는 매번 창을 띄워 직접 입력하게 만들지 않는 편이 좋습니다. 자동화의 목적은 흐름을 끊지 않는 것이기 때문입니다.

Push on backup은 백업할 때 GitHub 원격 저장소까지 올릴지 정하는 옵션입니다. 이 옵션을 끄면 내 컴퓨터 안에는 커밋이 남지만 GitHub 서버에는 올라가지 않을 수 있습니다. 혼자 쓰는 임시 실험 볼트라면 로컬 커밋만으로도 의미가 있지만, 커뮤니티 자료를 안전하게 보관하려면 GitHub까지 올라가야 합니다. 따라서 우리 온보딩 기본값은 켜기입니다.

Pull updates on startup은 옵시디언을 켤 때 GitHub에 올라와 있는 최신 내용을 먼저 받아오는 옵션입니다. 여러 기기를 쓰거나 여러 강사가 같은 저장소를 공유한다면 매우 중요합니다. 어제 집 컴퓨터에서 수정해 푸시한 내용을 오늘 강의장 노트북에서 먼저 받아와야 이어서 작업할 수 있기 때문입니다.

로컬에만 기록할지, GitHub까지 올릴지 판단하기

자동 백업을 설정할 때 많은 사람이 "그냥 다 켜면 되는 것 아닌가요?"라고 묻습니다. 초보 단계에서는 대부분 켜는 것이 편하지만, 원리를 알고 판단하는 편이 안전합니다.

로컬에만 기록한다는 것은 내 컴퓨터 안에 커밋만 쌓는다는 뜻입니다. 인터넷이 불안정하거나, 아직 올리면 안 되는 자료를 정리 중이거나, GitHub 인증 문제가 있을 때 임시로 사용할 수 있습니다. 이 경우 컴퓨터가 고장 나면 GitHub에는 최신 내용이 없을 수 있습니다.

GitHub까지 올린다는 것은 커밋을 만든 뒤 원격 저장소로 푸시한다는 뜻입니다. 이것이 우리가 원하는 기본 백업입니다. 노트북을 잃어버려도 GitHub에 접속하면 최근 커밋까지 복구할 수 있습니다. 커뮤니티 내부 공유도 이 방식이 되어야 가능합니다.

옵시디언 시작 시 최신 내용을 받는다는 것은 Pull을 먼저 한다는 뜻입니다. 여러 사람이 함께 쓰거나, 집 컴퓨터와 강의장 노트북을 번갈아 쓰는 사람에게는 거의 필수입니다. 다만 Pull은 원격 저장소와 내 로컬 저장소의 내용을 합치는 작업이므로, 같은 파일을 서로 다르게 고친 경우 충돌이 생길 수 있습니다. 충돌은 나쁜 일이 아니라 "둘 다 바뀌었으니 확인해 주세요"라는 신호입니다. 자세한 복구는 뒤 장에서 다루겠습니다.

추천 설정값으로 시작하기

우리 커뮤니티의 초보자용 기본 설정은 다음과 같습니다.

자동 백업 간격: 10분
자동 커밋 메시지: vault backup: {{date}}
수동 커밋 메시지: vault backup: {{date}}
Push on backup: 켜기
Pull updates on startup: 켜기
자동 백업 중 메시지 직접 입력: 끄기
자동 백업 대상을 staged files only로 제한: 끄기

여기서 staged files only는 Git을 더 세밀하게 다루는 사람에게 필요한 옵션입니다. 초보자는 이 옵션을 켜지 않는 편이 좋습니다. 켜 두면 "왜 자동 백업이 안 되죠?"라는 문제가 생길 수 있습니다. 변경 파일을 먼저 별도로 선택해야 하기 때문입니다. 우리 목적은 강의 노트와 프롬프트를 빠짐없이 기록하는 것이므로, 처음에는 변경된 모든 파일을 자동 백업 대상으로 두는 편이 이해하기 쉽습니다.

자동 Pull 간격을 별도로 설정할 수 있는 화면이라면 10분 정도로 시작합니다. 다만 여러 사람이 동시에 같은 저장소를 자주 편집하는 구조라면 자동 Pull만 믿지 말고 작업 시작 전 수동 Pull을 습관화해야 합니다. 자동 Pull은 안전벨트이고, 작업 전 Pull은 출발 전 좌우 확인입니다.

첫 수동 실행으로 정상 작동 확인하기

자동 백업을 켰다고 바로 끝내지 말고, 먼저 수동으로 한 번 실행해 봅니다. 자동화는 첫 실행을 눈으로 확인해야 안심할 수 있습니다.

옵시디언에서 테스트 노트를 하나 수정합니다. 예를 들어 자동백업 테스트.md에 다음 문장을 적습니다.

Obsidian Git 자동 백업 테스트입니다.

이제 명령 팔레트를 열고 Obsidian Git: Commit-and-sync를 실행합니다. 버전에 따라 Backup 명령을 실행해도 됩니다. 이 명령은 현재 변경 사항을 커밋하고, 설정에 따라 Pull과 Push까지 함께 처리합니다. 공식 설명에서도 기본 설정의 Commit-and-sync는 모든 변경 사항을 커밋한 뒤 pull과 push를 수행하는 흐름으로 소개됩니다.⁵

실행 후 하단 상태 표시줄을 봅니다. 작업이 진행 중이면 잠시 기다립니다. 완료 메시지가 보이면 GitHub 웹사이트로 이동해 저장소를 새로고침합니다. 방금 수정한 테스트 노트가 반영되어 있으면 성공입니다.

이 확인은 꼭 해야 합니다. 옵시디언 안에서는 성공처럼 보였지만 인증 문제로 GitHub까지는 올라가지 않았을 수 있습니다. 자동 백업의 최종 확인 지점은 GitHub 웹사이트입니다.

작업 시작 루틴: 먼저 Pull

자동 백업을 사용하기 시작하면 하루의 시작 루틴이 바뀝니다. 예전에는 옵시디언을 열고 바로 쓰기 시작했다면, 이제는 먼저 GitHub의 최신 내용을 받아와야 합니다.

강의장에 도착해 노트북을 열었다고 상상해 봅시다. 어젯밤 집 컴퓨터에서 커뮤니티 프롬프트 모음을 수정해 GitHub에 올렸습니다. 오늘 강의장 노트북은 아직 그 내용을 모릅니다. 이 상태에서 바로 같은 파일을 수정하면 나중에 충돌이 생길 수 있습니다.

그래서 작업 시작 전에는 명령 팔레트에서 Obsidian Git: Pull을 한 번 실행합니다. Pull updates on startup을 켜 두었다면 옵시디언을 켤 때 자동으로 Pull이 실행될 수 있지만, 초보 단계에서는 수동 Pull을 한 번 더 확인하는 습관이 안전합니다.

우리 커뮤니티의 구호는 간단합니다.

쓰기 전 Pull, 끝나기 전 Sync

쓰기 전 Pull은 GitHub 금고에서 최신 자료를 꺼내오는 일입니다. 끝나기 전 Sync는 내가 오늘 쓴 내용을 GitHub 금고에 다시 넣는 일입니다. 이 문장 하나만 기억해도 충돌의 상당 부분을 줄일 수 있습니다.

작업 중 루틴: 자동 백업에 맡기되 상태 보기

작업 중에는 매번 커밋을 누르지 않아도 됩니다. 자동 백업 간격을 10분으로 설정했다면, 플러그인이 주기적으로 변경 사항을 확인합니다. 우리는 강의 준비에 집중하면 됩니다.

하지만 처음 며칠은 하단 상태 표시줄을 확인하세요. 특히 긴 강의안을 작성하거나, 프롬프트 라이브러리를 대량으로 수정하거나, PDF와 이미지를 많이 첨부한 날에는 상태 메시지를 보는 습관이 필요합니다.

자동 백업은 옵시디언이 열려 있고, 컴퓨터가 깨어 있으며, 네트워크와 인증이 정상일 때 가장 잘 작동합니다. 옵시디언을 저장 직후 바로 종료하거나, 노트북을 덮어 절전 모드로 들어가거나, 와이파이가 끊기면 마지막 커밋 또는 푸시가 실패할 수 있습니다. 자동 백업은 든든한 비서지만, 전원이 꺼진 사무실에서는 일할 수 없습니다.

작업 종료 루틴: 마지막은 수동으로 한 번 더

자동 백업을 켰더라도 작업을 마치기 전에는 Commit-and-sync 또는 Backup을 한 번 수동 실행하는 것을 권합니다. 이 마지막 수동 실행은 문을 잠그기 전 확인하는 행동과 같습니다.

강의를 마치고 노트북을 닫기 직전, 또는 집으로 이동하기 전에는 다음 순서로 마무리합니다.

1. 명령 팔레트에서 Obsidian Git: Commit-and-sync 또는 Backup 실행

2. 하단 상태 표시줄에서 성공 메시지 확인

3. GitHub 웹사이트에서 최근 커밋 시각 또는 수정 파일 확인

특히 여러 기기를 오가는 강사라면 이 루틴이 매우 중요합니다. 집 컴퓨터에서 작업한 뒤 마지막 푸시가 실패했는데, 강의장 노트북에서 옛날 파일을 수정하면 충돌이 생깁니다. 자동 백업을 믿되, 이동 전 마지막 동기화는 직접 확인하세요.

GitHub에서 실제 반영 여부 확인하기

자동 백업이 제대로 되었는지 확인하는 가장 확실한 방법은 GitHub 웹사이트에서 저장소를 보는 것입니다. 저장소 페이지를 열면 파일 목록 위나 옆에 최근 커밋 메시지와 시간이 보입니다. vault backup: 2026-05-06 ... 같은 메시지가 보이면 자동 커밋이 올라간 것입니다.

테스트 노트를 클릭해 실제 문장이 반영되었는지도 확인하세요. 처음 설정한 날에는 적어도 한 번은 이 확인을 해야 합니다. 자동 백업의 성공 기준은 "옵시디언에서 오류가 안 보인다"가 아니라 "GitHub에 최신 내용이 올라와 있다"입니다.

커뮤니티 운영자는 온보딩 첫날 구성원들에게 같은 테스트를 시키는 것이 좋습니다. 각자 내이름_백업테스트.md 파일을 만들고, 자동 또는 수동 Commit-and-sync 후 GitHub에서 보이는지 확인합니다. 이 짧은 연습이 나중에 자료 유실과 혼란을 크게 줄여 줍니다.

자주 만나는 오류와 대처법

Obsidian Git을 쓰다 보면 몇 가지 흔한 상황을 만납니다. 오류가 보인다고 해서 바로 망한 것은 아닙니다. 대부분은 원인을 좁혀 가면 해결됩니다.

여기서 가장 안전한 태도는 "오류가 나면 계속 버튼을 누르지 않는다"입니다. 같은 오류 상태에서 Pull, Push, Commit을 반복하면 상황이 더 헷갈릴 수 있습니다. 먼저 상태 메시지를 읽고, 어떤 파일이 문제인지 확인하고, 필요하면 GitHub Desktop으로 돌아가 눈에 보이는 화면에서 처리합니다.

로그를 확인하는 법

플러그인 설정이나 소스 컨트롤 화면에는 로그를 여는 기능이 있을 수 있습니다. 로그는 플러그인이 방금 어떤 Git 작업을 실행했고, 어디에서 실패했는지 보여주는 기록입니다. 영어가 많아 처음에는 겁이 날 수 있지만, 모든 문장을 해석할 필요는 없습니다.

초보자는 로그에서 다음 단어만 찾아도 충분합니다.

• authentication, permission: 로그인 또는 권한 문제

• conflict, merge: 서로 다른 변경이 부딪힌 문제

• remote, origin: GitHub 원격 저장소와의 연결 문제

• nothing to commit, up to date: 변경 사항이 없거나 최신 상태라는 의미

오류를 커뮤니티 운영자나 IT에 익숙한 동료에게 물어볼 때는 화면 전체를 설명하려 하지 말고, 로그의 마지막 5줄 정도를 복사해 공유하면 됩니다. "안 돼요"보다 "Push failed와 authentication이 보입니다"가 훨씬 빠른 해결을 부릅니다.

자동 백업이 실패하는 대표 상황

자동 백업은 편리하지만 모든 상황을 이기지는 못합니다. 특히 다음 상황에서는 실패할 수 있습니다.

첫째, 저장 직후 바로 옵시디언을 종료하는 경우입니다. 자동 백업 간격이 10분인데 마지막 수정 후 30초 만에 앱을 닫으면, 그 수정은 아직 커밋되지 않았을 수 있습니다. 그래서 종료 전 수동 Commit-and-sync가 필요합니다.

둘째, 네트워크가 끊긴 경우입니다. 인터넷이 없어도 로컬 커밋은 가능할 수 있지만 GitHub로 푸시하는 것은 실패합니다. 이때는 나중에 인터넷이 연결된 뒤 다시 Commit-and-sync 또는 Push를 실행해야 합니다.

셋째, 인증이 풀린 경우입니다. GitHub 비밀번호를 바꾸었거나, 토큰이 만료되었거나, 새 컴퓨터에서 권한 설정이 안 되어 있으면 푸시가 실패합니다. 이때는 Obsidian Git만 붙잡고 있기보다 GitHub Desktop에서 먼저 Pull과 Push가 되는지 확인하는 것이 빠릅니다.

넷째, Git 설정이 꼬인 경우입니다. 컴퓨터를 포맷했거나, Git을 재설치했거나, 저장소 폴더를 복사해 옮긴 뒤에는 플러그인이 예전처럼 작동하지 않을 수 있습니다. 이럴 때는 자동화를 고집하지 말고 수동 경로로 돌아가야 합니다.

어려울 때는 GitHub Desktop으로 돌아간다

이 장에서 가장 중요한 안전장치는 이것입니다. Obsidian Git이 어렵게 느껴지면 GitHub Desktop으로 돌아가도 됩니다. 자동 백업을 설정했다고 해서 GitHub Desktop을 지워야 하는 것이 아닙니다. 오히려 초보자에게 GitHub Desktop은 비상구입니다.

문제가 생겼을 때는 다음 순서로 수동 백업 경로를 사용합니다.

1. GitHub Desktop을 연다.

2. Fetch origin 또는 Pull origin으로 최신 내용을 받는다.

3. Changes에서 어떤 파일이 바뀌었는지 확인한다.

4. 커밋 메시지를 쓰고 Commit to main을 누른다.

5. Push origin으로 GitHub에 올린다.

이 흐름은 지난 장에서 배운 내용입니다. 자동화가 잠시 멈춰도 수동 경로가 있으면 자료를 잃지 않습니다. 커뮤니티 전체 운영에서도 마찬가지입니다. 모든 구성원이 Obsidian Git을 완벽히 이해할 필요는 없습니다. 다만 자동 백업이 실패했을 때 GitHub Desktop으로 Pull, Commit, Push를 할 수 있으면 충분히 안전합니다.

커뮤니티용 권장 루틴

이제 우리 커뮤니티의 기본 루틴을 정리해 봅시다. 이 루틴은 초보자도 따라 할 수 있어야 하며, IT 지식이 많은 사람에게만 의존하지 않아야 합니다.

작업 시작 전: Pull
작업 중: 자동 백업에 맡기기
작업 종료 전: Commit-and-sync 또는 Backup 수동 실행
종료 후: GitHub에서 최근 반영 여부 확인
문제 발생 시: GitHub Desktop으로 수동 백업

이 루틴은 단순하지만 강력합니다. 특히 쓰기 전 Pull, 끝나기 전 Sync만 기억해도 협업 안정성이 크게 올라갑니다. 여러 강사가 같은 자료를 다루는 커뮤니티에서는 기술보다 습관이 더 중요합니다.

운영자는 처음 한 달 동안 구성원들에게 매주 한 번씩 최근 커밋이 GitHub에 올라갔는지 확인하게 해도 좋습니다. 자동화는 보이지 않기 때문에, 초반에는 눈으로 확인하는 의식이 필요합니다. 확인이 반복되면 신뢰가 생기고, 신뢰가 생기면 기록에 더 집중할 수 있습니다.

오늘의 실습 체크리스트

이번 장을 마치기 전에 아래 항목을 차례대로 확인해 보세요.

• 커뮤니티 플러그인에서 Obsidian Git을 설치하고 활성화했다.

• 명령 팔레트에서 Open source control view, Backup, Commit-and-sync, Pull 명령을 확인했다.

• 소스 컨트롤 화면에서 변경된 노트가 보이는지 테스트했다.

• 자동 백업 간격을 5분 또는 10분으로 설정했다.

• 커밋 메시지 형식을 vault backup: {{date}}처럼 알아보기 쉽게 정했다.

• Push on backup을 켜 GitHub까지 올라가게 했다.

• Pull updates on startup을 켜 시작 시 최신 내용을 받게 했다.

• 수동 Commit-and-sync를 한 번 실행하고 GitHub 웹사이트에서 반영 여부를 확인했다.

• 작업 시작 전 Pull, 작업 종료 전 Sync 루틴을 정했다.

• 문제가 생기면 GitHub Desktop으로 돌아가는 안전 경로를 기억했다.

여기까지 왔다면 이제 옵시디언은 단순한 메모장이 아닙니다. 강의 준비 중 떠오른 아이디어, 커뮤니티에서 나온 인사이트, 반복해서 쓰는 프롬프트와 사례 자료가 일정 간격으로 기록되는 지식 창고가 되었습니다.

자동 백업은 우리를 게으르게 만들기 위한 기능이 아닙니다. 더 중요한 일에 집중하게 해 주는 장치입니다. 강사는 백업 버튼을 기억하느라 에너지를 쓰기보다, 더 좋은 질문을 만들고, 더 선명한 사례를 정리하고, 더 깊은 통찰을 남기는 데 집중해야 합니다. Obsidian Git은 그 뒤에서 조용히 우리의 기록을 지켜 주는 비서가 되어 줄 것입니다.

다음 장에서는 한 걸음 더 나아갑니다. 이제 자료가 안전하게 백업되기 시작했으니, 어떤 자료를 Public으로 공개하고 어떤 자료를 Private으로 보호할지 저장소 전략을 세워 보겠습니다. 자동 백업이 기록의 안전을 만든다면, 공개·비공개 분리는 커뮤니티의 신뢰를 지키는 울타리가 됩니다.

참고

¹Obsidian Git 플러그인 공식 저장소

²Obsidian Git 문서 시작하기

³Obsidian Git 모바일 안내

⁴Obsidian Git 명령 안내

⁵Obsidian Git Commit and sync 설명