Windows PowerShell 5.1과 PowerShell 7의 차이 ── 사내 스크립트 마이그레이션 실무 가이드

「서버에 PowerShell 7을 넣으면 지금 쓰는 스크립트가 깨지지 않나요」「5.1 그대로 두면 안 되는 건가요」── 사내 운영 스크립트를 가진 고객에게서 이런 질문을 받는 일이 늘었습니다. Windows에 처음부터 들어 있는 PowerShell(5.1)과, 따로 설치하는 PowerShell 7. 이름이 같아서 「버전을 올리면 교체된다」고 오해하기 쉽지만, 실제로는 공존하는 별개 제품입니다.

이 관계를 이해하지 못한 채 7을 넣으면, 「설치했는데 아무것도 안 바뀐다(작업은 여전히 5.1로 돈다)」거나, 반대로 「옮겼더니 일본어 파일 연동이 깨졌다」 중 하나를 겪게 됩니다. 특히 후자는 일본어 환경에서 잘 나는 사고이고, 원인은 기본 문자 인코딩의 차이입니다.

이 글에서는 사내 스크립트를 다루는 정보시스템·운영 담당자를 대상으로, 5.1과 7의 관계와 차이를 구조부터 정리하고, 실제로 마이그레이션을 진행하는 절차를 판단표와 함께 정리합니다.

1. 먼저 결론

• Windows PowerShell 5.1과 PowerShell 7은 별개 제품이며, side-by-side로 공존합니다. 5.1은 Windows에 기본 포함되어 .NET Framework 위에서, 7은 별도 설치로 .NET 위에서 동작합니다. 7을 넣어도 5.1은 사라지지 않습니다.¹²
• Microsoft는 5.1에 신기능을 추가하지 않습니다. 5.1 지원은 Windows 본체의 수명 주기에 묶여 있고, 개발의 중심은 7입니다. 새로 작성하는 스크립트는 7을 기준으로 삼아야 합니다.¹³
• 실행 파일이 다릅니다. 5.1은 powershell.exe, 7은 pwsh.exe입니다. 작업 스케줄러 등의 시작 명령을 바꾸지 않는 한, 기존 구성은 5.1로 계속 동작합니다.⁴⁵
• 기본 문자 인코딩이 다릅니다. 5.1은 cmdlet마다 제각각이고(Out-File은 UTF-16LE, Get-Content는 ANSI 등), 7은 모두 BOM 없는 UTF-8입니다. 일본어 환경 마이그레이션에서 가장 먼저 걸리는 함정입니다.⁶
• 7에서 동작하지 않는 모듈에는 Windows 호환 기능이 있습니다. Import-Module -UseWindowsPowerShell로 백그라운드 5.1 프로세스에 로드한 뒤 remoting으로 사용할 수 있지만, 돌아오는 것은 직렬화된 객체이며 메서드는 호출할 수 없습니다.⁷
• #Requires -Version과 $PSVersionTable로 「어느 쪽에서 동작해야 하는 스크립트인지」를 코드에 명시합니다. 의도하지 않은 버전에서 실행되어 조용히 깨지는 사고를, 실행 전에 막을 수 있습니다.⁸⁹
• 마이그레이션은 인벤토리 → 7에서 실행 테스트 → 시작 명령 업데이트의 단계 방식으로 진행합니다. 7 설치는 MSI 또는 winget으로 하고, 업데이트 배포(Microsoft Update를 경유할지)도 처음에 정해 둡니다.⁵²⁴

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

2. 5.1과 7은 어떤 관계인가 ── 대체가 아니라 공존

먼저 전체 그림을 표로 잡습니다.

7은 5.1을 대체하지 않고, 다른 디렉터리에 설치되어 side-by-side로 동작합니다. 모듈 경로(PSModulePath)도 프로필도 이벤트 로그도 따로 관리됩니다. 7 쪽 PSModulePath에는 5.1의 모듈 경로도 포함되므로, 7에서 기존 모듈의 상당수를 로드할 수 있습니다.⁵²

「지금 어느 쪽에 있는지」는 다음 두 줄로 언제든 확인할 수 있습니다. $PSVersionTable은 PowerShell 버전 정보를 담는 자동 변수입니다.⁹

