우분투 버전 정리: 26.04 LTS와 지원 기간, 데스크톱·서버 에디션, x86·ARM 아키텍처 차이

들어가며

“우분투 몇 버전 쓰세요?”라는 질문에 “22요”, “24요”라고 답하는 경우가 많습니다. 그런데 막상 설치하려고 다운로드 페이지에 들어가면 26.04 LTS, 25.10, 데스크톱, 서버, 64비트 ARM, 라즈베리 파이 이미지가 한꺼번에 나와서 무엇을 받아야 할지 헷갈리기 쉽습니다. 인터넷에 있는 설치 글도 작성 시점의 버전을 기준으로 쓰여 있어서, 지금 받으려는 버전과 맞는지 판단하기 어렵습니다.

이 글은 2026년 9월 말 기준으로 우분투의 버전 체계를 처음부터 정리합니다. 버전 번호가 무엇을 뜻하는지, LTS와 중간 릴리스가 어떻게 다른지, 지금 지원을 받고 있는 버전은 무엇인지, 26.04 LTS에서 무엇이 바뀌었는지, 그리고 데스크톱·서버 같은 에디션과 x86·ARM 같은 아키텍처를 어떻게 골라야 하는지 순서대로 설명합니다. 날짜와 버전 정보는 Canonical 공식 릴리스 주기 페이지와 26.04 릴리스 노트를 기준으로 했습니다.

버전 번호와 코드네임 읽는 법

우분투 버전 번호는 출시 연도.출시 월 형식입니다. 26.04는 2026년 4월, 24.04는 2024년 4월에 나온 버전입니다. 우분투는 매년 4월과 10월, 1년에 두 번 새 버전을 내기 때문에 뒷자리는 거의 항상 .04 아니면 .10입니다. 번호만 보고도 얼마나 오래된 버전인지 바로 알 수 있다는 것이 이 방식의 장점입니다.

LTS 버전에는 26.04.1, 24.04.3처럼 세 번째 숫자가 붙기도 합니다. 이것은 포인트 릴리스로, 새 버전이 아니라 그동안 쌓인 보안 업데이트와 버그 수정을 반영해 설치 이미지를 다시 만든 것입니다. 이미 26.04를 설치해 두고 apt upgrade를 꾸준히 해 왔다면 26.04.1을 따로 설치할 필요가 없습니다. 새로 설치할 때 최신 포인트 릴리스 이미지를 받으면 설치 직후 받아야 할 업데이트 양이 줄어들 뿐입니다.

각 버전에는 형용사 + 동물 형태의 코드네임도 붙습니다. 두 단어의 첫 글자가 같고, 알파벳 순서대로 진행되는 것이 관례입니다.

버전	코드네임	구분
26.10	Stonking Stingray	중간 릴리스 (2026년 10월 15일 출시 예정)
26.04	Resolute Raccoon	LTS
25.10	Questing Quokka	중간 릴리스 (지원 종료)
24.04	Noble Numbat	LTS
22.04	Jammy Jellyfish	LTS
20.04	Focal Fossa	LTS
18.04	Bionic Beaver	LTS

코드네임은 단순한 애칭이 아니라 실제 설정 파일 곳곳에 쓰입니다. apt 저장소 주소에 noble, resolute 같은 첫 단어가 들어가고, Docker 공식 이미지 태그(ubuntu:noble)나 서드파티 저장소 설치 안내에서도 코드네임을 요구합니다. 외부 저장소를 추가할 때 다른 버전의 코드네임을 적어 넣으면 패키지 의존성이 맞지 않아 설치가 꼬이는 일이 흔하므로, 내 시스템의 코드네임은 lsb_release -cs로 확인해서 쓰는 것이 안전합니다.

LTS와 중간 릴리스: 지원 기간이 다른 두 갈래

우분투 버전은 크게 두 종류입니다.

LTS(Long Term Support) 는 2년마다 짝수 해 4월에 나옵니다. 22.04, 24.04, 26.04가 모두 LTS입니다. 출시 후 5년간 표준 보안 유지보수를 받고, Ubuntu Pro를 쓰면 ESM(Expanded Security Maintenance)으로 5년이 더 늘어나 총 10년, 여기에 Legacy 애드온까지 더하면 최대 15년 동안 보안 패치를 받을 수 있습니다. 서버, 회사 PC, 오래 두고 쓸 개발 머신은 거의 예외 없이 LTS를 씁니다.

