[MySQL] 8.0을 그냥 두면 RDS 요금이 붙습니다 — 8.4와 9.7 사이에서 고르기

RDS 청구서를 보다가 못 보던 항목이 생겼다면 확인해 볼 것이 있습니다. MySQL 8.0을 쓰고 있는지입니다.

MySQL 8.0은 2026년 4월 30일에 확장 지원까지 끝났습니다. 그리고 Amazon RDS의 표준 지원은 2026년 7월 31일에 종료됐습니다. 그 뒤로도 8.0 인스턴스를 그대로 두면 AWS가 유료 확장 지원에 자동으로 등록하고 vCPU 시간당 요금을 청구합니다. 지금은 이미 그 시점을 지났습니다.

그런데 막상 올리려고 보면 선택지가 하나가 아닙니다. 8.4 LTS가 있고, 2026년 4월에 나온 9.7 LTS도 있습니다. 이 글에서는 어디로 갈지 정하는 기준과 가는 길에 깨지는 것들을 정리합니다.

Oracle의 MySQL 릴리스 정책과 8.4 릴리스 노트, AWS RDS 문서를 확인해 정리했습니다(확인일 2026-08-30). 직접 운영 DB를 올린 기록이 아니라 공식 문서 기준입니다.

MySQL 8.0·8.4·9.7의 지원 종료 시점 비교

지금 어디쯤 와 있나요

날짜부터 정리하면 이렇습니다.

버전	출시	프리미어 지원 종료	확장 지원 종료	성격
8.0	2018-04-08	2025-04-30	2026-04-30	LTS (종료)
8.4	2024-04-10	2029-04-30	2032-04-30	LTS
9.7	2026-04-21	2034-04-21	—	LTS

9.0부터 9.6까지는 Innovation 릴리스라 다음 버전이 나오면 바로 지원이 끝났습니다. 예를 들어 9.0은 2024년 6월에 나와 그해 10월에 지원이 끝났습니다. 프로덕션에 올릴 대상이 아니라는 뜻이죠. 9.7이 그 계열에서 처음 나온 LTS입니다.

클라우드는 별도의 시계로 움직입니다.

• AWS RDS: 8.0 표준 지원 2026년 7월 31일 종료. 이후 유료 확장 지원이 자동 적용되며 2029년 7월 31일까지입니다.
• Google Cloud SQL: 유료 확장 지원이 2027년 1월부터, 2029년 7월에 8.4로 강제 업그레이드가 예정돼 있습니다.
• Oracle HeatWave: 8.0을 2027년 4월까지 연장한 뒤 8.4로 강제 전환합니다.

AWS를 쓰신다면 자동 등록이 핵심입니다. 인스턴스를 만들거나 복원할 때 수명주기 플래그를 따로 끄지 않으면 그대로 유료 구간에 들어갑니다. 청구서를 안 보고 있었다면 8월분부터 이미 붙고 있을 수 있습니다.

8.4로 갈까요, 9.7로 갈까요

먼저 알아야 할 제약이 있습니다. 건너뛸 수 없습니다.

"You cannot directly upgrade between Innovation releases of different major versions. Instead, you must first upgrade to the nearest LTS release, and then to the following Innovation release."

메이저를 건너뛰는 업그레이드는 지원되지 않습니다. 8.0에서 9.7로 한 번에 갈 수 없고 8.0 → 8.4 → 9.x 순서를 밟아야 합니다. 그러니까 9.7이 목적지여도 8.4는 반드시 거치는 경유지입니다.

이 사실이 결정을 단순하게 만듭니다.

8.4에서 멈출 팀. 2029년 4월까지 3년 가까이 시간을 벌 수 있고, 그 사이에 9.x 계열이 충분히 검증됩니다. 운영 인력이 적거나 DB를 자주 못 건드리는 조직이라면 여기서 멈추는 게 합리적입니다. 클라우드 관리형 서비스의 기본 목적지도 대부분 8.4입니다.

9.7까지 갈 팀. 2034년까지 한 번에 확보하고 싶고, 업그레이드 창을 자주 열기 어려운 경우입니다. 다만 8.4를 거쳐야 하니 다운타임 창이 두 번 필요합니다. 그리고 9.7은 나온 지 넉 달 남짓이라 사내 도구·드라이버·ORM 호환성을 따로 확인해야 합니다.

당장 못 올리는 팀. 8.0에서만 동작하는 레거시 클라이언트나 인증 방식에 묶여 있다면, 유료 확장 지원 기간을 예산에 넣고 일정을 다시 잡는 편이 낫습니다. 다만 이건 시간을 사는 것이지 문제를 푸는 게 아닙니다.

8.0에서 9.7로 가려면 8.4를 반드시 거칩니다

8.0에서 8.4로 갈 때 깨지는 것들

릴리스 노트를 보면 실무에서 걸리는 항목이 몇 가지로 좁혀집니다.

첫째, mysql_native_password입니다. 8.0에서 deprecated였고 8.4에서는 기본 비활성입니다. 이 플러그인을 쓰는 계정은 인증에 실패합니다. 오래된 애플리케이션이나 커넥터를 쓰는 프로젝트에서 가장 많이 걸립니다.

올리기 전에 이 쿼리로 대상을 먼저 뽑으시면 됩니다.

SELECT user, host, plugin
FROM mysql.user
WHERE plugin = 'mysql_native_password';

나오는 계정이 있으면 caching_sha2_password로 옮기는 것이 원칙입니다. 다만 릴리스 노트에 되살리는 방법도 함께 적혀 있습니다.

