MySQL 8.0 지원 종료와 8.4 LTS 전환 운영 전략

지원 종료 이후 남는 공격 표면

MySQL 8.0.x Community Edition은 2026년 4월 30일 공식 지원이 종료된다. 오라클은 이 시점 이후 보안 패치와 버그 픽스를 제공하지 않는다. 같은 날 IBM Db2 11.1 LUW도 지원 종료 상태에 들어간다.

MySQL 제품 지원은 Premier Support, Extended Support, Sustaining Support 순으로 이어진다. 2026년 4월 30일 이후 MySQL 8.0은 Sustaining Support 단계로 전환된다. 기술 지원은 유지되지만 새 보안 패치, 버그 수정, 기능 개발은 중단된다.

이 상태의 RDBMS는 취약점 대응에서 불리해진다. MySQL 8.4나 9.x에 CVE 패치가 적용되면 패치 내용을 역추적하는 backport diff 분석으로 8.0의 취약점 위치가 공개적으로 드러날 수 있다. 인터넷에 노출된 MySQL 8.0 인스턴스는 미패치 취약점의 공격 표면이 된다. 금융·의료·공공처럼 컴플라이언스 요구가 있는 환경에서는 PCI DSS, HIPAA, SOC 2 감사 기준 위반도 검토 대상이다.

AWS RDS for MySQL은 표준 지원 만료가 2026년 7월 31일까지 연장된다. Aurora MySQL-Compatible 엔진은 2028년까지 MySQL 8.0 지원을 유지한다. 반면 온프레미스와 자체 호스팅 환경은 4월 30일 이후 바로 지원 공백을 맞는다. IBM Db2 11.1 LUW를 함께 운용하는 레거시 환경이라면 두 데이터베이스의 대응 순서도 조정해야 한다.

8.4 LTS에서 달라지는 호환성 지점

MySQL 8.4는 2024년 4월 출시된 첫 번째 공식 LTS(Long Term Support) 릴리스다. 지원은 2032년까지 보장된다. 8.0에서 넘어갈 때는 인증, 그룹 복제, 성능 스키마의 변화를 우선 확인할 필요가 있다.

인증 플러그인 전환의 영향

MySQL 8.4에서 mysql_native_password 플러그인은 기본 비활성화 상태가 됐다. 기본 인증 플러그인은 caching_sha2_password로 바뀐다. MySQL 9.0에서는 mysql_native_password가 완전히 제거된다.

영향 범위는 데이터베이스 사용자만으로 끝나지 않는다. 커넥터, ORM, 모니터링 에이전트, 레거시 드라이버처럼 MySQL에 접속하는 모든 컴포넌트를 검토해야 한다.

장애 조치와 메모리 관리 변화

그룹 복제의 일관성 기본값은 EVENTUAL에서 BEFORE_ON_PRIMARY_FAILOVER로 변경됐다. Primary 장애 조치 시 읽기 일관성을 강화하는 변경이다.

싱글 프라이머리 모드의 메모리 관리를 위해 group_replication_preemptive_garbage_collection과 group_replication_preemptive_garbage_collection_rows_threshold가 추가됐다. group_replication_exit_state_action의 기본값도 바뀌어 노드 이탈 시 동작을 더 예측 가능하게 한다.

복제 진단에 추가된 정보

performance_schema.replication_group_communication_information 테이블에는 MEMBER_FAILURE_SUSPICIONS_COUNT 컬럼이 추가됐다. 네트워크가 불안정한 상황에서 그룹 복제를 진단하는 데 활용할 수 있다. 복제 스레드의 사용자 귀속 정책도 정리돼 system user가 모든 포그라운드 시스템 스레드에 일관되게 할당된다.

전환 방식은 서비스 제약에서 고른다

⤢✕

제자리 업그레이드는 MySQL 8.4 바이너리로 교체하고, 첫 기동에서 자동 딕셔너리 스키마 업그레이드를 수행하는 방식이다. 다운타임은 생기지만 운영 절차는 단순하다. 소규모 서비스나 점검 시간을 확보할 수 있는 환경에 맞는다. 직접 롤백은 지원되지 않으므로, 업그레이드 전에 논리적 백업인 mysqldump 또는 물리적 스냅샷을 준비해야 한다.

