제프리 스노버의 PowerShell 개발 이야기

• Jeffrey Snover는 Windows를 명령줄로 관리 가능한 서버 OS로 만들기 위해 PowerShell을 추진했고, GUI 중심이던 Microsoft 문화와 조직 저항을 넘어서야 했음
• 초기의 UNIX 도구 이식은 Windows가 파일보다 Registry, Active Directory, WMI 같은 API에 의존하는 구조라 서버 관리 문제를 풀지 못함
• WMIC에서 WMI 기반 명령 70개를 만든 뒤, 테스트 병목과 비용 문제를 줄이기 위해 메타데이터 기반 명령 생성 엔진으로 방향을 바꿈
• PowerShell의 전신 Monad는.NET과 Longhorn 흐름을 타고 출발했지만, Longhorn 리셋 뒤 Windows에서 밀려났고 Exchange 팀과 Windows Server 조직의 지원으로 되살아남
• Snover는 직급과 보상 손실을 감수하며 PowerShell 1~4에 집중했고, 이 도구는 Windows 관리 자동화와 Office 클라우드 전환의 기반이 됨

---

GUI 중심 Windows와 데이터센터 관리 문제

• PowerShell은 Windows 시스템 관리를 바꾼 명령 도구였지만, Microsoft 내부에서 처음부터 자연스럽게 받아들여진 프로젝트는 아니었음
• 당시 Microsoft 문화는 GUI 중심이었고, Bill Gates가 command.exe를 마지막으로 보게 될 것이라고 말한 일화가 나올 정도로 명령줄 인터페이스는 낡은 것으로 취급됨
• Snover가 Microsoft에 합류한 출발점은 Windows NT 기반 OS를 데이터센터와 엔터프라이즈 시장에 맞게 바꿔야 한다는 문제의식이었음
  • 목표는 Sun, IBM, HP 같은 UNIX 벤더와 경쟁하는 것이었음
  • Intel과 개방형 하드웨어 생태계는 비용 면에서 장점이 있었지만, 서버 관리 소프트웨어는 충분히 좋지 않았음

시스템 통합업체 의존을 줄이는 관리자 모델

• Windows 서버 관리는 많은 서버를 클릭으로 설정해야 했고, 기업마다 필요한 구성이 달라 시스템 통합업체 의존이 커질 수 있었음
• Snover는 통합업체 비용이 커지면 Windows의 가격 우위가 사라진다고 봄
  • 예시로 하드웨어 10, 소프트웨어 2, 시스템 통합업체 40이라는 비용 구조를 들었음
  • 고객 관계와 가치가 통합업체로 넘어가는 것도 문제였음
• 대안은 UNIX식 프로그래머 관리자 모델이었음
  • 작은 도구를 조합해 고유한 문제를 해결하고 자동화하는 방식임
  • Windows에도 “다음 버튼만 누르는 관리자”가 아니라 스크립트와 자동화를 다루는 전문 관리자층이 필요했음

UNIX 도구 이식이 맞지 않았던 이유

• 초기 해법은 Windows Services for Unix로 Windows에 UNIX 셸과 AWK/GREP/SED 같은 도구를 올리는 것이었음
• 하지만 Windows의 관리 구조는 UNIX와 달랐음
  • UNIX는 파일 중심 OS라 파일을 조작하고 프로세스를 재시작하면 많은 관리 작업을 처리할 수 있음
  • Windows는 Registry, Active Directory, WMI 등 API 뒤에 기능이 있는 구조였음
  • AWK는 Registry에, SED는 Active Directory에, GREP은 WMI에 직접 맞지 않았음
• WMI는 관리 작업을 위한 가능성이 있었지만 널리 쓰이지 않았고, Snover의 팀은 WMI 객체를 다루는 명령줄 도구를 만들려 함

WMIC와 메타데이터 기반 엔진

• Windows XP 시기에는 코딩 창이 10주뿐이라는 제약 속에서 WMI 기반 명령줄 인터페이스를 만들어야 했음
• 계약 엔지니어를 활용해 70개 작업을 구현했지만, Windows 서버 전체 관리에 필요한 범위에는 턱없이 부족했음
• Microsoft 내부에서는 테스트 조직이 승인하지 않으면 기능이 출시되지 않는 구조였고, 명령이 늘어날수록 테스트 병목도 커졌음
• Snover는 HTML과 브라우저의 관계처럼, 개별 명령을 코드가 아니라 메타데이터로 보고 공통 엔진만 테스트하는 방식을 밀어붙임
  • 엔진이 명령을 생성하고, 각 명령의 설정은 XML 같은 형식의 메타데이터로 표현하는 접근이었음
  • 그는 크리스마스 휴가 동안 메타데이터를 작성해 72개 명령을 만듦
  • 기존 70개 명령에는 약 400만 달러가 들었고, 엔진에는 약 6만 달러가 들었다고 회고함
