Ubuntu 24.04에서 26.04 업그레이드 방법 및 주의사항

Ubuntu 24.04에서 26.04로 업그레이드는 언제 가능한가?

VPS에서 Ubuntu 24.04를 26.04로 업그레이드하는 작업은 2026년 8월 27일로 예정된 26.04.1 포인트 릴리스가 출시된 이후에 가능합니다. 그전까지는 의도적으로 24.04 서버에서 새 릴리스를 감지하지 못하도록 설정되어 있습니다. Ubuntu 26.04 LTS(Resolute Raccoon)는 2026년 4월 23일에 출시되었으나, Canonical은 첫 번째 포인트 릴리스가 나올 때까지 LTS에서 LTS로의 업그레이드 경로를 열어두지 않습니다. 해당 릴리스에는 출시 후 수개월 동안 발견된 설치 및 업그레이드 관련 버그가 수정되어 포함되기 때문입니다. 버전 번호 체계가 생소하다면 26.04.1은 다른 Ubuntu가 아니라 4개월간의 수정 사항이 반영된 동일한 26.04 버전이라는 점을 참고하십시오. 이것이 바로 Canonical이 기존 서버에 제공하는 첫 번째 버전인 이유입니다.

2026년 8월 초에 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 릴리스만 제안하며, 그마저도 .1 포인트 릴리스가 존재할 때만 가능하다는 의미입니다. 대신 Prompt=normal으로 설정하면 이미 수명 주기가 종료된 24.10, 25.04, 25.10과 같은 중간 릴리스를 순차적으로 거치게 됩니다. 설정을 lts로 유지하고 기다리십시오. Canonical의 일정은 변경될 수 있으므로, 예정일이 지나도 소식이 없다면 다시 확인해 보시기 바랍니다.

아래의 모든 명령어는 사용자가 직접 자신의 서버에서 순서대로 실행해야 합니다. 릴리스 업그레이드는 업그레이드 중인 시스템에서 미리 연습해 볼 수 없습니다. 이 과정은 커널과 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이 아무것도 출력하지 않는다면 업그레이드를 방해할 버전으로 고정(pin)된 패키지가 없다는 뜻입니다. 목록에 나오는 패키지는 sudo apt-mark unhold과 패키지 이름을 사용하여 고정을 해제하거나, 고정된 이유를 확인하고 여기서 작업을 중단하십시오.

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

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

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

df -h / /boot

/의 여유 공간이 5 GB 미만일 경우 문제가 발생합니다. /boot이 300 MB 미만이면 나중에 커널 설치 과정에서 No space left on device 오류와 함께 실패합니다. 보통 오래된 커널이 원인이며, 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 시스템을 손상시킬 수 있기 때문입니다. 도구는 인식 가능한 저장소만 다시 활성화하고 나머지는 주석 처리합니다. 도구가 임의로 결정하기 전에 현재 어떤 패키지를 사용 중인지 파악해야 합니다.

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/에 있는 모든 항목은 고정(pin) 설정이며, 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.

공급업체가 새 버전을 배포할 때까지 해당 소스를 비활성화 상태로 두십시오. 공급업체가 빌드하지 않은 코드네임으로 임의 수정하는 것은 잘못된 시스템 라이브러리와 연결된 패키지를 설치하는 원인이 됩니다.

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

일반 로그인 셸에서 do-release-upgrade이 실행되는 도중 연결이 끊기면, 프로세스는 SIGHUP 신호를 받고 압축 해제 도중 종료됩니다. 이로 인해 dpkg는 절반만 설정된 상태가 되며, 서버는 네트워크 스택이 정상 작동하지 않아 재접속이 불가능해질 수 있습니다. 터미널 멀티플렉서 내부에서 실행하면 클라이언트 연결이 끊겨도 서버의 프로세스는 계속 유지됩니다.

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 sources가 noble과 resolute로 나뉘어 있다면 실패한 릴리스 업그레이드 복구에서 패키지 상태를 복구하는 방법과 복구를 중단하고 대신 스냅샷을 복원해야 하는 시점을 설명한다.

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

dpkg는 사용자가 직접 수정했거나 스크립트에 의해 변경된 파일에 대해서만 프롬프트를 표시합니다. 따라서 모든 프롬프트는 사용자가 의도적으로 수정한 파일에 관한 것이며, 단순히 엔터 키를 눌러 넘어가는 행위는 보안이 강화된 서버를 기본 설정 상태로 되돌리는 결과를 초래합니다.

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은 잘못 응답할 경우 세션이 종료될 수 있으며, 웹 서버 설정 파일은 잘못 응답할 경우 사이트 접속이 중단될 수 있기 때문입니다.