# 자신이 어느 PowerShell에 있는지 확인한다
$PSVersionTable.PSVersion   # 5.1.x이면 Windows PowerShell, 7.x이면 PowerShell 7
$PSVersionTable.PSEdition   # Desktop = Windows PowerShell / Core = PowerShell 7

공식 입장도 분명합니다. Windows PowerShell은 Windows에 기본 포함되는 제품으로, Microsoft는 신기능으로 업데이트하지 않으며, 지원은 사용 중인 Windows 버전에 묶입니다. 한편 PowerShell(7 계열)은 새로운 .NET 위에 구축되고, 릴리스마다 기반 .NET의 지원 정책에 따른 지원 기간이 정해집니다.¹³ 5.1이 내일 당장 사라지는 것은 아니지만, 「앞으로 작성할 것」「앞으로 오래 쓸 것」의 기준은 7에 두어야 한다는 것이 실무 결론입니다.

3. 가장 먼저 걸리는 함정 ── 기본 인코딩 차이와 문자 깨짐

일본어 환경 마이그레이션에서 가장 흔한 문제가 문자 깨짐입니다. 원인은 분명합니다. 기본 문자 인코딩이 둘에서 다릅니다.⁶

# 같은 한 줄이라도, 5.1과 7에서는 만들어지는 파일의 바이트열이 다르다
'こんにちは' | Out-File -FilePath C:\temp\hello.txt
# 5.1에서 실행 → UTF-16LE(BOM 포함) 파일
# 7에서 실행   → BOM 없는 UTF-8 파일

이것이 실무에서 의미하는 바는 두 가지입니다.

첫째, Shift_JIS를 전제로 한 파일 연동은 7로 옮긴 순간 읽기와 쓰기 모두 깨질 수 있습니다. 5.1의 Get-Content는 BOM 없는 파일을 ANSI(일본어 환경에서는 Shift_JIS)로 읽지만, 7은 UTF-8로 읽기 때문입니다. 대책은 파일 입출력 모두에서 -Encoding을 명시하는 것입니다. 7에서는 코드 페이지 번호(-Encoding 932)나 등록 이름으로 지정할 수 있고, 7.4부터는 ansi라는 값도 쓸 수 있습니다.⁶ CSV 처리의 구체적인 작성법은 같이 공개한 「PowerShell로 Excel·CSV 업무 처리를 자동화하기」에 정리했습니다.

둘째, 스크립트 파일 자체의 저장 형식입니다. BOM 없는 UTF-8로 저장된, 일본어 주석이 들어간 스크립트를 5.1이 읽으면 ANSI로 잘못 해석해 문자 깨짐이나 구문 오류가 납니다. 공식 문서 권장대로 비ASCII 문자가 들어간 스크립트는 BOM 포함 UTF-8로 저장하면, 5.1과 7 모두에서 올바르게 해석됩니다.⁶

4. 호환성 ── 7에서 동작하지 않는 것과 Windows 호환 기능의 실력

4.1. 무엇이 동작하지 않게 되는가

7은 기존 모듈의 상당수를 그대로 로드할 수 있지만⁵, 로드되지 않는 것도 있습니다. 공식에서 드는 대표적인 예입니다.

• 더 이상 포함되지 않는 모듈: PSWorkflow/PSWorkflowUtility(워크플로), PSScheduledJob, ISE용 모듈, Microsoft.PowerShell.LocalAccounts 등은 7에 들어 있지 않습니다.⁴
• 스냅인: 모듈 이전의 오래된 확장 형식인 스냅인은 7에서 지원되지 않습니다.⁴
• .NET Framework에 밀착된 코드: 7은 기반 .NET이 다르므로, .NET 메서드를 직접 호출하는 스크립트는 동작이 달라질 수 있습니다.⁵⁴
• 세부 동작 변경: Export-Csv는 #TYPE 행을 기본으로 출력하지 않게 되었고, Group-Object는 그룹이 정렬되어 돌아오는 등, 출력에 의존하는 스크립트가 영향을 받는 변경이 있습니다.⁴

