충돌과 실수를 두려워하지 않는 복구 입문

실수하지 않는 팀보다, 돌아올 줄 아는 팀이 강하다

옵시디언과 깃허브를 함께 쓰기 시작하면 처음에는 이런 생각이 듭니다.

"이제 모든 자료가 안전하겠지?"

맞습니다. 훨씬 안전해집니다. 하지만 여기서 중요한 단어는 "완벽"이 아니라 "훨씬"입니다. 사람이 쓰는 도구에는 늘 실수가 끼어듭니다. 누군가는 Pull을 깜빡하고 문서를 수정합니다. 누군가는 같은 회의록의 같은 문장을 동시에 고칩니다. 또 누군가는 폴더를 정리하다가 중요한 강의안을 삭제합니다.

그런데 깃허브의 진짜 장점은 실수를 없애는 데 있지 않습니다.

깃허브의 진짜 장점은 실수해도 돌아갈 수 있다는 데 있습니다.

이 장에서는 겁나는 단어들을 아주 천천히 다룹니다. 충돌, 삭제, 잘못된 수정, 이전 버전 복구. 이름은 무섭지만 원리는 단순합니다. 깃허브는 우리가 남긴 변화의 발자국을 기억합니다. 옵시디언은 우리가 쓴 마크다운 파일을 로컬에 보관합니다. 이 둘을 잘 다루면 "망했다"는 순간에도 "잠깐, 기록을 보자"라고 말할 수 있습니다.

복구의 첫 번째 기술은 버튼을 잘 누르는 것이 아닙니다. 멈추는 것입니다. 문제가 생겼을 때 바로 덮어쓰거나 삭제하거나 다시 Push하지 않는 것, 그것이 복구의 절반입니다.

충돌은 고장이 아니라 질문이다

Git에서 말하는 충돌, 정확히는 병합 충돌입니다. 영어로는 merge conflict라고 합니다. 병합은 서로 다른 변경 내용을 하나로 합치는 일입니다. 충돌은 Git이 자동으로 합치기 어려운 변경을 만났을 때 생깁니다.

Git은 보통 꽤 똑똑합니다. 김강사님이 A 파일을 고치고, 이강사님이 B 파일을 고쳤다면 대부분 자동으로 합칩니다. 같은 파일이라도 서로 다른 줄을 고쳤다면 자동으로 합쳐지는 경우가 많습니다. 문제는 같은 파일의 같은 부분을 서로 다르게 고쳤을 때입니다. GitHub 공식 문서에서도 병합 충돌은 주로 같은 파일의 같은 줄을 다르게 수정했거나, 한 사람은 파일을 수정하고 다른 사람은 같은 파일을 삭제했을 때 생긴다고 설명합니다.¹

그러니 충돌 메시지를 보면 이렇게 이해하면 됩니다.

Git: 두 버전이 서로 다릅니다. 제가 마음대로 고르면 위험합니다.
     어떤 내용을 살릴지 사람이 확인해 주세요.

즉 충돌은 고장이 아닙니다. Git이 우리에게 던지는 질문입니다.

"어느 쪽을 남길까요?"

이 질문에 차분히 답하면 됩니다.

우리 커뮤니티에서 충돌이 자주 생기는 세 가지 순간

AI 활용 강사 커뮤니티가 옵시디언과 깃허브를 free tier로 운영할 때, 충돌은 대체로 비슷한 장면에서 생깁니다. 원인을 알면 절반은 이미 해결한 것입니다.

첫 번째는 한 기기에서 최신 변경을 가져오지 않은 채 수정하는 경우입니다. 예를 들어 집 데스크톱에서 어젯밤에 강의안을 고치고 Push했습니다. 그런데 다음 날 노트북에서 Pull을 하지 않고 예전 파일을 열어 또 수정했습니다. 이제 노트북은 "내가 맞다"고 말하고, 깃허브에는 "어젯밤 버전이 맞다"고 남아 있습니다. 이 상태에서 Push하려고 하면 Git은 당황합니다.

두 번째는 여러 사람이 같은 Markdown 파일의 같은 부분을 고치는 경우입니다. 20_프롬프트/강의안초안생성.md 파일의 첫 문단을 김강사님은 "초보자용"으로 바꾸고, 이강사님은 "기업 교육용"으로 바꿨다고 해봅시다. 둘 다 의미 있는 수정입니다. Git은 어느 표현이 더 좋은지 판단하지 못합니다. 그래서 사람에게 물어봅니다.

