문서의 각 단락이 어느 리비전에서 마지막으로 수정되었는지 확인할 수 있습니다. 왼쪽의 정보 칩을 통해 작성자와 수정 시점을 파악하세요.

Windows PowerShell | |
개발사 | |
유형 | 명령 줄 셸 및 스크립트 언어 |
운영 체제 | |
관련 기술 | |
상태 | 유지보수 중 |
상세 정보 | |
대체 제품 | PowerShell Core |
관련 소프트웨어 | |


윈도우의 기존 명령 줄 인터페이스인 명령 프롬프트와 윈도우 스크립트 호스트의 한계를 극복하기 위해 마이크로소프트가 개발을 시작했다. 기존 도구들은 텍스트 기반 처리에 머물러 있었고, 복잡한 시스템 관리 작업을 자동화하기에는 기능이 부족했다. 이에 마이크로소프트는 2002년부터 "Monad"라는 코드명으로 새로운 셸 프로젝트를 추진하게 된다.
이 프로젝트의 핵심 목표는 강력한 자동화 기능과 일관된 관리 환경을 제공하는 것이었다. 이를 위해 .NET 프레임워크를 기반으로 하는 객체 지향 방식을 채택했다. 2006년 11월, Windows PowerShell 1.0이 윈도우 XP, 윈도우 서버 2003, 윈도우 비스타용으로 정식 출시되었다. 초기에는 별도 다운로드가 필요했으나, 이후 운영 체제에 점차 통합되기 시작했다.
Windows PowerShell 2.0은 윈도우 7과 윈도우 서버 2008 R2에 기본 포함되면서 보급이 크게 확대되었다. 이 버전에서는 원격 관리 기능이 강화되고 스크립트 디버깅 도구가 도입되는 등 중요한 발전이 이루어졌다. 이후 버전 업데이트를 거쳐 Windows PowerShell 5.1이 윈도우 10의 기본 셸로 자리 잡게 되었다. 이 역사적 배경을 통해 PowerShell은 단순한 명령 해석기를 넘어 포괄적인 구성 관리 및 자동화 플랫폼으로 진화해왔다.