반대 방향의 비호환도 있습니다. 삼항 연산자나 ForEach-Object -Parallel처럼 7에서 추가된 구문·기능을 쓴 스크립트는 5.1에서 동작하지 않습니다.⁵ 「양쪽에서 돌아가게 쓸지」「어느 쪽에서 실행할지를 명시할지」를 스크립트마다 정해야 합니다.

Microsoft 모듈의 지원 상황은 공식 모듈 호환성 페이지에서 확인할 수 있습니다.¹⁰

편집 환경(ISE)의 이전 대상도 같이 정해 둡니다. Windows PowerShell ISE는 Windows에서 삭제될 예정이 없고, 보안과 우선순위가 높은 수정도 이어지지만, 신기능 개발은 끝났고 대응하는 것은 PowerShell 5.1 이전뿐입니다.¹¹ 즉 7에서 돌릴 스크립트를 ISE에서 작성·실행하는 운영은 성립하지 않습니다. 공식이 안내하는 이전 대상은 Visual Studio Code와 PowerShell 확장입니다. 확장을 넣으면 통합 콘솔에서 사용할 PowerShell 버전을 전환할 수 있습니다(추가 경로도 설정으로 넣을 수 있습니다). ISE에 익숙한 사람을 위해 「ISE 조작감을 VS Code에서 재현하는」 가이드도 있으므로, 전환 안내는 거기서 시작하는 편이 빠릅니다.¹¹ 정보시스템 현장은 ISE 사용자가 많으니, 스크립트 마이그레이션 계획과 편집 환경 전환은 같은 타이밍에 안내하십시오.

4.2. Windows 호환 기능(-UseWindowsPowerShell)의 구조와 제약

7에는 5.1에서만 동작하는 모듈을 위한 Windows 호환 기능이 있습니다.

# 7에 대응하지 않는 모듈을 호환 기능을 통해 로드한다(공식 문서의 예)
Import-Module -Name ScheduledTasks -UseWindowsPowerShell

구조는 remoting의 응용입니다. 백그라운드에서 Windows PowerShell 5.1 프로세스가 뜨고, WinPSCompatSession이라는 세션에 모듈이 로드되며, 7 쪽에는 암묵적 remoting으로 생성된 프록시 모듈이 import됩니다. System32 아래의 5.1 전용 모듈은 이름 지정이나 명령 자동 검색에서도 암묵적으로 이 경로로 로드됩니다.⁷

그림으로 보면 두 프로세스의 관계가 분명해집니다.

flowchart LR
    subgraph PS7["pwsh.exe ── PowerShell 7 프로세스"]
        SCRIPT["스크립트 본체"]
        PROXY["프록시 모듈<br/>암묵적 remoting으로 생성된 진입점.<br/>본체가 아님"]
    end
    subgraph PS51["powershell.exe ── 뒤에서 뜨는 5.1 프로세스"]
        SESSION["WinPSCompatSession<br/>호환 기능으로 로드한 모든 모듈이<br/>하나의 runspace를 공유한다"]
        MOD["5.1에서만 동작하는 모듈 본체"]
    end
    SCRIPT --> PROXY
    PROXY -->|"명령 호출을 전달"| SESSION
    SESSION --> MOD
    MOD -->|"결과"| SESSION
    SESSION -.->|"직렬화된 값의 사본만 돌아온다<br/>메서드는 호출할 수 없다"| SCRIPT

그림대로, 7 쪽에 있는 것은 모듈 본체가 아니라 진입점뿐입니다. 「7을 넣으면 전부 7에서 돈다」가 아니라 「7이 5.1에 맡기고, 결과의 사본을 받는다」가 실상이며, 뒤에서 말할 제약은 모두 이 구조에서 나옵니다.

편리하지만, 제약을 모르고 쓰면 조용히 깨집니다. 공식에 적힌 제약은 다음과 같습니다.⁷

