Linux 배포판의 역사와 계보 정리

Linux 배포판의 실체

Linux 배포판의 역사는 공백에서 시작됩니다. Linux 커널 자체만으로는 사용자가 활용할 수 있는 기능이 없습니다. 커널은 부팅하고 하드웨어를 인식할 뿐, 그 이후에는 아무것도 하지 않습니다. 누군가는 사용자 공간(userland)을 추가하고, 소프트웨어 설치 및 업데이트 방식을 결정하며, 수년간 유지보수를 책임지겠다고 약속해야 합니다. 배포판이란 이러한 선택의 집합이며, 그 이후에도 함께하는 사람들의 모임입니다.

배포판은 다섯 가지 요소로 구성됩니다. 이 중 하나라도 변경되면 대부분의 바이너리가 일치하더라도 서로 다른 배포판이 됩니다.

• 커널: 프로젝트가 선택한 버전이며, 추가된 패치와 드라이버가 포함됩니다.
• 사용자 공간: C 라이브러리, 셸, init 시스템, 표준 명령어가 포함됩니다.
• 패키지 형식 및 설치 도구: 소프트웨어를 관리하는 방식입니다.
• 릴리스 정책: 무엇이 변경될 수 있는지, 얼마나 자주 변경되는지, 각 릴리스가 얼마나 오랫동안 수정되는지를 결정합니다.
• 사람: 패키지 관리자, 보안 팀, 그리고 패키지에 문제가 생겼을 때 대응하는 인력입니다.

커널은 공유되는 부분이므로, 두 Linux 배포판은 서로 다른 Unix 계열 운영체제보다 훨씬 더 가깝습니다. 이 점은 서버 플랫폼으로서의 Linux와 FreeBSD를 비교할 때 기억해야 할 중요한 사실입니다. FreeBSD와 같은 시스템은 커널과 기본 사용자 공간이 하나의 프로젝트에 의해 빌드되고 함께 릴리스됩니다. 반면 Linux에서는 이러한 구성 요소들이 각기 다른 업스트림에서 제공되며, 배포판은 이들을 조율하여 하나의 운영체제로 만드는 역할을 합니다.

세 가지 계보로 보는 리눅스 배포판의 역사

1993년과 1994년에 시작된 세 프로젝트가 각각의 계보를 형성했습니다. 바로 Slackware, Debian, Red Hat입니다. 오늘날 VPS 제어판에서 볼 수 있는 거의 모든 이미지는 이들 중 하나이거나 그 파생형입니다. 파생형은 패키지 형식, 파일 구조, 그리고 대개 릴리스 관행까지 그대로 물려받습니다. 이것이 바로 Debian 기반 배포판에서 브랜딩을 제거해도 여전히 Debian처럼 느껴지는 이유입니다.

독립적인 배포판들은 별도의 계보로 분류해야 합니다. 이들은 그 누구로부터도 갈라져 나오지 않았기 때문입니다. Arch, Gentoo, Alpine, NixOS, Void는 각각 독자적인 패키지 관리자와 규칙을 직접 만들었습니다. 이 중 Arch와 Alpine 두 배포판은 데스크톱과는 전혀 무관한 이유로 결국 여러분이 사용하는 서비스 제공업체의 이미지 목록에 포함되었습니다.

1992년: 배포판 계보 이전의 초기 형태

