Ubuntu 24.04에서 26.04로 안전하게 업그레이드하는 방법

Ubuntu 24.04에서 26.04로 언제 업그레이드할 수 있습니까?

이제 VPS에서 Ubuntu 24.04를 26.04로 업그레이드할 수 있습니다. Canonical이 24.04 LTS에서의 업그레이드를 허용한 2026년 9월 29일부터 24.04 서버의 do-release-upgrade은 26.04.1 버전을 제공합니다. Ubuntu 26.04 LTS(Resolute Raccoon)는 2026년 4월 23일에 출시되었으나, Canonical은 첫 번째 포인트 릴리스가 나온 이후에만 LTS 간 업그레이드 경로를 엽니다. 해당 릴리스에는 출시 초기 몇 달간 발견된 설치 및 업그레이드 버그가 수정되어 포함되기 때문입니다. 이번에는 포인트 릴리스 시점보다 대기 기간이 더 길었습니다. 26.04.1은 2026년 8월 27일에 출시되었으나, Canonical은 최근 버전의 rust-coreutils에서 발생한 회귀(regression) 문제를 해결하기 위한 백포트 작업을 위해 몇 주간 업그레이드를 보류했습니다. 버전 번호 체계가 생소하다면 26.04.1은 다른 Ubuntu가 아니라 4개월간의 수정 사항이 반영된 동일한 26.04 버전이라는 점을 참고하십시오. 이것이 바로 Canonical이 기존 서버에 제공하는 첫 번째 버전인 이유입니다.

9월 29일 이전까지 24.04 서버에서 확인 명령을 실행하면 다음과 같은 결과가 나타났습니다.

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

이는 서버의 오류가 아니며, 오늘날에도 이 메시지가 보인다면 관련 설정을 확인해야 합니다. /etc/update-manager/release-upgrades에는 Ubuntu Server의 Prompt=lts이 포함되어 있습니다. 이는 해당 도구가 다음 LTS 릴리스만 제공하며, Canonical이 업그레이드 경로를 연 이후에만 가능하다는 것을 의미합니다. 나중에 normal로 설정하면 단기 지원 버전(interim version)까지 제공되므로, 어쨌든 lts로 유지하는 것이 좋습니다. 대기 기간 동안 Canonical은 기다릴 수 없는 사용자를 위해 do-release-upgrade -d을 제공했으나, 이제 경로가 열렸으므로 서버용 공지에서 명시한 일반 명령어를 사용하면 됩니다. 시작하기 전에 26.04.1의 변경 사항과 업그레이드 경로가 열린 시점을 읽어보십시오. 22.04 서버는 이 과정을 바로 수행할 수 없습니다. 업그레이더는 항상 다음 LTS 버전만 제공하기 때문입니다. 따라서 24.04를 거쳐 22.04에서 26.04로 업그레이드하는 방법을 통해 첫 번째 단계를 수행하고 두 번째 단계 이전에 스냅샷을 생성해야 합니다.

아래의 모든 명령어는 사용자가 직접 자신의 서버에서 순서대로 실행해야 합니다. 릴리스 업그레이드는 업그레이드 중인 시스템에서 미리 연습할 수 없습니다. 이 과정은 커널과 C 라이브러리를 교체하므로 완료하려면 재부팅이 필요합니다.

업그레이드를 반드시 해야 하는가?

Ubuntu 24.04는 2029년까지 표준 보안 업데이트를 지원하므로, 정상 작동 중인 운영 서버를 급하게 업그레이드할 필요는 없습니다. 26.04 버전이 제공하는 PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 또는 7.0 커널과 같은 기능이 필요한 경우에만 업그레이드를 고려하십시오. 단순히 "버전 숫자가 올라갔다"는 이유만으로 고객에게 서비스를 제공하는 서버를 건드려서는 안 됩니다.

다음 중 하나라도 해당한다면 인플레이스(in-place) 업그레이드를 하지 마십시오:

• 클라우드 제공업체의 콘솔(VNC 또는 시리얼)을 열어 직접 로그인해 본 적이 없는 경우. SSH 접속이 끊겼을 때 서버에 다시 접근할 수 있는 유일한 방법은 콘솔뿐이며, 접속이 차단된 상태에서 콘솔이 작동하지 않는다는 사실을 깨닫는 것은 이미 늦은 때입니다.
• 1시간 정도의 다운타임을 감당할 수 없거나 롤백 계획이 없는 경우.
• 사용 중인 스택이 아직 resolute용 패키지를 배포하지 않은 타사 저장소에 의존하는 경우.
• 서버를 2년 넘게 수동으로 구축해 왔으며, 현재 서버에 무엇이 설치되어 있는지 아무도 정확히 모르는 경우.