• 주고받는 것은 직렬화된 값이며, 생 객체가 아닙니다. 돌아온 객체의 메서드는 호출할 수 없고, 속성의 스냅샷만 손에 들어옵니다.
• 로컬 Windows에서만 동작하며, Windows PowerShell 5.1이 필요합니다.
• 호환 기능으로 로드한 모든 모듈이 하나의 runspace(하나의 5.1 프로세스)를 공유합니다.
• 일부 모듈(PSScheduledJob 등)은 기본으로 로드가 거부됩니다.

「가져온 결과의 메서드를 호출한다」「파이프라인 도중에 생 객체가 필요하다」 같은 처리는 호환 기능으로는 성립하지 않습니다. 이 경우 파이프라인 전체를 5.1 쪽에서 실행하고 최종 결과만 받는 작성법도 가능하지만⁷, 복잡해질 정도라면 그 처리만 5.1에 남겨 두는 편이 유지보수하기 쉽다는 것이 실무 감각입니다.

5. 방어적으로 작성하기 ── #Requires와 버전 분기

마이그레이션 기간에는 「어느 쪽에서 실행될지 모르는」 상태가 반드시 생깁니다. 의도하지 않은 버전에서 돌다가 중간에 깨지는 것이 최악이므로, 스크립트 쪽에 방어를 넣습니다.

#Requires 문을 적어 두면, 조건을 충족하지 않는 PowerShell에서는 스크립트가 실행되기 전에 거부됩니다.⁸

#Requires -Version 7.0
# 이 스크립트는 7 전용(ForEach-Object -Parallel 등을 사용).
# powershell.exe(5.1)로 시작된 경우, 여기서부터는 일절 실행되지 않는다

반대로 5.1 전용 스크립트에는 #Requires -PSEdition Desktop을 적습니다. Desktop이 5.1 계열, Core가 7 계열의 에디션 이름입니다.⁸⁹

양쪽에서 동작하는 스크립트에서 일부만 동작을 바꾸고 싶을 때는 $PSVersionTable로 실행 시점에 분기합니다.⁹

# 5.1과 7 양쪽을 지원하는 스크립트에서, 버전 차가 있는 처리만 분기한다
if ($PSVersionTable.PSVersion.Major -ge 6) {
    $enc = 932            # 7: 코드 페이지 번호로 Shift_JIS를 지정할 수 있다
} else {
    $enc = 'Default'      # 5.1: Default = 시스템의 ANSI 코드 페이지
}
Get-Content -LiteralPath $path -Encoding $enc

핵심은 이 명시를 「마이그레이션이 끝난 뒤」가 아니라 「인벤토리 시점」에 넣는 것입니다. #Requires 행이 한 줄 있으면, 그 스크립트가 어느 쪽 환경의 것인지 누구나 알 수 있습니다.

6. 마이그레이션 진행 방법 ── 인벤토리부터 작업 스케줄러 업데이트까지

실제 마이그레이션은 다음 순서로 진행합니다. 한 번에 바꾸는 것은 사고의 원인이므로, 단계 마이그레이션이 원칙입니다.

절차 1: 인벤토리. 스크립트 보관 위치와 작업 스케줄러에서, 동작 중인 .ps1과 시작 명령을 모두 끌어냅니다.

# 작업 스케줄러에서, PowerShell을 시작하는 작업을 모두 끌어낸다
Get-ScheduledTask | ForEach-Object {
    foreach ($action in $_.Actions) {
        # cmd.exe /c powershell ... 같은 간접 실행도 잡기 위해, 실행 파일과 인수 양쪽을 본다
        if ("$($action.Execute) $($action.Arguments)" -match 'powershell|pwsh') {
            [pscustomobject]@{
                TaskPath  = $_.TaskPath        # 작업 이름은 폴더 안에서만 고유하므로, 경로도 적어 둔다
                TaskName  = $_.TaskName
                Execute   = $action.Execute    # powershell.exe인지 pwsh.exe인지
                Arguments = $action.Arguments
            }
        }
    }
} | Export-Csv -Path .\ps-tasks.csv -NoTypeInformation -Encoding UTF8

만들어지는 ps-tasks.csv는 4열입니다. 열의 의미와 형식 예를 듭니다(값은 형식의 예이며, 실제 내용은 환경마다 다릅니다).