중간(interim) 릴리스는 LTS 사이에 6개월마다 나오는 버전입니다. 24.10, 25.04, 25.10, 26.10 같은 버전이 여기에 속하며 지원 기간은 9개월입니다. 다음 LTS에 들어갈 새 기능을 미리 선보이는 성격이라 커널과 데스크톱 환경이 가장 최신이지만, 9개월이 지나면 반드시 다음 버전으로 올려야 합니다.

여기서 흔히 놓치는 점이 하나 있습니다. 공식 플레이버(Kubuntu, Xubuntu, Lubuntu 등)의 LTS는 지원 기간이 3년입니다. 기반 패키지는 우분투 본체와 같이 5년간 업데이트되지만, KDE나 Xfce 같은 플레이버 고유의 데스크톱 구성 요소는 각 커뮤니티가 3년만 책임집니다. Kubuntu 22.04를 5년 쓸 생각으로 설치했다가 3년 차에 데스크톱 쪽 업데이트가 끊기는 것을 뒤늦게 알게 되는 경우가 있으니, 플레이버를 고를 때는 이 차이를 기억해 두는 것이 좋습니다.

Ubuntu Pro와 ESM은 무엇이 다른가

Ubuntu Pro는 Canonical의 구독 서비스이고, ESM은 그 안에 포함된 기능 중 하나입니다. 표준 지원 기간에도 Pro를 연결하면 universe 저장소(커뮤니티가 관리하는 방대한 패키지 모음)에 대한 보안 패치까지 받을 수 있고, 표준 지원이 끝난 뒤에는 main 저장소 패키지의 보안 패치도 이어서 받습니다. 재부팅 없이 커널 보안 패치를 적용하는 Livepatch도 Pro에 포함됩니다. 개인 사용자는 최대 5대까지 무료라서, 오래된 LTS를 당장 올리기 어려운 개인 서버라면 켜 두는 것이 좋습니다.

pro status                  # 현재 Pro 연결 상태와 활성화된 서비스 확인
sudo pro attach <토큰>       # ubuntu.com/pro 에서 받은 토큰으로 연결

2026년 9월 기준 지원 중인 버전

Canonical 공식 릴리스 주기 표를 기준으로, 지금 시점에서 어떤 버전이 어떤 지원을 받고 있는지 정리하면 다음과 같습니다.

버전	출시	표준 지원 종료	ESM(Pro) 종료	지금 상태
26.10	2026년 10월(예정)	2027년 7월	–	출시 예정
26.04 LTS	2026년 4월	2031년 5월	2036년 5월	표준 지원 중 (26.04.1 출시)
25.10	2025년 10월	2026년 7월	–	지원 종료
24.04 LTS	2024년 4월	2029년 5월	2034년 5월	표준 지원 중
22.04 LTS	2022년 4월	2027년 5월	2032년 5월	표준 지원 중 (종료 약 8개월 전)
20.04 LTS	2020년 4월	2025년 5월	2030년 5월	Pro 없이는 보안 업데이트 없음
18.04 LTS	2018년 4월	2023년 5월	2028년 5월	Pro 없이는 보안 업데이트 없음

표에서 실무적으로 중요한 줄은 두 개입니다.

첫째, 22.04 LTS의 표준 지원이 2027년 5월에 끝납니다. 아직 22.04로 돌아가는 서버가 많은데, 이제 올릴 계획을 세워야 할 시점입니다. 22.04에서 26.04로 바로 가는 공식 경로는 없고 24.04를 거쳐야 하므로(LTS 간 업그레이드는 한 단계씩만 지원됩니다), 두 번의 업그레이드 또는 재설치를 일정에 넣어야 합니다.

둘째, 20.04는 이미 표준 지원이 끝났습니다. apt upgrade를 해도 새 보안 패치가 오지 않는 상태이므로, Pro를 연결해 ESM을 받거나 새 LTS로 옮겨야 합니다. 20.04 서버에서 apt update를 할 때 “추가 보안 업데이트는 ESM을 활성화하면 받을 수 있다”는 안내가 나오는 것이 바로 이 상태를 뜻합니다.

26.04 LTS(Resolute Raccoon)에서 바뀐 것