세 번째는 플러그인이 자동으로 만든 설정 파일이 여러 기기에서 동시에 바뀌는 경우입니다. 옵시디언의 일부 플러그인은 .obsidian 폴더 안에 JSON 파일을 저장합니다. JSON은 설정값을 담는 형식입니다. 사람이 읽는 글이라기보다 프로그램이 읽기 쉬운 메모장이라고 생각하면 됩니다. 여러 기기에서 이 파일이 동시에 바뀌면 사람이 직접 고치기 까다로운 충돌이 생길 수 있습니다.²

초보자에게 특히 어려운 것은 세 번째입니다. 마크다운 본문은 읽어보고 합치면 되지만, JSON 파일은 쉼표 하나만 잘못 지워도 플러그인이 오작동할 수 있습니다. 그래서 우리는 본문 노트와 설정 파일을 다르게 다룰 것입니다.

문제가 생겼을 때의 3단계: 멈추기, 보기, 복사하기

충돌이나 삭제 실수를 만났을 때 가장 위험한 행동은 "빨리 없애버리기"입니다. 눈앞의 빨간 표시, conflict 파일, 알 수 없는 오류 메시지가 보기 싫어서 아무 파일이나 삭제하면 복구가 더 어려워질 수 있습니다.

문제가 생기면 이 세 단계를 기억하세요.

1. 멈추기

2. 보기

3. 복사하기

먼저 멈춥니다. 옵시디언에서 계속 문서를 수정하지 않습니다. GitHub Desktop이나 Obsidian Git에서 무작정 Push, Pull, Discard, Delete를 누르지 않습니다. 특히 Discard changes, Reset, Delete, Overwrite처럼 되돌리거나 지우는 느낌의 버튼은 초보 단계에서 조심해야 합니다.

다음으로 봅니다. GitHub Desktop의 Changes 화면을 열어 어떤 파일이 바뀌었는지 확인합니다. 파일명을 클릭하면 오른쪽에 Diff가 보입니다. Diff는 변경 비교 화면입니다. 보통 추가된 줄은 초록색, 삭제된 줄은 빨간색으로 표시됩니다. 이 화면은 "문제의 현장 사진"입니다. 수습하기 전에 현장을 보는 것입니다.

마지막으로 복사합니다. 중요한 자료이거나 상황이 복잡하다면 현재 vault 폴더를 통째로 ZIP으로 압축해 둡니다. 이 ZIP은 "응급 안전망"입니다. 복구 작업 중에 더 꼬이더라도 최소한 지금 상태로 돌아갈 수 있습니다.

Windows에서는 vault 폴더를 오른쪽 클릭한 뒤 보내기 > 압축(zip) 폴더를 선택하면 됩니다. macOS에서는 vault 폴더를 오른쪽 클릭하고 압축을 선택하면 됩니다. 파일명은 날짜와 상황이 보이게 적습니다.

2026-05-06_vault_backup_before_conflict_fix.zip
2026-05-06_vault_backup_before_folder_restructure.zip
2026-05-06_vault_backup_after_delete_mistake.zip

ZIP 백업은 멋진 기술이 아닙니다. 하지만 초보 팀에게는 가장 든든한 보험입니다.

GitHub Desktop에서 먼저 확인할 것

충돌이 나기 전에도 GitHub Desktop의 Changes 화면을 보는 습관을 들이면 실수가 줄어듭니다. 이 화면에는 아직 커밋하지 않은 변경 파일이 나타납니다.

예를 들어 강의안초안생성.md를 고쳤다면 왼쪽 목록에 파일명이 보입니다. 파일을 클릭하면 오른쪽에 변경 내용이 줄 단위로 표시됩니다. 여기서 우리가 확인할 것은 세 가지입니다.

• 내가 의도한 파일만 바뀌었는가?

• 삭제된 문단이 정말 삭제해도 되는 내용인가?

• .obsidian 안의 낯선 설정 파일이 함께 바뀌지는 않았는가?

