apt 명령어 dnf 대응 정리: Rocky Linux 및 Fedora

간단한 답변

apt에서 dnf로 전환하는 것은 대부분 용어의 변화입니다. apt install nginx은 dnf install nginx가 됩니다. apt remove nginx는 dnf remove nginx이 됩니다. apt update은 직접 대응하는 명령어가 없습니다. dnf는 캐시된 메타데이터가 오래되면 자동으로 저장소 메타데이터를 갱신하기 때문입니다. 전환의 쉬운 절반은 한 화면으로 정리됩니다. 유용한 절반은 전혀 대응되지 않는 네 가지 작업, 즉 저장소 추가, 트랜잭션 취소, 패키지 그룹 설치, 자동 업데이트 실행입니다.

아래의 모든 명령어는 사용자의 서버에서 직접 실행할 수 있도록 작성되었습니다. y에 응답하기 전에 dnf가 출력하는 트랜잭션 요약을 읽어보십시오. 특히 패키지를 삭제할 때는 더욱 주의해야 합니다.

어떤 배포판이 dnf를 사용하고, 어떤 배포판이 apt를 사용하는가

dnf는 Fedora, Red Hat Enterprise Linux (RHEL) 및 RHEL의 리빌드 버전인 Rocky Linux, AlmaLinux, CentOS Stream에서 사용하는 패키지 관리자입니다. apt는 Debian 및 Debian에서 파생된 모든 운영체제(VPS 환경에서는 거의 항상 Ubuntu를 의미함)에서 사용하는 패키지 관리자입니다. 이 외의 다른 답변은 없습니다. 제공업체의 이미지 목록에서 Rocky Linux나 AlmaLinux를 선택하면 dnf를 사용하게 되며, Ubuntu를 선택하면 apt를 사용하게 됩니다.

패키지 형식은 사용하는 도구에 따라 결정됩니다. dnf는 .rpm 파일을 설치하며 데이터베이스는 rpm입니다. apt는 .deb 파일을 설치하며 데이터베이스는 dpkg입니다. 이것이 많은 소프트웨어 공급업체의 설치 페이지에 각 계열별로 탭이 나뉘어 있는 이유이며, 프로젝트 릴리스 페이지에서 다운로드한 .deb이 Rocky Linux에서 무용지물인 이유입니다.

어떤 계열을 선택하든 첫 로그인 후 수행하는 작업은 동일합니다. 새 VPS에서의 첫 10분 가이드는 두 경우 모두에 적용됩니다. 오직 설치 명령어만 달라질 뿐입니다.

모든 apt 명령어와 그에 대응하는 dnf 명령어

설치, 삭제, 검색 및 정보 확인입니다. 양쪽 모두 거의 동일한 단어를 사용합니다.

# apt
sudo apt install nginx
sudo apt remove nginx
apt search nginx
apt show nginx

# dnf
sudo dnf install nginx
sudo dnf remove nginx
dnf search nginx
dnf info nginx

apt show는 dnf info와 같습니다. 이 그룹에서 유일하게 이름이 바뀐 동사이지만, 동작 방식에 차이가 있어 주의가 필요합니다. dnf remove은 다른 곳에서 필요로 하지 않는 의존성 패키지도 함께 삭제하지만, apt remove은 나중에 apt autoremove을 수행할 때를 대비해 그대로 남겨둡니다. 따라서 Rocky Linux에서 작은 유틸리티 하나를 삭제하려 할 때 수십 개의 라이브러리가 함께 삭제될 수 있습니다. 확인 메시지가 나오면 목록을 반드시 읽어보십시오.

메타데이터 갱신, 대기 중인 업데이트 확인 및 업그레이드입니다.

# apt
sudo apt update
apt list --upgradable
sudo apt install --only-upgrade nginx
sudo apt upgrade

# dnf
sudo dnf makecache
dnf check-update
sudo dnf upgrade nginx
sudo dnf upgrade

apt update는 apt에서 필수입니다. apt는 디스크에 있는 메타데이터를 그대로 사용하므로 몇 달 전 버전의 패키지를 설치할 위험이 있기 때문입니다. dnf는 모든 트랜잭션 이전에 캐시의 유효 기간을 확인하고 스스로 최신 메타데이터를 다운로드하므로, sudo dnf makecache은 다음 설치 작업까지 기다리지 않고 지금 즉시 다운로드를 강제할 때만 사용합니다.

