帮助中心

적용 환경

이 문서에서 알아볼 내용

• 오류가 발생한 저장소와 실제 오류 메시지 확인
• 디스크 공간, DNS, 네트워크, 시간 및 TLS 인증서 점검
• DNF 메타데이터 캐시 삭제와 강제 재생성
• 공식 저장소와 외부 저장소를 분리하여 원인 확인
• CentOS Stream 10 공식 저장소 설정 파일 검증 및 복구
• 정상 작동 확인, 재발 방지 및 원상복구

오류 저장소와 메시지 확인

먼저 모든 저장소를 한꺼번에 수정하지 말고 어느 저장소에서 어떤 오류가 발생하는지 확인합니다. 다음 명령은 활성화된 저장소의 메타데이터를 강제로 새로 확인하면서 상세 정보를 표시합니다.

sudo dnf -v --refresh makecache

출력에서 repository '저장소_ID' 또는 repo: 저장소_ID와 함께 표시되는 URL, HTTP 상태 코드, Curl 오류 번호를 기록합니다. 오류가 길어 확인하기 어렵다면 DNF 로그의 최근 내용을 확인합니다.

sudo tail -n 100 /var/log/dnf.log /var/log/dnf.librepo.log 2>/dev/null

현재 등록된 저장소와 활성화 상태도 확인합니다.

dnf repolist --all

가장 먼저 확인할 항목

1. 운영체제와 DNF 버전 확인

서버가 실제로 CentOS Stream 10인지 확인합니다. 다른 배포판 또는 이전 CentOS Stream 버전의 저장소 파일을 혼용하면 404 오류나 의존성 문제가 발생할 수 있습니다.

cat /etc/os-release
dnf --version
rpm -E '%{rhel}'
uname -m

/etc/os-release에서 CentOS Stream 10을 확인하고, rpm -E '%{rhel}' 결과는 10이어야 합니다. 아키텍처는 일반적인 서버에서 x86_64, ARM 서버에서는 aarch64로 표시될 수 있습니다.

CentOS Stream 저장소 변수 파일이 존재한다면 값도 확인합니다.

sudo cat /etc/dnf/vars/stream 2>/dev/null

CentOS Stream 10에서는 일반적으로 10-stream이 표시됩니다. 값이 9-stream이거나 파일을 임의로 수정한 이력이 있다면 공식 저장소 패키지를 복구해야 합니다.

2. 디스크 공간과 inode 확인

DNF는 메타데이터를 /var/cache/dnf에 내려받고 압축을 해제합니다. 디스크 공간이나 inode가 부족하면 네트워크가 정상이어도 메타데이터 생성에 실패할 수 있습니다.

df -h / /var /tmp
df -i / /var /tmp
sudo du -sh /var/cache/dnf 2>/dev/null

Use% 또는 IUse%가 100%에 가깝다면 먼저 불필요한 로그와 임시 파일을 안전하게 정리한 뒤 DNF 복구를 진행합니다.

3. 시스템 시간 확인

시스템 시간이 크게 틀리면 HTTPS 인증서의 유효 기간 검증에 실패하여 Curl error 60 또는 인증서 오류가 발생할 수 있습니다.

timedatectl status
systemctl is-active chronyd 2>/dev/null
chronyc tracking 2>/dev/null

시간이 잘못되었다면 NTP 동기화와 네트워크 상태를 먼저 복구합니다. 단순히 인증서 검증을 끄는 방법으로 우회하지 마십시오.

DNF 메타데이터 캐시 초기화

서버의 네트워크와 디스크 상태가 정상이라면 손상되거나 오래된 로컬 메타데이터를 먼저 삭제합니다. DNF 공식 명령인 clean all은 저장소 메타데이터, 생성된 캐시 데이터와 내려받은 패키지 캐시를 정리합니다.

sudo dnf clean all

활성화된 저장소에서 메타데이터를 강제로 다시 내려받습니다.

sudo dnf --refresh makecache

정상이라면 각 저장소의 메타데이터가 내려받아지고 마지막에 캐시 생성 완료 메시지가 표시됩니다. 동일한 오류가 계속되면 캐시만의 문제가 아니므로 다음 단계에서 저장소별로 원인을 분리합니다.

DNF 캐시 디렉터리를 직접 초기화해야 하는 경우

dnf clean all 후에도 손상된 파일 관련 오류나 권한 오류가 계속될 때만 /var/cache/dnf의 내용을 직접 비웁니다. 이 디렉터리는 다시 생성할 수 있는 캐시이며 설치된 RPM 데이터베이스가 아닙니다.