• 엔진에 필터링과 포맷팅 같은 기능을 추가하자 모든 명령이 함께 좋아졌고, 이는 PowerShell 아키텍처의 중요한 전조가 됨

Longhorn, .NET, Monad

• Bill Gates는 Windows 98 사용자가 XP로 잘 옮겨가지 않는 문제를 보고, Longhorn을 새로운 Windows 95 같은 전환점으로 만들려 했음
  • Longhorn에는 .NET 기반 개발 방식, WPF, WCF, 새 저장소 모델 등이 포함될 예정이었음
• Snover는 .NET이 Windows 관리 범위를 넓히는 수단이 될 수 있다고 판단함
  • WMI 제공자 작성은 충분한 동력을 얻지 못했지만, Bill Gates는 .NET 채택을 강하게 밀고 있었음
  • .NET 위에 관리 유틸리티를 올리면 더 넓은 커버리지를 얻을 수 있다고 봄
• 다른 조직에서 K-shell을 포팅해 셸을 만들려 하자, Snover는 더 나은 접근을 설명했지만 설득에 실패함
• 그는 방에 틀어박혀 약 1만 줄짜리 프로토타입을 만들었고, 여기에 PowerShell의 핵심 아키텍처 원칙이 들어 있었음
  • 시연 뒤 해당 팀이 아이디어를 받아들였고, Snover는 이것이 자신의 최고의 아이디어일 수 있다고 생각함
  • 이 프로젝트에 참여하기 위해 수백~천 명 규모 제품·서비스의 chief architect 역할을 내려놓았고, 사실상 강등을 감수함

Monad Manifesto와 팀 설득

• 새 팀은 프로젝트 이름을 Monad로 정했고, 인력이 부족해 일부 작업을 인도에 외주화했음
• Snover는 프로젝트 비전과 성공 경로를 맞추기 위해 Monad Manifesto를 작성함
  • 문제, 기존 접근, 새 접근, 가치, 차별점을 정리함
  • 관리자, 제공자, 개발팀 등 이해관계자별로 어떤 가치를 제공하는지 명확히 함
• Microsoft 각 팀은 해야 할 일이 많았고, 명령줄 인터페이스를 만들지 않아도 해고되지 않으며 만들어도 승진으로 이어지지 않는 상황이었음
• Monad의 제안은 각 제품팀이 자기 객체를 조작하는 코드만 작성하고, 나머지는 PowerShell이 제공한다는 것이었음
  • 포맷팅, 정렬, 필터링, 파서, 원격 실행, 권한 상승 등은 PowerShell 쪽에서 제공함
  • 각 팀은 자기 도메인 객체를 어떻게 조작할지만 알려주면 됨
• Active Directory 팀은 몇 주를 투자해 cmdlet 몇 개를 만들었고, 사용자 그룹 반응이 강하자 더 많은 작업을 진행하게 됨

Longhorn 리셋 뒤 Windows로 돌아가기

• Longhorn에서는 .NET 도입이 과도하게 추진되며 문제가 커졌음
  • 예시로 Notepad의 Save As 대화상자가 .NET/WCF 기반 공용 대화상자 때문에 1분 30초 뒤 뜨고, 작업 세트가 15KB에서 15MB로 늘어나는 상황이 있었음
  • 야간 빌드가 약 7개월 동안 동작하지 않았다는 회고도 나옴
• Windows 조직은 리셋을 하며 .NET 코드를 Windows에서 빼냈고, PowerShell도 Windows 밖으로 밀려남
• 이후 PowerShell은 명령줄 인터페이스이자 .NET 기반이라는 이유로 반복적인 취소 압박을 받음
  • Bill Gates는 가치를 이해했지만 일상적인 방어에는 도움이 되지 않았음
  • Windows Server 책임자는 중요한 순간에 지원했음
  • Exchange 팀은 PowerShell에 의존하는 “수십억 달러 규모 사업”을 내세워 취소를 막는 역할을 함
• Windows에 .NET을 넣기 위한 WinArch 요구사항은 매우 엄격했지만, PowerShell 팀은 모든 조건을 충족하도록 준비함
• Windows 책임자가 요청 철회를 요구하자 프로그램 매니저는 정식 거부를 요구했고, 그 결과 검토 절차가 열림
  • Windows Server 조직이 이 결정권을 가졌고, PowerShell이 요구사항을 충족한다고 판단해 Windows에 다시 들어가게 됨

PowerShell 1~4와 실제 영향

