동기화와 백업

제 컴퓨터 두 대(회사 PC와 집 PC)는 Syncthing이라는 무료 프로그램으로 같은 폴더를 실시간으로 맞추고, 아마존 클라우드 저장소인 AWS S3에 하루 한 번 백업을 올립니다. 둘은 비슷해 보이지만 하는 일이 반대라서 둘 다 둡니다.

동기화는 복사기이고, 백업은 금고입니다

Syncthing은 두 컴퓨터를 인터넷으로 직접 이어 주는 프로그램입니다. 한쪽에서 파일이 바뀌면 몇 초 안에 다른 쪽 파일도 똑같이 바꿉니다. 파일을 중간 서버에 맡기지 않고 두 PC끼리 주고받습니다. 그래서 회사에서 고친 문서를 집에 가서 그대로 이어 쓸 수 있습니다.

문제는 «똑같이»입니다. 실수로 파일을 지우면 그 실수도 몇 초 안에 다른 PC로 건너갑니다. 랜섬웨어가 파일을 망가뜨려도 마찬가지입니다. 동기화는 지키는 장치가 아니라 베끼는 장치입니다.

S3는 아마존(AWS)이 빌려주는 클라우드 저장소입니다. 저는 여기에 하루 한 번, 아침 8시에 회사 PC의 폴더를 올립니다. 오늘 실수를 해도 어제 올린 판은 그대로 남아 있습니다.

	동기화 (Syncthing)	백업 (S3)
언제	파일이 바뀌면 바로	하루 한 번, 08:00
방향	두 PC가 서로	회사 PC → 클라우드, 한쪽으로만
실수로 지우면	양쪽에서 같이 사라진다	어제 올린 판이 남아 있다
비용	무료	한 달 1달러 안쪽 (계산값)

사고마다 막아 주는 층이 다릅니다

파일 하나를 잘못 지웠다면 첫째 층, 버전 보관으로 갑니다. Syncthing은 상대 PC에서 건너온 변경 때문에 파일이 바뀌거나 지워지면, 바뀌기 전 판을 숨김 폴더에 따로 챙겨 둡니다. 저는 이걸 1년까지 두도록 켜 놨습니다. 기본값은 꺼짐이라 직접 켜야 합니다.

한쪽 PC의 디스크가 통째로 죽으면 둘째 층, 다른 PC가 있습니다. 거기에 같은 파일이 다 있으니까요.

셋째 층 S3는 두 PC가 한꺼번에 당했을 때를 위한 것입니다. 실수가 이미 양쪽에 퍼졌거나, 둘 다 포맷해야 하는 경우입니다. 그래서 S3는 동기화가 고장 났을 때보다 동기화가 너무 잘 돌았을 때 필요합니다.

백업은 한 PC에서만, 한 방향으로만 올립니다

S3에 올리는 일은 회사 PC 혼자 합니다. 집 PC에서 같은 백업 스크립트가 켜지면, 스크립트가 자기 자신을 끄고 끝납니다.

이유가 있습니다. 한 방향 백업은 «원본에 없는 파일은 백업에서도 지운다»는 규칙으로 돕니다. 두 PC가 같은 저장소에 각자 올리면, 서로 상대가 올린 파일을 «원본에 없다»고 보고 지우게 됩니다. 집 PC의 변경은 어차피 Syncthing이 회사 PC로 가져오니, 한 곳에서만 올려도 빠지는 게 없습니다.

거꾸로 S3에서 PC로 내려받는 일은 자동으로 두지 않았습니다. 그게 자동이면 PC에서 난 사고가 그대로 백업까지 덮어쓸 수 있어서, 되살릴 때는 사람이 직접 명령을 칩니다.

옮기지 않는 파일도 정해 둡니다

모든 파일을 옮기는 게 정답은 아닙니다. 아래 넷은 일부러 동기화에서 뺐습니다.

