apt update와 apt upgrade 차이, 언제 실행해야 할까

패키지를 설치하려고 했는데 Unable to locate package가 나오거나, 서버 보안 업데이트를 적용해야 하는데 apt update만 실행해도 되는지 apt upgrade까지 해야 하는지 헷갈리는 경우가 많습니다. 이 글은 Debian/Ubuntu 계열 서버에서 두 명령어의 차이를 구분하고, 실제 운영 서버에서 어떤 순서로 확인한 뒤 실행해야 하는지 정리한 문서입니다.

이 글에서 해결할 문제

초보자가 가장 많이 헷갈리는 지점은 update라는 단어 때문에 apt update만 실행하면 프로그램이 최신 버전으로 바뀐다고 생각하는 것입니다. 하지만 실제로는 다릅니다. apt update는 저장소의 패키지 목록을 새로 받아오는 작업이고, apt upgrade는 설치된 패키지를 실제로 새 버전으로 올리는 작업입니다.

서버 운영에서는 이 차이를 잘못 이해하면 다음과 같은 문제가 생깁니다.

패키지 설치 실패 원인을 패키지명 문제로 오해한다.
보안 패치를 적용했다고 생각했지만 실제로는 목록만 갱신한 상태로 남는다.
운영 중인 웹서버나 애플리케이션 서버에서 업그레이드를 바로 실행해 예상치 못한 서비스 재시작이 발생한다.
업데이트 후 어떤 패키지가 바뀌었는지 확인하지 않아 장애 원인을 추적하기 어려워진다.

먼저 확인할 핵심 요약

명령어	역할	실제 변경 여부	주로 쓰는 상황
`sudo apt update`	패키지 저장소 목록 갱신	설치된 프로그램 버전은 바뀌지 않음	패키지 설치 전, 업그레이드 전, 저장소 정보가 오래됐을 때
`sudo apt upgrade`	설치된 패키지를 새 버전으로 업그레이드	실제 파일과 패키지 버전이 바뀜	보안 패치 적용, 일반 패키지 업데이트 반영
`apt list --upgradable`	업그레이드 가능한 패키지 확인	변경 없음	업그레이드 전에 영향 범위 확인
`sudo apt upgrade -s`	업그레이드 시뮬레이션	변경 없음	운영 서버에서 실제 적용 전 점검

실제 서버 운영 중 헷갈리기 쉬운 지점

새 VPS를 만들거나 Ubuntu 서버에 처음 접속한 뒤 Node.js, Nginx, curl 같은 패키지를 설치하려고 하면 저장소 목록이 오래되어 설치가 실패하는 경우가 있습니다. 처음에는 패키지명이 틀렸거나 서버에 문제가 있는 것처럼 보이지만, 실제 원인은 apt update를 실행하지 않아 로컬 패키지 목록이 최신 상태가 아닌 경우가 많습니다.

반대로 보안 업데이트를 해야 하는 상황에서 sudo apt update만 실행하고 작업을 끝내면, 서버는 최신 패키지 목록만 알고 있을 뿐 실제 패키지는 여전히 예전 버전일 수 있습니다. 이 오류를 겪은 뒤에는 패키지 작업을 할 때 항상 “목록을 갱신했는지”와 “실제로 업그레이드했는지”를 나눠서 확인하는 편이 좋습니다.

처음 의심하기 쉬운 원인과 실제 원인의 차이

겉으로 보이는 상황	처음 의심하기 쉬운 원인	실제로 자주 확인해야 하는 원인
`Unable to locate package`가 나온다	패키지명이 틀렸다고 생각함	저장소 목록이 오래됐거나 해당 저장소가 활성화되지 않았을 수 있음
`apt update`를 했는데 프로그램 버전이 그대로다	업데이트가 실패했다고 생각함	`apt update`는 목록만 갱신하므로 정상 동작일 수 있음
업그레이드 후 서비스 동작이 달라졌다	애플리케이션 코드 문제로만 생각함	업그레이드된 라이브러리, 웹서버, 런타임 패키지 영향일 수 있음
`Permission denied`가 나온다	apt 명령어가 고장났다고 생각함	관리자 권한 없이 실행했을 가능성이 큼