• PowerShell 1은 Windows Vista의 일부로 출시됨
• Snover는 출시 뒤 다른 일을 하라는 조언과 경력상 불이익 경고를 받았지만, PowerShell 2, 3, 4까지 같은 비전에 집중함
  • 버전 1은 일부 목표에 도달했고, 버전 2와 3에서 기능을 채웠으며, 버전 4에서 비전이 거의 완성됐다고 회고함
• PowerShell은 Windows 관리자들이 스크립트를 쓰고 복잡한 작업을 자동화하게 만들었음
  • 사용자 그룹, 온라인 질문 답변, 스크립트 공유, 콘퍼런스 발표가 생김
  • 일부 관리자는 PowerShell 경험을 통해 전문 발표자가 됨
• Snover는 약 5년 뒤 Distinguished Engineer가 되었고, 이후 Technical Fellow가 됨
• Office 책임자는 PowerShell이 없었다면 Office의 클라우드 전환이 어려웠고, Office의 클라우드 전환이 Azure의 클라우드 전환에도 영향을 줬다고 말함
  • 이전에는 서버 프로비저닝이 클릭 작업이어서 반복과 수정이 어려웠음
  • 스크립트 덕분에 확장할 수 있었고, 문제가 생기면 스크립트를 바꿔 대응할 수 있었음

[GN⁺]

Hacker News 의견들

• 진행자 입장에서 보자면, PowerShell은 Microsoft 내부에서 극심한 반대에 부딪혔고 만든 사람인 Jeffrey Snover는 이를 밀어붙이다가 강등까지 당했음
  Jeffrey는 원래 Microsoft가 데이터센터에서 경쟁하는 법을 배우도록 돕기 위해 영입됐지만, 당시 문화가 개인용 컴퓨터 중심 세계관에 너무 묶여 있어서 매 단계마다 저항을 받았음
  또 흥미로운 점은 Windows가 파일 기반이 아니었기 때문에 PowerShell이 생겼다는 것임. Jeffrey의 목표는 서버 관리였지만 Windows에서는 설정 파일만 편집해서 관리할 수 없고, 여러 API를 호출해 구조화된 데이터를 주고받아야 했기 때문에 풍부한 객체 모델이 사실상 유일한 방법이었음
  녹취록은 전문 전사에서 Descript, GPT-4의 문장부호 정리, 직접 훑어보기 순서로 만들었는데 기대만큼 품질이 높지 않을 수 있음

  • MS-PWSH 팀이 본다면, 많은 .NET 코드를 직접 쓰지 않아도 되는 기본 GUI 기능을 넣어줬으면 좋겠음
    PowerShell을 좋아하는 이유는 간단한 동적 언어이고 쓰기 쉬운 명령을 연결할 수 있기 때문이라, 간단한 사용자 인터페이스와 차트를 만드는 새 cmdlet 집합이 있으면 좋겠음
    예를 들어 Create-Chart -Type "Bar" -XAxis $Cities -YAxis $GDP -OutputFile "C:/Documents/ProjectAnalysis/CitiesBarGraph.png" 같은 기능은 Microsoft가 제품에 넣기 쉬울 것 같고, 잘 이해하지 못하는 보일러플레이트 코드 한 페이지를 없애줄 수 있음
    기본적인 프로그래밍은 할 줄 알지만 Java나 C# 같은 도구가 직무상 맞지 않는 사용자가 수백만 명은 있을 것임. Python이 보통 잘 맞지만, Microsoft가 서버 관리자나 IT 담당자뿐 아니라 일반 업무 사용자도 쓸 수 있는 무언가를 더 만들어줬으면 함
    PowerShell이 파일 파싱 같은 작업에서 느리지 않도록 더 투자하고, 위에서 말한 기능이나 통계·과학용 cmdlet까지 추가하면 일반적인 비즈니스 분석가가 업무 개선용 소프트웨어나 개발팀에 넘길 프로토타입을 빠르게 만들 수 있는 꽤 대단한 도구가 될 수 있음
    Microsoft는 선택지가 C#을 쓰는 정식 소프트웨어 개발자, PowerShell을 쓰는 IT 업무, 비즈니스 사용자를 위한 Excel 세 가지라고 보는 듯함. Excel은 여러모로 훌륭하지만 꽤 제한적이고, VBA+Excel은 다뤄본 생태계 중 가장 제한적인 축에 속함. Python, R 같은 서드파티 언어가 네 번째 선택지이긴 하지만 Microsoft가 이 영역에 더 시간을 썼으면 좋겠음
  • GitHub에서 MVP들이 Microsoft가 약속했던 추가 투자가 실현되지 않았고, 변경이 반영되지 않았으며, 좋은 기능들이 방치되고 있다고 불평하는 걸 보면 이제 MSFT의 우선순위는 아닌 듯함
    PowerShell의 이상한 흠까지 포함해 좋아했지만 이제는 떠났음
  • 왜 Python이나 비슷한 기존 도구 대신 처음부터 새로 만들었는지 궁금함
  • 녹취록을 읽어보려 했지만 끝까지 못 갔고, 읽기 조금 어렵다고 느낌
    읽는 동안 기계 생성이라고 짐작했지만 구체적으로 왜 그런지는 말하기 어렵고, 더 읽기 쉽게 하려면 편집이 조금 필요해 보임
    그래도 녹취록이 아예 없는 것보다는 훨씬 낫다

