Fedora 서버 운영 시 13개월마다 업그레이드가 필요한 이유

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)를 의미하며, 패치 제공이 중단되는 날짜입니다. 오늘 설치할 릴리스에 대해 각 프로젝트가 발표한 내용은 다음과 같습니다.

[
  {
    "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 자체에 포함되어 있으므로 별도로 설치할 플러그인이 없습니다. 먼저 현재 릴리스를 완전히 업데이트한 상태에서 시작합니다.

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 reboot

dnf 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 서버가 업데이트 시기를 놓치면 어떻게 됩니까

당일에는 아무 일도 일어나지 않습니다. 문제는 패키지 관리자를 실행하는 다음 순간에 발생합니다. 수명이 다한(End of life) 릴리스는 미러 네트워크에서 아카이브로 이동하므로, 메타데이터를 가져오는 과정에서 dnf upgrade 명령이 실패하며 해당 릴리스의 metalink URL에서 404 오류가 발생합니다.

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 실행 시 해당 릴리스의 메탈링크(metalink) URL에서 404 오류가 발생합니다. 리포지토리 파일을 해당 아카이브로 다시 지정하여 단계적으로 업그레이드하거나, 지원되는 릴리스로 서버를 새로 구축할 수 있습니다. 이 두 가지 중 하나를 수행하기 전까지는 보안 업데이트를 받을 수 없으며 패키지 설치도 불가능합니다.

Fedora는 프로덕션 서버용으로 부적합한 선택입니까?

기본값으로 선택하기에는 부적합하지만, 명확한 이유가 있다면 합리적인 선택이 될 수 있습니다. 운영체제를 건드리고 싶지 않은 서버라 하더라도 매년 전체 운영체제 업그레이드를 수행해야 한다는 비용이 발생합니다. LTS(장기 지원) 버전보다 더 최신 커널이나 사용자 공간이 필요하거나, 설계상 서버의 수명이 짧은 경우 Fedora를 선택하십시오. 버전을 변경하지 않고 수년간 서버에 패치를 적용해야 한다면 LTS나 엔터프라이즈 리빌드 버전을 선택하십시오.