[Linux] YUM에서 DNF로: CentOS 7에서 Rocky Linux 9로 마이그레이션

목차

• 1. 왜 지금 YUM DNF 마이그레이션을 봐야 할까요?
• 2. YUM과 DNF, 쉽게 말해 뭐가 다른가요?
• 3. 마이그레이션 전략: 인플레이스 업그레이드보다 새 환경 이전이 안전합니다
• 4. 실전 구현: CentOS 7에서 현재 상태 정리하기
• 4-1. 설치된 패키지 목록 백업
• 4-2. 서비스 목록과 활성화 상태 확인
• 4-3. 설정 파일과 애플리케이션 데이터 백업
• 5. 실전 구현: Rocky Linux 9에서 DNF 기반으로 재구성하기
• 5-1. 시스템 갱신과 기본 도구 설치
• 5-2. 자주 쓰는 YUM 명령을 DNF로 치환
• 5-3. 패키지 그룹과 저장소 확인
• 5-4. 예시: 웹 서버 재구성
• 6. ⚠️ 실제로 많이 걸리는 문제와 해결법
• 6-1. 서드파티 저장소가 그대로 안 붙는 문제
• 6-2. 패키지 이름이 달라졌거나 사라진 문제
• 6-3. 오래된 스크립트가 yum 전제인 문제
• 6-4. SELinux와 방화벽 이슈
• 7. 검증: 마이그레이션 결과를 어떻게 확인할까요?
• 8. 정리와 FAQ: CentOS EOL 이후 운영 습관도 같이 바꿔야 합니다
• 자주 묻는 질문
• 마무리 체크리스트

[리눅스] YUM에서 DNF로: CentOS 7에서 Rocky Linux 9로 마이그레이션

CentOS 7에서 Rocky Linux 9로 넘어가야 하는 시점이 오면 제일 먼저 부딪히는 게 YUM DNF 마이그레이션이더라고요. 운영 서버를 오래 굴려보신 분들은 아시겠지만, 패키지 관리자(package manager) 하나 바뀌는 문제가 생각보다 큽니다. 단순히 명령어만 바뀌는 게 아니라 저장소(repository), 의존성(dependency), 자동화 스크립트, 보안 업데이트 흐름까지 전부 영향받거든요. 특히 CentOS EOL 이후에는 더 미루기 어려워졌습니다. 저도 홈랩이랑 사내 테스트 장비에서 리눅스 OS 이전을 여러 번 해봤는데, 처음엔 "yum만 dnf로 바꾸면 끝 아닌가?" 싶었다가 삽질 좀 했습니다. 이번 글에서는 Rocky Linux 9 기준으로 YUM에서 DNF로 옮길 때 무엇을 확인해야 하는지, 어떤 식으로 이전하면 덜 위험한지 경험 기준으로 정리해보겠습니다.

CentOS 7 환경에서 Rocky Linux 9 환경으로 넘어가며 패키지 관리 흐름이 바뀌는 모습을 보여주는 개요 이미지입니다.

1. 왜 지금 YUM DNF 마이그레이션을 봐야 할까요?

여기서 중요한 포인트가 있습니다. CentOS 7은 이미 수명 주기 종료(EOL, End of Life) 상태라서, 운영 환경에 그대로 두면 보안 패치와 유지보수 측면에서 부담이 커져요. 실제로 서버를 오래 운영하다 보면 "지금 잘 돌아가는데 굳이?"라는 생각이 드는데요, 이런 시기에 더 무서운 건 조용히 쌓이는 기술 부채(technical debt)입니다.

패키지 관리자 관점에서 보면 CentOS 7은 익숙한 YUM(Yellowdog Updater Modified, RPM 계열 패키지 관리 도구) 중심이었고, Rocky Linux 9는 DNF(Dandified YUM, 개선된 차세대 패키지 관리자)가 기본입니다. 이름만 보면 YUM의 후속 버전처럼 보이지만, 실제로 써보니까 의존성 해결 방식, 메타데이터 처리, 플러그인 사용감이 꽤 달라졌더라고요.

• CentOS 7은 오래된 운영 환경에 익숙한 자동화가 많이 붙어 있어요.
• Rocky Linux 9는 보안과 최신 패키지 생태계 측면에서 훨씬 유리합니다.
• YUM DNF 마이그레이션은 명령어 치환이 아니라 운영 습관 전체를 점검하는 작업에 가깝습니다.

2. YUM과 DNF, 쉽게 말해 뭐가 다른가요?

쉽게 말해, YUM이 오래된 익숙한 작업 방식이라면 DNF는 그걸 좀 더 현대적으로 다듬은 도구예요. 저도 처음엔 헷갈렸는데, 실제로 써보니까 차이는 몇 가지로 정리되더라고요.