업그레이드 과정에서 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 명령은 릴리스 이미지 빌드 이후 배포된 업데이트를 적용합니다.

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

Ubuntu 24.04는 PostgreSQL 16을 제공하며, 26.04는 PostgreSQL 18을 제공합니다. 업그레이드를 수행하면 16 옆에 18이 설치되지만 데이터는 이동하지 않습니다. Debian의 postgresql-common 계층은 다음 가용 포트에 새 메이저 버전을 위한 빈 클러스터를 생성합니다. 따라서 16은 모든 데이터를 유지한 채 5432 포트를 점유하고, 18은 5433 포트에서 비어 있는 상태로 대기합니다. 애플리케이션은 계속해서 5432 포트로 통신하며 겉보기에는 아무런 문제가 없기 때문에, 많은 사용자가 몇 달이 지나서야 이 사실을 발견하곤 합니다.

pg_lsclusters

두 개의 클러스터가 나열되어 있다면 마이그레이션이 완료되지 않은 것입니다. 애플리케이션을 중단할 수 있을 때 다음 작업을 수행하십시오.

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

먼저 비어 있는 18 클러스터를 삭제하십시오. pg_upgradecluster는 이미 존재하는 대상 클러스터에는 데이터를 기록하지 않기 때문입니다. 기본 방식은 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에서 이전 플러그인을 다시 활성화할 수 있습니다. 해당 플러그인은 완전히 제거될 예정이므로, 이 방법은 기한이 정해진 임시 방편으로만 사용하십시오.

PHP 8.3에서 8.5로 업그레이드: vhost가 사라진 소켓을 참조하는 경우

24.04 버전은 PHP 8.3을, 26.04 버전은 PHP 8.5를 기본으로 제공합니다. 패키지는 버전별 경로에 설치되며, 웹 서버 설정 파일은 자동으로 수정되지 않습니다. fastcgi_pass unix:/run/php/php8.3-fpm.sock;을 참조하던 nginx vhost는 이제 생성되지 않는 소켓을 가리키게 되며, 모든 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을 실행하십시오. 이 명령은 실제 인증서를 건드리지 않고 웹 서버 리로드 훅을 포함한 전체 갱신 과정을 테스트합니다. 서비스 이름이나 바이너리가 변경되어 훅이 실패하는 경우, 60일 뒤에 문제가 발생하는 대신 지금 즉시 확인할 수 있습니다. 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) 파일이 하단의 모든 설정을 덮어씁니다. 설정을 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이라면 systemd가 포트를 제어하고 있는 것이며, sshd_config의 Port 설정은 무시됩니다. Ubuntu는 22.10부터 sshd에 소켓 활성화(socket activation)를 사용하며, 이것이 Port 2222를 수정해도 아무런 변화가 없는 이유입니다. sudo systemctl edit ssh.socket을 사용하여 소켓 유닛에서 설정을 변경하십시오:

[Socket]
ListenStream=
ListenStream=2222

비어 있는 ListenStream= 설정이 필요합니다. 이는 상속된 값을 초기화하며, 이 설정이 없으면 소켓은 22번 포트와 2222번 포트 모두에서 대기하게 됩니다. 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"가 나타나는 이유는 무엇입니까?

/etc/update-manager/release-upgrades 파일에 Prompt=lts 설정이 포함되어 있기 때문입니다. 이 설정은 다음 장기 지원(LTS) 릴리스의 첫 번째 포인트 릴리스가 출시된 이후에만 업그레이드를 제공합니다. Ubuntu 26.04 LTS는 2026년 4월 23일에 출시되었으며, 26.04.1은 2026년 8월 27일로 예정되어 있습니다. 해당 날짜 이전에는 24.04 서버에서 새 릴리스를 감지하지 못합니다. 중간 릴리스를 거치게 만드는 Prompt=normal으로 설정을 변경하기보다는 현재 설정을 그대로 유지하십시오.

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

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

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

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

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

일반 로그인 셸에서 작업하면 프로세스가 SIGHUP 신호를 받아 중간에 종료되며, 이로 인해 dpkg가 불완전하게 설정됩니다. tmux 또는 screen 내부에서 작업을 시작하면 프로세스가 유지되므로, 재접속 후 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를 다시 로드하십시오. Apache의 mod_php를 사용하는 경우 sudo a2dismod php8.3 명령으로 수정하고 sudo a2enmod php8.5 명령을 실행한 뒤 서비스를 재시작하십시오.