apt 명령어 dnf 대응 정리: Rocky, 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를 사용하게 됩니다. 이 분기점의 한쪽 진영이 사실상 동일한 시스템을 두고 왜 네 가지 이름으로 불리는지는 선택하기 전에 알아둘 가치가 있는 이야기이며, Red Hat Linux가 어떻게 Fedora, RHEL, CentOS, Rocky 및 AlmaLinux가 되었는지에서 각 배포판의 유래를 설명합니다.

패키지 형식은 도구에 따라 결정됩니다. 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는 고정(hold) 기능이 플러그인이 아닌 dpkg 상태의 일부이므로 apt-mark hold을 위해 별도의 추가 작업이 필요 없습니다.

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

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

대신 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 및 그 재빌드 버전(rebuilds)을 위한 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 파일을 사용하는 방식으로 dnf와 유사한 형태를 갖추고 있습니다. 만약 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에서 설정합니다. 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입니다. 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/ 디렉터리에 이름, baseurl, gpgkey 정보를 담은 .repo 파일을 사용하는 것이 대응 방식입니다. 벤더가 해당 파일을 제공하며, 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가 재설치할 대상을 찾지 못하므로 되돌리기 작업은 실패합니다. 또한 이 작업은 패키지 변경 사항만 되돌립니다. 업그레이드 과정에서 다시 작성된 설정 파일이나 서비스가 처음 시작될 때 마이그레이션된 데이터베이스는 그대로 유지됩니다. 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가 이를 사용자가 직접 선택한 패키지로 기록하게 하십시오.