▲

GN⁺: 제프리 스노버와 PowerShell 개발 이야기

 (corecursive.com)
1P by neo 2달전 | favorite | 댓글 1개

Jeffrey Snover와 PowerShell의 탄생

  • 기업 거대 조직 탐색

    • Jeffrey Snover는 Microsoft의 PowerShell을 만든 건축가임.
    • PowerShell은 Windows 시스템 관리를 혁신적으로 변화시킨 도구임.
    • 초기에는 회의적인 반응을 받았으나, Snover의 끈질긴 노력으로 성공을 거둠.

  • 문제

    • Microsoft는 서버 시장을 이해하지 못하고 있었음.
    • 개인용 컴퓨터에 익숙한 경영진은 기업 환경에 대한 경험이 부족했음.
    • Snover는 이 문제를 해결하기 위해 고용됨.

  • Jeffrey의 설득

    • Snover는 Microsoft의 서버 팀에 합류하여 Windows를 UNIX와 경쟁할 수 있도록 만들기 위해 노력함.
    • 목표는 동일한 기능을 더 낮은 비용으로 제공하는 것이었음.

  • UNIX를 이기기

    • UNIX는 파일 중심의 운영 체제였으나, Windows는 API 중심의 운영 체제였음.
    • UNIX의 도구는 Windows에서 제대로 작동하지 않았음.
    • Snover는 WMI(Windows Management Instrumentation)를 사용하여 관리 명령을 개발하기로 결정함.

  • 문화적 도전

    • Microsoft 팀은 GUI를 선호했으며, Snover의 명령줄 인터페이스 아이디어에 회의적이었음.
    • Snover는 엔터프라이즈 환경에서 GUI가 아닌 명령줄 인터페이스가 필요하다고 주장함.

  • 기업 시나리오

    • Microsoft 팀은 각 문제에 대해 사용자 인터페이스를 제공하는 현대적인 방법을 선호했음.
    • Snover는 도구 상자 접근 방식을 주장함.

  • Windows는 UNIX가 아님

    • Windows는 파일 중심이 아닌 API 중심의 운영 체제였음.
    • WMI를 사용하여 관리 명령을 개발하기로 결정함.

  • 코딩 윈도우

    • Snover는 10주 동안 코딩을 해야 한다는 사실을 알게 됨.
    • 10주 동안 코드를 작성한 후 몇 년 동안 작동하도록 만드는 방식이었음.

  • .Net의 쐐기

    • Bill Gates는 .NET을 강력히 추진하고 있었음.
    • Snover는 .NET을 사용하여 더 많은 커버리지를 얻을 수 있을 것이라고 판단함.

  • 재조직

    • Snover의 조직은 재조직으로 인해 혼란에 빠짐.
    • Snover는 자신의 계획을 계속 추진하기로 결정함.

  • 쉘 팀

    • 다른 그룹이 쉘을 개발하고 있었음.
    • Snover는 그들에게 더 나은 방법을 제안했으나, 그들은 이해하지 못함.
    • 결국 Snover는 자신만의 프로토타입을 개발함.

GN⁺의 의견

  • PowerShell의 중요성

    • PowerShell은 Windows 시스템 관리의 패러다임을 바꾸었음.
    • 명령줄 인터페이스를 통해 대규모 서버 관리를 가능하게 함.

  • 기술 리더십

    • Snover의 끈질긴 노력과 명확한 비전이 성공의 열쇠였음.
    • 기술 리더십은 강한 반대에도 불구하고 중요한 결과를 달성하는 것임.

  • 비슷한 기능을 가진 제품

    • Linux의 Bash와 유사한 기능을 제공함.
    • PowerShell은 Windows 환경에서 Bash와 같은 역할을 함.

  • 새로운 기술 채택 시 고려 사항

    • 새로운 기술을 채택할 때는 기존 시스템과의 호환성을 고려해야 함.
    • PowerShell은 기존 Windows API와의 호환성을 유지하면서도 새로운 기능을 제공함.

  • 장단점

    • 장점: 대규모 서버 관리의 효율성 증가, 자동화 가능성
    • 단점: 초기 학습 곡선, 기존 GUI 사용자들의 저항
▲
neo 2달전  [-]
Hacker News 의견

  • PowerShell의 창시자 Jeffrey Snover가 Microsoft 내에서 큰 반대에 부딪혔고, 결국 강등되었음

    • Jeffrey는 원래 Microsoft가 데이터 센터에서 경쟁할 수 있도록 돕기 위해 고용되었음
    • Windows가 파일 기반이 아니기 때문에 PowerShell이 존재하게 되었음
    • 서버 관리를 위해 다양한 API 호출과 구조화된 데이터가 필요했음

  • PowerShell을 작성할 때 배열 길이가 1인 경우 배열이 제거되고 포함된 타입이 되는 이유를 이해하지 못했음

    • 이로 인해 많은 버그가 발생했음

  • Bash 개발자로서 PowerShell이 출시되었을 때 매우 기대했지만, 여전히 Bash를 사용하고 있음

    • 다른 개발자들의 경험을 알고 싶어함
    • PowerShell이 정말로 더 효율적이고 현대적인 쉘이 되었는지 궁금해함

  • 20년 된 SQL Server 저장 프로시저 코드베이스를 관리하는 작업을 맡고 있음

    • 소스 제어가 되지 않았고, 성능 튜닝도 제대로 되지 않았음
    • PowerShell Core가 Windows와의 상호 운용성이 가장 뛰어났음
    • 코드 작성은 불편했지만, 빠르게 실행되었고 사용자와 상호작용하는 도구가 좋았음
    • 검색을 열심히 하면 원하는 것을 달성할 수 있었음

  • Windows 하위 시스템과 상호작용할 때를 제외하고는 Python을 사용하지 않는 이유를 모르겠음

    • PowerShell이 너무 장황하고 느림
    • Microsoft가 왜 Python이나 Node를 기반으로 하지 않았는지 궁금해함

  • Microsoft가 Windows와 중요한 엔터프라이즈 애플리케이션을 구성하는 프로그램적 방법의 가치를 보지 못한 것이 이상함

    • 원격 데스크톱을 통해 마우스로 클릭하는 것이 대안으로 제안된 것은 터무니없음

  • PowerShell은 Microsoft의 독점적 자신감의 산물임

    • 다른 언어와의 문법적 연계가 전혀 없었음
    • 극도로 장황한 문법이 프레젠테이션에는 좋을 수 있지만, 실제 사용에는 불편했음
    • 파일 이름에 대괄호가 포함된 경우 문제가 발생했음

  • Windows 관리를 할 때 PowerShell은 사용하기 좋았음

    • Linux는 훌륭하지만 Bash 사용은 끔찍했음
    • Bash 스크립트는 여전히 많이 사용될 것 같음

  • Windows 사용자가 아니었지만 PowerShell은 좋았음

  • PowerShell은 많은 점에서 훌륭했지만, 더 넓은 사용자층을 끌어들이지 못했음

    • PowerShell cmdlet은 자체 설명적이고 풍부한 정보를 제공했음
    • 시뮬레이션 모드와 같은 유용한 기능이 있었음
    • 그러나 Windows 외부에서는 인기를 끌지 못했고, Microsoft는 Linux 개발자들을 끌어들이기 위해 PowerShell을 소홀히 하고 있음
답변달기