Claude Desktop 윈도우 샌드박스 함정 — 3일간 명령이 안 먹힌 이유와 해법

Claude Desktop에게 레지스트리를 수정하라고 했더니 "성공했습니다"라고 답했어요. 확인해보니 실제 레지스트리에는 아무것도 바뀌지 않았습니다. 다시 시켰더니 또 성공. 3일 동안 Fable 토큰 몇만 원어치를 태우고 나서야 알았죠. 윈도우 Claude Desktop이 모든 명령을 MSIX 샌드박스 안에 가둬서 실제 시스템은 건드리지 않는다는 걸요. 이 글을 읽으면 같은 함정에 빠지지 않을 수 있습니다. Process Monitor로 문제를 확인하고 Task Scheduler로 우회하는 방법까지 직접 해본 순서대로 정리했어요.

준비물

• Windows 10 또는 11 (MSIX 패키징 지원 버전)
• Claude Desktop 윈도우 버전 (Microsoft Store나 공식 사이트 설치판)
• Process Monitor (Sysinternals Suite, 무료)
• Task Scheduler (윈도우 기본 내장)

Claude Desktop 버전은 설정 > About에서 확인할 수 있어요. 제가 테스트한 건 1.2.3 기준이지만 MSIX 패키징 방식을 쓰는 모든 버전에서 동일한 현상이 나타납니다.

MSIX 샌드박스가 명령을 삼키는 원리

윈도우 Claude Desktop은 MSIX 패키지로 배포돼요. MSIX는 앱을 샌드박스 안에 가두는 패키징 방식입니다. 보안상 좋은 구조지만 ai 에이전트처럼 시스템을 직접 수정하는 도구와는 궁합이 최악이죠.

Claude가 PowerShell로 레지스트리를 수정하면 실제로는 가상 레지스트리 레이어에만 쓰입니다. 레지스트리 키를 바꿔도 패키지 전용 가상 저장소에만 기록되고, 진짜 시스템 하이브는 그대로예요. 파일도 마찬가지입니다. 시스템 폴더에 뭔가 쓰려고 하면 실제론 샌드박스 내부로 우회 저장되죠.

문제는 Claude가 다시 읽을 때예요. 같은 샌드박스 안에서 읽으니까 자기가 쓴 가상 값을 정상적으로 읽어냅니다. 그래서 "수정 완료, 확인했습니다"라고 보고하는 거예요. 시스템 원본은 1바이트도 안 바뀌었는데 말이죠.

Process Monitor로 실체를 확인하는 법

제가 3일 만에 문제를 발견한 건 Process Monitor 덕분이었어요. Sysinternals Suite에 포함된 무료 도구인데 모든 레지스트리·파일 접근을 실시간으로 보여줍니다.

1단계: 트레이스 캡처 시작

Process Monitor를 실행하고 필터를 Process Name is Claude.exe로 설정하세요. Claude Desktop에게 간단한 레지스트리 수정을 시킵니다. 예를 들어 "HKEYCURRENTUSER\Software\TestApp 키에 Version=1.0 값을 추가해줘"라고 요청하는 거죠.

Claude가 "완료했습니다"라고 답하면 Process Monitor를 멈추고 로그를 확인합니다.

2단계: 가상 경로 발견

로그를 보면 실제 HKEY_CURRENT_USER\Software\TestApp이 아니라 HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\TestApp 같은 가상 경로로 쓴 게 보일 거예요. 파일이라면 C:\Users\<사용자>\AppData\Local\Packages\Anthropic.ClaudeDesktop_<해시>\AC\VFS\ProgramFilesX64\ 같은 경로로 리다이렉트됩니다.

3단계: 실제 레지스트리 확인

regedit를 열어서 HKEY_CURRENT_USER\Software\TestApp을 직접 찾아보세요. 없을 겁니다.

이 단계에서 입력은 "Claude에게 레지스트리 수정 요청" → 출력은 "Process Monitor 로그에 가상 경로만 보임, 실제 레지스트리엔 변화 없음"이에요.

Task Scheduler로 샌드박스를 우회하는 법

발견했으니 이제 해결책입니다. MSIX 샌드박스는 끌 수 없어요. 대신 샌드박스 밖에서 명령을 실행하면 됩니다. 저는 Task Scheduler를 썼습니다.

1단계: 스크립트 준비

실제로 실행하고 싶은 PowerShell 명령을 .ps1 파일로 저장하세요. 예를 들어 C:\Scripts\fix-registry.ps1:

New-ItemProperty -Path "HKCU:\Software\TestApp" -Name "Version" -Value "1.0" -PropertyType String -Force