만약 강의 노트 한 줄만 고쳤는데 .obsidian/workspace.json, .obsidian/plugins/.../data.json 같은 파일이 잔뜩 보인다면 잠깐 멈추세요. 이 파일들은 옵시디언의 화면 배치나 플러그인 상태 때문에 자동으로 바뀐 것일 수 있습니다. 팀에서 설정 파일까지 공유하기로 했다면 커밋할 수 있지만, 잘 모르면 저장소 관리자에게 확인하는 편이 안전합니다.

Obsidian Git 플러그인을 쓰는 경우에도 비슷한 확인이 가능합니다. Obsidian Git은 옵시디언 안에서 변경 파일을 보고, 커밋하고, Pull·Push하며, History View와 Diff View로 변경 내역을 확인하는 기능을 제공합니다.³ 다만 초보 단계에서는 복잡한 충돌을 만났을 때 옵시디언 안에서만 해결하려고 하기보다 GitHub Desktop의 화면과 ZIP 백업을 함께 사용하는 편이 마음이 편합니다.

Pull 중 충돌이 났을 때 기본 복구 절차

이제 가장 흔한 장면을 다뤄보겠습니다. GitHub Desktop에서 Pull origin을 눌렀는데 충돌이 났습니다. 화면에는 대략 이런 의미의 메시지가 나타납니다.

Some files have conflicts.
Resolve the conflicts before continuing.

우리말로 하면 이렇습니다.

몇몇 파일에 충돌이 있습니다.
계속하려면 충돌을 먼저 해결하세요.

이때 순서는 다음과 같습니다.

충돌 파일 확인 → 파일 열기 → 충돌 표시 찾기 → 살릴 내용 결정 → 표시 삭제 → 저장 → 커밋 → Push

Git은 충돌이 난 파일 안에 특별한 표시를 넣습니다. 바로 아래 세 가지입니다.

<<<<<<<
=======
>>>>>>>

실제 파일에서는 이런 식으로 보일 수 있습니다.

## 강의 도입 멘트

<<<<<<< HEAD
오늘은 AI를 처음 만나는 분들도 바로 따라 할 수 있도록, 프롬프트 작성의 기본 구조부터 살펴보겠습니다.
=======
오늘은 기업 교육 현장에서 바로 쓸 수 있는 프롬프트 설계법을 실습 중심으로 다루겠습니다.
>>>>>>> origin/main

겁먹지 마세요. 이것은 파일이 깨진 것이 아닙니다. Git이 두 버전을 한 파일 안에 나란히 보여주는 것입니다.

일반적으로 <<<<<<< HEAD 아래에는 내 컴퓨터 쪽 변경이 표시됩니다. ======= 아래부터 >>>>>>> origin/main 위까지는 상대방 또는 원격 저장소 쪽 변경이 표시됩니다. 다만 상황에 따라 표시 이름은 조금 다를 수 있으니, 핵심은 위아래 두 구간을 비교하는 것입니다. GitHub 공식 문서에서도 충돌을 해결할 때는 유지할 변경을 결정한 뒤 <<<<<<<, =======, >>>>>>> 같은 충돌 표시를 삭제하고 최종 문장만 남겨야 한다고 안내합니다.⁴

위 예시에서는 두 문장이 모두 쓸 만합니다. 그러면 둘 중 하나만 고를 필요가 없습니다. 새 문장으로 합치면 됩니다.

## 강의 도입 멘트

오늘은 AI를 처음 만나는 분들도 바로 따라 할 수 있도록 프롬프트 작성의 기본 구조를 살펴보고, 기업 교육 현장에서 바로 쓸 수 있는 실습 예제로 연결해 보겠습니다.

중요한 것은 충돌 표시를 반드시 지우는 것입니다. 최종 파일에는 <<<<<<<, =======, >>>>>>>가 남아 있으면 안 됩니다. 이 표시는 독자에게 보여줄 내용이 아니라 Git이 임시로 붙인 비교 표시입니다.

저장한 뒤 GitHub Desktop으로 돌아갑니다. 변경 화면에서 충돌 표시가 사라졌는지, 최종 문장이 의도대로 남았는지 확인합니다. 그다음 커밋 메시지를 씁니다.

Resolve conflict in lecture intro note

한글로 써도 괜찮습니다.

[충돌해결] 강의 도입 멘트 병합

커밋한 뒤 Push origin을 눌러 깃허브에 올립니다. 여기까지 하면 충돌 해결이 끝납니다.

충돌 해결 예제: 두 강사의 프롬프트를 모두 살리기

