PowerShell Remoting(WinRM) 입문 ── 여러 대의 Windows를 일괄 관리하기

「Windows Update 이후에 서버 20대가 전부 제대로 부팅되었는지 확인하고 와 줘」「전 거점 PC에서 그 설정값이 어떻게 되어 있는지 조사해 줬으면 해」── 이런 요청을 원격 데스크톱으로 한 대씩 로그인해서 확인하고 있지는 않습니까? 한 대에 3분이 걸려도 20대면 1시간입니다. 사람은 도중에 지치고, 확인 누락도 생깁니다.

PowerShell Remoting은 이 「여러 대에 같은 작업」을 명령 한 번으로 바꾸는 메커니즘입니다. Windows에는 WinRM이라는 원격 관리 기반이 기본 탑재되어 있으며, Windows Server에서는 기본적으로 활성화되어 있습니다. 즉 많은 현장에서는 추가 소프트웨어 없이 바로 쓸 수 있습니다. 그런데도 「왠지 두렵다」「워크그룹에서 연결이 안 돼서 포기했다」는 말을 자주 듣습니다.

이 글에서는 중소기업 정보시스템·운영 담당자를 대상으로, Remoting의 구조(무엇이 어느 포트에서 동작하고 누가 연결할 수 있는지)부터 Invoke-Command를 이용한 일괄 실행, 도메인 환경과 워크그룹 환경의 차이, second hop 문제 같은 잘 알려진 함정, 연결되지 않을 때의 원인 분리, 그리고 「읽기부터 시작하는」 안전한 운영까지 정리합니다.

전제로 하는 환경

• 연결을 받는 쪽: Windows Server 2012 이후 Windows Server에서는 PowerShell Remoting이 기본적으로 활성화되어 있습니다.¹ 클라이언트 Windows에서는 WinRM 서비스가 기본적으로 꺼져 있으므로 Enable-PSRemoting으로 켜야 합니다.¹
• 연결하는 쪽: 이 글의 명령 예는 Windows PowerShell 5.1과 PowerShell 7 양쪽에 있는 cmdlet만 사용합니다. 다만 WSMan: 드라이브와 Test-WSMan 같은 WS-Management 관련 cmdlet은 Windows의 PowerShell에서만 쓸 수 있습니다(Linux·macOS의 PowerShell에서는 6장의 SSH 기반 Remoting을 사용합니다).²
• 권한: 원격 쪽 설정 변경(Enable-PSRemoting, TrustedHosts, 리스너)은 모두 관리자로 실행한 PowerShell이 필요합니다.¹
• 네트워크: 도메인 환경과 워크그룹 환경을 모두 다룹니다. 차이는 3장에 정리했습니다.

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

1. 먼저 결론

• PowerShell Remoting은 WinRM(WS-Management 구현) 위에서 동작하며, 기본 포트는 HTTP 5985 / HTTPS 5986입니다. HTTP라도 통신 내용에는 인증 프로토콜에 의한 메시지 수준 암호화가 적용됩니다.³
• 연결할 수 있는 대상은 기본적으로 원격 쪽 Administrators 그룹 구성원뿐이며, 세션은 연결 사용자 컨텍스트에서 동작합니다. 「Remoting을 켰더니 누구나 들어온다」는 뜻이 아닙니다.³
• Enable-PSRemoting이 하는 일은 명확히 정의되어 있습니다. WinRM 서비스 시작과 자동 시작, 리스너 생성, 방화벽 예외, 세션 구성 활성화입니다. Windows Server에서는 기본적으로 켜져 있고, 클라이언트 Windows에서는 수동으로 켭니다.⁴³
• 도메인 환경은 Kerberos로 그대로 동작하고, 워크그룹은 NTLM + TrustedHosts + 명시적 자격 증명이 필요합니다. TrustedHosts는 「상대를 신뢰한다」는 설정이 아니라 「상대의 신원 확인을 포기하는 목록」이므로 최소한으로 좁힙니다.⁵³
• 일괄 실행은 Invoke-Command, 대화형 조작은 Enter-PSSession, 상태를 유지한 채 여러 번 쓰려면 New-PSSession입니다. Invoke-Command는 기본적으로 동시에 32대까지 병렬 처리합니다.⁶⁷
• 원격에서 돌아오는 것은 역직렬화된 객체이며 메서드가 없습니다. 작업은 ScriptBlock 안(원격 쪽)에서 끝내고, 로컬에서는 결과 집계만 합니다.⁸⁷
• 연결 대상에서 다시 다른 서버로는 접근할 수 없습니다(second hop 문제). 결함이 아니라, 자격 증명을 원격으로 보내지 않는 안전 설계의 결과입니다. 대응 방법은 여러 가지이며 요구 사항에 따라 고릅니다.⁹
• PowerShell 7에서는 SSH 기반 Remoting도 쓸 수 있습니다. Linux와 서로 관리해야 하거나 WinRM을 열고 싶지 않은 환경의 선택지가 됩니다.²