대안을 선택하는 것이 더 나은 경우가 많습니다. 26.04 버전의 새로운 VPS를 구축하고 스택을 설치한 뒤 데이터를 복원하십시오. 이후 새 서버가 정상적으로 응답하면 DNS를 변경하십시오. 새 서버가 검증될 때까지 기존 서버를 계속 실행할 수 있으며, 문제가 생겨도 복원 작업 대신 DNS를 되돌리는 것만으로 롤백이 가능합니다. 이 방식을 선택한다면 새 VPS에서의 첫 10분 가이드를 따라 새 서버를 올바르게 구축하는 것부터 시작하십시오.

1단계: 복구 가능한 백업 생성

두 가지 계층을 사용하여 백업하십시오. 각 계층은 서로 다른 방식으로 실패할 수 있기 때문입니다. 제공업체 스냅샷은 전체 디스크를 포함하며 몇 분 안에 복구할 수 있지만, 데이터베이스가 쓰기 작업을 수행하는 중에 생성되므로 애플리케이션 일관성이 아닌 크래시 일관성(crash consistent)을 갖습니다. restic을 사용하여 서버 외부에 저장하는 파일 수준 백업은 개별 파일을 복구할 수 있게 해주며, 계정 잠금과 같은 상황에서도 데이터를 안전하게 보관합니다.

먼저 데이터베이스를 수동으로 덤프하십시오. 덤프는 실행 중인 데이터베이스를 백업하는 한 가지 방법입니다.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction은 InnoDB 테이블에 대해서만 일관된 덤프를 제공합니다. MyISAM 테이블은 일관된 덤프를 위해 잠금이 필요합니다. /etc tarball은 업그레이드 과정에서 질문하게 될 모든 설정 파일을 포함하고 있으므로, 실제로 가장 먼저 찾게 될 백업본입니다.

복구해 본 적 없는 백업은 추측에 불과합니다. 긴급한 상황이 닥치기 전에 지금 당장 백업에서 파일 하나를 추출해 보십시오.

2단계: 먼저 24.04를 완전히 패치하십시오

do-release-upgrade는 패키지 상태가 손상된 시스템에서는 실행을 거부하며, 24.04가 절반만 패치된 상태라면 이후 발생하는 모든 오류의 원인을 파악하기 어려워집니다.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

dpkg --audit이 아무것도 출력하지 않는다면 설정이 완료되지 않은 패키지가 없다는 뜻입니다. apt-mark showhold이 아무것도 출력하지 않는다면 dpkg hold 상태인 패키지가 없다는 뜻입니다. 이 명령은 별도의 메커니즘으로 패키지 업데이트를 보류할 수 있는 APT preference pin은 표시하지 않으며, 이는 3단계에서 확인합니다. showhold에 나열된 패키지는 sudo apt-mark unhold과 패키지 이름을 사용하여 보류를 해제하거나, 보류가 설정된 이유를 인지하고 여기서 작업을 중단하십시오.

커널이 변경되었다면 재부팅하여, 현재 실행 중인 코드와 시스템이 인식하는 커널 버전이 일치하는 상태에서 업그레이드를 진행하십시오.

[ -f /var/run/reboot-required ] && sudo reboot

그다음 디스크 공간을 확인하십시오. 업그레이더는 설치를 시작하기 전에 새로운 패키지 세트 전체를 다운로드하며, 공간이 부족하면 파일 시스템 이름을 명시하며 중단됩니다.

df -h / /boot

오래된 커널이 원인인 경우가 많으며, sudo apt --purge autoremove를 실행하면 이를 정리할 수 있습니다.

시작하기 전에 한 가지 더 주의할 점이 있습니다. 자동 보안 업데이트가 실행 도중에 작동하면 dpkg 잠금을 점유하게 되어, 릴리스 업그레이더가 Could not get lock /var/lib/dpkg/lock-frontend 오류와 함께 중단됩니다. 먼저 sudo systemctl stop unattended-upgrades을 실행하여 업데이트를 완료한 뒤 다시 시작하십시오.

3단계: 타사 저장소 및 고정(pinned) 패키지 확인