• Bash를 오래 써온 개발자로서 PowerShell이 나왔을 때는 정말 기대했음
  드디어 Windows에서도 개발용으로 멋진 셸을 쓰게 되리라 생각했지만, 이후로도 PowerShell을 제대로 체득하지 못했고 Windows에서도 익숙한 Bash를 계속 쓰고 있음
  두 셸 모두에 능숙한 개발자들은 어떻게 비교하는지 궁금함. PowerShell이 더 효율적이고 현대적인 셸이라는 약속을 실제로 이뤘는지, 아니면 기본 설치되어 있고 CMD보다 나아서 쓰는 것인지 알고 싶음

  • Bash를 많이 썼고 책도 좀 읽었지만, 복잡한 Bash 스크립트를 쓰면 안 된다고 굳게 믿음
    대략 50줄을 넘으면 코드 냄새로 보고, 누군가를 설득해야 할 때를 대비해 이 페이지를 저장해뒀음: http://mywiki.wooledge.org/BashPitfalls
    최근 PowerShell을 써보니 명령이 텍스트가 아니라 객체를 반환해서 텍스트를 억지로 다룰 필요가 없다는 점이 스크립트 언어이자 명령줄 언어로 훨씬 쉬웠음
    인자 파싱을 처리하는 공식 방식이 있다는 것도 훌륭함. 모든 것이 통일되어 있고 명령줄 창에서 사실상 모든 옵션을 자동완성할 수 있는데, Bash는 꿈도 못 꿀 수준이라 생산성이 매우 높아짐
    다만 형 변환이 Bash에는 없던 새로운 버그를 만들어내기도 함. 지금은 PWSH를 더 선호하지만 둘 다 어느 정도는 싫고, 다음 자연스러운 진화를 기다리는 중임
  • PowerShell은 Bash보다 장황하고, 0개나 1개짜리 배열을 예상치 못한 순간 스칼라로 자동 해제하는 식의 특이함이 있지만, 더 생산적이고 읽기 쉬움
    객체 지향은 파이프라인을 만들 때 꽤 유용함
    예를 들어 폴더 안에서 재귀적으로 파일 크기별 그룹을 만들어 중복 후보를 찾으려면 Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Count처럼 쓸 수 있음
    난해한 file 주문을 기억할 필요도 없고 텍스트 출력을 파싱할 필요도 없음. 속성이 있는 실제 객체를 받고, 탭 자동완성은 그 구조를 볼 수 있음
    JSON을 파싱해야 하면 jq 없이 Get-Content -Raw whatever.json | ConvertFrom-Json으로 바로 처리하면 됨. XML을 CSV로 바꾸려면 ConvertFrom-Xml 또는 Select-Xml 뒤에 필요한 작업을 하고 ConvertTo-Csv를 쓰면 됨
    Get-ChildItem이 너무 길면 gci, dir, ls를 쓰면 되고, Where-Object가 길면 where나 ?를 쓰면 됨. 기본적으로 대소문자도 구분하지 않음
  • SunOS 피자 박스의 X 터미널로 커리어를 시작했고, 수천 개의 스크립트를 썼으며 그중 상당수는 수천 줄 규모였음
    몇 년 전 PowerShell로 복잡하고 무인으로 동작하는 견고한 데이터 전송 시스템을 작성해야 했는데, 그 경험이 너무 좋아서 macOS와 Linux의 셸을 모두 PWSH로 바꿨음
    가장 좋았던 점은 객체를 파이프라인으로 전달하는 힘이었음. 첫 필터에서 객체의 일부 속성을 추출·조작하고도, 파이프라인 뒤쪽 필터에서 다른 속성과 첫 필터가 만든 객체 속성에 계속 접근할 수 있었음
    명령, 오류 처리, 객체 속성의 일관성도 매우 좋았음
    이후 업무 성격이 바뀌면서 오래된 근육 기억이 되살아나 모든 셸을 Bash로 되돌렸음. 그 공간에서 많이 일하고 생각할 때는 PWSH가 셸로서 자연스러웠지만, 벗어나고 나니 PWSH로 생각하는 게 Bash로 돌아가는 것보다 더 힘들었음
    가끔 그리울 때가 있음. 셸 영역에서 이만큼 가까운 것은 없고, 적어도 전환할 노력을 정당화할 만큼 가까운 대안은 없다고 봄
  • 둘 다 전문가는 아니지만 꽤 써봤고, PowerShell은 몇 가지 함정 때문에 쓰기 끔찍해졌다고 느낌
    첫째, .NET 언어가 되려 한 점임. 하나의 런타임과 여러 언어라는 .NET의 약속이 왜 Java 쪽에서는 그런 약속 없이도 꽃피었는데 .NET에서는 시들었는지 모르겠지만, .NET 코드를 쓸 거면 C#을 쓰는 편이 낫다고 봄
    둘째, 셸의 기본기를 제대로 잡지 못했음. 세부는 이제 과거로 묻어놔서 기억나지 않지만 리다이렉션 처리가 망가져 있었고, Bash에서는 사소한 일이 PowerShell에서는 거의 불가능한 수준이었음. 개발자들이 새롭고 강력한 것을 만드는 데 들떠 Bash 등이 잘하던 것을 무시했다는 느낌을 받았음
    셋째, 모든 이름에 Verb-Object 형식을 요구하는 식의 집착이 있음. 주관적이고 옹호자도 있겠지만, 스크립트를 보기 흉하게 만들고 타이핑도 어색하며 발견 가능성이나 기억 가능성을 실질적으로 개선하지도 않는다고 봄
  • Bash와 너무 다른 방식으로 놀라게 하는 지점이 수없이 많아서 PowerShell을 좋아하지 않음
    탭 대신 오른쪽 화살표를 쓰게 되는 것도 헷갈리고, 익숙한 명령이 없다는 점과 이름 짓기에 강한 규칙이 있는 것도 불편함
    그래도 잘 알면 PowerShell이 Bash보다 더 유능해 보임. 더 나은 형 시스템이 있고 인자를 다루기 쉬운 반면 Bash의 값들은 형태 없는 문자열에 가깝기 때문임
    https://github.com/bionicles/tree_plus/blob/main/tests/more_...는 Windows 머신에서 테스트 환경을 구성할 때 쓰는 약간 오래된 버전이고, 무엇이 가능한지 어느 정도 보여줌

