Ubuntu

Ubuntu 계열

UbuntuDebian 기반	Ubuntu · Ubuntu Server · Ubuntu Core · Edubuntu · Kubuntu · Lubuntu · Ubuntu Budgie · Ubuntu Cinnamon · Ubuntu Kylin · Ubuntu MATE · Ubuntu Studio · Ubuntu Unity · Xubuntu · Bodhi Linux · elementary OS · KDE neon · Linux Lite · Pop!_OS · Zorin OS · Trisquel · Uruk GNU/Linux
	Linux Mint	Linux Mint · HamoniKR · Feren OS Classic

Ubuntu의 탄생

Ubuntu의 기원은 2004년 마크 셔틀워스가 새로운 Linux 배포판 프로젝트를 조직하면서 시작되었다. 프로젝트는 이미 방대한 패키지 저장소와 강력한 커뮤니티를 갖춘 Debian을 기반으로 하되, 일반 사용자가 설치하고 관리하기 쉬우며 일정한 주기로 새로운 버전을 받을 수 있는 운영체제를 만드는 것을 목표로 했다. 당시 개발 초기에는 프로젝트 이름이 정해지지 않아 no-name-yet이라는 이름으로 알려졌으며, 2004년 9월 프로젝트의 정식 이름이 Ubuntu로 발표되었다.^[6]

'Ubuntu'라는 이름은 남아프리카의 여러 문화권에서 사용되는 개념인 우분투(ubuntu)에서 가져왔다. 일반적으로 다른 사람과의 관계 속에서 인간성을 설명하는 개념으로 해석되며, Ubuntu 프로젝트는 이를 자유 소프트웨어를 누구나 사용할 수 있도록 한다는 프로젝트의 방향과 연결하였다.

Ubuntu 프로젝트와 함께 셔틀워스는 프로젝트를 재정적으로 지원하고 개발자를 고용하며 상용 지원 사업을 담당하는 Canonical을 설립하였다. 이에 따라 Ubuntu는 처음부터 커뮤니티 기반 자유 소프트웨어 프로젝트와 이를 장기적으로 지원하는 기업 조직을 함께 갖춘 형태로 개발되었다.

Debian과의 관계

Ubuntu는 처음부터 Debian의 패키지 생태계와 개발 성과를 적극적으로 활용하는 배포판으로 설계되었다. 최초 릴리스인 Ubuntu 4.10도 당시 Debian unstable의 스냅샷을 기반으로 만들어졌으며, Ubuntu 개발자는 Debian에서 제공되는 수많은 소스 패키지를 가져와 Ubuntu의 릴리스 일정과 정책에 맞추어 통합하였다.^[7]

다만 Ubuntu는 Debian의 단순한 재배포판으로 머물지 않았다. Debian이 준비된 기능과 패키지 상태를 중심으로 릴리스 시점을 결정해 온 것과 달리 Ubuntu는 처음부터 시간 기반 릴리스를 핵심 정책으로 채택했다. 약 6개월마다 새로운 버전을 공개하는 일정이 고정되면서, 특정 시점의 Debian 개발판을 기반으로 패키지를 가져온 뒤 Ubuntu 자체의 통합, 수정, 테스트 과정을 거쳐 하나의 릴리스를 완성하는 개발 방식이 자리잡았다.^[8]

이 관계는 이후에도 유지되어 Ubuntu의 많은 패키지가 Debian에서 유래하며 양쪽 프로젝트 사이에서 수정 사항이 공유된다. 동시에 Ubuntu는 자체 커널 구성, 설치 프로그램, 데스크톱 환경, 하드웨어 지원, 클라우드 도구와 배포 정책 등을 발전시키면서 독립적인 배포판 생태계를 형성하였다.

Canonical의 설립

Canonical은 Ubuntu 개발을 지원하기 위해 마크 셔틀워스가 2004년에 설립한 회사이다. Canonical은 Ubuntu 자체를 유료 운영체제로 판매하는 대신 배포판과 핵심 업데이트를 자유롭게 제공하고, 기업 지원, 시스템 관리, 인증, 컨설팅과 장기 보안 유지보수 등의 서비스를 통해 사업을 운영하는 구조를 채택했다.

프로젝트 초기부터 Canonical의 유급 개발자와 외부 커뮤니티 개발자가 같은 Ubuntu 개발 과정에 참여하였다. 이후 Canonical은 Launchpad를 비롯한 개발 인프라를 운영하고 Ubuntu Desktop, Ubuntu Server, 클라우드 이미지, Ubuntu Core 등의 개발에 직접 참여하면서 Ubuntu의 주요 개발 조직으로 자리잡았다.

2005년에는 셔틀워스와 Canonical이 Ubuntu Foundation 설립을 발표하고 초기 자금으로 1,000만 미국 달러를 출연하였다. 당시 재단은 Ubuntu 프로젝트의 지속성과 장기간의 릴리스 지원을 보장하기 위한 법적·재정적 기반으로 제시되었다.^[9]

Ubuntu 4.10

2004년 10월 20일 최초의 정식 버전인 Ubuntu 4.10 "Warty Warthog"가 공개되었다. 버전 번호 4.10은 2004년 10월에 공개되었다는 의미이며, 이후 Ubuntu 버전 번호의 기본적인 명명 방식이 되었다.

Ubuntu 4.10은 Debian의 폭넓은 소프트웨어를 기반으로 하면서 빠르고 비교적 단순한 설치 과정, 약 6개월 간격의 정기 릴리스, 엄선된 기본 프로그램과 보안 업데이트 제공을 주요 특징으로 내세웠다. 최초 발표에서 Ubuntu는 모든 최종 사용자용 기본 프로그램을 자유 소프트웨어로 구성하고 배포판 자체를 무료로 제공하며, 각 릴리스에 18개월의 보안 및 기술 지원을 제공하겠다고 밝혔다.^[10]

최초 버전부터 각 릴리스에는 형용사와 동물 이름을 결합한 코드명이 사용되었다. Warty Warthog 이후 이러한 코드명은 Ubuntu 릴리스의 대표적인 전통으로 자리잡았다.

초기 성장

Ubuntu는 초기 몇 년 동안 빠르게 커뮤니티와 사용자층을 확대하였다. 2005년에는 포르투갈, 이탈리아, 프랑스, 일본 등에서 초기 LoCo(Local Community) 팀이 조직되었고, 같은 해 최초의 공식 Ubuntu Flavor인 Kubuntu 5.04가 공개되었다.^[11]

초기 확산에 중요한 역할을 한 서비스 가운데 하나는 ShipIt이었다. 인터넷 연결 속도가 느리거나 대용량 ISO 이미지를 다운로드하기 어려웠던 사용자가 Ubuntu 설치 CD를 무료로 요청할 수 있도록 한 프로그램으로, 전 세계 사용자에게 실제 설치 매체를 우편으로 배송했다. ShipIt은 광대역 인터넷과 다운로드 방식의 보급이 확대된 뒤 2011년 종료되었다.^[12]

2006년 6월에는 Ubuntu 6.06 LTS "Dapper Drake"가 공개되었다. 이 버전은 Ubuntu 최초의 Long Term Support(LTS) 릴리스였으며, 정기적인 단기 릴리스와 별도로 장기간 안정성과 보안 업데이트를 제공하는 Ubuntu의 릴리스 모델을 확립했다. 이후 약 2년마다 4월에 새로운 LTS가 공개되는 체계가 자리잡았다.^[13]

데스크톱 Linux 시장에서의 확산

Ubuntu 초기 개발의 가장 중요한 목표 가운데 하나는 Linux 데스크톱을 일반 사용자가 보다 쉽게 사용할 수 있도록 만드는 것이었다. 설치 과정, 하드웨어 자동 인식, 소프트웨어 관리와 시스템 설정을 단순화하고, 데스크톱에서 사용할 프로그램을 기본 설치 이미지에 통합하는 방식은 Ubuntu가 기존 Linux 사용자뿐 아니라 처음 Linux를 접하는 사용자에게도 알려지는 데 영향을 주었다.

Ubuntu는 초기에는 GNOME 2를 기본 데스크톱 환경으로 사용했고, KDE를 사용하는 Kubuntu와 이후 Xfce 기반 Xubuntu, LXDE 및 LXQt 계열의 Lubuntu 등 서로 다른 데스크톱을 사용하는 Flavor가 등장했다. 이를 통해 공통 Ubuntu 패키지 기반을 유지하면서도 다양한 데스크톱 환경을 선택할 수 있는 생태계가 형성되었다.

2008년에는 Windows 파티션 내부에 Ubuntu를 설치하고 제거할 수 있게 한 Wubi가 제공되면서 기존 Windows 사용자가 별도의 전통적인 디스크 파티셔닝 없이 Ubuntu를 경험할 수 있는 경로도 마련되었다. 같은 시기 Canonical은 데스크톱 외의 시장에도 Ubuntu를 확장하기 시작하였다.^[14]

Unity의 도입

Canonical은 데스크톱과 넷북에서 보다 일관된 사용자 경험을 제공하기 위해 자체 사용자 인터페이스인 Unity를 개발하였다. Unity는 처음에 Ubuntu Netbook Edition을 중심으로 개발되었으며, Ubuntu 11.04 "Natty Narwhal"부터 Ubuntu Desktop의 기본 인터페이스로 채택되었다.^[15]

Unity는 화면 왼쪽의 Launcher, 상단 패널, Dash 기반 검색과 애플리케이션 실행 등의 인터페이스를 사용했다. Canonical은 기존 데스크톱 인터페이스와 다른 설계를 통해 작은 노트북 화면부터 일반 데스크톱까지 효율적으로 사용할 수 있는 환경을 만드는 것을 목표로 했다.

Unity의 도입은 Ubuntu 데스크톱의 정체성을 크게 변화시켰다. 기존 GNOME 인터페이스를 그대로 제공하기보다 Ubuntu가 자체 사용자 경험을 적극적으로 설계하기 시작했으며, 이후 디스플레이 서버 Mir, Unity 8과 모바일 Ubuntu 등의 자체 기술 개발로 이어졌다.

모바일과 컨버전스 전략

2010년대 초 Canonical은 Ubuntu를 PC 운영체제를 넘어 스마트폰, 태블릿과 기타 장치까지 확장하는 전략을 추진하였다. 이 전략의 핵심에는 동일한 운영체제와 애플리케이션 환경이 여러 종류의 화면과 입력 방식에 적응하는 컨버전스(convergence) 개념이 있었다.

Canonical은 스마트폰용 Ubuntu와 Ubuntu Touch, 차세대 인터페이스인 Unity 8, 자체 디스플레이 서버인 Mir를 개발하였다. 스마트폰을 모니터와 키보드에 연결했을 때 데스크톱과 유사한 작업 환경으로 전환하는 구상도 컨버전스 전략의 일부였다.

일부 제조사를 통해 Ubuntu 기반 스마트폰이 실제로 출시되었고 태블릿용 제품도 등장했지만, 모바일 생태계에서 Android와 iOS가 이미 강력한 플랫폼을 구축하고 있던 상황에서 Ubuntu Phone은 충분한 규모의 응용 프로그램과 하드웨어 생태계를 확보하지 못했다.

2017년 4월 마크 셔틀워스는 Canonical이 Unity 8과 스마트폰·컨버전스 셸에 대한 투자를 종료한다고 발표하였다. 회사의 개발 역량을 Ubuntu Desktop의 지속적인 개발과 함께 클라우드 및 IoT 분야에 더 집중하는 방향으로 전환한 것이다.^[16]

Canonical이 모바일 개발에서 철수한 이후 Ubuntu Touch는 커뮤니티 프로젝트인 UBports에 의해 계승되었다.

GNOME으로의 복귀

Unity 8과 컨버전스 전략 종료와 함께 Canonical은 Ubuntu Desktop의 기본 환경을 다시 GNOME 기반으로 전환하기로 결정하였다. 당초 발표에서는 Ubuntu 18.04 LTS부터 GNOME을 기본 데스크톱으로 사용할 예정이라고 밝혔지만, 실제 전환은 개발 과정에서 앞당겨져 Ubuntu 17.10 "Artful Aardvark"부터 GNOME Shell이 기본 세션으로 사용되었다.^[17]

Ubuntu의 GNOME 환경은 완전히 수정되지 않은 GNOME을 그대로 제공하기보다는 Ubuntu의 기존 사용 경험을 일부 유지하도록 구성되었다. 예를 들어 Dock과 테마, 기본 확장 기능 등을 통해 Unity 시절의 일부 작업 흐름을 이어갔다. 기존 Unity 7 역시 패키지를 통해 별도로 설치할 수 있었다.

이 전환으로 Canonical은 자체 데스크톱 셸 전체를 유지하는 부담을 줄이고 GNOME 업스트림과 보다 밀접하게 협력하는 방향으로 돌아갔다. 이후 GNOME은 현재까지 Ubuntu Desktop의 기본 데스크톱 환경으로 유지되고 있다.

Snap의 확대

Ubuntu는 전통적으로 Debian에서 이어진 deb 패키지와 APT를 핵심 소프트웨어 배포 방식으로 사용해 왔다. 그러나 릴리스마다 패키지 버전이 고정되고 안정 릴리스에는 큰 기능 변경을 제한하는 방식은 최신 데스크톱 응용 프로그램이나 여러 Ubuntu 버전에 동일한 프로그램을 배포하려는 개발자에게 제약이 될 수 있었다.^[18]

Canonical은 이러한 용도를 비롯해 데스크톱, 서버와 IoT 환경에서 하나의 응용 프로그램 패키지를 여러 시스템에 배포할 수 있도록 Snap 패키지 형식을 개발하였다. Snap 패키지는 응용 프로그램과 필요한 종속성을 함께 묶을 수 있고, 자동 업데이트와 격리 기능을 제공하도록 설계되었다.

2016년에는 Snap이 Ubuntu에 본격적으로 도입되었으며, 같은 해 장치용 운영체제인 Ubuntu Core에서도 Snap을 시스템 구성의 핵심 단위로 사용하기 시작했다.^[19]

이후 Canonical은 일부 기본 데스크톱 응용 프로그램을 Snap으로 전환하고 Snap Store를 주요 응용 프로그램 배포 채널 가운데 하나로 확대하였다. 한편 deb와 APT 역시 Ubuntu의 기본 시스템과 패키지 저장소를 구성하는 핵심 기술로 계속 사용되고 있어 두 패키지 체계가 함께 존재한다.

클라우드와 서버 시장의 성장

Ubuntu의 발전은 데스크톱에만 국한되지 않았다. 2000년대 후반부터 클라우드 컴퓨팅이 빠르게 성장하면서 Ubuntu Server와 가상 머신용 Ubuntu 이미지의 사용 범위도 크게 확대되었다.

2008년에는 최초의 Ubuntu Cloud 이미지가 베타로 제공되었고, 2011년 Ubuntu는 OpenStack을 핵심 클라우드 플랫폼으로 채택하였다.^[20] 이후 Canonical은 OpenStack, Kubernetes, 컨테이너와 퍼블릭 클라우드를 Ubuntu의 주요 활용 영역으로 확대했다.

Ubuntu 이미지는 Amazon Web Services, Microsoft Azure, Google Cloud 등 주요 퍼블릭 클라우드에서 제공되었고, 서버와 클라우드에서 사용할 수 있는 장기 지원 버전과 보안 유지보수 체계가 발전하였다. Ubuntu는 하나의 데스크톱 배포판에서 출발했지만 시간이 지나면서 동일한 기본 시스템을 데스크톱, 물리 서버, 가상 머신, 컨테이너, 퍼블릭 클라우드와 IoT 장치까지 확장하는 플랫폼으로 변화하였다.

2017년 Canonical이 스마트폰과 Unity 8 투자를 종료할 때에도 클라우드와 IoT는 향후 Ubuntu 개발의 핵심 영역으로 명시되었다.^[21]

최근 개발

2020년대 Ubuntu는 기존의 6개월 릴리스와 2년 LTS 주기를 유지하면서 데스크톱, 서버, 클라우드와 장치 플랫폼을 함께 발전시키고 있다. LTS의 중요성도 계속 확대되어 Ubuntu 프로젝트에 따르면 전체 Ubuntu 설치 가운데 상당수가 LTS 계열을 사용한다.^[22]

2023년에는 Ubuntu Pro가 본격적으로 확대되면서 기존 main 저장소뿐 아니라 universe의 다수 패키지에 대해서도 확장된 보안 유지보수를 제공하는 체계가 강화되었다. 2024년에는 Ubuntu 24.04 LTS "Noble Numbat"가 공개되었으며 같은 해 Ubuntu는 최초 정식 버전 출시 20주년을 맞았다.^[23]

2026년 4월 23일에는 Ubuntu 26.04 LTS "Resolute Raccoon"이 공개되었다. 이 버전은 GNOME 50과 Wayland 기반 데스크톱을 제공하고, TPM 기반 전체 디스크 암호화, 응용 프로그램 권한 제어 개선, Arm용 Livepatch, 메모리 안전성을 고려한 Rust 기반 구성 요소 확대 등 보안과 시스템 기반의 변화를 포함하였다.^[24]

2026년 8월에는 첫 포인트 릴리스인 Ubuntu 26.04.1 LTS가 공개되어 26.04 출시 이후의 보안 업데이트와 주요 오류 수정이 설치 이미지에 통합되었다.^[25]

Ubuntu는 현재도 Debian에서 패키지와 소프트웨어 생태계의 상당 부분을 이어받으면서 Ubuntu 자체의 6개월 릴리스 체계와 LTS, 데스크톱 통합, 서버·클라우드 이미지, Snap과 Ubuntu Core, 기업용 보안 지원을 발전시키고 있다. 2004년 데스크톱 사용성을 중시한 새로운 Debian 기반 배포판으로 시작한 프로젝트가 데스크톱에서 서버, 클라우드, 컨테이너, IoT와 개발 환경까지 포괄하는 Linux 플랫폼으로 범위를 확장해 온 것이 Ubuntu 역사의 가장 큰 흐름이다.

Ubuntu는 Canonical이 주요 개발 인력과 인프라를 제공하면서도 외부 커뮤니티가 개발과 의사결정에 참여하는 형태로 운영된다. Canonical은 Ubuntu의 배포자이자 6개월 주기의 정식 릴리스, LTS 릴리스, 보안 업데이트와 주요 온라인 인프라의 제공을 책임지지만, Ubuntu의 거버넌스 전체가 Canonical 내부 조직으로 구성되는 것은 아니다. 커뮤니티 관련 사안은 Ubuntu Community Council, 배포판의 기술적 방향은 Ubuntu Technical Board를 중심으로 다루며, 이들은 필요에 따라 여러 위원회와 팀에 권한을 위임한다.^[26]

Ubuntu는 가능한 경우 투표보다 합의에 의해 결정을 내리는 것을 지향한다. 특정 영역의 담당 팀과 실제 작업을 수행할 개발자의 의견을 바탕으로 합의를 찾으며, 합의가 이루어지지 않거나 프로젝트 전체 차원의 결정이 필요한 경우 정해진 거버넌스 구조를 통해 문제를 상위 기관으로 넘길 수 있다. Ubuntu의 Code of Conduct는 이러한 협업과 의사결정 과정에서 구성원에게 요구되는 행동 기준의 기반으로 사용된다.^[27]

Canonical

Canonical은 Ubuntu를 창설한 마크 셔틀워스가 2004년 설립한 회사로, Ubuntu의 주요 후원자이자 배포자이다. Canonical은 Ubuntu의 커널, 기본 데스크톱, 기반 시스템, 보안, OpenStack, Kubernetes 등 여러 핵심 영역에 개발 인력을 투입하며 정기 릴리스와 LTS를 실제 제품으로 통합하고 배포하는 역할을 맡는다.^[28]

Canonical은 Ubuntu의 6개월 정기 릴리스와 LTS 릴리스 제공, 보안 업데이트, 상용 지원 및 Ubuntu 커뮤니티가 사용하는 주요 온라인 인프라의 운영을 담당한다. 기업을 대상으로는 Ubuntu Pro, 시스템 관리와 보안 유지보수, 기술 지원과 각종 관리형 서비스를 제공하며 이 사업이 Ubuntu 개발을 지속하기 위한 주요 경제적 기반을 이룬다.^[29]

그러나 Canonical 직원이라는 이유만으로 Ubuntu 아카이브에 패키지를 자유롭게 업로드할 수 있는 것은 아니다. Ubuntu의 공식 개발 문서에서는 Canonical 직원 역시 일반 커뮤니티 개발자와 동일한 절차를 거쳐 필요한 업로드 권한을 획득하도록 규정하고 있다.^[30]

Canonical과 Ubuntu 프로젝트의 관계는 따라서 단순한 기업 내부 개발 조직과 제품의 관계와는 다르다. Canonical은 많은 핵심 개발자를 고용하고 릴리스를 실질적으로 제작하는 중심 조직이지만, 배포판의 커뮤니티·기술 거버넌스에는 별도의 공개적인 의사결정 구조가 존재한다.

마크 셔틀워스는 프로젝트 창립자와 후원자로서 거버넌스에서도 특별한 위치를 갖는다. Community Council과 Technical Board 후보 선정 과정에 관여하고, 필요한 경우 두 기관의 표결에서 결정표를 행사할 수 있다. Ubuntu의 거버넌스 문서는 이 역할을 전통적으로 SABDFL(Self-Appointed Benevolent Dictator For Life)이라고 표현해 왔다.^[31]

Ubuntu 커뮤니티

Ubuntu 커뮤니티는 Canonical 직원뿐 아니라 전 세계의 개인 개발자, 패키지 유지관리자, 번역자, 문서 작성자, 디자이너, 테스터, 지원 커뮤니티 운영자와 지역 커뮤니티 등으로 구성된다. Ubuntu 프로젝트는 패키징만을 개발 기여로 보지 않으며 번역, 문서화, 품질 보증, 디자인, 사용자 지원 등 다양한 활동을 공식적인 프로젝트 기여로 취급한다.^[32]

커뮤니티에는 특정한 하나의 중앙 조직만 존재하는 것이 아니라 기능별로 여러 팀과 하위 프로젝트가 구성되어 있다. 예를 들어 Desktop Team은 Ubuntu 데스크톱 설치에 포함되는 패키지를 담당하고 Kernel Team은 Ubuntu용 Linux 커널을, Foundations Team은 Ubuntu 제품군 전체의 기반 시스템을 담당한다. 이외에도 서버, 보안, 고성능 컴퓨팅, 각 공식 Flavor와 지역 커뮤니티 등 다양한 조직이 존재한다.^[33]

Ubuntu에서는 프로젝트에 지속적이고 의미 있는 기여를 한 사람에게 Ubuntu Membership을 부여하는 제도도 운영한다. Membership은 단순한 계정 등록이 아니라 Ubuntu 프로젝트에 대한 지속적인 기여를 인정하는 지위이며, 일부 거버넌스 기관의 구성원 선출에도 사용된다.

프로젝트 규모가 확대되면서 모든 사안을 Community Council이나 Technical Board가 직접 처리하지는 않는다. 두 기관은 Membership Board와 각종 Team Council을 비롯한 하위 조직에 특정 권한을 위임할 수 있으며, 권한을 위임받은 조직은 원래 권한을 가진 상위 거버넌스 기관에 대해 책임을 진다.^[34]

Ubuntu Community Council

Ubuntu Community Council은 Ubuntu 프로젝트의 비기술적·사회적 사안을 담당하는 최상위 커뮤니티 거버넌스 기관이다. Ubuntu 커뮤니티의 조직 구조와 활동 절차를 감독하고, 다른 커뮤니티 위원회와 평의회의 구성 및 운영에 관여한다.^[35]

Community Council은 특히 Ubuntu Code of Conduct와 관련된 책임을 갖는다. 커뮤니티 구성원과 리더가 행동 강령에서 정한 기준을 지키도록 하고, 개별 커뮤니티 조직에서 해결하기 어려운 갈등이 발생한 경우 최종적인 분쟁 해결 기관 역할도 수행한다.^[36]

Council의 일부 권한은 하위 조직으로 위임된다. 예를 들어 Ubuntu Membership의 심사와 승인과 같은 업무는 별도의 Membership Board가 수행할 수 있으며, 각 조직은 Community Council로부터 위임받은 범위 안에서 독립적으로 결정을 내린다.

Community Council 구성원은 마크 셔틀워스가 후보자를 선정하고 전체 Ubuntu Membership의 투표를 통해 승인하는 구조를 사용한다.^[37]

Community Council은 다른 Ubuntu 거버넌스 조직들과 정기적인 Ubuntu Governance Sync Meeting도 수행한다. 이를 통해 서로 다른 위원회와 팀에서 진행되는 사안과 프로젝트 차원의 문제를 공유한다.^[38]

Technical Board

Ubuntu Technical Board는 Ubuntu 배포판의 기술적 방향에 관한 최고 의사결정 기관이다. 패키지 선택과 패키징 정책, 설치 시스템과 절차, 도구 체인, Linux 커널, 디스플레이 시스템, 라이브러리 버전과 의존성 등 Ubuntu 전체에 영향을 미치는 기술 사안을 담당한다.^[39]

일상적인 개발 결정이 모두 Technical Board를 거치는 것은 아니다. 각 패키지와 구성 요소를 담당하는 개발자와 팀이 대부분의 결정을 자체적으로 처리한다. 그러나 여러 팀에 동시에 영향을 주는 공통 기술이나 프로젝트 전체의 정책처럼 한 팀만으로 결정하기 어려운 문제가 발생하면 Technical Board가 관련 팀 사이의 합의를 조정하거나 최종 결정을 내릴 수 있다.

Technical Board는 Ubuntu Package Policy, 릴리스별 기능 목표와 패키지 선택 등 배포판의 공통 기술 정책에도 관여한다. main에 포함되어 Canonical의 전체 지원 대상이 되는 패키지와 기본 설치에 포함되는 구성 요소 등도 Technical Board의 책임 범위에 포함된다.^[40]

Technical Board는 Ubuntu 개발자에게 부여되는 공식적인 접근 권한과 개발자 지위의 최종적인 책임도 가진다. 실제 개별 개발자의 권한 심사는 대체로 Developer Membership Board(DMB)에 위임되어 있지만, DMB 자체는 Technical Board의 위임을 받아 활동한다.^[41]

Technical Board 구성원은 일정 임기로 선출되며 Ubuntu Developers가 후보에 대해 투표할 수 있다. Ubuntu의 공식 문서에 따르면 현재 구조에서 Board는 선출된 구성원과 마크 셔틀워스로 구성된다.^[42]

개발자와 패키지 유지관리자

Ubuntu의 개발자는 하나의 동일한 권한 집단이 아니라 경험과 담당 영역에 따라 서로 다른 업로드 권한을 가질 수 있다. Ubuntu 패키지 아카이브의 변경 권한은 신뢰 수준과 실제 기여 경험을 기준으로 단계적으로 부여된다.^[43]

직접 업로드 권한이 없는 개발자도 패키지 수정안을 작성할 수 있다. 이 경우 필요한 권한을 가진 다른 Ubuntu 개발자가 변경 사항을 검토하고 대신 업로드하는 sponsorship 절차를 이용한다. 이러한 작업 기록과 다른 개발자의 검토 경험은 이후 직접 업로드 권한을 신청할 때 기여 실적과 신뢰성을 판단하는 자료로 사용될 수 있다.^[44]

Ubuntu에는 여러 종류의 업로드 권한이 존재한다. Per-Package Uploader(PPU)는 특정 패키지에 대한 업로드 권한을 가지며, Packageset Uploader는 ubuntu-desktop이나 ubuntu-server처럼 일정한 범주로 묶인 패키지 집합을 담당할 수 있다.^[45][46]

MOTU(Masters of the Universe)는 주로 universe 영역의 패키지에 대한 업로드 권한을 가진 개발자이며, Ubuntu Core Developers(core-dev)는 Ubuntu 아카이브 전반에 걸쳐 패키지를 업로드할 수 있는 폭넓은 권한을 가진다. 안정 버전 업데이트에 전문화되어 별도의 권한을 갖는 SRU Developer도 존재한다.^[47]

이러한 개발자 권한의 심사는 Developer Membership Board가 담당한다. DMB는 Contributing Developer, Per-Package Uploader, Packageset Uploader, MOTU, SRU Developer와 Core Developer 등의 신청을 심사하며, 신청자의 실제 기여 내역과 패키징 지식, 판단 능력 및 신뢰성을 바탕으로 권한 부여 여부를 결정한다.^[48]

이 구조는 특정 회사나 소속보다 개인이 실제로 맡을 수 있는 책임의 범위를 기준으로 권한을 부여하도록 설계되어 있다. 따라서 Canonical 직원과 외부 커뮤니티 개발자 모두 동일한 Ubuntu 아카이브 권한 체계 안에서 작업한다.

Launchpad

Launchpad는 Canonical이 개발한 오픈 소스 소프트웨어 협업 플랫폼으로, Ubuntu 개발 인프라의 중심적인 역할을 한다. GitHub와 비슷한 코드 협업 기능도 제공하지만 Ubuntu에서는 단순한 소스 코드 호스팅을 넘어 패키지 빌드와 배포, 버그 관리, 번역, 팀과 권한 관리 등 배포판 개발 전반에 사용된다.^[49]

Launchpad는 Git 기반 소스 코드 호스팅과 코드 리뷰, 버그 추적, 번역 시스템, 기능 계획을 위한 Blueprints, 사용자 지원을 위한 Answers, Ubuntu 패키지 빌드와 호스팅 등의 기능을 제공한다. Ubuntu 자체도 Launchpad의 프로젝트 구조 안에서 관리된다.

특히 Ubuntu 패키지 개발에서는 Launchpad가 단순한 프로젝트 관리 사이트 이상의 역할을 한다. Ubuntu의 패키지 아카이브와 빌드 인프라가 Launchpad와 연결되어 있으며, 업로드된 소스 패키지를 각 지원 아키텍처에 맞추어 빌드하고 결과물을 배포하는 과정에 사용된다.

개발자의 Ubuntu 팀 소속과 여러 종류의 권한도 Launchpad 팀을 통해 표현된다. ubuntu-core-dev 같은 개발자 팀, Technical Board와 Community Council 등의 구성원 목록 역시 Launchpad에서 관리된다.

Launchpad는 Ubuntu 전용 플랫폼은 아니며 다른 자유·오픈 소스 프로젝트도 사용할 수 있다. 다만 Ubuntu는 Launchpad의 가장 큰 사용자 가운데 하나이며, Ubuntu와 Debian 개발 인프라 사이의 대표적인 차이이기도 하다.^[50]

개발 과정

Ubuntu의 개발은 공개적으로 이루어지며 필요한 기술과 지속적인 기여 의사가 있는 사람이라면 개발 과정에 참여할 수 있다. 하나의 Ubuntu 릴리스는 수많은 업스트림 프로젝트와 Debian 패키지, Ubuntu 자체 변경 사항을 하나의 배포판으로 통합하는 과정으로 이루어진다.^[51]

새로운 Ubuntu 개발 주기가 시작되면 Debian에서 많은 소스 패키지를 가져와 Ubuntu 개발 아카이브에 동기화한다. Ubuntu에 별도 변경 사항이 없는 패키지는 가능한 경우 Debian의 새 버전을 그대로 동기화할 수 있으며, Ubuntu 고유 패치가 존재하면 새 Debian 버전과 변경 사항을 병합해야 할 수 있다.

이후 각 개발 팀과 패키지 담당자가 새로운 업스트림 버전, Ubuntu 고유 기능과 버그 수정 등을 통합한다. 패키지 변경은 소스 패키지 형태로 Ubuntu 아카이브에 업로드되며 빌드 인프라가 이를 여러 아키텍처용 바이너리 패키지로 빌드한다.

직접 업로드 권한이 없는 기여자의 변경은 권한을 가진 개발자의 sponsorship을 통해 검토되고 업로드될 수 있다. 업로드 권한이 있는 개발자는 자신의 권한 범위에 해당하는 패키지를 직접 처리한다.

릴리스가 가까워지면서 Ubuntu는 기능 추가 범위를 단계적으로 제한한다. Feature Freeze와 여러 종류의 동결 시점을 거치며 새 기능보다는 오류 수정과 안정화에 집중하고, 이미지와 패키지에 대한 자동 및 수동 테스트를 수행한다. 마지막으로 릴리스 팀이 설치 이미지와 패키지 상태를 검증하여 정식 릴리스를 만든다.

이미 공개된 안정 버전은 개발 버전과 다른 정책을 적용한다. 일반적으로 기능을 대규모로 변경하는 대신 보안 수정이나 명확한 오류 수정을 제한적으로 반영하며, 일반적인 버그 수정은 Stable Release Update(SRU) 절차를 통해 회귀 가능성과 검증 결과를 확인한 뒤 배포한다.

Ubuntu 개발은 이러한 패키지 단위의 분산된 유지관리와 정해진 릴리스 일정, 프로젝트 전체에 적용되는 기술 정책을 결합하는 구조로 이루어진다.

업스트림 프로젝트와의 관계

Ubuntu 자체가 운영체제의 모든 구성 요소를 직접 개발하는 것은 아니다. Linux 커널, GNU 도구, GNOME, systemd, Mesa, Firefox를 비롯한 Ubuntu 구성 요소의 대부분은 각각 독립적인 업스트림(upstream) 프로젝트에서 개발된다.

Ubuntu 개발자의 중요한 역할 가운데 하나는 이러한 업스트림 소프트웨어를 Ubuntu의 패키지와 시스템에 통합하는 것이다. 업스트림의 새 릴리스를 패키징하고 Ubuntu 환경에서 테스트하며, 필요한 경우 배포판 차원의 패치를 적용한다.

Ubuntu에서 발견된 문제가 Ubuntu 자체의 패키징이나 통합 문제가 아니라 원래 프로젝트의 코드에서 발생한 것이라면 해당 문제와 수정 사항을 업스트림 프로젝트에 전달하는 것이 일반적으로 선호된다. 수정이 업스트림에 포함되면 Ubuntu뿐 아니라 동일한 프로젝트를 사용하는 다른 Linux 배포판과 운영체제도 함께 혜택을 받을 수 있기 때문이다.

반대로 Ubuntu가 장기간 자체 패치를 유지하면 새로운 업스트림 버전을 가져올 때마다 이를 다시 적용하고 호환성을 확인해야 한다. 따라서 특별히 Ubuntu에만 필요한 변경이 아니라면 가능한 한 업스트림 프로젝트와 협력하고 변경 사항을 원래 프로젝트에 반영하는 것이 지속적인 유지관리 측면에서도 중요하다.

이러한 관계 때문에 Ubuntu 개발은 독립적인 응용 프로그램 개발보다는 여러 업스트림 프로젝트와 Debian, Ubuntu 자체 변경 사항 사이의 통합 작업이 큰 비중을 차지한다.

Debian과의 개발 관계

Debian은 Ubuntu가 구축되는 직접적인 기반이다. Ubuntu 공식 문서는 Debian을 Ubuntu가 세워진 기반으로 설명하며, Ubuntu는 Debian의 패키지 구조와 인프라, 수많은 소프트웨어 패키지와 패키징 작업을 지속적으로 활용한다.^[52]

새 Ubuntu 개발 주기에는 Debian의 패키지 변경 사항이 정기적으로 Ubuntu로 들어온다. 이를 통해 Debian 개발자와 업스트림 프로젝트가 수행한 새로운 버전의 패키징, 버그 수정과 개선 사항을 Ubuntu에서도 사용할 수 있다.^[53]

Ubuntu와 Debian은 같은 패키지 형식과 많은 개발 도구를 공유하지만 별도의 개발자 커뮤니티와 아카이브, 릴리스 절차를 가진 독립된 배포판이다. Debian은 폭넓은 아키텍처와 범용성을 중시하며 릴리스 준비 상태에 따라 안정 버전을 공개하는 반면, Ubuntu는 상대적으로 적은 공식 아키텍처를 대상으로 약 6개월마다 정해진 일정에 따라 릴리스하고 2년마다 LTS를 제공한다.

두 프로젝트 모두에서 활동하는 개발자도 존재한다. Ubuntu는 개발자에게 수정 사항이 Debian에도 적용될 수 있다면 Debian으로 다시 전달할 것을 권장한다. Ubuntu에서만 수정한 패키지를 계속 유지하는 것보다 Debian에서 수정 사항을 받아들인 뒤 다음 동기화를 통해 Ubuntu로 다시 가져오는 구조가 중복 작업을 줄일 수 있기 때문이다.^[54]

반대로 Debian에서 이루어진 새 패키징과 수정은 Ubuntu에 지속적으로 유입된다. 따라서 두 배포판의 관계는 Ubuntu가 일정 시점의 Debian을 한 번 복사한 뒤 별도로 개발하는 방식보다는, 각 릴리스 개발 과정에서 Debian의 변화가 반복적으로 Ubuntu로 흘러 들어오고 Ubuntu의 유용한 수정이 다시 Debian이나 각 업스트림으로 환류하는 형태에 가깝다.

다만 모든 Ubuntu 변경 사항이 Debian에 그대로 적용될 수 있는 것은 아니다. Ubuntu 전용 인프라, 기본 설정, 릴리스 정책이나 Ubuntu 제품에서만 필요한 기능은 Ubuntu에서 별도로 유지될 수 있다. 결과적으로 Ubuntu는 Debian을 기반으로 긴밀하게 협력하면서도 독립적인 기술 정책, 릴리스 과정과 개발 거버넌스를 가진 별도의 배포판으로 개발된다.^[55]

Ubuntu는 기능 완성 시점을 기준으로 릴리스하는 방식보다 정해진 시간에 맞추어 새로운 버전을 공개하는 시간 기반 릴리스 모델을 사용한다. 2004년 첫 Ubuntu 릴리스 이후 약 6개월마다 새로운 시리즈가 공개되며, 이 가운데 약 2년에 한 번 4월에 공개되는 릴리스가 장기 지원 버전(Long Term Support, LTS)으로 지정된다.^[56]

Ubuntu의 릴리스는 크게 LTS 릴리스와 일반 릴리스(interim release) 두 종류로 나뉜다. 두 유형은 같은 Ubuntu 개발 과정과 품질 기준을 거쳐 공개되지만 지원 기간과 사용 목적에 차이가 있다. LTS는 장기간 같은 기반을 유지해야 하는 데스크톱, 서버와 기업 환경에 주로 사용되고, 일반 릴리스는 다음 LTS에 들어갈 새로운 기술과 소프트웨어를 보다 빠르게 제공한다.^[57]

릴리스 주기

Ubuntu는 기본적으로 6개월 주기로 새로운 정식 버전을 공개한다. 일반적인 일정은 매년 4월과 10월이며, 4월 버전은 YY.04, 10월 버전은 YY.10 형식의 번호를 사용한다.

예를 들어 다음과 같은 식이다.

Ubuntu의 릴리스는 특정 기능이 모두 완성될 때까지 일정을 미루는 방식보다는 미리 정해진 일정에 맞춰 개발을 진행한다. 따라서 특정 기능이 해당 릴리스의 동결 시점까지 충분히 안정화되지 못하면 릴리스를 연기하기보다는 해당 기능을 제외하거나 다음 버전으로 넘기는 방식이 일반적이다.^[58]

각 개발 주기에는 기능 개발과 패키지 통합이 이루어지는 기간 이후 Feature Freeze, 사용자 인터페이스·문서·커널 등 여러 구성 요소의 동결 단계와 베타 및 최종 검증 절차가 존재한다. 릴리스에 가까워질수록 새로운 기능보다는 오류 수정과 안정화가 우선된다.