기본적으로 do-release-upgrade은 Ubuntu 공식 저장소가 아닌 모든 apt 소스를 주석 처리합니다. noble용으로 빌드된 패키지가 resolute 시스템을 손상시킬 수 있기 때문입니다. --allow-third-party 옵션을 사용하면 이를 계속 활성화할 수 있지만, 언급한 위험을 그대로 감수해야 합니다. 도구가 자동으로 결정하기 전에 사용 중인 항목을 정확히 파악하십시오.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04는 해당 디렉터리에서 두 가지 형식을 사용합니다. 기존의 한 줄짜리 .list 파일과 Types: 및 Suites: 필드를 포함하는 deb822 형식의 .sources 파일입니다. 업그레이드 시 두 형식 모두 기본적으로 비활성화됩니다. ubuntu-security-status --thirdparty는 Ubuntu 저장소에서 제공하지 않는 설치된 패키지 목록을 보여주며, 이는 시스템에 추가로 설치한 패키지의 실제 개수입니다. /etc/apt/preferences.d/ 내의 파일은 파일 이름에 확장자가 없거나 .pref로 끝나고, 영문자, 숫자, 하이픈, 밑줄, 마침표만 포함된 경우에만 고정(pin) 설정으로 읽힙니다. APT는 그 외의 파일은 무시하며, 보통 관련 알림을 표시합니다. noble을 지정하는 고정 설정은 업그레이드 후에도 사용 가능한 버전과 설정된 우선순위에 따라 패키지를 이전 버전에 머무르게 할 수 있으므로, 각 파일을 읽고 유지 여부를 결정하십시오.

각 타사 저장소에 대해 업그레이드를 시작하기 전, 공급업체가 새 코드네임용 패키지를 배포했는지 확인하십시오. Docker의 제품군은 https://download.docker.com/linux/ubuntu/dists/에서 확인할 수 있으며, 다른 공급업체들도 동일한 디렉터리 구조를 제공합니다. 존재하지 않는 제품군을 가리키는 소스는 업그레이드 후 첫 번째 apt update 실행 시 다음과 같은 오류를 발생시킵니다.

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Docker는 현재 resolute 제품군을 배포합니다. 공급업체가 배포하기 전까지 제품군이 누락된 소스는 비활성화 상태로 두십시오. 공급업체가 빌드하지 않은 코드네임으로 임의 수정할 경우, 잘못된 시스템 라이브러리와 연결된 패키지가 설치될 수 있습니다.

4단계: 일반 SSH 셸이 아닌 tmux에서 업그레이드 실행하기

서버 업그레이더는 일반적으로 GNU screen 내부에서 실행되며 연결이 끊겨도 다시 연결할 수 있도록 지원하므로, SSH 연결이 끊긴다고 해서 업그레이드가 즉시 중단되지는 않습니다. 업그레이더를 직접 tmux 세션 내에서 실행하면 나중에 다시 연결할 수 있는 명명된 세션을 확보할 수 있습니다.

sudo apt install -y tmux
tmux new -s upgrade

해당 세션 내부에서 다음을 실행합니다:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

업그레이더는 설정을 변경하기 전에 1022 포트에서 두 번째 SSH 데몬을 시작하며, 관련 내용을 다음과 같이 안내합니다:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

업그레이더는 해당 포트를 위해 방화벽을 자동으로 열지 않습니다. 사용자의 동의 없이 방화벽에 구멍을 뚫는 것은 예기치 않은 보안 문제를 야기할 수 있기 때문입니다. 업그레이드를 시작하기 전에 직접 1022 포트를 개방하고, sudo ufw delete allow 1022/tcp 작업이 완료되면 다시 닫으십시오. 서버 외부의 제어판에서 별도의 방화벽을 운영하는 호스팅 제공업체도 있으니 유의하시기 바랍니다.

연결이 끊기더라도 다시 로그인하여 tmux attach -t upgrade을 실행하십시오. 사용자가 자리를 비운 동안에도 업그레이드는 계속 진행됩니다. 만약 업그레이드가 중단되어 dpkg 설정이 절반만 완료되었거나 apt 소스가 noble와 resolute 상태로 섞여 있다면, 실패한 릴리스 업그레이드 복구 문서를 참조하여 패키지 상태를 복구하는 방법과 복구를 중단하고 스냅샷을 복원해야 할 시점을 확인하십시오.

5단계: 설정 파일 프롬프트에 신중하게 응답하기