빼는 것	왜
PC마다 다른 설정·로그인 파일	파일 안에 그 PC의 사용자 이름이 박혀 있어서, 건너가면 서로를 덮어쓴다
프로그램이 쓰고 있는 데이터베이스	쓰는 도중에 복사되면 깨진다
언제든 다시 만들 수 있는 색인	두 PC가 각자 만들면 매번 «양쪽이 고쳤다»로 부딪친다
AI와 나눈 대화 기록 파일	계속 길어지는 파일이라, 버전 보관이 통째로 복사하다가 22GB까지 불었다

반대 경우도 있습니다. _no_sync라는 이름의 폴더는 S3에는 안 올리지만 Syncthing으로는 일부러 옮깁니다. 이 이름의 쓰임은 AI 폴더링에 따로 적었습니다.

아직 못 한 것

Syncthing이 조용히 멈춰도 알려 주는 장치가 없습니다. 8월에 한 번 그런 일이 있었고, 그 뒤로도 사람이 가끔 들여다보는 게 전부입니다.

집 PC의 AI 대화 기록은 집 PC에만 있습니다. 대화 기록을 동기화에서 뺐고 S3는 회사 PC만 올리니, 집에서 나눈 대화는 어디에도 사본이 없습니다.

클라우드 요금 경보도 없습니다. 백업용 계정에 저장소 권한만 줘서 청구서를 읽을 수 없습니다. 위 표의 한 달 비용은 그래서 계산값입니다.

여기부터는 자세한 기록입니다

처음(2026-05-21)에는 S3 하나로 두 PC를 묶었습니다. 회사 PC와 집 PC가 각각 S3와 양방향으로 맞추는 구조였습니다. 석 달 동안 요금이 오르고 가짜 충돌이 쌓였고, 8월 7일에 Syncthing을 들이면서 S3를 백업 전용으로 내렸습니다. 아래는 지금(2026-10-29) 돌고 있는 설정과, 거기까지 오면서 값을 치른 일들입니다.

지금 설정은 이렇습니다

항목	값
Syncthing	v2.1.7. 두 PC가 직접 연결된다(중계 서버를 안 거친다)
맞추는 폴더	작업 폴더와 AI 설정 폴더로 시작해, 지금은 다른 도구 설정 폴더 둘이 더해져 넷
바뀐 뒤 보내기까지 기다리는 시간	작업 폴더 10초 · AI 설정 폴더 300초
버전 보관	단계식(staggered). 처음 한 시간은 30초마다, 그 뒤로는 점점 성기게 남기고 1년이 지나면 지운다
충돌 감시	15분마다 충돌 사본을 찾아 로그·캐시류는 정리하고, 작업 파일은 남긴 채 알림. 회사 PC에서만 돈다
S3로 올리는 도구	rclone sync, 회사 PC → S3 한 방향, 매일 08:00
올릴 때 붙이는 것	--checksum(내용으로 비교) · --max-delete 300(한 번에 300개 넘게 지우면 멈춤)
S3 저장소 설정	버전 관리 켬 · 서버 쪽 암호화 · 공개 접근 차단 · 서울 지역
옛 판 정리 규칙	옛 판은 하루가 지나면 가장 최근 것 하나만 남긴다. 끝나지 않은 업로드 조각은 7일 뒤 지운다
rclone 설정 파일	암호화해 두고, 암호는 각 PC 안의 파일에서 읽는다
게임 저장소의 git 기록	폴더째 올리지 않고, 매일 git bundle 로 묶은 파일 한 개(약 10MB)만 올린다

두 장치가 같은 폴더를 맡으면 가짜 충돌이 납니다

Syncthing을 처음 붙인 8월 7일 하루 동안 충돌 알림이 계속 울렸습니다. 열어 보니 전부 가짜였습니다. 충돌 사본 한쪽은 지금 파일과 글자 하나 다르지 않았고, 다른 한쪽은 S3에 남아 있던 하루 전 판이었습니다.

