윈도우11 PowerShell 서명 검증 실패 해결｜NotSigned·UTF-8 BOM·스크립트 재서명

윈도우11 업데이트 이후 평소 사용하던 파워쉘(PowerShell) 스크립트가 갑자기 실행되지 않거나, 분명 디지털 서명을 했는데도 NotSigned로 표시된다면 조금 당황스러울 수 있는데요 특히 회사에서 로그인할 때 자동으로 실행되는 스크립트나 백업·배포 작업이라면 원인을 모르고 실행 정책부터 바꾸기 쉽죠.

이번에는 그 방법부터 권하고 싶지는 않습니다.

2026년 11월 마이크로소프트 보안 업데이트에서 서명된 PowerShell 파일의 문자 인코딩 검사가 강화됐기 때문인데요. 실제 문제가 인코딩이라면 정책을 느슨하게 바꿔도 서명 자체가 올바르게 복구되는 것은 아닙니다.

먼저 할 일: 오류가 발생한 .ps1 원본을 백업 → Get-AuthenticodeSignature로 서명 상태 확인 → 공식 검사 도구 Scan → 문제가 확인된 복사본만 UTF-8 BOM 변환·재서명 → Valid 확인.

윈도우11 업데이트 후 PowerShell 서명 오류가 생기는 이유

2026년 11월 10일 배포된 보안 업데이트부터 Windows는 PowerShell 스크립트에 대한 서명 검증 과정에서 잘못된 문자 인코딩을 더 엄격하게 검사합니다.

예전에는 부정확한 UTF-8 바이트가 섞여 있어도 검증을 통과하던 파일이 새 검사에서는 거부될 수 있다는 설명입니다.

문제는 모든 NotSigned 오류가 이번 업데이트 때문은 아니라는 점입니다. 원래 서명이 없는 파일, 배포 중 내용이 바뀐 파일, 인증서 신뢰 문제도 비슷하게 보일 수 있으니 바로 UTF-8로 덮어쓰지 말고 상태를 구분해야 합니다.

나타나는 증상	의심할 부분	우선 확인
NotSigned	인코딩 인식 문제 또는 원래 미서명	파일 이력·공식 Scan
UnknownError	서명할 때 문자 디코딩 실패 가능성	오류 문구·원본 인코딩
ConstrainedLanguage	WDAC 등 앱 제어 정책 영향 가능성	회사 정책·보안 로그
해시 불일치	서명 후 파일 변경 또는 로캘 차이	원본·배포본 비교

윈도우11 보안 업데이트 설치 자체가 실패한다면 지금 다루는 스크립트 서명 오류와는 다른 문제입니다. 설치 오류 코드 0x800F0993 등이 나타난다면 KB5132061 설치 실패와 샌드박스 점검 방법을 먼저 확인하세요.

1. 파워쉘 실행 후 현재 서명 상태 확인하기

우선 작업 표시줄 검색에서 PowerShell을 검색해서 실행합니다. 단순 조회 명령은 일반 권한으로 충분하며, 특별한 이유 없이 관리자 권한으로 시작할 필요는 없습니다.

시작 메뉴에서 찾기 어렵거나 터미널과 CMD의 차이가 헷갈린다면 파워쉘 실행·관리자 권한·버전 확인 방법을 참고하면 됩니다.

예시로 스크립트가 C:\Scripts\Deploy.ps1에 저장되어 있다고 가정하겠습니다. 실제 사용 중인 경로로 바꿔 입력하면 됩니다.

Get-AuthenticodeSignature -FilePath "C:\Scripts\Deploy.ps1" |
    Format-List Status, StatusMessage, SignerCertificate

Valid가 보이면 현재 환경에서 서명이 유효하다고 판정된 것입니다. NotSigned라면 과거에 서명이 있었는지부터 확인하세요. 지금 결과 하나만으로 인코딩 손상이라고 결론 내리면 안 됩니다.

현재 사용 중인 Windows PowerShell 버전이 궁금하다면 $PSVersionTable도 입력할 수 있습니다. 참고로 이 화면은 기존 PowerShell 사용법 이미지이며, 이번 서명 오류가 실제 발생한 캡처는 아닙니다.

$PSVersionTable
Get-ExecutionPolicy -List

두 번째 명령어로 실행 정책을 확인하더라도 바로 Set-ExecutionPolicy Unrestricted를 실행하지는 마세요. 특히 회사 PC에서는 그룹 정책으로 관리되는 항목을 임의로 바꾸면 문제가 커질 수 있습니다.

2. UTF-8 BOM이 왜 중요한지 먼저 이해하기

