작성자 Fedora 서버 운영 시 13개월마다 업그레이드가 필요한 이유
Fedora는 릴리스당 약 13개월의 보안 업데이트만 제공합니다. 서버 운영 시 매년 수행해야 하는 버전 업그레이드의 비용과 관리 부담을 분석하고, Fedora를 선택하기 전 고려해야 할 LTS 배포판과의 차이점을 상세히 설명합니다.
Fedora 릴리스의 보안 업데이트 지원 기간은 얼마나 됩니까?
Fedora 서버는 장비가 존재하는 한 약 1년에 한 번씩 버전 업그레이드가 필요합니다. Fedora는 대략 6개월마다 새로운 릴리스를 발표합니다. 각 릴리스는 두 버전 뒤의 릴리스가 나온 후 약 4주까지 지원되며, 이는 약 13개월의 업데이트 기간에 해당합니다. 해당 날짜가 지나면 릴리스에 대한 보안 수정 사항은 전혀 제공되지 않습니다. 서버는 계속 작동하지만, 패키지 세트는 더 이상 아무도 패치하지 않는 상태가 됩니다.
날짜를 보면 더 명확해집니다. 2026년 8월 기준으로 지원되는 릴리스는 Fedora 43과 Fedora 44입니다. Fedora 44는 2026년 4월 28일에 출시되었으며, 지원 종료일은 2027년 6월로 예정되어 있습니다. Fedora 42는 2025년 4월에 출시되었고 Fedora 44가 나온 지 4주 뒤인 2026년 5월에 지원이 종료되었습니다. 따라서 Fedora 42 이미지로 구축된 서버는 아무런 잘못을 하지 않았더라도 13개월 뒤에는 지원이 종료된 상태가 됩니다.
Fedora와 LTS 비교 (개월 단위)
LTS는 장기 지원(Long Term Support)을 의미하며, 벤더가 수개월이 아닌 수년간 패치를 제공하는 릴리스를 뜻합니다. EOL은 지원 종료(End of Life)를 의미하며, 패치 제공이 중단되는 날짜입니다. 오늘 설치할 릴리스에 대해 각 프로젝트가 발표한 내용은 다음과 같습니다.
The data behind this chart
[
{
"distro": "Fedora 44",
"support_window": 13,
"upgrades_per_decade": 10
},
{
"distro": "Ubuntu 26.04 LTS",
"support_window": 60,
"upgrades_per_decade": 2
},
{
"distro": "Debian 13 stable",
"support_window": 36,
"upgrades_per_decade": 3
},
{
"distro": "AlmaLinux 10",
"support_window": 120,
"upgrades_per_decade": 1
}
]Fedora는 릴리스당 13개월의 지원 기간을 제공합니다. Ubuntu LTS는 60개월을, AlmaLinux와 같은 엔터프라이즈 리빌드 버전은 120개월을 제공합니다. 두 번째 열은 관리 비용으로 이해하십시오. 10년 동안 Fedora는 운영체제 전체 업그레이드를 대략 10회 요구하는 반면, Ubuntu LTS는 2회 요구합니다. Debian의 36개월이라는 수치는 일반적인 보안 지원 기간이며, 별도의 LTS 팀이 대부분의 릴리스를 약 5년까지 연장합니다.
이 수치들은 2026년 8월 기준으로 확인된 공식 지원 기간이며, 측정된 가동 시간이 아닙니다. 주기가 다른 이유는 Ubuntu LTS와 서버용 중간 릴리스의 차이에서 다룹니다. 여기서 중요한 것은 각 운영체제가 사용자에게 요구하는 작업량입니다.
Fedora 버전 업그레이드의 실제 과정
Fedora 41부터 DNF 5가 기본 패키지 관리자로 채택되었으며, dnf이 이를 실행합니다. system-upgrade 명령어는 dnf5 자체에 포함되어 있으므로 별도로 설치할 플러그인이 없습니다. Debian이나 Ubuntu 환경에서 넘어왔다면, 평소 사용하는 명령어 대부분은 apt와 대응되는 dnf 명령어가 존재하지만, 아래의 버전 업그레이드는 직접적인 대응 명령어가 없는 몇 안 되는 작업 중 하나입니다. 먼저 현재 릴리스를 완전히 업데이트합니다.
sudo dnf upgrade --refresh
sudo reboot재부팅이 중요한 이유는 업그레이드가 현재 설치되어 실행 중인 상태를 기준으로 의존성을 해결하기 때문입니다. 커널이나 glibc 업데이트가 완전히 적용되지 않은 상태라면 다음 단계를 예측하기 어렵습니다. 이제 새 릴리스를 준비합니다. 44를 이동하려는 릴리스 버전으로 변경하십시오.
sudo dnf system-upgrade download --releasever=44이 과정은 전체 트랜잭션을 해결하고 모든 패키지를 다운로드하지만, 실행 중인 시스템에는 아무런 변경을 가하지 않습니다. 소규모 서버 기준으로 수천 개의 패키지와 1~3GB 정도의 용량이 필요합니다. 만약 dnf가 트랜잭션을 해결하지 못하면 여기서 중단되고 차단 원인이 된 패키지를 알려줍니다. 이는 시스템이 여전히 작동 중이고 셸에 접근할 수 있는 상태에서 실패가 발생하므로 다행인 경우입니다.
그다음 실행합니다.
sudo dnf offline status
sudo dnf system-upgrade rebootdnf offline status은 트랜잭션이 준비되어 대기 중임을 확인합니다. dnf system-upgrade reboot는 오프라인 트랜잭션 모드로 시스템을 재시작합니다. 이는 RPM 트랜잭션이 독립적으로 실행되는 최소한의 부팅 환경입니다. 실행 중인 서비스 하위에서 glibc나 systemd를 교체하면 시스템이 반쯤 설치된 상태가 될 수 있기 때문에 이러한 방식을 사용합니다. 트랜잭션이 진행되는 동안 서버에는 접속할 수 없으며, 소규모 VPS에서는 보통 수 분이 소요됩니다. 이후 새 릴리스로 다시 재부팅됩니다. 두 번의 재부팅과 SSH 접속이 불가능한 시간을 계획에 포함하십시오.
시스템이 돌아오면 다음을 수행합니다.
cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras/etc/fedora-release는 Fedora release 44 (Forty Four)과 같은 줄을 출력해야 합니다. log 하위 명령어는 셸이 없던 오프라인 부팅 당시의 트랜잭션 로그를 출력하며, 이는 당시 무슨 일이 일어났는지 확인할 수 있는 유일한 기록입니다. distro-sync은 새 릴리스 버전으로 업데이트되지 않고 남은 패키지들을 정리합니다. repoquery --extras는 더 이상 활성화된 저장소에 존재하지 않는 설치된 패키지 목록을 보여주며, 여기서 새 릴리스용으로 배포되지 않은 저장소의 잔여물을 찾을 수 있습니다.
다운로드 단계 이전에 디스크 스냅샷을 생성하십시오. 트랜잭션은 화면을 볼 수 없는 상태에서 실행되므로, 오프라인 부팅 중 실패하면 SSH 접속이 불가능해집니다. 이때 유일한 접속 방법은 VNC나 시리얼 콘솔 등 제공자가 제공하는 콘솔뿐입니다. 시작하기 전에 콘솔 접근 권한이나 스냅샷이 있는지 반드시 확인하십시오.
사람들이 자주 놓치는 마지막 확인 사항입니다.
sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'패키지가 새로운 기본 설정 파일을 배포할 때 사용자가 기존 파일을 수정했다면, RPM은 기존 파일을 덮어쓰지 않습니다. 대신 패키지에 포함된 버전을 .rpmnew 확장자로 저장합니다. 따라서 sshd나 nginx는 이전 릴리스와 동일하게 동작하며, 새로운 기본 설정은 디스크에 읽히지 않은 채로 남게 됩니다. 업그레이드 후에는 항상 이 파일들을 확인하십시오. rpmconf을 설치하고 sudo rpmconf -a를 실행하면 파일들을 하나씩 검토하며 차이점을 확인할 수 있습니다.
서드파티 저장소가 업그레이드를 방해하는 주원인입니다
Fedora 공식 패키지들은 릴리스 당일에 모두 함께 업데이트됩니다. 하지만 Fedora 외부에서 제공하는 패키지들은 각 공급업체의 일정에 따라 움직입니다. 대부분의 공급업체 저장소는 URL에 $releasever을 포함하므로, 업그레이드를 수행하는 즉시 dnf는 아직 존재하지 않을 수 있는 경로를 요청하기 시작합니다.
현재 설정된 저장소 목록을 확인하십시오:
sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/Fedora 공식 저장소가 아닌 모든 저장소에 대해, 업그레이드를 진행하기 전에 대상 릴리스에서 정상적으로 작동하는지 테스트하십시오:
sudo dnf --releasever=44 --repo=docker-ce-stable makecache공급업체가 해당 릴리스용 패키지를 배포했다면 dnf는 메타데이터를 다운로드하고 조용히 종료됩니다. 그렇지 않다면 https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml와 같은 경로에서 404 오류가 발생하며, 동일한 실패로 인해 나중에 system-upgrade download가 중단됩니다. Fedora 릴리스 직후 몇 주 동안은 이것이 업그레이드가 시작되지 않는 가장 흔한 이유입니다.
두 가지 해결책이 있습니다. 공급업체가 배포할 때까지 몇 주 기다리는 것이 보통 올바른 선택입니다. 아니면 해당 저장소를 제외하고 업그레이드하십시오:
sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable저장소를 비활성화한다고 해서 해당 패키지들이 삭제되지는 않습니다. 패키지는 설치된 상태로 관리되지 않으며, 만약 이 패키지들이 트랜잭션을 방해한다면 dnf가 이를 알립니다. --allowerasing을 추가하면 dnf가 충돌을 해결하기 위해 설치된 패키지를 제거할 수 있게 되므로, 승인하기 전에 제거 목록을 반드시 읽어보십시오. 이 목록을 제대로 확인하지 않으면 유지하려던 데이터베이스 서버가 삭제될 수 있습니다.
Fedora 서버가 지원 기간을 놓치면 어떻게 됩니까
당일에는 아무 일도 일어나지 않습니다. 문제는 패키지 관리자를 다음에 실행할 때 발생합니다. 수명이 종료된 릴리스는 미러 네트워크에서 아카이브로 이동하므로, 해당 릴리스의 metalink URL에서 404 오류가 발생하여 dnf upgrade 명령이 메타데이터를 가져오는 데 실패합니다.
Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64서버는 계속 트래픽을 처리하며, 바로 이 점이 이 상황을 조용하고 위험하게 만듭니다. 보안 업데이트는 전혀 제공되지 않습니다. 또한 패키지 설치도 불가능하므로, OpenSSH나 nginx에 대한 보안 권고가 발표되어도 패치를 적용할 공식적인 방법이 없습니다.
상황을 해결하는 것은 가능하지만 시간이 오래 걸립니다. 저장소 주소를 https://dl.fedoraproject.org/pub/archive/fedora/linux/에 있는 Fedora 아카이브로 변경한 뒤 업그레이드를 진행할 수 있습니다. Fedora는 한 번에 한두 단계의 릴리스만 건너뛰는 업그레이드를 권장하므로, 4단계 이상 뒤처진 서버라면 여러 번의 업그레이드를 연속으로 수행해야 합니다. 이 과정에서 실패할 가능성이 있으며, 각 단계마다 오프라인 부팅 상태로 작업을 진행해야 합니다. VPS를 사용 중이라면 최신 이미지로 서버를 재구축하고 데이터를 옮기는 것이 보통 더 빠르고 안전하며, 이는 새로운 VPS의 초기 10분 작업과 동일한 수준의 노력이 필요합니다.
자동 업데이트는 릴리스를 패치합니다. 릴리스를 업그레이드하지는 않습니다.
Fedora는 타이머를 사용하여 업데이트를 설치할 수 있습니다.
sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer설정은 /etc/dnf/automatic.conf에 저장되며, 이는 /usr/share/dnf5/dnf5-plugins/automatic.conf에 제공된 기본값을 재정의합니다. apply_updates은 기본적으로 꺼져 있으므로, 초기 상태의 타이머는 업데이트를 다운로드하기만 하고 아무것도 설치하지 않습니다. upgrade_type는 default과 security 중 하나를 선택합니다. reboot는 never, when-changed 또는 when-needed을 허용합니다.
이 방식은 현재 릴리스 내에서 최신 상태를 유지하게 합니다. Fedora 43에서 Fedora 44로 이동하지는 않는데, 버전 업그레이드는 오프라인 트랜잭션으로 재부팅해야 하는 별도의 신중한 작업이기 때문입니다. 이것이 LTS와 비교되는 실질적인 차이입니다. Ubuntu의 경우 무인 보안 업그레이드는 버전 변경 없이 5년의 전체 기간 동안 시스템을 유지하며, 버전 변경 자체는 24.04에서 26.04로의 업그레이드와 같이 몇 년에 한 번 계획된 작업으로 수행됩니다.
Fedora가 서버 운영에 적합한 경우
최신성이 가장 중요한 요소라면 Fedora는 좋은 선택입니다.
- LTS 버전이 제공하는 것보다 더 최신 커널이나 사용자 공간(userspace)이 필요한 경우입니다. 최신 하드웨어를 사용하거나, 엔터프라이즈 릴리스까지는 아직 1년 정도 남은 컨테이너 및 systemd 스택이 필요한 상황이 이에 해당합니다. Fedora는 릴리스 기간 중에도 최신 업스트림 커널로 업데이트되므로, 설치 시점에만 이득을 보는 것이 아닙니다.
- RHEL(Red Hat Enterprise Linux)에 도입될 기술을 검증하는 경우입니다. Fedora는 CentOS Stream에 반영되고, 이는 다시 RHEL로 이어집니다. 따라서 오늘날 Fedora에서 빌드되고 실행되는 소프트웨어는 수년 뒤의 엔터프라이즈 플랫폼을 미리 테스트하는 셈입니다.
- 서버의 수명이 짧게 설계된 경우입니다. 2개월 뒤에 폐기될 빌드 러너나 테스트용 서버는 지원 종료(EOL) 날짜를 걱정할 필요가 없습니다. 같은 논리로 코딩 에이전트에게 제공하는 일회용 VM도 해당합니다. 이런 서버는 Fedora 릴리스 주기보다 훨씬 더 자주 재구축됩니다.
- 업그레이드를 책임질 담당자가 있는 경우입니다. Fedora는 담당자가 지정되어 있고 관리 일정이 잡혀 있는 서버에서는 훌륭하게 작동합니다. 하지만 모두가 잊어버린 서버에는 적합하지 않습니다.
중도 노선: 안정적인 기반 위에서 최신 패키지 사용하기
서버에 Fedora를 설치하려는 대부분의 사용자는 운영체제 전체가 최신 버전이기를 원하기보다 특정 패키지 2~3개가 최신 버전이기를 원합니다. 이 두 가지는 분리할 수 있습니다. LTS 배포판이나 기업용 리빌드 버전을 기반으로 운영하고, 필요한 부분에만 최신 소프트웨어를 가져오는 방식입니다. 컨테이너 이미지를 사용하면 호스트를 업그레이드할 필요 없이 애플리케이션의 최신 버전을 실행할 수 있습니다(VPS에서 Docker 실행하기). PostgreSQL이나 nginx처럼 특정 패키지만 최신 버전이 필요하다면, 해당 벤더의 저장소를 추가하여 기반 시스템은 그대로 둔 채 해당 패키지만 업데이트하면 됩니다.
이 방식은 양방향으로 장단점이 명확합니다. 컨테이너는 호스트의 구형 커널 위에서 새로운 사용자 공간을 제공하므로, 커널 업데이트가 필요한 경우에는 도움이 되지 않습니다. 벤더 저장소는 기반 시스템보다 벤더가 덜 검증한 최신 패키지를 제공합니다. 두 방식 모두 기반 시스템의 보안 업데이트는 LTS 주기를 따르게 되며, Fedora를 사용할 때 매년 유지보수 시간을 할애해야 하는 부담을 덜어줍니다.
만약 서버용으로 Fedora를 선택했다면, 업그레이드 주기를 달력에 기록해 두어야 합니다. 새 버전이 출시되면 벤더 저장소가 업데이트될 때까지 몇 주 정도 기다린 후, 스냅샷을 생성하고 업그레이드를 진행한 다음 서비스가 정상적으로 복구되었는지 확인하십시오. 이러한 주기적인 관리는 연간 약 1시간 정도의 시간만 투자하면 되며 매우 효과적입니다. 업그레이드에 실패하는 경우는 대개 문제가 발생한 뒤에야 업그레이드를 기억해내는 상황에서 발생합니다.
FAQ
Fedora 릴리스는 얼마나 오랫동안 지원됩니까?
약 13개월입니다. Fedora는 대략 6개월마다 새 릴리스를 발표하며, 각 릴리스는 두 버전 뒤의 릴리스가 나온 후 약 4주까지 지원됩니다. Fedora 44는 2026년 4월 28일에 출시되었으며 2027년 6월에 지원이 종료될 예정입니다. 해당 날짜가 지나면 해당 릴리스는 보안 업데이트를 더 이상 받지 않으며, 패키지는 미러 서버에서 Fedora 아카이브로 이동합니다.
Fedora 릴리스를 건너뛰고 두 버전을 한 번에 업그레이드할 수 있습니까?
네, 제한적으로 가능합니다. dnf system-upgrade download --releasever=는 현재 버전보다 한두 단계 앞선 릴리스를 대상으로 업그레이드를 수행하며, 두 버전씩 건너뛰는 방식은 1년에 한 번 업그레이드하는 일반적인 주기와 같습니다. 그 이상을 건너뛰는 것은 지원되지 않는 경로이며, 릴리스를 많이 건너뛸수록 패키지 이름 변경이나 설정 형식 변경으로 인해 트랜잭션이 중단될 가능성이 커집니다. 이미 여러 릴리스가 뒤처져 지원 기간이 종료된 상태라면, 업그레이드를 반복하는 것보다 최신 이미지로 서버를 재구축하는 것이 보통 더 빠릅니다.
Fedora 서버의 지원 기간이 종료되면 어떻게 됩니까?
서버는 계속 작동하지만 패치 제공이 중단됩니다. 지원이 종료된 릴리스는 dl.fedoraproject.org의 아카이브로 이동하므로, 다음 dnf upgrade 실행 시 해당 릴리스의 메타링크 URL에서 404 오류가 발생합니다. 리포지토리 파일을 해당 아카이브 주소로 변경하여 단계적으로 업그레이드하거나, 지원되는 릴리스로 서버를 재구축해야 합니다. 이 두 가지 조치를 취하기 전까지는 보안 업데이트를 받을 수 없으며 패키지 설치도 불가능합니다.
Fedora는 운영 서버용으로 부적합한 선택입니까?
기본값으로 선택하기에는 부적합하지만, 명확한 이유가 있다면 합리적인 선택이 될 수 있습니다. 운영 비용은 1년마다 전체 운영 체제를 업그레이드해야 한다는 점이며, 이는 건드리고 싶지 않은 서버를 계속 관리해야 함을 의미합니다. LTS 버전보다 최신 커널이나 사용자 공간이 필요하거나, 서버의 수명이 짧게 설계된 경우 Fedora를 선택하십시오. 버전을 변경하지 않고 수년간 서버에 패치를 적용해야 한다면 LTS나 엔터프라이즈 리빌드 버전을 선택하는 것이 좋습니다.