apt는 시스템 전체 업그레이드를 두 단계로 나누지만, dnf는 그렇지 않습니다. apt upgrade은 설치된 패키지를 삭제하지 않으므로, 업데이트 과정에서 패키지 삭제가 필요하면 작업을 중단합니다. apt full-upgrade는 삭제를 허용하는 버전입니다. dnf에는 이러한 제한이 없으며, 이는 dnf upgrade이 apt upgrade가 아닌 apt full-upgrade와 동일한 역할을 함을 의미합니다. dnf update은 같은 명령어를 가리키는 이전 별칭이며 여전히 작동합니다.

스크립트를 작성할 때 중요한 세부 사항이 있습니다. dnf check-update은 업데이트가 대기 중일 때 상태 코드 100을 반환하고, 없을 때는 0을 반환합니다. apt list --upgradable은 상황과 관계없이 항상 0을 반환하므로, 스크립트에서 출력 내용을 파싱해야 합니다.

설치된 패키지 목록 확인 및 특정 파일의 소유 패키지 찾기입니다.

# apt
dpkg -l
dpkg -S /usr/sbin/nginx
dpkg -L nginx
apt-file search /usr/sbin/nginx

# dnf
dnf list --installed
rpm -qf /usr/sbin/nginx
rpm -ql nginx
dnf provides /usr/sbin/nginx

각 블록의 마지막 줄은 위와 다른 질문에 답합니다. dpkg -S와 rpm -qf은 이미 설치된 패키지 내에서만 검색하므로 "이 파일을 설치한 패키지가 무엇인가"라는 질문에 답합니다. apt-file search과 dnf provides는 저장소를 검색하므로 "이 파일을 얻으려면 어떤 패키지를 설치해야 하는가"라는 질문에 답합니다. apt-file은 Ubuntu에서 별도의 패키지로 제공되므로 처음 사용하기 전에 sudo apt-file update가 필요합니다. dnf provides는 별도의 추가 작업이 필요 없지만, dnf가 저장소 파일 목록을 다운로드하여 응답해야 하므로 첫 실행은 느릴 수 있습니다.

아직 설치하지 않은 패키지 내부의 파일 목록을 보려면 dnf repoquery -l nginx을 사용하십시오. apt에서는 apt-file list nginx을 사용합니다.

자동 삭제, 캐시 정리 및 버전 고정입니다.

# apt
sudo apt autoremove
sudo apt clean
sudo apt-mark hold nginx
apt-mark showhold
sudo apt-mark unhold nginx

# dnf
sudo dnf autoremove
sudo dnf clean all
sudo dnf versionlock add nginx
dnf versionlock list
sudo dnf versionlock delete nginx

versionlock은 Rocky Linux나 AlmaLinux에 기본으로 설치되어 있지 않으므로, 새로 설치한 시스템에서 첫 번째 줄을 실행하면 No such command: versionlock 오류가 발생합니다. 먼저 sudo dnf install python3-dnf-plugin-versionlock으로 설치하십시오. apt는 apt-mark hold을 위해 별도의 추가 작업이 필요하지 않습니다. 버전 고정(hold)은 플러그인이 아니라 dpkg 상태의 일부이기 때문입니다.

매핑이 어긋나는 지점: 저장소 추가

이 부분은 Ubuntu 관리자들이 존재하지 않는 명령어를 찾아 헤매게 만드는 구간입니다. dnf에는 add-apt-repository가 없으며, 개인 패키지 저장소(PPA)라는 개념도 존재하지 않습니다. PPA는 Launchpad에서 운영하는 서비스이며, Launchpad는 Ubuntu 인프라의 일부이기 때문입니다. RPM 생태계에는 PPA를 호스팅하는 서비스가 없습니다.

대신 dnf는 /etc/yum.repos.d/ 디렉터리 내에 저장소당 하나의 일반 텍스트 파일을 사용하며, 파일 확장자는 .repo입니다.

[docker-ce-stable]
name=Docker CE Stable
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

$releasever와 $basearch은 dnf 변수입니다. dnf는 런타임에 메이저 릴리스 번호와 CPU 아키텍처를 자동으로 채워 넣으므로, 동일한 파일을 버전 9와 버전 10, 또는 x86_64와 aarch64 환경에서 모두 사용할 수 있습니다.