Windows PowerShell의 핵심 설계 철학 중 하나는 기존의 텍스트 기반 파이프라인을 넘어선 객체 기반 파이프라인이다. 전통적인 유닉스 셸이나 명령 프롬프트에서는 한 명령어의 출력이 단순한 텍스트(표준 출력)로 다음 명령어의 입력(표준 입력)으로 전달된다. 이 방식은 후속 명령어가 필요한 데이터를 추출하기 위해 복잡한 텍스트 파싱(예: grep, awk, cut)에 의존해야 한다는 한계가 있다.
PowerShell의 파이프라인은 .NET 객체를 전달한다. 각 Cmdlet은 하나 이상의 객체를 출력하며, 이 객체는 속성과 메서드를 가진 채로 파이프라인을 통해 다음 Cmdlet으로 흐른다. 예를 들어, Get-Process Cmdlet은 실행 중인 각 프로세스에 대한 객체를 생성하며, 각 객체는 ProcessName, Id, CPU 같은 속성을 포함한다. 사용자는 이 객체의 속성을 직접 참조하거나, Where-Object나 Select-Object 같은 Cmdlet을 사용해 객체 스트림을 필터링하고 형식을 변경할 수 있다.
이 객체 기반 모델은 시스템 관리 작업을 훨씬 더 강력하고 직관적으로 만든다. 관리자는 데이터의 형식이나 레이아웃보다는 데이터 자체(객체)에 집중할 수 있으며, 복잡한 텍스트 처리 없이도 객체의 속성을 기준으로 정렬, 그룹화, 계산하는 것이 가능해진다. 이는 WMI나 COM 객체와 같은 복잡한 시스템 리소스를 조작할 때 특히 유용하다.
객체 기반 파이프라인은 또한 PowerShell의 확장성을 뒷받침한다. 개발자는 .NET Framework을 사용해 자신만의 객체를 생성하고 출력하는 사용자 정의 Cmdlet이나 함수를 쉽게 작성할 수 있으며, 이러한 사용자 정의 객체도 네이티브 Cmdlet과 동일한 방식으로 파이프라인에서 처리될 수 있다. 이로 인해 PowerShell은 시스템 관리, Active Directory 관리, Microsoft Azure 같은 클라우드 서비스 관리에 이르기까지 광범위한 자동화 시나리오의 핵심 도구로 자리잡게 되었다.
Cmdlet은 Windows PowerShell의 핵심 명령 단위이다. 이는 "Command-let"의 약자로, 기존 명령 프롬프트의 내장 명령어나 유닉스 셸의 실행 파일과는 다른 독특한 구조를 가진다. 각 Cmdlet은 .NET Framework 클래스로 구현된 단일 기능을 수행하는 경량 명령이다. 이 설계는 PowerShell이 객체를 기반으로 동작하도록 하는 토대를 제공한다.
Cmdlet의 이름은 "동사-명사" 형식을 엄격히 따른다. 동사 부분은 명령이 수행하는 작업(예: Get, Set, New, Remove)을 나타내고, 명사 부분은 작업이 적용되는 대상(예: Process, Service, Item)을 지정한다. 예를 들어, Get-Process는 프로세스를 가져오는 명령이며, Stop-Service는 서비스를 중지시키는 명령이다. 이 명명 규칙은 명령의 용도를 직관적으로 이해할 수 있게 한다.
Cmdlet은 파이프라인을 통해 객체를 주고받도록 설계되었다. 한 Cmdlet의 출력 결과가 객체로 생성되면, 이 객체는 파이프라인(|)을 통해 다음 Cmdlet의 입력으로 전달된다. 후속 Cmdlet은 이 객체의 속성을 직접 참조하여 필터링하거나 추가 작업을 수행할 수 있다. 이는 텍스트 기반 출력을 처리하는 기존 셸과의 근본적인 차이점이다.
사용 편의를 위해 PowerShell은 많은 Cmdlet에 대해 별칭을 제공한다. 예를 들어, Get-ChildItem Cmdlet은 dir이나 ls라는 별칭으로도 호출할 수 있다. 또한, -? 매개변수를 사용하거나 Get-Help Cmdlet을 실행하면 각 Cmdlet의 상세한 사용법과 예제를 확인할 수 있다.
Windows PowerShell은 .NET Framework에 깊이 통합되어 설계되었다. 이는 기존의 텍스트 기반 셸과는 근본적으로 다른 차별점으로, 모든 명령의 출력이 단순한 문자열이 아닌 .NET 객체로 처리된다는 점이다. 이러한 객체 기반 파이프라인은 시스템 관리 작업을 훨씬 더 강력하고 유연하게 만들어준다. 예를 들어, 프로세스 목록을 가져오는 Get-Process Cmdlet의 출력은 각 프로세스 정보를 담은 객체의 컬렉션이며, 이를 다른 Cmdlet에 전달하여 필터링하거나 정렬하는 것이 가능하다.
이 통합 덕분에 PowerShell 스크립트는 .NET Framework의 방대한 클래스 라이브러리를 직접 활용할 수 있다. 관리자는 C#이나 Visual Basic .NET과 같은 .NET 언어로 작성된 코드를 PowerShell 내에서 실행하거나, COM 객체 및 WMI 인스턴스를 쉽게 생성하고 조작할 수 있다. 이는 복잡한 시스템 정보 수집이나 애플리케이션 자동화와 같은 고급 작업을 수행하는 데 필수적인 기능을 제공한다. 결과적으로 PowerShell은 단순한 명령 해석기를 넘어서 완전한 기능을 갖춘 스크립팅 환경으로 자리 잡았다.
Windows PowerShell의 핵심 강점 중 하나는 강력한 스크립팅 및 자동화 기능이다. 이는 단순한 명령어 나열을 넘어서 복잡한 시스템 관리 작업을 프로그램 가능한 방식으로 처리할 수 있게 해준다. PowerShell 스크립트는 .ps1 확장자를 가지며, Cmdlet, 함수, 제어 흐름 문(예: if, for, foreach) 및 .NET 클래스를 직접 활용하는 코드를 포함할 수 있다. 이를 통해 관리자는 반복적이고 시간 소모적인 작업을 스크립트로 작성하여 일관되고 오류 없이 실행할 수 있으며, 작업 스케줄러와 연동하여 특정 시간이나 조건에 따라 자동으로 수행되도록 구성할 수 있다.
자동화 능력은 광범위한 관리 시나리오에 적용된다. 예를 들어, 여러 대의 서버에 소프트웨어를 배포하거나, 사용자 계정을 대량으로 생성 및 구성하며, 이벤트 로그를 분석해 특정 조건이 감지되면 경고를 발생시키는 것이 가능하다. PowerShell은 원격 관리를 기본적으로 지원하여, 한 컴퓨터에서 스크립트를 실행하면서 네트워크를 통해 다른 컴퓨터의 작업을 제어할 수 있다. 이러한 자동화는 IT 인프라 관리의 효율성을 극대화하고, 인간의 실수를 줄이며, 표준화된 운영 프로세스를 구축하는 데 기여한다.