dpkg는 사용자가 직접 수정했거나 스크립트에 의해 변경된 파일에 대해서만 프롬프트를 표시합니다. 따라서 모든 프롬프트는 사용자가 변경한 파일과 관련이 있으며, 기본적으로 Enter 키를 누르면 현재 버전을 유지하게 됩니다.

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

매번 가장 먼저 D을 누르십시오. 변경 사항을 읽어본 뒤, N을 사용하여 현재 버전을 유지할지 아니면 관리자가 제공한 버전을 설치할지 결정하십시오. 기본값은 이미 N로 설정되어 있지만, 모든 패키지에 대해 기존 파일을 유지하는 것이 안전한 것은 아닙니다. 업그레이드된 시스템이 정상적으로 작동하려면 일부 설정 변경이 필수적일 수 있기 때문입니다.

기존 파일을 유지하면 새로운 기본 설정을 적용받지 못한다는 단점이 있습니다. 시스템이 정상화되고 시간적 여유가 생겼을 때 나중에 설정을 조정하십시오.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

나열되는 각 파일은 관리자가 제공한 버전이며, 사용자의 파일 옆에 저장됩니다. 하나씩 차례대로 diff를 확인하고 필요한 설정을 복사하십시오. 특히 다음 두 가지는 각별한 주의가 필요합니다. /etc/ssh/sshd_config는 잘못된 응답 시 세션이 종료될 수 있으며, 웹 서버 설정은 잘못된 응답 시 사이트가 중단될 수 있기 때문입니다.

Ubuntu 24.04부터는 needrestart이 기본적으로 영향을 받는 서비스를 자동으로 재시작합니다. 만약 대화형 모드로 복구했다면 전체 목록을 수락하십시오. 이전 공유 라이브러리를 계속 사용하는 데몬은 재시작하기 전까지 업데이트로 해결된 버그에 여전히 노출된 상태로 남게 됩니다.

6단계: 재부팅 후 시스템 확인

sudo reboot

시스템이 다시 시작되면 다음을 확인합니다.

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a 명령은 Release: 26.04 및 Codename: resolute 상태를 보고해야 합니다. uname -r 명령은 7.0 커널 버전을 표시해야 합니다. systemctl --failed 명령은 실패한 유닛을 0개로 출력해야 하며, 만약 유닛이 나열된다면 해당 항목을 해결하는 것이 다음 작업입니다. 마지막으로 apt update 명령은 패키지 인덱스를 새로 고치며, apt full-upgrade 명령은 업그레이드 이후 배포된 모든 업데이트를 설치합니다.

PostgreSQL 16에서 18로 업그레이드: 조용히 뒤에 남겨진 클러스터

Ubuntu 24.04는 PostgreSQL 16을, 26.04는 PostgreSQL 18을 기본으로 제공합니다. 업그레이드를 수행하면 18 버전이 16 버전과 나란히 설치되지만, 기존 데이터는 자동으로 이전되지 않습니다. Debian의 postgresql-common 계층은 기존 클러스터가 없을 때만 패키지 설치 시점에 main 클러스터를 생성하므로, 이미 PostgreSQL 16 클러스터가 존재한다면 5433 포트에 18 클러스터가 자동으로 생성되지 않습니다. 애플리케이션은 계속해서 5432 포트로 통신하며 아무런 오류도 발생하지 않기 때문에, 많은 사용자가 수개월이 지난 뒤에야 이 사실을 발견합니다.

pg_lsclusters

16 버전에 대한 항목이 존재한다면 해당 클러스터는 여전히 16 버전을 사용 중인 것입니다. 만약 pg_lsclusters 목록에 18 main 클러스터가 함께 표시된다면, 해당 클러스터가 비어 있는지 확인한 후 sudo pg_dropcluster --stop 18 main 명령으로 삭제하십시오. pg_upgradecluster는 이미 존재하는 대상 클러스터에는 데이터를 기록하지 않기 때문입니다. 애플리케이션을 중단할 수 있는 시점에 마이그레이션을 진행하십시오:

sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

기본 방식은 16 버전의 데이터를 덤프한 뒤 18 버전으로 다시 로드하는 것이므로, 데이터베이스 크기만큼의 여유 디스크 공간이 필요합니다. -m upgrade은 대신 pg_upgrade을 사용하며 대용량 데이터베이스에서 훨씬 빠르게 동작합니다. 작업이 완료되면 Port 열을 확인하십시오. 새 클러스터가 5432 포트를 점유하고 기존 클러스터는 중지된 상태로 남게 됩니다. 패키지 업그레이드 훅이 자동으로 analyze 과정을 수행하지만, 위 명령은 이를 명시적으로 다시 실행합니다.