2. 동작 원리 ── WinRM 위에서, 누가, 어떻게 들어가는가

PowerShell Remoting의 기반은 WinRM(Windows Remote Management)입니다. WinRM은 표준 프로토콜 WS-Management의 Microsoft 구현이며, PowerShell Remoting은 이 WinRM을 통해 원격 컴퓨터의 PowerShell로 명령을 전달합니다.³ 통신은 기본적으로 HTTP 5985번, HTTPS 5986번 포트를 사용합니다.³⁵

「HTTP면 평문 아닌가」라는 걱정을 듣습니다만, 최초 인증이 끝난 뒤에는 WinRM이 통신을 암호화합니다. HTTPS에서는 TLS, HTTP에서는 인증 프로토콜이 협상한 메시지 수준 암호화(Kerberos라면 현재 환경에서 AES-256)입니다.³ 또한 연결할 수 있는 대상은 기본적으로 원격 쪽 Administrators 그룹 구성원뿐이며, 세션은 연결한 사용자 컨텍스트에서 실행되므로 파일이나 레지스트리 액세스 제어는 평소와 같이 적용됩니다.³

받는 쪽 준비는 Enable-PSRemoting입니다. 이 cmdlet이 하는 일은 공식 문서에 나열되어 있습니다. 내부에서 Set-WSManQuickConfig를 실행해 (1) WinRM 서비스 시작, (2) 시작 유형 자동화, (3) 임의의 IP 주소로 받는 리스너 생성, (4) WS-Management 통신의 방화벽 예외 활성화, (5) 세션 구성(엔드포인트) 생성·활성화와 원격 액세스 허용을 수행한 뒤 WinRM 서비스를 다시 시작합니다.⁴

# 연결을 「받는」 쪽에서, 관리자 권한 PowerShell로 한 번만 실행한다
# (Windows Server에서는 기본적으로 켜져 있어 보통은 불필요. 클라이언트 Windows에서 필요)
Enable-PSRemoting

# 연결하는 쪽에서 하는 통신 확인 ── 여기가 통과하면 Remoting 기반은 갖춰진 상태
Test-WSMan -ComputerName sv-app01

모르면 막히는 사양이 두 가지 있습니다. 첫째는 방화벽입니다. 서버 Windows에서는 Enable-PSRemoting이 공용 네트워크용으로도 「같은 서브넷에서만 허용」하는 규칙을 만들지만, 클라이언트 Windows에서는 네트워크 프로필이 공용이면 활성화 자체가 오류가 됩니다(테스트용 PC를 사내 Wi-Fi에 연결했을 때 흔히 겪는 문제입니다). 이 경우에는 -SkipNetworkProfileCheck를 붙이거나 프로필을 개인으로 바꿉니다.⁴

둘째는 PowerShell 버전과 엔드포인트의 관계입니다. Enable-PSRemoting은 「실행한 PowerShell 버전용」 엔드포인트를 구성합니다. PowerShell 7에서 실행해도 Windows PowerShell 5.1 엔드포인트에는 영향이 없고, 반대도 마찬가지입니다.⁴ 게다가 PowerShell 7에서 연결해도 기본적으로는 Windows PowerShell 5.1의 기존 엔드포인트(Microsoft.PowerShell)가 쓰이므로¹⁰, 「로컬은 7인데 원격에서 도는 것은 5.1이었다」는 일은 흔합니다. 원격 쪽에서 $PSVersionTable을 표시해 확인하는 습관을 들이십시오.

3. 도메인과 워크그룹 ── 인증의 벽은 여기에 있다

Remoting 입문에서 가장 자주 막히는 지점은 명령 문법이 아니라 인증입니다. 환경에 따라 필요한 준비가 달라집니다.

도메인 환경이면 Kerberos 상호 인증(클라이언트와 서버가 서로를 검증)이 동작하므로 Invoke-Command -ComputerName sv-app01 { ... } 가 그대로 통과합니다. 워크그룹에서는 Kerberos를 쓸 수 없어⁵ 연결하는 쪽 TrustedHosts에 상대를 등록합니다.