PowerShell 콘솔은 Windows PowerShell의 기본 실행 환경으로, 명령 프롬프트와 유사한 검은색 창 인터페이스를 제공한다. 사용자는 이 콘솔에서 직접 Cmdlet을 입력하거나 스크립트를 실행하여 시스템을 관리할 수 있다. 이 콘솔은 자동 완성 기능과 명령어 히스토리 검색을 지원하여 사용 편의성을 높인다.
보다 강력한 스크립트 작성 및 디버깅을 위해 마이크로소프트는 PowerShell ISE를 제공했다. ISE는 통합 스크립팅 환경으로, 멀티 탭 스크립트 편집기, 구문 강조, 시각적 디버거 등의 기능을 포함한다. 이는 복잡한 자동화 작업을 개발하고 테스트하는 관리자에게 특히 유용한 도구였다.
그러나 Windows 10 이후, 마이크로소프트는 새로운 Windows Terminal 애플리케이션과 강력한 코드 편집기인 Visual Studio Code에 공식 PowerShell 확장을 제공하는 방향으로 전환했다. 결과적으로 PowerShell ISE는 더 이상 적극적으로 개발되지 않으며, 새로운 프로젝트에는 Visual Studio Code 사용이 권장된다. 현재 PowerShell 콘솔은 여전히 기본 실행 환경으로 유지되지만, 사용자는 Windows Terminal을 통해 더 현대적이고 구성 가능한 탭 인터페이스에서 PowerShell을 사용할 수 있다.
PowerShell은 사용자가 시스템과 상호작용하기 위해 사용하는 세 가지 주요 명령어 유형인 Cmdlet, 함수, 스크립트를 제공한다. 이들은 각각 다른 수준의 복잡성과 재사용성을 가지며, PowerShell의 강력한 자동화 기능을 구성하는 핵심 요소이다.
가장 기본적이고 핵심적인 명령어 유형은 Cmdlet이다. Cmdlet은 "Command-let"의 줄임말로, .NET 클래스로 컴파일된 경량 명령어이다. 모든 Cmdlet은 동사-명사 형식의 일관된 이름 규칙을 따르며, 예를 들어 Get-Process, Set-Location, Stop-Service와 같은 형태를 가진다. 이러한 구조는 명령어의 기능을 직관적으로 이해할 수 있게 한다. Cmdlet은 주로 파이프라인을 통해 객체를 주고받으며 작동한다.
함수는 사용자가 필요에 따라 직접 정의하여 만드는 명령어 블록이다. 함수는 스크립트 블록을 이름과 연결하여, 복잡한 작업을 하나의 간단한 명령어로 캡슐화할 때 유용하다. 함수는 현재 세션 내에서만 존재하는 메모리 기반 명령어로, 세션을 종료하면 사라진다. 반면에 스크립트는 .ps1 확장자를 가진 텍스트 파일에 저장된 PowerShell 명령어의 집합이다. 스크립트 파일은 디스크에 저장되어 반복적으로 실행하거나 다른 시스템으로 배포할 수 있으며, 보안 정책에 따라 실행이 제한될 수 있다.
명령어 유형 | 설명 | 주요 특징 |
|---|---|---|
Cmdlet | .NET으로 작성된 컴파일된 경량 명령어 | 동사-명사 명명 규칙, 객체 기반 파이프라인 |
함수 | 사용자가 정의하는 명령어 블록 | 세션 내에서 정의 및 사용, 로직 캡슐화 |
스크립트 |
| 파일 시스템에 저장, 재사용 및 배포 가능 |
이 세 가지 명령어 유형은 서로 보완적으로 작동한다. 자주 사용하는 함수는 스크립트 파일로 저장하여 프로필에 포함시킬 수 있으며, 복잡한 스크립트 내부에서는 핵심 작업을 위해 다양한 Cmdlet을 호출한다. 또한, 별칭(Alias) 기능을 통해 긴 Cmdlet 이름을 ls, dir, cp 같은 짧고 익숙한 이름으로 호출할 수 있어 사용 편의성을 높인다.
Windows PowerShell의 프로필은 사용자가 셸 환경을 개인화하고, 세션 시작 시 자동으로 실행되는 스크립트 파일이다. 이 파일은 주로 별칭(Alias)을 정의하거나, 자주 사용하는 함수(Function)를 로드하며, 환경 변수(환경 변수)를 설정하는 데 사용된다. 이를 통해 매번 반복적으로 입력해야 하는 초기화 명령을 자동화하여 작업 효율을 높일 수 있다.
프로필은 여러 위치에 존재할 수 있으며, 각각 다른 범위와 우선순위를 가진다. 주요 프로필 경로로는 현재 사용자 전용 프로필과 모든 사용자에게 적용되는 전역 프로필이 있다. 사용자는 $PROFILE이라는 자동 변수(Automatic Variable)를 통해 현재 세션에 적용되는 프로필 파일의 경로를 쉽게 확인할 수 있다. 프로필 파일이 존재하지 않을 경우, 사용자가 직접 생성해야 한다.
프로필 스크립트는 일반적인 PowerShell 스크립트(.ps1) 파일이므로, 여기에는 모든 유효한 Cmdlet, 함수, 변수 설정 코드를 작성할 수 있다. 일반적인 사용 예로는 Set-Alias를 이용한 명령어 단축 설정, 자주 사용하는 .NET 클래스 라이브러리를 미리 로드하는 작업, 또는 PowerShell 콘솔의 색상과 글꼴 같은 UI 설정 변경 등이 포함된다. 프로필을 효과적으로 관리하면 시스템 관리(시스템 관리) 및 자동화(자동화) 작업의 출발점을 표준화할 수 있다.

