자가 호스팅 지식 시스템을 위한 Syncthing 파일 동기화

로컬 지식용 프라이빗 동기화

Page content

Syncthing은 사용자가 제어하는 여러 기기 간에 파일을 동기화하며, 클라우드 종속을 피하는 자체 호스팅 지식 인프라를 구축하는 데 가장 실용적인 도구 중 하나입니다.

클라우드 저장소 플랫폼과 달리 Syncthing은 각 기기가 동기화된 폴더의 자체 사본을 보유하고 신뢰할 수 있는 피어(Peer)와 직접 변경 사항을 교환하는 피어 투 피어(P2P) 모델을 사용합니다. 사용자의 데이터를 소유하는 중앙 서버는 없으며, 구독 계정이나 벤더 락인(Vendor Lock-in)도 존재하지 않습니다. 이 프로젝트는 오픈 소스이며 커뮤니티 주도이며, 더 자세한 정보는 syncthing.net에서 확인할 수 있습니다.

laptop with server

이러한 아키텍처는 데스크톱, 노트북, 홈 서버 및 스마트폰에서 마크다운 노트, 연구 문서, PDF 및 프로젝트 파일을 관리하는 지식 근로자에게 Syncthing을 특히 유용하게 만듭니다. 이 도구는 개념은 단순하지만, 동기화를 백업으로 오인하거나 격리되어야 하는 폴더를 동기화하는 등의 일반적인 함정을 피하기 위해 신중한 설정이 필요합니다.

Syncthing이 무엇인지, 그리고 무엇이 아닌지

Syncthing은 두 개 이상의 기기 간에 파일을 동기화합니다. 각 기기는 폴더의 자체 사본을 유지하며, 변경 사항은 신뢰할 수 있는 피어 간에 전파됩니다. 디스커버리(Discovery) 및 릴레이(Relay) 서비스는 네트워크 간에 기기를 서로 찾을 수 있도록 도와줄 수 있지만, 저장 모델은 여전히 로컬 우선(Local-first) 방식입니다. 설치 및 구성에 대한 자세한 내용은 Syncthing 문서를 참조하세요.

여기서 조용하지만 중요한 주장을 하나 드리겠습니다. Syncthing은 동기화 인프라로 취급될 때 훌륭합니다. 그러나 백업으로 취급될 때는 위험해질 수 있습니다.

이는 클라우드 드라이브가 아닙니다. 완전한 백업 시스템도 아닙니다. 협업 스위트(Suite)도 아닙니다. 이는 사적이고 피어 투 피어 방식의 파일 동기화 도구입니다.

지식 관리에서 Syncthing이 중요한 이유

지식 관리는 단순히 메모를 작성하는 것 이상이 아닙니다. 이는 지식이 어디에 존재하는지, 어떻게 이동하는지, 시간이 지나도 접근 가능한지 유지되는지와 관련이 있습니다 — 이 도구가 어떻게 도구, 방법론 및 자체 호스팅 플랫폼의 더 큰 그림에 들어맞는지 보려면 지식 관리 가이드를 참조하세요.

유용한 개인 또는 팀 지식 시스템에는 일반적으로 다음이 포함됩니다:

  • 마크다운 노트
  • PDF 및 논문
  • 다이어그램 및 스크린샷
  • 내보낸 웹 페이지
  • 소스 스니펫 및 구성 파일
  • 미팅 노트 및 프로젝트 문서
  • 스캔된 문서 및 일반 텍스트 로그

이 중 많은 항목은 단순히 파일일 뿐입니다. 이는 좋은 일입니다. 파일은 내구성이 뛰어나고, 휴대하며, 검색 가능하고, 스크립팅이 가능하며, 백업하기 쉽습니다.

Syncthing은 이러한 파일들을 벤더 플랫폼으로 강제로 넣지 않으면서도 이동성을 제공합니다. 한 기기에서 노트를 작성하고, 다른 기기에서 읽으며, 홈 서버에 사본을 유지할 수 있습니다. 또한 grep, ripgrep, Obsidian, VS Code, DokuWiki 가져오기, 정적 사이트 생성기 또는 사용자 지정 스크립트와 같은 일반적인 도구를 계속 사용할 수 있습니다.

자체 호스팅 지식 시스템에 있어 이는 강력한 아키텍처적 특성입니다. PKM의 목표와 방법론에 대한 더 넓은 관점은 개인 지식 관리 기초를 참조하고, 다양한 지식 시스템이 다른 층위에서 어떻게 작동하는지는 PKM vs RAG vs Wiki vs Memory Systems를 참조하세요.

