Linux 서버를 운영하다 보면 웹 서버, 데이터베이스, 개발 도구, 모니터링 프로그램 등 다양한 소프트웨어를 설치하고 관리해야 합니다. 특히 시스템 엔지니어는 단순히 프로그램을 설치하는 것뿐만 아니라 버전 관리, 의존성 해결, 보안 업데이트, 패키지 삭제, 저장소 관리까지 수행할 수 있어야 합니다.
Rocky Linux를 비롯한 RHEL 계열 Linux에서는 주로 RPM과 DNF를 이용해 패키지를 관리합니다. 과거 CentOS에서 많이 사용했던 YUM 역시 익숙한 명령어지만, 현재의 Rocky Linux에서는 DNF가 기본 패키지 관리 도구입니다.
이번 글에서는 Linux 패키지의 개념부터 RPM과 DNF의 차이, 패키지 설치와 삭제, 업데이트, 저장소 관리, 의존성 문제 해결, 실무에서 자주 사용하는 패키지 관리 방법까지 단계별로 알아보겠습니다.
Linux에서 패키지(Package)는 특정 프로그램을 설치하고 실행하는 데 필요한 파일들을 하나로 묶어 관리할 수 있도록 만든 소프트웨어 단위입니다.
예를 들어 Nginx를 설치한다고 생각해 보겠습니다.
단순히 실행 파일 하나만 설치한다고 해서 Nginx가 정상적으로 동작하는 것은 아닙니다.
프로그램 실행에 필요한 라이브러리, 설정 파일, 문서, 서비스 파일 등이 함께 필요할 수 있습니다.
패키지는 이러한 구성 요소를 체계적으로 관리할 수 있도록 만들어졌습니다.
대표적인 패키지 형식은 Linux 배포판에 따라 다음과 같이 구분됩니다.
RHEL / Rocky Linux / Fedora
→ RPM
Debian / Ubuntu
→ DEB
Rocky Linux 서버를 운영한다면 기본적으로 RPM 패키지와 DNF 패키지 관리 방법을 이해해야 합니다.
RPM은 Red Hat 계열 Linux에서 사용하는 패키지 관리 시스템입니다.
패키지 파일의 확장자는 일반적으로 .rpm입니다.
예를 들어 다음과 같은 파일이 있을 수 있습니다.
nginx-1.26.1-1.el9.x86_64.rpm
RPM 명령어를 사용하면 패키지의 설치, 삭제, 조회, 검증 등을 수행할 수 있습니다.
설치된 패키지를 확인하려면 다음 명령어를 사용할 수 있습니다.
rpm -qa
특정 패키지를 검색하려면
rpm -qa | grep nginx
를 사용할 수 있습니다.
설치된 패키지의 정보를 확인하려면
rpm -qi nginx
패키지에 포함된 파일 목록을 확인하려면
rpm -ql nginx
를 사용할 수 있습니다.
RPM과 DNF는 서로 경쟁하는 도구가 아니라 역할이 다릅니다.
RPM은 개별 패키지 파일을 직접 관리하는 저수준 패키지 관리 도구에 가깝습니다.
반면 DNF는 저장소(Repository)를 기반으로 필요한 패키지를 검색하고 설치하며 의존성을 자동으로 해결하는 고수준 패키지 관리 도구입니다.
예를 들어 RPM 패키지를 직접 설치할 경우 필요한 라이브러리가 추가로 필요하다면 사용자가 직접 의존성을 해결해야 할 수 있습니다.
반면 DNF는 저장소 정보를 이용하여 필요한 의존 패키지를 함께 찾아 설치합니다.
따라서 실제 서버 운영에서는 일반적인 소프트웨어 설치와 업데이트에 DNF를 사용하는 경우가 많습니다.
DNF는 RPM 기반 Linux 시스템에서 사용하는 패키지 관리 도구입니다.
Rocky Linux에서는 다음과 같은 작업에 DNF를 사용합니다.
패키지 검색
패키지 설치
패키지 삭제
패키지 업데이트
패키지 정보 확인
저장소 관리
의존성 해결
패키지 그룹 관리
가장 기본적인 명령어는 다음과 같습니다.
dnf --version
현재 시스템에서 DNF가 정상적으로 설치되어 있는지 확인할 수 있습니다.
프로그램을 설치하기 전에 먼저 저장소에서 해당 패키지가 제공되는지 확인하는 것이 좋습니다.
예를 들어 Nginx 패키지를 검색하려면 다음과 같이 합니다.
dnf search nginx
보다 정확하게 패키지 정보를 확인하려면
dnf info nginx
를 사용할 수 있습니다.
패키지 이름뿐만 아니라 버전과 저장소 정보 등을 확인할 수 있습니다.
실무에서는 바로 설치하기보다 먼저 검색과 정보 확인을 수행하는 습관을 들이는 것이 좋습니다.
Rocky Linux에서 Nginx를 설치하는 기본적인 방법은 다음과 같습니다.
sudo dnf install nginx
설치 과정에서 필요한 의존성 패키지가 있다면 DNF가 함께 확인합니다.
설치 여부를 묻는 메시지가 나타나면 내용을 확인한 후 진행할 수 있습니다.
설치가 완료된 후 패키지가 정상적으로 설치되었는지 확인합니다.
rpm -qa | grep nginx
또는
dnf list installed nginx
를 사용할 수 있습니다.
초보자가 자주 혼동하는 부분입니다.
다음 명령어는 Nginx 패키지를 설치합니다.
sudo dnf install nginx
하지만 패키지를 설치했다고 해서 반드시 서비스가 즉시 실행되는 것은 아닙니다.
서비스를 실행하려면 다음과 같이 해야 합니다.
sudo systemctl start nginx
정상적으로 실행되었는지 확인합니다.
sudo systemctl status nginx
서버가 재부팅된 이후에도 자동으로 실행하려면 다음과 같이 설정합니다.
sudo systemctl enable nginx
즉 다음 세 가지 작업을 구분해서 이해해야 합니다.
dnf install
→ 프로그램 설치
systemctl start
→ 현재 서비스 실행
systemctl enable
→ 부팅 시 자동 실행 설정
이 차이는 Linux 서버 운영에서 매우 중요합니다.
더 이상 사용하지 않는 패키지를 삭제할 수도 있습니다.
sudo dnf remove nginx
삭제 전에 어떤 패키지가 함께 제거되는지 확인하는 것이 좋습니다.
특히 운영 서버에서는 다른 프로그램이 해당 패키지를 의존하고 있을 수 있기 때문에 삭제 작업은 신중하게 수행해야 합니다.
패키지 삭제 후에도 설정 파일이나 별도의 데이터 디렉터리가 남을 수 있으므로 서비스별 파일 구조를 확인해야 합니다.
Linux 서버에서는 보안 취약점과 버그를 해결하기 위해 정기적인 패키지 업데이트가 필요합니다.
업데이트 가능한 패키지를 확인하려면 다음 명령어를 사용할 수 있습니다.
dnf check-update
전체 패키지를 업데이트하려면
sudo dnf update
또는
sudo dnf upgrade
를 사용할 수 있습니다.
실제 운영 서버에서는 무조건 즉시 전체 업데이트를 수행하기보다 변경 사항과 영향 범위를 확인한 후 작업하는 것이 좋습니다.
특히 커널, OpenSSL, glibc, 데이터베이스, 웹 서버 등 핵심 패키지의 업데이트는 서비스 영향 여부를 반드시 검토해야 합니다.
Linux 서버에서 패키지 업데이트는 단순히 최신 버전을 사용하는 것이 목적이 아닙니다.
보안 취약점을 해결하는 것이 중요한 목적 중 하나입니다.
예를 들어 오래된 웹 서버나 OpenSSL 라이브러리를 사용하는 경우 이미 알려진 취약점에 노출될 수 있습니다.
따라서 운영 서버에서는 다음과 같은 관리 체계를 만드는 것이 좋습니다.
패키지 목록 확인
↓
보안 업데이트 확인
↓
변경 사항 검토
↓
백업 확인
↓
테스트 서버 적용
↓
운영 서버 적용
↓
서비스 정상 여부 확인
특히 기업 환경에서는 패키지 업데이트 전에 변경 관리와 작업 계획을 수립하는 것이 중요합니다.
Linux에서 저장소(Repository)는 패키지를 제공하는 서버 또는 패키지 모음입니다.
DNF는 저장소에 등록된 패키지를 검색하고 필요한 패키지를 다운로드하여 설치합니다.
현재 활성화된 저장소를 확인하려면 다음 명령어를 사용할 수 있습니다.
dnf repolist
더 자세하게 확인하려면
dnf repolist all
을 사용할 수 있습니다.
Rocky Linux에서는 기본 저장소 외에도 특정 소프트웨어 설치를 위해 추가 저장소를 사용하는 경우가 있습니다.
하지만 운영 서버에서는 출처가 불분명한 저장소를 무분별하게 추가해서는 안 됩니다.
DNF 저장소 설정은 일반적으로 다음 위치에서 관리됩니다.
/etc/yum.repos.d/
해당 디렉터리의 파일을 확인합니다.
ls -l /etc/yum.repos.d/
저장소 설정 파일은 일반적으로 .repo 확장자를 사용합니다.
예를 들어 다음과 같은 형태입니다.
[repository-name]
name=Repository Name
baseurl=...
enabled=1
gpgcheck=1
gpgkey=...
여기서 enabled는 저장소 활성화 여부를 나타내며 gpgcheck는 패키지 서명을 검증하는 설정과 관련됩니다.
실무에서는 보안상의 이유로 패키지 출처와 서명 검증을 중요하게 관리해야 합니다.
프로그램은 혼자 동작하지 않는 경우가 많습니다.
예를 들어 프로그램 A가 특정 라이브러리를 필요로 한다면 해당 라이브러리도 설치되어 있어야 합니다.
이를 의존성(Dependency)이라고 합니다.
예를 들어 다음과 같은 관계가 있을 수 있습니다.
Nginx
├── Library A
├── Library B
└── Library C
직접 RPM 파일을 설치하다 보면 다음과 같은 오류가 발생할 수 있습니다.
failed dependencies
이러한 의존성 문제를 자동으로 해결하는 것이 DNF의 중요한 장점입니다.
따라서 특별한 이유가 없다면 RPM 파일을 직접 설치하는 것보다 신뢰할 수 있는 저장소에서 DNF를 이용해 설치하는 방법을 우선 고려하는 것이 좋습니다.
외부에서 .rpm 패키지를 전달받아 설치해야 하는 상황도 있습니다.
예를 들어 다음과 같은 파일이 있다고 가정하겠습니다.
example-1.0.0.x86_64.rpm
DNF를 이용해 로컬 RPM을 설치할 수 있습니다.
sudo dnf install ./example-1.0.0.x86_64.rpm
이 방법은 DNF가 가능한 의존성을 함께 처리할 수 있다는 장점이 있습니다.
RPM 명령어를 직접 사용하는 방법도 있습니다.
sudo rpm -ivh example-1.0.0.x86_64.rpm
하지만 의존성 문제가 발생하면 직접 해결해야 할 수 있습니다.
따라서 일반적인 상황에서는 다음과 같이 DNF를 이용하는 방법이 편리합니다.
sudo dnf install ./example.rpm
특정 패키지가 어떤 파일을 설치했는지 확인하는 것은 장애 분석에서 매우 중요합니다.
예를 들어 Nginx가 설치한 파일을 확인합니다.
rpm -ql nginx
특정 파일이 어떤 패키지에 포함되어 있는지도 확인할 수 있습니다.
rpm -qf /usr/sbin/nginx
이 기능은 서버에서 특정 파일이 어느 패키지에 의해 설치되었는지 확인할 때 유용합니다.
현재 설치된 패키지 버전을 확인하려면 다음과 같이 합니다.
rpm -q nginx
또는
dnf list installed nginx
예를 들어 다음과 같이 표시될 수 있습니다.
nginx.x86_64 1.x.x ...
운영 서버에서는 소프트웨어 버전을 기록해 두는 것이 좋습니다.
장애가 발생했을 때 서버마다 패키지 버전이 다른지 비교할 수 있기 때문입니다.
DNF는 다운로드한 패키지 관련 데이터를 캐시로 관리합니다.
캐시를 정리해야 하는 상황에서는 다음 명령어를 사용할 수 있습니다.
sudo dnf clean all
이후 저장소 메타데이터가 다시 필요한 경우 DNF가 저장소 정보를 다시 가져올 수 있습니다.
저장소 정보가 이상하거나 패키지 검색 결과가 정상적이지 않을 때 캐시 문제를 의심할 수 있습니다.
다만 운영 서버에서 무조건 캐시를 삭제할 필요는 없습니다.
문제가 발생했을 때 원인을 확인한 후 필요한 경우 사용하는 것이 좋습니다.
Linux에서는 여러 관련 패키지를 하나의 그룹으로 묶어 제공하기도 합니다.
그룹 목록을 확인하려면 다음과 같이 합니다.
dnf group list
그룹 정보를 확인한 후 필요한 경우 그룹 단위로 설치할 수 있습니다.
sudo dnf group install "Development Tools"
개발 도구나 컴파일 환경을 구성할 때 유용합니다.
다만 서버에는 필요한 소프트웨어만 설치하는 것이 보안과 관리 측면에서 유리하므로 무조건 많은 패키지를 설치하는 것은 피해야 합니다.
패키지 관리에서 가장 중요한 원칙 중 하나는 필요한 소프트웨어만 설치하는 것입니다.
사용하지 않는 프로그램이 많이 설치되어 있을수록 관리해야 할 패키지가 증가하고 잠재적인 취약점도 늘어날 수 있습니다.
예를 들어 웹 서버 역할만 수행하는 서버라면 필요하지 않은 개발 도구나 데스크톱 환경 등을 설치할 필요가 없습니다.
서버 구축 시 다음과 같은 원칙을 적용할 수 있습니다.
필요한 패키지만 설치
불필요한 서비스 제거
정기적인 보안 업데이트
패키지 출처 확인
패키지 버전 관리
변경 작업 기록
업데이트 전 백업
이러한 기본 원칙만 지켜도 서버 관리의 안정성을 크게 높일 수 있습니다.
패키지 업데이트가 끝났다고 작업이 완전히 끝난 것은 아닙니다.
특히 서버에서는 업데이트 이후 서비스가 정상적으로 동작하는지 확인해야 합니다.
예를 들어 Nginx를 업데이트했다면 다음과 같이 확인할 수 있습니다.
nginx -t
서비스 상태를 확인합니다.
systemctl status nginx
로그도 확인합니다.
journalctl -u nginx -n 50
포트가 정상적으로 열려 있는지도 확인할 수 있습니다.
ss -lntp
웹 서버라면 실제 HTTP 요청을 통해 서비스가 정상적으로 응답하는지도 확인하는 것이 좋습니다.
즉 패키지 업데이트는 다음과 같이 생각해야 합니다.
업데이트
→ 서비스 확인
→ 로그 확인
→ 포트 확인
→ 실제 서비스 확인
Linux 시스템 엔지니어라면 다음 명령어는 기본적으로 익혀두는 것이 좋습니다.
패키지 검색:
dnf search nginx
패키지 정보:
dnf info nginx
패키지 설치:
sudo dnf install nginx
패키지 삭제:
sudo dnf remove nginx
패키지 업데이트:
sudo dnf update
설치된 패키지 확인:
dnf list installed
특정 패키지 확인:
rpm -q nginx
패키지 파일 목록:
rpm -ql nginx
파일이 어느 패키지에 속하는지 확인:
rpm -qf /usr/sbin/nginx
저장소 확인:
dnf repolist
실패한 패키지 작업을 다시 확인하거나 의존성 문제를 분석할 때는 DNF 출력 메시지를 자세히 확인하는 습관이 중요합니다.
실제 서버에서 새로운 소프트웨어를 설치할 때는 단순히 dnf install만 실행하는 것보다 다음과 같은 절차를 권장합니다.
먼저 서버의 OS와 버전을 확인합니다.
cat /etc/os-release
CPU 아키텍처도 확인할 수 있습니다.
uname -m
현재 저장소를 확인합니다.
dnf repolist
설치하려는 패키지를 검색합니다.
dnf search 패키지명
패키지 정보를 확인합니다.
dnf info 패키지명
그다음 설치합니다.
sudo dnf install 패키지명
설치가 완료되면 버전을 확인합니다.
rpm -q 패키지명
서비스형 프로그램이라면 실행 상태를 확인합니다.
systemctl status 서비스명
마지막으로 로그와 실제 서비스를 확인합니다.
이러한 절차를 습관화하면 서버 구축 과정에서 발생하는 문제를 줄일 수 있습니다.
운영 서버에서는 패키지 업데이트를 단순한 명령어 실행으로 생각해서는 안 됩니다.
특히 다음과 같은 패키지는 서비스에 큰 영향을 줄 수 있습니다.
Linux Kernel
glibc
OpenSSL
OpenSSH
systemd
Python
Java
PostgreSQL
MariaDB
Nginx
Apache
Docker
이러한 핵심 패키지를 업데이트할 때는 현재 운영 중인 애플리케이션과 호환되는지 확인해야 합니다.
또한 커널 업데이트가 포함된 경우 재부팅이 필요한지 확인해야 합니다.
따라서 운영 환경에서는 테스트 서버에서 먼저 업데이트한 후 운영 서버에 적용하는 방식이 가장 안전합니다.
Linux 패키지 관리는 단순히 프로그램을 설치하는 기술이 아닙니다.
시스템 엔지니어는 다음 내용을 이해해야 합니다.
RPM
DNF
Repository
Dependency
Package Version
Security Update
Package Configuration
Service
Log
Rollback
특히 “어떤 패키지를 설치했는가”, “어떤 버전을 사용하고 있는가”, “어떤 저장소에서 가져왔는가”를 관리할 수 있어야 합니다.
대규모 서버 환경에서는 수십 대에서 수백 대 이상의 서버가 동일한 패키지 정책을 사용하기 때문에 패키지 버전 관리와 자동화가 더욱 중요해집니다.
이후 Ansible과 같은 자동화 도구를 사용하면 여러 서버에 동일한 패키지를 설치하고 업데이트하는 작업도 자동화할 수 있습니다.
Linux 서버에서 소프트웨어를 설치하고 관리하는 것은 시스템 엔지니어의 기본 업무 중 하나입니다.
Rocky Linux에서는 RPM과 DNF를 중심으로 패키지를 관리하며, 일반적인 소프트웨어 설치와 업데이트에는 DNF를 사용하는 것이 편리합니다.
RPM은 개별 패키지의 정보와 파일을 확인하거나 직접 패키지를 관리할 때 유용하고, DNF는 저장소를 기반으로 패키지 설치와 의존성 해결, 업데이트 등을 수행하는 데 적합합니다.
특히 실무에서는 다음 흐름을 기억하는 것이 중요합니다.
패키지 검색
→ 패키지 정보 확인
→ 저장소 확인
→ 패키지 설치
→ 버전 확인
→ 서비스 실행
→ 로그 확인
→ 정상 동작 확인
그리고 운영 서버에서는 최신 버전을 무조건 설치하는 것보다 안정성과 호환성을 고려해야 합니다.
패키지 업데이트 역시 테스트 환경에서 먼저 검증하고, 운영 서버에 적용한 후 서비스 상태와 로그까지 확인하는 것이 안전합니다.
Linux 패키지 관리에 익숙해지면 Nginx, PostgreSQL, MariaDB, Docker와 같은 다양한 서버 소프트웨어를 안정적으로 설치하고 관리할 수 있게 됩니다.