핵심 요약
MySQL 8.0이 2026년 4월 패치 8.0.46을 끝으로 사실상 EOL(End of Life) 단계에 진입한다. 2018년 4월 GA 이후 8년간 지속된 LTS 기간이 마무리되는 것으로, MySQL 사용자는 8.4 LTS 또는 Innovation 9.x로의 전환을 준비해야 한다.
- 마지막 패치: 8.0.46 (2026-04 패치 발표)
- 지원 모드: Premier Support 종료, Extended Support 한정
- 대안: MySQL 8.4 LTS (다음 LTS), MySQL 9.x (Innovation Track)
- 마이그레이션 도구: MySQL Shell upgrade checker 8.4+
왜 지금이 분수령인가
MySQL 8.0의 EOL은 단순한 버전 교체 이상의 의미를 가진다.
- 지난 8년 동안 MySQL은 8.0 단일 메이저 버전 정책을 유지 — 사실상 표준이 됐다
- 2024년 LTS/Innovation 이원화 정책 발표 이후 첫 큰 분기점
- 대규모 클라우드 사용자(AWS RDS·Aurora)는 이미 8.4 채택 진행 중
8.4 LTS의 핵심 변화
1) Group Replication 안정화
InnoDB Cluster의 자동 failover·노드 복구가 운영 환경 검증을 마쳤다. 동기 복제 지연이 평균 22% 감소.
2) Caching SHA-2 기본 인증
mysql_native_password가 기본에서 제거된다. 일부 오래된 클라이언트(레거시 PHP·드라이버)는 명시적으로 활성화하거나 업그레이드 필요.
3) JSON 표 함수
JSON_TABLE이 모든 옵티마이저 경로에서 인덱스를 활용한다. JSON 워크로드의 N+1 문제 큰 폭 감소.
4) Vector Type Preview
네이티브 VECTOR 타입이 기능 미리보기 형태로 들어왔다. pgvector 수준은 아니지만 RAG 통합의 첫 단계.
5) Performance Schema 단순화
관측성 지표 누적·집계 비용이 평균 35% 감소. 운영 부담이 큰 환경에서 체감 가능.
9.x Innovation Track의 의미
Oracle의 새 정책에 따라 9.x는 매 분기 새 기능을 흡수하는 빠른 트랙이다. 단 LTS는 아니므로 보통 2~3분기 단위로 EOL된다. 다음 LTS는 9.7 또는 10.0 예상.
마이그레이션 5단계
- 업그레이드 체커 실행 —
mysqlsh upgrade_checker.run({"target": "8.4"}) - 비호환 SQL 감지 — deprecated 함수·프로시저·드라이버 식별
- 사용자/권한 점검 — caching_sha2_password 전환
- 스테이징 검증 — Performance Schema 차이 확인
- 롤백 플랜 — 8.0 백업·바이너리 로그 보존 (최소 30일)
주요 비호환 — 자주 부딪히는 7가지
| 변경 | 대응 |
|---|---|
| mysql_native_password 기본 제거 | caching_sha2_password 또는 명시적 옵션 |
| SQL_CALC_FOUND_ROWS 제거 | COUNT(*) 별도 쿼리로 분리 |
| 일부 프로파일링 명령 제거 | Performance Schema 통합 |
| old_passwords 시스템 변수 제거 | 비밀번호 재설정 |
| character_set_filesystem 변경 | config 명시 |
| ndb 클러스터 일부 옵션 | NDB 9.x 별도 트랙 검토 |
| 일부 JSON 함수 시그니처 | 코드 마이그레이션 |
클라우드 매니지드 동향
- AWS RDS for MySQL: 8.4 가용, RDS 8.0은 2027-04까지 Extended Support 가능
- Aurora MySQL: 5월부터 8.4 컴패티블 GA 예정
- Cloud SQL for MySQL: 8.4 LTS GA, 9.x는 Q3 도입 예정
- Azure DB for MySQL: 8.4 LTS 베타, GA는 6월
비교 — PostgreSQL과의 갈림길
이번 EOL을 계기로 PostgreSQL로의 이전을 검토하는 팀이 늘었다. 그러나 다음 시나리오에서는 MySQL 잔류가 합리적이다.
- InnoDB Cluster 기반 동기 복제 운영
- WordPress·Magento 등 MySQL 의존 OSS 운영
- OLTP 단순 워크로드 + 거대한 InnoDB row count
실무 권고 일정
- 2026 5월 — 8.4 LTS로 스테이징 환경 전환
- 2026 6~7월 — 비호환 코드 정리·드라이버 업그레이드
- 2026 8월 — 비프로덕션 환경 100% 8.4 전환
- 2026 9~10월 — 프로덕션 단계적 전환 (canary → 일부 → 전체)
- 2026 12월 — 8.0 인스턴스 0개 목표
자주 묻는 질문
8.4 vs 9.x 어디로 가야 하나?
운영 환경이 LTS 정책을 요구한다면 8.4. 빠른 새 기능이 비즈니스 가치를 만든다면 9.x.
MariaDB 11 LTS는 대안인가?
InnoDB Cluster·MySQL Shell 같은 Oracle 전용 도구가 필요 없다면 MariaDB 11 LTS도 합리적. 단 양사 SQL 방언 차이가 매년 벌어지는 추세.
RDS Extended Support는 비용이 어느 정도인가?
인스턴스 사이즈에 따라 시간당 단가가 약 25% 추가된다. 1년 사용 시 인스턴스당 수백 달러 단위 추가 비용 발생.
댓글 0