UTF-8과 UTF-8 BOM은 글자를 저장하는 방식이 아주 비슷하지만, BOM은 파일 맨 앞에 인코딩을 식별할 수 있는 바이트를 넣습니다. 일부 Windows 환경에서는 BOM이 없는 스크립트를 시스템 코드 페이지로 잘못 해석할 수 있어요.

파일 형식	특징	이번 오류에서 판단
UTF-8 BOM	파일 시작에 인코딩 표시	문자 확인 후 재서명 권장
UTF-8 (BOM 없음)	개발 도구에서 흔한 형식	무조건 오류는 아님·검사 먼저
ANSI·CP949 등	구형 국내 업무 파일에서 사용	원본 문자셋 확인 후 변환
UTF-16	BOM으로 구분 가능	서명·호환성 별도 확인

여기서 꼭 알아둘 부분이 있습니다. 이미 깨진 문자를 UTF-8 BOM으로 저장한다고 원래 글자가 살아나지는 않습니다. 잘못 읽힌 파일을 그대로 저장하면 오히려 복구가 어려워질 수 있어요.

글자가 깨지는 문제까지 동반된다면 메모장 한글 깨짐과 UTF-8·CP949 인코딩 복구 방법에서 원본 인코딩을 다시 확인하는 절차를 먼저 살펴보는 것이 좋겠습니다.

3. 마이크로소프트 공식 도구로 먼저 Scan 검사

마이크로소프트는 Repair-SignedPowerShellUtf8.ps1라는 검사·복구용 예제 스크립트를 공개했습니다.

아래 링크에서 원본 코드를 확인할 수 있으며, 회사 환경이라면 승인된 스크립트만 사용하세요. 실행이 차단된다고 보안 정책을 해제해 우회하는 방법은 권하지 않습니다.

공식 다운로드·확인: Microsoft 서명 인코딩 복구 스크립트 문서 (KB5136213). 문서에 있는 전체 코드를 저장하고 Windows PowerShell 5.1의 승인된 FullLanguage 환경에서 사용합니다.

스크립트를 준비하고 해당 폴더에서 실행할 때, 먼저 파일을 변경하지 않는 Scan 모드를 사용해 보세요.

.\Repair-SignedPowerShellUtf8.ps1 -Mode Scan -Path C:\Scripts -Recurse |
    Format-Table Path, Issue, SignatureStatus, Action -Wrap

Scan 결과	의미	다음 행동
MalformedUtf8	잘못된 UTF-8 바이트 가능성	복사본 변환 또는 Repair 검토
Utf8WithoutBom	BOM 없는 UTF-8과 코드페이지 충돌 가능성	원본 인코딩·서명 환경 확인
CodePageTextReadAsUtf8	다른 코드페이지를 UTF-8로 오인	원본 인코딩 지정 후 변환
None	스캔에서 인코딩 문제 미발견	인증서·파일 변경 여부 진단

결과가 None인데도 NotSigned가 나오면 인코딩 복구를 무조건 시도할 이유는 없습니다.

원래 서명이 없었는지, 배포 과정에서 내용이 수정됐는지, 서명 인증서에 문제가 있는지를 따로 봐야 합니다.

4. UTF-8 BOM으로 변환하고 승인된 인증서로 다시 서명하기

Scan에서 인코딩 문제가 확인됐고 원본의 문자 인코딩까지 판단했다면 원본 파일을 유지한 채 새 복사본으로 변환할 수 있습니다.

공식 도구는 원본이나 이미 존재하는 출력 파일을 덮어쓰지 않도록 설계되어 있습니다.

.\Repair-SignedPowerShellUtf8.ps1 -Mode ConvertToUtf8Bom -Path C:\Scripts\Deploy.ps1

기본 출력은 Deploy.utf8bom.ps1입니다. Shift-JIS처럼 다른 문자셋으로 작성된 파일은 그 형식을 알고 있을 때만 -SourceCodePage를 지정합니다. 한국어 파일이라고 무조건 코드페이지 949를 지정하는 방법도 정확하지는 않습니다.

변환된 복사본을 편집기에서 열어 한글, 경로, 주석, 명령어가 정상인지 확인하세요. 변환은 서명까지 해주지 않습니다. 기존 서명이 제거된 복사본을 코드 서명용 인증서로 다시 서명해야 합니다.

# 조직에서 승인받은 코드 서명 인증서를 사용합니다.
# $cert는 사전에 선택한 실제 인증서여야 합니다.
Set-AuthenticodeSignature -FilePath "C:\Scripts\Deploy.utf8bom.ps1" -Certificate $cert

Get-AuthenticodeSignature -FilePath "C:\Scripts\Deploy.utf8bom.ps1" |
    Format-List Status, StatusMessage