대부분의 벤더는 해당 파일을 공개하고 이를 내려받도록 안내합니다. RHEL 및 그 파생 배포판을 위한 Docker 공식 설치 지침은 다음 두 명령어로 구성됩니다.

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

첫 번째 줄이 필요한 이유는 config-manager이 dnf 자체의 일부가 아닌 플러그인이기 때문입니다. 이 단계를 건너뛰면 두 번째 줄은 No such command: config-manager 오류와 함께 실패합니다. curl을 사용하여 동일한 .repo 파일을 직접 /etc/yum.repos.d/ 경로로 내려받아도 결과는 동일합니다. VPS에 Docker 설치하기 문서는 Debian 계열에서의 동일한 작업을 다루고 있는데, 해당 과정에서는 소스 리스트와 서명 키를 서로 다른 두 디렉터리에 작성합니다.

이러한 구조적 차이는 저장소에 문제가 발생했을 때 어디를 확인해야 할지 결정합니다. apt는 저장소 정의를 /etc/apt/sources.list와 /etc/apt/sources.list.d/에 보관하며, 서명 키는 /etc/apt/keyrings/에 별도로 저장합니다. 반면 dnf는 모든 것을 /etc/yum.repos.d/에 보관하며, 키 정보는 .repo 파일 내부의 URL로 명시되어 있습니다. 따라서 읽어야 할 파일과 삭제해야 할 파일이 각각 하나씩으로 명확합니다. 최신 apt는 deb822 형식을 도입하여 저장소당 하나의 .sources 파일을 사용하는 방식으로 이와 유사한 구조를 취하고 있습니다. 만약 Ubuntu에서 deb822 중복 소스 오류를 겪었다면, 이미 apt 측면에서 이 문제의 절반을 경험한 셈입니다.

EPEL은 대부분의 가이드가 전제로 하는 저장소입니다

Extra Packages for Enterprise Linux(EPEL)는 RHEL 및 그 파생 배포판을 위해 Fedora 패키지를 빌드하는 Fedora 프로젝트입니다. 이는 이 생태계에서 범용 PPA에 가장 가까운 존재이며, 매우 많은 튜토리얼이 이미 활성화되어 있다고 가정합니다. 프로젝트 공식 웹사이트에서 확인할 수 있는 패키지에 대해 dnf install 명령이 No match for argument라고 응답한다면, 가장 먼저 EPEL을 확인해야 합니다.

Rocky Linux 및 AlmaLinux의 경우:

sudo dnf config-manager --set-enabled crb
sudo dnf install epel-release
sudo dnf makecache

CRB는 CodeReady Builder의 약자로, 배포판과 함께 제공되지만 기본적으로는 비활성화되어 있는 라이브러리 저장소입니다. 대부분의 EPEL 패키지는 이 저장소의 라이브러리에 의존하므로, CRB 없이 EPEL만 활성화하면 당장은 오류가 발생하지 않습니다. 하지만 나중에 설치 시점에 생소한 패키지의 의존성 문제가 해결되지 않아 실패하게 됩니다. CRB를 먼저 활성화하면 이러한 유형의 오류는 사라집니다.

RHEL의 경우 CRB는 config-manager이 아닌 구독을 통해 제공되므로, 해당 단계는 Red Hat의 공식 EPEL 지침을 따라야 합니다. Fedora는 메인 저장소에 이미 EPEL이 백포트하는 패키지들을 포함하고 있으므로 이러한 과정이 필요 없습니다. EPEL의 정책은 RHEL이 제공하는 패키지를 절대 대체하지 않는 것이므로, 저장소를 추가해도 서버에 이미 설치된 패키지에는 아무런 영향을 주지 않습니다.

dnf history undo, apt가 수행할 수 없는 기능

dnf는 모든 트랜잭션을 기록하며, 이를 바탕으로 역방향 트랜잭션을 생성할 수 있습니다.

sudo dnf history
sudo dnf history info 42
sudo dnf history undo 42

