Windows Sandbox로 앱 검증을 빠르게 하는 방법

Windows 앱 개발에서 검증이 느려지는 이유는 대개 비슷합니다.

• 로컬 개발 PC가 지저분해져서, 처음 설치 문제가 재현되지 않는다
• 고객 환경에서는 생기는데, 내 PC에서는 생기지 않는다
• “관리자로 실행하면 동작한다”만 있고, 실제로 필요한 권한 경계가 보이지 않는다
• 권한이나 의존이 부족할 때의 동작을 시험하고 싶지만, 평소 환경을 깨고 싶지 않다
• 저메모리나 GPU 없음에 가까운 상태에서 죽는데, 매번 풀 VM을 세울 정도는 아니다

이럴 때 Windows Sandbox는 꽤 쓰기 편합니다.

풀 VM만큼 무겁지 않고 시작이 빠르며, 닫으면 매번 깨끗이 사라지므로 “같은 Windows 빌드에서, 클린한 검증 환경을 몇 분 만에 다시 만들고 싶다” 는 요구와 잘 맞기 때문입니다.

다만 생각 없이 매번 빈 Sandbox만 열면, 효율은 그만큼 오르지 않습니다. 실무에서 실제로 효과가 나는 운영은 검증 시나리오마다 .wsb를 고정하고, 읽기 전용 입력 폴더와 쓰기 전용 수집 폴더를 나누며, 관리자 계열·표준 사용자 계열·제한된 계열을 구분해 쓰는 방식입니다.

이 글에서는 그 방법을 Windows 앱 개발 관점에 맞춰 정리합니다. 내용은 2026년 4월 시점에서 확인할 수 있는 Microsoft 공식 정보를 전제로 합니다.

이 글의 전제

이 글에서 쓰는 용어

영어 그대로 나오는 용어를 먼저 정리합니다.

목차

• 먼저 결론
• 왜 Windows Sandbox가 개발 검증과 잘 맞는가
• 먼저 알아 둘 제약
• 미리 만들어 두면 빠른 디렉터리 구성
• 클린 환경 스모크 테스트를 더블클릭 한 번으로 만들기
• 관리자 권한 문제의 원인을 분리하는 절차
• 권한이나 의존이 부족한 상태를 의도적으로 만들기
• 리소스가 부족한 쪽에 가까운 환경 만들기
• Windows 11 24H2 이후는 CLI로도 돌리기 쉽다
• 운영에서 빼지 말아야 할 주의점
• 정리
• 관련 기사
• 참고 자료

이 글의 지식 맵

Windows 샌드박스는 Windows Pro/Enterprise/Education 계열에서만 사용할 수 있으며, .wsb 구성 파일로 MappedFolders·Networking·VGpu·MemoryInMB 등을 고정하면 같은 조건의 검증 환경을 원클릭으로 다시 만들 수 있습니다. 기본 로그온 세션은 컨테이너 사용자가 관리자 계정이어야 한다고 되어 있어 표준 사용자 검증에는 적합하지 않으므로, Sandbox 안에 로컬 사용자를 만들고 runas로 시작하는 기법으로 보완합니다. MemoryInMB나 VGpu를 줄이면 저메모리·GPU 없음에 가까운 검증을 할 수 있는 한편, write 권한을 붙인 공유 폴더의 변경은 Sandbox를 닫아도 호스트 쪽에 남으므로 입력은 read-only, 출력만 read-write로 나누는 것이 안전합니다. 다른 OS 버전의 재현이나 여러 개를 동시에 시작, CPU 쿼터의 엄격한 제어가 필요한 검증에는 풀 VM이 더 적합하며, Windows 11 24H2 이후의 CLI도 완전한 headless 자동 시험 기반으로 너무 기대하지 않는 편이 좋습니다.