PowerShell Core는 기존 Windows PowerShell의 후속이자 오픈 소스, 크로스 플랫폼 버전이다. 마이크로소프트는 2016년 8월에 PowerShell을 오픈 소스로 공개하고, .NET Core 기반으로 재작성한 PowerShell Core의 첫 번째 공식 버전(버전 6.0)을 2018년 1월에 출시했다. 이로써 PowerShell의 실행 환경이 윈도우에 국한되지 않고 리눅스와 macOS에서도 공식적으로 지원되게 되었다.
주요 차이점은 기반 기술에 있다. Windows PowerShell(버전 5.1 및 이전)은 .NET Framework에 완전히 의존했기 때문에 윈도우에서만 실행 가능했다. 반면 PowerShell Core(버전 6.0 이후)는 .NET Core(현재의 .NET)를 기반으로 하여 다양한 운영 체제에서 동작할 수 있도록 설계되었다. 또한, PowerShell Core는 기존 Windows PowerShell 모듈과의 호환성 모드(WindowsPSCompatibility)를 제공하지만, 일부 오래되거나 .NET Framework에 깊게 의존하는 모듈과 Cmdlet은 동작하지 않을 수 있다.
버전 7부터는 마이크로소프트가 공식적으로 "PowerShell Core"라는 명칭 대신 단순히 "PowerShell"로 부르기 시작했다. 이는 .NET Core와 .NET Framework가 통합된 .NET 5 이상의 출시와 궤를 같이한다. PowerShell 7은 기존 Windows PowerShell 5.1의 많은 기능을 포용하면서도 성능과 보안이 개선된 장기 지원(LTS) 버전으로 자리 잡았다. 따라서 현대적인 시스템 관리 및 자동화 작업에서는 Windows PowerShell 5.1보다 PowerShell 7 이상의 사용이 권장된다.

