Linux 배포판
Linux 배포판(Linux distribution)은 Linux 커널을 중심으로 시스템 도구, 라이브러리, 설치 프로그램, 패키지 관리자, 소프트웨어 저장소와 기본 응용 프로그램을 조합하여 배포하는 운영체제이다. 일반적으로 하나의 배포판 프로젝트가 커널과 수많은 독립 소프트웨어를 선별...
Linux 배포판(Linux distribution)은 Linux 커널을 중심으로 시스템 도구, 라이브러리, 설치 프로그램, 패키지 관리자, 소프트웨어 저장소와 기본 응용 프로그램을 조합하여 배포하는 운영체제이다. 일반적으로 하나의 배포판 프로젝트가 커널과 수많은 독립 소프트웨어를 선별하고 통합하며, 설치 이미지와 업데이트 체계, 보안 정책, 문서 및 지원 환경을 함께 제공한다.[1]
Linux 커널 자체는 완전한 사용자용 운영체제 환경을 구성하지 않는다. 실제 시스템을 사용하려면 GNU 도구와 C 라이브러리, 셸, 부팅 시스템, 장치 관리 도구, 네트워크 프로그램, 패키지와 응용 프로그램 등이 필요하다. Linux 배포판은 이러한 구성 요소를 일관된 정책 아래 묶고, 사용자가 설치·업데이트·제거할 수 있는 형태로 제공한다.
배포판마다 채택하는 구성 요소와 운영 정책은 크게 다르다. Debian 계열은 주로 deb 패키지와 APT를 사용하고, Fedora와 Red Hat Enterprise Linux 계열은 RPM과 DNF를 사용한다. Arch Linux 계열은 pacman, SUSE Linux 계열은 RPM과 Zypper, Gentoo는 Portage, Alpine Linux는 apk, Void Linux는 XBPS를 중심으로 소프트웨어를 관리한다.
새 버전을 일정한 주기로 발표하는 고정 릴리스 배포판이 있는 반면, 개별 패키지를 지속적으로 갱신하는 롤링 릴리스 배포판도 있다. 장기간 안정성과 호환성을 중시하는 기업용 배포판, 최신 소프트웨어와 개발 기술을 빠르게 도입하는 배포판, 데스크톱 사용성에 집중하는 배포판, 서버·라우터·컨테이너·보안 분석·멀티미디어 제작과 같은 특정 용도를 위한 배포판도 존재한다.
많은 배포판은 다른 배포판의 패키지 저장소와 기반 기술을 계승하면서 독자적인 설치 환경, 기본 설정, 데스크톱 환경과 지원 정책을 추가한다. Ubuntu는 Debian을 기반으로 형성되었으며, 다시 Linux Mint, Pop!_OS, elementary OS 등 여러 배포판의 기반이 되었다. Debian 프로젝트는 직접 또는 간접적으로 Debian을 기반으로 하는 배포판이 300개 이상 존재한다고 설명한다.[2]
배포판 사이의 계보는 항상 단순한 상하 관계로 구분되지는 않는다. 일부 프로젝트는 특정 배포판의 저장소를 직접 사용하고, 일부는 소스 패키지를 다시 빌드하며, 일부는 여러 배포판의 기술을 결합한다. 같은 프로젝트에서도 기반 배포판이나 패키지 관리 체계가 변경될 수 있으므로, 배포판 계열은 주로 현재의 패키지 기반과 개발 관계를 기준으로 구분한다.
배포판 목록
명칭과 범위
Linux 배포판이라는 표현은 Linux 커널을 사용하여 구성된 운영체제 배포물을 넓게 가리킨다. 여기에는 커널뿐 아니라 시스템 라이브러리, 명령줄 도구, 부팅 체계, 패키지 관리자, 설치 프로그램, 소프트웨어 저장소와 기본 응용 프로그램 등이 포함된다. 따라서 배포판은 Linux 커널의 단순한 복사본이 아니라, 여러 독립 프로젝트의 소프트웨어를 하나의 설치·업데이트·운영 체계로 통합한 결과물이다.
배포판의 범위는 명확히 고정되어 있지 않다. Debian, Fedora, Arch Linux처럼 범용 컴퓨터에 설치하는 전통적인 배포판뿐 아니라 OpenWrt와 같은 네트워크 장비용 시스템, Alpine Linux와 같은 경량 환경, Android처럼 Linux 커널 위에 독자적인 사용자 공간과 응용 프로그램 플랫폼을 구성한 운영체제도 넓은 의미에서는 Linux 기반 배포 체계에 포함될 수 있다.
다만 일반적인 문맥에서 Linux 배포판은 패키지 저장소와 패키지 관리 체계를 제공하며, 사용자가 범용 소프트웨어를 설치하고 시스템 전체를 관리할 수 있는 운영체제를 주로 의미한다. Android처럼 Linux 커널을 사용하더라도 전통적인 데스크톱·서버 Linux와 다른 응용 프로그램 모델과 사용자 공간을 사용하는 운영체제는 보통 별도의 계열로 다룬다.
Linux와 GNU/Linux
Linux는 엄밀하게는 리누스 토르발스가 시작한 운영체제 커널의 이름이다. 커널은 프로세스, 메모리, 장치, 파일 시스템과 네트워크 같은 하드웨어 및 시스템 자원을 관리하지만, 사용자 명령과 응용 프로그램을 실행하는 완전한 사용자 환경 전체를 단독으로 제공하지는 않는다. Linux 커널 프로젝트의 공식 문서 역시 커널 자체의 개발 절차, 내부 인터페이스와 하위 시스템을 중심으로 구성되어 있다.[3]
초기의 많은 Linux 배포판은 Linux 커널에 GNU 프로젝트가 개발한 셸, 컴파일러, 명령줄 도구, C 라이브러리와 여러 시스템 프로그램을 결합하여 만들어졌다. GNU 프로젝트는 완전한 자유 유닉스 계열 운영체제를 개발하기 위해 시작되었으며, 자체 커널인 GNU Hurd가 실용적인 범용 환경으로 완성되기 전에 Linux 커널과 결합되었다.[4]
GNU 프로젝트와 자유 소프트웨어 재단은 이러한 운영체제를 단순히 Linux라고 부르면 GNU 시스템과 GNU 프로젝트의 기여가 드러나지 않는다고 보고 GNU/Linux라는 명칭을 사용한다. GNU 측에서는 Linux를 커널로, GNU를 커널과 결합되는 운영체제의 주요 사용자 공간으로 설명한다.[5]
반면 Linux라는 이름은 커널뿐 아니라 Linux 커널을 사용하는 운영체제 전체를 지칭하는 통상적인 명칭으로도 널리 사용된다. 배포판과 기업, 언론, 사용자 커뮤니티는 대체로 Debian Linux, Fedora Linux 또는 Linux 배포판과 같은 표현을 사용하며, 문맥상 커널과 전체 운영체제를 구분한다.
모든 Linux 기반 운영체제가 GNU 사용자 공간을 중심으로 구성되는 것도 아니다. Alpine Linux는 GNU C 라이브러리 대신 musl을 사용하고 여러 기본 명령에 BusyBox를 채택한다. Android는 자체 C 라이브러리인 Bionic과 Android 런타임 및 응용 프로그램 프레임워크를 사용한다. 이러한 시스템을 GNU/Linux라고 부르는 것은 구성 요소를 정확히 반영하지 못하므로 일반적으로 Linux 기반 운영체제 또는 각각의 고유한 운영체제 이름으로 부른다.
따라서 TechPedia에서 Linux는 문맥에 따라 커널 또는 Linux 기반 운영체제 계열을 가리키며, 커널 자체를 명확히 구분해야 할 때는 Linux 커널이라는 표현을 사용한다. GNU/Linux는 Linux 커널과 GNU 사용자 공간을 중심으로 구성된 시스템이라는 점을 강조하는 명칭으로 사용한다.
배포판을 구성하는 요소
Linux 배포판은 여러 소프트웨어 구성 요소와 이를 관리하는 정책 및 기반 시설로 이루어진다. 각 구성 요소는 서로 다른 프로젝트에서 개발될 수 있으며, 배포판 프로젝트는 이들을 선택하고 수정하여 일관된 시스템으로 통합한다.
가장 아래에는 하드웨어를 관리하는 Linux 커널이 있다. 배포판은 특정 커널 버전을 선택하고 필요한 보안 수정, 장치 드라이버, 파일 시스템 또는 성능 개선 패치를 적용한다. 일부 배포판은 공식 커널과 가까운 구성을 유지하고, 일부는 실시간 처리, 모바일 장치, 가상화 또는 특정 하드웨어를 위해 별도의 커널 구성을 제공한다.
커널 위에는 프로그램이 운영체제 기능을 사용할 수 있도록 하는 C 표준 라이브러리와 시스템 라이브러리가 위치한다. 많은 배포판은 GNU C Library를 사용하지만 Alpine Linux의 musl처럼 다른 구현을 채택할 수도 있다. 라이브러리 선택은 프로그램의 바이너리 호환성, 시스템 크기, 성능과 지원 가능한 소프트웨어 범위에 영향을 준다.
사용자 공간에는 셸, 파일 조작 도구, 네트워크 명령, 프로세스 관리 도구와 같은 기본 시스템 프로그램이 포함된다. 전통적인 배포판에서는 GNU Core Utilities, Bash, util-linux, iproute2 등 여러 프로젝트의 도구가 조합된다. 경량 배포판과 임베디드 시스템에서는 여러 명령을 하나의 실행 파일로 제공하는 BusyBox나 Toybox를 사용할 수 있다.
시스템 시작과 서비스 관리는 초기화 시스템 및 서비스 관리자가 담당한다. 많은 현대 배포판은 systemd를 사용하지만, OpenRC, runit, s6, SysV init과 같은 다른 체계를 사용하는 배포판도 존재한다. 이 선택은 부팅 과정뿐 아니라 서비스 의존성, 로그, 장치 관리와 시스템 세션 구성에도 영향을 줄 수 있다.
배포판을 다른 Linux 시스템과 구분하는 핵심 요소 가운데 하나는 패키지 관리 시스템이다. 패키지 형식은 파일과 프로그램을 설치 가능한 단위로 묶으며, 패키지 관리자는 설치, 제거, 업데이트와 의존성 해결을 처리한다. Debian 계열은 주로 deb와 APT, Fedora 및 Red Hat 계열은 RPM과 DNF, Arch Linux 계열은 pkg.tar.zst와 pacman, Alpine Linux는 apk를 사용한다.
패키지 자체뿐 아니라 패키지를 배포하는 공식 저장소, 패키지 서명, 빌드 서버와 보안 업데이트 체계도 배포판의 일부다. 배포판 프로젝트는 수많은 업스트림 소프트웨어의 버전을 선택하고, 함께 동작하도록 빌드하며, 발견된 취약점과 오류를 수정한 패키지를 사용자에게 배포한다.
설치 프로그램, 부트로더 설정, 하드웨어 자동 감지, 기본 네트워크 구성과 사용자 계정 관리 도구도 배포판의 사용자 경험을 형성한다. 데스크톱 배포판은 GNOME, KDE Plasma, Xfce 등의 데스크톱 환경과 그래픽 설정 도구를 함께 제공할 수 있으며, 서버용 배포판은 그래픽 환경 없이 관리 도구와 네트워크 서비스를 중심으로 구성할 수 있다.
배포판은 소프트웨어 묶음만이 아니라 릴리스 주기, 지원 기간, 패키지 승인 기준, 라이선스 정책, 보안 대응 방식과 프로젝트 거버넌스까지 포함한다. 같은 Linux 커널과 데스크톱 환경을 사용하는 두 배포판도 패키지 버전, 기본 설정, 업데이트 정책과 지원 체계가 다르면 별개의 배포판으로 취급된다.
배포판과 운영체제의 관계
Linux 배포판은 일반적으로 사용자가 설치하고 실행하는 완성된 운영체제다. Linux 커널은 그 운영체제의 핵심 구성 요소지만, 배포판은 커널에 사용자 공간과 시스템 관리 체계를 추가하여 실제 컴퓨터에서 사용할 수 있는 환경을 제공한다.
전통적인 UNIX 운영체제는 커널, 시스템 라이브러리, 명령줄 도구와 관리 프로그램을 하나의 조직이나 공급자가 함께 개발하는 경우가 많았다. Linux 배포판은 이와 달리 Linux 커널, GNU 도구, 데스크톱 환경, 웹 브라우저와 수많은 독립 프로젝트의 소프트웨어를 배포판 프로젝트가 통합하는 구조를 가진다.
이 때문에 Linux라는 공통 커널을 사용하더라도 배포판마다 하나의 운영체제로서의 동작과 사용 방법이 달라질 수 있다. 패키지 관리자, 디렉터리 구성, 기본 라이브러리, 서비스 관리 체계, 보안 정책과 릴리스 주기가 다르며, 동일한 프로그램도 배포판에 따라 다른 버전과 빌드 옵션으로 제공될 수 있다.
배포판은 자체 이름과 버전 체계를 가진다. 예를 들어 Debian 13, Fedora 42와 Ubuntu 24.04는 Linux 커널 버전이 아니라 각각의 배포판 릴리스를 의미한다. 하나의 배포판 릴리스에는 특정 시점의 커널, 라이브러리, 도구와 응용 프로그램 버전이 함께 포함된다.
배포판 안에서 제공되는 모든 소프트웨어가 배포판 프로젝트가 직접 개발한 것은 아니다. 배포판은 원본 소프트웨어를 개발하는 업스트림 프로젝트에서 소스 코드를 가져와 패키지로 만들고, 배포판에 맞는 수정 사항과 보안 패치를 적용한다. 배포판에서 발견된 개선 사항은 다시 업스트림에 제출될 수 있다.
운영체제와 배포판의 경계는 시스템 종류에 따라 달라진다. 범용 데스크톱과 서버 환경에서는 배포판 자체가 운영체제로 인식된다. 반면 임베디드 제품에서는 Yocto Project나 Buildroot를 이용해 제품마다 별도의 Linux 시스템 이미지를 만들 수 있으며, 이 경우 공통 배포판보다 제품별 운영체제 이미지라는 성격이 강하다.
컨테이너 이미지도 Alpine, Debian 또는 Ubuntu의 사용자 공간을 포함할 수 있지만 자체 커널을 포함하지 않는 경우가 일반적이다. 컨테이너는 호스트의 Linux 커널을 공유하므로, 배포판 사용자 공간을 담고 있더라도 완전한 독립 운영체제와 동일하지는 않다.
배포판·파생판·리믹스
배포판은 Linux 커널과 사용자 공간, 패키지 저장소, 설치 및 업데이트 체계를 하나의 프로젝트나 조직이 관리하여 배포하는 운영체제다. 다른 배포판을 기반으로 하지 않고 독자적인 패키지와 기반 시설을 구축한 배포판도 있으며, 기존 배포판을 활용하여 만들어진 배포판도 있다.
파생 배포판은 기존 배포판의 패키지, 저장소, 빌드 시스템 또는 개발 결과를 기반으로 하면서 독자적인 목표와 정체성을 가진 배포판이다. Debian은 파생 배포판을 Debian에서 수행된 작업을 기반으로 하지만 자체적인 정체성, 목표와 사용자를 가지며 Debian과 독립된 주체가 만드는 배포판으로 설명한다.[6]
파생 방식은 하나로 고정되지 않는다. 일부 파생판은 기반 배포판의 공식 저장소를 거의 그대로 사용하고 자체 패키지만 추가한다. 일부는 기반 배포판의 소스 패키지를 자체 서버에서 다시 빌드하며, 일부는 패키지를 복제한 뒤 장기간 독립적으로 수정한다. Debian 파생판에서 흔한 방식은 Debian 패키지 대부분을 재사용하거나 다시 빌드하면서 자체 패키지와 설정을 추가하는 것이다.[7]
파생판은 다시 다른 배포판의 기반이 될 수 있다. Ubuntu는 Debian을 기반으로 하지만 자체 저장소, 릴리스 주기와 패키지 수정 사항을 운영하며, Linux Mint와 Pop!_OS 등은 다시 Ubuntu를 기반으로 한다. 따라서 배포판 계보는 단순히 원본과 복사본의 관계가 아니라 여러 단계로 이어지는 개발 및 패키지 공급 관계를 형성한다.
파생 관계는 항상 전체 시스템의 복제를 의미하지 않는다. 어떤 배포판은 기반 배포판의 패키지 저장소를 직접 사용하면서 소수의 자체 패키지와 설정만 제공하고, 다른 배포판은 기반 배포판과 바이너리 호환성을 목표로 모든 패키지를 독립적으로 다시 빌드한다. 기반 배포판의 일부 기술만 채택하고 나머지를 독자적으로 구성하는 경우도 있다.
리믹스는 일반적으로 기존 배포판의 패키지와 저장소를 유지하면서 기본 데스크톱 환경, 응용 프로그램 선택, 테마 또는 설정을 바꾼 배포물을 가리킨다. 파생판보다 원본 배포판과의 기술적 거리가 가까운 경우가 많지만, 리믹스에 대한 Linux 생태계 전체의 통일된 공식 정의는 없다.
Ubuntu 생태계에서는 리믹스라는 이름이 Ubuntu 저장소의 패키지를 추가하거나 기본 응용 프로그램을 변경하여 새로운 설치 이미지를 구성한 비공식 프로젝트에 사용되어 왔다. 프로젝트가 Ubuntu의 공식 승인과 개발 절차를 갖추면 공식 flavor로 인정될 수 있지만, 리믹스와 flavor의 명칭 및 상표 사용 범위는 Canonical의 정책과 프로젝트 관계에 따라 달라진다.[8]
에디션, 스핀, 플레이버는 보통 같은 배포판 프로젝트 안에서 제공되는 공식 변형을 뜻한다. 이들은 서로 다른 데스크톱 환경이나 기본 패키지 구성을 제공할 수 있지만, 동일한 저장소, 릴리스 정책과 배포판 정체성을 공유한다. Ubuntu 공식 flavor는 서로 다른 Ubuntu 설치 구성을 제공하는 형태로 설명된다.[9]
따라서 Ubuntu Server, Fedora Workstation, Fedora의 각 Spin과 같은 변형은 일반적으로 새로운 파생 배포판으로 분류하지 않는다. 이들은 해당 배포판 내부의 제품 또는 설치 구성으로 다루며, Linux 배포판의 계보를 정리할 때는 Ubuntu나 Fedora 자체만 하나의 배포판 노드로 표시하는 편이 적절하다.
배포판과 파생판의 구분은 프로젝트의 자기 정의, 저장소 운영, 패키지 공급 관계와 독립적인 릴리스 여부를 함께 살펴야 한다. 이름이나 외형만 바뀌었다고 별도 배포판이 되는 것은 아니며, 반대로 같은 패키지 형식을 사용한다고 동일 계열에 속하는 것도 아니다. 배포판 계보는 주로 어떤 프로젝트의 패키지와 개발 기반을 직접 계승했는지를 기준으로 판단한다.
역사
Linux 배포판의 역사는 사용자가 Linux 커널과 각종 시스템 프로그램을 개별적으로 내려받아 조립하던 초기 단계에서 출발했다. 이후 설치 가능한 배포 묶음, 패키지 관리 체계, 정기적인 릴리스와 보안 지원이 등장하면서 배포판은 독립된 운영체제 프로젝트로 발전했다.
1990년대에는 개인과 소규모 공동체가 중심이 되어 범용 Linux 시스템을 구성했으며, 상용 기업과 대규모 공동체가 등장한 뒤에는 데스크톱, 서버와 기업용 시장으로 범위가 확대되었다. 2000년대 이후에는 모바일 장치와 클라우드가 새로운 주요 환경이 되었고, 2010년대부터는 컨테이너 운영과 자동화된 배포를 위해 최소 구성·불변 구조·원자적 업데이트를 채택한 배포판이 성장했다.
초기 Linux 시스템
리누스 토르발스가 1991년 Linux 커널을 공개했을 당시에는 오늘날과 같은 완성된 Linux 배포판이 존재하지 않았다. 초기 사용자는 커널, 부트 및 루트 디스크 이미지, GNU 컴파일러와 명령줄 도구, 시스템 라이브러리와 셸을 여러 FTP 서버와 뉴스그룹에서 따로 구해야 했다.
토르발스가 제공한 초기 부트·루트 플로피 이미지는 Linux를 부팅하고 기본적인 시스템을 구성하는 데 필요한 최소 환경을 제공했지만, 다양한 프로그램과 설치 관리 체계를 포함한 완전한 배포판은 아니었다. 사용자는 디스크 파티션을 직접 구성하고 커널과 사용자 공간을 설치했으며, 라이브러리와 프로그램 사이의 버전 호환성도 직접 해결해야 했다.
Linux 커널의 개발 속도가 빨라지고 GNU 소프트웨어, X Window System, 네트워크 도구와 개발 도구가 Linux에서 동작하기 시작하면서 이들을 검증된 조합으로 묶어 제공하려는 시도가 나타났다. 이러한 배포 묶음은 설치 과정을 단순화했을 뿐 아니라, 특정 시점에 서로 호환되는 커널·라이브러리·프로그램의 기준 구성을 제공했다.
초기 Linux 시스템은 대체로 플로피 디스크 여러 장으로 배포되었다. 인터넷 연결 속도가 느리고 CD-ROM 드라이브도 일반화되지 않았기 때문에 최소 시스템, 개발 도구, 문서, X Window System과 추가 프로그램을 서로 다른 디스크 묶음으로 나누는 방식이 사용되었다.[10]
최초의 배포판
최초의 Linux 배포판을 무엇으로 볼지는 배포판의 기준에 따라 달라진다. Linux 커널과 기본 도구를 설치 가능한 묶음으로 제공한 최초의 사례로는 MCC Interim Linux가 주로 언급되며, 그래픽 환경과 폭넓은 응용 프로그램까지 포함한 초기 종합 배포판으로는 Softlanding Linux System과 Yggdrasil Linux/GNU/X가 중요하게 평가된다.
맨체스터 컴퓨팅 센터의 오언 르 블랑은 1992년 2월 MCC Interim Linux를 공개했다. 이 배포판은 Linux 커널, 셸, GNU 도구와 개발 프로그램을 플로피 디스크에 묶고 비교적 단순한 설치 절차를 제공했다. 다만 X Window System과 대규모 응용 프로그램 모음보다는 안정적인 기본 개발·사용 환경을 제공하는 데 중점을 두었다.[11]
같은 해 피터 맥도널드가 공개한 SLS는 Linux 커널과 GNU 도구뿐 아니라 X Window System, TCP/IP 네트워크 기능, 개발 도구와 여러 응용 프로그램을 함께 제공했다. SLS는 초기 Linux 사용자에게 비교적 완성된 시스템을 제공하면서 한동안 널리 사용되었고, 배포판이 커널과 기본 도구 이상의 종합 운영체제 환경을 제공할 수 있음을 보여주었다.[12]
Yggdrasil Linux/GNU/X는 1992년 말 시험판을 공개하고, 이후 CD-ROM을 중심으로 Linux와 그래픽 환경을 배포했다. Yggdrasil은 설치 전에 CD-ROM에서 시스템을 실행하는 초기 라이브 배포 방식과 하드웨어 자동 설정을 시도한 배포판으로 알려졌다. 당시의 여러 프로젝트는 각각 설치 편의성, 프로그램 범위와 배포 매체를 확장하면서 이후 Linux 배포판의 기본 형태를 만들어 갔다.
따라서 MCC Interim Linux는 초기의 설치 가능한 배포판, SLS는 폭넓은 프로그램을 통합한 종합 배포판, Yggdrasil은 CD-ROM과 라이브 실행을 적극 활용한 초기 상용 배포판이라는 서로 다른 역사적 의미를 가진다.
Slackware와 Debian의 등장
SLS는 초기 Linux 생태계에서 널리 사용되었지만 패키지 구성과 업데이트의 불안정성, 오류와 유지 관리 방식에 대한 불만도 커졌다. 이러한 문제를 개선하려는 과정에서 1993년 Slackware와 Debian이 등장했다. 두 배포판은 모두 SLS의 영향을 받았지만 개발 구조와 운영 철학에서는 서로 다른 방향을 선택했다.
패트릭 볼커딩은 자신이 사용하던 SLS 시스템을 수정하고 안정화한 배포본을 만들었으며, 1993년 7월 16일 Slackware 1.00을 공개했다. 첫 공개판은 3.5인치 플로피 디스크 이미지 형태의 완전한 설치 시스템으로 제공되었다.[13]
Slackware는 구성 요소를 업스트림 형태에 가깝게 유지하고, 시스템 동작을 단순하고 예측 가능하게 만드는 방향을 택했다. 복잡한 자동 설정보다 전통적인 UNIX식 구성과 관리 방식을 중시했으며, 이후 여러 초기 배포판과 파생 프로젝트에 영향을 주었다. Slackware는 1993년에 처음 공개된 뒤 계속 개발되어 온 가장 오래된 Linux 배포판 가운데 하나다.[14]
이언 머독은 1993년 8월 Debian 프로젝트를 시작했다. Debian은 한 사람이 완성된 배포본을 관리하는 방식보다 여러 개발자가 공개적으로 협력하고 각 패키지를 분담하여 유지하는 공동체형 배포판을 목표로 했다. Debian 0.01부터 0.90까지의 초기 판은 1993년 8월부터 12월 사이에 공개되었다.[15]
Debian은 패키지를 개별적으로 설치·제거·갱신할 수 있는 체계를 발전시켰고, 프로젝트 정책과 공개적인 의사 결정 구조를 구축했다. 1997년에는 Debian 사회 계약과 Debian 자유 소프트웨어 지침을 채택하여 프로젝트가 사용자와 자유 소프트웨어에 대해 지는 책임을 문서화했다.
Slackware와 Debian의 등장은 Linux 배포판이 단순한 프로그램 모음에서 지속적으로 관리되는 운영체제 프로젝트로 전환되는 과정이었다. Slackware는 단순성과 전통적인 시스템 구성을, Debian은 공동체 기반 패키지 관리와 명시적인 정책을 대표하게 되었다.
상용 Linux 시장의 형성
초기 Linux는 인터넷과 대학, 개발자 공동체를 통해 주로 무료로 배포되었지만, 다운로드와 설치가 쉽지 않았던 당시에는 CD-ROM과 인쇄 설명서, 기술 지원을 함께 판매하는 사업이 빠르게 형성되었다. 자유 소프트웨어의 복제와 배포를 허용하는 라이선스는 소프트웨어 자체를 독점적으로 판매하기보다 편리한 배포 매체, 문서, 업데이트와 지원 서비스를 상품화하는 모델로 이어졌다.
1990년대 초에는 Yggdrasil Computing, Walnut Creek CDROM, InfoMagic와 여러 소규모 업체가 Linux 배포판과 소프트웨어 저장소를 CD-ROM으로 제공했다. 인터넷 연결이 느리거나 없는 사용자에게 CD-ROM은 수십 장의 플로피 디스크보다 편리한 설치 매체였으며, 한 장에 커널과 개발 도구, 그래픽 환경과 대량의 응용 프로그램을 담을 수 있었다.
SUSE의 전신은 독일에서 UNIX와 Linux 관련 소프트웨어 및 기술 지원을 제공하다가 Slackware를 기반으로 한 배포판을 거쳐 독자적인 SUSE Linux를 발전시켰다. Caldera, TurboLinux, Mandrake Linux와 같은 기업도 특정 지역, 기업 환경 또는 데스크톱 사용자를 대상으로 제품과 서비스를 제공했다.
상용화는 Linux를 기업에 도입하는 데 필요한 설치 지원, 하드웨어 인증, 보안 업데이트와 장기적인 유지 보수 체계를 만들었다. 기업은 자유롭게 내려받을 수 있는 소프트웨어에도 안정적인 공급자와 계약상 지원이 필요했으며, 이 수요는 이후 기업용 Linux 배포판 시장의 기반이 되었다.
한편 상용 배포판과 공동체 배포판의 경계는 완전히 분리되지 않았다. 기업은 자유 소프트웨어 프로젝트와 공동체 개발에 참여하면서 상용 지원 제품을 제공했고, 공동체에서 개발된 패키지와 개선 사항은 상용 제품에 반영되었다. 이러한 공동체와 기업의 결합은 이후 Red Hat, SUSE, Canonical과 여러 Linux 공급자의 주요 운영 모델이 되었다.
Red Hat과 RPM 생태계
마크 유잉은 1990년대 초 자신의 Linux 배포판을 만들기 시작했고, 밥 영은 이를 CD-ROM으로 유통했다. 두 사람이 협력하면서 1995년 Red Hat Software가 설립되었고, Red Hat Linux는 설치 편의성과 체계적인 패키지 관리를 앞세워 주요 상용 배포판으로 성장했다.[16]
Red Hat의 핵심 기술 가운데 하나는 RPM이었다. RPM은 프로그램 파일, 버전, 의존성, 설치 스크립트와 검증 정보를 표준화된 패키지에 기록하고, 설치·업그레이드·제거 과정을 일관되게 관리하도록 했다. RPM은 이후 Red Hat 계열뿐 아니라 SUSE, Mandriva와 여러 독립 배포판에서도 채택되어 deb와 함께 대표적인 Linux 패키지 형식으로 자리 잡았다.[17]
Red Hat은 2002년 기업 환경을 위한 Red Hat Enterprise Linux를 발표하고 장기 지원, 하드웨어와 소프트웨어 인증, 안정적인 ABI와 유료 기술 지원에 중점을 두었다. 기존 Red Hat Linux의 대중적·실험적 개발 역할은 2003년 시작된 Fedora 프로젝트로 이어졌다. Fedora는 새로운 자유 소프트웨어 기술을 빠르게 통합하고, 성숙한 결과가 이후 Red Hat Enterprise Linux에 반영되는 상류 공동체 역할을 맡았다.[18]
Red Hat Enterprise Linux의 소스 패키지를 다시 빌드하여 호환성을 제공한 CentOS는 비용 없이 기업용 Linux와 유사한 환경을 구축하려는 사용자에게 널리 사용되었다. 이후 CentOS 프로젝트의 중심이 RHEL 이후의 재빌드에서 RHEL 다음 부 릴리스 개발 과정 앞에 위치하는 CentOS Stream으로 이동하면서, AlmaLinux와 Rocky Linux 등 새로운 RHEL 호환 배포판이 등장했다.
RPM 생태계는 단일 배포판의 계보를 넘어 패키지 형식, 빌드 도구, 저장소 메타데이터와 기업용 호환성 시장을 형성했다. Fedora, CentOS Stream과 RHEL 사이에는 공동체에서 새로운 기술을 통합하고 이를 기업용 제품으로 안정화하는 개발 흐름이 만들어졌다.
Debian 파생판과 Ubuntu의 성장
Debian은 개방적인 패키지 저장소와 광범위한 하드웨어 아키텍처 지원, 명시적인 자유 소프트웨어 정책을 바탕으로 여러 파생 배포판의 기반이 되었다. 파생판은 Debian 패키지 전체 또는 일부를 가져와 설치 프로그램, 기본 설정, 릴리스 주기와 특정 사용자층을 위한 구성을 추가했다.
1990년대 후반부터 Corel Linux, Storm Linux, Libranet과 같은 상용 Debian 파생판이 등장했으며, KNOPPIX는 2000년대 초 CD에서 직접 실행할 수 있는 라이브 시스템을 대중화했다. KNOPPIX의 하드웨어 자동 감지와 라이브 실행 방식은 시스템 복구, 시험 사용과 설치 미디어 설계에 큰 영향을 주었고, 다시 여러 라이브 배포판의 기반이 되었다.
2004년 Canonical은 Debian을 기반으로 Ubuntu를 공개했다. 최초의 공식 릴리스인 Ubuntu 4.10 Warty Warthog는 2004년 10월 출시되었으며, 정기적인 출시 일정, 설치 편의성, 기본 데스크톱 구성과 사용자 지원을 전면에 내세웠다.[19]
Ubuntu는 6개월 단위의 정기 릴리스와 장기간 지원되는 LTS를 결합했다. 2006년 Ubuntu 6.06 LTS가 첫 장기 지원 릴리스로 발표되었고, 일반 사용자에게는 예측 가능한 새 버전을, 기업과 서버 운영자에게는 장기간 유지되는 기반을 제공했다.[20]
Ubuntu는 무료 설치 CD를 우편으로 배포한 ShipIt 프로그램, 지역 공동체와 폭넓은 번역, 간단한 설치 과정과 기본 하드웨어 지원을 통해 Linux에 처음 접근하는 사용자를 확대했다. 또한 Debian의 방대한 패키지 생태계를 활용하면서 자체 저장소와 패치, 릴리스 관리 및 상용 지원 체계를 운영했다.
Ubuntu의 성장 이후 Linux Mint, elementary OS, Pop!_OS, Zorin OS와 수많은 파생 배포판이 등장했다. 이들은 Ubuntu의 패키지 저장소와 하드웨어 지원을 활용하면서 서로 다른 데스크톱 환경, 기본 응용 프로그램과 사용자 경험을 제공했다. 이에 따라 Debian에서 Ubuntu로, 다시 여러 데스크톱·전문 배포판으로 이어지는 다단계 계보가 Linux 생태계의 큰 축을 형성했다.
데스크톱 배포판의 확산
초기 Linux는 명령줄과 개발 환경을 중심으로 사용되었지만, X Window System과 자유 데스크톱 환경이 발전하면서 일반 사용자를 위한 그래픽 운영체제로 확장되었다. 배포판은 X 서버, 창 관리자와 응용 프로그램을 개별적으로 설정해야 했던 환경을 통합하고, 설치 직후 사용할 수 있는 데스크톱 구성을 제공하기 시작했다.
1996년 마티아스 에트리히는 Qt와 C++를 기반으로 일관된 UNIX용 그래픽 사용자 환경을 만들기 위한 KDE 프로젝트를 발표했다. KDE는 데스크톱 셸, 파일 관리자와 기본 응용 프로그램이 통합된 환경을 제공하여 Linux 배포판의 그래픽 사용자 경험을 크게 확장했다.[21]
1997년 미겔 데 이카사와 페데리코 메나는 완전한 자유 소프트웨어 데스크톱 환경을 목표로 GNOME 프로젝트를 시작했다. GNOME 1.0은 1999년에 공개되었고, 이후 여러 배포판의 기본 데스크톱 환경으로 채택되었다.[22][23]
Mandrake Linux, SUSE Linux, Red Hat Linux와 이후의 Ubuntu는 그래픽 설치 프로그램, 하드웨어 자동 감지, 제어판과 소프트웨어 관리 도구를 발전시켰다. 사용자는 텍스트 설정 파일을 모두 직접 편집하지 않고도 디스크 파티션, 네트워크, 프린터, 사용자 계정과 데스크톱 환경을 구성할 수 있게 되었다.
2000년대에는 라이브 CD와 광대역 인터넷의 보급으로 배포판을 설치하지 않고 시험하거나 ISO 이미지를 직접 내려받는 방식이 일반화되었다. KNOPPIX와 Ubuntu를 비롯한 배포판은 하드웨어 자동 감지와 라이브 부팅을 개선했고, USB 메모리가 보편화된 뒤에는 라이브 USB와 영구 저장 기능도 널리 사용되었다.
데스크톱 배포판은 하나의 표준 사용자 환경으로 통일되기보다 GNOME, KDE Plasma, Xfce, LXDE와 여러 창 관리자를 선택할 수 있는 형태로 발전했다. 이러한 선택권은 다양한 하드웨어와 사용자 취향을 지원했지만, 배포판과 데스크톱 환경에 따라 설정 도구, 응용 프로그램과 사용자 경험이 달라지는 원인이 되기도 했다.
모바일·클라우드·컨테이너 환경
2000년대 이후 Linux 배포판의 중심은 개인용 컴퓨터와 서버에서 모바일 장치, 대규모 가상화 인프라와 클라우드로 확대되었다. Linux 커널의 이식성과 수정 가능성은 제조사가 장치에 맞는 운영체제를 구성하고, 클라우드 사업자가 대량의 가상 머신과 서비스를 자동으로 운영하는 기반이 되었다.
Android는 Linux 커널 위에 Bionic C 라이브러리, Android 런타임, 응용 프로그램 프레임워크와 모바일 사용자 환경을 구축했다. Android 커널은 장기 지원 Linux 커널에 Android 전용 변경 사항을 결합한 Android Common Kernel을 기반으로 발전했다.[24]
Android는 전통적인 GNU/Linux 데스크톱 배포판과 다른 사용자 공간과 응용 프로그램 배포 체계를 사용하지만, Linux 커널을 소비자용 모바일 장치에 대규모로 보급했다. 스마트폰과 태블릿 제조사는 장치별 드라이버와 구성을 추가했고, 이 과정에서 발생한 커널 파편화를 줄이기 위해 Generic Kernel Image와 같은 구조가 도입되었다.[25]
클라우드 환경에서는 배포판이 가상 머신 이미지, 자동 설치와 API 기반 관리에 적합하도록 변화했다. Ubuntu, Debian, Red Hat Enterprise Linux, CentOS와 Amazon Linux 등은 주요 클라우드에서 미리 구성된 이미지로 제공되었고, cloud-init과 같은 초기 설정 도구를 통해 인스턴스 생성 시 사용자 계정, 네트워크, 저장소와 프로그램 설치를 자동화했다.
Linux의 프로세스 격리 기술인 네임스페이스와 cgroup을 이용한 컨테이너는 이전부터 존재했지만, 2013년 공개된 Docker는 응용 프로그램과 의존성을 이미지로 묶고 공유·실행하는 과정을 단순화했다. Docker는 표준화된 이미지와 저장소를 통해 개발 환경에서 실행한 응용 프로그램을 서버와 클라우드로 옮기는 흐름을 대중화했다.[26]
2014년 Google이 Kubernetes를 오픈 소스로 공개하면서 컨테이너화된 응용 프로그램의 배포, 확장, 서비스 연결과 장애 복구를 클러스터 단위로 자동화하는 환경이 형성되었다.[27]
컨테이너는 호스트 커널을 공유하므로 전통적인 배포판 전체를 각 응용 프로그램마다 설치할 필요를 줄였다. 그 결과 배포판은 한편으로 Debian, Ubuntu와 Alpine 기반의 작은 컨테이너 사용자 공간 이미지를 제공하고, 다른 한편으로는 컨테이너 런타임과 Kubernetes를 실행하기 위한 최소 호스트 운영체제로 분화했다.
불변 시스템과 원자적 업데이트
전통적인 Linux 배포판은 실행 중인 루트 파일 시스템의 개별 패키지와 설정 파일을 직접 변경하는 방식으로 업데이트한다. 이 방식은 유연하지만, 시스템마다 설치된 패키지와 변경 이력이 달라지면서 구성 편차가 누적될 수 있고, 업데이트가 중간에 중단되면 이전 상태와 새 상태가 혼합될 수 있다.
클라우드와 대규모 서버 운영에서는 개별 시스템을 수동으로 수정하기보다 검증된 이미지를 배포하고 문제가 생긴 인스턴스를 새 이미지로 교체하는 방식이 확대되었다. 이러한 운영 모델은 기본 시스템을 직접 변경하지 않는 불변 운영체제와, 업데이트 전체를 하나의 단위로 전환하는 원자적 업데이트의 발전으로 이어졌다.
CoreOS Container Linux는 컨테이너 실행을 위한 최소 호스트 운영체제를 제공하고, 시스템 파티션을 이미지 단위로 자동 갱신하는 방식을 채택했다. CoreOS Container Linux가 종료된 뒤 그 계보를 이어받은 Flatcar Container Linux는 읽기 전용 시스템 이미지, 자동 프로비저닝과 원자적 업데이트를 사용하여 클라우드·가상화·베어메탈에서 일관된 컨테이너 호스트를 제공한다.[28]
OSTree는 Linux 기반 운영체제의 전체 파일 시스템 트리를 버전이 지정된 배포 객체로 관리하고 원자적으로 전환하는 기술로 개발되었다. 업데이트 도중 전원이 꺼지거나 오류가 발생해도 시스템은 완전한 이전 배포 또는 완전한 새 배포 중 하나로 부팅되도록 설계되었다.[29]
Fedora는 OSTree와 RPM을 결합한 rpm-ostree를 Fedora Silverblue, Fedora Kinoite, Fedora CoreOS와 Fedora IoT 등에 적용했다. 기본 운영체제는 하나의 배포 이미지로 갱신하고, 사용자 응용 프로그램과 개발 환경은 Flatpak 또는 컨테이너로 분리하는 구조가 발전했다. Fedora Atomic Desktops는 새 운영체제 배포를 내려받은 뒤 재부팅하여 적용하며, 이전 배포 상태로 롤백할 수 있다.[30][31]
openSUSE MicroOS, Talos Linux, Bottlerocket, Vanilla OS와 여러 현대 배포판도 읽기 전용 또는 스냅샷 기반 루트 파일 시스템, 선언적 설정과 원자적 업데이트를 서로 다른 방식으로 도입했다. 일부는 서버와 Kubernetes 노드에 집중하고, 일부는 데스크톱에서도 기본 운영체제와 응용 프로그램을 분리한다.
불변 시스템은 Linux 배포판을 개별 패키지가 계속 변경되는 설치 환경에서 버전이 지정된 운영체제 이미지로 전환한다. 다만 모든 파일을 완전히 변경 불가능하게 만드는 것은 아니며, 사용자 데이터, 시스템 상태와 명시적으로 허용된 설정 영역은 별도로 쓰기 가능하게 유지된다.
이러한 흐름은 전통적인 패키지 관리가 사라진다는 의미보다 역할이 이동한다는 의미에 가깝다. 패키지는 배포 서버에서 운영체제 이미지를 조립하는 입력으로 사용되고, 클라이언트는 완성된 시스템 트리를 받아 전환한다. 응용 프로그램은 Flatpak, 컨테이너와 개발 환경으로 분리되며, 운영체제 업데이트는 재현 가능성과 롤백을 중심으로 관리되는 방향으로 발전하고 있다.
계열과 파생 관계
Linux 배포판의 계열은 일반적으로 공통 조상 배포판, 패키지 기반, 저장소와 빌드 체계, 개발 결과가 전달되는 방향을 기준으로 구분한다. 같은 패키지 형식을 사용하는 배포판이라도 직접적인 개발 관계가 없을 수 있으며, 반대로 패키지 구성이 크게 달라졌더라도 기반 배포판의 소스 패키지와 저장소를 계속 이어받으면 같은 계열로 분류할 수 있다.
파생 관계는 소스 코드 전체를 복사했는지만으로 결정되지 않는다. 기반 배포판의 바이너리 패키지를 직접 사용하는 경우, 소스 패키지를 가져와 다시 빌드하는 경우, 저장소를 일정 시점에 동기화한 뒤 독자적으로 수정하는 경우와 일부 구성 요소만 선택적으로 가져오는 경우가 모두 존재한다.
배포판 계보에서 상류는 패키지와 변경 사항이 먼저 개발되는 쪽이고, 하류는 그 결과를 가져와 통합하거나 수정하는 쪽이다. 그러나 Fedora, CentOS Stream과 Red Hat Enterprise Linux의 관계처럼 하나의 계열 안에서도 기술별·릴리스별 상류와 하류의 위치가 달라질 수 있다. 따라서 배포판 계열은 단순한 가계도보다 지속적인 소프트웨어 공급망에 가깝다.
Debian 계열
Debian 계열은 Debian의 deb 패키지 형식, 패키지 메타데이터, 소스 패키지와 방대한 저장소를 기반으로 형성된 배포판 계열이다. Debian 프로젝트는 Debian에서 수행된 작업을 기반으로 하면서 독자적인 정체성, 목표와 사용자를 가진 별도의 조직이 만드는 배포판을 Debian 파생판으로 정의한다.[32]
Debian 파생판은 Debian 저장소를 그대로 사용하는 것부터 소스 패키지를 자체 저장소에서 다시 빌드하는 것까지 다양한 형태를 가진다. 일부 배포판은 Debian Stable을 기반으로 장기간 유지되는 시스템을 만들고, 일부는 Debian Testing이나 Unstable에서 더 최신의 패키지를 가져온다.
Ubuntu는 대표적인 Debian 파생판이다. Ubuntu는 Debian에서 소스 패키지를 가져오지만 자체 저장소, 릴리스 일정, 패키지 수정 사항과 보안 지원 체계를 운영한다. Debian의 파생판 조사 자료에서도 Ubuntu는 Debian을 기반으로 Linux를 대중화하고 다듬는 것을 목표로 한 배포판으로 분류된다.[33]
Ubuntu는 다시 Linux Mint, Pop!_OS, elementary OS, Zorin OS와 여러 배포판의 기반이 되었다. 이들은 Ubuntu의 패키지 저장소와 하드웨어 지원을 이용하면서 자체 데스크톱 환경, 설치 프로그램, 응용 프로그램과 정책을 추가한다.
이러한 구조에서는 Debian이 Ubuntu의 직접 기반이고, Ubuntu가 Linux Mint 등의 직접 기반이 된다. Linux Mint가 궁극적으로 Debian의 소프트웨어 생태계에 의존하더라도 일반판의 직접적인 패키지 기반은 Ubuntu이므로 계보에서는 Ubuntu 아래에 배치하는 것이 적절하다.
Debian 계열에는 Ubuntu를 거치지 않는 직접 파생판도 많다. Kali Linux, Tails, Raspberry Pi OS, Proxmox VE, Devuan, MX Linux와 SparkyLinux 등은 목적과 구성은 서로 다르지만 Debian의 패키지 기반과 개발 결과를 직접 활용한다.
Debian 계열의 파생판은 기반 Debian 릴리스와 어느 정도 동기화하는지에 따라 호환성이 달라진다. Debian 패키지를 거의 그대로 사용하는 배포판도 있지만, 자체 패치와 패키지 버전이 누적된 배포판에서는 Debian 저장소의 패키지를 직접 혼합하는 것이 안전하지 않을 수 있다.
Red Hat과 Fedora 계열
Red Hat 계열은 역사적으로 Red Hat Linux와 RPM을 중심으로 형성되었다. 그러나 현대의 Fedora, CentOS Stream과 Red Hat Enterprise Linux 관계는 하나의 배포판에서 여러 파생판이 단순히 갈라지는 구조보다 연속적인 개발 흐름에 가깝다.
Fedora는 새로운 커널, 컴파일러, 라이브러리와 시스템 기술을 빠르게 통합하는 공동체 배포판이며, Red Hat Enterprise Linux의 주요 상류 프로젝트 역할을 한다. Fedora 공식 문서는 Fedora가 RHEL보다 먼저 새로운 기술을 받아들이고, 그 가운데 선택된 기술이 이후 RHEL 개발에 반영된다고 설명한다.[34]
CentOS Stream은 Fedora의 결과가 기업용 RHEL 릴리스로 안정화되는 과정에서 다음 RHEL 부 릴리스에 들어갈 변경 사항을 지속적으로 공개하는 위치에 있다. Fedora가 다음 RHEL 주 버전의 넓은 기술적 상류라면 CentOS Stream은 다음 RHEL 부 릴리스에 더 가까운 개발 흐름이다.
이를 단순화하면 Fedora에서 새로운 기술이 통합되고, 선택된 구성이 CentOS Stream을 거쳐 RHEL의 향후 릴리스로 이어진다. Fedora 프로젝트에서도 Fedora가 RHEL과 CentOS Stream의 상류에 위치한다는 관계를 설명한다.[35]
AlmaLinux, Rocky Linux, Oracle Linux과 여러 Enterprise Linux 호환 배포판은 RHEL과의 응용 프로그램 및 바이너리 호환성을 목표로 한다. 이들은 Fedora를 직접 기반으로 일상적인 패키지를 가져오는 배포판이라기보다 RHEL의 인터페이스와 패키지 구성을 재현하거나 호환되도록 구축하는 하류 배포판이다.
Fedora 자체를 직접 기반으로 하는 파생판도 존재한다. Nobara Linux와 Ultramarine Linux 등은 Fedora 패키지를 기반으로 자체 저장소, 기본 설정과 추가 패키지를 제공한다. Universal Blue 계열은 Fedora의 원자적 데스크톱 이미지를 기반으로 다시 조립된 운영체제 이미지를 제공한다.
Red Hat 계열을 정리할 때는 Fedora, CentOS Stream과 RHEL을 동일한 단계의 병렬 배포판으로만 보는 것보다, 서로 다른 안정화 단계와 릴리스 목적을 가진 연결된 개발 계열로 보는 편이 정확하다.
Arch Linux 계열
Arch Linux는 다른 주요 배포판의 패키지 기반을 직접 계승하지 않고 독립적으로 개발된 롤링 릴리스 배포판이다. 최소한의 기본 시스템을 제공하고 사용자가 필요한 구성 요소를 직접 선택하도록 하며, 공식 저장소와 pacman 패키지 관리자를 중심으로 운영된다.[36]
Arch 계열 파생판은 Arch의 패키지와 저장소를 직접 사용하거나 일정 기간 지연하여 동기화하고, 그래픽 설치 프로그램, 사전 구성된 데스크톱 환경, 자체 저장소와 관리 도구를 추가하는 경우가 많다. ArchWiki는 Arch Linux에서 전체 또는 일부가 파생된 배포판 목록을 별도로 관리한다.[37]
EndeavourOS는 Arch에 가까운 패키지 흐름을 유지하면서 설치 프로그램과 초기 설정을 제공한다. Manjaro는 Arch 패키지를 자체 저장소로 가져온 뒤 별도의 시험과 지연 과정을 거쳐 제공하며, 자체 도구와 릴리스 채널을 운영한다. 따라서 Manjaro는 Arch 패키지 생태계에서 출발하지만 Arch 공식 저장소와 완전히 동일한 시점의 패키지를 사용하는 시스템은 아니다.
Artix Linux는 Arch의 패키지 체계와 사용자 경험을 계승하면서 systemd 대신 OpenRC, runit, s6와 dinit 같은 다른 초기화 체계를 제공한다. Parabola GNU/Linux-libre는 Arch를 기반으로 비자유 소프트웨어와 펌웨어를 제외하고 자유 소프트웨어 정책을 강화한다.
SteamOS는 기반이 변경된 대표적인 사례다. 초기 SteamOS 1과 2는 Debian을 기반으로 했지만, Steam Deck과 함께 사용되는 SteamOS 3 계열은 Arch Linux를 기반으로 한다. Valve는 현재 SteamOS를 Arch Linux 기반 배포판으로 설명한다.[38]
Arch 계열 배포판은 패키지를 빠르게 갱신한다는 공통점이 있지만, Arch 공식 저장소를 직접 사용하는지, 자체 저장소로 복제한 뒤 지연하는지에 따라 호환성과 업데이트 시점이 달라진다. Arch용 패키지라는 이유만으로 모든 Arch 파생판에서 그대로 사용할 수 있는 것은 아니다.
SUSE 계열
SUSE 계열은 역사적으로 SUSE Linux에서 발전했으며, 현대에는 openSUSE 공동체 배포판과 SUSE Linux Enterprise가 밀접하게 연결된 구조를 가진다. 두 프로젝트는 RPM 패키지 형식과 Zypper, Open Build Service 등의 기술을 공유한다.
openSUSE Tumbleweed는 지속적으로 갱신되는 롤링 릴리스 배포판이며, 새로운 패키지와 기술이 통합되는 주요 공동체 기반이다. SUSE는 이 생태계에서 선택한 기술을 시험하고 안정화하여 기업용 SUSE Linux Enterprise에 반영한다.
openSUSE Leap의 관계는 전통적인 단방향 파생 관계보다 복합적이다. Leap은 한동안 SUSE Linux Enterprise의 바이너리와 기반 패키지를 직접 공유하면서 openSUSE 공동체 패키지를 추가하는 형태로 구성되었다. openSUSE는 Leap 15.3에서 SUSE Linux Enterprise와 동일한 바이너리를 공유하는 구조를 확대했다고 설명했다.[39]
따라서 openSUSE Tumbleweed는 새로운 기술이 통합되는 상류 역할을 하고, SUSE Linux Enterprise는 이를 기업용으로 안정화하며, Leap은 다시 SLE 기반과 공동체 패키지를 결합하는 형태를 가질 수 있다. SUSE 역시 openSUSE와 SLE 사이의 기여 및 코드 공유 구조를 강화해 왔다.[40]
GeckoLinux과 같은 배포판은 openSUSE를 직접 기반으로 기본 데스크톱 구성, 코덱과 설치 경험을 변경한다. 이 경우 직접 기반은 SUSE Linux Enterprise가 아니라 openSUSE이므로 openSUSE 파생판으로 분류한다.
SUSE 계열은 Fedora–RHEL 계열과 마찬가지로 공동체 배포판과 기업용 배포판이 서로 코드를 주고받는 구조이므로, 단순한 한 방향 계보로만 표시하면 실제 개발 관계의 일부가 생략된다.
Gentoo 계열
Gentoo Linux는 소스 기반 패키지 관리자인 Portage와 ebuild를 중심으로 구성된 배포판이다. 사용자는 패키지 빌드 옵션, 기능과 최적화 설정을 세밀하게 선택할 수 있으며, Gentoo는 완성된 단일 바이너리 구성을 제공하기보다 다양한 시스템을 만들 수 있는 메타배포판의 성격을 가진다.
Funtoo Linux, Calculate Linux, Sabayon Linux, Redcore Linux, Pentoo와 Ututo 등은 Gentoo 또는 Gentoo의 Portage 생태계를 기반으로 만들어졌다. 일부는 Gentoo 패키지를 소스에서 직접 빌드하는 방식을 유지하고, 일부는 미리 빌드한 바이너리 패키지와 그래픽 설치 프로그램을 추가하여 설치 시간을 줄인다.
Gentoo 계열에서는 기반 관계가 패키지 파일의 직접 복제보다 Portage, ebuild 저장소, 프로파일과 USE 플래그 체계를 공유하는 방식으로 나타나는 경우가 많다. 파생판은 Gentoo 저장소 위에 자체 오버레이를 추가하거나 Gentoo ebuild를 가져와 독자적으로 관리할 수 있다.
ChromiumOS와 ChromeOS는 전통적인 범용 Gentoo 파생 배포판과는 성격이 다르지만, 빌드 시스템에서 Gentoo의 Portage와 ebuild 체계를 활용한다. ChromiumOS 개발 문서는 Portage가 운영체제의 기반 패키징 시스템으로 사용된다고 설명한다.[41]
ChromiumOS는 Gentoo 패키지를 그대로 사용자에게 제공하는 일반적인 Gentoo 데스크톱 배포판이 아니라, Portage와 오버레이를 이용해 장치별 운영체제 이미지를 빌드한다. 따라서 Gentoo 계열 기술을 기반으로 하지만 독자적인 플랫폼과 릴리스 체계를 가진 특수한 파생 계통으로 보는 편이 적절하다.
Slackware 계열
Slackware는 1993년부터 개발된 오래된 독립 Linux 배포판으로, 시스템 구성과 패키지를 비교적 단순하고 업스트림에 가까운 형태로 유지하는 것을 중시한다. Slackware는 전통적인 UNIX와 유사한 사용 방식, 단순성과 안정성을 프로젝트의 주요 원칙으로 제시한다.[42]
Slackware의 패키지는 일반적으로 압축된 파일 묶음과 설치 스크립트로 구성되며, 기본 패키지 도구는 복잡한 자동 의존성 해결보다 설치·제거와 업그레이드 자체에 집중한다. 이러한 단순한 구조는 파생 배포판이 Slackware 패키지를 재사용하면서 자체 저장소와 관리 도구를 추가하기 쉽게 했다.
Salix OS는 Slackware와의 호환성을 유지하면서 의존성 관리, 간소화된 설치와 데스크톱 구성을 추가한다. Zenwalk는 Slackware에서 출발하여 자체 패키지 선택과 데스크톱 환경을 발전시켰다. Absolute Linux와 VectorLinux도 Slackware를 기반으로 더 가볍거나 데스크톱 지향적인 구성을 제공했다.
Slax는 초기에는 Slackware를 기반으로 한 경량 라이브 배포판으로 발전했지만, 이후 Debian 기반으로 전환한 시기가 있다. 이처럼 같은 배포판 이름이 유지되어도 릴리스 시기에 따라 계열이 달라질 수 있다.
Porteus는 Slax와 Slackware 계통에서 발전한 모듈형 라이브 배포판이다. Porteus의 직접적인 역사적 기반을 따지면 Slackware뿐 아니라 Slax를 거친 중간 계보도 고려해야 한다.
Slackware 계열은 Debian이나 Fedora 계열보다 파생판의 수와 규모는 작지만, 라이브 배포판, 경량 시스템과 전통적인 UNIX식 구성을 선호하는 프로젝트에 지속적으로 영향을 주었다.
독립 배포판
독립 배포판은 Debian, Fedora, Arch Linux, Gentoo와 같은 기존 주요 배포판의 패키지 저장소와 릴리스 결과를 직접적인 기반으로 삼지 않고 자체 패키지, 빌드 체계와 저장소를 운영하는 배포판을 의미한다.
독립 배포판이라고 해서 모든 구성 요소를 처음부터 직접 개발한다는 뜻은 아니다. Linux 커널, GNU 도구, 데스크톱 환경과 응용 프로그램은 다른 배포판과 마찬가지로 공통 업스트림 프로젝트에서 가져온다. 차이는 이를 어느 배포판의 패키지로부터 가져오는 것이 아니라 자체 규칙으로 패키징하고 빌드한다는 점이다.
Arch Linux는 독립적으로 개발된 배포판이며, pacman과 자체 저장소를 운영한다. ArchWiki도 Arch Linux를 독립적으로 개발되는 범용 GNU/Linux 배포판으로 설명한다.[43]
Alpine Linux는 musl, BusyBox와 apk를 중심으로 자체 패키지 생태계를 형성했다. Void Linux는 XBPS 패키지 관리 체계와 독자적인 저장소를 운영하며, Solus는 eopkg와 자체 패키지 구성을 사용한다.
NixOS는 Nix 패키지 관리자와 선언적 시스템 구성을 중심으로 다른 전통적인 배포판과 구별되는 독립 계열을 형성했다. Guix System은 Nix의 개념에서 영향을 받았지만 GNU Guix와 Guile을 기반으로 별도의 패키지 및 운영체제 체계를 구축했으므로 NixOS의 일반적인 파생판으로만 보기는 어렵다.
Clear Linux OS, KaOS, Chimera Linux, Serpent OS, CRUX, Source Mage GNU/Linux, Tiny Core Linux와 SliTaz도 각각 자체 패키지 또는 빌드 체계를 운영하는 독립 배포판으로 분류할 수 있다.
독립 배포판 사이에서도 다른 프로젝트의 도구를 채택하는 경우는 흔하다. RPM, systemd, GNOME이나 KDE Plasma를 사용한다고 해서 자동으로 Fedora나 SUSE 계열이 되는 것은 아니다. 계열은 개별 기술의 사용보다 패키지와 릴리스 기반을 어디에서 가져오는지를 중심으로 판단한다.
복합 기반과 기반 변경
Linux 배포판의 계보는 항상 하나의 부모에서 하나의 자식으로 이어지는 고정된 구조가 아니다. 여러 배포판의 패키지와 기술을 동시에 가져오거나, 프로젝트가 개발 도중 기반 배포판을 바꾸거나, 같은 이름 아래 서로 다른 기반의 판을 병행하는 사례가 존재한다.
Linux Mint의 일반판은 Ubuntu를 직접 기반으로 하지만, LMDE은 Ubuntu를 거치지 않고 Debian을 직접 기반으로 한다. Linux Mint 프로젝트는 LMDE를 Ubuntu 없이 동일한 사용자 경험을 제공하기 위한 Debian 기반 판으로 설명한다.[44]
따라서 Linux Mint 전체를 하나의 계열에만 고정하면 세부 판의 실제 패키지 기반을 놓치게 된다. 일반 Linux Mint는 Ubuntu 계열에, LMDE는 Debian 직접 파생 계열에 해당한다.
SteamOS도 기반 변경 사례다. 초기 SteamOS는 Debian을 기반으로 했지만 SteamOS 3은 Arch Linux 기반으로 다시 설계되었다. 현재 SteamOS 공식 페이지와 Steam Deck 사양은 SteamOS 3을 Arch 기반으로 명시한다.[45][46]
배포판이 기반을 변경하면 패키지 형식, 저장소, 업데이트 방식과 호환성이 함께 달라질 수 있다. 프로젝트 이름과 사용자 경험은 유지되더라도 기술적 계보는 이전 릴리스와 분리해서 기록해야 한다.
일부 시스템은 특정 배포판의 패키지 관리 도구를 사용하지만 완성된 배포판 패키지를 그대로 가져오지는 않는다. ChromiumOS는 Gentoo의 Portage와 ebuild 모델을 사용하면서 자체 오버레이와 장치별 빌드 시스템으로 운영체제 이미지를 구성한다. 이러한 경우는 전통적인 파생판과 도구 기반 계승의 중간에 위치한다.
기업용 배포판과 공동체 배포판 사이에는 변경 사항이 양방향으로 이동하기도 한다. openSUSE Tumbleweed, SUSE Linux Enterprise와 openSUSE Leap의 관계처럼 한쪽에서 개발된 코드가 다른 쪽에서 안정화된 뒤 다시 공동체 배포판의 기반으로 사용될 수 있다.
Fedora, CentOS Stream과 RHEL의 관계 역시 고정된 하나의 부모·자식 관계가 아니다. Fedora는 장기적으로 새로운 RHEL 주 버전의 상류이고, CentOS Stream은 향후 RHEL 부 릴리스에 가까운 개발 흐름이며, RHEL 호환 배포판은 완성된 기업용 인터페이스를 재현하는 하류에 위치한다.
여러 기반의 패키지를 직접 혼합하는 배포판도 있지만, 서로 다른 배포판의 패키지는 라이브러리 버전, 컴파일 옵션과 파일 배치가 다를 수 있다. 따라서 복합 기반 배포판은 보통 각 기반 저장소를 그대로 동시에 사용하는 대신 자체 빌드 과정에서 소스와 패치를 통합하고 하나의 일관된 저장소로 다시 제공한다.
배포판 계보를 기록할 때는 프로젝트 이름보다 해당 릴리스의 직접적인 패키지 공급원, 저장소와 빌드 체계를 우선해야 한다. 기반 변경이 일어난 경우에는 전체 프로젝트를 하나의 계열에 고정하기보다 시기와 판별로 구분하는 것이 실제 기술 관계를 더 정확하게 나타낸다.
시스템 구성
Linux 배포판은 Linux 커널과 사용자 공간 프로그램을 중심으로 부트로더, 시스템 라이브러리, 초기화 시스템, 설치 프로그램, 데스크톱 환경과 장치 지원 파일을 결합해 하나의 운영체제를 구성한다. 배포판마다 같은 구성 요소를 사용하더라도 버전, 빌드 옵션, 기본 설정과 통합 방식이 다르며, 특정 구성 요소를 다른 구현으로 교체할 수도 있다.
배포판의 구성은 고정된 단일 계층이라기보다 부팅과 실행 과정에서 서로 연결되는 여러 부분으로 이루어진다. 펌웨어가 부트로더를 실행하면 부트로더가 커널과 초기 램 파일 시스템을 메모리에 적재하고, 커널이 하드웨어를 초기화한 뒤 루트 파일 시스템과 사용자 공간을 시작한다. 이후 초기화 시스템이 서비스와 로그인 환경을 구성하고, 데스크톱 배포판에서는 디스플레이 서버와 데스크톱 환경이 실행된다.
서버, 데스크톱, 모바일과 임베디드 배포판은 같은 기본 구조를 공유하지만 실제 포함 범위는 다르다. 서버 배포판은 그래픽 환경을 생략할 수 있고, 컨테이너 이미지는 자체 커널과 부트로더를 포함하지 않는 경우가 일반적이다. 임베디드 배포판은 하나의 장치에 필요한 드라이버와 프로그램만 넣어 고정된 시스템 이미지를 만들기도 한다.
Linux 커널
Linux 커널은 배포판의 핵심 구성 요소로서 프로세스 실행, 가상 메모리, 파일 시스템, 장치 드라이버, 네트워크와 보안 기능을 관리한다. 사용자 프로그램은 시스템 호출과 여러 커널 인터페이스를 통해 이러한 기능을 사용한다.
배포판은 일반적으로 Linux 커널의 공식 소스에서 특정 버전을 선택하고, 필요한 설정과 패치를 적용하여 자체 커널 패키지를 만든다. 같은 커널 버전을 사용하는 배포판이라도 활성화된 파일 시스템, 보안 모듈, 네트워크 기능, 선점 방식과 장치 드라이버가 다를 수 있다.
커널은 배포판 전체와 별도로 개발되는 업스트림 프로젝트다. 배포판 유지 관리자는 업스트림 커널 릴리스를 가져오고, 배포판의 릴리스와 지원 정책에 맞춰 안정화한다. 최신 기능을 빠르게 제공하는 배포판은 새로운 커널 계열로 자주 이동하는 반면, 장기 지원 배포판은 특정 커널을 유지하면서 보안 수정과 중요한 하드웨어 지원을 이전 버전에 역이식할 수 있다.
커널과 사용자 공간 사이에는 시스템 호출, 장치 파일, procfs, sysfs, Netlink와 여러 전용 인터페이스가 존재한다. Linux 커널 문서는 사용자 공간이 의존할 수 있는 안정적 인터페이스와 시험 중이거나 폐기된 인터페이스를 별도로 구분한다. 일반적인 시스템 호출과 안정적인 사용자 공간 인터페이스는 기존 프로그램의 동작을 유지하기 위해 강한 하위 호환성을 갖는다.[47]
배포판은 하나의 커널 패키지만 제공하지 않을 수도 있다. 일반용 커널 외에 장기 지원 커널, 실시간 커널, 강화된 보안 커널, 가상 머신용 커널과 특정 장치용 커널을 별도 패키지 또는 이미지로 제공할 수 있다.
컨테이너 이미지는 일반적으로 Linux 커널을 포함하지 않는다. 컨테이너 안의 사용자 공간은 호스트 운영체제의 커널을 공유하기 때문에, 컨테이너 내부 배포판의 버전과 호스트 배포판이 서로 달라도 커널 기능과 시스템 호출의 실제 제공자는 호스트다.
사용자 공간
사용자 공간은 커널 권한 밖에서 실행되는 시스템 프로그램, 라이브러리, 서비스와 응용 프로그램의 영역이다. 사용자가 배포판을 직접 이용하면서 접하는 셸, 명령줄 도구, 패키지 관리자, 로그인 서비스, 네트워크 도구와 데스크톱 환경 대부분이 사용자 공간에 속한다.
전통적인 GNU/Linux 배포판은 GNU Core Utilities, Bash, util-linux, procps, iproute2와 같은 여러 프로젝트의 프로그램을 조합한다. 파일 복사와 삭제, 프로세스 조회, 디스크 연결, 사용자 관리와 네트워크 설정 같은 기본 기능도 하나의 통합 프로젝트가 아니라 서로 다른 업스트림 프로젝트에서 제공되는 경우가 많다.
경량 또는 임베디드 배포판은 여러 명령을 하나의 실행 파일로 묶은 BusyBox를 사용해 시스템 크기를 줄일 수 있다. Android는 GNU 중심의 전통적인 사용자 공간 대신 Bionic, Toybox, Android 런타임과 자체 서비스 프레임워크를 사용한다.
사용자 공간은 배포판의 성격을 구분하는 핵심 부분이다. 같은 Linux 커널을 사용하더라도 어떤 C 라이브러리와 셸, 서비스 관리자, 패키지 관리자와 그래픽 환경을 선택하는지에 따라 응용 프로그램 호환성과 관리 방법이 달라진다.
배포판은 사용자 공간 프로그램을 개별 패키지로 관리하며, 각 패키지를 특정 라이브러리 버전과 파일 시스템 구조에 맞게 빌드한다. 업스트림에서 같은 소스 코드를 가져오더라도 배포판의 패치와 컴파일 옵션에 따라 기능과 기본 동작에 차이가 생길 수 있다.
사용자 공간과 커널은 독립적으로 갱신할 수 있다. 새로운 사용자 공간을 이전 커널에서 실행하거나, 비교적 오래된 사용자 공간에 최신 커널을 사용할 수 있지만 필요한 시스템 호출과 라이브러리 요구 사항이 맞아야 한다. Linux가 사용자 공간 인터페이스의 하위 호환성을 중시하는 것은 이러한 조합을 가능하게 하는 기반이다.
C 라이브러리
C 표준 라이브러리는 응용 프로그램과 Linux 커널 사이에서 핵심적인 연결 역할을 한다. 프로그램은 파일 입출력, 메모리 할당, 문자열 처리, 스레드, 시간과 네트워크 기능을 C 라이브러리의 함수로 호출하며, 라이브러리는 필요한 경우 이를 Linux 시스템 호출로 변환한다.
대부분의 전통적인 범용 배포판은 glibc를 사용한다. glibc는 ISO C 표준 라이브러리뿐 아니라 POSIX, 스레드, 동적 링커와 여러 GNU 확장 인터페이스를 제공하며, Debian, Ubuntu, Fedora, Red Hat Enterprise Linux, Arch Linux와 openSUSE 등의 기본 C 라이브러리다.
Alpine Linux와 일부 경량 배포판은 musl을 사용한다. musl은 Linux 시스템 호출 API 위에 ISO C와 POSIX 인터페이스를 구현하는 C 라이브러리이며, 정적 링크와 작은 시스템 구성, 단순한 구현을 주요 목표로 한다.[48]
Android는 자체 C 라이브러리인 Bionic을 사용한다. 임베디드 환경에서는 uClibc-ng 같은 구현이 사용될 수 있다. 이처럼 Linux 배포판이라고 해서 반드시 glibc나 GNU 사용자 공간을 사용하는 것은 아니다.
C 라이브러리는 단순한 함수 모음에 그치지 않고 프로그램의 ABI에 큰 영향을 준다. 동적으로 링크된 프로그램은 특정 동적 링커 경로와 함수 버전, 데이터 구조와 동작에 의존할 수 있다. 따라서 glibc용으로 빌드된 바이너리는 musl 기반 배포판에서 별도의 호환 계층이나 재컴파일 없이 실행되지 않을 수 있다.
같은 C 라이브러리를 사용하더라도 CPU 아키텍처와 라이브러리 버전이 다르면 바이너리 호환성이 보장되지 않는다. 배포판은 C 라이브러리를 핵심 시스템 패키지로 관리하며, ABI를 깨뜨리는 변경이 전체 패키지 재빌드로 이어질 수 있기 때문에 일반 응용 프로그램보다 신중하게 갱신한다.
C++ 프로그램은 C 라이브러리와 함께 libstdc++ 또는 libc++ 같은 C++ 표준 라이브러리를 사용한다. Rust, Go와 다른 언어도 실행 방식에 따라 C 라이브러리와 동적 링커에 의존할 수 있으므로, C 라이브러리의 선택은 C 프로그램에만 영향을 주는 문제가 아니다.
초기화 시스템
커널이 루트 파일 시스템을 준비하면 사용자 공간의 첫 프로세스를 실행한다. 전통적으로 이 프로세스는 init으로 불리며 프로세스 식별자 1번인 PID 1을 가진다. 초기화 시스템은 나머지 서비스와 로그인 환경을 시작하고, 시스템 종료와 서비스 수명 주기를 관리한다.
현대의 많은 주요 배포판은 systemd를 기본 초기화 및 서비스 관리 체계로 사용한다. systemd는 PID 1로 실행되는 시스템·서비스 관리자뿐 아니라 로그, 로그인 세션, 장치 이벤트, 네트워크와 시간 관리 등에 사용되는 여러 구성 요소를 제공한다. systemd 프로젝트는 이를 Linux 시스템을 구성하는 기본 구성 요소 모음으로 설명한다.[49]
systemd에서는 서비스를 유닛으로 표현하며, 서비스 사이의 의존 관계와 시작 순서를 선언적으로 기술한다. 필요한 서비스를 병렬로 시작할 수 있고, 소켓·장치·경로와 타이머를 기준으로 서비스를 활성화할 수도 있다.
모든 배포판이 systemd를 사용하는 것은 아니다. Gentoo Linux와 Alpine Linux에서는 OpenRC가 널리 사용되며, Void Linux는 runit을 기본으로 사용한다. Artix Linux는 OpenRC, runit, s6와 dinit 기반 구성을 제공하고, Devuan은 Debian에서 systemd에 대한 기본 의존성을 제거한 배포판이다.
초기화 시스템의 선택은 서비스 명령과 설정 파일뿐 아니라 로그 관리, 사용자 세션, 장치 처리와 데스크톱 구성에도 영향을 줄 수 있다. 일부 응용 프로그램은 systemd 자체보다 D-Bus, logind 또는 특정 기능 인터페이스에 의존하므로 다른 초기화 시스템을 사용하는 배포판은 대체 구현이나 호환 계층을 제공하기도 한다.
초기화 시스템이 실행되기 전에는 initramfs가 임시 사용자 공간으로 사용될 수 있다. initramfs는 실제 루트 파일 시스템을 찾고, 저장 장치·암호화·RAID와 논리 볼륨에 필요한 모듈과 도구를 실행한 뒤 최종 루트 파일 시스템으로 전환한다.
부트로더
부트로더는 컴퓨터의 펌웨어로부터 실행 제어를 받아 Linux 커널과 필요한 초기 램 파일 시스템을 메모리에 적재하고 커널에 제어를 넘긴다. 여러 운영체제나 커널 버전이 설치된 경우 사용자가 부팅 대상을 선택할 수 있는 메뉴도 제공한다.
전통적인 BIOS 환경에서는 부트로더가 디스크의 부트 영역에서 단계적으로 실행되었다. 현대의 UEFI 환경에서는 펌웨어가 EFI 시스템 파티션에 저장된 EFI 실행 파일을 직접 실행한다. 같은 배포판이라도 펌웨어와 설치 방식에 따라 부트로더 구성이 달라질 수 있다.
GNU GRUB은 여러 Linux 배포판에서 널리 사용되는 범용 부트로더다. 다양한 파일 시스템과 운영체제를 인식하며, Linux 커널을 직접 적재하거나 다른 부트로더와 운영체제로 체인 로딩할 수 있다. GNU 프로젝트는 GRUB을 여러 아키텍처와 운영체제를 지원하는 유연한 부트로더로 설명한다.[50]
systemd-boot는 UEFI 환경을 위한 비교적 단순한 부트 관리자다. EFI 시스템 파티션에 위치한 항목을 읽고 EFI 실행 파일이나 EFI Stub을 포함한 Linux 커널을 실행한다.[51]
그 밖에 Syslinux, extlinux, rEFInd, U-Boot와 아키텍처별 부트로더가 사용된다. 임베디드 장치와 ARM 보드에서는 U-Boot가 펌웨어와 운영체제 사이의 부팅 환경을 제공하는 경우가 많다.
Linux 커널은 EFI Stub을 포함해 UEFI 펌웨어에서 직접 실행될 수도 있다. 통합 커널 이미지는 커널, initramfs, 커널 명령행과 필요한 메타데이터를 하나의 서명 가능한 EFI 실행 파일로 묶는다. 이 방식은 Secure Boot와 원자적 시스템 이미지 관리에서 활용된다.
배포판은 부트로더 패키지만 제공하는 것이 아니라 커널 업데이트 때 부팅 항목과 initramfs를 자동으로 갱신하는 스크립트와 정책을 함께 관리한다. 이 통합이 올바르게 동작하지 않으면 새 커널이 설치되어도 부팅 메뉴에 나타나지 않거나 필요한 저장 장치 드라이버를 불러오지 못할 수 있다.
설치 프로그램
설치 프로그램은 실행 중인 설치 미디어나 네트워크 환경에서 대상 디스크에 배포판을 구성하는 도구다. 하드웨어 감지, 언어와 키보드 선택, 디스크 파티션, 파일 시스템 생성, 패키지 설치, 사용자 계정 설정, 네트워크 구성과 부트로더 설치를 처리한다.
Debian Installer는 Debian의 설치 시스템으로, 각 설치 작업을 수행하는 여러 전용 구성 요소로 이루어진다. 일반 설치에서는 이 구성 요소들이 정해진 순서로 실행되지만 필요하면 메뉴를 통해 개별 단계를 수동으로 선택할 수 있다.[52]
Anaconda는 Fedora, Red Hat Enterprise Linux와 일부 RPM 계열 배포판에서 사용하는 설치 프로그램이다. 대상 컴퓨터의 하드웨어를 확인하고 파일 시스템과 저장소를 구성한 뒤 선택한 운영체제 소프트웨어를 설치한다.[53]
Calamares는 특정 배포판에 종속되지 않는 공용 그래픽 설치 프로그램이다. 여러 독립 배포판이 같은 설치 프로그램을 공유하면서 배포판별 브랜딩, 파티션 정책, 패키지 설치와 부트로더 구성을 모듈로 지정할 수 있다. Calamares 프로젝트는 여러 배포판이 공동으로 사용할 수 있는 설치 시스템을 만들기 위해 시작되었다.[54]
Ubuntu 계열에서는 Subiquity와 여러 설치 프런트엔드가 사용되어 왔고, Arch Linux는 전통적으로 수동 설치 절차를 제공하면서 공식 설치 도우미인 archinstall도 제공한다. 일부 데스크톱 배포판은 라이브 환경에서 설치 프로그램을 실행해 현재 표시되는 시스템을 대상 디스크로 복사한다.
설치 프로그램이 배포판 자체의 필수 조건인 것은 아니다. 컨테이너 이미지와 클라우드 이미지는 디스크에 대화형으로 설치하지 않고 이미지 복제와 초기 설정으로 배치된다. NixOS, Gentoo와 Linux From Scratch처럼 명령과 설정 파일을 이용해 시스템을 직접 구성하는 배포 방식도 있다.
설치 프로그램은 설치가 끝난 뒤 실행되는 운영체제의 일부로 계속 남지 않을 수 있다. 그러나 디스크 레이아웃, 파일 시스템, 암호화, 부트 방식과 기본 패키지를 결정하므로 설치 이후 시스템 구조에 직접적인 영향을 준다.
기본 데스크톱 환경
데스크톱용 Linux 배포판은 그래픽 셸, 창 관리자 또는 컴포지터, 패널, 설정 도구, 파일 관리자와 기본 응용 프로그램을 묶은 데스크톱 환경을 제공할 수 있다. 서버와 최소 설치에서는 데스크톱 환경을 포함하지 않으며 사용자가 필요할 때 별도로 설치한다.
GNOME과 KDE Plasma는 주요 범용 Linux 데스크톱 환경이다. GNOME은 활동 개요와 작업 공간 중심의 통합된 사용자 경험을 제공하며, Plasma는 패널·위젯·창 동작과 외형을 폭넓게 구성할 수 있는 데스크톱 환경이다. KDE 문서에서는 Plasma를 데스크톱의 핵심 사용자 인터페이스로 설명한다.[55][56]
Xfce, LXQt, MATE, Cinnamon, Budgie와 COSMIC 등의 환경도 배포판의 기본 데스크톱으로 사용된다. 하드웨어 자원 사용량, 전통적인 데스크톱 배치, Wayland 지원, 접근성과 사용자 정의 정도에 따라 배포판이 선택하는 기본 환경이 달라진다.
데스크톱 환경은 Linux 배포판 자체와 별도의 업스트림 프로젝트다. Fedora가 GNOME을 기본으로 제공하고 Kubuntu가 Plasma를 제공하더라도, 각 데스크톱의 핵심 개발은 해당 프로젝트에서 이루어진다. 배포판은 이를 패키징하고 테마, 확장, 기본 응용 프로그램과 설정을 추가한다.
동일한 배포판에서도 여러 데스크톱 환경을 설치할 수 있다. Debian과 Arch Linux처럼 설치 시 사용자가 선택하게 하는 배포판이 있고, Fedora와 Ubuntu처럼 특정 기본 구성을 중심으로 별도의 공식 변형이나 설치 이미지를 제공하는 프로젝트도 있다.
그래픽 환경에는 데스크톱 셸 외에도 Wayland 컴포지터 또는 X.Org Server, 로그인 화면을 제공하는 디스플레이 관리자, 오디오·입력·네트워크 서비스와 그래픽 드라이버가 연결된다. 따라서 데스크톱 환경은 독립된 응용 프로그램처럼 보이지만 실제로는 사용자 공간의 여러 시스템 서비스와 함께 동작한다.
기본 데스크톱 환경은 배포판의 계열을 결정하지 않는다. GNOME을 사용하는 Debian 계열과 Fedora 계열은 서로 다른 배포판 계열이며, Plasma를 기본으로 제공하는 배포판도 패키지 기반과 개발 관계에 따라 각각 다른 계열에 속한다.
하드웨어 지원
Linux 배포판의 하드웨어 지원은 Linux 커널의 장치 드라이버, 펌웨어 파일, 사용자 공간 드라이버, 그래픽 스택과 배포판의 커널 설정이 함께 결정한다. 같은 Linux 커널 계열을 사용하는 배포판이라도 제공하는 펌웨어와 독점 드라이버, 커널 버전에 따라 실제 지원 범위가 달라질 수 있다.
Linux 커널에는 PCI, USB, 저장 장치, 네트워크, 입력 장치, 그래픽, 오디오와 여러 시스템 온 칩 장치를 위한 드라이버가 포함된다. 커널의 장치 모델은 버스, 장치와 드라이버의 공통 구조를 제공하고, 하드웨어와 일치하는 드라이버를 연결한다.[57]
많은 장치는 커널 드라이버 외에 장치 내부의 마이크로컨트롤러에서 실행할 펌웨어 파일을 요구한다. 커널은 사용자 공간에 저장된 펌웨어를 요청해 장치에 적재할 수 있다.[58]
배포판은 linux-firmware와 제조사별 펌웨어 패키지를 제공하지만 자유 소프트웨어 정책에 따라 기본 포함 범위가 다를 수 있다. 비자유 펌웨어를 설치 이미지에 포함하는 배포판도 있고, 별도 저장소나 사용자의 명시적 선택을 요구하는 배포판도 있다.
그래픽 하드웨어는 커널의 DRM/KMS 드라이버와 Mesa 사용자 공간 드라이버, Vulkan·OpenGL 라이브러리와 디스플레이 서버가 함께 지원한다. AMD와 Intel 그래픽은 주로 커널과 Mesa의 공개 드라이버를 사용하며, NVIDIA는 공개 커널 모듈과 독점 사용자 공간 구성 요소를 포함한 별도 드라이버 패키지가 사용될 수 있다.
새로운 하드웨어는 최신 커널, 펌웨어와 Mesa가 필요한 경우가 많다. 롤링 릴리스와 최신 배포판은 새로운 장치를 빠르게 지원할 가능성이 높고, 장기 지원 배포판은 안정된 사용자 공간을 유지하면서 커널이나 하드웨어 지원 스택을 별도로 갱신할 수 있다.
노트북의 절전, 화면 밝기, 터치패드, 지문 인식, 카메라와 오디오처럼 여러 장치와 펌웨어가 연결된 기능은 단일 드라이버만으로 결정되지 않는다. ACPI 또는 장치 트리 정보, 커널 드라이버, 펌웨어, PipeWire·libinput·UPower 같은 사용자 공간 구성 요소와 데스크톱 환경이 함께 동작해야 한다.
배포판은 설치 프로그램과 라이브 이미지에서 하드웨어를 자동 감지하고 필요한 커널 모듈과 펌웨어를 불러온다. 설치 후에는 장치 추가 이벤트를 처리하고, 필요한 경우 별도의 독점 드라이버나 마이크로코드를 설치하도록 안내할 수 있다.
지원하는 CPU 아키텍처도 배포판마다 다르다. x86-64만 공식 지원하는 배포판이 있는 반면 Debian과 같은 배포판은 ARM64, RISC-V, IBM Z와 여러 아키텍처용 패키지 저장소를 운영한다. 같은 배포판 이름이더라도 아키텍처마다 사용할 수 있는 패키지와 장치 지원 범위가 다를 수 있다.
하드웨어 제조사가 Linux 드라이버와 문서를 공개하지 않거나 특정 커널 버전에만 맞춘 외부 모듈을 제공하면 지원이 제한될 수 있다. 외부 커널 모듈은 커널 내부 인터페이스 변화에 맞춰 다시 빌드해야 하며, Secure Boot 환경에서는 신뢰할 수 있는 키로 서명해야 적재할 수 있다.
따라서 Linux 배포판의 하드웨어 호환성은 단순히 “Linux가 지원하는가”만으로 판단하기보다 배포판이 제공하는 커널 버전, 펌웨어 정책, 그래픽 드라이버, CPU 아키텍처와 지원 기간을 함께 확인해야 한다.
패키지 관리
패키지 관리는 Linux 배포판을 구성하는 소프트웨어를 일정한 형식으로 설치하고, 갱신하고, 제거하며, 파일과 의존 관계를 추적하는 체계다. 배포판은 Linux 커널과 기본 사용자 공간부터 데스크톱 환경과 응용 프로그램까지 대부분의 구성 요소를 패키지로 관리한다.
패키지 관리 체계는 일반적으로 패키지 파일 형식, 설치된 패키지 데이터베이스를 관리하는 저수준 도구, 원격 저장소와 의존성을 처리하는 고수준 패키지 관리자, 패키지를 빌드하고 배포하는 서버 기반 시설로 구성된다.
사용자가 패키지 설치를 요청하면 패키지 관리자는 활성화된 저장소의 메타데이터를 검색하고, 요청한 패키지와 필요한 의존 패키지의 버전 및 아키텍처를 선택한다. 이후 파일을 내려받아 서명과 무결성을 확인하고, 충돌 여부를 검사한 뒤 하나의 트랜잭션으로 설치하거나 갱신한다.
패키지 관리 방식은 배포판 계열을 구분하는 주요 특징이지만, 패키지 형식 하나만으로 계열이 결정되지는 않는다. Fedora와 openSUSE는 모두 RPM을 사용하지만 서로 다른 저장소, 빌드 서비스, 패키지 정책과 고수준 관리 도구를 운영한다. 반대로 Debian과 Ubuntu는 같은 deb 계열이지만 패키지 버전과 저장소를 독립적으로 관리한다.
패키지 형식
패키지 형식은 프로그램 파일과 설치에 필요한 메타데이터를 하나의 배포 단위로 묶는 규격이다. 패키지에는 실행 파일과 라이브러리뿐 아니라 패키지 이름, 버전, 대상 아키텍처, 의존 관계, 파일 권한, 설정 파일 정보와 설치 전후에 실행할 스크립트가 포함될 수 있다.
Debian 계열은 주로 deb 형식을 사용한다. Debian 바이너리 패키지는 실행 파일, 설정 파일, 설명서, 저작권 정보와 기타 자료를 포함하는 Debian 전용 아카이브이며 일반적으로 .deb 확장자를 사용한다.[59]
deb 패키지는 내부적으로 패키지 제어 정보와 실제 파일 아카이브를 포함한다. 제어 정보에는 패키지 이름, 버전, 아키텍처, 유지 관리자, 설명과 Depends, Recommends, Conflicts, Provides 등의 관계가 기록된다.
Red Hat, Fedora, SUSE와 여러 배포판은 RPM 형식을 사용한다. RPM 패키지는 설치할 파일과 함께 설명 정보, 파일 속성, 의존 관계, 보조 스크립트와 검증 정보를 포함한다. RPM 도구는 패키지의 설치·갱신·삭제뿐 아니라 설치된 파일과 패키지의 무결성 검증도 지원한다.[60][61]
Arch Linux 계열의 패키지는 일반적으로 .pkg.tar.zst 형식으로 배포된다. 이는 프로그램 파일과 패키지 메타데이터를 포함한 압축 tar 아카이브이며, pacman은 간단한 압축 패키지 파일과 로컬 패키지 데이터베이스를 이용해 이를 관리한다.[62]
Slackware는 전통적으로 압축 tar 아카이브와 설치 스크립트를 결합한 비교적 단순한 패키지 형식을 사용한다. Alpine Linux는 .apk, Void Linux는 .xbps, Gentoo는 소스 빌드 규칙을 기록하는 ebuild를 중심으로 자체 형식과 관리 체계를 운영한다.
패키지 파일은 일반적인 압축 파일과 달리 임의의 위치에 단순히 압축을 푸는 용도로 사용되지 않는다. 패키지 관리자는 파일 소유권을 기록하고, 기존 패키지와의 충돌을 검사하며, 설정 파일과 설치 스크립트를 정해진 정책에 따라 처리한다.
패키지 형식이 같더라도 다른 배포판의 패키지를 안전하게 설치할 수 있다는 뜻은 아니다. 패키지는 특정 라이브러리 버전, 파일 시스템 구조, 컴파일 옵션, 패키지 이름과 배포판 정책에 맞춰 빌드된다. Fedora용 RPM을 openSUSE에 설치하거나 Debian용 deb를 Ubuntu에 임의로 설치하면 형식은 인식되어도 의존성과 시스템 구성이 맞지 않을 수 있다.
패키지 관리자
패키지 관리자는 패키지를 설치·갱신·제거하고 설치 상태를 기록하는 프로그램 또는 도구 모음이다. 하나의 배포판에서도 개별 패키지 파일을 처리하는 저수준 도구와 저장소 및 의존성을 관리하는 고수준 도구가 분리될 수 있다.
Debian 계열에서 dpkg는 개별 deb 파일을 풀고 설치 스크립트를 실행하며 로컬 패키지 데이터베이스를 관리하는 저수준 도구다. APT는 저장소에서 패키지와 메타데이터를 받아 의존성을 계산한 뒤 dpkg를 통해 실제 설치를 수행한다. Debian은 dpkg가 개별 패키지를 처리하고 APT와 Synaptic 같은 도구가 저장소에서 패키지를 받아 dpkg에 작업을 전달한다고 설명한다.[63]
사용자가 일반적으로 실행하는 apt install, apt upgrade와 같은 명령은 고수준 작업에 해당한다. apt-get, apt-cache, aptitude와 그래픽 프런트엔드도 같은 APT 및 Debian 패키지 기반을 이용할 수 있다.
RPM 계열에서 rpm은 개별 RPM 패키지의 설치, 조회, 검증, 갱신과 제거를 담당하는 저수준 도구다. Fedora와 Red Hat 계열에서는 DNF가 저장소 메타데이터와 의존성 해결을 담당하며, openSUSE에서는 Zypper가 같은 역할을 수행한다.
Arch Linux의 pacman은 로컬 패키지 데이터베이스 관리와 원격 저장소 동기화, 의존성 해결을 하나의 명령 체계로 제공한다. Gentoo의 Portage와 emerge는 소스 코드를 내려받아 선택한 빌드 옵션에 맞춰 컴파일하고 설치하는 과정까지 관리한다.
Alpine Linux는 apk, Void Linux는 xbps-install을 포함한 XBPS 도구 모음, NixOS는 Nix를 사용한다. Nix는 패키지를 고유한 저장소 경로에 설치하고 동일한 라이브러리의 여러 버전을 병렬로 유지할 수 있다는 점에서 전통적인 전역 파일 배치 방식과 차이가 있다.
그래픽 소프트웨어 센터는 독립된 패키지 형식이라기보다 여러 패키지 관리 체계를 호출하는 프런트엔드인 경우가 많다. GNOME Software와 KDE Discover는 배포판 패키지뿐 아니라 Flatpak, Snap과 펌웨어 업데이트를 하나의 사용자 인터페이스에 표시할 수 있다.
패키지 관리자는 관리자 권한으로 시스템 전체에 파일을 설치할 수 있으므로 운영체제의 핵심 신뢰 구성 요소다. 패키지 서명 검증을 비활성화하거나 출처가 확인되지 않은 패키지를 설치하면 프로그램 자체뿐 아니라 설치 스크립트에도 시스템 권한이 부여될 수 있다.
소프트웨어 저장소
소프트웨어 저장소는 배포판이 제공하는 패키지 파일과 검색·의존성 해결에 필요한 메타데이터를 보관하는 배포 서버다. 저장소는 일반 웹 서버, 미러 서버, 로컬 디렉터리, 광학 디스크 또는 별도의 네트워크 프로토콜을 통해 제공될 수 있다.
저장소 메타데이터에는 이용 가능한 패키지의 이름, 버전, 아키텍처, 의존 관계, 파일 크기, 체크섬과 다운로드 위치가 기록된다. 패키지 관리자는 모든 패키지 파일을 먼저 내려받지 않고 메타데이터만 동기화하여 검색과 의존성 계산을 수행한다.
Debian 계열에서 APT는 하나 이상의 저장소에서 패키지 목록을 내려받는다. 저장소는 안정판과 시험판 같은 배포 묶음, main과 같은 구성 요소, CPU 아키텍처와 소스 패키지 영역으로 나뉠 수 있다. 저장소는 인터넷 서버뿐 아니라 로컬 디렉터리와 CD 또는 DVD에도 위치할 수 있다.[64]
Fedora와 Red Hat 계열의 DNF 저장소는 RPM 패키지와 repodata 메타데이터를 제공한다. 저장소 설정에는 일반적으로 고유 식별자와 패키지를 가져올 baseurl, metalink 또는 미러 목록이 포함된다.[65]
배포판은 지리적으로 분산된 미러를 이용해 다운로드 부하를 나눈다. 미러 선택 도구는 네트워크 위치와 응답 속도, 최신 동기화 상태를 기준으로 적절한 서버를 선택할 수 있다.
공식 저장소는 보통 릴리스 정책에 따라 여러 영역으로 나뉜다. 핵심 시스템과 공식 지원 패키지, 공동체 유지 패키지, 자유 소프트웨어 정책에 따라 분리된 펌웨어와 비자유 소프트웨어, 시험 또는 디버그 패키지가 서로 다른 저장소에 제공될 수 있다.
패키지와 저장소 메타데이터에는 디지털 서명이 적용된다. 패키지 관리자는 배포판이 미리 신뢰하도록 설정한 공개 키를 사용해 메타데이터 또는 패키지가 정식 배포자에 의해 서명되었으며 전송 중 변경되지 않았는지 확인한다.
서명은 패키지 내용이 안전하거나 오류가 없다는 것을 보증하지 않는다. 서명은 해당 패키지가 특정 키 소유자가 배포한 그대로임을 확인하는 수단이다. 따라서 어떤 키와 저장소를 신뢰할 것인지는 별도의 정책 문제다.
의존성 해결
프로그램은 다른 라이브러리, 런타임, 데이터 파일과 시스템 서비스에 의존할 수 있다. 패키지 관리자는 이러한 관계를 패키지 메타데이터로 표현하고, 설치 요청을 만족하는 패키지 집합을 계산한다.
Debian 패키지의 Depends 필드는 프로그램이 정상적으로 동작하기 위해 필요한 다른 패키지와 허용되는 버전 범위를 기록한다. APT는 이 정보를 사용해 필요한 라이브러리와 도구를 함께 설치한다.[66]
의존 관계에는 반드시 필요한 패키지 외에도 권장 패키지, 선택적인 제안, 기능상 충돌하는 패키지, 다른 패키지를 대체하거나 가상 기능을 제공하는 관계가 포함될 수 있다. Debian 정책은 Depends, Pre-Depends, Recommends, Suggests, Breaks, Conflicts, Provides와 같은 필드로 패키지 관계를 정의한다.[67]
RPM도 패키지가 필요로 하는 패키지 이름이나 기능을 Requires로 표현한다. RPM은 설치, 삭제와 갱신 과정에서 이 요구 사항이 만족되는지 확인한다.[68]
고수준 패키지 관리자는 사용자의 요청, 현재 설치된 패키지, 활성 저장소의 모든 후보와 충돌 조건을 하나의 의존성 문제로 계산한다. 단순히 가장 최신인 패키지를 고르는 것이 아니라 전체 조건을 만족시키기 위해 일부 의존 패키지의 이전 버전을 선택하거나 다른 패키지를 제거해야 할 수도 있다. DNF는 설정에 따라 충돌 패키지의 제거까지 포함한 해결책을 탐색할 수 있다.[69]
패키지 A가 B에 의존하고 B가 다시 C에 의존하면 관리자는 이 관계를 재귀적으로 계산한다. 순환 의존성, 서로 양립할 수 없는 버전 제약, 저장소에 없는 패키지 또는 아키텍처 불일치가 있으면 트랜잭션을 완료하지 못할 수 있다.
설치가 끝난 뒤 더 이상 어떤 패키지에서도 필요하지 않은 자동 설치 패키지는 고아 의존 패키지로 분류될 수 있다. 패키지 관리자는 사용자가 직접 설치한 패키지와 의존성으로 자동 설치된 패키지를 구분해 불필요한 항목을 정리할 수 있다.
의존성 해결은 저장소 전체가 일관된 정책으로 빌드되어 있다는 전제에 의존한다. 서로 다른 배포판이나 릴리스의 저장소를 혼합하면 같은 이름의 라이브러리가 서로 다른 ABI와 패키지 관계를 요구할 수 있어 해결 불가능한 충돌이나 부분 업그레이드가 발생할 수 있다.
소스 패키지와 바이너리 패키지
소스 패키지는 프로그램의 원본 소스 코드와 배포판에서 이를 빌드하는 규칙, 패치, 메타데이터를 포함한다. 바이너리 패키지는 소스 패키지를 특정 CPU 아키텍처와 배포판 환경에서 빌드하여 사용자가 바로 설치할 수 있게 만든 결과물이다.
Debian의 소스 패키지는 일반적으로 업스트림 소스 아카이브, Debian 패키징 변경 사항과 소스 설명 파일로 구성된다. 하나의 소스 패키지에서 실행 프로그램, 공유 라이브러리, 개발 헤더, 문서와 디버그 심볼 등 여러 바이너리 패키지가 생성될 수 있다.
RPM 계열에서는 .spec 파일이 패키지의 소스 위치, 빌드 의존성, 빌드·설치 단계, 파일 목록과 메타데이터를 정의한다. rpmbuild는 이 규칙을 사용해 소스 RPM과 설치 가능한 바이너리 RPM을 생성한다. RPM 프로젝트는 소스에서 소프트웨어를 빌드해 배포 가능한 패키지로 만드는 기능을 RPM의 핵심 기능으로 설명한다.[70]
Arch Linux의 PKGBUILD는 소스 위치, 체크섬, 의존성, 빌드 명령과 패키징 과정을 셸 스크립트 형태로 정의한다. Arch User Repository는 주로 완성된 바이너리 패키지가 아니라 사용자가 패키지를 빌드할 수 있는 PKGBUILD와 관련 파일을 공유한다.[71]
Gentoo의 ebuild도 소스 코드의 획득, 패치, 설정, 컴파일과 설치 방법을 정의한다. 사용자는 USE 플래그와 컴파일 옵션에 따라 같은 소스 패키지를 서로 다른 기능 구성으로 빌드할 수 있다.
바이너리 패키지는 사용자가 직접 컴파일할 필요가 없어 설치가 빠르고, 배포판이 시험한 동일한 빌드 결과를 여러 시스템에 제공할 수 있다. 배포판은 각 지원 아키텍처용 빌드 서버에서 패키지를 생성하고 자동 시험과 서명을 거쳐 저장소에 게시한다.
소스 패키지는 배포판이 어떤 수정과 빌드 설정을 적용했는지 확인하고 다른 아키텍처나 환경에서 다시 빌드할 수 있게 한다. 소스 공개 의무가 있는 자유 소프트웨어 라이선스를 준수하는 수단이기도 하다.
같은 소스 패키지에서 만든 바이너리라고 해도 빌드 환경, 컴파일러, 타임스탬프와 파일 정렬에 따라 결과가 달라질 수 있다. 재현 가능한 빌드는 동일한 소스와 빌드 지침으로 독립적으로 생성한 바이너리가 같은 결과를 내도록 하여 배포 서버의 변조 여부를 추가로 검증하려는 방식이다.[72]
범용 패키지 형식
전통적인 배포판 패키지는 시스템 라이브러리와 밀접하게 통합되므로 배포판과 릴리스마다 별도로 빌드해야 하는 경우가 많다. 이를 줄이기 위해 응용 프로그램과 필요한 라이브러리를 함께 묶거나 공통 런타임 위에서 실행하는 범용 패키지 방식이 등장했다.
Flatpak은 주로 그래픽 데스크톱 응용 프로그램을 배포하기 위한 체계다. 응용 프로그램은 샌드박스 안에서 실행되며, 공통 라이브러리는 별도의 런타임으로 공유한다. Flatpak은 응용 프로그램과 런타임을 리모트라고 부르는 저장소에서 설치하고 갱신한다.[73]
Flatpak 응용 프로그램은 호스트 배포판의 라이브러리를 직접 사용하는 대신 지정된 런타임과 응용 프로그램에 포함된 라이브러리를 기준으로 실행된다. 파일, 장치, 네트워크와 데스크톱 기능에 대한 접근은 샌드박스 권한과 포털을 통해 제어된다.
Flatpak 저장소는 응용 프로그램과 런타임의 여러 버전을 저장하고 변경된 데이터만 전달할 수 있는 OSTree 계열 구조를 사용한다. 사용자는 시스템 전체 또는 사용자 계정 단위로 리모트를 추가할 수 있으며, .flatpakrepo 파일에는 저장소 정보와 GPG 키가 포함될 수 있다.[74][75]
Snap은 Canonical이 개발한 응용 프로그램 및 서비스 배포 형식이다. Snap 패키지는 필요한 구성 요소와 메타데이터를 묶고 snapd를 통해 설치, 마운트, 실행과 자동 갱신을 관리한다.
Snap Store의 릴리스는 트랙, 위험도와 선택적인 브랜치로 구성된 채널에 게시된다. 사용자는 stable, candidate, beta, edge 등의 위험도 채널을 선택하고 이후 해당 채널의 새 리비전을 추적할 수 있다.[76]
대부분의 Snap은 strict confinement를 사용해 응용 프로그램의 시스템 접근을 제한하며, 필요한 자원은 인터페이스를 통해 연결한다. 전통 패키지와 유사한 접근 권한이 필요한 일부 응용 프로그램은 별도 승인이 필요한 classic confinement를 사용할 수 있다.[77]
AppImage는 하나의 응용 프로그램과 실행에 필요한 라이브러리를 단일 파일에 묶는 방식이다. 사용자는 파일을 내려받아 실행 권한을 부여한 뒤 별도의 시스템 설치 없이 실행할 수 있다. AppImage는 일반적인 Linux 배포판에서 실행하는 네이티브 바이너리를 제공하기 위해 시스템에서 충분히 최신이라고 가정하기 어려운 의존성을 함께 포함한다.[78]
AppImage는 중앙 패키지 관리자나 필수 저장소를 전제로 하지 않는다. 각 AppImage는 일반 파일이며 하나의 응용 프로그램과 필요한 의존성을 포함한다.[79] 이 단순성은 휴대와 직접 배포에 유리하지만, 업데이트·서명 검증·응용 프로그램 검색과 제거를 통일된 방식으로 관리하는 기능은 배포자나 별도의 관리 도구에 따라 달라진다.
범용 형식은 전통 패키지를 완전히 대체하기보다 역할을 분담한다. 커널, 부트로더, C 라이브러리, 초기화 시스템과 장치 드라이버처럼 운영체제와 긴밀하게 통합되는 구성 요소는 배포판 패키지로 관리되는 경우가 일반적이다. Flatpak, Snap과 AppImage는 배포판 릴리스와 독립적으로 갱신하려는 사용자 응용 프로그램에 주로 사용된다.
응용 프로그램에 라이브러리를 함께 포함하면 배포판마다 다시 빌드할 필요가 줄지만, 같은 라이브러리의 여러 복사본이 저장될 수 있다. 보안 취약점이 발견되었을 때 각 응용 프로그램이나 런타임을 별도로 갱신해야 할 수도 있으며, 샌드박스와 데스크톱 통합 방식에 따라 기능 차이가 생길 수 있다.
서드파티 저장소
서드파티 저장소는 배포판 공식 프로젝트가 아닌 소프트웨어 개발사, 하드웨어 제조사, 사용자 공동체 또는 개인이 운영하는 패키지 저장소다. 공식 저장소에 없는 프로그램, 더 최신인 버전, 독점 드라이버와 특정 제품용 패키지를 제공하는 데 사용된다.
서드파티 저장소도 공식 저장소와 같은 패키지 관리자에 등록될 수 있다. Debian 계열에서는 APT 저장소, Fedora 계열에서는 DNF 저장소, openSUSE에서는 Zypper 저장소 형태로 추가된다. 등록 후에는 해당 저장소의 패키지가 일반 검색과 의존성 해결, 시스템 업그레이드의 후보에 포함된다.
저장소를 추가할 때는 보통 저장소 주소와 서명 검증용 공개 키를 함께 등록한다. 공개 키를 신뢰하도록 설정하는 것은 해당 키 소유자가 서명한 패키지와 메타데이터를 시스템 패키지로 설치할 권한을 부여하는 것과 같다.
현대적인 APT 구성에서는 키가 어느 저장소에 사용될지 제한하는 방식이 권장된다. 하나의 키를 시스템 전체의 모든 저장소에 무제한으로 신뢰시키면, 해당 키를 가진 저장소가 다른 저장소의 패키지를 가장해 제공할 가능성이 생기기 때문이다.
서드파티 저장소는 공식 저장소보다 더 최신인 응용 프로그램을 제공할 수 있지만, 배포판의 패키지 정책과 시험 과정에 포함되지 않을 수 있다. 동일한 패키지 이름을 더 높은 버전으로 제공하면 공식 패키지를 대체하거나 핵심 라이브러리까지 연쇄적으로 갱신할 수 있다.
서로 다른 배포판 릴리스의 공식 저장소를 함께 사용하는 것도 사실상 위험한 서드파티 혼합과 비슷한 결과를 낼 수 있다. Debian 문서는 다른 Debian 버전이나 제3자 저장소를 추가하면 복구하기 어려운 방식으로 시스템이 손상될 수 있다고 경고한다.[80]
패키지 관리자는 저장소별 우선순위, 버전 고정과 패키지 제외 정책을 지원할 수 있다. APT의 pinning, DNF의 저장소 우선순위 및 패키지 제외, Zypper의 vendor 정책 등을 이용하면 특정 패키지만 서드파티에서 받고 나머지는 공식 저장소에 유지하도록 구성할 수 있다.
PPA, Fedora의 COPR, openSUSE Build Service의 사용자 저장소와 Arch User Repository는 사용자 또는 개발자가 공식 저장소 밖에서 패키지를 제공하는 대표적인 구조다. 다만 성격은 서로 다르다. PPA와 COPR은 빌드된 바이너리 패키지 저장소를 제공하는 반면, AUR는 주로 사용자가 직접 패키지를 만들기 위한 PKGBUILD와 관련 파일을 공유한다.
AUR의 패키지 빌드 파일은 사용자가 내용을 검토하고 로컬에서 빌드하는 구조지만, 빌드 과정에서 임의의 명령이 실행될 수 있다. 인기나 사용자 수가 많다는 사실만으로 공식 Arch 패키지와 같은 검토 및 지원 수준이 보장되지는 않는다.
소프트웨어 개발사가 직접 운영하는 저장소는 해당 프로그램을 배포판 릴리스보다 빠르게 갱신하고 공식 자동 업데이트를 제공할 수 있다. 반면 배포판 전체와의 통합 시험은 제한될 수 있으며, 저장소 운영이 종료되거나 서명 키와 배포 URL이 변경되면 사용자가 직접 설정을 갱신해야 한다.
서드파티 저장소를 사용할 때는 운영 주체, 지원하는 배포판과 릴리스, 서명 키의 출처, 갱신 빈도와 설치 과정에서 대체되는 패키지를 확인해야 한다. 사용하지 않는 저장소는 비활성화하거나 제거하고, 운영체제의 주 버전을 업그레이드할 때는 새 릴리스를 공식적으로 지원하는지 다시 확인하는 것이 일반적이다.
릴리스와 업데이트
Linux 배포판은 새로운 소프트웨어를 사용자에게 전달하는 시점과 방법에 따라 서로 다른 릴리스 모델을 사용한다. 특정 시점의 패키지를 묶어 번호가 붙은 버전을 발표하는 배포판이 있는 반면, 하나의 설치를 계속 갱신하여 별도의 대규모 버전 전환을 두지 않는 배포판도 있다.
릴리스 모델은 단순히 소프트웨어가 최신인지 오래되었는지를 나타내지 않는다. 패키지가 시험되는 기간, 호환성 유지 범위, 기능 변경이 허용되는 정도, 보안 패치의 제공 방식과 사용자가 수행해야 하는 업그레이드 절차를 함께 결정한다.
같은 배포판 안에서도 여러 모델이 병행될 수 있다. Ubuntu는 6개월 주기의 일반 릴리스와 2년 주기의 장기 지원 릴리스를 제공하고, openSUSE는 고정 릴리스 계열과 Tumbleweed·Slowroll 같은 롤링 계열을 함께 운영한다. 서버·데스크톱·임베디드 제품에 서로 다른 지원 정책을 적용하는 프로젝트도 있다.
고정 릴리스
고정 릴리스 또는 포인트 릴리스 모델은 특정 시점의 커널, 시스템 라이브러리와 응용 프로그램을 하나의 배포판 버전으로 확정하여 발표하는 방식이다. Debian 13, Ubuntu 24.04, Fedora 43과 같은 번호 또는 이름이 배포판의 특정 릴리스를 나타낸다.
개발 과정에서는 새 기능과 패키지 버전을 받아들이는 기간 뒤에 기능 동결, 오류 수정, 통합 시험과 출시 후보 단계가 이어진다. 정식 릴리스가 발표된 뒤에는 일반적으로 핵심 패키지의 주 버전을 크게 변경하기보다 보안 수정과 중요한 오류 수정을 현재 버전에 적용한다.
Debian의 Stable은 Testing에서 충분히 검증된 패키지 집합을 동결하고 정식 릴리스로 발표한다. 정식 출시 뒤에는 안정성과 호환성을 유지하기 위해 새 기능보다 보안 문제와 중대한 오류의 수정에 중점을 둔다.[81]
고정 릴리스에서 포인트 릴리스는 기존 배포판을 완전히 새로 설계한 버전이 아니라, 출시 뒤 축적된 보안 수정과 오류 수정, 설치 이미지 갱신을 모은 중간 판을 의미하는 경우가 많다. Debian 13.1이나 Ubuntu 24.04.1 같은 버전은 같은 주 릴리스의 지원 범위에 속한다.
새로운 주 릴리스로 이동할 때는 일반 패키지 업데이트와 구분되는 배포판 업그레이드 절차가 필요할 수 있다. 이 과정에서는 저장소 주소가 새 릴리스를 가리키도록 변경되고, 핵심 라이브러리와 패키지 전체가 새로운 버전으로 교체된다.
고정 릴리스는 특정 버전의 API와 동작을 장기간 유지하기 쉬우므로 기업 서버, 개발 기준 환경과 장기간 운영되는 시스템에 적합하다. 반면 릴리스 시점이 지난 뒤에는 일부 응용 프로그램과 개발 도구의 버전이 최신 업스트림보다 오래될 수 있다.
배포판은 이러한 차이를 줄이기 위해 특정 패키지를 역이식하거나, 별도의 백포트 저장소, 하드웨어 지원 커널과 범용 응용 프로그램 패키지를 제공하기도 한다. 이 경우에도 기본 시스템의 핵심 구성은 해당 고정 릴리스의 기준을 유지한다.
롤링 릴리스
롤링 릴리스는 일정한 간격으로 전체 배포판의 새 주 버전을 발표하는 대신, 개별 패키지와 시스템 구성 요소를 지속적으로 갱신하는 방식이다. 사용자는 배포판을 한 번 설치한 뒤 정기적인 전체 시스템 업데이트를 통해 현재 상태를 유지한다.
Arch Linux는 대표적인 롤링 릴리스 배포판이다. Arch는 하나의 설치를 계속 갱신하며, 특정 배포판 버전에서 다음 버전으로 별도의 업그레이드를 수행할 필요가 없는 구조를 사용한다.[82]
Arch가 매달 새로운 설치 ISO 이미지를 공개하더라도 이는 새로운 운영체제 버전의 발표와 같지 않다. 월별 ISO는 해당 시점의 최신 커널과 기본 패키지를 담은 설치 매체이며, 기존 설치 시스템은 일반 패키지 업데이트를 통해 같은 상태에 도달할 수 있다.[83]
롤링 릴리스에서도 패키지가 업스트림에서 공개되는 즉시 검증 없이 사용자에게 전달되는 것은 아니다. 배포판 유지 관리자는 패키지를 빌드하고 시험 저장소나 자동화된 시험을 거친 뒤 안정 저장소로 이동시킨다. 다만 고정 릴리스처럼 전체 배포판의 기능을 장기간 동결하지 않는다.
라이브러리의 ABI, 컴파일러, 그래픽 스택과 초기화 시스템 같은 핵심 구성 요소도 지속적으로 변경될 수 있으므로, 롤링 배포판에서는 부분 업데이트보다 전체 시스템을 일관되게 갱신하는 것이 중요하다. 저장소 일부만 갱신하면 새 라이브러리를 요구하는 프로그램과 이전 라이브러리에 의존하는 프로그램이 혼재할 수 있다.
롤링 릴리스의 설치 시점과 현재 상태 사이에 별도의 주 버전 경계가 없더라도 중요한 수동 조치가 발생할 수 있다. 파일 형식 변경, 패키지 교체, 부트 방식 전환과 사용자 설정의 마이그레이션이 필요한 경우 배포판 공지나 뉴스에서 절차를 안내한다.
이 모델은 최신 커널과 개발 도구, 데스크톱 환경을 빠르게 사용할 수 있다는 특성이 있다. 동시에 변화가 연속적으로 들어오므로 장기간 업데이트하지 않은 시스템을 한 번에 갱신하거나, 공지를 확인하지 않고 핵심 변경을 적용할 때 추가 조정이 필요할 수 있다.
반롤링 릴리스
반롤링 릴리스, 느린 롤링 릴리스 또는 단계적 롤링 릴리스는 Linux 생태계 전체에서 하나의 엄격한 규격으로 정의된 용어가 아니다. 일반적으로 롤링 릴리스처럼 시스템을 지속적으로 갱신하되, 상류 또는 더 빠른 저장소에서 패키지를 일정 기간 보류하고 추가 시험을 거쳐 묶음 단위로 전달하는 방식을 가리킨다.
이 방식에서는 별도의 주 버전 업그레이드 없이 최신 패키지로 이동할 수 있지만, 가장 빠른 롤링 저장소보다 업데이트 주기가 느리다. 기능 업데이트는 일정한 간격으로 모아서 제공하고 보안 수정과 중요한 오류 수정은 중간에도 전달할 수 있다.
openSUSE Slowroll은 openSUSE Tumbleweed를 기반으로 패키지를 더 느리게 전달하는 롤링 배포판이다. 주요 패키지 갱신을 대략 월 단위로 통합하면서 오류와 보안 수정은 지속적으로 제공하는 방식을 목표로 한다.[84]
Slowroll은 고정 릴리스인 openSUSE Leap처럼 특정 버전을 장기간 동결하지 않는다. 시스템 전체가 Tumbleweed를 따라 계속 전진하지만, 새 패키지가 Slowroll에 도달하기 전 추가적인 시간과 시험 구간을 둔다.
Manjaro도 Arch Linux 패키지를 자체 저장소로 가져온 뒤 Unstable, Testing과 Stable 등의 분기에서 단계적으로 이동시키는 구조를 사용한다. 사용자는 롤링 방식으로 시스템을 갱신하지만 Arch 공식 저장소와 같은 시점에 모든 패키지를 받지는 않는다.
반롤링 방식은 빠른 롤링과 고정 릴리스 사이에서 최신성과 시험 기간의 균형을 조정한다. 그러나 “반롤링”이라는 이름만으로 실제 정책을 판단하기는 어렵다. 배포판마다 패키지 보류 기간, 저장소 분기, 보안 수정의 우선순위와 대규모 변경의 전달 방식이 다르기 때문이다.
일부 배포판은 기본 시스템은 고정하고 웹 브라우저, 커널, 개발 도구와 데스크톱 환경의 일부만 지속적으로 갱신한다. 이러한 혼합 방식도 넓은 의미에서 부분 롤링으로 불리기도 하지만, 전체 시스템이 롤링되는 Slowroll이나 Manjaro의 방식과는 구분할 필요가 있다.
장기 지원 릴리스
장기 지원 릴리스(Long-Term Support, LTS)는 일반 릴리스보다 긴 기간 동안 보안 수정과 중요한 유지 보수를 제공하도록 지정된 고정 릴리스다. LTS는 장기간 같은 운영체제 기반을 유지해야 하는 서버, 기업 환경, 임베디드 장치와 소프트웨어 제품의 기준 플랫폼으로 주로 사용된다.
Ubuntu는 2년마다 LTS를 발표하며, 각 LTS에 기본 5년의 표준 보안 유지 보수를 제공한다. Canonical의 추가 서비스와 상품을 이용하면 일부 패키지와 시스템에 대해 더 긴 보안 유지 기간을 적용할 수 있다.[85]
LTS 기간에 모든 패키지가 처음 출시된 기능과 버전으로 완전히 고정되는 것은 아니다. 보안 문제를 수정하려면 패치를 이전 버전으로 역이식하거나, 유지가 어려운 소프트웨어를 더 새로운 안정 버전으로 교체해야 할 수 있다. 하드웨어 지원을 위해 새 커널과 그래픽 스택을 제공하는 경우도 있다.
Debian의 릴리스 수명 주기는 일반적으로 처음 약 3년 동안 Debian 프로젝트의 정규 지원을 받고, 이후 약 2년 동안 Debian LTS 팀이 지원을 이어가는 방식으로 총 5년을 구성한다.[86]
Debian LTS 단계에서는 지원되는 CPU 아키텍처나 패키지 범위가 정규 지원 기간보다 줄어들 수 있다. 특정 웹 브라우저, 개발 도구와 복잡한 응용 프로그램은 장기간 안전하게 유지하기 어려워 전체 기간 동안 동일한 지원을 받지 못할 수도 있다.
장기 지원은 기능 변화가 적다는 의미이지 모든 소프트웨어의 상태가 처음부터 끝까지 완전히 같다는 의미는 아니다. 배포판은 ABI와 동작의 안정성을 최대한 유지하면서 취약점 수정, 인증서 갱신, 시간대 데이터와 하드웨어 지원 등 운영에 필요한 변경을 계속 제공한다.
LTS라는 이름과 기간은 배포판마다 다르다. 어떤 프로젝트는 공동체가 지원하고, 어떤 프로젝트는 기업과의 유료 계약으로 지원 기간을 연장한다. 따라서 LTS를 선택할 때는 숫자로 표시된 전체 기간뿐 아니라 지원 대상 저장소, 아키텍처와 패키지 범위를 함께 확인해야 한다.
원자적 업데이트
원자적 업데이트는 운영체제 변경을 여러 개의 독립된 파일 작업으로 노출하는 대신, 완전한 이전 상태 또는 완전한 새 상태 가운데 하나로 전환되도록 적용하는 방식이다. 업데이트가 중간에 실패하더라도 절반만 갱신된 시스템을 실행하지 않는 것이 핵심이다.
전통적인 패키지 업데이트는 실행 중인 루트 파일 시스템의 파일을 차례로 교체한다. 업데이트 도중 전원이 끊기거나 저장 장치 오류가 발생하면 일부 패키지만 새 버전으로 변경될 수 있다. 패키지 관리자는 이를 복구할 수 있는 기능을 제공하지만, 시스템 상태 전체의 전환이 하나의 원자적 작업인 것은 아니다.
OSTree는 완전한 파일 시스템 트리를 버전이 지정된 객체로 관리하고, 여러 부팅 가능한 배포 상태 사이를 원자적으로 전환한다. 패키지 관리자를 직접 대체하기보다 빌드 서버에서 패키지로 운영체제 트리를 조립하고 클라이언트에 배포하는 체계를 제공한다.[87]
OSTree 기반 시스템은 새 파일 시스템 트리를 현재 시스템과 병렬로 준비하고 부트로더의 다음 부팅 대상을 변경한다. 새 배포 상태가 정상적으로 동작하지 않으면 이전 트리로 되돌아갈 수 있다. 콘텐츠 주소 기반 저장소를 사용하므로 기존 버전과 같은 파일은 중복 저장하지 않고 변경된 데이터만 전송할 수 있다.
rpm-ostree는 OSTree의 이미지형 운영체제 배포 방식과 RPM 패키지 생태계를 결합한다. 서버나 클라이언트에서 RPM 패키지를 이용해 새로운 시스템 트리를 조립하고, 트랜잭션형 업그레이드와 롤백을 제공한다.[88]
Fedora의 원자적 데스크톱과 Fedora CoreOS 등은 이러한 계열의 기술을 사용해 기본 운영체제를 배포 단위로 갱신한다. 응용 프로그램과 개발 환경은 Flatpak이나 컨테이너로 분리하고, 호스트 운영체제는 재현 가능한 이미지에 가깝게 관리한다.
원자적 업데이트는 OSTree에만 한정되지 않는다. A/B 파티션, 파일 시스템 스냅샷, 부팅 가능한 컨테이너 이미지와 장치용 트랜잭션 시스템도 같은 목적을 다른 방식으로 구현할 수 있다. 한 파티션을 실행하는 동안 다른 파티션에 새 시스템을 기록하고, 검증이 끝난 뒤 부팅 대상을 바꾸는 방식이 대표적이다.
원자적이라는 표현은 시스템이 실행되는 동안 어떤 파일도 바뀌지 않는다는 뜻이 아니다. 사용자 데이터, 로그와 일부 설정은 계속 기록될 수 있다. 원자성이 적용되는 범위는 배포판에 따라 기본 운영체제 트리, 부팅 이미지 또는 특정 패키지 집합으로 제한된다.
보안 업데이트
보안 업데이트는 운영체제와 패키지에서 발견된 취약점을 수정하거나 공격 가능성을 줄이는 변경이다. 배포판 보안 팀은 공개된 취약점, 업스트림 프로젝트의 수정 사항과 자체 보고를 추적하고, 지원 중인 릴리스에 적용할 패치를 준비한다.
고정 릴리스에서는 최신 업스트림 버전 전체를 가져오는 대신 취약점을 수정한 변경만 현재 패키지 버전에 역이식하는 방식이 흔하다. 이를 통해 기능과 ABI 변화를 줄이면서 보안 문제를 해결할 수 있다.
역이식된 패키지는 표시되는 주 버전이 오래되어 보이더라도 최신 보안 수정이 포함될 수 있다. 따라서 배포판 패키지의 안전성을 판단할 때는 업스트림 버전 번호만 비교하기보다 배포판의 패키지 리비전과 보안 공지를 확인해야 한다.
롤링 릴리스는 취약점이 수정된 새로운 업스트림 버전을 일반 업데이트 흐름으로 제공하는 경우가 많다. 다만 수정 버전의 통합과 시험에 시간이 필요하며, 긴급한 문제에는 별도 패치가 우선 적용될 수 있다.
보안 업데이트에는 커널, 시스템 라이브러리와 네트워크 서비스뿐 아니라 웹 브라우저, 문서 처리기, 펌웨어와 언어별 라이브러리도 포함된다. 배포판 저장소 밖에서 직접 설치한 프로그램과 서드파티 저장소의 패키지는 배포판 보안 팀의 지원 대상이 아닐 수 있다.
취약점 하나가 지원 중인 모든 릴리스와 아키텍처에 영향을 주는 것은 아니다. 해당 기능이 빌드에서 비활성화되어 있거나, 취약한 코드가 포함되지 않았거나, 다른 보안 완화 기능이 적용된 경우 배포판은 영향을 받지 않는 것으로 판정할 수 있다.
자동 업데이트를 활성화하면 보안 수정이 빠르게 적용될 수 있지만, 커널과 핵심 라이브러리의 변경은 재부팅이나 서비스 재시작이 필요할 수 있다. 패키지가 설치되었다고 실행 중인 이전 코드가 즉시 사라지는 것은 아니므로 배포판은 재부팅 또는 재시작 필요 여부를 안내하기도 한다.
보안 지원은 배포판 릴리스가 지원되는 동안 제공된다. 다만 하나의 릴리스 안에서도 저장소 영역, 패키지와 아키텍처마다 보장 범위가 다를 수 있으므로, 장기 운영 시스템에서는 배포판의 공식 보안 정책을 확인해야 한다.
지원 종료
지원 종료(End of Life, EOL)는 특정 배포판 릴리스에 대한 정기 업데이트와 공식 지원이 끝나는 시점을 의미한다. 지원 종료 뒤에는 일반적인 오류 수정뿐 아니라 새로운 보안 취약점에 대한 패키지도 제공되지 않는 것이 원칙이다.
Fedora는 각 릴리스를 대략 13개월 동안 지원하며, 새로운 N 버전이 출시된 뒤 약 4주 후 N-2 버전이 지원 종료에 도달하는 수명 주기를 사용한다.[89]
지원 종료된 시스템이 즉시 작동을 멈추는 것은 아니다. 설치된 프로그램과 기존 서비스는 계속 실행될 수 있지만, 새로 발견된 취약점과 하드웨어·프로토콜 변화에 대응하는 공식 패키지를 받지 못한다.
배포판은 지원 종료된 저장소를 일반 미러에서 기록 보관 서버로 옮길 수 있다. 이 저장소는 이전 패키지를 보존하기 위한 것이며, 최신 보안 상태를 제공하는 저장소는 아니다. 보관 저장소를 계속 사용할 수 있다는 사실은 해당 릴리스가 지원된다는 의미가 아니다.
지원 종료 전에 사용자는 다음 지원 릴리스로 배포판 업그레이드를 수행하거나 새 시스템으로 마이그레이션해야 한다. 여러 주 버전을 건너뛰는 업그레이드를 지원하지 않는 배포판도 있으므로, 공식적으로 허용된 경로와 중간 버전을 확인해야 한다.
장기 지원 단계가 끝난 뒤 기업용 연장 지원이나 공동체 기반의 추가 유지 보수가 제공될 수 있다. 이 경우에도 기본 지원과 동일한 패키지·아키텍처 범위를 보장하지 않을 수 있으며, 별도의 계약이나 저장소 설정이 필요할 수 있다.
파생 배포판의 지원 기간은 기반 배포판과 일치하지 않을 수 있다. 기반 배포판이 아직 지원 중이어도 파생판 프로젝트가 자체 저장소와 설치 이미지의 유지 보수를 중단할 수 있고, 반대로 기반 릴리스의 공식 지원이 끝난 뒤 파생판이 일부 패키지를 자체적으로 더 오래 유지할 수도 있다.
지원 종료는 커널 하나의 수명이 아니라 배포판 릴리스 전체의 수명과 관련된다. 장기 지원 Linux 커널을 사용하고 있더라도 배포판의 사용자 공간, 패키지 저장소와 보안 팀 지원이 종료되었다면 시스템 전체가 공식적으로 유지되는 것은 아니다.
장기간 운영할 시스템에서는 설치 당시의 최신성보다 예정된 지원 종료일, 다음 릴리스로의 업그레이드 경로와 사용 중인 패키지의 실제 지원 범위를 함께 고려해야 한다.
개발과 유지 관리
Linux 배포판의 개발은 Linux 커널, 시스템 라이브러리, 셸, 데스크톱 환경과 응용 프로그램을 하나의 운영체제로 통합하고 지속적으로 갱신하는 작업이다. 배포판 프로젝트는 모든 소프트웨어를 직접 개발하기보다 여러 업스트림 프로젝트의 소스 코드를 받아 패키지로 만들고, 배포판 전체에서 함께 동작하도록 조정한다.
일반적인 패키지 변경은 업스트림 릴리스 확인, 패키지 정의와 패치 갱신, 격리된 환경에서의 빌드, 자동 시험, 검토, 저장소 반영과 사용자 배포의 순서로 진행된다. 보안 문제나 심각한 오류가 발견되면 같은 흐름을 단축하거나 별도의 긴급 업데이트 절차를 사용할 수 있다.
배포판 유지 관리에는 패키지 개발자뿐 아니라 릴리스 공학, 빌드 인프라, 품질 보증, 보안, 번역, 문서화, 미러와 웹 서비스 운영을 담당하는 여러 팀이 참여한다. 프로젝트에 따라 이러한 역할을 자원봉사 공동체가 수행하기도 하고, 후원 기업이 전담 개발자와 서버 자원을 제공하기도 한다.
업스트림 프로젝트와의 관계
업스트림 프로젝트는 배포판보다 앞선 위치에서 원본 소프트웨어를 개발하는 프로젝트를 뜻한다. Linux 커널, GNU C Library, systemd, GNOME, KDE Plasma, Firefox와 같은 프로젝트가 이에 해당한다.
배포판은 업스트림이 발표한 소스 코드를 가져와 자신이 지원하는 CPU 아키텍처, 컴파일러와 시스템 정책에 맞게 빌드한다. 파일 설치 위치, 기본 설정, 선택 기능과 다른 패키지에 대한 의존 관계도 배포판의 기준에 맞게 조정한다.
업스트림 소프트웨어가 다른 배포판 패키지와 충돌하거나 특정 환경에서 빌드되지 않으면 배포판은 별도의 패치를 적용할 수 있다. 이 패치는 배포판에만 유지되기도 하지만, 일반적으로는 원인을 수정한 뒤 업스트림에 제출하는 것이 선호된다.
Debian은 패키지에 포함된 패치가 업스트림에 전달되었는지, 관련 버그 보고가 어디에 있는지와 패치를 배포판에만 유지하는 이유를 기록하도록 권장한다. 패치가 업스트림에 포함되면 이후 릴리스에서 배포판이 같은 변경을 별도로 관리해야 하는 부담이 줄어든다.[90]
배포판은 업스트림의 새 릴리스를 항상 즉시 채택하지 않는다. 고정 릴리스에서는 기능과 ABI의 안정성을 유지하기 위해 기존 버전을 계속 사용하면서 필요한 오류와 보안 수정만 역이식할 수 있다. 롤링 릴리스에서도 새 버전은 빌드와 통합 시험을 거친 뒤 저장소에 반영된다.
문제의 원인이 배포판의 패치나 설정에 있으면 배포판의 버그 추적기에서 해결한다. 원본 소프트웨어 자체의 문제라면 업스트림 버그 추적기로 전달하고 두 보고서를 연결할 수 있다. 이러한 과정은 동일한 문제가 여러 배포판에서 각각 수정되는 중복을 줄인다.
배포판은 여러 업스트림 프로젝트가 실제 운영체제 안에서 만나는 통합 지점이기도 하다. 하나의 라이브러리 변경이 수백 개의 응용 프로그램 빌드와 실행에 영향을 줄 수 있으며, 새 컴파일러나 커널이 사용자 공간 전체에서 문제를 일으키는지도 배포판 규모의 시험을 통해 확인된다.
패키지 유지 관리자
패키지 유지 관리자는 특정 소프트웨어를 배포판 저장소에 포함하고 지속적으로 관리하는 사람 또는 팀이다. 유지 관리자는 새 업스트림 릴리스를 추적하고, 패키지 빌드 정의와 패치를 갱신하며, 버그와 보안 문제를 처리한다.
유지 관리자는 소스 코드뿐 아니라 패키지의 이름, 설명, 라이선스, 빌드 의존성, 실행 의존성, 충돌 관계와 설치 스크립트를 관리한다. 하나의 소스 패키지에서 실행 프로그램, 공유 라이브러리, 개발 헤더, 문서와 디버그 기호를 별도의 바이너리 패키지로 나눌 수도 있다.
Debian에서는 패키지 관리자가 패키지를 Debian 정책에 맞게 유지하고, 버그 보고와 새 버전 업로드를 처리한다. 직접 업로드 권한이 없는 기여자는 권한이 있는 Debian 개발자의 검토와 후원을 받아 패키지를 아카이브에 올릴 수 있다.[91]
Arch Linux의 공식 저장소 패키지는 프로젝트의 패키저와 개발자가 관리한다. 패키지는 PKGBUILD에 소스 위치, 버전, 의존성, 빌드와 설치 절차를 기록하며, makepkg가 이 정의를 읽어 설치 가능한 패키지를 생성한다.[92]
AUR은 공동체가 작성한 PKGBUILD를 공유하는 저장소다. AUR은 미리 빌드된 공식 패키지를 제공하는 저장소가 아니며, 사용자가 빌드 정의를 검토한 뒤 직접 소스에서 패키지를 생성하는 구조다.[93]
하나의 관리자가 여러 패키지를 담당할 수도 있고, 데스크톱 환경이나 프로그래밍 언어 생태계처럼 서로 밀접한 패키지 묶음을 팀이 공동으로 관리할 수도 있다. 팀 유지 관리는 특정 담당자가 활동을 중단했을 때 패키지가 즉시 방치되는 상황을 줄인다.
관리자가 더 이상 패키지를 유지할 수 없으면 다른 기여자에게 인계하거나 고아 패키지로 표시한다. 새 관리자가 나타나지 않고 소프트웨어가 더 이상 사용되지 않거나 안전하게 유지하기 어렵다면 공식 저장소에서 제거될 수 있다.
패키지 유지 관리자는 자신이 담당하는 패키지를 자유롭게 변경할 수 있지만, 배포판 전체의 패키징 정책과 릴리스 동결, 보안 정책을 따라야 한다. 핵심 라이브러리처럼 다른 패키지에 큰 영향을 주는 변경은 관련 팀과의 조정과 대규모 재빌드가 필요하다.
빌드 시스템
배포판의 빌드 시스템은 소스 패키지와 빌드 정의를 받아 특정 CPU 아키텍처용 바이너리 패키지를 생성한다. 빌드 결과, 로그, 의존성과 서명 정보는 저장되어 이후 검토와 문제 분석에 사용된다.
공식 패키지는 일반적으로 유지 관리자의 개인 컴퓨터에서 생성한 바이너리를 그대로 배포하지 않는다. 중앙 빌드 서버가 깨끗하고 통제된 환경을 만들고, 선언된 빌드 의존성만 설치한 뒤 패키지를 다시 생성한다.
격리된 빌드는 유지 관리자의 컴퓨터에 우연히 설치된 파일이나 라이브러리가 패키지에 포함되는 것을 방지한다. 패키지가 선언하지 않은 프로그램에 의존해 빌드되는 문제도 비교적 쉽게 발견할 수 있다.
Fedora는 중앙 빌드 시스템으로 Koji를 사용한다. 패키지 소스와 빌드 정의가 제출되면 Koji가 격리된 빌드 루트를 구성하고 RPM 패키지를 만든다. 생성된 결과는 이후 시험과 업데이트 관리 절차로 전달된다.[94]
openSUSE와 SUSE는 Open Build Service를 사용한다. OBS는 소스에서 여러 배포판과 CPU 아키텍처용 바이너리 패키지를 자동으로 만들며, 패키지 분기, 제출 요청과 검토 기능도 제공한다.[95]
Arch Linux에서는 PKGBUILD가 패키지의 빌드 정보를 담고, makepkg가 소스를 내려받아 컴파일한 뒤 pkg.tar.zst 패키지를 생성한다. 생성된 패키지는 pacman으로 설치할 수 있다.[96]
빌드 시스템은 개별 패키지뿐 아니라 설치 ISO, 라이브 시스템, 클라우드 이미지, 컨테이너 이미지와 원자적 운영체제 트리도 생성할 수 있다. 배포판은 같은 패키지 저장소를 바탕으로 서로 다른 설치 대상과 제품 이미지를 자동 조립한다.
패키지 의존성이 변경되면 영향을 받는 다른 패키지를 다시 빌드해야 할 수 있다. C 라이브러리, 컴파일러, Python이나 Perl처럼 생태계 전체에 영향을 주는 구성 요소가 바뀌면 수백 개 또는 수천 개의 패키지가 연쇄적으로 재빌드된다.
재현 가능한 빌드는 같은 소스와 빌드 환경에서 동일한 바이너리 결과를 다시 만들 수 있도록 하는 작업이다. 재현 가능한 패키지는 공식 배포물이 공개된 소스에서 생성되었는지 독립적으로 검증할 수 있게 한다.[97]
Arch Linux를 비롯한 여러 배포판은 공식 패키지를 다시 빌드해 결과를 비교하고, 시간 정보, 임시 경로, 파일 정렬과 같은 비결정적 요소를 제거하는 작업을 진행한다.[98]
자동화된 시험
자동화된 시험은 패키지가 성공적으로 컴파일되었다는 사실뿐 아니라 설치, 실행, 업그레이드와 다른 패키지와의 연동이 정상적으로 이루어지는지를 확인한다.
패키지 빌드 중에는 업스트림 프로젝트가 제공하는 단위 시험과 통합 시험을 실행할 수 있다. 시험이 실패하면 패키지 빌드 자체를 실패로 처리하거나 유지 관리자가 원인을 검토할 때까지 저장소 반영을 중단한다.
배포판은 완성된 바이너리 패키지를 실제 시스템 환경에 설치한 뒤 시험하기도 한다. 서비스가 시작되는지, 명령이 예상한 결과를 내는지, 라이브러리 변경 뒤 이를 사용하는 다른 프로그램이 계속 동작하는지 등을 확인한다.
Debian의 autopkgtest는 설치된 패키지에 대한 시험을 실행하며, 새 패키지가 Debian Testing으로 이동할 때 자신과 역의존 패키지의 시험 결과를 판단 자료로 사용한다.[99]
Fedora에서는 패키지가 Koji에서 빌드된 뒤 Bodhi를 통해 정식 릴리스 업데이트로 관리된다. 자동 시험 결과, 안정화 기간과 사용자 피드백을 바탕으로 시험 상태의 업데이트를 안정 저장소로 이동시킨다.[100]
openSUSE가 사용하는 openQA는 가상 머신에서 설치 프로그램, 부팅, 데스크톱과 응용 프로그램을 실제로 조작하고 화면 결과를 비교한다. openSUSE Tumbleweed에서는 패키지 집합이 배포 가능한 스냅샷인지 판단하는 데 사용된다.[101]
자동 시험은 설치 이미지가 실제로 부팅되는지, 기존 릴리스에서 새 릴리스로 업그레이드할 수 있는지와 주요 데스크톱·서버 기능이 동작하는지도 확인할 수 있다. 단일 패키지 시험과 배포판 전체 시험은 서로 다른 문제를 찾아낸다.
모든 하드웨어와 사용자 구성을 자동으로 재현할 수는 없으므로 시험 저장소, 베타 릴리스와 사용자 버그 보고도 함께 사용된다. 자동 시험을 통과한 패키지라도 특정 그래픽 카드, 파일 시스템이나 언어 설정에서는 별도의 문제가 나타날 수 있다.
부팅, 설치, 패키지 관리자와 보안 기능 같은 핵심 경로의 오류는 정식 릴리스를 막는 차단 문제로 지정될 수 있다. 영향이 제한적인 오류는 알려진 문제로 문서화하고 이후 업데이트에서 수정할 수 있다.
보안 대응
배포판의 보안 대응은 취약점 정보를 수집하고, 어떤 패키지와 릴리스가 영향을 받는지 분석하며, 수정된 패키지를 빌드·시험한 뒤 사용자에게 배포하는 과정이다.
취약점이 보고되면 보안 팀과 패키지 관리자는 문제가 발생하는 업스트림 버전과 코드 경로를 확인한다. 동일한 버전이라도 배포판의 빌드 옵션이나 패치에 따라 영향을 받지 않을 수 있으므로 단순한 버전 비교만으로 판단하지 않는다.
고정 릴리스에서는 새로운 업스트림 버전 전체를 도입하기보다 취약점을 수정하는 변경만 기존 버전에 역이식하는 경우가 많다. 이를 통해 기존 동작과 ABI를 유지하면서 보안 문제를 해결할 수 있다.
Debian 보안 팀은 지원 중인 안정 릴리스의 취약점을 추적하고 Debian Security Advisory를 발표한다. 권고문에는 영향을 받는 패키지와 릴리스, 문제의 내용과 수정된 패키지 버전이 기록된다.[102]
Fedora에서는 보안 버그가 일반 버그 추적 및 업데이트 절차와 연결되며, 패키지 관리자가 수정 빌드를 만들어 Bodhi에 제출한다. 심각도와 영향 범위에 따라 업데이트 시험과 배포 우선순위가 조정된다.[103]
취약점 공개 전에 조율이 필요한 경우 업스트림, 여러 배포판과 연구자가 제한된 채널에서 수정과 공개 시점을 협의할 수 있다. 공개와 동시에 수정 패키지를 제공하면 취약점 정보만 먼저 알려지는 시간을 줄일 수 있다.
보안 대응은 프로그램 코드만 대상으로 하지 않는다. 저장소 서명 키, 개발자 계정, 빌드 서버, 미러와 업데이트 배포 인프라도 보호해야 한다. 공격자가 이러한 공급망을 장악하면 정상적으로 서명된 악성 패키지를 배포할 수 있기 때문이다.
Arch Linux의 pacman은 패키지의 출처와 무결성을 확인하기 위해 OpenPGP 서명을 사용한다. 공식 패키지는 프로젝트의 신뢰 체계에 속한 키로 검증된다.[104]
보안 수정 패키지를 설치해도 실행 중인 이전 프로세스가 즉시 새 코드로 바뀌는 것은 아니다. 커널은 재부팅이 필요할 수 있고, 공유 라이브러리와 서비스를 사용하는 프로세스는 다시 시작해야 수정된 코드를 사용한다.
프로젝트 거버넌스
배포판의 거버넌스는 기술적 방향, 릴리스 정책, 자원과 프로젝트 규칙을 누가 어떤 절차로 결정하는지를 의미한다. 배포판마다 전체 개발자 투표, 선출된 위원회, 기업 주도 또는 소규모 핵심 팀 중심 구조가 사용된다.
Debian은 프로젝트 헌법을 가진 공동체 배포판이다. Debian 개발자는 프로젝트 지도자를 선출하고 일반 결의에 투표하며, 프로젝트 지도자, 기술 위원회, 프로젝트 서기와 위임받은 팀이 정해진 권한을 행사한다.[105]
Debian의 개별 패키지 결정은 일반적으로 담당 관리자에게 맡겨진다. 여러 패키지나 프로젝트 전체에 영향을 주는 기술적 분쟁이 합의로 해결되지 않으면 기술 위원회가 결정을 내릴 수 있다.
Fedora는 공동체 프로젝트이면서 Red Hat의 후원을 받는다. Fedora Council은 프로젝트의 전략과 공동체 운영을 담당하고, Fedora Engineering Steering Committee는 기술 정책, 패키징 규칙과 주요 기능 변경을 다룬다.[106][107]
Arch Linux는 개발자, 패키지 유지 관리자와 여러 프로젝트 팀으로 구성된다. 패키징, 인프라와 프로젝트 운영에 관한 결정은 담당 팀과 프로젝트 내부의 합의 및 투표 절차를 통해 이루어진다.
openSUSE는 공동체 구성원이 선출하는 openSUSE Board와 여러 릴리스·패키징·인프라 팀을 중심으로 운영된다. SUSE는 개발 인력과 인프라를 지원하지만 openSUSE에는 별도의 공동체 조직과 참여 구조가 존재한다.
기업이 직접 운영하는 배포판에서는 회사가 제품 지원 기간, 인증, 상용 서비스와 릴리스 일정을 결정할 수 있다. 그러나 포함된 소프트웨어 대부분은 외부 업스트림 프로젝트에서 개발되므로 기업의 제품 결정과 자유 소프트웨어 공동체의 기술 방향이 함께 작용한다.
배포판의 법적 자산과 상표는 프로젝트 자체, 비영리 단체 또는 후원 기업이 보유할 수 있다. 기술적 결정권, 재정 관리와 상표 소유권이 반드시 같은 조직에 속하는 것은 아니다.
거버넌스 구조는 프로젝트의 변화 속도와 책임 분배에 영향을 준다. 소규모 핵심 팀은 빠르게 방향을 바꿀 수 있고, 광범위한 공개 토론과 투표를 사용하는 프로젝트는 여러 이해관계를 반영하는 대신 결정에 더 긴 시간이 필요할 수 있다.
커뮤니티와 기업
Linux 배포판에서 공동체와 기업은 서로 분리된 영역이라기보다 상호 의존적인 관계를 형성한다. 자원봉사자가 패키지, 번역, 문서와 지원에 기여하고, 기업 소속 개발자는 근무 시간에 같은 프로젝트의 코드와 인프라를 유지할 수 있다.
Debian과 Arch Linux는 특정 기업의 제품으로 운영되지 않는 공동체 중심 배포판이다. 그러나 미러 서버, 행사, 장비, 법률과 재정 지원에는 여러 기업과 비영리 단체의 후원이 사용될 수 있다.
Fedora와 Red Hat Enterprise Linux는 공동체 배포판과 기업용 배포판이 연결된 대표적인 구조다. Fedora에서 새로운 기술이 공개적으로 통합되고, 선택된 결과가 CentOS Stream과 Red Hat Enterprise Linux의 개발에 반영된다.
openSUSE와 SUSE Linux Enterprise도 빌드 인프라, 코드와 개발자를 공유한다. openSUSE에서 시험된 기술이 기업용 제품에 반영될 수 있고, SUSE가 개발한 구성 요소가 다시 공동체에 제공되기도 한다.
Ubuntu는 Canonical이 릴리스, 저장소와 핵심 인프라를 운영하면서 공동체가 패키징, 번역, 문서와 사용자 지원에 참여하는 형태다. Canonical은 기업 지원, 클라우드 도구와 연장 보안 서비스를 제공한다.
기업의 참여는 전담 개발자, 하드웨어 시험 장비, 대규모 빌드 서버와 장기 보안 지원을 확보하는 데 도움이 된다. 여러 아키텍처와 수천 개의 패키지를 계속 빌드하고 취약점에 대응하려면 지속적인 인력과 인프라가 필요하다.
기업의 제품 전략과 공동체의 기대가 달라질 수도 있다. 지원 범위, 소스 제공 방식이나 개발 모델이 바뀌면 기존 사용자가 별도의 조직과 파생 배포판을 만들 수 있다. CentOS Linux의 개발 모델이 CentOS Stream 중심으로 변경된 뒤 AlmaLinux와 Rocky Linux가 등장한 사례가 대표적이다.
공동체는 단순히 기업이 만든 결과물을 사용하는 집단이 아니다. 패키지 유지, 코드 검토, 버그 보고, 번역, 인프라 운영과 정책 결정에 직접 참여하며, 기업이 상업적 필요를 느끼지 않는 아키텍처와 소프트웨어도 유지할 수 있다.
현대 Linux 배포판은 업스트림 프로젝트, 배포판 공동체, 후원 기업과 사용자가 변경 사항과 문제 보고를 주고받는 구조로 개발된다. 각 주체의 영향력은 프로젝트마다 다르지만, 하나의 주체만으로 커널부터 수만 개의 사용자 공간 패키지까지 장기간 유지하기는 어렵다.
데스크톱 환경과 사용자 경험
Linux 배포판의 데스크톱 사용자 경험은 데스크톱 환경, 창 관리자 또는 컴포지터, 디스플레이 서버, 그래픽 드라이버, 오디오·입력 서비스와 배포판의 기본 설정이 결합되어 형성된다. 같은 Linux 커널과 패키지 기반을 사용하더라도 어떤 데스크톱 환경과 응용 프로그램을 기본으로 선택하는지에 따라 화면 구성, 작업 방식, 자원 사용량과 설정 방법이 크게 달라질 수 있다.
데스크톱 환경은 일반적으로 패널이나 셸, 창 관리, 파일 관리자, 시스템 설정, 알림, 로그인 세션과 기본 응용 프로그램을 하나의 통합된 환경으로 제공한다. GNOME과 KDE Plasma처럼 광범위한 구성 요소를 함께 개발하는 프로젝트가 있는 반면, Xfce와 LXQt처럼 비교적 모듈화되고 가벼운 구성을 지향하는 환경도 있다.
배포판은 데스크톱 환경의 업스트림 소프트웨어를 그대로 제공하기도 하지만, 테마, 확장 기능, 패널 배치, 기본 응용 프로그램과 설정을 변경하여 독자적인 사용자 경험을 만든다. 따라서 같은 GNOME이나 KDE Plasma를 사용하는 배포판도 초기 화면과 기본 동작이 다를 수 있다.
한 배포판에서 여러 데스크톱 환경을 설치할 수도 있다. Fedora와 Ubuntu는 서로 다른 데스크톱 환경을 사용하는 공식 변형을 제공하며, Debian과 Arch Linux는 사용자가 설치 과정이나 설치 이후에 원하는 환경을 직접 선택할 수 있다. Fedora 문서도 Workstation은 GNOME을 기본으로 사용하지만 다른 Fedora 변형은 서로 다른 기본 데스크톱 환경을 사용한다고 설명한다.[108]
GNOME 기반 배포판
GNOME은 Linux 데스크톱에서 널리 사용되는 통합형 데스크톱 환경이다. 활동 개요, 작업 공간, 응용 프로그램 검색과 알림을 하나의 셸에 결합하며, 응용 프로그램과 시스템 설정 전반에 일관된 인터페이스를 제공하는 것을 중시한다.
Fedora Workstation은 GNOME을 기본 데스크톱 환경으로 사용한다. Fedora는 Workstation을 노트북과 데스크톱 컴퓨터용 운영체제로 제공하며 GNOME과 개발자·제작자용 도구를 함께 포함한다.[109]
Ubuntu Desktop도 GNOME을 기반으로 하지만 업스트림 GNOME을 그대로 제공하지는 않는다. Canonical은 자체 테마, Dock, 데스크톱 확장, 설치 프로그램과 기본 응용 프로그램 구성을 추가하여 Ubuntu의 사용자 경험을 만든다. 따라서 Fedora Workstation과 Ubuntu Desktop은 모두 GNOME 계열이지만 화면 배치와 기본 동작이 다르다.
Debian은 GNOME을 기본 데스크톱 선택지로 제공하면서 KDE Plasma, Xfce와 다른 환경도 함께 지원한다. PureOS, Tails, Pop!_OS 등도 GNOME 또는 GNOME 기술을 기반으로 자체 사용자 경험을 구성해 왔다.
GNOME Shell은 Mutter를 창 관리자이자 Wayland 컴포지터로 사용한다. 현대 GNOME 세션은 Wayland를 기본으로 사용하는 경우가 많으며, 호환성이 필요한 환경에서는 X.Org 기반 세션을 별도로 제공할 수 있다.
GNOME 기반 배포판은 일반적으로 기본 구성을 단순하게 유지하고, 자주 사용하는 기능을 일관된 작업 흐름 안에 배치하려는 경향이 있다. 세부 설정이나 외형 변경은 GNOME 설정, 확장 기능과 별도 조정 도구를 통해 이루어진다.
배포판이 GNOME 확장 기능을 기본으로 추가하면 업스트림 GNOME과 다른 작업 흐름을 만들 수 있다. Ubuntu의 Dock처럼 배포판 정체성을 만드는 데 활용되기도 하지만, GNOME Shell 버전 변경 때 확장 기능도 함께 갱신해야 한다.
GNOME은 국제화와 접근성을 프로젝트의 주요 목표로 다뤄 왔다. GNOME은 여러 언어와 문자 체계를 위한 번역 및 입력 환경을 제공하고, 화면 읽기 프로그램과 키보드 탐색을 포함한 접근성 기술을 통합한다.[110]
KDE Plasma 기반 배포판
KDE Plasma는 KDE 공동체가 개발하는 데스크톱 환경이다. 패널, 응용 프로그램 메뉴, 시스템 트레이, 위젯, 가상 데스크톱과 창 동작을 폭넓게 구성할 수 있으며, Qt와 KDE Frameworks를 기반으로 한다.
KDE는 Plasma를 웹 사용, 파일 관리, 멀티미디어와 생산성 작업을 수행할 수 있고 사용자 요구에 맞게 조정되는 자유 소프트웨어 데스크톱으로 설명한다.[111]
Kubuntu는 Ubuntu의 패키지 기반에 KDE Plasma와 KDE 응용 프로그램을 결합한 공식 Ubuntu 변형이다. Ubuntu 공식 flavor 문서는 Kubuntu가 Ubuntu와 KDE Plasma 데스크톱을 결합한다고 설명한다.[112]
KDE neon은 Ubuntu LTS 기반 사용자 공간 위에 KDE가 최신 Plasma와 KDE 소프트웨어를 직접 제공하는 배포판이다. openSUSE, Fedora, Arch Linux, Manjaro와 여러 배포판도 Plasma를 주요 또는 기본 데스크톱 선택지로 제공한다.
Plasma의 창 관리자와 Wayland 컴포지터는 KWin이다. KWin은 X11과 Wayland 세션에서 창 배치, 화면 효과, 가상 데스크톱, 입력과 디스플레이 출력을 관리한다.
Plasma는 기본 패널과 응용 프로그램 실행 메뉴를 사용하는 전통적인 데스크톱 구성을 제공하지만, 패널 위치, 위젯, 전역 테마, 창 장식과 단축키를 세밀하게 변경할 수 있다. 사용자는 Windows와 유사한 작업 표시줄, macOS에 가까운 상단 메뉴와 Dock 또는 여러 패널을 조합한 구성을 만들 수 있다.
Plasma 기반 배포판은 KDE 응용 프로그램을 기본으로 선택하는 경우가 많다. Dolphin 파일 관리자, Konsole 터미널, Okular 문서 뷰어와 KDE Connect 등이 대표적이다. 다만 Plasma에서 GTK 기반 응용 프로그램을 실행하거나 GNOME에서 KDE 응용 프로그램을 사용하는 것도 가능하다.
높은 사용자 정의 가능성은 Plasma의 주요 특징이지만, 배포판은 신규 사용자가 별도 설정 없이 사용할 수 있도록 자체 기본 구성을 제공한다. openSUSE, Kubuntu와 Fedora의 Plasma 환경은 같은 업스트림을 사용하면서도 테마, 패널과 기본 패키지가 서로 다르다.
Plasma는 화면 확대, 색상 반전, 마우스 포인터 찾기와 같은 시각적 보조 기능을 시스템 설정과 데스크톱 효과에 포함한다.[113] KDE는 Plasma 릴리스에서도 화면 읽기 프로그램, 색각 보조와 키보드 접근성 개선을 계속 반영하고 있다.[114]
경량 데스크톱 배포판
경량 데스크톱 배포판은 메모리와 저장 공간 사용량, 그래픽 효과와 백그라운드 서비스의 수를 줄여 오래된 컴퓨터, 저사양 장치 또는 최소한의 환경을 원하는 사용자에게 적합하도록 구성한 배포판이다.
경량이라는 분류에는 절대적인 기준이 없다. 데스크톱 환경 자체의 메모리 사용량뿐 아니라 배포판이 기본으로 실행하는 서비스, 응용 프로그램, 인덱싱과 애니메이션도 전체 자원 사용량에 영향을 준다.
Xfce는 UNIX 계열 운영체제를 위한 경량 데스크톱 환경으로, 현대적인 데스크톱에서 기대되는 기능을 여러 모듈형 구성 요소로 제공한다.[115] Xfce는 창 관리자, 패널, 파일 관리자, 세션 관리자와 설정 도구를 포함하면서 비교적 전통적인 데스크톱 구조를 유지한다.
Xubuntu, MX Linux, Linux Lite, Manjaro의 Xfce 판과 여러 경량 배포판이 Xfce를 사용한다. Ubuntu는 Xubuntu를 안정적이고 가벼우며 구성 가능한 Xfce 데스크톱을 사용하는 공식 flavor로 설명한다.[116]
LXQt는 Qt를 기반으로 하는 경량·모듈형 데스크톱 환경이다. 패널, PCManFM-Qt 파일 관리자, QTerminal, 설정 도구와 여러 독립 구성 요소를 제공하며, X11에서는 특정 창 관리자에 종속되지 않고 여러 Wayland 컴포지터와도 결합할 수 있다.[117]
Lubuntu는 LXQt를 사용하는 Ubuntu flavor다. Xfce와 LXQt 모두 전통적인 패널과 응용 프로그램 메뉴를 제공하지만, 사용한 툴킷과 구성 요소는 서로 다르다.
MATE는 GNOME 2 계열의 전통적인 데스크톱 방식을 이어받아 패널, 메뉴와 창 중심의 환경을 제공한다. Ubuntu MATE, Linux Mint MATE와 여러 배포판이 이를 제공한다.
경량 배포판은 일반 데스크톱 환경 대신 Openbox, Fluxbox, JWM과 같은 단순한 창 관리자를 패널·파일 관리자와 조합할 수도 있다. antiX, BunsenLabs, Puppy Linux과 Tiny Core Linux 등은 전체 데스크톱 스택을 최소화하는 서로 다른 구성을 사용한다.
경량 환경은 그래픽 효과와 통합 서비스가 적어 낮은 사양에서 유리할 수 있지만, 실제 성능은 그래픽 드라이버, 웹 브라우저와 실행 중인 응용 프로그램의 사용량에 크게 좌우된다. 최신 웹 브라우저와 웹 응용 프로그램이 데스크톱 환경보다 더 많은 메모리를 사용할 수도 있다.
경량 데스크톱이라고 해서 기능이 제한된 단순한 화면만 제공하는 것은 아니다. Xfce와 LXQt는 패널 플러그인, 테마, 단축키, 세션과 다중 모니터 설정을 제공하며, 필요한 기능을 추가 패키지로 확장할 수 있다.
창 관리자 중심 배포판
창 관리자 중심 배포판은 GNOME이나 KDE Plasma처럼 완전한 데스크톱 환경을 기본으로 구성하기보다, 독립적인 창 관리자 또는 Wayland 컴포지터와 필요한 프로그램을 조합한다.
창 관리자는 응용 프로그램 창의 위치, 크기, 포커스와 작업 공간을 관리한다. 완전한 데스크톱 환경과 달리 파일 관리자, 설정 센터, 패널, 알림과 전원 관리 프로그램을 모두 함께 제공하지 않을 수 있으므로 배포판이나 사용자가 필요한 구성 요소를 별도로 선택한다.
i3는 X11에서 동작하는 타일링 창 관리자다. 창을 겹치기보다 화면 영역에 자동으로 배치하며, 작업 공간과 키보드 단축키를 중심으로 조작한다. i3 프로젝트는 이를 처음부터 새로 작성한 타일링 창 관리자로 설명한다.[118]
Sway는 Wayland용 타일링 컴포지터이며 i3의 설정과 사용 방식을 이어받는 대체 구현을 목표로 한다.[119] i3가 X.Org 위에서 창을 관리하는 반면 Sway는 Wayland 컴포지터로서 화면 출력, 입력과 창 합성을 직접 담당한다.
Awesome, bspwm, dwm, Openbox, Fluxbox, Hyprland, River와 Niri 등도 창 관리자 또는 컴포지터 중심 환경에 사용된다. 각각 동적 타일링, 수동 타일링, 스크립트 기반 설정, 스크롤형 배치와 시각 효과 등 서로 다른 방식을 제공한다.
Arch Linux와 Gentoo처럼 최소 설치에서 시작하는 배포판은 사용자가 창 관리자와 주변 도구를 직접 선택하기 쉽다. Fedora는 i3와 Sway 기반 설치 구성을 제공해 완전한 데스크톱 환경 대신 타일링 작업 흐름을 사용할 수 있게 한다.
창 관리자 중심 환경에서는 상태 표시줄, 응용 프로그램 실행기, 알림 데몬, 배경 설정, 화면 잠금, 네트워크 관리와 정책 인증 도구를 별도로 결합하는 경우가 많다. 예를 들어 Sway는 Waybar, foot 또는 다른 터미널, mako, wofi나 fuzzel 등과 조합될 수 있다.
이러한 구성은 사용자가 시스템의 각 부분을 직접 선택하고 자동화하기 좋으며, 키보드 중심의 빠른 작업 흐름과 낮은 기본 자원 사용량을 만들 수 있다. 반면 통합 설정 화면이 없는 경우가 많아 설정 파일과 개별 프로그램의 관계를 이해해야 한다.
창 관리자 중심 배포판과 경량 데스크톱 배포판은 겹치는 부분이 있지만 동일한 개념은 아니다. Xfce와 LXQt는 가볍더라도 완전한 데스크톱 환경이며, i3나 Sway 구성은 자원 사용량보다 창 배치와 조작 모델을 중심으로 선택될 수 있다.
기본 설정과 사용자 정의
Linux 데스크톱의 사용자 경험은 업스트림 데스크톱 환경뿐 아니라 배포판이 제공하는 기본 설정에 크게 좌우된다. 배포판은 테마, 글꼴, 배경 화면, 패널 배치, 확장 기능, 단축키와 기본 응용 프로그램을 미리 선택한다.
같은 GNOME 환경에서도 Fedora는 업스트림에 가까운 구성을 제공하는 반면 Ubuntu는 Dock과 자체 테마, 확장 기능을 추가한다. 같은 KDE Plasma에서도 Kubuntu, Fedora와 openSUSE는 서로 다른 기본 테마와 응용 프로그램 구성을 사용한다.
배포판의 기본 설정은 단순한 외형 변경 이상의 역할을 한다. 파일 대화상자, 기본 웹 브라우저, 소프트웨어 설치 도구, 업데이트 알림, 전원 정책과 로그인 화면까지 포함해 사용자가 운영체제를 어떻게 인식하는지를 결정한다.
데스크톱 환경은 사용자의 홈 디렉터리에 개인 설정을 저장한다. GNOME은 주로 GSettings와 dconf를 사용하고, KDE Plasma는 여러 텍스트 기반 구성 파일과 KDE Frameworks의 설정 체계를 사용한다. Xfce와 LXQt도 각각 자체 설정 데몬과 구성 파일을 제공한다.
시스템 관리자는 전체 사용자에게 적용되는 기본값과 정책을 배포할 수 있다. 기업과 교육 기관에서는 특정 설정을 잠그거나, 프록시·인증서·응용 프로그램 메뉴와 배경 화면을 일괄적으로 배포하기도 한다.
사용자는 데스크톱 환경 전체를 교체하지 않고도 테마, 아이콘, 글꼴, 패널과 단축키를 변경할 수 있다. GNOME에서는 확장 기능이 셸 동작을 바꾸고, Plasma에서는 위젯과 전역 테마가 데스크톱 구성을 확장한다.
여러 데스크톱 환경을 한 시스템에 함께 설치할 수도 있지만, 각 환경의 기본 응용 프로그램과 설정 도구가 중복될 수 있다. 파일 연결, 키링, 인증 에이전트, 포털과 디스플레이 관리자 설정이 서로 영향을 주는 경우도 있다.
Wayland와 X11의 차이도 사용자 경험에 영향을 준다. Wayland에서는 화면 캡처, 전역 단축키, 입력 자동화와 원격 데스크톱이 컴포지터와 포털을 통해 권한을 받아야 하며, X11용 도구가 동일하게 동작하지 않을 수 있다.
배포판은 기본 구성을 통해 안정적이고 일관된 환경을 제공하지만, Linux 데스크톱은 구성 요소를 교체할 수 있는 구조를 유지한다. 사용자는 기본값을 그대로 사용할 수도 있고, 데스크톱 환경·창 관리자·응용 프로그램을 조합해 별도의 환경을 만들 수도 있다.
접근성과 국제화
Linux 데스크톱의 접근성은 시각, 청각, 운동 및 인지상의 차이가 있는 사용자가 시스템을 조작하고 정보를 인식할 수 있도록 하는 기능을 포함한다. 화면 읽기, 확대, 고대비, 키보드 탐색, 고정 키, 느린 키, 화면 키보드와 포인터 보조 기능 등이 대표적이다.
Orca는 GNOME과 여러 Linux 데스크톱에서 사용되는 화면 읽기 프로그램이다. 응용 프로그램의 접근성 정보를 읽어 음성 또는 점자 출력으로 전달한다. GTK와 Qt 응용 프로그램은 각 툴킷의 접근성 구현과 AT-SPI를 통해 보조 기술에 정보를 제공한다.
데스크톱 환경이 접근성 기능을 제공하더라도 모든 응용 프로그램이 같은 수준으로 지원되는 것은 아니다. 응용 프로그램이 버튼과 텍스트의 역할, 이름, 상태와 키보드 포커스를 올바르게 노출해야 화면 읽기 프로그램과 키보드 탐색이 정상적으로 동작한다.
GNOME은 접근성과 국제화를 오랫동안 주요 목표로 다뤄 왔으며, 데스크톱과 응용 프로그램이 여러 언어·문화권과 보조 기술에서 동작하도록 관련 기반을 제공한다.[120]
KDE Plasma는 시스템 설정에서 접근성 옵션을 제공하고, 전체 화면 확대, 색상 반전과 마우스 포인터 위치 표시 같은 시각적 보조 기능을 데스크톱 효과에 포함한다.[121]
배포판은 설치 프로그램과 로그인 화면에서도 접근성 기능을 제공해야 한다. 운영체제를 설치한 뒤에만 화면 읽기 기능을 사용할 수 있다면 시각 장애 사용자가 독립적으로 설치하기 어렵기 때문이다. 설치 이미지에서 음성 안내나 키보드 접근성을 제공하는 배포판도 있다.
국제화(internationalization, i18n)는 프로그램이 여러 언어와 지역 형식을 처리할 수 있도록 설계하는 과정이며, 현지화(localization, l10n)는 실제 번역과 지역별 설정을 제공하는 작업이다.
배포판의 국제화에는 메뉴와 문서 번역뿐 아니라 문자 인코딩, 글꼴, 입력기, 키보드 배열, 날짜·시간·숫자·통화 형식과 오른쪽에서 왼쪽으로 쓰는 문자 체계의 지원이 포함된다.
현대 Linux 배포판은 일반적으로 유니코드와 UTF-8을 기본 문자 체계로 사용한다. 로케일 설정은 프로그램이 표시할 언어, 문자 정렬, 날짜·숫자 표현과 메시지 번역을 결정한다.
한국어, 중국어와 일본어처럼 키보드에서 직접 모든 문자를 입력하기 어려운 언어에는 IBus, Fcitx와 같은 입력기 프레임워크가 사용된다. 배포판은 선택한 언어에 맞는 입력기, 글꼴과 사전을 자동으로 설치하거나 설치 과정에서 선택하게 할 수 있다.
번역은 배포판 프로젝트와 GNOME, KDE, Firefox 같은 업스트림 프로젝트에서 각각 이루어진다. 배포판이 업스트림 번역을 가져온 뒤 설치 프로그램, 패키지 관리자와 자체 응용 프로그램의 번역을 추가한다.
KDE는 언어별 번역 팀을 통해 Plasma, 응용 프로그램과 문서를 현지화한다.[122] GNOME도 번역 프로젝트를 통해 데스크톱과 응용 프로그램 문자열을 각 언어로 제공한다.[123]
번역률은 언어와 구성 요소에 따라 다를 수 있다. 데스크톱 셸은 완전히 번역되어 있어도 일부 설정 도구, 도움말이나 서드파티 응용 프로그램은 원문으로 표시될 수 있다.
오른쪽에서 왼쪽으로 쓰는 아랍어·히브리어 계열 언어에서는 단순히 문자열을 번역하는 것뿐 아니라 화면 배치, 아이콘 방향, 문장 안의 양방향 텍스트와 입력 위치를 올바르게 처리해야 한다. 복잡한 문자 조합과 글꼴 대체도 국제화 품질에 영향을 준다.
접근성과 국제화는 부가 기능이 아니라 데스크톱 환경과 응용 프로그램 전반의 설계 문제다. 배포판은 업스트림 기능을 패키징하는 데 더해 설치 이미지, 로그인 화면, 기본 글꼴, 입력기와 번역을 하나의 시스템으로 통합해야 다양한 사용자가 처음 설치할 때부터 운영체제를 사용할 수 있다.
용도별 배포판
Linux 배포판은 같은 커널과 공통 사용자 공간 소프트웨어를 바탕으로 하면서도 대상 장치, 운영 규모와 작업 목적에 따라 서로 다른 구성을 제공한다. 데스크톱 배포판은 그래픽 환경과 일반 응용 프로그램을 기본으로 제공하고, 서버 배포판은 원격 관리와 네트워크 서비스를 중심으로 구성한다. 임베디드·모바일·네트워크 장비용 시스템은 특정 하드웨어에 맞춰 크기와 기능을 제한하며, 보안 분석이나 멀티미디어 제작처럼 전문 작업을 위한 배포판은 관련 도구를 미리 통합한다.
용도별 배포판은 별도의 계열을 뜻하지 않는다. 동일한 Debian·Ubuntu·Fedora·Arch Linux 기반에서도 데스크톱, 서버, 보안 또는 게임용 배포판이 만들어질 수 있다. 반대로 하나의 배포판이 설치 방식과 선택한 패키지에 따라 여러 용도로 사용되기도 한다.
특정 용도를 표방하는 배포판이라도 모든 환경에 고정된 구성을 강제하는 것은 아니다. 서버 배포판에 데스크톱 환경을 설치하거나 데스크톱 배포판을 서버로 운영할 수 있으며, 전문 배포판에 일반 응용 프로그램을 추가할 수도 있다. 용도 구분은 기술적으로 가능한 범위보다 기본 패키지, 설정, 시험과 공식 지원의 중심을 나타낸다.
데스크톱
데스크톱용 Linux 배포판은 개인용 컴퓨터에서 웹 탐색, 문서 작업, 통신, 개발, 멀티미디어와 게임을 수행할 수 있도록 그래픽 사용자 환경과 기본 응용 프로그램을 통합한다.
일반적인 데스크톱 배포판은 GNOME, KDE Plasma, Xfce 또는 다른 데스크톱 환경과 함께 디스플레이 서버, 오디오 서비스, 네트워크 관리, 프린터 설정, 전원 관리와 소프트웨어 설치 도구를 제공한다. 설치 과정에서도 그래픽 인터페이스, 자동 하드웨어 감지와 사용자 계정 설정을 제공하는 경우가 많다.
Ubuntu Desktop은 PC와 노트북을 위한 범용 데스크톱 운영체제로 웹 탐색, 메시징, 게임, 콘텐츠 제작과 개발 도구를 지원한다.[124] Fedora Workstation, Linux Mint, Pop!_OS, elementary OS, Zorin OS, openSUSE, Manjaro와 여러 배포판도 데스크톱 사용자를 주요 대상으로 삼는다.
데스크톱 배포판은 운영체제의 기반 기술뿐 아니라 초기 화면과 사용자 경험으로 구별된다. 같은 GNOME을 사용하더라도 Ubuntu는 자체 Dock과 테마를 제공하고, Fedora Workstation은 업스트림 GNOME에 가까운 구성을 제공한다. KDE Plasma 기반 배포판도 기본 패널, 응용 프로그램과 설정에 차이가 있다.
하드웨어 지원에서는 그래픽·무선 네트워크·오디오·블루투스·절전과 고해상도 화면의 통합이 중요하다. 최신 하드웨어를 지원하려면 새 커널과 Mesa, 펌웨어가 필요할 수 있으며, 안정성을 중시하는 배포판은 별도의 하드웨어 지원 스택을 제공하기도 한다.
데스크톱 배포판은 사용 편의성과 자유로운 구성 사이에서 서로 다른 방향을 택한다. 설치 후 바로 사용할 수 있는 완성된 환경을 제공하는 배포판이 있는 반면, Arch Linux나 Gentoo처럼 사용자가 직접 데스크톱 구성 요소를 선택하고 조립하는 방식을 제공하는 배포판도 있다.
서버
서버용 Linux 배포판은 웹 서비스, 데이터베이스, 파일 공유, 네트워크 서비스, 가상화와 응용 프로그램 실행을 장기간 안정적으로 운영하는 데 중점을 둔다. 그래픽 데스크톱 환경을 기본으로 설치하지 않고 명령줄과 원격 관리 도구만 제공하는 구성이 일반적이다.
서버에서는 장기적인 보안 지원, 예측 가능한 업데이트, 서비스 재시작 관리와 응용 프로그램 호환성이 중요하다. 커널과 핵심 라이브러리의 버전을 장기간 유지하면서 보안 수정과 중요한 오류 수정만 역이식하는 정책이 널리 사용된다.
Debian, Ubuntu Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, AlmaLinux, Rocky Linux와 Oracle Linux 등이 서버 환경에서 사용된다. Red Hat은 RHEL Server를 물리 서버, 가상 머신과 클라우드에 배포할 수 있으며 여러 하드웨어 플랫폼과 상용·자체 개발 응용 프로그램을 지원하는 기반으로 설명한다.[125]
서버 배포판은 웹 서버, SSH, 데이터베이스와 컨테이너 런타임을 패키지 저장소에서 제공하지만 모든 서비스를 기본 설치하지는 않는다. 관리자는 필요한 역할만 선택해 공격 표면과 자원 사용량을 줄인다.
규모가 큰 환경에서는 자동 설치, 구성 관리, 중앙 인증, 로그 수집과 모니터링이 중요하다. 배포판은 Kickstart, cloud-init, Ansible과 같은 도구를 이용해 동일한 서버 구성을 반복적으로 배포할 수 있게 한다.
서버용과 데스크톱용이 반드시 별개의 배포판인 것은 아니다. Debian이나 Ubuntu처럼 같은 저장소와 기반 시스템에서 설치 시 선택한 패키지에 따라 서버 또는 데스크톱 환경을 구성할 수 있다.
기업 환경
기업용 Linux 배포판은 일반 서버 기능에 장기 지원, 기술 지원 계약, 하드웨어·소프트웨어 인증, 보안 및 규정 준수 도구를 결합한다. 조직은 특정 버전을 장기간 유지하면서 업무 응용 프로그램과 관리 절차가 계속 호환되는 것을 중요하게 본다.
Red Hat Enterprise Linux는 보안과 관리 기능을 포함하고 물리 시스템, 가상화와 하이브리드 클라우드에서 주요 업무를 실행하기 위한 기업용 플랫폼으로 제공된다.[126] SUSE Linux Enterprise와 Ubuntu LTS도 기업용 지원과 인증, 장기 유지 보수 서비스를 제공한다.
기업 배포판은 일반적으로 커널, C 라이브러리와 핵심 시스템 인터페이스를 안정적으로 유지한다. 새 기능을 무조건 빠르게 도입하기보다 기존 응용 프로그램이 계속 실행될 수 있도록 패치를 역이식하고 ABI 호환성을 관리한다.
하드웨어 제조사와 응용 프로그램 공급자는 특정 배포판 릴리스에서 자사 제품을 시험하고 지원 대상으로 인증할 수 있다. 데이터베이스, ERP, 가상화, 백업과 보안 제품은 지원 계약에서 허용되는 배포판과 버전을 명시하는 경우가 많다.
기업 환경에서는 중앙 계정, 디렉터리 서비스, 암호화 정책, 감사 로그와 보안 기준 적용도 중요하다. 배포판 공급자는 규정 준수 프로파일, 시스템 상태 분석과 대규모 패치 관리 도구를 제공할 수 있다.
기업용 배포판의 소프트웨어 자체는 자유 소프트웨어로 공개되더라도 공식 바이너리, 인증, 기술 지원과 추가 관리 서비스에는 구독이나 계약이 필요할 수 있다. 이 구조는 무료 공동체 배포판과 유료 기업용 제품이 같은 업스트림 생태계를 공유하도록 한다.
클라우드와 컨테이너
클라우드용 Linux 배포판은 가상 머신과 자동화된 인프라에서 빠르게 부팅하고 원격으로 설정할 수 있도록 구성된다. 설치 프로그램을 직접 실행하기보다 미리 만들어진 디스크 이미지를 복제하고, 인스턴스가 처음 시작될 때 네트워크·계정·키와 패키지를 자동으로 구성한다.
Debian, Ubuntu, Red Hat Enterprise Linux와 여러 배포판은 주요 클라우드 사업자를 위한 공식 이미지를 제공한다. Debian도 공식 클라우드 팀이 만든 이미지를 배포한다.[127]
클라우드 이미지는 일반 설치 이미지보다 작게 구성되고, 가상 장치용 드라이버, cloud-init, 원격 접속과 클라우드 메타데이터 처리 도구를 포함한다. 물리 장치용 펌웨어와 데스크톱 응용 프로그램은 생략될 수 있다.
컨테이너에서는 호스트의 Linux 커널을 공유하므로 컨테이너 이미지 자체에 커널과 부트로더가 포함되지 않는 경우가 일반적이다. Debian, Ubuntu, Fedora, Alpine Linux 등의 사용자 공간을 작은 루트 파일 시스템 이미지로 제공하여 응용 프로그램과 의존성을 함께 배포한다.
Alpine Linux는 작은 사용자 공간과 apk 패키지 관리 체계로 인해 컨테이너 기본 이미지에 널리 사용된다. 그러나 musl과 BusyBox를 사용하므로 glibc와 GNU 도구를 전제로 한 프로그램에서는 추가 호환성 검토가 필요하다.
컨테이너 호스트용 배포판은 일반 서버 배포판보다 구성 변경 범위를 줄이고 자동 업데이트와 이미지 기반 배포를 강조할 수 있다. Fedora CoreOS, Flatcar Container Linux, Bottlerocket와 Talos Linux 등이 이러한 용도를 대상으로 한다.
컨테이너 배포판은 응용 프로그램 컨테이너의 사용자 공간과 컨테이너를 실행하는 호스트 운영체제로 구분해야 한다. Ubuntu 컨테이너가 Fedora CoreOS 위에서 실행될 수 있으며, 컨테이너 안의 Ubuntu는 호스트의 Fedora 계열 커널을 공유한다.
임베디드 시스템
임베디드 Linux 시스템은 라우터, 산업 장비, 자동차 장치, 텔레비전, 카메라와 각종 전자 제품처럼 특정 기능을 수행하는 장치에 맞춰 구성된다. 범용 PC 배포판보다 저장 공간, 메모리, 부팅 시간과 전력 사용량에 엄격한 제한을 받을 수 있다.
임베디드 시스템은 필요하지 않은 드라이버와 프로그램을 제거하고, 장치에 필요한 커널 설정, 부트로더, 사용자 공간과 응용 프로그램만 포함한 전용 이미지를 만든다. 읽기 전용 루트 파일 시스템, A/B 업데이트와 장치 복구 기능을 사용하는 경우도 많다.
Yocto Project는 완성된 하나의 배포판이 아니라, 하드웨어 아키텍처와 제품 요구에 맞는 Linux 기반 시스템을 생성할 수 있는 도구, 템플릿과 개발 방법을 제공한다. 프로젝트 스스로도 “임베디드 Linux 배포판이 아니라 사용자에게 맞는 배포판을 만드는 도구”라고 설명한다.[128]
Buildroot, OpenEmbedded와 Yocto Project를 사용하면 커널, 부트로더, C 라이브러리, BusyBox와 응용 프로그램을 교차 컴파일하여 장치용 이미지를 만들 수 있다. 제조사는 공통 기반 위에 보드 지원 패키지, 장치 드라이버와 제품별 소프트웨어를 추가한다.
임베디드 Linux는 일반적인 패키지 저장소를 장치에 제공하지 않을 수도 있다. 완성된 펌웨어 이미지를 통째로 교체하거나, 제조사의 업데이트 서버에서 서명된 시스템 이미지만 받도록 설계할 수 있다.
임베디드 환경에서는 제품 수명과 보안 지원 기간이 중요하다. 장치가 장기간 판매·운영되더라도 사용한 커널, 부트로더와 라이브러리가 지원 종료될 수 있으므로 제조사가 패치를 유지하거나 새로운 기반으로 이전해야 한다.
모바일 장치
모바일 장치용 Linux 시스템은 스마트폰과 태블릿의 터치 입력, 무선 통신, 센서, 카메라, 절전과 응용 프로그램 생태계를 통합한다. 일반 데스크톱 배포판을 작은 화면에 옮기는 것보다 장치별 하드웨어와 모바일 응용 프로그램 모델을 지원하는 것이 중요하다.
Android는 Linux 커널 위에 Bionic C 라이브러리, Android 런타임과 자체 응용 프로그램 프레임워크를 구성한다. 전통적인 GNU/Linux 데스크톱 배포판과 사용자 공간 및 패키지 체계가 다르지만 Linux 커널을 기반으로 한다.[129]
Android 계열에는 제조사 시스템과 LineageOS, GrapheneOS, CalyxOS, Replicant 같은 파생 프로젝트가 존재한다. 이들은 Android의 응용 프로그램 호환성을 유지하면서 개인정보 보호, 보안, 자유 소프트웨어 또는 장치 지원에 서로 다른 우선순위를 둔다.
postmarketOS는 Alpine Linux를 기반으로 일반 Linux 사용자 공간과 모바일 인터페이스를 여러 스마트폰에 제공하려 한다. Mobian은 Debian 기반 모바일 환경을, Ubuntu Touch는 Ubuntu 계열 사용자 공간을 모바일 장치에 적용한다.
모바일 Linux의 가장 큰 기술적 과제 가운데 하나는 장치별 하드웨어 지원이다. 스마트폰 제조사가 사용하는 커널과 독점 드라이버, 모뎀·카메라·그래픽 구성은 일반 업스트림 Linux와 차이가 클 수 있다.
모바일 배포판은 터치 중심 셸, 화면 키보드, 전화·문자·모바일 데이터와 센서 서비스를 제공해야 한다. 데스크톱 응용 프로그램이 실행되더라도 작은 화면과 터치 입력에 적합하지 않으면 실제 사용성이 제한될 수 있다.
네트워크 장비
네트워크 장비용 Linux 배포판은 라우터, 무선 액세스 포인트, 방화벽, VPN 게이트웨이와 네트워크 어플라이언스를 구성하는 데 사용된다. 일반 데스크톱보다 패킷 처리, 인터페이스 설정, 방화벽, 무선 네트워크와 원격 관리 기능을 중심으로 구성한다.
OpenWrt는 주로 무선 라우터를 비롯한 임베디드 장치를 대상으로 하는 확장 가능한 Linux 운영체제다. 제조사가 제공하는 고정된 펌웨어 대신 패키지 관리와 수정 가능한 파일 시스템을 제공한다.[130]
OpenWrt는 장치별 펌웨어 이미지를 제공하면서도 apk 또는 이전 릴리스의 opkg를 통해 추가 패키지를 설치할 수 있다. 웹 관리 인터페이스인 LuCI와 명령줄을 이용해 라우팅, 방화벽, VLAN, 무선 네트워크와 VPN을 구성한다.
VyOS는 일반 서버와 네트워크 어플라이언스에서 라우팅, 방화벽, VPN과 동적 라우팅 프로토콜을 제공하는 네트워크 운영체제로 사용된다. IPFire와 Smoothwall 등은 방화벽과 게이트웨이 역할에 집중한다.
네트워크 장비용 배포판은 지원 장치의 플래시 저장 공간, RAM, 네트워크 스위치와 무선 칩에 맞는 드라이버가 필요하다. OpenWrt는 지원 가능한 장치와 하드웨어 요구 조건을 별도로 관리한다.[131]
공급자 펌웨어를 범용 네트워크 배포판으로 교체하면 기능과 업데이트 선택권이 늘어날 수 있지만, 장치별 부트로더, 파티션 구조와 무선 규정 설정이 다르므로 정확한 장치 모델용 이미지를 사용해야 한다.
보안과 디지털 포렌식
보안용 Linux 배포판은 침투 시험, 취약점 분석, 무선 네트워크 점검, 역공학, 사고 대응과 디지털 포렌식 도구를 미리 통합한다. 일반 데스크톱 배포판에 같은 도구를 개별 설치할 수도 있지만, 전문 배포판은 도구 간 의존성, 기본 설정과 라이브 실행 환경을 함께 제공한다.
Kali Linux는 Debian 기반의 오픈 소스 배포판으로 고급 침투 시험과 보안 감사를 대상으로 한다. 수백 개의 도구와 보안 작업을 위한 설정 및 스크립트를 포함하며 디지털 포렌식, 역공학과 취약점 탐지에도 사용된다.[132]
Parrot OS, BlackArch Linux, Pentoo, BackBox와 ArchStrike 등도 보안 분석을 주요 용도로 삼는다. 각 배포판은 기반 계열, 도구 선택, 업데이트 주기와 일반 데스크톱 사용 가능성에서 차이가 있다.
디지털 포렌식용 환경은 분석 대상 저장 장치를 변경하지 않고 읽기 전용으로 연결하고, 디스크 이미지 생성, 파일 시스템 복구, 메모리 분석과 증거 기록을 지원해야 한다. CAINE, Tsurugi Linux와 같은 배포판은 포렌식 작업 흐름을 중심으로 도구를 구성한다.
보안 배포판이 보안이 자동으로 강화된 일상용 운영체제를 의미하는 것은 아니다. 공격·분석 도구와 특수 설정이 포함되어 있으므로 일반 사용자용 환경과 다른 운영 방식이 필요할 수 있다.
침투 시험 도구는 허가된 시스템과 범위에서 사용해야 하며, 전문 배포판은 도구를 제공할 뿐 대상 시스템에 대한 권한이나 합법성을 대신 판단하지 않는다.
과학과 교육
과학용 Linux 배포판과 패키지 모음은 수치 계산, 통계, 시각화, 시뮬레이션, 전자 설계, 생명정보학과 고성능 컴퓨팅에 필요한 도구를 통합한다. 자유 소프트웨어 개발 도구와 자동화 환경을 함께 제공하기 때문에 연구 결과의 재현과 공동 작업에도 활용된다.
Fedora Scientific Lab은 과학·공학 계산을 위한 도구와 라이브러리를 모은 Fedora 기반 환경이다.[133] Scientific Linux는 과거 고에너지 물리학 연구 기관을 중심으로 유지된 RHEL 호환 배포판이었으며, 현재는 후속 기업 Linux 환경과 일반 과학 패키지 생태계가 그 역할을 이어간다.
교육용 배포판은 교실과 학교 네트워크에서 사용할 응용 프로그램, 사용자 계정, 서버와 관리 도구를 제공한다. Debian Edu·Skolelinux는 Debian 기반의 완전히 구성된 학교 네트워크 환경을 제공하는 Debian 공식 하위 프로젝트다.[134]
Edubuntu, Sugar on a Stick와 여러 교육용 배포판은 연령과 교육 과정에 맞는 학습 프로그램, 그래픽 환경과 콘텐츠를 제공한다. 학교 환경에서는 다수의 사용자 계정, 중앙 인증, 제한된 권한과 오래된 하드웨어 지원도 중요하다.
과학·교육용 배포판은 완전히 별개의 패키지 기반을 구축하기보다 Debian Pure Blends, Fedora Labs와 메타패키지처럼 기존 배포판에서 관련 패키지를 선택해 하나의 작업 환경으로 구성하는 경우가 많다.
연구 환경에서는 배포판의 안정성과 최신 라이브러리 사이의 균형이 중요하다. 오래된 배포판은 검증된 계산 환경을 유지하기 쉽지만 최신 컴파일러, GPU 연산과 과학 라이브러리가 필요한 연구에서는 컨테이너나 별도 환경 관리 도구를 함께 사용할 수 있다.
멀티미디어 제작
멀티미디어 제작용 배포판은 음악 녹음과 편집, 영상 제작, 그래픽 디자인, 사진 처리, 3차원 모델링과 출판에 필요한 응용 프로그램을 통합한다.
Ubuntu Studio는 오디오, 영상, 그래픽, 사진과 출판 작업에 중점을 둔 Ubuntu 공식 flavor다. 초보자부터 전문 제작자까지 사용할 수 있도록 관련 자유 소프트웨어 도구를 함께 제공한다.[135]
AV Linux, KXStudio와 과거의 Musix GNU+Linux 등도 오디오·영상 제작 환경을 제공해 왔다. 일부는 완성된 배포판이고, 일부는 일반 배포판에 설치할 수 있는 저장소와 패키지 모음에 가깝다.
오디오 제작 환경에서는 낮은 지연 시간, 안정적인 장치 처리와 여러 오디오 응용 프로그램의 연결이 중요하다. PipeWire, JACK, ALSA와 플러그인 시스템을 적절히 설정하고, 실시간 또는 저지연 커널 설정을 제공할 수 있다.
영상과 그래픽 작업에서는 GPU 드라이버, 색상 관리, 대용량 저장 장치와 코덱 지원이 중요하다. Blender, Kdenlive, Ardour, Krita, GIMP, Inkscape와 OBS Studio 같은 응용 프로그램이 주로 포함된다.
전문 배포판을 사용하지 않아도 일반 Linux 배포판에 같은 제작 프로그램을 설치할 수 있다. 멀티미디어 배포판의 장점은 응용 프로그램 선택과 오디오·그래픽 설정을 미리 통합하여 초기 구성 부담을 줄이는 데 있다.
게임과 홈 엔터테인먼트
게임용 Linux 배포판은 그래픽 드라이버, 게임 런타임, 컨트롤러 지원과 전체 화면 인터페이스를 통합한다. 일반 PC 게임용 환경과 거실·휴대용 콘솔 형태의 전용 시스템으로 나눌 수 있다.
SteamOS는 Steam Deck을 위해 설계되고 휴대용 게임 경험에 맞게 최적화된 운영체제다. Steam 클라이언트와 게임 모드를 중심으로 제공하며, Proton 호환 계층과 Deck Verified 프로그램을 통해 Windows용 게임의 실행 가능성을 관리한다.[136]
Bazzite, ChimeraOS, HoloISO, Nobara Linux와 Garuda Linux 등도 게임을 주요 대상으로 한다. 이들은 Steam, Gamescope, Wine·Proton, 그래픽 드라이버와 게임 관련 설정을 기본으로 제공하거나 설치를 단순화한다.
게임용 배포판은 최신 Mesa·Vulkan 드라이버와 커널이 필요한 경우가 많다. AMD·Intel 그래픽과 NVIDIA 그래픽의 드라이버 구성, 셰이더 캐시, 게임패드와 가변 주사율 지원이 실제 사용자 경험에 영향을 준다.
Lakka는 소형 컴퓨터를 레트로 게임 콘솔로 전환하는 경량 Linux 배포판이며 RetroArch와 libretro 생태계의 공식 Linux 배포판이다.[137] Batocera.linux와 Recalbox도 에뮬레이션과 컨트롤러 중심의 콘솔형 환경을 제공한다.
홈 엔터테인먼트용 배포판은 TV에 연결된 장치에서 영상·음악과 네트워크 미디어를 재생하도록 구성된다. LibreELEC과 CoreELEC은 Kodi 중심의 미디어 센터 운영체제로 사용되며, 일반 데스크톱 기능보다 리모컨 조작과 빠른 부팅에 중점을 둔다.
게임·미디어 배포판은 읽기 전용 또는 이미지 기반 루트 파일 시스템을 사용하여 사용자가 내부 운영체제를 직접 관리하지 않아도 되는 콘솔형 경험을 제공할 수 있다. 사용자 데이터와 게임 파일은 시스템 이미지와 별도의 영역에 저장된다.
시스템 복구
시스템 복구용 Linux 배포판은 설치된 운영체제가 부팅되지 않거나 디스크·파일 시스템·부트로더에 문제가 발생했을 때 외부 매체에서 실행하여 시스템을 진단하고 복구하도록 구성된다.
이러한 배포판은 USB 또는 광학 디스크에서 부팅되는 라이브 환경을 제공하고, 다양한 파일 시스템과 저장 장치, 네트워크 인터페이스를 지원하는 커널과 도구를 포함한다. 대상 시스템의 운영체제가 Linux가 아니더라도 디스크와 파일 시스템에 접근할 수 있다.
SystemRescue는 충돌 뒤 시스템과 데이터를 관리하거나 복구하기 위한 부팅 가능한 Linux 도구 모음이다. Linux와 Windows 파일 시스템의 포맷, 크기 변경과 검사, 부팅되지 않는 시스템의 데이터 백업 등을 지원한다.[138]
GParted Live는 파티션 생성·삭제·크기 변경과 파일 시스템 작업에 집중하고, Clonezilla Live는 디스크와 파티션 이미지 생성 및 복제를 제공한다. Rescatux와 Super Grub2 Disk는 부트로더와 운영체제 부팅 문제 해결에 중점을 둔다.
복구 환경에는 fsck, SMART 검사, 데이터 복구, 암호화 볼륨, LVM, RAID, 네트워크 복사와 메모리 시험 도구가 포함될 수 있다. 그래픽 도구와 명령줄 도구를 함께 제공하여 손상 정도와 관리자의 숙련도에 맞게 사용할 수 있다.
복구 배포판은 대상 디스크에 설치할 필요 없이 메모리에서 실행할 수 있다. 이 때문에 손상된 루트 파일 시스템을 마운트하지 않은 상태로 검사하거나, 읽기 전용으로 연결하여 데이터를 복사할 수 있다.
파일 시스템 복구와 파티션 변경은 저장된 데이터를 직접 변경할 수 있으므로, 가능한 경우 먼저 디스크 이미지를 만들고 원본 장치보다 복사본에서 작업하는 방식이 사용된다. 복구 도구가 모든 물리적 손상과 덮어쓴 데이터를 되살릴 수 있는 것은 아니다.
배포판 선택
Linux 배포판을 선택할 때는 유명도나 외형만 비교하기보다 사용할 컴퓨터, 필요한 프로그램, 업데이트 정책과 예상 운영 기간을 함께 고려해야 한다. 같은 Linux 커널을 사용하는 배포판이라도 지원하는 하드웨어, 패키지 버전, 관리 도구, 보안 정책과 공식 지원 범위가 다르다.
개인용 데스크톱에서는 설치 편의성, 그래픽 드라이버와 응용 프로그램 제공 범위가 중요할 수 있다. 서버와 기업 환경에서는 장기적인 보안 지원, 업그레이드 경로, 자동화 도구와 공급자의 지원 계약이 더 중요한 기준이 된다. 개발·연구 환경에서는 필요한 컴파일러와 라이브러리의 버전, 컨테이너와 개발 도구의 지원 여부도 확인해야 한다.
배포판 선택은 절대적인 우열을 정하는 과정이 아니다. 최신 패키지를 빠르게 제공하는 특성은 새로운 하드웨어와 개발 환경에서는 장점이지만, 장기간 같은 환경을 유지해야 하는 시스템에서는 관리 부담이 될 수 있다. 반대로 변화가 적은 장기 지원 배포판은 운영 안정성에 유리하지만 최신 데스크톱과 개발 도구가 늦게 제공될 수 있다.
하드웨어 호환성
하드웨어 호환성은 배포판이 제공하는 Linux 커널, 펌웨어, 그래픽 드라이버와 지원 CPU 아키텍처에 따라 달라진다. Linux 커널 자체가 장치를 지원하더라도 배포판 설치 이미지에 필요한 드라이버나 펌웨어가 포함되지 않으면 설치 또는 부팅 과정에서 장치를 사용하지 못할 수 있다.
새로 출시된 CPU, 그래픽 카드, 무선 네트워크 장치와 노트북은 비교적 최신 커널과 Mesa, linux-firmware가 필요할 수 있다. 이러한 환경에서는 최신 고정 릴리스나 롤링 릴리스 배포판이 오래된 장기 지원 릴리스보다 빠르게 하드웨어를 지원할 가능성이 높다.
오래된 컴퓨터에서는 최신성보다 CPU 아키텍처와 명령어 집합 지원 여부가 중요하다. 일부 배포판은 x86-64만 지원하거나 오래된 32비트 x86 지원을 중단했으며, 다른 배포판은 여러 ARM·RISC-V·IBM Z 계열 아키텍처를 위한 별도 포트를 운영한다.
Debian은 공식 포트별로 지원 아키텍처를 관리하며, 각 포트에는 해당 아키텍처용 커널과 사용자 공간 패키지가 제공된다.[139] 같은 배포판이라도 모든 패키지가 모든 아키텍처에서 빌드되는 것은 아니므로, CPU 지원 목록뿐 아니라 필요한 응용 프로그램의 패키지 제공 여부도 확인해야 한다.
노트북에서는 절전, 화면 밝기, 지문 인식, 웹캠, 터치패드와 오디오가 함께 정상적으로 동작하는지가 중요하다. 이러한 기능은 단순히 커널 드라이버 하나로 결정되지 않고 ACPI, 펌웨어, 그래픽 스택과 데스크톱 서비스가 함께 작동해야 한다.
NVIDIA 그래픽, 일부 무선 장치와 전문 장비는 별도의 독점 드라이버나 펌웨어가 필요할 수 있다. 배포판이 이를 공식 저장소, 별도 저장소 또는 설치 도구로 제공하는지와 Secure Boot 환경에서 자동으로 서명·적재할 수 있는지도 확인해야 한다.
설치 전에는 라이브 USB에서 네트워크, 그래픽, 오디오, 절전과 외부 모니터를 시험할 수 있다. 다만 라이브 환경이 사용하는 커널과 설치 뒤 적용되는 업데이트가 다를 수 있으므로 제조사 인증 목록, 배포판 하드웨어 데이터베이스와 실제 동일 모델의 사용 사례도 함께 참고하는 편이 좋다.
소프트웨어 제공 범위
배포판의 소프트웨어 제공 범위는 공식 저장소에 포함된 패키지의 수뿐 아니라 버전, 유지 관리 상태, CPU 아키텍처와 설치 방법까지 포함한다.
Debian과 Ubuntu처럼 규모가 큰 저장소를 운영하는 배포판은 데스크톱 응용 프로그램, 서버 소프트웨어, 개발 도구와 언어별 라이브러리를 폭넓게 제공한다. Fedora, Arch Linux와 openSUSE도 자체 공식 저장소와 공동체 저장소를 통해 다양한 소프트웨어를 제공한다.
필요한 프로그램이 저장소에 있다고 해도 버전이 요구 조건을 충족하는지 확인해야 한다. 고정 릴리스에서는 출시 당시의 안정 버전을 유지하므로 최신 개발 프레임워크나 그래픽 프로그램이 늦게 제공될 수 있다. 롤링 릴리스는 최신 버전을 빠르게 제공하지만 프로그램의 설정과 호환성이 자주 변할 수 있다.
공식 저장소에 없는 소프트웨어는 Flatpak, Snap, AppImage, 언어별 패키지 관리자, 공급자 저장소 또는 직접 빌드로 설치할 수 있다. 그러나 이러한 방식은 배포판 패키지 관리자와 별도의 업데이트·보안 체계를 사용할 수 있다.
개발 환경에서는 컴파일러와 인터프리터뿐 아니라 필요한 헤더, 디버그 패키지, 크로스 컴파일 도구와 특정 라이브러리 버전을 확인해야 한다. Python, Node.js, Rust와 Java 등의 최신 버전은 배포판 패키지보다 언어별 도구나 컨테이너로 관리하는 편이 적합할 수도 있다.
상용 응용 프로그램과 게임은 공식적으로 지원하는 배포판을 제한할 수 있다. 프로그램이 일반적인 Linux 바이너리로 제공되더라도 glibc 버전, 그래픽 드라이버, 패키지 형식과 파일 경로 차이로 인해 별도 조정이 필요할 수 있다.
필요한 소프트웨어가 서드파티 저장소에만 존재한다면 해당 저장소가 선택한 배포판 릴리스를 계속 지원하는지 확인해야 한다. 운영체제는 지원 중이어도 특정 공급자가 새 릴리스용 패키지를 늦게 제공하거나 지원을 중단할 수 있다.
안정성과 최신성
안정성은 단순히 오류가 적다는 의미뿐 아니라 시스템의 인터페이스와 동작이 예측 가능하게 유지되는 정도를 뜻한다. 최신성은 새로운 커널, 라이브러리, 데스크톱 환경과 응용 프로그램이 배포판에 반영되는 속도를 의미한다.
고정 릴리스 배포판은 특정 시점의 패키지 집합을 확정한 뒤 보안 수정과 중요한 오류 수정을 중심으로 제공한다. 이러한 방식은 응용 프로그램과 운영 절차를 장기간 유지하는 데 유리하지만, 패키지의 주 버전이 최신 업스트림보다 오래될 수 있다.
롤링 릴리스 배포판은 새 소프트웨어를 지속적으로 제공한다. 최신 하드웨어 지원, 개발 도구와 데스크톱 기능을 빠르게 사용할 수 있지만, 핵심 라이브러리와 설정 방식이 연속적으로 바뀌므로 정기적인 업데이트와 공지 확인이 중요하다.
Fedora는 약 6개월 주기로 새 릴리스를 발표하고 비교적 최신 기술을 빠르게 통합한다.[140] Ubuntu는 6개월 주기의 일반 릴리스와 2년 주기의 장기 지원 릴리스를 함께 제공하여 최신성과 장기 운영을 서로 다른 릴리스로 나눈다.[141]
고정 릴리스에서도 웹 브라우저, 보안 도구와 일부 하드웨어 지원 구성 요소는 새 버전으로 갱신될 수 있다. 따라서 “안정 배포판은 모든 패키지를 처음 버전으로 고정한다”거나 “롤링 배포판은 시험 없이 즉시 배포한다”는 설명은 정확하지 않다.
안정성과 최신성 가운데 어느 쪽이 중요한지는 시스템 목적에 따라 달라진다. 개인용 최신 하드웨어나 게임 PC에서는 새로운 커널과 그래픽 드라이버가 중요할 수 있고, 업무용 서버와 개발 기준 환경에서는 패키지 동작과 ABI가 오랫동안 변하지 않는 편이 중요할 수 있다.
지원 기간
배포판의 지원 기간은 보안 수정과 오류 수정이 제공되는 기간을 의미한다. 설치 당시 최신 버전이더라도 지원 기간이 짧으면 가까운 시기에 다음 릴리스로 업그레이드해야 한다.
Ubuntu는 일반적으로 6개월마다 새 릴리스를 제공하고, LTS 릴리스에는 일반 릴리스보다 긴 표준 보안 유지 기간을 제공한다.[142] Fedora는 빠른 릴리스 주기를 사용하며 각 릴리스를 다음 여러 릴리스가 나올 때까지 제한된 기간 동안 유지한다.[143]
지원 기간을 확인할 때는 배포판 전체의 종료일만 보아서는 안 된다. 저장소 영역, CPU 아키텍처와 패키지에 따라 지원 범위가 다를 수 있으며, 일부 복잡한 응용 프로그램은 장기 지원 전체 기간 동안 유지되지 않을 수 있다.
기업용 배포판은 기본 지원 뒤에 연장 수명 주기 지원을 제공할 수 있다. 이 단계에서는 새 기능과 일반 오류 수정이 줄어들고 중요한 보안 문제와 제한된 패키지만 지원될 수 있으며, 별도의 유료 계약이 필요할 수 있다.
파생 배포판은 기반 배포판과 지원 기간이 같지 않을 수 있다. Ubuntu 또는 Debian이 계속 지원되더라도 파생판의 자체 저장소, 설치 이미지와 데스크톱 구성은 먼저 유지 관리가 중단될 수 있다.
장기간 사용할 시스템에서는 현재 릴리스의 남은 지원 기간뿐 아니라 다음 버전으로의 업그레이드 경로, 여러 버전을 건너뛸 수 있는지와 업그레이드 중 서비스 중단이 얼마나 필요한지도 확인해야 한다.
관리 도구
배포판의 관리 도구는 패키지 설치와 업데이트, 서비스, 네트워크, 저장 장치, 사용자 계정과 보안 정책을 설정하는 방법을 결정한다.
Debian과 Ubuntu 계열은 dpkg와 APT를 사용하고, Fedora와 Red Hat 계열은 RPM과 DNF, Arch Linux는 pacman, openSUSE는 RPM과 Zypper를 중심으로 관리한다. 패키지 관리자의 명령과 설정 방식이 다르므로 기존 운영 경험과 자동화 스크립트도 배포판 선택에 영향을 줄 수 있다.
데스크톱 사용자는 그래픽 소프트웨어 센터, 드라이버 설치 도구와 시스템 설정을 중요하게 볼 수 있다. 서버 관리자는 명령줄 도구, 원격 관리, 자동 설치와 구성 관리 시스템과의 통합을 우선할 수 있다.
openSUSE의 YaST처럼 설치, 네트워크, 저장 장치와 시스템 서비스를 하나의 관리 체계에서 제공하는 배포판도 있다. 반대로 Arch Linux처럼 통합 제어판보다 표준 명령과 설정 파일을 사용자가 직접 관리하도록 하는 배포판도 있다.
기업 환경에서는 중앙 관리, 정책 적용, 시스템 등록, 보안 상태 검사와 대규모 업데이트 배포 기능이 중요하다. 공급자가 제공하는 관리 서버나 웹 콘솔이 기존 인증·자산 관리 체계와 연동되는지도 확인해야 한다.
자동화에서는 Ansible, Puppet, Salt, cloud-init, Kickstart와 같은 도구의 공식 지원과 모듈 제공 여부가 중요하다. 같은 작업이라도 배포판마다 패키지 이름, 서비스 이름과 설정 경로가 달라 자동화 코드를 수정해야 할 수 있다.
관리 도구가 사용하기 쉽다는 것은 사용자의 경험과 목적에 따라 다르다. 그래픽 설정 도구가 많은 배포판은 입문자에게 편리할 수 있지만, 구성 파일과 선언적 설정을 선호하는 운영자에게는 단순한 명령줄 환경이 더 예측 가능할 수 있다.
문서와 커뮤니티
배포판의 공식 문서는 설치, 업데이트, 문제 해결과 보안 정책을 이해하는 기본 자료다. 문서가 최신 릴리스와 실제 패키지 상태를 반영하는지, 초보자용 안내와 관리자용 참조 문서가 모두 제공되는지를 확인할 수 있다.
공식 위키, 설치 안내서, 패키지 문서와 릴리스 노트가 잘 정리된 배포판은 문제가 발생했을 때 원인을 찾기 쉽다. 업그레이드 전에 알려진 문제와 수동 조치를 안내하는 공지가 제공되는지도 중요하다.
커뮤니티 규모가 크면 포럼, 메일링 리스트, 채팅과 질의응답 사이트에서 많은 해결 사례를 찾을 수 있다. 다만 오래된 게시물이나 다른 배포판을 기준으로 작성된 명령은 현재 시스템에 맞지 않을 수 있다.
ArchWiki는 Arch Linux를 중심으로 작성되지만 Linux의 여러 구성 요소에 대한 폭넓은 기술 문서를 제공한다. 그러나 명령, 패키지 이름과 파일 경로는 Arch 계열을 기준으로 하므로 다른 배포판에서 그대로 적용해서는 안 된다.
커뮤니티의 규모뿐 아니라 운영 방식도 중요하다. 질문에 대한 응답 속도, 행동 강령, 번역된 문서, 지역 사용자 모임과 버그 보고 절차가 사용자의 참여 가능성에 영향을 준다.
소규모 배포판은 개발자와 직접 소통하기 쉬울 수 있지만, 문서와 문제 해결 사례가 적고 핵심 유지 관리자가 떠날 때 프로젝트 전체가 영향을 받을 가능성이 크다. 파생판을 선택할 때는 기반 배포판 문서로 해결 가능한 부분과 파생판 고유 변경 사항을 구분해야 한다.
기업 지원
기업 지원은 배포판을 사용하는 조직이 공급자로부터 기술 지원, 보안 대응, 하드웨어·응용 프로그램 인증과 장기 유지 보수를 계약 형태로 받는 것을 의미한다.
Red Hat Enterprise Linux, SUSE Linux Enterprise와 Ubuntu LTS는 대표적인 상용 지원 선택지를 제공한다. 기업은 문제의 심각도에 따른 응답 시간, 지원 연락 창구, 보안 공지와 장기 수명 주기 관리 서비스를 이용할 수 있다.
기업 지원이 필요한지는 시스템 중요도와 조직 내부 역량에 따라 달라진다. 자체 Linux 관리자가 충분한 조직에서는 공동체 배포판을 직접 운영할 수 있지만, 장애 책임과 규정 준수 증빙이 필요한 환경에서는 공급자 계약이 중요할 수 있다.
상용 소프트웨어 공급자는 특정 기업 배포판과 버전만 공식 지원 대상으로 지정할 수 있다. 프로그램이 다른 배포판에서도 기술적으로 실행되더라도 문제가 발생했을 때 공급자가 지원을 거절할 수 있으므로 도입 전에 인증 목록을 확인해야 한다.
하드웨어 인증은 서버, 저장 장치, 네트워크 어댑터와 가속기가 특정 배포판 릴리스에서 시험되었다는 의미다. 대규모 구축에서는 개별 부품의 동작 여부보다 전체 시스템과 공급자 지원 책임이 명확한지가 중요하다.
기업 지원은 배포판 자체의 품질과 동일한 개념은 아니다. 공동체 배포판도 높은 품질과 빠른 보안 대응을 제공할 수 있으며, 기업용 제품도 지원 계약의 범위 밖에 있는 패키지와 사용자 변경 사항은 지원하지 않을 수 있다.
비용을 비교할 때는 구독료뿐 아니라 관리 인력, 업그레이드, 장애 대응과 장기간 패치 유지에 드는 전체 운영 비용을 고려해야 한다.
자유 소프트웨어 정책
Linux 배포판은 자유 소프트웨어와 비자유 소프트웨어를 저장소와 설치 이미지에 포함하는 기준이 서로 다르다. 이 정책은 펌웨어, 그래픽 드라이버, 코덱, 상용 응용 프로그램과 하드웨어 지원 범위에 직접적인 영향을 준다.
일부 배포판은 기본 저장소를 자유 소프트웨어로 제한하면서 비자유 펌웨어와 프로그램을 별도 저장소로 분리한다. 다른 배포판은 설치 편의성과 하드웨어 호환성을 위해 필요한 독점 펌웨어나 드라이버를 기본 설치 이미지에 포함하거나 설치 과정에서 선택하게 한다.
GNU 프로젝트의 자유 시스템 배포판 지침은 배포판이 비자유 프로그램을 포함하거나 사용하도록 유도하지 않아야 하며, 자유 소프트웨어만으로 이루어진 시스템을 제공해야 한다는 기준을 제시한다.[144]
GNU 프로젝트는 이 지침을 충족하는 배포판을 별도로 소개하며, 일반적으로 널리 사용되는 여러 배포판은 비자유 펌웨어·저장소 또는 소프트웨어를 제공한다는 이유로 승인하지 않는다.[145][146]
Trisquel, PureOS, Parabola GNU/Linux-libre와 Guix System 등은 자유 소프트웨어만 제공하는 것을 주요 정책으로 삼는다. 이러한 배포판은 비자유 펌웨어가 필요한 무선 네트워크와 그래픽 장치에서 기능이 제한될 수 있다.
반대로 일반적인 데스크톱 배포판은 사용자가 하드웨어를 쉽게 사용할 수 있도록 비자유 펌웨어, NVIDIA 드라이버와 멀티미디어 코덱을 별도 또는 기본 저장소에서 제공할 수 있다. 이 경우에도 대부분의 운영체제 구성 요소가 자유 소프트웨어라는 사실과 모든 포함물이 자유 소프트웨어라는 주장은 구분해야 한다.
자유 소프트웨어 정책은 단순히 비용이 무료인지와 관계없다. 무료로 내려받을 수 있는 독점 드라이버는 자유 소프트웨어가 아닐 수 있으며, 유료로 판매되는 프로그램도 사용·수정·배포의 자유를 보장하면 자유 소프트웨어일 수 있다.
배포판을 선택할 때는 자신의 원칙과 실제 하드웨어 요구를 함께 고려해야 한다. 완전히 자유로운 배포판을 사용하려면 자유 펌웨어 없이 작동하는 장치를 선택해야 할 수 있으며, 현재 하드웨어의 모든 기능을 사용하는 것이 우선이라면 비자유 구성 요소를 제공하는 배포판이 더 실용적일 수 있다.
결국 배포판 선택은 하드웨어, 소프트웨어, 유지 기간과 정책 사이의 균형을 정하는 과정이다. 설치 전에는 라이브 환경과 가상 머신에서 사용성을 시험하고, 필요한 프로그램·드라이버·지원 수명과 업그레이드 절차를 확인하는 편이 안전하다.
호환성과 표준화
Linux 배포판은 공통된 Linux 커널과 다수의 사용자 공간 소프트웨어를 공유하지만, 하나의 통일된 운영체제 구현은 아니다. 배포판마다 파일 배치, 패키지 형식, 라이브러리 버전, 컴파일 옵션, 기본 설정과 릴리스 정책이 달라 동일한 프로그램이나 패키지가 모든 배포판에서 그대로 동작하지 않을 수 있다.
이러한 차이를 줄이기 위해 파일 시스템 구조, 운영체제 인터페이스와 바이너리 실행 환경을 규정하는 여러 표준이 만들어졌다. Filesystem Hierarchy Standard, Linux Standard Base와 POSIX가 대표적이며, ELF, glibc ABI, 데스크톱 항목과 AppStream 같은 개별 규격도 배포판 사이의 공통 기반을 제공한다.
표준은 호환성을 높이지만 모든 차이를 제거하지는 않는다. 프로그램이 POSIX를 준수해도 사용한 라이브러리와 그래픽 환경에 따라 특정 Linux 배포판에서 추가 작업이 필요할 수 있고, 같은 패키지 형식을 사용하더라도 저장소와 패키지 정책이 다르면 패키지를 서로 교환할 수 없다.
Filesystem Hierarchy Standard
Filesystem Hierarchy Standard(FHS)는 유닉스 계열 운영체제에서 파일과 디렉터리를 배치하는 공통 원칙을 규정한다. 프로그램이 필요한 파일의 위치를 예측하고, 사용자와 시스템 관리자가 시스템 구조를 일관되게 이해할 수 있도록 하는 것이 목적이다.[147]
FHS는 루트 파일 시스템과 /usr, /var 계층의 목적을 구분한다. /etc에는 시스템별 설정, /var에는 실행 중 변경되는 데이터, /usr에는 공유 가능하고 일반적으로 읽기 전용으로 취급되는 프로그램과 데이터, /home에는 사용자 홈 디렉터리를 배치하는 방식이 대표적이다.
루트 파일 시스템에는 시스템을 부팅하고 다른 파일 시스템을 연결하며 복구하는 데 필요한 파일이 위치한다. FHS는 배포판이 이식성에 미치는 영향을 고려하지 않고 루트 바로 아래에 새로운 디렉터리를 추가하지 않도록 요구한다.[148]
/usr는 여러 시스템에서 공유할 수 있는 읽기 전용 데이터를 담는 계층으로 정의되며, 프로그램·라이브러리·헤더와 아키텍처 독립 데이터를 포함한다.[149] /var에는 로그, 캐시, 스풀, 상태 파일과 같이 시스템 실행 중 변경되는 데이터를 배치한다.[150]
FHS의 규정에는 필수 항목과 선택 항목이 함께 존재한다. /home처럼 널리 사용되지만 선택적인 디렉터리도 있으며, 시스템 관리자가 별도의 저장 장치나 네트워크 파일 시스템을 이용해 일부 계층을 다르게 구성하는 것도 허용된다.
배포판은 FHS를 대체로 따르지만 완전히 동일하게 구현하지는 않는다. 일부 배포판은 /bin, /sbin, /lib를 /usr 아래의 대응 디렉터리로 통합하고 기존 경로에는 심볼릭 링크를 두는 usr merge 구조를 사용한다. 이는 기존 경로로 프로그램을 실행할 수 있게 하면서 실제 파일 배치를 /usr에 통합하는 방식이다.
NixOS와 Guix System처럼 프로그램을 전통적인 /usr 계층보다 콘텐츠 주소나 패키지별 저장 경로에 배치하는 배포판도 있다. 이러한 시스템은 호환성을 위한 링크와 실행 환경을 제공할 수 있지만 내부 패키지 배치는 전통적인 FHS 기반 배포판과 크게 다르다.
FHS는 파일이 어디에 있어야 하는지를 다루며 패키지 형식, 서비스 관리 방식이나 프로그램의 바이너리 ABI 전체를 정의하지 않는다. 따라서 두 배포판이 FHS를 준수한다고 해서 패키지와 실행 파일이 자동으로 호환되는 것은 아니다.
FHS 3.0은 2015년 Linux Foundation에서 최종판이 발표되었고, 이후 freedesktop.org의 사양 체계에서 관리·게시되고 있다.[151]
Linux Standard Base
Linux Standard Base(LSB)는 서로 다른 Linux 배포판 사이의 호환성을 높이고, 독립 소프트웨어 공급자가 하나의 공통 Linux 실행 환경을 대상으로 프로그램을 제공할 수 있도록 만들어진 표준 체계다.
LSB는 POSIX와 FHS를 기반으로 명령, 라이브러리 인터페이스, 실행 파일 형식, 동적 링크, 설치 스크립트와 데스크톱 구성 요소의 공통 기준을 정의했다. 아키텍처별 ABI도 규정하여 LSB를 준수하는 응용 프로그램이 같은 아키텍처의 준수 배포판에서 실행될 수 있도록 하는 것을 목표로 했다.
LSB의 핵심 사양은 컴파일된 응용 프로그램이 사용할 수 있는 시스템 인터페이스와 설치 스크립트가 기대할 수 있는 최소 실행 환경을 정의한다.[152]
LSB는 ELF 실행 파일 구조, 동적 링커, 라이브러리와 함수의 ABI, 셸 명령과 파일 시스템 배치 등을 규정했다. 단순히 소스 코드가 컴파일되는 수준이 아니라 미리 컴파일된 상용 프로그램을 여러 배포판에서 실행하는 것을 주요 목표로 삼았다.
또한 배포판과 응용 프로그램이 규격을 준수하는지 확인하기 위한 시험 도구와 인증 체계가 제공되었다. 소프트웨어 공급자는 지원 배포판마다 별도 패키지를 만들지 않고 LSB가 정의한 공통 환경을 대상으로 바이너리를 배포할 수 있었다.
그러나 Linux 사용자 공간은 빠르게 변화했고, 실제 응용 프로그램은 LSB가 규정한 범위 밖의 그래픽 툴킷, 멀티미디어 라이브러리와 배포판별 기능에 의존하는 경우가 많았다. 배포판과 응용 프로그램 공급자도 자체 패키지, 컨테이너 또는 필요한 라이브러리를 함께 제공하는 방식을 널리 사용하게 되었다.
LSB의 최종 승인판인 5.0은 2015년 6월 3일 발표되었다. 이 사양은 Core, Desktop, Runtime Languages, Imaging과 아키텍처별 규격으로 구성되며 현재 Linux Foundation의 사양 보관소에서 제공된다.[153]
LSB가 제시한 공통 ABI와 파일 시스템 원칙은 Linux 표준화 역사에서 중요한 역할을 했지만, 현대 Linux 응용 프로그램 배포가 전적으로 LSB를 중심으로 이루어지는 것은 아니다. 범용 패키지, 컨테이너 이미지, 웹 응용 프로그램과 배포판별 공식 패키지가 그 역할을 나누어 맡는다.
lsb_release 명령은 본래 배포판이 지원하는 LSB 모듈과 배포판 식별 정보를 표시하기 위해 규정되었다.[154] 그러나 현재는 모든 배포판이 이 명령을 기본 설치하는 것은 아니며, 배포판 식별에는 /etc/os-release가 널리 사용된다.
POSIX와 UNIX 호환성
POSIX는 운영체제가 제공해야 하는 프로그램 인터페이스, 셸과 명령줄 유틸리티의 공통 동작을 정의하는 표준이다. 특정 커널이나 파일 시스템 구현을 강제하기보다 프로그램이 의존할 수 있는 소스 수준의 인터페이스를 규정한다.
POSIX.1-2024는 운영체제 인터페이스와 환경, 명령 해석기인 셸, 공통 유틸리티를 정의하며 응용 프로그램의 소스 코드 이식성을 지원하는 것을 목적으로 한다.[155]
POSIX에는 파일 열기와 읽기, 프로세스 생성, 신호, 스레드, 시간, 소켓과 파일 권한 등의 C API가 포함된다. sh, awk, sed, grep, make와 여러 명령의 옵션 및 동작도 규정한다.
Linux 커널과 glibc, musl 및 여러 사용자 공간 도구는 광범위한 POSIX 인터페이스를 구현한다. 이 때문에 POSIX API만 사용하는 프로그램은 Linux뿐 아니라 BSD, macOS와 다른 유닉스 계열 시스템으로 비교적 쉽게 이식할 수 있다.
그러나 일반적인 Linux 배포판 전체가 자동으로 UNIX 상표 인증을 받는 것은 아니다. UNIX는 역사적 운영체제 계열을 가리키는 말로도 사용되지만, 대문자 UNIX 상표는 The Open Group의 Single UNIX Specification을 준수하고 인증받은 제품에 적용된다.
Linux 배포판은 대체로 유닉스 계열의 설계와 POSIX 인터페이스를 따르지만 GNU 확장, Linux 전용 시스템 호출, /proc·sysfs, systemd, epoll과 여러 비표준 기능도 사용한다. 이러한 기능에 의존하는 프로그램은 POSIX 시스템이라도 Linux가 아닌 운영체제에서 직접 컴파일되지 않을 수 있다.
반대로 POSIX 표준만으로 현대 그래픽 데스크톱, 오디오, 장치 관리, 컨테이너와 패키지 관리 환경을 설명할 수는 없다. GTK, Qt, Wayland, D-Bus와 여러 freedesktop.org 규격이 Linux 데스크톱의 추가 공통 기반을 제공한다.
셸 스크립트의 이식성도 어떤 명령 해석기를 대상으로 하는지에 따라 달라진다. POSIX sh 문법으로 작성한 스크립트는 여러 셸에서 실행할 수 있지만, Bash 배열이나 [[ ... ]] 같은 확장 문법을 사용하면 Bash가 설치된 환경을 요구한다.
따라서 Linux 프로그램의 UNIX 호환성은 POSIX 인터페이스를 따르는 부분과 Linux·GNU 전용 기능을 사용하는 부분을 구분하여 판단해야 한다.
패키지 간 호환성
Linux 배포판의 패키지는 프로그램 파일만 압축한 단순한 묶음이 아니다. 패키지 이름, 버전, CPU 아키텍처, 의존성, 충돌 관계, 설치 스크립트와 배포판 정책이 함께 기록된다.
Debian 계열의 deb, Red Hat·Fedora·SUSE 계열의 RPM, Arch Linux의 pkg.tar.zst와 Alpine Linux의 apk는 서로 다른 형식과 관리 체계를 사용한다. 한 형식의 패키지를 다른 패키지 관리자가 직접 설치할 수는 없다.
같은 패키지 형식을 사용하는 배포판 사이에도 완전한 호환성은 보장되지 않는다. Fedora와 openSUSE는 모두 RPM을 사용하지만 패키지 이름, 의존성, 파일 경로, 컴파일 옵션, 릴리스 태그와 설치 스크립트 정책이 다르다.
Debian과 Ubuntu도 모두 deb와 APT를 사용하지만 Ubuntu 패키지는 Ubuntu의 라이브러리 버전과 저장소 구성을 대상으로 만들어진다. 간단한 패키지는 Debian에서도 설치될 수 있지만 시스템 라이브러리나 서비스에 의존하는 패키지는 충돌하거나 의존성을 해결하지 못할 수 있다.
같은 배포판 계열에서도 릴리스가 다르면 패키지 호환성이 깨질 수 있다. 최신 릴리스용 패키지가 더 새로운 glibc, OpenSSL, Python 또는 그래픽 라이브러리를 요구하면 이전 릴리스에 설치할 수 없다.
패키지 변환 도구는 deb와 RPM 사이의 파일 및 일부 메타데이터를 변환할 수 있지만, 대상 배포판의 라이브러리와 정책까지 바꾸지는 않는다. 변환에 성공한 패키지도 설치 스크립트, 서비스 이름과 의존성 차이 때문에 정상적으로 동작하지 않을 수 있다.
배포판 패키지는 해당 배포판의 공식 빌드 환경에서 다시 만드는 것이 가장 안정적이다. 공급자가 여러 배포판을 지원하려면 각 배포판 또는 계열별 패키지를 별도로 빌드하고 시험하는 방식이 일반적이다.
바이너리 호환성
바이너리 호환성은 프로그램을 소스에서 다시 컴파일하지 않고 다른 시스템에서 실행할 수 있는지를 뜻한다. Linux에서의 바이너리 호환성은 CPU 명령어 집합, 실행 파일 형식, 커널 시스템 호출, 동적 링커와 라이브러리 ABI에 의해 결정된다.
대부분의 Linux 배포판은 실행 파일 형식으로 ELF를 사용한다. ELF는 실행 코드, 데이터, 동적 라이브러리 정보와 심볼을 저장하는 공통 구조를 제공한다. LSB도 ELF와 동적 링크 동작을 바이너리 호환성의 일부로 규정했다.[156]
ELF 형식이 같더라도 CPU 아키텍처가 다르면 실행할 수 없다. x86-64 실행 파일은 ARM64 Linux에서 직접 실행되지 않으며, QEMU 사용자 모드와 같은 에뮬레이션 또는 별도의 아키텍처용 빌드가 필요하다.
같은 x86-64에서도 프로그램이 대상 CPU보다 새로운 명령어 집합을 사용하면 실행되지 않을 수 있다. 배포판은 지원하려는 최소 CPU 세대에 맞춰 공식 패키지의 컴파일 기준을 정한다.
동적으로 링크된 프로그램은 지정된 동적 링커와 공유 라이브러리를 요구한다. glibc를 대상으로 만든 프로그램은 일반적으로 musl 기반 시스템에서 직접 실행되지 않으며, 필요한 glibc 환경이나 호환 계층을 추가해야 한다.
라이브러리의 이름이 같아도 ABI가 달라질 수 있다. 함수의 인자, 데이터 구조, 심볼 버전 또는 C++ ABI가 바뀌면 기존 바이너리가 로드되지 않거나 잘못 동작할 수 있다. 배포판은 공유 라이브러리의 SONAME과 패키지 의존성을 사용해 이러한 관계를 관리한다.
Linux 커널은 사용자 공간 시스템 호출에 대해 강한 하위 호환성을 유지하려 한다. 이 때문에 오래된 Linux 바이너리가 최신 커널에서 실행되는 경우가 많다. 그러나 프로그램이 요구하는 오래된 사용자 공간 라이브러리와 런타임까지 최신 배포판이 계속 제공하는 것은 아니다.
정적 링크는 필요한 라이브러리 일부를 실행 파일에 포함해 배포판 의존성을 줄일 수 있다. 그러나 DNS, 사용자 계정 조회, 그래픽 드라이버, 보안 모듈과 커널 인터페이스처럼 외부 시스템 구성에 의존하는 부분까지 완전히 독립시키지는 못한다.
상용 프로그램은 지원 가능한 최소 glibc 버전을 대상으로 빌드하고, 자체 라이브러리를 프로그램 디렉터리에 포함하는 방식으로 여러 배포판을 지원하기도 한다. 컨테이너와 범용 패키지도 응용 프로그램이 기대하는 사용자 공간을 함께 제공하여 호환성 차이를 줄인다.
배포판 간 소프트웨어 배포
소프트웨어 개발자는 배포판별 공식 저장소에 패키지를 제출하거나, 자체 저장소를 운영하거나, 여러 배포판에서 사용할 수 있는 범용 형식을 제공할 수 있다. 각 방식은 시스템 통합, 유지 관리 책임과 지원 범위가 다르다.
배포판 공식 패키지는 해당 배포판의 라이브러리, 보안 업데이트와 관리 도구에 가장 잘 통합된다. 패키지 유지 관리자가 업스트림 릴리스를 배포판 정책에 맞게 시험하고, 다른 패키지와의 의존성과 충돌을 관리한다.
그러나 공식 저장소에 들어가기까지 검토와 릴리스 일정이 필요하며, 배포판마다 별도의 패키징 작업을 수행해야 한다. 개발자가 새 버전을 발표해도 고정 릴리스 저장소에서는 기존 버전이 유지될 수 있다.
개발자가 자체 deb 또는 RPM 저장소를 제공하면 공식 저장소보다 빠르게 새 버전을 배포할 수 있다. 대신 여러 배포판 릴리스와 아키텍처용 패키지를 직접 빌드하고 보안 업데이트, 저장소 서명과 호환성 문제를 책임져야 한다.
Flatpak은 여러 Linux 배포판에서 데스크톱 응용 프로그램을 배포하기 위한 체계다. 응용 프로그램은 공통 런타임과 필요한 추가 라이브러리를 사용하고, 호스트 시스템과 분리된 샌드박스 안에서 실행된다.[157]
Flatpak 응용 프로그램은 중앙 저장소인 Flathub, 개발자가 운영하는 별도 저장소 또는 단일 번들 파일로 배포할 수 있다.[158] 같은 Flatpak 런타임을 지원하는 배포판에서는 호스트 라이브러리 버전 차이의 영향을 상대적으로 적게 받는다.
Snap은 응용 프로그램과 필요한 의존성을 하나의 패키지로 제공하고 snapd가 설치, 갱신과 실행 제한을 관리하는 체계다. snapd를 지원하는 여러 배포판에서 같은 Snap 패키지를 설치할 수 있다.[159]
AppImage는 응용 프로그램과 대상 시스템에 있다고 가정하기 어려운 라이브러리를 하나의 실행 가능한 이미지에 포함한다. 사용자는 파일을 내려받아 실행 권한을 부여한 뒤 별도의 시스템 설치 과정 없이 실행할 수 있다.[160]
AppImage는 일반적으로 응용 프로그램 개발자가 직접 만들고 배포한다. 이는 배포판 유지 관리자가 업스트림 소프트웨어를 다시 패키징하는 전통적인 방식과 다르다.[161]
컨테이너 이미지는 서버 응용 프로그램과 명령줄 도구를 배포판 사용자 공간과 함께 제공할 수 있다. 이미지 안에 필요한 라이브러리와 런타임을 고정하므로 호스트 배포판 차이를 줄이지만, 그래픽 데스크톱 통합과 일반 사용자 파일 접근에는 별도 구성이 필요하다.
언어별 패키지 관리자인 pip, npm, Cargo와 RubyGems도 배포판과 독립적으로 소프트웨어를 전달한다. 이들은 주로 해당 언어의 라이브러리와 개발 도구를 관리하며, 운영체제 패키지 관리자와 같은 파일을 동시에 관리하면 충돌할 수 있다.
소스 코드를 직접 배포하는 방식은 가장 넓은 배포판에서 사용할 가능성을 제공하지만, 사용자가 컴파일러와 개발 라이브러리를 설치해야 한다. 또한 빌드 옵션과 시스템 환경에 따라 결과가 달라질 수 있어 공식 바이너리보다 지원 범위를 명확히 정하기 어렵다.
따라서 배포판 간 소프트웨어 배포에는 하나의 완전한 해결책이 존재하지 않는다. 시스템 서비스와 핵심 라이브러리는 배포판별 패키지가 유리하고, 데스크톱 응용 프로그램은 Flatpak·Snap·AppImage, 서버 응용 프로그램은 컨테이너, 개발 라이브러리는 언어별 패키지 관리자가 적합할 수 있다. 실제 소프트웨어는 대상 사용자와 시스템 통합 수준에 따라 여러 방식을 함께 제공하기도 한다.
배포판 생태계의 특징
Linux 배포판 생태계는 하나의 중앙 조직이 운영체제 전체를 통제하는 구조가 아니라, 여러 독립 프로젝트가 Linux 커널과 공통 사용자 공간 소프트웨어를 서로 다른 방식으로 조합하는 구조다. 배포판은 패키지 형식, 릴리스 정책과 기본 설정을 독자적으로 선택하면서도 Linux 커널, GNU 도구, systemd, GNOME, KDE Plasma와 같은 업스트림 프로젝트의 결과를 공유한다.
이 구조에서는 하나의 기술이 여러 배포판으로 확산되고, 하나의 배포판이 다시 여러 파생판의 기반이 된다. 서로 다른 배포판이 같은 데스크톱 환경과 응용 프로그램을 제공하는 한편, 동일한 배포판 계열 안에서도 서버·데스크톱·임베디드와 전문 작업용 시스템이 갈라질 수 있다.
배포판의 다양성은 특정 사용자와 장치에 맞는 선택지를 제공하지만, 같은 소프트웨어를 여러 형식으로 반복해서 패키징하고 시험해야 하는 비용도 만든다. 컨테이너, Flatpak과 이미지 기반 운영체제는 이러한 중복을 일부 줄이는 동시에 전통적인 배포판의 경계를 다른 방식으로 재구성하고 있다.
다양성과 전문화
Linux 배포판은 범용 데스크톱과 서버에서 시작하여 기업 시스템, 클라우드, 컨테이너 호스트, 네트워크 장비, 스마트폰, 임베디드 장치와 시스템 복구 환경으로 범위를 넓혀 왔다.
배포판은 같은 소프트웨어 기반을 사용하면서도 목표에 따라 기본 구성을 크게 다르게 만든다. 데스크톱 배포판은 그래픽 환경, 오디오, 프린터와 일반 응용 프로그램을 통합하고, 서버 배포판은 원격 관리, 네트워크 서비스와 장기적인 보안 지원을 중시한다. 임베디드 시스템은 저장 공간과 메모리를 줄이고 특정 장치에 필요한 구성 요소만 포함한다.
전문화는 새로운 패키지 형식이나 완전히 독립된 기반을 만들지 않고도 이루어질 수 있다. Fedora Spins는 Fedora Linux를 기반으로 서로 다른 데스크톱 환경과 선택된 응용 프로그램 구성을 제공한다. 이들은 별개의 독립 배포판이라기보다 같은 Fedora 저장소와 릴리스 기반을 공유하는 공식 변형이다.[162]
Debian Pure Blends와 Fedora Labs처럼 특정 분야의 패키지를 기존 배포판 안에서 하나의 작업 환경으로 묶는 방식도 있다. 이러한 구성은 별도의 저장소와 배포판 전체를 유지하지 않고도 과학, 교육, 디자인과 보안 분석에 필요한 기본 환경을 제공한다.
다른 프로젝트는 기반 배포판을 가져와 독립적인 이름, 저장소, 릴리스와 사용자층을 가진 파생 배포판을 만든다. Kali Linux는 Debian 기반에서 보안 분석 도구를 통합하고, Ubuntu Studio는 Ubuntu의 공식 변형으로 멀티미디어 제작 환경을 제공한다. 두 시스템은 전문화를 추구하지만 프로젝트와 기반 배포판의 관계는 서로 다르다.
전문화된 배포판에 포함된 프로그램은 일반 배포판에도 설치할 수 있는 경우가 많다. 전문 배포판의 차이는 특정 프로그램의 독점적 제공보다 도구 선택, 기본 설정, 커널 구성, 설치 이미지와 문서가 하나의 작업 흐름에 맞춰 통합되어 있다는 데 있다.
배포판 수가 많다는 사실이 모두 독립된 기술 기반이 존재한다는 뜻은 아니다. 상당수 배포판은 소수의 주요 계열에서 파생되며 커널, 패키지와 데스크톱 환경의 대부분을 기반 배포판과 공유한다.
파생 배포판의 형성
파생 배포판은 기존 배포판의 패키지, 저장소, 소스 코드나 빌드 체계를 기반으로 새로운 목표와 사용자층을 위한 운영체제를 만드는 방식으로 형성된다.
Debian은 파생판을 Debian에서 이루어진 작업을 기반으로 하지만 독자적인 정체성, 목표와 사용자를 가지며 Debian과 별도의 주체가 만드는 배포판으로 설명한다.[163]
파생판을 만드는 가장 일반적인 방식은 기반 배포판의 패키지 대부분을 재사용하거나 다시 빌드하고, 자체 패키지·설정·설치 프로그램과 저장소를 추가하는 것이다.[164]
파생 배포판은 기반 배포판이 해결한 패키징, 하드웨어 지원과 보안 유지 관리 작업을 활용할 수 있다. 새로운 프로젝트가 커널부터 수만 개의 응용 프로그램까지 모두 독립적으로 패키징하지 않고도 자체 사용자 경험과 정책을 만들 수 있다는 점이 파생판 형성의 주요 배경이다.
파생 정도는 프로젝트마다 다르다. 일부 배포판은 기반 저장소를 직접 사용하면서 몇 개의 패키지와 기본 설정만 추가한다. 다른 배포판은 패키지 전체를 자체 저장소로 복제하고 별도의 시험·릴리스 일정을 운영한다.
Ubuntu는 Debian 소스 패키지를 광범위하게 활용하지만 자체 저장소, 릴리스 주기, 수정 사항과 보안 지원 체계를 운영한다. Ubuntu를 다시 기반으로 Linux Mint, Pop!_OS, elementary OS와 여러 파생판이 만들어지면서 다단계 계보가 형성되었다.
파생판에서 개발된 변경은 기반 배포판으로 돌아갈 수도 있다. Debian의 파생판 협력 조직은 파생 프로젝트의 개발자가 수정 사항을 Debian에 제출하고, 여러 배포판이 작업을 공유하도록 지원한다.[165]
Debian의 DEX는 Debian을 직접 또는 간접적으로 기반으로 한 배포판이 300개 이상이라고 설명하며, 파생판과 Debian 개발자가 변경 사항을 Debian에 통합하기 위한 공동 작업을 수행한다.[166]
파생판은 기반 배포판의 장점을 빠르게 활용할 수 있지만 기반 프로젝트의 릴리스, 패키지 제거와 정책 변경에도 영향을 받는다. 자체 수정이 많아질수록 기반 패키지의 새 버전을 가져올 때 충돌을 해결하고 패치를 다시 적용해야 하는 유지 관리 비용도 커진다.
프로젝트의 인력과 자원이 부족하면 자체 저장소와 보안 업데이트가 기반 배포판보다 늦어질 수 있다. 따라서 파생판의 지속 가능성은 기반 배포판의 규모뿐 아니라 자체 개발자, 빌드 인프라와 업데이트 정책에 달려 있다.
패키지 중복과 분산
각 Linux 배포판은 업스트림 소프트웨어를 자체 패키지 형식과 정책에 맞게 빌드한다. 같은 프로그램이라도 Debian의 deb, Fedora의 RPM, Arch Linux의 pkg.tar.zst와 Alpine Linux의 apk 패키지로 각각 만들어질 수 있다.
동일한 형식을 사용하는 배포판 사이에서도 패키지를 별도로 관리하는 경우가 많다. Fedora, openSUSE와 Red Hat Enterprise Linux는 모두 RPM을 사용하지만 저장소, 의존성 이름, 빌드 옵션, 패치와 릴리스 정책이 다르다.
이 구조에서는 하나의 업스트림 보안 수정이나 새 버전을 여러 배포판의 유지 관리자가 각각 가져와 패키지화하고 시험해야 한다. 동일한 문제를 서로 다른 버전과 환경에 역이식하면서 비슷한 작업이 반복될 수 있다.
반면 이러한 중복은 단순한 낭비만을 의미하지 않는다. 각 배포판은 서로 다른 안정성 기준, CPU 아키텍처, 자유 소프트웨어 정책과 사용자 요구에 맞게 패키지를 검토한다. 하나의 패키징 오류나 공급망 문제가 모든 Linux 시스템에 동시에 영향을 주는 것을 줄이는 분산 효과도 있다.
배포판 유지 관리자는 업스트림에 패치를 제출하고 다른 배포판과 취약점 정보를 공유하여 반복 작업을 줄일 수 있다. 그러나 배포판마다 지원하는 소프트웨어 버전과 패치 수준이 다르기 때문에 하나의 수정 사항을 모든 곳에 그대로 적용할 수 있는 것은 아니다.
패키지 중복은 저장 공간에도 나타난다. 전통적인 시스템 패키지는 공통 라이브러리를 여러 응용 프로그램이 공유하지만, Flatpak·Snap·AppImage와 컨테이너는 호환성을 위해 일부 라이브러리를 응용 프로그램이나 런타임 안에 별도로 포함할 수 있다.
범용 패키지는 배포판별 패키징 중복을 줄이는 대신 같은 라이브러리의 여러 버전이 시스템에 함께 존재하게 만들 수 있다. 다만 Flatpak은 여러 응용 프로그램이 공통 런타임을 공유하고, OSTree의 콘텐츠 주소 방식으로 동일한 파일의 물리적 중복을 줄인다.
패키징 작업의 분산은 소프트웨어의 발견과 설치 경로도 나눈다. 사용자는 배포판 공식 저장소, 서드파티 저장소, Flathub, Snap Store, 언어별 패키지 저장소와 개발자 웹사이트 가운데 어디에서 프로그램을 설치해야 하는지 판단해야 할 수 있다.
데스크톱 환경의 공유
Linux 데스크톱 환경은 특정 배포판에 종속되지 않는 독립 업스트림 프로젝트로 개발된다. GNOME, KDE Plasma, Xfce와 LXQt는 여러 배포판에서 공통으로 제공되며, 각 배포판은 이를 자체 패키지와 설정으로 통합한다.
Fedora Workstation은 GNOME을 기본으로 제공하지만 Fedora의 다른 변형에서는 KDE Plasma, Xfce, LXQt와 여러 창 관리자를 선택할 수 있다.[167]
Ubuntu, Debian, Arch Linux, openSUSE와 Gentoo에서도 같은 데스크톱 환경을 설치할 수 있다. 따라서 데스크톱 환경이 같다고 해서 같은 배포판 계열에 속하거나 패키지 호환성이 생기는 것은 아니다.
같은 데스크톱 환경을 공유하면 응용 프로그램, 번역, 접근성 기능과 사용자 문서가 여러 배포판에서 활용될 수 있다. GNOME이나 KDE에서 수정된 기능은 각 배포판이 새 버전을 채택하면서 전체 생태계로 확산된다.
배포판은 업스트림 데스크톱을 그대로 제공하거나 자체 테마, 확장 기능과 기본 응용 프로그램을 추가할 수 있다. Ubuntu와 Fedora Workstation은 모두 GNOME을 사용하지만 패널 배치, 확장 기능과 기본 소프트웨어에서 차이가 있다.
GTK나 Qt로 작성된 응용 프로그램은 같은 툴킷을 기본으로 사용하지 않는 데스크톱에서도 실행할 수 있다. KDE Plasma에서 GNOME 응용 프로그램을 사용하거나 GNOME에서 KDE 응용 프로그램을 사용하는 것이 가능하다.
다만 툴킷, 파일 선택 창, 테마, 시스템 트레이와 포털 구현이 다르면 외형과 일부 통합 기능이 일관되지 않을 수 있다. 배포판과 데스크톱 프로젝트는 freedesktop.org 규격, D-Bus와 데스크톱 포털을 통해 이러한 차이를 줄인다.
데스크톱 환경의 공유는 배포판의 외형적 경계를 흐리게 한다. 사용자는 Fedora와 Debian에 거의 같은 Plasma 구성과 응용 프로그램을 설치할 수 있지만, 패키지 관리자, 시스템 업데이트와 관리 정책은 여전히 각 배포판을 따른다.
컨테이너와 범용 패키지의 영향
컨테이너와 범용 패키지 형식은 응용 프로그램이 호스트 배포판의 라이브러리와 패키지 버전에 직접 의존하는 정도를 줄였다.
Flatpak 응용 프로그램은 특정 배포판의 사용자 공간 전체 대신 정해진 런타임을 대상으로 빌드된다. 런타임은 응용 프로그램이 공통으로 사용하는 기본 라이브러리를 제공하며, 여러 버전의 런타임을 한 시스템에 함께 설치할 수 있다.[168]
Flatpak 런타임은 특정 배포판 버전에 종속되지 않는 기반을 제공한다. 응용 프로그램 개발자는 여러 배포판의 각 라이브러리 조합을 개별적으로 지원하는 대신 하나 이상의 Flatpak 런타임을 대상으로 패키지를 만들 수 있다.
Flatpak에서는 Freedesktop, GNOME과 KDE 런타임이 주요 공통 기반으로 제공된다.[169] 응용 프로그램은 런타임에 없는 라이브러리만 자체 패키지 안에 추가할 수 있다.
범용 패키지는 개발자가 새 버전을 배포판 릴리스 일정과 별도로 전달할 수 있게 한다. 고정 릴리스 배포판에서도 기본 운영체제를 크게 바꾸지 않고 최신 데스크톱 응용 프로그램을 설치할 수 있다.
반면 응용 프로그램과 포함 라이브러리의 보안 유지 책임이 배포판 관리자에서 Flatpak 패키지나 응용 프로그램 게시자로 이동할 수 있다. 오래된 런타임이나 포함된 라이브러리가 계속 유지되는지 별도로 확인해야 한다.
컨테이너는 응용 프로그램과 필요한 사용자 공간을 하나의 이미지로 묶고 호스트의 Linux 커널 위에서 실행한다. Debian 기반 컨테이너를 Fedora나 Ubuntu 호스트에서 실행할 수 있으므로 서버 응용 프로그램의 배포가 호스트 배포판과 상당 부분 분리된다.
Open Container Initiative의 이미지 규격은 컨테이너 이미지를 매니페스트, 파일 시스템 계층과 실행 설정으로 정의하고, 서로 다른 도구가 이미지를 생성·운반·준비할 수 있는 공통 형식을 제공하는 것을 목표로 한다.[170]
OCI 이미지 인덱스는 여러 CPU 아키텍처와 운영체제용 이미지를 하나의 상위 구조에서 가리킬 수 있다.[171] 이를 통해 같은 이미지 이름 아래 x86-64, ARM64와 다른 플랫폼용 이미지를 제공할 수 있다.
컨테이너는 호스트의 커널을 공유하므로 배포판 경계를 완전히 제거하지는 않는다. 사용할 수 있는 시스템 호출, 보안 모듈, cgroup과 파일 시스템 기능은 호스트 커널과 컨테이너 런타임에 의해 결정된다.
범용 패키지와 컨테이너는 전통적인 배포판 저장소를 대체하기보다 역할을 분리한다. 커널, 장치 드라이버와 시스템 서비스는 호스트 배포판이 관리하고, 데스크톱 응용 프로그램은 Flatpak, 서버 응용 프로그램은 컨테이너로 제공하는 구성이 늘어났다.
배포판 경계의 변화
전통적인 Linux 배포판은 커널부터 응용 프로그램까지 하나의 패키지 저장소와 릴리스 정책으로 관리했다. 사용자가 Debian을 설치하면 시스템 라이브러리와 데스크톱 응용 프로그램도 주로 Debian 저장소에서 받는 구조였다.
범용 응용 프로그램 패키지와 컨테이너가 확산되면서 운영체제의 각 계층이 서로 다른 공급 경로를 사용할 수 있게 되었다. 호스트는 Fedora 계열이지만 데스크톱 응용 프로그램은 Flathub에서, 개발 환경은 Ubuntu 컨테이너에서, 프로그래밍 언어 라이브러리는 언어별 저장소에서 받을 수 있다.
이러한 환경에서는 사용자가 체감하는 응용 프로그램 생태계가 호스트 배포판의 공식 저장소만으로 결정되지 않는다. 전통적으로 패키지 수가 적었던 배포판도 Flatpak과 컨테이너를 이용해 다른 배포판과 비슷한 응용 프로그램 범위를 제공할 수 있다.
Distrobox와 같은 도구는 호스트 데스크톱 안에서 다른 배포판의 사용자 공간 컨테이너를 실행하고, 그 안의 명령줄 프로그램과 그래픽 응용 프로그램을 호스트 환경에 통합한다. 이를 이용하면 Fedora 호스트에서 Ubuntu나 Arch Linux 사용자 공간의 개발 도구를 사용할 수 있다.
이미지 기반 또는 불변 배포판에서는 이러한 분리가 더 뚜렷하다. 기본 운영체제는 원자적으로 갱신되는 읽기 전용 또는 제한된 시스템 이미지로 유지하고, 일반 응용 프로그램은 Flatpak, 개발 도구는 컨테이너에 설치한다.
배포판의 역할은 모든 응용 프로그램을 직접 공급하는 것에서 안정적인 커널, 하드웨어 지원, 보안 정책, 컨테이너 런타임과 응용 프로그램 실행 기반을 제공하는 방향으로 일부 이동하고 있다.
그럼에도 배포판 경계가 사라진 것은 아니다. 부팅, 커널, C 라이브러리, 초기화 시스템, 네트워크, 보안 모듈, 그래픽 드라이버와 시스템 업데이트는 여전히 호스트 배포판이 결정한다.
컨테이너와 Flatpak 내부의 프로그램도 호스트 커널, 그래픽 드라이버, D-Bus, 데스크톱 포털과 파일 시스템 권한을 통해 외부 시스템과 상호 작용한다. 호스트 배포판의 정책과 버전은 이러한 경계에서 계속 영향을 준다.
배포판 계열은 이전처럼 설치 가능한 응용 프로그램의 목록만으로 구분되기보다 시스템 기반, 업데이트 방식, 기본 보안 모델과 관리 경험으로 구분되는 경향이 강해졌다.
결과적으로 현대 Linux 생태계는 하나의 배포판이 운영체제 전체를 단독으로 공급하는 구조와, 여러 독립적인 패키지·런타임·컨테이너 생태계가 계층별로 결합되는 구조가 함께 존재한다.
장점과 한계
Linux 배포판의 특성은 하나의 공통된 장점이나 단점으로 설명하기 어렵다. Linux 커널과 자유 소프트웨어를 공유하면서도 배포판마다 대상 사용자, 릴리스 정책, 패키지 구성, 관리 방식과 지원 체계가 다르기 때문이다.
다양한 배포판이 존재한다는 점은 사용자가 목적과 환경에 맞는 운영체제를 선택할 수 있게 하지만, 소프트웨어 공급자와 사용자가 여러 패키지 형식과 시스템 차이를 처리해야 하는 원인이 되기도 한다. 최신 패키지를 빠르게 제공하는 배포판의 특성은 새로운 하드웨어와 개발 환경에서는 장점이지만, 장기간 같은 환경을 유지해야 하는 시스템에서는 추가적인 관리 부담이 될 수 있다.
장점
선택과 구성의 자유
Linux 배포판은 데스크톱, 서버, 클라우드, 네트워크 장비, 모바일 장치와 임베디드 시스템 등 다양한 환경을 대상으로 한다. 사용자는 같은 Linux 커널을 기반으로 하면서도 그래픽 환경, 초기화 시스템, 패키지 관리자와 릴리스 모델이 서로 다른 배포판을 선택할 수 있다.
일반 사용자에게 필요한 기본 환경을 미리 구성한 배포판이 있는 반면, Arch Linux와 Gentoo처럼 사용자가 시스템 구성 요소를 직접 선택할 수 있는 배포판도 있다. 기업은 범용 배포판을 그대로 사용할 수도 있고, 제품에 필요한 패키지와 설정만 포함한 자체 이미지를 만들 수도 있다.
배포판은 공개된 소스 코드와 재배포 가능한 패키지를 기반으로 하므로 특정 목적을 위한 파생판을 만들기 쉽다. Debian은 파생 배포판이 Debian의 작업을 활용하면서 독자적인 목표와 사용자를 위한 시스템을 만들 수 있다고 설명한다.[172]
폭넓은 용도와 하드웨어 지원
Linux 배포판은 개인용 컴퓨터뿐 아니라 대규모 서버, 슈퍼컴퓨터, 클라우드 인스턴스, 라우터와 소형 임베디드 장치에서 사용된다. 배포판은 대상 환경에 맞춰 커널 설정, 사용자 공간, 설치 방식과 관리 도구를 변경할 수 있다.
Linux 커널에는 여러 CPU 아키텍처와 장치 종류를 위한 드라이버가 포함되며, 배포판은 커널과 펌웨어를 패키지로 제공한다. 새 커널을 빠르게 제공하는 배포판은 최신 하드웨어를 일찍 지원할 수 있고, 장기 지원 배포판은 안정된 사용자 공간에 새로운 하드웨어 지원 커널을 결합할 수 있다.
커널의 사용자 공간 인터페이스는 기존 응용 프로그램의 동작을 유지하기 위해 안정성을 중시한다. Linux 커널 문서는 안정된 사용자 공간 ABI를 별도로 기록하며, 사용자 프로그램이 해당 인터페이스를 사용할 수 있도록 한다.[173]
통합된 패키지 관리
Linux 배포판은 운영체제와 응용 프로그램을 패키지 저장소에서 함께 제공한다. 패키지 관리자는 프로그램 설치, 업데이트, 제거, 의존성 해결과 파일 추적을 통합하여 처리한다.
공식 저장소의 패키지는 배포판의 라이브러리와 정책에 맞춰 빌드되고, 다른 패키지와의 호환성을 함께 시험할 수 있다. 보안 문제가 발견되면 배포판은 영향을 받는 패키지를 수정하고 같은 업데이트 체계를 통해 사용자에게 전달한다.
서버에서는 명령줄과 자동화 도구를 이용해 여러 시스템에 동일한 패키지와 설정을 반복적으로 배포할 수 있다. 데스크톱에서는 그래픽 소프트웨어 센터를 통해 같은 저장소를 사용할 수 있다.
공개된 개발 과정
주요 Linux 배포판은 패키지 정의, 소스 코드, 패치, 버그 추적기와 개발 토론을 공개한다. 사용자는 배포판이 원본 소프트웨어에 어떤 변경을 적용했는지 확인하고, 문제를 보고하거나 수정에 참여할 수 있다.
공개된 빌드 정의는 패키지가 어떤 소스와 옵션으로 만들어졌는지 추적할 수 있게 한다. 재현 가능한 빌드가 적용된 패키지는 같은 소스와 환경에서 동일한 결과를 다시 생성해 공식 바이너리를 검증할 수 있다.[174]
개발이 공개되어 있다는 사실이 모든 코드의 안전성을 자동으로 보장하지는 않지만, 여러 프로젝트와 연구자가 같은 코드를 검토하고 문제를 공유할 수 있는 기반을 제공한다.
업스트림과 공동체의 공유
배포판은 Linux 커널, GNU 도구, GNOME, KDE Plasma와 수많은 응용 프로그램을 공동으로 사용한다. 하나의 업스트림 프로젝트에서 이루어진 개선은 각 배포판이 새 버전을 채택하면서 전체 생태계로 확산될 수 있다.
배포판에서 발견된 오류와 하드웨어 문제도 업스트림으로 전달될 수 있다. 수정 사항이 원본 프로젝트에 포함되면 다른 배포판도 같은 해결책을 사용할 수 있고, 배포판마다 동일한 패치를 계속 유지할 필요가 줄어든다.
대규모 공동체는 번역, 문서, 버그 보고와 다양한 하드웨어 시험에 참여한다. 기업은 개발자를 고용하고 빌드 서버, 보안 대응과 장기 지원을 제공하면서 같은 생태계에 기여할 수 있다.
다양한 지원 모델
Linux 배포판은 무료 공동체 지원부터 기업의 유료 기술 지원까지 여러 운영 방식을 제공한다. 개인 사용자는 공동체 문서와 포럼을 이용할 수 있고, 조직은 응답 시간과 지원 범위가 명시된 계약을 체결할 수 있다.
Red Hat Enterprise Linux, SUSE Linux Enterprise와 Ubuntu LTS 등은 장기 지원, 하드웨어·응용 프로그램 인증과 기업용 관리 서비스를 제공한다. Debian, Fedora와 Arch Linux 같은 공동체 배포판은 공개 개발과 사용자 참여를 중심으로 유지된다.
이러한 선택지는 같은 Linux 생태계 안에서 개인 실험 환경, 무료 서버와 지원 계약이 필요한 기업 시스템을 모두 구성할 수 있게 한다.
오래된 시스템과 최신 시스템의 병행
고정 릴리스, 장기 지원 릴리스와 롤링 릴리스가 함께 존재하므로 사용자는 변화 속도를 선택할 수 있다. 서버는 오랫동안 유지되는 배포판을 사용하고, 개발용 컴퓨터는 최신 컴파일러와 라이브러리를 제공하는 배포판을 사용할 수 있다.
컨테이너와 Flatpak 같은 기술을 이용하면 안정된 호스트 운영체제를 유지하면서 일부 응용 프로그램만 더 새로운 사용자 공간에서 실행할 수도 있다. Flatpak 런타임은 특정 배포판 버전에 종속되지 않는 공통 기반을 제공한다.[175]
한계
배포판과 패키지의 분산
Linux 배포판은 하나의 통일된 패키지와 설정 체계를 사용하지 않는다. Debian 계열의 deb와 APT, Fedora·Red Hat·SUSE 계열의 RPM, Arch Linux의 pkg.tar.zst, Alpine Linux의 apk 등 여러 형식과 관리자가 병존한다.
같은 프로그램을 배포판마다 별도로 패키징하고 시험해야 하므로 유지 관리 작업이 중복될 수 있다. 패키지 이름, 파일 경로, 빌드 옵션과 서비스 설정도 달라 소프트웨어 공급자가 하나의 패키지만으로 모든 배포판을 지원하기 어렵다.
Linux Standard Base는 배포판 간 바이너리 호환성을 높이기 위한 공통 규격을 제시했지만, 최종 LSB 5.0은 2015년에 발표되었으며 현대 응용 프로그램 배포가 LSB 하나로 통일되지는 않았다.[176]
Flatpak, Snap, AppImage와 컨테이너가 이러한 차이를 줄일 수 있지만, 새로운 패키지 저장소와 업데이트 경로를 추가하여 소프트웨어를 어디에서 설치하고 누가 유지하는지 판단해야 하는 문제도 만든다.
완전하지 않은 배포판 간 호환성
Linux 커널과 ELF 실행 파일 형식을 공유하더라도 모든 Linux 바이너리가 모든 배포판에서 실행되는 것은 아니다. CPU 아키텍처, C 라이브러리, 동적 링커, 라이브러리 ABI와 컴파일 옵션이 맞아야 한다.
glibc 기반 배포판용 프로그램은 musl 기반 시스템에서 직접 실행되지 않을 수 있으며, 최신 배포판용 바이너리는 이전 배포판에 없는 라이브러리 버전을 요구할 수 있다. 같은 RPM이나 deb 형식을 사용하는 배포판 사이에서도 패키지 의존성과 정책이 달라 직접 설치가 안전하지 않을 수 있다.
Linux 커널의 시스템 호출 인터페이스는 강한 하위 호환성을 유지하지만, 커널 내부 드라이버 인터페이스는 같은 방식으로 고정되지 않는다. 외부 커널 모듈은 새 커널에 맞춰 수정하거나 다시 빌드해야 할 수 있다. 커널 문서도 사용자 공간 인터페이스와 달리 안정된 커널 내부 드라이버 인터페이스를 유지하지 않는 이유를 설명한다.[177]
상용 소프트웨어 지원의 차이
Linux용 프로그램이 존재하더라도 공급자가 모든 배포판을 공식 지원하는 것은 아니다. 상용 데이터베이스, 설계 도구, 게임과 기업용 응용 프로그램은 특정 Ubuntu 또는 Red Hat Enterprise Linux 릴리스만 지원 대상으로 지정할 수 있다.
다른 배포판에서 기술적으로 실행할 수 있어도 공급자가 문제를 재현하거나 지원하지 않을 수 있다. 패키지 형식과 라이브러리 버전이 다르면 사용자가 별도의 변환, 컨테이너 또는 호환 환경을 구성해야 한다.
Windows나 macOS만 대상으로 개발된 응용 프로그램은 Linux용 버전이 없을 수 있다. Wine과 Proton 같은 호환 계층이 일부 프로그램과 게임을 실행할 수 있게 하지만, 모든 기능과 업데이트에서 완전한 호환성을 보장하지는 않는다.
하드웨어 지원의 편차
Linux 커널은 폭넓은 장치를 지원하지만 모든 하드웨어가 동일한 수준으로 동작하는 것은 아니다. 제조사가 드라이버, 펌웨어나 기술 문서를 제공하지 않으면 공동체가 장치를 완전히 지원하기 어렵다.
일부 무선 네트워크 장치, 지문 인식기, 전문 오디오·영상 장비와 노트북의 특수 기능은 제한적으로 동작할 수 있다. 새 장치는 최신 커널과 펌웨어를 요구하는 반면, 배포판의 안정 릴리스가 이를 아직 제공하지 않을 수도 있다.
배포판의 자유 소프트웨어 정책에 따라 비자유 펌웨어와 독점 드라이버의 기본 제공 여부도 다르다. 같은 컴퓨터라도 배포판 설치 이미지에 포함된 펌웨어와 커널 버전에 따라 초기 설치 경험이 달라질 수 있다.
선택의 복잡성
배포판, 데스크톱 환경, 패키지 형식과 릴리스 모델이 다양하다는 점은 처음 접하는 사용자에게 선택 부담이 될 수 있다. 이름과 외형이 비슷한 배포판도 지원 기간, 기반 저장소와 프로젝트 규모가 다르다.
인터넷의 해결 방법은 특정 배포판과 버전을 전제로 작성되는 경우가 많다. 다른 배포판의 명령을 그대로 실행하면 존재하지 않는 패키지를 설치하려 하거나 저장소와 시스템 설정을 손상시킬 수 있다.
여러 데스크톱 환경과 서드파티 저장소를 함께 사용하면 설정 도구와 응용 프로그램이 중복되고, 파일 연결이나 테마가 일관되지 않을 수 있다. 사용자는 시스템 계층과 응용 프로그램 계층의 설치 방식을 구분해야 할 수 있다.
관리와 업데이트 부담
롤링 릴리스는 최신 소프트웨어를 제공하지만 지속적인 변경을 따라가야 한다. 장기간 업데이트하지 않은 시스템을 한 번에 갱신하면 패키지 교체와 설정 변환이 복잡해질 수 있다.
고정 릴리스는 변화가 적지만 지원 종료 전에 다음 릴리스로 업그레이드해야 한다. 여러 주 버전을 건너뛰지 못하거나 업그레이드 도중 서비스 중단이 필요한 배포판도 있다.
공식 저장소 밖에서 설치한 프로그램은 배포판 패키지 관리자와 별도의 업데이트 체계를 사용할 수 있다. 서드파티 저장소, 언어별 패키지 관리자, Flatpak과 컨테이너를 함께 사용하면 각 경로의 보안 업데이트와 지원 상태를 따로 관리해야 한다.
소규모 파생판의 지속 가능성
기존 배포판을 기반으로 새로운 파생판을 만드는 것은 비교적 쉽지만 장기간 유지하는 것은 별개의 문제다. 자체 저장소, 설치 이미지, 보안 업데이트, 웹사이트와 사용자 지원을 계속 운영하려면 인력과 비용이 필요하다.
핵심 개발자가 활동을 중단하거나 기반 배포판이 구조를 변경하면 파생판의 업데이트가 지연되거나 프로젝트가 중단될 수 있다. 기반 배포판의 패키지를 많이 수정한 파생판일수록 새 릴리스와 변경 사항을 병합하는 비용이 커진다.
프로젝트가 중단되어도 설치된 시스템은 당분간 작동할 수 있지만 새로운 보안 문제와 저장소 인증서, 하드웨어 변화에 대응하지 못한다. 파생판을 선택할 때는 기능과 외형뿐 아니라 개발 인력, 릴리스 기록과 기반 배포판으로 돌아갈 수 있는 경로도 고려해야 한다.
자유와 편의성 사이의 차이
자유 소프트웨어만 제공하는 배포판은 사용자가 시스템 전체의 소스 코드를 검토하고 수정할 수 있는 환경을 제공한다. 그러나 비자유 펌웨어가 필요한 장치나 독점 응용 프로그램은 사용할 수 없거나 기능이 제한될 수 있다.
반대로 비자유 펌웨어와 드라이버를 쉽게 설치할 수 있는 배포판은 하드웨어 호환성과 사용자 편의성이 높을 수 있지만, 모든 구성 요소를 자유롭게 수정·재배포할 수 있는 것은 아니다.
GNU의 자유 시스템 배포판 지침은 비자유 소프트웨어를 포함하거나 사용하도록 유도하지 않는 배포판의 기준을 정의한다.[178] 이 기준을 어디까지 적용할지는 배포판의 철학과 사용자의 우선순위에 따라 달라진다.
Linux 배포판의 장점과 한계는 서로 분리된 특성이 아니다. 다양성은 전문화를 가능하게 하지만 호환성과 선택의 복잡성을 만들고, 빠른 업데이트는 최신 기술을 제공하지만 변화 관리가 필요하다. 따라서 배포판은 절대적인 우열보다 사용 목적, 하드웨어, 필요한 소프트웨어와 유지 관리 능력을 기준으로 평가해야 한다.
관련 문서
- Linux
- Linux 커널
- GNU
- GNU/Linux
- 운영체제
- 유닉스 계열
- Linux 배포판 목록
- Debian
- Ubuntu
- Fedora
- Red Hat Enterprise Linux
- CentOS Stream
- Arch Linux
- openSUSE
- SUSE Linux Enterprise
- Gentoo Linux
- Slackware
- Alpine Linux
- NixOS
- Android
- 패키지 관리 시스템
- 소프트웨어 저장소
- Filesystem Hierarchy Standard
- Linux Standard Base
- POSIX
- Flatpak
- Snap
- AppImage
- 컨테이너
- 데스크톱 환경
- 자유 소프트웨어
- 오픈 소스 소프트웨어
- Debian: Debian derivatives ↩
- Debian Wiki: DEX ↩
- Linux Kernel Documentation ↩
- GNU Project: What is GNU? ↩
- GNU Project: GNU/Linux FAQ ↩
- Debian: Debian derivatives ↩
- Debian Wiki: Derivatives ↩
- Ubuntu Community: Flavour Guidelines ↩
- Ubuntu: Ubuntu flavours ↩
- Linux Distribution HOWTO ↩
- LWN: A Short History of Linux Distributions ↩
- ibiblio: Historic Linux Distribution Archive ↩
- Slackware Linux 1.00 Release Announcement ↩
- Slackware Documentation: Slackware ↩
- Debian Project History: A Detailed History ↩
- Red Hat Brand Standards: History ↩
- Red Hat Enterprise Linux Documentation: Introduction to RPM ↩
- Red Hat: The Fedora Project, Open Source Evolved ↩
- Ubuntu: About the Ubuntu Project ↩
- Ubuntu: 20 Years of Ubuntu ↩
- KDE Timeline ↩
- GNOME: About ↩
- GNOME Foundation: GNOME 1.0 Released ↩
- Android Open Source Project: Kernel Overview ↩
- Android Open Source Project: Generic Kernel Image ↩
- Docker: What is a Container? ↩
- Kubernetes: What is Kubernetes? ↩
- Flatcar Container Linux Documentation ↩
- OSTree: Atomic Upgrades ↩
- Fedora Docs: Atomic Desktops Technical Information ↩
- Fedora Docs: Updates, Upgrades and Rollbacks ↩
- Debian: Debian derivatives ↩
- Debian Derivatives Census: Ubuntu ↩
- Fedora Docs: Fedora and Red Hat Enterprise Linux ↩
- Fedora Discussion: Red Hat removes public access to RHEL source code ↩
- ArchWiki: Arch Linux ↩
- ArchWiki: Arch-based distributions ↩
- Steam: SteamOS ↩
- openSUSE News: openSUSE Leap 15.3 Bridges Path to Enterprise ↩
- SUSE: How SUSE builds its Enterprise Linux distribution, part 5 ↩
- ChromiumOS Developer Guide ↩
- Slackware Documentation: Slackware ↩
- ArchWiki: Arch Linux ↩
- Linux Mint: LMDE ↩
- Steam: SteamOS ↩
- Steam Deck ↩
- Linux Kernel Documentation: Linux ABI description ↩
- musl libc: About musl ↩
- systemd: System and Service Manager ↩
- GNU GRUB Manual ↩
- systemd-boot ↩
- Debian Installation Guide: How the Installer Works ↩
- Anaconda Documentation: Introduction to Anaconda ↩
- Calamares: About ↩
- GNOME ↩
- The Plasma Handbook ↩
- Linux Kernel Documentation: The Linux Kernel Device Model ↩
- Linux Kernel Documentation: Firmware API Introduction ↩
- Debian FAQ: Basics of the Debian package management system ↩
- RPM Package Manager ↩
- RPM Manual: rpm(8) ↩
- Pacman Home Page ↩
- Debian Wiki: Debian Package Management ↩
- Debian Wiki: SourcesList ↩
- DNF Configuration Reference ↩
- Debian Administrator's Handbook: Package Meta-information ↩
- Debian Policy Manual: Declaring relationships between packages ↩
- RPM Documentation: Dependencies ↩
- DNF API: Base ↩
- RPM Package Manager ↩
- ArchWiki: Arch User Repository ↩
- Debian Wiki: Reproducible Builds ↩
- Flatpak Documentation: Basic Concepts ↩
- Flatpak Documentation: Using Flatpak ↩
- Flatpak Documentation: Repositories ↩
- Snap Documentation: Channels and tracks ↩
- Snap Documentation: Snap confinement ↩
- AppImage Documentation: Introduction ↩
- AppImage Documentation: Concepts ↩
- Debian Wiki: SourcesList ↩
- Debian: Debian Releases ↩
- Arch Linux: About ↩
- Arch Linux: Releases ↩
- openSUSE News: Slowroll Set for a Quarter of Updates ↩
- Ubuntu: Release cycle ↩
- Debian: Debian Releases ↩
- OSTree: Overview ↩
- rpm-ostree: A true hybrid image/package system ↩
- Fedora Docs: Fedora Linux Release Life Cycle ↩
- Debian Developer's Reference ↩
- Debian Developer's Reference: Sponsoring packages ↩
- ArchWiki: Creating packages ↩
- ArchWiki: Arch User Repository ↩
- Fedora Project: Koji ↩
- Open Build Service ↩
- ArchWiki: PKGBUILD ↩
- Reproducible Builds ↩
- ArchWiki: Reproducible builds ↩
- Debian Continuous Integration ↩
- Fedora Docs: Bodhi ↩
- openQA ↩
- Debian Security Information ↩
- Fedora Project: Security Bugs ↩
- ArchWiki: Package signing ↩
- Debian Constitution ↩
- Fedora Project: Fedora Council ↩
- Fedora Project: FESCo ↩
- Fedora Docs: Installing and Switching Desktop Environments ↩
- Fedora Linux ↩
- GNOME Internationalization: Accessibility for All over the World ↩
- KDE Plasma Desktop ↩
- Ubuntu Flavors ↩
- KDE UserBase: Accessibility in Plasma ↩
- KDE Plasma 6.5 ↩
- Xfce: About ↩
- Ubuntu Flavors ↩
- LXQt: About ↩
- i3 Window Manager ↩
- Sway ↩
- GNOME Internationalization: Accessibility for All over the World ↩
- KDE UserBase: Accessibility in Plasma ↩
- KDE Community: Translation ↩
- GNOME Wiki Archive: Translation ↩
- Ubuntu Desktop documentation ↩
- Red Hat Enterprise Linux Server ↩
- Red Hat Enterprise Linux ↩
- Debian: Download Debian ↩
- The Yocto Project ↩
- Android Open Source Project: Kernel overview ↩
- OpenWrt Project ↩
- OpenWrt: Supported devices ↩
- Kali Linux Documentation: What is Kali Linux? ↩
- Fedora Scientific Lab ↩
- Debian Edu: About Debian Edu ↩
- Ubuntu Studio: Help ↩
- Steam Deck: Software ↩
- Lakka ↩
- SystemRescue ↩
- Debian: Ports ↩
- Fedora Linux Release Life Cycle ↩
- Ubuntu release cycle ↩
- Ubuntu release cycle ↩
- Fedora Linux Release Life Cycle ↩
- GNU: Free System Distribution Guidelines ↩
- GNU/Linux Distros ↩
- GNU: Explaining Why We Don't Endorse Other Systems ↩
- Filesystem Hierarchy Standard: Introduction ↩
- Filesystem Hierarchy Standard: The Root Filesystem ↩
- Filesystem Hierarchy Standard: The /usr Hierarchy ↩
- Filesystem Hierarchy Standard: The /var Hierarchy ↩
- Filesystem Hierarchy Standard ↩
- Linux Standard Base Core Specification for X86-64 ↩
- Linux Standard Base 5.0 Specifications ↩
- Linux Standard Base: lsb_release ↩
- The Open Group Base Specifications Issue 8 ↩
- Linux Standard Base: Executable and Linking Format ↩
- Flatpak Documentation: Introduction ↩
- Flatpak Documentation: Publishing ↩
- Snap Documentation: Install the daemon ↩
- AppImage Documentation: Concepts ↩
- AppImage Documentation: A word on upstream packaging ↩
- Fedora Docs: Fedora Spins & Labs ↩
- Debian: Debian derivatives ↩
- Debian Wiki: Debian Derivatives ↩
- Debian Derivatives Front Desk ↩
- Debian Wiki: DEX ↩
- Fedora Docs: Switching desktop environments ↩
- Flatpak Documentation: Basic concepts ↩
- Flatpak Documentation: Available Runtimes ↩
- Open Container Initiative: Image Format Specification ↩
- Open Container Initiative: Image Index Specification ↩
- Debian: Debian derivatives ↩
- Linux Kernel Documentation: Linux ABI description ↩
- Reproducible Builds ↩
- Flatpak Documentation: Basic concepts ↩
- Linux Standard Base 5.0 Specifications ↩
- Linux Kernel Documentation: The Linux Kernel Driver Interface ↩
- GNU: Free System Distribution Guidelines ↩