항목	CentOS 7 / YUM	Rocky Linux 9 / DNF
기본 패키지 관리자	yum	dnf
의존성 처리	기본적이며 오래된 방식	더 개선된 의존성 해결
메타데이터 처리	익숙하지만 구형 환경 중심	성능과 관리 편의성이 개선됨
자동화 스크립트 영향	yum 명령 하드코딩 사례 많음	dnf 기준으로 스크립트 점검 필요
운영 포인트	레거시 유지보수	현행 표준 운영에 가까움

Rocky Linux 9에서 yum 명령이 아예 완전히 사라진 건 아닐 수 있어요. 다만 운영 기준으로는 DNF를 표준으로 보고 스크립트와 문서를 정리하는 게 맞습니다. 저는 이 부분을 대충 넘겼다가 자동 배포 스크립트 일부가 애매하게 남아서, 나중에 어떤 서버는 yum, 어떤 서버는 dnf를 쓰는 어정쩡한 상태가 됐더라고요. 이런 건 초기에 정리하는 게 진짜 중요합니다.

3. 마이그레이션 전략: 인플레이스 업그레이드보다 새 환경 이전이 안전합니다

여기서 많이 물어보시는 게 "CentOS 7을 Rocky Linux 9로 바로 올리면 되나요?"인데요, 제 경험상 신규 Rocky Linux 9 서버를 만들고 워크로드를 이전하는 방식이 훨씬 안전했어요. 특히 메이저 버전을 두 단계 가까이 건너뛰는 식의 접근은 패키지 충돌, 라이브러리 차이, 서비스 설정 변경 때문에 예상보다 위험하거든요.

1. 현재 CentOS 7 서버에서 설치 패키지와 저장소 구성을 수집합니다.
2. 애플리케이션, 데이터, 설정 파일을 분리해서 백업합니다.
3. 새 Rocky Linux 9 서버를 준비합니다.
4. DNF 기준으로 필요한 패키지를 다시 설치합니다.
5. 서비스 설정을 이관하고 동작을 검증합니다.
6. 컷오버(cutover, 운영 전환) 후 구 서버를 단계적으로 종료합니다.

이 방식이 귀찮아 보여도, 장애 대응이 훨씬 쉬워요. 실패했을 때 원복(rollback)도 명확하고요.

4. 실전 구현: CentOS 7에서 현재 상태 정리하기

제가 직접 해보니 마이그레이션의 절반은 "현재 상태를 얼마나 정확히 기록하느냐"에서 갈려요. 특히 오래된 서버는 누가 왜 추가했는지 모르는 패키지와 서드파티 저장소(third-party repository)가 꼭 있거든요.

4-1. 설치된 패키지 목록 백업

rpm -qa | sort > /root/centos7-rpm-list.txt
yum repolist all > /root/centos7-repolist.txt
yum history list > /root/centos7-yum-history.txt

이 세 파일만 있어도 나중에 정말 도움이 돼요. 특히 rpm -qa 결과는 "어떤 기능 때문에 이 패키지가 필요했는지"를 추적하는 출발점이 됩니다.

4-2. 서비스 목록과 활성화 상태 확인

systemctl list-unit-files --type=service > /root/centos7-services.txt
systemctl list-units --type=service --state=running > /root/centos7-running-services.txt

운영 서버는 패키지보다 서비스가 더 중요해요. 패키지는 다시 깔면 되지만, 어떤 서비스가 자동 시작되었는지를 놓치면 전환 후에 "설치는 됐는데 왜 안 뜨지?" 상황이 바로 생기거든요.

4-3. 설정 파일과 애플리케이션 데이터 백업

tar czf /root/etc-backup.tar.gz /etc
mkdir -p /root/migration-notes
cp -a /var/www /root/migration-notes/ 2>/dev/null
cp -a /opt /root/migration-notes/ 2>/dev/null

물론 실제 운영에서는 애플리케이션별 데이터 경로를 더 정확히 잡아야 합니다. 웹 서버라면 /var/www, 자체 배포 앱이면 /opt, DB면 별도 덤프가 필수죠.

이전 작업 전에 현재 서버의 패키지와 서비스 상태를 정리하는 과정을 보여주는 이미지입니다.

5. 실전 구현: Rocky Linux 9에서 DNF 기반으로 재구성하기

이제 새 서버 쪽입니다. Rocky Linux 9에 들어오면 운영 습관을 DNF 중심으로 재정리하는 게 핵심이에요.

5-1. 시스템 갱신과 기본 도구 설치