• PowerShell을 직접 쓸 때 끔찍하진 않았지만, 왜 길이 1인 배열이 배열을 벗겨내고 내부 타입으로 바뀌는지는 이해하지 못했음
  이 때문에 배열에 몇 개가 들어올 수 있는지 매번 신경 써야 했고, 일반적으로 처리하는 대신 수정할 때마다 확인해야 해서 엄청난 버그가 생겼음. 왜 이렇게 했는지 아는 사람이 있는지 궁금함

  • 배열 주변이 느슨한 이유는 cmdlet 출력 API도 배열에 대해 느슨하기 때문임
    WriteObject라는 함수 하나가 주어진 값을 cmdlet의 출력으로 쓰고, 한 번 호출하면 그것이 출력이 됨. 여러 번 호출하면 셸은 그 값들을 모두 모은 배열을 출력으로 만들 수밖에 없음
    따라서 어떤 cmdlet 실행에서는 WriteObject를 한 번만 호출하고 다른 실행에서는 두 번 호출하면, 첫 번째 경우 셸은 그 단일 출력도 배열로 감싸야 했다는 지식을 가질 수 없음. 그렇다고 항상 cmdlet 출력을 배열로 감싸면 Get-Date처럼 의미상 결과가 하나뿐인 cmdlet에는 방해가 됨
    어떤 이유에서인지 cmdlet 스스로가 실제 WriteObject 호출 횟수와 무관하게 의미상 단일 출력인지 다중 출력인지를 표현하도록 API를 복잡하게 만들고 싶어 하지 않았던 듯함. 이런 API는 매개변수에 따라 출력이 크게 달라질 수 있으므로 cmdlet의 정적 속성일 수 없고, 빈 배열에도 동작해야 하므로 (Object, bool iMightWriteMoreValues) 같은 WriteObject 오버로드도 곤란함. 아마 별도의 IWillWriteMultipleValues() 함수가 필요했을 것임
    여기에도 설명되어 있음: https://news.ycombinator.com/item?id=40874873
  • 이건 정말 짜증남. 배열을 강제하려고 앞에 쉼표를 붙이는 comma hack을 쓰기 시작했음
    $Ary = @(, "value")
    배열을 만들 때 특히 큰 배열에서는 +=보다 성능이 나아서, 배열에 for 루프를 할당하는 기능도 꽤 괜찮음. 배열을 채우는 방법으로 직관적이진 않았지만 확실히 유용함
    $Ary = foreach ($Obj in $Objs) { @{ foo = $Obj.foo } }
  • 이건 소프트웨어가 너무 영리해지려다 실패하는 전형적인 사례처럼 들림
    소프트웨어 개발자는 자기 소프트웨어를 너무 영리하게 만들고 싶은 유혹을 항상 경계해야 함
  • 반쯤 구워진 기능처럼 느껴짐
    빠진 나머지 절반은 받는 쪽이 배열을 기대할 때 단일 값을 길이 1짜리 배열로 자동 변환하는 기능이었을 것임
  • 틈새 언어는 매번 이런 미친 특이점을 갖게 되는 것 같음
    Lua 같은 게 이미 있는데도 그대로 쓰거나 조금만 수정해서 단순하고 작고 우아하며 일관된 언어를 얻는 대신, 사람들은 바퀴를 다시 만들고도 둥글게 만들지 못하는 시시포스의 비극 같음