dnf history은 각 트랜잭션을 시작한 명령줄과 함께 번호가 매겨진 트랜잭션 목록을 출력합니다. undo는 반대되는 트랜잭션을 구성합니다. 즉, 해당 트랜잭션에서 설치된 패키지는 제거되고, 업그레이드된 패키지는 이전 버전으로 되돌아갑니다. 이는 apt 사용자가 다른 패키지 관리자로 전환한 뒤 가장 그리워하는 기능입니다.

이 기능에는 실제적인 한계가 있으며, 이를 의존하기 전에 미리 알아두어야 합니다. undo은 활성화된 저장소에 여전히 존재하는 패키지 버전만 다시 설치할 수 있으므로, 이전 빌드가 미러 서버에서 삭제되면 undo 작업은 not-found 오류와 함께 실패합니다. 롤백은 패키지 데이터베이스 수준에서 멈춥니다. 업그레이드 과정에서 다시 작성된 설정 파일은 그대로 유지되며, 서비스가 처음 시작될 때 마이그레이션된 데이터베이스 스키마도 그대로 유지됩니다. dnf는 파일을 이전 상태로 되돌릴 뿐, 사용자의 데이터를 복구하지는 않습니다.

apt에는 이에 대응하는 기능이 없습니다. /var/log/apt/history.log는 명령줄을 포함하여 정확히 어떤 일이 발생했는지 기록하지만, 로그를 읽는 것과 작업을 되돌리는 것은 다릅니다. apt 측의 복구는 수동으로 진행해야 합니다. 먼저 apt list -a nginx를 실행하여 아카이브에 여전히 보관 중인 버전을 확인한 다음, sudo apt install nginx=<exact version string>으로 특정 버전을 고정하고, sudo apt-mark hold nginx을 추가하여 다음 업그레이드 시 수정 사항이 되돌려지지 않도록 해야 합니다.

패키지 그룹에 대응하는 apt 명령어는 없습니다

dnf는 하나의 명령어로 지정된 패키지 묶음을 설치할 수 있습니다.

dnf group list
dnf group info "Development Tools"
sudo dnf group install "Development Tools"

오래된 가이드에서는 dnf groupinstall "Development Tools"을 사용하라고 안내합니다. 해당 별칭은 dnf 4 버전까지는 작동하지만 dnf 5부터는 제거되었으므로, 모든 환경에서 작동하는 두 단어 조합인 dnf group install를 사용하는 것이 유일한 방법입니다. 이 명령어를 사용하고 더 이상 고민하지 마십시오.

apt에는 그룹 개념이 없습니다. Debian에서 가장 유사한 개념은 메타패키지(metapackage)입니다. 이는 실제 내용은 없고 build-essential과 같이 의존성 목록만 포함하는 빈 패키지를 의미합니다. 실질적인 차이는 삭제 시 발생합니다. 메타패키지를 삭제해도 apt autoremove을 실행하기 전까지는 의존성 패키지들이 그대로 남아 있지만, dnf group remove는 동일한 트랜잭션 내에서 그룹에 속한 패키지들을 함께 삭제합니다.

unattended-upgrades와 dnf-automatic

두 제품군 모두 사용자가 로그인하지 않은 상태에서 업데이트를 설치하는 기능을 제공합니다. 이 도구들은 목적만 같을 뿐 공유하는 요소는 없습니다.

Ubuntu와 Debian에서는 unattended-upgrades 패키지를 사용하며, /etc/apt/apt.conf.d/50unattended-upgrades에서 설정을 구성합니다. 이 파일에 업데이트를 가져올 수 있는 출처(origin)를 나열합니다. Ubuntu에서 unattended upgrades 설정하기 문서에서 해당 설정 파일과 그에 따른 재부팅 문제를 다룹니다.

Rocky Linux, AlmaLinux, Fedora에서는 dnf-automatic 패키지를 사용하며, 활성화한 systemd 타이머가 동작 방식을 결정합니다.

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer
systemctl list-timers 'dnf-automatic*'

dnf-automatic-install.timer은 업데이트를 다운로드하고 적용합니다. dnf-automatic-download.timer은 업데이트를 다운로드하기만 하고 설치는 사용자에게 맡깁니다. dnf-automatic-notifyonly.timer은 보고만 수행합니다. 이 유닛들은 각각 /etc/dnf/automatic.conf의 apply_updates 설정을 덮어쓰므로, 설정 파일의 내용보다 어떤 타이머를 선택했는지가 더 중요합니다.