조금 더 실제 상황에 가까운 예제를 보겠습니다. 20_프롬프트/강의안작성.md 파일에서 두 강사가 같은 부분을 고쳤습니다.

충돌 파일은 이렇게 보입니다.

## 기본 프롬프트

<<<<<<< HEAD
당신은 초보 강사를 돕는 교육 설계 전문가입니다. 아래 주제에 대해 60분 강의안을 만들어 주세요.
=======
당신은 AI 활용 교육 전문 강사입니다. 아래 주제와 대상자를 바탕으로 실습 중심의 90분 강의안을 만들어 주세요.
>>>>>>> origin/main

주제:
대상자:
강의 목표:

여기서 선택지는 세 가지입니다. 첫째, 내 문장만 남깁니다. 둘째, 원격 저장소의 문장만 남깁니다. 셋째, 둘을 합쳐 더 좋은 문장으로 만듭니다.

우리 커뮤니티에서는 가능하면 세 번째를 먼저 생각합니다. 두 사람이 고친 이유가 있을 가능성이 높기 때문입니다.

최종 문장은 이렇게 정리할 수 있습니다.

## 기본 프롬프트

당신은 초보 강사를 돕는 AI 활용 교육 설계 전문가입니다. 아래 주제와 대상자를 바탕으로 실습 중심의 강의안을 만들어 주세요.

강의 시간:
주제:
대상자:
강의 목표:

이렇게 하면 초보 강사, AI 활용 교육, 실습 중심, 강의 시간이라는 장점이 모두 살아납니다. 충돌 해결은 싸움에서 이기는 일이 아닙니다. 두 변경 중에서 최종 문서에 가장 도움이 되는 형태를 만드는 일입니다.

옵시디언에서 보이는 중복 파일과 conflict 파일 다루기

가끔 Git의 충돌 표시가 파일 안에 들어가는 대신, 옵시디언이나 동기화 도구가 중복 파일을 만들어 놓는 경우가 있습니다. 파일명에 conflict, conflicted copy, 충돌, 기기 이름, 날짜 같은 단어가 붙어 있을 수 있습니다.

예를 들면 이런 식입니다.

강의안작성.md
강의안작성 conflicted copy.md
강의안작성_김강사노트북_충돌.md

이때도 원칙은 같습니다. 바로 삭제하지 않습니다. 먼저 두 파일을 열어 내용을 비교합니다. 본문 노트라면 사람이 읽을 수 있으므로 천천히 합치면 됩니다.

가장 안전한 방법은 원본 파일을 기준으로 삼고, 충돌 파일에서 필요한 문단만 복사해 오는 것입니다. 예를 들어 강의안작성.md가 현재 공식 파일이라면, 강의안작성 conflicted copy.md를 열어 새로 추가된 예시나 문장을 확인합니다. 필요한 내용만 공식 파일에 붙여 넣습니다. 합친 뒤에는 GitHub Desktop의 Changes 화면에서 변경 내용을 확인하고 커밋합니다.

충돌 파일을 바로 지우고 싶어도 하루 정도는 보관하는 편이 좋습니다. 커밋 메시지에 이렇게 남길 수 있습니다.

[충돌정리] 강의안작성 중복 파일 내용 병합

병합이 끝나고 팀원이 확인했다면 그때 중복 파일을 삭제하고 다시 커밋합니다.

[정리] 병합 완료된 충돌 파일 삭제

이렇게 두 번에 나누면 기록이 깔끔합니다. "내용을 합친 커밋"과 "찌꺼기 파일을 정리한 커밋"이 분리되기 때문입니다.

본문 노트와 설정 파일은 다르게 다룬다

옵시디언 vault에는 크게 두 종류의 파일이 섞여 있습니다. 하나는 우리가 직접 쓰는 본문 노트입니다. 보통 .md로 끝납니다. 다른 하나는 옵시디언이나 플러그인이 쓰는 설정 파일입니다. 보통 .json, .css, 플러그인 폴더 안의 파일 등입니다.

본문 노트는 비교하고 합치면 됩니다. 회의록, 프롬프트, 강의안, 도구 리뷰는 사람이 읽고 판단할 수 있습니다.