# 연결하는 쪽에서, 관리자로 실행한 PowerShell에서 실행(워크그룹에서만 필요)
# TrustedHosts 변경에도 관리자 권한이 필요하다. 기존 값은 덮어쓰이므로 먼저 현재 값을 확인한다
Get-Item WSMan:\localhost\Client\TrustedHosts

# 꼭 필요한 호스트 이름만 추가한다. -Concatenate가 없으면 기존 등록이 사라진다. '*'로 전부 허용하지 않는다
Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'sv-app01,sv-app02' -Concatenate

# 자격 증명을 명시해 연결 테스트
$cred = Get-Credential sv-app01\Administrator
Invoke-Command -ComputerName sv-app01 -Credential $cred -ScriptBlock { hostname }

여기서 중요한 것은 TrustedHosts의 의미입니다. 공식 문서는 「TrustedHosts에 올린 컴퓨터는 인증되지 않으며, 클라이언트가 자격 증명을 보내 버릴 수 있다」고 명시합니다.⁵ 즉 「신뢰할 수 있는 상대 목록」이라기보다 「서버 신원을 검증할 수 없다는 경고를 억누르는 목록」입니다.³ DNS나 ARP가 조작된 환경에서는 가짜 서버에 관리자 자격 증명을 넘기는 위험이 있습니다. 그래서 와일드카드 등록을 피하고, 고정 호스트 이름·IP만 최소한으로 올립니다. 본격적으로 운영하는 워크그룹 환경이나 DMZ에서는 인증서를 준비해 HTTPS(5986) 리스너를 구성하는 편이 맞다는 것이 실무 판단입니다.³

참고로 Get-Credential으로 받은 자격 증명을 스크립트에 평문으로 쓰기 시작했다면 경고 신호입니다. 자격 증명의 저장과 전달 정석은 함께 공개한 「PowerShell에서 자격 증명을 안전하게 다루기」에 정리했습니다.

워크그룹에서 또 하나 놓치기 쉬운 것이 비밀번호 유무입니다. 연결 대상 계정에 비밀번호가 설정되어 있지 않으면(빈 비밀번호) 원격 명령을 실행할 수 없습니다.¹

3.1. HTTPS(5986) 리스너를 구성하기

워크그룹이나 DMZ에서 상시 쓴다면 TrustedHosts로 끝내지 말고 HTTPS 리스너를 세웁니다. 절차의 뼈대는 다음과 같습니다.¹²

1. 서버 인증용 인증서를 준비합니다. 요건은 「로컬 컴퓨터의 서버 인증 인증서일 것」「CN(또는 주체 대체 이름)이 호스트 이름과 일치할 것」「유효 기간 안이고, 해지되지 않았고, 자체 서명이 아닐 것」입니다. 사내 CA가 있으면 https://<인증 기관 서버>/certsrv의 웹 등록에서 요청할 수 있습니다.
2. 인증서를 로컬 컴퓨터의 개인 저장소에 넣습니다. 확인은 인증서 스냅인(MMC에서 「인증서」를 추가하고, 마법사에서 「컴퓨터 계정」을 선택)의 인증서(로컬 컴퓨터) > 개인 > 인증서입니다.

3. HTTPS 리스너를 만듭니다. 손쉬운 방법은 다음 한 줄입니다.

    winrm quickconfig -transport:https
   

   인증서가 여러 장일 때 무엇을 쓸지 명시하려면 PowerShell에서 지문을 지정해 만들 수도 있습니다(지문은 Get-ChildItem Cert:\LocalMachine\My로 확인할 수 있습니다).

    New-Item -Path WSMan:\localhost\Listener -Address * -Transport HTTPS -CertificateThumbPrint '인증서의 지문' -Force
   

4. 방화벽에서 TCP 5986 수신을 허용합니다. Enable-PSRemoting이 만드는 규칙은 HTTP(5985)용이므로 HTTPS는 따로 필요합니다.

5. 리스너가 생겼는지 확인합니다.

    winrm enumerate winrm/config/listener
   

연결하는 쪽은 -UseSSL만 붙이면 됩니다.

Invoke-Command -ComputerName sv-app01.example.local -UseSSL -Credential $cred -ScriptBlock { hostname }

