Obsidian을 개인 지식창고처럼 쓰다 보니 동기화가 멈추는 순간 가장 먼저 겁이 납니다. 특히 Self-hosted LiveSync를 쓰는 입장에서는 “서버 DB가 깨진 건가?”, “노트가 날아간 건가?” 같은 생각부터 듭니다.
이번에는 Obsidian에서 `Initializing database has been failed on some module!`이라는 오류가 나타났습니다. 문장만 보면 데이터베이스 초기화 실패입니다. 비개발자인 김부장 눈에는 거의 빨간불처럼 보였습니다. 그런데 AI와 함께 확인해 보니 서버를 바로 갈아엎을 문제가 아니라, 먼저 “어디의 DB가 문제인가”를 구분해야 하는 상황이었습니다.
CouchDB가 죽은 줄 알았다
처음에는 당연히 홈서버의 CouchDB부터 의심했습니다. LiveSync는 결국 CouchDB와 연결되니 컨테이너가 죽었거나, 인증이 풀렸거나, DB가 사라졌을 수 있다고 생각했습니다.
AI는 삭제나 초기화부터 권하지 않고 서버 상태를 먼저 읽었습니다. 컨테이너가 실행 중인지, CouchDB가 응답하는지, 인증했을 때 실제 DB가 보이는지를 차례로 확인했습니다. 결과는 의외로 정상이었습니다. 컨테이너는 살아 있었고, 인증 후 DB 조회도 HTTP 200으로 응답했습니다. 문서 수도 확인됐습니다.
여기서 배운 첫 번째는 동기화 오류라고 해서 서버부터 고치면 안 된다는 점이었습니다. 서버가 정상인데 서버 DB를 리셋하거나 다시 만들면 문제를 해결하기는커녕 더 크게 만들 수도 있습니다.
LiveSync 설정 파일을 봐도 확신이 서지 않았다
다음으로 Obsidian 보관함 안의 LiveSync 플러그인 설정을 확인했습니다. 플러그인이 켜져 있는지, 버전은 무엇인지, `data.json`에 동기화 설정이 남아 있는지를 살펴봤습니다.
여기서도 중요한 점이 있었습니다. 최신 LiveSync는 예전처럼 위쪽 필드 몇 개만 보고 판단하기 어렵고, `remoteConfigurations` 같은 구조 안에 실제 연결 정보가 들어갈 수 있었습니다. AI는 비밀번호 같은 값은 출력하지 않고 값의 존재 여부, 활성 설정, 암호화 여부처럼 진단에 필요한 정보만 확인했습니다.
예전 같으면 빈 필드 하나를 보고 “설정이 날아갔나 보다”라고 생각했을 겁니다. 하지만 설정 구조가 바뀔 수 있다는 점까지 함께 보니 성급한 결론을 피할 수 있었습니다.
문제는 원격 DB가 아니라 로컬 IndexedDB 쪽이었다
결정적인 단서는 Obsidian의 로컬 캐시였습니다. Obsidian은 앱 안에서 IndexedDB를 사용하고, LiveSync도 로컬 DB 상태와 맞물려 움직입니다. 서버는 정상인데 앱 초기화 단계에서 계속 실패한다면 로컬 캐시가 꼬였을 가능성도 살펴봐야 했습니다.
그렇다고 바로 지우지는 않았습니다. 먼저 Obsidian 프로세스가 실제로 종료됐는지 확인했습니다. 한 번은 프로세스 확인 방식 때문에 실행 중인 것처럼 보여 작업을 멈췄고, 더 정확한 방법으로 다시 확인했습니다. 그다음 기존 IndexedDB 폴더를 삭제하지 않고 백업용 이름으로 옮겼습니다. LiveSync 설정 파일도 따로 백업했습니다.
이 순서가 마음에 들었습니다. 비개발자는 “고친다”는 말에도 겁이 나는데, 이번 작업은 없애는 것이 아니라 되돌릴 수 있게 옮기는 방식이었습니다.
AI와 함께 확인한 해결 순서
확인 과정은 다음과 같았습니다.
1. CouchDB 컨테이너 실행 상태 확인
2. 인증 전후의 접근 결과 구분
3. Obsidian LiveSync 플러그인 활성화와 설정 구조 확인
4. 원격 DB가 정상이라는 근거를 확인한 뒤 로컬 IndexedDB 캐시 점검
5. Obsidian 종료 여부 확인
6. 로컬 IndexedDB를 백업 폴더로 이동
7. LiveSync 설정 파일 별도 백업
8. Obsidian을 다시 실행해 IndexedDB가 새로 생성되는지 확인
마지막에는 Obsidian 창이 다시 열리고 새 IndexedDB 폴더가 만들어지는 것까지 확인했습니다. 최종 동기화 완료 여부는 사용자가 직접 눈으로 확인해야 했지만, 적어도 서버 DB를 건드리지 않고 로컬 초기화 단계의 병목을 풀어낸 셈입니다.
비개발자 김부장이 배운 점
이번 일에서 가장 크게 배운 것은 오류 문구에 나온 단어를 너무 크게 해석하지 않는 것입니다. “database failed”라고 적혀 있어도 그 데이터베이스가 서버의 CouchDB인지, Obsidian 앱의 로컬 IndexedDB인지, 플러그인 내부 초기화 단계인지는 따로 확인해야 했습니다.
또 하나는 백업하는 방식입니다. 예전에는 문제가 생기면 검색해서 나온 명령을 그대로 따라 하거나 초기화 버튼부터 누르고 싶어졌습니다. 지금은 AI에게 “먼저 읽어봐”, “비밀값은 출력하지 말고 상태만 봐”, “삭제하지 말고 백업해”라고 요청하는 쪽으로 바뀌고 있습니다.
이게 제가 말하는 바이브코딩의 현실적인 장점 같습니다. 코드를 모두 외우는 것이 아니라, 겁나는 상황에서 확인 순서를 세우고 위험한 버튼을 누르기 전에 멈추는 힘이 생기는 것입니다.
다음 편에서는 홈서버나 업무 자동화에서 성공처럼 보이는 로그를 어디까지 믿어야 하는지, 실제 검증 기준을 잡았던 기록을 이어가 보겠습니다.