개인 지식 저장소를 백그라운드에서 계속 맞추는 헤드리스 동기화 클라이언트의 프로세스는 8월 6일부터 살아 있었다. 그런데 로그는 8월 20일 새벽, Disconnected와 Waiting을 거쳐 Connecting에서 멎었다. 프로세스 번호는 남아 있었지만 TCP 소켓은 하나도 없었다. 운영체제의 프로세스 표만 보면 생존, 실제 일은 사흘째 중단이었다.
이런 고장은 화려한 오류를 내지 않는다. 죽은 프로세스라면 서비스 관리자가 다시 띄우기라도 한다. 이번에는 껍데기가 살아 있어서 단순한 “실행 중인가” 검사만 통과했다. 백그라운드 동기화의 건강 상태를 프로세스 존재 하나로 판단하면 안 되는 이유다. 연결이 있는지, 로그가 앞으로 움직이는지, 대기 파일이 줄어드는지를 함께 봐야 한다.
설치된 클라이언트는 0.0.8이었다. 조사 당시 Node 22를 지원하는 고정 버전 0.0.13으로 올리고, 같은 Node ABI에 맞춰 네이티브 SQLite 모듈을 다시 빌드했다. 그 뒤 문제가 난 서비스만 재시작했다. 저장소 내용과 인증 설정, 동기화 설정, 상태 데이터베이스는 초기화하지 않았다. 장애를 고친다는 이유로 정상 상태까지 갈아엎으면 원인과 복구 효과를 구분하기 어려워진다.
새 프로세스가 떴다는 사실도 복구 증거로 삼지 않았다. 밀린 파일이 실제로 업로드됐고, TCP 443 연결이 생겼으며, 로그에 Fully synced가 반복됐다. 상태 데이터베이스에서는 pending_files=0을 확인했다. 프로세스 번호 교체는 조치의 흔적이고, 이 네 가지가 서비스가 다시 일한다는 증거였다.
재발 방지도 무조건 재시작하는 감시자로 만들지 않았다. 실패 표지가 오래 멎은 경우에만 동기화 서비스를 다시 띄우고, 한 번 손댄 뒤에는 30분 동안 냉각 시간을 둔다. 원격 서비스가 잠깐 흔들릴 때마다 로컬 프로세스를 두들겨 패는 감시자는 장애보다 더 시끄러울 수 있다.
Connecting은 진행 상황처럼 보이지만, 시간과 소켓과 대기열이 멈췄다면 그냥 마지막으로 남은 단어다. 살아 있는 PID는 가장 값싼 증거다. 동기화 서비스의 건강은 “떠 있나”가 아니라 “앞으로 가고 있나”로 판정해야 한다.