sudo dnf update -y
sudo dnf install -y dnf-plugins-core vim tar rsync

dnf-plugins-core는 실무에서 꽤 자주 써요. 저장소 관리나 쿼리 작업할 때 진짜 편하더라고요.

5-2. 자주 쓰는 YUM 명령을 DNF로 치환

기존 YUM 명령	Rocky Linux 9 DNF 명령	설명
yum install httpd	dnf install httpd	패키지 설치
yum remove httpd	dnf remove httpd	패키지 제거
yum update	dnf update	패키지 갱신
yum search nginx	dnf search nginx	패키지 검색
yum info podman	dnf info podman	패키지 정보 확인
yum repolist	dnf repolist	저장소 목록 확인

처음엔 별 차이 없어 보이죠. 근데 운영 자동화에서 이 차이가 커요. Ansible(앤서블, 자동화 도구) 플레이북이나 셸 스크립트 안에 yum이 하드코딩되어 있으면, 이참에 dnf 기준으로 정리하는 게 좋아요.

5-3. 패키지 그룹과 저장소 확인

sudo dnf repolist
sudo dnf group list
sudo dnf module list

여기서 module(모듈, 버전 스트림 관리 기능) 개념이 처음엔 좀 낯설 수 있어요. 예전처럼 무조건 패키지 이름만 보고 설치하다가 원하는 버전이 안 맞는 경우가 생기거든요. 특히 언어 런타임이나 DB 클라이언트 계열은 모듈/저장소 정책을 한 번 더 확인하는 습관이 필요합니다.

5-4. 예시: 웹 서버 재구성

sudo dnf install -y httpd
sudo systemctl enable --now httpd
sudo systemctl status httpd

여기서 중요한 포인트! 패키지 설치만 끝내고 만족하면 안 돼요. 서비스 활성화, 방화벽, SELinux(Security-Enhanced Linux, 보안 정책 프레임워크)까지 같이 봐야 실제 서비스가 떠요.

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo restorecon -Rv /var/www/html

CentOS 7에서 대충 넘어가던 권한/보안 이슈가 Rocky Linux 9에선 더 또렷하게 드러나는 경우가 많았어요. 저도 처음엔 "분명 httpd는 떴는데 왜 페이지가 안 보이지?" 하다가 SELinux 컨텍스트(context) 때문에 한참 봤었네요.

Rocky Linux 9에서 DNF, systemd, firewall-cmd, SELinux를 함께 점검하는 흐름을 보여주는 이미지입니다.

6. ⚠️ 실제로 많이 걸리는 문제와 해결법

이 섹션은 제가 특히 강조하고 싶은 부분이에요. YUM DNF 마이그레이션 자체보다, 주변 요소에서 더 많이 막히거든요.

6-1. 서드파티 저장소가 그대로 안 붙는 문제

CentOS 7 시절에 붙여둔 외부 저장소가 Rocky Linux 9에서는 바로 호환되지 않는 경우가 있어요. 배포판 버전, GPG 키, 패키지 경로가 달라졌기 때문입니다.

• 기존 .repo 파일을 그대로 복사하지 마세요.
• Rocky Linux 9 지원 여부를 먼저 확인하세요.
• 지원이 불분명하면 OS 기본 저장소 우선으로 재설계하는 게 안전해요.

6-2. 패키지 이름이 달라졌거나 사라진 문제

레거시 패키지는 이름이 바뀌거나 더 이상 기본 저장소에 없을 수 있어요. 이럴 때는 억지로 같은 이름만 찾기보다, 기능 단위로 대체 패키지를 찾는 쪽이 낫습니다.

sudo dnf search <keyword>
sudo dnf provides '*/binary-name'

예전엔 패키지 이름을 외워서 설치했다면, 이제는 파일 제공자(provides) 검색을 더 자주 써요. 이거 진짜 편하더라고요.

6-3. 오래된 스크립트가 yum 전제인 문제

배치 스크립트나 운영 문서에 이런 코드가 많이 남아 있어요.

yum install -y rsync
if yum repolist | grep -q epel; then
  echo "repo exists"
fi

이런 부분은 명시적으로 DNF 기준으로 바꾸는 게 좋아요.

dnf install -y rsync
if dnf repolist | grep -q epel; then
  echo "repo exists"
fi

호환 래퍼(wrapper)가 있더라도 운영 표준은 하나로 맞추세요. 혼용하면 나중에 문서, 인수인계, 자동화에서 꼭 꼬여요.

6-4. SELinux와 방화벽 이슈

