RHEL 계열 관리 · dnf/yum 기초 · 이론
dnf 가 apt 와 다른 점
한 줄 요약
dnf 의 결정적 차이는 모든 설치가 트랜잭션으로 기록되고 되돌릴 수 있다는 것이다. apt 에는 이에 대응하는 기능이 없다.
왜 이게 필요했나
우분투에서 넘어온 사람이 처음 놀라는 지점이 이것이다.
dnf history # 지금까지의 모든 트랜잭션 목록dnf history info 42 # 42번 트랜잭션에서 무엇이 바뀌었나dnf history undo 42 # 42번을 되돌린다dnf history rollback 41 # 41번 시점의 상태로 되돌린다apt 에는 /var/log/apt/history.log 라는 기록은 있지만 되돌리는 명령은 없다. 이 차이가 운영 방식을 바꾼다. RHEL 계열에서는 "일단 설치해 보고 아니면 되돌린다" 가 가능하다.
다만 한계가 명확하다. 이전 버전 패키지가 저장소에 없으면 다운그레이드가 실패한다. 그리고 Red Hat 은 시스템 패키지(selinux, selinux-policy, kernel, glibc 및 glibc 에 의존하는 gcc 등)의 다운그레이드를 지원하지 않는다고 명시한다. 롤백은 만능이 아니다.
어떻게 동작하나
명령 대응표
| 작업 | apt | dnf |
| --- | --- | --- |
| 색인 갱신 | apt-get update | (자동, 필요시 dnf makecache) |
| 설치 | apt-get install X | dnf install X |
| 제거 | apt-get remove X | dnf remove X |
| 검색 | apt-cache search X | dnf search X |
| 정보 | apt-cache show X | dnf info X |
| 파일→패키지 | dpkg -S /path | dnf provides /path (미설치 포함) |
| 설치된 파일 목록 | dpkg -L X | rpm -ql X |
| 업그레이드 | apt-get upgrade | dnf upgrade |
| 버전 고정 | apt-mark hold | dnf versionlock add |
| 롤백 | 없음 | dnf history undo |
dnf provides 가 특히 강력하다. apt 의 dpkg -S 는 이미 설치된 파일만 찾지만, dnf provides 는 저장소 메타데이터를 뒤져 아직 설치되지 않은 패키지까지 찾아 준다.
dnf provides '*/nginx.conf'dnf provides 'libnl-3.so.200()(64bit)'두 번째 예시가 중요하다. RPM 에서 의존성의 단위는 패키지 이름이 아니라 능력(capability) 이다. 공유 라이브러리의 소네임, 파일 경로, 심지어 심볼 버전까지 의존 대상이 될 수 있다.
dnf repoquery --requires httpddnf repoquery --requires --resolve --recursive httpd | sort -u | wc -l--requires 는 요구하는 능력, --resolve 는 그 능력을 제공하는 패키지로 치환, --recursive 는 재귀적으로 계속 내려간다. 폐쇄망 반입 목록을 만들 때 핵심 도구다.
저장소 파일
# /etc/yum.repos.d/labhub-local.repo[labhub-local]name=LabHub local (snapshot 2026-08-20)baseurl=file:///srv/repo/labhubenabled=1gpgcheck=1gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-labhubmetadata_expire=-1각 키의 기본값을 알아 두는 것이 중요하다.
enabled기본 Truegpgcheck기본 False — 명시적으로 켜야 한다repo_gpgcheck(메타데이터 서명 검증) 기본 Falsepriority기본 99metadata_expire기본 48시간. 폐쇄망 로컬 저장소에서는-1(만료 없음)로 두는 편이 낫다module_hotfixes기본 False
저장소 표시 이름에 스냅샷 날짜를 박아 두면 6개월 뒤 dnf repolist -v 한 줄로 그 서버가 언제 시점 콘텐츠로 설치됐는지 알 수 있다.
캐시
폐쇄망에서 가장 많은 신고가 "저장소에 패키지를 넣었는데 안 보인다" 다. 원인은 둘 중 하나다.
# 저장소 쪽: 메타데이터를 다시 만들었는가 (이걸 빼먹는 경우가 정말 많다)createrepo_c --update /srv/repo/labhub# 클라이언트 쪽: 캐시를 만료 표시 (가장 가벼움)dnf clean expire-cache# 그래도 안 되면dnf clean metadata# 최후의 수단dnf clean alldnf makecache각각의 정의: expire-cache 는 메타데이터를 만료 표시만, metadata 는 메타데이터 제거, packages 는 캐시된 패키지 제거, all 은 전부.
현장에서 만나는 모습
dnf update --security 가 조용히 "할 일 없음" 으로 끝나는 경우. 보안 권고(updateinfo) 메타데이터가 저장소에 없으면 그렇게 된다. createrepo_c 는 rpm 파일에서 primary/filelists/other 만 만들 수 있고, 권고 정보는 rpm 안에 없다. 조용히 아무것도 하지 않는다는 점이 위험하다. dnf updateinfo --summary 로 확인하는 습관이 필요하다.
다음 실습에서 할 것
dnf 로 저장소를 확인하고, 설치하고, provides 로 역추적하고, 히스토리로 롤백하고, 버전을 고정한다.