인증서 요건을 충족하지 못하면 리스너 생성 시 「Cannot create a WinRM listener on HTTPS because this machine does not have an appropriate certificate.(오류 번호 -2144108267 / 0x80338115)」가 납니다. 이때는 인증서 유효 기간, 발급 대상이 호스트 이름과 일치하는지, 향상된 키 사용에 「서버 인증」이 포함되는지, 인증 경로가 유효한지를 순서대로 확인합니다.¹²

4. Invoke-Command ── 「20대에 같은 일을 한다」의 기본형

Remoting의 주역은 Invoke-Command입니다. -ComputerName에 여러 대를 넘기고, -ScriptBlock에 「원격에서 할 일」을 씁니다.⁶ 먼저 읽기 전용 현황 파악부터 시작하는 것이 안전 운영의 철칙입니다.

$servers = 'sv-app01', 'sv-app02', 'sv-db01'

# 패치 적용 후 상태 확인 ── 읽기만 하므로 안심하고 실행할 수 있다
$result = Invoke-Command -ComputerName $servers -ScriptBlock {
    # 이 블록 안은 「원격 쪽」에서 실행된다
    $os = Get-CimInstance Win32_OperatingSystem
    [PSCustomObject]@{
        LastBoot   = $os.LastBootUpTime                      # 재시작이 끝났는지
        SpoolerRun = (Get-Service -Name Spooler).Status      # 업무에 필요한 서비스 상태
        FreeGB     = [math]::Round((Get-PSDrive C).Free / 1GB, 1)
    }
}

# 어느 결과가 어느 서버인지는 PSComputerName으로 알 수 있다
$result | Sort-Object PSComputerName |
    Select-Object PSComputerName, LastBoot, SpoolerRun, FreeGB |
    Export-Csv -Path .\patch-check.csv -NoTypeInformation -Encoding UTF8

각 서버 연결은 병렬로 처리되며, 기본 동시 실행 수(ThrottleLimit)는 32입니다.⁷ 결과는 도착한 순서대로 섞여 돌아오므로, 위 예처럼 자동으로 붙는 PSComputerName 속성으로 다시 정렬합니다.⁸

4.1. 변수를 넘기는 방법 ── $using: 과 -ArgumentList

ScriptBlock은 원격에서 실행되므로 로컬 변수는 그대로 보이지 않습니다. 값을 가져가는 방법은 두 가지입니다.¹³

$threshold = (Get-Date).AddDays(-30)

# 방법 1: $using: ── 호출 쪽 변수의 「값 복사본」을 원격에 넣는다
Invoke-Command -ComputerName $servers -ScriptBlock {
    (Get-ChildItem 'D:\AppLogs' -Filter *.log |
        Where-Object LastWriteTime -lt $using:threshold).Count
}

# 방법 2: -ArgumentList ── ScriptBlock 쪽 param으로 받는다(인자가 많을 때 읽기 쉽다)
Invoke-Command -ComputerName $servers -ScriptBlock {
    param($limit)
    (Get-ChildItem 'D:\AppLogs' -Filter *.log |
        Where-Object LastWriteTime -lt $limit).Count
} -ArgumentList $threshold

$using:으로 넘어가는 값은 원격 쪽에서는 독립된 복사본입니다. 원격에서 바꿔도 로컬 변수는 변하지 않습니다.¹³

4.2. 돌아오는 것은 「스냅샷」── 역직렬화된 객체

Remoting 결과에서 처음 당황하는 지점이 여기입니다. 살아 있는 .NET 객체는 네트워크를 넘지 못하므로, 원격 출력은 XML(CLIXML)로 직렬화되어 보내지고 로컬에서 역직렬화된 객체로 복원됩니다. 실행 시점 속성의 스냅샷이며 메서드가 없습니다.⁸⁷

예를 들어 Get-Service 결과를 로컬에서 받아 .Stop()을 호출할 수는 없습니다. 서비스를 멈추려면 ScriptBlock 안에서 Stop-Service를 실행합니다. 즉 작업은 원격에서 끝내고, 로컬로 가져오는 것은 보고용 데이터만 가져오는 역할 분리가 올바른 형태입니다. 속성 선별·가공·CSV화 같은 로컬 가공은 평소 PowerShell과 같은 감각으로 할 수 있습니다(이 부근의 기본 조작은 「PowerShell 명령의 기본」을 참고하십시오).

5. Enter-PSSession과 New-PSSession ── 대화와 재사용

