GUI 시대의 종말

GUI와 시스템 관리 세계에서의 역할에 대한 역사적 맥락을 살펴보는 것으로 시작하겠습니다.

"옛날"에는 어떤 컴퓨터에도, 하물며 서버에도 그래픽 사용자 인터페이스가 없었습니다. GUI가 최종 사용자 장비에서 인기를 얻기 시작한 지 한참 후에도 서버에는 여전히 GUI가 없었습니다. 1980년대와 1990년대에는 GUI를 구현하는 데 필요한 계산 오버헤드가 기기의 전체 컴퓨팅 용량 대비 상당했으며, 적은 용량을 GUI 생성에 사용하는 것은 다소 비실용적이었고 종종 완전히 불가능하기도 했습니다. 시스템 관리의 세계는 다른 선택지가 없었기 때문에 커맨드라인에서 작업하는 이 맥락 속에서 성장했습니다. GUI를 원하는 사람들이 많지 않았던 것은 어쩌면 그 아이디어 자체가 사람들에게 떠오르지 않았기 때문일 수도 있습니다.

1990년대 중반에 Microsoft를 비롯한 몇몇 업체들이 엔트리 레벨 서버 시장을 위한 GUI 기반 시스템 관리 개념을 도입하기 시작했습니다. 처음에는 이 접근 방식이 시장에서 경험 많은 관리자들이 일하는 방식과 맞지 않아 그다지 인기를 얻지 못했습니다. 하지만 새로운 Windows 관리자들이, 그리고 어느 정도는 Novell Netware 관리자들이 GUI 기반 관리 도구에 "익숙해지면서" 서버 시장에서 이러한 시스템을 위한 자리가 점차 인정받기 시작했습니다. 1990년대 중후반에 UNIX 및 기타 비Windows 서버들이 시장을 완전히 지배했습니다. VMS도 여전히 주요 플레이어였으며 소규모 비즈니스 및 상용 서버 측면에서 Novell Netware가 10년대 중반의 지배적인 플레이어였고 10년 후반에도 여전히 매우 강력한 경쟁자였습니다. Netware는 GUI 경험을 제공했지만 매우 가벼운 것이었으며 아마도 적어도 1996년부터, 그리고 NT 3.x 패밀리를 통해 어느 정도는 그 이전부터 Windows NT가 제공하는 풍부한 GUI 경험과 비교하면 "반 GUI" 정도로 봐야 할 것입니다. 다만 Windows NT는 NT 4 출시 전까지는 서버 세계에서 자리를 잡기 시작한 수준이었습니다.

당시에도 GUI 기반 관리 시장은 주로 주변부에 머물러 있었습니다. Microsoft와 Windows는 서버 측에서 아직 주요한 위치를 차지하지 못했지만 저비용과 사용 편의성을 앞세워 소규모 비즈니스 시장을 통해 진입하기 시작하고 있었습니다. 그러나 실제로 GUI 기반 관리 시장에서 의미 있는 성장과 전환이 일어난 것은 Y2K 공포, 닷컴 버블, Microsoft의 탁월한 제품 개발과 마케팅이 결합되어 1990년대 후반의 공황과 시장 확장이 일어났을 때였습니다.

1990년대 후반 IT 시장의 대규모 확장은 새로 IT에 입문하는 사람들을 교육하기에 충분한 시간과 자원이 없다는 것을 의미했습니다. Solaris와 Netware를 포함한 많은 시스템의 학습 곡선은 매우 가팔랐으며 업계는 당시 기존 플랫폼으로 가능한 것보다 더 빠르게 엄청난 수의 사람들을 제로에서 "유능한 IT 전문가"로 만들어야 했습니다. 시장 성장은 폭발적이었고 IT에서 일해서 얻을 수 있는 돈이 너무 많아서 교육을 담당할 자격이 있는 사람은 누구나 교육 분야에서 일하는 것보다 업계에서 훨씬 더 많은 수입을 얻을 수 있었기 때문에 새로 입문하는 사람들을 효과적으로 교육할 자원이 없었습니다. 시장이 성장함에 따라 전체적으로 계속 확장하는 분야에서 점점 더 희귀해지는 성숙하고 경험 있는 전문가들의 가치는 매우 높아졌습니다.