사실 패키지 설치는 됐는데 서비스가 안 되는 경우, 원인은 DNF가 아니라 보안 정책인 경우가 많아요. 특히 다음 항목을 꼭 같이 봐야 합니다.

• getenforce로 SELinux 상태 확인
• journalctl -xeu 서비스명으로 서비스 로그 확인
• firewall-cmd --list-all로 방화벽 규칙 확인
• 웹/앱 데이터 경로의 컨텍스트와 권한 확인

7. 검증: 마이그레이션 결과를 어떻게 확인할까요?

저는 전환 작업이 끝나면 "설치됐다"가 아니라 "운영 관점에서 정상인가"를 봐요. 검증 체크리스트를 짧게라도 만드는 게 좋습니다.

1. 필수 패키지가 DNF 기준으로 모두 설치되었는지 확인
2. 주요 서비스가 부팅 후 자동 시작되는지 확인
3. 애플리케이션 로그에 의존성 오류가 없는지 확인
4. 방화벽과 SELinux 정책이 서비스 요구사항과 맞는지 확인
5. 모니터링과 백업 작업이 새 서버에서 정상 동작하는지 확인

dnf repolist
rpm -qa | sort
systemctl --failed
ss -tulpn
journalctl -p err -b

이 다섯 줄만 잘 봐도 초반 점검은 꽤 돼요. 저는 여기에 애플리케이션 헬스체크(health check)까지 붙여서 최종 확인하는 편이에요. 드디어 됐다! 싶은 순간이 여기서 오죠.

이전 후 서비스 상태와 로그를 검증하는 운영 점검 결과를 보여주는 이미지입니다.

8. 정리와 FAQ: CentOS EOL 이후 운영 습관도 같이 바꿔야 합니다

이번 YUM DNF 마이그레이션에서 핵심은 간단해요. CentOS 7의 레거시 운영 습관을 Rocky Linux 9 환경에 그대로 들고 오지 말자는 거예요. 패키지 관리자만 바뀌는 게 아니라 저장소 운영, 보안 정책, 자동화 기준까지 함께 정리해야 실제로 편해져요. 저도 처음엔 명령어 몇 개만 바꾸면 되는 줄 알았는데, 결국 문서와 스크립트까지 손봐야 마음이 편하더라고요.

다음 글에서는 Rocky Linux 9로 넘어온 뒤 EPEL(Extra Packages for Enterprise Linux)이나 컨테이너 도구를 어떻게 정리하면 좋은지 다뤄볼 예정입니다. 이전 글에서 다룬 시스템 백업 전략과 함께 보시면 흐름이 더 잘 잡히실 겁니다.

자주 묻는 질문

• Q. CentOS 7에서 Rocky Linux 9로 바로 인플레이스 업그레이드해도 되나요?
  제가 직접 해본 기준으로는 권장하지 않아요. 새 서버를 만들고 데이터와 설정을 옮기는 방식이 훨씬 안전했습니다.
• Q. Rocky Linux 9에서도 yum 명령을 써도 되나요?
  일부 환경에서는 동작할 수 있어도 운영 표준은 DNF로 맞추는 게 좋아요. 문서와 자동화도 함께 정리하세요.
• Q. 가장 많이 놓치는 건 뭔가요?
  서드파티 저장소, SELinux, 자동 시작 서비스, 그리고 배포 스크립트 안의 yum 하드코딩입니다.

CentOS 7에서 Rocky Linux 9로 옮길 때 꼭 확인할 체크포인트를 요약한 이미지입니다.

마무리 체크리스트

• CentOS EOL 대응이 필요한 서버인지 확인
• 기존 YUM 기반 패키지와 저장소 목록 백업
• Rocky Linux 9 신규 서버 준비
• DNF 기준으로 패키지 재설치 및 저장소 정리
• 서비스, 방화벽, SELinux, 로그까지 검증
• 자동화 스크립트와 운영 문서를 DNF 기준으로 통일

혹시 지금 CentOS 7 서버를 붙잡고 계신다면, 오늘은 최소한 패키지 목록이랑 서비스 목록부터 백업해보세요. 그 한 걸음이 나중에 진짜 큰 차이를 만들어요.

📚 함께 읽으면 좋은 글

• iptables에서 nftables로 전환: 레거시 방화벽 마이그레이션 가이드
• 컨테이너 없이 리눅스 네임스페이스로 프로세스 격리하기: 실제 사례 연구
• Linux 커널 튜닝으로 보는 네트워크 I/O 벤치마크 분석
• OpenStack Trove vs RDS 마이그레이션, 왜 AWS RDS로 옮겼나
• Proxmox VE vs VMware ESXi: 홈랩 환경 마이그레이션 1년 후기