Windows 샌드박스로 Windows 앱 개발의 검증을 빠르게 하는 방법 - 관리자 권한 문제, 클린 환경, 권한 부족・리소스 부족의 재현을 실무용으로 정리

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

수중의 개발기가 더러워져 있어 초회 도입 문제가 재현되지 않는다
고객 환경에서는 일어나는데 자신의 PC에서는 일어나지 않는다
「관리자로 실행하면 동작한다」는 진짜 필요한 권한 경계가 보이지 않는 것
권한이나 의존이 부족할 때의 거동을 시험하고 싶지만, 평소 환경을 망가뜨리고 싶지 않다
저 메모리나 GPU 없는 쪽의 상태에서 떨어지는데, 매번 풀 VM을 세울 정도는 아니다

이런 때 Windows 샌드박스는 꽤 사용하기 쉽습니다.

풀 VM만큼 무겁지 않고 기동이 빠르며 닫으면 매번 깨끗하게 사라지므로, 「같은 Windows 빌드에서 클린한 검증 환경을 몇 분 만에 다시 만들고 싶다」는 요건과 상성이 좋기 때문입니다.

다만 아무 생각 없이 매번 새하얀 Sandbox를 여는 것만으로는 그렇게 효율이 오르지 않습니다. 실무에서 정말로 효과적인 것은 검증 시나리오별로 .wsb를 고정하고, 읽기 전용 입력 폴더와 쓰기 전용 회수 폴더를 나누며, 관리자계・표준 사용자계・제한 있는 계를 구분 사용하는 운용입니다.

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

먼저 결론

먼저 결론만 나열하면 실무에서는 대체로 다음입니다.

Windows 샌드박스는 클린 환경의 재현, 초회 도입 확인, 관리자 권한 문제의 구분, 의존 부족의 씻어내기에 어울립니다.
매번 GUI로 수작업하기보다 용도별로 .wsb를 나누는 편이 빠릅니다.
호스트 공유는 입력은 read-only, 출력만 read-write로 나누면 사고가 줄어듭니다.
기본 Sandbox 세션은 표준 사용자 검증에는 그대로 사용하기 어렵습니다. 표준 사용자 검증을 하고 싶다면 Sandbox 내에 별도 사용자를 만들어 그 사용자로 기동합니다.
메모리 부족이나 GPU 없는 쪽의 재현에는 .wsb의 MemoryInMB와 VGpu / vGPU 무효화가 효과적입니다.
다만 CPU 쿼터, 디스크 핍박, 복수 동시 기동, 별도 OS 버전의 재현까지 하고 싶다면 Windows 샌드박스보다 풀 VM 쪽이 어울립니다.

요컨대 Windows 샌드박스는 「가볍지만 일회용」「빠르지만 동일 OS 계열」「한정적이지만 충분히 실무에 효과적」한 검증 환경입니다. 이 위치를 먼저 이해하면 사용처를 틀리지 않습니다.

왜 Windows 샌드박스가 개발 검증과 상성이 좋은가

Windows 샌드박스가 Windows 앱 개발과 상성이 좋은 이유는 다음 4가지입니다.

닫으면 매번 리셋할 수 있다

이것이 가장 큽니다.

인스톨러를 몇 번이나 시험하고, 설정을 망치고, 레지스트리를 만지고, 전제물을 넣었다 지웠다 한다. 이런 작업은 개발기 본체에서 하면 점점 「무엇이 들어 있는지 모르는 환경」이 됩니다.

Sandbox라면 닫으면 전부 사라집니다. 그래서 초회 도입 시에만 일어나는 문제나 전제물이 우연히 수중에 들어 있어서 보이지 않는 문제를 발견하기 쉬워집니다.

같은 Windows 계열의 깔끔한 환경을 즉시 만들 수 있다

Windows 샌드박스는 호스트와 같은 계통의 Windows 빌드를 사용하는 전제입니다. 여기는 제약이기도 하지만 반대로 말하면 수중의 Windows 11과 같은 계통의 클린 환경을 즉시 만들 수 있다는 것이기도 합니다.

「고객도 Windows 11 24H2, 이쪽도 Windows 11 24H2」라는 상황이라면 꽤 다루기 쉽습니다.

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

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

인스톨 순서 확인
UAC의 나오는 방식 확인
권한 부족 시의 에러 확인
의존 부족 시의 로그 확인
클린 환경에서의 스모크 테스트

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

Windows 샌드박스는 OS 이미지 관리나 스냅샷 운용을 그렇게 가지고 들어오지 않아도 되므로, 「조금 재현하고 싶다」 검증을 앞으로 진행하기 쉬운 것이 강점입니다.

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

Sandbox의 진가는 단순히 「안전하게 시험할 수 있다」는 것보다 같은 조건으로 몇 번이고 다시 할 수 있다는 점입니다.

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