시장은 이 필요에 여러 방식으로 대응했지만 가장 큰 것 중 하나는 IT에 대한 접근 방식을 근본적으로 변화시키는 것이었습니다. 당시 시장에 있던 시스템을 효과적으로 관리하는 데 필요한 기술을 개발하기 위해 전통적인 학습 곡선을 극복하도록 IT 전문가들을 밀어붙이는 대신, 시장은 경험이 적고 지식이 부족한 IT 직원을 수용하기 위해 사용하는 도구를 바꿨습니다. GUI 인터페이스를 갖춘 더 단순하고 종종 더 비싼 도구들이 시장에 넘쳐나기 시작했으며, 이를 통해 훈련과 경험이 부족한 사람들도 이전에 제품을 본 적이 없더라도 거의 즉시 유용하고 생산적이 될 수 있었습니다.

이러한 변화는 컴퓨터 하드웨어 성능의 자연스러운 발전과 맞물렸습니다. 이 시대는 많은 시스템의 성능이 GUI가 여전히 성능에 상당한 영향을 미쳤음에도 불구하고, 더 낮은 지원 인력 비용과 시스템을 배포하고 관리할 수 있는 속도가 일반적으로 GUI가 차지하는 컴퓨팅 용량 손실을 상쇄하는 수준이 된 첫 번째 시기였습니다. GUI는 불과 몇 년 전이라면 상상도 못했을 시스템의 표준 추가 기능으로 빠르게 자리 잡았습니다.

이 새로운 IT 전문가들의 역량을 향상시키고 시장에 빠르게 투입하기 위해 업계는 당시에는 거의 새로운 혁신이었던 자격증 취득으로 크게 방향을 전환했습니다. 이를 통해 어떠한 실무 경험도 없는 새로운 IT 전문가들이 대학 프로그램에서처럼 기존 IT 전문가들과의 유의미한 상호작용이나 투자 없이도 어느 정도의 역량을 입증할 수 있게 되었습니다. GUI 기반 관리 시장과 자격증 업계 모두 호황을 이루었고 IT의 모습은 크게 변화했습니다.

결과적으로 훈련이 부족하거나 가볍게 훈련된 새로운 IT 전문가들이 기록적인 속도로 시장에 대거 진입했습니다. 단기적으로 이 변화는 업계에 효과가 있었습니다. 극심하게 인력이 부족했던 분야가 그렇지 않았다면 가능했을 것보다 몇 년 더 빨리 상대적으로 충분한 인력을 갖추게 되었습니다. 하지만 이 빠른 신규 인력 채용에 따른 불이익이 나타나기까지 오래 걸리지 않았습니다.

업계에 가장 큰 영향 중 하나는 업계 전반에 걸친 "베이비 붐"이 발생하여 그에 따른 모든 성장통을 겪게 된 것이었습니다. 1990년대 후반의 부트캠프와 빠른 "자격증 훈련" 프로그램에서 전체 세대의 IT 전문가들이 성장했습니다. 이로 인해 그 시대에 일반적이었던 경험 법칙과 일반적인 접근 방식이 종종 이전 및 이후 접근 방식에서는 그러지 않을 방식으로 거의 종교적 믿음의 수준으로 고착화되는 장기적 효과가 나타났습니다. 종종 교육이 빠르고 피상적으로 이루어졌기 때문에 많은 개념들이 근본적인 이해 없이 암기식으로 학습되어야 했습니다. "1998년 졸업생"이 시간이 지남에 따라 회사의 시니어 IT 전문가로 성장하면서 새로운 세대의 멘토가 되었고, 그 오래된 암기식 학습은 그 이후로 비슷한 접근 방식을 통해 눈에 띄게 이어져 왔습니다. 지식이 시대에 뒤떨어지거나 비실용적인 지 한참 지난 후에도, 그리고 많은 경우 잘못 해석되어 시작된 시대에도 예측 가능한 방식으로 틀린 경우에도 그러했습니다.