이 CSV는 다음 세 가지를 보기 위해 만듭니다. Execute가 powershell.exe인 행은 아직 5.1로 도는 작업, 즉 마이그레이션 대상입니다. Execute가 cmd.exe인 행은 Arguments 안에 PowerShell 시작이 묻혀 있으므로 내용을 열어 확인합니다. 그리고 Arguments에 -File도 -Command도 나오지 않는 행은 위치 지정 그대로 넘기는 호출이므로, 절차 5에서 pwsh로 바꿀 때 해석이 달라집니다(이유는 절차 5). 이 셋을 구분해 두기만 해도 마이그레이션 계획의 분모가 정해집니다.

절차 2: 7 설치. MSI 패키지(배포 관리 도구로 배포하기에 적합) 또는 winget으로 설치합니다.⁵²

어느 판을 어떻게 넣을지는 다음 기준으로 정합니다.³²

# winget으로 설치. 업데이트도 winget upgrade로 같은 경로를 탄다
winget install --id Microsoft.PowerShell --source winget

# MSI 패키지로 넣고 싶은 경우(서버·배포 관리 도구용)
winget install --id Microsoft.PowerShell --source winget --installer-type wix

winget 자체에도 전제가 있습니다. 7.6.0 winget 패키지부터 winget install --id Microsoft.PowerShell은 기본으로 MSIX 패키지를 넣는 동작으로 바뀌었으므로, MSI가 필요하면 위처럼 --installer-type wix를 붙입니다. 또한 winget은 Windows Server 2022 이전에서는 쓸 수 없습니다(Windows Server 2025의 Desktop Experience 판에는 기본 포함). 서버 군에 대한 배포는 MSI를 전제로 계획하는 편이 무난합니다.²

업데이트 운영도 처음에 정합니다. 7.2 이후 MSI에는 Microsoft Update로 업데이트를 받는 옵션(기본 사용)이 있어, WSUS나 구성 관리 도구의 일반 업데이트 흐름에 태울 수 있습니다.⁴ 관리되지 않은 설치를 방치해 오래된 7이 남는 것이 가장 나쁜 패턴입니다.

절차 3: 7에서 실행 테스트. 인벤토리한 각 스크립트를 pwsh로 실행해, 도는지·출력 파일이 깨지지 않았는지를 확인합니다. 7은 5.1과 공존하므로, 운영 중인 작업을 멈추지 않고 테스트할 수 있는 것이 side-by-side 설계의 이점입니다.² 오류가 나면 4장의 호환성 문제(모듈, .NET API, 동작 변경)를 나눠 봅니다.

「됐다」의 기준을 정해 두지 않으면 테스트가 끝나지 않으므로, 합격 조건을 체크리스트로 만들어 둡니다.

• pwsh -NoProfile -File <스크립트>가 끝까지 돌고, $LASTEXITCODE가 0으로 끝난다
• 오류 스트림에 아무것도 나오지 않는다(예상된 경고는 내용을 확인하고 허용한다)
• 의존 모듈이 모두 7에서 로드된다(Import-Module이 통과한다. 호환 기능으로 넘어가지 않았는지도 본다)
• 출력 파일 내용이 5.1 판과 일치한다(아래 Compare-Object)
• 출력 파일 인코딩이 수신 측 기대와 같다(3장. Shift_JIS를 전제로 한 연동 대상이 있으면 필수)
• 변경을 수반하는 처리는 -WhatIf로 대상이 5.1일 때와 같은지 확인했다
• 실행 시간이 극단적으로 늘지 않았다(호환 기능을 타면 느려지는 경우가 있다)

출력 비교는 같은 스크립트를 5.1과 7 양쪽에서 돌려 차이를 보는 것이 확실합니다.

# 5.1과 7에서 같은 스크립트를 실행하고, 출력 파일을 비교한다
& "$Env:windir\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -File .\daily-report.ps1
Move-Item .\report.csv .\report-51.csv -Force
& "$Env:ProgramFiles\PowerShell\7\pwsh.exe" -NoProfile -File .\daily-report.ps1
Move-Item .\report.csv .\report-7.csv -Force