한 대를 대화형으로 조사하려면 Enter-PSSession입니다. 프롬프트가 [sv-app01]: PS>로 바뀌고, 입력한 명령이 원격에서 실행됩니다. exit로 나갑니다.¹¹ 원격 데스크톱과 달리 화면은 가져오지 않지만, 「로그를 본다」「설정을 확인한다」 정도라면 이쪽이 빠르고, 연결에 Administrators 그룹 구성원이어야 하는 점은 같습니다.¹¹

한편 Invoke-Command를 -ComputerName으로 호출할 때마다 연결 수립과 해제가 매번 일어납니다.¹⁴ 같은 서버 무리에 명령을 여러 번 던지는 조사 작업에서는 New-PSSession으로 지속 세션을 만들어 재사용하는 편이 빠르고, 원격 쪽 변수나 상태도 명령 사이에 유지됩니다.¹⁴¹⁵

# 세션을 한 번만 열고, 변수 $s로 재사용한다
$s = New-PSSession -ComputerName $servers
try {
    # 1회째: 원격 쪽에 $hotfix 변수를 만든다
    Invoke-Command -Session $s { $hotfix = Get-HotFix | Sort-Object InstalledOn -Descending }

    # 2회째: 앞 명령에서 만든 변수를 그대로 쓸 수 있다(세션이 상태를 유지한다)
    Invoke-Command -Session $s { $hotfix | Select-Object -First 5 }
}
finally {
    # 도중에 오류나 중단이 있어도 반드시 해제한다(원격 쪽 리소스를 풀어 준다)
    Remove-PSSession $s
}

6. 함정 ── second hop, 그리고 SSH라는 선택지

6.1. second hop(더블 홉) 문제

현장에서 가장 유명한 벽이 이것입니다. 로컬 PC(A)에서 서버 B로 Remoting한 뒤, B 안에서 \\fs01\share(서버 C)를 읽으려 하면 액세스가 거부됩니다. 기본 Kerberos/NTLM 인증은 자격 증명 자체를 B로 보내지 않고 인증하는 안전한 방식이라, B가 사용자를 대리해 C에 인증할 수 없습니다.³⁹

대응은 여러 가지이며, 공식 문서가 권장 순서로 정리합니다.⁹ 주요한 것만 들면 다음과 같습니다.

• ScriptBlock 안에서 자격 증명을 명시적으로 넘긴다 ── 서버 쪽 구성 변경이 필요 없어 가장 손쉽습니다. $using:cred로 안쪽 Invoke-Command에 자격 증명을 넘깁니다.⁹ 다만 자격 증명 객체가 중계 서버(B) 세션으로 넘어가는 이상, B가 침해되면 넘긴 자격 증명도 쓰일 수 있으므로 B를 완전히 신뢰할 수 있는 경우에 한해, 넘기는 계정도 C 쪽에서 최소 권한만 가진 전용 계정으로 두는 것이 전제입니다.
• 리소스 기반 Kerberos 제한 위임 ── 자격 증명을 저장하지 않고, 접근 대상(C) 쪽에서 「B로부터의 위임을 받는다」고 구성하는 방식입니다. 도메인 관리자 권한 없이 구성할 수 있고, 보안과 구성 난이도의 균형이 좋은 선택지입니다.⁹
• JEA(Just Enough Administration) ── 「그 업무에 필요한 명령만」 허용한 전용 엔드포인트를 두고 권한을 좁히는 PowerShell 메커니즘입니다. 가상 계정을 쓰는 구성이면 사용자는 관리자가 아닌 자격 증명으로 연결하면서도 허용된 관리 명령만 실행할 수 있습니다.¹⁶ second hop 맥락에서는 중계 서버(B)에 관리자 자격 증명을 배포하는 대신, C 접근을 포함한 정형 작업만 실행할 수 있는 창구를 만드는 쓰임새입니다.⁹
• CredSSP ── 자격 증명이 원격 서버에 캐시되므로, 그 서버가 침해되면 자격 증명까지 도난됩니다. 기본적으로 꺼져 있으며, 활성화는 가장 신뢰할 수 있는 환경으로 한정해야 합니다.⁹