이 부근을 .wsb나 Windows 11 24H2 이후의 CLI로 고정하면, 검증이 「떠오르는 작업」에서 「반복할 수 있는 절차」로 바뀝니다.

먼저 파악해 둘 제약

편리하지만 어울리지 않는 것도 있습니다. 여기는 먼저 짚어 두는 편이 좋습니다.

이용할 수 있는 에디션에 제약이 있다

Windows 샌드박스는 Windows Pro / Enterprise / Education 계에서 사용할 수 있습니다. Home 에디션에서는 사용할 수 없습니다.

사내의 개발기는 Pro라도 영업 단말이나 개인 PC는 Home인 케이스가 있으므로, 거기서 걸리기 쉽습니다.

가상화 요건이 있다

이용에는 가상화 기능이 유효할 것, 일정 이상의 RAM / 디스크 / CPU 코어가 있을 것이 전제입니다. 가볍다고는 해도 완전히 공짜는 아닙니다.

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

이것은 실무상 꽤 중요합니다.

Windows 샌드박스는 별도 OS 버전의 검증에는 어울리지 않습니다.

호스트가 Windows 11이라면 Windows 10의 재현 환경은 되지 않는다
고객이 오래된 빌드를 사용하고 있다면 그 차분은 다 메울 수 없다

그래서 별도 OS 판의 호환성 검증이나 구 빌드 의존의 문제는 처음부터 풀 VM을 선택하는 편이 좋습니다.

동시에 복수 기동할 수 없다

현상, Windows 샌드박스는 동시에 복수 인스턴스를 돌리는 운용에는 어울리지 않습니다.

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

기본으로 네트워크와 클립보드가 유효

여기는 놓치기 쉽습니다.

Windows 샌드박스는 기본으로 네트워크 접속이 유효입니다. 클립보드 공유도 기본으로 유효입니다.

즉, 아무 생각 없이 기동하면 「완전히 닫힌 세계」가 아닙니다. 불명한 파일의 확인이나 의존 부족의 재현에서는 처음부터 .wsb로 명시적으로 제어하는 편이 안전합니다.

Windows 11 24H2 이후에서는 일부 inbox 앱을 사용할 수 없다

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

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

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

매번 그 자리에서 공유 폴더를 결정하기보다 처음에 1곳만 검증용 둘 곳을 만들어 두면 꽤 편합니다.

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

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도 시나리오별로 고정합니다.

곤란한 일	먼저 사용할 것
클린 환경에서의 초회 도입 확인	`00-clean-smoke.wsb`
표준 사용자에서의 권한 부족 재현	`10-standard-user.wsb`
네트워크나 공유를 자른 제한 환경 확인	`20-restricted-runtime.wsb`
저 메모리・GPU 없는 쪽 확인	`30-low-resource.wsb`

이것만으로도 검증의 개시 비용이 꽤 내려갑니다.

클린 환경에서의 스모크 테스트를 1 더블 클릭으로 한다

먼저 처음에 만들어 두고 싶은 것이 클린 환경에서의 스모크 테스트용 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를 더블 클릭하는 것만으로 매번 깔끔한 초회 검증을 할 수 있습니다.

이것으로 발견되기 쉬운 문제

이 단계에서 자주 발견되는 것은 예를 들어 다음입니다.

개발기에는 들어 있던 전제 DLL / 런타임이 본번에는 없다
WebView2나 VC++ 재배포 가능 패키지의 전제가 암묵이 되어 있다
초회 기동 시에만 만들어지는 디렉터리나 설정 파일의 작성처가 나쁘다
Program Files 산하로 실행 시 데이터를 쓰려고 해서 떨어진다
「개발자의 수중에서는 들어 있던」 증명서・폰트・설정이 전제가 되어 있다

포인트는 Sandbox 측에서 일어난 것을 반드시 Outbox에 내는 것입니다. 닫힌 순간에 전부 사라지므로 로그도 덤프도 그대로 남겨서는 안 됩니다.

네트워크 있음 판도 별도 파일로 가진다

만약 대상이 Web installer나 온라인 인증 있는 앱이라면, 네트워크를 자른 채로는 별개의 문제밖에 보이지 않습니다.

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

관리자 권한 문제를 구분하는 순서

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

인스톨 시에만 필요한가
실행 시까지 필요한가
일부의 설정 변경만 필요한가
실은 저장처가 나쁠 뿐인가

이 이야기 자체는 이전에 쓴 다음 기사에서 정리하고 있습니다.

여기서는 Sandbox를 사용해 어떻게 검증을 빠르게 할까에 좁힙니다.

먼저 봐야 할 관점

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

인스톨러가 Program Files나 HKLM에 쓰고 있는가
서비스 등록, 드라이버 도입, 방화벽 설정 변경이 있는가
업데이터가 machine-wide로 교체하려고 하고 있는가
실행 시의 설정, 로그, 캐시를 보호 영역에 쓰려고 하고 있지 않은가
Shell Extension이나 COM 등록과 같은 OS 통합이 있는가

