PowerShell 실행 정책, 범위와 서명·차단 파일을 나눠 조정하는 법

AI를 활용하여 생성한 이미지입니다.

PowerShell 스크립트가 실행되지 않을 때 Set-ExecutionPolicy Unrestricted부터 입력하는 경우가 있어요. 하지만 실행 정책은 하나의 전역 스위치가 아니고, 컴퓨터·사용자·현재 프로세스·그룹 정책이 서로 다른 범위에서 적용돼요. 먼저 어디에서 거부되는지 확인해야 설정을 낮추지 않고도 문제를 풀 수 있어요.

실행 정책은 보안 경계가 아니에요

Microsoft는 PowerShell 실행 정책을 악성 스크립트 실행을 어렵게 하는 방어 계층으로 설명하지만, 이 정책 자체를 완전한 보안 경계로 보지는 않아요.[1] 정책을 우회할 수 있는 상황이 있기 때문에, 실행 정책을 AllSigned로 바꿨다고 안전한 스크립트만 실행되는 것은 아니에요. 파일 출처, 코드 내용, 관리자 권한, 백신과 애플리케이션 제어 정책을 따로 봐야 합니다.

이 구분이 중요한 이유는 오류를 고치려고 정책을 낮추는 순간, 원래 필요했던 통제가 사라질 수 있기 때문이에요. 반대로 사내 PC에서 그룹 정책이 강제된 상태라면 로컬 PowerShell에서 값을 바꿔도 결과가 달라지지 않을 수 있어요.

첫 진단은 Get-ExecutionPolicy -List

관리자 PowerShell을 열기 전에 일반 PowerShell에서 다음 명령을 실행하세요.

Get-ExecutionPolicy -List
Get-ExecutionPolicy

-List는 범위별 값을 보여주고, 인자를 생략한 두 번째 명령은 현재 세션에서 실제로 적용되는 값을 보여줘요.[2] 보통 확인할 항목은 MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine 순서예요. 앞쪽 범위에 값이 있으면 뒤쪽 범위에서 바꾼 값이 적용되지 않을 수 있습니다.

정책을 낮추기 전에 파일 차단부터 확인해요

인터넷에서 내려받은 .ps1 파일은 파일 시스템의 영역 정보 때문에 RemoteSigned에서 막힐 수 있어요. 이때는 컴퓨터 전체의 정책을 바꾸기보다 파일이 실제로 차단됐는지 먼저 확인하는 편이 좁은 해결책이에요.

Get-Item .\build.ps1 -Stream *
Unblock-File -Path .\build.ps1
.\build.ps1

Microsoft 문서도 Unblock-File을 사용하기 전에 스크립트 코드를 읽고 안전성을 확인하라고 안내해요.[1][2] 특히 압축 파일 안의 여러 스크립트를 한꺼번에 풀고 실행하는 경우에는, 파일 하나를 해제하는 것보다 압축 파일의 출처와 내부 파일 목록을 먼저 확인해야 합니다.

차단 해제는 실행 정책 자체를 바꾸지 않아요. 따라서 회사가 정한 정책을 유지하면서 신뢰할 수 있는 파일 하나만 검토 후 실행할 때 적합해요. 반대로 출처를 모르는 스크립트라면 오류를 없애는 것이 목표가 되어서는 안 돼요.

개발용 설정은 범위를 좁게 시작하세요

개인 PC에서 직접 작성한 스크립트를 반복 실행해야 한다면 먼저 현재 사용자 범위에 RemoteSigned를 적용하는 방식을 검토할 수 있어요.

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
Get-ExecutionPolicy -List

Set-ExecutionPolicy는 Windows 컴퓨터의 실행 정책을 바꾸고, 변경은 즉시 적용돼요.[3] 다만 그룹 정책이 우선하는 환경에서는 이 명령이 성공한 것처럼 보여도 유효한 정책이 달라질 수 있으므로, 설정 직후 반드시 Get-ExecutionPolicy -List를 다시 읽어야 합니다.

일회성 실험이나 설치 스크립트 테스트라면 Process 범위가 더 좁아요.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
# 테스트가 끝나면 창을 닫습니다.

프로세스 범위 값은 현재 세션의 메모리에만 남고 PowerShell 창을 닫으면 사라져요.[1][3] 그래서 팀 개발 환경의 영구 설정으로 쓰기보다, 재현 가능한 테스트 절차에서 임시 조건을 명시할 때 맞습니다. Bypass를 기본값처럼 프로필에 넣는 것은 피하세요.

정책 값보다 먼저 확인할 실패 원인

1. 오류 메시지가 실행 정책인지, 모듈 서명·권한·경로 문제인지 구분해요.
2. Get-ExecutionPolicy -List로 그룹 정책이 앞 범위에 있는지 확인해요.
3. Get-Item -Stream *로 인터넷 영역 차단 정보가 있는지 봐요.
4. 스크립트의 해시나 배포 경로를 확인하고, 코드를 읽은 뒤 필요한 파일만 해제해요.
5. 변경했다면 같은 범위에 Undefined를 지정할지, 원래 값을 복원할지 기록해요.

원래 값이 무엇이었는지 모른 채 Undefined를 입력하면 상위 범위의 정책이 다시 적용될 뿐이에요. 개인 설정을 되돌릴 때도 먼저 현재 목록을 저장하고, 조직 정책을 개인 명령으로 없애려 하지 않는 편이 안전합니다.

상황별 선택 기준

실행 정책은 스크립트의 안전성을 판정하는 단독 도구가 아니에요. 오류를 없애는 가장 짧은 명령보다, 적용 범위를 줄이고 파일 출처를 확인하는 순서가 나중에 되돌리기 쉽습니다.

특히 자동화 작업에서 오류가 반복되면 정책을 한 단계씩 낮추기보다, 같은 스크립트를 새 PowerShell 프로세스에서 재현하고 Get-ExecutionPolicy -List 결과와 파일의 차단 상태를 함께 남기는 것이 좋아요. 그래야 다음 실행에서 정책 변경, 파일 출처, 권한 상승 중 무엇이 영향을 줬는지 다시 분리할 수 있습니다.

출처

1. Microsoft Learn: about_Execution_Policies
2. Microsoft Learn: Get-ExecutionPolicy
3. Microsoft Learn: Set-ExecutionPolicy