• Windows 하위 시스템과 상호작용해야 해서 특정 PowerShell 명령이 필요한 경우가 아니라면, “왜 Python을 안 쓰고 있지?”라는 생각이 듦
  Bash로 할 일의 90%에는 너무 장황하고 느리며, 다른 삶이었다면 Perl로 했을 일에도 마찬가지임
  Microsoft가 왜 Python, Node 같은 것 위에 만들지 않았는지 자주 궁금함. PowerShell이 처음 언제 나왔는지 기억이 안 나서 당시 무엇이 이상적이었을지는 확실하지 않음

  • Python 기본 REPL은 정말 형편없음
    또한 PowerShell이 잘하는 콘솔 작업에 맞게 설계되지 않았음. 파일 내용을 받아 다른 명령으로 넘기면 될 일을 파일 핸들 관리 같은 식으로 직접 해야 하기 때문임
    PowerShell이 좋은 이유는 자동완성이 있는 훌륭한 REPL, 이상한 공백 동작 없음, readline[0], 필요하면 .NET으로 할 수 있는 모든 일을 할 수 있는 스위스 아미 나이프이기 때문임
    게다가 객체 지향이라, 낡은 유틸리티의 텍스트 기반 출력을 또 다른 낡은 유틸리티로 파싱하는 법을 알아내는 대신 실제 해야 할 작업에 집중할 수 있음
    0: https://learn.microsoft.com/en-us/powershell/module/psreadli...
  • 원래는 Perl과 Korn shell을 느슨하게 기반으로 했음
    Bruce Payette의 “Powershell in Action” 초판에는 PowerShell이 @ 기호, 기본 변수 $_, 함수 호출 연산자 &를 쓰기 때문에 Perl처럼 보인다는 곁가지 설명이 있음. 실제로 한때 Perl을 뿌리 언어로 사용했고, 이 요소들이 그 시기에서 왔다고 함. 나중에 구문은 C#에 더 맞게 바뀌었지만 이 요소들은 잘 동작했기 때문에 유지됐고, Perl 용어로는 언어의 “whipupitude quotient”에 크게 기여했다고 설명함
    또한 PowerShell 핵심 언어는 Korn shell의 POSIX 1003.2 문법을 기반으로 하며, 원래 해시 테이블 같은 고급 개념에는 Perl 관용구를 가져왔지만 프로젝트가 진행되면서 PowerShell 구문을 C#에 맞추는 편이 더 적절하다는 점이 분명해졌다고 함
  • PowerShell은 Node보다 3년 먼저 나왔음
    다른 무언가를 기반으로 하지 않은 건 Microsoft가 .NET을 통제하고 있었기 때문일 가능성이 큼
    느린 이유가 .NET 때문이라고는 생각하지 않고, 설계 문제거나 성능 투자 부족 때문일 것 같음
    다만 어떤 버전의 PS를 쓰는지에 따라 다름. 기억상 최신 버전은 꽤 빠름

