같은 “패키지를 설치한다”는 동작인데 배포판마다 명령어가 apt install, dnf install, pacman -S, zypper install로 전부 달라요. 데비안 계열, 레드햇 계열, 아치 계열의 철학 차이를 다룬 글에서 큰 그림을 살펴봤다면, 이번엔 실제로 손가락이 기억해야 할 명령어 차원의 이야기예요. 계열을 옮길 때 가장 먼저 부딪히는 벽인 이 패키지 관리자들, 정확히 뭐가 어떻게 다를까요?
4대 패키지 관리자를 한눈에 비교하면 이렇다
APT, DNF, Pacman, Zypper는 저장소 갱신부터 패키지 검색까지 동일한 작업을 각자 다른 명령어로 표현해요.
| 작업 | APT (Debian/Ubuntu) | DNF (Fedora/RHEL) | Pacman (Arch) | Zypper (openSUSE) |
|---|---|---|---|---|
| 저장소 정보 갱신 | apt update | dnf check-update | pacman -Sy | zypper refresh |
| 패키지 설치 | apt install pkg | dnf install pkg | pacman -S pkg | zypper install pkg |
| 전체 업그레이드 | apt upgrade | dnf upgrade | pacman -Syu | zypper update |
| 패키지 제거 | apt remove pkg | dnf remove pkg | pacman -R pkg | zypper remove pkg |
| 패키지 검색 | apt search pkg | dnf search pkg | pacman -Ss pkg | zypper search pkg |
| 설치된 패키지 정보 | apt show pkg | dnf info pkg | pacman -Qi pkg | zypper info pkg |
설계 철학은 겉보기보다 훨씬 다르다
같은 “패키지 설치”라는 목적이라도 내부 동작 방식은 상당히 달라요.
- APT:
.deb패키지를 다루며, 의존성 해결에 있어 가장 보수적이고 안정성을 우선해요. 저장소 갱신(update)과 실제 업그레이드(upgrade)가 명확히 분리되어 있어요. - DNF:
.rpm기반이며, 예전 YUM의 후속으로 의존성 해결 알고리즘(libsolv)이 크게 개선됐어요. 트랜잭션 단위로 설치·롤백 이력을 관리해요. - Pacman: 저장소 동기화와 업그레이드를
-Syu한 명령으로 동시에 처리하는 게 관례예요. 이진 형태가 단순해 속도가 빠르지만, 그만큼 사용자가 직접 결과를 확인하는 습관이 중요해요. - Zypper: RPM 기반이지만 SUSE 고유의 의존성 해결 엔진을 사용하며, 트랜잭션 롤백과 Btrfs 스냅샷 연동이 특히 매끄러워요.
자주 겪는 실수는 계열마다 패턴이 있다
- Pacman을 부분 업그레이드로 쓰는 것:
pacman -Sy pkg처럼 저장소만 갱신하고 전체 업그레이드 없이 특정 패키지만 설치하면 의존성 불일치로 시스템이 깨질 수 있어요. Arch 진영에서 “부분 업그레이드 금지”가 거의 규칙처럼 통용되는 이유예요. - APT의 update와 upgrade를 헷갈리는 것:
apt update는 저장소 목록만 최신화할 뿐 실제 패키지는 그대로예요. 실제 업그레이드는 반드시apt upgrade를 따로 실행해야 해요. - DNF/Zypper에서 캐시 정리를 잊는 것: 트랜잭션 기록과 캐시가 쌓이면서 디스크 공간을 차지하므로,
dnf autoremove나zypper clean같은 정리 명령을 주기적으로 실행해야 해요.
가장 흔한 실수는 계열을 옮기면서 예전 습관을 그대로 새 명령어에 적용하는 것이에요. 특히 Pacman의 부분 업그레이드 금지 규칙은 Arch를 처음 쓰는 사람이 가장 자주 걸려 넘어지는 함정이에요.
프론트엔드 도구가 명령어를 더 편하게 만들어준다
각 패키지 관리자 위에는 더 사용자 친화적인 프론트엔드가 얹히기도 해요.
- nala: Debian/Ubuntu에서 APT의 출력을 보기 좋게 재구성해줘요.
- GNOME Software: Fedora에서 DNF를 GUI로 감싸서 명령줄 없이도 패키지를 관리할 수 있게 해줘요.
- yay, paru: Arch에서 Pacman을 확장해 커뮤니티 저장소(AUR)까지 다룰 수 있게 해주는 AUR 헬퍼예요.
결국 어떤 계열이든 흐름은 같다
패키지 관리자는 배포판을 고르는 데 있어 겉으로는 사소해 보이지만, 매일 손으로 치는 명령어이기 때문에 실사용 만족도에 미치는 영향이 생각보다 커요. 어떤 계열이든 결국 “저장소 갱신 → 검색 → 설치 → 제거”라는 동일한 흐름을 각자의 문법으로 표현할 뿐이라서, 하나에 익숙해지면 나머지도 금방 손에 붙어요. 특히 Zypper처럼 스냅샷 기반 롤백까지 통합된 openSUSE 환경에 익숙해지면, 다른 계열에서도 비슷한 안전망을 찾게 될 정도예요. Flatpak이나 Snap처럼 배포판을 가리지 않는 앱 형식까지 함께 알아두면, 계열이 달라져도 소프트웨어 설치 자체는 오히려 더 간단해지는 경우도 많아요.
자주 묻는 질문
Q1. apt update만 실행하면 패키지도 최신으로 바뀌나요?
아니요, apt update는 저장소 목록만 최신화할 뿐이고 실제 패키지를 최신으로 바꾸려면 apt upgrade를 별도로 실행해야 해요.
Q2. pacman -Sy로 특정 패키지만 설치해도 되나요?
권장하지 않아요. 저장소만 갱신하고 전체 업그레이드 없이 특정 패키지만 설치하면 의존성 불일치로 시스템이 깨질 수 있어서, Arch 진영에서는 부분 업그레이드를 금지하는 게 관례예요.
Q3. Zypper는 Btrfs 스냅샷과 잘 연동되나요?
네, SUSE 고유의 의존성 해결 엔진을 쓰면서 트랜잭션 롤백과 Btrfs 스냅샷 연동이 특히 매끄럽게 통합되어 있어요.
Q4. 패키지 관리자 캐시가 쌓이면 어떻게 하나요?
dnf autoremove나 zypper clean 같은 정리 명령을 주기적으로 실행해서 트랜잭션 기록과 캐시가 디스크 공간을 차지하지 않도록 관리해야 해요.
Q5. 명령어를 더 편하게 쓸 방법이 있나요?
네, nala(APT), GNOME Software(DNF GUI), yay/paru(Pacman + AUR) 같은 프론트엔드 도구가 각 패키지 관리자를 더 사용자 친화적으로 감싸줘요.
BFQ 비디오 재생 벤치마크: 반응성을 높인 대가로 프레임이 얼마나 떨어졌나
BFQ+의 low-latency 휴리스틱이 반응성을 높이는 대신 소프트 실시간 애플리케이션에 어떤 지연 시간 대가를 요구하는지 논문의 비디오 재생 벤치마크로 확인합니다.
NCQ가 켜지면 디스크 스케줄러 보장이 무너지는 이유 (BFQ 논문 실측)
Native Command Queueing이 활성화되면 BFQ, CFQ 같은 OS 스케줄러의 공정성·지연 보장이 어떻게 무력화되는지 논문의 실측 데이터로 설명합니다.
BFQ+ vs BFQ vs CFQ 실측 벤치마크: 처리량과 앱 기동 시간 비교
BFQ 논문이 세 대의 리눅스 시스템에서 실측한 집계 처리량과 bash·konsole 기동 시간 벤치마크 결과를 수치 그대로 정리합니다.