Hermes의 기억을 만들기 전에 두 Mac의 문서부터 맞췄다: MainVault 동기화·충돌·복원

📝 한줄 요약

바쁘시면 이것만 읽어도 돼요:

• Hermes가 사용할 지식 저장소를 만들기 전에 두 Mac의 MainVault부터 동기화했습니다.

• Syncthing을 개인 네트워크 안에서만 연결하고 관리 화면은 각 장비 안에서만 열리게 했습니다.

• 생성·수정뿐 아니라 삭제 전파, 이전 버전 보존, 고의 충돌까지 시험했습니다.

• 충돌 파일은 자동으로 덮지 않고 사용자가 기준 문서를 선택해 정리했습니다.

• 삭제한 시험 문서는 Syncthing의 공식 버전 복원 기능으로 되살렸습니다.

• 동기화는 백업이 아니라는 한계를 명확히 남기고 Hermes의 읽기·쓰기는 아직 열지 않았습니다.

ALT

헤르메스

문서를 양쪽에서 같게 만드는 동기화와, 과거 상태를 독립적으로 보관하는 백업은 역할이 다릅니다.

🎯 이런 분들께 도움돼요

• Obsidian Vault를 두 대 이상의 Mac에서 안전하게 사용하려는 분

• AI에게 문서를 연결하기 전에 저장소의 기준을 먼저 세우려는 분

• 동기화 충돌과 실수로 지운 파일의 복원 과정을 직접 확인하고 싶은 분

• Syncthing의 버전 보존 기능과 한계를 알고 싶은 분

😫 문제 상황 (Before)

Hermes에게 개인 문서를 읽게 하려면 먼저 어느 파일이 최신인지 분명해야 합니다. Mac mini와 MacBook의 문서가 따로 움직이면 에이전트가 오래된 내용을 읽거나 한쪽의 수정이 다른 쪽을 덮을 수 있습니다.

단순히 “동기화 완료” 표시만 보는 것도 부족했습니다. 양쪽에서 동시에 같은 문서를 고치면 어떤 일이 생기는지, 삭제가 반대편에도 전달되는지, 과거 버전을 실제로 복구할 수 있는지 확인해야 했습니다. 이 작업에서는 Hermes 연결보다 문서 기반의 신뢰성을 먼저 다뤘습니다.

🛠️ 사용한 도구

콘텐츠 해시는 파일 내용으로 만든 짧은 지문입니다. 파일명이 같아도 내용이 다른 경우를 찾아낼 수 있습니다.

🔧 작업 과정

1. MainVault만 동기화 범위로 정했다

두 Mac에서 MainVault 폴더 하나만 Send & Receive로 연결했습니다. 이는 양쪽 모두 수정 내용을 보낼 수 있다는 뜻입니다. Syncthing 관리 화면은 외부에서 열리지 않도록 각 장비의 내부 주소에만 묶고, 장비 간 연결도 개인 네트워크 안으로 제한했습니다.

핵심 프롬프트는 정상 동작보다 실패 상황을 더 구체적으로 요구했습니다.

두 Mac의 MainVault만 양방향 동기화한다.
생성, 수정, 삭제 전파, 이전 버전 보존, 양쪽 동시 수정 충돌,
사용자 선택에 따른 충돌 정리, 삭제 문서 복원을 각각 시험한다.
동기화를 백업으로 표현하지 말고 Hermes 읽기·쓰기는 아직 활성화하지 않는다.

macOS가 자동으로 만드는 .DS_Store는 동기화 대상에서 제외했습니다. 이전 버전은 최대 5개, 30일 동안 보존하도록 설정했습니다.

이 보존 규칙은 짧은 실수에서 복구할 시간을 주지만 영구 보관은 아닙니다. 두 장비가 함께 고장 나거나 30일이 지나면 도움이 되지 않을 수 있으므로, 별도의 암호화 백업을 대체하지 않는다고 처음부터 선을 그었습니다.

2. 생성과 수정은 내용 지문까지 비교했다

시험 문서를 한쪽에서 만들고 다른 쪽에 나타나는지 확인했습니다. 이어 내용을 수정한 뒤 양쪽 파일의 해시를 비교했습니다. 화면에 “최신”이라고 표시되는 것뿐 아니라 실제 내용이 같은지 확인한 것입니다.

