Linux에서 의존성 오류로 설치되지 않을 때의 원인과 해결 방법

Linux에서 소프트웨어를 설치하려고 할 때 “의존성을 해결할 수 없음”, “필요한 패키지를 찾을 수 없음”, “충돌하는 패키지가 있음” 같은 오류가 나타나면서 설치가 중단되는 경우가 많습니다. 이것은 단순히 어떤 앱 하나가 설치되지 않는 문제가 아니라, 시스템 전체의 패키지 상태가 이미 어긋나 있을 수 있다는 뜻입니다. apt, dnf, pacman 같은 패키지 관리자는 라이브러리, 런타임, 보조 패키지가 서로 맞는 조합으로 존재한다는 전제에서 동작하기 때문에, 어느 한 부분의 버전이나 출처가 맞지 않으면 전체 설치가 중단됩니다.

중요한 점은 의존성 오류를 “하나만 더 설치하면 끝나는 문제”로 가볍게 보면 안 된다는 것입니다. 실제 원인은 손상된 캐시, 오래된 저장소 설정, 서드파티 저장소 혼합, 중간에 끊긴 업데이트, 부분 업데이트, hold 된 패키지, 아키텍처 불일치 등 매우 다양할 수 있습니다. 그래서 무작정 파일을 지우거나, 출처가 불분명한 .deb / .rpm 파일을 인터넷에서 받아 강제로 설치하는 방식은 오히려 문제를 더 키우기 쉽습니다.

의존성 오류란 무엇인가

Linux의 대부분의 패키지는 혼자서 동작하지 않습니다. 어떤 프로그램은 특정 버전의 SSL 라이브러리, Python 런타임, GUI 라이브러리, 오디오 관련 라이브러리 등을 필요로 할 수 있습니다. 이런 필수 요소가 없거나 버전이 맞지 않으면 패키지 관리자는 시스템 일관성을 위해 설치를 거부합니다.

즉, 의존성 오류는 단순히 “뭔가 하나가 없다”는 의미만이 아니라, 여러 조건이 동시에 성립할 수 없거나, 서로 충돌하는 패키지가 있거나, 버전 조합이 깨져 있는 상태 전체를 뜻할 수 있습니다.

자주 나타나는 증상

• Depends:, requires, unresolved dependency 같은 메시지가 나온다
• “깨진 패키지가 있음”, “의존성을 해결할 수 없음” 같은 오류가 나온다
• 하나의 패키지를 설치하려는데 다른 패키지를 지우라고 한다
• 특정 라이브러리 버전이 부족하거나 맞지 않는다고 나온다
• 업데이트 이후부터 설치만 실패하기 시작한다
• 서드파티 저장소를 추가한 뒤 의존성 충돌이 시작된다
• 일부만 업데이트한 이후 전체 패키지 상태가 꼬인다

가장 먼저 확인해야 할 것

겉으로는 의존성 오류처럼 보여도 실제로는 네트워크, DNS, 미러 접속 실패 때문에 필요한 패키지를 가져오지 못한 것일 수 있습니다. 먼저 네트워크와 패키지 목록 갱신이 정상인지 확인해야 합니다.

ping -c 4 8.8.8.8
ping -c 4 google.com
ip addr
ip route

그다음 패키지 목록 갱신이 제대로 되는지 봅니다.

sudo apt update
sudo dnf makecache
sudo pacman -Sy

여기서 404, 이름 해석 실패, 서명 오류, 미러 timeout 같은 것이 나온다면, 실제 문제는 의존성 자체가 아니라 패키지 정보를 가져오는 과정일 수 있습니다.

의존성 오류의 주요 원인

1. 저장소 혼용

가장 대표적인 원인 중 하나입니다. 공식 저장소, 오래된 PPA, 다른 배포판용 저장소, 테스트 저장소, 각종 서드파티 저장소를 섞으면 같은 패키지 이름이어도 서로 다른 버전과 의존 조건이 들어옵니다. 결국 한 패키지는 새 라이브러리를 원하고, 다른 패키지는 옛 라이브러리를 원해서 동시에 만족할 수 없는 상태가 됩니다.

2. 중간에 끊긴 업데이트

업데이트 도중 전원이 꺼지거나, 터미널이 닫히거나, SSH 연결이 끊기거나, GUI가 멈추면 일부 패키지는 새 버전이 되고 일부는 예전 상태로 남을 수 있습니다. 이런 반쯤 업데이트된 상태가 의존성 오류의 매우 흔한 원인입니다.

3. 부분 업데이트

특히 Arch Linux 계열에서 심각하게 다뤄지는 문제입니다. 일부 패키지만 업데이트하고 나머지는 오래된 상태로 두면 라이브러리 버전 불일치가 발생합니다. Debian / Ubuntu 나 Fedora 계열에서도 핵심 패키지를 일부만 강제로 올리면 비슷한 문제가 생길 수 있습니다.

4. hold 되었거나 버전이 고정된 패키지

특정 패키지가 업데이트되지 않도록 hold 되어 있거나, 버전이 고정되어 있으면 다른 패키지가 그에 맞춰 올라갈 수 없어 전체 의존 관계가 막히는 경우가 있습니다.

5. 수동 설치한 패키지와의 충돌

.deb, .rpm 파일을 직접 설치했거나, 소스에서 수동으로 라이브러리를 넣었거나, /usr/local 등에 별도 버전을 넣은 경우 패키지 관리자가 인식하는 상태와 실제 파일 상태가 달라질 수 있습니다. 이 차이가 의존성 문제나 파일 충돌로 이어질 수 있습니다.

6. 패키지 간 충돌