하지만 설정 파일은 조심해야 합니다. 특히 .obsidian/plugins/플러그인이름/data.json 같은 파일은 플러그인의 내부 상태를 담고 있을 수 있습니다. 이 파일을 잘못 고치면 플러그인 설정이 초기화되거나, 동기화 상태가 꼬이거나, 옵시디언에서 오류가 날 수 있습니다.

초보 팀의 기본 원칙은 다음과 같습니다.

.md 파일 충돌 = 내용을 읽고 병합한다.
JSON 설정 파일 충돌 = 임의 수정 전에 ZIP 백업하고 숙련자에게 확인한다.
화면 배치 파일 충돌 = 팀에서 공유할 파일인지 먼저 판단한다.

예를 들어 .obsidian/workspace.json은 화면 배치와 관련된 파일일 수 있습니다. 사람마다 화면 배치가 다르다면 굳이 함께 공유할 필요가 없을 수 있습니다. 이런 파일은 .gitignore에 넣어 충돌을 줄이는 전략도 가능합니다. 다만 이미 팀 규칙이 있다면 혼자 바꾸지 말고 저장소 관리자와 상의하세요.

플러그인 설정 파일 충돌을 만났을 때는 이렇게 말하면 됩니다.

[도움 요청]
.obsidian/plugins/플러그인이름/data.json 파일에 충돌이 생겼습니다.
현재 vault ZIP 백업은 만들어 두었습니다.
임의로 수정하지 않고 대기하겠습니다.
확인 가능하신 분 계실까요?

이 문장 하나가 많은 사고를 막아줍니다.

잘못 삭제한 문서 되살리기: GitHub 웹사이트에서 찾기

이번에는 충돌이 아니라 삭제 실수입니다. 예를 들어 누군가 10_강의자료/2026-05-06_챗GPT입문.md 파일을 실수로 지웠습니다. 로컬에서도 사라졌고, 이미 커밋과 Push까지 했습니다.

이때도 끝난 것이 아닙니다. GitHub에는 이전 커밋 기록이 남아 있습니다. 커밋은 그 시점의 스냅샷입니다. 사진첩처럼 "그때 파일이 어떤 모습이었는지" 볼 수 있습니다.

가장 쉬운 복구 방식은 파일 전체를 되돌리는 것보다, 필요한 내용을 이전 버전에서 복사해 현재 문서에 붙여 넣는 것입니다. 초보자에게는 이 방식이 안전합니다. 저장소 전체를 과거로 되돌리는 작업은 다른 사람의 최신 작업까지 영향을 줄 수 있기 때문입니다.

절차는 다음과 같습니다.

GitHub 저장소 열기 → Commits 또는 파일 History 열기 → 삭제 전 커밋 찾기 → 이전 파일 내용 확인 → 필요한 내용 복사 → 현재 vault에 새 파일로 붙여넣기 → 커밋·Push

파일이 아직 GitHub에서 보인다면 해당 파일을 열고 History를 누르면 됩니다. 이전 버전 목록에서 원하는 시점을 엽니다. 내용을 확인한 뒤 필요한 문단을 복사합니다.

파일이 삭제되어 현재 목록에서 보이지 않는다면 저장소의 Commits 목록으로 갑니다. 삭제가 일어나기 전 날짜의 커밋을 찾습니다. 그 커밋에서 파일을 열어 내용을 확인합니다. 그리고 현재 옵시디언에 같은 이름으로 새 파일을 만들고 내용을 붙여 넣습니다.

커밋 메시지는 이렇게 남깁니다.

[복구] 실수로 삭제된 챗GPT 입문 강의노트 복원

복구할 때 중요한 것은 "조용히 되살리기"가 아니라 "왜 되살렸는지 기록하기"입니다. 나중에 같은 일이 반복될 때 원인을 찾을 수 있습니다.

잘못 수정한 문서 되돌리기: 전체 되돌리기보다 문단 복사가 안전하다

삭제보다 더 흔한 실수는 잘못 수정하는 것입니다. 예를 들어 공개용으로 다듬다가 내부 강의용 설명을 지워버렸거나, 프롬프트 예시를 새 버전으로 바꿨는데 예전 버전이 더 좋았던 경우입니다.

이때 초보자에게 추천하는 방법은 "과거 버전에서 필요한 문단만 복사"입니다.

