LiveSync 수동 Replicate는 되는데 자동 push만 안 될 때 — 새 볼트·새 DB로 재설정하고 DB wipe를 멈추자 풀렸다

환경: Obsidian Self-hosted LiveSync · CouchDB 3.3 백엔드 · 동기화 모드 LiveSync(상시연결)

TL;DR / 빠른 해결

동기화가 안 될 때 서버 DB를 지웠다 다시 만드는 걸 반복하지 마라. 그 행위가 새 고장을 만들 수 있다.

수동 Replicate는 되는데 자동 push만 안 된다면 — DB를 여러 번 지웠다 만들면서 동기화 체크포인트가 깨진 것을 의심한다. 다만 정직하게 말하면, 아래 본문에서 보듯 원인 1만으로도 같은 그림이 나올 수 있고 그걸 갈라놓을 관측은 남아 있지 않다. 여기서 실제로 한 건 새 볼트 + 새 DB로 한 번 재설정하고 그 뒤로 wipe를 중단한 것이고, 이미 어긋난 상태에서 "wipe만 멈춰도" 돌아오는지는 확인하지 못했다.
저장해도 아무 일도 안 일어난다면(로컬 DB에 편집이 담기지도 않음) — 반복 리셋으로 쌓인 로컬 캐시가 부팅마다 Error during vault initialisation process를 내고, LiveSync가 보호 동작으로 파일 감시를 스스로 중단한 상태일 수 있다. 이때는 Verify and repair all files 같은 전체 스캔만 동작하고 평소 저장은 잡히지 않는다.
둘 다 걸렸다면 완전히 새 볼트 + 새 DB로 한 번 깨끗하게 재설정하는 게 가장 빠르다. 그리고 그 뒤로는 DB를 지우지 않는다.

증상

이 글은 지금 다시 실행해 재현한 게 아니라, 그때 남긴 운영기록을 바탕으로 내가 다시 정리한 것이다. 시리즈 전체의 배경은 노션 대신 Obsidian 자가호스팅에 정리해뒀다.

동기화가 안 되는 증상은 두 갈래였다.

증상 1 — 편집이 아예 안 잡힌다. 노트를 고치고 저장해도 아무 일도 일어나지 않았다. 다른 기기로 안 넘어가는 정도가 아니라, 로컬 DB에조차 담기지 않았다. 그런데 Verify and repair all files 같은 전체 스캔을 수동으로 돌리면 그때는 변경이 잡혔다. 즉 파일은 멀쩡한데 "바뀌었다는 사실"을 실시간으로 감지하는 쪽이 죽어 있었다.

증상 2 — 수동은 되는데 자동만 안 된다. 수동 Replicate 버튼을 누르면 복제가 정상적으로 돌았다. 다만 기록에는 "수동은 됐다"까지만 적혀 있고, 특정 편집이 반대편 기기에 도착하는 것까지 확인했는지는 남아 있지 않다. 그런데 상시연결(LiveSync) 모드로 두면 자동 push가 일어나지 않았다. 연결 자체는 살아 있는데 변경이 서버로 안 올라갔다.

그때는 원인도 둘로 봤다. 그리고 둘 다 고치려고 한 행동에서 비롯된 것으로 봤다.

시간으로 보면 이렇다. 그날은 Cloudflare로 접속 경로를 만드는 일로 시작해 반나절 넘게 거기 매달렸고, 그다음 여기 적은 동기화 문제를 잡느라 저녁까지 갔다. 꼬박 하루가 통째로 들어갔다.

오진 배제 (여기서 시간을 제일 많이 버렸다)

전부 원인이 아니었다. 같은 길로 갈 사람을 위해 남긴다.