• 직장에서는 20년 넘은 SQL Server 저장 프로시저 코드베이스를 다루는 축복을 받았음
  약 30만 줄의 원숭이 테스트를 거친 비즈니스 핵심 코드인데, 소스 관리가 없었고 성능 튜닝도 제대로 된 적이 없었으며, SSMS에서 SQL을 편집·실행해 환경에 배포했고, 당연히 자동 테스트도 없었음
  회사는 Windows 중심이고, 개발은 Mac에서 하며, GitHub Actions에서는 Linux를 씀
  PowerShell Core, sqlcmd, Windows SQL Server 인스턴스를 실행하기 위한 docker, 기존 레거시 서버에서 스키마와 코드를 추출하기 위한 RedGate SQL Compare, 단위 테스트용 tSQLt, 코드 준수용 TSqlLint, 스타일 준수용 SQLFluff, 배포용 Flyway 같은 도구를 선택했음
  Windows가 플랫폼 중 하나여야 할 때 PowerShell Core가 가장 상호운용성 좋은 크로스플랫폼 스크립팅 셸이라는 걸 금방 알게 됨
  코딩이 즐겁지는 않았음. 정규식 엔진은 .NET에서 오는데 치명적인 백트래킹 문제가 있고, 배열 동작도 이상했음. 실행 파일을 원하는 방식으로 띄우고 출력 스트림을 잡는 것도 들쭉날쭉해서, 종종 프로세스를 실행하고 출력을 임시 파일로 리다이렉트한 뒤 자식 프로세스가 종료되면 그 파일을 읽어야 했음. 자식 프로세스의 표준 출력을 문자열 변수로 파이프하는 일도 필요 이상으로 번거로웠음
  하지만 PowerShell Core는 실행이 빠름. Microsoft가 하나 잘하는 게 있다면 마이크로 최적화임. ASCII 아트 목록 선택기나 쉬운 입력 프롬프트 생성기처럼 사용자와 상호작용하는 도구도 좋음. 잠긴 파일이 있는 폴더를 피하면 Windows 파일 시스템의 이상한 특이점도 대부분 가려짐
  열심히 검색하면 원하는 일은 대체로 해낼 수 있음. 추천할 만함

• 커리어가 Windows 관리에 가까워질 때마다 그 경험을 정말 싫어했다는 다른 감상들에 동의함
  하지만 Windows의 다른 모든 것이 극도로 투박한 것과 달리 PowerShell 자체는 실제로 꽤 훌륭했고, 항상 신중하게 설계된 느낌이었음
  Linux는 훌륭하고 앞으로도 업무용 일상 환경으로 쓰겠지만 Bash를 쓰는 것은 정말 끔찍함. 그래도 어디에나 항상 있기 때문에 모두가 가장 먼저 손을 대고, 아마 2100년에도 온갖 흠을 가진 Bash 스크립트를 계속 다루고 있을 것임

• PowerShell은 정말 Microsoft의 독점적 자신감에서 나온 제품 같음
  다른 언어에서 넘어올 수 있는 구문적 연결고리가 거의 없는 언어를 만든다는 건 대담한 일임. 명령, 매개변수, 플래그를 추측하거나 짐작할 수 없었음. Microsoft의 야심을 감안해도 관리자와 프로그래머 군단이 적어도 수십 년은 PowerShell과 Bash 스크립트를 함께 배우고 유지해야 한다는 점을 알았어야 함
  극도로 장황한 구문은 위원회 발표에는 좋아 보일지 모르지만, 실제로 자주 다루면 인간 두뇌의 잘 연구된 한계와 충돌함. 정보 크기나 지연 시간이 일정 수준을 넘으면 몰입 흐름이 깨지고, 집중과 명시적 암기와 재확인이 필요해짐. 연습해도 생각을 현실로 바꾸는 흔한 셸 주문을 빠르게 실행하기 어렵고, 자동완성이 뜨길 기다렸다가 여러 부분으로 된 명령의 다음 단어를 받아들일지 결정하는 것만으로도 구문과 씨름해야 함
  시작 메뉴에서 pow..를 검색하면 PowerShell, PowerShell ISE, 각각의 일반 버전과 x86 버전이라는 멋진 네 가지 선택지가 나옴. 어느 쪽이든 로딩이 걸려 흐름이 깨짐. ISE는 작은 스플래시 화면을 띄우고 다른 위치로 점프함. 또 다른 대화상자는 지난 세션을 이름 없는 스크립트 파일을 저장하지 않고 닫았다고 알려주지만, 어차피 예상대로 다시 열어줌. 그렇다면 왜 혼내는지 모르겠음
  텍스트를 입력하거나 복사해서 어떤 악성 코드든 실행할 수는 있는데, 파일로 저장한 뒤 .ps 스크립트로 실행하려면 우스꽝스러운 실행 정책 절차가 시작됨. 초기 Internet Explorer와 Windows의 나쁜 보안 평판에서 온 트라우마였을지도 모름
  그래도 사랑해보려 했지만 어느 날 스크립트가 대괄호가 들어간 파일명을 만났고, PowerShell은 그 [1], [2]를 암묵적으로 반복자 비슷하게 해석했음: https://stackoverflow.com/questions/21008180/copy-file-with-...
  스크립팅 언어의 핵심 업무 하나가 파일 다루기인데, 파일명은 스크립트 작성자가 통제할 수 없고 Windows에서 유효한 파일명 공간은 알고 있어야 함. 이 일 때문에 그 언어에 오래가는 신뢰 문제가 생겼음
  Azure 팀은 Microsoft 안에서 충분한 힘이 있었는지 az find vm, az account show 같은 제정신이고 읽기 쉬운 구문을 따로 만들었음

  • 그렇지는 않음. PowerShell은 셸, Perl, 여러 다른 언어에서 영감을 받았고 설계에서 그 흔적이 보임
    다른 한편은 일관성을 원한 것이었음. *NIX 지식은 사실상 무식하게 외워서 얻는 편임. -v가 대체로 verbose이고 -h가 대체로 help이긴 하지만, 실제로는 아무것도 믿고 의존할 수 없음