블루-그린 전환은 별도 MySQL 8.4 환경을 만들고 데이터 동기화를 검증한 뒤 트래픽을 한 번에 옮긴다. AWS RDS Blue/Green Deployments는 이 패턴을 자동화해 거의 제로 다운타임 업그레이드를 지원한다. 전환 후 기존 8.0 인스턴스를 일정 기간 유지하면 롤백 경로도 남길 수 있다.

점진적 복제 마이그레이션은 8.0을 Primary로 두고 8.4를 Replica로 구성한 뒤 읽기 트래픽부터 옮기는 방식이다. 양방향(Duplex) 복제를 구성하면 8.4 Primary 전환 뒤에도 8.0으로 즉시 롤백할 경로를 유지할 수 있다. 가장 안전한 선택지이지만 복제 토폴로지의 관리 복잡도는 높다.

애플리케이션에서 먼저 확인할 호환성

마이그레이션 전에는 애플리케이션이 사용하는 JDBC, MySQL Connector/Python, mysql2(Node.js), Go MySQL Driver 등의 드라이버가 caching_sha2_password를 지원하는지 확인한다. 구형 드라이버에서는 인증 실패가 발생한다.

Hibernate, SQLAlchemy, Sequelize 같은 ORM이 사용하는 쿼리 패턴도 점검 대상이다. 8.4에서 제거된 기능의 사용 여부와 SET_USER_ID 권한을 포함한 privilege 변경사항을 확인해야 한다.

프로덕션 데이터의 서브셋을 8.4 스테이징 환경으로 복제한 뒤 통합 테스트와 성능 테스트를 수행한다. 인증 플러그인 변경으로 생기는 연결 장애는 이 단계에서 검출돼야 한다. InnoDB 스토리지 엔진 최적화로 8.4의 쿼리 실행 속도와 트랜잭션 처리량이 향상됐지만, 기존과 다른 쿼리 플랜이 선택될 수 있다. 주요 쿼리는 EXPLAIN ANALYZE로 실행 계획 변화를 확인한다.

지원 종료를 반복하지 않는 운영 체계

MySQL의 LTS/Innovation 이중 릴리스 트랙에서는 엔터프라이즈 환경의 버전 정책을 LTS 릴리스 기준으로 세우는 편이 맞다. MySQL 8.4 LTS는 2032년까지 지원되며, MySQL 9.x LTS는 향후 별도 공지 예정이다. LTS 릴리스 간 업그레이드 주기를 3-4년 단위로 계획하면 지원 공백을 피할 수 있다.

CVE 공개부터 패치 적용까지 걸리는 시간을 줄이려면 버전 추적, 패치 자동 배포, 회귀 테스트 자동화를 한 흐름으로 묶어야 한다. endoflife.date와 MySQL Product Support EOL Announcements로 버전을 추적하고, Ansible·Terraform 기반 배포와 회귀 테스트 자동화를 연계할 수 있다.

CMDB(Configuration Management Database)에는 조직 내 MySQL 인스턴스의 버전과 EOL 날짜를 기록한다. EOL 6개월, 3개월, 1개월 전에 경보를 자동 발송하면 지원 종료 직전의 긴급 대응을 예방할 수 있다. 사용 가능 버전 화이트리스트, 업그레이드 승인 절차, 롤백 절차 문서화를 포함한 거버넌스 정책도 필요하다. 이를 통해 개발팀과 DBA 팀의 역할을 명확히 할 수 있다.

MySQL 8.0의 지원 종료는 단순한 버전 교체 일정이 아니다. 8.4 LTS 전환의 부담은 비교적 낮지만, caching_sha2_password 전환에 따른 커넥터와 드라이버 검증이 병목이 될 수 있다. 블루-그린 배포나 복제 기반 전환을 선택하면 서비스 중단 위험을 낮추면서 이전할 수 있으며, 이후에는 패치 자동화와 CMDB 기반 가시성으로 다음 수명 주기 전환을 준비할 수 있다.