Obsidian 본체 버전. 그때 쓰던 1.12.7이 문제인가 싶어 사용자가 앱에서 1.11.7로 내려보기까지 했다. 무관했다.
LiveSync 플러그인 버전. 사용자가 0.25.73과 0.24.31을 오가며 교체해봤다. 역시 무관했다.
Cloudflare의 100초 연결 제한. 앞 편에서 다룬 그 문제다. 실재하는 제약이지만 이 증상의 원인은 아니었다 — 접속 경로를 시간 제한이 없는 tailscale로 갈아탄 뒤에도 자동 push는 그대로 안 됐다. 이 지점이 "네트워크 탓"이라는 가설을 접게 만든 결정적 관측이었다.

버전을 의심하는 건 자연스러운 반사신경이지만, 버전을 바꿔가며 재현되는 증상은 버전 문제가 아니다. 여기서 훨씬 일찍 방향을 틀었어야 했다.

원인 1로 지목한 것: 반복 리셋이 남긴 로컬 캐시 → 파일 감시 자동 중단

플러그인을 붙였다 떼고 리셋하기를 반복하는 동안 로컬 캐시에 정리되지 않은 상태가 쌓였다. 그 결과 Obsidian을 켤 때마다 Error during vault initialisation process가 떴다.

같은 메시지가 다른 원인으로도 뜬다. 신규 기기의 최초 fetch가 미완으로 끊길 때도 이 문구가 나오는데, 그건 이 글과 원인이 다르다 — 신규 기기 최초 동기화가 761/23585에서 멈출 때를 보면 된다. 이 글은 이미 쓰던 기기에서 부팅할 때마다 뜨는 경우다.

문제는 그다음이다. 관측된 건 여기까지다 — 저장은 로컬 DB에 담기지 않는데, 전체 스캔은 같은 변경을 잡는다. 그때 남긴 기록은 이걸 LiveSync가 보호 동작으로 파일 감시를 스스로 중단한 상태로 적어뒀고, 초기화가 깨진 채 계속 파일을 삼키면 데이터가 망가질 수 있으니 그렇게 설계됐으리라는 해석이 붙어 있었다. 다만 이건 플러그인 문서나 이슈로 확인한 게 아니라 증상에서 끌어낸 해석이다. 전체 스캔(Verify and repair all files)은 파일을 직접 훑는 경로라 그때만 변경이 잡혔던 것이다.

여기서 중요한 건 이 상태가 조용하다는 점이다. 감시를 중단했다고 크게 알려주는 게 아니라, 그냥 저장해도 아무 일이 안 일어난다. 그래서 원인을 서버나 네트워크에서 찾게 된다 — 실제로는 클라이언트가 스스로 손을 놓은 상태인데.

원인 2로 지목한 것: 반복된 DB wipe

두 번째가 더 고약하다. 원인으로 지목된 게 내 디버깅 행위 그 자체였다.

동기화가 안 되니 "서버를 깨끗하게 비우고 다시 해보자"며 내가 CouchDB의 데이터베이스를 지웠다 다시 만들기를 여러 번 반복했다. CouchDB는 HTTP API 호출 한 번으로 데이터베이스를 통째로 지울 수 있다. 서버 관리자 계정이 필요하긴 하지만 그 자격증명은 서버에 이미 있었고, OS 권한(sudo) 같은 건 필요 없다 — 되돌릴 수 없는 작업치고 손이 너무 쉽게 닿는다는 게 문제였다. 그런데 LiveSync는 복제가 어디까지 진행됐는지를 기록하는 체크포인트를 들고 동작한다. 서버 DB가 통째로 사라졌다 새로 생기면 이 체크포인트의 앞뒤가 맞지 않게 되는 것으로 추정되고, 실제로 상시연결 모드의 자동 push가 그 상태에서 동작하지 못했다.

경계를 하나 그어둔다. wipe를 시작하기 전에 자동 push가 정상이었다는 관측은 기록에 없다 — 지우기 시작한 시점엔 이미 원인 1로 동기화가 깨져 있었기 때문이다. 그러니 "wipe가 체크포인트를 깨뜨렸다"는 건 관측이 아니라 증상 조합에서 끌어낸 진단이다.