즉, 「정말로 관리자가 필요한 처리」와 「실행 시의 둘 곳이 나쁜 것뿐인 처리」를 나누는 것이 목적입니다.

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

여기는 중요합니다.

Windows 샌드박스의 로그온 커맨드는 컨테이너의 사용자 계정으로 동작합니다. 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에 쓰려고 해서 실패한다
업데이터가 machine-wide 전제가 되어 있다
로그의 저장처가 Program Files 산하가 되어 있다
1 버튼만 관리자가 필요한데 앱 전체를 승격 전제로 하고 있다

관리자 권한 문제는 코드 리뷰만으로 알 수 있는 경우도 있습니다. 다만 「실제로 표준 사용자로 동작시키면 어디가 막힐까」를 눈으로 보면 설계상의 경계가 꽤 분명해집니다.

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

「관리자가 아니다」뿐만 아니라 환경 측의 편리함을 일부 일부러 지운다고 숨은 의존이 보입니다.

예: `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 세션 너머로도 거칠게 성립하고 있던 조작에 쓸데없는 의존이 없는가
공유 폴더에 자유롭게 쓸 수 있는 전제의 거친 구현이 없는가

특히 업무 앱에서는 「수중에서는 평범하게 할 수 있었다」가 현장 단말에서는

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

인 경우가 많이 있습니다.

Sandbox에서 먼저 그 세계로 기울여 두면 나중에 문의로 막히기 어렵습니다.

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

여기도 꽤 중요합니다.

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

그래서 다음은 피하는 편이 안전합니다.

C:\Users를 통째로 공유
리포지토리 전체를 write로 보여준다
Downloads나 Documents를 거칠게 write 공유한다

기본은,

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

의 2단으로 하는 것이 추천입니다.

리소스 부족 쪽의 환경을 만든다

Windows 샌드박스는 리소스 제어의 자유도는 높지 않습니다. 그래도 「가볍게 리소스를 좁힌 검증」에는 사용할 수 있습니다.

예: `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 / 이미지 처리 / 동영상 처리의 폴백 시 거동이 나쁘다
「수중에서는 고성능 GPU가 있었으니 보이지 않았던」 UI 문제

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

Sandbox만으로는 부족한 케이스

반대로 다음은 Windows 샌드박스만으로는 약간 부족합니다.

CPU 사용률을 강하게 좁히고 싶다
디스크 용량 부족을 엄밀히 만들고 싶다
I/O 지연을 만들고 싶다
복수 메모리 사이즈로 매트릭스적으로 돌리고 싶다
장시간 가동의 soak test를 persistent하게 돌리고 싶다

이 부근은 처음부터 Hyper-V 등의 풀 VM으로 올리는 편이 자연스럽습니다.

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

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

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

사용할 수 있는 것은 예를 들어 다음입니다.

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

예를 들어 최소한이라면 이런 흐름입니다.

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

실행 중인 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입니다.

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

Group Policy로 제어되고 있는 설정은 .wsb에서 바꿀 수 없는 경우가 있습니다. 사내의 엄격한 단말에서 「설정이 효과가 없다」고 할 때는 먼저 정책 제어를 의심하는 편이 빠릅니다.

정리

Windows 샌드박스는 Windows 앱 개발에서 다음과 같은 검증을 꽤 빠르게 합니다.

관리자 권한 문제의 구분
클린 환경에서의 초회 도입 확인
네트워크나 공유 의존의 씻어내기
권한 부족・의존 부족의 재현
저 메모리 / GPU 없는 쪽의 가벼운 제한 검증

실무에서 효과적인 형태로 정리하면 대체로 다음입니다.

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

Sandbox의 좋은 점은 만능인 것이 아닙니다. 「검증 전의 준비를 작게 하면서 환경을 매번 깨끗하게 되돌릴 수 있는 것」입니다.

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

참고 자료

Microsoft Learn, Windows Sandbox
Microsoft Learn, Install Windows Sandbox
Microsoft Learn, Use and configure Windows Sandbox
Microsoft Learn, Windows Sandbox sample configuration files
Microsoft Learn, Windows Sandbox frequently asked questions (FAQ)
Microsoft Learn, Windows Sandbox versions
Microsoft Learn, Windows Sandbox command line interface

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

이 주제와 연결되는 서비스

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

Windows 앱 개발

상주 처리, 장비 연동, 운영 로그, 유지 보수 가능한 구조가 필요한 Windows 데스크톱 애플리케이션을 지원합니다.

서비스 보기 문의하기

저자 프로필

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

Go Komura

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

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

프로필 보기 문의하기

공개 링크

GitHub LinkedIn X COM_BLAS COM_BigDecimal