새 클러스터에서 애플리케이션을 며칠간 테스트하십시오. 그 후에 기존 클러스터를 삭제하십시오:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

기존 클러스터의 데이터 디렉터리는 가장 빠른 롤백 수단입니다. 업그레이드 당일에 바로 삭제하지 마십시오.

MySQL 8.0에서 8.4로의 전환: 서버 실행을 막는 삭제된 옵션

26.04 버전은 MySQL을 8.0에서 8.4 LTS로 업그레이드하며, 이 과정에서 서버 운영에 영향을 주는 두 가지 변경 사항이 있습니다.

첫째, mysqld는 설정 파일에 새 버전에서 삭제된 옵션이 포함되어 있으면 실행을 거부합니다. default_authentication_plugin은 많은 구형 가이드에서 설정을 권장하기 때문에 흔히 발생하는 문제입니다. 서비스는 실패하며, journalctl -u mysql -n 50은 알 수 없는 변수를 직접 지목합니다. /etc/mysql/mysql.conf.d/ 아래의 파일에서 해당 줄을 삭제한 다음, sudo systemctl start mysql을 수행하십시오.

둘째, mysql_native_password 플러그인이 8.4부터 기본적으로 활성화되지 않으므로, 이를 사용하는 계정은 로그인이 불가능합니다. 8.0 버전 상태에서 다음을 확인하십시오:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

mysql_native_password를 사용하는 모든 계정을 업그레이드 전에 이전하고, 애플리케이션 설정에서 비밀번호를 업데이트하십시오:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

클라이언트 라이브러리가 너무 오래되어 caching_sha2_password을 지원하지 않는 경우, [mysqld] 아래에 mysql_native_password=ON을 추가하여 8.4에서 이전 플러그인을 다시 활성화할 수 있습니다. MySQL 9.0에서 해당 플러그인이 완전히 삭제되므로, 이는 임시 방편으로만 사용하십시오.

PHP 8.3에서 8.5로 업그레이드: 가상 호스트가 사라진 소켓을 참조함

24.04 버전은 PHP 8.3을, 26.04 버전은 PHP 8.5를 기본으로 제공합니다. 패키지는 버전별 경로에 설치되며, 웹 서버 설정 파일은 자동으로 수정되지 않습니다. fastcgi_pass unix:/run/php/php8.3-fpm.sock;를 포함하는 nginx 가상 호스트가 이제는 생성되지 않는 소켓을 참조하게 되어, 모든 PHP 요청이 502 오류를 반환하며 nginx 오류 로그에는 다음과 같이 기록됩니다.

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

새로운 소켓을 가리키도록 설정을 변경하고, 설정을 테스트한 뒤 리로드하십시오.

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

Apache와 mod_php를 사용하는 경우 증상이 다릅니다. Apache가 아예 시작되지 않으며, sudo apache2ctl -t은 파일이 존재하지 않아 libphp8.3.so을 로드할 수 없다고 보고합니다. 활성화된 모듈은 이제 사라진 패키지를 가리키는 심볼릭 링크 상태입니다.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

Ubuntu 24.04의 LAMP 스택 가이드를 따라 서버를 구축했다면, 해당 가이드가 버전이 명시된 모듈 이름과 소켓 경로를 사용하므로 두 경로 모두 확인해야 합니다.

php.ini 튜닝 설정도 자동으로 이전되지 않습니다. memory_limit, upload_max_filesize 및 기타 설정값들은 /etc/php/8.3/에 위치하며, 새로운 버전은 기본값으로 시작합니다. 두 파일을 비교(diff)하여 값을 수동으로 옮기십시오. 이전 파일을 새 파일 위에 그대로 덮어쓰면 8.3의 기본값이 8.5 설치 환경에 적용되어 문제가 발생합니다. 그 후 php -m을 실행하여 비교하십시오. php8.3-redis로 설치된 확장 기능은 해당 php8.5- 패키지가 필요합니다. 만약 PPA를 통해 설치했다면 업그레이드 과정에서 해당 소스가 비활성화되어 확장 기능이 누락될 수 있습니다.