지금 다시 보면 대안 설명도 하나 있다. 원인 1로 파일 감시가 꺼져 있으면 저장이 로컬 DB에 담기지 않는데, LiveSync의 실시간 복제는 파일이 아니라 로컬 DB를 기준으로 올린다. 즉 감시가 꺼진 것만으로도 "자동 push가 일어나지 않는다"는 그림이 그대로 나온다. 두 원인을 갈라놓으려면 전체 스캔으로 변경을 로컬 DB에 넣은 다음 아무것도 누르지 않고 올라가는지 확인했어야 하는데, 그 관측은 남아 있지 않다.

이 대안이 성립하려면 "수동은 됐다"가 "복제가 에러 없이 돌았다"는 뜻이어야 한다 — 편집이 실제로 건너간 걸 확인한 것이었다면 그 편집은 로컬 DB에 담겨 있었다는 뜻이고, 그러면 이 대안은 무너진다. 기록만으로는 어느 쪽인지 갈리지 않는다. 그때는 여기까지 생각이 닿지 않았다.

그래도 수동 Replicate가 계속 됐던 건 체크포인트 쪽 그림에도 맞는다. 수동 복제는 "지금 양쪽을 비교해서 맞춰라"에 가까워서 체크포인트가 어긋나도 굴러가지만, 자동 push는 그 체크포인트를 기준으로 움직이기 때문에 멈춰 서는 것으로 보인다.

즉 동기화를 고치려던 내 행동이 새로운 고장을 하나 더 만들어놓고 있었다는 게 그때의 결론이었다. 그리고 그 고장은 원래 증상과 겉모습이 비슷해서, 지울수록 원인 진단이 더 어려워지는 악순환이었다.

해결

당시 진단이 두 원인이었으므로 각각을 따로 끊었다.

완전히 새 볼트 + 새 DB로 한 번 깨끗하게 재설정한다.(볼트 쪽 재설정은 Obsidian 앱에서 해야 해서 사용자가 진행했다.) 쌓인 로컬 캐시를 물려받지 않는 게 핵심이다. 이러자 부팅 때마다 뜨던 Error during vault initialisation process가 사라졌고, 파일 감시가 정상 동작해 저장이 곧바로 잡히기 시작했다.
그 뒤로 DB wipe를 하지 않는다. 서버 DB를 그대로 두자 상시연결 모드의 자동 push도 정상 동작했다.

여기서 순서가 중요하다. 먼저 깨끗한 상태를 한 번 만들고, 그다음부터는 지우지 않는 것이다. "안 되니까 또 지운다"를 반복하면 1번을 아무리 해도 2번이 계속 재생산된다.

한 가지 더 밝혀두면, 두 조치를 같이 했기 때문에 각각이 얼마나 기여했는지는 분리해서 검증하지 못했다. 확인된 건 "둘을 함께 하자 두 증상이 모두 사라졌다"까지다.

교훈 / 체크리스트

"수동 복제는 되는데 자동만 안 된다"는 네트워크 문제가 아니라 상태 문제일 가능성이 높다. 연결이 죽었다면 수동도 안 됐어야 한다. 둘의 차이가 곧 단서다.
동기화 디버깅에서 서버 DB를 지우는 건 마지막 수단이다. 반복하면 그 자체가 원인이 될 수 있다. 특히 체크포인트 기반으로 도는 시스템에서는 "초기화"가 안전한 행동이 아니다.
저장해도 아무 일도 안 일어나면 클라이언트가 보호 동작으로 손을 놨는지부터 본다. 조용히 멈추기 때문에 서버·네트워크를 먼저 뒤지게 되는데, 방향이 반대일 수 있다.
버전을 바꿔도 똑같이 재현되면 버전 문제가 아니다. 다운그레이드는 싸 보여서 자꾸 손이 가지만, 재현되는 순간 그 가설은 죽은 것으로 취급하고 넘어가야 한다.