먼저 결론부터. Claude Desktop 업데이트가 “실행 파일이 이미 사용 중”에서 멈추고 앱까지 뜨지 않는다면, 대개 앱 프로세스는 이미 종료된 상태다. 남아서 발목을 잡는 것은 프로세스가 아니라, 구 버전 MSIX 컨테이너의 Job 객체가 svchost.exe 아래에 좀비로 남은 것이다. 이걸 모르면 작업 관리자에서 아무리 프로세스를 죽여도, 앱을 다시 설치해도 증상이 반복된다.

이 글은 그 증상을 실제로 겪고 원인을 특정한 진단 기록이다. 성급한 재설치나 강제 종료로 상황을 더 꼬이게 만들기 전에, 무엇을 확인하고 무엇을 건드리지 말아야 하는지 순서대로 정리한다.

/ 01 — 증상

업데이트를 눌렀는데, 앱이 사라졌다

패턴은 이렇게 진행된다. 업데이트를 적용하려고 앱을 재시작한다. 그런데 설치 과정에서 실행 파일이 사용 중이라는 경고가 뜨고 업데이트가 완료되지 못한다. 이후 앱을 다시 켜려 하면, 이번엔 아예 시작 자체가 되지 않는다.

여기서 많은 사람이 자연스럽게 밟는 수순이 있다. 작업 관리자를 열어 Claude가 붙은 프로세스를 전부 끝낸다. 그리고 다시 실행한다. 그런데 여전히 같은 증상이다. 이 지점에서 원인을 프로세스로 계속 의심하면 답이 나오지 않는다. 프로세스는 이미 문제의 원인이 아니기 때문이다.

/ 02 — 오진

프로세스 목록은 비어 있는데 잠겨 있다

정확히 확인하려면 추측을 멈추고 실제 상태를 봐야 한다. 관리자 권한 PowerShell에서 두 가지를 확인한다. 하나는 현재 살아 있는 Claude 프로세스, 다른 하나는 파일·객체를 붙잡고 있는 핸들이다. 핸들 확인에는 Sysinternals의 handle.exe를 쓴다. 작업 관리자나 리소스 모니터보다 커널 객체까지 정확히 드러난다.

# 살아 있는 Claude 프로세스 (앱 본체)
Get-Process *claude* | Select ProcessName, Id, Path

# 무엇이 무엇을 붙잡고 있는가
handle.exe -a claude

확인 · 관리자 PowerShell

여기서 결정적인 장면이 나온다. Get-Process는 빈 출력이었다. 앱 본체는 이미 죽어 있다는 뜻이다. 그런데 handle.exe 출력 맨 위에는 이 한 줄이 살아 있었다.

svchost.exe  pid: 8116  type: Job  710: \Container_Claude_1.15962.1.0_x64__pzs8sxrjxfjjc-...

증거 · 좀비가 된 구 버전 Job 객체

파일 핸들이 아니라 Job 객체다. MSIX 앱은 실행될 때 컨테이너 단위의 Job 객체 안에서 돌아가고, 이 Job이 살아 있는 동안 배포 엔진은 해당 패키지 파일의 교체를 거부한다. 그래서 “실행 파일이 사용 중”이 뜨는 것이다. 붙잡고 있는 실체가 눈에 보이는 앱 창이 아니라 커널의 Job이었을 뿐이다.

노이즈 세 종류를 먼저 버린다. 브라우저의 claude.ai IndexedDB 핸들은 웹세션일 뿐 앱과 무관하고, 워크트리에서 도는 작업 러너는 MSIX 샌드박스 밖이라 잠금과 관계없다. 남는 한 줄, 구 버전 Job이 진짜 원인이다.

/ 03 — 특정

버전이 어긋나 있다는 단서

WindowsApps*Claude* 필터로 좁히면, 살아남은 앱 프로세스가 딱 하나 드러난다. 그리고 여기서 사건의 성격이 확정된다.

Get-Process | ? { $_.Path -like "*WindowsApps*Claude*" } | Select ProcessName, Id, Path

ProcessName   Id   Path
-----------   --   ----
cowork-svc  4408   …\Claude_1.17377.1.0_x64__…\resources\cowork-svc.exe

특정 · 잠금을 붙잡은 단일 프로세스

버전이 엇갈려 있다. 좀비 Job은 구 버전 1.15962인데, 살아남은 프로세스는 신 버전 1.17377 폴더의 cowork-svc.exe다. 업데이트가 신 버전 패키지를 이미 깔아 놓았지만, 구 버전 컨테이너가 내려가지 못해 전환이 완료되지 못한 상태라는 뜻이다. 이 배경 서비스 하나가 마지막 자물쇠였다.

/ 04 — 해제

순서대로, 그러나 마지막 한 칸은 재부팅

붙잡은 프로세스가 특정됐으니 그것부터 내린다. cowork-svc는 앱을 다시 켜면 자동으로 재기동되므로 지금 종료해도 잃는 것이 없다.

Stop-Process -Id 4408 -Force

# 확인 ① Claude 프로세스가 비었는가  -> 빈 출력이어야 정상
Get-Process | ? { $_.Path -like "*WindowsApps*Claude*" }

# 확인 ② 구 버전 Job이 사라졌는가
handle.exe -a Container_Claude

해제 시도 · 1단계

여기서 두 갈래로 나뉜다. 운이 좋으면 Job이 함께 사라지고 상황이 끝난다. 하지만 이번 사례에서는 프로세스가 모두 내려갔는데도 구 버전 Job이 그대로 남았다. 붙잡을 프로세스가 없는데도 커널에 Job 객체만 좀비로 고착된 것이다. 이 상태는 Stop-Process로는 손댈 수 없다.

재부팅으로 넘어가기 전에, 배포 관련 서비스를 재시작해 좀비 Job의 정리를 유도하는 시도를 한 번 해볼 수 있다.

Restart-Service AppXSvc -Force -ErrorAction SilentlyContinue
Get-Service ClipSVC, AppXSvc, StateRepository | Restart-Service -Force -ErrorAction SilentlyContinue

# 신 버전 재등록으로 전환 확정 유도
Get-AppxPackage *Claude* | Foreach {
  Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"
}

handle.exe -a Container_Claude   # 다시 확인

해제 시도 · 2~3단계

이 사례에서는 서비스 재시작과 재등록으로도 Job이 풀리지 않았다. 프로세스 종료 → 서비스 재시작 → 재등록을 모두 소진하고도 커널에 남은 좀비 Job은, 결국 재부팅만이 물리적으로 해제한다.

재부팅은 진단을 건너뛴 만능 처방이 아니다. 잠금 주체를 좀비 Job으로 특정하고, 프로세스 종료·서비스 재시작·재등록을 모두 소진한 뒤에 남는 마지막 물리적 수단으로서의 재부팅이다. 순서를 지켰기에 재부팅이 정당한 결론이 된다.

재부팅 후 마지막으로 한 번만 확인한다. 좀비 Job이 사라졌으면 신 버전 컨테이너로 깨끗하게 전환된 것이고, 앱은 정상적으로 실행된다.

handle.exe -a Container_Claude
# 구 버전(1.15962) 라인이 나오지 않으면 완료

확인 · 재부팅 후

---

독자에게 — 주의할 점

같은 증상을 만났을 때, 상황을 악화시키지 않으려면 이 네 가지를 기억해 두는 편이 좋다.