Ubuntu LTS vs 중간 릴리스 서버 선택 가이드

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 릴리스의 지원 기간

[
  {
    "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월에 종료됩니다. 이는 2026년 7월에 종료된 25.10 버전과 동일한 9개월 주기입니다. 달력상으로 보면 3분기마다 한 번씩 유지보수를 수행하는 것처럼 보입니다. 하지만 이러한 달력상의 해석은 잘못되었으며, 비용 측면에서 더 불리한 방향으로 오해를 불러일으킵니다.

릴리스 업그레이드는 운영체제를 현재 상태에서 교체하는 작업입니다. 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에서 meta-release 파일을 가져온 뒤, 특정 전환을 위해 빌드된 업그레이드 도구를 다운로드합니다. Canonical은 한 번에 하나의 전환 경로만 빌드하고 테스트하므로, 릴리스를 건너뛰는 점프는 도구도 없고 테스트도 거치지 않았습니다. 업그레이드 도구가 거부하는 것은 신중함 때문이 아닙니다. 제공할 수 있는 경로 자체가 존재하지 않기 때문입니다.

어떤 릴리스를 제안받을지는 다음 설정 파일의 한 줄에 의해 결정됩니다.

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=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일로 예정되어 있습니다. 포인트 릴리스는 새로운 버전의 Ubuntu가 아니라 4개월간 누적된 수정 사항이 포함된 동일한 릴리스의 새 설치 미디어이며, 이 대기 기간은 업그레이드 경로가 4개월간의 테스트를 거치도록 하기 위함입니다. 2026년 여름 동안 Prompt=lts 설정으로 No new release found.을 응답받던 24.04 서버는 고장 난 것이 아닙니다. 정책을 따르고 있었을 뿐입니다. 경로가 열리면 24.04에서 26.04 LTS로의 업그레이드를 계획하고 연습해야 합니다.

인터림 릴리스가 적절한 선택인 경우

다음 네 가지 상황에서는 인터림 릴리스를 사용하는 것이 확실한 이점이 있습니다.

• LTS 아카이브에는 없지만 현재 서버에서 즉시 사용해야 하는 커널이나 유저스페이스 버전이 필요한 경우.
• 해당 장비가 빌드 호스트, CI 러너, 또는 테스트 박스여서 이미지로부터 새로 구축하는 경우(이때 업그레이드는 유지보수 기간을 갖는 대신 새로운 인스턴스를 생성하는 과정이 됩니다).
• LTS가 고정된 이후에 출시된 하드웨어 기능이나 하이퍼바이저 기능을 사용해야 하는데 백포트가 존재하지 않는 경우.
• 다음 LTS에 포함될 내용을 미리 확인하려는 경우. 28.04는 26.10, 27.04, 27.10을 기반으로 구성되므로, 중요 장비에서 문제를 발견하는 것보다 여분의 VPS에서 호환성 문제를 확인하는 것이 비용 측면에서 훨씬 유리합니다.

인터림 릴리스를 찾는 대부분의 사용자는 운영체제 전체가 아닌 특정 패키지의 최신 버전을 원합니다. 이럴 때는 더 효율적인 두 가지 대안이 있습니다. 하드웨어 지원 스택(HWE)을 사용하면 LTS에서도 이후 릴리스의 커널을 사용할 수 있습니다. 24.04의 경우 sudo apt install linux-generic-hwe-24.04를 통해 제공되며, 두 번째 포인트 릴리스부터 순차적으로 업데이트됩니다. 단일 애플리케이션의 경우, 컨테이너 이미지나 벤더가 직접 제공하는 저장소를 이용하면 운영체제 전체를 변경하지 않고도 필요한 구성 요소만 업데이트할 수 있습니다.

중간 릴리스가 적절하지 않은 경우

• 유료 사용자가 있거나 온콜(on-call) 로테이션이 운영되는 환경입니다. 사용하지도 않을 패키지 버전을 얻기 위해 1년에 두 번씩 강제 업그레이드를 수행해야 합니다.
• unattended-upgrades가 보안 패치를 자동으로 수행하는 서버입니다. 해당 자동화 도구는 패치를 가져오는 보안 저장소의 상태만큼만 유효합니다.
• 수동으로 업그레이드하는 서버군입니다. 실제 비용은 한 대의 작업 시간에 서버 대수를 곱한 만큼 발생하기 때문입니다.
• 설치 후 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 오류를 확인하거나 릴리스 종료 날짜를 추적하지 않는 한, 시스템상에서는 현재 어떤 상태인지 알 수 있는 방법이 없습니다.

인터림 트랙에 먼저 적용되는 변경 사항

2026년 3월, Canonical의 한 엔지니어는 Ubuntu 포럼을 통해 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-status

lsb_release -a 명령어는 설치하려는 릴리스 이름을 출력해야 하며, LTS 버전의 경우 설명 줄이 LTS로 끝납니다. Prompt 줄은 공급자가 제공한 이미지의 기본값이 아니라 사용자가 선택한 트랙과 일치해야 합니다. 현재 LTS 버전에서 do-release-upgrade -c을 실행하면 No new release found.라는 응답이 나와야 합니다. 만약 중간 릴리스(interim release)를 제안한다면 Prompt가 normal으로 설정된 것이며, 이것이 의도된 것인지 확인해야 합니다. pro security-status은 설치된 패키지 중 어떤 업데이트 스트림이 적용되는지 보고하며, 시스템이 구독에 연결되지 않은 경우 이를 명확히 알립니다.

그런 다음 해당 서버의 나머지 빌드 노트와 함께 다시 확인할 수 있도록 지원 종료(end of life) 날짜를 기록해 두십시오. 이 작업은 새 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) 버전이 문제라면, 전체 시스템을 중간 릴리스 트랙으로 옮기는 것보다 컨테이너나 벤더 저장소를 사용하는 것이 훨씬 작은 변경으로 문제를 해결하는 방법입니다.