"The deprecated mysql_native_password authentication plugin is now disabled by default. It can be enabled by starting MySQL with the new --mysql-native-password=ON server option, or by adding mysql_native_password=ON to the [mysqld] section of your MySQL configuration file."

삭제가 아니라 기본 비활성이라 서버 옵션으로 다시 켤 수 있습니다. 오래된 클라이언트를 한 번에 못 고치는 팀이라면 이걸로 시간을 벌 수 있죠. 다만 임시방편이라는 점은 분명히 해 두시는 게 좋습니다. 8.0 시절의 default_authentication_plugin은 authentication_policy로 대체됐습니다.

둘째, 예약어가 늘었습니다. MANUAL, PARALLEL, QUALIFY, TABLESAMPLE 같은 단어가 예약어가 됐습니다. 컬럼명이나 별칭으로 따옴표 없이 쓰고 있었다면 쿼리가 깨집니다. 컴파일 단계에서 안 잡히고 실행할 때 문법 오류로 나오는 유형이라 배포 후에 발견되기 쉽습니다.

셋째, 스키마 제약이 강해졌습니다. FLOAT이나 DOUBLE 컬럼에는 AUTO_INCREMENT를 쓸 수 없습니다. 오래된 테이블에서 가끔 나옵니다.

넷째, 제거된 함수가 있습니다. WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS()가 사라졌습니다. 복제 스크립트에서 쓰고 있었다면 대체가 필요합니다.

MySQL 8.4.0 릴리스 노트 — 제거·비활성화된 항목 (확인일 2026-08-30)

올리기 전에 돌려 볼 것

MySQL은 업그레이드 사전 점검 도구를 제공합니다. MySQL Shell의 업그레이드 체커를 먼저 돌리면 위 항목 대부분을 미리 잡아 줍니다.

mysqlsh -- util check-for-server-upgrade \
  root@localhost:3306 --target-version=8.4.0 --output-format=JSON

RDS라면 스냅샷을 복원해 사본에서 먼저 돌려 보는 편이 안전합니다. AWS는 블루/그린 배포로 전환하는 방법을 안내하고 있는데, 롤백 경로가 생긴다는 점에서 실전에서는 이쪽이 낫습니다.

8.4는 첫 기동 때 데이터 딕셔너리와 시스템 테이블을 자동으로 올립니다. 편하지만 되돌리기가 어렵다는 뜻이기도 합니다. 그래서 스냅샷이 업그레이드 전 필수 단계입니다.

업그레이드 확인 목록

[ ] 현재 버전이 8.0.x 최신 마이너인가 (8.0 → 8.4는 최신 8.0에서 출발)
[ ] mysql.user 에서 mysql_native_password 계정을 조회했는가
[ ] 애플리케이션 커넥터(JDBC·드라이버) 버전이 caching_sha2_password를 지원하는가
[ ] MANUAL·PARALLEL·QUALIFY·TABLESAMPLE 을 식별자로 쓰는 쿼리가 있는가
[ ] FLOAT/DOUBLE 컬럼에 AUTO_INCREMENT 가 걸린 테이블이 있는가
[ ] WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() 를 쓰는 복제 스크립트가 있는가
[ ] MySQL Shell 업그레이드 체커를 사본에서 돌렸는가
[ ] 스냅샷과 롤백 절차가 준비됐는가
[ ] RDS라면 확장 지원 자동 등록 상태와 청구 항목을 확인했는가
[ ] 최종 목적지가 8.4인지 9.7인지 팀 안에서 합의됐는가

어느 쪽을 고르든 지금 해야 할 일

목적지가 8.4든 9.7이든 다음 한 걸음은 같습니다. 8.4로 올리는 것이죠. 그러니 9.x 검증이 안 끝났다는 이유로 8.0에 머물 이유는 없습니다.

미루는 동안 생기는 비용도 분명합니다. 보안 패치가 더 이상 나오지 않고, 클라우드에서는 유료 구간 요금이 매시간 쌓입니다. 스키마가 단순한 서비스라면 사전 점검부터 전환까지 며칠이면 끝나는 작업입니다.

다음에 볼 글

DB 스키마를 버전 관리하고 있다면 업그레이드 전에 마이그레이션 도구도 함께 정리해 두시면 좋습니다. 그 선택 기준은 따로 올릴 예정입니다. 쿼리 성능이 걱정되신다면 인덱스를 만들었는데 안 타는 5가지 경우에 EXPLAIN 읽는 법을 정리해 뒀고, 트랜잭션 격리수준과 갭 락이 짝이 되는 글입니다.

이 글은 Oracle의 MySQL 지원 정책과 8.4 릴리스 노트, AWS RDS 공개 문서에 나온 내용을 기준으로 정리했습니다(확인일 2026-08-30). 지원 종료일과 클라우드 정책은 변경될 수 있으니 업그레이드 계획을 세우기 전에 본인이 쓰는 제공사의 최신 공지를 확인해 주세요. 잘못된 내용이나 보충이 필요한 부분이 있으면 댓글로 알려 주시면 반영하겠습니다.

참고한 자료

• MySQL 8.4 릴리스 노트 — Changes in MySQL 8.4.0 (2024-04-30) (확인일 2026-08-30)
• Oracle MySQL 릴리스 지원 정책 — LTS와 Innovation 릴리스의 지원 기간 (확인일 2026-08-30)
• MySQL 업그레이드 경로 안내 — 메이저 버전 간 LTS 경유 요구 (확인일 2026-08-30)
• Amazon RDS for MySQL 버전 관리 문서 — 표준 지원 종료와 확장 지원 (확인일 2026-08-30)
• AWS Database Blog — Upgrade strategies for Amazon RDS for MySQL 8.0 to 8.4 (확인일 2026-08-30)