모든 의존성 오류가 “무언가가 부족하다”는 뜻은 아닙니다. 두 패키지가 동시에 설치될 수 없거나 같은 파일을 제공하는 경우처럼, 실제로는 부족이 아니라 충돌 때문에 멈추는 경우도 많습니다.

7. 아키텍처 불일치

64비트 환경에서 32비트 의존성을 불완전하게 섞거나, ARM 패키지를 x86_64 시스템에 넣으려는 경우처럼 아키텍처가 맞지 않으면 패키지가 존재해도 의존성이 충족되지 않은 것으로 처리됩니다.

8. 캐시나 메타데이터 불일치

오래된 패키지 목록, 손상된 캐시, 동기화가 어긋난 미러 정보 때문에 실제로는 존재하는 의존 패키지를 패키지 관리자가 제대로 찾지 못할 수 있습니다.

apt 계열에서 확인할 점

Debian / Ubuntu 계열에서는 apt 뿐 아니라 그 아래 계층인 dpkg 상태까지 보는 것이 중요합니다.

미완료 상태 복구

sudo dpkg --configure -a
sudo apt --fix-broken install

중간에 끊긴 업데이트가 원인이라면, 이 두 명령이 가장 기본적인 시작점입니다.

hold 패키지 확인

apt-mark showhold

hold 된 패키지가 전체 의존 관계를 막는 경우가 많습니다.

버전 후보 확인

apt-cache policy 패키지명

어떤 저장소에서 어떤 버전이 들어오는지 확인하면 혼합 저장소 문제를 찾기 쉬워집니다.

dnf 계열에서 확인할 점

Fedora / RHEL 계열에서는 시스템 일관성과 트랜잭션 이력이 중요합니다.

현재 상태 확인

sudo dnf check

시스템 전체에 걸쳐 만족되지 않는 의존 조건을 확인할 수 있습니다.

배포판 상태에 맞게 동기화

sudo dnf distro-sync

너무 앞선 버전과 뒤처진 버전이 섞여 있을 때 정상적인 배포 상태로 맞추는 데 도움이 됩니다.

미충족 의존성 확인

sudo dnf repoquery --unsatisfied

어떤 조건이 채워지지 않았는지 보다 명확히 볼 수 있습니다.

pacman 계열에서 확인할 점

Arch Linux 계열에서는 전체 시스템의 일관성을 회복하는 것이 핵심입니다.

전체 업데이트

sudo pacman -Syu

이미 의존성 오류가 나온 상태에서 특정 패키지만 따로 업데이트하는 것은 문제를 더 악화시키기 쉽습니다.

동기화 데이터베이스 갱신

sudo pacman -Syy

로컬 메타데이터가 미러 상태와 어긋난 경우 필요합니다.

로그 확인이 매우 중요함

의존성 오류는 마지막 한 줄만 보면 본질을 알기 어렵습니다. 어떤 패키지가 어떤 버전을 요구했고, 어떤 후보가 왜 거절되었는지를 봐야 합니다.

apt / dpkg

sudo tail -n 100 /var/log/apt/history.log
sudo tail -n 100 /var/log/dpkg.log

dnf

sudo journalctl -xe --no-pager | tail -n 100
sudo dnf history

pacman

sudo tail -n 100 /var/log/pacman.log

실전 점검 순서

1단계: 네트워크와 저장소 접근 확인

ping -c 4 8.8.8.8
ping -c 4 google.com

2단계: 패키지 목록 새로고침

sudo apt update
sudo dnf makecache
sudo pacman -Syy

3단계: 중간 상태 복구

apt 는 dpkg --configure -a, dnf 는 dnf check, pacman 은 전체 동기화 원칙으로 접근합니다.

4단계: 문제 패키지의 버전과 출처 확인

어느 저장소에서 오고 있는지, 어떤 버전 후보가 있는지, hold 상태는 아닌지를 봅니다.

5단계: 서드파티 저장소와 오래된 설정 의심

많은 의존성 오류는 결국 공식이 아닌 저장소 혼합에서 시작됩니다.

하면 안 되는 것

• 오류를 읽지 않고 부족해 보이는 패키지를 닥치는 대로 설치하는 것
• 수상한 사이트에서 개별 .deb / .rpm 을 받아 설치하는 것
• 부분 업데이트를 반복해서 더 꼬이게 만드는 것
• 서명 검증이나 의존성 검사를 함부로 끄는 것
• 원인을 모른 채 서드파티 저장소를 더 늘리는 것

재발 방지 포인트

• 공식 저장소 중심으로 운영하기
• 오래된 PPA 나 잘못된 저장소를 남겨두지 않기
• 업데이트 중간에 강제 종료하지 않기
• Arch 계열에서는 부분 업데이트를 하지 않기
• 큰 변경 전에는 스냅샷이나 백업 만들기

정리

Linux에서 의존성 오류 때문에 설치되지 않을 때는 단순히 “라이브러리 하나가 부족하다” 수준이 아니라, 저장소 혼합, 업데이트 중단, 부분 업데이트, hold 패키지, 수동 설치 라이브러리, 아키텍처 충돌 같은 더 큰 일관성 문제가 숨어 있는 경우가 많습니다. 핵심은 오류 메시지를 자세히 읽고, 어떤 패키지가 어떤 버전을 요구하며 왜 충족되지 않는지 이해하는 것입니다. 그 뒤 apt 계열은 dpkg --configure -a 와 apt --fix-broken install, dnf 계열은 dnf check 와 distro-sync, pacman 계열은 전체 동기화와 완전 업데이트를 중심으로 시스템을 다시 일관된 상태로 돌리는 것이 안전한 방법입니다.