실행 전에 현재 상태부터 확인하기

서버에 영향을 줄 수 있는 명령어를 바로 실행하기보다, 먼저 현재 배포판과 권한, 업그레이드 후보를 확인하는 것이 안전합니다. 특히 운영 중인 서버라면 전체 업그레이드 전에 어떤 패키지가 바뀌는지 보는 습관이 필요합니다.

whoami
lsb_release -a
apt --version
apt list --upgradable

whoami는 현재 사용자를 확인하는 명령어입니다. 일반 사용자라면 패키지 설치와 업그레이드에 sudo가 필요합니다. lsb_release -a는 Ubuntu/Debian 계열에서 배포판 정보를 확인할 때 자주 사용합니다. 일부 최소 설치 환경에서는 lsb_release가 없을 수 있으므로, 이 경우 아래 명령어로도 확인할 수 있습니다.

cat /etc/os-release

`apt update`는 무엇을 바꾸는가

apt update는 실제 프로그램을 업그레이드하지 않습니다. 서버에 설정된 저장소에서 패키지 목록, 버전 정보, 의존성 정보를 다시 받아옵니다. 쉽게 말하면 “지금 설치 가능한 패키지 목록표를 새로 받는 작업”입니다.

sudo apt update

이 명령어는 시스템의 패키지 데이터베이스를 갱신하므로 관리자 권한이 필요합니다. 다만 일반적인 의미의 프로그램 업그레이드는 아직 일어나지 않습니다. 그래서 실행 후에도 Nginx, curl, OpenSSL 같은 패키지 버전이 그대로일 수 있습니다.

패키지 설치 전에 아래처럼 실행하는 이유가 여기에 있습니다.

sudo apt update
sudo apt install curl

첫 줄에서 최신 패키지 목록을 받아오고, 두 번째 줄에서 그 목록을 기준으로 curl을 설치합니다. 새 서버에서 패키지 설치가 실패할 때는 설치 명령어를 반복하기보다 먼저 sudo apt update 결과를 확인하는 편이 원인을 좁히기 쉽습니다.

`apt upgrade`는 무엇을 바꾸는가

apt upgrade는 이미 설치되어 있는 패키지를 저장소에 있는 새 버전으로 올립니다. 이 단계에서는 실제 파일이 바뀌고, 일부 서비스는 재시작될 수 있습니다. 웹서버, 데이터베이스, 런타임 패키지가 포함되어 있다면 운영 중인 서비스에 영향이 있을 수 있으므로 바로 실행하지 말고 후보 목록을 먼저 확인하는 것이 좋습니다.

apt list --upgradable

목록을 확인한 뒤 실제 적용 전에 시뮬레이션을 해볼 수 있습니다.

sudo apt upgrade -s

-s는 시뮬레이션 옵션입니다. 실제 설치를 진행하지 않고 어떤 패키지가 업그레이드될지 보여줍니다. 운영 서버에서는 이 결과를 보고 웹서버, 데이터베이스, 언어 런타임, 보안 관련 패키지가 포함되어 있는지 확인한 뒤 작업 시간대를 정하는 편이 안전합니다.

실제로 적용할 때는 아래처럼 실행합니다.

sudo apt upgrade

명령 실행 중에는 업그레이드될 패키지 목록과 다운로드 용량이 표시되고 진행 여부를 묻는 경우가 있습니다. 내용을 확인하지 않고 습관적으로 진행하면 예상보다 많은 패키지가 바뀔 수 있으므로, 운영 서버에서는 표시되는 목록을 한 번 읽어보는 것이 좋습니다.

실제로 자주 막히는 상황

1. `apt update`를 했는데 버전이 그대로인 경우

이 경우는 오류가 아닐 가능성이 큽니다. apt update는 설치된 패키지를 바꾸지 않기 때문입니다. 먼저 업그레이드 가능한 패키지가 있는지 확인합니다.

apt list --upgradable

목록에 패키지가 보인다면 apt update는 정상적으로 목록을 갱신했고, 실제 반영은 apt upgrade 단계에서 해야 합니다.

2. `Unable to locate package`가 나오는 경우