보안 수정 사항으로만 제한하려면 /etc/dnf/automatic.conf에서 upgrade_type = security을 설정하십시오. 이 필터는 저장소에서 보안 errata를 게시하는지에 따라 달라지므로, 먼저 dnf updateinfo list security으로 확인해야 합니다. 업데이트가 대기 중인 서버에서 결과가 비어 있다면 메타데이터가 없는 것이며, 이 경우 security는 아무것도 설치하지 않습니다.

Fedora의 dnf 5에서는 유닛 이름이 변경되었습니다. 해당 유닛은 dnf5-automatic.timer이며, 동일한 /etc/dnf/automatic.conf 파일을 읽습니다.

yum은 여전히 유효한 명령어입니까?

네, 하지만 yum 자체는 아무런 동작도 하지 않습니다. Rocky Linux, AlmaLinux, CentOS Stream에서 /usr/bin/yum은 dnf를 가리키는 심볼릭 링크입니다. 다음 명령어로 확인하십시오:

ls -l /usr/bin/yum
dnf --version

대부분의 구문이 그대로 호환되기 때문에 튜토리얼에는 여전히 예전 yum 문법이 등장합니다. yum install, yum remove, yum update은 모두 정상적으로 작동합니다. 다만 한 가지 습관은 버리는 것이 좋습니다. yum-config-manager은 dnf 4 시스템에서 별도의 바이너리로 존재하지만, 현재 문서에서는 dnf config-manager라는 표기를 사용합니다. 이 표기를 사용해야 시스템이 dnf 5로 업그레이드되어도 문제없이 작동합니다.

dnf 4와 dnf 5: 명령어를 복사하기 전 확인 사항

dnf 5는 완전히 새로 작성된 버전이며, 여러 명령어의 표기법이 변경되었습니다. Fedora 41 이상 버전은 이를 dnf으로 제공합니다. 엔터프라이즈 리빌드 배포판들은 전환 속도가 더 느리므로, 배포판 이름만 보고 추측해서는 안 됩니다. 자신의 서버에서 dnf --version를 실행하여 첫 번째 줄을 읽어보십시오. 해당 숫자에 따라 아래의 어떤 구문을 사용해야 할지 결정됩니다.

가장 명확한 예시는 Docker에서 확인할 수 있는데, 각 버전에 따라 서로 다른 저장소 명령어를 게시합니다. RHEL 및 그 리빌드 배포판에서 dnf 4를 사용하는 경우:

sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

Fedora에서 dnf 5를 사용하는 경우:

sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

같은 공급업체, 같은 작업이지만 사용하는 단어가 다릅니다. dnf 5는 config-manager를 하위 명령 기반 도구로 변경했기 때문에, 기존의 --add-repo 플래그는 허용되지 않으며 저장소가 추가되는 대신 사용법 오류가 발생합니다. 또 다른 예로 저장소 활성화가 있습니다. dnf 4의 dnf config-manager --set-enabled crb은 dnf 5에서 dnf config-manager setopt crb.enabled=1로 변경되었습니다.

실질적으로 중요한 선택

패키지 관리자만 보고 서버 배포판을 선택하는 것은 잘못된 기준입니다. dnf와 apt는 동일한 작업을 수행하며, 명령어 체계를 익히는 데는 반나절이면 충분합니다. 운영자의 1년을 좌우하는 것은 저장소 이면의 릴리스 모델입니다. Fedora는 빠르게 변화하며 특정 릴리스는 출시 후 약 13개월이 지나면 업데이트가 중단됩니다. 이는 워크스테이션에는 적합하지만, 재구축을 원치 않는 서버에는 고통스러운 일입니다. Rocky Linux와 AlmaLinux는 RHEL을 추종하므로 10년의 지원 기간을 보장받으며, 패키지 버전도 의도적으로 고정됩니다. Ubuntu는 두 가지 형태를 모두 제공하며, 서버 환경에서 Ubuntu LTS와 중간 릴리스 간의 차이는 apt 생태계 내에서 내려야 할 동일한 결정입니다.

2026년 8월 기준으로, 이 모든 것은 일반적인 VPS 이미지입니다. 원하는 지원 기간을 선택한 다음, 위에서 언급한 10가지 명령어를 익히십시오.

FAQ

apt update에 대응하는 dnf 명령어는 무엇입니까?