26.04 LTS는 2026년 4월 23일에 출시되었고, 첫 포인트 릴리스인 26.04.1이 8월 27일에 나왔습니다. 24.04에서 넘어오는 사용자 입장에서는 2년 치 변화가 한꺼번에 들어온 셈이라 체감 차이가 큽니다. 공식 릴리스 노트의 “LTS 사용자를 위한 요약”을 바탕으로 중요한 것만 추리면 다음과 같습니다.

커널과 데스크톱

• 리눅스 커널 7.0: 24.04의 6.8에서 크게 올라갔습니다. 최신 인텔 Core Ultra(Panther Lake) 그래픽과 NPU, 스냅드래곤 계열 ARM 노트북 등 새 하드웨어 지원이 여기서 들어옵니다.
• GNOME 50, Wayland 전용: 24.04의 GNOME 46에서 올라갔고, GNOME의 X.org 세션이 완전히 제거되었습니다. 17.10부터 시작된 Wayland 전환이 이번 LTS에서 마무리된 것입니다. X11 전용 앱은 XWayland로 여전히 실행되지만, 화면 공유·원격 제어·전역 단축키처럼 X11의 동작을 전제로 한 도구는 Wayland 방식을 지원하는 버전으로 바꿔야 할 수 있습니다.
• TPM 기반 전체 디스크 암호화가 설치 프로그램에서 정식 기능이 되었습니다. 부팅할 때마다 암호를 입력하지 않고도 디스크를 암호화할 수 있지만, BIOS 업데이트나 Secure Boot 설정 변경 후 복구 키를 요구할 수 있으므로 복구 키를 반드시 따로 보관해야 합니다.

Rust로 다시 쓴 기본 도구

26.04에서 가장 눈에 띄는 변화는 시스템의 기본 명령어 일부가 Rust 구현으로 바뀐 것입니다. sudo는 sudo-rs로, ls·cp·mv 같은 기본 명령어 묶음(coreutils)은 uutils coreutils로 교체되었습니다. 목적은 메모리 안전성입니다. 수십 년 된 C 코드에서 반복적으로 나오던 버퍼 오버플로 계열 취약점을 언어 차원에서 줄이려는 것입니다.

사용자 입장에서는 대부분 차이를 느끼지 못하지만, 셸 스크립트가 GNU coreutils의 아주 세세한 동작(특정 옵션 조합의 출력 형식, 에러 메시지 문구, 드문 옵션)에 의존하고 있다면 결과가 달라질 수 있습니다. 실제로 24.04→26.04 자동 업그레이드가 열리기 전에 Canonical이 rust-coreutils 회귀 버그 몇 가지를 먼저 고쳤을 정도로, 초기에는 호환성 문제가 있었습니다. 에러 메시지 문자열을 grep해서 분기하는 식의 오래된 운영 스크립트가 있다면 업그레이드 전에 테스트 환경에서 한 번 돌려 보는 것을 권합니다.

개발 도구 버전

개발자에게 가장 직접적인 변화는 기본 저장소의 언어·도구 버전입니다. apt로 설치했을 때 기본으로 들어오는 버전을 24.04와 비교하면 다음과 같습니다.

도구	24.04 LTS	26.04 LTS
GCC	14	15.2
LLVM/Clang	18	21
Python	3.12	3.14
OpenJDK(기본)	21	25
Go	1.22	1.25
Rust	1.75	1.93
PHP	8.4	8.5
systemd	255	259
OpenSSH	9.6p1	10.2p1
APT	2.7	3.1
MySQL	8.0	8.4 LTS

.NET 10과 PostgreSQL 18도 기본 저장소에서 설치할 수 있습니다. 또 NVIDIA CUDA와 AMD ROCm이 공식 저장소에 들어온 첫 LTS라서, GPU 개발 환경을 꾸릴 때 벤더 저장소를 따로 추가하지 않아도 되는 경우가 늘었습니다.

Python 3.14로 올라가면서 시스템 Python에 pip install을 하면 externally-managed-environment 에러가 나는 동작(PEP 668)은 그대로 유지됩니다. 24.04부터 이미 그랬기 때문에 22.04에서 바로 넘어오는 분들이 가장 많이 당황하는 부분입니다. 프로젝트마다 python3 -m venv나 uv로 가상 환경을 만들어 쓰는 습관을 들이면 버전이 바뀌어도 문제를 피할 수 있습니다.

조용히 사라진 것들