패키지명을 먼저 의심할 수 있지만, 새 서버나 오래 관리하지 않은 서버에서는 패키지 목록이 오래된 것이 원인일 수 있습니다.

sudo apt update
apt-cache policy 패키지명

apt-cache policy는 해당 패키지를 어떤 저장소에서 찾을 수 있는지 확인하는 데 도움이 됩니다. 패키지명이 정확한데도 후보가 나오지 않는다면, 현재 배포판 저장소에 없는 패키지이거나 별도 저장소가 필요한 패키지일 수 있습니다. 이 부분은 Ubuntu 버전과 저장소 설정에 따라 달라질 수 있습니다.

3. `Permission denied` 또는 잠금 오류가 나는 경우

패키지 작업은 시스템 영역을 변경하므로 일반적으로 관리자 권한이 필요합니다. 먼저 현재 사용자를 확인합니다.

whoami
id

일반 사용자라면 sudo를 붙여 실행합니다.

sudo apt update

만약 다른 apt 작업이 진행 중이면 잠금 관련 메시지가 나올 수 있습니다. 이때는 무리하게 잠금 파일을 삭제하기보다, 자동 업데이트나 다른 터미널에서 실행 중인 apt 작업이 끝나는지 먼저 확인하는 것이 안전합니다.

ps aux | grep apt

서버 운영에서는 명령어 자체보다 현재 사용자, 실행 중인 프로세스, 이전 작업 상태가 원인인 경우도 많습니다.

원인 분리: 어떤 명령어를 실행해야 할지 판단하는 순서

패키지를 새로 설치하려는 상황인지, 이미 설치된 패키지를 최신화하려는 상황인지 구분합니다.
설치 전이라면 먼저 sudo apt update로 목록을 갱신합니다.
보안 패치나 업데이트 적용 전이라면 apt list --upgradable로 후보를 확인합니다.
운영 서버라면 sudo apt upgrade -s로 시뮬레이션을 먼저 실행합니다.
서비스 영향이 적은 시간대에 sudo apt upgrade를 진행합니다.
업그레이드 후 서비스 상태와 apt 로그를 확인합니다.

잘못된 예시

아래 흐름은 초보 서버 운영에서 흔히 나오는 실수입니다.

sudo apt update
node -v

이렇게 실행한 뒤 Node.js 버전이 그대로라고 해서 apt update가 실패한 것은 아닙니다. 목록만 갱신했기 때문에 설치된 패키지 버전은 바뀌지 않는 것이 정상입니다.

또 다른 실수는 운영 서버에서 후보를 확인하지 않고 바로 전체 업그레이드를 진행하는 것입니다.

sudo apt update
sudo apt upgrade

이 명령어 조합 자체가 틀린 것은 아닙니다. 다만 운영 중인 서버에서는 어떤 패키지가 바뀌는지 확인하지 않으면 웹서버, 런타임, 보안 라이브러리 업데이트가 서비스에 영향을 줄 수 있습니다. 특히 Nginx, PHP, Node.js, OpenSSL 관련 패키지가 포함된 경우에는 적용 후 상태 확인이 필요합니다.

수정 예시: 안전하게 패키지 설치와 업그레이드 진행하기

패키지 설치가 목적일 때

예를 들어 curl을 설치하려는 경우에는 목록 갱신 후 설치합니다.

sudo apt update
apt-cache policy curl
sudo apt install curl
curl --version

apt-cache policy curl로 설치 후보가 보이는지 확인한 뒤 설치하면, 패키지를 찾지 못하는 문제와 저장소 문제를 분리하기 쉽습니다.

보안 업데이트 또는 일반 업데이트가 목적일 때

업그레이드가 목적이라면 바로 적용하지 말고 후보와 시뮬레이션 결과를 먼저 확인합니다.

sudo apt update
apt list --upgradable
sudo apt upgrade -s

결과를 확인한 뒤 적용 가능한 시간대라면 업그레이드를 진행합니다.

sudo apt upgrade

이 작업은 실제 패키지를 변경합니다. 운영 중인 서비스가 있는 서버에서는 접속자가 적은 시간대에 진행하고, 적용 후 서비스 상태를 확인하는 것이 좋습니다.