flowchart LR
    accTitle: Windows 샌드박스를 이용한 앱 검증의 지식 맵
    accDescr: Windows 샌드박스가 Pro/Enterprise 계열 에디션에서 사용할 수 있고 깨끗한 검증 환경을 .wsb 구성 파일이나 CLI로 고정할 수 있다는 점, 기본 세션이 표준 사용자 검증에 적합하지 않아 로컬 사용자와 runas로 보완하는 기법, 저리소스 검증이나 풀 VM이 필요한 장면과의 구분을 보여주는 그림
    windows_sandbox["Windows 샌드박스"]
    wsb_configuration_file[".wsb 구성 파일"]
    pro_edition["Windows Pro/Enterprise 계열 에디션"]
    home_edition["Windows Home 에디션"]
    windows_sandbox_cli["Windows 샌드박스 CLI(wsb 명령)"]
    wsb_mapped_folder["MappedFolders(공유 폴더)"]
    wsb_networking_option["Networking 설정(.wsb)"]
    wsb_clipboard_option["ClipboardRedirection 설정(.wsb)"]
    wsb_vgpu_option["VGpu 설정(.wsb)"]
    wsb_memory_option["MemoryInMB 설정(.wsb)"]
    wsb_protectedclient_option["ProtectedClient 설정(.wsb)"]
    admin_rights["관리자 권한"]
    sandbox_default_logon_session["기본 Sandbox 로그온 세션"]
    standard_user_simulation["표준 사용자 검증(Sandbox 내 재현)"]
    local_account["로컬 계정"]
    runas_command["runas 명령"]
    low_resource_validation["저리소스 검증(저메모리·GPU 없음 위주)"]
    hyper_v_full_vm["풀 VM(Hyper-V 등)"]
    vm_only_validation_scenario["전체 VM 필요 검증(다른 OS·다중 기동·엄격한 리소스 제한)"]
    host_write_back_risk["호스트에 대한 쓰기 잔류 리스크"]
    group_policy["그룹 정책"]
    headless_ci_automation["완전 headless CI 자동 시험 기반"]
    windows_sandbox -->|"전제로 한다"| pro_edition
    windows_sandbox -->|"양립하지 않는다"| home_edition
    windows_sandbox -->|"에서 구성할 수 있다"| wsb_configuration_file
    windows_sandbox -.->|"에서 구성할 수 있다"| windows_sandbox_cli
    wsb_configuration_file -->|"이용한다"| wsb_mapped_folder
    wsb_configuration_file -->|"이용한다"| wsb_networking_option
    wsb_configuration_file -->|"이용한다"| wsb_clipboard_option
    wsb_configuration_file -->|"이용한다"| wsb_vgpu_option
    wsb_configuration_file -->|"이용한다"| wsb_memory_option
    wsb_configuration_file -->|"이용한다"| wsb_protectedclient_option
    admin_rights -->|"에서 확인할 수 있다"| windows_sandbox
    sandbox_default_logon_session -->|"사용은 비권장"| standard_user_simulation
    standard_user_simulation -->|"이용한다"| local_account
    standard_user_simulation -->|"이용한다"| runas_command
    low_resource_validation -->|"이용한다"| wsb_memory_option
    low_resource_validation -->|"이용한다"| wsb_vgpu_option
    hyper_v_full_vm -->|"권장되는 대응"| vm_only_validation_scenario
    windows_sandbox -->|"사용은 비권장"| vm_only_validation_scenario
    wsb_mapped_folder -.->|"원인이 될 수 있다"| host_write_back_risk
    group_policy -.->|"양립하지 않는다"| wsb_configuration_file
    windows_sandbox_cli -->|"사용은 비권장"| headless_ci_automation
    windows_sandbox -->|"이용한다"| sandbox_default_logon_session

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 22건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

먼저 결론

결론부터 나열합니다.

• Windows Sandbox는 클린 환경 재현, 처음 설치 확인, 관리자 권한 문제의 원인 분리, 의존 부족을 찾아내는 작업에 맞습니다.
• GUI에서 매번 손으로 하기보다 용도마다 .wsb를 나누는 편이 빠릅니다.
• 호스트 공유는 입력은 read-only, 출력만 read-write로 나누면 사고가 줄어듭니다.
• 기본 Sandbox 세션은 표준 사용자 검증에 그대로 쓰기 어렵습니다. 표준 사용자 검증을 하려면 Sandbox 안에 다른 사용자를 만들고 그 사용자로 실행합니다.
• 메모리 부족이나 GPU 없음에 가까운 재현에는 .wsb의 MemoryInMB와 VGpu(가상 GPU 공유) 끄기가 효과가 있습니다.
• 다만 CPU 쿼터, 디스크 부족, 여러 인스턴스 동시 실행, 다른 OS 버전 재현까지 하려면 Windows Sandbox보다 풀 VM이 더 맞습니다.

즉 Windows Sandbox는 “가볍지만 일회용”“빠르지만 같은 OS 계통”“한정적이지만 실무에는 충분하다” 는 검증 환경입니다. 이 위치를 먼저 이해해 두면 쓸 곳을 잘못 고르지 않습니다.

왜 Windows Sandbox가 개발 검증과 잘 맞는가

Windows Sandbox가 Windows 앱 개발과 잘 맞는 이유는 네 가지입니다.

닫으면 매번 리셋된다

이것이 가장 큽니다.