# 가장 손쉬운 우회: 안쪽 Invoke-Command에 $using:cred로 자격 증명을 넘긴다
# 바깥(sv-app01)에는 자기 자격 증명으로 연결하고, 안쪽에 넘기는 것은 fs01 쪽에서
# 최소 권한만 가진 전용 계정만 사용한다(관리자 자격 증명을 배포하지 않는다)
#
# 【전제】안쪽 호출은 「sv-app01에서 fs01로의 새 Remoting 연결」이므로 다음이 필요하다:
#   1. sv-app01에서 fs01로 WinRM(5985/5986)이 도달할 것
#   2. 워크그룹이나 IP 주소 지정이면 sv-app01 쪽 TrustedHosts에 fs01이 등록되어 있을 것
#   3. $cred가 fs01에서 유효한 계정(도메인 계정, 또는 fs01 로컬 계정)일 것
# 이를 확인하지 않고 복사해 쓰면 「로컬에서는 되는데 중계 서버에서는 실패한다」가 되기 쉽다
$cred = Get-Credential CONTOSO\svc-fileread
Invoke-Command -ComputerName sv-app01 -ScriptBlock {
    Invoke-Command -ComputerName fs01 -Credential $using:cred -ScriptBlock { hostname }
}

애초에 「B를 거쳐 C의 파일을 읽는다」가 아니라 로컬에서 C를 상대로 직접 Invoke-Command하는 구성이 가능한지를 먼저 생각하는 것이 가장 저렴한 해결입니다.

6.2. PowerShell 7이라면 SSH 기반 Remoting도 고를 수 있다

PowerShell 6.0부터는 WinRM 대신 SSH로 연결하는 Remoting을 쓸 수 있습니다. Invoke-Command / Enter-PSSession / New-PSSession에 -HostName, -UserName, -KeyFilePath라는 SSH용 매개변수 집합이 추가되어 있으며, Windows와 Linux를 넘나드는 관리가 됩니다.² 연결 대상에는 SSH 서버와 PowerShell SSH 서브시스템 구성이 필요하고, WinRM 기반에 있는 엔드포인트 구성이나 JEA 같은 기능은 현재 지원되지 않습니다.² Linux 서버가 섞인 환경이나 키 인증으로 운영을 맞추고 싶을 때의 선택지로 기억해 두면 좋습니다. Windows PowerShell 5.1에는 이 기능이 없으므로, 필요하면 이전 동기가 됩니다(차이의 전체 그림은 함께 공개한 「Windows PowerShell 5.1과 PowerShell 7의 차이」를 참고).

덧붙여 Remoting 세션은 RDP 같은 데스크톱 세션을 만들지 않습니다. 「원격에서 동작한다」는 의미가 둘에서 어떻게 다른지는 「Windows의 세션 분리를 어떻게 이해할까」에서 정리했습니다.

7. 연결되지 않을 때의 원인 분리

입문자가 Remoting을 포기하는 이유의 대부분은 「연결되지 않는다」입니다. 실패 원인은 서비스·리스너·방화벽·인증·권한 어디에나 있을 수 있습니다. 앞단부터 순서대로 원인을 제거하면 헤매지 않습니다.

7.1. 원인 분리 순서

1. 연결 가능 여부를 봅니다. 먼저 연결하는 쪽에서 Test-WSMan -ComputerName sv-app01. 여기가 통과하면 WinRM 서비스·리스너·방화벽까지는 살아 있습니다(인증이나 권한 문제는 남을 수 있습니다). 통과하지 못하면 아래로 갑니다.
2. 원격 쪽에서 WinRM 서비스가 동작 중인지. 서버 버전은 시작 유형이 자동이지만, 클라이언트 Windows에서는 WinRM 서비스가 기본적으로 꺼져 있습니다.¹ Get-Service WinRM으로 확인하고, 필요하면 Enable-PSRemoting(서비스 시작·자동 시작·리스너·방화벽 예외·세션 구성을 한꺼번에 설정)을 실행합니다.⁴

3. 리스너가 대기 중인지. 원격 쪽에서 다음을 실행해 ListeningOn이 비어 있지 않은지 봅니다. 비어 있으면 그룹 정책으로 리스너를 배포하는 환경의 설정 실수가 전형입니다.¹

    Get-WSManInstance winrm/config/listener -Enumerate
   

