몇 년 전, 저는 PowerShell의 리눅스와 닮은 특성에 감탄하며 한 편의 글을 쓴 적이 있습니다. 당시에는 재미있는 애니메이션도 곁들였죠. 그리고 시간이 흘러 마이크로소프트는 PowerShell을 오픈소스로 공개했고, 놀랍게도 리눅스용으로도 출시했습니다. 현재는 초기 테스트 버전을 이용해 볼 수 있습니다.
저는 이 움직임을 여러 가지 이유로 반기고 있습니다. 개발과 시스템 유지보수의 공통 기반이 넓어지기 때문입니다. 이미 윈도우에서 Bash를 사용할 수 있게 된 것과 맞춰 보면, 양측의 노력이 멋지게 거울처럼 대응하고 있음을 알 수 있습니다. 장기적으로 두 운영체제가 더 효과적으로 협력하게 될 것이며, 그 진정한 수혜자는 시스템 관리자와 개발자, 나아가 일반 사용자일 것입니다. 그럼 실제로 어떻게 작동하는지 살펴보겠습니다.
PowerShell 설치하기
테스트 환경은 CentOS 7.2 Xfce 머신으로, 공식적으로 지원되는 리눅스 배포판 중 하나입니다. 마이크로소프트는 현재 우분투(두 세대의 LTS 버전 포함)와 CentOS용 설치 패키지를 제공합니다. 다운로드 페이지에서 패키지를 찾는 과정이 약간 복잡할 뿐, 설치 자체는 매우 간단합니다. yum으로 로컬 설치한 뒤 명령줄에서 실행하면 됩니다.
yum install powershell-6.0.0_alpha.9-1.el7.centos.x86_64.rpm
이제 무엇을 할까?
저는 PowerShell의 고급 사용자는 아니지만, 어차피 셸(shell)인 만큼 문법만 익히면 바로 활용할 수 있습니다. 그렇다면 Bash 같은 셸을 완전히 대체할 수 있을까요? 솔직히 그렇지는 않습니다. 하지만 그것이 중요한 게 아닙니다. 일단 몇 가지 기본 명령어를 입력해 보며 감각을 익혀 보았습니다.
처음에는 리눅스 사용자에게 사용 방식이 다소 낯설게 느껴질 수 있습니다. 그래도 핵심 원리는 같습니다. 현재 PowerShell 구현의 단점 하나를 꼽자면 색상 설정입니다. 흰색 배경 위의 노란 글씨는 가독성이 좋지 않으므로, 다른 터미널 테마를 적용하는 것이 좋습니다.
막힌다면 언제든 help <명령어>로 도움말을 호출할 수 있고, 더 좋은 방법은 get-help <명령어> -examples를 사용해 올바른 문법과 실제 사용 예시를 확인하는 것입니다. 이 기능이 꽤 유용합니다. 명령어는 대소문자를 구분하지 않지만, 일부 공식 표기에서는 대문자가 사용됩니다.
일부 명령(cmdlet)은 축약형도 제공합니다. 예를 들어 Get-ChildItem은 UNIX의 find에 해당하는 기능인데 이름이 직관적이지 않으며, gci로 줄여 쓸 수 있습니다. 처음에는 조금 헷갈릴 수 있지만 크게 어렵지는 않습니다.
gci -path /* -include "igor" -recurse
또 하나 혼란스러울 수 있는 점은 경로 처리 방식입니다. 루트 디렉터리는 물론 슬래시(/)로 표시하지만, 경로 관련 대부분의 명령이 정상 동작하려면 슬래시 뒤에 별표(*)를 붙여야 합니다. 참 신기하죠. 저 역시 여러분과 마찬가지로 한 걸음씩 배워가는 중입니다.
필요한 기능은 모두 갖춰져 있습니다. 겉모습과 이름은 다르지만 실제로 잘 작동합니다. 셸 자체도 상당히 안정적이었고, 단 한 번 예외가 있었습니다. 아주 깊은 재귀 파일 검색의 소요 시간을 측정하는 도중 PowerShell이 멈춰 버린 것입니다. 실행이 정지했지만 강제로 중단할 수는 있었습니다.
오류 메시지
PowerShell은 매우 장황하고 오류를 자주 출력합니다. 빨간색 텍스트와 길게 늘어진 오류 블록 때문에 윈도우에서처럼 다소 불길해 보일 수 있습니다. 하지만 실제로는 명령줄에서 파일 검색 중 발생하는 권한 거부(permission denied) 같은 무해한 메시지가 대부분입니다.
또 다른 예로, measure-command cmdlet(리눅스의 time과 유사한 기능)은 인수를 중괄호({})로 묶어야 합니다. 이를 누락하면 상당히 극적인 듯한 커다란 오류가 출력되지만, 실제로는 전혀 위험하지 않습니다. 다른 많은 cmdlet도 마찬가지입니다.
위 이미지는 오류 메시지의 상단 절반에 불과합니다. 아래로 더 이어집니다.
Fedora 사용자라면?
마이크로소프트가 우분투와 CentOS용 PowerShell을 출시했다면, Fedora에서도 될까요? 사실 궁금해할 필요 없이 직접 테스트해 보았습니다. 결과는 기대만큼 순탄하지 않았습니다. 설치 직후 PowerShell을 실행하자 다음과 같은 오류가 발생했습니다.
powershell
Failed to initialize CoreCLR, HRESULT: 0x80131500
꽤 범용적인 오류 메시지이며, GitHub에 이 주제에 대한 긴 토론 스레드가 있습니다. 하지만 제안들을 무작정 따르기 전에, 문제가 libicu 의존성에 있다는 것을 먼저 확인하고 싶었습니다. 그래서 제 디버깅 무기고에서 가장 유용한 도구 중 하나인 strace의 힘을 빌렸습니다.
open("/usr/lib64/libicuuc.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
역시 몇 가지 라이브러리가 누락된 것으로 확인되었습니다. 문제는 해당 패키지가 Fedora에 존재하기는 하지만, PowerShell이 요구하는 버전보다 최신이라는 점입니다. 심볼릭 링크를 생성해 문제를 우회해 보았고, 이것이 어느 정도 도움이 되었습니다.
ln -s /usr/lib64/libicui18n.so.56 /usr/lib64/libicui18n.so.50
그 결과 오류가 일반적인 시작 실패에서 공유 객체 내부의 심볼 문제로 바뀌었습니다. 그리고 이것은 임의로 해결할 수 있는 종류의 문제가 아닙니다.
powershell
powershell: symbol lookup error: /opt/microsoft/powershell/6.0.0-alpha.9/System.Globalization.
Native.so: undefined symbol: uloc_getDefault_50
해결책은 구버전의 libicu를 다운로드해 임의의 위치에 압축을 풀고, PowerShell이 libicu 의존성을 우선적으로 찾아 사용하도록 라이브러리 경로를 설정하는 것입니다. 예를 들면 다음과 같습니다.
export LD_LIBRARY_PATH=<libicu-폴더>/:$LD_LIBRARY_PATH
결론
이렇게 해서 결론에 도달했습니다. 2016년, 이제는 윈도우에서 Bash를 네이티브로 실행할 수 있고, 리눅스에서도 PowerShell을 네이티브로 실행할 수 있습니다. Bob이 당신의 친구일 뿐만 아니라, 당신도 Bob의 친구가 된 셈이죠! 저는 이러한 변화를 반갑게 생각하며, 장기적으로 모두에게 이익이 될 것이라 확신합니다.
PowerShell이 저의 첫 번째 스크립팅 도구, 언어, 프레임워크 선택은 아니지만 분명한 장점이 있습니다. 특히 멀티 OS 환경을 관리해야 하는 사람들에게는 관리 업무를 크게 단순화해 줄 수 있습니다. 초기 알파 빌드도 테스트하기에 충분히 안정적이지만, 과도한 테스트는 권장하지 않습니다. 특히 root 권한으로 운영 중인 프로덕션 시스템에서의 사용은 피하는 것이 안전합니다. 전반적으로 꽤 괜찮은 결과입니다. 자, 이제 여러분 차례입니다. 키보드를 잡고 직접 만져 보세요.
즐거운 리눅스 되세요.