GitHub 웹사이트에서 해당 파일을 엽니다. 파일 상단의 History를 눌러 이전 커밋 목록을 봅니다. 원하는 시점의 파일을 열고, 필요한 문단만 복사합니다. 옵시디언의 현재 파일로 돌아와 알맞은 위치에 붙여 넣습니다. 그런 다음 커밋합니다.

예를 들어 커밋 메시지는 이렇게 쓸 수 있습니다.

[복구] 이전 버전의 실습 안내 문단 재반영

이 방식은 단순하지만 강력합니다. 저장소 전체를 되돌리지 않기 때문에 다른 팀원의 최신 작업을 건드리지 않습니다. 필요한 지식만 과거에서 꺼내 현재 문서에 가져오는 방식입니다.

Git을 개발자처럼 깊게 쓰면 특정 커밋으로 되돌리기, revert, checkout 같은 방법도 있습니다. 하지만 우리 책의 초보자 온보딩 단계에서는 먼저 "기록을 열어 보고 필요한 내용을 복사해 현재 문서에 반영한다"는 방식을 익히면 충분합니다.

Obsidian File Recovery는 가까운 응급상자다

깃허브 기록은 든든하지만, 모든 순간을 실시간으로 저장하는 것은 아닙니다. 커밋하기 전의 짧은 수정이나, 아직 Push하지 않은 로컬 변경은 GitHub에 없을 수 있습니다. 이럴 때 옵시디언의 File Recovery가 도움이 됩니다.

File Recovery는 옵시디언의 코어 플러그인입니다. 코어 플러그인은 옵시디언에 기본으로 포함된 공식 기능이라고 생각하면 됩니다. 옵시디언 도움말에서는 File Recovery가 노트의 스냅샷을 주기적으로 저장해 실수로 삭제하거나 원치 않게 변경된 작업을 보호한다고 설명합니다.⁵

확인 경로는 대략 다음과 같습니다.

Obsidian 설정 → Core plugins → File Recovery → View 또는 Snapshots 확인

옵시디언 버전이나 언어 설정에 따라 메뉴 이름은 조금 다를 수 있습니다. 핵심은 File Recovery를 켜두고, 문제가 생겼을 때 해당 파일의 이전 스냅샷을 찾아보는 것입니다.

File Recovery는 특히 이런 상황에서 유용합니다.

방금 문단을 지웠는데 아직 커밋하지 않았다.
옵시디언 안에서 실수로 내용을 덮어썼다.
GitHub에 올라가기 전의 로컬 수정본이 필요하다.

다만 File Recovery만 믿으면 안 됩니다. 이것은 응급상자입니다. 커뮤니티의 장기 기억은 GitHub 커밋 기록입니다. 둘을 함께 쓰면 훨씬 안전합니다.

Obsidian Git의 History와 Diff를 보조 도구로 쓰기

Obsidian Git 플러그인을 설치해 두었다면 옵시디언 안에서도 기록을 볼 수 있습니다. 명령어 팔레트에서 Git: Open history view 또는 비슷한 명령을 실행하면 커밋 기록을 확인할 수 있습니다. Open diff view 기능을 쓰면 파일의 변경 차이도 볼 수 있습니다. Obsidian Git 공식 저장소에서도 History View, Diff View, Source Control View 같은 기능을 제공한다고 설명합니다.³

이 기능은 "옵시디언을 떠나지 않고 확인한다"는 점에서 편리합니다. 다만 복구 작업이 복잡하거나 여러 파일이 얽혀 있다면 GitHub Desktop과 GitHub 웹사이트를 함께 여는 편이 좋습니다.

초보자에게 추천하는 역할 분담은 이렇습니다.

Obsidian Git History/Diff = 빠른 확인용
GitHub Desktop Changes/Diff = 커밋 전 최종 확인용
GitHub 웹사이트 History/Commits = 이전 버전 복구용
ZIP 백업 = 복구 전 안전망

도구가 많아 보이지만 역할을 나누면 어렵지 않습니다. 병원에도 체온계, 소독약, 엑스레이, 응급차가 각각 따로 있듯이 복구 도구도 상황별 역할이 다릅니다.

대량 이동과 이름 변경 전에는 반드시 ZIP 백업

커뮤니티 저장소에서 가장 큰 사고는 보통 "정리하다가" 생깁니다. 자료가 많아지면 누군가 좋은 마음으로 폴더 구조를 개편합니다.