• 지금 돌아보면 Microsoft가 Windows와 Active Directory, Exchange 같은 중요 엔터프라이즈 애플리케이션의 모든 설정을 쉽게 조합 가능하고 프로그래밍 가능한 방식으로 구성하는 가치가 왜 보이지 않았는지 이상함
  Remote Desktop으로 접속해서 마우스로 클릭하고 다니는 것을 대안으로 제안했다는 생각은 터무니없음. 그런 작업을 자동화하는 일은, 적어도 AutoHotkey와 Window Spy를 써본 경험상, 끔찍하게 어렵고 성가심

  • Windows 설정을 쉽게 조합 가능하고 프로그래밍 가능하게 만드는 결과를 원하지 않는 컨설턴트와 소프트웨어 벤더 산업 전체가 있음
    Remote Desktop으로 접속해서 마우스로 클릭하는 방식은 많은 청구 시간을 만들어냄
    그런 일이 끔찍하게 어렵고 성가시다는 점이 대체 운영체제가 존재하는 주된 이유일 가능성이 높다는 게 아이러니함
  • 더 이상한 건 그 “클릭해 돌아다니기” 사고방식이 Azure에도 들어갔다는 점임
    예전에는, 공정하게 말해 10년 전쯤이지만, 어떤 설정을 자동화하는 가장 좋은 방법이 Selenium이라는 기술 지원 담당자의 진지한 제안을 받은 적이 있음

• 1982년부터 컴퓨터를 써왔지만 Windows 사용자는 정말 단 한 번도 아니었음
  1990년대 초 Wintel이 부상할 때는 Linux와 386BSD의 성장을 따라갔고, 1990년대 후반 Win95와 NT가 비즈니스 데스크톱을 지배할 때는 SPARCStation, Linux, 단종된 NeXT 하드웨어로 피신했음. 세기가 바뀐 뒤에는 새로 POSIX를 준수하게 된 Mac OS를 받아들였음
  거의 반세기 동안 Microsoft 제품을 피하는 것이 컴퓨팅 정책의 핵심이었고, 주목할 만한 예외는 Applesoft BASIC 정도였음
  그런데 PowerShell은 좋음

  • 컴퓨팅, 특히 패러다임을 바꾼 혁신 흐름에 오랜 경험이 있는 듯함
    다만 첫 문단이 만든 기대를 둘째 문단이 일부러 비껴가는데, 왜 PowerShell이 “좋다”고 보는지 설명해줬으면 함
  • 무엇이 PowerShell을 Bash보다 낫게 만드는지 궁금함

• 적절한 프로그래밍 언어인 C/C++ 같은 것으로 직접 명령줄 도구를 작성해야 할 때, 전통적인 셸용으로 만들 때와 PowerShell용으로 만들 때 생산성 차이는 과소평가되어 있음
  일반적으로 유용한 CLI 도구를 수천 줄 이하의 지저분한 코드 없이 만든 적이 없음. 보통 파이프라인 입력, 선택 매개변수, 값을 가진 매개변수, 기본값과 재정의, dry run 모드, 다양한 출력 형식 요구사항 등을 처리해야 해서 90%는 군더더기이고 10%만 실제 동작이 됨
  PowerShell에서는 C# 모듈이 기본적으로 20줄 정도의 오버헤드만 있고 나머지는 전부 실제 동작임. 생산성이 놀라울 정도임
  매개변수 검증, 매개변수 이름 탭 자동완성, 파이프라인 입력과 출력, 형식 지정, 강한 타입, 글로빙 등을 모두 공짜로 얻음

  • C#은 써본 적 없지만 동의함
    유지보수와 관리 작업에서는 CLI 도구보다 컴파일 언어나 인터프리터 언어로 점점 더 옮겨가고 있음