수정 후 확인 방법

업그레이드가 끝난 뒤에는 apt 로그와 주요 서비스 상태를 확인합니다. 화면상으로 완료된 것처럼 보여도 일부 패키지 설정이 보류되었거나 서비스 재시작이 실패했을 수 있습니다.

tail -n 50 /var/log/apt/history.log
systemctl --failed

/var/log/apt/history.log에서는 어떤 패키지가 설치되거나 업그레이드되었는지 확인할 수 있습니다. systemctl --failed는 실패 상태의 systemd 서비스가 있는지 확인합니다. 웹서버를 운영 중이라면 서비스 상태도 함께 봅니다.

systemctl status nginx

Nginx를 사용하지 않는 서버라면 해당 명령은 필요하지 않습니다. Apache, MySQL, PostgreSQL, Redis 등 실제 운영 중인 서비스에 맞게 상태를 확인하면 됩니다.

업그레이드 후 재부팅이 필요한 패키지가 있을 수 있습니다. Ubuntu/Debian 계열에서는 환경에 따라 아래 파일이 생성될 수 있습니다.

test -f /var/run/reboot-required && cat /var/run/reboot-required

이 파일이 있다고 해서 즉시 재부팅해야 한다는 뜻은 아닙니다. 운영 서버라면 서비스 영향 시간을 고려해 재부팅 일정을 잡는 것이 좋습니다.

재발 방지 체크리스트

패키지 설치 전에는 sudo apt update를 먼저 실행했는지 확인합니다.
apt update만으로 설치된 패키지 버전이 바뀐다고 생각하지 않습니다.
업그레이드 전에는 apt list --upgradable로 변경 후보를 확인합니다.
운영 서버에서는 sudo apt upgrade -s로 시뮬레이션을 먼저 실행합니다.
Nginx, PHP, Node.js, OpenSSL, 데이터베이스 관련 패키지가 포함되면 적용 시간을 신중히 정합니다.
업그레이드 후에는 /var/log/apt/history.log와 systemctl --failed를 확인합니다.
오류가 나면 같은 명령어를 반복하기보다 권한, 저장소 상태, 실행 중인 apt 프로세스를 먼저 분리해 봅니다.

정리

apt update와 apt upgrade의 차이는 “정보 갱신”과 “실제 적용”으로 나누면 이해하기 쉽습니다. apt update는 저장소의 최신 패키지 목록을 가져오고, apt upgrade는 그 목록을 기준으로 설치된 패키지를 새 버전으로 올립니다.

새 패키지를 설치할 때는 sudo apt update를 먼저 실행하고, 보안 패치나 일반 업데이트를 적용할 때는 업그레이드 후보를 확인한 뒤 sudo apt upgrade를 진행하는 흐름이 안전합니다. 운영 서버에서는 명령어 실행 자체보다 변경 범위 확인과 적용 후 점검이 더 중요합니다.

FAQ

Q1. `apt update`만 매일 실행해도 보안 업데이트가 적용되나요?

아니요. apt update는 패키지 목록만 갱신합니다. 보안 업데이트를 실제로 적용하려면 업그레이드 가능한 패키지를 확인한 뒤 sudo apt upgrade를 실행해야 합니다. 다만 운영 서버에서는 변경 범위를 먼저 확인하는 것이 좋습니다.

Q2. `apt upgrade`를 실행하면 서버가 재부팅되나요?

일반적으로 apt upgrade 자체가 서버를 즉시 재부팅하지는 않습니다. 하지만 커널이나 핵심 라이브러리 업데이트 후 재부팅이 필요할 수 있습니다. Ubuntu/Debian 계열에서는 /var/run/reboot-required 파일을 확인해 재부팅 필요 여부를 참고할 수 있습니다.

Q3. `apt update`와 `apt upgrade`를 한 줄로 실행해도 되나요?

테스트 서버나 개인 실습 환경에서는 sudo apt update && sudo apt upgrade처럼 이어서 실행할 수 있습니다. 다만 운영 서버에서는 업그레이드 후보를 먼저 확인하고, 서비스 영향이 적은 시간대에 진행하는 편이 안전합니다.