dev 서버가 돌고 있는데 worktree 디렉터리가 통째로 사라졌다

이 글은 해결책이 없는 기록이다. 원인을 못 찾았다. 그래도 남겨두는 이유는, 같은 일을 겪은 사람이 “복구할 수 있나”를 빨리 판단하고 헛수고를 줄이길 바라서다.

worktree 에서 vite dev 서버를 띄워놓고 장시간 작업하던 중, 그 디렉터리와 브랜치가 통째로 없어졌다. 두 번 겪었다.

어떻게 보이는가

• 서버 프로세스는 살아 있는데 응답이 404 다.

• /proc/<pid>/cwd 를 확인하면 (deleted) 가 붙어 있다.

  $ ls -l /proc/12345/cwd
  lrwxrwxrwx ... /proc/12345/cwd -> '/home/user/prj/myapp.wt/feature-x (deleted)'

• 새 셸에서 cd <worktree경로> 하면 no such file or directory.

• git worktree list 에 아예 안 뜬다. prune 된 흔적이 아니라 항목 자체가 없다.

• git branch -a 에는 remotes/origin/<브랜치> 만 남고 로컬 브랜치도 사라졌다.

마지막 두 줄이 중요하다. 경로만 깨진 경우와 여기서 갈린다.

원인 — 모른다

재현 조건을 특정하지 못했다. 정황만 적는다.

• 첫 발생 때는 git stash 로 잠깐 clean 상태가 됐던 순간과 겹쳤다. “사용하지 않는 clean worktree 를 자동 정리”하는 백그라운드 동작이 어딘가 있는 게 아닌가 의심했다. 확인은 못 했다.
• 두 번째는 stash 없이도 일어났다. 그러니 stash 는 필요조건이 아니다.

공통점은 worktree 생성 → 장시간 편집·커밋 → 방치라는 흐름뿐이었다. 그 이상 좁히지 못했다.

원인을 모르는 상태에서 예방책을 만들 수는 없다. 그래서 “언제든 사라질 수 있다”를 전제로 운용 방식을 바꿨다.

대응 원칙

1. 커밋은 자주, push 는 더 자주

로컬에만 있는 변경은 worktree 가 사라지면 100% 유실된다. 복구 경로가 없다. 열려 있던 프로세스의 파일 디스크립터로 뭔가 건질 수 있지 않을까 싶겠지만, 그 프로세스가 죽으면 그것도 끝이다.

첫 발생 때는 진행 중이던 미커밋 변경을 전부 잃었다. 두 번째는 이미 push 해둔 상태라 실질 피해가 없었다. 이 차이가 전부다.

2. 복구를 시도하지 말고 판별부터 한다

worktree 가 안 열릴 때 흔한 원인은 경로만 깨진 경우다. 디렉터리를 옮겼거나 .git 파일의 gitdir 포인터가 어긋난 상황이고, 그건 포인터를 고쳐 복구된다.

이 사고는 다르다. gitdir 포인터 문제가 아니라 worktree 항목 자체의 소멸이다. 복구 절차가 통하지 않는다.

판별은 간단하다.

확인	경로만 깨짐	이 사고
디렉터리 존재	있음	없음
git worktree list	항목 있음 (경로가 틀림)	항목 없음
로컬 브랜치	남아 있음	사라짐

오른쪽 열이면 복구 시도는 시간 낭비다. 새로 만드는 게 빠르다.

3. 재구성 절차

마지막 push 이후의 변경은 대화 기록이나 메모에서 손으로 되살리는 수밖에 없다.

1. 새 이름으로 worktree 를 다시 만든다
2. 의존성을 재설치한다
3. 직전까지의 변경을 하나씩 다시 적용한다
4. typecheck 와 grep 으로 원본과 같아졌는지 검증한다

4번을 건너뛰면 안 된다. 기억에 의존한 재구성은 한두 개씩 빠진다.

4. 자리를 비우기 전에 push

세션을 오래 방치할 걸 알고 있다면 — 자리를 뜨거나, 다른 일로 넘어가거나 — 그 직전에 push 한다. 두 번 다 방치 구간에서 일어났다. 원인은 몰라도 타이밍의 상관관계는 있었다.

정리

원인 불명 사고에 대한 대응은 결국 손실 범위를 줄이는 것뿐이다. push 주기를 짧게 가져가면 이 사고의 피해가 “몇 분 작업 재구성”으로 줄어든다.

worktree 를 여러 개 굴리는 환경 자체를 어떻게 세팅했는지는 worktree 기반 dev 서버 전략에 정리해뒀다.