설치 프로그램을 여러 번 시험하고, 설정을 깨고, 레지스트리를 건드리고, 선행 구성 요소를 넣었다 지웠다 합니다. 이런 작업을 개발 PC 본체에서 하면, 점점 “무엇이 들어 있는지 모르는 환경”이 됩니다.

Sandbox는 닫으면 전부 사라집니다. 그래서 처음 설치 때만 생기는 문제나 선행 구성 요소가 우연히 로컬에 있어서 보이지 않는 문제를 찾기 쉬워집니다.

같은 Windows 계통의 깨끗한 환경을 바로 만들 수 있다

Windows Sandbox는 호스트와 같은 계통의 Windows 빌드를 쓰는 전제입니다. 제약이기도 하지만, 반대로 말하면 로컬 Windows 11과 같은 계통의 클린 환경을 바로 만들 수 있다는 뜻이기도 합니다.

“고객도 Windows 11 24H2, 이쪽도 Windows 11 24H2”라면 꽤 다루기 쉽습니다.

풀 VM보다 가볍고 관리 비용이 낮다

Hyper-V나 VMware의 풀 VM은 강력하지만, 매번 용도가

• 설치 절차 확인
• UAC가 뜨는 방식 확인
• 권한 부족 시 오류 확인
• 의존 부족 시 로그 확인
• 클린 환경 스모크 테스트

정도라면 다소 무거운 경우도 많습니다.

Windows Sandbox는 OS 이미지 관리나 스냅샷 운영을 그만큼 끌어오지 않아도 되므로, “잠깐 재현하고 싶다”는 검증을 진행하기 쉽다는 점이 강점입니다.

.wsb와 CLI로 시나리오를 고정할 수 있다

Sandbox의 진가는 단순히 “안전하게 시험할 수 있다”보다 같은 조건으로 몇 번이든 다시 할 수 있다는 데 있습니다.

• 네트워크 있음 / 없음
• 공유 폴더 read-only / read-write
• 저메모리
• GPU 공유 없음
• 클립보드 공유 없음
• 시작 시 특정 스크립트 실행

이 부분을 .wsb나 Windows 11 24H2 이후 CLI로 고정하면, 검증이 “그때그때 하는 작업”에서 “반복할 수 있는 절차”로 바뀝니다.

먼저 알아 둘 제약

편리하지만 맞지 않는 일도 있습니다. 여기는 먼저 잡아 두는 편이 좋습니다.

쓸 수 있는 에디션에 제약이 있다

Windows Sandbox는 Windows Pro / Enterprise / Education 계열에서 사용할 수 있습니다. Home 에디션에서는 사용할 수 없습니다.

사내 개발 PC는 Pro여도, 영업용 PC나 개인 PC는 Home인 경우가 있어 거기서 막히기 쉽습니다.

가상화 요건이 있다

쓰려면 가상화 기능이 켜져 있고, 일정 이상의 RAM / 디스크 / CPU 코어가 있어야 합니다. 가볍다고 해도 공짜는 아닙니다.

Sandbox는 호스트와 같은 OS 계통이 된다

실무에서 꽤 중요합니다.

Windows Sandbox는 다른 OS 버전 검증에는 맞지 않습니다.

• 호스트가 Windows 11이면 Windows 10 재현 환경이 되지 않는다
• 고객이 옛 빌드를 쓰면 그 차이는 메우지 못한다

그래서 다른 OS 판 호환성 검증이나 옛 빌드에 묶인 문제는 처음부터 풀 VM을 고르는 편이 좋습니다.

동시에 여러 개를 시작할 수 없다

현재 Windows Sandbox는 인스턴스를 동시에 여러 개 돌리는 운영에는 맞지 않습니다.

테스트 매트릭스를 병렬로 돌리고 싶다면 Hyper-V 등이 자연스럽습니다.

기본값으로 네트워크와 클립보드가 켜져 있다

놓치기 쉬운 부분입니다.

Windows Sandbox는 기본으로 네트워크 연결이 켜져 있습니다. 클립보드 공유도 기본으로 켜져 있습니다.

즉 생각 없이 시작하면 “완전히 닫힌 세계”가 아닙니다. 출처가 불분명한 파일을 확인하거나 의존 부족을 재현할 때는 처음부터 .wsb로 명시해 제어하는 편이 안전합니다.

Windows 11 24H2 이후에는 일부 inbox 앱을 쓸 수 없다

Windows 11 24H2 이후 Sandbox에서는 메모장, 터미널, 계산기, 사진 등 일부 inbox Store 앱을 쓸 수 없습니다.

그래서 시작 시 자동화나 보조 조작은 cmd.exe, powershell.exe, explorer.exe를 전제로 짜는 편이 무난합니다.