"회의록은 여기로 옮기고, 프롬프트는 이름을 통일하고, 공개 후보는 따로 빼야겠다."

의도는 훌륭합니다. 하지만 대량 이동, 대량 이름 변경, 폴더 구조 개편은 Git 입장에서 큰 변화입니다. 파일이 삭제되고 새로 생긴 것처럼 보일 수 있고, 다른 사람이 작업 중인 파일 경로가 바뀌어 충돌이 커질 수 있습니다.

그래서 대량 작업 전에는 세 가지를 지킵니다.

첫째, 작업 전 Pull로 최신 상태를 만든다.
둘째, vault 전체를 ZIP으로 백업한다.
셋째, 팀 채널에 작업 시작과 예상 종료 시간을 알린다.

예고 문구는 이렇게 쓰면 됩니다.

[폴더 구조 개편 시작]
작업자: 김강사
범위: 20_프롬프트, 60_공개후보 폴더 정리
시작: 2026-05-06 14:00
예상 종료: 2026-05-06 15:00
요청: 이 시간 동안 해당 폴더 수정은 잠시 멈춰 주세요.
백업: 작업 전 ZIP 백업 완료

작업이 끝나면 GitHub Desktop의 Changes 화면을 꼭 봅니다. 이동한 파일이 예상대로 보이는지, 삭제되면 안 되는 파일이 삭제 목록에 있는지 확인합니다. 그리고 커밋 메시지는 구체적으로 씁니다.

[구조개편] 프롬프트와 공개후보 폴더 정리

대량 작업은 한 번에 몰아서 하기보다 작은 단위로 나누는 것이 좋습니다. 프롬프트 폴더 정리, 회의록 폴더 정리, 공개후보 이동처럼 커밋을 나누면 문제가 생겼을 때 어느 작업에서 꼬였는지 찾기 쉽습니다.

작업 전 Pull, 작업 후 Commit-and-sync

충돌 복구를 잘하는 것도 중요하지만, 가장 좋은 복구는 복구할 일을 줄이는 것입니다. 이를 위해 하루 루틴을 단순하게 고정합니다.

작업 전에는 최신 상태를 확인합니다. GitHub Desktop에서는 Fetch origin을 누릅니다. 원격 저장소에 새 변경이 있으면 Pull origin으로 가져옵니다. Obsidian Git을 쓴다면 작업 시작 시 Pull 또는 Commit-and-sync 흐름을 확인합니다.

중요한 점은 내 컴퓨터에 아직 커밋하지 않은 변경이 많이 쌓인 상태에서 무작정 Pull하지 않는 것입니다. 이때는 먼저 GitHub Desktop의 Changes 화면을 봅니다. 내가 하던 작업이 남아 있다면 커밋할지, ZIP 백업할지, 잠시 별도 문서로 복사해 둘지 결정합니다.

작업이 끝나면 의미 있는 메시지로 커밋하고 동기화합니다. Obsidian Git의 Commit-and-sync는 커밋, Pull, Push 과정을 한 번에 처리해 주는 편리한 기능입니다. Obsidian Git은 자동 commit-and-sync도 지원하지만,³ 협업 팀에서는 자동 기능만 믿기보다 중요한 작업 후 수동으로 한 번 확인하는 습관이 좋습니다.

커밋 메시지는 미래의 우리에게 보내는 짧은 메모입니다.

나쁜 예: 수정
좋은 예: [프롬프트] 강의안 작성 예시 3개 추가
좋은 예: [복구] 삭제된 회의록 내용 복원
좋은 예: [정리] 공개후보 폴더 파일명 통일

메시지가 구체적일수록 복구가 쉬워집니다. 나중에 GitHub 기록에서 "그때 뭘 바꿨더라?"를 찾을 수 있기 때문입니다.

팀 채널에 남길 응급 보고 템플릿

문제가 생겼을 때 혼자 해결하려다 더 꼬이는 경우가 많습니다. 특히 비전공자 커뮤니티에서는 "내가 괜히 망친 것 같아서" 말하지 못하고 조용히 이것저것 눌러보는 일이 위험합니다.

문제가 생기면 짧고 정확하게 알리면 됩니다. 아래 템플릿을 50_템플릿/복구_응급템플릿.md로 저장해 두세요.

## 복구 도움 요청

상황:
예) Pull 중 충돌 발생 / 파일 삭제 실수 / 잘못 수정 후 Push함

