ubuntu-latest가 Ubuntu 26.04로 바뀝니다. 롤아웃은 2026년 10월 19일에 시작해 11월 19일에 끝나고, 그사이에 ubuntu-latest 라벨을 쓰는 워크플로가 순서대로 새 이미지에 올라탑니다(Ubuntu 26 generally available and latest migration). 버전을 그대로 두고 싶은 레포는 runs-on: ubuntu-24.04로 못 박아 두면 그만입니다. 아래 버전과 날짜는 2026년 9월 18일 기준이며, 두 이미지 문서가 갱신되면 숫자도 함께 바뀝니다.

「Ubuntu 26 generally available and latest migration (GitHub Changelog)」 문서 화면

출처: 「Ubuntu 26 generally available and latest migration (GitHub Changelog)」, github.blog. 2026-09-18 캡처.

바뀌는 폭이 좁지 않습니다.

시스템 Python이 3.12에서 3.14로, Node.js가 22에서 24로 올라갔고 Miniconda·Julia·Swift는 이미지에서 통째로 빠졌어요. 반대로 actions/setup-python 계열이 꺼내 쓰는 툴캐시 목록은 두 이미지가 같아서, 버전을 명시해 둔 워크플로는 흔들릴 자리가 적습니다.

ubuntu-latest는 언제 26.04로 바뀌나요?

날짜가 세 개 있습니다. 2026년 9월 17일에 ubuntu-26.04와 ubuntu-26.04-arm 이미지가 공개 프리뷰를 끝내고 정식 지원으로 올라갔고, ubuntu-latest 라벨의 이동은 10월 19일에 시작해 11월 19일에 마무리되는 일정입니다(ubuntu-latest 라벨의 26.04 이전 일정 공지).