구분된 시스템 역할

graph LR S["Syncthing
files 이동"] --> B["Backup
history 보존"] S --> K["Knowledge tools
create and edit"] B --> R["Recovery
things go wrong when"] K --> S

이러한 역할은 분리되어 유지되어야 합니다.

Syncthing은 중요한 데이터의 유일한 사본이 되어서는 안 됩니다. 우연한 삭제로부터 당신을 보호하는 유일한 수단도 되어서는 안 됩니다. 손상, 랜섬웨어, 파일 시스템 실패 또는 잘못된 스크립트 이후의 유일한 복구 메커니즘도 되어서는 안 됩니다.

올바르게 사용될 때, Syncthing은 탄력적인 파일 워크플로우의 일부입니다. 그러나 단독으로 사용될 경우, 실수를 매우 효율적으로 복제할 수 있습니다.

Syncthing의 유용한 사용 사례

Syncthing은 폴더에 명확한 소유자가 있고, 예측 가능한 구조가 있으며, 신뢰할 수 있는 기기의 수가 적을 때 가장 잘 작동합니다.

유용한 사용 사례에는 다음이 포함됩니다:

  • Obsidian 또는 마크다운 노트 볼트(Vault) 동기화
  • 데스크톱과 노트북 간 프로젝트 노트 동기화
  • 상시 가동(home server) 홈 서버로의 문서 동기화
  • 내보낸 PDF 및 연구 자료 동기화
  • 개인 기기 간 구성 파일 동기화
  • 한 기기에서 다른 기기로 스캔된 문서 동기화
  • 선택된 휴대폰 폴더를 데스크톱 또는 NAS로 동기화
  • 게시 전 정적 사이트 소스 노트 동기화
  • 작업stations와 서버 간 지식 아카이브 동기화

이는 이국적인 사용 사례가 아닙니다. 이는 지식 근로자가 매일 필요로 하는 지루하지만 필수적인 파일 이동입니다.

Syncthing은 Syncthing 없이도 폴더가 이해 가능할 때 가장 강력합니다. 파일 관리자에서 폴더를 열어보고 그것이 무엇인지 이해할 수 있다면, 도구를 잘 사용하고 있는 것입니다.

Syncthing의 위험한 사용 사례

사용자가 Syncthing을 백업, 협업 소프트웨어 또는 관리형 클라우드 저장소처럼 행동할 것으로 기대할 때 Syncthing은 위험해집니다.

다음 사항에는 주의해야 합니다:

  • Syncthing을 유일한 백업으로 사용
  • 삭제 위험을 고려하지 않고 거대한 폴더 동기화
  • 여러 앱이 동시에 편집하는 동안 동일한 파일 동기화
  • 독점적인 로컬 액세스를 기대하는 애플리케이션 데이터베이스 동기화
  • 브라우저 프로필 동기화
  • 메일 스토어 동기화
  • 빌드 디렉토리 또는 캐시 폴더 동기화
  • 자주 생성되는 파일이 있는 폴더 동기화
  • 저용량 저장소 기기로 매우 큰 사진 라이브러리 동기화
  • 테스트하지 않고 모바일 배경 동기화에 의존

문제는 Syncthing이 신뢰할 수 없다는 것이 아닙니다. 문제는 동기화가 강력한 기능이라는 것입니다. 사용자의 요청대로 작동하며, 여기에는 삭제, 충돌, 손상된 파일 및 우연한 편집의 동기화도 포함됩니다.

따라서 지식 시스템은 Syncthing을 버전 관리, 스냅샷 및 실제 백업과 결합해야 합니다.

Syncthing은 백업이 아닙니다

이 점은 별도의 섹션이 필요합니다.

백업은 복구에 관한 것입니다. 동기화는 수렴(Convergence)에 관한 것입니다. 이는 관련이 있지만 동일하지는 않습니다.

한 기기에서 파일을 삭제하면 동기화 도구는 모든 곳에서 삭제할 수 있습니다. 스크립트가 폴더를 손상시키면 손상된 버전이 다른 기기로 동기화될 수 있습니다. 랜섬웨어가 로컬 파일을 암호화하면 암호화된 버전이 변경된 파일로 처리될 수 있습니다.

파일 버전 관리는 이러한 위험을 줄일 수 있지만, Syncthing을 완전한 백업 시스템으로 만들지는 않습니다. Syncthing 버전 관리는 폴더 및 기기별로 구성되며, 주로 다른 기기에서 변경 사항을 받을 때 이전 버전을 보호합니다. 이는 모든 로컬 편집이 발생하기 전을 마법처럼 보존하지는 않습니다.

더 안전한 설계는 다음과 같습니다:

활성 파일 이동을 위한 Syncthing.
단기 실수 복구를 위한 파일 버전 관리.
로컬 롤백을 위한 파일 시스템 스냅샷.
실제 복구를 위한 Restic, Borg, ZFS send, Btrfs 스냅샷 또는 다른 백업 시스템.

이는 동기화가 백업인 것처럼 가장하는 것보다 지루하지만, 훨씬 더 안전합니다.

권장 지식 워크플로우

실용적인 자체 호스팅 지식 설정은 다음과 같을 수 있습니다:

graph TD subgraph "Desktop Workstation" D["Main editing device
Full notes and documents"] end subgraph "Laptop" L["Mobile editing device
Same knowledge folders"] end subgraph "Home Server or NAS" H["Always-on sync target
Receive-side versioning
Filesystem snapshots
Separate backup job"] end subgraph "Phone" P["Selected folders only
Camera scans or quick capture
Avoid full archive sync"] end D <--> H L <--> H P --> H

이러한 구조가 작동하는 이유는 상시 가동 서버가 시스템의 안정적인 지점이 되기 때문입니다. 이는 중앙 클라우드 서버일 필요는 없지만, 동기화 토폴로지에 신뢰할 수 있는 앵커를 제공합니다.

지식 관리에 있어 이 앵커는 중요합니다. 노트북은 절전 모드로 들어가고, 휴대폰은 배경 서비스를 제한하며, 데스크톱은 항상 켜져 있지 않습니다. 작은 홈 서버나 NAS는 시스템이 안정적으로 수렴할 수 있는 장소를 제공합니다.

폴더 설계의 중요성

모든 것을 동기화하는 하나의 거대한 폴더를 만들지 마세요.

별도의 목적을 위해 별도의 폴더를 만드세요:

knowledge-notes
knowledge-documents
research-papers
project-notes
scans-inbox
static-site-drafts
configs

이는 다음과 같은 사항을 더 잘 제어할 수 있게 해줍니다:

  • 어떤 기기가 어떤 파일을 받을지
  • 어떤 폴더에 버전 관리가 필요한지
  • 어떤 폴더에 스냅샷이 필요한지
  • 어떤 폴더는 송신 전용(Send-only)일 수 있는지
  • 어떤 폴더는 모바일 기기를 피해야 하는지
  • 어떤 폴더에 프라이버시 또는 크기 문제가 있는지

폴더 경계는 아키텍처입니다. 이는 신뢰, 저장, 복구 및 운영 행위를 정의합니다.

예를 들어, Obsidian 볼트는 노트북, 데스크톱 및 서버로 동기화될 수 있습니다. 큰 PDF 아카이브는 데스크톱과 서버로만 동기화할 수 있습니다. 휴대폰 스캔 인박스(Inbox)는 서버로만 전송하도록 설정할 수 있습니다.

이는 모든 기기를 동등하게 취급하는 것보다 훨씬 깔끔합니다.

Syncthing 폴더 유형 이해하기

Syncthing은 변경 사항을 어떻게 흐르길 원하는지에 따라 다양한 폴더 행동을 지원합니다.

**송수신(Send and receive)**은 기본 모드입니다. 기기는 로컬 변경 사항을 보내고 원격 변경 사항을 받습니다. 이는 신뢰할 수 있는 기기 간 활성 편집을 위한 일반적인 선택입니다.

**송신 전용(Send-only)**은 로컬 변경 사항을 다른 기기로 보내지만, 원격 변경 사항을 권위 있는 것으로 받아들이지 않습니다. 이는 한 기기를 원본으로 취급해야 하는 소스 폴더에 유용할 수 있습니다.

**수신 전용(Receive-only)**은 변경 사항을 받지만 로컬 변경 사항을 클러스터의 나머지 부분에 게시하지 않습니다. 이는 로컬 편집이 다시 전송되지 않아야 하는 미러, 복제 대상 및 백업 인접 목적지에 유용할 수 있습니다.

이러한 모드는 강력하지만 시스템을 더 추론하기 어렵게 만들 수도 있습니다. 의도적으로 사용하세요. 대부분의 일상적인 폴더에는 송수신이 더 단순합니다.

노트를 위한 좋은 폴더 레이아웃

마크다운 기반 노트의 경우, 구조를 예측 가능하게 유지하세요.

예시:

knowledge-notes/
  inbox/
  projects/
  areas/
  references/
  archive/
  attachments/

이는 Obsidian, VS Code, ripgrep, 정적 사이트 생성기 및 명령줄 스크립트와 같은 도구와 잘 작동합니다.

임시 내보내기, 생성된 인덱스 및 애플리케이션 캐시를 동기화하고 싶지 않다면 동일한 폴더에 넣지 마세요. 노이즈가 많거나 기계 특정 파일에는 무시 패턴(Ignore patterns)을 사용하세요.

무시할 수 있는 파일 예시:

.DS_Store
Thumbs.db
*.tmp
*.swp
.cache/
node_modules/
dist/
build/

특히 Obsidian의 경우, 모든 플러그인 상태를 동기화하기 전에 신중하게 생각하세요. 일부 설정은 기기 간에 유용하지만, 작업 공간 상태는 창 레이아웃이나 활성 패널을 끊임없이 변경하면 귀찮을 수 있습니다.

Syncthing과 Obsidian

Obsidian은 노트를 로컬 마크다운 파일로 저장하기 때문에 Syncthing은 종종 Obsidian 볼트 동기화에 사용됩니다.

이는 좋은 조합입니다. Obsidian은 작성 및 링크 인터페이스를 제공합니다. Syncthing은 파일을 이동합니다. 당신의 노트는 여전히 평문 파일입니다.

주요 위험은 충돌과 모바일 동작입니다.

동기화 전에 두 기기에서 동일한 노트를 편집하면 Syncthing은 충돌 파일을 생성할 수 있습니다. 이는 조용한 데이터 손실보다 낫지만, 여전히 정리 작업이 필요합니다. 실용적인 습관은 다른 곳에서 동일한 활성 노트를 편집하기 전에 기기가 동기화되도록 기다리는 것입니다.

모바일 기기의 경우, 배경 동기화가 데스크톱 동기화와 정확히 동일하게 작동한다고 가정하지 마세요. 테스트해 보세요. 앱을 열고, 동기화가 완료되도록 하고, 노트를 편집한 후, 변경 사항이 다른 기기에서 나타나는지 확인하세요.

PKM 도구의 동기화 고려 사항에 대한 더 넓은 토론은 Obsidian vs Logseq 비교를 참조하세요.

Syncthing과 DokuWiki 또는 정적 지식 사이트

Syncthing은 파일 기반 또는 파일 친화적 지식 시스템 주변에서도 잘 작동합니다.

DokuWiki의 경우, Syncthing을 사용하여 내보낸 문서, 미디어 파일 또는 스테이징 콘텐츠를 기기 간에 이동할 수 있습니다. 라이브 서버 데이터, 권한 및 동시 편집에는 더 주의해야 합니다. 플랫폼 옵션에 대해서는 DokuWiki 및 자체 호스팅 위키 대안을 참조하세요.

Hugo 또는 다른 정적 사이트 생성기의 경우, Syncthing은 초안, 연구 노트 및 콘텐츠 소스 파일에 유용할 수 있습니다. 이는 소스 컨트롤을 위한 Git를 대체해서는 안 되지만, 비코드 지식 자료를 위한 Git를 보완할 수 있습니다.

좋은 규칙은 다음과 같습니다:

히스토리 및 협업을 위해 Git 사용.
사적인 파일 이동을 위해 Syncthing 사용.
복구를 위해 백업 사용.

각 도구에는 역할이 있습니다.

Syncthing vs Nextcloud

Syncthing과 Nextcloud는 종종 비교되지만, 서로 다른 문제를 해결합니다.

기능 Syncthing Nextcloud
아키텍처 피어 투 피어 동기화 중앙 서버
가장 적합한 용도 사적인 기기 간 폴더 웹 접근 가능한 파일 플랫폼
저장 모델 기기별 로컬 사본 서버 우선 저장
웹 UI 최소한의 로컬 관리 UI 완전한 웹 파일 인터페이스
공유 링크 주요 목적이 아님 내장됨
사용자 및 권한 기기 신뢰 모델 사용자 및 그룹 모델
캘린더 및 연락처 없음 있음
오피스 협업 없음 애드온으로 가능
지식 노트 로컬 우선 노트에 좋음 서버 중심 공유에 좋음
운영 스타일 가벼우지만 수동 무거우지만 더 완전함

자신의 기기 간 사적인 파일 동기화가 필요할 때 Syncthing을 사용하세요.

사용자, 웹 액세스, 공유, 캘린더, 연락처 및 더 넓은 협업 기능이 있는 자체 호스팅 클라우드 플랫폼이 필요할 때 Nextcloud를 사용하세요. 자세한 설정 안내는 Nextcloud 자체 호스팅 가이드를 참조하세요.

두 가지 모두 필요하면 둘 다 사용하세요. 예를 들어, Syncthing은 로컬 우선 노트를 처리하고, Nextcloud는 가족 파일 공유 또는 브라우저 기반 액세스를 처리할 수 있습니다.

Syncthing vs rsync

Rsync는 일회性或 예약된 파일 복사에 훌륭합니다. 단순하고, 스크립팅이 가능하며, 널리 사용 가능합니다.

Syncthing은 자체 스케줄링, 충돌 감지 및 디스커버리 로직을 작성하지 않고도 여러 기기 간에 지속적인 동기화가 필요할 때 더 좋습니다.

rsync를 사용하는 경우:

  • 스크립트된 배포
  • 원방향 복사
  • 서버 유지 관리
  • 간단한 백업 작업
  • 예측 가능한 배치 전송

Syncthing을 사용하는 경우:

  • 지속적인 다중 기기 동기화
  • 로컬 우선 노트
  • 개인 문서 이동
  • 상시 가동 폴더 수렴
  • 크로스 플랫폼 기기 동기화

Rsync는 도구입니다. Syncthing은 작은 동기화 시스템입니다.

Syncthing vs Seafile

Seafile은 파일 동기화 플랫폼에 더 가깝습니다. 중앙 서비스, 클라이언트, 라이브러리 및 더 관리되는 팀 파일 동기화 경험을 원할 때 좋은 선택이 될 수 있습니다.

Syncthing은 더 분산화되어 있고 개념이 단순합니다. 진실을 소유하는 주요 서버가 없습니다. 기기들이 서로 폴더를 공유합니다.

개인 지식 관리의 경우, 로컬 파일을 이미 선호한다면 Syncthing이 더 추론하기 쉬울 수 있습니다. 팀 파일 공유의 경우, Seafile 또는 Nextcloud가 더 적합할 수 있습니다.

문제는 어떤 도구가 더 나은지가 아닙니다. 문제는 로컬 우선 피어 동기화를 원하는지, 아니면 중앙 파일 플랫폼을 원하는지입니다.

2026년의 Android

Android 이야기는 주의가 필요합니다.

원래 Syncthing Android 앱은 2024년 12월 출시 이후 중단되었습니다. 커뮤니티 포크 및 대체 접근 방식이 존재할 수 있지만, Android는 Syncthing 지식 시스템의 가장 안정적인 부분으로 취급해서는 안 됩니다.

이는 Android에서 Syncthing이 쓸모없다는 의미가 아닙니다. 이는 모바일 동기화를 편의 계층으로 설계해야 하며, 유일한 신뢰할 수 있는 사본으로 취급해서는 안 된다는 의미입니다.

Android의 경우, 더 좁은 사용 사례를 선호하세요:

  • 스캔 인박스
  • 카메라 가져오기 폴더
  • 빠른 노트 폴더
  • 읽기 전용 참조 폴더
  • 선택된 문서

휴대폰을 지식 아카이브의 유일한 완전한 동기화 경로에 대한 책임을 지우지 마세요. 휴대폰은 배터리 관리가 되고, 저장 공간이 제한되며, 배경 파일 액세스에 대해 점점 더 제한적입니다.

지루하지만 가장 좋은 권장 사항은 다음과 같습니다: 데스크톱, 노트북 및 서버에 권위 있는 지식 세트를 유지하세요. 휴대폰이 선택적으로 참여하도록 하세요.

버전 관리 전략

Syncthing은 파일 버전 관리를 지원하며, 최소한 하나의 안정적인 기기에서 이를 활성화해야 합니다.

지식 관리 설정의 경우, 홈 서버 또는 NAS가 버전 관리에 가장 적합한 장소일 수 있습니다. 이는 항상 가동되며, 더 많은 저장 공간을 가지고 있으며, 백업 작업에 포함하기가 더 쉽습니다.

일반적인 버전 관리 접근 방식에는 다음이 포함됩니다:

  • 휴지통 버전 관리(Trash can versioning) — 이동된 파일이 휴지 폴더로 이동
  • 간단한 버전 관리(Simple versioning) — 고정 수의 이전 버전 유지
  • 간격 버전 관리(Staggered versioning) — 현재 근처에 더 많은 버전을 유지하고, 파일이 노후화됨에 따라 적은 수의 버전 유지
  • 외부 버전 관리(External versioning) — 버전 관리를 외부 도위임

대부분의 개인 지식 폴더의 경우, 간격 버전 관리가 합리적인 시작점입니다. 이는 현재 근처에 더 많은 버전을 유지하고 파일이 노후화됨에 따라 적은 수의 버전을 유지합니다.

버전 관리는 무료가 아닙니다. 저장 공간을 소비하고 주기적인 검토가 필요합니다. 그러나 저장 공간은 1년 분량의 노트를 잃는 것보다 저렴합니다.

스냅샷 및 백업

Syncthing 대상이 NAS 또는 Linux 서버인 경우, 스냅샷을 추가하세요.

좋은 옵션에는 다음이 포함됩니다:

  • ZFS 스냅샷
  • Btrfs 스냅샷
  • LVM 스냅샷
  • restic
  • BorgBackup
  • Kopia
  • NAS 플랫폼의 파일 시스템 수준 백업 도구

강력한 설정은 다음과 같을 수 있습니다:

Syncthing이 서버로 파일을 동기화합니다.
서버는 Syncthing 파일 버전을 유지합니다.
파일 시스템은 스냅샷을 유지합니다.
백업 도구가 암호화된 백업을 외부로 복사합니다.

이는 여러 복구 레이어를 제공합니다.

노트를 실수로 삭제하면 Syncthing 버전 관리가 도움이 될 수 있습니다. 폴더가 손상되면 파일 시스템 스냅샷이 도움이 될 수 있습니다. 서버 디스크가 고장 나면 외부 백업이 도움이 될 수 있습니다.

이는 동기화 설정과 복구 전략 간의 차이입니다.

프라이버시 및 신뢰

Syncthing은 모든 지식 파일을 제3자 클라우드 계정에 넣지 않고도 피할 수 있게 하기 때문에 매력적입니다.

그러나 프라이버시는 자동으로 보장되지 않습니다. 여전히 기기 신뢰에 대해 생각해야 합니다.

폴더에 참여하는 모든 정상적인 신뢰된 기기는 해당 폴더를 읽을 수 있습니다. 노트를 오래된 노트북으로 동기화하면, 그 노트북은 이제 보안 경계의 일부가 됩니다. 문서를 VPS로 동기화하면, 그 서버도 중요합니다.

Syncthing에는 신뢰받지 않는 암호화 디바이스(Untrusted encrypted device) 기능도 있지만, 신중하게 취급해야 합니다. 이는 평문 파일 콘텐츠를 보지 않아야 하는 기기에서 암호화된 복제를 원할 때 유용할 수 있지만, 더 고급이며 신뢰하기 전에 테스트해야 합니다.

대부분의 사람들에게 더 단순한 모델이 더 좋습니다:

 실제로 신뢰하는 기기로만 민감한 폴더를 동기화.
 노트북 및 서버의 디스크 암호화.
 중요한 데이터 별도 백업.
 사적인 아카이브를 모든 곳에 동기화하지 않음.

자체 호스팅은 자동으로 안전하다는 의미가 아닙니다. 이는 당신이 책임을 소유한다는 의미입니다.

충돌 처리

충돌은 동기화가 수렴되기 전에 다른 기기가 동일한 파일을 변경할 때 발생합니다.

노트의 경우, 하나가 오프라인인 동안 노트북과 데스크톱에서 동일한 마크다운 파일을 편집하면 발생할 수 있습니다. Syncthing은 조용히 하나의 버전을 선택하는 대신 충돌 사본을 보존합니다.

이는 올바른 동작이지만, 여전히 정리 작업을 남깁니다.

충돌을 줄이기 위해:

  • 두 개의 오프라인 기기에서 동일한 노트를 편집하지 않음
  • 기기를 전환하기 전에 동기화가 완료되도록 함
  • 자주 편집되는 인박스 노트를 작게 유지
  • 불필요하게 애플리케이션 상태 파일을 동기화하지 않음
  • 휘발성 파일에 무시 패턴 사용
  • 주기적으로 충돌 파일 검토

충돌 파일은 Syncthing이 고장났다는 신호가 아닙니다. 이는 두 기기가 동시에 현실을 변경했다는 신호입니다.

무시 패턴

무시 패턴은 지식 폴더에 중요합니다.

이는 생성된, 임시 또는 기계 특정 파일을 동기화 세트에서 제외합니다. 이는 충돌을 줄이고, 대역폭을 절약하며, 다른 기기를 오염시키지 않습니다.

일반적인 예시:

.DS_Store
Thumbs.db
*.tmp
*.swp
*.bak
.cache/
node_modules/
dist/
build/
__pycache__/

노트 볼트의 경우, 플러그인 캐시, 작업 공간 레이아웃 파일 또는 생성된 인덱스가 실제로 동기화되어야 하는지 고려하세요. 일부는 동기화해야 하고, 일부는 그렇지 않습니다.

원리는 단순합니다: 소스 재료는 동기화하되, 노이즈는 동기화하지 마세요.

권장 Syncthing 토폴로지

한 사람의 경우, 홈 서버 주변의 별 모양 토폴로지가 종종 가장 쉽습니다.

desktop <-> home-server
laptop  <-> home-server
phone   -> home-server

기기들은 여전히 직접 연결될 수 있지만, 서버는 안정적인 만남의 지점을 제공합니다.

작은 가구의 경우, 개인 폴더를 분리하세요. 모든 사람이 결과를 이해하지 않는 한 하나의 공유 메가 폴더를 만들지 마세요.

작은 기술 팀의 경우, 주의해야 합니다. Syncthing은 신뢰할 수 있는 피어 간 공유 파일에 작동할 수 있지만, 적절한 협업 도구, 권한, 검토 워크플로우 또는 버전 관리를 대체하지는 않습니다.

더 많은 사람을 추가할수록, Nextcloud, Seafile, Git 또는 문서 시스템과 같은 서버 중심 플랫폼이 더 매력적으로 됩니다.

실용적인 설정 예시

합리적인 자체 호스팅 지식 설정은 다음과 같습니다.

Folders:
  knowledge-notes
  knowledge-documents
  research-papers
  scans-inbox

Devices:
  desktop
  laptop
  home-server
  phone

Rules:
  desktop and laptop use send-receive for notes
  home-server uses send-receive with versioning enabled
  phone sends scans-inbox only
  large PDFs do not sync to phone
  home-server snapshots all synced folders
  home-server backup runs nightly

이 설정은 화려하지는 않지만 강인합니다.

로컬 우선 작업, 모바일 캡처, 서버 측 복구 및 외부 백업을 지원합니다. 휴대폰을 전체 아카이브의 책임자로 만들지 않습니다. 또한 동기화와 백업을 혼동하지 않습니다.

운영 체크리스트

Syncthing에 중요한 지식 파일을 신뢰하기 전에 기본 사항을 확인하세요.

모든 중요한 폴더가 최소 두 개의 실제 기기로 동기화되었나요?
하나의 기기가 항상 가동 중이거나 자주 온라인인가요?
최소 하나의 안정적인 기기에서 파일 버전 관리가 활성화되었나요?
서버 또는 NAS에서 파일 시스템 스냅샷이 활성화되었나요?
외부 백업이 있나요?
노이즈 파일이 무시되었나요?
모바일 폴더가 제한되었나요?
복구를 테스트했나요?
충돌 동작을 테스트했나요?
어떤 폴더가 송신 전용 또는 수신 전용인지 이해하고 있나요?

가장 중요한 항목은 복구 테스트입니다.

한 번도 복구해본 적이 없는 백업 전략은 이론에 불과합니다. 충돌 하에서 한 번도 테스트해본 적이 없는 동기화 전략도 이론입니다.

일반적인 실수

가장 흔한 실수는 너무 많은 것을 동기화하는 것입니다.

사람들은 하나의 유용한 폴더로 시작하지만, 곧 모든 문서, 모든 사진, 모든 내보내기, 모든 캐시 및 모든 애플리케이션 디렉토리를 추가합니다. 시스템은 노이즈가 많고 추론하기 어려워집니다.

두 번째 실수는 수신 전용 폴더를 마법 같은 백업으로 취급하는 것입니다. 이는 유용하지만, 완전한 역사적 복구 시스템은 아닙니다.

세 번째 실수는 삭제 동작을 무시하는 것입니다. 삭제가 모든 곳으로 동기화되면, 삭제는 디자인의 일부입니다.

네 번째 실수는 모바일 동기화를 너무 신뢰하는 것입니다. 모바일 운영 체지는 장기간 배경 파일 동기화에 친숙하지 않습니다.

다섯 번째 실수는 버전 관리를 사용하지 않는 것입니다. 데이터가 중요하다면, 어딘가에 버전을 유지하세요.

여섯 번째 실수는 실제 백업이 없는 것입니다. Syncthing은 백업 대상에 데이터를 채우는 데 도움이 될 수 있지만, 유일한 보호 수단이 되어서는 안 됩니다.

자체 호스팅 지식 스택에서 Syncthing의 위치

자체 호스팅 지식 시스템에서 Syncthing은 인프라입니다.

이는 노트 앱, 위키, 검색 도구, 정적 사이트, 스크립트 및 AI 지원 워크플로우 아래에 위치합니다. 이는 이러한 시스템이 사용하는 파일을 이동합니다.

간단한 스택은 다음과 같을 수 있습니다:

graph TB subgraph "Capture" C1["Phone scanner"] C2["Browser save"] C3["Quick notes"] end subgraph "Sync" S["Syncthing"] end subgraph "Storage" ST1["Desktop"] ST2["Laptop"] ST3["Home server / NAS"] end subgraph "Authoring" A1["Obsidian"] A2["VS Code"] A3["Vim"] A4["DokuWiki"] A5["Static site generator"] end subgraph "Search" SR1["ripgrep"] SR2["Desktop search"] SR3["Local index"] SR4["RAG pipeline"] end subgraph "Recovery" R1["Versioning"] R2["Snapshots"] R3["Encrypted backup"] end C1 --> S C2 --> S C3 --> S S --> ST1 S --> ST2 S --> ST3 ST1 --> A1 ST1 --> A2 ST2 --> A3 ST3 --> A4 ST3 --> A5 A1 --> SR1 A2 --> SR2 A3 --> SR3 A4 --> SR4 ST3 --> R1 ST3 --> R2 ST3 --> R3

이러한 분리는 건강합니다.

저장을 교체하지 않고 편집기를 교체할 수 있습니다. 노트 형식을 교체하지 않고 백업 도구를 교체할 수 있습니다. Syncthing을 중단해도 여전히 일반 파일을 가질 수 있습니다.

이는 로컬 우선 지식 인프라의 가치입니다.

Syncthing이 적합한 도구인 경우

Syncthing은 제어하는 기기 간 사적인 파일 동기화가 문제일 때 강력한 선택입니다. 이는 협업, 웹 액세스, 권한 또는 장기적 복구가 실제 문제일 때는 덜 적합합니다.

이 구별은 많은 자체 호스팅 파일 워크플로우가 불분명한 기대에서 실패하기 때문에 중요합니다. 동기화 도구는 파일을 매우 잘 이동할 수 있지만, 클라우드 스위트, 백업 아카이브 및 팀 협업 플랫폼을 동시에 행동하도록 요청해서는 안 됩니다.

필요 Syncthing 적합도 Syncthing이 충분하지 않을 때 더 나은 적합도
자신의 기기 간 사적인 동기화 우수 일반적으로 불필요
로컬 우선 마크다운 노트 우수 관리형 동기화를 선호한다면 Obsidian Sync
개인 문서 폴더 좋음 브라우저 액세스가 필요하면 Nextcloud
가족 파일 공유 가능하지만 어색함 Nextcloud
팀 문서 협업 제한적 Nextcloud, Seafile, Google Drive, Microsoft 365
원방향 서버 복사 좋음 rsync가 더 단순할 수 있음
완전한 백업 및 복구 단독으로는 부족 restic, BorgBackup, Kopia
웹 파일 액세스 약함 Nextcloud 또는 Seafile
캘린더 및 연락처 지원 안 함 Nextcloud
모바일 사진 백업 주의가 필요함 가능 Immich, Nextcloud, 플랫폼 사진 도구
암호화된 오프사이트 백업 주요 역할이 아님 restic, BorgBackup, Kopia
신뢰받지 않는 기기로의 암호화 동기화 고급 사용 사례 Syncthing 신뢰받지 않는 기기, 신중하게 테스트

이는 Syncthing이 유용하게 남아있는 주요 이유입니다. 이는 완전한 클라우드 플랫폼이 되려고 하지 않습니다. 작업이 명확할 때 가장 잘 작동합니다: 신뢰할 수 있는 기기 간에 선택된 폴더를 동기화 유지.

최종 권장 사항

신뢰할 수 있는 기기 간 사적이고 로컬 우선 파일 동기화가 필요할 때 자체 호스팅 지식 관리를 위해 Syncthing을 사용하세요.

노트, 문서, 연구 폴더, 스캔 및 개인 지식 아카이브에 사용하세요. 마크다운, 평문 파일, 로컬 검색 및 자체 호스팅 서비스와 결합하세요. 대시보드 없이도 이해할 수 있을 만큼 구조를 단순하게 유지하세요.

그러나 동기화와 백업을 혼동하지 마세요.

최고의 설정은 Syncthing 단독이 아닙니다. 최고의 설정은 Syncthing에 파일 버전 관리, 파일 시스템 스냅샷 및 실제 백업을 추가한 것입니다.

이 조합은 자체 호스팅 지식 시스템이 지향해야 하는 것을 제공합니다: 로컬 제어, 실용적인 편의성 및 복구 가능한 데이터.

구독하기

시스템, 인프라, AI 엔지니어링에 관한 새 글을 받아보세요.