장기 지원 릴리스에 대한 재고

전통적으로 장기 지원(LTS) 운영 체제 릴리스는 엔터프라이즈 배포의 기반이었습니다. 이것은 IBM, Oracle, Microsoft, Suse, Red Hat이 사용하는 모델이며, 수십 년 전 지원 서비스가 시작된 이래로 운영 체제에 관한 관습적인 사고 방식이었습니다.

과거에는 서버와 데스크톱 운영 체제 릴리스 모두 이 모델을 따르는 것이 일반적이었지만, Linux 공간에서는 특히 덜 공식적인 제품들이 더 빠른 릴리스, 비지원 릴리스, 또는 단순히 비구조적인 릴리스를 실험할 자유를 얻으면서 이 모델이 흔들리기 시작했습니다. 주요 제품군에서 openSuse, Fedora, Ubuntu는 모두 단기 지원 또는 빠른 릴리스 제품을 제공했습니다. 수년 단위의 릴리스 주기와 10년에 가까운 지원 주기 대신, 릴리스 주기를 몇 개월로 단축하고 지원 기간을 몇 개월 또는 최대 몇 년으로 줄였습니다.

데스크톱 공간에서는 서버에서 일반적이었던 안정성에 주로 집중하는 대신 새로운 기능과 애플리케이션을 더 빨리 얻는 것이 종종 합리적이었으며, 새로운 기술이나 접근 방식을 장기 지원 서버 제품에 통합하기 전에 더 빠른 릴리스 주기의 제품에서 테스트할 수 있다는 추가적인 이점도 있었습니다. 예를 들어, Fedora는 검증된 후 Red Hat Enterprise Linux 릴리스에 포함될 기술들의 테스트 장이 됩니다. Fedora를 사용함으로써 최종 사용자는 기능을 더 빨리 얻고 RHEL 기술을 더 일찍 배울 수 있으며, Red Hat은 중요 서버에 배포하기 전에 대규모로 제품을 테스트할 수 있습니다.

시간이 지남에 따라 단기 릴리스의 안정성이 크게 향상되었고, 이러한 시스템들은 점점 더 서버 시스템의 실행 가능한 옵션으로 여겨지고 있습니다. 이러한 시스템들은 더 새로운 개선 사항, 기능, 업그레이드를 더 빨리 제공받는데, 이는 종종 유익한 것으로 여겨집니다.

운영 체제의 주요 이점 중 하나는 기본 운영 체제의 일부로 지원되고 제공되는 패키지와 라이브러리를 포함한 지원 생태계입니다. 장기 릴리스에서는 릴리스 수명 전반에 걸쳐 중요한 패키지가 크게 노후화되는 경우가 많으며, 이는 극단적인 경우 성능, 호환성, 심지어 보안 문제를 일으킬 수 있습니다. 이는 명백히 장기 릴리스 운영 체제 사용자들로 하여금 구버전 구성 요소의 한계를 계속 감수하거나, 새로운 구성 요소를 스스로 통합해야 하는 선택을 강요하는데, 후자는 종종 장기 릴리스 제품의 근본적인 가치를 훼손합니다.

장기 릴리스의 목표가 안정성과 통합 테스트를 갖는 것이기 때문에, LTS의 한계를 “우회하기” 위해 제품 내 구성 요소를 교체하는 것은 그 구성 요소들이 LTS 방식으로 취급되지 않고 있으며, 벤더의 통합 테스트가 더 이상 진행되지 않거나, 진행되더라도 같은 수준이 아님을 의미합니다. 사실상 이것은 레거시 핵심 구성 요소와 더 적은 감독을 가진 자체 제작 단기 릴리스 제품이 됩니다.

실질적으로 대부분의 측면에서 이렇게 하는 것은 처음부터 단기 릴리스 제품으로 가는 것보다 더 나쁩니다. 단기 또는 빠른 릴리스 제품을 사용하면 벤더가 가정된 테스트와 통합을 유지할 수 있으며, 단지 더 빠른 릴리스와 지원 주기를 가질 뿐이므로, 일부 구성 요소만이 아니라 운영 체제의 모든 구성 요소에 대해 장기 릴리스 개념의 일반적인 가치가 유지됩니다. 이는 부분적인 LTS 모델보다 더 많은 표준화, 산업 테스트, 공유 지식 및 통합을 가능하게 합니다.