이 시대의 학습 중 일부는 GUI가 단순히 수용 가능한 것이 아니라 실용적이고 기대되는 것이라는 일반적인 수용이었습니다. 베이비 붐 효과는 이전 시대로부터의 멘토십이 거의 없었다는 것을 의미했으며, 이전에 확립된 관행과 규범은 종종 쓸려 나갔습니다. 베이비 붐 효과는 업계가 정확히 자신을 재발명했다기보다는 단순히 스스로를 투자했다는 것을 의미했습니다. 정보 기술이 독자적인 특정 산업으로서의 현재 형태를 갖추고 이 경비대 교체 기간 동안 대중의 의식에 자리 잡기도 했습니다. 다른 부서나 학문의 흔적이 되는 대신 IT는 스스로 자리를 잡았지만, 더 유기적인 성장과 함께 존재했을 관행의 성숙과 연속성 없이 그렇게 하였으며, 이는 지속적인 방식으로 발전했다면 있었을 것보다 업계를 더 나쁜 위치에 두었을 수도 있습니다.

1990년대 후반 IT 붐의 지속적인 영향은 그 시기의 트렌드, 믿음, 가정이 마침내 쓸려 나가기까지 많은 세대가 필요할 것이기 때문에 매우 오랫동안 느껴질 것입니다. 서서히 새로운 개념과 접근 방식이 자리를 잡고 있으며, 종종 오래된 기술이 사라지고 새로운 것이 도입될 때만 전통의 장악력을 깨뜨립니다. 그중 하나가 GUI가 시스템 관리를 완수하는 지배적인 방법이라는 개념입니다.

앞서 언급했듯이 GUI는 처음 등장했을 때 낡은 시스템과 1990년대 후반의 새로운 세계를 구별하는 차별점이었습니다. 그러나 그 이후로 GUI 관리 도구는 그 가용성에서 어디서나 볼 수 있게 되었습니다. 모든 주요 플랫폼은 그래픽 관리 옵션을 갖추고 있으며 오랫동안 그래왔으므로 GUI는 더 이상 어떤 플랫폼도 의미 있는 방식으로 차별화하지 않습니다. 이는 더 이상 GUI 개념을 밀어붙일 명확한 의제를 가진 벤더가 없다는 것을 의미합니다. GUI의 마케팅 가치는 사실상 사라졌습니다. 마찬가지로 이전에 강력한 GUI가 없었던 시스템들이 거의 모두 하나(또는 그 이상)를 개발했을 뿐만 아니라 강력한 커맨드라인 도구가 없었던 GUI 기반 시스템들도 그것을 개발하고 그것을 중심으로 새로운 전문 생태계를 발전시켰습니다. 조류는 분명히 바뀌었습니다.

더욱이 지난 거의 20년에 걸쳐 비GUI 세계의 주장이 자리를 잡기 시작했습니다. 어떤 플랫폼에서든 커맨드라인을 마스터한 위치에서 일하는 시스템 관리자들은 일반적으로 더 많은 커리어 기회, 더 도전적인 역할, 더 높은 수입으로 이어지는 더 나은 성과를 보입니다. 커맨드라인 관리에 집중하는 회사들은 더 숙련된 작업자와 더 높은 관리 밀도를 갖추게 되어 결과적으로 전체 비용이 낮아집니다.

이것만으로도 GUI의 위치가 흔들리기 시작하게 하기에 충분했습니다. 하지만 GUI가 1990년대 후반에도 약간의 시스템 자원을 사용했고 매우 적은 추가 공격 표면을 추가했다는 오래된 주장이 항상 있었습니다. 사용되지 않더라도 왜 "만약을 위해" 설치해 두지 않겠냐는 것이었습니다. CPU가 빨라지고, 메모리가 커지고, 스토리지가 저렴해지고, 시스템 설계가 개선됨에 따라 GUI의 영향이 점점 줄어들었기 때문에 GUI를 사용 가능하게 두어야 한다는 이 주장이 강해졌습니다. 특히 GUI가 주니어 직원들도 작업을 잘 수행할 수 있게 하여 더 유용하게 만든다는 제안이 강력했습니다. 하지만 이러한 상황에서 시니어 직원들이 GUI를 목발처럼 유지하는 것이 너무 일반적이었습니다.