Windows PowerShell은 윈도우 시스템 관리 및 구성 작업을 위한 핵심 도구이다. 기존 명령 프롬프트의 한계를 넘어, .NET 객체 모델을 기반으로 한 강력한 스크립팅 환경을 제공하여 관리자가 복잡한 작업을 자동화하고 시스템 상태를 효율적으로 제어할 수 있게 한다.
주요 시스템 관리 용도로는 서비스 관리, 프로세스 제어, 이벤트 로그 분석, 레지스트리 편집, 파일 시스템 작업 등이 있다. 예를 들어, Get-Service, Stop-Process, Get-EventLog와 같은 Cmdlet을 사용하면 서버 팜 전체의 상태를 원격으로 일괄 점검하거나 구성 변경을 스크립트로 배포하는 것이 가능하다. 또한 WMI와 CIM을 완벽하게 지원하여 하드웨어 정보 수집이나 시스템 설정을 세부적으로 조회 및 변경할 수 있다.
이러한 기능들은 특히 대규모 엔터프라이즈 환경에서 Active Directory 사용자 및 컴퓨터 객체 관리, 그룹 정책 적용 상태 확인, 네트워크 설정 구성 등에 광범위하게 활용된다. Windows PowerShell을 통한 자동화는 반복적이고 오류가 발생하기 쉬운 수동 작업을 줄여 IT 관리의 효율성과 정확성을 크게 향상시킨다.
Windows PowerShell은 마이크로소프트의 Active Directory 관리에 있어 핵심적인 도구이다. Active Directory는 윈도우 기반 네트워크 환경에서 사용자, 컴퓨터, 그룹 정책과 같은 디렉터리 서비스를 중앙에서 관리하는 서비스이다. PowerShell은 이 복잡한 인프라의 구성, 모니터링, 자동화 작업을 효율적으로 수행할 수 있도록 설계된 강력한 Cmdlet 모듈을 제공한다.
Active Directory 관리를 위한 주요 Cmdlet은 ActiveDirectory 모듈에 포함되어 있으며, 이를 통해 관리자는 스크립트를 작성하여 대량의 사용자 계정을 생성하거나 수정하고, 보안 그룹에 멤버를 추가하며, 조직 구성 단위를 관리할 수 있다. 예를 들어, Get-ADUser, New-ADUser, Set-ADUser 등의 명령어를 사용하면 GUI 도구인 Active Directory 사용자 및 컴퓨터 콘솔에서 수동으로 수행하던 작업을 자동화할 수 있어 시간을 절약하고 오류를 줄일 수 있다.
또한 PowerShell은 원격 관리 기능을 통해 도메인 컨트롤러에 직접 접속하지 않고도 네트워크를 통해 Active Directory 객체를 관리할 수 있다. 이는 클라우드 서비스 환경과의 통합에도 유용하며, 특히 Microsoft Azure의 Azure Active Directory와 같은 하이브리드 클라우드 환경 관리에도 PowerShell 스크립트가 광범위하게 활용된다. 따라서 Windows PowerShell은 현대적인 시스템 관리 및 IT 자동화에서 Active Directory를 효과적으로 제어하는 표준 도구로 자리 잡았다.
Windows PowerShell은 마이크로소프트의 클라우드 플랫폼인 Microsoft Azure를 관리하는 데 필수적인 도구로 자리잡았다. Azure 서비스의 광범위한 제어와 자동화를 위해 설계된 Azure PowerShell 모듈을 통해 관리자는 클라우드 컴퓨팅 인프라를 효율적으로 운영할 수 있다. 이 모듈은 수백 개의 전용 Cmdlet을 제공하여 가상 머신, 스토리지 계정, 가상 네트워크, 데이터베이스 등 거의 모든 Azure 리소스를 명령줄이나 스크립트를 통해 생성, 구성, 모니터링 및 삭제할 수 있게 한다.
Azure PowerShell의 핵심 강점은 복잡한 클라우드 관리 작업을 스크립트로 자동화할 수 있다는 점이다. 예를 들어, 특정 시간에 개발 환경을 자동으로 시작하거나 중지하거나, 여러 리소스를 일관된 설정으로 배포하는 인프라스트럭처를 코드로 관리하는 작업을 쉽게 수행할 수 있다. 또한 Azure Active Directory, 구독 및 역할 기반 액세스 제어를 관리하는 Cmdlet을 통해 보안과 거버넌스 정책을 적용하는 데도 적극적으로 활용된다.
PowerShell은 Azure CLI와 함께 Azure를 관리하는 두 가지 주요 공식 도구 중 하나이다. 두 도구 모두 동일한 Azure Resource Manager 백엔드를 사용하여 기능 면에서 동등하지만, PowerShell은 .NET 환경과 기존 Windows 관리 스크립트에 익숙한 관리자들에게 더 친숙한 선택지가 된다. 특히 대규모 엔터프라이즈 환경에서 기존 시스템 관리 스크립트와의 통합이 필요하거나, 객체 기반 출력을 선호하는 경우에 유용하다.
Azure 관리 외에도 PowerShell은 Microsoft 365 및 기타 마이크로소프트 클라우드 서비스 관리에도 광범위하게 사용된다. Exchange Online, SharePoint Online, Teams 등의 서비스를 관리하는 전용 모듈을 통해, 관리자는 하나의 스크립팅 환경에서 하이브리드 및 멀티 클라우드 환경을 포괄적으로 관리할 수 있는 능력을 갖추게 된다.