약 네 번째 릴리스마다, 즉 2년에 한 번 공개되는 4월 릴리스가 LTS가 된다. 따라서 Ubuntu의 일반적인 흐름은 다음과 같이 반복된다.

Ubuntu 24.04 LTS → 24.10 → 25.04 → 25.10 → 26.04 LTS

이 패턴 때문에 LTS 사이에는 보통 세 개의 일반 릴리스가 존재한다.

버전 번호

Ubuntu의 버전 번호는 전통적으로 **공개 연도와 월을 YY.MM 형식으로 조합**한다. 예를 들어 Ubuntu 24.04는 2024년 4월, Ubuntu 25.10은 2025년 10월에 공개된 버전을 의미한다.^[59]

이는 일반적인 소프트웨어에서 사용되는 주 버전·부 버전 방식과 성격이 다르다. 24.10이 24.04보다 기능적으로 0.06만큼 증가했다는 의미가 아니라 단순히 출시 시기를 나타낸다.

예외적으로 실제 공개가 계획보다 늦어진 경우에도 기존 버전 번호가 유지된 사례가 있다. 대표적으로 최초 LTS인 Ubuntu 6.06은 원래 2006년 4월 릴리스를 목표로 했으나 안정화를 위해 약 두 달 연기되었고, 실제 공개 월인 6월을 반영해 6.06이라는 번호가 사용되었다.

LTS의 업데이트된 설치 이미지는 포인트 릴리스(point release) 형식으로 구분한다. 예를 들어 Ubuntu 26.04 LTS가 공개된 뒤 누적된 업데이트와 수정 사항을 포함한 설치 이미지가 Ubuntu 26.04.1 LTS, 이후 26.04.2 LTS와 같은 형식으로 제공될 수 있다.

포인트 릴리스는 새로운 Ubuntu 시리즈가 아니다. Ubuntu 26.04와 Ubuntu 26.04.1은 서로 다른 배포판 버전으로 업그레이드되는 관계가 아니라 같은 26.04 LTS 시리즈의 서로 다른 설치 이미지 상태를 의미한다. 이미 설치된 시스템에 정상적으로 업데이트를 적용하면 포인트 릴리스 이미지에 포함된 수정 사항도 대부분 동일하게 적용된다.

코드명

각 Ubuntu 릴리스에는 버전 번호와 별도로 코드명(code name)이 부여된다. 코드명은 일반적으로 같은 알파벳으로 시작하는 형용사와 동물 이름을 결합한다.

예를 들면 다음과 같다.

최초 릴리스인 Ubuntu 4.10은 Warty Warthog라는 코드명을 사용했다. 이후 Hoary Hedgehog, Breezy Badger, Dapper Drake가 이어졌고 Dapper Drake 이후부터는 대체로 알파벳 순서대로 코드명의 첫 글자가 진행하는 방식이 확립되었다.^[60]

코드명 전체 외에도 첫 번째 단어만 소문자로 바꾼 짧은 이름이 시스템 내부에서 광범위하게 사용된다. 예를 들어 Ubuntu 24.04 LTS Noble Numbat는 noble, Ubuntu 26.04 LTS Resolute Raccoon은 resolute로 표현된다.

이 짧은 코드명은 APT 저장소 경로, 패키지 버전, 개발 도구와 Launchpad의 시리즈 식별자 등에 사용된다. 따라서 코드명은 단순한 마케팅용 별칭이 아니라 Ubuntu 개발 및 패키지 관리 과정에서도 중요한 식별자이다.

정식 출시 전 개발 중인 버전을 버전 번호로 부르면 최종 버전과 혼동될 수 있기 때문에 Ubuntu 개발 과정에서는 코드명을 주로 사용한다.^[61]

일반 릴리스

LTS가 아닌 Ubuntu 릴리스는 interim release라고 부른다. 과거에는 일반 릴리스 또는 비-LTS 릴리스라는 표현도 널리 사용되었다.

일반 릴리스는 새로운 커널, 데스크톱 환경, 그래픽 스택, 컴파일러와 시스템 구성 요소를 LTS보다 빠른 주기로 제공한다. 다음 LTS에 포함될 가능성이 있는 변화가 먼저 일반 릴리스에서 배포되고 실제 사용자 환경에서 사용되는 경우도 많다.

현재 일반 릴리스의 공식 지원 기간은 9개월이다.^[62]

예를 들어 4월에 공개되는 일반 릴리스는 대체로 다음 해 1월까지, 10월 릴리스는 다음 해 7월까지 지원된다. 지원 기간이 다음 Ubuntu 릴리스 공개보다 약 3개월 길기 때문에 사용자는 새로운 버전이 나온 직후 즉시 업그레이드하지 않아도 어느 정도의 전환 기간을 가질 수 있다.

일반 릴리스를 계속 사용하는 시스템은 보통 6개월마다 다음 일반 릴리스로 순차적으로 업그레이드해야 한다. 장기간 동일한 시스템 기반을 유지하려는 환경보다는 최신 소프트웨어 스택과 새로운 Ubuntu 기능을 빠르게 사용하는 환경에 적합하다.

일반 릴리스도 정식 Ubuntu 릴리스이며 개발판이나 베타판을 의미하지 않는다. LTS와의 핵심적인 차이는 안정성 등급 자체라기보다 지원 기간과 릴리스의 장기 유지 목적에 있다.^[63]

장기 지원 버전

Long Term Support(LTS)는 장기간 동일한 Ubuntu 기반을 유지할 수 있도록 설계된 릴리스이다. 2006년 Ubuntu 6.06 LTS부터 도입되었으며 이후 2년에 한 번 4월에 새로운 LTS가 공개되는 방식이 정착되었다.

예를 들어 다음 릴리스가 LTS에 해당한다.

• Ubuntu 18.04 LTS
• Ubuntu 20.04 LTS
• Ubuntu 22.04 LTS
• Ubuntu 24.04 LTS
• Ubuntu 26.04 LTS

LTS는 데스크톱 사용자뿐 아니라 서버, 클라우드, 기업 환경과 제품 개발의 장기 기준 플랫폼으로 널리 사용된다. Canonical에 따르면 Ubuntu 설치의 대부분이 LTS 릴리스를 사용한다.^[64]

LTS에서는 장기간 호환성과 유지보수가 중요하기 때문에 같은 LTS 수명 주기 안에서는 시스템 전체의 기본 기술 스택을 새로운 Ubuntu 릴리스 수준으로 지속적으로 바꾸기보다 보안 패치와 검증된 오류 수정이 중심이 된다.

다만 모든 구성 요소가 5년 동안 처음 공개된 버전에 완전히 고정되는 것은 아니다. 웹 브라우저처럼 상위 프로젝트의 지원 특성상 새 버전으로 지속적으로 갱신되는 프로그램도 있으며, 일부 하드웨어 지원을 위해 새로운 커널과 그래픽 스택이 LTS 포인트 릴리스에 제공될 수 있다.

LTS에는 정기적으로 포인트 릴리스가 제공된다. 포인트 릴리스는 최초 LTS 공개 이후 축적된 보안 업데이트와 오류 수정, 경우에 따라 새로운 하드웨어 지원 스택 등을 새로운 설치 이미지에 통합한다.

지원 기간

현재 Ubuntu의 일반 릴리스는 9개월, LTS는 기본적으로 5년의 표준 보안 유지보수(Standard Security Maintenance)를 제공한다.^[65]

LTS의 표준 지원에서 Canonical이 보안 유지보수를 보장하는 중심 범위는 main 저장소의 패키지이다. universe의 패키지는 기본적으로 커뮤니티가 유지하지만 Ubuntu Pro의 ESM Apps를 사용하면 훨씬 넓은 universe 패키지 집합도 보안 유지보수 대상에 포함될 수 있다.^[66]

Ubuntu LTS의 현재 지원 구조는 대략 다음과 같다.

예를 들어 Ubuntu 26.04 LTS는 2026년 4월에 공개되었으며 표준 지원은 2031년까지, Ubuntu Pro를 통한 지원은 2036년까지, Legacy add-on을 포함하면 2041년까지 이어지는 일정으로 제공된다.^[67]

여기서 End of Standard Support와 End of Life는 같은 의미가 아니다. LTS는 기본 5년이 끝난 뒤에도 ESM이나 Legacy Support를 통해 지원을 연장할 수 있기 때문에 표준 지원 종료 뒤에도 전체 제품 수명은 계속될 수 있다.

또한 Ubuntu Flavor의 지원 기간은 Ubuntu 본판과 항상 동일하지 않을 수 있다. 각 Flavor가 자체적으로 정한 유지보수 기간이 적용될 수 있으므로 특정 Flavor를 사용하는 경우 해당 프로젝트의 릴리스 정보를 함께 확인해야 한다.

Ubuntu Pro와 연장 지원

Ubuntu Pro는 Canonical이 제공하는 Ubuntu LTS용 추가 보안·관리 서비스이다. Ubuntu의 일반적인 무료 LTS 사용을 대체하는 별도의 배포판이 아니라 기존 Ubuntu LTS 설치에 활성화하는 구독형 서비스이다.

Ubuntu Pro의 핵심 기능 가운데 하나가 Expanded Security Maintenance(ESM)이다. ESM은 LTS의 5년 표준 지원 이후에도 main의 보안 유지보수를 연장하며, ESM Apps를 통해 universe에 포함된 많은 패키지에도 보안 업데이트를 제공한다.^[68]

이를 통해 지원 가능한 LTS의 기본 보안 유지 기간은 최대 10년까지 확장된다.

Ubuntu Pro에는 ESM 외에도 조건과 Ubuntu 버전에 따라 다음과 같은 서비스가 포함될 수 있다.

• Kernel Livepatch
• 보안 및 규정 준수 기능
• FIPS 인증 암호 모듈
• Landscape 기반 시스템 관리
• 추가적인 기업 기술 지원

Ubuntu Pro는 상업용 서비스이지만 개인 사용자는 일정 수의 컴퓨터에 무료 구독을 사용할 수 있으며, 기업과 대규모 환경에서는 유료 구독을 사용할 수 있다.

ESM 기간까지 종료된 뒤에도 더 장기간 운영해야 하는 시스템을 위해 Legacy Support add-on이 제공된다. 현재 정책에서는 이를 통해 추가로 5년의 보안 유지 기간을 확보할 수 있어 LTS 공개 시점으로부터 최대 15년까지 지원 수명을 확장할 수 있다.^[69]

따라서 Ubuntu의 장기 지원은 단순히 'LTS는 5년'으로 끝나는 구조가 아니라 기본 5년, Ubuntu Pro의 ESM을 포함한 10년, Legacy add-on을 포함한 최대 15년이라는 단계적인 형태를 가진다.

개발 버전

하나의 Ubuntu 버전이 정식 공개되면 거의 동시에 다음 릴리스를 위한 새로운 개발 시리즈가 시작된다. 이 아직 공개되지 않은 시리즈를 일반적으로 development release, development series 또는 간단히 devel이라고 부른다.^[70]

개발판은 별도로 한 번 만들어지는 단일 시험 이미지가 아니라 다음 정식 릴리스가 될 패키지 저장소 자체가 지속적으로 변하는 형태이다. Debian에서 새로운 패키지가 동기화되고 Ubuntu 개발자가 변경 사항을 업로드하면서 개발 시리즈는 매일 계속 변화한다.

개발 시리즈에 업로드된 많은 패키지는 먼저 -proposed 영역에서 빌드와 자동 테스트를 거친다. 의존성 문제나 테스트 회귀가 발견되지 않고 정해진 조건을 만족하면 해당 패키지가 실제 개발 릴리스의 -release 영역으로 이동한다. 이를 proposed migration이라고 한다.^[71]

개발 주기에는 일정 단계부터 새로운 기능을 제한하는 Feature Freeze가 적용되며 이후 안정화가 진행된다. 필요에 따라 일일 설치 이미지인 daily image, 베타 이미지와 기타 시험 이미지도 제공된다.

개발판에는 최신 패키지와 다음 Ubuntu 기능을 미리 사용할 수 있다는 장점이 있지만 패키지 전환이나 의존성 문제, 설치 이미지 오류와 회귀가 발생할 수 있다. 따라서 일반적인 작업용 또는 운영 서버보다는 Ubuntu 개발, 테스트와 버그 검증을 목적으로 사용된다.

지원 중인 최신 Ubuntu에서 do-release-upgrade -d를 사용하면 조건이 충족될 경우 다음 개발 릴리스로 업그레이드할 수 있지만 Canonical은 이를 운영 환경에서 사용하는 것을 권장하지 않는다.^[72]

2026년 10월 초 기준 Ubuntu 26.04 LTS 이후의 다음 개발 계열은 Ubuntu 26.10 "Stonking Stingray"이며, 2026년 10월 정식 공개를 목표로 개발되고 있다.^[73]

업그레이드 정책

Ubuntu는 설치된 시스템을 다시 설치하지 않고 다음 Ubuntu 릴리스로 전환할 수 있는 release upgrade 기능을 제공한다. 데스크톱에서는 Update Manager를 통해 업그레이드 알림과 절차를 제공하고, 서버 및 명령줄 환경에서는 일반적으로 do-release-upgrade를 사용한다.^[74]

업그레이드 가능한 경로는 임의의 버전 사이를 직접 이동하는 방식이 아니라 지원되는 순차 경로를 따른다.

일반 릴리스를 사용하는 경우 보통 다음 Ubuntu 릴리스로 순서대로 업그레이드한다.

Ubuntu 25.04 → Ubuntu 25.10 → Ubuntu 26.04 LTS

중간 릴리스를 건너뛰어 일반 릴리스에서 훨씬 이후 버전으로 직접 업그레이드하는 것은 일반적인 지원 경로가 아니다.

LTS 사용자는 중간의 일반 릴리스를 모두 거치지 않고 다음 LTS로 직접 업그레이드할 수 있다.

Ubuntu 22.04 LTS → Ubuntu 24.04 LTS → Ubuntu 26.04 LTS

다만 LTS 역시 여러 세대를 한 번에 건너뛰는 직접 업그레이드는 공식적인 일반 경로가 아니다. 예를 들어 Ubuntu 20.04 LTS에서 Ubuntu 26.04 LTS로 바로 이동하는 대신 22.04, 24.04, 26.04 순으로 각각 업그레이드해야 한다.^[75]

LTS에서 다음 LTS로의 자동 업그레이드 제안은 새로운 LTS가 최초 공개되는 즉시 활성화되지 않는 것이 일반적이다. Ubuntu는 새 LTS의 첫 번째 포인트 릴리스가 공개되고 초기 사용자에게서 발견된 주요 문제가 수정된 뒤 기존 LTS 사용자에게 업그레이드를 본격적으로 제공한다.

예를 들어 Ubuntu 24.04 LTS에서 Ubuntu 26.04 LTS로의 일반 업그레이드는 Ubuntu 26.04.1 LTS의 안정화 이후인 2026년 9월 29일 공식적으로 활성화되었다.^[76]

/etc/update-manager/release-upgrades의 Prompt 설정을 통해 시스템이 LTS만 추적할지 모든 정식 릴리스를 추적할지 설정할 수 있다. 일반적으로 Prompt=lts는 LTS에서 다음 LTS만 제안하고 Prompt=normal은 일반 릴리스를 포함한 다음 Ubuntu 릴리스를 추적한다.^[77]

릴리스 업그레이드에서는 Ubuntu 공식 저장소 외의 제3자 저장소와 PPA가 새로운 릴리스에서 호환되지 않을 수 있기 때문에 업그레이드 과정에서 비활성화될 수 있다. 커널, 시스템 서비스, 설정 파일과 설치 패키지도 함께 변경되므로 주요 시스템에서는 업그레이드 전 백업과 호환성 검증이 권장된다.

릴리스 지원 종료

Ubuntu 릴리스가 정해진 유지보수 기간을 모두 지나면 End of Life(EOL) 상태가 된다. EOL이 된 일반 릴리스에는 더 이상 Ubuntu 프로젝트의 일반 보안 업데이트와 오류 수정이 제공되지 않는다.

일반 릴리스는 현재 공개 후 9개월 뒤 EOL이 된다. 예를 들어 Ubuntu 25.10 "Questing Quokka"는 2025년 10월 9일 공개되었고 2026년 7월 지원이 종료되었다.^[78]

LTS에서는 표준 지원 종료와 최종 EOL을 구분해야 한다. 표준 5년이 끝났더라도 Ubuntu Pro의 ESM 기간이 남아 있다면 해당 릴리스 자체의 전체 수명이 끝난 것은 아니다. Legacy Support까지 적용되는 릴리스에서는 이 기간이 더욱 길어진다.

EOL이 된 릴리스의 패키지 저장소는 일반 Ubuntu 미러에서 계속 유지되지 않을 수 있으며, 오래된 릴리스의 패키지는 별도의 old-releases.ubuntu.com 아카이브에서 제공된다.^[79]

이 아카이브는 과거 시스템을 그대로 안전하게 계속 운영하기 위한 새로운 보안 지원을 제공하는 것이 아니라 당시의 마지막 패키지 상태를 보존하는 역할에 가깝다. 따라서 EOL 시스템에서 apt update가 다시 동작하도록 저장소를 old-releases로 변경하더라도 새로운 보안 취약점에 대한 업데이트가 제공되는 것은 아니다.

지원이 종료된 버전을 계속 사용하고 있다면 지원 중인 Ubuntu 릴리스로 업그레이드하는 것이 일반적인 경로이다. 너무 오래된 버전은 현재 지원되는 릴리스까지 직접 업그레이드할 수 없으므로 여러 중간 버전을 차례대로 거치거나 새 버전을 다시 설치해야 할 수 있다.

이 때문에 일반 릴리스를 사용하는 시스템은 9개월이라는 짧은 수명을 고려해 정기적인 업그레이드가 필요하며, 장기간 동일한 기반을 유지해야 하는 시스템에서는 LTS와 필요에 따른 Ubuntu Pro·ESM이 주로 사용된다.

Ubuntu는 Linux 커널 위에 GNU 프로젝트를 비롯한 여러 자유·오픈 소스 사용자 공간 구성 요소를 결합하고, systemd를 중심으로 서비스·장치·세션을 관리하는 일반적인 현대 Linux 시스템 구조를 사용한다. 기본 시스템은 Debian에서 이어진 패키지 구조와 Filesystem Hierarchy Standard 계열의 디렉터리 배치를 따르며, 부팅 과정에서는 펌웨어와 부트로더, 커널, 초기 사용자 공간인 initramfs, 루트 파일 시스템, systemd 순으로 시스템이 초기화된다.

Ubuntu의 시스템 구성은 데스크톱, 서버, 클라우드 이미지와 장치별 이미지에 따라 설치되는 패키지와 기본 서비스가 달라질 수 있다. 예를 들어 데스크톱 환경에서는 NetworkManager가 일반적인 네트워크 관리 백엔드로 사용되는 반면 서버에서는 systemd-networkd를 사용하는 구성이 널리 쓰인다. 그러나 Netplan, systemd, udev와 같은 공통 기반을 통해 같은 Ubuntu 계열 안에서 일관된 시스템 관리 방식을 제공한다.

Linux 커널

Ubuntu의 핵심 커널은 Linux 커널이다. 프로세스 스케줄링, 가상 메모리, 파일 시스템, 네트워크 스택, 장치 드라이버, 보안 기능과 시스템 호출 인터페이스 등의 저수준 기능을 담당하며, 사용자 공간 프로그램은 커널이 제공하는 인터페이스를 통해 하드웨어와 시스템 자원을 사용한다.

Ubuntu는 단순히 kernel.org에서 배포하는 업스트림 Linux 커널 바이너리를 그대로 사용하는 것이 아니라, 각 Ubuntu 릴리스를 위해 별도의 커널 소스와 설정을 유지한다. Canonical Kernel Team은 업스트림 Linux 변경 사항을 가져오면서 Ubuntu에서 요구되는 AppArmor, 하드웨어 지원, 보안 수정과 배포판 통합 작업을 수행한다.^[80]

일반적인 데스크톱과 서버 설치에는 generic 커널이 기본적으로 사용된다. Ubuntu는 같은 Linux 소스에서 서로 다른 설정을 사용하거나 별도의 최적화된 소스 패키지를 통해 용도별 커널을 제공한다. 대표적으로 일반 시스템을 위한 generic, 지연 시간이 중요한 작업을 위한 lowlatency, PREEMPT_RT를 사용하는 realtime 등이 존재한다. AWS와 Raspberry Pi 같은 특정 환경을 위한 별도의 최적화 커널도 제공된다.^[81]

Ubuntu의 커널 패키지는 일반 응용 프로그램과 마찬가지로 APT를 통해 업데이트된다. 지원 중인 안정 릴리스에서는 새로운 기능을 무제한으로 도입하기보다 보안 수정과 검증된 안정화 패치를 반영하는 Stable Release Update(SRU) 절차가 사용된다.

LTS에서는 새로운 하드웨어를 지원하기 위해 Hardware Enablement(HWE) 커널을 제공할 수도 있다. 이를 통해 기존 LTS를 유지하면서 이후 Ubuntu 릴리스에서 사용된 더 새로운 Linux 커널과 그래픽 스택을 일부 시스템에 적용할 수 있다.

커널 이미지와 초기 RAM 파일 시스템은 일반적으로 /boot에 저장된다. 커널이 시작된 뒤에는 /proc을 통해 프로세스와 커널 상태를, /sys의 sysfs를 통해 장치와 커널 객체 정보를 사용자 공간에 노출한다.

GNU 사용자 공간

Ubuntu는 Linux 커널 위에서 동작하는 사용자 공간의 상당 부분에 GNU 프로젝트의 소프트웨어를 사용한다. 대표적으로 glibc, Bash, GNU Binutils, GCC와 전통적인 GNU Core Utilities 계열의 도구가 Ubuntu 생태계에서 사용되어 왔다.

glibc는 Ubuntu에서 일반적인 네이티브 프로그램이 사용하는 핵심 C 라이브러리로, 프로그램과 Linux 시스템 호출 인터페이스 사이에서 파일 입출력, 메모리 관리, 문자열·시간·로케일 처리, 스레드와 네트워크 등 광범위한 표준 인터페이스를 제공한다. Ubuntu의 로케일 생성 도구 역시 glibc의 locales 패키지를 기반으로 한다.^[82]

Bash는 전통적으로 Ubuntu의 대화형 명령줄 셸로 널리 사용된다. 다만 /bin/sh는 Bash와 동일한 의미가 아니며 Ubuntu에서는 시스템 셸 스크립트가 보다 작은 POSIX 호환 셸인 dash를 사용할 수 있도록 구성되어 있다.

파일 복사, 이동, 디렉터리 생성, 텍스트 출력과 같은 기본 명령의 상당수는 coreutils 계열에서 제공된다. Ubuntu 24.04 LTS까지의 coreutils 패키지는 GNU Core Utilities를 직접 제공했으며, 이후 Ubuntu에서는 coreutils를 여러 구현이 제공할 수 있는 구조도 도입하였다.^[83]

그러나 Ubuntu의 사용자 공간 전체를 GNU만으로 구성한다고 보는 것은 정확하지 않다. systemd, OpenSSH, Python, APT, dpkg, Netplan, NetworkManager, Mesa와 수많은 데스크톱·서버 구성 요소처럼 GNU 프로젝트에 속하지 않는 소프트웨어도 기본 시스템의 중요한 부분을 차지한다. 따라서 Ubuntu는 Linux 커널과 GNU 도구를 중요한 기반으로 사용하는 동시에 여러 독립 오픈 소스 프로젝트를 통합한 배포판이다.

init와 systemd

현대 Ubuntu는 systemd를 기본 init 시스템이자 시스템·서비스 관리자로 사용한다. systemd가 부팅 과정에서 PID 1로 실행되며 사용자 공간의 나머지 서비스를 시작하고 관리한다.^[84]

Ubuntu는 초기 버전에서는 전통적인 SysV init을 사용했고 이후 Canonical이 개발한 Upstart로 전환했지만, Ubuntu 15.04부터 systemd가 기본 init 시스템이 되었다.

systemd는 단순히 프로그램을 순서대로 실행하는 init 프로그램보다 넓은 기능을 담당한다. 서비스, 소켓, 마운트 지점, 장치, 타이머와 여러 시스템 자원을 unit이라는 공통 모델로 표현하고 이들의 의존성을 계산해 필요한 작업을 병렬로 수행한다.

대표적인 unit 형식에는 다음과 같은 것들이 있다.

서비스 관리에는 systemctl이 사용된다. 실행·중지·재시작뿐 아니라 부팅 시 자동 시작 여부, 서비스 상태와 의존 관계 등을 관리할 수 있다.

시스템 전체용 unit은 주로 /usr/lib/systemd/system 등에 패키지가 제공하고, 관리자가 추가하거나 재정의하는 설정은 /etc/systemd/system에 위치한다. 이를 통해 패키지의 기본 unit 파일을 직접 수정하지 않고도 drop-in 설정으로 동작을 변경할 수 있다.

systemd는 init 외에도 journald, logind, udev, timesyncd와 같은 여러 시스템 서비스를 포함한다. Ubuntu는 이들 가운데 필요한 구성 요소를 다른 프로젝트의 도구와 함께 조합해 사용한다.

Ubuntu 26.04 LTS에는 systemd 259가 포함되며, 이 릴리스는 systemd의 오래된 System V 서비스 스크립트 호환을 제공하는 마지막 Ubuntu 릴리스로 지정되었다.^[85]

파일 시스템 구조

Ubuntu는 다른 일반적인 Linux 시스템과 마찬가지로 하나의 / 루트에서 시작하는 단일 파일 시스템 계층을 사용한다. 물리적으로 서로 다른 파티션이나 디스크, 네트워크 파일 시스템이 존재하더라도 각각의 파일 시스템은 이 디렉터리 트리의 특정 위치에 마운트된다.

주요 디렉터리의 역할은 다음과 같다.

/etc에는 호스트별 설정이 저장되며 /var/lib에는 서비스가 유지하는 영구 상태, /var/log에는 지속적인 로그, /run에는 PID 파일·소켓 등 현재 부팅에서만 의미가 있는 상태가 저장된다. /run은 일반적으로 tmpfs로 제공되므로 재부팅하면 내용이 사라진다.^[86]

현대 Ubuntu는 usr merge 구조를 사용한다. 전통적으로 별도 디렉터리였던 /bin, /sbin, /lib 등은 현대 시스템에서 /usr 아래의 대응 위치로 연결되는 호환 심볼릭 링크가 될 수 있다. 예를 들어 /bin과 /sbin은 실제 실행 파일이 위치하는 /usr/bin 계열과 연결된다.^[87]

/proc, /sys, /dev는 일반적인 디스크 파일만 저장하는 공간이 아니다. /proc과 /sys는 커널이 런타임 정보를 노출하는 가상 파일 시스템이고, /dev에는 사용자 공간이 장치에 접근하기 위한 장치 노드가 존재한다.

Ubuntu 26.04 LTS부터는 systemd의 tmp.mount가 기본적으로 사용되어 /tmp가 tmpfs 파일 시스템으로 제공된다. 따라서 해당 릴리스의 기본 구성에서 /tmp의 내용은 메모리와 스왑을 기반으로 하는 임시 저장 공간이며 재부팅을 넘어 보존할 목적으로 사용되지 않는다.^[88]

부팅 과정

일반적인 Ubuntu 시스템의 부팅은 펌웨어 → 부트로더 → Linux 커널 → initramfs → 실제 루트 파일 시스템 → systemd → 사용자 환경 순으로 진행된다.

Ubuntu의 일반적인 부팅 흐름

1. UEFI 또는 BIOS가 하드웨어를 초기화
   ↓
2. 부트로더가 Ubuntu의 커널과 initramfs를 로드
   ↓
3. Linux 커널이 CPU, 메모리와 초기 장치를 초기화
   ↓
4. initramfs의 초기 사용자 공간이 실제 루트 파일 시스템을 준비
   ↓
5. 루트 파일 시스템으로 전환
   ↓
6. systemd가 PID 1로 시작
   ↓
7. 장치, 파일 시스템, 네트워크와 시스템 서비스 활성화
   ↓
8. 로그인 또는 그래픽 데스크톱 환경 준비

전원을 켜면 UEFI 또는 BIOS와 같은 시스템 펌웨어가 기본적인 하드웨어 초기화를 수행하고 부팅 가능한 항목을 찾는다. 일반적인 PC용 Ubuntu 설치에서는 이후 GRUB이 부트로더 역할을 수행한다.

GRUB은 선택된 Ubuntu 설치의 Linux 커널 이미지와 initramfs를 메모리에 적재하고 커널을 실행한다. UEFI 시스템에서는 부트 체인에 EFI System Partition이 사용되며 Secure Boot가 활성화된 시스템에서는 서명 검증 과정도 포함될 수 있다.

커널은 CPU와 메모리 관리, 인터럽트, 초기 장치 드라이버 등을 준비한 뒤 initramfs를 임시 루트 파일 시스템으로 사용한다. initramfs에는 실제 루트 파일 시스템을 찾고 접근하는 데 필요한 최소한의 사용자 공간 도구와 드라이버가 들어 있다. 암호화된 루트 디스크, LVM, RAID나 특수 저장장치가 사용되는 경우 이 단계에서 필요한 준비가 수행된다.^[89]

실제 루트 파일 시스템이 준비되면 initramfs에서 본 시스템으로 전환하고 /sbin/init을 통해 systemd가 PID 1로 실행된다. systemd는 필요한 파일 시스템을 마운트하고 udev를 통한 장치 초기화, 네트워크와 각종 서비스를 의존 관계에 따라 활성화한다.^[90]

systemd의 default.target은 일반적으로 시스템의 용도에 맞는 최종 부팅 목표와 연결된다. 그래픽 데스크톱에서는 주로 graphical.target, 그래픽 환경이 필요 없는 서버에서는 multi-user.target에 해당하는 서비스 집합이 활성화된다.

systemd는 가능한 작업을 무조건 직렬로 실행하지 않고 unit의 의존 관계가 허용하는 범위에서 병렬화한다. 따라서 현대 Ubuntu의 부팅은 과거 SysV init의 단순한 시작 스크립트 번호 순서와 다른 의존성 기반 구조를 사용한다.^[91]

장치 관리

Ubuntu에서 하드웨어 장치의 가장 낮은 수준 관리는 Linux 커널의 장치 드라이버가 담당한다. 커널이 PCI, USB, 저장장치, 입력 장치와 네트워크 인터페이스 등을 발견하면 관련 정보를 sysfs를 통해 /sys에 노출하고 사용자 공간에 장치 이벤트인 uevent를 전달한다.

사용자 공간에서는 udev가 이러한 이벤트를 처리한다. 현대 Ubuntu에서 udev 데몬은 systemd 프로젝트에 포함된 systemd-udevd이며, 커널 uevent를 수신하고 일치하는 udev 규칙을 적용한다.^[92]

udev는 장치가 추가·제거되거나 상태가 변경될 때 /dev의 장치 노드와 심볼릭 링크를 구성하고, 장치 속성과 이름, 권한 등을 설정한다. 규칙은 시스템이 제공하는 기본 규칙과 관리자가 작성하는 로컬 규칙을 함께 사용할 수 있다.

udevadm은 udev 상태를 조회하고 이벤트를 관찰하거나 규칙을 시험하는 관리 도구이다. 장치의 속성을 조회하거나 새로운 장치 이벤트를 다시 발생시키고, 특정 udev 규칙이 어떤 결과를 만들지 테스트하는 데 사용할 수 있다.^[93]

하드웨어에 필요한 커널 모듈은 커널과 사용자 공간의 장치 감지 과정에서 자동으로 로드되는 것이 일반적이다. 특정 모듈을 직접 다룰 때에는 modprobe, modinfo, lsmod 등의 도구를 사용할 수 있다.

상위 사용자 공간에서는 udev가 제공한 장치 정보를 다시 데스크톱 서비스, NetworkManager, UDisks, 로그인 관리자 등이 이용한다. 예를 들어 USB 저장장치를 연결하면 커널이 장치를 탐지하고 udev가 장치 노드를 준비한 뒤 데스크톱 환경의 저장장치 서비스가 이를 인식하여 사용자에게 마운트 가능한 장치로 표시할 수 있다.

네트워크 구성

현대 Ubuntu는 네트워크 설정의 공통 추상화 계층으로 Netplan을 사용한다. 관리자는 일반적으로 /etc/netplan/ 아래의 YAML 파일에 원하는 네트워크 구성을 선언하고, Netplan이 이 설정을 실제 네트워크 관리 백엔드가 이해할 수 있는 구성으로 변환한다.^[94]

Netplan을 통한 네트워크 구성