인증서도 별도로 점검해야 합니다. 업그레이드 후 sudo certbot renew --dry-run --run-deploy-hooks를 실행하십시오. 이 명령은 실제 인증서를 건드리지 않고 웹 서버 리로드 훅을 포함한 전체 갱신 과정을 테스트합니다. 서비스 이름이나 바이너리 경로가 변경되어 훅이 실패하는 경우, 다음 갱신 시점에 조용히 실패하는 대신 지금 즉시 문제를 확인할 수 있습니다. nginx에서 Let's Encrypt와 Certbot 사용하기 문서에서 올바른 훅 설정 방법을 확인할 수 있습니다.

SSH: 작업 중인 세션을 종료시키는 오류

sshd_config 프롬프트는 사용자가 스스로 접속을 차단하게 만드는 지점입니다. Y에 응답하면 관리자가 제공한 파일이 설치되며, 사용자가 추가한 PermitRootLogin, PasswordAuthentication, AllowUsers, Port 및 기타 모든 설정 줄이 삭제됩니다. 방화벽이 사용자 지정 포트만 허용하는데 패키지 설정이 22번 포트에서 대기하도록 되어 있다면, 다음 접속은 거부되며 현재 작업 중인 세션이 마지막 접속이 됩니다.

업그레이드 전에 이를 방지해야 합니다. 24.04의 /etc/ssh/sshd_config은 Include /etc/ssh/sshd_config.d/*.conf로 시작합니다. OpenSSH는 대부분의 설정에서 처음 읽은 값을 우선하므로, 상단에 포함된 드롭인(drop-in) 설정이 하단의 동일한 설정보다 우선합니다. 몇 가지 키워드는 예외입니다. Port와 ListenAddress은 여러 값을 허용하므로, 드롭인 파일에 Port 줄을 추가하면 하단 설정이 대체되지 않고 포트가 추가됩니다. dpkg가 관리하지 않는 파일로 설정을 옮기십시오.

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

/etc/ssh/sshd_config에 사용자의 설정이 하나도 없으면, 프롬프트 응답은 중요하지 않게 됩니다. 어떤 응답을 선택하든 설정은 별도의 파일에 저장되어 있으므로 유지됩니다.

사용자 지정 포트를 사용하는 경우, 예상한 위치가 아닐 수 있으므로 한 가지를 더 확인해야 합니다.

systemctl is-enabled ssh.socket

이 명령이 enabled을 출력한다면, sshd가 아닌 systemd가 리스닝 포트를 엽니다. Ubuntu는 22.10부터 sshd에 소켓 활성화(socket activation)를 사용해 왔습니다. 24.04에서는 systemd 생성기가 sshd 설정에서 Port와 ListenAddress 설정을 읽어 소켓의 리스닝 주소로 변환하지만, 이는 systemd가 유닛을 다시 불러올 때만 수행됩니다. 이것이 Port 2222을 수정해도 아무런 변화가 없는 것처럼 보이는 이유입니다. 수정 사항은 sudo systemctl daemon-reload && sudo systemctl restart ssh.socket 이후에 적용되며, 패키지에 포함된 sshd_config에는 이제 이 내용이 명시되어 있습니다. 소켓 유닛에서 직접 포트를 설정하려면 sudo systemctl edit ssh.socket를 사용하십시오.

[Socket]
ListenStream=
ListenStream=2222

빈 ListenStream= 설정이 필요합니다. 이는 상속된 값을 지우며, 이 설정이 없으면 소켓은 2222번 포트뿐만 아니라 22번 포트에서도 대기하게 됩니다. sudo systemctl daemon-reload && sudo systemctl restart ssh.socket을 사용하여 적용하십시오.

업그레이드 후, 현재 세션을 닫기 전에 다음을 수행하십시오.

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

그런 다음 로컬 컴퓨터에서 두 번째 터미널을 열고 다시 로그인하십시오. 두 번째 터미널에서 셸이 정상적으로 작동하는 것만이 유일한 확인 방법입니다. 확인이 완료될 때까지 첫 번째 세션을 열어 두십시오. VPS에서 SSH 보안 강화하기에서 드롭인 파일에 유지할 가치가 있는 설정들을 다룹니다.

이미 너무 늦었다면, 제공자의 웹 콘솔을 통해 SSH를 거치지 않는 로그인 방식을 사용하십시오. 콘솔에 로그인하여 설정을 수정하고, sudo sshd -t를 실행한 뒤 서비스를 재시작하십시오. 업그레이드 도중이 아니라 업그레이드 전에 콘솔 접근성을 미리 테스트해야 하는 이유가 바로 이 콘솔 때문입니다.

FAQ

Ubuntu 24.04에서 do-release-upgrade 실행 시 "No new release found"가 발생하는 이유는 무엇입니까?

2026년 9월 29일부터는 이 메시지가 나타나지 않아야 합니다. 해당 날짜에 Canonical이 24.04 LTS에서 26.04.1로의 업그레이드를 활성화했기 때문입니다. 그 이전에는 이 메시지가 정상적인 동작이었습니다. Ubuntu 26.04 LTS는 2026년 4월 23일에 릴리스되었고, 26.04.1은 8월 27일에 뒤이어 나왔습니다. Canonical이 rust-coreutils 회귀 버그에 대한 수정 사항을 백포트하는 동안 업그레이드 경로는 몇 주간 닫혀 있었습니다. 여전히 이 메시지가 보인다면 /etc/update-manager/release-upgrades에 Ubuntu Server 기본값인 Prompt=lts이 설정되어 있는지 확인하십시오. 이 설정은 다음 LTS 릴리스만 제공합니다. 이를 lts로 변경하십시오.

업그레이드를 완료하려면 서버를 재부팅해야 합니까?

그렇습니다. 업그레이드는 새로운 커널, 새로운 C 라이브러리, 새로운 init 시스템을 설치합니다. 실행 중인 시스템은 재시작 전까지 이전 버전을 계속 사용합니다. do-release-upgrade은 작업 종료 시 재부팅을 요청합니다. "나중에" 재부팅하려고 서버를 계속 켜두면 두 릴리스가 혼재된 상태로 운영됩니다. 재부팅 후에는 uname -r를 통해 새로운 커널을 확인하고, systemctl --failed를 통해 정상적으로 시작되지 않은 서비스를 확인하십시오.

제자리 업그레이드를 해야 합니까, 아니면 26.04 서버를 새로 구축해야 합니까?

가능하다면 새로 구축하는 것을 권장합니다. 새로운 VPS를 사용하면 기존 서버가 트래픽을 처리하는 동안 스택을 설치하고 데이터를 복원하며 모든 것을 테스트할 수 있습니다. 따라서 롤백 시 백업 복원이 아닌 DNS 변경만으로 대응이 가능합니다. 제자리 업그레이드는 이동하기 어려운 상태를 서버가 유지하고 있거나, 제공업체가 머신당 비용을 청구하거나, 스냅샷과 검증된 콘솔 접근 권한이 있을 때 수행하십시오. 제자리 업그레이드 경로는 잘 검증되어 있지만, 작업이 진행되는 동안에는 되돌릴 수 없는 단방향 경로입니다.

업그레이드 도중 SSH 연결이 끊기면 어떻게 됩니까?

서버 업그레이더는 일반적으로 GNU screen을 사용하므로, SSH 연결이 끊긴다고 해서 업그레이드가 즉시 중단되지는 않습니다. 위에서 언급한 tmux 세션 내부에서 시작했다면, 다시 연결한 후 tmux attach -t upgrade을 실행하여 작업을 이어가십시오. 업그레이더는 또한 진입 경로를 확보하기 위해 1022번 포트에서 예비 SSH 데몬을 시작합니다. 하지만 방화벽을 자동으로 열지는 않으므로, 작업 전에 직접 1022번 포트를 허용하고 작업 완료 후 다시 닫아야 합니다.

업그레이드 후 PHP 사이트에서 502 오류가 발생합니다. 무엇이 문제입니까?

버전이 바뀌면서 PHP FPM 소켓 경로가 변경되었습니다. Ubuntu 24.04는 PHP 8.3을, 26.04는 PHP 8.5를 실행합니다. 따라서 nginx 가상 호스트 설정에 여전히 이전 경로가 남아 있으면 /run/php/php8.3-fpm.sock이 존재하지 않게 됩니다. nginx 오류 로그에는 connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)이 기록됩니다. fastcgi_pass를 8.5 소켓 경로로 업데이트하고 sudo nginx -t을 실행한 뒤 nginx를 리로드하십시오. mod_php를 사용하는 Apache의 경우, 동일한 수정 작업으로 sudo a2dismod php8.3을 수행한 후 sudo a2enmod php8.5를 실행하고 서비스를 재시작해야 합니다.