정상 확인: 서명 상태가 Valid인지 확인하고, 테스트 환경에서 스크립트 기능까지 정상 작동하는지 확인한 다음 배포합니다. 인증서가 없는 일반 사용자는 임의 인증서를 만들어 공급업체 파일을 재서명하기보다 원래 배포처에 수정본을 요청해야 합니다.

인증서가 없어도 Repair 모드로 해결할 수 있나요?

공식 도구의 Repair 모드는 일부 사례에서 기존 서명을 유지한 별도 복사본을 만드는 임시 방법입니다.

하지만 모든 파일에 성공하지 않으며, 원본이 이미 손상됐거나 코드 페이지가 다른 환경에서는 실패할 수 있습니다.

.\Repair-SignedPowerShellUtf8.ps1 -Mode Repair -Path C:\Scripts\Deploy.ps1

출력된 복사본의 SignatureStatus가 Valid인 경우에만 검토 대상으로 삼아야 합니다. CodePageTextReadAsUtf8 사례에는 Repair가 제공되지 않으므로 원본 문자셋을 확인하고 변환·재서명하는 절차가 필요합니다.

5. 그래도 실행되지 않는다면 실행 정책 오류와 분리해서 보기

PowerShell은 스크립트를 실행하는 정책과 파일 자체의 디지털 서명이 서로 다른 부분입니다.

예를 들어 npm.ps1 파일을 로드할 수 없습니다는 개발 환경에서 자주 나오는 실행 정책 오류인데, 이번 인코딩 서명 문제와 원인이 다를 수 있습니다.

관련 증상이라면 npm.ps1 파일을 로드할 수 없습니다 오류와 실행 정책 확인 방법도 참고해 보세요.

다만 회사에서 요구하는 AllSigned 정책을 일시적으로 낮춰 문제를 감추는 방식은 피하는 편이 좋겠습니다.

추가로 보이는 문제	확인할 대상	대응 방향
PSSecurityException	스크립트 실행 정책	Get-ExecutionPolicy -List
UnknownError	문자 변환 및 서명 단계	공식 Scan·원본 비교
인증서 체인 오류	발급자·만료·폐기·신뢰	보안 담당자·배포처 문의
서명은 Valid, 기능은 실패	스크립트 로직·파일 권한	실행 로그·테스트 환경 점검

자주 묻는 질문

NotSigned라고 나오면 무조건 UTF-8 BOM으로 변환해야 하나요?

아닙니다. 원래 서명이 없는 파일도 NotSigned로 표시됩니다. 2026년 보안 업데이트 이후 인코딩 문제가 생긴 일부 파일에서도 같은 표시가 나올 수 있는 것이므로, 공식 Scan 결과와 과거 정상 서명 여부를 함께 확인해야 합니다.

UTF-8 BOM으로 저장했는데도 서명 오류가 남는 이유는?

저장 과정에서 문자가 깨졌거나, 기존 서명이 복사본과 일치하지 않거나, 인증서가 신뢰되지 않을 수 있습니다. 올바른 원본 인코딩으로 다시 읽고 내용 검토 → 승인된 인증서로 재서명 → Valid 확인까지 진행해야 합니다.

스크립트 실행 정책을 Unrestricted로 바꾸면 해결되지 않나요?

실행 정책을 완화해도 서명 검증 자체가 복구되는 것은 아닙니다. 특히 회사의 보안·앱 제어 정책을 임의로 우회하면 안 됩니다. 실행 정책 오류와 실제 서명 오류를 나누어 진단하는 것이 정확합니다.

일반 사용자의 파워쉘 명령어도 모두 영향을 받나요?

일반 명령 한두 줄을 터미널에 직접 입력하는 상황과, 서명된 스크립트 파일을 로딩해 검증하는 상황은 다릅니다. 이번 변경의 핵심 대상은 인코딩 문제가 있는 서명 스크립트입니다.

복구 전후 최종 확인

제가 이 문제를 정리하면서 가장 중요하다고 본 것은 서명이 안 된다는 이유로 보안 설정부터 끄지 않는 것입니다. 업무용 자동화일수록 복구 자체보다 잘못된 스크립트가 다시 배포되는 일을 막는 게 중요하기 때문입니다.

원본 보관 → 실패 시점과 오류 메시지 기록 → Scan → 원문 검토 → 재서명 → Valid와 실제 실행 테스트. 이 정도를 거친 뒤 교체하면 어디서 문제가 발생했는지도 훨씬 명확하게 남길 수 있습니다.

Microsoft 공식 문서: 서명된 PowerShell 스크립트 인코딩 진단 (KB5135999) · 복구 스크립트 원문 (KB5136213)
기준일: 2026년 11월 13일.