업그레이드 후 문제를 일으키는 것은 새 기능보다 제거된 기능인 경우가 많습니다. 26.04에서 빠진 것 중 실제로 부딪히기 쉬운 것은 다음과 같습니다.

• apt-key 명령 제거: 오래된 설치 안내서의 curl ... | sudo apt-key add - 방식은 더 이상 동작하지 않습니다. 저장소 키는 /etc/apt/keyrings/에 두고 .sources 파일(또는 signed-by= 옵션)에서 지정해야 합니다. 24.04에서도 경고가 나왔지만 이제는 명령 자체가 없습니다.
• cgroup v1 지원 제거: 아주 오래된 Docker·Kubernetes 버전이나 cgroup v1을 전제로 한 모니터링 에이전트는 동작하지 않습니다.
• systemd의 System V 스크립트 호환: 26.04의 systemd 259가 /etc/init.d/ 스크립트를 지원하는 마지막 버전입니다. 지금은 동작하지만, 자체 서비스가 아직 init.d 스크립트로 되어 있다면 systemd 유닛 파일로 옮겨 둘 때입니다.
• 초기 램디스크 도구 변경: initramfs-tools 대신 Dracut이 기본이 되었습니다. update-initramfs에 맞춰 넣어 둔 커스텀 훅이 있다면 확인이 필요합니다.
• 시간 동기화: systemd-timesyncd 대신 chrony가 기본 시간 데몬이 되었습니다. timedatectl로 상태를 보는 방법은 그대로지만, NTP 서버를 설정하는 파일 위치가 달라집니다.

에디션: 데스크톱, 서버, 클라우드, WSL, Core

같은 26.04라도 용도에 따라 여러 형태로 배포됩니다. 내부 패키지 저장소와 커널은 같지만, 처음에 무엇이 설치되어 있고 어떤 설치 방식을 쓰는지가 다릅니다.

Ubuntu Desktop

그래픽 환경(GNOME)이 포함된 일반 PC·노트북용입니다. 설치 프로그램에서 마우스로 디스크와 사용자를 설정하고, 네트워크는 NetworkManager가 관리하며, 앱은 App Center(snap과 deb 모두 지원)로 설치합니다. 개발용 개인 머신이라면 대부분 이 이미지를 씁니다.

26.04부터 권장 메모리가 6GB로 올라갔습니다(2GHz 듀얼코어 CPU, 저장 공간 25GB). 6GB는 설치를 막는 강제 조건은 아니어서 4GB 이하에서도 설치는 되지만, 브라우저 탭을 몇 개 띄우는 순간 스왑을 쓰기 시작해 체감 속도가 크게 떨어집니다. 메모리가 적은 오래된 노트북이라면 Xubuntu나 Lubuntu 같은 가벼운 플레이버가 공식 권장 대안입니다.

Ubuntu Server