ps -ef | grep -E '[d]nf|[r]pm'
sudo rm -rf /var/cache/dnf/*
sudo dnf --refresh makecache

캐시 경로를 비운 뒤 DNF가 새 디렉터리와 메타데이터를 정상적으로 생성하는지 확인합니다.

문제 저장소 분리

외부 저장소 하나가 중단되어도 기본 dnf update 전체가 실패할 수 있습니다. 먼저 CentOS Stream 10 공식 핵심 저장소만 활성화하여 메타데이터를 생성합니다.

sudo dnf --disablerepo='*' \
  --enablerepo=baseos,appstream \
  --refresh makecache

이 명령이 성공하면 CentOS 공식 저장소는 정상이며, EPEL이나 벤더 저장소 등 다른 저장소가 원인일 가능성이 높습니다. 오류 출력에서 확인한 저장소를 한 번만 제외하고 다시 실행합니다.

sudo dnf --disablerepo='문제_저장소_ID' --refresh makecache

문제_저장소_ID는 실제 오류에 표시된 ID로 변경합니다. 예를 들어 docker-ce-stable이 실패했다면 해당 저장소만 일시적으로 제외합니다.

외부 저장소를 영구적으로 비활성화

해당 저장소가 CentOS Stream 10을 지원하지 않거나 더 이상 사용하지 않는 저장소라면 설정을 백업한 뒤 비활성화합니다. dnf config-manager가 설치되어 있다면 다음 명령을 사용할 수 있습니다.

sudo cp -a /etc/yum.repos.d "/root/yum.repos.d.backup-$(date +%Y%m%d-%H%M%S)"
sudo dnf config-manager --set-disabled '문제_저장소_ID'

config-manager 명령을 찾을 수 없다면 해당 .repo 파일을 열고 문제 저장소 섹션의 enabled=1을 enabled=0으로 변경합니다. 파일을 삭제하기보다 백업 후 비활성화하는 방법이 원상복구에 유리합니다.

저장소 파일에 이전 버전 경로가 남아 있는지 점검합니다.

sudo grep -RniE '8-stream|9-stream|el8|el9' /etc/yum.repos.d/

검색 결과가 모두 오류라는 의미는 아니지만 CentOS Stream 10에서 사용하는 저장소가 맞는지 공급자 공식 문서와 대조해야 합니다.

DNS·프록시·TLS 오류 해결

1. DNS 조회 확인

Curl error (6): Could not resolve hostname 또는 Couldn't resolve host name이 표시되면 저장소 설정을 수정하기 전에 DNS부터 확인합니다.

getent ahosts mirrors.centos.org
getent ahosts mirror.stream.centos.org
nmcli dev show | grep -i 'IP4.DNS\|IP6.DNS' 2>/dev/null
cat /etc/resolv.conf

호스트 주소가 출력되지 않으면 서버의 DNS 설정, 기본 경로, 보안그룹 또는 상위 네트워크의 UDP·TCP 53번 통신을 점검합니다. /etc/resolv.conf를 임시로 덮어쓰기 전에 NetworkManager가 관리하는 설정인지 확인하십시오.

2. CentOS metalink와 직접 미러 연결 확인

CentOS Stream 10 공식 저장소는 일반적으로 mirrors.centos.org의 metalink를 사용합니다. 먼저 metalink 서버에 HTTPS 연결이 가능한지 확인합니다.

curl -I --connect-timeout 10 'https://mirrors.centos.org/'

metalink 경로 문제와 DNF 자체 문제를 구분하려면 CentOS 공식 직접 미러의 repomd.xml에도 연결해 봅니다.

ARCH=$(rpm --eval '%{_arch}')
curl -I --connect-timeout 10 \
  "https://mirror.stream.centos.org/10-stream/BaseOS/${ARCH}/os/repodata/repomd.xml"

직접 미러는 응답하지만 metalink만 실패하면 DNS 필터, 프록시, 방화벽 또는 특정 도메인 차단을 점검합니다. 직접 미러 URL을 영구 저장소로 바꾸는 작업은 미러 장애 분산 기능을 잃게 되므로 임시 진단 목적으로만 사용하는 것이 좋습니다.

3. 프록시 설정 확인

이전 프록시 주소나 인증정보가 남아 있으면 DNF만 저장소에 연결하지 못할 수 있습니다. 셸 환경변수와 DNF 설정을 함께 확인합니다.

env | grep -iE '^(http|https|no)_proxy='
sudo grep -RniE '^[[:space:]]*proxy[[:space:]]*=' \
  /etc/dnf/dnf.conf /etc/yum.repos.d/*.repo 2>/dev/null

사용하지 않는 프록시가 설정되어 있다면 백업 후 제거합니다. 조직의 TLS 검사 프록시를 사용한다면 프록시가 발급하는 루트 CA를 시스템 신뢰 저장소에 올바르게 등록해야 합니다.

4. CA 인증서와 TLS 확인

Curl error (60), SSL certificate problem 또는 인증서 체인 오류가 표시되면 시스템 시간과 CA 패키지 상태를 확인합니다.

rpm -q ca-certificates
sudo update-ca-trust extract
curl -Iv --connect-timeout 10 'https://mirrors.centos.org/'

CentOS Stream 10 공식 저장소 설정 복구

baseos와 appstream도 모두 실패하고 저장소 URL이나 GPG 키 경로가 임의로 변경된 흔적이 있다면 CentOS 공식 저장소 패키지의 파일 상태를 확인합니다.

1. 저장소 파일 백업

sudo cp -a /etc/yum.repos.d "/root/yum.repos.d.backup-$(date +%Y%m%d-%H%M%S)"

생성된 백업 경로를 기록해 둡니다. 이후 저장소 파일을 편집하거나 패키지를 재설치하기 전에 반드시 백업이 존재하는지 확인합니다.

2. 공식 저장소 패키지와 파일 검증

rpm -q centos-stream-release centos-stream-repos centos-gpg-keys
rpm -V centos-stream-release centos-stream-repos centos-gpg-keys

첫 번째 명령에서 세 패키지가 모두 설치된 상태인지 확인합니다. rpm -V는 파일이 패키지 원본과 같으면 일반적으로 아무것도 출력하지 않습니다. missing 또는 변경 표시가 나오면 해당 파일이 삭제되거나 수정된 것입니다.

현재 저장소 설정의 핵심 항목을 확인합니다.

sudo grep -RHE '^\[|^name=|^enabled=|^baseurl=|^mirrorlist=|^metalink=|^gpgkey=|^gpgcheck=|^repo_gpgcheck=' \
  /etc/yum.repos.d/*.repo

CentOS Stream 10의 공식 baseos와 appstream 저장소는 CentOS 공식 metalink 또는 공식 미러를 사용해야 합니다. 알 수 없는 도메인이나 다른 메이저 버전 경로가 설정되어 있다면 원본 파일 복구가 필요합니다.

3. 공식 저장소 패키지 재설치

baseos 저장소가 동작하는 상태라면 외부 저장소를 모두 제외하고 공식 저장소 관련 패키지를 재설치합니다.

sudo dnf --disablerepo='*' \
  --enablerepo=baseos \
  reinstall -y centos-stream-release centos-stream-repos centos-gpg-keys

재설치가 완료되면 캐시를 다시 생성합니다.

sudo dnf clean all
sudo dnf --refresh makecache

4. metalink 문제를 임시 직접 미러로 진단

공식 metalink만 실패하는지 확인하기 위해 기존 저장소 파일을 수정하지 않고 임시 저장소를 명령행에서 추가할 수 있습니다. 이 명령은 BaseOS 메타데이터만 내려받으며 패키지를 설치하지 않습니다.

ARCH=$(rpm --eval '%{_arch}')
sudo dnf --disablerepo='*' \
  --repofrompath="c10-baseos,https://mirror.stream.centos.org/10-stream/BaseOS/${ARCH}/os/" \
  --enablerepo=c10-baseos \
  --refresh makecache

임시 직접 미러는 성공하지만 원래 저장소는 실패한다면 mirrors.centos.org metalink 접근, 프록시 또는 DNS 정책을 중점적으로 점검합니다. 임시 저장소는 명령 실행이 끝나면 시스템 저장소 파일에 저장되지 않습니다.

해결 여부 확인

1. 활성 저장소 확인

dnf repolist

기본 환경에서는 적어도 baseos와 appstream이 활성 상태로 표시되어야 합니다. crb는 개발용 패키지를 제공하는 추가 저장소이며 기본적으로 비활성화되어 있어도 정상입니다.

2. 메타데이터 강제 갱신

sudo dnf clean all
sudo dnf --refresh makecache

모든 활성 저장소가 오류 없이 동기화되고 메타데이터 캐시가 생성되면 저장소 통신은 정상입니다.

3. 업데이트 조회

sudo dnf check-update

업데이트가 있으면 DNF는 패키지 목록을 출력하고 종료 코드 100을 사용할 수 있습니다. 이는 오류가 아니라 업데이트가 존재한다는 정상적인 의미입니다. 저장소 오류는 일반적으로 종료 코드 1과 오류 메시지가 함께 표시됩니다.

마지막으로 실제 패키지 조회가 가능한지 확인합니다.

dnf info bash

설치된 버전과 저장소에서 제공하는 패키지 정보가 정상적으로 표시되면 메타데이터 조회 기능이 복구된 것입니다.

오류 유형별 해결 방법

재발 방지 권장사항

• 지원 버전 확인: 외부 저장소를 추가하기 전에 CentOS Stream 10 또는 Enterprise Linux 10을 공식 지원하는지 확인합니다.
• repo 파일 백업: /etc/yum.repos.d를 수정하기 전에 날짜가 포함된 백업을 생성합니다.
• 보안 검증 유지: sslverify와 gpgcheck를 비활성화하지 말고 인증서와 GPG 키의 원인을 해결합니다.
• 디스크 모니터링: /var의 디스크와 inode 부족을 사전에 경고하도록 모니터링합니다.
• 시간 동기화: chronyd 상태를 점검하여 TLS 인증서 검증에 필요한 정확한 시간을 유지합니다.
• 장애 저장소 격리: 외부 저장소 장애 시 전체 보안 업데이트가 중단되지 않도록 저장소별 상태를 확인합니다.
• 임의 미러 고정 지양: 특별한 사유가 없다면 CentOS 공식 metalink를 사용하여 여러 미러의 장애 분산 기능을 유지합니다.

저장소 변경 후에는 다음 명령으로 활성 상태와 메타데이터 갱신을 확인하는 습관이 좋습니다.

dnf repolist
sudo dnf --refresh makecache

원상복구 방법

캐시 초기화는 설치된 패키지를 변경하지 않으므로 별도의 원상복구가 필요하지 않습니다. 저장소 파일을 수정하거나 비활성화했다면 작업 전에 만든 백업을 사용합니다.

비활성화한 저장소 다시 활성화

sudo dnf config-manager --set-enabled '저장소_ID'

config-manager를 사용하지 않았다면 해당 .repo 파일에서 enabled=0을 원래 값으로 되돌립니다.

백업한 저장소 파일 복원

아래의 백업_경로를 실제로 생성한 디렉터리로 변경합니다.

sudo cp -a /root/yum.repos.d.backup-YYYYMMDD-HHMMSS/. /etc/yum.repos.d/
sudo dnf clean all
sudo dnf --refresh makecache

관련 지구 IDC 기술자료

• 지구 IDC 서버 운영 기술자료 전체 보기
• CentOS 업데이트 방법
• CentOS 버전 확인 방법

공식 참고자료

• The CentOS Project - CentOS Stream 10 Release Notes: 지원 상태, BaseOS·AppStream·CRB 저장소 구성 확인
• CentOS Stream 10 공식 BaseOS 미러: DNF 4.20 및 공식 저장소 패키지 제공 상태 확인
• DNF 공식 문서 - Command Reference: clean, makecache, --refresh, check-update 동작 확인
• DNF 공식 문서 - Configuration Reference: baseurl, metalink, mirrorlist, 프록시와 TLS 검증 설정 확인
• CentOS Stream 패키지 소스 - DNF c10s: CentOS Stream 10의 DNF 패키지 브랜치 확인

공식 자료 조회일: 2026년 7월 15일

자주 묻는 질문

dnf clean all을 실행하면 설치된 패키지가 삭제되나요?

아닙니다. dnf clean all은 저장소에서 내려받은 메타데이터와 패키지 캐시 같은 임시 데이터를 정리하며 현재 설치된 RPM 패키지를 제거하지 않습니다. 다음 DNF 실행 시 필요한 메타데이터를 다시 내려받습니다.

skip_if_unavailable=True로 설정하면 해결되나요?

실패한 저장소를 건너뛰어 작업을 계속할 수는 있지만 근본 원인을 해결하는 설정은 아닙니다. 특히 baseos나 appstream에 적용하면 필수 업데이트를 누락할 수 있습니다. 일시 장애가 잦은 비필수 외부 저장소에만 운영 정책을 검토한 뒤 제한적으로 사용해야 합니다.

CentOS Stream 10에서는 dnf5 명령을 사용해야 하나요?

현재 CentOS Stream 10 공식 BaseOS는 DNF 4.20 계열을 제공합니다. 따라서 일반적인 패키지 관리와 이 문서의 복구 절차는 dnf 명령을 사용합니다. Fedora의 최신 릴리스에서 사용하는 DNF5 문서와 명령 차이를 혼동하지 않도록 주의하십시오.

공식 저장소는 정상인데 EPEL 저장소만 실패합니다.

EPEL 저장소만 일시적으로 제외하여 보안 업데이트를 먼저 진행하고, 설치된 EPEL 릴리스 패키지가 EL10용인지 확인합니다. EL9용 EPEL 설정을 CentOS Stream 10에서 재사용하면 안 됩니다.

SSL 오류가 나는데 sslverify=0을 잠시 사용해도 되나요?

운영 서버에서는 권장하지 않습니다. 시스템 시간, CA 인증서, 프록시의 TLS 검사 인증서를 먼저 확인해야 합니다. 검증을 끄면 연결 대상의 신원을 확인할 수 없어 패키지 공급망 보안이 약해집니다.

dnf check-update가 종료 코드 100을 반환했습니다. 오류인가요?

오류가 아닙니다. dnf check-update는 설치 가능한 업데이트가 있으면 종료 코드 100, 업데이트가 없으면 0, 실행 오류가 발생하면 1을 반환할 수 있습니다.