Claude에게 이 스크립트를 만들어달라고 할 수도 있지만 실행은 직접 해야 합니다.

2단계: Task Scheduler 작업 생성

Task Scheduler를 열고 "Create Task"를 클릭하세요. General 탭에서 "Run with highest privileges"를 체크합니다. Actions 탭에서 "Start a program"을 선택하고:

• Program/script: powershell.exe
• Add arguments: -ExecutionPolicy Bypass -File "C:\Scripts\fix-registry.ps1"

Triggers는 "On demand"로 둡니다. 이러면 샌드박스 밖에서 직접 실행할 수 있는 작업이 만들어져요.

3단계: 작업 실행 및 확인

작업을 우클릭해서 "Run"을 누르세요. 그리고 다시 regedit로 확인합니다. 이번엔 HKEY_CURRENT_USER\Software\TestApp에 실제로 값이 생겼을 거예요.

입력: Task Scheduler 작업 실행 → 출력: 실제 레지스트리에 값 생성 확인.

이 방법은 ai 자동화 워크플로우에서 Claude Desktop이 윈도우 시스템을 직접 건드려야 할 때 필수입니다. 매번 수동으로 실행하긴 번거롭지만 적어도 토큰을 낭비하진 않죠.

왜 Claude는 성공했다고 착각할까요?

MSIX 샌드박스는 일종의 투명한 가상 레이어예요. Claude Desktop 프로세스 입장에선 자기가 쓴 레지스트리 키를 다시 읽을 때도 같은 가상 레이어를 봅니다. 그래서 "내가 방금 Version=1.0을 썼고 지금 읽어도 1.0이 나온다. 성공이다"라고 판단하는 거죠.

사람이 직접 regedit나 다른 프로세스로 확인하면 가상 레이어가 아니라 실제 레지스트리를 보게 되니까 당연히 없어요. ai 에이전트가 자기 행동을 자기가 검증하는 구조의 맹점입니다.

이 문제는 ai 코딩 도구 전반의 숙제기도 해요. GitHub Copilot이나 다른 코딩 에이전트도 비슷한 샌드박스 환경에선 같은 함정에 빠질 수 있습니다. 다만 Claude Desktop처럼 MSIX 패키징을 쓰는 윈도우 앱이 특히 심하죠.

흔한 실수와 해결법

제가 3일 동안 저지른 실수들을 정리했어요.

실수 1: 성공 메시지만 믿고 확인 안 함 Claude가 "완료했습니다"라고 하면 당연히 믿고 넘어가죠. 저도 처음 이틀은 "왜 안 되지?"만 반복했어요. 해결책은 간단합니다. 레지스트리 에디터나 파일 탐색기로 직접 확인하세요. ai 도구의 보고를 100% 신뢰하면 안 됩니다.

실수 2: 재설치로 해결하려 함 Claude Desktop을 지웠다 깔아도 소용없어요. MSIX 패키징 구조 자체가 문제니까요. 저는 3번 재설치했습니다. 시간 낭비였죠.

실수 3: 다른 경로로 우회 시도 C:\Temp\ 같은 경로에 쓰면 되지 않을까 싶어서 시도했어요. 안 됩니다. MSIX는 거의 모든 시스템 경로를 가상화하거든요. 샌드박스 밖으로 나갈 수 있는 건 Task Scheduler나 외부 프로세스 호출뿐이에요.

자주 묻는 질문

Q. MSIX 샌드박스를 완전히 끌 수는 없나요? A. 패키지 구조상 불가능합니다. MSIX 앱은 설계상 샌드박스 안에서 실행되도록 만들어졌어요. 끄려면 소스 코드에서 다시 빌드해야 하는데 Claude Desktop은 오픈소스가 아니라 불가능합니다. Task Scheduler나 외부 스크립트로 우회하는 게 유일한 방법이에요.

Q. Mac이나 Linux 버전도 같은 문제가 있나요? A. 없습니다. MSIX는 윈도우 전용 패키징 방식이라 다른 OS는 해당 없어요. macOS 버전은 일반 앱 번들이고 Linux는 AppImage나 deb 패키지라 샌드박스가 훨씬 느슨합니다.

Q. Task Scheduler 말고 다른 우회법은 없나요? A. Python이나 Node.js 같은 외부 런타임으로 별도 프로세스를 띄워도 됩니다. 다만 권한 상승이 필요한 작업은 Task Scheduler가 가장 안정적이에요. Claude에게 Node.js 스크립트를 만들게 하고 수동으로 실행하는 방식도 쓸 만합니다.

다음 행동

Sysinternals Suite를 받아서 압축 풀어두세요. 나중에 비슷한 문제가 생기면 10분 안에 원인을 찾을 수 있습니다.