그래픽 환경 없이 텍스트 기반 설치 프로그램으로 설치하는 서버용 이미지입니다. 권장 사양은 메모리 1.5GB, 저장 공간 4GB부터로 데스크톱보다 훨씬 가볍습니다. 설치 과정에서 OpenSSH 서버를 켤지, 자주 쓰는 서버 스냅(예: 컨테이너 도구)을 같이 설치할지 고를 수 있습니다. 네트워크는 netplan의 YAML 파일(/etc/netplan/*.yaml)로 설정하고, 첫 부팅 때 사용자·SSH 키·패키지를 자동으로 설정하는 cloud-init이 기본으로 들어 있습니다.

데스크톱과 서버의 차이는 설치 직후 상태일 뿐이라서, 서버에 ubuntu-desktop 패키지를 설치하면 데스크톱처럼 쓸 수도 있습니다. 하지만 이렇게 하면 네트워크 관리 주체가 netplan+systemd-networkd와 NetworkManager로 둘이 되어 재부팅 후 네트워크가 올라오지 않는 문제가 자주 생깁니다. “나중에 화면이 필요할지 모르니” 하고 원격 서버에 데스크톱을 얹었다가, 재부팅 후 네트워크가 올라오지 않아 SSH로 접속할 방법이 사라지는 것이 이 조합에서 가장 흔한 실수입니다. 저는 이런 이유로 서버에는 GUI를 올리지 않고, 화면이 꼭 필요하면 다른 PC에서 원격으로 붙는 쪽을 택합니다. 화면이 필요한 기계는 처음부터 데스크톱 이미지로, 서버는 서버 이미지로 설치하는 것이 가장 덜 꼬입니다.

클라우드 이미지와 WSL

AWS, Azure, Google Cloud, Oracle Cloud, IBM Cloud에서 EC2 같은 가상 머신을 만들 때 고르는 우분투는 Canonical이 각 클라우드에 맞게 최적화한 클라우드 이미지입니다. 서버 이미지와 패키지 구성은 거의 같지만, 해당 클라우드의 커널 변형(linux-aws, linux-azure 등)과 에이전트가 미리 들어 있고, 설치 과정 없이 cloud-init으로 바로 부팅됩니다.

Windows에서 쓰는 WSL용 우분투는 Microsoft Store나 wsl --install 명령으로 설치합니다. 설치할 수 있는 우분투 버전 이름은 wsl --list --online으로 확인할 수 있습니다. 커널은 우분투가 아니라 Microsoft가 제공하는 WSL 커널을 쓴다는 점이 일반 설치와 가장 큰 차이입니다. 그래서 커널 버전에 의존하는 기능(특정 파일 시스템, 커널 모듈)은 우분투 버전과 상관없이 WSL 커널 버전을 따라갑니다. WSL과 듀얼 부팅 중 무엇을 고를지는 WSL2 vs 듀얼 부팅 글에서 자세히 비교했습니다.

Ubuntu Core

IoT 기기와 임베디드 장비를 위한 읽기 전용(immutable) 버전입니다. 운영체제 전체가 snap 패키지로 구성되고, 업데이트는 원자적으로 적용되며 실패하면 이전 상태로 자동 롤백됩니다. 26.04를 기반으로 한 Ubuntu Core 26이 2026년 5월에 출시되었고, OTA 업데이트 크기를 크게 줄이고 ARM64 Livepatch를 지원하는 것이 특징입니다. apt로 패키지를 자유롭게 설치하는 일반 우분투와는 쓰는 방식이 완전히 다르므로, 일반 서버·PC 용도라면 고려 대상이 아닙니다.

공식 플레이버

기본 GNOME 대신 다른 데스크톱 환경을 쓰는 공식 파생판입니다. 26.04 기준으로 Kubuntu(KDE Plasma), Xubuntu(Xfce), Lubuntu(LXQt), Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Studio(멀티미디어 제작), Ubuntu Unity, Ubuntu Kylin(중국어 환경), Edubuntu(교육용)가 있습니다. 앞서 말했듯 LTS 플레이버는 3년 지원이라는 점만 기억하면, 패키지 저장소는 모두 같아서 나중에 다른 데스크톱을 추가 설치하는 것도 가능합니다.

지원 아키텍처: x86, ARM, RISC-V, IBM

우분투는 PC용 인텔·AMD뿐 아니라 여러 CPU 아키텍처를 공식 지원합니다. 26.04 LTS가 지원하는 아키텍처와 각각의 대표 사용처는 다음과 같습니다.

아키텍처(우분투 이름)	다른 이름	대표 사용처	26.04에서의 참고 사항
amd64	x86-64, x64	인텔·AMD PC, 노트북, 대부분의 서버	amd64v3 최적화 변형 추가
arm64	aarch64, ARMv8	라즈베리 파이 3/4/5, 스냅드래곤 노트북, AWS Graviton·Ampere 서버	범용 ARM64 데스크톱 ISO 제공
riscv64	RISC-V 64비트	RISC-V 개발 보드, 서버	RVA23 프로필 CPU 필요
ppc64el	POWER 리틀 엔디언	IBM Power 서버	서버 전용
s390x	IBM Z	IBM 메인프레임, LinuxONE	최소 z15 (z14 지원 종료)

amd64: 가장 일반적인 선택과 amd64v3 변형

인텔이나 AMD CPU를 쓰는 PC라면 amd64 이미지를 받으면 됩니다. 이름에 “amd”가 들어가 있지만 인텔 CPU도 똑같이 amd64입니다. 64비트 x86 명령어 집합을 AMD가 먼저 만들었기 때문에 붙은 이름일 뿐입니다.

26.04에서는 amd64v3라는 최적화 변형이 도입되었습니다. x86-64 명령어 집합은 세대별로 v1~v4 수준이 정의되어 있는데, v3는 AVX2, BMI2, FMA 같은 명령어를 포함하는 수준으로 인텔은 Haswell(4세대 Core) 이후, AMD는 Zen 이후의 CPU 대부분이 해당합니다. 다만 같은 시기의 인텔 저가형 펜티엄·셀러론 중에는 AVX2가 없어 v3에 못 미치는 모델도 있습니다. 이런 명령어를 쓰도록 컴파일한 패키지는 수치 계산이나 압축처럼 특정 작업에서 더 빠를 수 있습니다. 기본 amd64는 여전히 모든 64비트 x86 CPU에서 동작하도록 만들어지므로, 오래된 CPU를 쓴다고 해서 설치를 못 하는 것은 아닙니다. 내 CPU가 v3를 지원하는지는 다음처럼 확인할 수 있습니다.

/lib64/ld-linux-x86-64.so.2 --help | grep "x86-64-v"
# x86-64-v3 (supported, searched) 처럼 supported 가 붙어 있으면 지원

32비트 x86(i386)은 이미 오래전부터 설치 이미지가 없습니다. 64비트 우분투에서 Steam이나 Wine처럼 32비트 프로그램을 돌리기 위한 호환 라이브러리만 일부 남아 있고, 26.04에서는 i386용 MySQL 서버 빌드도 중단되었습니다. 32비트 전용 오래된 PC라면 우분투 대신 32비트를 계속 지원하는 다른 배포판을 찾아야 합니다.

arm64: 라즈베리 파이부터 노트북, 클라우드 서버까지

ARM은 이제 우분투에서 amd64 다음으로 중요한 아키텍처입니다. 26.04에서는 다운로드 페이지에서 세 가지 형태의 ARM 이미지를 제공합니다.

• 라즈베리 파이용 사전 설치 이미지: 라즈베리 파이 3, 4, 5, CM4, Zero 2 W를 지원합니다. ISO를 설치하는 방식이 아니라, Raspberry Pi Imager 등으로 microSD 카드에 이미지를 그대로 써서 부팅합니다. 26.04부터 부팅 파티션을 A/B로 나눠 업데이트가 실패해도 이전 상태로 부팅할 수 있게 되었습니다. 데스크톱을 쓰려면 메모리가 4GB 이상인 파이 4나 파이 5가 현실적입니다.
• 범용 ARM64 데스크톱 ISO: UEFI로 부팅하는 ARM 가상 머신(예: Apple Silicon Mac의 UTM, Parallels)과 스냅드래곤 X Elite 같은 Windows on ARM 노트북을 대상으로 합니다. 다만 스냅드래곤 노트북은 모델마다 하드웨어 지원 수준이 달라, 공식적으로도 “지원을 보장하지 않는다”고 밝히고 있습니다. 사기 전에 해당 모델의 커뮤니티 지원 현황을 먼저 확인하는 것이 좋습니다.
• ARM 서버 이미지와 클라우드 이미지: AWS Graviton, Ampere Altra 같은 ARM 서버에서 씁니다. 같은 성능 대비 비용이 낮아 클라우드에서 점점 많이 쓰입니다. 26.04부터는 Livepatch도 ARM64를 지원합니다.

ARM으로 옮길 때 가장 흔히 부딪히는 문제는 아키텍처가 다른 바이너리입니다. amd64용으로만 빌드된 Docker 이미지를 ARM 서버에서 실행하면 exec format error가 나고, amd64용 .deb 파일을 받아 설치하려 하면 package architecture (amd64) does not match system (arm64) 에러가 납니다. Apple Silicon Mac에서 만든 이미지를 amd64 서버에 올릴 때도 같은 문제가 반대로 생깁니다. 처음 ARM 서버로 옮기는 작업을 할 때 코드 자체보다 이런 빌드 산출물의 아키텍처를 맞추는 데 시간이 더 많이 드는 것이 보통이라, docker buildx로 linux/amd64,linux/arm64 멀티 플랫폼 이미지를 만드는 습관을 들이면 이런 일을 크게 줄일 수 있습니다.

RISC-V: RVA23 이전 보드는 26.04를 쓸 수 없음

RISC-V는 오픈 명령어 집합 아키텍처로, 우분투는 몇 년 전부터 riscv64를 공식 지원해 왔습니다. 그런데 26.04부터 최소 요구 사양이 RVA20에서 RVA23 프로필로 올라갔습니다. RVA23은 벡터 확장 등을 필수로 요구하는 최신 기준이라, 그 이전에 나온 대부분의 RISC-V 개발 보드는 26.04를 부팅할 수 없습니다. 기존 보드를 쓰고 있다면 24.04 LTS를 계속 쓰는 것이 현실적인 선택이고, 26.04를 쓰려면 RVA23을 지원한다고 명시된 새 하드웨어가 필요합니다.

IBM Power와 IBM Z

ppc64el(IBM Power)과 s390x(IBM Z 메인프레임, LinuxONE)는 기업 데이터센터용이라 개인이 접할 일은 드뭅니다. 26.04에서 s390x는 z15 이상만 지원하고 z14 지원은 종료되었습니다. 이런 환경을 운영 중이라면 하드웨어 세대를 먼저 확인한 뒤 업그레이드 계획을 세워야 합니다.

내 시스템의 버전과 아키텍처 확인하기

지금 쓰는 우분투의 버전·코드네임·아키텍처는 다음 명령으로 확인할 수 있습니다.

lsb_release -a               # 배포판 이름, 버전(26.04.1 LTS), 코드네임(resolute)
cat /etc/os-release          # 스크립트에서 쓰기 좋은 형식 (VERSION_ID, VERSION_CODENAME)
uname -r                     # 커널 버전 (예: 7.0.x-xx-generic)
dpkg --print-architecture    # 패키지 아키텍처 (amd64, arm64, riscv64 ...)
uname -m                     # 커널 기준 아키텍처 이름 (x86_64, aarch64 ...)
hostnamectl                  # 위 정보를 한 번에 요약

dpkg --print-architecture와 uname -m의 이름이 다른 것은 정상입니다. 우분투(데비안) 패키지 체계는 amd64·arm64라는 이름을 쓰고, 커널은 x86_64·aarch64라는 이름을 씁니다. 설치 스크립트에서 다운로드할 파일을 고를 때 이 두 이름을 섞어 쓰다가 잘못된 파일을 받는 일이 많으니, 어느 쪽 이름을 기준으로 하는지 확인해야 합니다.

셸 스크립트에서 버전에 따라 분기해야 한다면 lsb_release 출력을 파싱하기보다 /etc/os-release를 source해서 쓰는 편이 안정적입니다. lsb_release는 최소 설치 컨테이너 이미지에 없는 경우가 많기 때문입니다.

. /etc/os-release
echo "$VERSION_ID $VERSION_CODENAME"   # 26.04 resolute

어떤 버전을 골라야 하나

상황별로 정리하면 다음과 같습니다.

• 새 개발용 PC·노트북: 26.04 LTS. 26.04.1까지 나와 초기 안정화가 끝났고, 최신 하드웨어 지원과 개발 도구 버전이 모두 앞서 있습니다.
• 이미 24.04를 잘 쓰고 있는 PC: 급하게 올릴 이유는 없습니다. 24.04는 2029년까지 지원됩니다. 새 GNOME이나 최신 툴체인이 필요할 때 올리면 됩니다.
• 운영 서버: 새로 만드는 서버는 26.04 LTS, 기존 서버는 사용하는 소프트웨어(DB, 모니터링 에이전트, 보안 솔루션)가 26.04를 공식 지원하는지 먼저 확인합니다. 벤더 인증이 늦는 경우가 많아서, 인증이 나올 때까지 24.04로 새 서버를 만드는 것도 합리적인 선택입니다.
• 22.04 서버: 2027년 5월 표준 지원 종료 전에 24.04로 올리는 계획을 지금 세웁니다.
• 20.04 이하 서버: 당장 Ubuntu Pro를 연결해 ESM으로 보안 패치를 받고, 그다음 이전 계획을 세웁니다.
• 최신 기능을 먼저 써 보고 싶은 경우: 26.10(10월 15일 출시 예정). 단, 2027년 7월까지 27.04로 올려야 한다는 점을 감수해야 합니다.
• 메모리 4GB 이하 오래된 PC: Xubuntu나 Lubuntu 26.04.
• 라즈베리 파이: 파이 4(4GB 이상)·5는 26.04 데스크톱 또는 서버, 파이 3나 Zero 2 W는 서버 이미지.

개발 환경 자체를 어떤 OS로 할지 고민 중이라면 개발자 OS 선택: 우분투·macOS·윈도우를, 설치 후 첫 설정은 우분투 설치 후 개발자가 처음 할 일을 참고하세요.

LTS 업그레이드: 언제, 어떻게

.1 포인트 릴리스까지 기다리는 이유

새 LTS가 4월에 나와도 이전 LTS에서의 자동 업그레이드 안내는 첫 포인트 릴리스(.1) 이후에 열립니다. 2년 동안 바뀐 수천 개 패키지를 한 번에 올리는 작업이라, 실제 사용자 환경에서 발견되는 문제를 몇 달간 고친 뒤에 문을 여는 것입니다. 26.04의 경우 26.04.1이 8월 27일에 나왔고, rust-coreutils 관련 회귀 수정을 거쳐 24.04 사용자에게 업그레이드 안내가 나가기 시작한 것은 9월 초였습니다.

do-release-upgrade -d 옵션을 쓰면 이 기다림 없이 바로 올릴 수 있지만, 이 옵션은 원래 개발 버전으로 올리기 위한 것입니다. 업무에 쓰는 기계라면 .1 이후 정식 안내를 기다리는 것이 좋습니다. LTS가 나오자마자 업그레이드했다가 서드파티 드라이버나 PPA 패키지가 새 버전을 따라오지 못해 되돌리는 데 하루를 쓰는 일은 매 LTS 주기마다 반복되는 흔한 이야기입니다.

업그레이드 절차

sudo apt update && sudo apt full-upgrade   # 현재 버전을 먼저 최신 상태로
sudo reboot
sudo do-release-upgrade                     # 다음 LTS로 업그레이드

업그레이드 전에 확인할 것은 세 가지입니다.

1. 백업: 업그레이드가 중간에 실패하면 부팅이 안 되는 상태로 남을 수 있습니다. 홈 디렉터리와 /etc는 최소한 따로 백업해 둡니다.
2. 서드파티 저장소: 업그레이드 과정에서 PPA와 외부 저장소는 자동으로 비활성화됩니다. 업그레이드 후 새 버전의 코드네임을 지원하는지 확인하고 하나씩 다시 켜야 하는데, 26.04에서는 apt-key가 없어졌으므로 옛날 방식으로 등록한 저장소 키는 새 방식(/etc/apt/keyrings)으로 옮겨야 합니다.
3. 원격 서버라면 콘솔 접근 수단: SSH로 업그레이드하면 do-release-upgrade가 예비 SSH 데몬을 추가 포트(1022)로 띄워 주지만, 네트워크 설정이 깨지면 소용이 없습니다. 클라우드 콘솔이나 IPMI 같은 대체 접근 수단을 확보해 두고 시작합니다.

지원이 끝난 중간 릴리스를 계속 쓰면 생기는 일

25.10처럼 지원이 끝난 중간 릴리스는 일정 시간이 지나면 패키지 저장소가 old-releases.ubuntu.com으로 옮겨집니다. 그 이후에는 apt update를 하면 404 Not Found, The repository '...' does not have a Release file. 같은 에러가 나며 패키지를 설치할 수도, 업그레이드할 수도 없는 상태가 됩니다. 이 상태에서 다음 버전으로 가려면 /etc/apt/sources.list.d/의 저장소 주소를 old-releases.ubuntu.com으로 바꿔 현재 버전을 최신화한 뒤 do-release-upgrade를 실행해야 합니다. 중간 릴리스를 쓴다면 지원 종료 전에 다음 버전으로 올리는 일정을 달력에 적어 두는 것이 가장 확실한 예방책입니다.

마치며

우분투 버전을 고를 때 기억할 것은 세 가지입니다. 번호는 출시 연월이고 짝수 해 4월 버전이 LTS라는 것, LTS는 5년(Pro로 최대 15년) 지원되고 중간 릴리스는 9개월뿐이라는 것, 그리고 같은 버전이라도 데스크톱·서버·클라우드 에디션과 amd64·arm64 같은 아키텍처에 맞는 이미지를 골라야 한다는 것입니다.

2026년 9월 현재 새로 설치한다면 26.04 LTS가 기본 선택이고, 22.04를 쓰는 서버는 2027년 5월 이전에 올릴 계획을 세워 두는 것이 좋습니다. 버전별 세부 날짜는 바뀔 수 있으므로, 중요한 결정을 내리기 전에는 Canonical의 공식 릴리스 주기 페이지와 26.04 릴리스 노트를 한 번 더 확인하시기 바랍니다.