4. 네트워크 프로필을 봅니다. 클라이언트 Windows에서 네트워크가 공용이면 Enable-PSRemoting 자체가 「Unable to check the status of the firewall」로 실패합니다. 프로필을 개인으로 바꾸거나 -SkipNetworkProfileCheck를 붙입니다.¹
5. 방화벽 규칙을 봅니다. 서버 버전이라도 공용 프로필에서는 「같은 서브넷에서만 허용」하는 규칙이 됩니다. 다른 서브넷에서 들어오려면 규칙을 재검토해야 합니다(Get-NetFirewallRule로 규칙 이름을 확인한 뒤 변경하십시오. 규칙 이름은 Windows 버전마다 다릅니다).¹
6. 인증 방식 조건을 충족하는지. 워크그룹, 비도메인 가입, IP 주소 지정이면 Kerberos를 쓸 수 없고 NTLM이 되므로, TrustedHosts 등록(또는 HTTPS)과 -Credential 명시 지정이 필수입니다. 연결 대상 계정에 빈 비밀번호는 쓸 수 없습니다.¹
7. 연결할 권한이 있는지. 기본 엔드포인트에 연결할 수 있는 것은 원격 쪽 Administrators 구성원뿐입니다. 다른 도메인 사용자나 로컬 계정은 기본적으로 표준 사용자 토큰이 되므로 관리자로 동작하지 않습니다(필요하면 LocalAccountTokenFilterPolicy이지만, UAC의 원격 제한을 모든 사용자에 대해 끄는 설정이므로 영향을 이해한 뒤에).¹
8. 엔드포인트의 PowerShell 버전을 확인합니다. 연결은 됐는데 「그 cmdlet이 없다」는 말이 나오면, 2장에서 본 대로 Windows PowerShell 5.1 쪽 엔드포인트에 들어가 있을 수 있습니다. Invoke-Command -ComputerName sv-app01 { $PSVersionTable.PSVersion }로 확인하고, 필요하면 -ConfigurationName으로 명시합니다.¹⁰

7.2. 대표적인 오류 메시지 읽는 법

오류 문구는 거의 정형이라, 외우기보다 「이 문구면 여기를 본다」고 대응해 두는 편이 실용적입니다.¹

원인 분리의 요령은 「로컬 문제인지, 경로 문제인지, 상대 문제인지」를 하나씩 확정하는 것입니다. Test-WSMan 통과 여부로 경로와 상대 서비스까지를 가르고, 통과 후의 오류는 인증과 권한으로 좁힙니다. 이 두 단계로 보면 원인을 모른 채 설정만 만지는 일이 줄어듭니다.

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

마지막 행을 강조합니다. Invoke-Command는 「20대를 순식간에 고치는 명령」인 동시에 「20대를 순식간에 망가뜨리는 명령」입니다. 다행히 Stop-Service나 Set-ItemProperty 같은 변경 cmdlet의 상당수는 -WhatIf를 지원하며, ScriptBlock 안에서도 그대로 쓸 수 있습니다. 새 스크립트는 먼저 한 대에, 다음으로 -WhatIf를 붙여 전체 대수에, 마지막으로 실제 실행이라는 세 단계를 습관으로 두면 사고율이 눈에 띄게 내려갑니다.

9. 정리

• Remoting은 WinRM(WS-Management) 위에서 동작하며, 기본 포트는 HTTP 5985 / HTTPS 5986입니다. 연결할 수 있는 대상은 기본적으로 원격 쪽 Administrators 구성원뿐이며, 통신은 인증 후에 암호화됩니다.
• Enable-PSRemoting은 WinRM 서비스 시작·리스너 생성·방화벽 예외·세션 구성 활성화를 수행합니다. 실행한 PowerShell 버전용 엔드포인트가 구성된다는 점에 주의하십시오.
• 도메인은 Kerberos로 그대로, 워크그룹은 TrustedHosts + 명시적 자격 증명입니다. TrustedHosts는 신원 검증을 포기하는 목록이므로 최소한으로 둡니다.
• 일괄 실행은 Invoke-Command(기본 32 병렬), 대화형은 Enter-PSSession, 상태를 유지하려면 New-PSSession 재사용입니다. 결과는 메서드가 없는 역직렬화 객체이므로 작업은 원격에서 끝냅니다.
• 연결 대상에서 그 너머로는 닿지 않습니다(second hop). 먼저 자격 증명의 명시 전달, 상시 운영이라면 리소스 기반 Kerberos 제한 위임을 검토합니다.
• 「연결되지 않을」 때는 Test-WSMan으로 경로와 상대 서비스까지를 가른 뒤, 인증(TrustedHosts·자격 증명)과 권한(Administrators)으로 좁혀 봅니다. 대표적인 오류 문구와 대응처는 7장 표에 정리했습니다.
• 운영은 먼저 조회(읽기)부터. 변경은 한 대 → -WhatIf → 실제 실행의 세 단계로. 파일 서버 현황 파악에 응용하는 구체 예는 함께 공개한 「PowerShell로 파일 서버를 현황 파악하기」를 참고하십시오.