「ubuntu-latest 라벨의 26.04 이전 일정 공지 (actions/runner-images #14748)」 문서 화면

출처: 「ubuntu-latest 라벨의 26.04 이전 일정 공지 (actions/runner-images #14748)」, github.com. 2026-09-18 캡처.

한 번에 갈아치우는 방식이 아닙니다. 공지는 몇 주에 걸쳐 단계적으로 내보낸다고 적어 두었고, 그 기간에는 같은 라벨을 쓰는 잡이라도 24.04에 걸릴 때와 26.04에 걸릴 때가 섞입니다. 같은 커밋을 다시 돌렸을 때 CI 결과가 달라질 수 있는 구간이 여기예요.

세 번째 날짜는 22.04 쪽입니다. Ubuntu 22.04와 22.04-arm 이미지의 지원 종료 절차는 2026년 9월 17일에 시작됐고, 2027년 4월 17일이면 완전히 지원 밖으로 나갑니다(Ubuntu 22 기반 러너 이미지 지원 종료 공지 (actions/runner-images #14254)). 그 전에 사람들 눈에 띄게 하려고 잡을 일부러 실패시키는 브라운아웃이 3월 23일·3월 30일·4월 6일·4월 13일 네 차례 예고돼 있고, 각각 14:00 UTC에 시작합니다. 완전 종료가 2027년 4월 17일이니 이 날짜들은 그 직전 몇 주에 해당하고, 그 시간대에 돌도록 예약된 빌드는 실패합니다.

GitHub 쪽이 밝힌 기준은 단순합니다. 안정 버전 두 개만 유지한다는 원칙이라, 26.04가 정식으로 올라온 순간 세 번째였던 22.04가 밀려난 구조예요.

22.04를 쓰던 워크플로는 ubuntu-24.04, ubuntu-26.04, ubuntu-latest 중 하나로 바꾸라고 안내돼 있고, ubuntu-22.04-arm은 ubuntu-24.04-arm이나 ubuntu-26.04-arm으로 옮기라고 적혀 있습니다. 라벨을 그대로 두면 잡이 오류와 함께 종료됩니다.

runs-on에 ubuntu-26.04 라벨 넣는 방법

라벨 두 개가 새로 열렸습니다. x64는 ubuntu-26.04, Arm64는 ubuntu-26.04-arm이고 워크플로 파일에 이렇게 적습니다.

jobs:
  build:
    runs-on: ubuntu-26.04

  build-arm:
    runs-on: ubuntu-26.04-arm

같은 라벨이 Azure DevOps 파이프라인에도 적용됩니다(Ubuntu 26.04 x64·Arm64 이미지 정식 지원 공지). GitHub Actions만 대상인 변경이 아니라는 뜻이라, Azure Pipelines를 함께 쓰는 팀은 양쪽을 같이 봐야 합니다.

「Ubuntu 26.04 x64·Arm64 이미지 정식 지원 공지 (actions/runner-images #14747)」 문서 화면

출처: 「Ubuntu 26.04 x64·Arm64 이미지 정식 지원 공지 (actions/runner-images #14747)」, github.com. 2026-09-18 캡처.

사양은 26.04로 옮겨도 그대로입니다. 공개 레포에서 ubuntu-latest·ubuntu-24.04·ubuntu-26.04 라벨은 모두 4코어 CPU에 16GB 메모리, 14GB SSD를 받고, 비공개 레포에서는 2코어에 8GB 메모리, 14GB SSD입니다(GitHub-hosted runners reference). Arm64 라벨도 같은 값이라 아키텍처를 바꾼다고 메모리가 줄지는 않습니다.

요금은 아키텍처에 따라 갈립니다. 공개 레포의 표준 러너는 무료에 사용량 제한이 없고, 비공개 레포 쪽은 계정에 딸린 무료 분 할당량을 먼저 당겨 쓴 다음부터 분 단위 요금이 붙는 구조입니다(GitHub-hosted runners reference). 그때 적용되는 단가가 Linux 2코어 x64는 분당 0.006달러, Linux 2코어 Arm64는 분당 0.005달러입니다(Actions minute multipliers). 무료 분을 다 쓰고도 CI를 계속 돌리는 레포라면, 액션 호환성만 맞으면 Arm 쪽 단가가 낮은 편입니다.

한 줄 더 얹자면 ubuntu-slim이라는 1코어 라벨도 따로 있습니다. 메모리 5GB에 잡 제한 시간이 15분이고, VM이 아니라 비특권 컨테이너에서 돌기 때문에 파일시스템 마운트나 Docker-in-Docker가 막혀 있습니다. 단가는 분당 0.002달러로 앞의 두 라벨보다 낮지만 일반적인 빌드용은 아니에요.

Python 3.14, Node.js 24로 올라간 기본 런타임

이미지에 박혀 있는 런타임 버전이 크게 움직였습니다. Ubuntu 26.04 이미지 문서에는 Python 3.14.4, Node.js 24.20.0, Ruby 3.3.8, PHP 8.5.4, Perl 5.40.1, Bash 5.3.9가 올라 있고, Ubuntu 24.04 이미지 문서의 같은 자리는 Python 3.12.3, Node.js 22.23.2, Ruby 3.2.3, PHP 8.3.6, Perl 5.38.2, Bash 5.2.21입니다.

컴파일러 쪽도 한 단계가 아니라 두세 단계씩 뛰었습니다. GNU C++이 12·13·14 조합에서 13·14·15 조합으로, Clang이 16·17·18에서 20·21·22로 바뀌었어요. 배포판 차원에서는 GCC가 14에서 15.2로, binutils가 2.42에서 2.46으로, glibc가 2.39에서 2.43으로, LLVM이 18에서 21로, Rust가 1.75에서 1.93으로, Go가 1.22에서 1.25로 올라간 결과입니다(Ubuntu 26.04 LTS release notes).

여기서 갈리는 지점이 하나 있습니다.

툴캐시는 안 바뀌었습니다. setup-python·setup-node·setup-go·setup-ruby 계열이 꺼내 쓰는 캐시 목록을 보면 두 이미지가 글자 하나까지 같아요. Python은 3.10.21부터 3.14.7까지 다섯 갈래가 그대로 있고, Node.js는 22.23.2와 24.20.0 두 갈래, Go는 1.24.13과 1.25.14, 1.26.8이 남아 있습니다. Ruby도 3.2.11에서 4.0.6까지 네 갈래가 양쪽 이미지에 똑같이 들어 있고요. 워크플로에 python-version: '3.12'처럼 버전을 적어 둔 레포는 26.04로 넘어가도 같은 인터프리터를 받습니다.

위험한 건 버전을 안 적고 시스템 실행 파일을 그냥 부르는 스크립트입니다. python3 -m pip install이나 #!/usr/bin/env python3 로 시작하는 헬퍼가 그렇고, 이쪽은 라벨이 26.04로 넘어가는 차례가 오는 순간부터 3.12가 아니라 3.14를 만나게 됩니다. pip도 24.0에서 25.1.1로, npm은 10.9.8에서 11.19.0으로 함께 올라갑니다.

컨테이너와 빌드 도구 쪽 숫자도 적어 두면 이렇습니다. Docker 클라이언트·서버가 28.0.4에서 29.4.2로, Docker Compose가 2.38.2에서 5.1.3으로, Helm이 3.21.4에서 4.2.4로, CMake가 3.31.6에서 4.4.3으로, Podman이 4.9.3에서 5.7.0으로, Buildah가 1.33.7에서 1.42.1로, OpenSSL이 3.0.13에서 3.5.5로 바뀌었습니다. Helm과 CMake는 메이저 번호가 통째로 넘어간 경우라 옵션이나 최소 버전 선언을 쓰는 프로젝트는 손댈 곳이 생깁니다.

거꾸로 내려간 것도 있어요. Maven이 24.04 이미지의 3.9.16에서 26.04 이미지의 3.9.15로 한 칸 뒤로 갔습니다. 커널은 6.17.0-1022-azure에서 7.0.0-1012-azure로, systemd는 255에서 259로 올라갔고, Canonical은 26.04가 systemd에서 System V 서비스 스크립트 호환을 지원하는 마지막 릴리스라고 못 박아 두었습니다.

브라우저 쪽은 조용합니다. Chrome 152.0.7977.82, Edge 152.0.4191.66, Firefox 155.0, Selenium 서버 4.48.0, Geckodriver 0.37.1이 두 이미지 모두 동일해서 E2E 테스트만 돌리는 레포는 이번 전환에서 건드릴 것이 거의 없습니다.

Miniconda가 사라졌습니다, Julia와 Swift도 빠졌어요

버전이 올라간 것보다 아예 없어진 쪽이 더 아픕니다. 두 이미지 문서를 나란히 놓고 보면 24.04에는 있는데 26.04에는 없는 항목이 이렇게 나옵니다. Miniconda 26.7.1, Julia 1.12.7, Swift 6.3.3, Lerna 10.0.1, Fastlane 2.239.0, Mercurial 6.7.2, MediaInfo 24.01, Newman 6.2.2, Parcel 2.16.4, Pulumi 3.261.0, Haveged 1.9.14, Sphinx Open Source Search Server 2.2.11입니다.

환경변수도 같이 비었습니다. 24.04 이미지의 CONDA는 /usr/share/miniconda를 가리키지만 26.04 이미지에서는 값이 비어 있어서, $CONDA/etc/profile.d/conda.sh를 읽어 들이는 단계가 있으면 그 줄에서 파일을 찾지 못합니다. 반대로 VCPKG_INSTALLATION_ROOT는 /usr/local/share/vcpkg로 양쪽이 같습니다.

Swift는 빠진 상태로 정식 출시가 됐습니다. 24.04 이미지 문서에 Swift 6.3.3으로 올라 있던 자리가 26.04 이미지 문서에는 없으니, Swift 빌드를 돌리던 워크플로는 액션이나 설치 스크립트로 직접 넣는 쪽을 준비해 두는 편이 낫습니다.

그리고 여기서 GitHub 공지의 아쉬운 점이 드러납니다.

정식 출시 공지에 붙은 24.04 대 26.04 비교표는 열한 줄인데, 그중 일곱 줄이 Docker Buildx 0.37.0·Minikube 1.39.0·AWS CLI 2.36.40·Azure CLI 2.90.0·Google Cloud CLI 583.0.0·Rust 1.98.1·Firefox 155.0처럼 양쪽 이미지에 모두 있다는 설명으로 끝나고, 여덟 번째 줄인 Java는 기본값이 17로 유지된다고 적혀 있습니다. 실제로 달라진 것은 운영체제·커널·systemd 세 줄뿐이고, Miniconda가 사라졌다는 사실은 그 표 어디에도 없습니다. 공지 스스로 전체 목록이 아니라고 단서를 달아 두긴 했지만, 깨질 자리를 찾으려면 결국 두 이미지 문서를 직접 비교해야 하는 구조예요.

MySQL 8.4 mysql_native_password 오류는 왜 나나요?

이미지에 설치된 데이터베이스 버전이 세대 단위로 올라갔습니다. MySQL이 8.0.46에서 8.4.11로, PostgreSQL이 16.15에서 18.6으로, sqlite3가 3.45.1에서 3.46.1로 바뀌었습니다.

MySQL 쪽이 조용히 지나가지 않습니다. Canonical 릴리스 노트는 MySQL 8.4가 mysql_native_password 플러그인을 지원 중단했고 그 방식으로 인증하던 계정은 기본적으로 잠긴다고 적고 있습니다. 테스트용 계정을 예전 방식으로 만들어 두고 이미지의 MySQL을 그대로 쓰던 워크플로라면 26.04에서 로그인 단계부터 막힙니다.

권장 경로는 계정의 인증 방식을 바꾸는 것입니다.

ALTER USER 'user'@'host' IDENTIFIED WITH caching_sha2_password BY 'password';

이 명령은 비밀번호를 새로 설정하는 동작이라, 워크플로에 박아 둔 값과 어긋나지 않게 같이 맞춰야 합니다. 옛 방식을 계속 써야 하면 /etc/mysql/mysql.conf.d/mysqld.cnf의 [mysqld] 아래에 mysql_native_password = ON을 넣는 우회로가 있는데, 릴리스 노트는 MySQL 9.7 이상이 들어갈 이후 우분투 릴리스에서는 이 방법이 통하지 않는다고 미리 적어 두었습니다. 32비트 MySQL 서버는 상위 정책에 따라 아예 제공되지 않고, 8.4용 클라이언트와 클라이언트 라이브러리만 armhf·i386에 계속 제공됩니다.

PostgreSQL 18은 읽기 성능 쪽 이야기가 큽니다. 새 I/O 서브시스템이 스토리지에서 읽어 들이는 작업에서 최대 3배까지 개선된 사례가 있다고 하고, 메이저 버전 업그레이드 자체도 덜 끊기게 바뀌었다는 설명입니다. 가상 생성 컬럼과 uuidv7() 함수, OAuth 2.0 인증 지원이 새로 들어왔습니다.

워크플로가 services: 블록으로 MySQL이나 PostgreSQL 컨테이너를 따로 띄운다면 이 항목들은 해당 사항이 없습니다. 그쪽 버전은 워크플로 파일에 적힌 이미지 태그를 따라가니까요.

24.04 고정과 arm64 apt 멈춤 버그, 지금 옮겨도 될까요?

당장 옮기기 싫으면 라벨만 바꿔 두면 끝납니다.

jobs:
  build:
    runs-on: ubuntu-24.04

이 고정이 얼마나 갈지도 계산이 섭니다. 안정 버전 두 개를 유지한다는 원칙에서 지금 남은 두 개가 24.04와 26.04라, 24.04는 다음 LTS 이미지가 정식으로 올라오기 전까지 자리를 지킵니다. 22.04에 아직 남아 있는 레포라면 브라운아웃이 시작되기 전에 움직여야 하고요.

Arm64는 이야기가 다릅니다. ubuntu-26.04-arm 러너에서 apt install이 자주 멈춘다는 신고가 2026년 9월 11일에 runner-images 레포에 올라왔습니다(Ubuntu 26.04 Arm64 frequently hangs on apt package installation). 패키지 177개를 새로 받는 작업이 azure.archive.ubuntu.com의 resolute 저장소에서 진행되다 5분 제한에 걸려 죽는 로그가 붙어 있습니다. 이슈 제목과 재현 절차가 모두 ubuntu-26.04-arm 러너를 가리키고 있고요.

이 이슈는 정식 출시 공지가 나간 9월 17일에도 닫히지 않은 채 bug report와 needs eyes 라벨을 달고 열려 있습니다. 정식 지원이라는 말과 실제 안정성이 같은 뜻은 아니라는 신호예요.

그래서 지금 시점의 판정은 아키텍처별로 갈립니다. x64는 ubuntu-26.04 라벨을 붙인 잡을 하나 만들어 병렬로 돌려 두는 편이 10월 19일 이후에 급하게 뛰는 것보다 낫습니다. Arm64는 프로덕션 CI 전체를 옮기기에 이르고, apt로 패키지를 많이 설치하는 잡이라면 더 그렇습니다.

Ubuntu 26.04 자체는 2026년 4월 23일자로 공개된 LTS입니다(Ubuntu 26.04 LTS 릴리스 노트). 러너 이미지 쪽이 다섯 달 늦게 정식 지원으로 붙은 셈인데, 그사이 쌓인 프리뷰 기간이 arm64 쪽에서는 아직 부족했던 모양입니다.

10월 19일까지 한 달이 남았습니다. 그 사이에 할 일은 레포 검색창에 ubuntu-latest를 넣고 몇 줄이 걸리는지 세어 보는 것 정도네요.

참고 자료

</content> </invoke>