상용 서버 공간에서 가상화가 등장하면서 이 모든 것이 바뀌기 시작했습니다. GUI의 비용이 갑자기 다시 눈에 띄게 되었습니다. 20개의 가상 머신을 실행하는 시스템은 갑자기 단일 GUI 인스턴스보다 20배의 CPU 자원, 20배의 메모리, 20배의 스토리지 용량을 사용하게 됩니다. GUI의 공간이 다시 눈에 띄게 되었습니다. 가상 머신 밀도가 증가하기 시작하면서 GUI의 상대적 영향도 함께 증가했습니다.

가상화는 클라우드 컴퓨팅의 등장으로 이어졌습니다. 클라우드 컴퓨팅은 가상 머신 배포 밀도를 높이고 GUI의 다른 성능 영향, 주로 더 긴 인스턴스 빌드 시간과 더 복잡한 원격 콘솔 액세스 측면에서를 드러냈습니다. GUI가 필요한 시스템은 도입과 역량 면에서 GUI가 없는 시스템에 비해 눈에 띄게 뒤처지기 시작했습니다.

하지만 훨씬 더 큰 요인은 클라우드 컴퓨팅의 표준 청구 방법론의 산물이었습니다. 클라우드 컴퓨팅은 일반적으로 인스턴스별 비용을 원시적이고 완전히 가시적인 방식으로 노출하기 때문에 IT 부서는 추가 오버헤드가 종종 단일 클라우드 인스턴스 비용을 두 배로 만드는 GUI 배포 비용을 얼버무리거나 간과할 방법이 없었습니다. 회계 부서는 GUI 없는 시스템에 비해 GUI 시스템에 대한 청구서가 훨씬 더 많이 나온다는 것을 매우 명확하게 볼 수 있었습니다. 비기술 팀들조차 관리 비용을 고려하기 전에도 GUI 비용이 쌓이고 있다는 것을 볼 수 있었습니다.

이 비용은 개별 인스턴스의 규모가 점점 작아지는 컨테이너 기술로 이동함에 따라 GUI의 상대적 오버헤드가 더욱 중요해지면서 계속 증가하고 있습니다.

하지만 진정한 영향, 아마도 GUI 기반 시스템 문제의 가장 큰 노출은 DevOps 시스템 자동화 모델로의 업계 이동일 것입니다. 오늘날 상대적으로 적은 비율의 회사만이 클라우드 지원, 탄력적으로 확장 가능한 DevOps 시스템 관리 모델로 적극적으로 이동하고 있지만 그 추세는 있으며, 이 모델은 GUI 관리자와 그들의 시스템을 완전히 뒤처지게 합니다. DevOps 모델에서는 기기에 대한 직접 액세스가 더 이상 표준 관리 방식이 아니며, 시스템은 커맨드라인에서만 작업하는 것을 넘어 완전히 코드로 구축되었습니다. 즉, DevOps 세계에서 일하는 시스템 관리자들은 커맨드라인에서 시스템과 상호작용해야 할 뿐만 아니라 프로그래밍 방식으로 그렇게 해야 합니다.

시장은 이전 어느 시대보다 "관리자당" 훨씬 더 많은 서버를 관리하는 더 적고 더 숙련된 시스템 관리자를 향해 빠르게 이동하고 있습니다. 단일 시스템 관리자가 수십 대의 서버만 관리할 수 있다는 생각은 GUI 세계의 일반적인 믿음으로, 전통적인 "스노우플레이크" 커맨드라인 시스템 관리에서도 오래 전에 도전을 받아 수백 대 범위로 쉽게 올라갔습니다. 하지만 DevOps 모델이나 유사한 자동화 모델은 그 숫자를 관리자당 수천 대의 서버로 끌어올립니다. GUI의 오버헤드가 점점 더 명확해지고 있습니다.

클라우드, 컨테이너, DevOps 자동화 모델 같은 새로운 기술이 보편화됨에 따라 워크로드의 자연적인 "스프롤"도 함께 발생합니다. 이는 모든 규모의 회사들이 관리해야 할 워크로드 수의 증가를 경험하고 있다는 것을 의미합니다. 전통적으로 서버 두세 대만 있었던 회사들이 오늘날 10개 또는 20개의 가상 인스턴스를 보유할 수 있습니다! 가상 머신이 한두 개만 필요한 회사의 수는 줄어들고 있습니다.

