> ## Content Index
> Fetch the complete content index at: https://mlog.me/llms.txt
> Use this file to discover other available public pages before exploring further.

# apt upgrade와 apt-get upgrade 차이: kept back을 새 의존성으로 재현하기
- URL: https://mlog.me/apt-upgrade-vs-apt-get-upgrade-kept-back/
- Published: 2026-09-15T05:37:25.000Z
- Updated: 2026-09-15T05:37:25.000Z
- Description: apt upgrade와 apt-get upgrade의 새 의존성 처리 차이를 Ubuntu 24.04 모의 실험으로 확인합니다. --with-new-pkgs, hold, 설치·제거 계획을 안전하게 비교합니다.
- Author: mLog
- Tags: 서버·인프라, Ubuntu, Linux, #패키지-진단

`apt-get upgrade`에서 남았던 패키지가 `apt upgrade`에서는 설치 계획에 포함될 수 있다. 두 명령이 새 의존성 패키지를 다루는 기본 범위가 다르기 때문이다. 그렇다고 명령을 바꾸면 모든 `kept back`이 해결되는 것은 아니다.

[ESM·phased·kept back 종합 진단 글](https://mlog.me/ubuntu-apt-upgrade-esm-phased-kept-back/)이 출력 메시지와 보류 원인을 구분했다면, 이번 글은 **새 의존성 하나를 추가한 모의 패키지로 두 명령의 차이를 확인하는 후속 실험**이다. hold는 대조 조건으로 두고, 실제 단계적 배포는 재현하지 않았다.

2026-09-15 Ubuntu 공식 문서와 Ubuntu 24.04.3 LTS·APT 2.8.3 amd64 환경에서 확인했다. 실제 운영 서버를 업그레이드하거나 패키지를 설치한 기록이 아니다.

## 1\. 실험 조건: 업그레이드에 새 패키지가 필요한 경우

임시 디렉터리에 설치 상태와 로컬 패키지 인덱스를 만들어 다음 상황을 구성했다. 이름과 버전은 직접 만든 실험 자료이며 실제 Ubuntu 배포 패키지가 아니다.

- `mlog-demo` 1.0이 설치돼 있고, 새 2.0은 `mlog-extra` 1.0 이상을 요구한다.
- `mlog-extra`는 아직 설치되지 않았으며 인덱스에는 1.0 후보가 있다.
- `mlog-held` 1.0은 명시적인 hold 상태이고 2.0 후보가 있다.

임시 APT 설정으로 상태·캐시·로그·저장소 경로를 분리했다. 외부 저장소 대신 로컬 `file:` 인덱스만 읽었고 모든 upgrade에는 `--simulate`를 사용했다. deb 파일이나 설치 스크립트는 만들지 않았다.

이 구성은 “업데이트 후보가 있지만 새 의존성을 설치해야 하는 패키지”와 “관리자가 hold한 패키지”를 구별하기 위한 최소 조건이다. 운영 서버의 전체 의존성 그래프를 재현한 것은 아니다.

## 2\. 세 명령의 모의 결과

같은 설치 상태와 인덱스에서 얻은 결과다. 표의 패키지 이름은 위 실험용 이름을 줄여 적었다.

| 모의 실행                           | 설치·업그레이드 계획                   | 남은 패키지     |
| ------------------------------- | ----------------------------- | ---------- |
| apt-get upgrade                 | 업그레이드·신규 설치 모두 0              | demo, held |
| apt upgrade                     | demo 업그레이드 1개, extra 신규 설치 1개 | held       |
| apt-get --with-new-pkgs upgrade | 위 apt와 같은 설치 계획               | held       |

두 번째 모의 실행의 관련 출력은 다음과 같다. **설치 성공 로그가 아니라 APT가 제안한 계획**이다.

```text
1 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Inst mlog-extra (1.0 localhost [amd64])
Inst mlog-demo [1.0] (2.0 localhost [amd64])
Conf mlog-extra (1.0 localhost [amd64])
Conf mlog-demo (2.0 localhost [amd64])

```

`apt-mark showhold`에는 `mlog-held`가 표시됐다. 세 실행 모두 hold를 유지했으며 제거 계획은 없었다. 임시 설치 상태 파일과 실제 시스템의 `/var/lib/dpkg/status` 파일은 실행 전후 SHA-256이 같았다.

실험 코드의 7개 검사 항목은 모두 통과했다. 이 결과가 뜻하는 범위는 모의 설치 계획·hold 유지·제거 계획 부재·상태 파일 불변이다. 실제 다운로드, 설치 후 스크립트, 서비스 재시작, OCI arm64, 제3자 저장소, 실제 phased update는 검증하지 않았다.

## 3\. 왜 apt에서는 새 의존성이 포함됐나

Ubuntu 24.04 공식 매뉴얼의 기본 동작은 다음과 같다. 사용자 설정과 버전에 따라 추가 옵션이 적용돼 있지 않은지도 함께 확인한다.

| 명령                                      | 필요한 새 의존성 설치 | 기존 패키지 제거   |
| --------------------------------------- | ------------ | ----------- |
| apt-get upgrade                         | 기본적으로 하지 않음  | 하지 않음       |
| apt upgrade                             | 허용           | 하지 않음       |
| apt-get --with-new-pkgs upgrade         | 허용           | 하지 않음       |
| apt full-upgrade / apt-get dist-upgrade | 허용           | 필요하면 할 수 있음 |

`mlog-demo` 2.0은 새 패키지 `mlog-extra` 없이는 의존성을 만족하지 못한다. 기본 `apt-get upgrade`는 새 패키지를 추가하지 않으므로 demo를 남긴다. `apt upgrade`와 `--with-new-pkgs`를 붙인 apt-get은 이 신규 의존성을 계획에 포함할 수 있다. [Ubuntu apt 매뉴얼](https://manpages.ubuntu.com/manpages/noble/man8/apt.8.html?ref=mlog.me), [Ubuntu apt-get 매뉴얼](https://manpages.ubuntu.com/manpages/noble/man8/apt-get.8.html?ref=mlog.me)

이 실험에서 두 명령의 결과가 같았다는 것이 모든 옵션과 상황에서 완전히 같은 명령이라는 뜻은 아니다. 또한 `--with-new-pkgs`는 hold를 무시하거나 기존 패키지 제거를 허용하는 만능 옵션이 아니다.

`full-upgrade`나 `dist-upgrade`는 제거까지 필요할 수 있는 더 넓은 변경 범위다. 단지 보류 숫자를 0으로 만들기 위해 바로 실행하면 안 된다.

## 4\. 실제 환경에서는 먼저 상태와 모의 계획을 비교한다

다음은 상태 조회 명령이다. `example-package`를 실제 보류된 패키지 이름으로 바꾼다.

```bash
lsb_release -ds
apt --version
apt list --upgradable
apt-mark showhold

pkg='example-package'
apt-cache policy "$pkg"
apt-cache depends "$pkg"
apt-cache show "$pkg" | awk '/^(Package|Version|Phased-Update-Percentage):/'

```

`apt-cache`는 로컬 패키지 정보를 조회한다. 설치·후보 버전, 저장소·우선순위, 의존 관계를 함께 읽는다. `show`는 여러 버전 정보를 표시할 수 있으므로 `Version`과 phasing 필드를 같은 묶음에서 확인한다. 캐시가 오래됐다면 현재 저장소와 다를 수 있다. [Ubuntu apt-cache 매뉴얼](https://manpages.ubuntu.com/manpages/noble/man8/apt-cache.8.html?ref=mlog.me)

목록 갱신이 필요하면 승인된 환경에서 `sudo apt update`를 별도로 진행한다. 패키지 설치는 아니지만 저장소에 접속해 로컬 인덱스를 바꾸므로 읽기 전용 조회와 구분한다. 서명·DNS·디스크 오류가 있다면 먼저 해결한다.

그다음 **`-s`를 유지한 채** 같은 환경의 설치 계획을 비교한다. 이 단계에는 `-y`가 필요하지 않다.

```bash
sudo apt-get -s upgrade
sudo apt -s upgrade
sudo apt-get -s --with-new-pkgs upgrade

```

두 번째와 세 번째에만 신규 의존성이 나타나고 대상 패키지가 포함된다면 이번 실험과 비슷한 단서다. 그러나 다른 보류 원인까지 배제한 것은 아니다. 패키지 이름·버전과 실제 계획으로 판단한다.

출력에는 사설 저장소 주소가 포함될 수 있다. 공개 질문이나 장애 기록에서는 내부 호스트명·인증 정보·장비 식별자를 가린다. `/etc/machine-id` 원문은 공개할 필요가 없다.

## 5\. hold와 phasing은 별도 조건이다

이번 실험에서 `mlog-held`는 세 명령 모두에서 남았다. `apt-mark showhold`는 명시적인 hold를 확인하는 기능이다. `manual` 표시는 자동 설치 여부에 관한 별도 정보이며 hold와 같지 않다. 운영자가 호환성이나 변경 승인을 위해 hold했을 수 있으므로 이유와 해제 조건을 먼저 확인한다. [Ubuntu apt-mark 매뉴얼](https://manpages.ubuntu.com/manpages/noble/man8/apt-mark.8.html?ref=mlog.me)

`showhold`가 비어 있어도 단계적 배포·우선순위·의존성 때문에 남을 수 있다. 반대로 `kept back`이라는 말만으로 새 의존성이 원인이라고 단정할 수도 없다.

Ubuntu의 phased update는 일반 업데이트의 배포 대상을 점차 확대하는 정책이다. 기본 정책을 유지하고 원인을 확인하는 것이 우선이며, 무조건 전역 설정을 끄거나 개별 설치로 우회하는 방법을 기본 해결책으로 삼지 않는다. 공식 안내상 Ubuntu 보안 업데이트에는 phasing을 적용하지 않으므로 보안 수정이 남아 있다면 단순히 배포 대기라고 무기한 기다리지 않는다. [Ubuntu 단계적 업데이트 설명](https://ubuntu.com/server/docs/explanation/software/about-apt-upgrade-and-phased-updates/?ref=mlog.me)

실제 배포 대상 판정과 배포율은 이번 모의 실험에 넣지 않았다. phasing과 ESM 메시지까지 함께 보인다면 앞서 연결한 종합 진단 글에서 원인 분기를 확인한다.

## 6\. 시뮬레이션은 실제 업그레이드 검증이 아니다

필요한 경우에만 제거를 허용하는 더 넓은 범위의 계획을 모의 비교한다.

```bash
sudo apt-get -s dist-upgrade

```

APT 모의 출력에서 `Inst`는 설치·업그레이드 계획, `Remv`는 제거 계획, `Conf`는 구성 단계의 계획을 읽는 단서다. 실제 설치 스크립트나 서비스 재시작의 성공을 의미하지 않는다.

시뮬레이션은 잠금을 잡지 않으므로 동시에 진행된 패키지 작업으로 상태가 바뀔 수 있다. 일반 사용자로 실행하면 읽지 못하는 설정 때문에 결과가 달라질 수도 있다. [APT 시뮬레이션 설명](https://manpages.ubuntu.com/manpages/noble/man8/apt-get.8.html?ref=mlog.me)

검토할 것은 보류 숫자보다 변경 대상이다.

- 새로 설치되는 패키지가 실제로 필요한 의존성인가?
- 제거 대상에 DB·컨테이너 런타임·SSH·네트워크 관련 패키지가 있는가?
- 예상하지 않은 저장소나 다른 Ubuntu 릴리스 버전이 섞였는가?
- 버전이 내려가거나 예상보다 넓은 범위가 바뀌는가?
- 변경 후 서비스 확인과 복구 수단이 준비돼 있는가?

후보나 우선순위가 이상하면 저장소와 pinning을 별도로 진단한다. 원인 확인 없이 다른 릴리스 저장소를 추가하거나 서명 검사를 끄지 않는다. [APT preferences 주의사항](https://manpages.ubuntu.com/manpages/noble/man5/apt%5Fpreferences.5.html?ref=mlog.me)

제거 계획이 없더라도 무중단은 보장되지 않는다. [Ghost·MySQL 백업 복원 검증](https://mlog.me/server-security-check-backup-restore-docker-forensics/)처럼 복구 가능성을 확인하되, DB 백업만으로 OS 패키지·네트워크·부팅 상태까지 원복되는 것은 아님을 구분한다.

변경 후에는 [서버 보안 점검의 정상 기준선](https://mlog.me/server-security-check-general-baseline-mysql-upgrade/)처럼 실제 서비스 상태를 확인한다. `not upgraded`가 0이라는 것만으로 DB 접속과 외부 응답이 정상이라고 결론내리지 않는다.

## 정리

이번에 재현한 것은 **새 의존성을 설치해야 하는 패키지를 기본 apt-get upgrade가 남기는 경우**다. apt upgrade와 apt-get의 --with-new-pkgs 옵션은 그 신규 의존성을 계획에 포함했지만, 명시적인 hold는 세 명령 모두 유지했다.

따라서 kept back을 보았을 때는 먼저 실행한 정확한 명령을 확인하고, 상태 조회와 시뮬레이션으로 변경 범위를 비교한다. 명령을 바꾸는 것과 운영 환경에서 안전하게 업그레이드를 완료하는 것은 별개다.