Windows PowerShell은 마이크로소프트의 명령 줄 셸로서, 명령 프롬프트와 비교했을 때 상당히 장황하고 복잡한 문법을 가진다는 특징이 있다. 이는 명령어의 동작을 직관적으로 파악할 수 있도록 설계된 결과로, 예를 들어 디렉터리 목록을 보는 명령은 Bash의 ls와 달리 Get-ChildItem이라는 긴 이름을 사용한다. 이러한 특성은 자동완성 기능 없이는 사용이 다소 번거로울 수 있어, 일부 사용자들 사이에서 '셸 계의 자바'라는 별명으로 불리기도 한다.
기본 제공되는 PowerShell 콘솔의 인터페이스는 심미성이 부족하다는 평가를 받아 왔다. 이를 보완하기 위해 oh-my-posh와 같은 테마 도구를 설치하여 프롬프트의 외관을 개선할 수 있다. 또한, Windows 11부터는 Windows Terminal이 기본 터미널 애플리케이션으로 제공되며, 이는 탭 지원과 다양한 사용자 정의 옵션을 통해 PowerShell을 포함한 여러 셸 환경을 더욱 편리하고 시각적으로 매력적으로 사용할 수 있게 해준다.
PowerShell 스크립트는 악성코드 제작자들에게도 자주 악용되는데, 이는 윈도우 시스템에 기본적으로 설치되어 있어 접근성이 높기 때문이다. 이러한 악성 스크립트는 종종 파일리스 공격 기법에 사용되어 실행 파일을 남기지 않고 메모리에서 직접 동작함으로써 백신 프로그램의 탐지를 회피하려 한다. 따라서 신뢰할 수 없는 출처의 PowerShell 스크립트 파일(.ps1)을 실행하는 것은 매우 위험할 수 있다.