1. /etc/netplan/*.yaml에 네트워크 구성 정의
   ↓
2. Netplan이 설정을 읽고 처리
   ↓
3. NetworkManager 또는 systemd-networkd용 런타임 구성 생성
   ↓
4. 선택된 백엔드가 실제 네트워크 인터페이스 구성
   ↓
5. Linux 커널의 네트워크 스택에 주소·경로 등이 적용

Netplan 자체가 장기적으로 모든 네트워크 인터페이스를 직접 제어하는 데몬은 아니다. 설정을 읽고 실제 동작을 담당하는 renderer에 전달하는 역할을 한다. 대표적인 renderer는 NetworkManager와 systemd-networkd이다.^[95]

Ubuntu Desktop에서는 Wi-Fi, VPN, 이동식 네트워크와 사용자 세션에서의 동적 연결을 편리하게 관리할 수 있는 NetworkManager가 일반적으로 사용된다. GNOME 설정의 네트워크 인터페이스도 NetworkManager와 연동된다.

Ubuntu Server에서는 GUI에 의존하지 않는 systemd-networkd가 많이 사용된다. 서버·클라우드 환경에서는 설치 프로그램이나 cloud-init 등이 Netplan 설정을 생성하고 systemd-networkd를 통해 정적인 주소, DHCP, VLAN, bond, bridge 등의 구성을 적용할 수 있다.

Netplan 설정은 IP 주소뿐 아니라 기본 경로, DNS 서버, Wi-Fi, bridge, bonding, VLAN과 여러 고급 네트워크 옵션도 표현할 수 있다.

Ubuntu 26.04 LTS에서는 Netplan 1.2가 사용되며 systemd-networkd 환경의 온라인 상태 판단과 여러 네트워크 기능이 개선되었다.^[96]

DNS 이름 해석에는 systemd-resolved와 같은 구성 요소가 함께 사용될 수 있으며 실제 연결 관리 도구와 설정에 따라 DNS 서버와 검색 도메인이 전달된다. 애플리케이션은 일반적으로 glibc의 이름 해석 인터페이스 등을 통해 이 구성을 사용한다.

로깅

Ubuntu의 현대적인 시스템 로그 구조에서는 systemd-journald가 핵심적인 역할을 한다. journald는 Linux 커널 메시지, 전통적인 syslog 인터페이스로 전달된 메시지, systemd 서비스의 표준 출력과 표준 오류, native Journal API와 커널 audit 기록 등 여러 출처의 로그를 수집한다.^[97]

수집된 journal은 단순한 텍스트 파일의 연속이 아니라 프로세스 ID, unit 이름, 실행 파일, 우선순위, 부팅 ID와 같은 메타데이터를 함께 저장할 수 있는 구조화된 로그 형식이다.

journal을 조회할 때는 journalctl을 사용한다. 전체 시스템 로그뿐 아니라 특정 서비스, 현재 부팅, 특정 시간 범위와 우선순위 등으로 필터링할 수 있다.

예를 들어 systemd 서비스의 표준 출력과 표준 오류가 journal로 연결되어 있으면 프로그램이 별도의 /var/log 파일을 직접 만들지 않아도 서비스별 로그를 journalctl을 통해 확인할 수 있다.

journald는 설정에 따라 /run/log/journal에 휘발성 로그를 저장하거나 /var/log/journal에 재부팅 뒤에도 유지되는 로그를 저장할 수 있다.^[98]

Ubuntu에서는 전통적인 syslog 방식도 함께 사용할 수 있다. rsyslog와 같은 데몬이 설치된 환경에서는 syslog 메시지를 규칙에 따라 /var/log 아래의 텍스트 로그 파일이나 원격 로그 서버로 전달할 수 있다. Ubuntu Server 문서에서도 /etc/rsyslog.conf가 rsyslog 패키지의 시스템 설정 파일로 관리되는 예를 제공한다.^[99]

따라서 Ubuntu의 로깅은 journald와 기존 syslog 생태계 가운데 하나만을 반드시 선택하는 구조가 아니라 목적에 따라 함께 구성할 수 있다. 애플리케이션 자체 로그, 웹 서버 로그, 데이터베이스 로그 등은 해당 프로그램이 별도의 파일이나 자체 저장소에 기록하기도 한다.

시간과 지역 설정

Ubuntu는 시스템 시간, 하드웨어 시계, 시간대와 네트워크 시간 동기화를 서로 구분해 관리한다. systemd 기반 시스템에서는 timedatectl을 사용하여 현재 시간 설정을 조회하거나 시간대와 네트워크 시간 동기화 상태를 변경할 수 있다.^[100]

Linux 커널이 관리하는 system clock은 시스템 실행 중의 기준 시각이며, 컴퓨터의 RTC(Real-Time Clock)는 전원이 꺼진 동안에도 시간을 유지하는 하드웨어 시계이다. 일반적인 Linux 환경에서는 RTC를 UTC 기준으로 유지하고 사용자에게 표시할 때 설정된 시간대를 적용하는 구성이 권장된다.

시간대 데이터는 IANA Time Zone Database를 기반으로 제공되며 /usr/share/zoneinfo 아래에 설치된다. 현재 시스템의 시간대는 해당 데이터를 참조하도록 설정되며 timedatectl set-timezone 등을 사용해 변경할 수 있다.

네트워크를 통한 자동 시간 동기화는 systemd-timesyncd 또는 별도로 설치된 chrony와 같은 NTP 구현을 통해 수행될 수 있다. timedatectl은 현재 시스템에서 네트워크 시간 동기화가 활성화되어 있는지도 표시한다.^[101]

로케일(locale)은 시간대와 별개의 설정이다. 로케일은 사용자 인터페이스의 기본 언어뿐 아니라 문자 인코딩, 날짜·시간 표시 형식, 숫자와 통화 표시, 문자열 정렬 방식 등에 영향을 준다.

Ubuntu의 로케일은 glibc의 locale 체계를 사용하며 LANG, LC_TIME, LC_NUMERIC 등의 환경 변수를 통해 선택한다. 가장 넓은 기본값은 LANG으로 정하고, 필요한 경우 각각의 LC_* 변수로 특정 범주만 다르게 지정할 수 있다.

필요한 로케일 데이터는 locale-gen을 통해 생성할 수 있다. 이 도구는 /etc/locale.gen에 선택된 로케일을 읽어 glibc의 localedef를 통해 실제 사용할 데이터를 컴파일한다.^[102]

현대 Ubuntu에서는 localectl로 시스템 로케일과 키보드 설정을 조회하거나 변경할 수도 있다. systemd의 systemd-localed와 통신하여 로그인 이전의 시스템 서비스 및 사용자 세션이 기본적으로 사용할 지역 설정을 관리한다.^[103]

따라서 Ubuntu에서 시간(time), 시간대(time zone), 로케일(locale)과 키보드 배열은 서로 관련되어 보일 수 있지만 독립적으로 설정 가능한 항목이다. 예를 들어 시스템 언어를 한국어로 사용하면서 시간대는 America/Ciudad_Juarez로 설정하거나, 영어 인터페이스에서 Asia/Seoul 시간대를 사용하는 구성도 가능하다.

Ubuntu의 전통적인 패키지 관리 체계는 Debian에서 이어진 deb 패키지 형식, 저수준 패키지 관리 도구인 dpkg, 그리고 저장소·의존성·업데이트 처리를 담당하는 APT를 중심으로 구성된다. Ubuntu의 기본 운영체제 구성 요소 대부분은 이 체계를 통해 설치되고 유지된다.^[104]

이와 별도로 Ubuntu는 응용 프로그램 배포를 위한 Snap을 기본적으로 지원하며, 사용자가 필요하면 Flatpak과 Flathub 같은 외부 배포 체계도 설치해 함께 사용할 수 있다. 따라서 현대 Ubuntu에서는 시스템 패키지를 deb/APT로 관리하면서 일부 데스크톱 응용 프로그램은 Snap이나 Flatpak으로 설치하는 구성이 가능하다.^[105]

Ubuntu의 일반적인 deb 패키지 설치 흐름

1. APT가 설정된 저장소의 패키지 메타데이터를 조회
   ↓
2. 요청한 패키지와 필요한 의존성 계산
   ↓
3. 저장소에서 .deb 패키지 다운로드
   ↓
4. dpkg를 통해 파일 설치 및 패키지 데이터베이스 갱신
   ↓
5. 설정 스크립트와 트리거 실행
   ↓
6. 설치 완료

deb 패키지

deb는 Debian에서 만들어진 바이너리 패키지 형식이며 Ubuntu의 표준 시스템 패키지 형식이다. 일반적으로 .deb 확장자를 사용하며, 프로그램 파일뿐 아니라 패키지 이름, 버전, 아키텍처, 의존성, 충돌 관계, 설명과 설치·제거 과정에서 실행되는 관리 스크립트 등의 메타데이터를 포함할 수 있다.^[106]

하나의 소프트웨어가 반드시 하나의 deb 파일에 모두 포함되는 것은 아니다. Ubuntu에서는 재사용 가능한 라이브러리와 데이터, 개발 헤더, 문서와 디버그 심볼 등을 여러 패키지로 나누는 경우가 많다.

예를 들어 하나의 라이브러리 프로젝트가 다음처럼 나뉠 수 있다.

• 실제 런타임 라이브러리
• 개발용 헤더와 정적 파일을 제공하는 -dev
• 디버그 심볼을 제공하는 패키지
• 문서 패키지
• 명령줄 도구나 관련 프로그램

이렇게 여러 프로그램이 같은 라이브러리 패키지를 공유할 수 있기 때문에 중복 파일을 줄이고, 특정 구성 요소만 별도로 업데이트할 수 있다. 대신 하나의 프로그램을 설치할 때 여러 개의 의존 패키지가 함께 설치되는 일이 흔하다.^[107]

deb 패키지는 특정 Ubuntu 시리즈와 아키텍처를 대상으로 빌드되는 것이 일반적이다. 예를 들어 같은 소스 패키지에서 amd64, arm64 등에 맞는 서로 다른 바이너리 deb 패키지가 생성될 수 있다.

로컬에 내려받은 .deb 파일도 직접 설치할 수 있지만, 일반적으로는 APT를 통해 설치하는 방식이 권장된다. APT를 사용하면 해당 패키지에 필요한 다른 패키지까지 저장소에서 찾아 함께 처리할 수 있기 때문이다.^[108]

dpkg

dpkg는 Debian 계열 시스템에서 deb 패키지를 직접 처리하는 저수준 패키지 관리 도구이며 Ubuntu에서도 핵심 패키지 관리 기반으로 사용된다.

dpkg는 다음과 같은 작업을 담당한다.

• .deb 파일 설치
• 설치된 패키지 제거
• 패키지 설정
• 패키지 데이터베이스 관리
• 설치된 패키지와 파일 조회
• deb 패키지 생성

Ubuntu 시스템에서 어떤 패키지가 설치되어 있는지, 특정 패키지가 어떤 파일을 설치했는지 등의 정보도 dpkg 데이터베이스를 통해 확인할 수 있다.^[109]

dpkg 자체는 원격 저장소에서 필요한 패키지를 자동으로 찾아 내려받고 전체 의존성을 해결하는 고수준 도구가 아니다. 예를 들어 필요한 라이브러리가 설치되어 있지 않은 .deb 파일을 dpkg로 직접 설치하면 의존성 문제가 발생할 수 있다.

이러한 역할은 일반적으로 APT가 담당한다.

APT와 dpkg의 관계

1. 사용자가 APT에 설치 요청
   ↓
2. APT가 저장소와 의존성 분석
   ↓
3. 필요한 .deb 파일 다운로드
   ↓
4. APT가 dpkg를 호출
   ↓
5. dpkg가 실제 파일과 패키지 상태를 변경

따라서 APT와 dpkg는 서로 경쟁하는 별개의 패키지 관리 체계라기보다 서로 다른 계층을 담당한다. APT는 저장소와 의존성 수준의 고수준 관리를 담당하고, dpkg는 개별 deb 패키지의 실제 설치와 시스템 패키지 데이터베이스 관리를 수행한다.^[110]

APT

APT(Advanced Packaging Tool)는 Ubuntu에서 deb 패키지를 관리하는 기본적인 고수준 패키지 관리 체계이다. 설정된 저장소의 패키지 목록을 가져오고 사용자가 요청한 패키지와 의존성을 분석해 필요한 deb 파일을 다운로드한 뒤 dpkg를 통해 설치한다.^[111]

일반 사용자를 위한 대표적인 명령줄 인터페이스는 apt이다.

주요 작업은 다음과 같다.

apt update는 설치된 프로그램 자체를 업데이트하는 명령이 아니다. 설정된 저장소에서 최신 패키지 색인 정보를 받아와 로컬 APT 데이터베이스를 갱신한다. 그 뒤 apt upgrade 등의 명령을 실행해야 실제 패키지 업데이트가 이루어진다.^[112]

APT 계열에는 오래전부터 사용된 apt-get, apt-cache 등의 명령도 존재한다. apt는 사람이 직접 터미널에서 사용하기 편한 인터페이스를 제공하는 반면, Ubuntu 공식 문서는 자동화된 스크립트에서는 출력 형식이 비교적 안정적인 apt-get을 사용할 것을 권장한다.^[113]

APT는 버전 비교, 아키텍처, 의존성과 충돌 관계, 저장소 우선순위 등을 계산하여 어떤 패키지를 설치할지 결정한다. 필요하면 pinning을 통해 특정 저장소나 버전에 우선순위를 줄 수도 있다.

저장소

패키지 저장소(repository)는 APT가 다운로드할 수 있는 deb 패키지와 패키지 메타데이터를 제공하는 서버 또는 패키지 집합이다. Ubuntu의 공식 패키지들은 거대한 Ubuntu Package Archive에 저장된다.^[114]

Ubuntu 아카이브는 먼저 각 Ubuntu 버전을 나타내는 series로 구분된다. 예를 들어 Ubuntu 24.04 LTS의 series는 noble, Ubuntu 26.04 LTS는 resolute이다.

각 series 안에는 목적에 따라 여러 pocket이 존재한다.

-proposed는 일반 사용자가 항상 활성화하여 사용하는 저장소라기보다 새 업데이트가 -updates로 이동하기 전에 테스트하는 영역이다.^[115]

Ubuntu 24.04 LTS 이후 기본 APT 저장소 설정은 deb822 형식을 사용하며 주로 다음 파일에 저장된다.

/etc/apt/sources.list.d/ubuntu.sources

이전 Ubuntu에서는 /etc/apt/sources.list와 .list 파일 형식이 기본적으로 사용되었다.^[116]

Ubuntu 저장소는 전 세계 미러 서버를 통해 복제된다. 사용자는 지리적으로 가까운 미러를 선택해 패키지를 받을 수 있으며 보안 업데이트를 위한 security.ubuntu.com도 기본 설정에 사용된다.

공식 Ubuntu 저장소뿐 아니라 외부 개발자나 업체가 제공하는 제3자 APT 저장소도 등록할 수 있다. 이 경우 해당 저장소의 패키지를 시스템 수준의 권한으로 설치하게 되므로 저장소의 신뢰성과 서명 키 관리가 중요하다.^[117]

패키지 구성 요소

각 Ubuntu 아카이브 pocket은 다시 main, restricted, universe, multiverse라는 네 구성 요소(component)로 나뉜다.

main에는 Ubuntu의 기본 시스템과 주요 제품에 사용되는 오픈 소스 패키지가 포함되며 Canonical이 공식적인 유지보수와 보안 지원을 제공한다.^[118]

restricted에는 Canonical이 지원하지만 완전한 자유·오픈 소스 조건을 충족하지 않는 패키지가 포함된다. 대표적인 예가 일부 하드웨어용 독점 드라이버이다.

universe는 Ubuntu와 Debian 커뮤니티가 유지하는 방대한 오픈 소스 패키지 집합이다. main보다 훨씬 많은 응용 프로그램과 라이브러리가 여기에 포함될 수 있다. 기본 Canonical 지원 범위와는 다르지만 Ubuntu Pro의 ESM Apps를 통해 일부 보안 지원을 받을 수 있다.^[119]

multiverse에는 오픈 소스 요구사항을 완전히 충족하지 못하거나 저작권·특허·배포 조건 등의 제약이 존재하는 패키지가 포함된다.

이 네 구성 요소는 저장소의 별도 제품이 아니라 같은 Ubuntu archive를 지원 및 라이선스 성격에 따라 논리적으로 나눈 구조이다.

Personal Package Archive

Personal Package Archive(PPA)는 Launchpad가 제공하는 개인 또는 팀용 Ubuntu 패키지 저장소 서비스이다. 개발자는 공식 Ubuntu 아카이브에 포함되지 않은 패키지나 공식 버전과 다른 빌드를 PPA를 통해 배포할 수 있다.^[120]

PPA에서는 개발자가 일반적으로 소스 패키지를 Launchpad에 업로드한다. Launchpad의 빌드 시스템은 이를 지원되는 아키텍처용 바이너리 deb 패키지로 빌드하고 PPA 저장소에 게시한다.^[121]

사용자는 일반적으로 다음과 같은 식별자로 PPA를 추가할 수 있다.

ppa:소유자/아카이브

등록된 PPA는 일반적인 APT 저장소처럼 동작한다. apt update 이후 해당 PPA가 제공하는 패키지를 설치하거나 업데이트할 수 있으며, PPA의 버전이 Ubuntu 공식 저장소보다 높으면 기존 패키지가 PPA 버전으로 교체될 수도 있다.

PPA는 다음과 같은 용도로 사용된다.

• 아직 공식 Ubuntu에 포함되지 않은 소프트웨어 배포
• 새로운 버전의 응용 프로그램 제공
• 개발·시험 버전 배포
• 특정 버그 수정의 시험
• 프로젝트별 Ubuntu 패키지 제공

다만 PPA는 Ubuntu 공식 저장소가 아니다. 각 PPA의 패키지와 보안 유지보수 책임은 해당 PPA 소유자에게 있으며 Ubuntu 프로젝트가 모든 PPA를 검토하거나 보증하지 않는다.^[122]

Snap

Snap은 Canonical이 개발한 응용 프로그램 및 시스템 구성 요소용 패키지 형식과 배포 체계이다. Ubuntu에서는 snapd 데몬과 snap 명령을 통해 관리하며 Ubuntu Desktop에는 기본적으로 Snap 지원이 통합되어 있다.^[123]

deb 패키지가 시스템에 설치된 여러 라이브러리를 공유하는 방식이라면 Snap은 응용 프로그램이 필요한 구성 요소 상당 부분을 자체 패키지에 포함하거나 base snap 등 공통 Snap을 통해 제공할 수 있다. 따라서 Ubuntu의 특정 릴리스에 포함된 라이브러리 버전에 덜 종속된 응용 프로그램 배포가 가능하다.

Snap은 Ubuntu 릴리스와 독립적인 channel을 사용할 수 있다. 일반적으로 다음과 같은 위험 수준이 존재한다.

• stable
• candidate
• beta
• edge

응용 프로그램 개발자는 같은 Ubuntu 버전을 사용하는 사용자에게도 채널별로 서로 다른 Snap revision을 배포할 수 있다.

대부분의 Snap은 strict confinement를 사용해 호스트 시스템에서 어느 정도 격리된다. 파일, 카메라, 네트워크와 여러 시스템 자원은 interface를 통해 접근 권한을 부여받는다. strict confinement는 AppArmor, seccomp와 Linux namespace 등의 커널 기능을 활용한다.^[124]

시스템 전체에 자유롭게 접근해야 하는 프로그램은 classic confinement를 사용할 수도 있다. classic Snap은 일반적인 비격리 프로그램과 비슷한 접근 권한을 가지므로 Snap Store에서 이를 배포하려면 별도 검토가 필요하며 설치할 때도 --classic 옵션이 요구된다.^[125]

Snap의 또 다른 특징은 자동 업데이트(refresh)이다. snapd는 기본적으로 정기적으로 새 revision을 확인하고 자동으로 업데이트한다. 실행 중인 데스크톱 응용 프로그램은 일정 기간 업데이트를 미루고 종료된 뒤 새 revision으로 전환할 수 있다.^[126]

업데이트 시간대와 보류 여부 등은 refresh.timer, refresh.hold 등의 snapd 시스템 옵션으로 조절할 수 있다.^[127]

Snap은 데스크톱 애플리케이션뿐 아니라 서버 소프트웨어와 Ubuntu Core의 운영체제 구성 요소에도 사용된다.

Flatpak

Flatpak은 특정 Linux 배포판의 패키지 형식과 독립적으로 데스크톱 응용 프로그램을 배포하기 위해 개발된 패키징 및 샌드박싱 시스템이다. 응용 프로그램이 공통 runtime을 사용하고 호스트 시스템과 일정 수준 격리된 환경에서 실행된다는 점에서 Snap과 일부 목적이 겹친다.^[128]

Flatpak은 Ubuntu의 기본 데스크톱 패키지 체계는 아니지만 Ubuntu에서도 사용할 수 있다. flatpak 패키지는 Ubuntu의 universe 저장소를 통해 제공되며 사용자가 직접 설치할 수 있다.^[129]

Flatpak 애플리케이션의 대표적인 공개 저장소는 Flathub이다. Flatpak 설치 후 사용자가 Flathub remote를 추가하면 해당 저장소에서 응용 프로그램을 설치하고 업데이트할 수 있다.^[130]

Flatpak은 시스템 전체 설치와 사용자별 설치를 모두 지원한다. 시스템 설치 데이터는 일반적으로 /var/lib/flatpak, 사용자별 설치는 ~/.local/share/flatpak 아래에 저장된다.^[131]

Ubuntu의 기본 App Center는 Flatpak을 기본 통합하지 않는다. 따라서 Flatpak 응용 프로그램은 명령줄 도구나 Flatpak을 지원하는 별도의 소프트웨어 관리 프로그램을 통해 관리할 수 있다.^[132]

Ubuntu에서는 deb, Snap과 Flatpak을 같은 시스템에서 동시에 사용할 수 있기 때문에 동일한 응용 프로그램이 여러 형식으로 제공되는 경우도 있다. 각각 별도의 패키지 데이터와 업데이트 체계를 사용한다.

소스 패키지

Ubuntu의 공식 아카이브에 업로드되는 패키지의 개발 단위는 기본적으로 소스 패키지(source package)이다. 빌드 서버가 소스 패키지를 받아 각 아키텍처에 맞는 바이너리 deb 패키지를 생성한다.

하나의 소스 패키지에서 하나 이상의 바이너리 패키지가 만들어질 수 있다. 예를 들어 한 프로젝트의 소스에서 런타임 라이브러리, 개발용 -dev 패키지, 명령줄 프로그램과 문서 패키지를 각각 생성할 수 있다.

Debian 계열의 전통적인 소스 패키지는 일반적으로 원본 업스트림 소스와 Debian/Ubuntu 패키징 변경 사항, 그리고 패키지 설명 파일 등으로 구성된다.

APT는 바이너리 패키지뿐 아니라 소스 패키지도 내려받을 수 있다.

apt source 패키지명

또는

apt-get source 패키지명

과 같은 방식이 사용된다.^[133]

소스 패키지는 바이너리 패키지와 별도로 저장소에 등록되므로 APT 설정에 deb-src 타입이 활성화되어 있어야 한다. Ubuntu 24.04 LTS 이후 deb822 형식에서는 ubuntu.sources의 Types:에 deb-src를 추가하는 방식으로 설정할 수 있다.^[134]

Ubuntu 개발 문서에서는 소스 패키지를 다루는 현대적인 개발 방식으로 git-ubuntu도 제공하고 있으며, 패키지의 Ubuntu 및 Debian 이력을 Git 기반으로 다루는 작업 흐름을 지원한다.^[135]

의존성 관리

deb 패키지는 자신이 동작하기 위해 필요한 다른 패키지를 의존성(dependency)으로 선언할 수 있다. APT는 사용자가 패키지를 설치하거나 제거할 때 이 관계를 분석하고 필요한 추가 패키지를 자동으로 선택한다.

예를 들어 응용 프로그램이 특정 공유 라이브러리를 필요로 한다면 그 라이브러리를 별도의 deb에 포함하지 않고 해당 라이브러리 패키지에 의존하도록 만들 수 있다. 여러 응용 프로그램이 같은 라이브러리를 공유하기 때문에 패키지 크기와 중복 파일을 줄일 수 있다.^[136]

Debian 패키지 메타데이터에는 단순한 필수 의존성 외에도 여러 관계를 표현할 수 있다.

• Depends
• Pre-Depends
• Recommends
• Suggests
• Conflicts
• Breaks
• Replaces
• Provides

APT는 이러한 관계와 설치 가능한 버전, 아키텍처, 저장소 우선순위를 함께 고려한다.

소스 패키지에는 프로그램을 빌드하는 데 필요한 Build-Depends도 존재한다. apt build-dep 또는 apt-get build-dep를 사용하면 해당 소스 패키지를 빌드하기 위해 필요한 패키지 집합을 자동으로 설치할 수 있다.^[137]

자동으로 설치된 의존 패키지가 더 이상 어떤 패키지에서도 필요하지 않으면 APT가 이를 식별할 수 있으며 apt autoremove 등을 통해 제거할 수 있다.

Snap과 Flatpak은 이와 다른 의존성 모델을 사용한다. Snap은 base snap이나 콘텐츠 인터페이스와 자체 번들된 파일을 활용하며, Flatpak은 공통 runtime과 애플리케이션별 파일을 사용한다. 이 때문에 동일한 응용 프로그램이라도 deb, Snap, Flatpak에서 저장 공간 사용량과 업데이트 구조가 다를 수 있다.

업데이트 관리

Ubuntu의 deb 기반 업데이트는 APT와 Ubuntu Archive의 -updates, -security 등의 pocket을 통해 이루어진다.

일반적인 수동 업데이트 흐름은 다음과 같다.

APT 업데이트 흐름

1. apt update
   ↓
2. 저장소에서 최신 패키지 색인 다운로드
   ↓
3. 설치된 버전과 저장소 버전 비교
   ↓
4. apt upgrade 또는 관련 업데이트 도구 실행
   ↓
5. 새 .deb 패키지 다운로드
   ↓
6. dpkg를 통해 새 버전 설치

apt update는 저장소 상태를 새로 읽는 과정이고, apt upgrade가 실제 설치된 패키지를 새로운 버전으로 교체하는 과정이다.^[138]

Ubuntu Desktop에서는 Software Updater와 App Center 등의 그래픽 도구를 통해 업데이트할 수도 있다. 이들 역시 deb 패키지를 처리할 때는 APT와 같은 패키지 데이터와 저장소를 사용한다.

Ubuntu Server는 기본 설정에서 보안 업데이트를 자동으로 설치할 수 있으며, 일반적인 자동 업데이트는 unattended-upgrades 계열의 기능을 통해 관리된다.^[139]

업데이트가 안정 Ubuntu 릴리스에 들어갈 때는 새로운 패키지를 즉시 모든 사용자에게 배포하지 않고 Stable Release Update(SRU) 절차를 거칠 수 있다. 수정 패키지는 먼저 -proposed에서 검증되고 조건을 충족하면 -updates로 이동한다.

Ubuntu는 일부 패키지 업데이트에 phased updates를 적용할 수도 있다. 업데이트를 한 번에 모든 사용자에게 노출하지 않고 일정 비율의 시스템에 단계적으로 제공함으로써 예상하지 못한 회귀가 발견됐을 때 전체 사용자에게 영향을 미치는 것을 줄이는 방식이다.

보안 수정은 -security pocket을 통해 제공되며 지원 기간과 패키지 구성 요소에 따라 Canonical 또는 커뮤니티의 유지관리 범위가 달라진다.

Snap은 APT와 독립적으로 snapd가 자동 refresh를 수행한다. 기본적으로 snapd는 하루 동안 여러 차례 새 revision을 확인하며, 관리자는 refresh 일정이나 일정 기간 보류 여부를 설정할 수 있다.^[140]

Flatpak 역시 자체 remote를 기준으로 업데이트를 관리하며 APT 업데이트와는 별도의 과정이다.

따라서 여러 패키지 형식을 사용하는 Ubuntu 시스템에서는 다음과 같이 각 체계가 독립적인 업데이트 경로를 가진다.

Ubuntu의 주요 업데이트 경로

• Ubuntu 시스템
  • deb
    • APT
    • Ubuntu Archive
    • PPA·외부 APT 저장소
  • Snap
    • snapd
    • Snap Store 및 Snap 채널
  • Flatpak
    • flatpak
    • Flathub 등 Flatpak remote

이 구조 덕분에 Ubuntu는 운영체제 자체와 핵심 라이브러리는 전통적인 deb/APT 모델로 안정적으로 관리하면서, 필요에 따라 Ubuntu 릴리스 주기와 독립적으로 배포되는 응용 프로그램 패키지 형식을 함께 사용할 수 있다.

Ubuntu의 공식 소프트웨어 저장소는 Ubuntu Package Archive를 중심으로 구성된다. 이 아카이브에는 Ubuntu에서 제공하는 소스 패키지와 각 지원 아키텍처용 바이너리 패키지, 그리고 APT가 패키지를 검색하고 버전을 비교하는 데 사용하는 메타데이터가 저장된다.^[141]

Ubuntu Archive는 크게 series, pocket, component라는 축으로 구분할 수 있다. series는 noble, resolute처럼 하나의 Ubuntu 릴리스를 의미하고, pocket은 해당 릴리스의 최초 패키지와 이후 업데이트의 목적을 구분하며, component는 패키지의 라이선스와 지원 주체에 따라 아카이브를 분류한다.

Ubuntu Package Archive의 기본 구조

• Ubuntu Package Archive
  • Ubuntu 릴리스 series
    • release
    • updates
    • security
    • backports
    • proposed
  • 각 pocket의 component
    • main
    • universe
    • restricted
    • multiverse

따라서 main, universe, restricted, multiverse와 updates, security, backports, proposed는 같은 종류의 분류가 아니다. 전자는 component, 후자는 pocket이다. 예를 들어 Ubuntu 26.04의 resolute-updates 안에도 다시 main, universe, restricted, multiverse가 존재할 수 있다.^[142]

APT 설정에서는 이 구조가 다음과 같이 조합된다.

resolute-updates main universe restricted multiverse

이는 Ubuntu 26.04의 updates pocket에서 네 component를 모두 사용한다는 의미이다.

Main

Main은 Ubuntu가 공식적으로 지원하는 오픈 소스 패키지를 포함하는 component이다. Ubuntu의 기본 시스템을 구성하거나 Canonical이 지원하는 주요 워크로드에 필요한 패키지가 여기에 포함된다.^[143]

Ubuntu의 기본 설치에 포함되는 핵심 패키지는 일반적으로 main 또는 필요한 경우 restricted에 있어야 한다. Ubuntu의 Main Inclusion Review 문서는 기본 Ubuntu 설치에 필요한 패키지가 높은 수준의 품질 관리와 장기 유지보수를 보장하기 위해 main 또는 restricted에 속해야 한다고 규정한다.^[144]

main에는 운영체제의 핵심 구성 요소뿐 아니라 Canonical이 공식적으로 지원 대상으로 선정한 서버·클라우드·개발 워크로드용 패키지도 들어갈 수 있다. 따라서 main을 단순히 "기본 설치에 들어 있는 패키지"로만 정의할 수는 없다.

universe에 있던 패키지가 Ubuntu 기본 시스템이나 공식 지원 워크로드의 의존성이 되어 Canonical의 지원 범위에 들어가야 하는 경우 Main Inclusion Review(MIR)를 거쳐 main으로 승격될 수 있다. 이 과정에서는 보안 상태, 패키지 품질, 유지관리 가능성, 테스트와 의존성 등이 검토된다.^[145]

main은 기본 LTS 지원 기간 동안 Canonical의 표준 보안 유지보수 범위에 포함된다. LTS의 표준 지원 기간이 끝난 뒤에는 지원되는 릴리스에 대해 Ubuntu Pro의 ESM Infra를 통해 추가적인 보안 유지보수를 받을 수 있다.

Universe

Universe는 Ubuntu Archive에 포함된 오픈 소스 패키지 가운데 main에 포함되지 않은 방대한 패키지 집합이다. Debian과 Ubuntu 커뮤니티가 유지하는 수많은 응용 프로그램, 라이브러리, 개발 도구와 기타 소프트웨어가 여기에 포함된다.^[146]

Ubuntu가 Debian에서 패키지를 가져올 때 많은 패키지가 universe에 들어간다. 따라서 Ubuntu의 공식 설치 이미지에 기본으로 포함되지 않더라도 APT를 통해 설치할 수 있는 오픈 소스 프로그램의 상당수가 이 component에 존재한다.

전통적으로 universe는 Canonical의 기본 보안 지원 범위가 아니라 Ubuntu와 Debian 커뮤니티가 유지하는 영역이다. 다만 Ubuntu Pro의 ESM Apps는 지원되는 LTS에서 universe에 포함된 많은 패키지에 추가적인 보안 업데이트를 제공할 수 있다.^[147]

universe 패키지가 Ubuntu의 공식 지원 영역에 필요해지면 MIR 절차를 통해 main으로 이동할 수 있다. 반대로 더 이상 main의 조건을 충족하지 않거나 공식 지원 필요성이 사라진 패키지는 component가 변경될 수 있다.

현대 Ubuntu에서는 universe가 기본 APT 설정에 일반적으로 활성화되어 있으므로 사용자가 별도의 저장소를 추가하지 않아도 해당 패키지를 검색하고 설치할 수 있다.^[148]

Restricted

Restricted는 Canonical이 공식적으로 지원하지만 완전한 자유·오픈 소스 라이선스 조건을 충족하지 않는 패키지를 포함하는 component이다.^[149]

대표적으로 Ubuntu에서 특정 하드웨어를 정상적으로 사용하기 위해 필요한 일부 독점 장치 드라이버와 펌웨어가 이 영역에 포함될 수 있다.

Ubuntu는 가능한 한 자유 소프트웨어를 기본으로 사용하는 것을 지향하지만 현실적으로 일부 하드웨어는 제조사가 제공하는 비자유 드라이버 없이는 충분한 기능을 사용할 수 없다. Ubuntu는 이러한 경우 사용성 및 하드웨어 지원과 자유 소프트웨어 원칙 사이의 절충으로 restricted component를 별도로 운영한다.

restricted는 라이선스 성격은 main과 다르지만 Canonical의 공식 지원 범위라는 점에서는 main과 같은 축에 위치한다.

이를 단순화하면 다음과 같다.

multiverse 패키지가 Canonical의 공식 지원 대상으로 들어가야 하는 경우에는 MIR 계열 검토를 거쳐 restricted로 승격될 수 있다.^[150]

Multiverse

Multiverse는 Ubuntu Archive에 포함되어 있지만 자유·오픈 소스 소프트웨어의 요건을 충족하지 않거나 저작권, 특허, 재배포 조건 등의 제약이 존재하는 커뮤니티 관리 패키지를 포함한다.^[151]

restricted와 multiverse의 가장 중요한 차이는 단순히 소스 코드 공개 여부가 아니라 Canonical의 공식 지원 여부이다. restricted는 제한적인 라이선스를 가진 소프트웨어이지만 Canonical 지원 대상이고, multiverse는 일반적으로 그렇지 않다.

multiverse에는 소프트웨어의 라이선스나 특허 상태 때문에 모든 지역에서 자유롭게 사용하거나 재배포할 수 없는 패키지가 들어갈 수 있다. Ubuntu 공식 문서는 특정 multiverse 패키지가 사용자의 지역에서 법적으로 사용할 수 없는 경우도 있을 수 있으므로 관련 조건을 확인해야 한다고 설명한다.^[152]

현대 Ubuntu에서는 universe와 함께 multiverse도 일반적으로 기본 저장소 설정에서 활성화되어 있지만, 필요한 경우 APT source 설정에서 component를 제거하여 비활성화할 수 있다.

Updates

Updates, 즉 -updates pocket은 Ubuntu 정식 릴리스 이후 제공되는 일반적인 안정 업데이트가 들어가는 영역이다.

예를 들어 Ubuntu 26.04의 경우 다음과 같이 표현된다.

resolute-updates

정식 Ubuntu 버전이 공개된 뒤에는 해당 릴리스의 기본 release pocket을 자유롭게 변경하지 않는다. 대신 버그 수정과 검증된 변경 사항은 Stable Release Update 절차 등을 통해 -updates로 제공된다.

이는 이미 설치되어 운영되고 있는 시스템에서 예상하지 못한 기능 변화와 회귀를 최소화하기 위한 구조이다.

일반적인 안정 버전 업데이트 흐름

1. Ubuntu 정식 릴리스
   ↓
2. 문제 발견 및 수정
   ↓
3. 수정 패키지 준비
   ↓
4. -proposed에서 검증
   ↓
5. Stable Release Update 조건 충족
   ↓
6. -updates로 이동
   ↓
7. 일반 사용자에게 APT 업데이트로 제공

-updates에는 단순한 오류 수정 외에도 Ubuntu의 안정 릴리스 정책에서 허용되는 범위의 기능 개선이나 특정 하드웨어 지원 변경 등이 포함될 수 있다.

모든 프로그램이 최초 릴리스 당시 버전에 완전히 고정되는 것도 아니다. 웹 브라우저와 같이 보안상 최신 버전을 계속 추적해야 하는 일부 패키지는 일반적인 안정 버전 정책과 다른 방식으로 새로운 업스트림 버전이 제공될 수 있다.

APT 설정에서는 일반적으로 기본 release와 함께 -updates가 활성화되어 있으므로 사용자는 apt update와 apt upgrade 등을 통해 이러한 변경 사항을 받는다.

Security

Security, 즉 -security pocket은 지원 중인 Ubuntu 릴리스의 보안 취약점을 수정하는 업데이트를 배포하는 영역이다.

Ubuntu 26.04의 경우 다음과 같이 표현된다.

resolute-security

Ubuntu Security Team과 관련 패키지 유지관리자는 공개되거나 발견된 보안 취약점을 분석하고, 지원 범위에 있는 패키지에 필요한 수정 사항을 준비한다. 수정된 패키지는 보안 pocket을 통해 사용자에게 제공될 수 있다.

보안 업데이트는 일반 업데이트보다 빠른 배포가 특히 중요하다. 일반 Ubuntu Archive는 세계 여러 미러에 복제되기 때문에 미러 동기화 과정에서 일정한 지연이 발생할 수 있다.

이를 줄이기 위해 Ubuntu의 기본 APT 설정은 **security.ubuntu.com**에서도 보안 업데이트를 직접 확인하도록 구성된다. Ubuntu 공식 문서에 따르면 보안 업데이트는 먼저 이 경로에 게시되며, 사용 중인 미러에 아직 패키지가 동기화되지 않았을 경우 클라이언트가 security.ubuntu.com에서 받을 수 있다.^[153]

이는 취약점이 공개된 뒤 공격자가 이를 이용하기 시작할 수 있는 시간과 사용자에게 수정본이 도달하는 시간 사이의 간격을 줄이는 역할을 한다.

-security에서도 main, restricted, universe, multiverse component 구분은 유지된다. 다만 실제 보안 유지보수 범위는 component와 Ubuntu 버전, Ubuntu Pro 적용 여부에 따라 달라진다.

Backports

Backports, 즉 -backports pocket은 새로운 Ubuntu 버전에 포함된 일부 소프트웨어를 이전의 안정 Ubuntu 릴리스에서도 사용할 수 있도록 역이식(backport)한 패키지를 제공한다.^[154]

예를 들어 안정 LTS에 포함된 프로그램보다 이후 Ubuntu 릴리스에 훨씬 새로운 버전이 존재하고, 사용자가 해당 기능을 이전 릴리스에서도 필요로 할 경우 새 패키지를 기존 환경에 맞추어 다시 빌드하고 테스트하여 backport할 수 있다.

Backports의 목적은 일반적인 버그 수정이 아니다. Ubuntu 공식 문서에서는 안정 릴리스의 버그를 수정하기 위해 Backports를 사용하는 대신 문제의 성격에 따라 Security Update 또는 Stable Release Update 절차를 사용할 것을 명시한다.^[155]

Backports는 본질적으로 안정 릴리스가 처음 제공했던 버전보다 새로운 기능을 가져오기 때문에 기존 release나 updates보다 추가적인 호환성 위험이 존재할 수 있다.

이 때문에 backported 패키지는 사용자가 명시적으로 선택해야 하는 방향으로 설계되어 있다. Ubuntu 공식 Backports에 포함될 패키지는 해당 안정 릴리스에서 실제로 빌드되고 테스트되어야 한다.

Ubuntu 26.04의 Backports pocket은 다음과 같이 표현된다.

resolute-backports

Backports 역시 별도의 완전히 독립된 저장소가 아니라 Ubuntu Archive의 pocket 가운데 하나이다.

Proposed

Proposed, 즉 -proposed pocket은 Ubuntu 패키지가 일반 사용자에게 공개되기 전에 통합과 검증을 수행하는 시험 영역이다.^[156]

개발 중인 Ubuntu 릴리스에서는 새로운 패키지, Debian에서 가져온 패키지와 Ubuntu 개발자가 수정한 패키지가 우선 -proposed에 들어갈 수 있다. 자동 빌드, 의존성 분석과 각종 테스트를 통과하면 실제 개발 릴리스의 release pocket으로 이동한다. 이 과정을 proposed migration이라고 한다.

안정 Ubuntu 릴리스에서도 Stable Release Update 후보가 먼저 -proposed에 게시되고 실제 문제가 해결되는지, 새로운 회귀가 발생하지 않는지를 검증한 뒤 -updates로 이동한다.^[157]

`-proposed`의 역할

1. 새 패키지 또는 수정 패키지 업로드
   ↓
2. -proposed
   ↓
3. 빌드 및 의존성 검사
   ↓
4. 자동 테스트와 실제 수정 검증
   ↓
5. 회귀 여부 확인
   ↓
6. 조건 충족 시 일반 pocket으로 이동

-proposed는 일반 사용자가 항상 활성화해 최신 패키지를 받는 저장소가 아니다. 테스트되지 않은 변경이나 여러 패키지 사이의 전환 과정이 존재할 수 있기 때문이다.

Ubuntu는 필요한 패키지만 -proposed에서 선택적으로 설치해 시험할 수 있는 방법을 제공한다. Ubuntu 24.04 LTS 이후의 예에서는 별도의 deb822 source를 추가한 뒤 다음과 같은 방식으로 특정 패키지를 선택할 수 있다.

apt install -t <series>-proposed <패키지>

Ubuntu의 공식 SRU 문서 역시 -proposed를 **새 패키지가 -updates로 공개되기 전에 시험하는 영역**으로 설명한다.^[158]

미러 서버

Ubuntu Archive는 전 세계에서 매우 많은 시스템이 동시에 사용하기 때문에 하나의 중앙 서버만으로 패키지를 배포하지 않는다. 대신 공식 아카이브의 내용을 여러 지역과 기관의 미러 서버(mirror server)가 복제하여 제공한다.^[159]

미러는 다음과 같은 목적을 가진다.

• 중앙 Ubuntu 서버의 네트워크 부하 분산
• 사용자와 가까운 서버를 통한 다운로드 지연 감소
• 특정 서버 장애 시 가용성 확보
• 대규모 Ubuntu 업데이트의 전 세계 분산 제공

Ubuntu에는 일반 패키지를 제공하는 Archive mirror와 설치 ISO 등의 릴리스 이미지를 제공하는 Releases/CD image mirror가 구분되어 있다.^[160]

일부 국가는 공식 country mirror를 갖는다. 이러한 미러는 다음 형식의 주소로 접근할 수 있다.

<국가 코드>.archive.ubuntu.com

예를 들어 특정 국가에 승인된 country mirror가 존재하면 해당 도메인이 실제 미러 서버로 연결된다. 승인된 별도 미러가 없는 국가에서는 동일한 형식의 주소가 Ubuntu의 기본 아카이브 서버로 연결될 수도 있다.^[161]

Ubuntu 설치 과정에서는 선택한 국가나 환경에 따라 적절한 미러가 기본값으로 설정될 수 있으며, 사용자는 이후 다른 공식 미러로 변경할 수도 있다.

Ubuntu가 공식적으로 인정하는 공용 미러는 Launchpad에 등록된다. 등록된 미러는 상태가 확인되고 공식 미러 목록에 표시될 수 있다.^[162]

Archive mirror는 원본 저장소와 지속적으로 동기화되어야 한다. Ubuntu는 공식 country mirror에 대해 일반 Archive의 경우 하루 네 번, 약 6시간 간격으로 동기화할 것을 요구하며, 필요하면 변경 직후 동기화를 시작하는 push mirroring도 사용할 수 있다.^[163]

패키지 아카이브를 안전하게 동기화하려면 패키지 파일과 APT의 Packages 색인 사이에 불일치가 발생하지 않도록 하는 것도 중요하다. Ubuntu는 새 패키지를 먼저 복제하고 메타데이터를 갱신한 뒤 오래된 패키지를 제거하는 two-stage sync 방식을 권장한다.^[164]

보안 업데이트는 일반 미러 동기화에 따른 지연이 치명적일 수 있으므로 별도의 security.ubuntu.com 경로가 함께 사용된다. 따라서 일반적인 Ubuntu 시스템에서 패키지 다운로드는 가까운 Archive mirror가 담당하고, 긴급한 보안 업데이트는 필요하면 Canonical의 보안 아카이브에서 직접 받을 수 있다.

전체적으로 Ubuntu Archive는 다음과 같은 구조로 이해할 수 있다.

Ubuntu 소프트웨어 저장소 구조

• Ubuntu Package Archive
  • 릴리스 series
    • 예: resolute
  • pocket
    • release
    • -updates
    • -security
    • -backports
    • -proposed
  • component
    • main
    • universe
    • restricted
    • multiverse
  • 배포 인프라
    • archive.ubuntu.com
    • 국가별·지역별 Archive mirror
    • ports.ubuntu.com
    • security.ubuntu.com

이 구조에서 component는 어떤 종류의 패키지이며 누가 지원하는가를 나타내고, pocket은 해당 패키지가 릴리스 수명 주기의 어느 단계와 목적으로 제공되는가를 나타낸다. 미러 서버는 이렇게 구성된 아카이브의 실제 데이터를 전 세계 사용자에게 효율적으로 전달하는 배포 계층을 담당한다.

Ubuntu의 기본 데스크톱판인 Ubuntu Desktop은 GNOME을 기반으로 한다. 그러나 GNOME 프로젝트가 배포하는 기본 환경을 그대로 사용하는 것은 아니며 Canonical과 Ubuntu Desktop 팀이 테마, 확장 기능, 기본 응용 프로그램과 기본 설정을 조정한 Ubuntu 고유의 데스크톱 세션을 제공한다.^[165]

2026년의 Ubuntu 26.04 LTS는 GNOME 50을 기본 데스크톱 환경으로 사용하며, Ubuntu의 기본 GNOME 세션은 Wayland만을 디스플레이 서버 프로토콜로 사용한다. 기존 X11 응용 프로그램은 XWayland 호환 계층을 통해 실행할 수 있다.^[166]

Ubuntu는 GNOME 기반 기본판 외에도 KDE Plasma, Xfce, LXQt, MATE 등 서로 다른 데스크톱 환경을 사용하는 공식 Ubuntu Flavor를 제공한다. 따라서 이 절에서 설명하는 구성은 별도 언급이 없는 한 표준 Ubuntu Desktop을 기준으로 한다.

Ubuntu Desktop

Ubuntu Desktop은 개인용 PC와 노트북을 대상으로 하는 Ubuntu의 공식 데스크톱 제품이다. 일반적인 웹 브라우징, 문서 작업과 멀티미디어뿐 아니라 소프트웨어 개발, 콘텐츠 제작과 AI·머신러닝 작업 등에 사용할 수 있도록 데스크톱 그래픽 환경과 기본 응용 프로그램을 하나의 설치 환경으로 제공한다.^[167]

Ubuntu Desktop은 별도의 독립적인 운영체제가 아니라 Ubuntu의 동일한 패키지 아카이브와 기반 시스템 위에 데스크톱 관련 패키지와 기본 설정을 조합한 형태이다. 따라서 Ubuntu Server에 필요한 데스크톱 패키지를 추가하거나 Ubuntu Desktop에서 서버 소프트웨어를 설치하는 것도 가능하다.

표준 Ubuntu Desktop 세션의 중심 구성은 다음과 같다.

Ubuntu Desktop의 주요 구성

• Ubuntu Desktop
  • GNOME
    • GNOME Shell
    • Mutter
    • GNOME Settings
    • GNOME 기반 응용 프로그램
  • Ubuntu 사용자 환경
    • Ubuntu Dock
    • AppIndicators
    • Desktop Icons NG
    • Yaru
    • Ubuntu 글꼴
  • 그래픽 세션
    • Wayland
    • XWayland
  • 로그인
    • GDM
  • 응용 프로그램
    • Firefox
    • LibreOffice
    • Thunderbird
    • Files
    • App Center
    • 기타 기본 도구

설치 단계에서는 전체 기본 응용 프로그램을 포함하는 설치와 보다 작은 소프트웨어 집합을 사용하는 구성을 선택할 수 있으므로 실제 설치되는 응용 프로그램의 범위는 설치 방식과 Ubuntu 버전에 따라 달라질 수 있다.

Ubuntu Desktop의 인터페이스는 상단 바, Activities 개요, 애플리케이션 검색, 가상 작업 공간과 Dock을 중심으로 구성된다. 상단 바에서는 시간과 일정, 네트워크, 오디오, 전원과 여러 시스템 상태에 접근할 수 있으며 Super 키를 누르면 Activities 개요를 열어 실행 중인 창과 작업 공간을 확인하거나 프로그램·파일 등을 검색할 수 있다.^[168]

GNOME

GNOME은 Ubuntu Desktop의 기본 데스크톱 환경이다. Ubuntu는 초기 릴리스부터 GNOME 2를 사용했으며, 2011년부터 자체 인터페이스인 Unity를 기본으로 사용한 시기를 거친 뒤 Ubuntu 17.10부터 GNOME Shell 기반 데스크톱으로 돌아왔다.

GNOME은 하나의 프로그램이 아니라 셸, 창 관리자와 컴포지터, 설정 서비스, 시스템 설정 프로그램과 여러 기본 응용 프로그램으로 구성되는 데스크톱 플랫폼이다.

그 중심에는 GNOME Shell과 Mutter가 있다. GNOME Shell은 상단 바, Activities, 애플리케이션 실행과 검색, 알림, 작업 공간 등 사용자가 직접 보는 데스크톱 셸을 제공한다. Mutter는 GNOME의 창 관리자이자 Wayland 컴포지터 역할을 수행한다.

2026년 Ubuntu 26.04 LTS는 GNOME 50을 포함한다. 24.04 LTS의 GNOME 46 이후 GNOME 47부터 50까지의 변경이 누적되어 작은 화면 지원, 하드웨어 가속 화면 녹화, 파일 선택기와 Files 개선, 알림 그룹화, HDR, 디지털 웰빙, 가변 주사율과 fractional scaling, 원격 데스크톱, 접근성 등이 개선되었다.^[169]

Ubuntu에서 사용하는 GNOME은 흔히 Vanilla GNOME이라고 부르는 기본 GNOME 구성과 일부 차이가 있다. Ubuntu는 Firefox를 GNOME Web 대신 기본 브라우저로 제공하며, 자체 Dock과 AppIndicator 지원, 데스크톱 아이콘, Yaru 테마와 Ubuntu 글꼴 등의 변경을 추가한다.^[170]

Ubuntu는 GNOME의 기본 창 인터페이스에도 일부 차이를 둔다. 예를 들어 창 제목 표시줄에는 기본적으로 최소화와 최대화 버튼을 제공하며, Ubuntu의 기본 작업 흐름과 시각적 정체성을 위해 GNOME의 기본값과 일부 설정을 다르게 지정한다.

Ubuntu Shell과 확장 기능

Ubuntu에서 흔히 Ubuntu의 셸이라고 표현하는 데스크톱 인터페이스는 별도의 독자적인 셸을 사용하는 구조가 아니라 GNOME Shell에 Ubuntu가 선택한 설정과 확장 기능을 적용한 것이다. 과거 Unity처럼 Ubuntu가 별도의 데스크톱 셸을 직접 제공하는 구조와는 다르다.

Ubuntu의 GNOME Shell 사용자 경험에서 가장 눈에 띄는 차이 가운데 하나는 Ubuntu Dock이다. GNOME의 기본 Dash 기능을 확장하여 화면 가장자리에 지속적으로 표시할 수 있는 애플리케이션 Dock을 제공하고, 즐겨찾는 프로그램 실행과 실행 중인 프로그램 관리에 사용된다.^[171]

기본 Ubuntu 세션에는 다음과 같은 기능이 GNOME Shell 확장 형태로 통합된다.

Ubuntu 26.04에서는 이들 Ubuntu용 GNOME Shell 확장의 패키징도 정리되어 주요 Ubuntu 확장 기능이 gnome-shell-ubuntu-extensions를 통해 제공된다.^[172]

Ubuntu Dock은 즐겨찾기와 현재 실행 중인 프로그램을 표시하며 애플리케이션 목록을 여는 버튼도 제공한다. 기본 GNOME에서는 Dash가 주로 Activities 화면에서 나타나는 데 비해 Ubuntu에서는 Dock을 데스크톱에서 계속 사용할 수 있도록 구성한다.

AppIndicators 확장은 GNOME Shell이 기본적으로 지원하지 않는 AppIndicator와 KStatusNotifierItem 계열의 상태 아이콘을 상단 바에 표시하도록 한다. 백그라운드 프로그램, 메신저와 여러 데스크톱 응용 프로그램이 이 인터페이스를 사용할 수 있다.^[173]

Desktop Icons NG(DING)는 바탕화면에 파일과 디렉터리, 마운트된 장치 등의 아이콘을 표시할 수 있게 한다. 현대 GNOME Files 자체에서는 데스크톱 아이콘 관리 기능이 제거되었으므로 Ubuntu는 이를 Shell 확장을 통해 제공한다.

Ubuntu의 기본 시각 디자인에는 Yaru 테마가 사용된다. Yaru는 GTK 응용 프로그램, GNOME Shell과 아이콘 등을 Ubuntu 스타일로 통합하며 밝은·어두운 인터페이스와 Ubuntu의 강조색을 제공한다. Ubuntu 26.04에서는 Yaru가 업스트림 GNOME의 시각적 방향에 보다 가까워지고 여러 아이콘도 갱신되었다.^[174]

GNOME Shell은 추가 확장을 설치할 수 있는 구조이므로 사용자가 기본 Ubuntu 구성 이외의 확장을 추가해 창 관리, 패널, 작업 공간과 시스템 표시 방식을 변경하는 것도 가능하다. 다만 Shell의 내부 API는 GNOME 버전에 따라 변경될 수 있으므로 확장은 사용하는 GNOME 버전과 호환되어야 한다.

Wayland

Wayland는 현대 Ubuntu Desktop에서 기본적으로 사용되는 그래픽 디스플레이 프로토콜이다. 전통적인 X Window System과 달리 애플리케이션과 컴포지터 사이의 그래픽·입력 처리 구조를 보다 단순하고 현대적인 방식으로 설계한다.

GNOME 환경에서는 Mutter가 Wayland 컴포지터 역할을 맡는다. 애플리케이션의 화면 내용을 조합하고 창의 위치와 크기를 관리하며 키보드·마우스·터치 입력과 디스플레이 출력을 중재한다.

Ubuntu는 여러 릴리스에 걸쳐 X11과 Wayland를 병행하며 Wayland 사용 범위를 확대해 왔다. Ubuntu 25.10부터 표준 Ubuntu Desktop GNOME 세션은 Wayland 백엔드만으로 실행되며, 이 정책은 Ubuntu 26.04 LTS에도 이어진다. GNOME Shell 자체가 더 이상 X.org 세션으로 실행되지 않기 때문이다.^[175]

이는 X11용 응용 프로그램을 Ubuntu Desktop에서 더 이상 사용할 수 없다는 의미는 아니다. 기존 X11 프로그램은 XWayland를 통해 Wayland 데스크톱 안에서 실행된다.

Wayland 세션에서 기존 X11 프로그램 실행

1. Ubuntu GNOME Wayland 세션
   ↓
2. X11 전용 프로그램 실행
   ↓
3. XWayland가 X11 호환 서버 제공
   ↓
4. 프로그램의 창을 Wayland 환경과 연결
   ↓
5. Mutter가 다른 Wayland 창과 함께 합성

Wayland 구조는 애플리케이션이 다른 프로그램의 입력이나 화면 내용을 임의로 관찰하는 것을 줄일 수 있어 보안 격리 측면에서도 장점이 있다. 반면 화면 공유, 원격 제어, 전역 단축키와 자동화처럼 X11에서 프로그램이 직접 수행하던 작업은 Wayland에서는 compositor와 XDG Desktop Portal 등의 명시적인 인터페이스를 사용해야 하는 경우가 많다.

최근 Ubuntu와 GNOME에서는 이러한 Wayland 환경을 전제로 화면 공유, 원격 데스크톱, HDR, fractional scaling, VRR와 NVIDIA 그래픽 지원을 지속적으로 개선해 왔다. Ubuntu 26.04에서는 HDR 화면의 화면 녹화·공유, 색 관리, NVIDIA에서의 부드러운 동작과 원격 데스크톱 하드웨어 가속 등이 개선되었다.^[176]

X Window System

X Window System, 특히 현대 Linux에서 일반적으로 사용되는 X.Org Server는 오랫동안 Ubuntu Desktop의 기본 디스플레이 시스템이었다. X11 프로토콜은 클라이언트와 디스플레이 서버를 분리하는 네트워크 투명성 구조를 가지며 수십 년 동안 Unix 계열 그래픽 환경의 표준 기반으로 사용되었다.

과거 Ubuntu에서는 로그인 화면에서 Ubuntu와 Ubuntu on Xorg 같은 세션을 선택하여 Wayland와 X11 세션 사이를 전환할 수 있었다. 특정 그래픽 드라이버나 응용 프로그램이 Wayland와 충분히 호환되지 않는 경우 Xorg 세션을 대안으로 사용할 수 있었다.

그러나 GNOME의 X11 세션 지원 축소에 따라 Ubuntu 25.10 이후 표준 Ubuntu GNOME 세션에서는 Xorg 세션이 제거되었다.^[177]

X11 기술 자체가 Ubuntu에서 제거된 것은 아니다. Wayland에서 기존 X11 애플리케이션을 실행하기 위해 XWayland가 사용되며, Ubuntu 저장소에는 X.Org 관련 패키지도 계속 제공된다.

또한 Ubuntu의 모든 데스크톱 환경이 GNOME과 같은 전환 일정을 따르는 것은 아니다. Ubuntu 공식 릴리스 문서에 따르면 KDE의 X11 세션이나 Xfce, MATE, i3 등 다른 데스크톱·창 관리자 환경에서는 여전히 X.org 세션을 사용할 수 있다.^[178]

따라서 현대 Ubuntu에서 X11은 표준 GNOME 데스크톱 세션의 기반에서는 Wayland에 자리를 넘겼지만, 애플리케이션 호환 계층과 다른 데스크톱 환경에서는 계속 중요한 역할을 한다.

디스플레이 관리자

Ubuntu Desktop의 기본 디스플레이 관리자(display manager)는 GDM(GNOME Display Manager)이다. GDM은 그래픽 부팅 이후 로그인 화면을 표시하고 사용자를 인증한 뒤 선택된 데스크톱 세션을 시작한다. Ubuntu 공식 문서 역시 GDM을 GNOME과 Ubuntu의 기본 데스크톱 관리자로 설명한다.^[179]

GDM은 다음과 같은 역할을 담당한다.

• 그래픽 로그인 화면 표시
• 사용자 계정 선택
• 비밀번호 등의 인증 처리
• 접근성 기능 제공
• 세션 선택
• 사용자 데스크톱 세션 시작
• 사용자 전환
• 자동 로그인 처리

실제 사용자 인증에는 Linux의 PAM(Pluggable Authentication Modules) 체계가 사용된다. 환경에 따라 로컬 비밀번호 외에도 스마트 카드나 기업용 인증 체계를 GDM과 연동할 수 있다.

GDM의 로그인 화면도 GNOME 기술을 사용하며 접근성 메뉴와 Orca 스크린 리더 등을 로그인 이전부터 사용할 수 있다. Ubuntu 26.04의 접근성 개선에는 설치 프로그램과 로그인·GNOME 환경에서의 스크린 리더 동작 개선도 포함된다.^[180]

로그인 후 화면을 잠그는 기능은 별도의 새로운 로그인 세션을 만드는 것이 아니라 현재 사용자 세션을 보호한다. 잠금 화면에서는 시간, 일부 알림, 배터리와 네트워크 상태 등을 보여줄 수 있으며 인증을 마치면 기존 세션으로 돌아간다.^[181]

Ubuntu Flavor는 데스크톱 환경에 따라 다른 디스플레이 관리자를 사용할 수 있다. 따라서 GDM은 Ubuntu 전체에서 반드시 사용되는 로그인 관리자가 아니라 표준 GNOME 기반 Ubuntu Desktop의 기본값이다.

기본 응용 프로그램

Ubuntu Desktop은 설치 직후 일반적인 컴퓨터 작업을 수행할 수 있도록 여러 기본 응용 프로그램을 제공한다. 정확한 기본 프로그램 집합은 Ubuntu 버전과 설치 옵션에 따라 바뀔 수 있으며, Ubuntu는 업스트림 GNOME의 기본 응용 프로그램 구성과도 일부 다른 선택을 한다.

Ubuntu 26.04 LTS의 대표적인 기본·주요 데스크톱 응용 프로그램에는 다음과 같은 것들이 있다.

Ubuntu는 GNOME의 기본 웹 브라우저인 GNOME Web 대신 Firefox를 제공하며 GNOME Connections 대신 Remmina를 제공하는 등 업스트림 GNOME과 다른 응용 프로그램 선택을 한다.^[182]

GNOME Files, 흔히 프로젝트 이름인 Nautilus로도 알려진 파일 관리자는 로컬 파일과 폴더뿐 아니라 연결된 저장장치와 네트워크 위치 등을 관리한다. Ubuntu 26.04의 GNOME 50에서는 성능과 신뢰성, 사용자 인터페이스가 추가로 개선되었다.^[183]

PDF 등의 문서를 보는 기본 GNOME 응용 프로그램은 과거 Evince가 오랫동안 사용되었으나 Ubuntu 25.04부터 GTK 4 기반의 Papers로 전환되었다. Papers는 Evince 코드에서 출발했지만 일부가 Rust로 다시 작성되고 현대 GNOME 기술을 사용하도록 발전한 프로젝트이다.^[184]

터미널 프로그램 역시 Ubuntu 버전에 따라 변화해 왔으며, Ubuntu 25.04 이후의 현대 Ubuntu Desktop에서는 Ptyxis를 기본 터미널로 사용한다. Ubuntu는 기본 터미널을 변경할 수 있는 xdg-terminal-exec 기반 설정도 제공한다.^[185]

응용 프로그램 설치에는 App Center가 제공된다. App Center에서는 Snap과 Ubuntu 저장소의 deb 응용 프로그램을 검색하고 설치할 수 있으며 동일한 응용 프로그램이 두 형식으로 제공되는 경우 Snap이 우선적으로 표시될 수 있다.^[186]

Ubuntu 26.04 LTS에서는 Firefox 150, LibreOffice 25.8, Thunderbird 140 등의 버전이 기본 LTS 사용자에게 제공되었다.^[187]

사용자는 기본 프로그램에 제한되지 않으며 APT, App Center, Snap, Flatpak이나 개발자가 제공하는 별도 설치 방식을 통해 다른 응용 프로그램을 추가할 수 있다.

접근성

Ubuntu Desktop은 시각, 청각과 신체 움직임 등 다양한 환경의 사용자가 데스크톱을 사용할 수 있도록 GNOME의 접근성 기술과 Ubuntu 자체의 통합 기능을 제공한다.^[188]

주요 접근성 기능에는 다음이 포함된다.

• 화면 읽기
• 점자 출력 지원
• 화면 확대
• 고대비 표시
• 글자 크기 조절
• 화면 키보드
• Sticky Keys
• Slow Keys
• Bounce Keys
• 키보드를 이용한 포인터 이동
• Hover Click
• 시각적인 알림
• 애니메이션 감소
• 키보드 중심 인터페이스 탐색

시각 장애 사용자를 위한 핵심 구성 요소는 Orca 스크린 리더이다. Orca는 화면의 텍스트와 사용자 인터페이스를 음성 합성 또는 점자로 제공하며 GNOME과 AT-SPI 접근성 인터페이스를 지원하는 여러 응용 프로그램을 탐색할 수 있다. 표준 Ubuntu Desktop에는 Orca가 기본적으로 설치된다.^[189]

Super+Alt+S 단축키로 Orca를 켜거나 끌 수 있으며 로그인 화면에서도 같은 단축키를 사용할 수 있다. 마우스를 사용하지 않고 키보드만으로 GNOME의 주요 인터페이스와 접근성 메뉴를 탐색하는 것도 가능하다.^[190]

상단 바의 접근성 메뉴에서는 필요한 기능을 빠르게 활성화할 수 있다. 해당 아이콘을 항상 표시하도록 설정할 수도 있으며 GNOME Settings의 Accessibility 패널에서는 보다 세부적인 접근성 옵션을 관리한다.^[191]

물리 키보드를 사용할 수 없거나 터치 입력을 사용하는 환경에서는 화면 키보드를 활성화할 수 있다. 터치스크린이 사용되는 환경에서는 화면 키보드가 필요할 때 자동으로 표시될 수도 있다.^[192]

Wayland 전환 과정에서 과거 일부 접근성 기술과 단축키에 호환성 문제가 있었으나 GNOME과 Ubuntu는 이를 지속적으로 개선하고 있다. GNOME 48에서는 Wayland 세션에서 Orca modifier 등의 화면 읽기 단축키 동작이 개선되었고, GNOME 50에서는 Orca 자체와 Reduced Motion 기능 등이 추가로 개선되었다.^[193]

Ubuntu 26.04에서는 Ubuntu 고유 GNOME Shell 확장의 접근성도 개선되었으며, 기존에 스크린 리더로 사용하기 어려웠던 Ubuntu Desktop 설치 프로그램의 여러 문제도 수정되어 Orca를 사용한 설치가 가능하도록 개선되었다.^[194]

다국어 환경

Ubuntu Desktop은 설치 단계부터 여러 언어와 지역 설정을 지원하며 설치 이후에도 추가 언어를 설치하거나 사용자 인터페이스 언어와 키보드 입력 방식을 변경할 수 있다.

Ubuntu를 설치할 때 선택한 언어는 영어와 함께 설치되며 이후 Region & Language 및 Language Support 기능을 통해 추가 언어를 설치할 수 있다. 언어 지원 패키지에는 단순한 인터페이스 번역뿐 아니라 해당 언어에 필요한 맞춤법 검사 사전, 글꼴과 입력 방식 등이 함께 설치될 수 있다.^[195]

언어 설정과 지역 형식은 서로 독립적으로 지정할 수 있다. 따라서 사용자 인터페이스를 영어로 사용하면서 날짜, 시간, 통화와 측정 단위는 한국 형식으로 표시하거나 반대로 구성할 수 있다.^[196]

Ubuntu의 다국어 환경은 크게 다음 요소로 나눌 수 있다.

Ubuntu의 다국어 설정

• 다국어 환경
  • 표시 언어
    • 메뉴
    • 시스템 메시지
    • 도움말
  • 지역 형식
    • 날짜와 시간
    • 숫자
    • 통화
    • 측정 단위
  • 입력 소스
    • 키보드 배열
    • 언어별 입력 방식
  • 언어 지원 데이터
    • 번역
    • 글꼴
    • 맞춤법 사전
    • 입력 방식

하나의 사용자 계정에 여러 Input Source를 등록할 수 있다. 예를 들어 한국어와 영어, 일본어 입력을 동시에 등록하고 필요할 때 빠르게 전환할 수 있다.

현재 입력 소스는 상단 바에 짧은 식별자로 표시되며 기본적으로 Super+Space를 눌러 다음 입력 소스로, Shift+Super+Space를 눌러 이전 입력 소스로 전환할 수 있다. 이 단축키는 GNOME Settings에서 변경할 수 있다.^[197]

단순한 키보드 배열뿐 아니라 한글, 중국어, 일본어처럼 문자 조합이 필요한 언어는 입력기(input method)를 통해 입력할 수 있다. Ubuntu에서는 IBus를 비롯한 입력 방식 프레임워크를 사용할 수 있으며 설치된 언어 지원에 따라 필요한 입력 엔진을 추가할 수 있다.^[198]

각 사용자는 서로 다른 표시 언어와 입력 소스를 사용할 수 있다. 다중 사용자 시스템에서는 로그인 화면에 적용될 언어와 키보드 설정도 사용자 세션과 별도로 관리할 수 있다.^[199]

Ubuntu와 GNOME의 상당수 사용자 인터페이스는 커뮤니티 번역을 통해 여러 언어로 제공된다. 다만 모든 응용 프로그램이 Ubuntu 자체에서 개발되는 것은 아니므로 실제 번역 범위는 각 업스트림 프로젝트의 번역 상태에도 영향을 받는다. Ubuntu 공식 문서도 일부 언어의 번역이 완전하지 않거나 특정 응용 프로그램이 선택한 언어를 지원하지 않을 수 있음을 명시한다.^[200]

이러한 구조를 통해 Ubuntu Desktop은 운영체제 전체의 표시 언어, 지역 형식과 입력 체계를 서로 분리해 구성할 수 있으며, 하나의 설치에서 여러 언어를 동시에 사용하는 다국어 작업 환경도 지원한다.

Ubuntu Flavor는 Ubuntu의 공통 패키지 아카이브와 개발 기반을 사용하면서 데스크톱 환경이나 기본 응용 프로그램, 사용 목적을 달리 구성한 공식 배포 형태이다. 기본 Ubuntu Desktop이 GNOME을 중심으로 구성되는 것과 달리 각 Flavor는 KDE Plasma, Xfce, LXQt, MATE 등의 데스크톱을 선택하거나 교육·멀티미디어 제작처럼 특정 용도의 소프트웨어를 통합한다.^[201]

공식 Flavor라는 지위는 Canonical이 해당 데스크톱과 모든 응용 프로그램을 직접 개발한다는 의미는 아니다. 각 Flavor의 개발 팀이 패키지 선택, 기본 설정과 이미지 검증을 맡으며 Ubuntu의 릴리스 절차에 참여한다. 따라서 공통 기반 패키지의 지원과 Flavor 팀이 담당하는 데스크톱 패키지의 지원을 구분해야 하며, LTS 여부와 유지보수 기간도 각 프로젝트의 릴리스 발표를 기준으로 확인해야 한다.^[202]

Kubuntu

Kubuntu는 KDE Plasma를 기본 데스크톱으로 제공하는 Ubuntu Flavor이다. 패널, 애플리케이션 실행기, 위젯과 작업 공간을 사용자가 세밀하게 구성할 수 있으며, Dolphin 파일 관리자와 KDE 계열 응용 프로그램을 통합한다. GNOME 기반 Ubuntu와 화면 구성은 다르지만 APT와 Ubuntu 패키지 아카이브를 사용하는 기본 시스템은 공유한다.^[203]

Kubuntu에서 데스크톱의 동작은 Plasma와 KDE Frameworks, Qt 기반 응용 프로그램 사이의 통합에 의해 결정된다. 예를 들어 파일 관리, 시스템 설정과 창 배치 기능은 KDE의 구성 요소를 사용하므로 GNOME용 설정 절차가 그대로 적용되지 않을 수 있다. 또한 디스플레이 세션 정책도 릴리스에 따라 달라진다. Kubuntu 26.04는 Wayland 세션을 기본으로 제공하며, 별도로 설치할 수 있는 X11 세션 패키지와 프로젝트가 공식 지원하는 기본 세션을 구분하고 있다.^[204]

Xubuntu

Xubuntu는 Xfce 데스크톱을 사용하는 Ubuntu Flavor이다. 패널, 애플리케이션 메뉴, 창 관리자와 파일 관리자를 비교적 독립적인 구성 요소로 제공하며, 전통적인 데스크톱 작업 흐름을 유지한다. Xubuntu 프로젝트는 사용 편의성과 조정 가능한 가벼운 환경을 함께 지향하며, 설치 후에도 패널 배치와 기본 프로그램을 변경할 수 있다.^[205]

Xubuntu를 사용한다고 실행할 수 있는 프로그램이 Xfce 응용 프로그램으로 제한되는 것은 아니다. Ubuntu 저장소에서 GNOME이나 KDE 계열 프로그램을 설치할 수 있으며, 이때 필요한 라이브러리와 서비스가 의존성으로 추가된다. 따라서 기본 데스크톱의 자원 사용량과 실제 작업 전체의 자원 사용량은 구분해야 한다. 웹 브라우저, 가상 머신과 같은 프로그램을 함께 실행하면 전체 부하는 해당 작업의 특성에 크게 좌우된다.^[206]

Lubuntu

Lubuntu는 LXQt를 기본으로 사용하는 Ubuntu Flavor이다. LXQt는 Qt 기반의 패널, 세션 관리와 설정 도구 등을 제공하며, Lubuntu는 이를 기본 응용 프로그램과 설치 환경에 통합한다. 초기 Lubuntu는 LXDE를 사용했지만 이후 LXQt로 전환했으므로, 과거 LXDE용 설정 방법과 현대 Lubuntu의 설정 방식은 서로 다를 수 있다.^[207]

Lubuntu는 작은 기본 소프트웨어 구성과 단순한 데스크톱을 지향하지만, 특정 메모리 용량이나 오래된 모든 컴퓨터에서 동일한 성능을 보장하는 제품은 아니다. 지원 CPU 아키텍처와 그래픽 드라이버는 해당 Ubuntu 릴리스의 기반을 따르며, 브라우저와 작업 프로그램의 요구사항도 별도로 적용된다. 기본 LXQt 환경을 유지하면서 Ubuntu 저장소의 다른 프로그램을 추가할 수 있기 때문에 경량 데스크톱과 일반적인 Ubuntu 소프트웨어 생태계를 함께 활용할 수 있다.^[208]

Ubuntu MATE

Ubuntu MATE는 GNOME 2의 전통적인 데스크톱 구성을 계승한 MATE를 사용한다. 패널, 메뉴와 작업 표시줄을 중심으로 창을 관리하며, Caja 파일 관리자 등 MATE 계열 응용 프로그램을 통합한다. GNOME Shell의 Activities 중심 구성보다 전통적인 메뉴와 창 목록을 선호하는 사용자를 위한 선택지이다.^[209]

Ubuntu MATE는 오래된 GNOME 2 패키지를 그대로 보존하는 프로젝트가 아니라, MATE의 개발 성과를 현재 Ubuntu 기반에 통합하는 배포판이다. 데스크톱의 외형과 작업 흐름을 계승하면서도 패키지 관리, 보안 업데이트와 하드웨어 지원은 사용하는 Ubuntu 시리즈에 맞추어 갱신된다. 레이아웃과 패널 구성을 조절할 수 있어 기존 사용자에게 익숙한 화면을 유지하거나 다른 형태로 재구성할 수 있다.^[210]

Ubuntu Budgie

Ubuntu Budgie는 Budgie 데스크톱과 Ubuntu의 패키지 기반을 결합한 Flavor이다. Budgie의 패널과 Raven 사이드바를 통해 프로그램 실행, 알림과 데스크톱 조작 기능을 제공한다. Ubuntu Budgie는 기본 테마와 애플릿, 설정 도구를 조합하여 자체적인 사용자 경험을 구성하며, 표준 Ubuntu의 GNOME Shell 확장 구성과는 구별된다.^[211]

이 프로젝트의 차이는 데스크톱 셸 하나를 교체하는 데 그치지 않는다. 환영 도구와 추가 애플릿, 테마 선택 등 설치 이후의 환경 구성도 프로젝트가 통합하는 범위에 포함된다. 다만 실제 프로그램 실행과 패키지 갱신은 Ubuntu의 공통 기반을 사용하므로, Budgie 전용 도구와 APT·systemd 같은 일반 시스템 관리 계층을 구분하여 다루는 것이 적절하다.^[212]

Ubuntu Studio

Ubuntu Studio는 오디오 제작, 영상 편집, 그래픽, 사진과 출판 작업을 대상으로 하는 Ubuntu Flavor이다. KDE Plasma 데스크톱에 Ardour, Blender, Krita, Kdenlive, OBS Studio와 같은 제작 도구를 통합하며, 오디오 라우팅과 세션 관리 등 창작 작업에 필요한 설정도 제공한다. 일반 데스크톱에 프로그램을 많이 설치한 구성보다 제작 도구 사이의 연결과 작업 환경 통합을 중시한다.^[213]

특히 오디오에서는 처리량뿐 아니라 입력부터 출력까지의 지연 시간과 안정적인 실시간 처리가 중요하다. Ubuntu Studio는 PipeWire와 JACK 호환 기능, 관련 설정 도구 등을 활용하여 이러한 요구를 다룬다. 모든 버전이 반드시 별도의 저지연 커널만 사용하는 것은 아니며, 최근 구성에서는 generic 커널의 선점·인터럽트 관련 설정을 활용하는 방식도 사용한다. 따라서 커널 이름만으로 오디오 작업 적합성을 판단하기보다 해당 릴리스의 설정과 실제 장치의 지연·드롭아웃을 함께 확인해야 한다.^[214]

Ubuntu Kylin

Ubuntu Kylin은 중국어 사용자와 중국 지역의 사용 환경에 중점을 둔 공식 Ubuntu Flavor이다. UKUI 데스크톱을 중심으로 파일 관리, 설정과 기본 응용 프로그램을 통합하며, 중국어 입력과 지역화된 사용자 경험을 제공한다. 단순히 Ubuntu의 표시 언어를 중국어로 변경한 구성과는 달리 별도의 데스크톱과 기본 소프트웨어 선택을 갖는다.^[215]

Ubuntu Kylin의 지역화는 번역뿐 아니라 입력, 글꼴과 일상적으로 사용하는 프로그램의 통합까지 포함한다. 동시에 Ubuntu의 공통 패키지 기반을 사용하므로 일반적인 Linux 개발 도구와 서버 프로그램도 설치할 수 있다. UKUI와 그 응용 프로그램의 버전은 Ubuntu Kylin 릴리스에 따라 달라지며, 기본 Ubuntu GNOME의 설정 화면이나 확장 기능을 동일하게 적용하는 환경은 아니다.^[216]

Edubuntu

Edubuntu는 학교와 교육용 컴퓨터를 위해 Ubuntu Desktop에 교육 소프트웨어를 통합하는 Flavor이다. 학습용 프로그램을 개별적으로 찾아 설치하는 작업을 줄이고, 교육 목적에 맞는 프로그램 집합을 제공하는 데 초점을 둔다. 일반적인 Ubuntu 데스크톱을 기반으로 하므로 웹, 문서 작업과 개발 실습을 교육용 응용 프로그램과 함께 수행할 수 있다.^[217]

Edubuntu의 교육용 패키지는 모든 사용자가 동일한 프로그램을 전부 필요로 한다는 전제에만 의존하지 않는다. Edubuntu Installer와 관련 메타패키지를 통해 교육 단계나 용도에 맞는 소프트웨어 집합을 선택할 수 있다. 교육용 데스크톱을 제공하는 것과 학교 전체의 계정·수업·장치 관리를 자동으로 완성하는 것은 별개이므로, 다수의 컴퓨터를 운영하는 학교에서는 별도의 중앙 관리와 계정 정책을 결합할 수 있다.^[218]

Ubuntu Cinnamon

Ubuntu Cinnamon은 Cinnamon 데스크톱을 사용하는 공식 Flavor이다. 패널, 애플리케이션 메뉴, 알림 영역과 창 목록을 중심으로 하는 전통적인 데스크톱 인터페이스를 제공한다. Cinnamon의 애플릿과 확장 기능, 테마를 활용하면서 Ubuntu의 릴리스와 패키지 기반을 사용한다.^[219]

Cinnamon을 사용한다는 점에서 Linux Mint Cinnamon과 공통점이 있지만 두 배포판은 동일한 제품이 아니다. Ubuntu Cinnamon은 Ubuntu의 공식 Flavor이고, Linux Mint는 자체 저장소와 소프트웨어 관리 도구, 기본 정책을 유지하는 독립적인 파생 배포판이다. 따라서 데스크톱의 외형이 비슷하더라도 업데이트 도구와 기본 패키지, 지원 방식까지 같다고 볼 수는 없다.^[220][221]

기타 공식 Flavor

Ubuntu Unity는 Unity 7의 데스크톱 경험을 이어가는 공식 Flavor이다. Launcher와 Dash, 글로벌 메뉴와 HUD 등 과거 Ubuntu Desktop의 특징을 유지하면서 현재 Ubuntu 패키지 기반과 결합한다. GNOME Shell에 Ubuntu Dock을 추가한 표준 Ubuntu 세션과는 구현과 인터페이스가 다르다.^[222]

공식 Flavor의 목록과 릴리스 상태는 고정된 것이 아니다. 프로젝트가 새로 승인되거나 특정 릴리스를 제공하지 않을 수 있으며, Ubuntu 본판이 LTS로 공개되더라도 모든 Flavor가 같은 릴리스에 LTS 지위를 부여받는 것은 아니다. 예를 들어 Ubuntu Unity는 26.04를 일반 릴리스로 안내하고 있어, 제품 이름에 같은 숫자가 들어간다는 이유만으로 본판과 동일한 장기 지원 기간을 적용해서는 안 된다.^[223]

비공식 파생판과의 차이

공식 Flavor는 Ubuntu의 공통 아카이브, 개발 시리즈와 릴리스 절차 안에서 기본 패키지 집합과 사용자 환경을 구성한다. 각 팀이 이미지 검증과 데스크톱 통합을 담당하지만, 기반 배포판을 별도로 복제하여 완전히 독립적인 릴리스 체계를 운영하는 방식과는 다르다. 같은 시리즈의 Ubuntu 패키지를 공유하기 때문에 여러 Flavor 사이에는 상당한 시스템 관리 공통점이 존재한다.^[224]

독립 파생판은 Ubuntu 패키지를 이용하면서도 자체 저장소, 버전 번호, 기본 프로그램과 업데이트 정책을 유지할 수 있다. Linux Mint, elementary OS와 Pop!_OS가 이러한 범주에 해당하며, 특정 데스크톱을 사용한다는 사실만으로 공식 Flavor가 되는 것은 아니다. 이 차이는 문제 보고와 지원에서도 중요하다. 공통 패키지의 문제인지, Flavor 또는 파생판이 추가한 변경의 문제인지에 따라 담당 프로젝트가 달라진다.^[225]

Ubuntu의 서버 환경은 데스크톱과 별개의 커널 체계를 사용하는 것이 아니라, 같은 운영체제 기반에 서버용 패키지와 운영 구성을 결합한다. 서비스 프로세스의 실행, 네트워크 연결, 영구 데이터와 접근 권한을 관리하는 것이 중심이며, 그래픽 데스크톱은 필수 구성 요소가 아니다. 웹 서비스부터 데이터베이스, 파일 공유와 가상화까지 필요한 역할을 패키지 단위로 조합할 수 있다.^[226]

Ubuntu Server

Ubuntu Server는 물리 서버와 가상 머신, 클라우드 인스턴스에서 서버 소프트웨어를 운영하기 위한 Ubuntu 제품이다. 서버 설치에 적합한 기본 패키지와 설치 절차를 제공하며, 일반적으로 로컬 그래픽 셸보다 SSH와 명령줄·자동화 도구를 중심으로 관리한다. 다만 그래픽 환경을 설치할 수 없는 별도 운영체제는 아니며, 용도에 따라 데스크톱 패키지를 추가할 수 있다.^[227]

Ubuntu Server를 설치한 것만으로 웹 서버나 데이터베이스가 자동으로 완성되는 것은 아니다. 관리자는 서비스 패키지와 설정, 데이터 저장 위치와 인증 방법을 선택하여 실제 역할을 구성한다. 이러한 분리는 한 시스템에 필요한 기능만 설치하거나 역할별로 여러 서버를 나누는 데 유리하며, 운영체제 업데이트와 응용 프로그램의 데이터·설정 관리를 구분할 수 있게 한다.^[228]

설치와 기본 구성

Ubuntu Server 설치 프로그램은 네트워크와 저장장치, 사용자 계정, SSH 접근과 추가 소프트웨어를 구성한다. Subiquity 기반 설치에서는 대화형 입력뿐 아니라 자동 설치 설정을 사용할 수 있으므로, 단일 서버의 수동 설치와 반복적인 장비 배포를 같은 설치 체계로 처리할 수 있다. 디스크 구성을 확정하면 설치 대상 시스템의 파일 시스템과 부팅 환경이 준비된다.^[229]

설치 이후의 기본 구성은 운영 역할에 따라 달라진다. 일반적으로 패키지 상태와 보안 업데이트를 확인하고, 관리 계정과 SSH 인증, 호스트 이름과 네트워크를 정한 뒤 필요한 서비스만 활성화한다. 원격 관리 서버에서는 네트워크 설정과 방화벽 규칙이 실제 접속 경로에 영향을 주므로, 설정 파일이 문법적으로 유효한지 확인하는 작업과 서비스가 외부에서 정상적으로 접근되는지 확인하는 작업을 구분한다.^[230]

원격 관리

Ubuntu 서버의 대표적인 원격 관리 수단은 OpenSSH이다. SSH는 암호화된 연결을 통해 셸 접속과 명령 실행, 파일 전송과 터널링을 제공한다. 비밀번호 인증 외에 공개키 인증을 사용할 수 있으며, 운영자는 개인별 계정을 통해 접속한 뒤 필요한 작업에 대해서만 sudo 권한을 사용할 수 있다.^[231]

SSH 서버 설정은 /etc/ssh/sshd_config와 별도 설정 조각으로 관리할 수 있다. 접근 가능한 사용자, 인증 방법과 포트 등을 조절하며, 설정 변경 전후에 sshd -t로 문법을 검사할 수 있다. 인증이 허용된다는 사실과 방화벽·클라우드 네트워크에서 연결이 허용된다는 사실은 별개이므로, 원격 접속 문제는 서비스 상태, 인증 설정과 네트워크 경로를 나누어 조사한다.^[232]

웹 서버

Ubuntu는 Apache HTTP Server와 Nginx를 비롯한 웹 서버를 패키지로 제공한다. 웹 서버는 정적 파일을 직접 제공하거나, 클라이언트의 요청을 뒤쪽의 응용 프로그램 서버로 전달하는 리버스 프록시로 사용된다. HTTPS 인증서와 가상 호스트, 접근 로그를 함께 구성하면 하나의 서버에서 여러 도메인과 응용 프로그램을 운영할 수 있다.^[233]

Apache 패키지는 사이트와 모듈 설정을 활성화·비활성화하는 디렉터리 구조와 관리 도구를 제공한다. Nginx도 서버 블록과 프록시 설정을 통해 요청을 구분한다. 실제 웹 서비스에서는 웹 서버가 모든 처리를 맡기보다 응용 프로그램 런타임, 데이터베이스와 파일 저장소를 연결하는 구성이 흔하며, 각 계층의 로그와 상태를 별도로 관찰하는 것이 장애 원인을 구분하는 데 중요하다.^[234][235]

데이터베이스

Ubuntu에서는 PostgreSQL, MySQL 계열 데이터베이스와 여러 비관계형 데이터 저장 서비스를 운영할 수 있다. 데이터베이스 패키지는 서버 프로세스와 관리 도구를 제공하지만, 실제 데이터 모델과 사용자 권한, 백업 정책은 운영자가 구성한다. 같은 서버에서 실행되는 프로그램이라도 운영체제 계정과 데이터베이스 내부 계정은 서로 다른 권한 체계일 수 있다.^[236]

예를 들어 PostgreSQL은 접속할 데이터베이스와 사용자, 인증 방식에 따라 연결을 제어한다. 데이터 파일을 백업하는 작업도 단순한 실행 파일 복사와 다르며, 실행 중인 데이터베이스의 일관성을 보장하는 백업 방식이 필요하다. 따라서 운영체제의 패키지 업데이트와 데이터베이스의 주 버전 업그레이드, 데이터 형식 변환을 같은 작업으로 취급하지 않고 각각의 절차로 관리한다.^[237]

파일과 스토리지 서버

Ubuntu는 Samba를 통해 SMB 파일 공유를, NFS를 통해 Unix 계열 네트워크 파일 공유를 제공할 수 있다. Samba는 Windows와 Linux 클라이언트가 함께 사용하는 파일 서버에 활용되며, 공유 이름과 접근 권한을 서비스 설정으로 정의한다. NFS는 서버가 내보낼 디렉터리와 허용할 클라이언트를 지정하여 다른 시스템의 파일 계층에 연결한다.^[238][239]

네트워크 공유 권한과 서버 디스크의 파일 권한은 함께 작동한다. 공유 설정에서 쓰기를 허용하더라도 실제 파일의 소유권과 권한이 맞지 않으면 접근이 제한될 수 있으며, 사용자 식별자를 여러 시스템에서 일관되게 관리하는 것도 중요하다. 저장장치의 RAID나 볼륨 관리, 파일 시스템은 데이터를 보관하는 하위 계층이고 SMB·NFS는 이를 외부에 제공하는 상위 계층이므로, 두 영역의 장애와 설정을 구분해야 한다.^[240]

네트워크 서비스

Ubuntu 서버는 DNS, DHCP와 시간 동기화 등 다른 컴퓨터가 사용하는 네트워크 기반 서비스를 제공할 수 있다. DNS 서버는 이름과 주소 정보를 응답하고, DHCP 서버는 주소와 기본 경로 등의 구성을 클라이언트에 전달한다. 이러한 서버 역할은 Ubuntu 시스템 자체가 DHCP로 주소를 받거나 DNS를 조회하는 클라이언트 역할과 구분된다.^[241][242]

새로운 DHCP 서버 구성에서는 ISC Kea 같은 현재 유지되는 구현을 선택할 수 있다. 과거의 ISC DHCP 서버는 최신 Ubuntu 문서에서 더 이상 새로운 구성의 중심으로 권장되지 않는다. 시간 서비스에서도 chrony를 설치하여 자신의 시각을 동기화하는 것과 다른 장치에 NTP 서비스를 제공하는 것은 설정이 다르며, 서버로 동작시키려면 응답을 허용할 네트워크를 별도로 구성해야 한다.^[243][244]

고가용성

고가용성(High Availability, HA)은 특정 프로세스나 장비가 고장 나더라도 서비스를 계속 제공하도록 구성하는 운영 방식이다. Ubuntu에서는 Corosync와 Pacemaker 등을 이용하여 클러스터 구성원 상태와 서비스 자원을 관리할 수 있다. Corosync가 노드 간 통신과 구성원 판단을 담당하고, Pacemaker는 정책에 따라 서비스를 시작하거나 다른 노드로 이동시키는 역할을 수행한다.^[245]

여러 서버에 같은 프로그램을 설치하는 것만으로 안전한 자동 장애 전환이 완성되지는 않는다. 네트워크 분리 상황에서 두 노드가 동시에 자신을 주 서비스로 판단하면 같은 데이터에 충돌하는 쓰기를 수행할 수 있다. 이를 제어하기 위해 정족수와 fencing을 사용하며, 저장장치 복제와 응용 프로그램의 복구 방식도 함께 설계한다. 고가용성은 서비스 연속성을 위한 체계이고, 잘못 삭제되거나 손상된 데이터를 복구하기 위한 백업과는 목적이 다르다.^[246]

가상화 호스트

Ubuntu Server는 KVM과 QEMU를 이용하여 여러 가상 머신을 실행하는 호스트가 될 수 있다. KVM은 하드웨어 가상화 기능을 제공하고, QEMU는 가상 CPU 실행과 장치 모델을 구성하며, libvirt는 가상 머신과 네트워크·저장장치의 관리 계층을 제공한다. 각 게스트는 자신의 커널과 사용자 공간을 실행한다.^[247]

가상화 호스트의 운영에서는 CPU와 메모리 할당뿐 아니라 가상 디스크의 저장 위치, 네트워크 브리지와 게스트의 자동 시작 정책을 관리한다. libvirt 기반 도구는 이러한 구성을 호스트의 일회성 명령이 아니라 지속적인 가상 머신 정의로 보관할 수 있다. 같은 Ubuntu 호스트라도 관리 권한을 가진 시스템 연결과 개인 사용자 세션 연결은 별도의 자원 집합을 사용할 수 있다.^[248]

서버 보안

Ubuntu 서버 보안은 설치된 운영체제의 보안 기능과 실제 서비스 설정을 함께 다루는 문제이다. 보안 업데이트를 적용하고, 서비스별 계정과 파일 권한을 분리하며, 외부에서 접근할 필요가 없는 포트를 제한하는 방식이 기본적인 구성 요소가 된다. SSH 인증, 웹 애플리케이션의 권한과 데이터베이스 접근 정책은 서로 다른 계층에서 적용된다.^[249]

AppArmor는 프로파일이 적용된 프로세스의 접근 범위를 제한하고, 방화벽은 네트워크 통신을 제어한다. 이 기능들은 서로 대체 관계가 아니며, 취약한 응용 프로그램 자체를 자동으로 수정하는 기능도 아니다. 따라서 운영에서는 패치, 최소 권한, 서비스 격리와 로그 관찰을 결합하고, 인터넷에 공개되는 서비스와 관리용 접속 경로를 구분하여 다룬다.^[250][251]

Ubuntu의 클라우드 지원은 가상 머신용 이미지 제공뿐 아니라 초기 설정, 플랫폼별 인증과 장치 지원, 컨테이너 운영까지 포함한다. 같은 Ubuntu 시리즈라도 클라우드 공급자에 따라 이미지 식별자와 메타데이터 전달 방식, 네트워크와 저장장치 관리 계층이 달라진다. 따라서 운영체제 내부 구성과 클라우드 제어 계층의 구성을 함께 이해해야 한다.^[252]

클라우드 이미지

Ubuntu 클라우드 이미지는 가상 머신에 사용할 수 있도록 미리 설치된 운영체제 이미지이다. 사용자가 ISO에서 설치 절차를 실행하는 대신 이미 준비된 디스크 상태를 복제하여 인스턴스를 생성한다. 이미지에는 가상 환경에서 필요한 구성과 초기화 도구가 포함되며, 새 인스턴스의 계정과 SSH 키 등은 플랫폼 메타데이터를 통해 정해질 수 있다.^[253]

이미지를 고를 때는 Ubuntu 버전뿐 아니라 아키텍처와 이미지 게시자, 이미지가 만들어진 시점을 구분한다. 움직이는 이미지 별칭은 시간이 지나면 다른 빌드를 가리킬 수 있으므로, 재현 가능한 배포에서는 실제 이미지 버전을 기록하는 방법을 사용할 수 있다. 이미 배포된 인스턴스는 새 이미지가 공개되었다고 자동 교체되는 것이 아니며, 시스템 안의 패키지 업데이트와 인스턴스 재생성을 별도로 관리한다.^[254]

Amazon Web Services

Amazon Web Services의 EC2에서는 Ubuntu AMI를 선택하여 가상 머신을 생성한다. AMI는 특정 리전과 아키텍처에 대응하는 식별자를 가지므로, 같은 Ubuntu 릴리스라도 모든 리전에서 동일한 AMI ID를 사용하는 것은 아니다. 공식 이미지를 선택할 때에는 이름에 Ubuntu가 들어가는지만 확인하는 것이 아니라 Canonical이 게시한 이미지인지 확인하는 절차가 중요하다.^[255]

인스턴스의 디스크와 네트워크는 EBS, VPC와 보안 그룹 같은 AWS 자원과 연결된다. Ubuntu 안에서 서비스를 실행하고 포트를 열어도 보안 그룹이나 경로 설정에서 통신이 허용되지 않으면 외부에서 접근할 수 없다. 초기 SSH 키와 사용자 데이터는 인스턴스 생성 시 전달할 수 있으며, 같은 이미지를 여러 번 사용하더라도 이러한 초기 데이터에 따라 서로 다른 서버 역할을 구성할 수 있다.^[256]

Microsoft Azure

Microsoft Azure는 Ubuntu 가상 머신 이미지와 Ubuntu Pro를 포함한 여러 배포 선택지를 제공한다. 사용자는 이미지와 가상 머신 크기, 디스크와 네트워크를 선택하여 인스턴스를 만든다. Azure에서 사용하는 이미지의 게시자와 제품·버전 구분은 Ubuntu의 배포판 버전 번호와 별도의 식별 체계이다.^[257]

Ubuntu 내부의 사용자와 서비스는 일반적인 Linux 도구로 관리하지만, 관리 디스크와 가상 네트워크, 플랫폼의 접근 제어는 Azure가 담당한다. 클라우드 초기화 도구와 플랫폼 에이전트는 이 두 계층을 연결하는 역할을 한다. 따라서 가상 머신 문제를 조사할 때에는 운영체제의 부팅·서비스 로그와 Azure에서 관찰한 인스턴스 상태를 나누어 확인해야 하며, 플랫폼의 보안 정책이 응용 프로그램 내부 권한을 대신하는 것은 아니다.^[258]

Google Cloud

Google Cloud의 Compute Engine에서는 Ubuntu 이미지를 기반으로 가상 머신을 생성할 수 있다. 공식 Ubuntu 이미지가 게시되는 프로젝트와 이미지 계열을 선택하여 사용할 수 있으며, 이미지 계열은 해당 계열에서 권장되는 이미지로 갱신될 수 있다. 이는 특정 이미지 버전을 고정하여 사용하는 방식과 구별된다.^[259]

인스턴스의 디스크, 서비스 계정과 네트워크는 Google Cloud 제어 계층에서 구성하고, 운영체제 내부의 패키지와 서비스는 Ubuntu에서 관리한다. 새 이미지로 만든 인스턴스와 기존 인스턴스에 패키지 업데이트를 적용한 결과는 설정과 초기화 이력 때문에 완전히 같지 않을 수 있다. 이러한 차이를 관리하기 위해 이미지 버전과 초기 구성, 응용 프로그램 배포 절차를 함께 기록하는 방식이 사용된다.^[260]

OpenStack

OpenStack은 가상 머신, 네트워크와 저장장치를 API로 제공하는 오픈 소스 클라우드 플랫폼이다. Nova가 컴퓨트 자원을, Neutron이 네트워크를, Cinder가 블록 저장장치를, Glance가 이미지를 담당하는 식으로 기능이 여러 서비스로 나뉜다. Ubuntu는 이러한 서비스를 실행하는 호스트 운영체제가 될 수 있고, OpenStack이 제공하는 가상 머신의 게스트 이미지로도 사용된다.^[261]

OpenStack을 Ubuntu에서 사용한다는 것은 하나의 패키지를 설치해 모든 클라우드 기능이 즉시 완성된다는 의미가 아니다. 서비스 간 인증과 메시징, 데이터베이스, 네트워크와 저장장치를 조합해야 하며, 규모가 커지면 배포 이후의 업그레이드와 장애 복구가 중요한 작업이 된다. Canonical의 관련 제품은 이러한 구성 요소의 배포와 수명 주기 관리를 자동화하는 방향으로 OpenStack을 통합한다.^[262]

cloud-init

cloud-init은 클라우드 인스턴스가 자신이 실행되는 환경의 메타데이터와 사용자 데이터를 읽고 초기 상태를 구성하는 도구이다. 사용자와 SSH 키, 호스트 이름, 파일과 패키지, 초기 명령 등을 선언할 수 있다. 동일한 Ubuntu 이미지에 서로 다른 초기 데이터를 전달하면 이미지를 다시 제작하지 않고도 다양한 역할의 인스턴스를 생성할 수 있다.^[263]

cloud-init은 부팅 과정 전체를 한 번에 실행하는 단일 스크립트가 아니다. 환경 감지와 로컬 설정, 네트워크 준비, 구성과 최종 작업 등 여러 단계로 나뉘며 모듈마다 실행 빈도도 다르다. 최초 인스턴스에서만 실행되는 작업과 매 부팅 때 수행되는 작업을 구분하므로, 사용자 데이터를 수정했다고 기존 인스턴스의 모든 초기화 작업이 자동으로 다시 실행된다고 가정해서는 안 된다.^[264]

컨테이너 환경

클라우드에서 Ubuntu는 컨테이너를 실행하는 호스트와 컨테이너 이미지의 사용자 공간 양쪽에 사용된다. 호스트에는 커널과 컨테이너 런타임이 존재하고, 컨테이너 이미지는 응용 프로그램과 필요한 파일·라이브러리를 제공한다. Ubuntu 기반 컨테이너를 실행한다고 컨테이너 안에서 별도의 Ubuntu 커널이 부팅되는 것은 아니다.^[265]

이 구분은 보안 업데이트에서도 중요하다. 호스트 커널을 갱신하는 작업과 이미지 안의 라이브러리를 갱신하여 컨테이너를 다시 배포하는 작업은 서로 다르다. 또한 실행 중인 컨테이너의 임시 파일 계층과 서비스의 영구 데이터 저장소를 분리해야 하며, 이미지 교체와 컨테이너 재생성이 데이터베이스나 업로드 파일을 잃는 작업으로 이어지지 않도록 볼륨을 구성한다.^[266]

Kubernetes

Kubernetes는 컨테이너화된 응용 프로그램의 배포 상태를 선언하고 이를 유지하는 오케스트레이션 플랫폼이다. 제어 계층에는 API 서버와 상태 저장소, 스케줄러와 컨트롤러가 있고, 각 작업 노드에서는 kubelet과 컨테이너 런타임이 실제 워크로드를 실행한다. Ubuntu는 이러한 제어 계층과 작업 노드가 실행되는 운영체제로 사용할 수 있다.^[267]

Kubernetes에서 컨테이너 실행은 CRI를 지원하는 런타임과 연결되며, Docker 명령줄 도구를 설치하는 것과 Kubernetes 노드를 구성하는 것은 같은 작업이 아니다. Ubuntu 환경에서는 MicroK8s와 같은 통합 배포 방식을 선택할 수 있고, 네트워크와 저장장치 등의 기능을 추가 구성한다. 클러스터가 응용 프로그램을 재시작할 수 있더라도 데이터의 복구와 외부 서비스의 가용성까지 자동으로 해결하는 것은 아니므로, 영구 볼륨과 백업 정책을 별도로 다룬다.^[268]

퍼블릭 클라우드와 사설 클라우드

퍼블릭 클라우드에서는 공급자가 물리 장비와 가상화·네트워크 제어 계층을 운영하고, 사용자는 제공되는 API와 서비스를 통해 자원을 할당받는다. Ubuntu는 이 위에서 가상 머신이나 컨테이너 워크로드를 실행하는 운영체제로 사용된다. 다만 공급자가 기반 장비를 관리한다는 사실이 사용자가 설치한 응용 프로그램과 계정 설정의 책임까지 모두 이전한다는 의미는 아니다.^[269]

사설 클라우드에서는 조직이 OpenStack 같은 플랫폼을 통해 자체 하드웨어를 가상 자원으로 제공할 수 있다. 이 경우 Ubuntu 게스트의 운영뿐 아니라 호스트 패치와 스토리지, 네트워크와 제어 계층의 가용성도 조직의 운영 범위에 들어간다. 두 환경은 같은 Ubuntu 이미지와 자동화 도구를 재사용할 수 있지만, 장애 조사와 보안 관리의 책임 경계가 다르다.^[270]

Ubuntu에서 제공하는 격리 환경은 크게 호스트 커널을 공유하는 컨테이너와 별도 커널을 실행하는 가상 머신으로 나뉜다. 여기에 실제 실행 기능을 제공하는 커널 인터페이스, 가상 장치 구현과 상위 관리 도구가 계층적으로 결합한다. LXC, QEMU, KVM과 libvirt를 모두 같은 종류의 프로그램으로 취급하면 각 도구가 담당하는 역할을 구분하기 어렵다.^[271]

LXC

LXC는 Linux의 네임스페이스와 cgroup 등을 이용하여 격리된 사용자 공간을 실행하는 시스템 컨테이너 기술이다. 프로세스와 네트워크, 마운트 등의 관점을 분리하고 자원 사용량을 제한하면서, 컨테이너 안에서 일반적인 Linux 사용자 공간을 실행할 수 있도록 한다. 응용 프로그램 하나만 담는 구성뿐 아니라 여러 시스템 서비스를 포함하는 환경도 만들 수 있다.^[272]

LXC 컨테이너는 호스트의 커널을 공유하므로 독립적인 커널을 부팅하는 가상 머신과 구조가 다르다. 컨테이너 안에서 보이는 root 계정도 사용자 네임스페이스와 설정에 따라 호스트의 실제 root 권한과 다른 관계를 가질 수 있다. 이 때문에 이미지의 사용자 공간뿐 아니라 컨테이너의 권한과 호스트에서 노출하는 장치·마운트 설정이 격리 수준을 결정한다.^[273]

LXD

LXD는 시스템 컨테이너와 가상 머신을 관리하는 플랫폼이다. 인스턴스 생성뿐 아니라 이미지, 스토리지 풀과 네트워크, 프로파일과 원격 API를 함께 제공한다. 사용자는 인스턴스의 세부 실행 명령을 매번 직접 구성하는 대신 관리자가 보관한 정의와 공통 프로파일을 통해 여러 환경을 운영할 수 있다.^[274]

LXD의 컨테이너와 가상 머신은 관리 인터페이스가 비슷하더라도 실행 구조가 같다기보다 서로 다른 선택지이다. 컨테이너는 호스트 커널을 사용하고 가상 머신은 별도의 커널을 부팅하므로, 커널 의존성과 운영체제 요구에 따라 적절한 유형을 선택한다. Ubuntu에서는 LXD를 별도로 설치하여 사용할 수 있으며, 인스턴스의 수명과 네트워크·스토리지 자원을 함께 관리한다.^[275]

Incus

Incus는 LXD에서 파생하여 Linux Containers 커뮤니티가 개발하는 시스템 컨테이너·가상 머신 관리 플랫폼이다. 이미지와 프로파일, 네트워크와 스토리지 풀을 통해 여러 인스턴스를 관리하고 원격 API를 제공한다. Ubuntu도 Incus를 실행하거나 Incus 인스턴스의 운영체제로 사용할 수 있다.^[276]

Incus와 LXD는 공통된 개발 기원을 가지지만, 현재는 별도의 프로젝트와 릴리스 정책을 가진다. 따라서 기능 이름이 비슷하다고 모든 버전의 API와 설정, 이전 절차가 동일하다고 가정해서는 안 된다. 운영 환경에서 둘 중 하나를 선택할 때에는 실행하려는 인스턴스 유형뿐 아니라 지원되는 스토리지 드라이버, 네트워크와 클러스터 기능, 장기적인 관리 주체를 함께 고려할 수 있다.^[277]

Docker

Docker는 컨테이너 이미지를 빌드하고 배포하며 실행하는 도구 체계이다. Ubuntu에서는 Docker Engine을 설치하여 컨테이너를 실행할 수 있고, Ubuntu 이미지를 응용 프로그램의 기반으로 사용할 수도 있다. 이미지의 파일 계층과 실행 중인 컨테이너, 영구 데이터를 보관하는 볼륨은 서로 다른 자원이다.^[278]

Ubuntu 저장소에서 제공하는 Docker 관련 패키지와 Docker 프로젝트의 자체 저장소에서 제공하는 패키지는 공급 경로와 버전 관리가 다를 수 있다. 설치 과정에서는 서로 충돌하는 패키지를 구분해야 하며, 운영 중에는 호스트 커널과 이미지 내부 패키지를 각각 갱신한다. 또한 Docker의 포트 게시 기능은 호스트 방화벽 규칙과 상호작용하므로, UFW를 설정했다는 이유만으로 게시된 컨테이너 포트가 원하는 방식으로 제한된다고 가정해서는 안 된다.^[279]

Podman

Podman은 OCI 컨테이너와 이미지를 관리하는 도구로, 중앙의 상시 데몬을 필수로 두지 않는 실행 구조를 사용한다. 일반 사용자 권한으로 컨테이너를 실행하는 rootless 구성을 지원하며, 컨테이너와 이미지를 사용자별로 분리하여 관리할 수 있다. 여러 컨테이너를 pod로 묶는 기능도 제공한다.^[280]

rootless 실행은 컨테이너 안의 사용자 식별자와 호스트 사용자를 매핑하는 방식과 연결된다. 따라서 파일 소유권과 볼륨 접근, 낮은 포트 번호의 사용 등에서 root로 실행하는 컨테이너와 차이가 생길 수 있다. Podman의 명령이 Docker와 유사하더라도 데몬·소켓과 네트워크, 권한 모델이 완전히 같지는 않으며, 호환성을 전제로 하는 도구는 실제 요구사항을 확인해야 한다.^[281]

QEMU

QEMU는 CPU와 장치, 전체 시스템을 에뮬레이션하거나 가상화하는 도구이다. 전체 시스템 에뮬레이션에서는 가상 CPU와 메모리, 디스크와 네트워크 장치를 구성하여 게스트 운영체제를 부팅한다. 호스트와 다른 CPU 아키텍처를 소프트웨어로 실행할 수 있어 운영체제 개발과 크로스 플랫폼 시험에도 활용된다.^[282]

QEMU의 소프트웨어 변환 실행과 KVM 같은 가속기를 사용하는 실행은 구분된다. 다른 명령어 집합을 실행할 때에는 일반적으로 소프트웨어 변환이 필요하지만, 호스트가 지원하는 가상화 조건을 만족하면 하드웨어 가속을 사용할 수 있다. QEMU가 다양한 가상 장치를 제공한다는 사실은 실제 하드웨어와 모든 타이밍·동작이 같다는 뜻은 아니므로, 에뮬레이션 시험과 실제 장치 검증은 서로 보완적인 절차이다.^[283]

KVM

KVM은 Linux 커널이 제공하는 하드웨어 가상화 인터페이스이다. 사용자 공간의 가상 머신 프로그램은 /dev/kvm을 통해 가상 머신과 가상 CPU를 만들고, 메모리를 등록한 뒤 게스트 실행을 요청한다. KVM 자체가 가상 머신의 그래픽 관리 화면이나 모든 가상 장치를 제공하는 것은 아니다.^[284]

일반적인 Ubuntu 가상화 구성에서는 QEMU가 가상 장치와 실행 환경을 만들고 KVM이 게스트 CPU 실행을 가속한다. 이 구조 때문에 CPU의 가상화 지원과 펌웨어 설정, 커널 모듈과 접근 권한이 함께 맞아야 한다. 또한 다른 CPU 명령어 집합을 임의로 가속하는 기능이 아니므로, x86 호스트에서 RISC-V 게스트를 시험하는 일과 같은 아키텍처의 게스트를 KVM으로 실행하는 일은 구별된다.^[285]

libvirt

libvirt는 여러 가상화 기술을 일관된 API와 관리 모델로 제어하기 위한 계층이다. 가상 머신의 정의와 수명, 네트워크, 저장장치 풀과 볼륨 등을 관리한다. Ubuntu에서는 QEMU/KVM을 제어하는 데 많이 사용되며, virsh와 virt-manager 같은 프로그램이 libvirt를 통해 자원을 조작한다.^[286]

libvirt의 연결 대상은 URI로 구분되며, qemu:///system과 qemu:///session은 서로 다른 권한과 자원 범위를 가진다. 전자는 시스템 수준의 가상 머신 관리에, 후자는 사용자별 가상 머신 실행에 사용할 수 있다. 따라서 한 연결에서 만든 게스트가 다른 연결에서 보이지 않는 것은 단순한 표시 오류가 아니라 별도의 관리 영역을 사용하기 때문일 수 있다.^[287]

Multipass

Multipass는 Ubuntu 가상 머신을 간편하게 생성하고 사용하는 Canonical의 도구이다. Linux, macOS와 Windows에서 Ubuntu 인스턴스를 시작하고 셸에 접속하거나 명령을 실행할 수 있다. 개발자가 Ubuntu 설치 절차와 가상 하드웨어 구성을 매번 직접 반복하지 않고 시험 환경을 준비하는 용도에 적합하다.^[288]

인스턴스를 생성할 때 CPU와 메모리, 디스크 크기 등을 지정할 수 있고 cloud-init 설정을 전달하여 필요한 패키지와 계정을 준비할 수 있다. 이러한 방식은 같은 개발 환경을 반복적으로 만드는 데 활용된다. 다만 Multipass는 Ubuntu 가상 머신의 간편한 수명 관리에 초점을 둔 도구이며, 대규모 데이터센터의 모든 네트워크·저장장치·고가용성 기능을 제공하는 클라우드 제어 플랫폼과 같은 범위의 제품은 아니다.^[289]

가상 머신 게스트

Ubuntu는 가상화 호스트뿐 아니라 다른 하이퍼바이저 안에서 실행되는 게스트 운영체제로도 사용된다. 게스트는 가상 CPU와 디스크, 네트워크 장치를 실제 장치처럼 다루며 자신의 커널을 부팅한다. 가상 환경에 맞는 드라이버와 통합 기능을 사용하면 일반적인 장치 에뮬레이션보다 효율적인 입출력을 구성할 수 있다.^[290]

게스트 에이전트와 cloud-init은 서로 다른 역할을 맡는다. cloud-init은 이미지의 초기 설정을 처리하고, 게스트 에이전트는 실행 중인 게스트와 호스트 관리 계층 사이의 정보를 교환하는 데 사용될 수 있다. 가상 머신의 스냅샷과 운영체제 내부의 데이터베이스 백업도 동일하지 않으므로, 복구 시 응용 프로그램 데이터가 일관된 상태인지 별도로 검증해야 한다.^[291]

Ubuntu의 보안은 패키지 취약점 수정, 프로세스 권한 제한, 부팅 구성 요소 검증과 저장장치 보호 등 여러 계층으로 이루어진다. 각 기능은 보호하는 대상과 시점이 다르다. 예를 들어 Secure Boot는 부팅 코드의 검증에, 디스크 암호화는 저장된 데이터의 기밀성에, AppArmor는 실행 중인 프로그램의 접근 제한에 중점을 둔다.^[292][293]

보안 업데이트

Ubuntu의 보안 업데이트는 특정 취약점이 어떤 Ubuntu 릴리스와 패키지에 영향을 주는지 조사하고, 필요한 수정 사항을 해당 배포판에 반영하는 과정으로 제공된다. Ubuntu CVE 자료는 릴리스별 패키지 상태를 추적하며, Ubuntu Security Notice는 배포된 수정 사항과 영향을 받는 패키지를 안내한다. 동일한 상위 소프트웨어라도 Ubuntu 시리즈별 패치 상태는 다를 수 있다.^[294]

배포판은 최신 업스트림 버전으로 교체하지 않고 기존 버전에 보안 패치를 적용할 수 있다. 따라서 프로그램의 상위 버전 번호가 낮다는 사실만으로 취약점이 수정되지 않았다고 판단할 수는 없다. 반대로 지원이 종료된 패키지나 외부 저장소의 프로그램은 Ubuntu의 보안 업데이트 범위와 다를 수 있으므로, 실제 설치 출처와 Ubuntu 패키지 버전을 기준으로 상태를 확인한다.^[295]

Ubuntu Security Team

Ubuntu Security Team은 Ubuntu 패키지의 취약점을 추적하고 수정본과 보안 공지를 준비하는 개발 조직이다. 취약점마다 영향을 받는 코드와 Ubuntu에 적용된 변경을 조사하고, 상위 프로젝트와 배포판 유지관리자 사이의 정보를 조정한다. 이 과정에서 단순한 CVE 번호의 존재보다 해당 패키지와 릴리스가 실제로 영향을 받는지가 중요하다.^[296]

보안 공지는 사람을 위한 문서뿐 아니라 자동화된 도구가 처리할 수 있는 데이터로도 제공된다. Canonical은 Ubuntu Security Notice 정보를 기계 판독 가능한 형식으로 관리하며, 이를 통해 자산 관리와 취약점 분석 도구가 설치된 패키지와 수정 상태를 비교할 수 있다. 다만 취약점 목록의 경고를 운영 환경에 적용할 때에는 실제 패키지 출처와 활성화된 기능도 함께 확인해야 한다.^[297]

AppArmor

AppArmor는 프로그램별 프로파일을 통해 파일과 시스템 기능에 대한 접근을 제한하는 강제적 접근 제어 체계이다. 일반적인 사용자·그룹 권한이 접근을 허용하더라도 AppArmor 프로파일이 추가로 동작을 제한할 수 있다. Ubuntu는 여러 시스템 서비스와 Snap의 격리에 이 기능을 활용한다.^[298]

AppArmor가 설치되어 있다는 사실이 모든 프로그램에 동일한 제한이 적용된다는 의미는 아니다. 프로파일이 적용된 프로그램과 적용되지 않은 프로그램이 있으며, 프로파일의 enforce·complain 상태에 따라서도 처리 방식이 달라진다. aa-status와 관련 로그를 통해 적용 상태를 확인할 수 있고, 정책 변경 시에는 필요한 정상 접근과 의도하지 않은 접근을 구분하여 규칙을 조정한다.^[299]

방화벽

Ubuntu의 방화벽은 Linux 커널의 네트워크 패킷 처리 기능에 규칙을 적용하여 연결을 제어한다. UFW는 이러한 규칙을 비교적 단순하게 관리하는 인터페이스이며, 주소와 포트, 프로토콜과 인터페이스를 기준으로 통신을 허용하거나 차단할 수 있다. UFW가 제공된다는 사실과 실제로 활성화되어 있다는 사실은 구분해야 한다.^[300]

방화벽 규칙은 서비스가 어느 주소에서 대기하는지와 함께 작동한다. 로컬 주소에만 바인딩된 서비스는 외부 연결을 받지 않지만, 모든 인터페이스에서 대기하는 서비스는 허용 규칙에 따라 외부에 노출될 수 있다. 클라우드 보안 그룹이나 컨테이너 네트워크도 별도의 필터링 계층을 가질 수 있으므로, 연결 경로에 존재하는 여러 규칙을 함께 확인해야 한다.^[301]

권한과 sudo

Ubuntu는 파일 소유자와 그룹, 접근 모드 및 추가 보안 기능을 통해 자원 접근을 관리한다. 일반 사용자는 자신의 권한으로 작업하고, 시스템 변경에 필요한 경우 sudo 정책에 따라 관리 권한으로 명령을 실행할 수 있다. 기본 설치에서 root의 직접 비밀번호 로그인을 제한하는 구성은 root 계정이 존재하지 않는다는 의미가 아니다.^[302]

sudo는 모든 사용자에게 무조건적인 관리자 권한을 주는 기능이 아니라, 허용된 사용자와 명령의 범위를 정책으로 정하는 도구이다. 서비스 전용 계정과 대화형 관리 계정을 분리하고 필요한 디렉터리만 소유하도록 구성하면 한 서비스의 권한이 다른 데이터로 확장되는 범위를 줄일 수 있다. 이러한 계정·권한 설계는 AppArmor나 컨테이너 격리와 함께 적용할 수 있다.^[303]

Secure Boot

UEFI Secure Boot는 부팅 과정에서 실행되는 구성 요소의 서명을 검증하는 기능이다. Ubuntu는 shim과 부트로더, 커널의 서명 체계를 이용하여 신뢰할 수 있는 부팅 경로를 구성한다. 이는 디스크의 모든 파일을 암호화하거나 실행 중인 모든 응용 프로그램을 검증하는 기능과는 다르다.^[304]

외부 드라이버를 커널 모듈로 설치하는 경우에도 서명과 신뢰 관계가 중요할 수 있다. Ubuntu는 Machine Owner Key 등록 등을 통해 사용자가 허용한 키로 서명된 모듈을 다루는 절차를 제공한다. 따라서 드라이버 설치에 성공했더라도 모듈이 실제로 로드되지 않으면 패키지 상태뿐 아니라 Secure Boot와 서명 상태를 함께 확인해야 한다.^[305]

디스크 암호화

Ubuntu에서는 LUKS와 dm-crypt를 이용하여 블록 장치를 암호화할 수 있다. 암호화된 장치는 잠금을 해제한 뒤 일반적인 블록 장치로 제공되며, 그 위에 파일 시스템이나 LVM을 구성한다. 이러한 암호화는 장비가 꺼져 있거나 저장장치가 분리된 상태에서 원시 데이터에 접근하는 것을 제한하는 데 중점을 둔다.^[306]

일부 Ubuntu Desktop 구성에서는 TPM과 부팅 상태 검증을 활용하는 하드웨어 기반 암호화도 제공한다. 이 방식은 지원 장치와 설치 조건에 따라 사용 가능 여부가 달라지며, 펌웨어나 부팅 구성 변경 시 복구 절차가 필요할 수 있다. 암호화된 시스템이라도 로그인하여 데이터가 해제된 뒤에는 응용 프로그램 권한이 중요하므로, 디스크 암호화와 실행 중인 시스템의 접근 제어를 함께 사용한다.^[307]

자동 보안 업데이트

unattended-upgrades는 설정된 APT 저장소와 정책에 따라 업데이트를 자동으로 설치하는 도구이다. 어떤 출처의 업데이트를 허용할지, 특정 패키지를 제외할지 등을 구성할 수 있으며 자동 실행 기록을 로그로 확인할 수 있다. Ubuntu의 보안 업데이트를 자동 적용하는 것과 등록된 모든 외부 저장소의 프로그램을 자동 갱신하는 것은 동일한 정책이 아니다.^[308]

자동 설치가 끝났다고 모든 실행 중인 프로세스가 곧바로 새 코드를 사용한다고 볼 수는 없다. 라이브러리나 커널 변경에 따라 서비스 재시작 또는 재부팅이 필요할 수 있다. 따라서 운영 환경에서는 패키지 적용 결과와 재시작 정책, 유지보수 시간대와 서비스 상태 확인을 함께 관리하며, 자동화가 수행한 변경을 추적할 수 있도록 로그를 보관한다.^[309]

Livepatch

Canonical Livepatch는 지원되는 Ubuntu 커널의 일부 중요한 보안 수정 사항을 실행 중인 커널에 적용하는 서비스이다. 전체 커널을 새로 부팅하지 않고 수정할 수 있는 코드를 대상으로 하므로, 재부팅 간격이 긴 서버에서 일부 취약점에 대한 노출 시간을 줄이는 데 활용된다. 모든 보안 수정과 기능 변경을 같은 방식으로 적용하는 것은 아니다.^[310]

Livepatch는 지원 대상 커널과 아키텍처, 서비스 조건에 따라 사용할 수 있다. 새로운 하드웨어 지원이나 커널 주 버전 전환, live patch로 처리할 수 없는 변경에는 일반 커널 업데이트와 재부팅이 필요하다. 따라서 Livepatch 상태가 정상이라는 사실은 모든 시스템 패키지가 최신 상태라는 의미가 아니며, 정기적인 APT 업데이트와 커널 수명 관리를 대체하지 않는다.^[311]

Ubuntu Pro

Ubuntu Pro는 Ubuntu LTS에 추가 보안 유지보수와 관리 기능을 연결하는 구독 서비스이다. 별도의 운영체제를 새로 설치하는 방식이 아니라, 지원되는 기존 Ubuntu 시스템을 구독에 연결하여 필요한 서비스를 활성화한다. 시스템에서는 Pro 클라이언트를 통해 연결 상태와 서비스 활성화 여부를 확인할 수 있다.^[312]

구독에 포함되는 기능은 ESM, Livepatch와 보안·관리 서비스 등으로 나뉘며, 사용 가능한 기능은 릴리스와 아키텍처에 따라 달라질 수 있다. Pro가 연결되었다고 모든 서비스가 동일하게 활성화되거나 모든 제3자 소프트웨어가 지원되는 것은 아니다. 따라서 운영자는 구독의 존재뿐 아니라 실제 활성화된 서비스와 패키지의 출처를 기준으로 유지보수 범위를 판단한다.^[313]

Expanded Security Maintenance

Expanded Security Maintenance(ESM)은 Ubuntu LTS의 보안 유지보수 기간과 패키지 범위를 확장하는 체계이다. ESM Infra는 표준 지원 이후 주요 인프라 패키지의 유지보수를 연장하고, ESM Apps는 universe의 응용 프로그램과 라이브러리에 대한 추가 보안 유지보수를 제공한다. 두 서비스는 시작 시점과 대상이 같지 않으므로 모두 단순히 “5년 뒤부터 받는 업데이트”로 설명할 수는 없다.^[314]

ESM은 별도의 보안 저장소와 클라이언트 설정을 통해 동작한다. 서비스가 활성화된 시스템은 해당 패키지의 수정본을 APT 업데이트 과정에서 받을 수 있다. 다만 보안 패치를 제공하는 것과 응용 프로그램의 새 기능을 계속 최신화하는 것은 다르며, 외부 저장소나 직접 빌드한 바이너리는 별도의 유지관리 대상이다.^[315]

Ubuntu의 하드웨어 지원은 CPU 아키텍처 지원, 특정 장치의 드라이버 지원, 실제 제품 구성에 대한 인증으로 나누어 이해할 수 있다. 아키텍처용 패키지가 존재하더라도 모든 보드에서 같은 이미지가 부팅되는 것은 아니며, 특정 컴퓨터가 인증되었다고 같은 이름의 모든 부품 조합이 동일하게 검증된 것은 아니다.^[316][317]

amd64

amd64는 x86-64 명령어 집합을 사용하는 64비트 PC와 서버를 위한 아키텍처 이름이다. 이름에 AMD가 들어가지만 호환되는 Intel 프로세서에서도 사용되며, 32비트 x86 전용인 i386과는 별도의 실행 환경이다. 패키지 관리에서는 아키텍처 이름을 기준으로 해당 시스템에서 사용할 바이너리를 구분한다.^[318]

Ubuntu는 일반적인 amd64 기반을 유지하면서 일부 릴리스에서 더 높은 CPU 기능 수준을 대상으로 하는 선택적 최적화 변형도 제공한다. 이러한 변형의 존재가 일반 amd64 이미지 전체의 최소 요구사항이 동일하게 높아졌다는 의미는 아니다. 실제 설치에서는 이미지의 요구 명령어 수준과 그래픽·저장장치 지원을 함께 확인해야 한다.^[319]

arm64

arm64는 AArch64 실행 환경을 대상으로 하는 64비트 ARM 아키텍처이다. ARM 서버와 클라우드 인스턴스, 일부 노트북과 개발 보드에서 사용되며, 32비트 ARM용 패키지와는 명령어 집합과 ABI가 다르다. ARM 계열이라는 공통점만으로 armhf 바이너리와 동일하게 취급할 수는 없다.^[320]

ARM 시스템에서는 CPU뿐 아니라 펌웨어와 장치 설명, 부팅 매체와 커널의 보드 지원이 중요하다. Ubuntu도 특정 장치용 이미지와 서버용 이미지를 구분하며, 일부 서버 환경에서는 메모리 페이지 크기가 다른 설치 선택지를 제공한다. 같은 arm64 프로그램이라도 페이지 크기와 외부 바이너리의 전제 조건이 영향을 줄 수 있으므로, 아키텍처 이름 이외의 실행 조건을 함께 확인한다.^[321]

armhf

armhf는 하드웨어 부동소수점 호출 규약을 사용하는 32비트 ARM 포트이다. Ubuntu의 기준은 ARMv7 계열이며, 단순히 ARM 프로세서가 있다는 이유만으로 더 오래된 명령어 집합의 장치에서 실행할 수 있는 것은 아니다. 하드웨어 부동소수점을 사용한다는 특성은 함수 인자 전달과 라이브러리 호환성에도 반영된다.^[322]

32비트 ARM에는 서로 다른 ABI를 사용하는 포트가 있으므로, 외부에서 구한 ARM 바이너리의 이름만 보고 호환성을 판단해서는 안 된다. 커널이 장치를 지원하더라도 사용자 공간 라이브러리와 실행 파일의 ABI가 맞아야 한다. 또한 실제 부팅 가능 여부는 보드별 커널과 펌웨어 지원에 좌우되므로, 포트의 존재와 설치 이미지의 장치 지원을 구분한다.^[323]

ppc64el

ppc64el은 리틀 엔디언 방식의 64비트 POWER 계열 시스템을 위한 포트이다. Ubuntu는 서버용 POWER 시스템을 대상으로 이 아키텍처의 패키지를 제공하며, Ubuntu 22.04 이후의 기준 CPU는 POWER9 이상이다. 과거 PowerPC 계열을 사용한 모든 컴퓨터에 해당하는 범용 설치판이라는 의미는 아니다.^[324]

이 아키텍처에서도 커널, C 라이브러리와 응용 프로그램을 하나의 호환되는 조합으로 제공하는 것이 배포판의 역할이다. 외부 프로그램이 x86-64 바이너리만 제공한다면 별도의 ppc64el 빌드가 필요하며, 소스 코드가 존재하는 프로그램은 해당 아키텍처용 도구 체인으로 빌드하는 방식을 사용할 수 있다. 이런 차이 때문에 서버 도입 시에는 하드웨어 지원과 함께 실행할 소프트웨어의 아키텍처별 공급 여부도 확인한다.^[325]

s390x

s390x는 IBM Z 계열 메인프레임을 위한 64비트 빅 엔디언 아키텍처이다. 일반 PC용 amd64와 명령어 집합 및 입출력 환경이 다르며, 메인프레임의 가상화·파티션 환경에서 Linux를 실행하는 용도로 사용된다. Debian과 Ubuntu는 이 계열을 위한 별도의 패키지 포트를 유지한다.^[326]

Ubuntu 26.04의 s390x 기준 CPU는 z15 이상이다. 따라서 이전 Ubuntu가 실행되던 장비에서도 새 릴리스의 최소 세대 요구사항을 별도로 확인해야 한다. 응용 프로그램 관점에서는 패키지의 존재뿐 아니라 엔디언과 아키텍처에 의존하는 코드, 외부 바이너리와 네이티브 확장의 지원 여부가 배포 가능성에 영향을 준다.^[327]

riscv64

riscv64는 64비트 RISC-V를 대상으로 하는 Ubuntu 포트이다. RISC-V는 선택 가능한 확장이 다양한 명령어 집합이므로, 64비트라는 조건만으로 모든 바이너리의 실행 조건이 일치하지는 않는다. Ubuntu는 릴리스별 기준 프로파일을 정하며, 25.10 이후에는 RVA23을 기준으로 한다.^[328]

부팅에는 CPU의 명령어 지원 외에도 펌웨어와 커널 사이의 인터페이스, 메모리 배치와 장치 설명이 필요하다. Linux RISC-V 부팅 문서는 이러한 전달 조건을 명시하며, 실제 보드는 부트로더와 펌웨어, 장치 트리 등이 서로 맞아야 한다. 따라서 특정 riscv64 패키지를 빌드할 수 있다는 사실과 임의의 RISC-V 보드에 일반 Ubuntu 이미지를 설치할 수 있다는 사실은 구별된다.^[329]

i386 호환 패키지

현대 Ubuntu에서 i386은 완전한 독립 설치 포트가 아니라, amd64 시스템에서 일부 기존 32비트 프로그램을 실행하기 위한 보조 패키지 집합으로 유지된다. 과거와 같은 32비트 x86용 일반 설치 이미지와 커널을 제공하는 구조는 아니다. 이 패키지들은 호환성이 필요한 응용 프로그램의 사용자 공간 의존성을 충족하는 데 사용된다.^[330]

32비트 프로그램을 실행하려면 실행 파일뿐 아니라 동적 로더와 필요한 32비트 라이브러리가 함께 있어야 한다. 따라서 호환 패키지가 일부 존재한다는 사실을 모든 오래된 32비트 Linux 프로그램의 실행 보장으로 해석해서는 안 된다. 외부 프로그램의 의존성과 해당 Ubuntu 시리즈에서 제공하는 패키지 범위를 확인하는 것이 실제 호환성 판단의 기준이다.^[331]

장치 드라이버

Ubuntu의 장치 드라이버 대부분은 Linux 커널의 일부로 제공된다. 커널이 장치를 인식하면 해당 드라이버가 장치를 초기화하고, 사용자 공간은 커널이 제공하는 인터페이스를 통해 장치를 사용한다. 그래픽과 오디오, 네트워크처럼 여러 계층이 있는 기능에서는 커널 드라이버 외에 사용자 공간 라이브러리와 서비스도 함께 필요하다.^[332]

같은 Ubuntu LTS 안에서도 generic, HWE와 OEM 등 커널 계열에 따라 하드웨어 지원 구성이 달라질 수 있다. 새 장치의 지원을 위해 더 새로운 커널을 사용하는 경우가 있지만, 커널을 바꾸면 외부 모듈과 펌웨어의 호환성도 함께 확인해야 한다. 따라서 장치 문제를 조사할 때에는 Ubuntu 버전뿐 아니라 실제 실행 중인 커널 계열과 드라이버를 기록하는 것이 중요하다.^[333]

독점 드라이버

일부 하드웨어는 제조사가 제공하는 독점 또는 별도 배포 드라이버를 사용한다. Ubuntu는 이러한 드라이버를 패키지와 선택 도구를 통해 설치할 수 있도록 하며, NVIDIA 그래픽 드라이버가 대표적인 사례이다. 드라이버를 선택할 때에는 GPU 모델뿐 아니라 데스크톱 표시용인지 서버 계산용인지, 사용하려는 커널과 어떤 조합을 지원하는지 확인한다.^[334]

커널 모듈은 Ubuntu가 제공하는 미리 빌드된 패키지를 사용하거나 DKMS 등을 통해 설치된 커널에 맞게 빌드할 수 있다. Secure Boot를 사용하는 환경에서는 모듈 서명도 고려해야 한다. 제조사 설치 프로그램과 배포판 패키지를 중복 사용하면 파일 관리와 업데이트 경로가 섞일 수 있으므로, 설치 출처와 제거·갱신 방법을 일관되게 유지하는 것이 중요하다.^[335]

펌웨어

하드웨어에서 사용되는 펌웨어에는 운영체제가 장치에 로드하는 파일과 장치 내부의 비휘발성 메모리에 기록되는 코드가 있다. 전자는 드라이버가 장치를 초기화할 때 필요할 수 있고, 후자는 UEFI와 SSD·도킹 장치 등 제품 자체의 동작을 갱신하는 대상이 된다. 두 경우 모두 펌웨어라고 부르지만 설치와 업데이트 방식은 다르다.^[336]

Ubuntu에서는 지원되는 장치의 펌웨어 업데이트에 fwupd와 LVFS를 활용할 수 있다. LVFS는 제조사가 제공한 펌웨어를 Linux 환경에 전달하는 기반이며, 모든 장치가 자동으로 지원되는 것은 아니다. 또한 펌웨어 갱신은 일반 응용 프로그램 교체와 달리 재부팅이나 장치 재연결이 필요할 수 있으므로, 해당 장치의 업데이트 조건을 따르는 방식으로 수행한다.^[337]

인증 하드웨어

Canonical의 Ubuntu 하드웨어 인증은 특정 모델과 Ubuntu 릴리스, 실제 구성에 대한 호환성 검증이다. 단순히 운영체제가 한 번 부팅되었다는 확인을 넘어 장치 기능과 시스템 동작을 시험하는 절차를 포함한다. 인증 정보에는 제품과 적용되는 Ubuntu 버전 등이 제시되므로 구매와 배포 계획에서 이를 참고할 수 있다.^[338]

인증된 제품 이름이 같더라도 GPU나 무선 장치 등의 부품 구성이 다르면 검증 범위가 달라질 수 있다. 또한 특정 LTS에서 인증되었다는 사실이 모든 후속 릴리스와 임의의 커널에서 동일한 결과를 보장하는 것은 아니다. 인증은 하드웨어 도입의 불확실성을 줄이는 근거이며, 조직이 사용할 응용 프로그램과 주변 장치까지 포함한 시험을 대체하지는 않는다.^[339]

노트북과 데스크톱

개인용 컴퓨터에서는 CPU 성능 외에도 그래픽 출력과 오디오, 무선 네트워크, 터치패드와 절전·복귀가 실제 사용 경험에 큰 영향을 준다. 같은 CPU를 사용하는 노트북이라도 무선 칩과 GPU, 펌웨어가 다르면 Ubuntu에서의 동작이 달라질 수 있다. 외부 모니터와 도킹 장치를 연결하는 환경도 별도의 검증 요소가 된다.^[340]

Ubuntu 인증과 OEM 통합은 이러한 제품 단위의 차이를 다루는 데 목적이 있다. 제조사와 Canonical은 특정 모델에서 필요한 커널·펌웨어·사용자 공간 변경을 검증하고 배포할 수 있다. 일반 사용자가 설치하는 환경에서는 라이브 세션으로 기본 장치 동작을 확인할 수 있지만, 장시간 절전과 배터리 사용, 특수 주변 장치까지 모두 검증되었다고 볼 수는 없다.^[341]

서버 하드웨어

서버에서는 다중 네트워크 인터페이스와 저장장치 컨트롤러, 가상화 기능과 원격 관리 등 운영 역할에 필요한 장치 구성이 중요하다. Ubuntu 서버 인증은 CPU 아키텍처뿐 아니라 해당 제품의 여러 하드웨어 기능을 대상으로 시험한다. 특정 RAID 컨트롤러나 NIC가 지원된다는 사실도 드라이버와 펌웨어 조합을 포함하여 판단해야 한다.^[342]

서버 인증의 시험 범위와 실제 서비스 성능은 서로 다른 문제이다. 인증은 호환성 근거를 제공하지만 데이터베이스의 지연 시간이나 고가용성 구성, 특정 가속기 작업량까지 자동으로 검증하는 것은 아니다. 따라서 운영 환경에서는 인증 결과에 더해 저장장치 장애와 복구, 네트워크 부하와 응용 프로그램의 실제 작업을 시험하여 배포 구성을 확정한다.^[343]

Ubuntu 설치는 대상 이미지 선택, 부팅 매체 준비, 저장장치 구성과 사용자 설정을 연결하는 과정이다. 데스크톱과 서버, 클라우드와 개발 보드는 동일한 설치 매체를 사용하는 것이 아니며, 수동 설치와 자동 배포도 서로 다른 입력 경로를 사용한다. 설치 이후의 릴리스 업그레이드는 새로운 디스크 설치와 별개의 절차이다.^[344]

설치 이미지

Ubuntu는 용도와 아키텍처에 맞는 설치 이미지와 미리 설치된 이미지를 제공한다. PC용 ISO는 부팅 가능한 설치 환경을 포함하고, 클라우드 이미지나 개발 보드용 디스크 이미지는 이미 구성된 파일 시스템을 대상으로 한다. 따라서 파일 확장자와 이미지의 대상 환경을 확인한 뒤 적절한 방식으로 기록해야 한다.^[345]

이미지의 체크섬은 다운로드한 파일이 배포된 파일과 일치하는지 확인하는 데 사용된다. 신뢰할 수 있는 공식 배포 경로에서 이미지와 검증 정보를 받아야 하며, USB에 ISO 파일을 일반 파일로 복사하는 것과 부팅 가능한 매체를 만드는 것은 다르다. 개발 보드용 이미지도 대상 저장장치에 기록하는 과정에서 기존 파티션을 바꿀 수 있으므로 설치 대상을 명확하게 구분한다.^[346]

Ubuntu Desktop 설치 프로그램

Ubuntu Desktop 설치 프로그램은 언어와 키보드, 네트워크, 소프트웨어 구성과 디스크 배치를 선택하는 그래픽 인터페이스를 제공한다. 설치 옵션에 따라 기본 응용 프로그램 집합과 추가 드라이버·멀티미디어 지원 등을 구성할 수 있다. 이러한 선택은 설치 직후의 환경을 정하지만, 이후 패키지 관리 도구를 통해 프로그램을 추가하거나 제거할 수 있다.^[347]

데스크톱 설치의 화면과 기능은 릴리스에 따라 발전해 왔다. 현대 설치 환경은 수동 입력뿐 아니라 자동화된 설치 설정을 사용할 수 있는 경로도 제공한다. 디스크 암호화와 기존 운영체제와의 공존 같은 선택은 단순한 테마 설정과 달리 저장 구조와 복구 방법에 영향을 주므로, 해당 선택의 결과를 구분하여 구성한다.^[348]

Ubuntu Server 설치 프로그램

Ubuntu Server는 Subiquity 기반의 설치 체계를 사용한다. 대화형 설치에서는 네트워크와 저장장치, 계정과 SSH 등의 구성을 입력하고, 자동 설치에서는 같은 목적의 설정을 선언된 데이터로 전달한다. 설치 프로그램은 이러한 정보를 바탕으로 대상 디스크와 운영체제를 준비한다.^[349]

서버 설치에서는 로컬 화면 없이 운영할 수 있는 접속 경로를 준비하는 일이 특히 중요하다. 설치할 SSH 서버와 키, 관리 계정과 네트워크가 서로 맞아야 재부팅 후 원격 관리가 가능하다. 또한 RAID와 LVM 같은 저장 구조는 운영체제 설치와 밀접하게 연결되므로, 자동 설치에서도 디스크 선택 규칙과 파티션 구성을 명시적으로 관리한다.^[350]

라이브 환경

라이브 환경은 Ubuntu를 디스크에 영구 설치하기 전에 설치 매체에서 실행하는 세션이다. 그래픽과 네트워크, 입력 장치의 기본 동작을 확인하고 설치 프로그램을 실행할 수 있다. 필요하면 연결된 파일 시스템을 열어 데이터를 옮기거나 시스템 복구 작업에 사용할 수도 있다.^[351]

라이브 세션은 설치된 운영체제와 사용 중인 저장 계층이 다를 수 있다. 일반적인 라이브 세션에서 변경한 프로그램과 설정은 별도의 지속성 구성이 없으면 재부팅 후 유지되지 않을 수 있다. 또한 암호화된 저장장치의 데이터에 접근하려면 올바른 잠금 해제 정보가 필요하므로, 라이브 환경 자체가 디스크 암호화를 우회하는 기능은 아니다.^[352]

디스크 파티셔닝

Ubuntu 설치에서는 전체 디스크를 자동 구성하거나 파티션과 마운트 지점을 직접 지정할 수 있다. 일반적인 UEFI 설치에서는 EFI System Partition과 루트 파일 시스템이 사용되며, 필요에 따라 /home이나 다른 데이터 영역을 분리한다. 파티션은 저장 공간을 구분하고, 파일 시스템은 그 공간 안에서 파일을 조직하는 서로 다른 계층이다.^[353]

LVM과 암호화를 사용하면 저장 계층이 더 추가된다. 예를 들어 암호화된 블록 장치 안에 볼륨 그룹을 만들고 그 위에 여러 파일 시스템을 둘 수 있다. 자동 설치에서는 이러한 관계를 선언적으로 표현할 수 있지만, 물리 디스크 선택과 파티션 크기, 파일 시스템과 마운트 지점을 구분하여 지정해야 한다.^[354]

이중 부팅

Ubuntu는 다른 운영체제와 같은 컴퓨터에 설치하여 부팅 시 선택하는 구성을 사용할 수 있다. 이를 위해 기존 운영체제가 사용하는 공간과 Ubuntu의 설치 공간, EFI 부팅 항목을 함께 관리한다. 별도 디스크에 설치하는 방식과 같은 디스크의 여유 공간을 나누는 방식은 파티션 작업의 범위가 다르다.^[355]

Windows에서 BitLocker를 사용하는 경우 설치 프로그램이 암호화된 영역을 자유롭게 분석하거나 축소할 수 있는 것은 아니다. Ubuntu 문서는 이러한 상황에서의 선택지와 별도 디스크 사용 등을 안내한다. 운영체제별 암호화와 부팅 보호 기능을 함께 사용하는 환경에서는 각 운영체제의 복구 정보를 보관하고, 설치 후에도 두 운영체제의 부팅과 저장장치 접근이 의도대로 동작하는지 확인한다.^[356]

자동 설치

Autoinstall은 Ubuntu 설치에 필요한 선택을 YAML 설정으로 선언하여 대화형 입력을 줄이는 체계이다. 저장장치와 네트워크, 계정과 SSH, 추가 패키지와 설치 단계별 명령을 기술할 수 있다. 동일한 구성을 여러 서버에 적용하거나 장비별 입력값만 달리하는 반복 배포에 활용된다.^[357]

cloud-init은 설치 설정을 전달하는 경로로 사용할 수 있지만, cloud-init과 설치 프로그램은 같은 구성 요소가 아니다. 설치 환경은 전달받은 autoinstall 데이터를 해석하여 대상 시스템을 만들고, 설치 이후에는 별도의 초기화가 수행될 수 있다. 따라서 설치 중 실행할 작업과 설치된 시스템의 첫 부팅에서 실행할 작업을 구분하면 반복 실행과 잘못된 대상 경로에 대한 변경을 줄일 수 있다.^[358]

네트워크 설치

네트워크 설치는 USB 같은 로컬 매체 대신 네트워크에서 부팅 구성 요소와 설치 자료를 받아 설치 환경을 시작하는 방식이다. PXE 또는 UEFI 네트워크 부팅에서는 주소와 부팅 파일 정보를 얻고, 부트로더와 커널·initrd를 가져온 뒤 설치 환경을 실행한다. 이후 설치 ISO나 패키지, 자동 설치 데이터를 HTTP 등의 경로에서 받을 수 있다.^[359]

네트워크 설치에는 DHCP와 부팅 파일 배포, 설치 자료 제공이 서로 연결되어야 한다. CPU 아키텍처와 펌웨어에 맞지 않는 부팅 파일을 사용하면 네트워크 연결이 정상이어도 설치 환경이 시작되지 않을 수 있다. 따라서 amd64와 arm64, BIOS와 UEFI의 차이를 반영하여 부트로더와 커널을 선택하고, 자동 설치 설정은 설치 자료와 별도로 관리할 수 있다.^[360]

OEM 설치

OEM 설치는 제조사나 공급자가 운영체제와 필요한 드라이버·기본 설정을 준비하고, 최종 사용자가 처음 시작할 때 개인 설정을 완료하도록 하는 배포 방식이다. 장비 준비 단계에서 최종 사용자의 비밀번호와 계정을 미리 정하지 않고도 제품을 출하할 수 있다는 점이 일반적인 개인 설치와 다르다.^[361]

현대 Ubuntu의 OEM 프로비저닝은 이미지 준비와 첫 실행 설정을 분리하는 구조를 사용한다. 공급자가 적용하는 하드웨어·제품 설정과 사용자가 선택하는 계정·지역 설정이 서로 다른 단계에 위치한다. 이 때문에 과거의 OEM 설치 도구 이름이나 화면을 모든 릴리스에 그대로 적용하기보다, 사용하는 Ubuntu 버전의 프로비저닝 절차를 기준으로 이미지를 제작해야 한다.^[362]

업그레이드

릴리스 업그레이드는 설치된 Ubuntu의 패키지와 시스템 구성을 다음 Ubuntu 시리즈로 전환하는 절차이다. 같은 시리즈 안에서 apt upgrade로 패키지를 갱신하는 작업과는 범위가 다르며, 일반적으로 do-release-upgrade 등의 전용 도구를 사용한다. 일반 릴리스는 다음 릴리스로, LTS는 다음 LTS로 이동하는 지원 경로를 따른다.^[363]

업그레이드에서는 패키지 의존성과 기본 설정, 지원이 종료되거나 대체된 구성 요소가 함께 바뀔 수 있다. 외부 저장소와 PPA는 새 시리즈에 맞는 패키지가 없을 수 있으므로 별도로 검토하며, 응용 프로그램의 데이터 변환도 필요할 수 있다. 새 LTS로의 자동 업그레이드 제공 시점은 최초 ISO 공개 시점과 다를 수 있어, 설치 가능 여부와 기존 시스템의 업그레이드 제안 여부를 구분한다.^[364]

Ubuntu의 저장 구조는 물리 장치, 파티션과 논리 볼륨, 암호화 계층과 파일 시스템을 조합하여 구성한다. ext4와 Btrfs는 파일을 조직하는 파일 시스템이고, LVM은 논리 블록 장치를 제공하며, dm-crypt는 그 장치의 내용을 암호화한다. ZFS처럼 파일 시스템과 저장 풀 관리를 함께 제공하는 구현도 있다.^[365][366]

ext4

ext4는 Ubuntu의 일반적인 설치에서 널리 사용하는 Linux 파일 시스템이다. 파일과 디렉터리를 inode와 블록 단위로 관리하고, extent 등을 이용해 파일의 저장 위치를 표현한다. 범용적인 Linux 도구와 복구·관리 생태계가 잘 갖추어져 있어 일반 데스크톱과 서버의 기본 선택지로 사용된다.^[367]

ext4의 저널링은 갑작스러운 종료 뒤 파일 시스템의 메타데이터 일관성을 복구하는 데 도움을 준다. 그러나 저널이 존재한다고 삭제한 파일을 항상 되돌리거나 응용 프로그램이 아직 저장하지 않은 데이터를 복구할 수 있는 것은 아니다. 파일 시스템의 일관성과 데이터베이스 같은 응용 프로그램의 논리적 일관성, 외부 백업은 서로 다른 보호 범위이다.^[368]

ZFS

ZFS는 파일 시스템과 저장 풀 관리 기능을 결합한 기술이다. 여러 장치로 구성한 풀에서 데이터셋과 볼륨을 만들고, 데이터셋마다 마운트 지점과 속성을 관리할 수 있다. Ubuntu에서는 OpenZFS 구현을 사용하며, 풀을 관리하는 zpool과 데이터셋을 관리하는 zfs 명령을 구분한다.^[369]

스냅샷은 특정 시점의 데이터셋 상태를 보존하며, 활성 데이터와 공유하던 블록이 변경되면 그 차이에 해당하는 저장 공간이 필요해진다. scrub은 저장된 데이터를 읽어 무결성 문제를 찾는 작업이고, 장치 교체 뒤 필요한 복제본을 복원하는 resilver와는 목적이 다르다. 스냅샷과 중복 저장 기능이 있더라도 동일한 풀 전체의 손실에 대비하는 외부 백업은 별도로 구성한다.^[370][371]

Btrfs

Btrfs는 복사 시 쓰기 방식과 체크섬, 서브볼륨과 스냅샷 등을 제공하는 Linux 파일 시스템이다. 서브볼륨을 사용하면 하나의 파일 시스템 안에서 독립적으로 다룰 수 있는 파일 트리를 구성할 수 있다. 스냅샷과 reflink, 압축과 send/receive 기능은 데이터 복제와 버전 보존에 활용된다.^[372]

Ubuntu에서 Btrfs를 사용할 수 있다는 사실과 설치 프로그램이 모든 Btrfs 기능을 자동 구성한다는 사실은 다르다. 서브볼륨과 마운트 정책, 스냅샷 보존과 복구 절차를 별도로 설계할 수 있으며, 다중 장치 기능도 선택한 프로파일에 따라 동작 특성이 달라진다. 특히 파일 시스템이 제공하는 모든 RAID 프로파일을 동일한 성숙도로 취급하지 않고, 사용하는 기능의 공식 상태와 제한을 확인해야 한다.^[373]

LVM

LVM은 물리 저장장치를 논리적으로 관리하는 볼륨 관리 체계이다. 물리 볼륨을 볼륨 그룹으로 묶고, 그 안에서 논리 볼륨을 할당한다. 응용 프로그램과 파일 시스템은 논리 볼륨을 블록 장치처럼 사용하므로, 파일 시스템을 만들 때 물리 디스크의 전체 구조에 직접 의존하는 정도를 줄일 수 있다.^[374]

논리 볼륨의 크기를 변경하는 작업과 그 위의 파일 시스템을 변경하는 작업은 구분된다. 볼륨을 확장했더라도 파일 시스템이 새 공간을 사용하도록 처리해야 할 수 있으며, 축소 가능 여부와 절차는 파일 시스템에 따라 다르다. LVM은 유연한 공간 할당과 이동을 제공하지만 데이터를 자동으로 외부에 백업하거나 모든 장치 장애를 견디게 하는 기능은 아니므로, RAID와 백업 여부를 별도로 정한다.^[375]

소프트웨어 RAID

Ubuntu에서는 Linux MD와 mdadm을 이용하여 여러 블록 장치를 RAID 배열로 구성할 수 있다. 선택한 RAID 수준에 따라 데이터를 분산하거나 복제하고, 일부 장치가 고장 났을 때 남은 장치로 동작을 계속할 수 있다. 배열을 구성하는 일뿐 아니라 상태 관찰과 장애 알림, 교체 후 복구도 운영의 일부이다.^[376]

RAID는 구성에 따라 서로 다른 성능과 용량, 장애 허용 범위를 가진다. 디스크 하나가 고장 난 상태와 교체 디스크로 복구 중인 상태는 정상 상태와 부하·여유도가 다르며, 복구가 완료되었는지 확인해야 한다. 또한 RAID는 잘못된 삭제와 응용 프로그램의 데이터 손상, 도난과 전체 장비 손실을 되돌리는 기능이 아니므로 별도의 백업과 복구 시험을 결합한다.^[377]

암호화 저장장치

LUKS는 암호화된 블록 장치의 메타데이터와 키 슬롯 등을 관리하는 형식이며, dm-crypt는 커널의 블록 암호화 계층이다. cryptsetup을 통해 장치를 열면 해제된 매핑이 블록 장치로 제공되고, 그 위의 파일 시스템을 마운트할 수 있다. 따라서 암호화 계층 자체는 ext4나 Btrfs와 같은 파일 시스템을 대신하지 않는다.^[378]

여러 잠금 해제 수단을 구성하거나 키 슬롯을 관리할 수 있지만, 암호화 헤더와 복구 정보의 손실은 데이터 접근에 직접 영향을 줄 수 있다. 저장장치가 열린 상태에서는 권한을 가진 프로세스가 데이터를 읽을 수 있으므로, 암호화는 실행 중인 모든 악성 동작을 차단하는 기능이 아니다. 디스크 암호화와 사용자 권한, 시스템 잠금과 복구 정보 보관을 함께 운영한다.^[379]

이동식 저장장치

USB 메모리와 외장 디스크는 커널이 장치를 감지하고 udev가 사용자 공간에 장치 정보를 제공하는 과정을 거쳐 사용된다. 데스크톱에서는 UDisks와 같은 서비스가 장치 정보와 마운트 요청을 처리하며, 파일 관리자는 이 인터페이스를 통해 사용자에게 저장장치를 표시한다. 따라서 장치 노드의 생성과 데스크톱의 자동 마운트는 서로 다른 단계이다.^[380]

이동식 장치의 접근은 파일 시스템 지원과 사용자 권한, 암호화 여부에 따라 달라진다. 안전하게 제거하는 과정은 단순히 아이콘을 숨기는 작업이 아니라 쓰기 작업을 마무리하고 마운트를 해제하는 절차와 연결된다. 시스템 서비스나 다른 사용자가 장치를 사용 중일 수도 있으므로, 제거할 수 없다는 메시지가 나오면 실제 사용 중인 파일과 마운트 상태를 확인한다.^[381]

Ubuntu 네트워크는 커널의 인터페이스·라우팅 기능 위에 연결 관리 데몬과 설정 도구를 결합한다. Netplan은 원하는 구성을 선언하는 계층이고, NetworkManager와 systemd-networkd는 실제 연결을 관리하는 백엔드이다. DNS 해석과 방화벽, VPN은 이 위에 결합되는 별도의 기능이다.^[382]

NetworkManager

NetworkManager는 네트워크 연결의 상태와 프로파일을 관리하는 서비스이다. 유선과 무선 연결, VPN 등을 구성하며 데스크톱 설정 화면이나 nmcli 같은 도구에서 제어할 수 있다. 장치 자체와 특정 네트워크에 접속하기 위한 연결 프로파일을 구분하므로, 하나의 Wi-Fi 장치에 여러 네트워크의 설정을 저장할 수 있다.^[383]

Ubuntu Desktop에서는 사용자가 네트워크를 바꾸거나 노트북을 이동할 때 연결 상태를 조절하는 역할을 맡는다. 저장된 프로파일에는 IP 설정과 인증 정보, DNS와 경로 등이 포함될 수 있다. 같은 인터페이스를 여러 관리 데몬이 동시에 제어하면 설정 충돌이 발생할 수 있으므로, Netplan을 사용하는 환경에서도 해당 장치의 renderer와 실제 관리 주체를 구분한다.^[384]

Netplan

Netplan은 네트워크 구성을 YAML로 선언하고 이를 백엔드의 설정으로 변환하는 도구이다. 일반적으로 /etc/netplan의 파일에서 인터페이스와 주소, 경로와 DNS, VLAN과 브리지 등을 정의한다. Netplan 자체가 모든 패킷을 처리하거나 연결을 상시 관리하는 데몬은 아니며, 선택한 renderer에 실행을 맡긴다.^[385]

이 구조는 서버와 데스크톱에서 비슷한 선언 방식을 사용할 수 있게 하지만 모든 옵션이 모든 백엔드에서 동일하게 동작한다는 뜻은 아니다. 설정을 생성하는 단계와 실제로 적용하는 단계를 구분할 수 있으며, 원격 시스템에서는 netplan try로 제한 시간 동안 새 구성을 시험하는 방법도 제공된다. 다만 롤백 도구의 존재를 독립적인 복구 경로의 완전한 대체물로 가정하지 않고, 중요한 네트워크 변경에서는 콘솔 접근 같은 수단도 함께 준비할 수 있다.^[386]

systemd-networkd

systemd-networkd는 시스템 수준에서 네트워크 링크와 주소·경로를 관리하는 데몬이다. .network 파일은 어떤 링크에 어떤 설정을 적용할지 정의하고, .netdev 파일은 브리지와 같은 가상 네트워크 장치를 구성하는 데 사용된다. Ubuntu Server에서는 Netplan이 이러한 설정을 생성하는 백엔드로 선택할 수 있다.^[387]

networkd는 사용자 세션의 그래픽 인터페이스가 없어도 시스템 부팅과 함께 네트워크를 구성할 수 있다. 그러나 DNS 조회와 VPN의 모든 기능까지 단일 데몬에서 처리하는 것은 아니며, 다른 서비스와 설정을 연결한다. 같은 장치에 NetworkManager와 networkd의 설정을 중복 적용하기보다 각 인터페이스의 관리 주체를 명확히 지정하는 것이 구성의 일관성을 유지하는 데 중요하다.^[388]

DNS

Ubuntu의 DNS 클라이언트 환경에서는 응용 프로그램의 이름 해석 요청과 실제 DNS 서버에 대한 질의를 여러 구성 요소가 연결한다. systemd-resolved는 로컬의 이름 해석 서비스와 캐시, 인터페이스별 DNS 정보 등을 제공할 수 있다. 프로그램은 일반적인 라이브러리의 이름 해석 함수를 사용하고, 시스템 설정에 따라 이 서비스를 이용한다.^[389]

VPN과 여러 인터페이스를 함께 사용하면 모든 이름을 같은 DNS 서버로 보내는 방식이 적절하지 않을 수 있다. 특정 도메인만 사내 DNS로 보내는 분할 DNS 같은 구성을 사용할 수 있으며, 이는 기본 경로 설정과 별개로 다루어진다. 한편 다른 컴퓨터에 권한 있는 DNS 응답을 제공하는 BIND 서버를 운영하는 일은 Ubuntu 자체의 이름 해석을 설정하는 일과 구분된다.^[390]

무선 네트워크

Ubuntu의 Wi-Fi 사용에는 무선 장치 드라이버와 펌웨어, 인증 처리와 연결 관리 도구가 함께 필요하다. 장치가 인식되는 것과 특정 네트워크에 인증하여 연결되는 것은 서로 다른 단계이다. Ubuntu Desktop에서는 NetworkManager를 통해 네트워크를 선택하고 인증 정보를 저장하는 구성이 일반적이다.^[391]

가정용 공유기의 비밀번호 인증과 기업용 무선망의 EAP 인증은 필요한 설정이 다르다. 기업 환경에서는 사용자 자격 증명뿐 아니라 인증 서버의 인증서 검증이 중요할 수 있으며, Netplan도 지원되는 백엔드를 통해 무선 인증 정보를 표현할 수 있다. 연결 장애는 신호 품질과 장치 상태, 인증, 주소 할당과 DNS를 나누어 조사하면 원인을 더 명확하게 구분할 수 있다.^[392]

VPN

Ubuntu에서는 WireGuard와 OpenVPN, IPsec 계열의 구현을 이용하여 암호화된 네트워크 터널을 구성할 수 있다. VPN은 원격 네트워크의 자원을 연결하거나 특정 통신을 암호화된 경로로 보내는 데 사용된다. 운영체제의 네트워크 인터페이스와 경로, DNS를 함께 구성해야 하므로 터널이 만들어졌다는 사실만으로 모든 트래픽이 의도한 경로를 사용하는 것은 아니다.^[393]

WireGuard는 공개키로 식별되는 peer 사이에 통신을 구성하며, peer별 주소 범위와 키를 관리한다. 이는 사용자가 비밀번호를 입력하는 기업 계정 시스템을 자체적으로 제공하는 모델과 다르다. VPN 설계에서는 전체 트래픽을 터널로 보낼지 일부 목적지만 보낼지, 이름 해석은 어느 서버가 담당할지, 연결이 끊겼을 때 어떤 경로가 남는지를 함께 정한다.^[394]

방화벽

네트워크 구성에서 방화벽은 IP 주소를 설정하거나 연결을 만드는 기능이 아니라, 통신을 허용할 범위를 제어하는 기능이다. UFW는 일반적인 허용·차단 정책을 단순하게 표현하고, 보다 세밀한 구성에서는 nftables 등을 직접 사용할 수 있다. 입력 트래픽과 출력 트래픽, 시스템을 통과하는 전달 트래픽은 서로 다른 규칙 대상이 될 수 있다.^[395]

서버가 라우터나 컨테이너 호스트로 사용되는 경우에는 자신에게 도착한 패킷만 고려해서는 충분하지 않다. 인터페이스 사이로 전달되는 트래픽과 주소 변환, 별도의 네트워크 네임스페이스에서 나오는 통신도 관련된다. 따라서 운영에서는 포트 목록만 나열하기보다 실제 연결 경로와 서비스 바인딩 주소를 기준으로 방화벽 정책을 확인한다.^[396]

서버 네트워크 구성

서버는 정적 주소와 DHCP, 여러 NIC와 VLAN, 브리지와 bond 등을 조합하여 네트워크를 구성할 수 있다. VLAN은 논리적인 네트워크 구분에, 브리지는 가상 머신과 외부 네트워크 연결 등에, bond는 여러 링크를 하나의 논리 인터페이스로 다루는 데 사용된다. 각 기능은 서로 다른 목적을 가지며 하위 스위치의 설정과도 맞아야 한다.^[397]

여러 경로가 존재하는 서버에서는 주소를 추가하는 것만으로 통신 방향이 정해지지 않는다. 기본 경로와 경로 우선순위, 소스 주소에 따른 정책 등을 함께 구성해야 한다. 특히 원격 관리 연결에 사용되는 인터페이스를 변경할 때에는 설정 시험과 실제 접근 확인을 나누어 수행하고, 필요한 경우 기존 상태로 되돌릴 수 있는 방법을 확보한다.^[398]

Ubuntu의 개발 환경은 컴파일러와 런타임, 빌드 도구와 디버거, 편집기와 프로젝트 의존성을 조합하여 구성한다. 배포판이 제공하는 도구 체인은 시스템 패키지로 관리할 수 있고, 언어별 공식 설치 도구를 통해 프로젝트가 요구하는 버전을 별도로 사용할 수도 있다. 두 방식을 혼용할 때에는 실제 실행되는 도구의 경로와 버전을 명확하게 구분한다.^[399]

컴파일러와 도구 체인

Ubuntu는 GCC와 Clang/LLVM, Binutils와 여러 빌드 시스템·디버거를 제공한다. 컴파일러는 소스 코드를 변환하지만 완성된 프로그램을 만들기 위해서는 헤더와 런타임 라이브러리, 어셈블러와 링커 등도 필요하다. 이러한 도구의 조합이 개발 대상의 ABI와 실행 환경에 맞는 결과물을 만든다.^[400]

도구 체인의 기본 버전과 제공되는 대체 버전은 Ubuntu 시리즈별로 다르다. 같은 프로젝트를 여러 환경에서 빌드한다면 컴파일러 이름만 아니라 실제 버전과 링크한 라이브러리, 빌드 옵션을 기록해야 한다. 배포판 패키지와 외부에서 설치한 도구가 함께 존재할 때에는 PATH와 빌드 시스템의 설정이 어떤 실행 파일을 선택하는지 확인한다.^[401]

C와 C++

Ubuntu에서 C와 C++ 개발은 GCC 또는 Clang과 시스템의 C·C++ 라이브러리, 개발 헤더를 조합하는 방식으로 이루어진다. 프로젝트에 따라 Make와 CMake, Ninja 등의 빌드 도구를 사용할 수 있다. 컴파일 단계에서 헤더를 찾는 것과 링크 단계에서 올바른 라이브러리를 선택하는 것은 서로 다른 작업이다.^[402]

Ubuntu의 라이브러리는 실행에 필요한 패키지와 개발용 패키지로 나뉘는 경우가 많다. 프로그램이 이미 설치되어 잘 실행되더라도 해당 라이브러리를 사용하는 새 코드를 빌드하려면 헤더와 링크용 파일을 추가해야 할 수 있다. 또한 최신 Ubuntu에서 빌드한 바이너리가 더 오래된 Ubuntu에서 반드시 실행되는 것은 아니므로, 배포 대상의 라이브러리와 ABI를 기준으로 빌드 환경을 선택한다.^[403]

Python

Ubuntu는 시스템 관리 도구와 일반 응용 프로그램에 Python을 사용하며, 개발자는 별도의 Python 프로젝트 환경을 구성할 수 있다. venv는 특정 인터프리터를 기반으로 프로젝트별 패키지 설치 위치를 분리하는 기능이다. 이를 통해 서로 다른 프로젝트가 요구하는 라이브러리 버전을 시스템 전역 패키지와 구분할 수 있다.^[404]

배포판이 관리하는 Python 환경은 외부 패키지 관리 도구가 시스템 패키지를 임의로 덮어쓰지 않도록 표시될 수 있다. EXTERNALLY-MANAGED 표시는 이러한 소유권 경계를 알리는 장치이며, 가상 환경이나 목적에 맞는 별도 설치 방식을 사용하도록 유도한다. 가상 환경은 패키지 경로를 분리하는 기능이므로, 컨테이너나 가상 머신처럼 커널과 프로세스 권한을 강하게 격리하는 체계와는 다르다.^[405]

Java

Ubuntu에서는 OpenJDK를 비롯한 Java 개발 도구와 런타임을 패키지로 설치할 수 있다. JDK는 컴파일러와 개발 도구를 포함하고, Java 프로그램 실행에는 호환되는 런타임이 필요하다. Maven과 Gradle 같은 프로젝트 도구는 소스 빌드와 외부 라이브러리의 의존성을 관리한다.^[406]

여러 JDK를 설치한 환경에서는 기본 java 명령과 빌드 도구가 사용하는 JDK가 서로 다를 수 있다. 시스템의 대안 선택과 JAVA_HOME, 프로젝트의 도구 체인 설정을 구분하여 관리해야 한다. 배포 대상이 특정 Java 버전을 요구한다면 개발 PC의 가장 최신 JDK만 기준으로 삼기보다 컴파일 대상 버전과 실제 실행 환경의 호환성을 함께 검증한다.^[407]

Rust

Ubuntu에서 Rust는 배포판 패키지 또는 rustup을 통해 설치할 수 있다. rustc가 컴파일을 담당하고 Cargo가 프로젝트 빌드와 테스트, 의존성 관리를 수행한다. rustup은 여러 도구 체인과 타깃을 관리하므로, 프로젝트별로 필요한 Rust 버전을 선택하는 데 활용된다.^[408]

Rust 프로젝트라고 모든 의존성이 Rust 코드로만 구성되는 것은 아니다. C 라이브러리와 연결하거나 빌드 스크립트가 네이티브 도구를 호출하는 경우에는 링커와 헤더, 별도의 개발 패키지가 필요하다. 따라서 Cargo의 의존성 잠금 파일과 Ubuntu 패키지 의존성은 서로 다른 계층이며, 재현 가능한 빌드에서는 두 환경을 함께 관리한다.^[409]

Go

Ubuntu에서는 배포판 패키지나 Go 프로젝트의 배포 도구 체인을 이용하여 Go를 개발할 수 있다. Go 명령은 빌드와 테스트, 모듈 의존성 관리를 통합하며, 언어 서버와 디버거를 추가하여 편집기와 연결할 수 있다. 패키지로 설치한 Go와 외부 도구 체인이 함께 있으면 실제 사용되는 실행 경로를 확인해야 한다.^[410]

Go는 다양한 운영체제와 아키텍처를 대상으로 빌드할 수 있지만, 모든 프로젝트가 동일하게 단순한 크로스 빌드를 지원하는 것은 아니다. 네이티브 라이브러리와 연결하는 경우에는 대상 플랫폼의 C 도구 체인과 라이브러리가 추가로 필요할 수 있다. 따라서 순수 Go 코드의 빌드와 외부 네이티브 의존성을 포함한 프로그램의 빌드를 구분하여 배포 환경을 준비한다.^[411]

.NET

Ubuntu에서는 .NET SDK와 런타임을 설치하여 C# 등의 언어로 개발한 프로그램을 빌드하고 실행할 수 있다. SDK는 개발 도구와 빌드 기능을 포함하고, 실행 전용 시스템은 응용 프로그램이 요구하는 런타임을 설치하는 방식으로 구성할 수 있다. ASP.NET Core를 사용하는 웹 서비스는 해당 실행 환경도 함께 고려한다.^[412]

.NET 패키지의 공급 경로와 지원되는 버전은 Ubuntu 릴리스에 따라 다르다. Ubuntu 저장소와 다른 공급자의 저장소를 섞으면 패키지 경로와 의존성이 충돌할 수 있으므로, 공식 문서가 안내하는 공급 경로를 일관되게 사용하는 것이 중요하다. Windows 전용 API를 사용하는 프로그램과 여러 운영체제를 지원하는 .NET 프로그램도 구분해야 하며, 런타임 설치만으로 모든 Windows 프로그램이 실행되는 것은 아니다.^[413]

개발 패키지

개발용 패키지는 프로그램을 실행하는 데 필요한 파일과 구별되는 헤더, 링크용 파일과 빌드 메타데이터 등을 제공한다. Ubuntu에서는 라이브러리 이름 뒤에 -dev가 붙는 패키지에 이러한 자료가 포함되는 경우가 많다. 실행 라이브러리는 이미 설치되어 있지만 개발 패키지가 없어 컴파일에 실패하는 상황이 발생할 수 있다.^[414]

개발 환경을 구성할 때에는 소스 언어의 패키지 관리자만으로 모든 의존성을 해결한다고 가정하지 않는다. 빌드 도구와 시스템 헤더, 외부 라이브러리의 ABI는 배포판 패키지에 의존할 수 있다. 크로스 컴파일에서는 호스트용 헤더와 대상용 헤더를 섞지 않아야 하므로, 타깃 sysroot와 라이브러리 검색 경로도 별도로 관리한다.^[415]

IDE와 편집기

Ubuntu에서는 VS Code와 JetBrains 계열 IDE, Vim과 Emacs 등 다양한 개발 도구를 사용할 수 있다. 일부 도구는 Ubuntu 패키지나 Snap으로 제공되고, 일부는 개발사의 저장소와 설치 도구를 통해 제공된다. 편집기 자체의 설치와 언어 서버, 디버거와 컴파일러의 설치는 별도의 작업이다.^[416]

IDE가 프로젝트를 열었다고 실제 빌드 환경이 자동으로 일치하는 것은 아니다. 확장 기능이 선택한 인터프리터나 컴파일러와 터미널에서 실행되는 도구가 다를 수 있으며, 원격 개발에서는 도구가 로컬 PC가 아니라 컨테이너나 서버에서 실행되기도 한다. 따라서 편집 기능, 빌드 실행 위치와 프로젝트 의존성의 위치를 구분하면 개발 환경의 불일치를 줄일 수 있다.^[417]

컨테이너 기반 개발

컨테이너 기반 개발은 컴파일러와 라이브러리, 개발 도구를 이미지에 묶어 프로젝트별 실행 환경을 분리하는 방식이다. 호스트에는 편집기와 컨테이너 실행 도구를 두고, 실제 빌드와 테스트는 컨테이너 안에서 수행할 수 있다. Dev Container 구성은 프로젝트와 함께 개발 환경의 정의를 보관하는 데 사용된다.^[418]

이 방식은 팀원과 CI 환경의 도구 차이를 줄이는 데 도움이 되지만, 컨테이너가 호스트 커널을 공유한다는 특성은 그대로 남는다. 소스 디렉터리를 바인드 마운트하면 파일 소유권과 성능, 경로 차이가 영향을 줄 수 있으며, Docker 소켓이나 호스트 장치를 노출하면 격리 범위도 달라진다. 따라서 개발 편의성과 실행 권한을 함께 고려하여 환경을 구성한다.^[419]

크로스 컴파일

크로스 컴파일은 빌드를 수행하는 시스템과 다른 아키텍처나 운영체제에서 실행할 프로그램을 만드는 작업이다. 컴파일러의 타깃을 지정하는 것뿐 아니라 대상의 헤더와 라이브러리, 링커와 ABI를 맞추어야 한다. Clang과 GCC 계열 도구 체인은 이러한 구성을 지원하며, sysroot는 대상 시스템의 개발 파일을 구분하여 제공하는 데 사용된다.^[420]

컴파일에 성공했다는 사실이 대상 장치에서 정상적으로 실행된다는 사실을 보장하지는 않는다. CPU 기능 수준과 동적 로더, 시스템 호출과 장치 의존성을 확인해야 하며, 실행 시험에는 실제 장치나 QEMU를 사용할 수 있다. 에뮬레이터를 통한 기능 시험과 실제 하드웨어에서의 성능·장치 검증은 목적이 다르므로, 개발 과정에서 두 단계를 구분한다.^[421]

기업에서 Ubuntu를 운영할 때에는 개별 컴퓨터의 설치보다 계정과 정책, 소프트웨어 공급과 보안 유지보수의 일관성이 중요하다. Ubuntu Pro와 Landscape, 기업 인증 연동은 이러한 요구를 서로 다른 계층에서 다룬다. 보안 구독은 패키지의 유지보수 범위를, 중앙 관리 도구는 여러 장치에 적용할 정책과 작업을 관리한다.^[422]

Ubuntu Pro

기업용 Ubuntu Pro는 여러 Ubuntu LTS 시스템의 보안 유지보수 범위와 추가 서비스를 관리하는 수단이다. 서버와 데스크톱, 클라우드 인스턴스의 구독 연결 상태를 확인하고 필요한 기능을 활성화할 수 있다. 동일한 LTS를 오래 운영하면서 보안 수정이 필요한 조직에서 활용된다.^[423]

기업에서 중요한 것은 구독 수의 확보뿐 아니라 어떤 시스템과 패키지가 실제로 지원 범위에 들어가는지 파악하는 일이다. 외부 저장소의 프로그램과 내부에서 빌드한 소프트웨어, 배포판이 제공하는 패키지는 유지관리 책임이 다를 수 있다. 따라서 Pro 서비스 상태와 자산 목록, 소프트웨어 출처를 연결하여 관리하는 것이 운영상의 의미를 갖는다.^[424]

Landscape

Landscape는 Ubuntu 시스템의 상태와 소프트웨어를 중앙에서 관리하는 Canonical의 도구이다. 관리 대상 장치의 패키지와 하드웨어 정보를 수집하고, 업데이트와 스크립트 실행 등의 작업을 수행할 수 있다. 서버와 클라이언트 구조를 사용하며 웹 인터페이스와 API를 통해 운영한다.^[425]

운영자는 장치를 그룹화하고 관리 권한과 작업 범위를 나눌 수 있다. 저장소 프로파일을 이용하면 여러 장치가 어떤 패키지 출처를 사용해야 하는지 중앙에서 관리하는 구성을 만들 수 있다. Landscape는 관리 작업의 일관성을 높이는 도구이며, 실행하는 스크립트의 정확성과 응용 프로그램별 복구 절차까지 자동으로 보장하는 것은 아니므로 실제 배포 정책과 검증을 함께 구성한다.^[426][427]

Active Directory

Ubuntu는 SSSD와 Kerberos, 관련 도메인 가입 도구를 사용하여 Microsoft Active Directory와 사용자 인증을 연동할 수 있다. 이를 통해 도메인의 계정과 그룹 정보를 시스템에서 조회하고, 허용된 사용자가 Ubuntu에 로그인하도록 구성한다. DNS와 시간 동기화, 도메인 자격 증명은 정상적인 인증에 중요한 기반이다.^[428]

인증 연동과 그룹 정책 적용은 별개의 기능이다. SSSD가 사용자·그룹 조회와 로그인 경로를 연결하는 데 사용되는 반면, ADSys는 Active Directory의 정책을 Ubuntu 환경에 적용하는 역할을 맡는다. 또한 Microsoft Entra ID와 전통적인 Active Directory Domain Services는 동일한 시스템이 아니므로, 조직에서 사용하는 실제 디렉터리와 인증 구조에 맞는 통합 방법을 선택한다.^[429]

중앙 관리

중앙 관리는 여러 시스템이 같은 운영 정책과 소프트웨어 구성을 유지하도록 하는 방식이다. 패키지 저장소와 업데이트 일정, 관리 계정과 권한, 구성 파일과 스크립트 실행을 조직의 기준에 맞추어 조정한다. Landscape는 이러한 작업을 장치 그룹과 권한에 따라 수행할 수 있는 선택지이다.^[430]

동일한 설치 스크립트를 배포하는 것과 시간이 지나도 동일한 구성을 유지하는 것은 다른 문제이다. 운영 중 사용자가 바꾼 설정과 패키지 상태를 관찰하고, 변경 이력을 바탕으로 필요한 조치를 적용해야 한다. 저장소 스냅샷처럼 특정 시점의 패키지 집합을 고정하는 기능은 검증 환경과 배포 환경의 차이를 줄이는 데 활용할 수 있다.^[431]

장기 유지보수

장기 유지보수는 같은 기반 버전을 오래 사용하면서 필요한 보안 수정을 계속 적용하는 방식이다. Ubuntu LTS의 표준 유지보수 이후에는 Ubuntu Pro와 해당되는 Legacy 서비스 등을 통해 추가 기간의 지원을 받을 수 있다. 다만 지원 기간의 연장과 모든 프로그램의 기능 버전을 최신으로 바꾸는 것은 동일하지 않다.^[432]

Legacy 지원은 오래된 시스템의 이전 시간을 확보하는 선택지이지만 적용되는 릴리스와 아키텍처, 패키지 범위를 확인해야 한다. 예를 들어 Ubuntu 16.04의 안내는 표준 지원과 ESM 이후의 Legacy 기간을 별도로 설명한다. 실제 운영에서는 지원 만료일뿐 아니라 하드웨어 교체와 응용 프로그램의 공급자 지원, 데이터 형식 이전을 함께 계획해야 한다.^[433]

인증 하드웨어

기업은 Ubuntu 인증 하드웨어 목록을 이용하여 제품과 운영체제의 검증 조합을 확인할 수 있다. 이를 통해 대량 구매 전에 지원되는 구성과 필요한 이미지·커널의 조건을 파악할 수 있다. 데스크톱과 노트북, 서버는 시험하는 기능과 사용 환경이 다르므로 각 제품 범주의 인증 정보를 확인한다.^[434]

인증이 있는 제품을 도입해도 기업의 실제 업무 환경을 시험하는 과정은 남는다. VPN과 보안 에이전트, 주변 장치와 특정 응용 프로그램은 별도의 요구사항을 가질 수 있기 때문이다. 따라서 인증은 하드웨어 호환성을 검증한 출발점으로 사용하고, 조직의 표준 이미지와 업무 소프트웨어를 적용한 뒤 운영 환경의 적합성을 확인한다.^[435]

기업 기술 지원

Canonical의 기업 기술 지원은 계약 범위에 따라 문제 분석과 조치 지원, 관련 소프트웨어의 유지보수 등을 제공한다. 커뮤니티에서 공개적으로 도움을 구하는 방식과 달리 지원 대상과 연락 경로, 처리 조건이 계약으로 정해진다. 따라서 Ubuntu를 사용한다는 사실만으로 모든 응용 프로그램과 외부 저장소 패키지가 동일한 지원 대상이 되는 것은 아니다.^[436]

기술 지원은 새로 발견된 배포판 문제를 분석하고 패키지 수정으로 이어질 수 있다는 점에서도 의미가 있다. Canonical은 오래된 코드에서 발생한 문제를 지원 과정에서 분석한 사례를 공개하고 있다. 그러나 제품 수준의 지원과 개별 서비스의 고가용성 설계는 별개이므로, 운영 조직은 장애 대응 연락 체계와 함께 자체적인 백업·복구 절차를 유지한다.^[437]

규제와 보안 인증

Ubuntu의 보안 인증과 규정 준수 도구에는 FIPS 검증 암호 모듈과 CIS·DISA-STIG 기준에 따른 점검·강화 기능 등이 포함될 수 있다. FIPS 검증은 특정 암호 모듈과 버전, 동작 환경에 대한 것이며 운영체제의 모든 프로그램을 일괄 인증하는 개념이 아니다. 따라서 검증된 모듈이 설치되고 적절한 구성으로 사용되는지 확인해야 한다.^[438]

Ubuntu Security Guide는 보안 기준에 따라 시스템을 감사하고 설정을 조정하는 데 사용된다. 조직은 기준 프로파일을 그대로 적용하거나 업무 요구에 맞게 조정할 수 있으며, 자동 수정이 서비스 동작에 미치는 영향도 검증해야 한다. 도구의 점검을 통과했다는 사실과 조직 전체가 특정 법률이나 인증 요구를 충족했다는 판단은 구분된다.^[439]

Ubuntu의 임베디드·IoT 활용은 범용 Ubuntu를 장치에 설치하는 방식과, 장치 수명 관리에 맞추어 Ubuntu Core 이미지를 제작하는 방식으로 나뉜다. 이 분야에서는 사용자가 매번 접속하여 관리하기보다 원격 업데이트와 초기 등록, 오류 복구와 장기간의 보안 유지가 중요해진다.^[440]

Ubuntu Core

Ubuntu Core는 운영체제의 주요 구성 요소와 응용 프로그램을 Snap으로 구성하는 장치용 Ubuntu이다. 범용 데스크톱처럼 사용자가 시스템 파일을 계속 직접 수정하는 환경보다, 제조사와 운영자가 정한 이미지와 업데이트 정책을 유지하는 데 중점을 둔다. 키오스크와 게이트웨이, 로봇과 현장 장비 같은 무인 시스템에 활용할 수 있다.^[441]

Ubuntu Core의 장치 구성은 모델 선언과 서명된 구성 요소를 통해 정의된다. base와 kernel, gadget 등의 Snap이 운영체제의 역할을 나누어 맡고, 응용 프로그램은 별도의 Snap으로 배포된다. 따라서 전통적인 Ubuntu Server에서 APT로 시스템 파일을 수정하는 작업 흐름과 다르며, 장치 이미지를 만드는 단계와 배포 이후의 업데이트 정책을 함께 설계한다.^[442]

Snap 기반 시스템 구성

Ubuntu Core의 base Snap은 기본 사용자 공간을, kernel Snap은 커널과 관련 구성 요소를, gadget Snap은 장치별 부팅·저장 배치와 기본 설정을 제공한다. snapd는 Snap 설치와 업데이트를 관리한다. 이처럼 하나의 운영체제 이미지를 여러 역할의 서명된 구성 요소로 나누어 관리한다.^[443]

model assertion은 장치 모델과 브랜드, 허용되는 시스템 구성 등을 기술하는 서명된 선언이다. gadget의 파티션·부트로더 정보와 모델의 선택이 함께 장치 이미지를 결정하므로, 응용 프로그램 Snap 하나를 설치하는 것과 새로운 장치용 운영체제를 만드는 것은 작업 범위가 다르다. 이 구조를 통해 제조사는 공통 Ubuntu 기반을 사용하면서도 특정 하드웨어의 부팅과 업데이트 정책을 정의할 수 있다.^[444][445]

트랜잭션 업데이트

Snap 업데이트는 새 revision을 준비하고 전환하는 방식으로 수행되며, 실패 시 이전 상태로 복귀하는 기능을 제공한다. 여러 Snap을 하나의 원자적인 변경 집합으로 처리하는 기능도 존재하지만, 모든 업데이트가 항상 시스템 전체와 응용 프로그램 데이터까지 하나의 트랜잭션으로 묶인다고 볼 수는 없다. 업데이트 단위와 복구 범위를 구분해야 한다.^[446]

Ubuntu Core에서는 커널과 부팅 자산의 업데이트, 복구 모드가 장치의 무인 복구와 연결된다. 그러나 응용 프로그램이 외부 데이터베이스에 수행한 변경까지 Snap revision 복귀로 자동 취소되는 것은 아니다. 따라서 데이터 형식 변경과 되돌리기 가능성을 프로그램 차원에서 설계하고, 운영체제의 복구 기능과 외부 데이터 백업을 결합한다.^[447][448]

장치 관리

장치가 늘어나면 개별 설치보다 어떤 모델과 소프트웨어 조합이 어느 장치에 배포되어 있는지 관리하는 일이 중요하다. Ubuntu Core는 모델과 저장소, 채널과 업데이트 제어 기능을 통해 장치군의 소프트웨어 공급을 관리할 수 있다. Brand Store는 조직이나 제품에 맞는 배포 범위를 구성하는 선택지이다.^[449]

업데이트 정책에는 단순한 최신 버전 추적 외에 검증된 Snap 조합의 유지와 단계적인 전환이 포함될 수 있다. validation set과 refresh 제어를 이용하면 호환성이 확인된 구성을 기준으로 배포할 수 있다. 장치 모델 자체를 변경하는 remodeling은 일반 응용 프로그램 업데이트와 별도의 절차이므로, 장치의 신원과 시스템 구성 변경을 구분하여 관리한다.^[450][451]

Raspberry Pi

Ubuntu는 일부 Raspberry Pi 모델을 위한 Server와 Desktop 등의 이미지를 제공한다. 지원 여부는 보드 모델과 메모리, Ubuntu 버전과 이미지 종류에 따라 달라진다. 따라서 Raspberry Pi라는 제품군 이름만으로 모든 모델에서 같은 데스크톱 이미지를 사용할 수 있다고 가정해서는 안 된다.^[452]

Raspberry Pi용 이미지는 PC의 일반 ISO와 달리 보드용 부팅 파일과 파일 시스템이 준비된 디스크 이미지로 제공될 수 있다. 저장장치에 이미지를 기록한 뒤 초기 계정과 네트워크를 구성하며, 일부 기능은 보드의 EEPROM과 펌웨어 상태에도 영향을 받는다. 공식 하드웨어 문서는 모델별 지원과 설치·부팅 조건을 구분하여 안내한다.^[453]

엣지 컴퓨팅

엣지 컴퓨팅은 데이터가 발생하는 현장이나 네트워크의 가장자리에서 계산과 서비스를 수행하는 방식이다. Ubuntu는 센서 데이터 처리와 로컬 서비스, 컨테이너와 모델 추론을 실행하는 기반으로 사용할 수 있다. 네트워크가 항상 안정적이지 않은 환경에서는 중앙 서비스와의 연결이 끊겨도 필요한 기능을 유지할 수 있도록 구성할 수 있다.^[454]

엣지 장치는 사용자가 직접 관리하기 어려운 위치에 배치될 수 있으므로 업데이트 실패와 원격 복구가 중요한 설계 요소이다. Ubuntu Core의 업데이트 제어와 복구 모드는 이러한 운영을 지원한다. 다만 운영체제의 복구와 현장에서 수집한 데이터의 보존은 별개의 문제이므로, 통신 재개 시 전송할 데이터와 장치 내부의 저장 한도도 응용 프로그램 수준에서 관리한다.^[455]

산업용 장치

Ubuntu는 산업용 게이트웨이와 키오스크, 로봇과 현장 컴퓨터의 소프트웨어 기반으로 사용할 수 있다. 이러한 제품은 일반 데스크톱과 달리 정해진 응용 프로그램을 장기간 실행하며, 하드웨어 모델과 운영체제 구성을 함께 고정하는 경우가 많다. Ubuntu Core의 장치별 이미지 구성과 원격 배포 기능은 이와 같은 제품형 운영에 활용된다.^[456]

산업용이라는 범주가 모두 동일한 실시간 요구를 가지는 것은 아니다. 화면 표시나 데이터 수집과 엄격한 제어 주기 작업은 구분해야 하며, 필요한 경우 실시간 커널과 적절한 인터럽트·스케줄링 설정을 선택할 수 있다. 실시간 커널의 사용도 실제 하드웨어와 응용 프로그램의 지연 시간을 자동으로 보장하는 것은 아니므로, 제품이 요구하는 최악의 응답 시간과 복구 동작을 별도로 검증한다.^[457]

Ubuntu의 패키지 기반은 공식 Flavor 외에도 여러 독립 배포판에서 재사용된다. 파생판은 Ubuntu가 제공하는 커널과 라이브러리, 패키지 생태계를 활용하면서 자체 데스크톱과 프로그램, 저장소와 출시 정책을 추가할 수 있다. 따라서 Ubuntu 기반이라는 표현은 공통된 토대를 설명하지만 제품의 전체 동작과 지원 주체까지 동일하다는 뜻은 아니다.^[458][459]

공식 Flavor와 파생판의 차이

공식 Flavor는 Ubuntu의 개발 시리즈와 아카이브, 릴리스 절차에 참여하는 배포 형태이다. 반면 독립 파생판은 Ubuntu의 특정 릴리스를 기반으로 자체 저장소와 제품 구성을 유지할 수 있다. 같은 패키지를 공유하더라도 기본 설정과 소프트웨어 공급 방식, 버전 번호와 지원 기간이 달라질 수 있다.^[460]

예를 들어 KDE Plasma를 사용한다는 공통점이 있어도 Kubuntu와 KDE neon은 같은 프로젝트가 아니다. Kubuntu는 Ubuntu Flavor이고, KDE neon은 Ubuntu LTS 기반에 KDE 소프트웨어를 자체 정책으로 제공한다. 이러한 차이는 최신 데스크톱 기능의 공급 주기와 패키지 조합, 문제를 보고할 곳을 결정하므로 사용자 인터페이스의 유사성만으로 배포판을 분류하지 않는다.^[461]

Linux Mint

Linux Mint의 일반판은 Ubuntu LTS 기반에 자체 소프트웨어 관리와 데스크톱 구성을 추가한 배포판이다. Cinnamon과 MATE, Xfce 에디션을 제공하며, Mint의 업데이트·소프트웨어 관리 도구와 기본 정책을 유지한다. Ubuntu의 패키지를 상당 부분 사용하지만 공식 Ubuntu Flavor로 운영되는 프로젝트는 아니다.^[462]

Linux Mint에는 Ubuntu를 거치지 않고 Debian을 기반으로 하는 LMDE도 존재한다. LMDE는 Mint의 사용자 경험을 다른 기반 위에서도 제공하고, Ubuntu에 대한 의존성을 줄일 수 있는 경로를 유지하는 역할을 한다. 따라서 Linux Mint 전체를 예외 없이 Ubuntu 기반이라고 설명하는 것은 정확하지 않으며, 일반판과 LMDE의 패키지 기반을 구분해야 한다.^[463]

elementary OS

elementary OS는 Ubuntu 기반 위에 Pantheon 데스크톱과 자체 응용 프로그램·디자인 원칙을 제공하는 배포판이다. 시스템 설정과 기본 프로그램의 동작을 일관되게 구성하는 데 중점을 두며, 단순히 Ubuntu의 테마만 바꾼 제품과는 범위가 다르다. 사용자 경험과 응용 프로그램의 통합을 프로젝트 자체가 설계한다.^[464]

elementary의 AppCenter는 자체 생태계의 응용 프로그램을 제공하며 Flatpak 기반의 배포도 활용한다. 이러한 응용 프로그램 공급 방식은 Ubuntu의 기본 App Center와 동일하지 않다. Ubuntu를 기반으로 한다는 공통점이 있어도 데스크톱 설정과 기본 프로그램의 관리 방법, 응용 프로그램에 기대되는 디자인과 상호작용은 elementary의 정책을 따른다.^[465][466]

Pop!_OS

Pop!_OS는 System76이 개발하는 Ubuntu 기반 배포판이다. 개발과 창작 작업을 위한 데스크톱 흐름과 창 배치, 하드웨어 통합을 중시하며, 자체 COSMIC 데스크톱을 발전시키고 있다. 같은 Ubuntu 기반의 라이브러리와 프로그램을 활용하면서 사용자 인터페이스와 기본 운영 방식을 별도로 구성한다.^[467]

System76은 하드웨어와 운영체제를 함께 제공하는 업체이므로 전원 관리와 그래픽 구성 등 제품 통합도 Pop!_OS의 중요한 영역이다. 다만 일반 PC에서도 사용할 수 있는 배포판이며, 특정 제조사 제품에만 한정된 펌웨어와 운영체제를 같은 것으로 보아서는 안 된다. Ubuntu용 설치 안내가 상당 부분 적용될 수 있더라도 데스크톱과 드라이버·업그레이드 절차는 Pop!_OS의 공식 문서를 기준으로 구분한다.^[468]

Zorin OS

Zorin OS는 Ubuntu LTS 기반에 자체 데스크톱 구성과 사용 편의 기능을 추가한 배포판이다. 다른 데스크톱 운영체제에 익숙한 사용자가 화면 배치와 메뉴 구성을 선택할 수 있도록 하며, Zorin의 제품별 소프트웨어 구성을 제공한다. 기본 Ubuntu의 GNOME 세션과 디자인·기능 선택이 다르다.^[469]

Zorin OS의 버전 번호와 지원 일정은 기반 Ubuntu의 숫자와 동일하지 않으므로, 실제 기반 릴리스를 제품 정보에서 확인해야 한다. 또한 Windows 프로그램을 실행하기 위한 호환 도구가 제공되더라도 모든 Windows 응용 프로그램과 드라이버의 실행이 보장되는 것은 아니다. 배포판의 사용자 인터페이스와 응용 프로그램 호환 계층은 서로 다른 기능으로 이해해야 한다.^[470]

기타 Ubuntu 기반 배포판

KDE neon은 Ubuntu LTS를 기반으로 KDE 소프트웨어를 제공하는 프로젝트이다. 운영체제의 기반 패키지와 KDE 데스크톱의 공급 주기를 분리하여, 안정적인 기반 위에서 새로운 KDE 소프트웨어를 제공하는 데 초점을 둔다. 사용자용과 시험용 등 목적이 다른 에디션도 구분한다.^[471]

이러한 구성은 “Ubuntu 기반이면 모든 패키지가 Ubuntu의 기본 버전과 같다”는 가정이 성립하지 않음을 보여준다. 파생판은 특정 영역의 패키지를 자체 저장소에서 대체할 수 있으며, 그 결과 외부 PPA나 다른 파생판 저장소를 추가했을 때 충돌 가능성이 달라진다. 따라서 파생판을 사용할 때에는 기반 Ubuntu 시리즈와 프로젝트가 변경하는 패키지 범위를 함께 확인한다.^[472]

Ubuntu 생태계가 Linux 배포판에 미친 영향

Ubuntu는 커널과 라이브러리, 패키지 도구와 저장소를 통합한 기반을 제공함으로써 파생 프로젝트가 사용자 경험과 특정 용도에 개발 역량을 집중할 수 있게 한다. elementary OS는 자체 데스크톱과 응용 프로그램 경험을, Pop!_OS는 창 관리와 하드웨어 통합을 Ubuntu 기반 위에 구축한 사례이다.^[473][474]

동시에 기반 배포판의 변화는 파생판에도 영향을 준다. 라이브러리 전환과 커널 지원, 패키지 형식과 공급 정책이 바뀌면 파생 프로젝트는 이를 받아들이거나 별도로 유지해야 한다. Linux Mint의 LMDE처럼 다른 기반을 유지하는 사례는 재사용의 이점과 기반 의존성 관리가 함께 존재한다는 점을 보여준다.^[475]

Ubuntu와 Debian의 관계는 한 번의 소스 복사로 끝나는 계보 관계가 아니라, 패키지와 수정 사항이 개발 주기마다 지속적으로 이동하는 관계이다. Ubuntu는 Debian의 패키징 성과를 가져오고 자체 변경을 적용하며, 가능한 수정은 다시 Debian이나 원래 프로젝트에 전달한다. 두 배포판은 협력하지만 아카이브와 릴리스, 개발 권한을 별도로 유지한다.^[476]

패키지 기반

Ubuntu는 Debian의 deb 형식과 dpkg·APT, 소스 패키지 구조를 계승한다. 이 공통 기반 덕분에 많은 패키징 도구와 유지관리 지식을 공유할 수 있다. 그러나 같은 패키지 형식을 사용한다고 Debian의 임의의 바이너리 패키지를 모든 Ubuntu에서 그대로 설치해도 된다는 의미는 아니다.^[477]

각 배포판은 특정 시점의 라이브러리와 컴파일러, 패치와 의존성을 조합하여 패키지를 빌드한다. Ubuntu는 자신의 아카이브에서 소스 패키지를 빌드하고 테스트하므로, 패키지의 버전과 출처는 Ubuntu 시리즈의 전체 구성과 연결된다. 이러한 이유로 패키지 형식의 공통성과 바이너리 호환성을 구분하는 것이 중요하다.^[478]

패키지 동기화

Ubuntu에 별도의 변경이 없는 패키지는 Debian의 새 소스 패키지를 동기화하여 가져올 수 있다. 새 Ubuntu 개발 주기의 초기에는 이러한 동기화가 활발하게 수행되며, Debian Import Freeze 이후에는 변경 반영 조건이 달라진다. 동기화는 이미 Ubuntu에 존재하는 패치를 무조건 덮어쓰는 작업과는 다르다.^[479]

Ubuntu 고유 변경이 존재하면 새 Debian 버전과 기존 변경을 병합해야 한다. 개발자는 어떤 패치가 여전히 필요한지, 어떤 수정이 이미 Debian이나 업스트림에 포함되었는지를 검토한다. 변경이 더 이상 필요하지 않으면 별도 차이를 제거하고 다시 동기화 가능한 상태로 돌아갈 수 있어, 불필요한 패치 유지 비용을 줄일 수 있다.^[480]

Ubuntu의 변경 사항

Ubuntu는 커널 구성과 설치 도구, 기본 데스크톱과 클라우드 통합처럼 제품 요구에 따른 변경을 유지한다. 패키지 차원에서는 빌드 옵션과 의존성, 기본 설정과 소스 패치 등이 Debian과 달라질 수 있다. 이러한 차이는 Ubuntu가 별도의 릴리스와 지원 정책을 가진 배포판이라는 점을 반영한다.^[481]

큰 라이브러리나 언어 버전이 바뀌면 한 패키지만 교체하는 것으로 끝나지 않는다. 그 라이브러리를 사용하는 여러 패키지를 다시 빌드하고 의존성과 실행 상태를 확인하는 전환 작업이 필요하다. Ubuntu의 패키지 변경은 이런 아카이브 전체의 일관성을 유지하는 과정과 연결되므로, 개별 패키지의 최신 버전 여부만으로 개발 상태를 평가하기는 어렵다.^[482]

업스트림 반영

Ubuntu에서 발견한 오류가 원래 소프트웨어의 일반적인 문제라면 수정 사항을 해당 업스트림 프로젝트에 전달할 수 있다. Debian의 패키징과 공통되는 문제는 Debian에 반영하는 경로도 사용할 수 있다. 수정이 상위 프로젝트에 포함되면 Ubuntu가 다음 버전을 가져올 때 같은 패치를 계속 별도로 관리할 필요가 줄어든다.^[483]

모든 Ubuntu 변경이 그대로 업스트림에 적합한 것은 아니다. Ubuntu의 릴리스 일정이나 특정 기본 설정, 전용 통합에만 필요한 변경은 별도로 유지될 수 있다. 따라서 개발자는 수정의 목적과 적용 범위를 설명하고, 병합 시점마다 여전히 필요한 차이인지 검토한다. 이 과정은 패치의 개수를 무조건 줄이는 것보다 유지 이유와 책임을 명확하게 만드는 데 의미가 있다.^[484]

릴리스 정책의 차이

Debian은 stable과 testing, unstable 등의 개발·배포 상태를 구분하며, 안정판을 위해 패키지 전환과 동결 과정을 수행한다. Ubuntu는 자체적인 6개월 릴리스 주기와 LTS 정책에 맞추어 패키지를 통합한다. 따라서 두 배포판의 버전은 일대일 대응하지 않으며, 특정 Ubuntu가 Debian 안정판 하나를 그대로 다시 이름 붙인 제품도 아니다.^[485][486]

이 차이는 새 패키지 반영 시점과 유지보수의 기준에도 영향을 준다. Ubuntu는 개발 초기에 Debian의 변경을 받아들이다가 자신의 동결과 안정화 절차로 전환하며, 출시 뒤에는 보안 수정과 안정 업데이트 정책을 적용한다. 같은 업스트림 소프트웨어라도 두 배포판에 들어가는 시기와 버전, 유지되는 패치가 달라질 수 있다.^[487]

자유 소프트웨어 정책의 차이

Debian은 사회계약과 Debian Free Software Guidelines를 통해 프로젝트와 소프트웨어의 자유에 대한 기준을 제시한다. Ubuntu도 자유·오픈 소스 소프트웨어를 중심으로 하지만 아카이브를 지원 주체와 라이선스 성격에 따라 main, universe, restricted, multiverse로 구분한다. 두 프로젝트의 저장소 이름을 같은 의미로 대응시키는 것은 적절하지 않다.^[488]

또한 Debian이 비자유 펌웨어를 포함한 공식 설치 매체를 제공할 수 있도록 정책을 변경한 사실을 고려해야 한다. 과거의 상황을 바탕으로 “Debian은 언제나 비자유 펌웨어를 배제하고 Ubuntu만 포함한다”라고 단순화할 수는 없다. 실제 비교에서는 기본 구성과 저장소 분류, 사용자가 비자유 구성 요소를 선택·확인하는 방식과 각 프로젝트의 원칙을 함께 살펴본다.^[489]

Debian과 Ubuntu 생태계

두 프로젝트 사이에는 패키지와 버그 수정, 개발 지식이 공유되며 양쪽에서 활동하는 개발자도 존재한다. Ubuntu의 많은 소프트웨어는 Debian의 패키징 작업을 활용하고, Ubuntu에서 발견한 문제와 수정은 Debian에 도움이 될 수 있다. 이러한 관계는 공통된 기술 기반 위에서 별도의 배포 목표를 추구하는 협력 구조이다.^[490]

개발 권한과 패키지 관리 관행까지 모두 동일한 것은 아니다. Ubuntu 개발자는 Ubuntu의 업로드 권한과 검토 절차를 따르며, Debian 개발자라는 이유만으로 Ubuntu 아카이브의 모든 변경 권한을 자동으로 얻는 것은 아니다. 따라서 두 프로젝트의 기술적 유사성과 조직적인 독립성을 함께 이해해야 한다.^[491]

Linux 배포판은 공통된 커널과 많은 업스트림 소프트웨어를 공유하면서도 패키지 형식과 릴리스 주기, 기본 구성과 지원 정책에서 차이를 보인다. Ubuntu와 다른 배포판의 비교도 단순한 속도 순위보다 소프트웨어 공급과 유지관리 모델을 중심으로 이해하는 것이 적절하다. 데스크톱과 서버에서 중요하게 작용하는 차이가 서로 다를 수 있다.^[492][493]

Debian

Debian은 Ubuntu의 직접적인 기술 기반이지만 독립적인 개발자 공동체와 릴리스 구조를 가진다. Ubuntu는 Debian의 패키징 성과를 가져오면서 자신의 제품과 릴리스 정책에 맞게 통합하고 변경한다. 따라서 두 배포판은 명령과 패키징 지식을 공유하기 쉽지만, 저장소를 서로 섞어 사용하는 대상으로 볼 수는 없다.^[494]

Debian의 stable·testing·unstable은 단순한 Ubuntu LTS·일반판·개발판의 다른 이름이 아니다. 각 상태의 갱신과 보안 유지 방식이 다르므로, 사용자는 원하는 패키지 변화 수준과 운영 방식에 맞추어 선택한다. Ubuntu와 Debian의 차이는 최신성뿐 아니라 기본 통합과 지원 주체, 개발 과정의 차이로 이어진다.^[495]

Fedora

Fedora는 RPM 계열 패키지와 DNF를 사용하는 배포판으로, 비교적 짧은 릴리스 주기 안에서 새로운 소프트웨어를 통합한다. Ubuntu의 deb·APT 환경과는 패키지 형식과 저장소·관리 도구가 다르다. 같은 프로그램이 두 배포판에서 제공되더라도 패키지 이름과 기본 설정, 구성 요소의 버전이 달라질 수 있다.^[496]

Fedora 릴리스는 대략 13개월의 지원 주기를 사용하므로, Ubuntu LTS를 장기간 유지하는 운영과는 업그레이드 계획이 다르다. 두 배포판 모두 새 커널과 데스크톱을 통합하지만, 사용자가 변화에 대응해야 하는 빈도와 장기 고정 기반의 선택지가 다르다. 따라서 어느 쪽이 항상 더 안정적이라고 일반화하기보다 사용할 릴리스와 작업 환경을 기준으로 비교한다.^[497]

Red Hat Enterprise Linux

Red Hat Enterprise Linux는 Red Hat이 제공하는 기업용 배포판으로 RPM 계열의 패키지와 자체 제품 수명 주기를 사용한다. 장기적인 유지보수와 인증·지원 생태계가 중요한 제품이며, Ubuntu LTS와 기업 서버 환경에서 함께 비교된다. 패키지 관리와 보안 정책, 공급자 인증의 기준은 서로 다르다.^[498]

RHEL의 수명 주기는 전체 제품의 지원 단계와 특정 마이너 릴리스의 연장 지원을 구분한다. Ubuntu에서도 LTS의 표준 지원과 추가 서비스의 범위를 구분해야 하므로, 단순히 연도 수만 비교하면 실제 지원 대상을 놓칠 수 있다. 운영체제 선택에서는 업무 소프트웨어 공급자의 인증과 계약 범위, 패키지 버전과 시스템 관리 방식까지 함께 비교한다.^[499]

openSUSE

openSUSE는 RPM과 Zypper를 사용하는 배포판 계열이며, Tumbleweed와 Leap처럼 서로 다른 릴리스 모델을 제공한다. Tumbleweed는 지속적인 패키지 갱신을 제공하고 자동화된 검증을 통해 스냅샷을 배포한다. Ubuntu의 고정된 시리즈에 패키지를 유지하는 방식과는 갱신 단위가 다르다.^[500]

openSUSE의 관리·설치 도구도 제품과 버전에 따라 변화한다. 과거 YaST 중심의 설명을 모든 최신 제품에 그대로 적용할 수 없으며, Leap 16 계열에서는 Agama 설치 프로그램을 사용하는 변화가 있다. 따라서 비교에서는 “openSUSE”라는 이름만 아니라 사용할 제품과 버전을 지정하고, 릴리스와 설치·복구 도구의 실제 구성을 살펴본다.^[501]

Arch Linux

Arch Linux는 Pacman을 사용하며 지속적으로 패키지를 갱신하는 롤링 릴리스 배포판이다. 고정된 LTS 시리즈를 유지하는 Ubuntu와 달리, 전체 시스템을 현재의 패키지 조합으로 갱신하는 운영 모델을 따른다. 사용자는 필요한 데스크톱과 서비스를 직접 선택하여 자신의 구성을 만드는 방식으로 시스템을 운영할 수 있다.^[502]

Arch의 패키지들은 서로 호환되는 현재 상태를 전제로 갱신되므로, 일부 패키지만 오래된 상태로 남기는 부분 업그레이드는 일반적인 지원 방식이 아니다. 이는 Ubuntu의 안정 시리즈에 검증된 업데이트를 선택적으로 제공하는 모델과 중요한 차이이다. 두 환경에서 같은 업스트림 프로그램을 사용하더라도 시스템 전체를 관리하는 원칙과 변경에 대응하는 빈도가 다르다.^[503]

Linux Mint

Linux Mint는 Ubuntu 기반을 공유하면서도 데스크톱과 업데이트·소프트웨어 관리 정책을 별도로 구성한다. 따라서 Ubuntu와 명령줄 관리의 공통점이 많지만, 사용자에게 제공되는 기본 도구와 패키지 공급 방식은 달라질 수 있다. 특히 Cinnamon 중심의 사용자 경험과 Mint 자체 도구는 표준 Ubuntu GNOME과 다른 선택을 반영한다.^[504]

Snap 처리 정책은 두 프로젝트의 차이를 보여주는 사례이다. Linux Mint는 APT를 통한 설치가 사용자의 예상과 다르게 Snap 설치로 이어지는 방식에 반대하는 정책을 설명하고, 기본적인 Snap 설치 동작을 Ubuntu와 다르게 구성한다. 이는 같은 기반 라이브러리를 사용하더라도 응용 프로그램의 배포 방식에 대한 프로젝트의 판단이 달라질 수 있음을 보여준다.^[505]

데스크톱 배포판과의 비교

데스크톱 배포판의 차이는 기본 셸과 테마뿐 아니라 로그인과 입력기, 그래픽 세션과 응용 프로그램 공급 방식에 걸쳐 나타난다. Ubuntu는 GNOME 기본판과 공식 Flavor를 통해 여러 데스크톱 선택지를 제공한다. 따라서 KDE나 Xfce를 원한다는 이유만으로 반드시 Ubuntu 계열을 벗어나야 하는 것은 아니다.^[506]

반면 같은 데스크톱을 사용해도 배포판의 릴리스와 패키지 정책이 다르면 경험이 달라진다. KDE neon과 Kubuntu의 차이가 대표적이며, 데스크톱 업데이트의 주기와 기본 라이브러리의 유지 방식이 다르다. 실용적인 비교는 원하는 UI, 하드웨어와 주변 장치, 프로그램 공급 경로와 감당할 수 있는 업그레이드 빈도를 함께 기준으로 삼는다.^[507]

서버 배포판과의 비교

서버 배포판에서는 기본 데스크톱보다 지원 기간과 패키지 수명, 자동화 도구와 공급자 인증이 중요한 비교 요소가 된다. Ubuntu Server는 APT와 LTS, 공식 클라우드 이미지와 Canonical 지원을 중심으로 운영할 수 있다. 다른 배포판은 RPM 계열의 도구와 별도의 유지보수·인증 체계를 사용할 수 있다.^[508][509]

컨테이너를 사용하면 일부 사용자 공간 차이를 줄일 수 있지만 호스트 커널과 네트워크, 저장장치와 보안 정책의 차이는 남는다. 또한 컨테이너 안의 프로그램과 호스트 운영체제의 지원 계약이 자동으로 같아지는 것도 아니다. 따라서 서버 배포판을 선택할 때에는 실행할 워크로드와 운영 조직의 관리 도구, 복구 절차와 지원 책임을 기준으로 비교한다.^[510]

Ubuntu는 데스크톱용 운영체제이면서 서버·클라우드와 개발 도구의 실행 기반이다. 같은 패키지 관리와 시스템 관리 지식을 여러 환경에서 활용할 수 있지만, 실제 설치 형태와 응용 프로그램의 지원 조건은 용도에 따라 달라진다. 범용 이미지와 장치용 이미지, 컨테이너의 사용자 공간을 동일한 실행 환경으로 취급하지 않는 것이 중요하다.^[511][512]

개인용 데스크톱

Ubuntu Desktop은 웹 브라우징과 문서 작성, 파일 관리와 멀티미디어 등 일상적인 컴퓨터 작업에 사용할 수 있다. 설치 프로그램과 그래픽 설정 도구, 패키지 관리 인터페이스를 통합하므로 시스템을 구성하는 모든 요소를 사용자가 처음부터 선택할 필요는 없다. 기본 GNOME 환경 외에 공식 Flavor로 다른 데스크톱 작업 흐름을 선택할 수도 있다.^[513][514]

실제 개인용 환경의 적합성은 기본 프로그램 목록보다 사용하려는 소프트웨어와 주변 장치의 지원에 좌우될 수 있다. 인증된 노트북과 일반 PC, 전용 독점 프로그램에 의존하는 작업은 서로 다른 조건을 가진다. 따라서 설치 후에는 화면 출력과 입력, 무선과 절전뿐 아니라 일상적으로 사용할 파일 형식과 서비스까지 확인하여 작업 환경을 구성한다.^[515]

소프트웨어 개발

Ubuntu는 컴파일러와 런타임, 데이터베이스와 개발 편집기를 한 시스템에서 구성할 수 있는 개발 플랫폼이다. C와 C++, Python과 Java, Rust와 Go 등 여러 언어의 도구 체인을 사용할 수 있으며, 패키지 관리자와 언어별 의존성 도구를 결합한다. 데스크톱에서 개발하고 같은 Ubuntu 계열 서버에 배포하는 작업 흐름도 만들 수 있다.^[516]

프로젝트 환경을 명확하게 정의하면 개인 PC와 CI, 배포 서버 사이의 차이를 줄일 수 있다. 컨테이너와 가상 머신은 이러한 환경을 재현하는 수단이며, 도구 체인 버전과 시스템 패키지의 기록이 함께 필요하다. 운영체제가 같더라도 라이브러리와 빌드 옵션이 다르면 결과가 달라질 수 있으므로, Ubuntu라는 이름만으로 환경의 동일성을 가정하지 않는다.^[517]

서버

Ubuntu는 웹과 데이터베이스, 파일 공유와 네트워크 서비스 같은 범용 서버 역할을 제공할 수 있다. 역할에 맞는 패키지를 선택하여 GUI 없이 운영할 수 있으며, SSH와 자동화 도구를 통해 원격 관리한다. 여러 역할을 한 장비에 결합하거나 가상 머신과 컨테이너로 분리하는 구성도 가능하다.^[518]

서버 운영에서는 설치 이후의 상태 관리가 중요하다. 서비스가 부팅 때 시작되는지, 데이터가 어디에 저장되는지, 계정과 네트워크 접근이 어떻게 제한되는지 확인해야 한다. Ubuntu는 이러한 작업을 수행할 수 있는 기반과 패키지를 제공하며, 실제 서비스의 가용성은 모니터링과 백업·복구 설계까지 포함하여 결정된다.^[519]

웹 서비스

Ubuntu에서는 Nginx나 Apache를 앞단에 두고 언어별 응용 프로그램 서버와 데이터베이스를 연결하여 웹사이트와 API를 배포할 수 있다. 앞단 서버는 TLS와 정적 파일, 요청 전달을 처리하고, 응용 프로그램은 업무 로직을 실행한다. 이러한 역할 분리는 프로그램의 재시작과 배포, 로그 분석을 계층별로 수행할 수 있게 한다.^[520]

웹 서비스를 운영할 때에는 프로세스가 실행 중인지와 실제 요청이 성공하는지를 구분한다. 데이터베이스 연결과 외부 API, 파일 권한 문제로 웹 프로세스가 살아 있어도 정상 응답을 제공하지 못할 수 있다. 따라서 웹 서버 로그와 응용 프로그램 로그, 데이터베이스 상태를 연결하여 관찰하고, 비밀 정보와 영구 데이터를 프로그램 배포 파일과 분리한다.^[521]

클라우드 컴퓨팅

Ubuntu의 공식 클라우드 이미지는 가상 머신을 반복적으로 생성하는 데 사용할 수 있는 기반을 제공한다. 공급자별 이미지와 초기화 도구를 이용하면 계정과 패키지, 서비스 구성을 인스턴스 생성 과정에 통합할 수 있다. 이는 서버를 한 대씩 직접 설치하는 작업에서 선언적인 자원 배포로 이동하는 데 활용된다.^[522]

클라우드에서는 이미지와 실제 인스턴스, 연결된 데이터 디스크의 수명이 다를 수 있다. 인스턴스를 교체하더라도 유지해야 할 데이터와 새로 생성할 임시 상태를 구분하면 배포와 복구가 단순해진다. 같은 Ubuntu 이미지를 여러 공급자에서 사용할 때에도 메타데이터와 네트워크, 권한 모델이 다르므로 플랫폼별 초기화와 운영 조건을 함께 관리한다.^[523]

컨테이너

Ubuntu는 컨테이너 호스트와 응용 프로그램 이미지의 기반으로 활용된다. 이미지 안에는 필요한 사용자 공간을 넣고, 호스트는 커널과 실행 자원을 제공한다. 응용 프로그램별로 의존성을 분리하고 이미지로 배포하면 동일한 프로그램 구성을 다른 호스트에 전달하기 쉬워진다.^[524]

컨테이너의 장점은 운영체제 관리가 사라지는 것이 아니라 관리 단위가 나뉜다는 데 있다. 호스트 커널의 패치와 이미지의 재빌드, 영구 볼륨의 백업이 별도로 필요하다. Kubernetes와 같은 도구는 이러한 컨테이너를 여러 노드에서 배치하고 복구하지만, 응용 프로그램 데이터의 의미와 복구 방식은 워크로드에 맞게 설계해야 한다.^[525]

인공지능과 머신러닝

Ubuntu는 Python 기반의 모델 개발과 데이터 처리, GPU 가속을 사용하는 학습·추론 환경에 활용된다. 이 환경은 프레임워크 패키지뿐 아니라 GPU 드라이버와 계산 런타임, 컴파일러와 시스템 라이브러리에 의존한다. NVIDIA CUDA처럼 지원되는 Ubuntu·드라이버·도구 체인 조합을 명시하는 제품은 해당 조합을 기준으로 설치해야 한다.^[526]

컨테이너로 프레임워크를 묶어 배포하더라도 GPU를 제어하는 호스트 드라이버와의 관계는 남는다. 따라서 Python 패키지 버전만 고정하여 재현성을 보장한다고 가정하지 않고, 드라이버와 가속기 런타임의 조합도 기록한다. 클라우드에서는 이러한 구성이 준비된 Ubuntu 기반 이미지가 제공되기도 하지만, 이미지의 업데이트와 데이터·모델 저장은 별도로 관리한다.^[527]

교육

Ubuntu는 컴퓨터 기초와 프로그래밍, 네트워크와 운영체제 실습을 위한 환경으로 사용할 수 있다. 교육용 프로그램을 묶은 Edubuntu를 사용하거나 일반 Ubuntu에 필요한 도구를 설치하는 방식을 선택할 수 있다. 같은 운영체제에서 그래픽 작업과 명령줄, 코드 빌드와 서버 실습을 연결할 수 있다는 점이 활용 범위를 넓힌다.^[528]

여러 학생이 사용하는 환경에서는 개인 학습용 설치와 교실 전체의 운영 요구가 다르다. 계정과 저장 공간, 패키지 설치 권한과 초기 상태 복원 등을 별도로 관리해야 한다. 가상 머신이나 컨테이너로 실습 환경을 분리하면 학생이 시스템 설정을 바꾸어 보는 학습과 공용 장비의 기본 상태 유지를 함께 구성할 수 있다.^[529]

과학과 연구

Ubuntu는 수치 계산과 데이터 분석, 병렬 계산과 고성능 컴퓨팅의 기반으로 사용할 수 있다. 연구용 워크스테이션에는 분석 도구와 언어 환경을 설치하고, 클러스터에서는 작업 스케줄러와 공유 저장장치, 여러 계산 노드를 결합한다. 이때 로그인 노드와 제어 노드, 실제 계산 노드는 서로 다른 역할을 맡을 수 있다.^[530]

연구 환경의 재현성에는 운영체제 이름 외에 컴파일러와 라이브러리, 병렬 실행 환경과 입력 데이터가 영향을 준다. Charmed HPC 같은 도구는 클러스터의 배포와 수명 관리를 자동화하는 데 활용되며, 계산 작업의 과학적 재현성은 별도의 코드·환경 기록을 필요로 한다. 장기간의 연구에서는 패키지 갱신과 기존 실험 결과를 재실행하는 환경 보존 사이의 관계를 관리한다.^[531]

임베디드 시스템

Ubuntu는 지원되는 ARM과 RISC-V 장치, 산업용 컴퓨터에서 임베디드 소프트웨어의 기반으로 사용할 수 있다. 범용 Ubuntu Server는 개발 도구와 패키지를 쉽게 추가하는 환경에, Ubuntu Core는 제품 이미지와 원격 업데이트를 관리하는 환경에 활용된다. 두 방식은 패키지 관리와 시스템 변경 모델이 다르다.^[532]

로봇 분야에서는 Ubuntu와 ROS의 지원 조합이 중요한 예이다. ROS 배포판은 대상 Ubuntu 버전과 아키텍처를 명시하며, 예를 들어 ROS 2 Jazzy의 deb 패키지는 Ubuntu 24.04를 대상으로 제공된다. 따라서 가장 새로운 Ubuntu를 선택하는 것보다 사용할 로봇 미들웨어와 드라이버가 검증한 조합을 기준으로 개발 환경을 구성할 수 있다.^[533]

기업 IT

기업 IT에서는 Ubuntu 데스크톱과 서버를 계정·정책·자산 관리 체계에 연결하여 운영할 수 있다. Active Directory 인증과 중앙 패키지 관리, 보안 업데이트와 장치 인벤토리를 조합하면 개별 사용자의 수동 구성에 대한 의존성을 줄일 수 있다. 데스크톱과 서버가 공통 기반을 사용하더라도 적용할 정책은 역할에 맞게 나눈다.^[534]

Landscape와 Ubuntu Pro는 각각 관리와 유지보수의 일부를 제공한다. 조직은 장치 그룹과 운영 단계에 따라 업데이트를 검증하고 배포하며, 보안 기준과 업무 프로그램의 요구사항 사이에서 구성을 조정한다. 이러한 도구가 존재한다는 사실보다 실제로 어떤 자산에 어떤 정책이 적용되어 있는지를 추적하는 것이 기업 운영의 핵심이다.^[535]

Ubuntu의 영향은 데스크톱 보급만으로 한정되지 않는다. 설치와 배포의 접근성을 높인 활동, 클라우드 이미지와 자동 초기화, 파생 배포판의 기반 제공과 하드웨어 인증 등 서로 다른 영역에서 확인할 수 있다. 다만 이러한 사례를 특정 시장의 점유율이나 기술적 우월성을 입증하는 통계와 혼동해서는 안 된다.^[536]

Linux 데스크톱의 대중화

Ubuntu는 설치와 기본 프로그램의 통합을 통해 사용자가 여러 구성 요소를 처음부터 조립하지 않고 Linux 데스크톱을 시작할 수 있는 경로를 제공했다. 초기 ShipIt 프로그램은 설치 CD를 우편으로 제공하여 다운로드가 어려운 사용자에게도 배포 매체를 전달하였다. 이는 소프트웨어의 사용 가능성과 실제 접근성을 함께 다룬 사례이다.^[537]

공식 Flavor는 이러한 통합 방식을 하나의 데스크톱으로 제한하지 않고 다른 사용자 경험으로 확장했다. GNOME을 사용하지 않더라도 Ubuntu의 패키지와 관리 지식을 활용할 수 있게 한 것이다. 이 점에서 Ubuntu의 데스크톱 영향은 특정 화면 디자인뿐 아니라 설치 가능한 완성된 환경과 여러 선택지를 제공한 데에서도 찾을 수 있다.^[538]

Debian 계열 생태계

Ubuntu는 Debian의 패키징 성과를 새로운 릴리스와 제품 구성에 통합하여 Debian 계열 소프트웨어의 활용 범위를 넓혔다. 소스 패키지의 동기화와 병합은 Debian의 작업이 Ubuntu로 유입되는 구체적인 경로이며, 수정 사항을 되돌려 보내는 협업도 존재한다. 이러한 관계는 공통 도구와 패키지 지식의 재사용을 가능하게 한다.^[539]

동시에 Ubuntu는 여러 독립 파생판의 직접적인 기반이 되었다. 이 구조에서는 Debian, Ubuntu와 파생판이 각각 다른 범위의 변경을 유지할 수 있다. 따라서 생태계의 확장은 하나의 프로젝트가 모든 기능을 소유하는 방식이 아니라 공통 기반 위에 여러 개발 조직의 선택이 쌓이는 형태로 나타난다.^[540][541]

클라우드 컴퓨팅

Ubuntu는 초기 클라우드 이미지 제공과 OpenStack 통합을 통해 데스크톱 밖의 배포 형태를 발전시켰다. 클라우드 이미지는 운영체제를 매번 수동 설치하는 대신 준비된 디스크 상태를 복제하는 기반을 제공했고, 초기화 도구는 인스턴스마다 다른 계정과 역할을 적용하는 데 사용되었다.^[542]

cloud-init의 단계별 초기화와 공급자별 데이터 소스는 이미지와 환경별 설정을 분리하는 데 기여한다. 이러한 구조에서는 같은 운영체제 이미지를 여러 인스턴스에 사용하면서도 각 인스턴스의 역할을 선언할 수 있다. Ubuntu의 클라우드 영향은 특정 공급자의 상품뿐 아니라 재사용 가능한 이미지와 초기화 작업 흐름을 함께 제공한 점으로 설명할 수 있다.^[543]

서버 시장

Ubuntu는 LTS와 공식 클라우드 이미지, 기업용 보안 유지보수 선택지를 통해 장기간 운영되는 서버의 기반을 제공한다. 물리 서버와 가상 머신에서 비슷한 패키지 관리와 서비스 운영 지식을 재사용할 수 있다는 점은 여러 환경을 관리하는 조직에 의미가 있다. 다만 이를 모든 서버 분야에서 동일한 채택률을 가진다는 주장으로 확대할 수는 없다.^[544][545]

공개된 도입 사례에서는 Ubuntu가 웹 서비스와 인프라 운영의 기반으로 사용된 구체적인 방식을 확인할 수 있다. 이러한 사례는 특정 조직의 요구와 선택을 보여주는 자료이며 전체 시장의 통계를 대신하지 않는다. 따라서 서버 분야의 영향은 확인 가능한 제품 지원과 실제 적용 사례를 구분하여 설명하는 것이 적절하다.^[546]

Linux 하드웨어 지원

Ubuntu의 하드웨어 인증과 제조사 협력은 Linux가 실제 제품에서 동작하는지를 검증하는 경로를 제공한다. 커널에 드라이버가 존재하는 것과 특정 노트북·서버의 전체 구성이 정상 동작하는 것은 다르며, 인증은 이러한 제품 수준의 차이를 다룬다. Ubuntu는 공개된 인증 목록을 통해 사용자와 기업이 검증된 조합을 확인할 수 있게 한다.^[547]

하드웨어 지원 과정에는 드라이버뿐 아니라 펌웨어와 설치 이미지, 전원 관리와 사용자 공간 구성도 포함된다. 제조사와 배포판 개발자가 함께 문제를 조사하고 변경을 반영하는 과정은 일반적인 소프트웨어 패키징과 다른 제품 통합 작업이다. 따라서 Ubuntu의 기여는 단순한 지원 장치 수보다 이러한 검증과 배포 경로의 존재에서도 평가할 수 있다.^[548]

오픈 소스 소프트웨어 생태계

Ubuntu는 여러 업스트림 프로젝트의 소프트웨어를 하나의 운영체제로 통합하면서 패키징과 테스트, 오류 보고와 수정 전달을 수행한다. 라이브러리와 언어 버전 전환 과정에서는 다수의 응용 프로그램을 함께 검증해야 하므로, 배포판의 작업은 개별 프로그램의 개발과 다른 형태의 통합 검증을 제공한다.^[549]

개발 권한이 없는 기여자도 수정안을 준비하고 검토를 통해 참여할 수 있으며, 이러한 기여가 이후 개발자 지위로 이어질 수 있다. Ubuntu의 영향은 Canonical의 유급 개발뿐 아니라 외부 기여와 공개된 패키징 절차를 통해 이루어지기도 한다. 다만 Ubuntu에서 시작된 모든 변경이 자동으로 업스트림에 채택되는 것은 아니며, 각 프로젝트의 검토와 정책은 독립적으로 유지된다.^[550]

파생 배포판

Ubuntu를 기반으로 하는 프로젝트는 공통 패키지와 설치 가능한 기반을 활용하면서 자체적인 사용자 경험을 개발할 수 있다. Pop!_OS의 COSMIC과 elementary OS의 Pantheon, Linux Mint의 데스크톱·관리 도구는 이러한 분화를 보여주는 사례이다. 각각의 프로젝트가 제공하는 기능과 결정은 Ubuntu 전체의 기능으로 환원되지 않는다.^[551][552]

파생 구조는 개발 효율과 함께 의존성도 만든다. 기반 라이브러리와 릴리스 정책이 바뀌면 파생판도 이를 검증하고 자신의 변경을 다시 통합해야 한다. KDE neon이 Ubuntu LTS 기반과 KDE 패키지의 갱신을 분리하는 방식은 이러한 관계를 관리하는 하나의 사례이며, 파생판마다 다른 균형을 선택한다.^[553]

Ubuntu를 둘러싼 논쟁은 기술 자체의 성능뿐 아니라 기본값과 사용자 선택, 소프트웨어 공급의 통제권과 기업·커뮤니티의 관계에 걸쳐 나타났다. 특정 시기의 기능과 이후 변경된 정책을 구분해야 하며, 한 이해관계자의 평가는 그 주체의 입장으로 서술하는 것이 필요하다. 현재의 모든 Ubuntu 설치가 과거와 같은 설정을 사용한다고 일반화할 수는 없다.^[554][555]

Amazon 검색 기능

Ubuntu 12.10의 Unity Dash는 로컬 검색과 함께 온라인 쇼핑 결과를 제공하는 기능을 포함했다. 이 과정에서 검색어가 외부 서비스로 전달되는 방식이 개인정보 보호 논쟁을 일으켰다. EFF는 사용자가 로컬 프로그램이나 파일을 찾는다고 생각하는 인터페이스에서 검색어가 외부로 전송될 수 있다는 점과 데이터 전달 방식을 비판했다.^[556]

쟁점은 Amazon 결과가 표시된다는 사실만이 아니라, 어떤 검색을 온라인 요청으로 취급하고 기본적으로 어떻게 동작하게 할 것인가에 있었다. 통합 검색의 편의성과 사용자 기대에 맞는 데이터 통제 사이의 충돌로 볼 수 있다. 이후 Ubuntu 16.04에서는 Dash의 온라인 검색이 기본적으로 비활성화되었으므로, 12.10의 동작을 후속 Ubuntu 전체의 현재 동작으로 설명해서는 안 된다.^[557]

Unity와 사용자 인터페이스 변화

Unity는 Ubuntu가 자체적인 데스크톱 작업 흐름을 제공하려는 시도였다. Launcher와 Dash, 글로벌 메뉴와 HUD 등은 프로그램 실행과 메뉴 접근을 기존 GNOME 2와 다르게 구성했다. 이러한 기능은 새로운 인터페이스를 선호하는 사용자에게 의미가 있었지만, 기존의 패널과 메뉴 방식에 익숙한 사용자에게는 큰 변화이기도 했다.^[558]

Canonical은 2017년 Unity 8과 휴대전화·컨버전스 셸에 대한 투자를 종료하고 GNOME으로 방향을 전환한다고 발표했다. 이 결정은 기술 구현만이 아니라 프로젝트에 투입할 자원과 제품의 채택 가능성에 대한 판단이었음을 보여준다. 이후에도 Unity 7은 별도의 커뮤니티 프로젝트로 이어졌으므로, Canonical의 투자 종료와 해당 사용자 인터페이스의 완전한 소멸을 동일하게 보아서는 안 된다.^[559][560]

Mir과 Wayland

Mir은 Canonical의 디스플레이 기술 개발과 연결된 프로젝트로, 초기에는 다른 Linux 데스크톱의 Wayland 전환과 별도의 방향을 추구한 점이 논쟁의 대상이었다. Canonical의 2017년 전환 발표도 이러한 독자적인 방향이 커뮤니티에서 분절로 받아들여졌다는 점을 언급한다. 이는 공통 기반에 협력하는 방식과 제품 요구를 위해 별도 기술을 개발하는 방식 사이의 긴장을 보여준다.^[561]

현재의 Mir을 초기의 경쟁 구도만으로 설명하는 것은 정확하지 않다. Mir은 Wayland 컴포지터를 구현하는 데 사용하는 라이브러리와 도구로 발전했으며, 임베디드와 전용 화면 환경 등의 요구를 다룬다. 따라서 역사적 논쟁과 현재의 기술 구조를 나누어, 현재 Mir이 Wayland 기반의 시스템에서 사용될 수 있다는 점을 함께 서술해야 한다.^[562][563]

Snap

Snap에 대한 논쟁에는 응용 프로그램을 여러 Ubuntu 버전에 배포하기 쉽게 하는 장점과, 배포 경로와 업데이트 통제권에 대한 비판이 함께 존재한다. Canonical은 Chromium의 deb 패키지를 Snap으로 전환하면서 여러 지원 릴리스에 보안 수정과 새 버전을 지속적으로 제공하는 유지보수 부담을 이유로 설명했다. 패키지를 하나의 배포 경로로 관리하여 지원 환경 사이의 차이를 줄이려는 접근이었다.^[564]

Linux Mint는 이러한 전환에서 APT로 요청한 설치가 Snap 설치로 이어지는 동작과 중앙 저장소에 대한 의존성을 비판했다. 이는 Snap을 사용할 수 있다는 사실보다, 사용자의 명시적인 선택과 패키지 관리 도구의 기대를 어떻게 존중할 것인가에 관한 입장이다. Mint는 자체 정책에 따라 기본 Snap 설치 동작을 Ubuntu와 다르게 구성한다.^[565]

Snap의 기술적 평가와 저장소 운영 정책의 평가는 분리할 수 있다. 트랜잭션 업데이트와 revision 관리 같은 기능이 유용하더라도 저장소의 통제권이나 자동 전환에 동의하지 않을 수 있고, 반대로 중앙 배포의 편의를 우선할 수도 있다. 따라서 논쟁을 단순히 “Snap은 좋다” 또는 “Snap은 나쁘다”로 정리하기보다 업데이트 모델과 사용자의 선택, 배포자와 저장소 운영자의 역할을 각각 살펴보는 것이 적절하다.^[566]

독자적인 기술 개발

Ubuntu와 Canonical은 제품 요구를 해결하기 위해 자체적인 기술과 통합 방식을 개발해 왔다. 독자 개발은 기존 프로젝트가 바로 제공하지 않는 기능을 구현할 수 있게 하지만, 별도의 코드와 생태계를 유지해야 하는 부담도 만든다. Unity와 Mir을 둘러싼 논의는 이러한 선택이 개발 자원과 커뮤니티 협력에 어떤 영향을 줄 수 있는지 보여준다.^[567]

자체 기술이 업스트림과 반드시 대립하는 것은 아니다. Mir이 Wayland 컴포지터 구현 기반으로 발전한 사례처럼 역할과 인터페이스를 바꾸어 더 넓은 생태계 안에서 사용될 수 있다. 따라서 독자 개발의 결과는 시작 당시의 구도만으로 평가하기보다 이후의 유지 상태와 사용자, 다른 프로젝트와의 호환 관계를 기준으로 살펴볼 수 있다.^[568]

Canonical과 커뮤니티의 관계

Canonical은 Ubuntu의 주요 개발 인력과 인프라, 제품 방향에 큰 영향을 미친다. 동시에 Ubuntu는 Community Council과 Technical Board 등 공개적인 거버넌스 구조를 유지하며 커뮤니티의 참여를 제도화한다. 기업의 조직 구조와 Ubuntu 프로젝트의 전체 의사결정 구조는 같지 않지만, 창립자의 특별한 권한과 Canonical의 자원 배분이 중요한 역할을 한다.^[569]

이 구조에서는 커뮤니티의 합의와 기업이 실제로 투자할 영역이 항상 동일하지 않을 수 있다. 제품 개발을 계속하려면 인력과 재원이 필요하고, Canonical은 사업과 프로젝트의 지속성을 고려하여 투자 방향을 바꿀 수 있다. 따라서 Ubuntu를 순수한 기업 내부 제품이나 기업 영향이 없는 공동체 프로젝트 중 하나로만 분류하기보다, 두 구조가 결합하면서 협력과 긴장이 함께 발생하는 프로젝트로 이해할 수 있다.^[570]

독점 소프트웨어와 드라이버

Ubuntu는 자유·오픈 소스 소프트웨어를 중심으로 하면서도 일부 하드웨어를 위해 별도 라이선스의 드라이버를 사용할 수 있도록 한다. 이는 장치의 기능을 이용하기 위한 현실적인 선택지를 제공하지만, 사용자가 코드를 검토하고 수정·재배포할 수 있는 범위는 구성 요소별로 달라진다는 뜻이다. 따라서 “Ubuntu를 사용하면 모든 구성 요소가 같은 자유 라이선스를 따른다”라고 설명할 수는 없다.^[571]

이 문제는 하드웨어 사용성과 소프트웨어 자유, 제조사에 대한 의존성을 어떻게 조정할 것인가에 관한 논의로 이어진다. 독점 드라이버를 사용하면 특정 기능을 활용할 수 있지만, 업데이트와 커널 호환성은 제조사와 배포판의 공급 경로에 영향을 받는다. 실제 선택에서는 필요한 장치 기능과 대체 드라이버, 라이선스와 장기 지원 조건을 구분하여 검토할 수 있다.^[572]

개인정보 보호

Ubuntu의 개인정보 보호는 하나의 기능으로 판단하기보다 진단 정보와 오류 보고, 계정 연동과 온라인 서비스의 데이터 전달을 각각 구분해야 한다. Canonical의 시스템 정보 고지는 자발적으로 공유하는 하드웨어와 운영체제 관련 정보의 범위를 설명한다. 이러한 정보 공유를 선택하지 않는다는 사실이 모든 업데이트 요청과 온라인 서비스의 네트워크 통신까지 중단한다는 의미는 아니다.^[573]

오류 보고는 충돌한 프로그램과 실행 상태에 관한 자료를 포함할 수 있어 일반적인 하드웨어 통계와 다른 검토가 필요하다. 또한 온라인 계정이나 특정 서비스와 연결하면 해당 서비스의 데이터 처리 조건이 적용될 수 있다. 따라서 사용자는 기능별 고지와 설정을 확인하고, 조직에서는 어떤 정보가 어떤 목적과 경로로 전달되는지 구분하여 정책을 정할 수 있다.^[574]

일부 서버 기능도 별도의 원격 요청을 수행할 수 있다. 예를 들어 MOTD 뉴스 서비스에는 자체적인 고지와 비활성화 방법이 존재한다. 이러한 사례는 과거 Dash 검색 논쟁, 현재의 진단 정보 공유와 서버의 정보 갱신 기능을 하나의 동일한 수집 행위로 묶기보다, 실제 기능과 버전·설정을 기준으로 설명해야 함을 보여준다.^[575]

Ubuntu의 주요 강점은 공통 패키지 기반을 데스크톱과 서버, 클라우드와 장치 환경으로 확장하여 제공한다는 점이다. APT와 systemd, 여러 개발 도구에 대한 지식을 다른 Ubuntu 환경에서 재사용할 수 있으며, 공식 Flavor와 독립 파생판은 이 기반 위에서 다른 사용자 경험을 제공한다. 다만 같은 기반을 사용한다는 사실이 모든 이미지와 제품의 구성·지원 범위가 같다는 뜻은 아니다.^[576][577]

LTS와 추가 보안 유지보수는 오랫동안 같은 기반을 운영해야 하는 환경에 선택지를 제공한다. 패키지의 기능 버전을 무조건 최신화하지 않고 보안 수정을 적용하는 방식은 기존 응용 프로그램과의 호환성을 유지하는 데 도움이 될 수 있다. 반면 새로운 컴파일러나 라이브러리가 필요한 프로젝트는 언어별 도구 체인과 컨테이너, 다른 공급 경로를 함께 관리해야 할 수 있다.^[578][579]

하드웨어 인증과 제조사 협력은 제품 선택의 근거를 제공하지만, 모든 하드웨어 조합과 주변 장치의 동작을 일괄 보장하지는 않는다. 그래픽과 무선, 전원 관리와 가속기 소프트웨어는 실제 모델과 커널·펌웨어의 조합에 영향을 받는다. 따라서 일반적인 배포판 평가보다 사용할 장치와 응용 프로그램의 지원 조합을 확인하는 것이 실질적인 판단에 더 중요할 수 있다.^[580][581]

Ubuntu의 넓은 소프트웨어 공급 경로는 선택의 폭을 제공하는 동시에 관리 책임을 늘릴 수 있다. 배포판 패키지와 외부 저장소, 언어별 패키지와 컨테이너 이미지가 함께 존재하면 각각의 버전과 보안 수정, 데이터와 설정의 소유권을 구분해야 한다. 이는 특정 패키지 형식을 일괄 배제해야 한다는 의미가 아니라, 선택한 방식이 어떤 계층을 관리하고 누가 유지보수하는지 명확하게 해야 한다는 뜻이다.^[582][583]

Canonical의 개발 투자와 지원 서비스는 Ubuntu의 지속적인 통합과 제품 제공을 가능하게 하는 기반이지만, 제품 방향과 사용자 선택에 대한 논쟁도 함께 발생시켜 왔다. 공개 거버넌스와 커뮤니티 참여, 독립 Flavor와 파생판은 그 안에서 서로 다른 요구를 표현하는 경로이다. Ubuntu의 장점과 한계는 이러한 기술적·조직적 구조를 함께 고려하고, 사용 목적에 맞는 릴리스와 운영 방식을 선택할 때 구체적으로 드러난다.^[584][585]

• Linux
• Linux 커널
• Linux 배포판
• GNU
• Debian
• Canonical
• APT
• dpkg
• Snap
• Flatpak
• systemd
• GNOME
• Wayland
• X Window System
• Kubuntu
• Xubuntu
• Lubuntu
• Ubuntu MATE
• Ubuntu Budgie
• Ubuntu Studio
• Ubuntu Kylin
• Edubuntu
• Ubuntu Cinnamon
• Ubuntu Unity
• Linux Mint
• elementary OS
• Pop!_OS
• Zorin OS
• Ubuntu Server
• Ubuntu Core