MCC Interim Linux는 1992년 2월 맨체스터 컴퓨팅 센터(Manchester Computing Centre)의 Owen Le Blanc이 구성하여 등장했습니다. 이 배포판은 커널과 GNU(GNU's not Unix) 도구를 한 쌍의 플로피 디스크 이미지에 담아 메뉴 방식의 설치 프로그램을 제공했습니다. 수동으로 이를 설치하는 데 하루가 꼬박 걸렸기 때문에 이 배포판이 탄생했습니다.

1992년 Peter MacDonald가 출시한 SLS(Softlanding Linux System)는 여기서 더 나아가 X(X Window System)와 TCP/IP 네트워킹을 추가했습니다. 오늘날 배포판(distribution)이라는 용어가 현재의 의미로 정착된 것은 SLS 덕분입니다. 하지만 SLS는 버그가 많았고 유지보수가 느렸으며, 1993년 두 사람이 각자 이를 해결하기로 마음먹었습니다. 한 명은 기존 시스템을 재구축했고, 다른 한 명은 명확한 규칙을 세워 처음부터 다시 시작했습니다.

Slackware, 1993: 여전히 유지되는 가장 오래된 계보

Patrick Volkerding은 1993년 7월 16일, SLS에서 버그를 제거하여 빌드한 Slackware 1.00을 출시했습니다. 이 배포판은 현재까지 유지되고 있으며, 현존하는 가장 오래된 Linux 배포판입니다.

Slackware 패키지는 내부에 설치 스크립트가 포함된 압축 tar 아카이브입니다. 의존성 해결 기능은 존재하지 않으며, 새 패키지에 필요한 라이브러리가 디스크에 이미 존재하는지 확인하는 과정이 없습니다. 이러한 단일 결정이 다른 모든 특성을 형성했습니다. 도구가 의존성을 해결하지 않기 때문에, 배포되는 패키지 세트는 구성 단계부터 일관성을 유지해야 하며, 이로 인해 릴리스는 드물고 보수적으로 이루어집니다. Slackware 15.0은 14.2 이후 6년이 지난 2022년 2월에 출시되었습니다.

이 계보는 규모가 작습니다. 1990년대 중반 SUSE의 초기 릴리스는 Slackware를 기반으로 빌드되었으나, 이후 프로젝트가 YaST와 RPM 패키지 형식을 도입하며 독자적인 길을 걷게 되었습니다. 이 마지막 부분은 종종 혼란을 야기합니다. SUSE와 openSUSE는 RPM 패키지를 사용하지만, Red Hat 계열은 아닙니다. 형식은 전파되었으나, 계보는 이어지지 않았습니다.

Debian, 1993: 사회 계약과 3단계 스위트 파이프라인

Ian Murdock은 Slackware가 발표된 지 3주 후인 1993년 8월 16일, 같은 이유로 Debian을 발표했습니다. Debian이라는 이름은 그의 파트너 Debra와 자신의 이름에서 따왔습니다. 1994년 1월에 발표된 Debian Manifesto는 이 배포판이 기업이 아닌 자원봉사자들에 의해 공개적으로 유지될 것임을 명시했습니다.

이후 Debian은 운영 원칙을 문서화했습니다. 1997년 7월 Debian Social Contract와 DFSG(Debian free software guidelines)가 채택되었으며, DFSG는 1998년 Open Source Definition의 기반이 되었습니다. 특정 배포판의 포함 범위를 정하기 위해 작성된 문서가 결과적으로 전체 산업의 라이선스 범주를 정의하게 된 것입니다. 이것이 바로 여러분의 sources.list가 여러 구성 요소를 갖는 이유입니다. main에는 가이드라인을 충족하는 소프트웨어가 포함되고, contrib과 non-free에는 그렇지 않은 소프트웨어가 포함됩니다. Debian 12에서는 무선 랜 카드가 장착된 노트북에서 별도의 복잡한 과정 없이 설치할 수 있도록 non-free-firmware가 추가되었습니다.

도구 체인 또한 중요한 유산입니다. dpkg은 패키지를 하나 설치할 때 의존성이 부족하면 설치를 거부하고 dpkg: dependency problems prevent configuration of을 출력합니다. 1999년 Debian 2.1부터 기본값이 된 APT(advanced package tool)는 무엇을 추가로 가져와야 할지, 어떤 순서로 설치할지 결정하는 계층입니다. 모든 Debian 파생 배포판의 모든 apt 명령어는 이 작업에서 파생되었습니다.

릴리스 시스템은 3개의 스위트와 1개의 규칙으로 운영됩니다. 관리자가 unstable(코드명 sid)에 패키지를 업로드하면, 스크립트가 릴리스 아키텍처에서 정상적으로 빌드되고 새로운 릴리스 치명적 버그가 없는지 확인한 뒤 약 5일에서 10일 후에 testing으로 패키지를 이동시킵니다. 이후 testing이 freeze(동결)되고 릴리스 팀이 남은 문제를 해결하면, 버그 목록이 충분히 줄어들었을 때 stable이 릴리스됩니다. 날짜를 정해두고 배포하지 않습니다. Debian stable이 구형처럼 보이지만 안정적인 이유는 릴리스 동결 시점에 버전 번호가 고정되고, 이후에는 보안 수정 사항만 백포트되기 때문입니다.

거버넌스 또한 문서화되어 있으며, 선출된 프로젝트 리더와 구속력 있는 일반 결의안을 통해 운영됩니다. 2014년 이 체계는 systemd를 기본 init 시스템으로 채택했습니다. 이에 반대하는 사람들은 Devuan을 포크(fork)하여 2017년에 첫 릴리스를 내놓았습니다. Debian은 이러한 전환을 단행한 첫 번째 배포판도, 마지막 배포판도 아니었습니다. 이 변화가 반복된 이유와 그 과정에서 제기된 타당한 반론들은 systemd가 SysV init을 대체한 과정에 대한 기록에서 확인할 수 있습니다. 주요 파생 배포판으로는 Ubuntu, Raspberry Pi OS, Proxmox VE, Kali, Linux Mint 등이 있습니다.

Red Hat, 1994년: RPM의 등장과 Fedora 및 RHEL로의 분리

Marc Ewing은 1994년 핼러윈 무렵 첫 번째 Red Hat Linux를 출시했습니다. 1995년 Bob Young의 회사가 이를 인수했고, 두 사람은 소프트웨어가 아닌 기술 지원을 판매하는 최초의 Linux 비즈니스 모델을 구축했습니다. Red Hat은 1999년 8월 11일에 상장했습니다. IBM은 2019년 7월 약 340억 달러에 이 회사를 인수 완료했으며, 이후 대부분의 엔터프라이즈 소프트웨어가 인증 기준으로 삼는 배포판은 IBM의 자산이 되었습니다.

지속적인 기술적 기여는 1995년 Red Hat Linux 2.0을 위해 Erik Troan과 Marc Ewing이 작성한 RPM(Red Hat package manager)입니다. RPM은 의존성을 선언하며, 누구나 실행할 수 있는 빌드 레시피인 spec 파일을 통해 생성됩니다. 이 두 번째 특성 덕분에 나중에 Red Hat의 엔터프라이즈 제품을 독립적으로 재빌드하는 것이 가능해졌습니다.

2003년의 Red Hat Linux 9는 기존 라인업의 마지막 버전이었습니다. 회사는 이를 두 갈래로 나누었습니다. 2003년 11월에는 빠른 커뮤니티 릴리스인 Fedora Core 1이, 2002년 Advanced Server 2.1로 시작된 느리고 유료인 RHEL(Red Hat Enterprise Linux)이 각각 출시되었습니다. 이유는 명확합니다. 하나의 제품이 새로운 버전을 시험하는 장소인 동시에 은행이 10년 동안 수정 없이 운영하는 플랫폼이 될 수는 없기 때문입니다. 두 부분은 서로 연결되어 있습니다. RHEL 메이저 버전은 Fedora 릴리스에서 분기되어 안정화 과정을 거친 뒤 고정됩니다. 패키지 도구 또한 같은 일정에 따라 발전하여, 2000년대의 yum에서 2015년 Fedora의 기본값인 dnf로 이동했으며, 두 제품 모두 그 기반에 rpm를 사용합니다.

CentOS가 무료 RHEL 리빌드 배포판을 중단한 이유

CentOS는 2004년 단순한 목표로 시작되었습니다. Red Hat이 공개한 소스 패키지를 가져와 상표를 제거하고, 다시 빌드하여 무료로 배포하는 것이었습니다. 이 프로젝트는 10년 동안 기본 무료 서버 배포판으로 자리 잡았고, 2014년 Red Hat이 프로젝트를 인수했습니다.

2020년 12월 8일, Red Hat은 CentOS Linux 8의 지원을 당초 예정보다 8년 앞당긴 2021년 12월 31일에 종료한다고 발표했습니다. 또한 CentOS라는 이름은 CentOS Stream으로 이어질 것이라고 밝혔습니다. Stream은 리빌드 버전이 아닙니다. RHEL 마이너 릴리스가 생성되는 브랜치이므로, RHEL보다 뒤처지는 것이 아니라 앞서 나갑니다. 수년간 운영해야 하는 서버 입장에서 '앞서 나가는 것'은 잘못된 방향입니다. Red Hat의 유료 고객보다 먼저 변경 사항을 적용받기 때문입니다.

2021년에는 두 개의 리빌드 프로젝트가 등장했습니다. Rocky Linux는 CentOS의 공동 창립자인 Gregory Kurtzer가 시작했습니다. AlmaLinux는 CloudLinux의 지원을 받아 설립되었습니다. 2023년 6월, Red Hat은 CentOS Stream과 고객 포털을 제외한 모든 곳에서 RHEL 소스 공개를 중단했습니다. Rocky Linux는 여전히 동일한 리빌드를 목표로 합니다. AlmaLinux는 목표를 ABI(Application Binary Interface) 호환성으로 변경했습니다. 이는 RHEL용으로 빌드된 소프트웨어가 실행된다는 의미이지만, 버그 목록까지 완벽하게 일치한다는 보장은 없습니다. 그해 말 Oracle, SUSE, CIQ는 공유 소스를 공개하기 위해 OpenELA를 설립했습니다. 2003년의 분기부터 2023년의 소스 공개 정책 변경, 그리고 각 리빌드 프로젝트가 현재 약속하는 바에 이르는 전체 과정은 Red Hat, CentOS, Rocky, AlmaLinux에 대한 상세 설명에서 확인할 수 있습니다.

제공업체의 이미지 목록에 여전히 CentOS라고 표기되어 있다면, 구축하기 전에 어떤 버전을 의미하는지 반드시 확인하십시오.

cat /etc/os-release

NAME="CentOS Stream"은 RHEL을 선행하는 롤링 개발 브랜치입니다. NAME="AlmaLinux" 또는 NAME="Rocky Linux"은 10년의 지원 기간을 제공하며 RHEL을 뒤따르는 리빌드 버전입니다.

Ubuntu 20.04: Debian unstable의 일정 기반 스냅샷

Ubuntu 4.10은 Mark Shuttleworth의 지원을 받아 2004년 10월 20일에 출시되었습니다. Debian과의 관계는 감정적인 유대보다는 기계적인 결합에 가깝습니다. 각 개발 주기는 Debian unstable의 패키지를 새로운 Ubuntu 릴리스로 가져오는 작업으로 시작됩니다. 이러한 가져오기 작업은 주기 중간에 있는 Debian Import Freeze 시점까지 계속되며, 그 이후부터는 Ubuntu가 자체적인 변경 사항을 관리합니다. 많은 Ubuntu 패키지는 Debian 패키지에 델타(delta)가 추가된 형태이며, changelog에서 그 내용을 확인할 수 있습니다.

다른 절반은 일정입니다. Debian은 준비가 완료되면 출시합니다. 반면 Ubuntu는 4월과 10월에 출시하며, 버전 번호는 출시 날짜를 따릅니다. 예를 들어 24.04는 2024년 4월에 출시되었습니다. 2년마다 돌아오는 4월 릴리스는 LTS(long term support) 버전이며, 서비스 제공업체가 별도의 수식어 없이 Ubuntu를 나열할 때 지칭하는 대상이 바로 이것입니다. 서버에 어떤 버전을 설치할지는 Ubuntu LTS와 중간 릴리스 선택하기의 전체 주제이며, 한 LTS 버전에서 다음 LTS 버전으로 이동하는 절차는 24.04에서 26.04로 업그레이드에서 다룹니다.

매년 서버 관리자들이 간과하는 세부 사항이 하나 있습니다. Ubuntu 아카이브는 여러 구성 요소로 나뉩니다. main는 Canonical이 전체 지원 기간 동안 유지 관리합니다. universe은 커뮤니티가 유지 관리하며, 보안 지원 범위에 대한 약속이 다릅니다. apt install은 이 차이에 대해 별도로 명시하지 않습니다. 다음 명령어를 사용하면 이를 확인할 수 있습니다.

apt-cache policy nginx

저장소 라인이 /main로 끝난다면 해당 패키지는 Canonical 보안 팀이 관리한다는 의미입니다. /universe으로 끝난다면 커뮤니티가 관리한다는 의미입니다. 인터넷에 노출되는 모든 패키지에 대해 이 사항을 확인하십시오.

Arch, 2002: 롤링 릴리스와 부분 업그레이드의 비용

Judd Vinet은 2002년 3월 11일, 직접 작성한 패키지 관리자인 pacman와 일반 셸 스크립트로 구성된 빌드 레시피를 포함한 Arch 0.1을 출시했습니다. Arch에는 버전이 구분된 릴리스가 전혀 없습니다. 설치 미디어는 동일한 롤링 저장소의 날짜별 스냅샷일 뿐이므로, 2019년에 설치하여 매주 업데이트한 시스템은 오늘 새로 설치한 Arch와 동일하게 동작합니다. AUR(Arch user repository)에는 사용자가 기여한 빌드 레시피가 저장됩니다. 이는 검토를 거친 패키지가 아닌 레시피 형태이므로, 실행하기 전에 PKGBUILD를 읽는 것은 사용자의 몫입니다.

롤링 릴리스에는 한 가지 실패 유형이 있으며, 이는 전적으로 사용자 과실로 발생합니다. pacman -Sy foo를 사용하여 단일 패키지를 설치하면 패키지 데이터베이스가 새로 고침된 후, 디스크에 있는 라이브러리보다 최신 버전의 라이브러리에 링크된 새로운 바이너리가 설치됩니다. 이로 인해 프로그램은 다음과 같이 실패합니다.

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

공식적으로 지원되는 작업은 pacman -Syu이며, 이는 모든 패키지를 한꺼번에 업데이트합니다. 프로젝트 측은 특정 업그레이드 전 수동 개입이 필요하다는 뉴스 항목을 게시하기도 합니다. 이를 읽지 않고 업그레이드를 실행하면 시스템이 부팅되지 않는 상태가 될 수 있습니다.

이러한 특성 때문에 Arch는 관리를 소홀히 할 서버에는 적합하지 않습니다. 매주 업데이트하는 서버는 문제가 없지만, 1년 뒤에 한 번 업데이트하는 서버는 그동안 건너뛴 모든 수동 개입 사항을 한 번에 처리해야 하는 상황을 초래합니다.

Alpine: 컨테이너로 유명해진 경량 배포판

Alpine은 2005년경 LEAF(Linux embedded appliance framework)의 포크로 시작되었습니다. LEAF 자체는 Linux Router Project에서 파생된 것이며, Natanael Copa는 이를 데스크톱이 아닌 어플라이언스 용도로 구축했습니다. Alpine은 일반적인 사용자 공간(userland) 대부분을 대체합니다. GNU C 라이브러리 대신 musl을, GNU 코어 유틸리티 대신 BusyBox를, systemd 대신 OpenRC를 사용하며, 패키지 관리자로는 apk을 사용합니다. 2014년에 출시된 Alpine 3.0은 musl로 전환된 버전입니다.

컨테이너 기술이 Alpine을 유명하게 만들었습니다. Alpine 베이스 레이어는 Debian이나 Ubuntu 베이스보다 크기가 훨씬 작습니다. 따라서 2016년부터는 일반적인 베이스 이미지로 자리 잡았고, Alpine을 직접 설치해 본 적 없는 많은 사람이 매일 이를 실행하게 되었습니다.

문제는 musl이 glibc와 다르다는 점이며, 이 차이는 전혀 관련 없어 보이는 버그로 나타납니다. glibc에 링크된 바이너리는 Alpine에서 실행 시 이미 존재하는 파일을 찾지 못한다는 메시지를 출력하며 실패합니다.

sh: ./myapp: not found

프로그램은 존재합니다. 하지만 glibc의 로더가 없기 때문에 ELF 인터프리터가 동작하지 않는 것입니다. Python 또한 흔히 겪는 문제입니다. manylinux용으로 미리 빌드된 휠(wheel)은 musl에 설치되지 않습니다. 따라서 pip는 소스 코드 컴파일을 시도하지만, 컴파일러가 설치되어 있지 않으면 중단됩니다. 2021년에 도입된 musllinux 휠 표준은 해당 휠을 게시하는 프로젝트에는 문제를 해결해 주었지만, 그 외의 경우에는 여전히 문제가 남습니다.

VPS의 호스트 운영체제로 사용할 경우, Alpine은 설치 용량이 작고 업데이트가 빠릅니다. 하지만 대부분의 문서가 가정하는 표준 경로에서 벗어나게 됩니다. systemctl enable을 실행하라는 모든 가이드는 rc-update add로 변환하여 적용해야 합니다.

불변 세대: 원자적 업데이트와 이미지 기반 서버

최신 브랜치는 패키지 목록 대신 업데이트 모델을 변경합니다. ostree 기반 시스템은 /usr를 읽기 전용으로 유지합니다. 업데이트는 완전히 새로운 파일 시스템 트리이며, 다운로드 및 준비 과정을 거친 뒤 다음 재부팅 시점에 전환됩니다. 이전 트리는 부팅 항목으로 남기 때문에, 업데이트에 문제가 생기면 이전 트리로 재부팅하여 즉시 복구할 수 있습니다.

Fedora Silverblue는 2018년에 이를 데스크톱으로 가져왔고, Red Hat이 2018년에 CoreOS를 인수한 후 2019년에는 Fedora CoreOS가 이를 서버에 도입했습니다. Flatcar Container Linux는 2020년 Container Linux가 퇴역한 이후 그 명맥을 이었습니다. openSUSE MicroOS는 btrfs 스냅샷과 transactional-update을 통해 같은 목표에 도달합니다. 2024년 Red Hat은 bootc를 기반으로 RHEL에 이미지 기반 모드를 추가했습니다. 이 방식에서 운영 체제는 컨테이너 이미지로 제공되며, 새로운 태그를 지정하는 방식으로 시스템을 업데이트합니다. Talos Linux는 여기서 더 나아가 셸과 SSH를 완전히 제거했습니다. 이 시스템은 API를 통해 구성되므로 로그인할 대상 자체가 존재하지 않습니다. 2007년에 처음 출시된 NixOS는 다른 방향에서 접근합니다. 전체 시스템은 하나의 선언적 구성에서 빌드되며, 이전 세대들은 부팅 가능한 상태로 유지됩니다.

대부분의 제공업체는 이러한 시스템을 원클릭 이미지로 제공하지 않습니다. 관리자가 SSH로 파일을 직접 수정하는 방식이 아니라, 첫 부팅 시 Ignition이나 cloud-init을 통해 구성되기를 기대하기 때문입니다. 이러한 방식은 동일한 서버를 다수 운영할 때 진가를 발휘합니다. 여러 대의 Linux 서버를 동시에 관리하며 각 서버가 서로 완벽하게 동일함을 증명해야 하는 상황이라면 이러한 시스템이 적합합니다.

한 릴리스는 얼마나 오랫동안 지원됩니까?

릴리스 정책은 배포판을 사용할 때 가장 오랫동안 영향을 받는 부분이며, 일반적으로 연 단위로 발표됩니다. 다음은 현재 서버 릴리스 5개에 대한 지원 기간입니다.

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine은 각 3.x 브랜치를 2년 동안 지원합니다. 이 때문에 Alpine은 방치해 두는 호스트보다는 자주 다시 빌드하는 컨테이너 이미지에 더 적합합니다. Debian 보안 팀은 안정(stable) 릴리스를 약 3년 동안 지원하며, 이후 LTS 팀이 일반적인 아키텍처에 대해 총 5년까지 지원을 이어갑니다. Ubuntu LTS는 main 내 패키지에 대해 5년을 제공하며, Ubuntu Pro 구독을 이용하면 이를 10년까지 연장할 수 있습니다. 개인용으로 소수의 머신에서 사용하는 경우 무료입니다. RHEL 10은 10년을 발표했으며, 유료인 연장 수명 주기 지원(extended life cycle support) 애드온을 추가하면 13년까지 늘어납니다. AlmaLinux 10은 구독 없이도 RHEL과 동일한 10년의 지원 기간을 제공하며, 이것이 바로 리빌드(rebuild) 배포판이 존재하는 이유입니다.

Arch는 이 목록에 포함되지 않습니다. 롤링 릴리스 방식의 배포판은 지원해야 할 특정 릴리스가 없기 때문입니다. Arch에서 중요한 수치는 머신을 업데이트하지 않고 방치할 수 있는 기간이며, 이는 주(week) 단위로 측정됩니다.

VPS 이미지 목록이 이렇게 구성된 이유

제공업체는 고객이 요청한 이름에 맞춰 하이퍼바이저에 자동으로 설치되는 이미지를 배포합니다. 이것이 거의 모든 목록이 Ubuntu LTS와 Debian stable로 시작하고, RHEL 기반 소프트웨어 인증이 필요한 사용자를 위해 AlmaLinux나 Rocky를 추가하며, Alpine, Arch, Fedora를 목록 하단에 배치하는 이유입니다. VPS의 정의와 이미지가 디스크에 도달하는 과정을 이해하면 이 패턴이 명확해집니다. 제공업체는 자동 설치를 견딜 수 있고, 일반적인 고객의 서버 운영 기간보다 더 오래 지원되는 운영체제를 선택하는 것입니다.

이 선택은 단순히 패키지 관리자 이상의 것을 결정합니다. 3년 뒤에 수행할 업그레이드 방식을 결정하며, 이는 운영체제 계열마다 완전히 다릅니다. Debian과 Ubuntu는 제자리에서 수행하는 메이저 업그레이드를 지원합니다. Red Hat 계열은 leapp을 통해 업그레이드를 진행합니다. Arch는 버전 개념이 없으므로 업그레이드라는 개념 자체가 없습니다. Alpine은 /etc/apk/repositories을 편집하고 apk upgrade --available을 실행하는 방식입니다. 또한 이 선택에 따라 타사 저장소를 추가하지 않고 설치할 수 있는 소프트웨어, CVE(공통 취약점 및 노출) 항목이 발표되었을 때 패치를 배포하는 주체, 그리고 향후 설치할 소프트웨어가 기본으로 가정하는 init 시스템과 C 라이브러리가 결정됩니다.

과소평가하기 쉬운 영향이 하나 더 있습니다. 인터넷에 올라온 대부분의 답변은 Debian 계열이나 Red Hat 계열의 경로를 가정합니다. 따라서 이 두 계열 이외의 운영체제를 선택하면 서버를 운영하는 내내 지침을 직접 변환해야 합니다. 서버를 얼마나 자주 관리할 의향이 있는지에 맞춰 릴리스 정책이 부합하는 계열을 선택하고, 그 상태를 유지하십시오. 상위 패키지를 변경하는 것은 쉽습니다. 하지만 그 아래의 배포판을 바꾸는 것은 서버를 처음부터 다시 구축해야 함을 의미합니다.

FAQ

내 서버는 어떤 리눅스 배포판 계열입니까?

cat /etc/os-release를 실행하십시오. ID 필드에는 배포판 이름이, ID_LIKE 필드에는 계열 이름이 표시됩니다. 예를 들어 Ubuntu 머신은 ID_LIKE=debian를, AlmaLinux 머신은 ID_LIKE="rhel centos fedora"을 출력합니다. 패키지 관리자도 구분 방법 중 하나입니다. apt와 dpkg는 Debian 계열을 의미하며, dnf과 rpm은 Red Hat 계열, apk은 Alpine, pacman는 Arch를 의미합니다.

CentOS는 여전히 RHEL의 무료 버전입니까?

아닙니다. CentOS Linux 8은 해당 이름으로 출시된 마지막 리빌드 버전으로 2021년 12월 31일에 종료되었으며, CentOS Linux 7은 2024년 6월 30일에 수명이 종료되었습니다. 현재 운영 중인 CentOS Stream은 RHEL 마이너 릴리스의 기반이 되는 브랜치이므로, RHEL보다 변경 사항이 먼저 적용됩니다. 기존의 역할을 대신하는 무료 리빌드 버전으로는 AlmaLinux와 Rocky Linux가 있으며, 두 배포판 모두 10년의 지원 기간을 제공합니다.

Debian stable은 왜 그렇게 오래된 버전 번호를 사용합니까?

버전 번호는 고정되어 있지만 수정 사항은 계속 반영되기 때문입니다. Debian은 최신 업스트림 릴리스를 가져오는 대신 출시된 버전에 보안 패치를 백포트합니다. 따라서 2.4.57-2+deb13u1으로 표시되는 패키지에도 지난주에 발표된 수정 사항이 포함될 수 있습니다. 업스트림 버전 뒤의 접미사는 Debian 리비전이며, apt changelog <package>에서 해당 리비전에 포함된 변경 사항을 확인할 수 있습니다. 버전 번호만으로 Debian 서버의 보안 상태를 판단하는 것은 항상 잘못된 결과를 낳습니다.

VPS에서 Arch와 같은 롤링 릴리스를 사용해야 합니까?

정기적으로 업데이트를 수행할 계획이 있을 때만 사용하십시오. 롤링 릴리스 배포판은 모든 머신이 최신 패키지 세트로 수렴된다고 가정합니다. 따라서 pacman -Sy foo로 패키지 하나만 업데이트하면 라이브러리 불일치가 발생하여 cannot open shared object file과 같은 오류가 나타날 수 있습니다. pacman -Syu를 정기적으로 실행하고 실행 전마다 프로젝트 뉴스 페이지를 확인하면 시스템은 안정적으로 유지됩니다. 1년 동안 방치하면 첫 번째 업그레이드부터 위험해집니다.

불변(immutable) 또는 원자적(atomic) 배포판은 무엇을 바꿉니까?

업데이트가 적용되는 시점과 이를 되돌리는 방식을 변경합니다. /usr는 읽기 전용으로 마운트되며, 업데이트는 완전히 새로운 트리 형태로 준비됩니다. 재부팅 시 전환이 이루어지며, 이전 트리는 롤백을 위해 부팅 항목으로 보존됩니다. 이를 통해 시스템은 완전히 업데이트되었거나 전혀 업데이트되지 않은 상태 중 하나가 되며, 절반만 적용된 상태는 발생하지 않습니다. 파일을 직접 수정하여 소프트웨어를 설치하는 방식은 불가능해지며, 애플리케이션은 컨테이너나 레이어드 패키지 형태로 설치해야 합니다.