# 행 단위 차이. 실행 일시처럼 매번 바뀌는 열이 있으면, 그 열을 빼고 비교한다
Compare-Object (Get-Content .\report-51.csv) (Get-Content .\report-7.csv)

# 바이트 단위로 일치하는지도 본다(BOM이나 줄바꿈 코드 차이는 여기서 드러난다)
(Get-FileHash .\report-51.csv).Hash -eq (Get-FileHash .\report-7.csv).Hash

차이가 나면 먼저 「값이 다른지」「겉모습은 같고 바이트열만 다른지」를 가릅니다. Compare-Object에서는 차이가 없고 Get-FileHash만 불일치라면, 원인은 인코딩 또는 줄바꿈 코드 차이(3장)입니다. 마이그레이션 완료의 정의는 「7에서 예외 없이 끝나는 것」이 아니라, 「5.1일 때와 같은 결과물이 나오는 것」에 두십시오.

절차 4: 어느 쪽에서 실행할지 명시. 테스트에 통과한 것에는 #Requires -Version 7.0을, 5.1에 남길 것에는 #Requires -PSEdition Desktop을 추가합니다(5장).

절차 5: 시작 명령 업데이트. 작업 스케줄러의 동작을 바꿉니다. 여기를 빼먹으면 「7로 옮겼다고 생각했는데 5.1로 계속 돈다」가 발생합니다.

# 변경 전(5.1에서 실행된다):
#   powershell.exe -NoProfile -ExecutionPolicy RemoteSigned -File C:\scripts\daily-report.ps1
# 변경 후(7에서 실행된다):
#   "C:\Program Files\PowerShell\7\pwsh.exe" -NoProfile -File C:\scripts\daily-report.ps1

참고로 pwsh.exe는 첫 번째 위치 지정 매개변수가 -Command에서 -File로 바뀌었습니다. powershell.exe -Command "..."에 해당하는 호출을 기계적으로 치환하면 해석이 달라지므로, -File / -Command를 반드시 명시하십시오.⁴

실행 정책과 스크립트 서명 취급은 같이 공개한 「PowerShell의 실행 정책과 스크립트 서명」을, 배치 파일(.bat)에서의 이전 판단은 「배치를 PowerShell로 옮겨야 하는가」를 참고하십시오.

7. 실무의 정석(판단표)

8. 정리

• 5.1과 7은 별개 제품이며, side-by-side로 공존합니다. 7을 넣어도 기존 구성은 깨지지 않지만, 반대로 시작 명령을 바꾸지 않는 한 마이그레이션은 전혀 되지 않습니다.
• 5.1은 신기능 추가 없음·지원은 Windows 본체에 묶인 현상 유지 모드이고, 7이 개발의 중심입니다. 신규는 7 기준으로 작성합니다.
• 일본어 환경에서 가장 큰 함정은 기본 인코딩 차이(5.1은 제각각, 7은 BOM 없는 UTF-8)입니다. 입출력의 -Encoding 명시와, 스크립트의 BOM 포함 UTF-8 저장으로 막습니다.
• 7에서 동작하지 않는 모듈은 Windows 호환 기능으로 살릴 수 있지만, 직렬화된 값만 돌아오는 제약이 있습니다. 무리가 되면 해당 처리만 5.1에 남깁니다.
• #Requires와 $PSVersionTable로 「어느 쪽에서 동작하는 스크립트인지」를 코드에 명시하고, 의도하지 않은 버전에서의 실행을 막습니다.
• 마이그레이션은 인벤토리 → 7 설치(MSI/winget) → 실행 테스트 → #Requires 부여 → 작업 스케줄러의 시작 명령 업데이트, 의 단계 방식으로 진행합니다.

관련 글

• PowerShell 명령의 기본 ── 먼저 익힐 조작과 안전한 사용법
• PowerShell 스크립트 응용 ── 로그 조사·아카이브·리포트화를 안전하게 자동화하기
• PowerShell로 Excel·CSV 업무 처리를 자동화하기 ── 집계·대조·장표 출력의 실무 레시피
• VBScript 폐지에 대비하는 VBA·사내 도구 점검 가이드
• .NET Framework에서 .NET으로 이전하기 전 체크리스트
• 배치를 PowerShell로 옮겨야 하는가