관련 글

• PowerShell 명령의 기본 ── 먼저 익힐 조작과 안전한 사용법
• PowerShell 실용 명령 모음 ── 일상 작업에서 자주 쓰는 작은 기능 늘리기
• PowerShell로 파일 서버를 현황 파악하기 ── 용량 조사와 액세스 권한(ACL) 감사
• PowerShell에서 자격 증명을 안전하게 다루기
• Windows의 세션 분리를 어떻게 이해할까 ── Session 0·RDP·여러 사용자 동시 실행
• Windows 위장 토큰을 올바르게 다루기 ── 스레드 단위 권한 차용과 안전한 되돌리기

관련 상담 영역

합동회사 코무라소프트에서는 PowerShell을 이용한 서버·클라이언트 일괄 관리 체계 구축, Remoting을 넣은 운영 스크립트의 설계·리뷰, 「연결되지 않는다」「특정 환경에서만 인증이 실패한다」와 같은 WinRM/인증 조사를 다룹니다.

• 기술 상담·설계 리뷰
• 결함 조사·원인 분석
• Windows 앱 개발
• 문의하기

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

Enable-PSRemoting을 실행하면 무슨 일이 일어나나요?

내부에서 Set-WSManQuickConfig가 실행되어 WinRM 서비스 시작과 시작 유형 자동화, 임의의 IP 주소로 요청을 받는 리스너 생성, WS-Management 통신의 방화벽 예외 활성화, 세션 구성(엔드포인트) 활성화와 원격 액세스 허용으로의 변경이 이루어집니다. Windows Server에서는 기본적으로 켜져 있지만, 클라이언트 Windows에서는 직접 실행해야 합니다. 연결을 받는 쪽에만 필요하며, 연결하는 쪽에서는 실행할 필요가 없습니다.

워크그룹 환경(도메인 없음)에서 PowerShell Remoting을 쓰려면 무엇이 필요한가요?

도메인이 없으면 Kerberos 인증을 쓸 수 없어 NTLM 인증이 됩니다. 연결하는 쪽에서 대상을 WSMan의 TrustedHosts 목록에 등록하고, -Credential로 자격 증명을 명시적으로 넘기는 것이 기본입니다. 다만 TrustedHosts에 올린 상대는 인증(위장 여부 검증) 없이 자격 증명이 전송될 수 있으므로, 와일드카드가 아니라 꼭 필요한 호스트 이름만 등록하고, 가능하면 HTTPS(5986) 리스너 구성을 검토하십시오.

Invoke-Command의 결과 객체에서 메서드를 호출할 수 없는 이유는 무엇인가요?

원격 명령의 출력은 네트워크로 보내기 위해 XML(CLIXML)로 직렬화되고, 로컬에서는 역직렬화된 객체로 복원되기 때문입니다. 실행 시점 속성의 스냅샷이며 살아 있는 객체가 아니므로 메서드가 없습니다. 서비스 중지 같은 작업은 로컬에서 메서드를 호출하는 것이 아니라 ScriptBlock 안(원격 쪽)에서 실행해야 합니다.

second hop(더블 홉) 문제란 무엇인가요?

PC A에서 Remoting으로 서버 B에 들어간 뒤, B에서 다시 다른 서버 C(파일 서버 등)에 접근하려 하면 거부되는 문제입니다. 기본 Kerberos/NTLM 인증은 자격 증명 자체를 B로 보내지 않으므로, B는 사용자를 대신해 C에 인증할 수 없습니다. 대응으로는 ScriptBlock 안에서 자격 증명을 명시적으로 넘기는 방법, 리소스 기반 Kerberos 제한 위임, CredSSP(자격 증명이 원격 쪽으로 넘어가므로 위험이 커짐) 등이 있으며, 요구 사항에 따라 고릅니다.

PowerShell Remoting에는 누구나 연결할 수 있나요?

아니요. 기본적으로는 원격 컴퓨터 Administrators 그룹 구성원만 연결할 수 있습니다. 연결 후 세션은 연결한 사용자 컨텍스트에서 동작하므로 OS 액세스 제어는 그대로 적용됩니다. 다만 관리자에게는 강력한 진입점이므로, 방화벽 규칙 재검토, HTTPS 리스너, 필요한 관리자로만 제한하는 다층 방어와 함께 운영하십시오.

저자 프로필

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

Go Komura

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

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