별도로 실행해야 하는 명령어는 없습니다. dnf는 모든 트랜잭션 이전에 캐시된 메타데이터의 경과 시간을 확인하며, 만료된 경우 최신 복사본을 다운로드합니다. 따라서 한 달 동안 건드리지 않은 서버에서 dnf install를 실행해도 여전히 최신 패키지 정보를 확인할 수 있습니다. sudo dnf makecache 명령어가 존재하며 강제로 다운로드를 수행하지만, 이 명령어의 실제 용도는 다운로드 지연 시간을 다음 설치 시점이 아닌 사용자가 원하는 시점으로 옮기는 것입니다. "업데이트가 무엇이 있는지" 확인하는 명령어는 dnf check-update이며, 이는 apt list --upgradable와 동일하게 작동하고 업데이트가 있을 경우 상태 코드 100을 반환하며 종료합니다.

Rocky Linux나 Fedora에 PPA와 대응하는 개념이 있습니까?

아니요. PPA(Personal Package Archives)는 Launchpad 서비스이며 Launchpad는 Ubuntu 인프라이므로, add-apt-repository에는 이에 대응하는 개념이 없습니다. RPM에서의 대응 개념은 /etc/yum.repos.d/ 디렉터리에 위치한 .repo 파일이며, 이 파일은 이름, baseurl, gpgkey 정보를 담고 있습니다. 벤더가 이 파일을 제공하며, dnf 4에서는 sudo dnf config-manager --add-repo <url>, dnf 5에서는 sudo dnf config-manager addrepo --from-repofile <url>를 사용하여 해당 파일을 다운로드하고 배치합니다. 일반적인 추가 소프트웨어의 경우 보통 EPEL을 사용하며, sudo dnf config-manager --set-enabled crb을 실행한 뒤 sudo dnf install epel-release을 통해 활성화합니다.

서버를 고장 낸 dnf upgrade를 되돌릴 수 있습니까?

네, 제한적인 범위 내에서 가능합니다. sudo dnf history를 실행하여 트랜잭션 번호를 찾고, sudo dnf history info <id>으로 변경 사항을 정확히 확인한 뒤, sudo dnf history undo <id>를 실행하십시오. 이전 패키지 버전이 활성화된 저장소에 더 이상 존재하지 않으면 dnf가 재설치할 대상을 찾지 못하므로 되돌리기(undo) 작업은 실패합니다. 또한 이 작업은 패키지 변경 사항만 되돌립니다. 업그레이드 과정에서 덮어쓰인 설정 파일이나 서비스가 처음 시작될 때 마이그레이션된 데이터베이스는 그대로 유지됩니다. apt에는 이와 대응하는 명령어가 전혀 없으며, 오직 /var/log/apt/history.log의 기록만 존재합니다.

Rocky Linux와 AlmaLinux에서 yum은 여전히 작동합니까?

/usr/bin/yum이 dnf에 대한 심볼릭 링크이기 때문에 작동합니다. ls -l /usr/bin/yum 명령어로 직접 확인해 보십시오. yum install httpd을 입력하면 dnf가 실행되므로, 대부분의 오래된 튜토리얼도 여전히 기능합니다. yum이라는 명칭은 호환성을 위한 것일 뿐이므로, 새로운 스크립트나 문서를 작성할 때는 dnf를 사용하십시오. 또한 구형 yum-config-manager 바이너리보다는 dnf config-manager을 사용하는 것을 권장합니다.

왜 dnf remove는 그렇게 많은 패키지를 삭제하려고 합니까?

dnf는 동일한 트랜잭션의 일부로 더 이상 필요하지 않은 의존성 패키지를 함께 제거하기 때문입니다. 반면 apt remove은 별도로 apt autoremove를 실행하기 전까지 해당 패키지들을 그대로 남겨둡니다. 따라서 Ubuntu에서는 작게 보이는 삭제 작업이 Rocky Linux에서는 긴 목록으로 출력될 수 있습니다. 목록은 대개 정확하지만, 확인하기 전에 반드시 읽어보십시오. 목록에 있는 패키지 중 유지하고 싶은 것이 있다면, 먼저 해당 패키지를 명시적으로 설치하여 dnf가 이를 사용자가 직접 요청한 패키지로 기록하게 하십시오.