발생 시간:
예) 2026-05-06 14:20경

관련 파일:
예) 20_프롬프트/강의안작성.md

마지막으로 한 행동:
예) GitHub Desktop에서 Pull origin 클릭

현재 상태:
예) conflict 표시가 파일 안에 보임 / GitHub Desktop Changes에 파일 3개 표시됨

내가 이미 한 조치:
예) vault ZIP 백업 완료 / 아직 아무것도 삭제하지 않음

도움이 필요한 것:
예) 어떤 문장을 살릴지 함께 확인 필요 / JSON 파일이라 수정 전 확인 필요

이 템플릿의 핵심은 "이미 한 조치"입니다. 특히 "아직 아무것도 삭제하지 않음"은 좋은 소식입니다. 복구 담당자는 이 말을 들으면 안심합니다.

연습으로 충돌을 작게 만나보기

충돌은 실제 상황에서 처음 만나면 무섭습니다. 그래서 연습용 파일로 작게 경험해 보는 것이 좋습니다. 단, 실제 중요한 자료로 연습하지 마세요. 00_Inbox/온보딩연습/충돌연습.md 같은 파일을 따로 만듭니다.

운영진이나 숙련자가 두 기기 또는 두 계정으로 같은 줄을 다르게 수정해 작은 충돌을 만들어 봅니다. 그런 다음 신규 멤버와 함께 충돌 표시를 읽습니다.

<<<<<<< HEAD
내가 쓴 문장입니다.
=======
원격 저장소에 올라온 다른 문장입니다.
>>>>>>> origin/main

그리고 세 가지 방식으로 해결해 봅니다.

내 문장만 남기기
상대 문장만 남기기
두 문장을 합쳐 새 문장 만들기

연습의 목적은 Git 전문가가 되는 것이 아닙니다. 충돌 표시를 봐도 놀라지 않는 눈을 만드는 것입니다. 한 번이라도 직접 해결해 본 사람은 실제 문제가 생겼을 때 훨씬 차분합니다.

초보 팀을 위한 복구 판단표

마지막으로 상황별 판단표를 정리해 보겠습니다. 문제가 생기면 이 표를 먼저 보세요.

이 표는 기술 매뉴얼이라기보다 안전벨트입니다. 당황할수록 기본 순서로 돌아오면 됩니다.

복구의 핵심은 기록을 믿는 것이다

처음 Git을 배우면 충돌이 두렵습니다. 빨간 표시가 나오고, 알 수 없는 기호가 보이고, Push가 막히면 뭔가 크게 망가진 것처럼 느껴집니다. 하지만 이제 우리는 압니다. 충돌은 고장이 아니라 질문입니다. 삭제는 끝이 아니라 이전 기록을 찾아볼 신호입니다. 잘못된 수정은 부끄러운 사고가 아니라 더 나은 운영 규칙을 만드는 계기입니다.

우리 커뮤니티가 익혀야 할 태도는 단순합니다.

문제가 생기면 멈춘다.
변경 내용을 본다.
필요하면 ZIP으로 복사해 둔다.
기록에서 이전 버전을 찾는다.
의미 있는 커밋으로 복구 과정을 남긴다.

이 다섯 줄만 몸에 익어도 옵시디언과 깃허브는 훨씬 덜 무서워집니다.

AI 활용 강사들에게 자료는 단순한 파일이 아닙니다. 수업에서 건진 통찰, 수강생을 이해하게 된 순간, 더 쉬운 설명을 찾기 위해 쌓아온 시행착오입니다. 그런 자료를 다루는 팀에게 필요한 것은 완벽한 손놀림이 아닙니다. 실수해도 돌아올 수 있는 구조입니다.

깃허브는 우리에게 그 구조를 줍니다. 옵시디언은 생각을 쓰기 쉽게 해줍니다. 이제 우리는 실수를 두려워하기보다 기록을 믿고, 기록을 바탕으로 다시 정리할 수 있습니다. 이것이 협업하는 지식 커뮤니티가 오래 가는 힘입니다.

참고

¹About merge conflicts - GitHub Docs

²Solving Obsidian + Readwise Merge Conflicts with a Custom Git Driver

³Obsidian Git Plugin - GitHub

⁴Resolving a merge conflict using the command line - GitHub Docs

⁵File recovery - Obsidian Help