원인은 구조였습니다. Syncthing이 방금 두 PC를 똑같이 맞춰 놨는데, 하루 한 번 도는 S3 양방향 동기화가 하루 늦은 판을 들고 와서 «상대 PC가 고쳤다»고 읽었습니다. 제외 목록으로는 못 막았습니다. 그래서 같은 날 S3를 회사 PC 한 대에서 올리기만 하는 한 방향으로 바꿨고, 충돌이라는 개념 자체가 백업 쪽에서 사라졌습니다.

두 동기화 장치가 같은 폴더를 맡으면 서로의 쓰기를 남의 변경으로 봅니다. 한쪽은 맞추고, 다른 한쪽은 받아 적기만 해야 합니다.

돈은 저장이 아니라 «물어보는 횟수»에서 샜습니다

S3 청구액이 5월 20달러, 6월 47달러, 7월 75달러로 올랐습니다. 처음엔 옛 판이 쌓여서라고 생각했는데, 저장 요금은 한 달 1.7달러였습니다. 옛 판을 다 지워도 1.5달러밖에 안 줄어드는 셈입니다.

진짜 범인은 요청 수였습니다. rclone은 파일 목록만 받아서는 수정 시각을 알 수 없어, 파일마다 따로 «이 파일 언제 바뀌었나»를 묻습니다. 파일 2만 6천여 개를 하루 144번 맞추고 있었으니 한 달에 1억 번이 넘는 질문이었습니다.

손본 것	효과
하루 144번 → 하루 한 번	질문 수가 그만큼 준다
양방향 → 한 방향 + --checksum	목록에 이미 있는 내용 지문으로 비교해, 파일마다 묻지 않는다(35개로 재 보니 질문 36번 → 1번)
결과	한 번 도는 시간 2.1분 → 12초

중간에 한 번 크게 넘어졌습니다. 같은 질문을 줄이는 다른 옵션(--use-server-modtime)을 먼저 넣었는데, 명령 하나로 시험할 때는 멀쩡하던 것이 양방향 동기화의 정상 순환에 들어가자 «모든 파일이 바뀌었다»고 판단해 스스로 멈췄습니다. 두 PC 동기화가 7시간 섰습니다. 명령 하나가 통과했다고 순환 전체가 통과하는 건 아니었습니다.

브레이크는 평소 일도 사고로 봅니다

S3 백업에는 «한 번에 300개 넘게 지우려 하면 멈춘다»는 브레이크가 있습니다. 실수로 폴더를 통째로 지웠을 때 그게 백업까지 번지지 않게 하려는 장치입니다. 그런데 10월 2일부터 29일까지 28일 중 26일이 이 브레이크에 걸려 «실패»로 끝났습니다.

지우려던 파일을 날짜별로 세어 보니 날마다 240~300개가 한 폴더에서 나왔습니다. 제가 만드는 게임의 git 기록 폴더(.git)였습니다. git은 작업할 때마다 작은 파일을 하나씩 만들어 두다가, 수천 개가 쌓이면 큰 파일 하나로 묶고 작은 것들을 지웁니다. 10월에 그 저장소 커밋이 927개로 늘면서 하루 천 개 가까운 작은 파일이 올라갔고, 묶일 때마다 백업 쪽에서 수천 개를 지워야 했습니다. 하루 300개로는 못 따라가서, 29일에는 S3에 지우지 못한 파일이 7,332개 쌓여 있었습니다.

브레이크는 고장이 아니었습니다. 지우는 개수만 보는 장치라서, 평소 일과 사고를 구별하지 못했을 뿐입니다. 그래서 브레이크는 그대로 두고 들고 나는 파일의 모양을 바꿨습니다. 그 저장소의 .git 은 백업에서 빼고, 매일 git bundle 로 브랜치 314개와 작업 폴더별 위치까지 전부 파일 한 개로 묶어 올립니다. 묶는 데 4초가 걸렸고, S3에서 다시 내려받아 복원해 보니 브랜치 수와 최신 커밋이 원본과 같았습니다. 그다음 S3에 남아 있던 옛 .git 파일 10,816개를 지웠고, 같은 날 다시 돌린 백업은 성공으로 끝났습니다.

