당시 추정한 원인을 그린 도식입니다. 아래 진단 출력만으로 인과관계가 입증된 것은 아닙니다.

이 사례에서는 눈에 보이는 앱을 종료한 뒤에도 업데이트 오류가 남았다. 구 버전 컨테이너 이름의 Job 핸들을 단서로 조사했지만, 같은 오류가 항상 같은 원인으로 발생하는 것은 아니다. 현재 프로세스, 실제 파일 핸들, 배포 오류 기록을 함께 확인해야 한다.

아래 PID와 버전은 당시 진단 기록의 값이다. 자신의 시스템에 그대로 적용할 명령 목록이 아니라 사례를 읽기 위한 예시로 보아야 한다. 강제 종료나 서비스 변경 전에 현재 대상과 실행 중인 작업부터 확인해야 한다.

/ 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 출력에서는 다음 Job 핸들이 확인됐다.

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

관찰 기록 · 구 버전 이름의 Job 핸들

출력에 나온 것은 파일 핸들이 아니라 Job 객체 핸들이다. Microsoft 문서에 따르면 Job 객체는 연결된 모든 프로세스가 종료되고 마지막 핸들이 닫혀야 삭제된다. 이 핸들의 존재만으로 MSIX 파일 교체 거부 원인을 단정할 수는 없다. 실제 파일 핸들과 배포 이벤트를 대조해야 한다.

브라우저의 IndexedDB 핸들이나 작업 러너가 검색 결과에 섞일 수 있다. 이름이 비슷하다는 이유만으로 종료하거나 원인에서 제외하지 말고, 파일 경로·프로세스·배포 이벤트의 연관성을 확인한다. 당시 구 버전 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

관찰 기록 · 검색 조건에 일치한 프로세스

출력에는 구 버전 1.15962 이름의 Job과 신 버전 1.17377 경로의 cowork-svc.exe가 함께 나타났다. 버전이 혼재한 상태를 조사할 단서지만, 이 프로세스가 해당 Job에 연결되어 있었는지 또는 파일을 잠갔는지는 이 두 출력만으로 알 수 없다.

/ 04 — 해제

당시 복구 시도와 확인할 점

아래 강제 종료 명령은 당시 PID 4408을 대상으로 한 사례 기록이다. 지금의 PID 4408은 다른 프로세스일 수 있으므로 그대로 실행해서는 안 된다. 종료 전 실행 파일 경로와 대상 작업을 확인하고 미저장 내용·진행 중인 출력을 보존한다. 자동 재시작 여부나 데이터 손실이 없다는 보장은 하지 않는다.

Stop-Process -Id 4408 -Force

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

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

해제 시도 · 1단계

당시 기록에서는 프로세스 종료 시도 후에도 구 버전 이름의 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 핸들 검색 결과뿐 아니라 앱 실행, 실제 설치 버전, 배포 오류의 재발 여부를 함께 확인한다. 핸들 한 줄이 사라졌다는 사실만으로 업데이트 완료를 확정하지 않는다.

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

확인 · 재부팅 후

---

독자에게 — 주의할 점

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