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로의 업그레이드 경로를 열어두지 않습니다. 해당 릴리스에는 출시 초기 몇 달간 발견된 설치 및 업그레이드 관련 버그가 수정되어 포함되기 때문입니다.

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를 실행하십시오. 사용자가 없는 동안에도 업그레이드는 계속 진행됩니다.

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 명령은 실행 중인 실패 유닛이 없음을 보여야 하며, 만약 목록에 유닛이 나타난다면 해당 유닛을 수정하는 것이 다음 작업입니다. 마지막으로 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을 수행하십시오.

둘째, 8.4 버전부터는 mysql_native_password 플러그인이 기본적으로 활성화되지 않으므로, 해당 플러그인을 사용하는 계정은 로그인이 불가능합니다. 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는 각 설정에 대해 처음 읽은 값을 유지하므로 상단에 포함된 드롭인 설정이 하단의 모든 설정을 덮어씁니다. 설정을 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"라고 출력하는 이유는 무엇입니까?

Ubuntu Server의 /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를 다시 로드하십시오. mod_php를 사용하는 Apache의 경우, sudo a2dismod php8.3을 실행한 다음 sudo a2enmod php8.5을 수행하고 서비스를 재시작하면 해결됩니다.