미리 만들어 두면 빠른 디렉터리 구성

매번 그 자리에서 공유 폴더를 정하기보다, 처음에 검증용 위치를 한 곳만 만들어 두면 훨씬 편합니다.

예를 들면 이런 구성입니다.

C:\SandboxFixtures\
├─ AppUnderTest\
│  ├─ MyAppInstaller.msi
│  ├─ MyApp.exe
│  └─ sample-data\
├─ Scripts\
│  └─ Prep-StandardUser.ps1
├─ Outbox\
├─ 00-clean-smoke.wsb
├─ 10-standard-user.wsb
├─ 20-restricted-runtime.wsb
└─ 30-low-resource.wsb

역할은 이렇게 나눕니다.

• AppUnderTest: 검증 대상. read-only 공유
• Scripts: 시작 시 스크립트. read-only 공유
• Outbox: 로그, 덤프, 내보내기 결과. read-write 공유

이렇게 나누면 Sandbox 쪽에서 호스트에 쓸 수 있는 곳이 Outbox로 한정되므로 꽤 안전합니다.

추가로 .wsb도 시나리오별로 고정합니다.

이것만으로 검증을 시작하는 비용이 꽤 내려갑니다.

클린 환경 스모크 테스트를 더블클릭 한 번으로 만들기

먼저 만들어 두고 싶은 것은 클린 환경 스모크 테스트용 Sandbox입니다.

예: 00-clean-smoke.wsb

<Configuration>
  <Networking>Disable</Networking>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

이 용도에서 잡을 점은 다음 네 가지입니다.

• 배포물은 AppUnderTest에 둔다
• 그 폴더는 read-only로 보여 준다
• 로그와 결과만 Outbox에 쓴다
• 네트워크 의존을 보고 싶지 않으면 처음부터 끊는다

이렇게 하면 배포물만 갈아 끼우고 .wsb를 더블클릭하는 것만으로, 매번 깨끗한 첫 검증을 할 수 있습니다.

무엇이 보이면 성공인가

처음 쓸 때 가장 알기 어려운 것은 “어디까지 가면 성공인가”입니다. 확인 관점을 나열합니다.

.wsb를 더블클릭하면 호스트와는 다른 데스크톱이 창 하나로 열립니다. 안은 초기 상태 Windows이고, 기본 배경과 빈 데스크톱이 나옵니다. 호스트 배경, 설치된 앱, 로그온 중인 계정은 이어받지 않습니다. 여기까지 오면 시작 자체는 성공입니다.

이어서 LogonCommand에 적은 명령이 실행됩니다. 위의 00-clean-smoke.wsb라면 Sandbox 안에서 파일 탐색기가 열리고 C:\Work\AppUnderTest 내용이 보이는 상태가 됩니다.

의도한 구성으로 시작됐는지는 Sandbox 안에서 명령을 실행하면 확실히 알 수 있습니다. Sandbox 안 시작 메뉴에서 powershell.exe를 열고 다음을 순서대로 실행합니다.

# 1) 공유 폴더가 의도한 위치에 보이는지
Get-ChildItem C:\Work

# 2) 입력 쪽은 읽기 전용이어야 한다. 오류가 나면 의도대로다
New-Item -Path C:\Work\AppUnderTest\write-test.txt -ItemType File

# 3) 출력 쪽은 쓸 수 있어야 한다. 성공하면 의도대로다
New-Item -Path C:\Work\Outbox\write-test.txt -ItemType File

# 4) 네트워크를 끊은 셈이면 통신은 실패해야 한다
Test-NetConnection -ComputerName www.microsoft.com -Port 443

# 5) 지금 누구로 동작 중인지. 기본 세션에서는 관리자 계정
whoami
whoami /groups

3의 write-test.txt는 호스트 쪽 C:\SandboxFixtures\Outbox에도 나타납니다. 여기가 보이면 로그나 덤프를 수집하는 경로가 통해 있다는 확인이 됩니다.

잘 안 되면 다음 순서로 봅니다.

• 더블클릭해도 아무 일도 없거나 오류가 난다 → .wsb XML이 깨져 있을 수 있습니다. 요소 이름은 Microsoft Learn 구성 파일 문서의 표기에 맞추세요.
• C:\Work에 아무것도 없다 → HostFolder에 지정한 호스트 쪽 경로가 없습니다. 공유 폴더 지정은 호스트에 실제로 있는 경로여야 합니다.
• 시작 메뉴에 “Windows Sandbox”가 없다 → 전제 조건을 충족하지 않았거나 Windows 기능이 켜져 있지 않습니다. 이 글 전제 표를 확인하세요.