관련 상담 영역

합동회사 코무라소프트는 사내 스크립트 자산의 인벤토리와 PowerShell 7로의 단계 마이그레이션 계획·실시, 5.1 전용 모듈에 의존하는 처리의 분리, 「옮겼더니 문자가 깨졌다·동작하지 않게 됐다」 같은 장애 조사를 다룹니다.

• 레거시 자산 마이그레이션
• Windows 환경의 최신화·유지보수
• 기술 상담·설계 리뷰
• 문의

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

Windows PowerShell 5.1과 PowerShell 7은 무엇이 다른가요?

별개 제품입니다. 5.1은 Windows에 기본 포함되어 .NET Framework 위에서 동작하며, Microsoft는 신기능 추가를 종료했고 지원은 Windows 본체의 수명 주기를 따릅니다. 7은 .NET(구 .NET Core) 위에서 동작하는 별도 설치 제품으로, 현재 개발의 중심입니다. 7은 5.1을 대체하지 않고 다른 디렉터리에 설치되어 side-by-side로 공존하며, 실행 파일 이름도 powershell.exe와 pwsh.exe로 구분됩니다.

PowerShell 7을 설치하면 기존 5.1 스크립트가 깨지나요?

깨지지 않습니다. 7은 다른 디렉터리(기본값은 Program Files\PowerShell\7)에 설치되고, 모듈 위치와 프로필도 5.1과 따로 관리됩니다. 작업 스케줄러 등에서 powershell.exe를 실행하는 기존 구성은 이전과 같이 5.1로 계속 동작합니다. 그래서 반대로, 7을 넣기만 해서는 마이그레이션이 전혀 되지 않는다는 점에 주의해야 합니다. 7에서 실행하려면 시작 명령을 pwsh.exe로 명시적으로 바꿔야 합니다.

PowerShell 7에서 기존 스크립트의 문자가 깨지는 이유는 무엇인가요?

기본 문자 인코딩이 달라졌기 때문입니다. 5.1은 cmdlet마다 기본값이 다르고(Out-File은 UTF-16LE, Get-Content는 ANSI 등), 7은 모두 BOM 없는 UTF-8입니다. 일본어 환경에서는 Shift_JIS를 전제로 한 파일 연동이 많아서, 기본값 그대로 옮기면 읽기와 쓰기 모두에서 깨질 수 있습니다. 파일 입출력에 -Encoding을 명시하고, 비ASCII 문자가 들어간 스크립트 자체는 BOM 포함 UTF-8로 저장하면 거의 막을 수 있습니다.

PowerShell 7에서 동작하지 않는 모듈은 어떻게 하면 되나요?

먼저 7에서 그대로 Import-Module 해서 동작하는지 확인합니다. 동작하지 않으면 Windows 호환 기능(Import-Module -UseWindowsPowerShell)으로 백그라운드 5.1 프로세스에 모듈을 로드한 뒤, remoting을 통해 7에서 사용할 수 있습니다. 다만 돌아오는 것은 직렬화된 객체라 메서드를 호출할 수 없고, 로컬 Windows에서만 동작하는 제약이 있습니다. 제약에 걸리는 처리는 무리하지 말고 그 부분만 5.1에 남겨 두는 편이 현실적입니다.

사내 스크립트를 5.1에서 7로 어떻게 옮기면 되나요?

한 번에 바꾸지 말고 단계적으로 마이그레이션합니다. 먼저 작업 스케줄러와 스크립트 보관 위치에서 .ps1을 인벤토리하고, 각각을 7(pwsh)로 실행해 봅니다. 통과한 것부터 #Requires -Version 7을 넣고, 작업 스케줄러의 시작 명령을 powershell.exe에서 pwsh.exe로 바꿉니다. 5.1에서만 동작하는 것은 무리하게 옮기지 않고, 어느 쪽에서 실행해야 하는지를 명시한 채 남겨 둡니다. 7 자체는 MSI 또는 winget으로 설치하고, 업데이트 배포 방법도 함께 정해 둡니다.

저자 프로필

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

Go Komura

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

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