개수로 거는 브레이크는 «무엇이» 지워지는지를 모릅니다. 브레이크를 느슨하게 풀기보다, 매일 수천 개씩 바뀌는 것을 한 개로 바꾸는 편이 브레이크도 살리고 원인도 없앴습니다.

지운 파일의 마지막 판은 일부러 남깁니다

옛 판 정리 규칙은 «더 새로운 옛 판이 하나 이상 있으면» 지웁니다. 그런데 이미 지운 파일의 마지막 판은 그 뒤에 더 새로운 판이 없으니, 이 규칙으로는 영원히 안 지워집니다. 8월에 재 보니 그런 판이 11,472개, 4.75GiB였습니다.

처음엔 결함으로 봤습니다. 다시 보니 실수로 지운 파일을 되살릴 유일한 근거였습니다. 한 달 0.12달러라서 그대로 두기로 했습니다. 날짜만으로 지우는 규칙도 검토했다가 버렸습니다. 그러면 잘 안 바뀌는 중요한 파일일수록 복구 지점이 먼저 사라집니다.

Syncthing은 에러 없이 멈출 수 있습니다

8월 29일 오후, 이 PC의 변경이 다른 PC로 하나도 가지 않았습니다. 화면에도 로그에도 경고가 없었습니다. 폴더 상태가 «검사 중»에서 몇 시간째 안 바뀌고 있었고, 검사가 안 끝나니 주고받는 단계가 아예 시작되지 않았습니다.

갈라낸 기준은 상태 글자가 아니라 남은 양이었습니다. 받아야 할 바이트 수가 수십 분 동안 1바이트도 안 줄면 멈춘 것입니다. 연결 상태를 묻는 요청은 바로 답했기 때문에 «살아 있다»로 속기 쉬웠습니다.

시도	결과
프로그램 재시작	4분 뒤 적용, 15분쯤 돌다가 다시 멈춤
강제 종료	45초간 안 죽고, 다시 뜬 뒤 데이터베이스를 여느라 14분 무응답, 또 멈춤
재부팅	다음 날 정상으로 돌아옴

데이터는 하나도 안 잃었습니다. 멈추는 고장이지 지우는 고장은 아니었습니다. 지금 규칙은 «두 번 재시작해서 같은 자리로 돌아오면 재부팅»입니다.

버전 보관은 차이가 아니라 파일을 통째로 남깁니다

9월 14일, 디스크 경고가 왔습니다. 버전 보관 폴더가 22.04GB였고, 그중 22.02GB가 AI 대화 기록 파일이었습니다. 대화 하나짜리 파일이 287MB까지 자라 있었고, 대화가 이어질 때마다 30~60초 간격으로 그 파일이 통째로 한 판씩 쌓였습니다. 그 한 대화에서만 36판, 8.2GB였습니다.

같은 폴더의 첨부 이미지 3GB는 한 번 쓰고 안 바뀌어서 판이 하나도 안 쌓였습니다. 범인은 크기가 아니라 «계속 자라는 큰 파일»이었습니다. 대화 기록을 Syncthing에서 빼고, 원본이 살아 있는 옛 판(21.66GB)만 지웠습니다. 원본이 이미 없는 판 125개는 유일한 사본이라 남겼습니다.

이보다 먼저, 8월에는 이 폴더 크기로 알림을 걸었다가 두 번 헛울렸습니다. 버전 보관은 한 시간마다 스스로 솎아내서 크기가 톱니처럼 오르내리는데, 하필 솎아내기 직전 꼭대기를 재고 있었습니다. 그래서 알림 기준을 디스크 여유 공간으로 바꿨습니다. 중간 숫자 대신 정말 걱정하는 숫자를 재니 헛울림이 멎었습니다.

두 PC의 AI가 같은 파일을 고치면 한쪽 고침이 사라집니다