이 단계에서 잘 보이는 문제

이 단계에서는 이런 문제가 자주 나옵니다.

• 개발 PC에는 있던 선행 DLL / runtime이 프로덕션에는 없다
• WebView2나 VC++ 재배포 패키지 전제가 암묵적이다
• 첫 시작 때만 만들어지는 디렉터리나 설정 파일의 생성 위치가 나쁘다
• Program Files 아래에 실행 중 데이터를 쓰려다 죽는다
• “개발자 로컬에는 들어 있던” 인증서·글꼴·설정이 전제로 되어 있다

핵심은 Sandbox 쪽에서 생긴 일을 반드시 Outbox로 내보내는 것입니다. 닫는 순간 전부 사라지므로 로그도 덤프도 그 자리에 남겨 두면 안 됩니다.

네트워크 있음 버전도 별도 파일로 둔다

대상이 Web installer나 온라인 인증이 있는 앱이면, 네트워크를 끊은 채로 두면 다른 문제만 보입니다.

그때는 같은 구성으로 01-clean-online.wsb처럼 별도 파일을 만들고 “오프라인 전제 재현”과 “온라인 전제 재현”을 섞지 않는 편이 정리하기 쉽습니다.

관리자 권한 문제의 원인을 분리하는 절차

Windows 앱 개발에서는 관리자 권한 이야기가 꽤 섞입니다.

• 설치 때만 필요한가
• 실행 시까지 필요한가
• 일부 설정 변경만 필요한가
• 실은 저장 위치가 나쁠 뿐인가

이 이야기 자체는 이전에 쓴 다음 글에서 정리했습니다.

• Windows의 관리자 특권이 필요해지는 때는 언제인가 - UAC, 보호 영역, 설계상의 구별법
• Windows 앱에서 “관리자 권한이 필요한 처리만”을 분리하는 구체적인 작성법

여기서는 Sandbox를 써서 검증을 어떻게 빠르게 할지에 초점을 둡니다.

먼저 볼 관점

Sandbox에서 먼저 확인하고 싶은 것은 다음 같은 경계입니다.

• 설치 프로그램이 Program Files나 HKLM에 쓰는가
• 서비스 등록, 드라이버 도입, 방화벽 설정 변경이 있는가
• updater가 machine-wide로 바꾸려 하는가
• 실행 시 설정, 로그, 캐시를 보호 영역에 쓰려 하지 않는가
• Shell Extension이나 COM 등록 같은 OS 통합이 있는가

즉 “정말로 관리자가 필요한 처리”와 “실행 시 위치가 나쁠 뿐인 처리”를 나누는 것이 목적입니다.

Sandbox 기본 상태만으로는 표준 사용자 검증이 되지 않는다

여기는 중요합니다.

Windows Sandbox의 로그온 명령은 컨테이너의 사용자 계정으로 동작합니다. Microsoft Learn 설명에서도 그 컨테이너 사용자는 관리자 계정이어야 한다고 되어 있습니다.

즉 기본 Sandbox 세션은 “표준 사용자에서의 재현”에 그대로 쓰기 어렵습니다.

관리자 권한 문제의 원인을 제대로 분리하려면 Sandbox 안에 별도의 표준 사용자를 만들고, 그 사용자로 앱을 실행하는 편이 정리하기 쉽습니다.

예: 10-standard-user.wsb

<Configuration>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Scripts</HostFolder>
      <SandboxFolder>C:\Work\Scripts</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>powershell.exe -NoExit -ExecutionPolicy Bypass -File C:\Work\Scripts\Prep-StandardUser.ps1</Command>
  </LogonCommand>
</Configuration>

예: Prep-StandardUser.ps1

$UserName = 'wsbuser'
$Password = 'P@ssw0rd-For-Test-Only!'

$existing = Get-LocalUser -Name $UserName -ErrorAction SilentlyContinue
if (-not $existing) {
    $secure = ConvertTo-SecureString $Password -AsPlainText -Force
    New-LocalUser -Name $UserName -Password $secure -AccountNeverExpires | Out-Null
}

try {
    Remove-LocalGroupMember -Group 'Administrators' -Member $UserName -ErrorAction Stop
}
catch {
}

try {
    Add-LocalGroupMember -Group 'Users' -Member $UserName -ErrorAction Stop
}
catch {
}

Write-Host ''
Write-Host 'Standard user has been prepared.'
Write-Host "User     : $UserName"
Write-Host "Password : $Password"
Write-Host ''
Write-Host 'Run your app as the standard user with:'
Write-Host 'runas /user:wsbuser "C:\Work\AppUnderTest\MyApp.exe"'
Write-Host ''

