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

Linux 배포판의 실체

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

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

• 커널: 프로젝트가 선택한 버전이며, 추가된 패치와 드라이버를 포함합니다.
• 사용자 공간(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가 추가되었습니다.

도구 체인 또한 Debian의 중요한 유산입니다. 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이 구형처럼 보이지만 안정적으로 동작하는 이유입니다. 릴리스가 freeze되면 버전 번호는 고정되지만, 보안 수정 사항은 계속해서 백포트되기 때문입니다.

거버넌스 또한 문서화되어 있으며, 선출된 프로젝트 리더와 구속력 있는 일반 결의안을 통해 운영됩니다. 2014년 이 체계는 systemd를 기본 init 시스템으로 채택했습니다. 이에 동의하지 않는 사람들은 Devuan을 포크(fork)하여 2017년에 첫 릴리스를 내놓았습니다. Debian의 주요 파생 배포판으로는 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 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를 설립했습니다.

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

cat /etc/os-release

NAME="CentOS Stream"은 RHEL을 앞서 나가는 롤링 개발 브랜치입니다. NAME="AlmaLinux" 또는 NAME="Rocky Linux"은 10년의 지원 기간을 제공하며 RHEL을 뒤따르는 재빌드판입니다.

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

Ubuntu 4.10은 2004년 10월 20일에 출시되었으며 Mark Shuttleworth가 자금을 지원했습니다. 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은 일반적인 사용자 공간의 대부분을 대체합니다. 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를 인수한 이후 Fedora CoreOS가 2019년 이를 서버 환경으로 가져왔습니다. 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년의 지원 기간을 제공하며, 이것이 바로 리빌드 배포판이 존재하는 이유입니다.

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

내 서버는 어떤 Linux 배포판 계열인가?

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보다 변경 사항이 먼저 적용됩니다. 기존 CentOS의 역할을 대체하는 무료 리빌드 버전은 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는 읽기 전용으로 마운트되며, 업데이트는 전체 시스템 트리를 새로 구성하는 방식으로 준비됩니다. 재부팅 시 시스템이 전환되며 이전 트리는 부팅 항목으로 남아 롤백에 사용됩니다. 이 방식은 시스템이 완전히 업데이트되거나 이전 상태를 유지하는 두 가지 상태만 존재하게 하며, 중간에 업데이트가 멈추는 불완전한 상태를 방지합니다. 시스템 파일을 직접 수정하여 소프트웨어를 설치하는 방식은 불가능해지므로, 애플리케이션은 컨테이너나 계층화된 패키지 형태로 설치해야 합니다.