9월 22일, 이 PC의 AI 작업 창과 다른 PC의 AI 작업 창이 같은 코드 파일을 몇 초 간격으로 번갈아 고쳤습니다. Syncthing은 두 판을 합치지 않습니다. 하나를 고르고, 진 쪽은 이름.sync-conflict-날짜-시각-기기 사본으로 따로 빼 둡니다. 그래서 고친 내용이 작업 파일에서 사라졌다가 돌아오기를 1분 사이에 세 번 했습니다.

신호는 둘이었습니다. 고친 파일 옆에 충돌 사본이 생긴 것, 그리고 파일 안에 제가 쓰지 않은 코드가 들어온 것. 지금 규칙은 그 파일에서 손을 떼고, 지금 판과 사본을 다른 곳에 떠 두고, 누가 먼저 고칠지 사람에게 묻는 것입니다. 한 번에 한쪽만 고칩니다.

제외 목록은 PC마다 따로 고쳐야 합니다

Syncthing은 제외 목록 파일(.stignore)을 자기 설정으로 보고 상대 PC에 보내지 않습니다. S3가 양방향이던 시절에는 그걸 타고 건너갔지만, 한 방향이 된 뒤로는 어느 길로도 안 갑니다. 그래서 제외 목록을 고치면 회사 PC와 집 PC에서 각각 고칩니다. 한쪽만 고치면 아무 에러 없이 어긋난 채로 돕니다.

제외 규칙은 이름을 정확히 쓰지 않고 넓게 겁니다. 처음에 로그인 파일을 정확한 이름 하나로만 뺐더니, 계정별로 만든 사본과 .bak 붙은 사본이 그대로 백업에 올라갔습니다. 복구하려고 방금 만든 백업 파일까지 다음 번에 올라갔습니다. 지금은 .credentials*처럼 별표로 막고, 막은 뒤에는 S3를 직접 조회해서 정말 0개인지 확인합니다.

대소문자도 부딪쳤습니다. 윈도는 C--Users와 c--Users를 같은 폴더로 보지만 Syncthing과 S3는 다른 폴더로 봅니다. 그 때문에 34개 파일이 멈춰 있었고, 대소문자를 무시하는 제외 패턴으로 풀었습니다.

한쪽 PC를 포맷할 때는 순서가 있습니다

Syncthing을 다시 깔 때 예전 설정과 데이터베이스를 백업에서 되살리면 안 됩니다. 데이터베이스에는 «파일이 N개 있었다»가 적혀 있는데 디스크가 비어 있으면, 전부 «지워졌다»로 판정해 상대 PC에서도 지웁니다. Syncthing에는 한꺼번에 지우는 걸 막는 브레이크가 없습니다.

새 데이터베이스로 시작하면 안전합니다. 처음 보는 기기로 참가해 상대에게서 내려받기만 합니다. 순서는 S3 백업 작업을 먼저 끄고 → 포맷하고 → Syncthing을 새로 깔고 → 상대 PC가 제안하는 폴더 이름을 그대로 받고 → 다 맞춰진 걸 본 뒤에 백업을 다시 켜는 것입니다.

이 기록에서 값을 치른 교훈은 이겁니다 — 동기화가 조용하다는 건 아무 뜻도 없습니다. 가짜 충돌은 시끄럽게 울렸고, 진짜 고장(8월 29일의 정지)은 한 번도 안 울렸습니다. 그래서 상태 글자 대신 남은 양을, 폴더 크기 대신 디스크 여유를 재게 됐습니다.

남은 일

할 일	지금
Syncthing 정지 자동 감지	없음. 남은 양을 사람이 가끔 본다
버전 보관 기간 1년 → 7~30일	작업 폴더에도 영향이 있어 보류
집 PC 대화 기록 사본	없음. 동기화에서 뺀 뒤로 집 PC에만 있다
클라우드 요금 경보	없음. 백업용 계정이 청구서를 못 읽는다