Start-Process explorer.exe 'C:\Work\AppUnderTest'

이 구성으로 두면 Sandbox를 시작한 시점에 표준 사용자가 준비되어 있으므로, 그대로 이렇게 시험할 수 있습니다.

runas /user:wsbuser "C:\Work\AppUnderTest\MyApp.exe"

이렇게 하면 무엇이 보이는가

이 방법이면 이런 문제가 보이기 쉬워집니다.

• 실행 시 설정을 EXE 옆에 저장해서 실패한다
• HKLM에 쓰려다 실패한다
• updater가 machine-wide 전제이다
• 로그 저장 위치가 Program Files 아래이다
• 버튼 하나만 관리자가 필요한데 앱 전체를 승격 전제로 한다

관리자 권한 문제는 코드 리뷰만으로 알 수 있는 경우도 있습니다. 다만 “실제로 표준 사용자로 실행하면 어디서 막히는가” 를 눈으로 보면 설계상 경계가 꽤 분명해집니다.

권한이나 의존이 부족한 상태를 의도적으로 만들기

“관리자가 아니다”만이 아니라 환경 쪽 편의를 일부러 일부 없애면 숨은 의존이 보입니다.

예: 20-restricted-runtime.wsb

<Configuration>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <PrinterRedirection>Disable</PrinterRedirection>
  <ProtectedClient>Enable</ProtectedClient>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

이 프로필에서 보고 싶은 것

이 제한 프로필이 맞는 확인은 다음입니다.

• 네트워크가 없으면 시작하지 못하는 hidden dependency가 없는지
• 클립보드로 파일을 넣는 전제가 되어 있지 않은지
• 기본 프린터가 보이는 전제로 UI나 양식 처리를 쓰지 않았는지
• RDP 세션 너머에서도 대충 성립하던 조작에 불필요한 의존이 없는지
• 공유 폴더에 자유롭게 쓸 수 있다는 전제의 대충 구현이 없는지

특히 업무 앱에서는 “로컬에서는 평범하게 됐다”가, 현장 PC에서는

• 네트워크 제한 있음
• 클립보드 제한 있음
• 프린터 없음
• 공유 폴더 쓰기 제한 있음

인 경우가 많습니다.

Sandbox에서 먼저 그 세계에 가깝게 맞춰 두면, 나중에 문의로 막히기 어렵습니다.

공유 폴더는 넓게 보여 주지 않는다

여기도 꽤 중요합니다.

Sandbox의 mapped folder는 편리하지만, write 권한을 준 공유 폴더의 변경은 Sandbox를 닫아도 호스트에 남습니다.

그래서 이런 공유는 피하는 편이 안전합니다.

• C:\Users를 통째로 공유
• 리포지터리 전체를 write로 보여 주기
• Downloads나 Documents를 대충 write 공유하기

기본은

• 입력물은 좁은 폴더로 read-only
• 출력물만 전용 Outbox에 read-write

의 두 단계로 나누는 것을 권합니다.

리소스가 부족한 쪽에 가까운 환경 만들기

Windows Sandbox는 리소스 제어의 자유도는 높지 않습니다. 그래도 “가볍게 리소스를 줄인 검증” 에는 쓸 수 있습니다.

예: 30-low-resource.wsb

<Configuration>
  <VGpu>Disable</VGpu>
  <MemoryInMB>2048</MemoryInMB>
  <Networking>Disable</Networking>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

이렇게 하면 잘 드러나는 문제

이 프로필이면 이런 문제가 겉으로 나오기 쉽습니다.

• 시작 시 메모리를 너무 많이 쓴다
• 큰 파일을 읽을 때 메모리 여유를 보지 않는다
• GPU 공유가 없으면 그리기가 극단적으로 무거워진다
• WPF / WebView2 / 이미지 처리 / 동영상 처리의 fallback 시 동작이 나쁘다
• “로컬에는 고성능 GPU가 있어서 보이지 않았던” UI 문제

Microsoft 구성 사양에서는 MemoryInMB가 2048MB 미만이면 시작에 필요한 최솟값까지 자동으로 올려집니다. 즉 Windows Sandbox에서의 저메모리 검증은 대체로 2GB를 하한 기준으로 생각하는 것이 현실적입니다.

Sandbox만으로는 부족한 경우

반대로 이 부근은 Windows Sandbox만으로는 조금 부족합니다.

• CPU 사용률을 강하게 줄이고 싶다
• 디스크 용량 부족을 엄밀히 만들고 싶다
• I/O 지연을 만들고 싶다
• 여러 메모리 크기로 매트릭스처럼 돌리고 싶다
• 장시간 가동의 soak test를 persistent하게 돌리고 싶다