삭제 시험에서는 한쪽에서 문서를 지운 뒤 반대편에서도 삭제가 전파되는지 확인했습니다. 동시에 Syncthing의 버전 폴더에는 삭제 전 파일이 남아 있는지 검사했습니다.

3. 충돌을 일부러 만들었다

한 장비의 동기화를 잠시 멈추고, 두 Mac에서 같은 문서를 서로 다르게 수정했습니다. 다시 연결하자 Syncthing은 한쪽을 조용히 덮어쓰지 않고 충돌 사본을 만들었습니다.

어느 내용이 정답인지는 도구가 결정하지 않았습니다. 사용자가 Mac mini의 수정본을 기준으로 선택했고, 다른 내용을 확인한 뒤 수동으로 정리했습니다. 마지막에는 남은 충돌 파일이 0개인지 확인했습니다.

여기서 자동 병합을 사용하지 않은 이유는 시험 문서가 짧아서가 아니라 운영 원칙 때문입니다. 두 문장 중 어느 것이 최신 결정인지 기계가 알 수 없을 때는, 손실 없는 사본을 보존하고 사람이 최종본을 선택하도록 했습니다.

4. 삭제 파일을 공식 경로로 복원했다

삭제된 시험 문서를 단순히 버전 폴더에서 복사하지 않고 Syncthing의 공식 버전 복원 기능으로 되살렸습니다. 복원된 문서의 내용과 해시가 삭제 전 값과 같은지 확인했습니다. 시험 문서와 버전 출력은 검증 후 정확한 대상만 정리했습니다.

마지막에는 양쪽 장비의 미동기화 항목과 오류 수가 0인지 다시 확인했습니다. 복원 파일 하나만 맞는 것이 아니라 전체 MainVault가 안정된 상태로 돌아왔는지를 완료 기준으로 삼았습니다.

✅ 결과 (After)

Before vs After

결과물

• 두 Mac의 MainVault 양방향 동기화

• 이전 버전 5개·30일 보존 규칙

• 생성·수정·삭제·충돌·복원 시험 기록

• 충돌 시 사용자 선택을 우선하는 운영 절차

• “Syncthing은 독립 백업이 아니다”라는 운영 원칙

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

• AI에게 정상 동기화만 묻지 않고 삭제와 동시 수정 시나리오를 먼저 만들게 했습니다.

• “어느 문서가 맞는가”는 사용자가 결정하고, AI는 차이와 증거를 정리하게 했습니다.

• 파일 해시를 사용하니 눈으로 보기 어려운 공백이나 인코딩 차이도 확인할 수 있었습니다.

이렇게 하면 안 돼요

• 동기화 상태가 초록색이라는 이유만으로 복원 가능하다고 판단하면 안 됩니다.

• 충돌 파일을 자동 삭제하면 한쪽에서만 작성한 내용을 잃을 수 있습니다.

• 동기화를 독립 백업으로 오해하면 양쪽에 전파된 삭제를 막지 못합니다.

🌍 다른 업무에 적용한다면?

팀 공유 폴더, 연구 자료, 사진 원본처럼 여러 장비에서 수정되는 자료에도 같은 시험이 필요합니다. 정상 복사뿐 아니라 삭제, 동시 수정, 이전 버전 복원을 실제로 해봐야 운영 규칙을 만들 수 있습니다.

🚀 앞으로의 계획

• MainVault의 문서 형식과 주소 규칙을 먼저 확정

• 별도 저장 위치에 MainVault 독립 백업과 복원 시험 추가

• 검증된 일부 문서만 Hermes에 읽기 전용으로 연결

📋 재사용 가능한 프롬프트

프롬프트 1: 두 장비 문서 동기화 검증

[동기화 도구]로 두 장비의 [대상 폴더]만 양방향 동기화해줘.
관리 화면과 장비 간 통신 범위를 최소화하고 불필요한 시스템 파일은 제외해줘.
생성·수정·삭제 전파·동시 수정 충돌·사용자 선택·이전 버전 복원을 실제 파일과 내용 해시로 검증해줘.
동기화와 독립 백업의 차이, 아직 검증하지 않은 항목도 결과에 분리해줘.