Fedora 의 dnf 는 조용히 뼈대를 갈아 끼웠습니다

Fedora 41 이후의 시스템에서 dnf 를 치면, 실제로 도는 것은 그때 그 파이선으로 쓴 판이 아닌 경우가 대부분입니다. DNF5 는 같은 기획을 다시 쓴 판으로, C++ 로 구현되었고 Fedora 41 부터 기본 꾸러미 관리 도구가 되었습니다. dnf 라는 명령은 이제 그것을 가리키는 연결일 뿐입니다. 기획은 rpm 소프트를 관리하는 단체 아래에서 손질되며, 사용의 허락은 GPL 의 두 번째 판과 그 뒤의 개정입니다. 읽을 값이 있는 까닭은 도구 하나가 다시 쓰였다는 점이 아닙니다. 그런 일은 날마다 일어납니다. 그 대신 이번 다시 쓰기가 겨눈 곳이, 쓰는 사람이 실제로 느끼는 자리이기 때문입니다. 설치했을 때 얼마만큼의 자리를 차지하는지, 명령이 움직이기까지 얼마나 기다리는지, 조회가 얼마나 빨리 돌아오는지, 이 세 가지입니다.

파이선을 걷어내고 남은 것은 크기와 시작의 수고

예전 dnf 는 파이선 위에 세워져 있어서, 불릴 때마다 먼저 해석기를 깨우고 그 위에 한 무리의 부품을 읽어 들인 뒤에야 본래 일로 들어갔습니다. DNF5 는 그 논리를 번역된 부품 묶음으로 옮겼고, 명령 도구 자체는 더 이상 파이선에 기대지 않습니다. Fedora 의 공개 설명에 있는 숫자로 보면, 빈 그릇에 이 도구 묶음을 넣으면 크기가 원래보다 약 60 퍼센트 작아집니다. 조회의 이득은 더 직접적이어서, 저장소에 있는 것을 늘어놓는 repoquery 같은 명령은 처리 속도가 원래의 두 배쯤이 되고, 의존을 늘어놓을 때나 긴 인자 목록을 풀 때의 기다림도 함께 줄어듭니다. 한 달에 한 번 쓰는 일이라면 사소한 이야기지만, 스크립트가 한 시간에 백 번 부르는 일이라면 무엇이 아직 현실적인지를 정합니다.

실제로 바뀐 곳

세 도구가 하나가 되었습니다. 예전 dnf, microdnf, 그리고 그림 쪽 토대는 각자 자기 보관을 두어 같은 기록을 여러 겹으로 저장했습니다. dnf5 와 그 뒤에서 도는 부품은 하나의 사본을 나누어 쓰므로 그 겹침이 사라졌습니다. 덧붙이는 부품은 따로 꾸리지 않고 본체와 함께 들어가, 갱신 뒤에 판이 어긋날 일이 훨씬 드물어졌습니다. 꾸러미를 다루는 접점, 저장소를 다루는 접점, 의존을 푸는 접점이라는 세 갈래는 하나의 부품으로 모였고, 스크립트 언어로의 연결은 하나의 도구가 만들어 내며, 이름 붙이는 방식도 가지런해졌습니다. 출력과 설명도 다시 지었습니다. 처리 표는 더 자세히 말하고, 스크립트 조각이 토해내는 긴 출력은 꾸러미 이름별로 기록 파일로 흘려보내며, 명령마다 따로 선 손잡이가 붙고, Shell 의 채우기도 강해졌습니다.

옮길 때 살펴볼 두 가지

하나는 기록 보관이 서로 통하지 않는다는 점입니다. dnf 와 dnf5 는 저마다의 형식으로 적으므로, 예전 도구로 넣은 꾸러미는 새 쪽에서 하나의 사건으로 보이지 않습니다. DNF5 는 처음 처리를 실행할 때 예전 기록을 읽어 시스템의 상태를 옮겨 담으려 합니다. 이것은 이 꾸러미는 그때 의존으로 들어왔다 같은 정보를 되도록 남겨, 나중에 의존 꾸러미를 이용자가 스스로 고른 것으로 잘못 보고 거둘 기회를 놓치지 않게 하려는 뜻입니다. 다른 하나는 기업용 배포가 아직 예전 판을 쓴다는 점입니다. 상업용의 아홉 번째 세대, 그 두 지역판, 그리고 열 번째 세대는 모두 기본이 예전 dnf 그대로이고, DNF5 는 아직 그 자리를 이어받지 않았습니다. 2026 년 9 월 기준으로 최신은 5.4 입니다. Fedora 를 평범하게 쓰는 사람이라면 dnf 를 치면 넉넉하고, 구분을 드러내고 싶을 때만 dnf5 로 적으면 됩니다.

옮기는 값을 낮게 잡기 위해 자주 쓰는 명령과 선택지에는 호환 별명이 남아 있어, 손에 익은 표기가 그대로 통합니다. python3-dnf 와 libdnf 라는 두 벌의 예전 부품도 시스템에 남아 DNF5 와 나란히 놓일 수 있지만, 넣은 소프트를 양쪽에서 번갈아 건드리는 것은 권하지 않습니다. 시스템의 상태를 나누어 쓰지 않기 때문입니다.

누가 신경 써야 하는가

Fedora 책상 한 대만 쓰면서 이따금 소프트를 넣는 정도라면, 느끼는 것은 명령의 응답이 조금 빨라졌다 정도일 것입니다. 정말 이득을 보는 쪽은 Fedora 를 토대 그림으로 쓰는 자리입니다. 그릇 안에 파이선 실행 환경을 하나 덜 넣으면 그림이 한 바퀴 작아지고, 서버에서 repoquery 를 되풀이해 자산을 세는 일이라면 두 배가 된 조회 속도가 쌓여 실제의 시간이 됩니다. 값은 선택지가 몇 개 늘어난 데 있지 않고, 꾸러미 관리 도구가 스크립트 언어에서 번역된 언어로 옮겨 간 데 있습니다. 더 작고, 조회가 더 빠르고, 같은 보관을 두 번 들고 있지 않습니다. Fedora 41 이후를 쓰는 사람은 이미 이것을 밟고 있고, 기업 쪽은 조금 더 기다려야 합니다.