이 부근은 처음부터 Hyper-V 등의 풀 VM으로 올리는 편이 솔직합니다.

Sandbox는 “가벼운 제한 환경”까지는 잘하지만 “정밀한 부하 시험 기반”은 아닙니다.

Windows 11 24H2 이후는 CLI로도 돌리기 쉽다

Windows 11 24H2 이후의 새로운 Windows Sandbox에서는 CLI도 사용할 수 있습니다.

쓸 수 있는 명령은 예를 들면 다음입니다.

• wsb start
• wsb list
• wsb connect
• wsb exec
• wsb share
• wsb stop

최소한의 흐름은 예를 들면 이렇습니다.

wsb start --config "<Configuration><Networking>Disabled</Networking></Configuration>"
wsb list

참고로 Windows Sandbox CLI 공식 예에서는 Disabled가 쓰이지만, .wsb 구성 파일 스키마 설명에서는 Disable / Enable / Default로 안내합니다. 인라인 --config를 운영에 넣을 때는 대상 Windows 11 24H2 이후 실제 기기에서 받아들여지는 표기를 확인하세요.

실행 중인 Sandbox ID를 알면

wsb connect --id <sandbox-id>

로 연결할 수 있습니다.

CLI가 맞는 장면

CLI가 효과를 내는 것은 예를 들면 다음입니다.

• 로컬 재현 스크립트에 Sandbox 시작을 넣고 싶다
• 자주 쓰는 설정을 배치나 PowerShell에서 호출하고 싶다
• 실행 중인 Sandbox에 폴더 공유를 추가하고 싶다
• 로컬 검증 절차를 조금 자동화하고 싶다

그래도 .wsb를 남겨 두는 편이 좋은 이유

다만 현 시점에서는 .wsb를 버리지 않는 편이 좋습니다.

이유는 단순합니다. 시나리오 이름으로 읽을 수 있기 때문입니다.

• 00-clean-smoke.wsb
• 10-standard-user.wsb
• 20-restricted-runtime.wsb
• 30-low-resource.wsb

이렇게 두면 누가 봐도 용도를 알 수 있습니다.

CLI는 편리하지만, 운영으로는 “조건 정의는 .wsb, 시작 래핑은 CLI” 정도의 역할 분담이 가장 다루기 쉽습니다.

CLI의 주의점

wsb exec에는 현 시점에서 프로세스 I/O 취득 제약이 있고, 기존 로그온 사용자 문맥에서 실행할 때는 활성 사용자 세션도 필요합니다.

즉 완전한 headless 자동 시험 기반으로 너무 기대하지 않는 편이 좋습니다. 로컬 재현 자동화에는 편리하지만, CI 대신 그대로 두는 유형은 아닙니다.

운영에서 빼지 말아야 할 주의점

마지막으로 실무에서 빠지기 쉬운 점만 정리합니다.

공유 폴더는 최소한으로 한다

Sandbox는 isolated이지만 mapped folder는 호스트와 연결되어 있습니다. write 공유한 폴더는 호스트에 영향을 줍니다.

넓게 공유하지 않는다, 쓰기 가능한 공유는 Outbox에만 모은다. 이것이 기본입니다.

로그와 덤프는 닫기 전에 수집한다

당연하지만 닫으면 사라집니다. 그래서 출력 위치는 처음부터 Outbox에 고정해 두는 편이 좋습니다.

표준 사용자 검증은 “기본 Sandbox 세션 그대로”로 끝내지 않는다

관리자 권한 문제의 원인을 제대로 분리하려면 다른 사용자로 실행하는 편이 정리하기 쉽습니다. 여기를 애매하게 두면 “Sandbox에서는 동작했는데 고객의 표준 사용자에서는 죽는다” 가 남습니다.

OS 버전 차 검증에는 너무 쓰지 않는다

Sandbox는 같은 계통 OS의 클린 검증에는 맞지만, 옛 Windows를 재현하는 도구가 아닙니다. 다른 OS를 보려면 처음부터 풀 VM입니다.

기업에서 관리하는 PC에서는 정책 제약이 있을 수 있다

Group Policy로 제어되는 설정은 .wsb에서 바꾸지 못하는 경우가 있습니다. 사내의 엄격한 PC에서 “설정이 적용되지 않는다”면 먼저 정책 제어를 의심하는 편이 빠릅니다.

정리

Windows Sandbox를 쓰면 Windows 앱 개발의 이런 검증이 꽤 빨라집니다.

