Ubuntu 서버 운영: LTS와 중간 릴리스 선택 가이드
Ubuntu LTS는 5년의 보안 업데이트를 제공하지만 중간 릴리스는 9개월 후 지원이 종료되어 강제 업그레이드가 필요합니다. 서버 환경에 적합한 릴리스를 선택하는 기준과 Ubuntu Pro를 통한 10년 지원 연장 방법을 상세히 설명합니다.
Ubuntu LTS와 중간 릴리스 비교: 요약
서버에서 Ubuntu LTS와 중간 릴리스 중 무엇을 선택할지는 보안 업데이트가 얼마나 오래 지속되는지에 달려 있습니다. LTS는 5년간 표준 보안 유지보수를 제공합니다. 반면 중간 릴리스는 9개월 후 업데이트가 중단되므로, 반드시 업그레이드하거나 서버를 재구축해야 합니다. 타인이 의존하는 서비스에는 LTS를 사용하십시오. 재구축이 누구의 허락도 없이 자유롭게 가능한 환경에서만 중간 릴리스를 사용하십시오.
LTS는 Long Term Support(장기 지원)를 의미합니다. Canonical은 2년마다 짝수 해 4월에 LTS를 하나씩 발표하며, 그 사이 6개월마다 중간 릴리스를 하나씩 발표합니다. 26.04 LTS는 2026년 4월 23일에 출시되었으며, 표준 보안 유지보수는 2031년까지 이어집니다. 26.10은 2026년 10월 15일 출시 예정인 중간 릴리스이므로, 지원 기간은 2027년 7월에 종료됩니다.
Ubuntu 각 릴리스의 지원 기간
The data behind this chart
[
{
"label": "LTS, standard support",
"support_months": 60,
"upgrades_over_5_years": 1
},
{
"label": "LTS with Ubuntu Pro",
"support_months": 120,
"upgrades_over_5_years": 0
},
{
"label": "Interim release",
"support_months": 9,
"upgrades_over_5_years": 10
}
]이 수치는 테스트 서버에서 측정한 값이 아니라 2026년 8월 기준 Canonical이 공식 발표한 정책입니다. LTS 버전은 60개월 동안 표준 보안 유지보수를 제공하며, 이는 5년 동안 1회의 계획된 릴리스 업그레이드를 수행하는 것과 같습니다. 중간(interim) 릴리스의 지원 기간은 9개월입니다. 5년 동안 중간 릴리스 트랙을 유지하려면 총 10회의 릴리스 업그레이드가 필요합니다. 릴리스를 건너뛸 수 없으며 5년 동안 10개의 릴리스가 배포되기 때문입니다.
Ubuntu Pro 구독을 이용하면 LTS의 지원 기간이 120개월(10년)로 늘어나며, 지원 범위도 main 구성 요소에서 전체 아카이브로 확대됩니다. 2026년 8월 기준으로 Pro는 개인 사용 시 최대 5대의 기기까지 무료로 제공되므로, 대부분의 소규모 VPS 환경을 커버할 수 있습니다. 중간 릴리스에는 이에 상응하는 구독 서비스가 없습니다. 9개월이 지원 기간의 전부이며, 어떤 구독으로도 이를 연장할 수 없습니다.
실제 서버에서 9개월의 비용
26.10을 예시로 들어보겠습니다. 이 버전은 2026년 10월 15일에 출시되며 보안 유지보수는 2027년 7월에 종료됩니다. 이는 25.10이 2026년 7월에 종료된 것과 동일한 9개월 주기입니다. 달력으로 보면 3분기마다 한 번씩 유지보수 기간이 돌아오는 것처럼 보입니다. 하지만 이러한 달력상의 해석은 틀렸으며, 비용 측면에서 더 불리하게 작용합니다.
마감 기한의 연쇄 작용
2026년 10월에 26.10을 설치하고 마지막 안전한 시점까지 기다린다고 가정해 봅시다. 26.10 지원이 종료되기 직전인 2027년 6월에 27.04로 업그레이드합니다. 하지만 27.04는 2027년 4월에 출시되었으며, 해당 버전의 9개월 지원은 2028년 1월에 종료됩니다. 즉, 두 번째 마감 기한은 첫 번째로부터 9개월이 아닌 7개월 뒤에 찾아옵니다.
2027년 12월에 다시 27.10으로 업그레이드합니다. 이 버전은 2027년 10월에 출시되어 2028년 7월에 종료됩니다. 이 시점부터는 패턴이 고정됩니다. 항상 최신 릴리스보다 한 단계 뒤처진 상태를 유지하게 되므로, 약 6개월마다 마감 기한이 돌아옵니다. 9개월은 단일 릴리스의 지원 기간일 뿐, 유지보수 작업 사이의 간격이 아닙니다.
릴리스 업그레이드는 운영체제를 현재 상태에서 교체하는 작업입니다. do-release-upgrade은 apt 소스 목록을 다시 작성하고, 서드 파티 저장소를 비활성화하며, 설치된 거의 모든 패키지의 버전을 변경합니다. 또한 사용자가 수정한 설정 파일에 대해 중단하고 질문을 던지며, 마지막에는 재부팅을 수행합니다. 이것이 바로 업그레이드를 백그라운드 작업이 아닌 계획된 유지보수 기간으로 진행해야 하는 이유입니다.
ssh를 통해 실행하면 도구는 연결 끊김으로부터 사용자를 보호합니다. 도구는 자체 screen 세션을 시작하고 두 번째 sshd를 엽니다. 이때 사용자에게 먼저 다음과 같이 알립니다:
To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.이 과정을 허용하십시오. 방화벽이나 제공업체의 별도 네트워크 방화벽이 1022 포트를 차단하면 이러한 대체 수단이 존재하지 않게 되며, 연결이 끊길 경우 패키지가 절반만 업그레이드된 상태로 남게 됩니다. tmux나 screen 내부에서 직접 실행하면 어떤 서버에서든 동일한 보호를 받을 수 있습니다.
설정 파일에 대한 질문은 15분짜리 업그레이드를 1시간짜리 작업으로 만드는 주범입니다:
Configuration file '/etc/ssh/sshd_config'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ?기존 파일을 유지하면 새로운 기본값에서 변경된 내용을 놓치게 됩니다. 관리자의 파일을 선택하면 다시 복구하기 전까지 적용해 둔 보안 강화 설정이 사라집니다. 해당 릴리스에서 무엇이 변경되었는지 모르는 상태에서는 어떤 선택도 안전하지 않습니다. 이것이 바로 릴리스 노트를 읽는 것이 선택 사항이 아닌 유지보수 작업의 일부인 이유입니다.
이제 이를 서버 대수만큼 곱해 보십시오. 중간 릴리스(interim track)를 사용하는 VPS 한 대는 5년 동안 10번의 업그레이드 기간을 의미합니다. VPS 5대라면 50번이 됩니다. 단, 모든 서버가 일회용이며 이미지로부터 재구축되는 경우는 예외입니다. LTS 트랙을 사용하는 서버 5대는 같은 기간 동안 5번의 업그레이드만 수행하면 되며, 각 업그레이드 시점도 직접 선택할 수 있습니다.
Ubuntu 릴리스를 건너뛸 수 없는 이유
업그레이드 경로는 고정되어 있습니다. 중간 릴리스는 다음 릴리스로만 업그레이드할 수 있습니다. LTS 릴리스는 다음 LTS로 직접 업그레이드하거나, 사용자가 요청하는 경우 다음 중간 릴리스로 업그레이드할 수 있습니다. 한 번에 두 단계를 건너뛰는 업그레이드는 불가능합니다. 26.10에서 28.04 LTS로 가려면 27.04와 27.10을 거치거나 시스템을 재설치해야 합니다.
이 메커니즘을 이해하는 것이 중요한 이유는 규칙이 예외 없이 적용되기 때문입니다. do-release-upgrade은 changelogs.ubuntu.com에서 메타 릴리스 파일을 가져온 뒤, 특정 전환을 위해 제작된 업그레이드 도구를 다운로드합니다. Canonical은 한 번에 하나의 전환 경로만 빌드하고 테스트하므로, 릴리스를 건너뛰는 방식은 지원하는 도구도 없고 테스트도 거치지 않았습니다. 업그레이드 도구가 거부하는 것은 단순히 신중해서가 아닙니다. 애초에 제공할 수 있는 경로 자체가 존재하지 않기 때문입니다.
어떤 릴리스를 제안받을지는 다음 설정 파일의 한 줄에 의해 결정됩니다.
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -cPrompt=lts는 다음 LTS 릴리스만 제안합니다. Prompt=normal은 LTS 여부와 관계없이 다음 릴리스를 제안합니다. Prompt=never는 아무것도 제안하지 않으며, 이는 계획에 없던 업그레이드를 동료가 임의로 시작하지 못하게 막는 방법입니다. LTS가 아닌 릴리스에서 lts는 normal과 동일하게 동작합니다. 26.10 다음 릴리스는 어떤 설정을 선택하든 27.04이기 때문입니다. 확인 과정에서 Checking for a new Ubuntu release이 출력된 뒤, New release ... available. 라인이 나타나거나 No new release found.가 출력됩니다.
일정 관련 규칙 중 하나가 사용자들을 혼란스럽게 하곤 합니다. LTS에서 LTS로의 업그레이드는 새로운 LTS가 출시되는 당일에는 제공되지 않습니다. 첫 번째 포인트 릴리스가 나와야 업그레이드가 열리며, 26.04.1은 2026년 8월 27일로 예정되어 있습니다. Prompt=lts 설정이 된 24.04 서버가 2026년 여름 내내 No new release found.라고 응답했다면, 이는 고장 난 것이 아니라 정책을 따르고 있었던 것입니다. 업그레이드 경로가 열리면 24.04에서 26.04 LTS로의 업그레이드를 계획하고 예행연습을 진행하십시오.
중간 릴리스(interim release)가 적절한 선택인 경우
다음 네 가지 상황에서는 중간 릴리스를 사용하는 것이 확실한 이점이 있습니다.
- LTS 아카이브에서 제공하지 않는 커널이나 사용자 공간(userspace) 버전이 현재 서버에 즉시 필요한 경우.
- 해당 장비가 빌드 호스트, CI 러너, 또는 이미지로 재구축하는 테스트용 서버여서, 업그레이드 대신 새로운 인스턴스를 생성하는 것이 더 효율적인 경우.
- LTS 버전이 고정된 이후에 출시된 하드웨어 기능이나 하이퍼바이저 기능을 사용해야 하며, 백포트(backport)가 존재하지 않는 경우.
- 다음 LTS 버전에 포함될 내용을 미리 확인하려는 경우. 28.04 버전은 26.10, 27.04, 27.10을 기반으로 구성되므로, 중요도가 낮은 VPS에서 미리 변경 사항을 확인하는 것이 운영 중인 서버에서 문제를 발견하는 것보다 비용이 적게 듭니다.
중간 릴리스를 선택하려는 대부분의 사용자는 운영체제 전체가 아닌 특정 패키지의 최신 버전을 원합니다. 이 경우 더 효율적인 두 가지 대안이 있습니다. 하드웨어 지원 스택(Hardware Enablement stack)을 사용하면 LTS 버전에서도 이후 릴리스의 커널을 사용할 수 있습니다. 24.04 버전의 경우 sudo apt install linux-generic-hwe-24.04를 통해 제공되며, 두 번째 포인트 릴리스부터는 각 릴리스마다 커널이 순차적으로 업데이트됩니다. 단일 애플리케이션의 경우라면 운영체제 전체를 바꾸는 대신 컨테이너 이미지나 해당 벤더의 공식 저장소를 사용하는 것이 좋습니다.
인터림 릴리스가 적합하지 않은 경우
- 유료 사용자가 있거나 온콜(on-call) 로테이션이 운영되는 환경. 사용하지도 않을 패키지 버전을 얻기 위해 1년에 두 번 강제 업그레이드를 수행해야 합니다.
- unattended-upgrades가 보안 패치를 자동으로 수행하는 서버. 자동화의 품질은 패치가 공급되는 보안 저장소의 상태에 의존합니다.
- 수동으로 업그레이드하는 서버 군. 실제 비용은 작업 시간 1회에 서버 대수를 곱한 만큼 발생합니다.
- 설치 후 1년 동안 관리하지 않는 서버. 잊고 지낸 인터림 릴리스 서버는 9개월 뒤 보안 패치가 중단된 인터넷 노출 서버가 됩니다.
마지막 사례는 조용히 발생하기 때문에 위험합니다. 릴리스의 수명이 다하면 패키지는 old-releases.ubuntu.com으로 이동하며, sudo apt update은 archive.ubuntu.com에 접근할 때 404 오류를 반환하기 시작합니다. 디스크의 패키지 목록은 갱신되지 않습니다. unattended-upgrades는 타이머에 따라 계속 실행되며 /var/log/unattended-upgrades/unattended-upgrades.log에 다음과 같은 줄을 기록합니다.
No packages found that can be upgraded unattended and no pending auto-removals이 줄은 완전히 패치된 서버와 릴리스가 4개월 전에 종료된 서버에서 동일하게 나타납니다. 누군가 apt 오류를 확인하거나 릴리스 종료 날짜를 추적하지 않는 한, 시스템 내부의 그 무엇도 현재 상태를 알려주지 않습니다.
중간 릴리스(interim track)에 먼저 적용되는 변경 사항
2026년 3월, Canonical의 한 엔지니어가 Ubuntu discourse를 통해 26.10 버전의 보안 부팅(secure boot)용으로 제공되는 서명된 GRUB 부트로더를 간소화하겠다는 제안을 했습니다. 이 제안은 btrfs, hfsplus, xfs, zfs용 파일 시스템 드라이버와 JPEG 및 PNG 이미지 파서, Apple 파티션 테이블, LVM 기반의 /boot, RAID 1을 제외한 소프트웨어 RAID, 그리고 LUKS로 암호화된 /boot에 대한 지원을 제거하는 내용을 담고 있습니다. 제안된 이유는 부트로더 내부의 파서가 보안 취약점의 반복적인 원인이 되며, 스토리지 및 암호화 로직은 커널이 실제 루트 파일 시스템을 마운트하기 전에 로드하는 작은 초기 RAM 파일 시스템인 initramfs에서 처리하는 것이 적절하기 때문입니다. 2026년 8월 기준으로 이는 논의 중인 제안일 뿐, 실제 릴리스에 적용된 변경 사항은 아닙니다.
대부분의 VPS 인스턴스는 GPT 파티션 테이블의 일반 ext4 /boot에서 보안 부팅 없이 부팅되므로, 이러한 변경이 적용되어도 아무런 영향이 없습니다. 하지만 막연히 추측하기보다는 직접 확인해야 합니다. 만약 루트 파일 시스템이 ZFS이거나, /boot가 btrfs 또는 LUKS 내부에 위치한다면, 이는 중간 릴리스에서 가장 먼저 마주하게 될 전형적인 변경 사항입니다. 해당 논의 스레드에서도 영향을 받는 사용자들에게 LTS 버전을 유지할 것을 권장하고 있으며, 이 조언이 모든 논의의 핵심입니다. 중간 릴리스는 변경 사항을 시험하는 곳입니다. LTS는 2년 동안의 중간 릴리스를 통해 무엇이 문제인지 확인된 후에야 변경 사항이 적용되는 버전입니다.
이러한 패턴은 모든 중간 릴리스에서 더 작은 규모로 나타납니다. 데이터베이스, 언어 런타임, init 설정의 기본 버전이 업데이트되므로 기존에 작동하던 설정 파일이 더 이상 작동하지 않을 수 있습니다. 기본값을 최신으로 유지하는 것은 중간 릴리스의 존재 목적이며, 이는 10번의 업그레이드마다 릴리스 노트를 읽는 것이 사용자가 지불하기로 동의한 대가의 일부임을 의미합니다.
서버 구축 시 트랙 선택하기
설치 시점에 트랙을 선택하십시오. 나중에 변경하려면 재설치하거나 일련의 업그레이드를 거쳐야 하기 때문입니다. 새 서버에서 다음 네 가지 명령어를 실행하면 현재 상태를 확인할 수 있습니다.
lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-statuslsb_release -a은 의도한 릴리스 이름을 출력해야 하며, LTS 버전인 경우 설명 줄이 LTS로 끝납니다. Prompt 줄은 공급자가 제공한 이미지의 기본값이 아니라 사용자가 선택한 트랙과 일치해야 합니다. 현재 LTS에서 do-release-upgrade -c을 실행하면 No new release found.가 출력되어야 합니다. 만약 중간 릴리스(interim release)가 제공된다면 Prompt가 normal으로 설정된 것이며, 이것이 의도된 것인지 확인해야 합니다. pro security-status은 설치된 패키지 중 어떤 업데이트 스트림이 적용되는지 보고하며, 서버가 구독에 연결되지 않은 경우 이를 명확히 알립니다.
그런 다음 해당 서버의 빌드 노트와 함께 기술 지원 종료(EOL) 날짜를 기록해 두십시오. 이 작업은 새 VPS 설정 후 첫 10분에 수행하는 다른 작업들과 함께 관리해야 합니다. 누군가의 기억에만 의존하는 지원 종료일은 예고 없이 지나치기 때문입니다. 6개월마다 반복되는 릴리스 주기를 완전히 피하고 싶다면, 시스템을 본격적으로 도입하기 전에 FreeBSD 릴리스 모델과 Linux 비교 문서를 한 시간 정도 읽어보는 것을 권장합니다.
FAQ
프로덕션 서버에서 Ubuntu 중간 릴리스(interim release)를 사용해야 합니까?
대부분의 경우 사용하지 않는 것이 좋습니다. 중간 릴리스는 출시 후 9개월이 지나면 보안 업데이트가 중단되므로, 프로덕션 환경에서 이를 사용하면 1년에 두 번씩 강제 업그레이드를 수행해야 합니다. CI 러너나 빌드 호스트처럼 이미지를 통해 주기적으로 재구축하는 장비는 예외입니다. 이런 환경에서는 업그레이드가 새로운 인스턴스를 생성하는 과정이 되기 때문입니다. 실제 사용자가 의존하는 서버라면 LTS 버전을 설치하고, 업그레이드에 소요될 시간을 다른 작업에 활용하십시오.
Ubuntu 중간 릴리스의 지원 기간은 얼마나 됩니까?
9개월입니다. 26.10은 2026년 10월 15일에 출시되어 2027년 7월에 보안 유지보수가 종료됩니다. 이는 25.10이 2026년 7월에 종료된 것과 동일한 방식입니다. 모든 중간 릴리스는 4월 또는 10월에 출시되어 9개월 뒤에 지원이 종료됩니다. LTS 버전은 5년의 표준 보안 유지보수를 제공하며, Ubuntu Pro를 통해 10년까지 연장할 수 있습니다. 2026년 8월 기준으로 Ubuntu Pro는 개인용으로 최대 5대까지 무료로 사용할 수 있습니다.
업그레이드 시 Ubuntu 릴리스를 건너뛸 수 있습니까?
아니요. do-release-upgrade은 한 번에 한 단계씩만 이동합니다. 중간 릴리스는 다음 릴리스로만 업그레이드할 수 있으며, LTS는 다음 LTS로 직접 이동할 수 있습니다. 26.10에서 28.04 LTS로 가려면 27.04와 27.10을 거쳐 업그레이드하거나 서버를 재설치해야 합니다. Canonical은 한 번에 하나의 전환 경로만 구축하고 테스트하며, 업그레이더는 해당 특정 점프를 위한 도구만 다운로드합니다. 따라서 두 단계를 한 번에 건너뛰는 도구는 존재하지 않으며 지원되지도 않습니다.
Ubuntu 릴리스의 지원이 종료되면 어떻게 됩니까?
패키지가 old-releases.ubuntu.com으로 이동하므로 sudo apt update는 archive.ubuntu.com에서 404 오류를 발생시키며, 해당 릴리스에 대한 새로운 보안 업데이트는 더 이상 제공되지 않습니다. 시스템은 이를 별도로 알리지 않습니다. 서버는 계속 실행되며 네트워크 트래픽을 처리하지만, 새로 발견되는 모든 취약점에 무방비로 노출됩니다. 이 경우 급하게 릴리스 업그레이드를 수행하거나 서버를 재구축해야 하므로, 증상이 나타나기 전에 지원 종료 날짜를 미리 확인하십시오.
LTS 커널이 최신 하드웨어를 지원하기에 너무 오래되었습니까?
보통 그렇지 않습니다. LTS 버전은 5년 동안 초기 커널을 그대로 유지하지 않기 때문입니다. HWE(Hardware Enablement) 스택은 포인트 릴리스를 통해 이후 릴리스의 커널을 LTS로 가져오며, 서버 설치 시 linux-generic-hwe-24.04과 같은 패키지를 통해 이를 선택할 수 있습니다. 커널이 문제라고 단정하기 전에 uname -r을 사용하여 현재 실행 중인 버전을 확인하십시오. 만약 커널이 아닌 사용자 공간(userspace) 버전이 문제라면, 전체 시스템을 중간 릴리스 트랙으로 옮기는 것보다 컨테이너나 벤더 저장소를 사용하는 것이 훨씬 작은 변경으로 문제를 해결하는 방법입니다.