운영 체제의 장기 지원 가치를 재고할 때가 왔을지도 모릅니다. 너무 오랫동안 이 접근 방식의 가치는 당연한 것으로 여겨지고 따라왔으며, 분명히 장점이 있었고 지금도 있습니다. 하지만 운영 체제 세계는 이 접근 방식이 처음 도입된 이후로 변화했습니다. 업데이트의 필요성은 증가한 반면, 커널과 라이브러리와 같은 것들의 변화 속도는 크게 느려졌습니다. 더 강력한 서버들이 호환성을 스택 위로 이동시켰으며, 소프트웨어는 운영 체제에 직접 맞춰 작성되기보다는 특정 언어 버전이나 런타임 또는 다른 추상화 레이어에 맞춰 작성되는 경우가 많습니다.

짧은 릴리스 주기는 시스템이 상하단 전반에 걸쳐 더 자주 기능을 얻는다는 것을 의미합니다. “주요” 릴리스 간 업데이트는 더 작고 영향이 적습니다. 업데이트로 인한 변경 사항이 더 점진적이므로 더 유기적인 학습 및 적응 곡선을 제공합니다. 그리고 가장 중요하게, 신중하게 테스트되고 통합된 시스템 구성 요소를 서드파티 제공 버전으로 교체해야 할 필요성이 사실상 없어집니다.

소프트웨어 벤더에게 안정성은 장기 릴리스의 여전히 중요한 가치이며, 앞으로도 오랫동안 장기 릴리스를 사용해야 할 필요성을 유발할 것입니다. 하지만 시스템 관리자에게는 이 접근 방식의 가치가 줄어드는 것 같으며, 개인적으로 최근 몇 년 사이에 변곡점을 찾았다고 느낍니다. 패키지가 업데이트되기까지 2~3년을 기다리는 것이 당연하고 정상적인 것처럼 보였지만, 오늘날 이것은 불필요하게 번거롭게 느껴집니다. 상위 수준 구성 요소들이 더 새로운 기반 구성 요소를 요구하도록 구축되는 경우가 점점 더 많아지고 있습니다. 운영 체제가 더 최신 버전이거나 OS의 일부가 나머지와 별도로 업데이트될 것이라는 기대가 있습니다.

컨테이너화 기술에 대한 강한 의존은 어떤 면에서 이 트렌드를 역전시킬 수 있지만, 동시에 항상 장기 릴리스의 가치를 줄이는 방식으로 그렇게 합니다. 컨테이너화는 기본 운영 체제에 필요한 광범위한 기능의 필요성을 줄여, 향상된 커널, 파일 시스템, 드라이버, 컨테이너 지원을 위해 더 자주 업데이트하는 것을 더 쉽고 효과적으로 만들면서, 라이브러리와 다른 의존성은 컨테이너에 남겨 장기 지원 의존성이 필요한 애플리케이션은 그 방식으로, 최신 구성 요소에서 혜택을 얻을 수 있는 애플리케이션은 그에 맞게 처리될 수 있도록 합니다.

물론 가상화는 시스템의 신속한 복구와 복제를 쉽게 만들어 장기 지원 모델의 가치를 줄이는 역할을 해왔습니다. 장기 지원 릴리스가 다루어야 했던 안정성은 가상화 레이어에 의해 부분적으로 해결됩니다. 하드웨어 추상화는 매우 중요한 방식으로 드라이버 안정성을 향상시킵니다. 같은 맥락에서, 데브옵스 스타일의 지원 모델도 장기 지원의 필요성을 줄이고 서버 생태계를 더 민첩하고 유연하게 만듭니다. 시스템 관리 패러다임의 트렌드는 더 현대적인 운영 체제를 선호하는 방향으로 나아가고 있습니다.

트렌드가 향하는 방향으로 계속될지는 시간이 말해줄 것입니다. 저 자신은 지난 1년이 눈을 뜨게 해주는 한 해였으며, 10년간의 매우 장기 지원 제품에 대한 확고한 지지에서 빠른 릴리스 제품으로 제 워크로드를 이전했고, 그 변화에 매우 만족하고 있다고 말할 수 있습니다.