• 관리자 권한 문제의 원인 분리
• 클린 환경에서 처음 설치 확인
• 네트워크나 공유 의존을 찾아내기
• 권한 부족·의존 부족의 재현
• 저메모리 / GPU 없음에 가까운 가벼운 제한 검증

실무에서 효과가 나게 정리하면 대체로 이 다섯 가지입니다.

1. AppUnderTest, Scripts, Outbox를 고정으로 만든다
2. .wsb를 시나리오별로 나눈다
3. 입력은 read-only, 출력만 read-write로 한다
4. 표준 사용자 검증은 다른 사용자로 한다
5. CPU / 디스크 / 옛 OS까지 필요하면 풀 VM으로 올린다

Sandbox의 장점은 만능인 것이 아니라 “검증 전 준비를 작게 유지하면서, 환경을 매번 깨끗이 되돌릴 수 있는 것” 에 있습니다.

이 특징에 맞춰 시나리오를 고정해 두면, “그 자리의 재현”이 아니라 반복할 수 있는 검증 절차로 돌리기 쉬워집니다.

관련 기사

• Windows의 관리자 특권이 필요해지는 때는 언제인가 - UAC, 보호 영역, 설계상의 구별법
• Windows 앱에서 “관리자 권한이 필요한 처리만”을 분리하는 구체적인 작성법
• Windows 앱 배포 방식 고르기 - MSI/MSIX/ClickOnce/xcopy/독자 업데이트
• Windows 크래시 덤프 수집 입문 - WER/ProcDump/WinDbg

관련 토픽

• Windows 기술 토픽

이 주제가 이어지는 서비스

• Windows 앱 개발
• 기술 상담·설계 리뷰
• 문의

참고 자료

1. Microsoft Learn, Windows Sandbox
2. Microsoft Learn, Install Windows Sandbox
3. Microsoft Learn, Use and configure Windows Sandbox
4. Microsoft Learn, Windows Sandbox sample configuration files
5. Microsoft Learn, Windows Sandbox frequently asked questions (FAQ)
6. Microsoft Learn, Windows Sandbox versions
7. Microsoft Learn, Windows Sandbox command line interface

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

Windows Sandbox는 어떤 검증에 맞습니까?

클린 환경에서 처음 설치를 확인하는 작업, 관리자 권한 문제의 원인 분리, 네트워크나 공유 의존을 찾아내는 작업, 권한 부족·의존 부족의 재현, 저메모리·GPU 없음에 가까운 가벼운 제한 검증에 맞습니다. 풀 VM만큼 무겁지 않고 시작이 빠르며, 닫으면 매번 깨끗이 사라지는 점이 강점입니다. 반면 다른 OS 버전 재현, 여러 인스턴스 동시 실행, CPU 쿼터나 디스크 부족의 엄밀한 재현에는 풀 VM이 더 맞습니다.

Windows Sandbox를 쓰려면 조건이 있습니까?

Windows Pro / Enterprise / Education 계열에서 사용할 수 있습니다. Home 에디션에서는 사용할 수 없습니다. 또한 가상화 기능이 켜져 있어야 하고, 일정 이상의 RAM·디스크·CPU 코어가 전제입니다. 호스트와 같은 계통의 Windows 빌드에서 동작하므로, 호스트가 Windows 11이면 Windows 10 재현 환경이 되지 않습니다.

.wsb 파일에서는 무엇을 설정할 수 있습니까?

네트워크 사용·사용 안 함, 공유 폴더의 read-only / read-write, 메모리 상한(MemoryInMB), vGPU 끄기, 클립보드 공유 끄기, 시작 시 실행할 명령(LogonCommand) 등을 고정할 수 있습니다. 용도마다 .wsb를 나눠 두면 더블클릭만으로 같은 조건의 검증 환경을 몇 번이든 다시 만들 수 있습니다. 다만 MemoryInMB는 2048MB 미만이면 시작에 필요한 최솟값까지 자동으로 올려지므로, 저메모리 검증은 2GB를 하한 기준으로 보는 것이 현실적입니다.

Windows Sandbox에서 표준 사용자 동작 검증을 할 수 있습니까?

기본 Sandbox 세션 그대로는 표준 사용자 검증에 쓰기 어렵습니다. Sandbox의 로그온 명령은 컨테이너의 사용자 계정으로 동작하고, 그 사용자는 관리자 계정이어야 한다고 되어 있기 때문입니다. 표준 사용자에서의 권한 부족을 재현하고 싶다면, 시작 시 스크립트로 Sandbox 안에 표준 사용자를 만들고 runas 명령으로 그 사용자로서 앱을 실행하는 방법이 정리하기 쉽습니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.