이 모든 것이 GUI 관리가 가까운 미래에, 심지어 먼 미래에도 사라질 것이라는 것을 거의 의미하지는 않습니다. "일회성" 시스템 관리의 필요는 여전히 남을 것입니다. 하지만 GUI 관리 "일회성" 모드로 작업할 수 있는 관리자 대 커맨드라인, 특히 스크립트 또는 완전 자동화 시스템(Puppet, Chef, Ansible 등)을 통해 작업해야 하는 관리자의 비율은 이미 비GUI 시스템 관리 및 DevOps 관행으로 믿을 수 없을 정도로 빠르게 기울고 있습니다.

이것이 실제 현장의 우리에게 무엇을 의미하는가? 소규모 비즈니스 Windows 관리처럼 전통적으로 커맨드라인에서 거의 또는 전혀 작업할 필요가 없었던 역할들도 업무를 위한 로컬 서버 GUI 의존도를 재고해야 한다는 것을 의미합니다. 커맨드라인 도구와 프로세스는 점점 더 강력해지고 잘 알려지고 있으며 우리가 기대되는 작업 방식이 되고 있습니다. UNIX 세계에서 커맨드라인은 항상 남아 있었으며 GUI 도구에 의존해야 하는 필요는 거의 항상 큰 핸디캡으로 보여졌습니다. 이 동일한 인상이 Windows 세계에도 적용되기 시작하고 있습니다. 서서히 GUI 도구에만 의존하는 사람들은 이등 시민으로 보여지고 점점 더 주니어 역할과 소규모 조직에 국한되고 있습니다.

스크립팅 및 자동화 도구의 개선은 또한 규모의 가치가 더 좋아지고 있음을 의미하므로 소수의 서버를 관리하는 비용이 워크로드별로 매우 높아지고 있습니다. 이는 더 작은 회사들이 대규모 시스템 관리를 전문으로 하고 스크립팅 및 자동화 기술을 활용하여 비용을 대기업 비용에 더 가깝게 맞출 수 있는 외부 벤더 사용을 통한 관리 통합을 추구하는 것에 대한 강력한 장려책이 됩니다. 외부 벤더를 사용하여 규모 또는 그에 근접한 것을 확립하는 능력은 시간이 지남에 따라 더 작은 비즈니스들이 IT 요구사항에서 비용 경쟁력을 유지하면서도 오늘날 대기업들이 경험하기 시작한 것과 같은 스타일의 컴퓨팅 이점을 얻는 데 매우 중요할 것입니다.

이 커맨드라인 및 자동화 도구로의 업계 전환과 동시에 더 현대적이고 강력하며 주로 원격인 GUI로의 이동도 일어나고 있다는 점을 주목해야 합니다. 이것은 훨씬 덜 극적인 변화이지만 간과해서는 안 됩니다. Microsoft의 RSAT 및 서버 관리자 같은 도구들은 내부적으로 커맨드라인 및 API 인터페이스를 활용하는 GUI 뷰를 제공합니다. 마찬가지로 Canonical의 Ubuntu 세계에는 이제 Landscape가 있습니다. 이러한 도구들은 엔터프라이즈에서는 덜 인기 있지만 더 큰 SMB 시장이 더 많은 서버 인스턴스 세트를 관리하면서도 GUI 의존성을 유지할 수 있게 하기 시작하고 있습니다. 이러한 유형의 GUI 도구의 발전은 전반적으로 커맨드라인 도구 채택을 늦추는 가장 강력한 힘이 될 수 있습니다.

커맨드라인에서 GUI로, 다시 커맨드라인으로의 이동이 정보 기술 업계 역사의 흥미로운 유물로서 관심이 있든, 아니면 시스템 관리가 우리 자신의 용도를 위한 커리어 경로나 비즈니스 접근 방식으로 어떻게 진화하고 있는지를 이해하는 수단으로서 관심이 있든, 그것이 발생한 요인들과 업계의 흐름이 왜 다시 커맨드라인의 바다로 우리를 데려가고 있는지를 이해하는 것은 우리에게 유익합니다. 이러한 힘들을 이해함으로써 미래가 우리를 어디로 데려갈지, 조류가 다시 바뀔 수 있는지, 우리 자신의 커리어에 어떻게 접근하는 것이 최선인지, 또는 조직의 기술과 인재 모두를 어떻게 결정할지를 더 실용적으로 평가할 수 있습니다.